OPC UA

《OPC统一架构》 [德] 马科等著的读书笔记,同时参考了华北电力大学的一篇硕士学位论文《OPC UA服务器数据管理与订阅功能模块研究与开发》以及互联网上的一些资料。太长不看直接跳到总结部分,可以对OPC UA有一个整体上的认知。

OPC

1. 三个主要的OPC规范:

  • 数据访问:DA Data Access

    • 规范描述了访问过程数据的当前值
  • 报警和事件:A&E Alarms And Events

    • 描述了寄予时间的信息接口,包括过程报警确认
  • 历史数据访问:HDA History Data Access

    • 描述了访问历史数据的函数

    所有接口提供通过地址空间浏览的方法,并提供可用数据的信息。

2. OPC采用C/S方式进行信息交换。

服务器封装了过程信息来源(如设备),使信息可以通过它的接口访问。客户端连接到服务器后,可以访问和使用它所提供的的数据。数据可以被C&S使用。

3. 经典的OPC接口是基于微软的COM和DCOM。

OPC UA(OPC Unified Architecture)总览

可跨平台,提供更高的可靠性,安全性和数据集成,能显著改进企业信息的连通性。

相比于传统的OPC,OPC UA有如下四个特点:

统一的地址空间与信息模型。
  • 传统OPC的DA、A&E、HDA各自有相对独立的地址空间,相应也有不同的访问方式;

  • 而OPC UA定义了统一数据和服务模型。包括:

    • 行为和语义信息模型
    • 使应用程序相互作用的消息模型
    • 在终端之间传输数据的通信模型
    • 保证系统之间实现互操作性的一致性模型
  • 可以实现DA、A&E、HDA、控制命令、复杂数据的交互通信。

松耦合性。
  • 参考了SOA(Service-oriented architecture),以单元为最基本粒度的服务。
  • 通过网络组合形成不同的功能。
  • 使用HTTP协议在TCP信道上传输。
多平台性。
  • 由于采用SOA架构,服务可以是任何语言,只要有统一的通信方式。
更高的安全性。
  • UA的用户认证及加密可以采用现在以及未来出现的各种方式,非常灵活。
Summary 优势:
  • 平台无关
  • 所有级别的直接设备连接
  • 身份验证和加密
  • 语义服务

地址空间简介

是以一组引用行驶连接起来的节点构成网状结构,节点是一个世纪设备在地址空间中的映射,节点包括了属性和引用。地址空间为不同的实际设备提供了一个统一的抽象模型,利用此模型便于对节点的管理及服务集实现对其统一的访问方式。同时利用引用可以通过基本的节点搭建出复杂的节点模型,满足世纪设备需要多样性的描述的要求。

节点。

节点由属性和引用两部分组成:

  • 属性:描述节点的一些特性
  • 引用:指向另一个与之相关的节点。

  • BrowseName浏览名称,仅用于浏览目的,不用于显示节点名称。

  • 节点的属性集由OPC UA规定的,不能被扩展。

  • ReferenceType层次结构只支持单一继承,保证每个引用类型要么是一个层次化引用类型,要么是非层次化引用类型。

节点的主要(重要)类别:

  • 对象
    • 对象可以拥有变变量和方法
    • 用于地址空间结构,对象使用变量对外提供值,对象不像变量一样拥有Value属性。
  • 变量
    • 代表一个值,客户端可以对这个值进行读取、写入和订阅其变化
    • 分为
      • 特性:服务器定义的对象、数据变量和其他节点的特征。
      • 数据变量:代表了对象的内容。
  • 方法
    • 代表服务器中一个由客户端调用并返回结果的方法。

地址空间组织形式。

  • 在地址空间中,节点与节点之间通过引用连接到一起形成网状结构,一般节点数量非常庞大,客户端经常只对某个指定的子集的数据感兴趣。
  • 服务器通过视点的筛选参数属性,筛选相应的引用特性构成的区域称之为视域。视域由视域节点类定义。视域指定了一个地址空间的子集。
  • OPC UA服务器对客户端可用的对象几何及其相关信息被称为地址空间。

OPC UA属性服务。

