OPC UA PubSub模式及其使用场景1 – OPCUA标准模型概念以及OPC UA架构

1. OPC UA客户端/服务器模型

客户端/服务器模型是OPC UA中标准的通信模型。基于这样一种思想：存在一个被动的服务器组件，该组件对所有客户端的应用程序公开其数据。客户端应用程序可以通过一些标准化的服务从服务器访问数据和信息。

客户端/服务器模型

在客户端/服务器架构下，客户端要做的第一件事是实现与服务器的连接。客户端通过一个连接地址(在此我们略过一些细节)，将创建一个与服务器的会话通道。该会话包含一个安全的报文，其中包括可选择的加密和身份验证等参数——用于识别服务器中的客户端应用程序和用户是否匹配。客户端还可以识别服务器，并决定是否允许与该服务器通信。

会话建立之后，客户端应用程序可以从服务器请求一些标准服务。这些服务包括:

1.连接并创建会话

2. 浏览地址空间——查找服务器上可用的内容

3.读取-变量值或原始数据

4. 写入-变量值或原始数据

5. 调用方法

6. 阅读历史信息-变量和事件

7. 关闭会话并断开连接

所以最后，当客户端完成需求时，它将关闭会话并断开连接。

客户端/服务器订阅

客户端/服务器模型内还包含一个订阅模型。在这个模型中，每个客户端可以创建任意数量的服务器订阅（在此的订阅为订阅功能）。每个订阅都可以包括变量、EventNotifier的MonitoredItems(具有EventNotifier属性集的对象节点)。

客户端/服务器模型内订阅

客户端/服务器的优缺点

客户端/服务器模型已经成功地用于各种的SCADA场景中，当不同应用程序之间的连接数量不是很多时，它就会顺利交互。但是如果有数十或数百个设备(即服务器)需要持续连接或类似数量的客户端需要连接到任何服务器，可能会在资源配置方面遇到麻烦，因为每个连接和订阅都需要内部维护，并且它们会在网络中占用单独的流量。

客户端/服务器模型主要场景

OPC UA的设计不是为了实现任何确定性的通信或不可靠网络上的通信。但是它支持同步服务调用，接收即时结果或对操作指令的确认，这对应用程序非常重要。其安全性也很灵活，可以为每个应用程序和用户定义规则，甚至为每个变量定义规则。

随着OPCUA技术的应用范围越来越广，对OPCUA技术的更多需求也不断增加。很多应用希望OPCUA能具备更多确定性通讯特性，或者具备更好的伸缩性。为了应对这类需求，OPCUA定义了Pub/Sub模型。下期我们深入讨论Pub/Sub模型的技术详情。