之前与OPC基金会张Sir电话交流，谈及对于OPC UA的理解，大部分时候人都把OPC UA理解为通信协议—这就比较尴尬。其实，OPC UA定义了语义交互的框架，但是，它并不包含内容—这个倒是可以在各个垂直领域的规范里看到—就像PackML、Automation ML、Unimat。这些行业的规范本身可以基于OPC UA框架规则来进行定义，构成一个完整的行业通信标准与规范。

制造协作的问题有哪些？

我们经常讲制造业中的IT和OT融合，或者谈协同制造，其核心在于通信。通信并非仅仅是物理意义的通讯网络连接、信号编码规则、对象字典这些内容。它的关键在于如何“架构”一个既能灵活应对变化，又能标准而易于组装的机制，让机器和机器之间，以及辅助设备间能够根据生产作业任务进行协作。

我们可以从制造产线协作中需要考虑哪些问题，来理解通信在协作中所扮演的角色，而理解了通信的这个角色，我们也就知道如何去构建这样的通信机制：

1).如何标准化的对复杂的物理对象和中间产生的变量进行建模，以构成一个可灵活搭建的生产系统；

2).如何让这些模块间形成协作关系，用什么机制来协同？

3).技术逻辑与商业逻辑的集成，如何计算OEE、能源效率、品质？

4).生产任务变化后，新的任务如何快速的解析，并经由何种机制下发给每个执行单元？

4).怎么能够对生产过程进行动态的、持续的迭代？迭代的对象是什么？

5).可实现性的问题：这些问题如何被开发者用较为简单的方式来实现？就是如何开发这样的机器和产线，降低工程成本的问题。

6).应对新问题：当新的需求产生时，如何应对？就像锂电行业需要碳足迹追踪的时候。未来更多对于产品的可重复利用的追溯跟踪如何处理？

这些问题的解决，同时要考虑行业差异性、历史发展的技术继承性，纯粹的另起炉灶是很难的。因此，必须在模块化工程思想基础上进行开发。最为关键的实现性在于采用“已有”的软件资源来干活，避免大量的开发浪费。这就像现场总线最初用于节省接线，进而降低工程成本一样，工业通信的首要逻辑也在于如何降低“工程成本”。

一个生产系统如何被协作？

针对上述问题，通信规约的构建思想可以被剖析清楚：

图1-关于工厂数据互联的几个关键要素

简要来说，如图1，工厂数据互联，就是构建资产对象在组件、功能、机器单元、产线进行基础建模。并对这些对象赋予ID编号、属性、考虑编程也要有数据类型、数据单位等信息赋予这些组件（或者也被称为资产），以及可以对其进行操作的方法。这些资产有了这些后，就会定义通信与行规-包括对象字典，数据如何被在内存地址中编号存储，包括要传输哪些信息-产品、过程数据等等。第三步，然后定义在生产动态过程中的数据交互结构，再通过状态触发来实现协作。最后，作业单将协作生产的人机料法环—精益所需的参数对象。

1).工程的模块拆分：

解决任何复杂问题，在工程上，首先要做的就是“解构”，把一个模糊的、复杂的问题拆分为简单的模块，这个思想一直是行之有效的。

因此，在PackML、SEMI、JDF、IEC61850、ISA-95这些规约里，都是这样去实现的，首先是组件对象，ID及属性。然后是功能单元，其实就是自动化里一个闭环形成的独特任务，如放卷、温度控制，再由此构成一个设备，再就是设备构成的产线逻辑。

2).协作关系在于状态逻辑

在各个规约里，定义了状态逻辑，即，各个功能单元、机器通过状态逻辑形成一个整体。状态间携带信息进行转换，在条件允许（Allowed）时进入状态，例如启动机器，然后在运行中，由预设条件、报警触发另一个状态，比如等待、停机等。

这样做的好处在于，机器的组件、对象，可以是一个被封装好的模块，然后一层层构成局部功能单元、机器的模块化局部单元。那么，这样，机器模块之间的协作就变成了简单的“状态驱动”，逻辑编排任务，实现快速而灵活的协作关系。

图2-状态模型与协作

在OPC UA新的作业任务中，如图2，可以将设备定义为基于状态逻辑的作业任务。在准备阶段需要确保相关的物料、安全自检、通信正常等，然后再所有状态OK时，触发Start，然后进入运行状态，当出现中断、异常终止等时候，触发新的状态，运行新的模块化程序。