提供了对节点属性的访问功能,包括:

  • 读取 Read
  • 历史数据读取 HistoryRead
  • 写入 Write
  • 历史数据更新 HistoryUpdate
    对于监控项服务需要通过其读取函数对所订阅的节点属性进行读取,并对监控项实例中的数据进行更新。
  • OPC UA订阅与监控项服务及总揽

状态机

是OPC UA的一个基本概念。这个基本概念被服务器用来描述特定状态机的应用程序,同时也被OPC信息模型使用。有两个状态:空闲(Idle)和读(Reading),并在其间转换。

订阅数据变化和事件

客户端能从OPC UA服务器订阅3种不同类型的信息。

  • 订阅用于对信息源进行分组
  • 监控项用于管理一个信息源
  • 一条信息被称作一个通知

一个订阅可能含有所有的3种类型的监控项,服务器将传递通知给这些件是想直到订阅或监控项被删除。

监控项服务集

  • 客户端通过监控项订阅数据或事件。

  • 监控项保存需要监控的节点项目,节点项目可以是任意节点属性。

  • 提醒是由于描述数据改变和事件的数据结构。通过订阅打包生产提醒消息被发送到客户端。

  • 订阅根据用户定义的发布间隔,周期性允许发送提醒消息。

  • 监控项的主要参数用来设定数据的采样,评价和上报。分别是:

    • 采样间隔
    • 监控模式
    • 过滤器
    • 队列参数
  • 服务器可能以加快于客户端支持的速度采样,同时由于过滤器服务器会发送少于采样间隔设定的数值量。当应用数据改变过滤器时,最新的采样值会与队列中上一周期生成数据进行比对。

  • 触发模式。在监控项服务中允许设置当某一数据触发项发送辩护后引起其他项目数据上报。该服务可以由在触发项和上报项之间建立链接来完成。

    四种策略设置:

    • 引起触发项监控模式设定为上报禁止。此时引起触发项不会被上报。
    • 引起触发项监控模式设定为上报允许。此时引起触发项被上报。
    • 上报项监控模式设定为上报禁止。此时上报项被上报。
    • 上报项监控模式设定为上报允许。此时上报项只会被上报一次。

    另外:客户端可以创建或删除触发项与上报项之间的链接。如果上报项所指的监控项在出发链接删除之前被删除,则链接也会被删除,但触发项不受影响。

三种类型的监控项
  • 用来订阅变量值的变化,是最常见的。
  • 用于订阅时间。通过定义一个事件通知器来监视,同时可以为事件定义一个事件过滤器。
  • 用于订阅聚合值。聚合值是根据客户端定义的时间间隔,对获取到的变量值进行计算得出的。

监控项服务
  • 建立监控项

    用于为订阅建立或增加一个或多个监控项。

    • 订阅删除,关联的监控项也会被自动删除。

    • 删除监控项将引起其所指向到上报项的链接被删除,但膳宝香不会受到影响。

    • 多次调用创建监控项服务来创建多个监控项将影响到服务器的运行,应该一次为订阅创建多个监控项。

  • 更改监控项

    用于更改订阅中的监控项。对采样间隔和过滤器的更改在下一个周期生效。

  • 设置监控项模式

    用于设置订阅中一个或多个监控项的监控模式。若设置禁用模式将导致所有的提醒被删除。

  • 设置触发

    用于创建和删除触发项的触发链接。触发项和上报项应属于同一订阅。

  • 删除监控项

    用于删除订阅中一个或多个监控项。

    一个监控项被删除,其触发链接也被删除。

    但删除监控项可以不回删除已经发送到订阅的提醒,客户端肯能收到已删除的监控项上报的数据。

订阅服务集

订阅模型

用于向客户端发送提醒。本质是要求服务器到客户端的一个异常报告。

其实是相当于(设计模式中)一个扩展后的观察者模式。

  • 包含了一组由客户端定制的监控项。
  • 定义了发布间隔。
  • 提醒消息由客户端调用发布服务来返回。
  • 发布周期初始,如果提醒队列不为空,发布请求队列为空,服务器进入等待状态直到接收到发布请求。接收到后,服务器理科发送提醒消息不必等到发布时刻。
  • 定义有存在计数器,用来记录连续的发布周期内提醒队列为空次数。达到最大存在计数时,服务器产生一个返回发布请求的存在消息,用于通知客户端服务仍然有效。
  • 定义有生存时间计数器,用于记录在发布周期内客户端未发送发布请求的次数。该数值大于最大计数时,该订阅将被删除,相关的监控项也会被删除。
  • 订阅是否发布提醒消息可以由服务器在创建时设定,或调用设定发布模式来更改。当设定为禁用时,服务器任然进行采样,并发送存在消息。
  • 订阅将缓存已发送的提醒消息知道客户端确认或到达存在消息发送时间。

