OPCAE扫盲

目录

1 基本概念

1.1 服务器/客户端

1.2 区域

1.3 报警/条件

1.4 事件

2 条件概念

2.1 子条件

2.2 OPCConditions属性

2.3 Condition质量

2.4 OPCSubConditions属性

2.5 Condition定义

2.6 严重性

2.7 Condition启用/禁用

2.8 Area启用/禁用

2.9 Condition状态集

3 事件概念

3.1 事件通知

3.2 简单事件通知OPCSimpleEventNotifications 属性

3.3 跟踪事件通知OPCTrackingEventNotifications属性

3.4 条件事件通知OPCConditionEventNotifications属性

3.5 事件类别

3.6 订阅事件通知

3.7 OPCEventSubscriptions属性

3.8 条件状态同步

3.9 错误处理

---

1 基本概念

本文简单介绍OPC AE规范的基本概念。 OPC AE规范描述了OPC事件服务器应该实现的对象和接口，实现在多个OPC客户端间共享事件和警报条件。OPC官方说明文档

1.1 服务器/客户端

OPC AE有几种类型的OPC报警和事件服务器。至少支持：

     •组件能够检测到警报/事件，并将其报告给一个或多个客户端。

     •组件可以从多个来源收集警报和事件信息，并将其报告给一个或多个客户端。

OPC报警和事件服务器的客户端通常是订阅和显示的组件，处理、收集记录报警和事件信息。OPC报警和事件服务器的客户端可能包括（但不限于）：

     •操作员站

     •事件/报警记录组件

     •事件/警报管理子系统

下图为OPC AE服务器/客户端的典型结构图。Alarm/Event management Server既是OPC AE Server，也是OPC AE Client。它从Alarm/Event数据源Device Alarm Info和SPC Module采集事件/报警，并将其报告给OPC AE客户端Opeator Station1、Event Logger。

                   

实现IOPCEventServer接口的任何COM对象都是OPC事件服务器。IOPCEventServer接口提供了一些方法，使OPC客户端能够：

     •确定OPC事件服务器支持的事件类型。

     •输入指定事件的订阅，以便OPC客户端可以接收其事件。

     •指定在OPC事件服务器关闭时要调用的客户端回调接口。

1.2 区域

服务器中可用的事件和条件被组织在一个或多个内工艺区域。区域是工厂设备的分组，通常根据操作员责任来划分。如果区域可用，客户端可以创建一个OPCEventAreaBrowser对象来浏览过程区域组织。客户端可以通过指定进程区域来筛选事件订阅，限制服务器发送的事件通知。

1.3 报警/条件

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

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

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

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

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

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

 

1.4 事件

事件是可检测的发生的事情。事件可能与条件相关，也可能不相关。例如，转换到LevelAlarm状态和恢复正常是与条件相关联的事件。而操作员操作、系统配置更改和系统错误则是与条件无关的事件。

事件在OPC模型中没有直接表示。通过Event Notification告知事件发生，由OPCEventNotification3类实现。

   存在以下三种事件类型：

 1）条件事件：与OPCConditions相关的事件，表示进入或退出由OPCConditions和OPCSubConditions表示的状态转换。例如：FIC101转换为LevelAlarm状态和HighAlarm子状态。

 2）跟踪事件：不与条件相关联的事件，表示发生的事件涉及OPC客户端与OPC事件服务器内的“目标”对象的交互。例如：控制更改，操作员（OPC客户端）更改标签FIC101的设定点（“目标”）。

 3）简单事件：是除上述事件之外的所有事件。例如：由OPC事件服务器表示的系统/设备内的组件故障。

2 条件概念

OPC AE规范描述了OPC事件服务器应该实现的对象和接口，实现在多个OPC客户端间共享事件和警报条件。

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

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

2.1 子条件

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

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

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

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

                   

2.2 OPCConditions属性

每个OPCCondition都具有以下属性：

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

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

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

Enabled：条件激活/禁止。

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

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

LastAckTime： 最近确认的时间。

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

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

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

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

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

