Alarms and Conditions

From UaCapabilities
This is the approved revision of this page, as well as being the most recent.
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/Alarms_and_Conditions#Conditions

Discovery ID: AC


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.


Conformance Testing

Client Server

Use/understand the Condition model including the Refresh Method

Support Conditions including the Refresh Method

Alarms

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

Discovery ID: AC


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.


Conformance Testing

Client Server

Ability to handle alarms

Conditions with active/inactive state

Instances

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Instances

Discovery ID: AC


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

Conformance Testing

Client Server

Exclusive Alarms

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Exclusive_Alarms

Discovery ID: AC


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).


Conformance Testing

Client Server

Ability to use the exclusive alarm model

Exclusive: Only one sub-state active at a time

NonExclusive Alarms

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#NonExclusive_Alarms

Discovery ID: AC


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).


Conformance Testing

Client Server

Ability to use non-exclusive Alarms

Support of non-exclusive Alarms

Previous States

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Previous_States

Discovery ID: AC


Description
An extension of the Alarm and Condition model where previous states 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.

Conformance Testing

Client Server

Ability to list and acknowledge states that are older than the current state

Server maintains previous states that have not been acknowledged

Dialogs

URN:          https://opcfoundation.org/wiki/index.php/Alarms_and_Conditions#Dialogs

Discovery ID: AC


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

Client Server

Client dialog support

Server uses dialogs