当订阅被创建后,在第一个发周期结束时,服务器将向客户端发送消息用于告知客户端订阅正在运行,此时若待发送提醒则一并发送,否则发送存在消息。
状态表用来描述订阅操作。当完成订阅的创建后,服务器初始化发布计数器,并当其到期时进行重置。如果计数器超过创建订阅时设定的无客户端订阅服务请求次数值,服务器将认为客户端已经不存在,而注销该订阅。

请求不直接指向某一订阅,可以被任一订阅使用,每个请求包含对上一发布周期内发布提醒的订阅的“收到”应答。所有请求被服务器直接存入被所有订阅共享的对列表中,除了:

  • 无新的客户端发布请求,而上一服务器向客户端发送的提醒消息还未发送完储存在队列中的提醒。

  • 订阅计时器已经到期,且有提醒或存在消息需要发送。

    以上两种情况,服务器将不会把请求存入队列,而是直接交由处在以上两种情况中的订阅予以处理。

订阅服务
  • 创建订阅

    用于建立订阅。订阅监控了一组监控项并当客户端发送发布请求时返回提醒消息到客户端。

  • 更改订阅

    用于更改订阅的设置。

  • 更改订阅模式

    用于准许订阅发送提醒消息。

  • 发布服务

    • 用于通知服务器已收到订阅发布的提醒消息。
    • 用于请求服务器返回提醒消息或生存消息。

    确保服务器周期性上报。

  • 重新发布

    该服务要求订阅能从重传队列中发送提醒消息。如果服务器没有客户端所要求的的,则返回一个错误响应。

  • 传送订阅

    用于吧一个会话中的订阅及其相关监控项传送到另一个会话。

  • 删除订阅

    由客户端用于删除一个或多个由该客户端创建或传送的订阅。

    该服务执行后,会删除所有与该订阅相关的监控项。

访问历史数据和历史事件

用Read、Write、Subscriptions的方法访问当前数据和访问历史的主要不同在于对于时间域历史请求定义和当前数据或事件的时间域信息归档数组的返回。历史的可用性被变量的AccessLevel属性或者一个对象的EventNotifier(事件通知器)属性指定。
历史访问服务HistoryRead和 HistoryUpdate是被广泛应用的两种服务,它们通过多样性的可扩展参数( extended parameter)来覆盖不同的历史访问用例。

历史读取服务

HistoryRead 服务请求利用一个可扩充可修改的参数定义读取原始数据、修改的数据( modified data)、已处理的数据( processed data)、指定时间戳的数据和事件的历史。HistoryRead响应利用一个可扩展参数来传输两种类型的请求信息:数据和事件。HistoryUpdate 服务请求利用一个可扩展参数来插入、替换、更新、删除数据或事件。

  • 读取raw或modified数据

    储存在历史数据库中的raw数据可以直接被返回,一个更改的(modified)数据是在历史数据库中被相同的时间戳的其他值所覆盖的数据。如果同一时间戳有多个覆盖值,服务器必须全部返回。

  • 读processed(已处理)数据

    HistoryRead 服务被Read Processed类型的可扩展参数调用来读取在历史数据库中基于Raw数据的指定聚合所计算出来的processed 数据。它读取processed值、状态和时间戳在一个或多个指定时间域上的变量。

  • 读时间戳序列数据

    如果在特定的时间戳没有值,将会从周围值中插值计算出一个值。读取一个或多个变量的值、状态和时间戳

  • 读取历史事件

    使用读事件的类型的扩展参数阅读指定的时间域的事件。参数用来过滤返回那些历史事件并选择返回的字段。

历史更新服务

用来插入、替换、更新或删除历史值或事件。

  • 插入、替换或更新数据
  • 插入、替换或更新事件
  • 删除原始数据或修改数据
  • 删除特定时间戳的数据
  • 删除事件

