Alarms and Conditions

From UaCapabilities
Revision as of 15:18, 2 February 2015 by Karl (Talk | contribs)

(diff) ← Older revision | Approved revision (diff) | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Introduction

Conditions define some state in a system that requires interaction with an operator or users. An example would be a Dialog that is displayed when something occurs that an operator needs to respond to, such as mounting archive device. Alarms are specific conditions that represent abnormal states of a process or system. This includes unsolicited notifications when the Alarm state changes. Some common examples are:

  • a temperature exceeding a configured limit
  • infringing safety limits of equipment
  • a device needing maintenance
  • a batch process that requires a user to confirm some step in the process before proceeding

State-driven notifications have great advantages when dealing with large systems that have hundreds to millions of conditions. Alarm clients can subscribe for alarm notifications for specific areas in a plant. They will receive notifications whenever the state of a condition changes and where each notification includes enough information to identify the type and source. Such notifications will typically be used to help identify faulty equipment, create maintenance work orders and improve on operator's effectiveness.
Some state changes require actions like acknowledging the state change. An example is an Alarm becoming active when a measurement device exceeds a configured limit.
Note – Alarms & Conditions is specified in OPC UA Part 9

Alarms and Conditions Capabilities

Conditions

URN:          https://opcfoundation.org/wiki/index.php/Conditions

Description
Support the Condition Information Model and the notification mechanisms about condition states. Support for a refresh method.

Usage Considerations Conditions represent information that is of interest in a server. This information unlike events has a state associated with it and is not just a transitory notification
The client can obtain a current list of the system state with the use of the refresh method.




Alarms

URN:          https://opcfoundation.org/wiki/index.php/Alarms

Description
Support the Alarm information model and the notification mechanisms about the Alarm state. It also includes the management of transitions between various states by an alarm, such as shelving, acknowledgement, confirmation and the addition of comments.
The Alarm model builds on the condition model.

Usage Considerations
Indicate areas of the process that require immediate attention. Examples are:

  • safety limits of equipment
  • event detection, and
  • abnormal situations.

In addition to operators, other client applications may collect and record alarm information for later audit or correlation with other historical data.




Alarms/Instances

URN:          https://opcfoundation.org/wiki/index.php/Alarms/Instances

Description
By default the notification of events generated by transition between states are the only way to detect alarm & condition situations. When instances are supported, a client can browse the address space and discover the items that the server considers of interest, such as alarms.

Usage Considerations

  • In some systems clients may want to access some aspects of alarm or condition information in manner other than via the event notifications. For example a client may need to know the possible error state an object could encounter. In these systems the server would have to expose Alarm and Condition instances, to allow the client to browse the Alarm and Conditions.
  • Allows using Clients that are able to access data but not events.
  • Allows enabling and disabling of Alarms



Alarms/Instances/Enabling

URN:          https://opcfoundation.org/wiki/index.php/Alarms/Instances/Enabling

Description
The enabling or disabling of individual alarms via request from an OPC UA Client.
Enabling can only be applied to instances.

Usage Considerations
If a condition is disabled it will no longer report any information. For example if a piece of equipment is removed from the plant any condition associated with it maybe disabled. When the piece of equipment is returned the conditions may be enabled.


Conformance Testing

Client Server

TBD

TBD



Alarms/Exclusive

URN:          https://opcfoundation.org/wiki/index.php/Alarms/Exclusive

Description
The sub-states in the alarm model can function in two different modes: exclusive or non-exclusive. Exclusive means that only one sub-state can be active at a time. For example, if a temperature exceeds the HighHigh limit the associated exclusive LevelAlarm will be in the HighHigh sub-state and not in the High sub-state anymore.

Usage Considerations
All Alarm system include at least one of the alarm models (exclusive or non-exclusive).




Alarms/NonExclusive

URN:          https://opcfoundation.org/wiki/index.php/Alarms/NonExclusive

Description
The sub-states in the alarm model can function in two different modes: exclusive or non-exclusive. Non-exclusive means that more than one sub-state can be active at a time. For example, if a temperature exceeds the HighHigh limit the associated non-exclusive LevelAlarm will be in both the High and the HighHigh sub-state.

Usage Considerations
All Alarm system include at least one of the alarm models (exclusive or non-exclusive).




Alarms/PreviousStates

URN:          https://opcfoundation.org/wiki/index.php/Alarms/PreviousStates

Description
An extension of the Alarm model where previous states of Alarms will be retained until they are acknowledged and/or confirmed.

Usage Considerations

  • Domains, where all transition in an alarm model must be individually responded to by one or more operators.
  • Safety critical systems that require that all Alarms be acknowledged even if it the original problem goes away and the Alarm returns to the inactive state.



Alarms/Dialogs

URN:          https://opcfoundation.org/wiki/index.php/Condition/Dialogs

Description
A specialized Condition model where a Server can interact with a User. The information flow starts with the Server sending a message (a dialog prompt) and a number of possible responses. The User selects one of these responses which the Client then sends to the Server.

Usage Considerations
Dialogs are typically used in states that require intervention by a Client. For example, a Server monitoring a paper machine indicates that a roll of paper has been wound and is ready for inspection. The Server would activate a Dialog Condition indicating to the user that an inspection is required. Once the inspection has taken place the user responds by informing the Server of an accepted or unaccepted inspection allowing the process to continue.


Conformance Testing