图1：CPG中对象化控制模型

    图1是基于CPG的内容提炼出来的一个对象化控制模型，有一些阅读过的朋友反馈说这个模型看不懂，觉得这是故弄玄虚，真正好的架构是让人容易看懂和理解的，而他们在阅读过程中没有觉得这个模型和实际设备编程有多大的关系。所以，基于这样的反馈，本文就再探讨下这个对象化控制模型的实际含义和应用。

    首先说明的是，这个Object就是一个对象。这个对象在ISA88的设备分层中可能是UN，也可能是EM。当在一个系统中对这个对象编程的时候，除了工艺逻辑部分的其他数据的接口就是围绕着Object的外围的6个要素。

    当然，有人会说，PLC编程不就是工艺嘛，这个工艺都没有咋编程？这个就是编程时候撸起袖子就干的类型，等到客户或者工艺变化的时候才发觉程序没有架构的痛苦。这里所讨论的标准化或者说架构，就是规范编程方式，同时解放工程师的双手和思考，让工程师只要专注于工艺理解即可。当把工艺理解透彻后，只要按照框架的方式在里面实现即可，而其他程序都不需要自己去编辑。本模型和昨天相比，加入了Object的FUNCTION，具体见下文解析。

    下面，通过一个工程师常见的一个虚假的生产线编程来解析对象化模型编程的思想。

    6.1 工艺概述

    图2：工艺概览图

    以上是某个生成线的一部分，物料由UN01_EM01进入，当物料到达UN01_EM02末端请求机械手(UN02)搬运，机械手(UN02)将物料搬运到UN03_EM01后由UN03_EM02进入后端工序。这是工艺的一部分，还有其他设备的物料也需要搬运到UN03_EM01上并流向下一个工序。

    同时，当物料在系统输送转运过程中，需要向上位机系统表明物料的关键路劲信息，便于上位机系统对物料的流向的追踪。

    至于上图工艺的设备分组是基于ISA88设备分层原则，UN可以单独完成一种或多种功能，和其他部件或是设备组成完整的工艺设备或者项目。一个部件可以是由一台设备组成，也可以是多台设备的集合。一个部件至少包括一个以上的设备或者智能设备。

    EM是指具备一定功能的，可以配合其他设备或是部件，组成整个工艺设备或者是项目。设备是各种元器件的载体，包括驱动器（电机、阀门等）、传感器等。

具体的可以参考如下链接中关于设备分层的相关描述。

    上图的输送机虽然都是只有输送功能，但很可能根据工艺需求的不一样，一些输送设备只是工频控制，一些是变频控制，甚至一些还有多段式速度控制等等。但标准框架程序不涉及这些内容，标准框架程序就是将Object周围的数据疏通并实现，这样工程师只要在这个框架内实现设备的工艺即可，并不需要关心其他程序的逻辑和位置。这样不管研发工程师也好，应用工程师也好，关注的重点就是工艺的过程和逻辑，这样就会有更多时间和精力用于设备工艺的改进和提升，从而使设备工艺更加合理、可靠实用，并实现设备工艺的迭代。

     除了工艺以外，以下内容就结合该工艺布局来阐述怎么在对象化模型程序中匹配并实现的。

6.2 Operation操作&Event

    图3：工艺架构图

    整个生产线的SCADA/HMI作为整个控制指令源，除此之外这些控制指令源还可能来自本地控制柜或者操作面板，控制指令包括启动/停止命令以及模式切换指令，这些统称为Operation(Command&Mode)。

    对于一个系统来说，当有操作执行的时候，该操作的作用对象可能是整个生产线，也可能是某个(类)设备。不管对象是哪一个，这些操作指令肯定要向设备层面发送，请求设备层面的状态更新。

    所以，对于任何需要控制的对象来说，操作指令是一个必须的部分,且CPG架构中还多了一个操作的诊断信息，包括这些操作的名称，操作的结果，操作的时间以及反馈的信息等。

    既然对生产线或者设备有操作指令，那设备有没有接收并按照操作执行，这些就是一个事件(Event)的反馈。在整个架构程序中，Event由Status、Alarm和Warning组成。

    比如系统模式按钮由自动切换到手动，但生产线或者设备可能由于工艺要求，只有当前工艺执行完成后才能切换到手动模式。也有可能工艺对这些没有要求，比如一个传输带，在任何时候都允许切换到手动模式。

    ……这些反馈包括模式的反馈，包括当前状态的反馈，包括报警和警告的反馈等等。

    所以，Event既是当前事件的反馈，对于一个控制系统或设备来说，也必然要将一些必要的状态和报警警告信息反馈到工作人员，便于工作人员对于设备本身状态以及当前生产系统运行状态的反馈。

    对象化模型编程中把Event整理归类为一个大类，使其囊括整个的生产系统的生产和设备信息，这可能就是和普通编程方式的一个区别（普通编程可能只是把需要的编写出来）。

    所以，对于一个对象化编程框架或者说一个控制系统来说，操作指令(Command&Mode)和Event(Status、Alarm、Warning)是必须的两个要素，没有这两个要素就无法构成一个完整的控制系统。和普通编程的区别在于，你是愿意用一个模板免去这些程序呢还是愿意每一次编程都自己重新规划实施。

