1.简介
工业4.0和工业物联网（IIoT）原则正在指导生产力、质量、效率和安全，同时也在提高开放性和竞争力[1,2]. 结构、方法、目标和约束旨在实现改进，随着系统能够相互通信和理解，结果可能几乎是立竿见影的[三,4]，或可能在收集数据、确定依赖关系和模式、定义和测试配方以及对功能系统作出反应之后[5,6]. 所有改进都依赖于接口，一项主要的支持技术是开放平台通信统一体系结构（OPC UA）协议[7,8]. OPC UA最初是在SCADA软件环境中的监控和数据采集（SCADA）级别和OPC UA-集中服务器上实现的，但趋势是利用协议的优势，并在其他级别上使用它。这项技术是在PLC级别使用Client-Server概念进入的，公司慢慢扩展其功能，以尽可能多地包含特性和服务。为扩展和改进OPC UA能力，满足特定行业和层级不断增长的需求，开展了研究。进行了研究，试图降低现场设备的应用水平[9,10]. 此外，研究正在使用OPC UA解决云集成问题[11]. 针对学术界和工业界所关注的OPC UA问题，与实时、更高数据量和占地面积相关的第一个回应是一套OPC UA14规范[12]，这依赖于发布订阅机制。在工作中[13]作者在研究过程中评估了OPC UA发布订阅在工厂自动化中的适用性[14]正在open62541 SDK中设置应用前景[15]保持和发展。尽管研究界已经做出了努力，但需要澄清与OPC UA发布订阅机制有关的问题，尤其是与实时上下文以及不同工业场景的架构适用性和改进有关的问题。由于事情还远未解决，因此开始进行研究，以加快开发速度，满足针对MQTT等较低级别协议的需求（例如，OPC UA-MQTT网关[16]，或在中组合火花塞B和MQTT[17]). 使用发布-订阅范例的通信协议广泛用于具有实时要求的应用程序中。即使不同行业的用例可能不同，除了不同的设计、范式的特定实现以及用于实现机制的不同协议和标准之外，近年来，在确保实时应用程序的高性能方面，也有一些被证明是决定性的常用实践。由于OPC UA的发布-订阅概念仍处于相对较新的定义阶段，预计在不久的将来会有改进和变化，这些变化应该具有在遗留应用程序和多个行业的场景中观察到的基本原则。作者将参考当前工作中的OPC UA发布订阅机制，仅用于描述特定于[12]. 在汽车中实现发布订阅机制的通信协议之一是IP上面向服务的可扩展中间件（SOME/IP）。汽车开放系统体系结构（AUTOSAR）标准描述了有关汽车应用的SOME/IP协议的某些要求。在[18]，发布服务器和订阅服务器之间的通知过程是通过定义负责通知订阅服务器有关更改值或特定事件发生的机制来提及的，还允许订阅服务器请求更改值或事件，或通过指定的方法验证变量和事件的状态，从而从体系结构的角度实现多种策略。该标准在用于传输更改值的SOME/IP实例和负责订阅和发布过程的SOME/IP服务发现之间划分责任。通知过程根据不同场景的可能策略进行描述，包括为订阅服务器执行循环通知、更改通知和条件通知的可能性，为实现具有特定发布订阅功能的应用程序提供了通用路径。SOME/IP通知消息还需要具有某些特殊性，值得一提的是发送序列化负载的长度，这些数据可能被证明对端到端验证和过滤有用。在协议级别，除了使用UDP之外，SOME/IP协议还使用TCP处理网络拥塞，信息丢失、位错误和传输过程中可能发生的其他故障。OPC UA的发布订阅侧重于订阅方不断轮询网络中的消息，然后过滤接收到的消息，以确定是否提供了所需的信息。与SOME/IP中使用的设计类似，OPC UA通过专用的通知服务或模块，可以扩展发布订阅概念的模块化。此外，它可以确保出版商和订阅者作为实体，以及系统中存在的职责（谁发送信息，谁通知感兴趣的实体，谁负责安全，谁管理系统的时基，谁接收信息）之间的完全脱钩。一组专用服务或模块，可以用作单独的实体或当前定义实体（发布者、代理、订阅者）的一部分是确保高质量服务所必需的，并且可以代表开发大规模应用程序和具有高交互能力的健壮体系结构所必需的工具。发送点和接收点之间的中间件必须以抽象的方式确保一个场景可能需要的所有机制，使所有用户都可以根据自己的需求访问体系结构的可扩展性。在使用传输协议的情况下，OPC UA在未来尽可能减少实时应用程序的容错性的情况下使用UDP可能不够。可观察的路径是UDP和TCP在传输层的结合，用于实现发布订阅范例的最高级别通信协议。 除汽车领域外，发布订阅机制的实现还可以在具有实时约束的应用程序中找到，这些应用程序在连接性、可扩展性和高性能方面具有类似的目标。数据分发服务（DDS）广泛应用于航空、医疗行业、电力行业等各个领域（例如[19,20]). DDS以实时控制目标为开发目标，提供低延迟、高效过滤的实时容错交换，确保高模块化，发布订阅实体的解耦设计和基于时间的操作可能性，允许实施多种同步策略，提高了广泛应用程序的健壮性和可扩展性。DDS和时间敏感网络（TSN）技术之间的相互作用将在2020年第4季度以标准化的方式定义，以增加时间决定的可能性。DDS应用的一些实践被广泛使用，可能对OPC UA针对网络实时能力的最新概念有用。预计不久的将来，OPC UA.也会采用TSN技术作为标准化选项。然而，在达到这一点之前，发布订阅机制的设计原则可能需要修改。应优先实施能够巩固TSN和OPC UA之间绑定的特定服务，以丰富当前的发布订阅概念，并在IIoT的背景下扩展OPC UA-标准的功能。此场景的关键策略是观察多个行业之间问题的需求和解决方案，并在所有可能的领域建立提高服务质量（QoS）的目标。 当前工作的目标是：
- -
考虑到汽车行业的发展现状和一些基础良好的接口策略，使用发布订阅范式，就实体之间的实时约束和角色分配，对OPC UA接口进行分析；
- -
设想并实现一个关于OPC UA发布订阅UDP机制的解决方案，重点是同步算法和实现实时反应和更高效率的多线程代理应用程序，以扩展QoS和接口的适用性。该解决方案预计将减少松散耦合的订阅者和发布者的数量，降低以高速向不同订阅者发送大量数据的难度，降低网络和服务在轮询和过滤方面的费用。必须以可用性和安全性为指导，因此，解决方案必须处理故障的发生，重点是故障检测、容错和恢复。
第二章介绍了OPC UA发布订阅机制的分析，重点是实时约束，以及有关拟议架构和方法的概念方法。第三章通过一个案例详细介绍了所提出的解决方案，包括同步机制的算法，分别描述和分析了实现和测试后获得的结果。最后一章讨论了研究中遇到的挑战和一些直接的适用性背景。
2.材料和方法
本章侧重于对OPC UA发布订阅概念的深入分析，重点是设计、实时要求和对当前方法的可能影响。对不同领域特定的不同通信协议上的当前机制和类似实现进行了检查，目的是为IIoT环境中可能出现的未来场景确定可能的改进方法。最后一部分介绍了同步算法，如中所述第3节，以及对该方法的必要性和目标的简短描述。对于当前工作的开发，来自[15]已使用。 2.1. 发布订阅机制：设计与架构
发布订阅机制是一种依赖于两个或多个实体之间有效交换信息的模式，其基本原则是发布者将不断发布信息或事件，并且当值发生更改或事件发生时，将通知订阅者。发布服务器和订阅服务器的角色以及除了发送和接收数据之外的所有中间操作都可以，建议在系统中的多个实体（节点）之间分布。服务器和发布服务器角色以及客户端和订阅服务器角色之间的经典关联必须被忽略，重点必须放在发布什么信息上，允许更多实体发布相同的信息（例如，服务器和备份服务器，或在服务器之间拆分主题）。另一个重点应该是订阅者在预期时间间隔内接收信息。从更抽象的角度来看，相关实体之间的联系不如信息与目标之间的联系重要。该系统应在考虑较少信息的情况下运行（例如，出版商的订阅者数量），所有相关实体应分散角色，以利于信息的有效分发。在[21]提出了中间机构的概念，在系统中不存在任何对象间知识。该机制应该接管一些可以在没有上下文的情况下执行的角色，这些角色与有效负载的含义无关，而是充当发布者实体和订阅者实体之间的中间件，可以为大型系统提供显著优势。作者提到的一个优点是，负责信息传输和接收的实体可以只关注这些主题，保持其计算能力的低使用率（这可能会转化为一些节点的廉价硬件）并提供较少的网络使用（这可以转化为网络内参与者之间更好的响应能力）。消息将以更可预测的方式分发，提供有关相关发布者和订阅者之间关系的抽象视图。 在[21]基于信息的内容，讨论了复杂系统中关于敏感操作的集中化问题。除了提到不同的事件类型和子类型以更好地操作订阅者之外，在基于系统的单个节点封装许多依赖项的系统中，单个事件服务器也存在缺点。作为发布者和事件服务器的实体，可以使其他发布者和订阅者脱钩，因此在任何大型系统中都应将其视为高风险。例如，在OPC UA的情况下，如果一个工厂只实现了一个发布服务器来与云体系结构进行接口，那么如果服务器崩溃，并且没有为另一个服务器指定备份责任，那么该工厂可能会遭受巨大损失。如果没有实施安全机制来避免系统中的任何关键影响，那么如果服务器包含有关其他实体绑定的信息（发布者和订阅者之间的关系），则可能会丢失重要数据，并且可能会遇到未知的停机时间，还可能会出现总系统故障。为了在系统中具有分布式职责，指定的中间件实体必须存在，并负责在需要时通知订阅者，同时还充当发布者和订阅者之间的链接实体。还必须实施安全措施，以便在发布者和活动服务器发生故障时进行监控和反应。只有这样，才能保证出版商概念和订户概念之间的独立性。 在[12]发布者和订阅者的角色被描述为松散耦合，不影响现有订阅者数量和发布者实体之间的信息交换。它们之间的主要关系是对所涉及的特定数据集和消息发布细节的共同理解。面向消息的中间件在UDP消息中描述为与多播地址的连接，在MQTT或AMQP消息中则描述为代理。在传输级使用UDP的情况下，发布者将向多播地址发送信息。如果信息很复杂，并且在不同的时间段针对不同的订阅者，而没有明确定义通知角色，订阅者将侦听来自中间件的任何消息（多播地址），并将基于DataSetMetaData过滤信息，该数据也必须在过滤网络消息之前由同一发布者传输给每个订阅者。文件[12]将DataSetMetaData作为订阅服务器端用于筛选接收到的网络消息的信息，并描述了从发布服务器获取元数据的选项。所描述的方法之一是在更改DataSetMessages的内容之前将DataSetMetaData作为网络消息发送。在一个发布者对多个订阅者的情况下，此策略可能会增加系统的复杂性，并可能在发布和接收消息之间的时间限制方面造成困难。如果将安全加密添加到上下文中，则称为安全密钥服务器的新实体将负责管理已经涉及的实体所需的安全密钥。在一个有许多与发布者相关的订阅者的大型健壮系统中，假设每个订阅者都正确接收到加密密钥，并且他们监听传输的所有消息，解密可能是解码消息时的第一个过滤器。执行此步骤和其他筛选操作，直到订阅者识别出消息是否为预期消息，可能会不断产生计算工作量，而不会立即为所有订阅者带来任何好处。这一因素将有助于实现实时要求，而且在发布者以动态方式传输多条消息的情况下（假设DataSetMetaData也必须不断发送），并由未知数量的订阅者进行解密、筛选和提取。网络本身可能无法在特定时间间隔内管理多个交换。在发布者和订阅者之间的中间实体的上下文中讨论的中间件应该保存有关发布者和订阅者之间关系的信息，在这种情况下，如果需要，还可以接管DataSetMetaData的分发（请参阅图1). 应针对这种情况实施安全措施，并且包含出版商和订阅者之间关系的实体应不断根据该信息验证隐含实体的能力。在理想的模型中，发布服务器和订阅服务器彼此解耦，重点应该放在发送和接收信息上。但是，特别是对于实时系统，应该仔细考虑有关传递时间、解密时间和过滤时间的安全机制和保证，如果没有系统节点中不断存储的所有隐含实体之间的关系，就无法实现这些安全机制和保障。OPC UA Pub-Sub机制中存在这样一个实体的可能性可以通过PubSub目录的未来实施来体现。
中建议的另一种策略[21]详细描述了事件服务的概念，即发布服务器和订阅服务器之间的关系所在的位置，并描述了发布服务器共享特定信息或事件类型并从事件服务接收有关感兴趣的订阅服务器的信息的场景。通过这种方式，发布者可以直接将事件通知订阅者，但是，这种方法不如在发布者和订阅者之间有一个中介实体那么有效，并且通过应用此策略，发布者和订阅者不再解耦。正如作者所提到的，在讨论一个健壮高效的系统架构时，应该考虑多对多的方法，其中发布订阅机制的原则旨在正确实现。 在OPC UA中，用户端网络消息的过滤过程从消息的接收点开始创建许多步骤，直到可以访问有效载荷的内容。这些操作可能意味着超出必要的计算工作量，并可能导致延迟，从而难以实现实时要求。在发布服务器和订阅服务器之间的某个级别实现服务，可以部分过滤消息，这有助于订阅服务器不必处理发布服务器的身份。订阅者可以专注于其目标信息的类型，并可能提供一定的安全性，以防在出版商和订阅者实体完全独立的情况下可能出现的人为攻击。
在中间件由OPC UA中的代理表示的情况下，关于发布者和订阅者解耦的系统设计方法更接近原则，但在这种情况下，发布者和订阅者之间的实体并没有在OSI模型的同一层上链接应用程序。发布者确实将连接到代理，并将与信息接收者分离，信息将由代理接收和存储，但根据发布者使用的传输协议，代理将表示为MQTT或AMQP接收实体，因此是用于OPC UA发布者应用的较低层接收器。由于消息采用这种形式（MQTT/AMQP格式），代理的订阅者将由其他MQTT/AMQP应用程序表示，这些应用程序将读取所需的信息，而无需与OSI模型上传输层（实现OPC UA的地方）之上的层交互。因此，发布/订阅机制没有完全实现，而是发布者和接收实体（代理）之间的交换，接收实体提取信息并与MQTT/AMQP接收方的其他应用程序共享信息。这种设计的用途是与云架构和不同理解OPC UA信息传输方式的实体进行交互，在这种情况下，实时要求可能很难实现。可以保证在特定时间间隔内传输或检测消息丢失的安全功能和服务，在这种类型的设计中实现起来可能会更加复杂。从安全角度来看，如中所述，拥有了解OPC UA的发布者和仅作为MQTT/AMQP接收器的订阅者[12]，将实现所有实体（发布者、代理、订阅者）之间的传输安全。然而，发布服务器和订阅服务器之间、传输层之上以及特定于OPC UA的端到端安全是不可能的。在控制器与人机接口（HMI）进行通信并且需要对实体进行解耦的典型情况下，使用基于代理（MQTT/AMQP）的中间件的设计可能会在确保传输在固定的时间周期内完成时产生困难。即使该设计适用于具有低成本和低复杂性软件的设备之间的多对多交换，但服务质量的保证可能会比应有的更加困难。 在[22]发布/订阅机制在带有中间件（ROS中间件）的设计中进行了描述，发布者不应知道订阅者的身份或号码。每一个这样的细节都将由中间件管理，提供发布服务器和订阅服务器的抽象视图。这将允许在需要时实时更换发布者和订阅者。通过这种设计，中间件被真正实现为发布者和订阅者应用程序之间相同级别的链接，对所使用的技术有着完全相同的理解。该实现不同于OPC UA代理中间件设计（特定于MQTT/AMQP传输），在这种设计中，端点应用程序可能对OPC UA-软件有不同的理解。 在汽车领域，对于SOME/IP协议，发布-订阅模式负责隐含实体之间的事件交换。订阅者不直接订阅特定事件，而是订阅事件组，类似于在OPC UA的情况下订阅发布的数据集，但是，订阅是通过SOME/IP服务发现完成的。服务发现的主要职责是向任何参与者传输服务的可用性，并控制任何事件消息的发送顺序。实现此服务后，订阅服务器可以只接收所需的消息。发现方法也用于实现发布/订阅机制的其他协议。例如，DDS使用的是发现系统中的主题，而不是依赖于应用程序，将重点放在查找数据上，而是接收数据，从而改进了系统的解耦设计，并增加了实现安全机制以检测丢失消息的可能性。
2.2. OPC UA和TSN技术背景下的时间同步
在TSN和OPC UA发布订阅机制的背景下，工业物联网的重点正迅速转向实时功能，从网络级一直到应用级。OPC UA发布-订阅的目标是下一步为大规模应用程序提供解决方案，这些应用程序可以实时交换信息，并且可以很容易地集成到现有架构中。TSN技术代表了数据链路层的解决方案，使用一系列标准为信息交换中的所有参与者同步时钟和定义时间参考，在网络内传递消息时提供时间准确性。随着这两种技术的逐步发展，以满足实时要求为目标，在汽车、航空、，军事和其他不同行业。必须强调实现实时需求的方式，以及这对其他主题（如安全性、安全性、服务质量、可扩展性和成本）的影响。在需求和解决方案方面与自动化世界的当前背景进行比较，应该不断改进技术的发展，更好地理解在即将到来的、广泛连接的IIOT世界中必须克服的障碍。
汽车领域一直在开发具有不同复杂性的实时应用程序，这些应用程序在汽车内部的不同级别进行交互。AUTOSAR标准提供了定义时间管理和同步要求的特定模块。所述模块之一由时间同步模块表示。作为经典平台和自适应平台的一部分，时间同步实现控制用于不同节点之间同步的时基，它可以描述为时间协议的封装，使得在不同电子控制单元（ECU）上运行的进程之间的协调成为可能通过建立对时间的共同理解。时间同步的自适应版本由单个模块（SWS TimeSync）表示，还包括同步提供程序（TSP），经典平台的同步提供程序分为3个模块，每个模块都是特定于协议的。考虑到OPC UA应用程序的实时行为目标，从时间同步开始分析AUTOSAR标准中用于实现实时行为的一些要求，并分析这些要求对不同模块和技术的影响是有意义的。
根据[23]同步状态应该可以通过接口来监视和检测组件，这些组件的行为可能会受到接收信息中可能出现的去同步的影响。另一个要求是指对应用程序中涉及的所有实体中的时间有一个共同的理解，必须在所有软件组件和ECU之间实现通过以太网共享该时基的可能性和基于确定的时基的同步，以确保从多个源进行准确的传感器数据处理。在OPC UA实现硬实时同步的情况下，有必要使用特定于数据链路层的TSN技术。TSN实施的其中一项标准与将相关参与者与一个大师钟同步有关，如[24]. TSN实现应保证网络消息之间的一些时间传递，并应在实时上下文中集成OPC UA的发布订阅机制，以控制器到控制器的交换为目标。然而，目前很难预测使用发布订阅机制的当前规范，TSN技术的采用是否足以满足具有实时要求的OPC UA大规模应用。监控隐含实体之间的同步，在本例中是OPC UA发布者和订阅者之间的同步是另一个重要主题。记住，在大规模基础架构中，有多个应用程序需要不同的同步要求，而没有允许监视所涉及的每个组件的专用接口，时基的管理和实时应用程序之间的交互在某种程度上会变得势不可挡。用于时间管理和安全措施的专用服务可以保护用户免受操作失步的影响，可以提高任何通信协议的普及性和可扩展性。这可以代表实时应用程序的解决方案，特别是在IIoT环境中，不仅需要组件之间的交互，还需要现有架构之间的交互。 中提出的其他重要要求[23]提到了操作在经过时间段时的通知，这些操作希望接收特定时间周期的信息，以避免等待状态。为了避免不必要的轮询和网络同步，文件中给出了已过预定时间段的通知。OPC UA与此类需求的相似之处由可为OPC UA-发布者预定义的发布时间间隔表示。然而，为了避免在网络上进行不必要的轮询，当前的发布订阅机制似乎没有与专用服务交换或共享发布时间间隔，因此，在发布服务器传输UDP消息的情况下，订阅服务器正在轮询网络。通过将责任分散给其他实体（例如，通知服务，在必要时通知订阅者，允许订阅者只专注于接收信息），可以提高订阅者应用程序的效率并减少此类操作所需的计算工作量的未来服务，可以制定精确的目标，比如防止不必要的投票。在不再需要进一步等待下一个时间周期并且可以立即进行操作的情况下，会提到时间触发传输，在某些情况下可以提高效率，并且如果使用触发传输，也可以重新同步。在OPC UA的情况下，传输也可以在特定时刻触发，但触发时刻取决于基于硬件功能或操作系统功能的应用程序。考虑到TSN可以提供的时间保证，必须在特定于TSN的数据链路层和OPC UA层之间明确定义时间参考，以确保首先基于相同的时基同步实体本身（发布者或订阅者）内部的操作（参见图2). 对于AUTOSAR标准（以及文件中所述），访问时基的方式必须与提供有关失步、时间偏差、延迟和其他有用细节的接口共存，这些信息可使应用程序在实际场景中受益。在任何具有严格时间限制的用例中，定义的时间引用必须是可访问的。关于时间概念的任何细节，即使是在以太网硬件时钟或操作系统特定计时器的情况下，都可以在内部同步过程中使用，也可以与其他实体一起使用。因此，绑定具有时间确定性的技术的机制必须优选地以标准化的方式存在。 当前的OPC UA时间决定依赖于发布订阅概念，TSN可以提供增强的能力来实现实时需求。然而，对时间的感知，在参与网络信息交换的实体内部，以及在外部通过不同的同步手段和策略，必须进一步开发，通过定义良好的服务和中间件解决方案实现标准化，正如在其他实时确定性和共享类似目标的技术中观察到的那样。在改善每一个包含基于时间的操作的概念中的QoS的情况下，时间本身的概念应该存在于OSI模型的更高级别（OPC UA层）。管理和共享对时基的访问的服务和指定模块必须按照提高应用程序性能和可能性的未来步骤进行开发，这些模块可能会考虑到与同时提供实时功能的TSN技术的交互。从发布时间间隔，到使用时基进行操作的回调函数，必须确保时间概念的一致性。指定的模块和服务，以及采用其他有用的标准和技术来保证时间同步和延迟，代表着OPC UA标准更接近于克服IIoT和工业4.0背景下的挑战的下一步。
为了在具有不同时基的应用程序之间实现实时响应，需要进行同步。对于中的详细案例研究第3节在代理应用程序以预定的时间间隔传输信息的情况下，目标是通过能够找到正确的时间来读取网络消息，从而使订阅服务器与代理同步。针对这种情况开发了一种同步算法，并在第3节以及其他必要的操作，以便在任何时候都只为每个订阅者标识所需的消息，并尽可能避免网络轮询。 3.案例研究和结果
必须针对行业中存在的不同场景，不断分析实时需求背景下的OPC UA发布订阅机制。随着IIoT的快速发展，以及不同兴趣点之间信息交换过程中涉及的技术堆栈的不断演变和扩展，对任何解决方案的不断观察，以及对多个领域特定的不同需求和挑战的各种比较，可以为大规模应用程序的未来开发和任何用例中最佳解决方案的确定带来显著的改进。
作者建议在以UDP为传输协议的OPC UA发布订阅范式的背景下分析多线程代理应用程序，重点关注实时约束和相关实体之间的角色分配。
3.1. 建筑
代理应用程序的目的是以有效的方式与发布服务器和订阅服务器交互，使实现与规范保持一致[12]. 有了更多的实体，方法是让每个实体在单独的设备上运行，使用基于Linux的操作系统，如中所示图3. 3.2. 案例研究
对于快速高效的传输、低计算工作量和低资源使用、角色分配和涉及实体的同步，发布服务器和订阅服务器之间的应用程序可以代表一个可行的解决方案，特别是对于具有实时约束的用例。案例研究中涉及的每个实体都有特定的目标，并且在实现上述所有方面具有不同的特殊性。
3.2.1、。OPC UA发布者
出版商实体负责在不了解信息最终接收者和消费者的情况下交付数据。如中所示[24]，当前的实现在实现OPC UA发布订阅配置组件方面遵循相同的顺序。发布服务器首先必须正确配置，并使用UA_Server_addPubSubConnection方法初始化发布订阅连接。在这种情况下，发布服务器的目标是将信息传输到单个实体Broker App，因此该应用程序还将初始化并配置一个连接，以便仅从发布服务器接收数据。第二步是创建WritterGroup（请参见[12,24])组件，包含负责创建网络消息的参数，其中一个参数在考虑实时约束时非常重要，即发布UA_WriterGroupConfig数据类型的Interval部分。针对与代理应用程序的订阅者部分的一对一通信，可以以更抽象的方式组装预期的传输数据，从而保持实现的简单性。在本例中，使用Broker应用程序的目的之一是通过在配置组件方面使Publisher应用程序更抽象来表示。只有必要的组件将配置为基本配置，并在指定的协议特定结构中进行数据封装。有效载荷由十六进制数字（例如0xDC）表示，不知道数据将如何在订阅者之间分割，也不知道将有多少目标接收器。作为一个假设示例，数字的每2位可能表示传感器收集的值，出版商正在收集这些数据的现场设备上运行。数字将由DataSetMessage表示（请参阅[12,24])仅使用一个DataSetMessage字段，使有效负载的结构尽可能简单。发布时间间隔仅根据发布者实体的需要进行相应设置，但是，根据目标场景，时间间隔应设置为接近数据使用者的需要。发布程序开发的最后一个细节是与代理应用程序的连接。发布者希望仅与代理共享信息，因此无需为连接使用多播地址，包含代理应用程序的设备的Ip和可用端口足以连接和发布数据。 3.2.2. Broker应用程序
在使用代理应用程序的设计中，寻求提高发布订阅机制的效率。除了将有用信息过滤和路由到每个订阅者之外，还可以通过获取相关实体之间的同步来提高效率。目前的实施遵循上述所有方面，旨在以接近行业需求的方式实现每个目标。
Broker应用程序由2个不同的组件组成，每个组件具有不同的角色。主要作用是从OPC UA发布服务器接收数据，并在所需的时间间隔（向每个用户）进一步发布提取的数据。Broker的主要目标是接管发布-订阅设计中涉及的一些角色，通过根据每个订阅的需求设置发布间隔来实现实时需求，并在信息交换的这个特定点执行大部分过滤。必须管理2个具有不同时间限制的不同操作（进一步接收和传输数据），以及其他特定任务，因此选择了多线程方法以获得更好的性能和代理应用程序进程之间的同步。尽管[15]SDK不提供多线程，必须管理完全不同的操作，这使得该方法在当前情况下成为可能。代理应用程序的高级架构分为两个组件，每个组件运行在不同的线程上（请参阅图4). 应用程序背后的概念是在对定时详细信息、目标信息和唯一ID以及用户端应提供的特征进行一些假设的情况下制定的。broker应用程序的未来迭代可能会实现第三个组件，该组件负责broker和感兴趣的订阅者之间首次交换此类详细信息，通过使用经典服务器客户端范式的一次性传输，通过基于运行时Json配置文件的配置步骤，或者通过定期与包含消费者实体的此类详细信息的专用服务器通信。上述详细信息（计时详细信息、目标信息和唯一ID）在当前用例的代理应用程序的当前版本中进行了硬编码。
第一个线程专用于订阅服务器组件。该组件负责从发布服务器接收信息，还将根据每个订阅者的首选项，在特定目标变量中执行所需数据的提取。执行Broker应用程序的第一步是在单播地址（一对一通信）上与主OPC UA发布服务器初始化PubSubConnection。初始化连接后，组件开始在网络上侦听感兴趣的消息。Subscribe进程的实现是以一种经典的方式完成的，即以尽可能少的重复次数查询通过网络的所有内容，以确保没有丢失任何重要的DataSetMessages，并通过浏览所有DatSetMessages字段和筛选数据类型。
第二个线程专用于Publish组件。根据订阅者的数量以及订阅者期望接收数据的时间间隔，组件正在初始化一个OPC UA发布者实例，该实例具有多个WritterGroups，每个WritterGroup根据所有订阅者需求具有不同的发布时间间隔。数据在提取后存储，然后再传输给订阅者，以便在需要时访问历史数据（数据缓冲是可用性方面的一个基本功能）。在将信息分配给数据集之前，需要使用特定的唯一ID进行编码操作，特别是针对每个订阅者。在研究案例中，ID被定义为十六进制数（0xF表示订阅方1的感兴趣数据，0xA表示订阅方2的感兴趣的数据）。编码功能用4位移位提取的信息，并在移位后获得的数字的前4个低有效位上分配ID。因此，如OPC UA Publisher部分所述，用户的有效载荷为0xDC，即：
- -
xCF表示订阅方1，其中0xC是订阅方1的所需数据，0xF表示ID，
- -
订阅方2的xDA，其中0xD是订阅方2所需的数据，0xA是ID。
编码完成后，新的有效负载被封装在DataSetMessages中，并由其中一个WritterGroups以不同的时间间隔发布。传输在多播地址上进行，以便用户之间进行公共访问（一对多通信），从而[12]. 3.2.3. OPC UA用户
对于当前的研究案例，开发了2个用户实体作为OPC UA Publisher提供的初始有效载荷的消费者，每个实体在目标数据和实时行为方面具有不同的期望。对于当前用例的示例，订阅者期望信息的时间间隔是订阅者1的1s和订阅者2的3s。该概念经过测试，功能也在10毫秒以下（在3毫秒时，行为与目标时间间隔的情况类似）。
每个订阅者的实现都类似，第一步是在两个应用程序中初始化PubSubConnection，并在多播地址上建立与Broker App的通信。由于知道代理只发送感兴趣的信息，因此避免了针对OPC UA网络消息的任何不必要的过滤操作。还避免了通常用于过滤有效负载内容的浏览操作，每个订阅者都知道代理只会发送特定数据，并且只会在所需的时间发送（在理想情况下）。基于ID的解码功能是为了使订户能够将到达的消息分类为有效和无效，以实现中讨论的同步目的第3.2.4节. 拥有代理应用程序的主要目的是让订阅者避免不断询问网络内容，并使用发布者概念的发布时间间隔，并且通过保证由于同步只接收有用的信息来避免尽可能多的过滤操作。通过实现这些目标，订户应用程序的效率得到了提高，提供了一个优势，特别是当目标场景将订户应用与计算能力和资源较低的现场设备关联时。考虑到实时要求是OPC UA发布订阅概念的一个重要方面，订阅者端的实现遵循了相同的方面，关于接收信息的指令仅以与预期时间相等的时间间隔执行。为了举例说明接收指令调用之间的时间间隔，作者将在本章的下一部分使用术语“延迟”。订户的理想工作状态是延迟等于信息的预期接收时间。然而，某些机制是在退出理想的运行情况（去同步）的情况下开发的。所有这些机制和更多详细信息在中进行了描述第3.2.4节关于为使用代理应用程序进行概念设计而开发的同步算法。 3.2.4. 同步算法
有了代理应用程序，并且订阅者希望在正确的时间得到正确的消息，对于最佳情况，所有配置都是正确的。然而，在某些情况下，仅为代理和订阅服务器正确配置时间细节不足以在没有公共时基且不通过通知机制不断交换时间引用的实体之间实现实时同步。在这些情况下，挑战是以动态方式同步不同的实体，知道传输和接收操作的近似间隔。为了举例说明这个概念，作者将在本章的下一部分使用术语轮询来描述订阅者端与代理应用程序的去同步。作者根据订阅者所在州的两种特定情况定义了“轮询”一词：
只有通过获得所需信息的发送时刻和接收时刻之间的同步，才能避免特定于定义的轮询状态的两种情况。
从代理应用程序的配置到根据ID快速发送指定给不同订阅者的消息（请参阅第3.2.2节)，并在多播地址上具有两个不同的消息传递间隔，从订阅者的抽象角度来看，我们可以根据消息的有效性确定两种不同的场景（订阅者将使用其ID编码的消息分类为有效消息，并将所有其他消息分类，尽管涉及的订阅者数量为无效消息），以及消息的重复出现（为了举例说明，选择的重复出现次数为有效消息为100毫秒，无效消息为1000毫秒，反之亦然）（请参见图5). 在场景1中：如果接收到无效消息或检测到轮询状态，则延迟变为0（因此接收指令将尽快执行），直到发生同步事件（对于算法，同步事件意味着接收到有效消息）。如果发生了同步事件并且收到了有效消息，则延迟将再次成为订阅服务器特定的所需接收时间间隔。从这一点出发，可以保证代理应用程序使用相同的时间间隔发送该消息，因此在下一个周期之前不执行接收操作是安全的，如果消息已经到达，则无需轮询。从现在开始，如果网络稳定，那么订阅服务器应该与代理同步。只有当两个订阅者的传递时间间隔相交时，才可能取消同步，并且代理将一个接一个地快速提供消息，订阅者无法确定首先提供哪一个消息。在这种情况下，将执行接收指令，如果最先到达的消息无效，则延迟再次变为0，并尽快重复该指令，直到检测到有效消息且未丢失。同样，有效消息的出现被转换为同步事件，直到代理传递时间间隔的下一个交叉点，订阅服务器才被同步，即使出现去同步，动态修改延迟的机制也有能力将订阅服务器与代理重新同步。在有效消息之间总是会有所需的重复，从完成第一次同步的那一刻起就避免轮询（提高效率），并考虑到接收无效消息的可能性，并尽快纠正去同步。
在场景2中：如果接收到无效消息或检测到轮询状态，则延迟变为0（因此接收指令将尽快执行），直到发生同步事件（对于算法，同步事件意味着接收到有效消息）。该行为与场景1中的行为相同，不同之处在于，在每个周期中，代理的交付时间间隔之间都会发生交叉时刻，但是，在出现无效消息的情况下动态修改延迟的机制将重新同步代理和订阅服务器。在有效消息之间总是会有所需的重复，从完成第一次同步的那一刻起就避免了轮询（提高效率），并且在每个周期都会进行重新同步操作，而不会产生丢失的消息。
在这两种场景中，实现的同步算法都被证明是有效的，并且对实现的测试也证实了代理应用程序和订阅服务器上存在所需的行为。
此时，可以真正观察到在代理应用程序端编码信息的目的。在采用通用代理解决方案进行OPC UA发布服务器和订阅服务器之间的UDP传输时，所需信息的编码过程对同步过程具有决定性作用。
在代理应用程序因任何原因关闭的情况下，根据同步算法，订阅者将进入轮询状态并执行接收操作，直到发生同步事件（对于算法，同步事件意味着接收有效消息），同步完成后，如果网络稳定，则不应再次达到轮询状态。
3.3. 结果
代理应用程序以及发布者和订阅者实体的实现已经成功实现，这证明了该概念可以发挥作用，并且实现了主要目标，提供了真正的优势。
在实施案例研究时[15]使用的SDK未提供订阅服务器API的最终版本。从作者的角度来看，订阅服务器端接收操作的当前解决方案是符合的[12]. 然而，最终的API仍在开发中，即使作者没有发现任何情况，也有可能在劣质软件层（在用于开发Subscribe概念的软件层之下）存在网络查询或使用缓冲区来存储通过多播地址传递的所有网络消息，这可能与作者使用的SDK的应用层无关。这就是作者定义投票状态的原因，如第3.2.4节在特定于当前SDK解决方案使用的应用程序级别。一个主要目标是避免轮询状态（避免执行比必要更多的指令，没有同步是不可能的），以便订阅服务器只接收重要的消息，这是对当前接收概念描述的改进，如[12]，“订阅者应准备接收他们不理解或不相关的消息。每个NetworkMessage在NetworkMessage标头中提供未加密数据，以支持识别和筛选相关发布者、DataSetMessages、DataSetClasses或其他相关消息内容”，由[15]符合[12]在经典场景中，代理应用程序和同步算法不作为UDP发布订阅概念的一部分存在。 在实施阶段之后，可以从不同的角度观察到该概念的一系列结果：
发布服务器以比通常情况更抽象的方式实现，仅通过单个已发布数据集使用基本配置，为具有不同首选项和预期时间的两个订阅者传输信息。这可以被视为以较少的工作量传输大量数据的优势。
代理应用程序使用多线程，因此速度很快，两个组件独立工作。适用于大规模应用中的高复杂性操作。
代理应用程序存储从一方传递到另一方的大量数据。数据缓冲在OPC UA协议的许多情况下都很有趣。
如果需要，代理应用程序可以发布信息（最后一个可行的存储数据），即使在发布服务器关闭的情况下，也可以作为备份服务器。通过这种方式，所涉及实体的一些角色被其他实体接管（在本例中为发布角色），从而使系统在出现故障时更加准备就绪。此外，可以在代理应用程序上实施安全措施，以通知数据消费者数据源发生故障。
代理应用程序以所需的时间间隔提供数据，并通过使用编码策略和同步算法，通过以稳定的速率（而不是比所需的速度更快）高效地交付数据来确保数据的提供。
订阅服务器与信息源完全分离，而不知道主发布服务器的任何详细信息。这改进了发布者-订阅者机制的概念，如中所述[12]，“发布者和订阅者是松散耦合的。他们通常甚至彼此都不认识。他们的主要关系是对特定类型数据（DataSet）的共享理解，包含这些数据的消息的发布特征，以及面向消息的中间件”。 同步算法允许订阅服务器尽可能避免轮询状态和不同类型的筛选操作。这意味着提高了效率，减少了订阅方实体的主机设备的计算工作量和资源使用。
同步算法确保订阅服务器在正确的时间显示信息，在正常情况下避免轮询状态，并提供重新同步的可能性。这对信息的发布方式（在特定时间点）很重要，因此通过同步代理应用程序和订阅服务器，可以实现实时要求，并且解决方案可以针对控制器对控制器的场景。
当前的实现与中描述的AMQP和MQTT传输协议使用的代理不同[12]在使用代理APP进行设计时，所有相关实体都对OPC UA数据类型有一个共同的理解，传输链中涉及的所有链路都是OPC-UA应用程序。
实现中描述的体系结构图3和图4，所有上述结果都可以在图6,图7,图8和图9，每个图都说明了流程中涉及的实体、发布者、代理、订阅服务器1和订阅服务器2的终端。 4.讨论和结论
以下段落讨论了当前研究的挑战和一些直接适用性背景。
代理应用程序实现阶段的第一个障碍是确定当前设计的优点和缺点，以及如何进一步应用这些优点来改善发布者和订阅者实体的实时反应能力和提高效率。
当前工作的主要挑战之一是确定订阅者端与代理应用程序的同步机制。为了实现这一目标，考虑了许多不同的场景，包括订阅者在任何时刻的不同可能状态，订阅者应该在什么情况下开始减少和增加延迟时间，如何防止消息丢失，即使代理应用程序和订阅服务器不共享相同的时基。另一个巨大的挑战是找到一种快速简单的编码和解码方法，以节省代理应用程序和订阅服务器上的精力和时间，当代理应用程序的发布者组件将发送多条消息时，这可以提供一种明确的方式来区分所需的消息。订阅服务器的目的是尽可能简单，一个只在适当的时候接收和使用相关网络消息的实体，因此要避免基于发布服务器组件的不同子组件的过滤，保持完整的解耦设计，以较少的信息量保持功能不变。
其他挑战取决于为代理应用程序找到合适的体系结构，使其两个组件能够独立高效地工作，并通过尽可能简单的设计实现发布服务器和订阅服务器，维护代理方的所有重要操作。概念的测试很困难，必须为所有实体使用软件的增量版本，每个版本的演变都会影响其他实体的反应。由于涉及多个设备，对每个软件不同版本的特定结果进行测试是一项困难的任务，并且在开发阶段的不同阶段开发了额外的测试代码。
当前的概念方法有各种直接的适用性背景。如果传感器参数控制器暴露收集的传感器数据，或I/O控制器用于从现场设备收集数据，以便与PLC或冗余PLC通信，则所提出的概念将适合并有利于网络边缘的OPC UA发布订阅机制。
在cobot（协作机器人）的情况下，同步和速度是至关重要的，在制造业中，它们必须在协议方面符合工业4.0的要求。根据作者在使用机器人的多家公司的工业经验，制造过程中Cobot集成的挑战是实现接口。通常，在眼镜蛇生产单元内，在速度要求的情况下，遇到的最佳功能开发是消除任何工业接口，并实现基于字符串的简单接口，以便与单元内的本地监控结构通信。旗舰开发[25]对于通用机器人，可以使用当前的概念进行改进。 一般来说，制造业以及其他行业可以通过使用当前的概念而受益。考虑到一个终端汽车制造测试和包装的例子，机器实现了ECU引脚的自动化光学检查[26]在机器人销插入电路板、外壳固定和贴标签之后，以及在运输和包装到箱子中以及对箱子中的计数板进行最终光学检查以发送给客户公司之前。自动光学检查（AOI）结构必须在几秒钟内完成整个图像处理，并且必须与固定外壳、旋转结构并发送ECU进行打包或零件处理的同一台机器上的PLC进行通信。第一种观点是，光学检测解决方案必须将数据发送到机器上的PLC、上游和下游机器、制造执行系统（MES），以确保相关流程的正确、协调、同步、安全运行。提出的解决方案将大大有助于实现完全自动化的终端制造和测试，并将减少MES对整个流程功能的影响。 代理应用程序的实现以及同步算法显示了OPC UA协议在实时要求的使用中的能力，并提供了增强OPC UA-发布订阅机制的方法，以提高参与该协议的所有实体的效率和实时响应信息交换过程，扩大了IIoT背景下应用程序的开发可能性领域。
