作者：宋华珍

作为OPC基金会驻中国的免费技术顾问，我将在10月14日的中国OPC日线上会议上与大家分享OPC UA FX的进展。这里的FX 是Field eXchage。我对基金会中国的张宇也有一些深切的感受——那就是OPC UA基金会在推动数字标准和规范方面的工作值得学习。每年OPC Day，我们都能看到来自欧美的自动化同仁，以及大型终端用户如欧莱雅、大众、巴斯夫等，以及大型IT公司微软、华为、思科、英特尔等.他们都在积极推动这种关系。它将为未来的制造集成流程制定规范和标准。我们可以从OPC基金会的工作中看到很多值得学习的地方。

大背景-产业数字化中的难题

关于数字化转型，这里涉及到的话题是，我们到底需要数字化转型，还是转型需要数字化？

关于行业推进数字化过程中的几个困境：

1.缺乏互操作性标准

数字架构的实现，无论是边缘计算、数字孪生、工业互联网、工业物联网，还是智能制造架构都被提出。这些实现的显着特征是集成。数据、通信和应用的基本连接要求必须基于系统标准。这是数字化设计的CAD/CAE/CAM/CAPP等多个系统，以及PLC/DCS/SCADA等现场操作技术系统和ERP/CIMS/MES等管理系统以及应用云/边缘这些多功能场景中的融合，必然会遇到这种交互问题，如果没有统一的规范和标准，这是不可想象的。

在欧洲和美国构建这些架构的首要问题是标准问题。因此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对Fieldbus的支持、对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是最经典的一张——大家都见过。不宜详细谈论它。它被列为指南。看图就知道，未来工业通信的目的是从管理架构延伸到分布式计算架构。

其实，所谓数字化转型，仅仅从数字化的角度来说，就是将原有的架构延伸为分布式架构，这不仅意味着技术和通信，还意味着企业内部的数字化流动和业务的灵活组合。服务灵活组合的问题，即地方单位的智力，以及它们组合形成的对市场的反应能力。

本文仅讨论标准和规范。我只是想提醒大家，当我们讨论数字化转型的时候，在业务逻辑、技术和规范上一定要为业务服务。转型是商业模式的转型，是企业应对市场能力的转型。那么，技术架构就只能满足这个变化。当我们谈论这项技术的演进时，它只是业务转型发生后的匹配，而不是试图用技术来指导企业。数字化转型。

图3是OPC UA FLC~现场级通信的主要主动发起者。两者的关系是，FX是FLC制定的具体规范。 FLC主要由自动化行业知名公司推广，还有Intel、华为、思科等。不过，国内厂商似乎只有来自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在整个连接中的作用。

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 所示，OPC UA FX 涵盖了底层网络及其IA-Profile 的定义。从这个架构我们可以看出，OPC UA基金会的思路就是以OPC UA应用信息模型作为应用层架构，然后在网络层融合TSN/5G的思路是巨大的，即就是，OPC UA+TSN，将由新的FX规范定义。

OPC UA FX的规范简要展开

如图6所示，第一批OPC UA FX规范，即2022年发布的Part 80-84集，主要面向C2C，包括5个Part 80-84，其中发布了80和82去年有过介绍。这次我们主要讨论两个重要的规范，81和83，一个针对自动化组件本身的资产、功能模型和离线工程的规范。

Part 80：主要定义OPC UA FX的基本概念

第81部分：协调自动化组件的资产和功能模型，统一访问自动化组件信息，独立于控制器或设备制造商，适用于PLC或传感器、工厂或过程自动化

自动化系统的组件包括物理对象、软件、固件和授权。信息包括制造商、产品、固件版本、序列号等。实际上，它提供了向上层或横向系统提供的控制器和软件版本等基本信息，如图7所示。

其次，如图8所示，提供了这些自动化组件的验证（资产和功能实体）方法、所有者、应用配置等。另外，这些组件，例如PLC以及驱动程序支持的交互机制，都是基于OPC UA Pub/Sub机制进行传输的。这些信息包括功能安全、信息安全、TSN QoS（优先级、保护带宽、延迟、截止时间）、不同传输机制（以太网、UDP、AMQP、MQTT）和连接的监控。

