通讯协议015——全网独有的OPC AE知识二之条件

本文简单介绍OPC AE规范的条件概念，更多通信资源请登录网信智汇(http://wangxinzhihui.com)。OPC AE规范描述了OPC事件服务器应该实现的对象和接口，实现在多个OPC客户端间共享事件和警报条件。

警报是一种异常条件。条件是OPC事件服务器的一些过程状态集合。例如，标签FIC101可能具有“LevelAlarm”或与之相关的“偏差警报”条件。条件可以被定义（可选地）为包括多个子条件。例如LevelAlarm条件可能包括“HighAlarm”、“HighHighAlarm”和“LowAlarm”，以及“LowLowAlarm”子条件1。

在OPC事件服务器中，条件由OPCCondition2类型的对象表示。每个OPCCondition与一个OPCSource相关联，如下图所示。OPCSource可以是过程标签（例如FIC101）或可能的设备或子系统。如果OPC事件服务器是OPC DA服务器，OPCSource也可能是OPCItem。

1、子条件

条件可以是单一状态，也可以是多状态。多状态条件是指其状态包含多个感兴趣的“范围”或子状态。例如，“LevelAlarm”条件可能具有多个子状态，包括“HighAlarm”和“HighHighAlarm”。

表示每个子状态，由OPCSubCondition类型的对象（该对象也不是COM对象）执行。每个OPCSubCondition与一个OPC条件相关联，如下图所示。多状态条件的子状态必须互斥，例如标签不能同时处于HighAlarm和同时发出HighHighAlarm。

子条件允许客户更容易地处理密切相关的事件通知，使得客户端更容易检测并正确显示报警。例如：FIC101 从“HighAlarm” 切换到 “HighHighAlarm” ，这些子状态被建模为相同条件（“LevelAlarm”）。如果建模为独立的条件，则很难确定这些条件如何排斥。

单个状态条件只有一个子状态感，因此只有一个子条件。比如“硬件故障”，其中硬件设备要么处于故障状态，要么不处于故障状态。

2、 OPCConditions属性

每个OPCCondition都具有以下属性：

        Name：条件名称，例如“LevelAlarm”。条件名称在事件服务器中必须是唯一的。

        Active：关联的对象当前处于由条件表示的状态。

        ActiveSubCondition：如果处于活动状态，这是当前处于活动状态的SubCondition的名称。对于单状态条件，该值将是条件名称。例如：如果LevelAlarm条件处于活动状态，则ActiveSubCondition值可能为“高报警”。

        Enabled：条件激活/禁止。

        Quality：条件所基于的数据值的当前质量。

        Acked：如果条件激活，则表示条件已得到确认。

        LastAckTime： 最近确认的时间。

        SubCondiLastActive：最近转换到当前活动子条件的时间。这是确认时必须指定的时间值

        CondLastActive：最近转换到此状态的时间。

        LastInactive：此条件下最近一次转换的时间。

        AcknowledgerID：上次确认此条件的客户端的ID。

        Comment：上次确认此条件时，客户端传入的备注。

3、Condition质量

条件（Condition）通常基于一个或多个具有“质量”属性的OPCItem。条件也有相关的质量。如果过程值为“不确定”，则“LevelAlarm”情况也令人怀疑。与OPCItems一样，条件将具有强制的“质量”属性。当质量发生变化时，它将生成一个事件通知。

由服务器决定如何获得“质量”的值。服务器也可能定义一种特殊的EventCategory，用于报告值的不良质量属性。

质量属性的值符合OPC DA中的OPC质量标志定义规范。

4、OPCSubConditions属性

每个OPCSubCondition都具有以下属性：

        Name：子条件的名称。例如“HighAlarm”表示“液位报警”。在单一状态报警的情况下，子条件名称为与关联的条件名称相同。子条件的名称必须为在其相关条件下是唯一的。

        Definition：由子条件表示的子状态的表达式。

        Severity：此子条件生成的任何事件的严重性。请注意，同一条件的不同子条件可能具有不同的严重程度。

        Description：子条件生成的事件通知中的文本字符串。

5、Condition定义

条件定义是特定于服务器的。例如：

        1）一个或多个OPCItem上的布尔表达式。例：FIC101.PV>100和FIC101.PV<150。这是LevelAlarm条件的HighAlarm子条件的定义。

        2）引用由底层系统或设备定义的条件的文本字符串，例如：“设备故障”。

        3）与OPC事件服务器相关联的条件的文本字符串。例如：

        •在指定时间关闭

        •服务器过载

        •底层系统/设备故障

        •等等。

6、严重性

严重程度值表示子条件的紧急程度。这也通常被称为“优先级”，尤其是与过程警报有关的优先级。值的范围从1到1000，其中1是严重性最低，1000为最高。通常，严重性为1表示信息性事件，而1000的值表示灾难性事件，可能导致严重的经济损失或生命损失。

预计很少有服务器实现能够支持1000个不同的严重性级别。因此服务器开发人员负责将其严重性级别分布在1–1000范围内，客户端可以采用线性分布的方式。例如：

下图为底层设备严重性到OPC严重性范围的映射表。

有些服务器可能不支持任何灾难性事件，因此它们可能会选择映射它们的所有严重程度都划分为1–1000范围的一个子集（例如，1–666）。

7、Condition启用/禁用

客户端可以启用和禁用条件。

        •服务器可以选择在被禁用时继续测试某个条件。但是，无法生成事件通知，也无法确认。

        •禁用状态下是否定义以下条件属性取决于服务器：

        Active、ActiveSubCondition、Quality、Acked、LastAckTime、SubCondLastActive、CondLastActive、LastInactive、AcknowledgerID和Comment。

        •在刷新时，将不会为禁用条件生成事件通知。

        •启用时，与“激活条件”事件通知关联的时间属性为启用后首次发现该条件的时间，或该条件变为活动状态的时间。

8、 Area启用/禁用

客户端可以启用和禁用区域。

如果源的条件状态设置为“已启用”，并且的层次结构中的所有区域都已启用，则源启用。

如果源的条件状态设置为禁用或其层次结构中的任何区域禁用，则该源将被禁用。

举例说明，如下图所示。

图中以“S”命名的对象为源，以命名的对象为区域。高亮显示的对象处于禁用状态（即，A2、A11、S3和S5被禁用）。假设客户端正在订阅模型中所有区域和源的事件。

        1）尽管源“S2”为启用状态，但是A11不是。因此，客户端不能接收到这个条件的事件。

        2）源“S4”为启用状态，且包含的区域（A12，A1以及A0）君均为启用，所以，客户端没可以接收到这个条件的事件。

        3）源“S5”为禁用状态，尽管包含的区域都已启用，客户端不能接收到这个条件的事件。

9、Condition状态集

下图为OPC Condition的示例状态机。

        1）每个状态转换都是一个事件。在每次状态转换时都会发送事件通知消息。

        2）每个与条件相关的事件通知，需要确认的包括：条件名称、条件最近进入活动状态或转换为新的子条件的时间，以及事件通知的唯一标识Cookie。信息由OPC客户端在确认条件时指定，OPC事件服务器识别正在发生的特定事件（状态转换）使用此信息。。如果接收到具有过期的SubCondLastActive属性的确认（这可能是由于系统中的延迟造成的），条件状态不会得到确认。

        3）请注意，确认会影响条件状态，如果条件当前处于活动状态或它当前处于非活动状态，并且最近的活动状态未被确认。如果不活动，未确认条件再次变为活动状态，所有后续确认都将被验证，针对新激活的条件状态属性。服务器可以选择使用Cookie属性的事件通知，以记录“旧”条件激活的确认，但此类“晚”确认对该状况的当前状态没有影响。

        4）条件激活状态的确认可能来自OPC客户端，也可能是由于OPC事件服务器内部的逻辑。例如，对相关OPC条件的确认，可能导致该OPC条件被确认，或者OPC条件可能被设置为当条件变为不活动时自动确认。

        5）对于不跟踪或不需要确认的情况，状态转换更简单——只是在启用-非活动、启用-活动和禁用状态之间切换。

        6）建议事件服务器生成用于启用和禁用操作的跟踪事件，而不是为每个被启用或禁用的条件实例生成事件通知。如果不符合这个建议，则按区域启用和禁用可能会导致大量事件通知。

更多通信资源请登录网信智汇(http://wangxinzhihui.com)。