简单创建一个OPCUA服务器

下载地址 提取码:i5zd

点开.msi文件傻瓜式安装,直接next就行。

安装之后打开OPC UA DashBoard.exe,出现如下界面。

1:开启按键

2:帮助文档

开始搭建

  1. 启动 OPC UA Server & Client,变成如下界面

  1. 复制DA服务器端的endpoint URL到客户端,点击客户端endpoint右边的connect

OPC的一个强大功能是客户端可以浏览服务器并查看可用的数据(节点),下一部分将只是用客户端。

客户端使用

  1. 读取数据。

    点击客户端左侧栏各节点,将在右侧栏中显示节点中的值。

    实际上,很多OPC服务器在将值返回给客户端前会先从底层设备/底层系统获取数据。所以此时读取的数据相当于是该节点在某一时刻的数据快照。

  2. 写数据。

    在左侧导航栏中找到你想写数据的节点,单机右键—Write,即可写入。

这里我选择写的值是开始时间,单机OK之后弹出一个对话框

这是因为OPC UA中一些节点是只读的,对这些节点写入数据会触发异常。

  1. 订阅数据

    订阅可以连续采集数据,订阅是使服务器端代表客户端轮询底层设备,当服务器检测到节点值更改,向客户端发送一条新的消息。与连续读取操作相比,订阅减少了客户机端、服务器端和底层设备上的负载,特别是当多个客户机(以相同频率)同时订阅相同的节点时。

    具体操作:对你想订阅的节点单机右键—Monitor。

    当订阅值更新时,将在底部栏中显示。

​ 在底部栏中对订阅项单机右键,可以按需选择是否删除订阅项,写数据,设置监控模式,采样间隔,死区等操作。

技术映射

数据编码

数据编码是将服务消息包括它自身的输入、输出参数序列化到网络格式中。目前两种主要编码:OPC UA二进制和XML。

XML在此不做赘述,只说与XML相比,OPC UA二进制的不同之处。

即,其基本概念是基于一个定义好的规则,将特定的基本数据类型集合(内建数据类型)转译成二进制的表示形式,并写入一个流,将服务参数序列化与反序列化到二进制流中。由于大部分复杂数据类型都由基本数据类型结合产生,可以顺序地将他们包含的基本数据类型转译到二进制格式。因为这是基于在数据链路上较小的体积和高效的编码格式,所以可以提供快速数据编解码。

安全协议

两类安全协议,都基于一个基于证书的连接建立。

WS-SecureConversation

为通信定制的协议,对XML进行加密和签名。

UA-SecureConversation

WS-SecureConversation + TLS

传输协议

  1. UA TCP 简单,提供特殊错误恢复,允许会话在网络中断时保持存活。
  2. SOAP/HTTP 防火墙友好,高层。

总结

OPC UA首先是一个架构,这个架构的主体是地址空间。地址空间其实就是一个网状图,由一些可以互相引用到的节点组成。节点可以类比成数据结构链表中的节点,即由两部分组成,数据和指针(在OPC UA中是引用),数据部分存放节点相关的信息。

对节点的读写操作可以通过数据库,这样可以比较好的解决同步异步问题,因为数据库本身就有一个原子性的特点嘛。对于订阅操作,其实是设计模式中一个拓展后的观察者模式,数据一旦发生变化,就由服务器端直接发送一条消息给客户端,这样可以节省一些资源。不过在数据库设计中可能需要增加trigger触发器,再通知客户机,并将改变的数据添加到历史消息队列中(用于维护历史数据集)。

如果不通过数据库,对于读写操作,就需要手动控制同步异步和进程/线程互斥,可以用synchronized、lock或者更自由的PV信号灯之类的。然后订阅操作就是由服务器端监测到底层设备的某个值发生改变,发送一条消息给客户机,同时进行历史数据的维护。

对于数据编码,安全协议,传输协议在实际工程中考虑较少,我了解得也有限就不写了。

《OPC统一架构》 [德] 马科等著的读书笔记,同时参考了华北电力大学的一篇硕士学位论文《OPC UA服务器数据管理与订阅功能模块研究与开发》以及互联网上的一些资料。太长不看直接跳到总结部分,可以对OPC UA有一个整体上的认知。推荐使用支持浏览大纲的Markdown编辑器如Typora浏览本文档(当然也可以选择不,记事本也能打开)。

