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

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

标准的软件化问题

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

如何理解“厂商支持”,我们以ISA组织初始发起,并纳入了OPC基金会垂直行业信息模型的PackML这个规范为例。
在非常多自动化厂商的软件平台里,他们都支持PackML,将其作为一个功能块,可以给用户调用、配置、嵌入到应用软件中。还有像SEMI,它是在半导体行业普遍使用的设备间、设备与MES系统间协作的规约。它最早由应用材料所开发,现在已经被整个半导体行业所采用。

在半导体行业,在MES、机器的嵌入式操作软件(即,机器的PLC/PC控制器上运行的软件)均有对这一规约的专用软件功能块。包括像FMU/FMI这种,来自Modelica组织的建模仿真软件之间的交互标准,在非常多企业的开发工具平台里,都是支持的。

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

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

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

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

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

标准,是一个工程开发过程

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

以所参加的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”的过程,需要遵循工程规范。

数字化标准在于开放连接

在标准的制定过程中,非常多国标工作组,包括现在更多的团标工作组。会有一些承袭的行政管理思想,将标准作为一种“管控”工具,体现组织的一种权力,作为一种认证方式,来对行业、企业进行某种认定。或者把标准之争作为一种技术或贸易壁垒目的。

但是,数字化类的标准,它本身主旨在于“开放连接”,它是为了让数字化制造的工作,成为一个简单的工作。因此,它本身的核心意义在于“开放”、“协作”,而不在于建立“壁垒”。

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

学习、参与与引导三步走

在过去,由于非常多在标准方面的吃亏,我们就有了自主标准的意识,这是一种对标准的重视进步的表现。但是,另一方面,彻底抛弃原有国际标准另起炉灶的想法也会有一定的思虑不足。虽然,标准它本身是一个文件,但背后实际上是技术,尤其在数字化类的标准上。现在国际上的这些标准都是在数十年的积累下建立起来的—并且,数字化类标准不同于食品药品安全类、适航类,它更多强调的是开放性连接。

因此,抛开已经运行数十年的通信、IT技术架构是比较难的,也不现实。制定自主标准,必须在技术上处于领先地位,或者像5G、光伏、锂电制造等,它处于市场的主导地位,则可以,如果不是,那么,还是应该谨慎思虑。

因此,个人的建议是“学习、参与到引导”,三个阶段走的路径。

首先,好好学习,尤其是这种非常多企业之间,如何达成共识,一步步的推进一项“协作”标准的制定。这种企业、组织间的协作,开放性,是我们需要去仔细研究的。尤其是数字化标准,牵扯多方协作,如果不能达成共识,便很难形成一种合力,真正的资源共享。

第2步参与其中,在IEC/IEEE/ISO等组织中,还是要多参与标准的制定过程,将我们对于标准的实际产业情况(需求)、想法、技术实现等纳入到国际标准中。毕竟国际组织他们仍然是需要听到中国的声音的,因为,没有中国的声音,这些组织本身的说服力也会下降。引导阶段,在充分与标准化组织的参与后,我们会将我们在领先的领域,纳入国际标准中,将我们对这个开发的理解、功能、软件,都给标准化—但是,我们必须得回到前面几个问题,我们的标准是否有厂商在软件层面的支持、我们是否严格的遵循开发过程、以及这些是否基于协作的思想下的。

发表评论