BS EN 62541-9:2012 pdf download

BS EN 62541-9:2012 pdf download.OPC unified architecture Part 9: Alarms and conditions.
4.2 ConditIons
Conditions are used to represent the state of a system or one or Its components. Some
common examples are:
• a temperature exceeding a configured limit;
• a device needin9 maintenance;
• a batch process that requires a user to confirm some step in the process before proceeding.
Each Cond,ton instance is of a specific Condit ion Type. The ConditionType and derived types are subtypes or the BaseEventType (see IEC 62541.3 and IEC 62541-5). This part defines types that are common across many industnes. It is expected that vendors or other standardisation groups will define additional Condition Types deriving from the common base types defined in this part. The Condition Types supported by a Server are exposed In the AddressSpace of the Server.
Condition instances are specific implementations of a Condition Type It is up to the Server whether such instances are also exposed in the Servers AddressSpace. Subclause 4.10 provides additional background about Condition instances Condition instances shall have a unique Identifier to differentiate them from other Instances. This Is independent of whether they are exposed in the AddressSpace.
As mentioned above, Conditions represent the state of a system or one of its components. In certain cases, however, previous states that still need attention also have to be maintained. ConditionBranches are introduced to deal with this requirement and distinguish current state and previous states. Each ConditionBranch has a Branchld that differentiates it from other branches of the same Condition instance. The ConditionBranch which represents the current state of the Condition (the trunk) has a Null Branchld. Servers can generate separate Event Notifications for each branch. When the state represented by a ConditionBranch does not need further attention, a final Event Notification for this branch will have the Retain Property set to False. Subclause 4.4 provides more information and use cases. Maintaining previous states and therefore also the support of multiple branches is optional for Servers.
Conceptually, the lifetime of the Condition instance is independent of its state, However. Servers may provide access to Condition instances only while ConditionBranches exist.
The base Condition state model is illustrated in Figure 1. It is extended by the various Condition subtypes defined in this specification and may be further extended by vendors or other standardisation groups. The primary states of a Condition are disabled and enabled. The disabled state is intended to allow Conditions to be turned off at the Server or below the Server (in a device or some underlying system). The enabled state is normally extended with the addition of sub-states
4.4 Previous States of Conditions
Some systems require that previous states of a Condition are preserved for some time. A common use case is the acknowledgement process. In certain environments it is required to acknowledge both the transition into active state and the transition into inactive state, Systems with strict safety rules sometimes require that every transition into active state has to be acknowledged. In situations where state changes occur in short succession there can be multiple unacknowledged states and the Server has to maintain ConditionBranches for all previous unacknowledged states Those branches will be deleted after they have been acknowledged or If they reached their final state.
Multiple Cond,tionBranches can also be used for other use cases where snapshots of previous states of a Condition require additional actions.
4.5 Condition State Synchronization
When a Client subscribes for Events, the notification of transitions will begin at the time of the subscription. The currently existing state will not be reported. This means for example that Clients are not informed of currently active Alarms until a new state change occurs.
Clients can obtain the current state of all Condition instances that are in an interesting state. by requesting a refresh for a Subscript ion. It should be noted that refresh is not a general replay capability since the Server is not required to maintain an Event history,
Clients request a refresh by calling the ConditionRefresh Method. The Server will respond with a RefreshStartEvenl. This Event is followed by the Retained Conditions. The Server may also send new Event Notifications interspersed with the refresh related Event Notifications. After the Server is done with the refresh, a RefreshEndEvent is issued marking the completion of the Refresh. Clients shall check for multiple Event Notifications for a ConditionBranch to avoid overwriting a new state delivered together with an older state from the refresh process.