2.3 Condition质量

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

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

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

2.4 OPCSubConditions属性

每个OPCSubCondition都具有以下属性：

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

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

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

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

2.5 Condition定义

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

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

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

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

•在指定时间关闭

•服务器过载

•底层系统/设备故障

•等等。

2.6 严重性

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

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

 

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

 

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

2.7 Condition启用/禁用

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

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

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

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

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

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

2.8 Area启用/禁用

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

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

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

举例说明，如下图所示。

 

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

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

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

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

2.9 Condition状态集

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

 

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

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

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

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

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

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

3 事件概念

OPC AE规范描述了OPC事件服务器应该实现的对象和接口，实现在多个OPC客户端间共享事件和警报条件。

事件是一种可检测的对OPC事件服务器、设备、OPC客户端具有重要意义的事情。事件可能与条件相关，也可能不相关。例如，转换到LevelAlarm状态和恢复正常是与条件相关联的事件。而操作员操作、系统配置更改和系统错误则是与条件无关的事件。

事件在OPC模型中没有直接表示。通过Event Notification告知事件发生，由OPCEventNotification3类实现。

   存在以下三种事件类型：

1）条件事件：与OPCConditions相关的事件，表示进入或退出由OPCConditions和OPCSubConditions表示的状态转换。例如：FIC101转换为LevelAlarm状态和HighAlarm子状态。

2）跟踪事件：不与条件相关联的事件，表示发生的事件涉及OPC客户端与OPC事件服务器内的“目标”对象的交互。例如：控制更改，操作员（OPC客户端）更改标签FIC101的设定点（“目标”）。

3）简单事件：是除上述事件之外的所有事件。例如：由OPC事件服务器表示的系统/设备内的组件故障。

3.1 事件通知

OPCEventNotifications使用由OPC客户端在事件订阅中提供的连接点回调接口发送到订阅客户端。OPCEventNotifications的层级结构如下图所示。

                   

3.2 简单事件通知OPCSimpleEventNotifications 属性

OPCSimpleEventNotifications具有以下标准属性。请注意OPCConditionEventNotifications和OPCTrackingEventNotifications也包括这些标准属性。

Source：生成事件通知的对象的引用。例如：当标签FIC101进入LevelAlarm条件（与条件相关的事件），Source就是标签名FIC101；它也可以是跟踪事件，如操作员更改FIC101的设定点值，Source就是标签名FIC101；对于简单事件，如系统错误，Source值可能为“system”。

Time：事件发生的时间。

Type：条件事件、跟踪事件、简单事件。

EventCategory：事件所属的类别。

Severity：事件的紧迫性。可能的取值范围为1-1000。

Messgage：描述事件的消息文本。对于与条件相关的事件，一般包括活动子条件的描述属性。

3.3 跟踪事件通知OPCTrackingEventNotifications属性

OPCTrackingEventNotifications除了具备OPCSimpleEventNotifications的属性，还具备以下属性：

ActorID： 发起导致跟踪相关事件的操作的OPC客户端的标识符。例如，如果跟踪相关事件是FIC101的设置点的更改，则ActorID可能是对发起更改的客户端应用程序的引用，或者可能是指定更改的操作员的用户ID。

3.4 条件事件通知OPCConditionEventNotifications属性

OPCConditionEventNotifications除了具备OPCSimpleEventNotifications的属性，还具备以下属性：

ConditionName：关联OPCCondition名称

SubConditionName：当前激活的OPCSubCondition的名称

NewState：表示条件的新状态。表示条件的Enabled、Active和Acked属性新值

AckRequired：是否需要确认的标识符。许多事件与条件相关的通知通常不需要确认，例如：接收到确认或转换到非活动状态。此外可以配置一些条件，对于转换到该状态，或子条件之间的转换（例如转换为LevelAlarm或转换从HighAlarm到HighHighAlarm）不需要确认。在这种情况下，服务器自动将条件置于已确认状态，因此将永远不会收到确认。

