5.服务集

5.12 MonitoredItem服务集

5.12.1 MonitoredItem模型

5.12.1.1概述

客户端定义MonitoredItems来订阅数据和事件。每个MonitoredItem标识要监视的项目和用于发送通知的订阅。要监控的项目可以是任何节点属性。

通知是描述数据更改和事件发生的数据结构。它们被打包到NotificationMessages中传送给客户端。订阅以用户指定的发布间隔周期性地发送NotificationMessages，发送这些消息的周期称为发布周期。

MonitoredItems定义了四个主要参数，它们告诉Server如何采样、评估和报告项目。这些参数是采样间隔、监视模式、过滤器和队列参数。图15说明了这些概念。

图15 - MonitoredItem模型

除了Value Attribute之外，只监视值的更改。筛选器不用于这些属性。这些属性值的任何更改都会生成一个Notification。

Value属性在监视变量时使用。对变量值进行监视，以了解其值的变化或状态的变化。本标准(见7.17.2)和OPC 10000-8中定义的过滤器用于确定值的变化是否大到足以导致为变量生成通知。

对象和视图可以用来监视事件。事件只在EventNotifier属性的SubscribeToEvents位被设置的节点中可用。本标准中定义的过滤器(见7.17.3)用于确定从节点接收到的事件是否被发送到客户端。该过滤器还允许选择EventType字段，将包含在事件中，如EventId, EventType, SourceNode，时间和描述。

OPC 10000-3描述了事件模型和基本的EventTypes。

基本EventTypes的属性和AddressSpace中基本EventTypes的表示在OPC 10000-5中指定。

5.12.1.2采样间隔

客户端创建的每个MonitoredItem都被分配一个采样间隔，该采样间隔要么继承自订阅的发布间隔，要么专门定义为覆盖该速率。负数表示请求由订阅的发布间隔定义的默认采样间隔。采样间隔指示服务器对其底层源进行数据更改采样的最快速率。

如果客户订阅事件，则客户端应定义采样间隔为0。

分配的采样间隔定义了一个“最佳努力”循环率，服务器使用该循环率从其源对项目进行采样。在此上下文中，“尽最大努力”意味着服务器将尽最大努力以这种速度进行采样。可以接受比此速率更快的采样速率，但对满足客户的需求来说并不是必须的。Server如何处理采样率以及它在内部轮询数据源的频率是Server实现的细节。但是，返回给客户的值之间的时间间隔应大于或等于采样间隔。

客户端也可以指定采样间隔为0，这表示服务器应该使用最快的实际速率。预计服务器将只支持有限的采样间隔集，以优化它们的操作。如果服务器不支持客户端请求的准确间隔，那么服务器将根据服务器确定的最合适的间隔分配给MonitoredItem。它将这个分配的间隔返回给Client。OPC 10000-5中定义的服务器能力对象确定了服务器支持的采样间隔。

服务器可能支持基于抽样模型收集的数据或基于异常模型生成的数据。支持的最快采样间隔可能等于0，这表示该数据项是基于异常的，而不是在一段时间内采样。基于异常的模型意味着底层系统不需要采样和报告数据更改。

客户端可以使用修改后的采样间隔值作为设置发布间隔和订阅的保持活动计数的提示。例如，如果MonitoredItems的最小修改采样间隔是5秒，那么发送keepalive之前的时间应该大于5秒。

请注意，在许多情况下，OPC UA服务器提供对解耦系统的访问，因此不了解数据更新逻辑。在这种情况下，即使OPC UA Server以协商的速率进行采样，底层系统也可能以慢得多的速率更新数据。在这种情况下，只能以较慢的速度检测到更改。

如果底层系统更新项目的行为是已知的，它将通过OPC 10000-3中定义的MinimumSamplingInterval属性可用。如果服务器为最小采样间隔属性指定了一个值，它将总是返回一个修正后的采样间隔，该值等于或高于客户端订阅的最小采样间隔。

客户端还应该知道OPC UA服务器的采样和底层系统的更新周期通常是不同步的。这可能会导致变更检测的额外延迟，如图16所示。

图16 -变更检测中的典型延迟

5.12.1.3监控模式

监控模式参数用于启用和禁用MonitoredItem的采样，并提供独立启用和禁用通知的报告。此功能允许将MonitoredItem配置为示例、示例和报告，或者两者都不配置。禁用采样不会改变任何其他MonitoredItem参数的值，比如它的采样间隔。

当启用MonitoredItem MonitoringMode时(即从残疾人抽样或报告)或是在启用状态,创建服务器应当向第一个样品尽快和这个样品的时间成为下一个采样间隔的起点。

5.12.1.4过滤器

