山东省交通厅建设网站,沃尔玛网上商城中国,网页设计与制作考试2020,app网站建站系统目录 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状态集…目录 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.PV100和FIC101.PV150。这是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”为启用状态且包含的区域A12A1以及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事件类别。
在事件源失去通信的情况下该事件源的当前活动条件源应该更新其质量属性以表示通信丢失。可以通过将质量设置为“坏”并将子状态设置为“通信故障”来完成。这一质量变化必须向所有订阅者发出事件通知。
