到底怎么去理解PLC程序标准化

admin

当前很多人已经有做标准化的意识，一般都会涉及plc程序标准化。周围以及网络上的很多同行在谈论标准化时会有一些绝对的定义，比如“只要程序中不是这样或者只要程序中有那样的变量，你这都不是标准化！”每当听到类似声音的时候，我的内心都在思考，难道PLC程序标准化的评判标准就是这么一句无法考证的话吗？

那到底怎么去理解PLC程序标准化呢？这个肯定无法用一句话或者一段文字来描述。如果您看到这里还没有离开，我们不妨往下一起探讨下PLC程序标准化的内容。

1、标准化功能
所谓标准化功能就是一些常见的可以供所有人重复使用的函数或者实例化功能，比如一个电机的控制功能、西门子的Epos的功能块(FB284/FB285)。

但谈论标准化功能的时候也要分情况探讨，看这些标准化功能的作用范畴。

◆产品供应商或者独立的组织
比如西门子这样的供应商，他提供的库或者功能一定是要能所有的人都能使用，比如Epos的功能块、基本运动控制库LAxisCtrl等很多类似的库，这些标准化功能主要供所有各个行业的使用，所以它们不能有很多局限性的东西，比如里面应用到M寄存器等类似的变量(因为这些变量开发者可能会用到)。所以，这些标准功能一般都是需要实例化的功能块或者一些函数，并且里面的程序变量一般都是静态变量以及临时变量。

由于潜在使用者可能是所有行业，所以这样的功能块或者函数的功能一定是针对产品的功能，不会涉及到具体工艺(飞锯控制库属于工艺标准库，不是功能库)，这样大家只要参照文档即可像使用PLC自带的指令一样方便，并不会对自己的程序带有任何负面的影响。

还有一些独立的组织，常见的比如PLCopen组织，他们定义了一整套的运动控制的相关指令和方法，这些指令就是各个PLC厂商都在应用的MC指令。用过不同品牌PLC的人肯定会发现，大家的运动控制指令从名称到实现方式都很相似，不同的只是依据各个品牌的基因做了一些相关的改进。

◆设备开发商或者系统集成商
这类开发者开发的标准功能都是只有自己公司或者项目才有使用价值，对于除他自己以外的第三者只有思路的参考价值，并不能直接使用。

比如一个电机控制的标准功能块，若要将电机所有存在的可能性功能做在一个功能块，那这个功能块的管脚以及功能会非常庞大。随便列举下，电机可能存在的工频控制还是变频控制，有没有多段速控制，有没有方向的切换，远程启动还是本地启动，不同控制方式的错误诊断……等等，把这些全部实现的话，管脚是不是非常庞大(在PCS7中经常看到很多管脚)。

对于一个设备开发商或者系统集成商来说，匹配他们的电机控制需求可能没有那么多，同时对于一些工艺设备来说，往往简单的一个电机块也只是工艺设备需要的底层功能块(因为电机的控制需要结合工艺需求实现不同时序要求，Epos也可能是工艺设备的底层块)。这个时候，这个标准功能就没有必要大而全，也没有给第三方使用的必要。反而，这样的标准功能块的效率会更高，对于和工艺的匹配也是最佳拍档。

由于不需要考虑第三方的使用需求，这个时候我可以结合自身程序架构编程。有的程序架构中可能会使用一些M寄存器的变量，这些变量都是自身程序架构中已经定义好了，即使有需要使用的时候也会有一些预留区域，在设计标准功能块的时候就需要结合自身程序架构理念，实现工艺和程序架构的无缝匹配的程序。

这也是很多国外以前的程序中M变量频繁出现的原因，因为这些程序和自己设备工艺以及程序架构是无缝匹配的，同时也不需要像西门子一样提供给可能存在的所有从业者使用。

这样的功能块对于其他人来说不是标准功能，但对于该设备开发商或者系统集成商来说，这就是他们的标准化程序，是他们效率和质量倍增器(3-4个工程师一年可以做几个亿的项目，这是我的实际经历，这就是倍增器的加持效果)。

在Portal优化使用的时代，不建议使用M寄存器，这是另当别论。

2、标准化框架
在汽车行业或者包装行业可能都会用到Epos功能，而大家都知道汽车行业有一个规范的标准架构Sicar，包装行业有OMAC的ISA88标准。那在使用Epos的标准功能块的时候可能就需要做一些针对性的修改，用于匹配各自标准的规范和逻辑实现(比如控制和状态反馈的逻辑)。

那所有在该行业的企业都能合适上述的一些行业标准化架构么？本人对Sicar不是很了解，但对于OMAC的深入研究后发现其实并不是不一定。这类的标准有特定的前提以及特殊需求(OMAC里面主要为计算OEE)，一些该行业的边缘从业者或者配套企业来说，由于一些工艺需求根本无法匹配进去这类的标准架构。

