OPC_OPC UA规范_概述与概念

OPC UA概述

1 UA应用域

OPC UA是广泛适用于工业领域（industrial domains）的组件，例如工业传感器和致动器（actuator）、控制系统、制造执行系统和企业信息化系统，包括IIoT（Industrial Internet of Things，工业物联网）、机器对机器通信（Machine to machine，M2M），以及工业4.0和中国制造2025。这些系统旨在交换信息，并对工业过程发送命令和控制。OPC UA定义了一个通用的基础模型，以使这种信息交换更便捷。OPC UA规定了以下内容：

• 表示结构、行为和语义的信息模型（information model）；
• 与应用程序交互的消息模型（message model）；
• 在终端节点（end-points）间传输数据的通信模型（communication model）；
• 确保系统间互操作的一致性模型（conformance model）。

2 一般性

OPC UA是一个平台无关的（platform-independent）标准。
通过该标准，各种类型的系统和设备可以进行通信，通过在客户端和服务器间发送请求和响应消息，或在各种类型网络上的发布者和订阅者之间发送网络消息。它支持稳健、安全的通信，确保OPC UA应用程序的身份并抵御攻击。

在该C/S（Client Server）模型中，OPC UA定义了服务器可能提供的服务集，并且个别服务器指定了到客户端支持的服务集。信息使用OPC UA和供应商定义的数据类型传递，且服务器定义了客户端可以动态发现的对象模型。服务器可以访问当前数据和历史数据，以及警报和事件，以通知客户端发生了重要变更。OPC UA可以映射到各种通信协议上，数据可以以各种方式编码，以在可移植性和效率间进行权衡。

除了C/S模型，OPC UA还为发布者定义了一种机制，使用PubSub模型将信息传递给订阅者。

3 设计目标

OPC UA提供了一个统一的、集成的地址空间（AddressSpace）和服务模型。它允许单个服务器将数据（data）、告警（alarm）和事件（event）以及历史记录（history）集成到它的地址空间，并使用一组集成服务集提供访问。这些服务还包括一个集成的安全模型。

OPC UA还允许服务器为客户端提供从地址空间访问的对象的类型定义。这使得信息模型可以用来描述地址空间的内容。OPC UA允许数据以不同格式暴露/公开，包括二进制结构、XML和JSON文档。数据的格式可由OPC、其它标准组织或供应商定义。通过地址空间，客户端可以向服务器查询元数据（metadata，用以描述数据格式）。许多情况下，未预编程知晓（pre-programmedknowledge）的数据格式的客户端能够在运行时确定格式并正确利用数据。

OPC UA增加了对节点间多种关系的支持，而不局限于单一的层次结构。通过该方式，服务器可以以多种层级的方式呈现数据，以适应一组客户端通常希望查看数据的方式。这种灵活性结合类型定义的支持，使得OPC UA适用于各种问题领域。如下图所示，OPC UA不仅针对SCADA、PLC和DCS的接口，还作为一种方式，提供了更高级功能之间更大的互操作性。

OPC UA目标应用程序

OPC UA旨在提高发布数据的鲁棒性（robustness）。所有OPC服务器的一个重要特性就是能够发布数据和事件通知。OPC UA为客户端提供了快速检测和从传输相关的通信故障中恢复的机制，而不必等待底层协议提供的长超时。

OPC UA旨在支持广泛的服务器，从车间的PLC到企业服务器。这些服务器具有不同的规模、性能、执行平台和功能能力。因此，OPC UA定义了一套全面的功能，且服务器可以实现其中的一部分功能。为了提高互操作性，OPC UA定义了子集，称为配置文件，服务器可以声明符合子集配置文件。然后，客户端可以发现服务器的配置文件，并根据配置文件定制与该服务器的交互。配置文件在OPC 10000-7中定义。

OPC UA规范进行了分层设计，将核心设计与底层计算技术和网络传输隔离。这使得OPC UA可以根据需要映射到未来的技术（核心设计不变，实际技术可以替换），而不会否定基本设计。OPC 10000-6描述了映射和数据编码，定义了三种数据编码：

• XML/text
• UA Binary
• JSON

此外，定义了几种协议：

• OPC UA TCP
• HTTPS
• WebSockets

OPC UA应用程序支持多种传输和编码，允许终端用户（end-users）在部署时决定性能和兼容性之间的权衡，而不是由OPC供应商在产品定义时就确定。