OPC

1. 三个主要的OPC规范:

  • 数据访问:DA Data Access

    • 规范描述了访问过程数据的当前值
  • 报警和事件:A&E Alarms And Events

    • 描述了寄予时间的信息接口,包括过程报警确认
  • 历史数据访问:HDA History Data Access

    • 描述了访问历史数据的函数

    所有接口提供通过地址空间浏览的方法,并提供可用数据的信息。

2. OPC采用C/S方式进行信息交换。

服务器封装了过程信息来源(如设备),使信息可以通过它的接口访问。客户端连接到服务器后,可以访问和使用它所提供的的数据。数据可以被C&S使用。

3. 经典的OPC接口是基于微软的COM和DCOM。

OPC UA(OPC Unified Architecture)总览

可跨平台,提供更高的可靠性,安全性和数据集成,能显著改进企业信息的连通性。

相比于传统的OPC,OPC UA有如下四个特点:

统一的地址空间与信息模型。
  • 传统OPC的DA、A&E、HDA各自有相对独立的地址空间,相应也有不同的访问方式;

  • 而OPC UA定义了统一数据和服务模型。包括:

    • 行为和语义信息模型
    • 使应用程序相互作用的消息模型
    • 在终端之间传输数据的通信模型
    • 保证系统之间实现互操作性的一致性模型
  • 可以实现DA、A&E、HDA、控制命令、复杂数据的交互通信。

松耦合性。
  • 参考了SOA(Service-oriented architecture),以单元为最基本粒度的服务。
  • 通过网络组合形成不同的功能。
  • 使用HTTP协议在TCP信道上传输。
多平台性。
  • 由于采用SOA架构,服务可以是任何语言,只要有统一的通信方式。
更高的安全性。
  • UA的用户认证及加密可以采用现在以及未来出现的各种方式,非常灵活。
Summary 优势:
  • 平台无关
  • 所有级别的直接设备连接
  • 身份验证和加密
  • 语义服务

地址空间简介

是以一组引用行驶连接起来的节点构成网状结构,节点是一个世纪设备在地址空间中的映射,节点包括了属性和引用。地址空间为不同的实际设备提供了一个统一的抽象模型,利用此模型便于对节点的管理及服务集实现对其统一的访问方式。同时利用引用可以通过基本的节点搭建出复杂的节点模型,满足世纪设备需要多样性的描述的要求。

节点。

节点由属性和引用两部分组成:

  • 属性:描述节点的一些特性
  • 引用:指向另一个与之相关的节点。

节点的通用属性

  • BrowseName浏览名称,仅用于浏览目的,不用于显示节点名称。

  • 节点的属性集由OPC UA规定的,不能被扩展。

  • ReferenceType层次结构只支持单一继承,保证每个引用类型要么是一个层次化引用类型,要么是非层次化引用类型。

节点的主要(重要)类别:

  • 对象
    • 对象可以拥有变变量和方法
    • 用于地址空间结构,对象使用变量对外提供值,对象不像变量一样拥有Value属性。
  • 变量
    • 代表一个值,客户端可以对这个值进行读取、写入和订阅其变化
    • 分为
      • 特性:服务器定义的对象、数据变量和其他节点的特征。
      • 数据变量:代表了对象的内容。
  • 方法
    • 代表服务器中一个由客户端调用并返回结果的方法。

地址空间组织形式。

  • 在地址空间中,节点与节点之间通过引用连接到一起形成网状结构,一般节点数量非常庞大,客户端经常只对某个指定的子集的数据感兴趣。
  • 服务器通过视点的筛选参数属性,筛选相应的引用特性构成的区域称之为视域。视域由视域节点类定义。视域指定了一个地址空间的子集。
  • OPC UA服务器对客户端可用的对象几何及其相关信息被称为地址空间。

OPC UA属性服务。

提供了对节点属性的访问功能,包括:

  • 读取 Read
  • 历史数据读取 HistoryRead
  • 写入 Write
  • 历史数据更新 HistoryUpdate
    对于监控项服务需要通过其读取函数对所订阅的节点属性进行读取,并对监控项实例中的数据进行更新。
  • OPC UA订阅与监控项服务及总揽

