1.通信在制造系统的水平集成

在一个End User的工厂，它会出现不仅是某个设备的集成，例如一个电子工厂，它可能会牵扯到注塑机、CNC、贴片、包装，各种设备，那么，他们如何被统一协作？

VDMA试图构建一个适用于各种机器的状态模型，以及基础的信息模型来进行“一统江湖”，虽然感觉有点难，但这种精神值得赞扬。最新的OPC基金会的在线会议内容里浏览了一遍，看到VDMA试图要去构造如图1场景中的连接问题，即，在一个包含了切割、涂装、包装及检测的流水线里，这些机器间如何通过状态来实现协作。它定义了不多的状态机-执行（Executing）、不执行（Not Executing）、停止服务（Out of service），不可用（NotAvaliable）四个状态。不过，我的确觉得这四个状态如果对于复杂机器来说，也许计算可用性是够了，但如果计算OEE的话，就得看其他的参数是否足够。

图1-VDMA的机器状态模型

但是，如果其伴随信息模型-就目前的信息模型来看，仅包括机器ID、监控（状态、运行模式、健康状态、消耗）、机器设备、通知、作业单信息。感觉还差点意思，想要达到如图2的计算，如OEE、DPP的计算和访问，实现数字孪生的交互信息、AI应用的数据交互，现在这个CS（所谓的伴随行规）还是不够的。

图2-计算产线相关的数据与实现应用

对于这个伟大的想法，之所以觉得难，因为现实中，似乎只有SEMI的行规用的最好，但它并未基于OPC UA来实现。SEMI的规约整体就像G代码，它给每个命令行定义了对应的操作，以及携带的参数，机器的任务就在一个简单的G代码下就可以运行。SEMI其实是有个得天独厚的优势，就是在半导体的生产链上，所有的设备操作的对象是单一的，即那个被称为“Wafer”的东西，不管你是个退火炉，还是个光刻机、沉积、刻蚀、离子注入、抛光设备，但你们的加工对象其实是一致的，你们每个设备所进行的操作如上下料、工艺过程、检测，其实这些动作对应的参数（起始位置、路径、时间、温度、压力这些参数）都是围绕这个晶圆本身的。同样，就像TSN在汽车行业容易被统一，因为汽车都是四个轮子+悬挂+发动机（电机+逆变器）--从物理对象建模的视角，这个对象也是单一的模型。

通信的行规，其实就定义了在自动化的编写任务时，以更为结构和逻辑形式去操作这些机器之间的协作。因为所有的机器都是“动作”+“参数”、按照逻辑来运行的—就相当于每个子程序调用，在新状态下调用新的子程序（携带参数），而这些行规就定义了这些动作及所带的参数格式。所以，通信行规它简化了整个自动化程序的编写。

2.垂直行业的快速信息采集-垂直行业信息模型

在不同行业，我们如何去快速地搭建运行系统，让机器之间形成协作？虽然，这种行业的信息模型非常难以被适用，就像前面提到半导体SEMI人家对象单一，你包装的PackML，也推了有30年了吧，但是，你看究竟End User那里谁用这个了？因为，你包装领域这个机器实在对象太复杂了，像液体、固体、粉体他们就包装形式不同，你就制药包装里还有片剂、丸剂、胶囊制剂、液体制剂、气雾剂，这种复杂的对象变化，让人家很难统一啊！

当然，这里想说的不是这个难，这个难主要是大家还没有到高度的“工程集成”阶段，各个行业现实中，也未能实现真正的所谓“智能制造”，因为，连线才能显示这个制造的智能啊！只有连线的生产才能需要更为“实时”的协作，而单机仅在其动作间的工艺切换—产线则是全局的协作。

问题不在这里，而在于“软件化”的问题，即，标准的软件化设计。这很关键—即，我们如何看待标准的问题，是否我们制定的标准能够被软件化形式被自动化系统快速“配置”，标准不是一个文人骚客写的文档，而是基于工程需求来设计的一个产品，一个可复用的知识和“规则”。

