基于图数据库的物联网模型事件和告警

Posted 2021-06-29 姚家湾

 

   伊萨维（Issawi）的捷径法则——捷径是两点之间的最长距离。

       （A shortcut is the longest distance between two points.）

世界上的许多事情没有捷径。系统是复杂的，解决之道必然也是复杂的。和读者共勉。

  在一个物联网系统中，除了数据采集之外，还有两个非常重要的功能，就是控制和事件两部分。 

        控制是控制端发送给设备的命令（Command），而事件是设备端出现某些状况主动发送给控制端的信息。 控制端通过订阅的方式来指明希望接收某些事件。控制端和设备端的控制与事件的关系如下：

命令

命令的实现比较简单，可以通过 method 来实现。method 是一个object 几点，包括如下几个属性name 方法名称
输入参数

输出参数

    -结果码（result code）

OPC UA 的Alarm & Event 机制

      前面提到过，我们希望采用类似opc ua 的信息模型来构建物联网系统。所以我们首先来研究一下opc ua 的alarm&Event 机制。

  opc ua 的消息模型比较复杂的，很烧脑。我是从下面两个路线来理解的。

事件

事件相当于消息。在opc ua 中，事件是一个object 类型的节点。它主要用来描述事件。事件又派生出来condition 和alarm 。在iot 中，可以简化一点，直接来构建condition和alarm 节点。

 

事件的传递

在一个服务器中可能有许多的事件会产生。client 可能会订阅阅各种事件。这样就造成了事件的传递是比较复杂的过程。我们来看看opc ua 是如何建立事件传递的模型的。

事件源自于三个方面：

1 变量，周期低采用变量的值，当超过某个范围的时，产生一个事件。

2 该节点订阅的事件。如果一个节点订阅了某个事件，这些事件可以发送给订阅该节点事件的节点或者客户端。例如 一个环境传感器具有温度和湿度两个变量，当温度或者湿度超标时都会产生事件

 2 变量值。通过计算产生的事件。

opc ua 节点之间引用关系

在opc ua 中 使用HasNifier，HasEventSource，HasCondition来描述节点之间事件通知的引用关系的。

opc ua 的引用类型

这里我们重温一下opc ua 的引用类型的概念：

OPC UA 中的reference 的语义是节点之间的关系。reference 类型可以理解为类似于C++ 中的指针类型（point） 它指向另外一个节点。

         引用是引用类型的实例。可以在object 节点中定义一个引用 ，其中 target 指向另外一个节点。

理解了opc ua 的引用类型后，有助于我们理解Event 的机制。HasNifier，HasEventSource，HasCondition都是引用类型。它们表示了节点的关系

server->HasNotifier->Area1 表示有来自于Area 1的通知。

Tank A-> HasEventSource->levelMeasurement 表示 TankA 有来自于levelMearsument 的事件源。

• HasEventSource、HasNotifier有什么区别
  • HasEventSource指明了事件产生的源
  • HasNotifier是HasEventSource的子类
  • HasNotifer组织的是一张通知器的网，关系的目标节点所产生的事件在源端也可以看到，可供用户定义自己查看事件的范围
  • Condition只能加到HasEventSource的目标节点上

event，condition和alarm的关系

• 事件的父节点是object 类型的节点

• EventType是ConditionType的父类
• ConditionType是AlarmType的父类
• Event、Condition和Alarm是其实例
• Event最为泛化，主要是定义了事件的基本属性
• Condition则拥有状态
• Alarm则拥有更多可被设置的状态

物联网中Event，Alarm 和command 的机制

在我们基于图数据库的物联网中，信息模型和opc ua 的信息模型有所不同。

       首先 Iot 设备和iot 模型服务器的分离的。也就是说，iot 设备的数据，事件首先要通过某种网络的协议传送到IoT  模型服务器上，虽然设备上也可以实现opc ua 信息模型服务器，但是那样做毕竟过于复杂了。我们更倾向使用non opc ua 协议与iot平台连接。

     在Iot 平台上 ，设备传输到平台的数据有两个tag 一个是时间序列数据的 datapoint，它在整个iot系统中是唯一的。另一个是可以是Asset 。表示Iot平台处理消息的方式

•  存储到实时数据库
•  存储到实时数据库的同时，传输给图数据库处理
• 只传送到图数据库处理

event 的定义方式

事件和告警可以定义为一个Condition （object 类型）

HasNifier，HasEventSource，HasCondition的定义方式

它们是引用类型，定义节点的关系。在上面的图中，Condition - >[REF]  variable 关系要显式定义。

iot 平台运行时处理流程

• 当iot 平台接收到设备端发送的变量值时，存储到时间序列数据库中。
• 如果有 Asset tag 就传输给iot平台运行时，查找datapoint 的变量节点。插入value。
• 如果该节点具有HasCondition关系的节点，就顺藤摸瓜找到所有hasNotify 的节点，具有HasNotifier 的节点是订阅该事件的App 模型（例如下图中的web server）。是动态建立的。iot 运行时向该App 发送事件。

 

存在的问题

还有一堆事情需要进一步研究。

1 图数据库的查询效率如何？

2 iot 运行时的API如何设计？

3 设备的信息模型，协议如何安排？