第83部分-离线工程

在离线工程方面，如图9所示，FX包含一个离线描述符来描述配置自动化组件的能力、功能、资产以及有关自动化系统必要的开发、调试和维护阶段的信息。

该开放封装文档使用ECMA-376（即openXML格式）进行建模和附件封装、内部和外部关系以及数字签名。信息模型描述采用Automation ML规范，这是一种基于XML的车间工程数据交换格式，也是IEC62714的标准。工程附件包括其他信息模型的集成，例如PLCopen、YANG、文档、手册和图纸。

也就是说，这些是离线项目中自动化组件的相关信息、描述、图纸、文档等的统一规范。

应用场景分析

OPC UA FX，或者以前称为OPC UA over TSN，长期以来，很多人其实都好奇它的应用场景。事实上，如果您认为TSN 没有用，那么很可能：

(1).数字化还没有达到更深入的阶段。

后来我发现为什么人们不使用OPC UA over TSN是因为很多应用可以在OPC UA +以太网的任务级别解决。比如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网络是一个智能化程度要求很高的网络配置系统，而且必须是人性化的。这是一个难题。有必要将复杂的网络问题转化为与应用无关、与制造商无关的问题。配置本身需要特殊的标准，而IEEE/IEC6082的工作流程也让这项工作显得有些缓慢。近年来，疫情也让大家的工作变得不太稳定和有序。

在图9中，可以看到TSN首先采集现场数据，包括I/O、视觉、运动控制轴（目前C2D刚刚起步），然后传输到边缘控制器层，如贝加莱，通过基于TSN 的OPC UA。虚拟机管理程序工业PC 可以用作处理和分析单元。在该架构中，处理分析单元主要运行AI、调度、优化程序，然后解析出需要进行的调整，通过TSN网络下发给现场设备。对于长期模型训练，OPC UA还提供了到云端的连接规范（稍后可以单独共享）。

在OPC UA over TSN的应用架构中，首先是集成架构实现，然后是高速动态质量分析，快速动态调整执行行为，形成控制、边缘分析和执行的大闭环。这个闭环主要集中在整体质量的优化和提升方面。

关于标准的问题

我也阅读了大量的IEEE/IEC关于各种标准制定的文档。我观察到，这些标准的制定实际上是一个非常严格的工程过程。图10是根据我参与一些标准工作的经验，并与OPC和IEEE的标准工作进行比较。

首先，标准的制定参考了IEEE802.1Q系列的TSN标准和OPC基金会的标准。可见，标准的制定完全是基于工程开发过程。首先我们需要分析需求，设定目标，然后将其分解为各种场景，因为即使是行业也分为离散、流程、批处理等，然后分析各种业务场景以及解决这些问题的机制分为硬件、软件、网络拓扑、配置工具和方法等。因此，制定这个标准的过程本身就是一个非常严格的工程开发过程。

因为，由于工程思维的训练和技术研发水平的限制，感觉很多时候我们在制定标准的时候，会陷入解析单词和句子，因为很多都是遵循标准的。自行制定的标准往往是模仿的，但并不是根据需求的工程过程来实施的。它们在形式上看起来像标准，但缺乏指导性和实施的可行性。

关于协作问题，标准制定还需要更好的协作工作机制，这需要较强的研发项目管理能力。在专家方面，最好有一线工程技术人员参与。另外，在制定这些标准的过程中，行业标准应该得到多方的协调，包括各自的角色：

（1）终端厂商：对于目前大部分智能制造和工业通信标准来说，终端用户就是用户。因此，他们需要从需求方提出意见。许多国内标准缺乏最终用户的声音。如果只有自己行业的人来制定标准，那就难免有点闭门造车的感觉。

（2）设备企业：设备作为系统实施者或技术载体，需要对自身实施有更明确的要求。

（3）。技术提供商，如自动化、系统、软件厂商作为技术提供者，应根据需求分析模块，进行分布式开发。提出规范、标准的实施方法。

（4）。标准专家：根据标准标准，规范整个标准制定过程的程序、定义、边界、书写、引用等。

参与的企业必须具有广泛的代表性，专家的身份也需要来自技术和工程管理，众多的利益相关者必须深度参与。