OPC UA是基于微软COM技术的OPC客户端和服务器设计的。在设计OPC UA时，特别考虑到了OPC COM服务器（DA、HDA和A&E）现有的公开数据，可以通过OPC UA轻松映射和公开。供应商可以选择将其产品原生迁移到OPC UA或使用外部包装器将OPC COM转换到OPC UA，反之亦然。前面的每个OPC规范都定义了自己的地址空间模型和服务集。OPC UA将以前的模型统一到单个集成地址空间和一套服务集中。

OPC UA PubSub为OPC UA开辟了新的应用领域。下面是PubSub的一些应用示例：

• 控制器之间以及控制器与HMI之间的可配置对等/端对端通信。这些端点不直接连接，甚至不需要知道彼此存在。数据交换通常需要一个固定的时间窗；它可能是点对点或多点连接的。
• 异步工作流。例如，订单处理程序可以将一个订单放在消息队列或企业服务总线上。然后，它可以由一个或多个workers进行处理。
• 记录到多个系统。例如，传感器或致动器（actuator）可以将日志写入监控系统、HMI、存档程序以供以后查询，等。
• 代表服务或设备的服务器可以将数据流式传输到云端的应用程序。例如，后端服务器、用于系统优化和预测性维护的大数据分析。

PubSub并不绑定到特定的消息系统。相反，它可以映射到不同的系统，下面有两个例子：

• 在频繁传输少量数据的生产环境中，使用UDP的PubSub可能会很适用。它允许在一对一和一对多的配置中进行数据交换。
• 使用建立的消息传输协议（如ISO/IEC MQP 1.0）与JSON数据编码结合，支持云集成路径，并且可以轻松处理现代流式和批处理分析系统中的信息。

4 集成的模型与服务

4.1 安全模型

4.1.1 一般性

OPC UA安全性涉及客户端和服务器的身份验证、用户的身份验证、通信的完整性和机密性以及功能声明的可验证性。该规范并没有指定在各种情况下需要安全机制。这个规范至关重要，但它是由系统的设计者在给定的站点制定，并且可能由其它标准指定。

相反，OPC UA提供了一个安全模型，该模型在OPC 10000-2中进行了描述。
其中，安全措施可以被选择和配置以满足特定安装的安全需求。在某些情况下，交换安全参数的机制被定义了，但应用程序如何使用这些参数未被定义。该框架还定义了所有OPC UA应用程序都支持的一组最小安全配置文件，尽管它们可能不会在所有安装中使用。安全配置文件在OPC 10000-7中进行了定义。

4.1.2 发现和会话建立

应用程序级安全（application level security）依赖于一个安全的通信信道，该通道在应用程序会话期间保持激活，并确保所有交换的消息的完整性。这意味着用户只需要在建立应用会话时进行一次身份验证。发现服务器、建立安全通信通道和应用会话的机制在OPC 10000-4和OPC 10000-6中有描述。有关发现过程的更多信息在OPC 10000-12中描述。

当建立会话时，客户端和服务器应用程序会协商一个安全通信通道。数字（X.509）证书被用于识别客户端和服务器。服务器还会对用户进行进一步的身份验证，并授权后续请求以访问服务器中的对象。

4.1.3 审计

OPC UA包含了对安全审计跟踪的功能，可以在客户端和服务器审计日志之间进行追踪。如果在服务器上检测到安全相关问题，可以定位并检查相关的客户端审计日志项。OPC UA还为服务器提供了生成事件通知的功能，这些通知将可审计的事件报告给能够处理和记录它们的客户机。OPC UA定义了安全审计参数，这些参数能被包含在审计日志项和审计事件通知中。OPC 10000-5定义了这些参数的数据类型。并非所有的服务器和客户端都提供所有的审计功能。OPC 10000-7中的配置文件指明了支持哪些特性。

4.1.4 传输安全

OPC UA安全性对大多数web服务平台所提供的安全基础设施做了补充。

传输级安全性可用于加密和签名消息。加密和签名可以防止信息泄露和保护消息的完整性。加密能力由用于OPC UA应用程序之间交换消息的底层通信技术提供。OPC 10000-7定义了用于给定描述文件的加密和签名算法。

4.2 集成地址空间模型 Integrated AddressSpace model

服务器向客户端提供的对象和相关信息的集合称作地址空间（AddressSpace）。OPC UA地址空间将其内容表示为一组通过引用（reference）连接的节点。

节点的基本特征由OPC定义的属性描述。属性是服务器中具有数据值的唯一元素。定义属性值的数据类型可以是简单类型，也可以是复杂类型。