每次采样MonitoredItem时，服务器都会使用为MonitoredItem定义的过滤器来评估采样。筛选器参数定义了服务器用来确定是否应该为示例生成Notification的条件。筛选器的类型依赖于正在监视的项目的类型。例如，在监视变量值时使用DataChangeFilter和AggregateFilter，在监视事件时使用EventFilter。本标准描述了采样和评估，包括滤波器的使用。其他过滤器可以在本系列标准的其他部分中定义。

5.12.1.5队列参数

如果示例通过了筛选条件，则会生成一个Notification，并由Subscription排队等待传输。在创建MonitoredItem时定义队列的大小。当队列满并收到一个新的通知时，服务器要么丢弃最旧的通知并将新通知放入队列中，要么用新通知替换添加到队列中的最后一个值。MonitoredItem在创建MonitoredItem时为这些丢弃策略之一配置。如果一个DataValue的通知被丢弃，并且队列的大小大于1，那么在DataValue statusCode的InfoBits部分的Overflow位(标志)被设置。如果discardOldest为TRUE，最老的值将从队列中删除，队列中的下一个值将设置标志。如果discardOldest为FALSE，添加到队列的最后一个值将被替换为新的值。新值将获得标志设置，以指示下一个NotificationMessage中丢失的值。图17说明了队列溢出处理。

图17 -队列溢出处理

如果队列大小为1，则队列成为一个总是包含最新通知的缓冲区。在这种情况下，如果MonitoredItem的采样间隔比订阅的发布间隔快，则MonitoredItem将进行过采样，客户端将总是收到最新的值。当队列大小为1时，丢弃策略被忽略。

另一方面，客户端可能希望订阅没有任何间隔的连续通知流，但不希望在采样间隔报告它们。在这种情况下，MonitoredItem将创建一个队列大小足以容纳两个连续发布周期之间生成的所有通知。然后，在每个发布周期，订阅将向客户端发送为MonitoredItem排队的所有通知。服务器应按照队列中的顺序返回任何特定项目的通知。

服务器可能会以比采样间隔更快的速率采样，以支持其他客户端;客户端应该只期望在协商的采样间隔内的值。根据过滤器和实现约束，服务器可能会交付比采样间隔指定的更少的值。如果为MonitoredItem配置了DataChangeFilter，那么它总是应用于队列中与当前示例相比较的最新值。

例如，如果DataChangeFilter中的AbsoluteDeadband是“10”，队列可以由以下顺序的值组成:

• 100
• 111
• 100
• 89
• 100 当使用死带过滤器时，数据排队可能会导致意外行为，并且遇到的更改的数量大于可维护的值的数量。队列中的第一个新值不能超过发送给客户端的前一个值的死区限制。

队列大小是Server在监视Events时支持的最大值。在这种情况下，服务器负责事件缓冲区。如果事件丢失，则 EventQueueOverflowEventType类型的事件被放置在队列中。当必须丢弃订阅事件的MonitoredItem上的第一个事件时，将生成此事件。除了为这个MonitoredItem定义的队列的大小之外，它被放入MonitoredItem的队列中，而不丢弃任何其他事件。如果discardOldest设置为TRUE，它将被放在队列的开头，并且永远不会被丢弃，否则将被放在队列的末尾。聚合服务器不应传递此类事件。它应该像其他连接错误场景一样处理。

5.12.1.6触发模式

MonitoredItems服务允许添加只有在其他项目(触发项)触发时才报告的项目。这是通过在触发项和要报告的项之间创建链接来实现的。要报告的项目的监控模式被设置为仅采样，因此它将采样和队列通知，而不报告它们。图18说明了这个概念。

图18 -触发模型

触发机制是一个有用的特性，它允许客户端通过将一些项配置为频繁采样，但只在其他事件发生时报告，从而减少在线上的数据量。

指定了以下触发行为。

1. 如果触发项的监控模式为SAMPLING，则触发项触发要上报的项目时不上报。
2. 如果触发项的监控方式为REPORTING，则触发项触发需要上报的项目时上报。
3. 如果触发项的监控模式为“DISABLED”，则触发项不触发上报。
4. 如果要报告的项目的监控模式为SAMPLING，则在触发项目触发要报告的项目时才报告。
5. 如果要报告的项目的监控模式是REPORTING，这实际上会导致忽略触发项目。要报告的项目的所有通知将在发布间隔过期后发送。
6. 如果要报告的项目的监控模式是DISABLED，那么将不会有要报告的项目的抽样，因此也不会有要报告的通知。
7. 当第一个通知在链接创建后排队等待触发项时，第一个触发器将发生。客户端在一个触发项和一组要报告的项之间创建和删除触发链接。如果表示要报告的项目的MonitoredItem在其关联的触发链接被删除之前被删除，则触发链接也被删除，但触发项不受影响。

删除MonitoredItem不应与删除它所监视的属性相混淆。如果包含被监控属性的节点被删除，MonitoredItem会生成一个StatusCode Bad_NodeIdUnknown的Notification，表示删除，但MonitoredItem不会被删除。