![OPC UA订阅与监控项服务及总揽](.\OPCUA_Imgs\OPC UA订阅与监控项服务及总揽.png)

状态机

是OPC UA的一个基本概念。这个基本概念被服务器用来描述特定状态机的应用程序,同时也被OPC信息模型使用。有两个状态:空闲(Idle)和读(Reading),并在其间转换。

订阅数据变化和事件

客户端能从OPC UA服务器订阅3种不同类型的信息。

  • 订阅用于对信息源进行分组
  • 监控项用于管理一个信息源
  • 一条信息被称作一个通知

一个订阅可能含有所有的3种类型的监控项,服务器将传递通知给这些件是想直到订阅或监控项被删除。

监控项服务集

  • 客户端通过监控项订阅数据或事件。

  • 监控项保存需要监控的节点项目,节点项目可以是任意节点属性。

  • 提醒是由于描述数据改变和事件的数据结构。通过订阅打包生产提醒消息被发送到客户端。

  • 订阅根据用户定义的发布间隔,周期性允许发送提醒消息。

  • 监控项的主要参数用来设定数据的采样,评价和上报。分别是:

    • 采样间隔
    • 监控模式
    • 过滤器
    • 队列参数
  • 监控项监控机制

  • 服务器可能以加快于客户端支持的速度采样,同时由于过滤器服务器会发送少于采样间隔设定的数值量。当应用数据改变过滤器时,最新的采样值会与队列中上一周期生成数据进行比对。

  • 触发模式。在监控项服务中允许设置当某一数据触发项发送辩护后引起其他项目数据上报。该服务可以由在触发项和上报项之间建立链接来完成。

    四种策略设置:

    • 引起触发项监控模式设定为上报禁止。此时引起触发项不会被上报。
    • 引起触发项监控模式设定为上报允许。此时引起触发项被上报。
    • 上报项监控模式设定为上报禁止。此时上报项被上报。
    • 上报项监控模式设定为上报允许。此时上报项只会被上报一次。

    另外:客户端可以创建或删除触发项与上报项之间的链接。如果上报项所指的监控项在出发链接删除之前被删除,则链接也会被删除,但触发项不受影响。

    触发机制

三种类型的监控项
  • 用来订阅变量值的变化,是最常见的。
  • 用于订阅时间。通过定义一个事件通知器来监视,同时可以为事件定义一个事件过滤器。
  • 用于订阅聚合值。聚合值是根据客户端定义的时间间隔,对获取到的变量值进行计算得出的。

订阅和监控项设置

监控项服务
  • 建立监控项

    用于为订阅建立或增加一个或多个监控项。

    • 订阅删除,关联的监控项也会被自动删除。

    • 删除监控项将引起其所指向到上报项的链接被删除,但膳宝香不会受到影响。

    • 多次调用创建监控项服务来创建多个监控项将影响到服务器的运行,应该一次为订阅创建多个监控项。

  • 更改监控项

    用于更改订阅中的监控项。对采样间隔和过滤器的更改在下一个周期生效。

  • 设置监控项模式

    用于设置订阅中一个或多个监控项的监控模式。若设置禁用模式将导致所有的提醒被删除。

  • 设置触发

    用于创建和删除触发项的触发链接。触发项和上报项应属于同一订阅。

  • 删除监控项

    用于删除订阅中一个或多个监控项。

    一个监控项被删除,其触发链接也被删除。

    但删除监控项可以不回删除已经发送到订阅的提醒,客户端肯能收到已删除的监控项上报的数据。

订阅服务集

订阅模型

用于向客户端发送提醒。本质是要求服务器到客户端的一个异常报告。

其实是相当于(设计模式中)一个扩展后的观察者模式。

  • 包含了一组由客户端定制的监控项。
  • 定义了发布间隔。
  • 提醒消息由客户端调用发布服务来返回。
  • 发布周期初始,如果提醒队列不为空,发布请求队列为空,服务器进入等待状态直到接收到发布请求。接收到后,服务器理科发送提醒消息不必等到发布时刻。
  • 定义有存在计数器,用来记录连续的发布周期内提醒队列为空次数。达到最大存在计数时,服务器产生一个返回发布请求的存在消息,用于通知客户端服务仍然有效。
  • 定义有生存时间计数器,用于记录在发布周期内客户端未发送发布请求的次数。该数值大于最大计数时,该订阅将被删除,相关的监控项也会被删除。
  • 订阅是否发布提醒消息可以由服务器在创建时设定,或调用设定发布模式来更改。当设定为禁用时,服务器任然进行采样,并发送存在消息。
  • 订阅将缓存已发送的提醒消息知道客户端确认或到达存在消息发送时间。