地址空间中的节点根据其用途和含义进行分类。NodeClasses定义了OPC UA地址空间的元数据。OPC 10000-3定义了OPC UA节点的分类。

基本的NodeClass定义了所有节点的通用属性，允许标识、分类和命名。每个NodeClass都继承了这些属性，且能定义自己的属性。

为了提高客户端和服务器的互操作性，OPC UA地址空间被分层组织，所有服务器的顶层都是相同的。虽然地址空间中的节点通常可以通过层次结构访问，但它们可能互相引用，从而允许地址空间表示节点的相关联的网络。地址空间模型在OPC 10000-3中定义。

服务器可将地址空间划分进视图，以简化客户端访问。子句6.3.4.3更详细地描述了地址空间视图。

4.3 集成对象模型

OPC UA对象模型为在地址空间中表示对象提供了一致的、集成的NodeClass集合。该模型根据对象的变量、事件和方法以及它们与其它对象的关系来表示对象。OPC 10000-3描述了该模型。

OPC UA对象模型允许服务器为对象及其组件提供类型定义。类型定义可以子类化。它们可能是通用的，也可能是特定于系统的。对象类型可以由标准组织、供应商和终端用户定义。

该模型允许将数据、告警和事件及其历史记录集成到单个服务器中。例如，服务器能够将温度变送器表示为一个由温度值、一组报警参数和一组相应的报警限制组成的对象。

4.4 集成服务

客户端与服务器间的接口被定义为一组服务。这些服务被组织进逻辑分组中，称作服务集。在6.4中有详细讨论服务集，并于OPC 10000-4中指定。

OPC UA服务为客户端提供了两种功能。它们允许客户端向服务器发送请求并从服务器接收响应。它们还允许客户端大约服务器的通知。通知被服务器用于报告一些发生的事，如告警、数据值变更、事件和程序执行结果。

为了提高效率，OPC UA消息可以编码为XML文本或二进制格式。它们可以使用多种底层传输方式进行传输，例如TCP或HTTP上的web服务。服务器可以根据OPC 10000-6定义提供不同的编码和传输。

5 会话 Session

OPC UA C/S交互需要一个状态模型。状态信息在应用程序会话中维护。状态信息的示例包括订阅、用户凭据以及跨多个请求的操作的延续点。

会话被定义为客户端和服务器之间的逻辑连接。服务器可以根据资源可用性、许可限制以及其它约束限制并发会话的数量。每个会话都独立于底层通信协议。这些协议的事变不会自动导致会话终止。会话的终止取决于客户端或服务器的请求，或者客户端停止活动。未活动的时间间隔是在会话建立期间协商的。

6 系统概念

6.1 客户端服务器概述 Client Server Overview

OPC UA系统架构模型将客户端和服务器作为交互搭档。每个系统都包含多个客户端和服务器。每个客户端都可以与一个或多个服务器同时交互，每个服务器也可以与一个或多个客户端同时交互（并发交互，interact concurrently）。应用程序可以组合服务器与客户端组件，以允许与其它服务器和客户端交互。

下图展现了一个组合了服务器和客户端的架构。

OPC UA系统架构

6.2 OPC UA客户端

OPC UA客户端架构对C/S交互的客户端端点进行建模。下图说明了一个典型客户端的主要元素以及元素之间的关系。

OPC UA客户端架构

客户端应用程序指的是实现了客户端功能的代码。它使用客户端API向服务器发送和接收OPC UA服务请求和响应。为OPC UA定义的服务在规范条款6.4中描述，并在OPC 10000-4中详细说明。

请注意，客户端API是一个内部接口，它将客户端应用程序代码与OPC UA通信栈隔离开来。OPC UA通信栈将客户端API调用转换为消息，并通过底层通信实体将它们发送到服务器，以响应客户端应用程序的请求。OPC UA通信栈还接收来自底层通信实体的响应和通知消息，并通过客户端API将它们传给客户端应用程序。

6.3 OPC UA服务器

6.3.1 一般性

OPC UA服务器架构对C/S交互的服务器端点进行建模。下图说明了服务器的主要元素以及它们之间的关系。

OPC UA服务器架构

6.3.2 实际对象 Real objects

实际对象是服务器应用程序可以访问或在内部维护的物理或软件对象。例如物理设备和诊断计数器。

6.3.3 服务器应用程序

服务器应用程序是实现服务器功能的代码。它使用服务器API发送消息或接收来自客户端的消息（OPC UA消息）。注意，服务器API是一个内部接口，它将服务器应用程序代码与OPC UA通信栈隔离。

