风华正起 开放自动化

作 者

彭 瑜：上海工业自动化仪表研究院，PLCopen中国组织

编 审

林雪萍：北京联讯动力咨询公司总经理，天津大学精仪学院兼职教授

自OPAF打响开放自动化的第一枪至今，已经七八年了。对于工业自动化这一颠覆性的创新，有积极推动者和实践者，也有一些持不同意见者，更多的是不少观望者。下面从通用自动化和无边界自动化、对于终端用户的潜在利益，以及尚存争议的三个问题阐述近几年来值得关注的开放自动化的发展动态。

从通用自动化到无边界自动化

日前，艾默生的首席技术官Peter Zornio认为：“与专用硬件捆绑在一起的过程控制软件最终将会消失——对每个公司都如此。在高可用性管理程序上执行控制回路容器，将能够提供我们今天从特定硬件控制器获得的性能和延迟。硬件和软件的解耦是无边界自动化（Boundless Automation）愿景的一个关键方面。” 这意味着，经过七年之后，艾默生终于完全接受了开放流程自动化论坛OPAF开宗明义的声明和要义。艾默生在2016年加入OPAF之后，却在2017年因不满OPAF强调系统集成商的作用、而忽略自动化主承包商的作用，愤而退出。而如今，终于重新刷新对开放自动化的认知。这一转变，会使关心未来自动化发展方向的人们进一步感觉到，开放自动化的道路坦坦荡荡。而这自然会吸引越来越多的最终用户和工业自动化企业的青睐和投入。

2022年10月艾默生发表了一个重大声明，提出了“无边界自动化”。无边界自动化本质上是艾默生对未来自动化技术架构的愿景。当今工厂中自动化部署方式有着巨大的局限性，专用的硬件、传感、控制和信息的多层次，都不可避免地造成数据孤岛。它限制了数据的自由和安全移动，并将IT与OT分离。而新的自动化架构，将是由软件所定义。不仅仅是以数据为中心的，并且在设计上具有固有的安全性。软件应用将在三个计算范畴中执行，即智能现场设备，边缘计算/控制环境以及云端。通过一个有凝聚力的软件平台统一这些范畴，将使数据民主化，使其更容易存取和转移到增值应用和分析工具中。“（见图1）。这是继施耐德电气在2020年倡议通用自动化（Universal Automation）之后，又一个在国际自动化界具有影响力的企业的重要表态。

图1 艾默生的无边界自动化（图源：ARC网站）

2020年10月施耐德电气推出了一款以软件为中心的全新自动化系统——EcoStruxure™ 开放自动化平台（EcoStruxure™ Automation Expert，EAE），并提出了“通用自动化”的愿景。EAE是一个IEC 61499集成开发环境（IDE），用于设计、部署和管理工业控制系统，其开放的即插即用的自动化软件组件的方式，正是有的放矢地去应对未来工业自动化的特殊挑战。到今年已经迭代到V23.0版，并已扩展为集离散、混合和流程工业运营操作于一体的统一控制软件平台。施耐德电气正在联合生态合作伙伴共同呼吁工业用户、OEM厂商、系统集成商和总包商（EPC）等所有企业和个人携手拥抱开放自动化。

从历史上看，控制系统的综合开发环境IDE是导致所有工业自动化软件远远落后于IT同行的关键软肋。它的根源就在于传统自动化系统软硬件捆绑的专有性和封闭性。然而，现今工业的发展需要更大的制造灵活性和更高的生产力，要求控制系统软件开发及其开发的环境IDE必须变得更像IT软件开发那样。与此同时，在智能制造、工业互联网和工业4.0时代，把软件作为一种资源进行更好的管理成为一项关键需求。一个与硬件系统捆绑的软件，无论是升级还是复用都是相当困难的。这种类型的软件，原则上只是隶属于这个硬件系统，也因此不能视作为可长期使用的资产。