PackML在这方面堪称典范，它完美的制定了机器和系统如何被状态机协作，以及从最小的组件到整个产线的模块化设计。在作业管理解析下发到每个控制任务的参数中，以实现生产的变更。

PackML是个很好的通信行规设计范例，它解决了几个问题：

1).进行资产管理，计算OEE时，根据每个状态的计时来计算可用性(Avalibility)，根据良品率(Quality)统计、机器的实际运行效率（Performance），这三个指标就可以计算OEE。

2).它定义了很好的单一操作界面，机器无论如何复杂，其在多个状态间切换，实现了逻辑的任务编程与组织。这也是一个对用户友好的方式，用简单的逻辑来编排任务。

3).机器的信息模型提供了整个数据采集的效率，通过打包的数据来实现快速的工程数据采集。

从自动化工程的视角，通信的行规其实定义了一种快速的任务调度机制，即，当作业变化时，快速的用状态逻辑来配置生产成为可能。因此，通信行规，它要解决在整个变化的生产中，如何快速的进行Engineering的参数配置，而不是复杂的编程。

3.云端系统与数据源的连接-从传感器到云端的连接

越来越多的工厂，需要从底层到云端的数据，以及部署在云端或边缘侧的控制与调度优化。

图3-云倡议中的通用架构

在图3，OPC基金会的这个云应用的倡议架构中，其实，它提供了机器与产线端的数据，通过OPC UA Pub/Sub、C/S机制、OpenAPI Rest、REST Queries的方式来形成各种数据交互的支持。这个架构包括了微软、华为、亚马逊作为主要的推动者。

在图3的复杂架构中，采用了非常多的数据分发机制，来为显示、产品管理（消费者相关）、MES（云端MES）、ERP（云端ERP）、AI分析助手等，提供了各自的数据分发机制和协议。这种纯软件的领域，他们可真是不嫌烦，还定义了很多—当然他们比较熟悉，也会快速简单配置即可。

图4-WebAPI的连接方式

图4是我在OPC基金会的报告里看到的来自国内的自动化企业，D同学是老朋友，在OPC基金会的报告是关于WebAPI的方式，直接在浏览器端采用Web Client/Web Service的方式来提供对OT端数据的直接访问。这是个好办法，其实，现在的PLC有个Web Server也很正常，通过浏览器来作为访问，自适应性、易于开发的特性还是挺好的。也算是对OPC基金会发挥了中国的贡献。这很关键，支持WebAPI的OpenAtom组织也的确是由中国本地的华为、阿里、腾讯发起的。我觉得这是个很好事情，本土企业在全球的标准组织了起到这种积极的推动作用。

4.工业控制与CAE软件的协同-OPC UA的模型交互

为了构建数字孪生，需要在动态的方式连接这些软件之间的关系。最早时候，这个仿真类软件与自动化类软件的接口都是“私有”的，就像Mathworks针对不同的自动化公司，都开发个Connector的接口。后来，Modelica组织就开发了个FMU/FMI在各个CAD/CAE软件间来实现交互，包括自动化公司也支持这个，像SIEMENS、Rockwell AB、B&R、Beckhoff这些都有这个接口。这就相当于私有到专业，即，这个专业组织内部大家可以交互。不过，可能未来还是OPC UA能够跨领域，因为CAD/CAE/EDA之间还是个专业系统，OPC UA要打破这些专业之间的协作，还要跟MES/ERP、云端、AI系统进行交互，需要更为通用的接口。

这个接口对于自动化的好处其实在于“自动代码生成”，像Mathworks的自动代码生成可以为核心算法封装和下载到本地PLC，进而实现硬件在环测试，加速开发效率和降低自动化系统的开发成本。

这些接口与规范，正代表了协作范围的不断延伸，产业的不同领域必须打破那些横亘在所谓专业领域的“藩篱”，打开这些影响协作与全局优化的阻碍。这也是整个数字化要进行的工作前提，任何所谓的数字孪生、人工智能的分析与优化，都必须建立在这些藩篱打破的全开放世界。