6.3.4 OPC UA AddressSpace

6.3.4.1 AddressSpace节点

AddressSpace被建模为一组节点，由客户端使用OPC UA服务（接口和方法）访问。AddressSpace中的节点用于表示实际对象、对象的定义以及对象间的相互引用。

6.3.4.2 AddressSpace组织

OPC 10000-3包含元模型“构建块”的细节，用于以一致的方式将互连的节点创建成地址空间。服务器可以根据选择在地址空间中自由地组织它们的节点。节点之间引用的使用允许服务器将地址空间组织成层次结构、节点的完整网状网络或可能的混合结构。

OPC 10000-5定义了OPC UA节点和引用以及它们在地址空间中的预期组织。有些概要设计不需要实现所有的UA节点。

6.3.4.3 AddressSpace视图

视图是AddressSpace的子集。视图用于限制服务器对客户端可见的节点，从而限制由客户端提交的服务请求的AddressSpace的大小。默认的视图是整个AddressSpace。服务器可以选择定义其它视图。视图隐藏了AddressSpace中的一些节点和引用。视图通过AddressSpace可见，客户端能够浏览视图以确定其结构。视图通常是分层的，这样客户端更容易在树形菜单栏中将其表示。

6.3.4.4 对信息模型的支持

OPC UA AddressSpace支持信息模型。通过以下方式提供支持：

1. 节点引用允许AddressSpace中的对象相互关联；
2. 对象类型节点为实际对象（类型定义）提供了语义信息；
3. 对象类型节点支持将类型定义子类化；
4. 暴露在AddressSpace中的数据类型定义允许使用特定行业的数据类型；
5. OPC UA伙伴标准允许行业组织定义如何在服务器AddressSpace中表示特定的信息模型。

6.3.5 订阅实体 Subscription entities

6.3.5.1 监视项 MonitoredItems

MonitoredItems是由客户端在服务器中创建的实体，用于监视AddressSpace节点及其现实世界的对应对象。当它们检测到数据变更或事件/告警发生时，它们会生成一个通知，该通知会通过订阅传输到客户端。

6.3.5.2 订阅 Subscriptions

订阅是服务器中向客户端发布通知的端点。客户端通过发送发布消息来控制发布生成的速率。

6.3.6 OPC UA服务接口

6.3.6.1 一般性

为OPC UA定义的服务在条款6.4中定义，且在OPC 10000-4中详细介绍。

6.3.6.2 请求/响应服务

请求/响应服务是客户端通过OPC UA服务接口调用的服务，用于在AddressSpace中的一个或多个节点上执行特定的任务并返回响应。

6.3.6.3 订阅服务

通过OPC UA服务接口调用发布服务，用于定期向客户端发送通知。通知包括事件、警报、数据更改和程序输出。

6.3.7 服务器到服务器的交互 S2S interactions

在C/S模型中，服务器之间的交互（简称S2S）是指一个服务器充当另一个服务器的客户端的交互。S2S允许服务器的开发：

1. 在端到端的基础上互换信息，这可能包括用于维护系统范围类型定义的冗余或远程服务器。
2. 链接在服务器的分层架构中以提供：
   a. 从底层（lower-layer）服务器聚合数据；
   b. 客户端的高层（higher-layer）数据构造
   c. 到客户端的集中器接口用于对多个底层服务器提供单点访问。

服务器间的p2p交互

类似的p2p交互也可以用OPC UA PubSub模型完成，其中每个peer应用程序都是发布者和订阅者。

下图扩展了前面的示例，说明了如何将服务器链接在一起以实现企业中对数据的纵向/垂直访问。

链式服务器示例

6.4 冗余 Redundancy

OPC UA以标准化的方式提供了数据结构和服务，以实现冗余。冗余可用于高可用性、容错性和负载均衡。OPC 10000-4正式定义了客户端、服务器和网络冗余。只有某些OPC 10000-7配置文件需要冗余支持，基本配置文件不需要。

所需的客户端和服务器行为与两种不同的服务器冗余模式相关联，即透明模式和非透明模式。在使用透明或非透明冗余时，客户端和服务器的职责定义在OPC 10000-4中。

支持非透明冗余的服务器也支持客户端控制的负载均衡。服务器的运行状况（包括其服务请求的能力）统称为服务等级（ServiceLevel）。OPC 10000-4定义了四种不同的服务等级子范围和示例用法。

6.5 发布-订阅

