示例客户端 UaExpert UaExpert OPC UA客户端示例显示了如何能通过订阅方式接收 OPC UA 服务器的事件。以下 是有关所示事件/报警的Zui重要的信息： •事件视图是在数据访问视图之外的一个单独的事件视图。 • “Configuration”区域包含所选的事件信号传送对象，以及Select 语句的字段。目前，在 UaExpert 中不支持组态 Where 语句。 •在“Events”区域中，“Events”选项卡：对应于“报警归档”(Alarm archive) 按钮已激活的 TIA报警视图；其中也将显示离开的报警和“仅供参考”(Information only) 类别的事件，因为 UaExpert会在后台对其进行缓冲并支持进行显示。这些事件在“报警”(Alarms) 选项卡中 不可见。 •在“Events”字段中，“Alarms”选项卡：对应于“当前报警”(Current alarms) 按钮已激活的 TIA报警画面；其中将显示报警及其状态，例如，“激活”(active)（对应于“进入”(incoming)），并且这些报警也可通过快捷菜单进行确认。离开的报警将不会再在此 视图中显示。在事件区域的各个列中提供一系列事件字段，例如，事件文本 (Message) 以及报警是否已确 认(A=Acknowledged)。
CPU 的 OPC UA 服务器针对报警显示提供的特殊功能 下面再一次汇总了 OPC UA报警和条件的报警画面在反映当前状态上所提供的特殊功能。 主题 说明 注释 通过 OPC UA，用户可通过“AddComment”途径或“Acknowledge”方法为报警添加注释。此注释在服务器重启 后将不复存在。 而未决报警在服务器重启后将 不会丢失 OPC UA服务器支持“ConditionRefresh”方法，借此可在下 载新数据块之后（需要重启服务器并重新建立连接）或在其它此类情况下，将系统当前状态提供给 OPC UA 客户 端。 报警相关值的处理方式 (S7-1500, S7-1500T)用户可指定 SIMATIC 报警占位符。通过这些占位符，可将Zui多 10 个相关值（SD_1 到SD_10）集成到报警文本中。占位符也可以是特定的文本列表条目。 使用带有占位符的报警时，需遵循以下规则： •仅在系统诊断报警或安全事件报警中，才会在报警中自动插入代表相应值的占位符。对于其它类别的报警（如，程序报警），系统不会对这些值的占位符进行解析。OPC UA 客 户端必需对这些报警进行解析。 •引用文本列表的占位符由 CPU 进行解析（格式示例：%t#
CPU 的 OPC UA 服务器针对报警和条件注释提供的特殊功能 用户可以通过AddComment 方法为“SimaticAlarmConditionType”类型的报警对象添加注释。 在调用Acknowledge 方法时也将设置注释。“AddComment”方法可多次调用。 •注释保存在“Comment”事件字段。“Comment.SourceTimestamp”指示注释上一次设置的 时间。 •“Time”时间戳标记的是，报警对象上一次的修改时间。在调用“AddComment”方法时，“Time”和“Comment.SourceTimestamp”相同。在调用“Acknowledge”方法时，两个时间戳可能不同，因为确认不是同步进行的。 支持注释是 OPC UA报警和条件的强制要求。SIMATIC 报警系统没有相应报警注释的信息。因 此，一些特殊功能必须加以考虑： • 只有一个注释：某报警对象只有一个注释，因此在有多个方法连续进行调用时，既有注释始终都会受到 覆盖。 • 使用寿命和时间戳：注释仅存储在当前报警对象中。如果报警对象不复存在（例如，在服务器重启之后），相应的注释也将同样消失。相应的“Comment”和“Comment.SourceTimestamp”事件字段将 受到复位（归零）。“Time”事件字段也将设置，就像是方法调用“AddComment”从未存在过一般。示例：如果 对未确认的 Alarms报警对象添加注释，“Time”事件字段将收到此注释变更的时间。在服务器重启后，“Time”事件字段不会显示注释设置的时间，而是会显示相应 Event 到达的 时间。 处理 OPC UA报警和条件的存储器限制 (S7-1500, S7-1500T) S7-1500 CPU 的 OPC UA服务器根据产品的不同而对“报警和条件”功能有各异的有限存储 器容量（参见 CPU 规范）。 供有两个存储器池，分别存储不同类别的报警：• 仅适用于 ProgramAlarms 的存储器池（对应于与程序相关的报警源（生产者），例如基 于Program_Alarm、ProDiag、Graph 的程序报警） • 仅适用于 SystemDiagnostics的存储器池（对应于系统诊断报警） 在不利的条件下（例如，报警激增），CPU 无法将所有来自 SIMATIC 报警区域的所有未决报警（ProgramAlarms 或 SystemDiagnostics）提供给 OPC UA 报警和条件系统。但此时报警将不会丢失。用户可以在用户程序中就此过载事件做出响应。根据具体应用，用户可使用 “ConditionRefresh”方法来将“未能进入OPC UA 报警和条件系统”的报警再提供给 OPC UA 报警和条件系统。 要求 • 报警和条件已激活 • 事件订阅已在 OPCUA 客户端中设置 原理 下图显示了一个简化的过程，即，会将 ProgramAlarms 临时存储下来，并另寻时间来再次 提供给OPC UA 报警和条件系统。说明中提到的节点在以下地址模型图片中可见。① 活动报警的数量过多，无法通过 OPC UA报警和条件访问全部报警 ② 过载报警 (Overloads) 已触发。过载报警在发生以下情况之前保持激活： • 对于 OPC UA报警和条件系统，没有更多报警处于未决状态 (OutstandingProgramAlarms = 0)； • OPC UA报警和条件系统的报警数量 < 已清除滞后的 OPC UA 报警数量Zui大值 (= MaxAlarmsInQueue -OverloadHysteresis) 因过载情况而在 OPC UA 报警和条件系统中不可用的报警由 CPU作为“OutstandingAlarms”进行缓冲。 ③ 在 OPC UA 客户端执行 ConditionRefresh方法时，不仅相关订阅的所有报警对象都将同步，而且 OPC UA 报警和条件的未确认报警 (OutstandingAlarms)也将传送到报警和条件存储区中（但前提是未达到报警的Zui大数量）。“Zui早”的报警将Zui先传送。在此之后，这些报警的每个订阅（不jinxian于调用 ConditionRefresh方法的 OPC UA 客户端）都将收到已传送的报警。 ④ OPC UA 客户端通过“过载”(Overloads)节点的信息控制未决报警的处理。特殊功能 • 在未决报警转出或得到确认后，将不再经由 ConditionRefresh 方法进入 OCPUA 报警和 条件系统区域。于是，它们将对 OPC UA 报警和条件“不可见”，进而也无法由所连的 OPC UA客户端获取。这会影响报警进行过程的统计评估以及其它类似方面。 •为避免在报警数量围绕Zui大值上下波动时致使过载报警出现较高的报警频率，触发报警的限值要高于取消报警的限值：此差值显示在“OverloadHysteresis”节点中。示例：Zui大报警数量：200，OverloadHysteresis：3。 过载报警的数量在达到 200 时就开始触发，但只有在下降到197 以下时才会取消。如果 报警数量再次增加，仍需超过 200 才会触发报警。