当订阅被创建后,在第一个发周期结束时,服务器将向客户端发送消息用于告知客户端订阅正在运行,此时若待发送提醒则一并发送,否则发送存在消息。
状态表用来描述订阅操作。当完成订阅的创建后,服务器初始化发布计数器,并当其到期时进行重置。如果计数器超过创建订阅时设定的无客户端订阅服务请求次数值,服务器将认为客户端已经不存在,而注销该订阅。

请求不直接指向某一订阅,可以被任一订阅使用,每个请求包含对上一发布周期内发布提醒的订阅的“收到”应答。所有请求被服务器直接存入被所有订阅共享的对列表中,除了:

  • 无新的客户端发布请求,而上一服务器向客户端发送的提醒消息还未发送完储存在队列中的提醒。

  • 订阅计时器已经到期,且有提醒或存在消息需要发送。

    以上两种情况,服务器将不会把请求存入队列,而是直接交由处在以上两种情况中的订阅予以处理。

订阅服务
  • 创建订阅

    用于建立订阅。订阅监控了一组监控项并当客户端发送发布请求时返回提醒消息到客户端。

  • 更改订阅

    用于更改订阅的设置。

  • 更改订阅模式

    用于准许订阅发送提醒消息。

  • 发布服务

    • 用于通知服务器已收到订阅发布的提醒消息。
    • 用于请求服务器返回提醒消息或生存消息。

    确保服务器周期性上报。

  • 重新发布

    该服务要求订阅能从重传队列中发送提醒消息。如果服务器没有客户端所要求的的,则返回一个错误响应。

  • 传送订阅

    用于吧一个会话中的订阅及其相关监控项传送到另一个会话。

  • 删除订阅

    由客户端用于删除一个或多个由该客户端创建或传送的订阅。

    该服务执行后,会删除所有与该订阅相关的监控项。

访问历史数据和历史事件

用Read、Write、Subscriptions的方法访问当前数据和访问历史的主要不同在于对于时间域历史请求定义和当前数据或事件的时间域信息归档数组的返回。历史的可用性被变量的AccessLevel属性或者一个对象的EventNotifier(事件通知器)属性指定。
历史访问服务HistoryRead和 HistoryUpdate是被广泛应用的两种服务,它们通过多样性的可扩展参数( extended parameter)来覆盖不同的历史访问用例。

历史读取服务

HistoryRead 服务请求利用一个可扩充可修改的参数定义读取原始数据、修改的数据( modified data)、已处理的数据( processed data)、指定时间戳的数据和事件的历史。HistoryRead响应利用一个可扩展参数来传输两种类型的请求信息:数据和事件。HistoryUpdate 服务请求利用一个可扩展参数来插入、替换、更新、删除数据或事件。

  • 读取raw或modified数据

    储存在历史数据库中的raw数据可以直接被返回,一个更改的(modified)数据是在历史数据库中被相同的时间戳的其他值所覆盖的数据。如果同一时间戳有多个覆盖值,服务器必须全部返回。

  • 读processed(已处理)数据

    HistoryRead 服务被Read Processed类型的可扩展参数调用来读取在历史数据库中基于Raw数据的指定聚合所计算出来的processed 数据。它读取processed值、状态和时间戳在一个或多个指定时间域上的变量。

  • 读时间戳序列数据

    如果在特定的时间戳没有值,将会从周围值中插值计算出一个值。读取一个或多个变量的值、状态和时间戳

  • 读取历史事件

    使用读事件的类型的扩展参数阅读指定的时间域的事件。参数用来过滤返回那些历史事件并选择返回的字段。

历史更新服务

用来插入、替换、更新或删除历史值或事件。

  • 插入、替换或更新数据
  • 插入、替换或更新事件
  • 删除原始数据或修改数据
  • 删除特定时间戳的数据
  • 删除事件

