SIMATIC CPG Template案例解读：面向数据编程

  CPG(消费品包装)模板提供了一个基于模块化设计(ISA-S88 Make2Pack)的清晰和经过测试的项目结构。机器制造商得到了一个易于诊断和易于扩展的项目基础。计算机显示终端得到一个统一的机器行为(OMAC PackML)和一个标准化的

  最先进的包装机器和生产线是极其通用的，必须要提供最高程度的灵活性的高吞吐量率。降低总拥有成本和投资安全也是核心问题。大计算机显示终端希望来自不同供应商的机器具有相同的可用性和诊断功能。此外，一定要保证从上层系统对机器数据的标准化访问能够分析产品流程，获取机器运行时间或计算性能数据。实现这些目标的关键是采用国际标准。

  这个应用程序模板，称为SIMATIC CPG模板，可当作实现OMAC PackML兼容项目的基础，并为您提供具有明确定义的接口的测试代码，包括一个HMI模板。

  SIMATIC CPG模板结合了用于模式和状态管理的PackML指南和标准接口(PackTags)，以及sa - s88 Make2Pack模块化概念和集成的报警概念，为您的OMAC兼容项目提供了一个随时可用的解决方案。

  上面的文字和图片，我是直接从公众号《屯蒙闲谈》的文章《西门子案例推荐——SIMATIC CPGTemplate》搬过来的。当然， 他也只是对官方文档的简单翻译，并没有个性的解读。所以整体看起来相当规范整齐，也显得很有模板的范儿。

  然而当我们真正拿到这个模板，打开程序来阅读的时候，却根本不是那回事了。 或者可以说，跟想象的完全不一样。

  我为了学习理解PACKML， 拿这套资料学习了很久了。也组织了专门的学习群，大家一起探讨。然而花费了很长的时间， 仍然晕头转向，一头雾水。相信所有初学PACKML的同行也都和我一样。我们的学习群里的同行，大多数人的认知也是如此。

  这套程序， 如果不冠以模板的名号，任何人拿在手里看来，也就是个普通的自动化工程师为完成项目任务，所完成的一套控制程序。方法极为普通， 架构也极为普通。并看不到有任何先进之处。

  而且，程序也毫无模块化和封装性可言。程序中大量使用全局DB块，所有程序都是在对这一些数据块的访问中实现。由此也没办法实现模块化。其中的大量模块，虽然以FB的形式建立，但那些FB都是只使用一次的，并不能被重复调用，甚至这些FB连参数管脚都没有。就是一个光秃秃的FB调用一次而已。

  所以， 假设系统中有2个CM是完全相同的， 比如EM01-CM02与EM02-CM03是完全相同的设备逻辑。那么按照面向对象的理论，我们原本应该把它们的逻辑部分设计为一个类比如FB: CM-TYPEA，然后分别实例化为2个实例，分别对应了使用的工位EM01-CM02与EM02-CM03。

  然而实际中并非是这样。由于逻辑中访问的除了自身设备产生的数据以外，还访问了全局数据的与各自工位对应的数据工位，与各自类型对应的配置类型的数据值，其中也包含工位信息,工位代号是数据路径的一部分。

  所以，最终，每一个程序模块的逻辑语法虽然看起来相同，但由于数据的地址千变万化，就根本做不到封装，而是只能各自单独的FB了。以致于我在学习一些视频讲座的时候，有人讲到实例化， 实例化的结果竟然是多个FB， 是所谓的面向对象的实例了。这样的对面向对象的认知， 太让我惊掉下巴了。嘿嘿嘿。

  我在入手这个程序之后，连续读了好几天，都对这一处理不能理解。其实是对PACKML本身实现的功能和目的不太了解。所以就不免晕头转向。跟人探讨，也没有有用的收获。

  直到有一天，慢慢对PACKML的数据结构有些比较深刻的认知后，发现， CPG这个例子，其实它不是在面向对象编程，甚至也不是传统上的面向工艺编程，而是在面向数据编程！这是我给它做出总结后所独创的一个词汇。

  PACKML的核心在于设备数据的统一管理，一个系统UN中，有若干个设备EM以及子设备CM， 需要在设备正常运行过程中对各自的状态进行收集，指令进行分发传递， 报警状态记录，以及给定参数的分发，配方管理， 设备正常运行数据分析OEE等等。

  所以，相比较于普通的PLC设备控制程序， PACKML的重头戏在于这一些数据管理的实现方式。而这一些数据的规模，比起传统PLC控制的零星的控制字、状态字、给定值、运行值等多出来N多倍，甚至，整个CPG程序中，其实只是做了这一些数据的处理工作，具体的设备怎么动起来，还绝对没顾得上涉及。

  当然， 这对PLC生产厂商来说是好事。原本一个逻辑，几K的内存就能完成的控制任务，现在当套上PACKML规范之后，可能就要动辄过M的内存的控制器才能实现了。同样的设备的控制，可以卖给他更贵的PLC了。

  这对PLC工程师也是好事。原本你在PLC程序中只简单做做起保停，让电机伺服跑起来，做下数据格式转换，运行多个方面数据显示，就能完成设备的设计。在电工们看来，这点工作着实简单，他们也一样能做到。所以他们都觉得可完全与你是平起平坐的。而在工厂同事和领导看来，你做的事和电工也确实没多大差别，所以也确实不该比他们的工资高出来好几倍。

  CPG模板的实现过程中，由于以数据为核心， 倒是针对每个模块严格的对应设计了数据，如文章开始的图片示意，其实每一个六边形对应的都是一个数据区。然而为实现对这一些数据的管理，所设计的程序块就只好围绕着这一些数据穿针引线，眼花缭乱。体现在每一个全局数据块， 被每一个FB/FC块随意使用，按需访问，毫无规律可言。

  看到穿针引线的字眼，有没想到我有写过的一篇文章《【万泉河】PLC程序中的面条代码》？这些针线和面条代码啥不一样的区别？其实就是面条，一模一样！

  所以，在实现面向数据编程的同时，代价便是通篇程序都是面条代码，垃圾程序。

  我在尝试将CPG中的这些UN, EM ,CM的模块进行封装，以达到程序能重复使用的模块化，甚至，我期望的终极目标是，将PACKML的相关功能实现完全封装，任何一套传统设计的设备，比如一个完全不懂得PACKML机制原理的工程师设计的设备程序，比如一台注胶机，或者桁架设备等。现在设备要卖给新兴行业，对方的行业规范需要设备提供标准的PACKML接口， 那么只需要加装一套完全封装好的库模板，就能轻松实现了。

  然而目前的CPG模板， 还远远不能够实现。除了这些程序代码全部不能复用之外，甚至作为设计核心的数据，也并不是复制过来就能直接用的。毕竟每一套设备，工艺架构均不同，那么UN/EM/CM的数量也全部各不相同。比如它原始设计的EM01中原本有3个CM， CM01,CM02，CM03，而我们的新设备有6个CM的话，数据结构也要重新规划增加CM04, CM05,CM06。当然， 配置文件， 配方文件， 报警数据，全局数据等相关的部分也全部需要再次规划管理。再加上原本的程序代码也大都不能复用的，所以基本上来说参考这套CPG模板的结果就是要你消化理解之后，完全从头另起炉灶。

  每个人都要从头造轮子，丝毫没有经验的总结和技术的传承，这就完全偏离了技术发展的正常轨道了。绝不是我们技术工作所要的样子。

  我们来尝试对每一个EM/CM做独立封装，其模块的自身数据当然可当作管脚参数来输入。但对于配置数据和全局数据，就不适合再用管脚来传递数据了。会导致模块的管脚数量多到天量，模块调用时难度太高，即违背了低耦合的原理。所以必须在模块内部实现对全局数据和公用数据的管理。

  可以参考高级语言编程中的对注册表和数据库的访问的实现方式。每一个函数功能模块，在需要的时候，各自分头对注册表的对应位置读取数据，也将模块产生的数据送到数据库中。其实PACKML的众多全局数据块，起到的就是数据库的功能。而CFG配置相关的数据块， 起到的则相当于注册表的作用。

  那么对这一些数据的有规律的进行访问，就成了一个问题。比如同一类数据，在EM00中会是：GLV.EM00.STS， 而对EM01则对应为GLV.EM01.STS。程序块要想实现逻辑统一，就需要对这个包含有EMxx 的路径实现动态编程，即在程序逻辑内自动适应地址的变化。

  然而对于PLC编程来说，其本质上是基于绝对地址的，EM00, EM01本质上只是符号。即便是PORTAL中实现了符号编程，但要对符号地址再进行动态变化，其实是针对符号的指针的编程。

  把需求归纳一下：做一个FB，一个字符串类型的输入管脚EM， 一个int输出OUT。2次调用，当EM=’EM00’ 时，从数据块GLV.EM00.DATA1中读取数据送到OUT，而当EM01时则从GLV.EM01.DATA1读取。数据块GLV中EM是一个结构体，除了DATA1之外，还有许多其它的值。这里只读取一个，实现了当然也可以同样方法处理其它的数值。

  不许在FB块内做枚举，即不许用CASE语句把可能的EM00，01，02…..的代号全部囊括，因为这些代号其实是设备的名字，并没有规律可言。而因为模块要实现复用，做好了之后是需要封装的。封装之后密码保护，就再也不许打开修改了。