0130 【万泉河】用烟台方法重写PACKML模板库

0130 【万泉河】用烟台方法重写PACKML模板库

我近2个多月来在研究PACKML。

有写过2篇小作文题目分别为《1219 PACKML 学习群》和《1228 【万泉河】 SIMATIC CPG Template案例解读：面向数据编程》为证。

并由此组织了PACKML的群，拢聚了一批有志于在PACKML的应用方面做些知识储备和积累的同行，现在已有20多位。 也通过与这些群友互帮互助，我现在已经收集了除西门子之外的更多品牌厂家所出的PACKML库模板样例和文档资料，包括AB, 汇川，三菱，倍福，施耐德等。

我拿到这些原厂家的例子模板后，第一件事，就是去找到其中有共同特征逻辑：

还别说，大同小异，虽然每个品牌规划的UM，EM，CM数量和架构各不相同，但这方面还真不愧一个模子套出来的。

以至于我把这些截图发到群里后，就有位烟台方法的学员笑问道，如果设备UM中的EM有100个，难道他们还要把这段逻辑接100列不成？

我说，恐怕是的。

这些厂家（基本上可以认为代表了行业所有厂家）所做的所谓模板库，只不过是实现了他们预设的UM/EM/CM数量架构下的逻辑关系。其实更大可能的是，各厂家的应用工程师做了一套PACKML接口需求的项目/设备，做的过程中也没有什么模块化标准化的讲究，只不过是实现了这个接口，然后就把这套资料归档分享出来了。

当然各厂家在分享之前处理的深度不太相同，有的厂家修理的干净，而有的厂家基本未作修理，就那么原汁原味的项目打包分享了。

比如汇川：

好像工程师做的原本是一套汽车座椅安全检测的设备。

所以， 很显然， 这不是你可以拿来当作模具的模板，模块复制实例化一下就可以直接实现PACKML功能了。而我更愿意描述它是一个样板工程。 即我们可以参考样板工程中怎么做的，哪一些地方加入了PACKML和状态机的元素，然后在自己的项目中也如法炮制。

当然，也完全有可能人家厂家就是在当作样板来分享，内里并没有模板的暗示，只是我们同行们，甚至只有我自己，想多了。

按照我如上的分析，极大的可能性是，现在的整个行业，所谓的PACKML模板库压根不存在。有的只不过是一个个的样板示范应用。

这些样板工程，只不过是实现了功能需求，即满足OMAC所要求的，机器对外的接口是统一规范的。 而机器内部的编程方法如何实现的，OMAC并不涉及。 最终只要接口满足PACKML的协议即可。

这里，再阐述一下什么是OMAC组织所定义的标准化。

比如一个生产厂，投资建设了一条全自动的包装生产线，其中包括了输送线，码垛机，AGV，竖井，标签机，缠膜机，打包机等等。这些机器通常是不同的厂家提供的，当然也有可能其中的一部分设备是同一个厂家提供的，至少会有设备供应商会倾向于整体大包，全由它一家来干，钱他自己一家挣。然而即使是一家大包，每台设备具体工艺不同，在设备厂内部也会由不同的部门独立承担。

而标签机, AGV等更方便做成标准机的设备，就没那么容易由一家大包公司完成，反而那种有传统行业经验的专业厂家会更擅长。所以即便大包公司拿到订单后，也会把这一专机分包给另一家更强的专业厂家。

总的来说，不管在一条生产线中的单机设备是从一家供应商购买，还是从多家供应商引进，在最终使用方的企业看来，都可以认为这每一台都是一台完全独立的设备，然后整条产线的运行就是在协调各设备之间的运行信息和指令和数据，因而需要它们有统一的接口。

这个接口是数据层面的接口，前提当然是各设备在物理协议方面先达成统一。 这反而比较容易。现在工业以太网已经普及，所以各设备当然都会提供以太网接口，然后组成一个局域网。

而在通讯协议方面， OMAC选中了OPC UA，并与OPC组织达成了共识，共同推进协议的普及，即编号xxxx 的白皮书。具体编号读者自行查询。

而在OPC UA 之上，各设备再提供了统一的接口规范即PACKML后，整个工厂范围的自动化系统的互联互通就有了可能。即便这些设备如前文所述来自不同的供应商，甚至使用的不同品牌的控制系统，包括不同品牌的PLC， 甚至有设备使用的不是PLC， 而是PC， PAC， 单片机等，都无所谓，只要其提供的接口符合OMAC提出的PACKML的规范，那就可以。 这一点OMAC的文档中也有提及。

所以，以后大家再看到以OMAC PACKML和状态机等关键词的PLC编程标准化培训辅导的时候， 要意识到，他们搞的并不是PLC程序逻辑的编程方法的标准化，而只是给你解释普及PACKML接口标准，帮你把设备的对外接口给标准化成一台状态机。

而如果你跟他们说我做的行业并不要求PACKML， 或者我的设备或者系统原本就是独立运行的产线， 不需要跟其它的系统对接，甚至你要求对方的老师提供给你一个完全没有PACKML印记的程序架构用来学习， 你就会发现，他们给不出了。 或者给出来的也没有任何培训指导意义，就是完全普通的，几十年来常见的编程架构方法， 与你随便从网上下载到的，或者群文件中分享到的免费的项目资源案例没有什么区别。

同时，与各PLC厂家给出的各种案例所用的方法也没什么区别。 而厂家给出的带PACKML功能的例子程序与不带PACKML接口功能的例子程序，编程技巧方法也没有任何相同。PACKML就相当于一件外套， 穿了特定的外套和普通的外套，而内核并没有什么本质的不同。

