在我国，标准分为13类：基础标准、术语标准、符号标准、分类标准、试验标准、规范标准、规程标准、指南标准、产品标准、过程标准、服务标准、接口标准，和数据标准。比如接口标准就是规定产品或系统在其互连部位与兼容性有关的要求的标准。
不过这些年来在工业发达国家，尤其在美国，开展着一类非常活跃的标准活动，似乎不能归类于上述的任意一类标准。这就是在多种适用的工业标准的基础上，建立为特定细分行业服务的综合性应用标准，有时在文献中还被称为"标准的标准"（Standardofstandards）。这类标准往往不是由某个正式或官方的标准化组织所发起和操作的，而是由最终用户根据他们的需要、思考和判断来发起，并为此建立或委托一个非官方组织去开展相关的标准化活动。这类目标极为明确的标准化活动吸引了一批志同道合的伙伴（包括最终用户、自动化供应商、自动化咨询机构和一些标准化组织等），共同开展跨组织的、资源投入巨大的努力，有效推动了行业技术进步，并将继续显示出前所未有的经济潜力和组织活力。
下面我们分析两个案例：开放流程自动化标准OPAS和被誉为机械装备集成的样板的PackML。
开放流程自动化标准OPAS
OPAF论坛正在为下一代流程自动化系统的体系架构制定系列标准。所谓下一代流程自动化系统区别于现有的DCS的主要特征是：开放、可互操作、具有内生的信息安全。因此这些标准将使得独立供应商提供的基本功能部件能够按照模块化架构的方式以及开放的接口标准方便地集成到流程工业适用的各类大、中、小系统之中。
1.开放流程自动化的目标和技术架构
1.1开放流程自动化的目标
处于ISA95模型L1和L2层的自动化硬件和软件结构许多年没有变动，自动化市场也一直围绕着硬件和软件捆绑的模式在演进。每一个自动化供应商都有自己的软件开发和应用环境，并将这种软件环境交付给最终用户，而用户只能通过供应商提供的组态工具与控制器交互。由此可以断定，现今流程工业自动化控制系统DCS和PLC最大的问题在于其封闭和专用的特性。在IT技术飞跃发展的年代，这极大地阻碍了DCS和PLC的升级迁移，以及OT与IT深入高效的融合。此外，目前的DCS和PLC所有有关信息安全的措施都不是原生的，而是后加的，有如打补丁，因而一般不能提供内在的保护运营、资产设备和其它投资所需要的信息安全特性。
许多在役的控制系统其构成的硬件和软件由于专用、封闭，维护和升级的成本昂贵，一旦需要与一流的第三方部件集成，耗资不菲。尤其在目前IT技术快速深入地滲透和融合到企业运营管理方方面面的趋势下，这些控制系统通常不具备本征的信息安全特质，造成了巨大的风险和隐患。还有一个问题是，从长远发展来看，现有的控制器不能有效而恰当地保护设备资产和其它资本投资，以及多年来积累的过程数据和操作知识。
鉴于上述存在的问题，2016年埃克森美孚的研究和工程部门公开倡议开发一个全新的、基于标准的流程控制架构，得到ARC咨询集团大力支持，并由非盈利的第三方机构--美国开放集团（TheOpenGroup）组织了一个新的面向流程工业控制技术的标准化活动，即开放流程自动化论坛（OPAF）。论坛聚焦于如何运用最新的分布式云计算技术和虚拟化技术，重新定义已经日趋陈旧、20多年没有变动的架构，重新定义DCS和PLC，以及与优化运营密切相关的先进控制和MES，但不涉及专门针对流程工业安全保护的安全仪表系统SIS（见图1）。
图1开放流程自动化论坛OPAF定义的范围
值得高兴的是，循着这一方向的进展相当迅速。继2019年初发布OPASV1.0后，经过不到一年的时间已经在2020年1月定版正式发布；在今年2月发布了OPASV2.0，包括OPAS标准的Part6.1，6.2，6.4和Part7，已经可从OPAF的网站下载评估版；而OPASV2.1预计会在今年年中推出。与此同时，建立测试床和进行工业中试的计划，也在顺利推进并付诸建设落实。2019年5月的OPAF可互操作性工作会议，敦促成员把他们支持OPASV1.0的硬件和软件拿到已经建立的测试床来试验，以验证标准初始版本的正确性和清晰性，从而将初始版升级为正式版。
原型/中试装置包括4个反应器训练装置，由泵、反应器、分离器、分析装置等组成，系统有25个典型的流程控制回路，130个I/O单元，总计500点。碳氢流程包括原油和加氢以及H2S，主要是评估催化性能。在2020年1月完成现场接收测试。原型/中试装置用开放流程自动化OPA系统执行了常规的单元操作，诸如启动、停车、控制单元的操作运行参数，以及满足操作人员的期望等。原型/中试装置的数据由OSIsoft的PI历史数据软件和InductiveAutomation'的HMI/SCADA采集，其架构的硬件和软件来自Dell,nxtControls,PhoenixContact,Intel,Yokogawa,Moxa,Lantronix和Matrikon。其DCN有PhoenixContact的控制器、基于虚拟机的软控制器、由Intel提供的可由客户定义的DCN（具有4个通道），一个可切换的盒式微处理器组合（用来切换计算功能性）。通信采用OPCUA构成实时总线，在一台DellVxRailACP服务器中划分为6个信息段区处理软控制器和其它功能。图2是原型/中试装置的开放流程自动化系统。
图2为开放流程自动化系统的测试建立的原型/中试装置系统
1.2OPA的技术架构
OPAS标准支持通信的相互作用，通过列出硬件和软件部件的特定接口使自动化系统成为一个面向服务的架构SOA，而这些部件将被用来为最终用户设计、构建和启用自动化系统。
OPAS标准的版本并不限定一个架构中所用接口的数量，也就是说每一个自动化系统都可为满足其特定的要求构成最合适的设计。标准只给出参考系统架构（见图3），而不专门定义详细的系统架构，通过给出用例来描述如何使用部件级的接口。
图3开放型流程自动化OPA的参考系统架构
在参考系统架构中包含下列基本要素：
1.分布式控制节点（DCN）
DCN可以是一个基于微处理器的控制器、I/O、或可处理输入输出和具有计算功能的网关设备。O-PAS标准的一个关键特性是硬件与控制软件是解耦的，所以任意一个DCN的准确功能取决于系统的构造者。一个DCN包括硬件和某个系统软件，也允许在其中运行控制软件，同时DCN具有能够与O-PAS网络（称为OCF）连接的接口。
在OPAS标准中DCN表示一种基本的计算模块，它可以是硬件实现或者是虚拟实现。DCN可大可小，可以没有I/O或者有各种各样的I/O。目前每个DCN容许的I/O密度并没有规定，因此这方面的标准化可能要由市场来推动最终的配置。DCN也可以作为与其它网络或系统连接的网关，例如与传统系统、数字现场网络、I/O、和DCS、PLC控制器等连接。工业互联网IIoT的设备也可经由这些系统进行存取。
图4DCN由DCP、DFC等构成
2.分布式控制平台（DCP）
DCP是在所有DCN中要求的硬件和标准软件接口。标准软件接口是一个公共平台，在平台之上运行控制软件程序。DCP提供物理的基础结构和可互换的特性，这样最终用户便可以根据需要从多家供应商选用软件和硬件。
3.分布式控制框架（DCF）
DCF是软件接口的标准集合，提供一个执行应用软件（譬如控制软件）的环境。DCF是DCP上面的层级，提供一个与OPAS有关功能一致性集合的应用程序，而不管是哪个DCN在运行。这对于建立OPAS应用程序的市场地位很重要。
4.OPAS联接性框架（OCF）
OCF是一个免版税的、具有信息安全且可互操作的通信框架规范。在OPASV1.0中OCF运用OPCUA。
5.高级计算平台（ACP）
ACP是实现DCN功能性的计算平台，但具有可扩展可收缩的计算资源（存储、硬盘、多核CPU），用于处理那些需要更多的资源的应用程序或服务，通常这些应用程序或服务不能由小配置的DCP来完成。ACP可以用来运行不容易分布或无法分布的应用程序，也可安装在一个预置的服务器或云端服务器上。
2.制定标准的路线和方法
为开放、可互操作和安全的流程自动化建立一个"标准的标准"，即"OPAS"，是一项复杂的事业。其制定策略是首先参考现有的各种适用的工业标准，识别这些标准与OPAS所要求的目标之间存在的差距，再与制定这些标准的相关组织一起对这些标准进行修订，或增加适合OPAF要求的条款，以实现合适的定义。只有在现有标准都不适用的时候，才考虑开发全新的标准。为此OPAF论坛已经与下列组织达成许可协议：AutomationML、ControlSystemIntegratorAssociation（CSIA）、DistributedManagementTaskForce（DMTF）、FieldCommGroup、IndustrialInternetConsortium（IIC）、InternationalSocietyAutomation（ISA）、NAMUR、OPCFoundation、PLCopen以及ZVEI等。
OPAF制定标准的路线图分三步走。第一步是2019年1月公布了OPASV1.0，着重于规范流程控制系统所用部件的互操作性。第二步是在2020年发表V2.0，主要规范组态（配置）和可移植性、可互换性。第三步是在2021年发表V3.0，主要是面向如何应用的规范或指南。通过每年发布一个新版本这样的方式，OPAF旨在促使开放流程自动化能在工业界取得认可和推进，促使自动化供应商启动开发新产品，并反馈技术意见，同时也反映最终用户的意见。
已经发布的OPASV1.0共有5个部分：Part1-技术架构概述（资料性）;Part2-信息安全（资料性）;Part3-配置;Part4-联接性框架（OCF）;Part5-系统管理。OPASV1.0已经有效采用了三个现有的标准：ANAI/ISA62443（被IEC采纳为信息安全标准IEC62443）、OPCUA（被IEC采纳为连接性标准IEC62541）、以及RedFISH（来自DMTF的系统管理标准）。这里Redfish是一种将IT软件和软件定义数据中心（SDDC）聚集混合的管理标准，它增强了公用的Internet和web服务的标准，让信息直接面对现代工具链，不管是由人读取，还是由机器读取，既简单又安全。
OPASV2.0和V2.1（关于组态的可移植性）着重于对不同的自动化部件和系统进行控制策略的移植。所谓的可移植性是指从软件供应商购买的应用软件，能按照应用的许可协议在一个公司内部在各种控制系统之间移植。如果经过最终用户的识别、判断和采纳，就可以将他们的知识产权IP以控制策略的形式进行移植。V2.0和V2.1中用到的已有标准包括：IEC61131-3（用于控制概念）、IEC61499（用于执行协调）和IEC61804（用于功能块）。未来的OPASV3.0将着重于应用程序的可移植性。
PackML--细分行业管控一体化标准的成功范例
近年来的实践和发展表明，PackML（PackingMachineLanguage）已经获得巨大的成功，不仅在包装行业取得广泛的认可和应用，而且还被作为集成架构的典型策略解决方案，为机械装备的集成系统提供了建模的参照标准。因为PackML涵盖了机械设备的横向集成和运行管理的纵向集成所需要的各种功能性，其概念、策略、架构和方法完全可以适用于几乎所有的机械设备集成系统，特别是所有运用顺序控制工艺的产线。
PackML是一个经过充分验证的独立的系列标准。它综合运用了许多适合于包装过程的控制和管理的成熟工业标准，并按实际需要加以扩充和修改（见图5）。这些工业标准有：
工控编程语言标准IEC61131-3
运动控制规范PLCopen运动控制规范
机械功能安全规范PLCopen机械功能安全规范
功能安全标准IEC61508
管控一体化标准批量控制标准IEC61512（ISAS88）
通信标准IEC62541（OPCUA）
在此基础上PackML开发工作组已经完成大量工作，制定主要用于包装工业控制的国际标准以解决编程、联网和最佳实践三大技术关键。比如在管控架构上运用了IEC61512（ISAS88）批量控制标准，按企业、工厂、车间的传统结构将包装生产线设置为车间中的流程处理单元。产线由不同功能的设备单元集成，而设备单元又是由设备模块构成，设备模块包含了许多控制模块。按照这样的系统架构贯通从上层的调度管理到底层机械设备的逻辑控制、顺序控制和运动控制以及安全控制，还开创性地定义了PackTag包装用通信标签，用OPCUA实现了机器对机器（M2M）和机器对其上层的HMI、MES等的通信。
图5PackML综合运用工业标准促成OT-IT融合
总之，PackML成功地用软件工程的方法对包装生产过程重新定义，支持了多品种、变批量的柔性自动化高效生产；对机械设备供应商、控制和通信供应商、管理系统供应商和系统集成商提供了可操作的标准化的关系界定；而对最终用户则是以一揽子的方式满足了它们提质增效、降低成本的诉求。
欧洲工业界如此评价PackML："它是一个经过充分验证的独立的标准；它有一个完善定义的模式/状态模型；它提供一个一致性的人机接口；它提供的公用定义通信标签和专业术语是互操作性的坚实基础；其架构具有高度的模块化。"而从事工业互联网服务的公司则高兴地看到PackML为包装生产过程提供关键业绩指标KPI的潜力：机械设备的PLC/工业PC运用PackTag，通过OPCUA将生产信息和参数安全地传输到远程监控的云端；在云端进行分析计算和判断后，生成KPI发布到移动终端的APP，为相关的管理人员和工程技术人员提供即时的服务。
更值得关注的是它运用于其它细分行业的前景和潜力。当前制造企业面临数字化转型，提出任何资产都要集成、任何资产都要在线的目标；在云赋能、大数据、人工智能等领域都面临前所未有的挑战。
而在许多制造行业中最大也是最直接的挑战是怎么集成制造生产线，使得不论是老系统改造更新还是新系统设计调试和投运，都能快速地摊销其成本并获得盈利。工业自动化业界早已认识到最大的集成成本来自软件集成（机械装备控制系统的协调集成、与企业业务系统的数据交换集成、与云应用的集成等）。另外，许多制造厂希望提高他们的机械设备的效率，但苦于没有数据；有的制造厂有一些数据，但还不足以运用这些数据实施差异化；还有些已经有了很多数据，但不知如何处理数据。一言以蔽之，绝大多数制造厂处于没有标准机制的状态，无法支撑他们将所采集的数据按需进行分析。
其实，PackML标准所关注和侧重的都是许多其它行业中最终用户的心声。因为OMAC开发PackML的动力正是来自用户和系统集成商在设法将各种机械设备集成为一个协调的系统的过程中，耗费了过多的时间和劳力而效果却不佳这样一个事实。其原因在于不同的设备厂家有不同的编程理念和方法、不同的控制逻辑、不同的通信协议、不同的控制器平台和操作状态，这意味着每台机械设备有不同的操作过程、培训、标准和诊断方法。随着来自不同厂商设备数量的增加，由此形成的复杂性不是按比例增加，而是呈几何级数增加。因此，PackML在开发之初就充分考虑到：将机械部件集成为系统时一定要做到所见即所得的一致性；这样才能为机械部件纵向和横向的集成提供基础，而不用考虑这些部件是哪个厂家制造的，以及用了什么样的控制系统硬件。PackML最终实现了在不同种类和不同厂家的机械设备之间提供高度一致性，并在此基础上建立了机械状态的标准集合和控制功能块的公共集合，为简化控制系统的开发、削减系统集成的工作量、减少培训和操作运行成本提供了可行的条件，从而极大地降低了用户总的消耗和投入。
PackML从不规定在所定义的任意一个机械状态下的机械操作细节，不规定每一个状态下的功能性。这保证了OEM厂家保护自己的知识产权。PackML只规定机械设备一共有多少个状态以及由一个状态转移到另一个状态的条件。但是，只要有公共状态的集合和定义好的标准的PackTag标签，就完全可以实现对每一个符合PackML的机械设备的监视和控制。同理，PackML也通过状态机和PackTag标签使数据交换标准化，而不规定具体从哪个机械获得数据又需要送到哪一台机械去，或者将数据送到HMI还是上位的生产管理系统和业务管理系统去。PackML不规定具体的传输方法、信息安全、编码/解码规则，也不规定通信接口和物理介质，这就导致OPCUA、TCP/IP和以太网得以进入并发挥其所长。OPCUA提供安全的通信，承担通信的授权（例如使用PackTag的授权）和数据的封装。OPCUA还提供公共的编码，PackTag可以由OPCUA进行适当的编码和解码。总的说来，OPCUA为在很大程度上简化符合PackML的机械与其它机械的控制器、HMI、企业业务系统和云服务的集成提供了基础。OPCUA可以通过实现PackML的架构和方法，控制和监视任何一类机械装备，从而解决机械装备集成所常见的若干战略性问题。
著名仿真软件公司MathWorks的Matlab/Simulink为PackML开发了一套设计、仿真和测试的集成开发环境：用Stateflow建立符合PackML标准的状态机的模型样板，然后通过静态检查和一个附加的用户接口确保模型的状态和转移条件符合标准的定义。仿真则使开发人员具备执行早期和递增验证的能力。DesignVerifier用来生成对模型的基于覆盖延伸的测试实例，Test用来执行和管理测试实例。在此基础上运用自动代码生成可针对不同厂家的PLC生成符合IEC61131-3标准的结构化文本语言ST和符合ANSI/ISO的C/C++控制程序。用Coder（C/C++）或PLCCoder（IEC61131-3的ST）所生成的代码符合PackTag的规则，这样便可以与其它符合PackML的软件无缝集成。而且PLCCoder能够从测试实例中生成一个基准测试程序，对模型进行验证，以保证模型的行为特性和代码的行为特性相等效。下列PLC和工业PC平台支持由Simulink自动生成控制代码：3S的CoDeSys、贝加莱的AutomationStudio、倍福的TwinCAT、博世力士乐的IndraLogic、罗克韦尔的RSLogic、西门子的STEP7/TIAPortal/WinAC，以及三菱电机、OMRON、菲尼克斯的平台软件。
综上所述，我们可以得出以下结论：（1）作为建立在适用工业标准综合基础上的PackML系列标准已经发展成熟，在包装行业有了大量的推广和应用，而且已经形成的一整套的技术性和经济性的良性循环的生态系统。（2）PackML标准和规范所蕴含的价值远远超越了它为包装生产线解决系统集成问题的初衷。它所开创的理念、策略和方法可以直接推广到所有的目前因集成不同厂家制造的设备而举步维艰的应用场景。不仅可以用于食品和饮料生产、以及其他日用消费品如卫生纸品的生产，甚至对于汽车生产这样高度复杂的场景都可以发挥巨大作用。（3）PackML可以推广到任意制造行业解决设备集成问题，而PackML和OPCUA的进一步组合有助于解决所有制造厂在云赋能、大数据、人工智能等领域所面临的战略挑战。充分认识这些经过时间和实践充分验证的技术，将对众多行业降低集成成本、提高生产率、向数据驱动的智能服务商业模式转型带来无尽的应用潜力，产生难以估量的巨大价值。
讨论
已经获得成功应用的PackML细分行业综合标准，贯通了从上层的管理到中间的通信，再到底层的机械控制及其运动控制，支持了多品种、变批量的柔性自动化高效生产，对机械设备供应商、自动化供应商、系统集成商，都是可操作的标准化的关系界定。看起来一条已在役的专用自动化生产线要改造成柔性自动化生产线，可以从中汲取的将不仅仅是思路，而是从策略到方法、从整体框架乃至许多技术细节。
从包装行业的领域知识和领域模型的视角来看，这里显然有着深刻的技术背景：PackML遵循的是基于模型的系统工程（MBSE）的思路，通过建立和利用领域模型（即PackML的状态图）而不是通过建立和利用文档作为信息交换的主要手段。PackML从概念设计阶段开始，贯穿整个开发阶段，直到后续的生命周期阶段，都通过形式化的建模应用来支持系统的要求、设计、分析、验证和确认。特别是PackML选择OPCUA作为互操作的标准，这与OPCUA近年来被德国工业4.0的资产管理壳AAS选中作为其标准和技术体系的支撑部分，有非常好的契合。其中的原因在于OPCUA的信息模型及其建模工具和运行环境能够同时兼容并融合PLCopen/MTconnect/AutomationML/机器视觉/通信等MBSE模型，当然也包括PackML的MBSE模型。
从正在开展且取得部分中间成果的开放流程自动化标准OPAS来看，其涉及的面更广，对未来工业自动化的发展影响更深。其最深刻的颠覆在于一改现有的工业控制系统硬件软件捆绑的封闭面貌，开创了按照最终用户要求集成不同供应商的硬件和软件部件，就能够构筑具有互操作性特性的控制系统的全新局面。也就是说，在未来的DCS和PLC系统中硬件与软件是彻底解耦的，用哪些硬件部件和软件部件构筑控制系统的主动权完全在最终用户手中，只要遵循OPAS规范，系统一定能实现互操作性运行。进一步的发展将朝着即插即用方向实现同类型硬件部件和软件部件的可互换，为此就要求在进行系统组态和配置方面遵循相应的规范，即在不同组态工具链之间建立符合一致性数据交换国际标准AutomationML（等效于IEC62714）的接口，这样就可以保证所定义的组态信息和Layer-F（即开放联接框架层OCF，见图3）的应用软件可以被不同供应商的组态工具所输入，也可以被不同供应商的组态工具所输出，从而实现了组态的可移植。
这两个"标准的标准"展现了充分的系统性。所谓的系统性是一种复杂系统的状态、质量或条件。这种复杂系统虽然是由许多相互连接的部件所构成，但系统作为一个整体所展现出来的行为特性远远区别于其组成部件的单个行为特性。因此系统性就是一种属性，将最大而且直接地影响创新技术被采用的广泛性。开放流程自动化标准OPAS和PackML标准都是以它们鲜明和完整的系统性，已经和正在显露出无穷的生命力。
整体上说，国外在这个方面的工作做得非常扎实，不但是可操作、可实现的，而且还是统一的。不管是制定新的面向行业应用的标准规范的能力，还是对当前现有的各种标准规范的组合应用能力，国内外的差距简直可以说是天壤之别。在国内，大家一窝蜂地跟随某一潮流，大都为了当前短暂的利益单兵作战，彼此间没有协同和统一；更没有组织和单位去发起和创建服务于公共领域和细分行业的综合性标准，形不成合力，更遑论形成一种生态。我们都说，得标准者得天下！在开发"标准的标准"这一战略能力方面的长期缺失，很可能成为我国工业在自动化、信息化和智能化发展道路上将来被进一步拉大差距的根源。