ActiveTime：转换到事件通知的相关条件或子条件的时间。

Cookie：服务器定义的与事件通知关联的cookie。客户在确认时使用此值。该值对客户端是不透明的。

ActorID：确认条件的OPC客户端的标识符。

3.5 事件类别

EventCategories定义OPC事件服务器支持的事件分组。例如：事件类别可能包括“过程事件”、“系统事件”或“批处理事件”。事件类别可以为所有事件类型定义，即简单、跟踪和条件相关。特定事件类别可以仅包括一种类型的事件。给定来源（例如“System”或“FIC101”）可以为多个事件类别生成事件。事件类别的名称必须为在事件服务器中是唯一的。

事件类别的名称包含在每个事件通知中。事件订阅可以是根据事件类别筛选。

3.6 订阅事件通知

为了接收事件通知，OPC客户端必须订阅这些通知。订阅通过后，创建一个OPCEventSubscription对象与OPC事件服务器进行交互。OPC客户端可以有一个或多个OPCEventSubscriptions对象与单个OPC事件服务器进行交互。

OPCEventSubscriptions是“可连接对象”，因为它们实现DCOM连接点接口。这是用于向OPC客户端发送事件通知的机制。

OPCEventSubscriptions提供了一个接口，允许OPC客户端指定筛选器。此外它们实现了标准的DCOM连接点接口，将事件发生通知OPC客户端。

3.7 OPCEventSubscriptions属性

OPCEventSubscription具备如下属性：

Filter：用于选择客户端感兴趣事件的结构。空过滤器会导致OPC客户端接收所有事件通知。

OPCEventSubscription只有一个筛选器。

可以使用以下标准选择事件：

•事件类型：即简单、条件或跟踪。

•事件类别

•最低严重性，即严重性大于或等于指定严重性的所有事件。

•最高严重性，即严重性小于或等于指定严重性的所有事件。

•过程区域

•事件源

单个标准的值列表在逻辑上被“或”运算在一起（例如：如果指定两个事件类别，将接收两个类别的事件通知）。如果指定了多个标准，它们将被逻辑地“与”在一起，即仅那些满足所有标准的事件将被选择。例如：指定最低优先级和最高优先级，将导致事件的选择优先级介于两个值之间。

例如：

Type = CONDITION

Category = PROCESS

LowSeverity = 600

Area = AREA1, AREA2

   以上表示选择区域AREA1、AREA2内具有高紧急性（大于或等于600）的“过程”类别的条件关联事件。

       

3.8 条件状态同步

OPC客户端通过向每个活动的OPCEventSubscription对象请求“刷新”，获得所有处于活动或处于非活动但未确认的条件状态。服务器通过事件回调机制向客户端发送适当的事件。当调用客户端的回调时，服务器将指示调用是用于刷新还是原始通知，刷新和原始事件通知将不会混合在同一个回调调用中。

此设计假设客户端只需要条件的当前状态信息，因此仅将与条件相关的事件通知刷新。需要注意的是，“刷新”不是一般的重放功能，因为服务器不需要维护事件历史记录。

刷新事件通知可能以任意顺序发送，并且可能不按顺序发送。当服务器回复刷新请求时，条件可能会更改状态，刷新事件通知可能不再反映客户端接收到它时的当前条件状态。类似地，客户端可以在接收到刷新事件通知之后接收原始事件通知。客户端需要比较时间戳，以确保其状态正确情况。

客户端必须显式调用Refresh（）方法才能获得刷新事件通知。这是与OPC DA接口不同，在OPC DA接口中，激活或向组添加项目会导致隐式刷新。

3.9 错误处理

OPC事件服务器可能会将内部或源错误报告为标准事件，可能是简单事件或条件相关事件。服务器错误的事件属于OPC_SERVER_ERROR事件类别。

在事件源失去通信的情况下，该事件源的当前活动条件源应该更新其质量属性以表示通信丢失。可以通过将质量设置为“坏”并将子状态设置为“通信故障”来完成。这一质量变化必须向所有订阅者发出事件通知。