而这件外套的制作生成方法，也仍然是使用的同样的技能方法，即本文开篇所贴的各个厂家的程序截图。

PACKML接口是复杂的，为实现PACKML的功能所做的数据传递和整理工作，也相当复杂。OMAC规范中规定了PACKTAGS_C, PACKTAGS_S , PACKTAGS_A三种数据，分别对应了COMMAND指令， STATUS状态和ADIMI管理。 设备除了需要向上提供接口之外， 还需要在内部实现状态机的UI显示和操作，报警历史记录的管理等等。 这些需要在内部配合HMI来实现。

取决于所做设计的完备程度，各厂家所做的PACKML案例，复杂程度不同，其实主要就是做了这些工作。 其中最复杂的是我入手学习的西门子的CPG_TEMPLATE。它除了计算了设备的OEE等指标之外，还在PLC中做了报警记录的归档，报警信息和时间戳均保存在PLC中，因此在数据块中开辟了规模巨大数组，耗费的系统巨大，由此也提高了对PLC性能资源的需求。

而有的厂家的报警信息是按照通常的方法在触摸屏中实现记录缓存的，所以PLC程序部分就显得简化的多。

但总的来说，为了实现PACKML的功能，即为了给控制逻辑穿上PACKML的衣服，所耗费的逻辑资源，一点都不比系统的控制逻辑少，在简单机器中，甚至要超过控制逻辑本身。

所以，当我开始介入了解PACKML这一领域之后，了解了PACKML所要求的数据接口的种类和性质之后，很快就意识到，这是摆在我面前的另一个重大课题：用烟台方法重写PACKML。

前面我一直在打比方，对于一套遵循PACKML接口规范的设备程序来说， PACKML接口部分就像是一件衣服。我在之前做的烟台方法的标准化架构，只是针对没穿衣服的本体部分。 而现在有了PACKML需求后，这一部分实现过程又足够复杂，那么我就需要再用烟台方法把PACKML部分再重写出来。

在我的理想里， 比如原本一台设备UN，在没有PACKML的时候，我或者烟台方法的继承者做出来的程序块叫做FB_UN01，那么，给它穿上PACKML的外衣后，就是另一个FB_UN01_PM，即可。

即，我们做好了的FB_UN01和FB_PACKML，在需要的时候将这2者作为父类，融合派生出一个FB_UN01_PM的子类，子类中只做简单融合对接，即完成了穿衣工作。

大家在PACKML的各种资料中可以随处可见UN/EM/CM的多层设备层级的架构，而其实，这并不是OMAC的专利，而是ISA88或者ISA95或者ISA106早就定义过的东西，OMAC只不过是直接使用这种架构定义。 而我在烟台方法的理论中也同样提到过使用了这些标准架构。只不过我并不只是简单的使用了这3个名字，而是从下至上分别以L1/L2/L3/L4来定义。 因为实践中， 设备的层级绝不止3级，而会因为行业不同，拓扑结构异常混乱，除了层级远远不止3层之外，而且会有可能某些个别的设备单元，它自身会在一个复杂架构的顶端，然而当它被封装完成后，又会处于某个较低层级的一个单元。 比如一台制氮机系统，它的工艺结构足够复杂，你可以认为它是一套完整的UN，然而当它被集成入某条生产线内部后，又有可能只是一个CM的身份，与其它的电机，阀类等CM处于相同的。这些都是需要有实际的项目设计经验之后才能领会到的。而不是简简单单只对着标准的白皮书照本宣科。

而我对烟台方法重写的PACKML库的另一个目标是，它应该是通用于所有PLC平台的。 即应该可以很容易从一个PLC平台移植到另一个平台。就像烟台方法架构的程序已经实现了跨平台的移植一样，PACKML衣服应该更容易实现移植。 因为它的内容全部是逻辑层面上的，根本不涉及硬件。甚至大批的代码就是用SCL写成的，就直接可以移植使用。

现在的各原厂家做的PACKML的样板工程差异性巨大，其实主要是实现的功能复杂程度不同。导致工程师应用起来困难，甚至从一个品牌换到另一个品牌之后还要再从头学起。 当然也不是说这些厂家的模板程序就毫无用处了。 至少，他们做过的HMI部分的界面是可以直接拿来使用的。 前提条件便是，我们经过烟台方法整理过的数据，与其原来的数据结构保持一致就可以了。 而HMI部分的工作量通常是最大的，而且，不同的HMI之间的画面是不能移植的。

（我同时也在想， 有PLCOPEN组织实现了PLC程序语言的标准化，啥时候会有HMI画面语言的标准化呢？是PLCOPEN组织来做，还是将来会另有一个HMIOPEN组织？）

而其实我在入手PACKML的近2个月里，就一直在不断研究用烟台方法改写PACKML的问题，针对研究过程中遇到的CPG例程中的面向数据编程，也逐渐找到了处理的方法，最终可以实现模块化的封装，然后可以以派生的方式，直接叠加到原有的烟台方法程序架构上，即实现了设备程序的PACKML接口。

只不过现在的问题是，需要落地实践的机会。 如果有公司或者机构，在PACKML的标准化方面有一些需求，可以跟我联系共同开发落地。 当然，整个项目仍然是一个巨大的复杂课题。如果有大学或者科研机构有在这方面立项的意愿，应该会是一个不错的课题。

申请立项一个科研项目，研发成功后，可以为行业提供一套标准化的模块模板，任何PLC品牌，包括现在还没有在PACKML方面开展推广工作的国产新品牌，在需要PACKML功能的时候，只要把模板套上，就可以简单完成，对于PACKML的推广落地，应该会起到极大的助力作用。

我期待能从中做些贡献。