6.3 Paraments参数

    对象化模型中写的是必要的参数，这些参数是保证设备运行和生产要素的一些必要的前提条件。

    比如本文工艺图中的输送机可能的设备参数就包括如下一些：

    输送设备的速度设定，可能包括第一速度和第二速度

    输送设备的长度数据，这些数据可能用于设备节能的一些算法的依据

    输送设备上光电位置的堵塞时间的设置，若是将光电看成一个CM的话，可能还有更多的参数设定

    ……

    除了这种设备运行参数，每一个输送机或这机器人站可能还需要设置一些物料生产的参数。比如机器人抓取物料的速度、输送机上物料的前后间隔……这些影响生产效率的一些必要的参数可能不是所有控制对象都有，大部分情况下都是在影响生产效率的关键节点的设备和生产线需要。

    也有人说，这些参数每一个设备可以在FB块直接使用即可。但对象化模型编程的方式就是需要你把这些功能做成通用块，在每一个需要的地方调用，这些参数化的东西即可通过FB块的接口引进到相对应的背景数据块即可。

    当然，这些都需要工程师对工艺以及对象的物理运行过程完全并正确理解，这样也会使整个程序的可靠性得到极大的提高和稳定，因为工艺和物理运行过程在程序中完整的再现。

    所以，对于一个控制系统中的设备来说，这些不同参数根据设备工艺和运行效率，可以用不同的自定义数据类型(UDT)来表示，便于设备的模块化编程的时候基于工艺需要的自由定义和选择。

6.3 Performance性能

    Performance可以看成某些运行参数的实际性能的反馈。在CPG中是明确的定义了OEE设备综合效率。

OEE其中的一种计算方法是由可用率，表现性以及质量指数三个关键要素组成：

OEE=可用率*表现指数*质量指数

    其中：

    可用率=操作时间/计划工作时间

    它是用来评价停工所带来的损失，包括引起计划生产发生停工的任何事件，例如设备故障，原材料短缺以及生产方法的改变等。

    表现指数=理想周期时间/实际周期时间=理想周期时间/（操作时间/总产量）=（总产量/操作时间）/生产速率

    表现性是用来评价生产速度上的损失。包括任何导致生产不能以最大速度运行的因素，例如设备的磨损，材料的不合格以及操作人员的失误等。

    质量指数=良品/总产量

    质量指数是用来评价质量的损失，它用来反映没有满足质量要求的产品（包括返工的产品）。

    除了OEE以外常见的性能反馈数据就是当前总的生产速度，比如上述工艺图中机器人站每一个小时的实际抓取工件的数量等等。

6.4 Identity

    本文列举的工艺要求说明，物料在系统输送转运过程中，需要向上位机系统表明物料的关键路径信息，便于上位机系统对物料的流向的追踪。

    根据工艺要求，物料以下的节点需要向上位系统报告关键路径信息：物料的起点（UN01_EM01）、物料的等待点（UN01_EM02）、物料的接收点（UN03_EM03）以及物料的流向点（UN03_EM02）。

    在向上位系统发送信息的时候，只有将这些点设备的名称也加入到信息当中，上位系统才能由此而得到物料的路劲曲线。

    所以，Identity也是一个控制对象中必须的要素。

    因为除了上述工艺的要求以外，Event中的信息也是需要跟设备绑定。比如UN01_EM01的报警信息，都是需要和设备绑定，否则所有的信息根本无法区分发生的位置。

    CPG中的信息或者Event都是有时间标志戳，那Identity就可以理解为位置标志戳，很明显，对于一个事实的描述，时间和位置信息都是必须要交代的要素，否则无法构成一个完整的事实描述。

OMAC PackML Machine Simulation

https://support.industry.siemens.com/cs/cn/zh/view/109768201/en

SIMATIC CPG Template

https://support.industry.siemens.com/cs/ww/en/view/109475572