OPCUA 规范 第 1 部分：概述和概念 6：系统概念
原文链接：https://reference.opcfoundation.org/Core/Part1/6.1/
6 系统概念
6.1 客户端服务器概述
OPC UA 系统架构将客户端和服务器建模为交互伙伴。每个系统可能包含多个客户端和服务器。每个客户端可以同时与一个或多个服务器交互，每个服务器可以同时与一个或多个客户端交互。应用程序可以组合服务器和客户端组件，以允许与其他服务器和客户端交互，如6.3.7中所述。
客户端和服务器在子条款 6.2 和 6.3 中描述。图 3 说明了包含组合的 Server 和 Client 的体系结构。
图 3 – OPC UA 系统架构
6.2 OPC UA 客户端
OPC UA客户端架构对客户端/服务器交互的客户端端点进行建模。 图 4 说明了典型客户端的主要元素以及它们之间的关系。
图 4 – OPC UA 客户端架构
Client Application 是实现 Client 功能的代码。它使用客户端 API 向服务器发送和接收 OPC UA 服务请求和响应。为 OPC UA 定义的服务在第 6.4 条中描述，并在 OPC 10000-4 中指定。
请注意，“客户端 API ”是一个内部接口，用于将客户端应用程序代码与 OPC UA 通信堆栈隔离开来。OPC UA 通信堆栈将客户端 API 调用转换为消息，并应客户端 应用程序的请求通过底层通信实体将它们发送到服务器。OPC UA 通信栈还接收来自底层通信实体的响应和 NotificationMessages ，并通过客户端 API 将它们传递给客户端应用程序。
6.3 OPC UA 服务器
6.3.1 概述
OPC UA 服务器架构对客户端/服务器交互的服务器端点建模。图 5 说明了服务器的主要元素以及它们如何相互关联。
图 5 – OPC UA 服务器架构
6.3.2 实际对象
实际对象是可由服务器应用程序访问或在内部维护的物理或软件对象。示例包括物理设备和诊断计数器。
6.3.3 服务器应用
服务器应用程序是实现服务器功能的代码。它使用服务器 API 发送和接收来自客户端的 OPC UA 消息。请注意，“服务器 API ”是一个内部接口，用于将服务器应用程序代码与 OPC UA 通信堆栈隔离开来。
6.3.4 OPC UA 地址空间
6.3.4.1 地址空间节点
AddressSpace 被建模为一组可供客户端使用 OPC UA 服务 （接口和方法）访问的 Node 。AddressSpace 中的 Node 用于表示真实对象、它们的定义以及它们之间的引用。
6.3.4.2 地址空间组织
OPC 10000-3 包含元模型“构建块”的详细信息，用于以一致的方式从 互连的节点创建地址空间。服务器可以根据自己的选择在 AddressSpace 内自由地组织它们的 Node 。在 Node 之间使用 References 允许服务器将 AddressSpace 组织成层次结构、 Node 的全网状网络或任何可能的组合。
OPC 10000-5 定义了 OPC UA 节点和引用以及它们在地址空间中的预期组织。一些配置文件不需要实现所有的 UA 节点。
6.3.4.3 地址空间视图
View 是 AddressSpace 的一个子集。视图用于限制 Server 对 Client 可见的 Node，从而限制 Client 提交的 Service 请求的 AddressSpace 的大小。默认 View 是整个 AddressSpace。服务器可以选择定义其他视图。视图隐藏了 AddressSpace 中的一些 Node 或 References。视图通过地址空间可见，客户端能够浏览视图以确定它们的结构。视图通常是层次结构，客户端更容易在树中导航和表示。
6.3.4.4 对信息模型的支持
OPC UA地址空间支持信息模型。这种支持通过以下方式提供：
a) 允许地址空间中的对象相互关联的节点引用。
b) ObjectTypeNode 为真实对象（类型定义）提供语义信息。
c) ObjectTypeNode 支持类型定义的子类化。
d) 地址空间中公开的数据类型定义， 允许使用行业特定的数据类型。
e) 允许行业团体定义其特定信息模型如何在 服务器地址空间中表示的 OPC UA 配套标准。
6.3.5 订阅实体
6.3.5.1 监控项
MonitoredItems 是由客户端创建的服务器中的实体，用于监视地址空间节点及其现实世界的对应物。当它们检测到数据更改或事件/警报发生时，它们会生成一个通知，该通知通过订阅传输给客户端。
6.3.5.2 订阅
订阅是 服务器中向客户端发布通知的端点。客户端通过发送 Publish Messages 来控制发布的速率。
6.3.6 OPC UA 服务接口
6.3.6.1 概述
为 OPC UA 定义的服务在第 6.4 条中描述，并在 OPC 10000-4 中指定。
6.3.6.2 请求/响应服务
请求/响应服务是客户端通过 OPC UA 服务接口调用的服务，用于在地址空间中的一个或多个节点上执行特定任务并返回响应。
6.3.6.3 订阅服务
发布服务通过 OPC UA服务接口调用，目的是定期向客户端发送通知。通知包括事件、警报、数据更改和程序输出。
6.3.7 服务器到服务器交互
客户端服务器模型中的服务器到服务器交互是其中一个服务器充当另一个服务器的客户端的交互。服务器 到服务器交互允许开发以下服务器：
🟢 在对等的基础上相互交换信息，这可能包括用于维护系统范围类型定义的冗余或远程服务器（参见图 6 ），
🟢 链接在服务器的分层架构中， 以提供：
🟡 来自低层服务器的数据聚合，
🟡 对 Clients的高层数据构造，以及
🟡 与 客户端的集中器接口，用于对多个底层服务器的单点访问。
图 6 说明了服务器之间的交互。
图 6 – 服务器之间的点对点交互
类似的点对点交互也可以使用 OPC UA PubSub 模型完成，其中每个对等应用程序既是发布者又是订阅者。
图 7 扩展了前面的示例，并说明了将服务器链接在一起以垂直访问企业中的数据。
图 7 – 链式服务器示例
6.4 冗余
OPC UA 提供以标准化方式实现冗余的数据结构和服务。冗余可用于高可用性、容错和负载平衡。OPC 10000-4 正式定义了客户端、服务器和网络冗余。只有一些 Profiles OPC 10000-7 需要冗余支持，而不是基本 Profile。
所需的客户端和服务器行为与两种不同的服务器冗余模式相关联，即透明和非透明。使用透明或非透明冗余时的客户端和服务器职责在 OPC 10000-4 中定义。
支持非透明冗余的服务器也可以支持客户端控制的负载平衡。服务器的健康状况（包括其服务 请求的能力）统称为 ServiceLevel。有关 ServiceLevel 的正式定义，请参见 OPC 10000-5 。 OPC 10000-4 定义了四个不同的 ServiceLevel 子范围和示例用法。
❓ 冗余是有很多耦合的信息吗？多余的信息，用来显示什么的？不明白。
6.5 发布-订阅
使用 PubSub， OPC UA 应用程序不会直接交换请求和响应。相反，发布者将消息发送到面向消息的中间件，而不知道可能存在哪些订阅者（如果有的话） 。同样，订阅者对特定类型的数据表示兴趣，并处理包含此数据的消息，而不知道发布者有什么。
面向消息的中间件是支持在分布式系统之间发送和接收消息的软件或硬件基础设施。这取决于面向消息的中间件如何实现此分发。
为了涵盖大量用例，OPC UA PubSub 支持两种截然不同的面向消息的中间件变体。这些是：
🍄 一种无代理形式，其中面向消息的中间件是能够路由基于数据报的消息的网络基础设施。订阅者和发布者使用数据报协议，如 UDP 多播。
🍄 基于代理的表单，其中面向消息的中间件是代理。订阅者和发布者使用 AMQP 或 MQTT 等标准消息传递协议与 Broker 进行通信。所有消息都发布到代理公开的特定队列（例如主题、节点），订阅者可以监听这些队列。Broker 可以将消息从 Publisher 的正式消息协议转换为 Subscriber 的正式消息协议。
PubSub 用于在不同系统组件之间传递消息，而这些组件不必知道彼此的身份。
发布者预先配置了要发送的数据。Publisher 和 Subscriber 之间没有建立连接。
关于订阅者是谁以及将发布的数据转发给订阅者的知识被卸载到面向消息的中间件。发布者不知道甚至不关心是否有一个或多个订阅者。发布者的工作量和资源需求是可预测的，并且不依赖于订阅者的数量。
OPC 10000-14 描述了 OPC UA PubSub 模型的详细信息。
OPC UA 的发布订阅，可以基于 UDP，也可以基于代理，类似 MQTT 。
6.6 模型协同
PubSub 和客户端服务器都基于 OPC UA 信息模型。因此， PubSub 可以很容易地集成到服务器和客户端中。通常，发布者将是服务器（信息的所有者），订阅者通常是客户端。最重要的是，用于配置的 PubSub 信息模型促进了使用 OPC UA 客户端服务器模型的发布者和订阅者的配置。图 8 描绘了单个 OPC UA 同时充当服务器和发布者的应用程序。
图 8 – 集成客户端服务器和 PubSub 模型
尽管如此，PubSub 通信不需要这种角色依赖。即，客户端可以是发布者，服务器可以是订阅者。事实上，发布者或订阅者没有必要成为服务器或客户端来参与PubSub 通信。