所以说，标准化架构还是要和自身工艺以及整体的公司设计有关。比如物流行业，除了设备的控制以外，很多时候还要考虑物流的信息流程。这些信息流在PLC程序中怎么和架构程序实现，怎么和设备的控制相结合，让实际项目中方便简单的使用，那这些都是需要在标准化中体现出来。

这就是说，所谓的标准化并不是指一个架构或者规范就能完整覆盖所有行业，更多的都是一些思路的借鉴，然后结合公司自身的工艺要求和硬件基础，做成一个符合自身要求的程序架构。

当程序架构搭建完成后，就可以基于该架构的方式和方法，做符合自身工艺要求的程序库。当这些程序库随着时间的积累以及bug的不断解决，这些工艺程序块和程序架构的稳定性只会越来越高，后续PLC程序开发就会越来越节省时间，并能提高效率和质量(标准化的本质就是提高质量)，这样就能用最少的成本实现最大化的利益。

在以前经典Step7时代，很多标准架构中就存在很多M寄存器的变量。比如一个控制字是Word的名字是MW_Control，其地址是MW2。其中，M2.0到M3.7分别对应不同的控制命令，在程序中我只要对布尔型变量处理，然后在传递的时候直接用MW2以Word的形式传递，这样整个程序的管脚就会由可能存在的16个布尔管脚变成一个Word型的管脚。

在Portal的优化处理时代，M寄存器使用反而不高效，此时要像上面那样处理的话，还必须先定义一个由16个布尔型变量组成的自定义数据，然后处理结束后还必须通过SCATTER指令将这16个布尔型变量在Word型变量中序列化。


图1 SCATTER指令图

当然，需要说明的是，在标准架构中都是按照面向对象的编程思想编程的，对象的所有变量的转换都是通过实例化数据完成的，除了架构程序中使用到M寄存器以外，实例化程序中是不需要使用M寄存器变量。

以上描述意思就是，一个标准架构只要满足覆盖自身工艺需求(比如物流的信息处理)同时能简化工作提高效率，有着良好的工程接口和数据接口，让自身所有的工艺对象都能无缝的实例化，工程人员的工作效率和质量大幅提高，这可能就是一个符合自身工艺需求的标准架构。而这些工作更多的是企业自身将工艺需求和规律总结出来，然后将这些共性的东西提取出来，形成一个总结性的东西。

比如所有标准架构中都会有的控制指令的下发以及状态的反馈，那这些就是一些共性的规律。标准化架构只是把这些共性的内容通过一定规范的PLC程序和方法体现出来，只是在这个规范中要和自身工艺相结合。

所以，标准化其实是一群对象共性的内容的提炼和总结，让这些共性的东西规范化，这样就让编程人员聚焦在工艺的研究上，让工艺更加的成熟和进步。

也就是说，很多标准化的规范和方法，更多是具有借鉴参考意义。当然，这不是说企业自身都能自己搞成一个标准化体系，这些共性的内容没有一定的时间经验和积累，很可能您总结的内容不是很全面，这样就变成了您的标准化之路一直在路上。

3、工艺标准化
是不是有了上述说的两个方面的内容，所谓的标准化就完全实现了呢？非也，请参考下面的图示列举的内容。


图2 设备标准化系统图

标准化的目的是提高质量和效率，但标准化的基准一定是基于设备工艺。当完整的标准化做好以后，对于任意一个工艺设备，只要通过合适的指引，比如工艺代码编号，其整个工艺设备的各个标准资料和软件都有队形的资料和指导说明。

比如上图，只要知道设备的工艺代码，那该工艺设备的机械结构和运行数据就是一个标准设计，这些数据和说明可以在这一类的设备工艺说明书中可以了解到更详细的内容。

对应的，该设备的标准图纸也会随着工艺代码而出现，并且在整个标准电气图纸架构中有相关的接口融入到整个系统的电气设计图纸中。

同理，该工艺设备的标准实例化程序以及对应的标准程序架构也相应的有对应的资料和程序。当然，随着信息化的到来，该工艺设备的信息接口以及整个IT的软件架构也有对应的接口提取。

这就是一个工艺设备的完整标准化系统，当实际设备对应的功能代码有了之后，该类设备的上述四方面的信息和资料都会被提取出来，这才是一个完整的标准化内容。

当然，上述的内容就是一个架构设计，里面还有很多细化的内容。而要保证这些细化的内容和程序能实现不断的迭代和更新，那就需要具备相应的资料体系的规划和管理。
……
所以，一个合适的标准化体系内容是非常丰富的，也是很具体的。只有和工艺完美结合的PLC程序标准化才是一个符合实际需求的标准化体系，否则再好的程序架构也可能只是一个plc编程规范而已！