参与了多年与数字化相关的标准工作组工作，对于这项工作有一些粗浅的认识，作为一个内容与大家分享。之前主要是私下和一些标准化工作组的同仁做了交流，也得到了对这些想法的认同，因此，觉得可以写篇文章作为一个分享。

在过去的很长一段时间里，国家针对于“标准”存在的欠缺做了很多部署，也出台了鼓励企业、行业主导和参与标准化工作的政策。这些都有力的促进了标准化工作的开展。结合观察的标准工作以及存在的问题，做一些总结。

1.标准的软件化问题

国内很多有关数字化制造、服务、软件、接口、信息化等的标准，这里最大的问题可能在于“它是否有厂商支持?”。标准不是一个简单的文档，印有庄严的国家标准的文件，而是它究竟是否有厂商支持。

如何理解“厂商支持”，我们以ISA组织初始发起，并纳入了OPC基金会垂直行业信息模型的PackML这个规范为例。在很多自动化厂商的软件平台里，他们都支持PackML，将其作为一个功能块，可以给用户调用、配置、嵌入到应用软件中。还有像SEMI，它是在半导体行业普遍使用的设备间、设备与MES系统间协作的规约。它最早由应用材料所开发，现在已经被整个半导体行业所采用。在半导体行业，在MES、机器的嵌入式操作软件(即，机器的PLC/PC控制器上运行的软件)均有对这一规约的专用软件功能块。包括像FMU/FMI这种，来自Modelica组织的建模仿真软件之间的交互标准，在很多企业的开发工具平台里，都是支持的。

图1-PackML在各个公司被软件实现

PackML可以对来自不同企业的设备，可能应用的是也是不同自动化厂商的系统，但PackML制定了统一的数据标签、HMI操作界面，使得不同企业的机器可以实现M2M的连接，以及与MES系统在上下行数据上实现交互。

为什么要做成软件功能被调用?

因为标准这个东西，如果不能做成软件功能被用户使用，那么，就意味着无法被真正有效落地，只能停留在书面上。数字化类的标准，很多不是强制性标准，它就是用于不同厂商的设备，以及运行侧与管理侧之间的纵向集成。如果不能做成这个模块，那就完全不方便-如果需要针对这个规约由厂商在一个项目中自行开发，那就费时费力，却没有可复用性。

因此，标准的软件化，是标准能否被真正有效的贯彻的关键。而这就需要标准本身是具有可以软件化的条件。

2.标准，是一个工程开发过程;

如果要想标准实现软件化，那么，标准本身的制定过程，就得“匹配”软件的开发过程。而这就意味着，标准的开发过程要为其软件化提供工程开发的流程、结构、参考。

以所参加的TSN时间敏感网络为例，在IEC60802的标准中，我们可以观察到它是按照需求定义(Use Case)、模块开发、测试验证、系列化的过程来进行开发的。它先是对“应用场景”进行了梳理，按照对数据的周期性、负载容量、类型等进行了8个类别的划分。然后对不同场景制定了不同的整形器(Shaper)的设计，然后对各个场景如流程、多轴运动等场景进行了架构的设计、对网络的配置进行了规范—这个需要用户友好，即，不管网络多么强大，对于用户来说，必须是配置简单的。

表1-TSN定义的不同场景需求

在表1中，我们可以看到TSN是分析了8种不同的需求场景。并制定了图2中，以模块化的方式开发了相关的时钟同步、数据流调度、可靠性、网络与用户配置四个板块的模块。图2-TSN的模块化开发

在整形器的开发中，针对像汽车领域的IEEE802.1Qav的整形器，结合IEEE8-2.1AS的时钟同步、IEEE802.1Qat的流预留协议配置标准，构成了车载以太网的标准组。而在工业领域，IEC60802工作组则由IEEE802.1AS-Rev时钟、IEEE802.1Qbv、IEEE802.1Qcc构成了完整的自动化领域的标准组。TSN与之前的通信标准制定过程不同在于它采用了模块化，而不像传统的现场总线参考ISO/OSI模型将L1+L2+L7作为一个整体进行了定义。

因此，我们可以看出来，这是一个严格的“工程开发”过程，它是和技术人员开发一个产品或研发一项工程应用一样。遵循工程开发的整个流程与工作。

由于在较长时间内，国内标准都是“跟标”为主。这使得我们在制定标准的时候，缺乏“原创性”设计标准的过程，因此，未能建立起有效的标准工程开发流程。虽然，标准的开发不同于具体的技术，而且，标准都停留在“协作”层面，因此，它又与企业自身的Know-How技术开发不同。但是，它仍旧是一个“Development”的过程，需要遵循工程规范。

3.数字化标准在于开放连接

在标准的制定过程中，很多国标工作组，包括现在更多的团标工作组。会有一些承袭的行政管理思想，将标准作为一种“管控”工具，体现组织的一种权力，作为一种认证方式，来对行业、企业进行某种认定。或者把标准之争作为一种技术或贸易壁垒目的。但是，数字化类的标准，它本身主旨在于“开放连接”，它是为了让数字化制造的工作，成为一个简单的工作。因此，它本身的核心意义在于“开放”、“协作”，而不在于建立“壁垒”。

数字化方面的标准，它不同于食品安全、工业信息安全等。个人认为，任何安全类的标准它必须是强制的，也是需要政府监管的，需要非常强的贯标的力度，并且，它本身是应该由法律进行保障，而非行业或标准化组织来保障执行的。

4.学习、参与与引导三步走

在过去，由于很多在标准方面的吃亏，我们就有了自主标准的意识，这是一种对标准的重视进步的表现。但是，另一方面，彻底抛弃原有国际标准另起炉灶的想法也会有一定的思虑不足。虽然，标准它本身是一个文件，但背后实际上是技术，尤其在数字化类的标准上。现在国际上的这些标准都是在数十年的积累下建立起来的—并且，数字化类标准不同于食品药品安全类、适航类，它更多强调的是开放性连接。因此，抛开已经运行数十年的通信、IT技术架构是比较难的，也不现实。制定自主标准，必须在技术上处于领先地位，或者像5G、光伏、锂电制造等，它处于市场的主导地位，则可以，如果不是，那么，还是应该谨慎思虑。

因此，个人的建议是“学习、参与到引导”，三个阶段走的路径。首先，好好学习，尤其是这种很多企业之间，如何达成共识，一步步的推进一项“协作”标准的制定。这种企业、组织间的协作，开放性，是我们需要去仔细研究的。尤其是数字化标准，牵扯多方协作，如果不能达成共识，便很难形成一种合力，真正的资源共享。第二步参与其中，在IEC/IEEE/ISO等组织中，还是要多参与标准的制定过程，将我们对于标准的实际产业情况(需求)、想法、技术实现等纳入到国际标准中。毕竟国际组织他们仍然是需要听到中国的声音的，因为，没有中国的声音，这些组织本身的说服力也会下降。引导阶段，在充分与标准化组织的参与后，我们会将我们在领先的领域，纳入国际标准中，将我们对这个开发的理解、功能、软件，都给标准化—但是，我们必须得回到前面几个问题，我们的标准是否有厂商在软件层面的支持、我们是否严格的遵循开发过程、以及这些是否基于协作的思想下的。