只有可以反复使用，长期使用、与硬件脱耦解耦的软件才能够被视作为资产。从这个意义上看，开发并迅速推广应用符合此要求的工业控制系统的综合集成开发环境IDE，是工业自动化领域的重大的革命性变革。对开放自动化理念的认同，却又衍生出多种不一样的叫法，以及不同的发展路径和策略，只不过是由不同机构的多元化的构想，或者是商业利益的追求，以及适用的细分行业的差异等因素所造成。不论是OPAF的开放流程自动化，或者德国NAMUR的NOA和MTP，施耐德电气的通用自动化、艾默生的无边界自动化，都是为了满足工业发展和数字化转型的需要。为了让OT产生的数据能够自由地按需流动，让IT的管理、分析和决策得以在全局体系下都能有效实施。这样，现有的工业自动化系统的各种弊端（诸如、孤岛式的系统架构、数据的孤岛、信息安全的纵深防御、以硬件为中心的认知、建立在设备管理的基础上、单一现场的操作运行、大部分为资本性支出CAPEX等），才能消除。未来工业自动化系统将脱颖而出，而它具有令人心动的优异特性包括：无边界的自动化、统一的数据模型、系统固有的信息安全设计、软件定义和以数据为中心、建立在生产现场管理的基础上、云赋能的企业运行操作、大部分为运行性支出OPEX等。

开放自动化对于终端用户的潜在利益

硅谷软件公司Cplane.ai的联合创始人，本来是一名核潜艇军官，从事核反应堆（包括蒸汽推进和发配电系统）工作。他在美国海军服役后，还参与电信和云行业的基础设施软件工作。现在投身于开放流程自动化正是这两种经验的融合。2020年应一家大型DCS供应商邀请，他们演示了如何在新一代工业控制系统中使用Cplane.ai的编排软件，开始了他们将经验、学习和能力带入OPAF论坛的机会。他在接受媒体访谈时指出，开放自动化为工业用户提供了三个优势，即（1）提高了工业控制系统计算能力（2）增强了信息安全（3）使最终用户的工业控制系统总拥有成本更低、灵活性更强。这是工业自动化市场上的一个阶跃函数的颠覆，改变了此前在DCS领域供应商相互竞争，但没有一个能够完全颠覆市场的局面。

以下就这三个方面作进一步的展开：

（1）提高ICS的算力。据Cplane.ai估计，基于开放流程自动化标准O-PAS的工业控制系统将比现有DCS的计算能力提高至少500倍。而使用线性预测编码（LPC）的通用数据格式，则起着相当重要的作用。这种强大的算力将使ICS能够运行功能更强的应用程序软件（如预测控制模型，优化控制回路的操作）；适合运行人工智能和机器学习应用程序；无需通过数据网关或其它中介方式，也无需改变数据格式，便可以将ICS内部的实时数据在系统外部共享；能在ICS内运行更复杂的应用程序，对盈利能力和运营产生重大影响。这就是说，在开放体系结构中ICS可以就地托管更高级的数据分析，并让这些应用程序直接向控制逻辑提供反馈或更细致的分析洞察结果。开放架构还允许就地连接，而不是将一些数据和信息拼凑在一起，送到云端、物联网平台，或企业ERP；这种原生连接比现有的DCS更容易、更安全。

事实上，传统的DCS系统已经拥有DCS系统技术栈的每一部分，包括通过I/O连接现场的变送器、传感器以及各种执行器，执行控制逻辑的控制站，运行局部优化、分析的各类应用程序的计算服务平台。这类DCS的体系结构其设计决策早在1985年或1995年，甚至2000年，都是符合当时的控制水平和要求，都是有意义的。问题在于，这是一个完整的系统，在不改变整个技术栈的情况下想改变其中的某一部分是相当困难和昂贵的。1965年出现的摩尔定律预测每个硅芯片上的晶体管数量每年翻一番，这是建立在一个开放的系统的基础上的。这就是IT行业在能力上飞速发展的原因。然而控制系统行业则陷入封闭的状态。它一旦陷入一个专有的技术栈的陷阱，就很难升级。即使升级只不过还是在原有的总体设计架构下做有限的改进，而不是为系统创建可用的新功能。这种非颠覆性的创新在数字化转型的大趋势下也许难以持久。