比如电梯，是在厅门/轿门、底坑、顶层所有安全确认正常后，才会AlllowToStart、然后运行电梯曳引机系统的升降动作（Running）。当到达所指定楼层，启动变频器进行S曲线控制平层（程序模块），以达到稳定状态后，再触发新的程序-开轿门与厅门（轿门有电机与厅门机械连锁）。电梯会逐渐到达每个楼层。当多台电梯协作时，召梯信息会被汇集中央处理单元，它会根据多台电梯当前的运行状态，选择最近的电梯给予服务。电梯的运行就是一种集中式调度，分布式控制架构。

3).技术与商业逻辑的衔接

在定义组件的时候，它也是被定义为一个资产（Asset）的，根据这个设备（也是资产）它的运行状态触发的时间（计时程序，启动、停止、等待等状态间的时间数据计算机器的可用性）、以及过程中的品质数据（计数程序-计算良率），以及设备的性能与额定之间的关系（性能）等。这些数据会在运行期间产出，它可以被用于定义OEE综合使用率。这就为投资计算提供依据，评估设备的综合使用效率，反应其商业价值就是通过资产对象来实现。

4).任务变化时的机制

通过作业控制，机器和产线可以进行数据的多个维度交互，作业单定义了机器要执行的工艺参数，而这个作业单也会提交给生产管理，如原材料物流供应、测试、品质监测等多个部门。

制造现场，关键要素在于“人机料法环”，因此，交互的信息以此为内容。

图3-ISA关于作业单定义

参照ISA-95的作业订单对象状态与对象，我们可以看到，它实际上包括了材料、设备（机器）、物理资产、人员这些关键资产的连接，并在存储、启动、停止、取消、清理、暂停、中断、重启等多个状态间进行切换。

5).长期持续改善的问题

对于工厂来说，肯定要考虑产线，也要考虑数字化的长周期任务，例如基于机器学习对数据进行分析、挖掘、寻找规律，以改善生产的调度、策略。

资产管理壳AAS它也与云端数据库构建了汇集机制，它的好处在于在离线方式来实现数据的长周期训练，以获得更优的模型。对于AAS的应用域来说，可以通过MQTT、HTTP Rest请求方式进行连接—大概IT系统不大了解OPC UA，继续使用习惯的方式来交互。

6).如何应对新形势下的需求变化

拿一个比较典型的碳报告的需求来看，在去年OPC基金会在线报告里，看到他们针对设备的能源数据进行了采集。

具体这个报告是否有效，但基于已有的设备ID、数据框架，的确可以为新兴任务提供支撑。而无需额外的再去开发新的系统，充分利用既有的模型、数据资源，应对新的任务挑战。

图4-OPC UA中针对碳追踪的框架

通信是为了快速协作关系的构建

综上所述，通信的本质是为了协作，而这个协作的核心思想在于工程的“化繁为简”，采用模块化，构建一个单独的功能开发、整机的状态协作，以及数据的南向和北向的传输。总体来说，通信虽然看上去在定义一些参数，但其定义的参数、功能、状态驱动。所有这些都是为了实现机器本身的快速开发、以及产线之间的横向与管理系统间的纵向交互。

明白这个通信在其中的协作关系，我们就会知道标准与规范的意义—那么，在制定工厂数据互联时，我们就需要设定目标—我们谈数字化转型，谈数字化的落地，就要把这些问题在标准上进行定义。大家经常讨论数据的规范与标准问题—为什么要回到精益生产，比如，我们需要质量参数，那么，这个时候，就需要对质量进行定义-质量本身的评价模型是什么？这样才能推导出来，我们需要采集哪些数据？知道了质量评价的数学模型（例如SPC的定义），需要哪些用于评价设备综合利用率（OEE也需要根据实际生产定义）--因此，通信的问题，本身不是通信本身的问题，而是我们是否对生产的运营清晰定义的问题-如何协作的问题，以及希望获得什么？

如果仅仅把通信理解为通信协议，那就是看到了树，而没有看到森林。

来源：微信号 说东道西

作者：宋华振

该作品已获作者授权，未经许可，禁止任何个人及第三方转载。