简单创建一个OPCUA服务器

下载地址 提取码:i5zd

点开.msi文件傻瓜式安装,直接next就行。

安装之后打开OPC UA DashBoard.exe,出现如下界面。

OPCUA_ClientServer_1

1:开启按键

2:帮助文档

开始搭建

  1. 启动 OPC UA Server & Client,变成如下界面

OPCUA_ClientServer_2

  1. 复制DA服务器端的endpoint URL到客户端,点击客户端endpoint右边的connect

Client_1

Server_1

OPC的一个强大功能是客户端可以浏览服务器并查看可用的数据(节点),下一部分将只是用客户端。

客户端使用

  1. 读取数据。

    点击客户端左侧栏各节点,将在右侧栏中显示节点中的值。

    Client_2

    实际上,很多OPC服务器在将值返回给客户端前会先从底层设备/底层系统获取数据。所以此时读取的数据相当于是该节点在某一时刻的数据快照。

  2. 写数据。

    在左侧导航栏中找到你想写数据的节点,单机右键—Write,即可写入。

    Client_3

这里我选择写的值是开始时间,单机OK之后弹出一个对话框

Client_4

这是因为OPC UA中一些节点是只读的,对这些节点写入数据会触发异常。

  1. 订阅数据

    订阅可以连续采集数据,订阅是使服务器端代表客户端轮询底层设备,当服务器检测到节点值更改,向客户端发送一条新的消息。与连续读取操作相比,订阅减少了客户机端、服务器端和底层设备上的负载,特别是当多个客户机(以相同频率)同时订阅相同的节点时。

    具体操作:对你想订阅的节点单机右键—Monitor。

    当订阅值更新时,将在底部栏中显示。

    Client_5

​ 在底部栏中对订阅项单机右键,可以按需选择是否删除订阅项,写数据,设置监控模式,采样间隔,死区等操作。

技术映射

映射

数据编码

数据编码是将服务消息包括它自身的输入、输出参数序列化到网络格式中。目前两种主要编码:OPC UA二进制和XML。

XML在此不做赘述,只说与XML相比,OPC UA二进制的不同之处。

即,其基本概念是基于一个定义好的规则,将特定的基本数据类型集合(内建数据类型)转译成二进制的表示形式,并写入一个流,将服务参数序列化与反序列化到二进制流中。由于大部分复杂数据类型都由基本数据类型结合产生,可以顺序地将他们包含的基本数据类型转译到二进制格式。因为这是基于在数据链路上较小的体积和高效的编码格式,所以可以提供快速数据编解码。

安全协议

两类安全协议,都基于一个基于证书的连接建立。

WS-SecureConversation

为通信定制的协议,对XML进行加密和签名。

UA-SecureConversation

WS-SecureConversation + TLS

传输协议

  1. UA TCP 简单,提供特殊错误恢复,允许会话在网络中断时保持存活。
  2. SOAP/HTTP 防火墙友好,高层。

总结

OPC UA首先是一个架构,这个架构的主体是地址空间。地址空间其实就是一个网状图,由一些可以互相引用到的节点组成。节点可以类比成数据结构链表中的节点,即由两部分组成,数据和指针(在OPC UA中是引用),数据部分存放节点相关的信息。

对节点的读写操作可以通过数据库,这样可以比较好的解决同步异步问题,因为数据库本身就有一个原子性的特点嘛。对于订阅操作,其实是设计模式中一个拓展后的观察者模式,数据一旦发生变化,就由服务器端直接发送一条消息给客户端,这样可以节省一些资源。不过在数据库设计中可能需要增加trigger触发器,再通知客户机,并将改变的数据添加到历史消息队列中(用于维护历史数据集)。

如果不通过数据库,对于读写操作,就需要手动控制同步异步和进程/线程互斥,可以用synchronized、lock或者更自由的PV信号灯之类的。然后订阅操作就是由服务器端监测到底层设备的某个值发生改变,发送一条消息给客户机,同时进行历史数据的维护。

对于数据编码,安全协议,传输协议在实际工程中考虑较少,我了解得也有限就不写了。













2021.2.7

posted @ 2021-04-10 09:36  Cotmar  阅读(1796)  评论(0编辑  收藏  举报