Errata exists for this version of the document.

The AddressSpace organisation described in this Clause allows Clients to detect Conditions and ConditionSources. An additional hierarchy of Object Nodes that are notifies may be established to define one or more areas; the Client can subscribe to specific areas to limit the Event Notifications sent by the Server. Additional examples can be found in Clause B.2.

HasNotifier and HasEventSource References are used to expose the hierarchical organization of Event notifying Objects and ConditionSources. An Event notifying Object represents typically an area of Operator responsibility. The definition of such an area configuration is outside the scope of this standard. If areas are available, they shall be linked together and with the included ConditionSources using the HasNotifier and the HasEventSource Reference Types. The Server Object shall be the root of this hierarchy.

Figure 24 shows such a hierarchy. Note that HasNotifier is a sub-type of HasEventSource. I.e. the target Node of a HasNotifier Reference (an Event notifying Object) may also be a ConditionSource. The HasEventSource Reference is used if the target Node is a ConditionSource but cannot be used as Event notifier. See OPC 10000-3 for the formal definition of these Reference Types.

image027.png

Figure 24 – Typical HasNotifier Hierarchy

HasCondition is used to reference Conditions. The Reference is from a ConditionSource to a Condition instance or – if no instance is exposed by the Server – to the ConditionType.

Clients can locate Conditions by first browsing for ConditionSources following HasEventSource References (including sub-types like the HasNotifier Reference) and then browsing for HasCondition References from all target Nodes of the discovered References.

Figure 25 shows the application of the HasCondition Reference in a HasNotifier hierarchy. The Variable LevelMeasurement and the Object “Device B” Reference Condition instances. The Object “Tank A” References a ConditionType (MySystemAlarmType) indicating that a Condition exists but is not exposed in the AddressSpace.

image028.png

Figure 25 – Use of HasCondition in a HasNotifier hierarchy

Figure 26 shows the use of the HasCondition Reference and the HasEventSource Reference in an InstanceDeclaration. They are used to indicate what References and Conditions are available on the instance of the ObjectType.

The use of the HasEventSource Reference in the context of InstanceDeclarations and TypeDefinition Nodes has no effect for Event generation.

image029.png

Figure 26 – Use of HasCondition in an InstanceDeclaration

Use of HasCondition in a VariableType is a special use case since Variables (and VariableTypes) may not have Conditions as components. Figure 27 provides an example of this use case. Note that there is no component relationship for the “LevelMonitoring” Alarm. It is Server-specific whether and where they assign a HasComponent Reference.

image030.png

Figure 27 – Use of HasCondition in a VariableType