作为OPC基金会中国免费技术顾问，在10月14日的中国OPC Day在线会议为大家分享一下OPC UA FX的进程。这里FX即Field eXchage。也和基金会中国的张誉有些深刻的感受--即，OPC UA基金会在推进数字化标准与规范方面的工作值得借鉴。每一年的OPC Day都能看到欧美的自动化同仁们，以及来自大型终端用户如欧莱雅、大众汽车、巴斯夫等，大型IT企业Microsoft、华为、Cisco、Intel等，他们都在积极推进着这个关系着未来制造业集成进程的规范与标准。从OPC基金会的工作我们可以看到很多值得借鉴的地方。
大背景-产业数字化中的难题
关于数字化转型，这里牵扯到的话题是，我们究竟需要数字化转型，还是转型需要数字化？
图1-数字化推进中的困境
关于产业推进数字化进程中的几个困境：
1.互操作标准的欠缺
数字化架构的实现，无论提出边缘计算、数字孪生、工业互联网、工业物联网、智能制造架构。这些实现的显著特征是“集成”，数据、通信、应用的基础连接需求，必须建立在体系性的标准基础之上。这是共识，在多个系统间如数字化设计的CAD/CAE/CAM/CAPP，以及现场运营技术类的系统如PLC/DCS/SCADA和管理系统如ERP/CIMS/MES，以及应用的Cloud/Edge这些多功能场景中的集成，必然遇到这个交互的难题，如果没有统一的规范与标准，这是无法想象的。
欧美构建这些架构的首要问题就是标准的问题，因此，OPC UA基金会联合了众多的协会组织，包括中国的SAC/TC124、IEC、VDMA、I4.0组织、IIC、ECC（中国边缘计算组织），以及各个现场总线基金会、OMG(DDS)、MQTT等统一来构建这些标准连接问题。
2.工程成本如何降低的问题
目前国内推进的工业互联网企业，就其现实数据报表来看，鲜有能够盈利的。这个问题的关键就在于无法解决应用的“可复制性”问题—除了雄心勃勃准备从事该领域的大量企业，在资本的推动下，热火朝天的干了也有不少年头了。
可复制性的关键在于标准与规范，缺乏标准与规范会大幅影响工程实施成本，因为，大量的数据需要连接、配置、开发接口并进行测试，如果没有统一的规范与标准，那么这就会成为一个“劳动密集型”工作，就会带来大量的人工成本，而尤其是IT类工程师的成本又较之市场平均工程师成本高的情况下。
3.模块化编程
就实现层面来说，面向对象、模块化封装的方式构建了系统的各个应用，那么，整个应用是会快速实现的，也可以被复用—但是，这就是难题。
经常和张誉讨论起这件事情，OPC UA的角色其实非常关键，因为，在工程实施的时候，数据是一个独立体，而应用则千差万别的接口方式，那么，OPC UA提供了一个数据的标准封装框架，使得对于不同的应用而言，都可以基于相同的方式来调用数据。OPC UA首先就是一个容器来对数据进行了结构化和标准化的处理。
其次，OPC UA又将在不同场景中的通信连接方式予以了支持，这包括了C/S、Pub/Sub的不同机制下的通信协议支持，几乎涵盖了各个常用的通信规约，如OPC UA对现场总线的支持、对TSN、MQTT、DDS这些的支持，都是为了解决在不同的领域所习惯和常用的通信机制。
OPC UA提供了特别的命名空间（Name Space）来为数据提供了数据存储的格式、访问层级、角色、授权与验证机制、类型、参考、调用等，这些使得数据具有了“高完备性”的结构，这带来的问题是它看上去会有点过于“重”的结构。
不过，OPC UA比较好的解决了这些问题，它基于SoA，其实，这就是一种“关注点分离”的模块化编程思想，它使得应用和数据分离，OPC UA数据提供服务给不同的应用来“共享方式访问”，避免数据与应用的耦合关系带来的复杂性，以及不同应用间的潜在耦合风险。
另外，OPC UA提供了一种“动态”的交互模式—这使得系统具有“动态”运行的特征，满足制造现场中的变化，例如在数字化仿真系统和运行系统间的动态模型交互，可以有助于实现数字孪生运行、边缘计算的架构运行—因为，它自身也包含了对传统现场总线、TSN、Pub/Sub机制的高实时性任务交互的需求。
当然，OPC UA的确比较重，这也在于OPC基金会的野心实在庞大，想将整个制造纳入其中—并且，为何要将FLC纳入其中，因为，如果要实现制造现场的动态性能，就得把现场层通信纳入其中。
4.信息安全问题
由于集成，必然牵扯到了IT与OT系统的相互访问，而IT系统本身采用的通用访问机制也带来了端口的开放，带来对底层数据访问中的信息安全问题。因此，OPC UA信息安全采用了证书和授权机制，这使得信息安全得到保障—这也是非常重要的一环。
除了信息安全（Cyber Security），另一个在工业里需要被考虑的安全是功能安全（Functional Safety），确保生产装备的人身安全机制。
因此，本文，主旨讨论技术标准与规范，顺便展开讲一些观点与看法。
图2-OPC UA FX所描绘的通信全景
图2是最为经典的-所有人都看过的，不宜多讲，列为看官，看图生义，就知道未来工业通信的目的是从管理的架构延伸到分布式计算的架构。
其实，所谓的数字化转型，仅从数字化这个视角，它就是要将原有的架构扩展到分布式架构上，而意味着不仅技术，通信，也包括了企业内的数字流动、业务的灵活性组合、服务的灵活组合问题，即，局部单元的智能，以及，其组合形成的对市场的应对能力。
本文仅讨论标准与规范，只是顺便想提醒一下我们讨论数字化转型的时候，在商业逻辑上，技术、规范均是要服务于业务。转型，是业务模式的转型，企业应对市场能力的转型，那么，技术架构只是满足这种变化—我们讲这种技术的演进，只是在业务转型发生后的匹配，而不是试图用技术去指挥企业的数字化转型。
图3-参与OPC UA FLC倡议的企业
图3是主要OPC UA FLC～现场级通信倡议发起者，两者的关系在于FX是FLC制定的具体规范。FLC由自动化业界的知名企业、以及Intel、Huawei、Cisco主要推进的，而国内的厂商似乎只有来自IT业界的华为一家。前年的时候，某圈内朋友还表达“国内自动化厂商似乎还没有积极参与到国际规范与标准中去”。另一方面就是国内好像信誓旦旦要为工业通信制定规范与标准的，反倒不是自动化企业，而是来自于通信领域的企业。这一方面说明了或许在国内OT端企业的专业话语权并不重，亦或企业都只是忙着赚钱，也没空搭理所谓的未来通信规范与标准。由IT厂商建立工业通信规范与标准，我只是想说“此通信，非彼通信”。做了标准，和规范，需要有工业领域的企业参与并在产品研发中来支持。
后面我会总结一下，制定标准这件事情，看来也不是一个简单的事情，我们对于标准，如老尹说的算是个“指导”、“管理办法”—定性而不定量，有较大解释空间的描述性、建议性、指南性，但缺乏在实际层面的可操作性、落地执行方面的内容-好处就是快速就可以制定标准。
OPC UA FX中的关系
而根据FLC所倡议的规范，即，OPC UA FX，它是OPC UA Field eXchange的简写，从其名字即是将OPC UA涵盖至现场层，即，OPC UA不想仅停留在通信层，也想涵盖网络协议的统一规范，可谓志向远大。OPC UA FX听上去感觉是对OPC UA over TSN的新称呼，倒也不完全是，因为，OPC基金会想法并不局限于TSN，这个FX会涵盖5G、Wi-Fi 6这样的无线通信，可以被称为OPC UA over 5G、OPC UA over Wi-Fi 6，这些都被称为Field eXchange。
因此，有线和无线都会成为基础。目前TSN的确被赋予了更高的优先级，毕竟5G的性能和成本尚未对于工业有好的经济性，只是在测试验证阶段。而Wi-Fi 6，也在测试中，作为在OPC UA基金会的未来技术选项里，做了罗列。如图4，OPC UA FX在整个连接中的作用。
图4-OPC UA FX所处的位置和作用
OPC UA FX进展
OPC UA FLC作为倡议者组织，由主要的自动化厂商发起，在初始阶段，它主要聚焦在C2C，即，Controller to Controller阶段的通信。而在2022年7启动C2D和D2D领域的规范，使得TSN延伸至Controller to Device 及Device to Device的阶段。
TSN目前的国际标准IEC60802似乎进展比较慢，因为2020-2022年这期间疫情的缘故，以及很多企业人员的工作不稳定，IEC60802似乎并未完成其IA Profile的规范工作，因为目前才是CDS文件，尚未进入FDS文件状态。
图5-FX工作范围和边界
如图5，OPC UA FX涵盖的是底层网络和其IA-Profile的定义，我们从这个结构上可以看到，OPC UA基金会的想法就是用OPC UA的应用信息模型来作为应用层架构，然后集成网络层的TSN/5G，这个想法很大，也即，OPC UA+TSN，会被新的FX规范所定义。
OPC UA FX的规范简要展开
图6-OPC FX系列规范
如图6，OPC UA FX第一批规范，也即在2022年发布的Part 80-84这个集合，主要还是针对C2C的，即包括80-84五个部分，其中80，82在去年进行了介绍。此次主要还是交流一下两个重要的规范，81和83，一个针对自动化组件本身的资产、功能模型，和离线工程的规范。
Part 80：主要定义了OPC UA FX基本概念
Part 81：自动化组件的资产和功能模型的协调，统一的自动化组件信息访问，独立于控制器或设备厂商，适用于PLC或传感器、工厂或过程自动化
图7-自动化组件的信息模型参考
在自动化系统的组件中，包括了物理对象、软件、固件、授权，信息包括厂商、产品、固件版本、序列号等。实际上就是给上位或水平系统提供了谁家的控制器、软件版本等基本信息，如图7所示。
图8-自动化组件的逻辑连接
其次，如图8，就是提供了这些自动化组件的验证（资产与功能性实体）方法、拥有者、应用配置等。再者就是这些组件，如PLC、驱动器支持的交互机制，基于OPC UA Pub/Sub机制来传输，信息包括功能安全、信息安全、TSN的QoS（优先级、保护带宽、延时、截止时间）、不同的传输机制(以太网、UDP、AMQP、MQTT)、连接的监测。
Part 83-离线工程
图9-离线工程信息规范与参考
在离线工程方面，如图9，FX包括了离线描述器用以描述能力、功能，配置自动化组件的资产，自动化系统必要开发、调试、维护阶段的信息。
这个开放的封装文档采用ECMA-376，也就是openXML的格式来进行建模和附件封装，内部与外部关系、数字签名。信息模型描述采用了Automation ML规范，一种面向车间工程的XML-based数据交换格式，也是IEC62714的标准。工程附件包括其它信息模型的集成，如PLCopen、YANG，文档、手册、图纸。
就是说，这些是在离线工程中，对自动化组件的相关信息、描述、图纸、文档等进行统一规范。
应用场景分析
OPC UA FX，或者之前称为OPC UA over TSN的，在很长一段时间里，其实，很多人都会疑惑它的应用场景。其实，如果TSN你觉得用不到，那么大概率上来说：
（1）.数字化还未到达较为深入的阶段
后来发现，大家为什么不用OPC UA over TSN，而是因为其实很多应用，它在OPC UA +Ethernet这个任务等级上就可以解决，比如OPC UA在标准以太网上，其实也可以达到10mS倍数等级的，而且，在有些时候，如前段时间发现我们的工程师在OPC UA的访问上，可以达到2mS的循环，这还超出了我的原来的想像。
在什么场景下会需要TSN？
->真的是实现了互联，以及高速的推理应用这个场景；
->动态的数字化应用，即时分析与应用；
（2）.大概你还没有了解OPC UA FX的方案就是为了你的应用而设计；
因为，你可能在寻找方案，但因为目前TSN的很多方案其实，还都在测试阶段，还不是成熟到所谓的“拿来即用”，因此，对于在测试会觉得还没完成，而对于没有测试的一般都在拿其它的方案在测试，但是，还没有寻找到最佳的解决方案。而当OPC UA+TSN比较成熟的方案出来后，这个架构才会发挥力量。
（3）.这几年进程的确有点慢。
TSN最近几年进展比较慢，与TSN是一个基于IT思想而设计的标准，它的形成过程不同于以往，因为IEC其它的通信标准，基本上都是传统OT的“先有问题，再寻求方案，最后标准化”的思路。TSN是按照先有技术，然后去推进场景应用的IT思维来设计的。
另外，TSN被称为“历史上，首次，各家自动化厂商要来协同构建的标准”，TSN与以往的由某个主要厂商已有的标准来推进不同。这是第一次大家居然竞争企业坐在一起来商讨如何面向未来构建一个新的工业通信架构。因为，大家意识到，原有的玩法，在未来不会那么奏效。
这使得TSN较之以往的通信标准需要花费更多的沟通与协调时间，但是，好在它是有基础的，即早期的IEEE802.1Q的基本规范上。因此，相对来说，它又算快的—因为，毕竟第一次Shaper起草工作组会议还是在2016年，到2019年左右各家已经出了原型机，按说速度也够快的。
但是，目前来看，各家的问题都聚焦在了“软件”问题上，即，如何更为有效的对TSN网络进行配置，因为，TSN网络不同于以往的工业通信网络。传统工业通信网络基本上为了“确定性”，采用了非常简化的思路，就是“轮询”、“令牌”，因为，这种在软件上容易实现，配置简单。但TSN采用了复杂的排队和“桥接”网络模式，这使得系统复杂性会有所提高。
网络动态配置会是个关键问题，需要一个好的配置算法来实现高效的配置，在网络出现变化时，能够动态优化网络的数据流调度。因此，TSN网络是一个需要高度智能的网络配置系统，还有，这个必须要做到“User-friendly”，而这又是个难题，要把复杂的网络问题，转换为与应用无关、与制造商无关的进行配置，这本身就需要特别的“标准”，而IEEE/IEC6082的工作进程也使得这项工作推进有点慢，最近几年疫情也使得大家工作都不那么稳定有序。
图10-OPC UA over TSN的应用场景
在图9中，可以看到首先由TSN来采集现场数据，包括I/O、视觉、运动控制轴（目前C2D刚开始），然后经由OPC UA over TSN传输到边缘控制器层，如贝加莱可以采用Hypervisor的工业PC来作为一个处理和分析单元。在这个架构中，处理和分析单元，主要运行AI、调度、优化类的程序，然后解析出要去执行的调整，通过TSN网络来下发给现场设备。而对于长周期的模型训练，OPC UA也提供了到云端的连接规范（后续可以另行分享）。
在OPC UA over TSN的应用架构中，首先是有集成的架构实现，然后是高速动态的质量分析、快速动态的调节执行行为，构成一个控制、边缘分析下发执行的大闭环—这个闭环，主要聚焦在全局的质量优化、改善上。
关于标准的问题
我也看过了大量的IEEE/IEC关于各种标准的制定文件，能观察到这些标准的制定，其实是个非常严谨的工程过程。图10作为参与一些标准工作，以及对照OPC、IEEE的标准工作有感而发。
图11-对于标准制定的思考
首先，标准的制定，包括参考IEEE802.1Q系列的TSN标准，以及OPC 基金会的标准。可以看到，标准的制定完全基于一个工程开发过程的流程来实现，先要去分析需求，制定一个目标，然后要拆解为各种场景，因为即使工业也分为离散、流程、批处理等多种业务场景，然后要去解析，解决这些问题的机制，针对这些问题拆分为硬件、软件、网络拓扑、配置工具与方法等。因此，制定这个标准的过程本身就是一个非常严谨的工程开发过程。
因为，受制于在工程思维方面的训练，以及在技术研发水平上的制约，感觉很多时候，我们在制定标准的时候，会陷入到对“词句”的解析上，因为很多都是跟标。而自行制定的标准，往往照猫画虎，但并非基于需求的工程过程来实现，在形式上像是标准，但在指导性，实现可行性尚有欠缺。
协作问题，标准制定还是需要较好的协同工作机制，这需要本身具有强的研发项目管理水平。专家方面，还是需要一线的工程技术人员参与比较好。另外，在这些标准的制定过程中，行业的标准，应该多方协同，包括各自的角色分工：
（1）.终端生产企业：目前大部分的智能制造、工业通信标准，最终用户是使用者，因此，他们需要从需求端来提出意见。国内很多标准，缺乏来自终端用户的声音，如果仅是自身行业人制定标准，那么，难免有点“闭门造车”的问题。
（2）.装备企业：作为系统的实现者，或者技术的载体，装备需要更为明确在其自身的实现上的需求。
（3）.技术提供者，像自动化、系统、软件类厂商，作为技术提供者，应该去按照需求来解析模块，并对其进行分布开发。提出规范与标准的实现方法。
（4）.标准专家：基于标准的标准来对整个标准制定过程的程序、定义、边界、行文、引用等进行规范。
参与的企业要具有广泛的代表性，而专家身份也需要来自技术、工程管理，众多利益相关者必须深入参与其中。