（2）信息安全的增强。从风险的角度来看，确保工业控制系统具有固有的信息安全框架可能是采用基于开放的控制系统最紧迫的动机。开放流程自动化标准O-PAS的第2部分《信息安全》为整个ICS的体系结构集成了信息安全的原则和框架。O-PAS技术体系结构的一个原则是维系流程自动化系统的物理安全和功能安全、自动恢复的弹性（resilience）、可靠性、可维护性和信息安全诸方面的平衡。由于在符合O-PAS的环境中可能有成千上万个节点和应用程序，因此应该在没有大量人工干预的情况下通过组件之间的安全通信来实现信息安全，并确保只执行有效和授权的命令。工业控制系统仅仅依赖防火墙等物理隔离技术是远远不够的，依赖纵深防御的信息安全措施也是被动的。符合O-PAS标准的系统其安全合规自动进行，并且借助于日志记录确保验证简易可信。在整个ICS中可以为相关的软件自动打补丁和进行安全更新，而不会中断工厂的操作，这在传统系统中是不成立的。当检测到威胁或破坏时，系统可以立即采取启动高级系统管理功能集，不需要任何操作人员的操作就可以将控制功能从受病毒感染的控制设备转移到附近的安全设备上，而不会中断工厂操作，也无需任何操作人员的干预。这些功能是O-PAS标准赋予ICS所固有的。

（3）更低的拥有成本和灵活性。灵活性和总拥有成本是最终用户推动开放流程自动化创新的基本出发点。总结几十年DCS应用的经验和教训，终端用户已经厌倦这种以软硬件绑定为特征的供应商锁定。这种模式使他们受困于DCS供应商的创新周期，没有自己的主动权和创新节奏，不但造成系统维护和系统升级的高昂成本，而且妨碍了提高运营效率的灵活性和改变其业务的能力。

相比之下，开放式控制系统允许用户有足够的灵活性，以较小的增量和随时间变化来满足业务的需求，并进行持续改进，而成本和工作量只是传统DCS的一小部分。开放的体系结构和开放的标准使整个系统在设计上具有灵活性，硬件和软件组件预先设计为可互操作，借助于自动化软件组件的开发、部署、维护和重用的性能，使ICS在整个生命周期内获得巨大的生产潜力，从而为工厂在其整个生命周期中赢得更容易更新或增强控制的能力。比较传统的DCS与开放流程自动化论坛OPAF追求的资本性支出模型（如图2的右侧所示），可以看出后者在以下多个方面都是具有吸引力的：

· 降低初始投资；

· 保持持续的灵活性；

· 通过经常进行增量型的改善可大幅消除系统升级的投资；

· 可持续提高效率；

· 不存在非计划停车。

图2 DCS系统与开放流程自动化二者的资本性支出模型比较（图源：施耐德电气网站）

从经济角度来看，建立在标准化基础上的开放自动化系统其价值相当可观。据美国ARC咨询公司研究估计，全球DCS供应商的服务市场每年为70亿至80亿美元，最终用户每年为在役的DCS系统要花费约200亿至300亿美元服务费用。通过标准化的自动化软硬件组件可以避免大部分的支出。除了节省成本之外，标准化还将使高技能的过程工程师和技术人员能够更多地关注产品改进，而不仅仅是重写原有的代码。

总之，将软件视为可重用和长期使用的资产是工业自动化领域的重大变革，也是其提高灵活性和降低总拥有成本的强力手段。

开放自动化作为工业自动化的新生事物还在发展探索中，不可避免还存在一些有待澄清、有待通过争论和实践进一步明确的许多问题。以下是笔者多年观察多方收集发现的三个问题：（1）IEC 61499在开放自动化发展中的作用。（2）OPAF倡导的由最终用户/系统集成商的替代控制系统主承包商的模式的可行性。（3）流程工业中OPAF和NAMUR的NOA和MTP的协调统一的可能性。

第一个问题：61499行不行？

鉴于IEC 6113-3依赖于单个控制器的模型，而不是分布式系统，才有了开发IEC 61499的推动。IEC 61499重点强化的就是让控制系统能够作为一个单一的集成系统建模和开发，而又可以作为一个分布式系统进行部署。IEC 61499还具有如下的重要功能：提供强大的组态功能块模型；融合过程自动化和工厂自动化的习惯用法，并可能最终融合工业自动化和嵌入式系统的领域；既可以支持事件触发的执行模型，也可以支持循环执行的模型；可以通过任意数量的软件工具对应用程序进行广泛的预处理和测试，这是一个正在开发研究的方向，在不久的将来，终端用户可以期望更强大的功能来验证和测试他们的自动化应用程序；此外，它是一个开源和商业产品可以协同工作的领域。

