OPCUA as a starting-point
The popularity of the OPCUA standard made it possible for the development of Alarms & Events front-ends with advanced visualization features. Those APIs usually sit on the top of the PLC connected to the Process & Control network via an OPCUA driver connection. OPCUA attributes such as the alarm severity levels will be used to generate a more meaningful alarm banner. The RIVOPS 3D SCADA software suite, gives you a range of powerful features to display your alarms in the control room.
EATOPS is an early adopter of the OPC standard (2006). The firm sees it as a competitive advantage to go for a strict implementation of the OPCUA specifications. Let us have a look at the alarm banner (below) for instance.
Alarms & Events
FULL OPC AE CLIENT SEVERITY SUPPORT
The severity value is an indication of the urgency of the sub-condition. This is also commonly called "priority," especially in relation to process alarms although the notion of priority raises the need to define a "time-to-action". Severity values range from 1 to 1000, with 1 being the lowest severity and 1000 being the highest. Typically, a severity of 1 would indicate an event that is informational in nature while a value of 1000 would indicate a disastrous event.
EXTENSIVE ALARMS AND EVENTS CONDITION SUPPORT
RIVOPS supports nine OPC AE standard conditions, providing flexibility in how Alarms & Events Conditions are calculated and prioritized. Each condition has a unique name and a unique set of sub-conditions.
The multilevel condition supports multiple sub-conditions. This condition is used if the source has multiple states of interest and there is a need to know the transition between the condition states. For example, if you have a temperature tag with multiple temperatures of interest, use this condition. The HIGH_HIGH sub-condition has the highest priority and the LOW_LOW sub-condition has the lowest.
- HIGH_HIGH, HIGH, LOW, LOW_LOW
These are single level conditions with a sub-condition that matches the condition name. These conditions are used if a single state of a source is of interest. For example, if you have a temperature tag with a single temperature of interest, use this condition.
Note: Use HIGH_HIGH for higher priority states and LOW_LOW for lower priority states.
- ROC_HIGH, ROC_LOW
This condition compares the source data to a static or dynamic ROC. For example, if you have a source tag that represents production output and you want to trigger the condition if the output falls below 100 units a minute, use this condition.
Note: Use ROC_HIGH for high priority conditions and ROC_LOW for low.
- DEV_HIGH, DEV_LOW
These conditions monitor the deviation of the source data. The condition is triggered if the condition of the source is outside the limits set. The limits can be either a percentage or a static value. For example, if you have a source that monitors power consumption and you want to trigger the condition if the power consumption is outside of 100W ±20%, use a deviation condition.
RIVOPS supports AE acknowledgements. As soon as an operator reads and acknowledges the alarm, the alarm stops blinking and shows as acknowledged with ack time.
RIVOPS supports AE grouping. Alarm grouping features are related to scenario detection. As soon as alarm is detected to belong to a known scenario, the alarm is shelved shown under an alarm parent header.