0.2 标准化架构

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

那所有在该行业的企业都能适用上述的一些行业标准化架构么？笔者对Sicar不是很了解，但通过对OMAC的深入研究后发现其实并不一定。这类标准有特定的前提以及特殊需求（比如在OMAC里面主要为计算设备综合效率），一些该行业的边缘从业者或者配套企业来说，由于一些工艺需求的限制，根本无法匹配这类的标准化架构。

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

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

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

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

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

图0-2 SCATTER指令图

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

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

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