开放将突破专业领域，也将突破层次结构，即，在横向与纵向打破壁垒。

5.管理相关信息模型DPP/碳追踪

之前看过关于DPP在绿色包装产品方面的，但现在看来，这个DPP可能更像是个针对动力电池、消费电池这个领域的一个壁垒。不过，欧盟这个DPP的参与方，感觉还得是国内的电池厂商比较多,CATL、BYD、亿纬锂能、阳光电源这些厂商，毕竟，欧洲好像也没什么特别拿得出手的电池制造商。它这个标准，还是得与全球主要的电池厂商，那90%都在亚洲尤其是在中国。除了这些问题，包括像DPP-数字产品护照、碳足迹这些贸易相关的内容，也需要从机器来采集数据（Embedded DPP），以及为了实现碳追踪，在机器的系统里对能源相关数据进行采集。

图5-数字产品护照DPP运行与数据实现

所以，OPC基金会和ZVEI、CATENA-X这些组织一起来实现这个DPP的嵌入式数据采集方案，包括在BMS里的数据点，以及在销售流通环节、处理后环节的各个数据的监测。其实，也包括了碳足迹的追踪问题—在去年的报告里，OPC UA也定义了碳足迹和碳捕捉的数据采集，这个可能会和绿色电力的贸易壁垒还是有关系的。就是要知道你制造这个产品的电力来自哪里。

6.统一工程规范MTP

对于自动化系统而言，如何在分布式的系统里，实现数据间的工程，这就像，系统里由5个不同厂商的PLC厂商来实现的各个单元控制，现在系统的任务变了，如何让每个单元都能去升级他们的系统，怎么样才能把变更，通过一个接口写入到每个控制器的逻辑或算法单元？

Automation ML试图构建这样的方案，但似乎也并未能够很好的实现，现实是Automation ML并未被大多数的公司作为一个模块嵌入在系统中。

不过，MTP则似乎正在成为一个热点，它试图去为分布式系统定义一个工程的统一接口，以便能够为这种分布在多个地点的，由不同的组件构成的整体系统的升级带来工程效率的提升。

因此，对于自动化系统来说，工程集成—通过这种统一的规范就可以很快的实现自动化任务的集成。

图6-氢电解槽的构成

图7-MTP在氢能系统里的架构

图6是去年还研究了一下Power to X（消纳清洁能源，转为绿氢，再转为X-甲烷、绿氨、汽油、甲醇等，统称为Power to X，即，电转各种能源X）其中核心的电解槽结构，以及通过MTP为这个制氢系统搭建的工程服务架构。

不过，最近听说欧美的很多大型的氢能项目都停止了。这个其实清华大学一位专家在大约8年前就做过分析，电价如果均量化度电成本（LCOE）不能低于0.25人民币，制氢这个路就不具有经济性。因为只有中国的光伏和风能的电价可能才能干到这个数左右。另外，从清洁能源消纳角度，可能中国才有Power to X这个必要性。

当然，这部分就算闲扯了—本来我这个文章想说的其实是，通信规约对于自动化工程的角色，以及其核心作用。

越来越复杂的集成，以及IIoT和AI应用，这些使得工程集成变得复杂，那么快速的搭建这种信息模型、数据交互接口规范与标准，还是很有必要的，OPC UA提供了一个好的方向，不过，戴老师总是说OPC UA太重了，的确是—他们也雄心勃勃要干出一统江湖的通信。什么都往里面加，今年的OPC基金会的报告浏览一遍，包括信息安全、针对垂直行业的（激光系统、铁路系统、航空系统）、能源问题的，机器的统一通信行规，还把各种通信都要纳入，TSN/WiFi/5G，啥都想干。

私下里和戴老师等也讨论过这个问题，为什么像IEEE/IEC这些组织能够把这么多来自不同领域，很多竞争的企业抓到一起来为未来的发展制定标准，这个也是个挺厉害的事，这种组织运行机制也挺有意思。

来源：微信号 说东道西