ARC咨询集团这样认为，硬件和软件的相互依赖，以及由此产生的专有技术和软件工具，导致了制造业最终用户在工业自动化领域苦苦挣扎的弊病。最明显的是，无法将现有软件应用程序从一个供应商系统移植到另一个供应商系统。存在的困难还有：在要求系统规模扩大，以及在现有自动化系统上采用新技术时，由于缺乏灵活性，用户往往无能为力，只能依靠供应商，而且成本奇高；此外，现有的专有软件工具需要太多的专业技能——这些技能既难以获得，又不能从一个供应商转移到另一个供应商。所有这些问题都是工业自动化行业特有的问题，并且考虑到自动化系统的要求，被视为是不可避免的。但是今天，硬件和软件方面的新IT技术可以在很大程度上满足OT需求。今天的标准化系统可以结合时间敏感网络(TSN)、开源操作系统和云技术等新技术，创建工厂车间的赛博物理系统CPS，将实时确定性行为和几乎任何程度的高可用性结合起来。显然，自动化应用将继续沿用现有的控制系统建模的范例来定义。不同的是未来的控制系统将是分布式的，而不是集中在大型PLC或DCS控制器中。这就需要一种建模技术来统一自动化系统的控制系统应用开发；该模型基于IEC 61499标准居于首选地位，这是因为IEC 61499：

· 可以跨OT和IT设备的异构架构对分布式自动化应用建模，从而对OT/IT融合系统进行一体化设计（参见图3）；

· 与标准的应用程序组态文件相结合时，可确保应用程序具有可移植性；

· 其图形功能块的表达方式既能被自动化工程师所理解，其事件驱动的软件组件又能被IT软件工程师理解；

· 可以让实时的应用程序和事件驱动的应用程序混合使用；

· 便于控制系统软件进行一键部署；

· 便于控制系统的软件进行动态升级和迁移。

因此，ARC咨询集团将IEC 61499视为定义和管理控制系统组态的关键软件技术。

图3 开放自动化将IT和OT的视角融合在同一赛博物理系统中

当前IEC 61499的工业应用主要是由施耐德电气通过EcoStruxure™ Automation Expert平台软件以及Universal Automation.org这个组织在推动。开放流程自动化论坛OPAF在其创建的O-PAS系列标准中选择IEC 61499作为定义和管理控制系统组态的基础标准，而且在2020年由埃克森美孚和Cplane.ai公司合作的实验项目中获得了进一步的验证。由Cplane.ai公司提供的工业编排软件工具运用施耐德电气提供的EAE软件的控制系统组态，成功将应用程序及其组态文件部署到来自不同供应商的10个控制器中，而这10个分布式控制节点DCN构成两个在地理上分布于相隔数千公里的不同的执行平台上。整个组态过程在不到10分钟完成部署，随后整个系统成功启动。应该说这是IEC 61499在开放自动化发展中的一个里程碑。同时也启示我们，尽管IEC 61499标准并不是100%全面的，但它是当今最合适的。正如开放过程自动化论坛所解释的那样：“IEC 61499标准在设计上是抽象的，允许不同的工业部门插入特定于行业的偏好，例如通信协议和数据模型。这种设计试图适应广泛的工业用例，而不是强制采用一刀切的方法。虽然该标准没有规定应该用什么来填补标准中缺失的空白，但它规定了如何以合规性概要的形式填补这些空白。”

当然，不论在国际上还是在国内对此还是有争议的。对IEC 61499持怀疑态度的一个论据是这些年来工业自动化领域并没有围绕IEC 61499一轰而起，这确实是严峻的事实。

这种怀疑或许一部分来自对IEC 61499本质的认识不足，对工业自动化领域内技术发展的规律没有充分了解，一部分来自对IEC 61499开源软件的正确利用的误解。想当年IEC 61131-3在1993年正式发布，到二十一世纪初叶才在工业自动化领域初见端倪，又经过包括PLCopen国际组织在内的有志之士十多年的辛勤耕耘，才见到如今被普遍认可的境地。IEC 61499自2005年颁布，冷板凳也坐了十几年，分布在全世界为数不多的的几个团队为它的工业应用持续努力着，到了前几年才开始出现像施耐德电气这样的跨国公司和像OPAF这样的有影响的技术组织以平台的形式支持这项技术，也有越来越多的工业实例在多个细分行业成功实践，看好这项技术的人士不断增多。不求遍地开花，只求踏实细致，解决实际问题，一旦有杀手级的应用场景成功问世，可能会在工业自动化领域中产生“当惊世界殊”的效果。