使用PubSub，OPC UA应用程序无法直接交换请求和响应。相反，发布者将消息发送给面向消息的中间件，而不知道可能有哪些订阅者。类似地，订阅者表示对特定类型的数据感兴趣，并处理包含该数据的消息，而不知道有哪些发布者。

面向消息的中间件是支持分布式系统之间发送和接收消息的软件或硬件基础设施。该分发的实现取决于面向消息的中间件。

为了覆盖大量情况，OPC UA PubSub支持两种不同的面向消息的中间件变体。它们是：

• 无代理形式，其中面向消息的中间件是能够路由基于数据包的消息的网络基础设置。订阅者和发布者使用数据包协议，如UDP多播。
• 基于代理的形式，其中面向消息的中间件是代理。订阅者和发布者使用AMQP或MQTT等标准消息传递协议与代理通信。所有消息都被发布到代理公开的特定队列（例如主题、节点），订阅者可以监听这些队列。代理可以将发布者的正式消息传递协议转换为订阅者的正式消息传递协议。

PubSub用于不同系统组件之间的消息通信，这些组件无需知道彼此的身份。

发布者预先配置了要发送的数据。在发布者和订阅者之间没有建立连接。

关于订阅者的信息以及要发布的数据转发给订阅者的工作由面向消息的中间件完成。发布者不知道甚至不关心是否有一个或多个订阅者。发布者的能力和资源需求是可预测的，不依赖于订阅者的数量。

OPC 10000-14描述了OPC UA PubSub模型的细节。

6.6 模型协同 Synergy of models

PubSub和C/S都是基于OPC UA信息模型的。因此，PubSub可以轻松集成到服务器和客户端中。比较典型的是，发布者是服务器（信息的所有者），订阅者通常是客户端。首先，PubSub配置信息模型采用OPC UA C/S模型，对发布者和订阅者的配置进行改进。下图描述了一个同时充当服务器和发布者的OPC UA应用程序。

集成C/S和PubSub的模型

然而，PubSub通信并不需要角色依赖（role dependency）。例如，客户端可也是发布者，服务器也可以是订阅者。事实上，发布者或订阅者没有必要作为服务器或客户端参与PubSub通信。

7 服务集 Service Sets

7.1 一般性

OPC UA服务划分为服务集，每个服务集定义了一组逻辑服务，用于访问服务器的特定方面。服务集描述如下。服务集及其服务在OPC 10000-4中有详细说明。服务器是否支持服务集或服务集中的特定服务，由其配置文件定义。OPC 10000-7中描述了配置文件。

7.2 发现服务集 Discovery Service Set

该服务集定义了用于发现系统中可用服务器的服务。它还提供了一种方式，让客户端可以读取连接到服务器所需的安全配置。发现服务由各个的服务器和专用的发现服务器实现。众所周知，专用的发现服务器提供了一种客户端可以发现所有已注册服务器的方式。OPC 10000-12描述了如何使用发现服务和专用的发现服务器。

7.3 安全通道服务集 SecureChannel Service Set

该服务集定义了用于打开通信通道的服务，该通道确保与服务器交换的所有消息的机密性和完整性。UA安全的基本概念在OPC 10000-2中定义。

安全通道服务不同于其它服务，因为它们通常不是由OPC UA应用程序直接实现的。相反，它们是由OPC UA应用程序建立在的通信栈提供的。OPC UA应用程序只需验证安全通道在接收到消息时是否处于活动状态。OPC 10000-6描述了如何使用不同类型的通信栈实现安全通道服务。

安全通道是在单个客户端和单个服务器之间长时间运行的逻辑链接。该通道维护一组密钥，这些密钥只有客户端和服务器知道，用于验证和加密通过网络发送的消息。安全通道服务允许客户端和服务器安全地协商要使用的密钥。

用于验证和加密消息的确切算法在服务器的安全策略中描述。这些策略通过发现服务集公开。在创建安全通道时，客户端会选择（由服务器支持所需的安全策略）适当端点。

当客户端和服务器通过安全通道通信时，它们会根据安全策略验证所有传入消息是否已经签名或加密。UA应用程序应该忽略所有不符合通道安全策略的消息。

安全通道和UA应用程序会话是分开的；不过，单个UA应用程序会话只能通过单个安全通道访问。这意味着UA应用程序能够确定每个消息与哪个安全通道相关联。如果通信栈提供了安全通道机制，但不允许应用程序知道给定消息使用了什么安全通道，则不能用于实现安全通道服务器集。

