OPC-UA信息建模
OPC UA信息建模
为什么要对信息建模
OPC UA的基础是数据传输和信息建模。
相对于传统的OPC,数据传输已经是艺术级的、平台独立的、安全的、技术可靠的技术了,同时信息建模的能力也获得了大幅度提高。传统OPC只能提供纯数据,例如,由温度传感器测量出来的温度。要了解已提供的数据是什么语义,可以利用的信息就只是测点的名称和一些类似测量值的工程单位的基本信息。OPC UA提供更有效的展示数据语义的可能性。除了由传统OPC提供的数据,它允许对外展示这样的信息:测量的温度是由一个特定类型的传感器设备提供的,并允许暴露该种设备支持的类型层次。因此, OPC UA的客户端可以获得它们在处理不同地方的同类设备的信息。通过暴露更多的语义,OPC UA的服务器允许客户端通过解释所提供的数据的语义来处理非常复杂的任务。它包括自动集成由OPC UA服务器提供的数据,就像在一个普通的OPC UA客户端上设计OPC UA服务器一样。
基本的OPC UA规范只提供模型信息的基础设施,这些信息可以由供应商建模。当然,这会导致对类似的信息有不同的建模方式,从而给OPC UA客户端造成困难。为了避免这种情况, OPC UA规范提供了基于OPC UA规范定义信息模型的可能性。OPC基金会已经开始创建这些规范。例如,已经尝试定义一个基本模型,用来展示OPC UA的设备信息和设备类型[UA设备]。供应商将使用此基础模型,并且使用与设备相关的供应商特定信息来,这个模型。客户可以用相同的方法访问不同的、供应商特定的OPC UA服务器提供的设备信息,因为它们是在一个类似的、使用相同基本模型的方式暴露出来的。此外,因为都使用相同的基本模型,供应商可以把通过OPC UA提供数据的第三方设备轻松地无缝整合到自己的服务器中。
OPC UA信息建模的基础原则
- 使用面向对象的技术，包括类型层次结构和继承。
- 类型信息对外暴露，并且能够以访问实例一样的方式访问。 类型信息是由OPC UA服务器提供的，并且可用访问实例一样的机制去访问。类似于关系数据库中通过SQL语句访问数据库表中的信息。
- 全网状的节点网络，允许信息以各种方式连接。
- 类型层次结构以及节点间引用类型的扩展性。
- 没有限制如何对信息建模，以便为所提供的数据建立适当的模型。
- OPC UA 的信息建模工作总是在服务器侧完成的。
下面通过一个例子来看看OPC UA的建模能力。设备供应商提供了一个传感器,如下图所示。该装置具有一定的配置参数和一些测量值,这些测量值可能因为配置不同而不同。一个使用之前提到的基础设备模型的OPC UA服务器提供了这些信息。
节点和引用
OPC UA建模的基本概念是节点以及节点之间的引用。
节点可以根据不同的用途归属于不同的节点类别（NodeClass）。
节点包含属性和引用，如下图。
地址空间里节点被实例化后，节点类别属性的值将提供。OPC UA节点有七个通用属性。
节点之间的关系用引用来表示，地址空间是由引用连接起来的节点网，通过它来表示数据交换的各种信息。引用不能直接访问，只那个间接地通过浏览节点访问，引用并没有表示为节点，不能包含任何属性和特性。
注意：虽然引用不是节点，但是引用类型在地址空间中被当作节点。
引用类型出了包含节点的通用属性还包含下面的附加属性：
节点和节点之间可以互相引用（引用类似于指向节点的指针）
OPC UA规范定义的完整引用类型层次机构：
对象、变量和方法
在OPC UA 中，最重要的节点类别（NodeClass）是对象、变量和方法。
熟悉面向对象的话，我们知道，对象可以拥有变量和方法。
举个例子：把电动机（Motor）看成一个对象，它包含了状态（Status）,一个配置（Configuration）对象，加上开始（start）停止(stop)的方法。
客户端可以读取订阅变量，调用方法。
如图，是一个对象包含对象、变量、方法和生成事件的概念。
- 电机对象Motor包含Status变量，而Status变量使用HasTypeDefinition引用继承自BaseDataVariableType。客户端可以订阅该变量，从而在电机状态变化时得到通知。
- Motor对象有一些配置变量，在Configuration对象下管理着。客户端可以读取或订阅这些变量。其中Torque变量代表电机的转矩，其工程单位使用HasProperty引用，被定义为TorqueUnit的特性。
- Motor对象下有Start和Stop两个方法，客户端可以调用方法来操作电机。
- Motor对象的EventNotifier属性，定义了电机的事件，客户可以订阅事件来掌握电机的相关动态。
当不止存在一个电机时，则需要定义一个复杂的对象类型，通过实例化对象类型来产生具有共同属性的电机对象。
那么上图中的Motor对象，则可使用HasTypeDefinition引用，指向MotorType对象类型，通过实例化，产生多个电机。此时MotorType对象类型变成了一个自定义的类型节点，但MotorType下的对象、方法和变量，仍旧还是继承自基本节点类型。
对象和变量类型
OPC UA的地址空间定义了两种节点类别(NodeClass), ObjectType用来定义对象类型,而VariableType用来定义变量类型。
对象类型
对象类型，我们可以简单认为它就是面向对象的一个类，通过下面的例子，一个Employee类和对应对象类型的映射关系，就可以很清楚的了解。相对的，创建实例就相当于我们用这个类new()了一个对象。
变量类型
OPCUA规范第5部分定义了基本的变量类型——BaseVariableType.
BaseVariableType下面是基本数据类型和属性类型。
变量类型自然是定义各种类型的变量的，这里我们可以认为是为了表示对象的某种属性定义的结构体，当然它也可以直接是一些简单的变量类型。
通过下面几个图我们可以清楚知道OPCUA的基本类型。
一共分为六种类型：
DataTypes，数据类型层次结构：
BaseEventType,事件类型层次结构：
Reference，引用类型层次结构：
另外的三种类型没有层次图。。。
地址空间
OPC UA 的信息由地址空间向外展示，地址空间被定义为“在客户端能显示 OPC UA服务器收集的信息”，OPC UA 客户端通过地址空间来访问服务器提供的数据和信息。地址空间的基本组成是节点，它通常用来表示服务器所有的信息，节点之间的相互连接依赖各种类型的引用。地址空间是由引用连接起来的节点网，通过它来表示数据交换的各种信息。
信息模型
信息模型主要定义了地址空间中的节点,OPC UA 的服务器为对象和变量提供类型定义。通过 Type Definition Node (类型定义节点)中的 Has Type Definition 引用来连接类型定义和实例，Has Type Definition 是必须的。然而，如果没有更好的类型信息可用，规范中定义的 Base Object Type、Property Type 和 Base Data Variable Type 能作为基本类型。
地址空间模型、信息模型和实例数据之间关系
OPCUA信息建模的流程
把信息建模分为四个详细步骤：
(1) 需求获取主要是从系统框架图和应用场景图中获取建模需要的设备类型、设备的参数即属性、设备具有的方法即事件，以及设备之间或设备与属性、设备与方法之间的关系,然后，根据特定领域相关规范来验证建模需要的信息，同时进行必要的补充，最后对这些节点信息归入八个标准的节点类别。
(2) 定义类型模型主要根据节点类别中的 4 个类型，分别定义对象类型模型、变量类型模型、引用类型模型、数据类型模型，然后合并为统一的类型模型，在定义这些模型时，UA 规范中已经存在的内置类型，可以不定义，在定义类型模型中仅仅显示根据特定领域扩展的类型，
(3) 类型模型定义之后，根据特定领域的具体实例对 4 个类型模型进行实例化，同时按照 OPC UA 服务器的标准地址空间方式，建立实例化信息模型。
(4) 利用 UA Address Space Model Designer 工具导出 XML 和 CSV 文档，作为实现实例化信息的数据来源。
OPCUA建模工具有：UAmodeler,opcua-modeler等。
设备对象 -> 提取设备属性 -> 实例化信息模型 -> 生成XML描述文档 ->绑定数据源
OPCUA客户端和设备交互的两种方式
一种是客户端的服务请求，服务请求经底层通信实体发送给OPCUA通信栈，通过OPCUA服务器接口调用请求或响应服务， 请求的任务将在服务器的地址空间中执行，执行完成后返回一个响应消息。
另外一种为发送发布请求，请求服务器发布数据或通知消息，发布请求经过底层通信实体发送给 OPCUA 通信栈，通过OPCUA服务器接口发送给预定端，当预定指定的监测 项探测到数据变化或者事件、报警发生时监视项生成一个通知发送给预定并由预定发送给客户。
基于OPCUA的系统数据交互流程