另外，在基于IEC 61499的分布式控制系统开源开发平台中，由Eclipse 基金会支持的4diac比较完备，也是被关注和引用较多的。它由三个部分组成，即4diac的IDE集成开发环境，基于Eclipse开放源码框架；4diac FORTE运行环境，适用于小型嵌入式控制设备（16/32位）IEC 61499运行时环境，用c++实现；4diac功能块库（4diac LIB）包含4diac FORTE上可用的功能块。4diac FORTE支持在线重新组态其应用程序，并能够实时执行IEC 61499标准提供的所有功能块类型；支持所有IEC 61131-3 Version.2的基本数据类型、结构和数组；它提供了一个可扩展的体系结构，允许4diac FORTE适应应用程序的需求。应用程序可以由任何IEC 61499元素组成，如基本功能块（BFB）、复合功能块（CFB）、服务接口功能块（SIFB）、适配器和子应用程序。即使如此，这个开源的软件是个供参考的入门级软件，如果要用于工业实际还需要大量的开发和实践。有些开发者不明白这种状况，想拿来就用，用不好就认为是IEC 61499标准的问题。这种想法，只能被认为是浅尝即止，离开深入其中还差得远呢。

与IT开源项目相比，OT的开源项目相当小众，如果没有持续的支持和一贯热心的开发团队，OT开源项目的更新和活跃程度就差得多。据IEC TC65B/WG 15（即IEC 61499）的召集人（也是Eclipse Foundation 4diac的项目负责人）奥地利林茨Johannes Kepler大学的教授Alois Zoitl博士说：在CPLANE.ai和合作者ExxonMobil的概念验证试点项目中，Schneider Electric EAE中的nxtControl和开源的4diac，理论上可以运行彼此的应用程序，但在nxtControl和Eclipse 4diac之间有一些可移植性的讨论。据他所知，它们大多导致了4diac IDE中XML解析程序（parser）的错误实现。不幸的是，这些问题并没有很好地传达给Eclipse 4diac团队。Zoitl博士认为这些问题是可以解决的，不过透过这一问题可以看出IEC 61499要获得工业自动化行业的广泛支持，尚有待于解决两个主要关节，一是目前存在的IEC 61499供应商数量非常有限，用户的实际数量也没有达到规模的临界数量点，二是需要建立一个强大的IEC 61499认证和符合性检验机构。

第二个问题：集成商，还是主承包商

（1）OPAF倡导的由最终用户/系统集成商替代控制系统主承包商的模式的可行性问题。

为了实现把不同供应商的软件和硬件组件无缝集成，OPAF尽了很大的努力，不但制定了相应的标准、严格认证的程序，还做了互操作性、互换性、应用程序和组态文件的可移植性的实验及测试。在其技术架构中规定了应用程序和服务类型的分级模型FILO Model（见图4）。在O-PAS标准中，应用程序是由程序、相关组态和数据组成的不可分割的单个组件，它执行一组相关的协调功能。

图4 应用程序类型的分层定义的FILO模型（图源：The Open Group网站）

Layer-F层应用程序是通过O-PAS标准定义的O-PAS可移植组态规范定义的应用程序。这些包括功能块、报警应用块、IEC 61131-3程序和IEC 61499-1应用。这还包括O-PAS标准中定义的基本组态信息。Layer-F应用程序/组态还包括遵循相同可移植组态结构的Layer-F库，例如Layer-F应用程序可用的功能块库。Layer-I应用程序是用典型的IT编程语言（如c#、c++、Python、GO、ADA等）定义的应用程序。Layer-I应用通程序通常对Layer-F应用程序和组态信息进行操作。Layer-I应用程序通常是平台相关的，因为它们已被编译为针对特定CPU体系结构和O/S的二进制格式。Layer-L应用程序是用典型的IT语言（如c#、c++、Python、GO、ADA等）定义的程序库或服务程序，它们为Layer-I层的应用程序提供服务。Layer-L层应用程序通常是平台相关的，因为它们已被编译为针对特定CPU体系结构和O/S的二进制格式。Layer-O层应用程序通常是底层的O/S，它为Layer- L层和Layer-I层的应用程序提供操作环境。在O-PAS技术体系结构中，这被标识为平台O/S，或者运行在管理程序内核之上的O/S。