UA应用程序会话和安全通道的关系如下图。UA应用程序使用通信栈交换消息。首先，安全通道服务用于在两个通信栈之间建立一个安全通道，允许它们以安全的方式交换消息。其次，UA应用使用会话服务集建立UA应用会话。

安全通道和会话服务

7.4 会话服务集

该服务集定义了用于在会话的上下文中建立应用层连接的服务。

7.5 节点管理服务集

节点管理服务集允许客户端在地址可见中添加、修改和删除节点。这些服务为服务器的配置提供了接口。

7.6 视图服务集

视图是公开定义的，是服务器创建的地址空间的子集。默认视图是整个地址空间，因此，视图服务能够对整个地址空间进行操作。该规范的未来版本还可能定义服务来创建客户端定义的视图。

7.7 查询服务集

查询服务集允许用户在不浏览和不了解数据内部存储的逻辑模式的情况下访问地址空间。

查询允许客户端根据客户端提供的过滤条件选择选择视图中节点的子集。视图中选择的查询语句称为结果集。

服务器可能很难处理需要访问运行时数据的查询，例如设备数据，这些查询涉及资源密集型操作或大延迟。这种情况下，服务器可能会拒绝查询。

7.8 属性服务集

属性服务集用于读写属性值。属性是OPC UA定义的节点的基本特征。它们不能由客户端或服务器定义。属性是地址空间中唯一允许具有数据值的元素。值属性是一种特殊的属性，用于定义变量的值。

7.9 方法服务集

方法表示对象的函数调用。它们在OPC 10000-3中被定义。方法被调用后，会在完成后返回，无论成功与否。方法的执行时间取决于它们执行的功能函数。

方法服务集定义了调用方法的方法。方法始终是对象的组成部分。通过浏览和查询服务提供了发现功能。客户端通过浏览标识其支持的方法的拥有对象来发现服务器支持的方法。

因为方法可以控制工厂操作的某些方面，所以方法调用可能依赖于环境或其它条件。当试图在方法完成执行后立即重新调用方法时，这点尤其重要。调用方法需要的条件可能尚未恢复到允许方法重新启动的状态。此外，某些方法可能支持并发调用，而其它方法可能在给定时间只能执行单个调用。

7.10 监视项服务集

监视项服务集由客户端用于创建和维护监视项。监视项监视变量、属性和事件通知。当它们检测到某些条件时，会生成通知。它们监视变量的值或状态的变化；属性的值变化；以及事件通知器生成的新报警和事件报告。

每个监视项标识要监视的项和用于定期向客户端发布通知的订阅。每个监视项还指定监视（采样）该项的速率，对于变量和事件通知器，还指定用于确定何时生成通知的筛选条件。OPC 10000-4中的属性定义确定了属性的筛选标准。

为监视项定义的采样率可能比订阅的发布率快。因此，监视项可以配置为对所有通知进行排队，也可以配置为只对最新的通知进行排队，以便由订阅进行传输。后者，队列的大小为1。

监视项服务也定义了一种监视模式。监视模式被配置为禁用采样和报告、仅启用采样。当启用采样时，服务器对项进行采样。此外，对每个样本进行评估以确定是否应该生成该通知。如果是，通知将排队。如果启用了报告，则队列将用于订阅以进行传输。

最后，监视项可以配置为触发其它监视项的报告。该情况下，要报告的项的监视模式通常设置为仅抽样，并且当触发项生成通知时，要报告的项的任何排队通知将用于订阅以进行传输。

7.11 订阅服务集

订阅服务集由客户端用于创建和维护订阅。订阅是为监视项定期发布给与其分配的监视项通知消息的实体。通知消息包含一个公共头，后面跟着一系列通知。通知的格式取决于被监控项的类型（即变量、属性和事件通知）。

一旦创建，订阅的存在就独立于客户端与服务器的会话。这允许一个客户端创建一个订阅，另一个客户端（可能是冗余客户端）从它那里接收通知消息。

为了防止客户端不使用，订阅具有配置生命周期，客户端会定期续订。如果所有客户端都没有续订生命周期，生命周期将过期，服务器会关闭订阅。当一个订阅被关闭时，所有分配给该订阅的监视项都会被删除。

订阅包含支持检测和恢复丢失消息的功能。每个通知消息包含一个序列号，允许客户端检测丢失的消息。当在保活时间间隔内没有通知要发送时，服务器会发送一个保活消息，其中包含下次发送的通知消息的序列号。如果客户端在保活间隔过期后未能收到消息，或者它确定丢失了一些消息，则可以请求服务器重新发送一条或多条消息。