尽管如此，还存在一些不同的主张和意见。譬如艾默生的首席技术官Peter Zornio认为：“控制系统软件将不再像今天一样与特定的硬件捆绑在一起，这是共同点。我们根本不同意的是，尽管OPAF标准可能提供最低程度的遵从性（a minimum level of complianc），但它们不够丰富，无法提供人们想要的自动化软件应用程序之间的统一和集成级别。比如说，有100个不同的供应商提供100种不同的软件系统，集成商把它们任意组合在一起，使它们就像由一个供应商设计和编写的DCS中的软件一样相互工作和发挥作用? OPA是一个伟大的愿景，人人都喜欢这种愿景。谁不想从一个供应商那里购买这个软件，让它与另一个供应商的另一个软件无缝地、透明地工作呢? 但在现实中，要做到这一点需要付出巨大的努力。每当这些软件中的任何一个进行了安全升级并停止与其他软件一起工作时，或者新版本发布并停止与其他软件一起工作时，那么谁将对此负责?因此，艾默生相信拥有一个自动化供应商基础设施的软件生态系统，而不是一个试图将来自多个不同供应商的软件捆绑在一起的系统集成商。在艾默生无限自动化的愿景中，统一的软件套件将来自我们和合作伙伴，而不是来自任何第三方。我们将掌握自己的命运。当然，我们仍然会支持所有的开放标准，并允许其他第三方以越来越丰富的方式进行集成; 但是，艾默生支持从真正统一的软件中获得易用性，以及支持需要有相关的机构承担全面的责任。”

由最终用户/系统集成商替代控制系统主承包商的模式的可行性尚待时间和实践来证明。但在未来的开放自动化方向上，硬件的标准化和彻底的商品化在认识上已经基本统一，有争议的是自动化供应商基础设施的软件生态系统是由谁来主导：单一的主承包商的局部开放软件生态系统，还是全面开放的系统集成商。

第三个问题：两个流派的协调性

开放自动化存在着流程工业中OPAF和NAMUR的NOA和MTP的协调统一的可能性问题。

2020年国际自动控制联盟（IFAC）的大会上，埃克逊美孚和洛马的研究人员发表了名为《开放流程自动化：一种基于标准的开放、信息安全、可互操作的流程控制架构》的论文，除了阐述基于O-PAS标准构建的实验室原型系统和碳氢流程控制原型系统，证实开放流程自动化架构的可行性，还提出， OPA与NAMUR的开放自动化NOA和MTP这三个开放自动化系统的功能和概念是互补的，而不是矛盾的，有可能采用DCN或O-PAS连接接口（OCI）充当非O-PAS标准产品的“网关”，将NOA和MTP的系统组件接入，构建协调的统一架构（见图5）。

图5 构建OPA、NOA和MTP协调的统一架构

之后，美国CSI公司（Collaborative Systems Integration of Austin,Texas）进一步提出，在OPA的总体框架中NOA的局部M&O（运维和优化）软件可以在先进计算平台ACP（即预装的OT数据中心）内安装，也可以通过分布式控制节点DCN将非OPA标准的外部OT数据中心经由开放通信接口OCI与系统连接；还可以通过DCN将其内装有全局M&O软件的非OPA标准的外部IT数据中心经由OCI与系统连接。此外，通过DCN把内装MTP软件系统的PLC/DCS接入，是OPA系统纳入MTP的可行方式。这样就可以完成统一的协调的OPA/NOA/MTP架构（见图6）。

图6 美国CSI公司的开放流程自动化统一架构

O-PAS和MTP这两个标准都旨在为未来的自动化系统提供所需的开放性。不过，这两个标准起源于不同的细分领域。O-PAS起源于石油和天然气工业，其特点是连续的流程生产，一般而言流程相对稳定很少变化。因此，O-PAS的目标是构造一个标准化的、开放的流程控制体系结构，例如优化这些流程中的输入和产出，并在不改变流程的情况下便于置换控制器的硬件（即实现硬件和应用软件的互换性）。相比之下，VDI/VDE/NAMUR 2658模块类型包MTP植根于特殊化学品和制药等行业，这些行业的发展趋势是市场波动和产品定制化程度高。因此该标准的目的是在模块化的基础上快速而简便地构建流程工厂。尽管这两个标准的出发点不同，但都是为开放自动化系统提供了解决方案。

不过O-PAS和MTP概念的分歧可能会导致两个风险：首先，哪个标准最适合哪些应用可能存在不确定性；其次，如果流程工厂之间依据的标准不同，则无法保证工厂间的互操作性标准。因此，作为这些标准的领导机构The Open Group、NAMUR和ZVEI，已经在2020年决定O-PAS和MTP 方法应该保持协调一致，并成为一个整体概念。通过引入一个结合了OPAS、MTP和NAMUR开放架构（NOA）概念的演示系统，O-PAS和MTP的协调迈出了第一步。然而，尽管这种协调是在相当高的水平上进行，但所展示的演示程序使用O-PAS和MTP的方法是以各行其是的形式存在的，实际上并没有协调一致。因此，这种结盟可能产生的协同效果很难得到充分利用。

选择模块化、互操作性、工厂流程协调和组态等进行比较可知，要将O-PAS和MTP的概念特征进行协调和调整相当不容易，要落地更难。作为比较这两个标准的基础可以认为，定义自动化软件所包含的最小组成单元是模块化比较和处理的内容；互操作考核检查已定义组成单元之间的接口和交互机制是否合乎规范；工厂流程协调着重对由组成单元构成的工厂的运行时体系结构进行比较处理；组态则是在前面三项的基础上处理工厂的工程问题。

这里仅以模块化为例略加讨论。O-PAS和MTP这两个标准的概念都基于流程工业功能性的模块化，包括将流程工厂的硬件和自动化软件分解成多个在很大程度上相互独立、但又需要相互协同配合执行的单元。在讨论自动化软件的模块化时，如果把构建自动化软件的最小单元称为软件组件，那么在这种情况下，软件组件被理解为一个可完全实现的、不可分割的软件单元，它封装了流程工厂各类功能性的某一部分。此外，软件组件总是在单个控制器上执行。当然，也可以根据需要将多个软件组件配置到不同的控制器。在O-PAS中，这些控制器被称为分布式控制节点（DCN)。在VDI/VDE/ NAMUR 2658的环境中，控制器本身和运行在其内的自动化软件，以及执行流程功能所需的所有硬件以及流程设备都被视为一个单独的模块。这些模块被称为流程设备组件（PEA）或功能设备组件（FEA）。基于前面提到的软件组件定义，可以从两个标准的角度对之进行识别。显然在O-PAS的情况下，功能块可以被视为软件组件；而在VDI/VDE/NAMUR 2658 MTP规范中，服务被视为软件组件。在其内运行的自动化软件和执行流程功能所需的所有硬件都被视为一个单独的模块。

显然，O-PAS比VDI/VDE/NAMUR 2658对流程自动化的功能进行了更细粒度的划分。在O-PAS标准中（O-PAS Part 6.4 – Information and Exchange Models: Function Blocks），流程工业的自动化功能由四类功能块组合（数据输入、数据输出、PID和控制相关计算）组成，再加上用于开放连接性框架OCF的这一类功能块，一共有5类。这些功能块可以看作是软件组件，因此可以根据需要分布到不同的DCN中。在MTP实现中，只有控制回路被视为一个软件组件。之所以两个标准的软件组件粒度有如此的差异，可以用其不同的目标来分析。O-PAS旨在对高度分布式的流程工厂架构予以标准化，从而促进流程工厂设计和实施的高度灵活性。然而，VDI/VDE/NAMUR 2658侧重于工厂/成套设备的快速和简单的构建和重建，因此采用由相当粗粒度的元素是合理的选择。

小记

开放自动化发展的技术路线仍然存在着分歧，背后是自动化巨头之间、自动化公司与用户之间的大博弈。然而它的趋势正在决定性地确立。人们只是需要时间，就会清楚技术流派最终会如何演化。在开放自动化风华正起的时候，中国自动化界应该有所作为，积极参与到建设新一代自动化的潮流中来。我们高兴地发现，现今勇立潮头的也有我国的自动化团队，在他们的支持下，在刚刚闭幕的上海工博会上已经有了奋起直追的中国公司。