Posts Tagged ‘Alarm Management’

Alarm management challenge 5: Keeping an overview and finding specific alarms

Thursday, September 17th, 2015

This challenge is very much interconnected with the challenge of how to cope with too many alarms presented earlier in this article. If the amount of information presented by your alarm management seems already overwhelming, you will be surprised how lost you would feel in an alarm flood without proper filtering mechanisms. For a truly effective and manageable alarm system, finding and displaying the most critical alarms is a key success factor.

zenon’s Alarm Management Solution 5: Advanced Filtering Mechanisms

zenon offers flexible and user-definable solutions to enhance operations such as alarm classes and alarm groups for the purpose of classification and prioritization. Alarm groups and classes in zenon are also defined globally and set independently of the variable limits or Reaction Matrix states. Therefore, it is possible to have a pressure transmitter with a High Alarm with a class of Warning and the same pressure transmitter with a High-High Alarm with a class of Critical.

In Runtime mode, individual colors of the alarms can be defined within the alarm groups or classes to give operators a clear indication from the Alarm Message List about the most important alarms to handle. Of course, filtering in the groups and classes is an integrated part of the zenon filtering concept.

When alarm classes are used in combination with zenon alarm areas, then the ultimate statistics and overview are provided to the operator. Alarm areas are abstracted so they can be used for a variety of purposes, but they provide detailed information about active, unacknowledged, and acknowledged alarms within a logic area. The figure below shows a simple example how alarm groups, classes, and areas can be used together to provide a complete overview of the alarm status of an entire production facility.

Alarm groups, classes and areas examples.

Alarm groups, classes and areas examples.

There is one additional attribute to the unique alarm concept in zenon, and this is the Equipment Model. The Equipment Model in zenon represents an ISA 88 and 95 model that allows for the linking of objects to a physical piece of equipment. In general, it is a structured, hierarchical tree view of equipment within a plant or facility.

Equipment model example in zenon.

Equipment model example in zenon.

The zenon variable which generated an alarm can be linked to one or multiple equipment groups. When this is utilized, it provides not only a connection of a variable to a piece of equipment for the operator, but will also provide a hierarchical alarm filtering mode. If we look at an example from a beverage bottling facility, the equipment model may be structured as follows:

In Runtime, if the operator filters on Line 3, all alarms that occur from any piece of equipment within Line 3 will be returned. If the operator filters alarms in the Runtime for just Line 3 filler, only the alarms generated from the Line 3 filler will be returned. As a result, the operator who is looking to troubleshoot or diagnose a problem can quickly and effectively narrow the results of hundreds of alarms to just the alarms relevant for their investigation.


Alarm management standards such as ISA 18.2-2009 and IEC 62682 are practical guidelines developed by industry professionals to implement and maintain an effective alarm management system. These standards are, however, just one piece of a larger equation.

Contact us to learn how zenon HMI/SCADA can help you convert these standards into reliable, dynamic, and effective alarm management solutions.

See “Alarm Management Challenge 4: Quality of Values and String Processing” here.

Alarm Management Challenge 4: Quality of Values and String Processing

Thursday, September 3rd, 2015

Energy_AMLIt’s a matter of fact that the communication quality to the PLC very much influences the alarm generation in the SCADA system. If the communication is bad, interrupted, or even lost, the system generates a flood of alarms which might lead to false conclusions. Therefore, the quality of values is essential. Another common challenge is the monitoring of string values via alarming features.

zenon’s Alarm Management Solution 4: Reaction Matrix

The most powerful tool for a global alarm definition, status supervision and string monitoring in zenon is the Reaction Matrix, known by zenon users by its abbreviated name ReMa. The Reaction Matrix differs from variable and datatype limits in a few ways, but most notably in its linking. Where limits are defined directly on the variable or datatype, the Reaction Matrix makes it possible to define a global alarm condition and reuse it for multiple variables. For example, in an automation system using zenon, there could be 300 valves and all valve statuses are read in as an integer for the defined states. Since all valves have a common value reading for their states, the Reaction Matrix is perfectly suited. The engineer must create only one reaction matrix with this configuration and it is then simply linked to all instances of the valve.

In addition to the global aspect of the Reaction Matrix, zenon also offers the ability to use a Numerical Reaction Matrix, a Binary Reaction Matrix, or a String Reaction Matrix. The Numeric Reaction Matrix gives the user the option to define the alarm set points in terms of less than, greater than, or equal to a specific numeric value. It also has a unique feature to “treat any value change as a limit violation”. The Binary Reaction Matrix gives the engineer the ability to define alarm conditions based on the state of individual bits of a word. The String Reaction Matrix can be linked with any string variables being read from the PLC to generate an alarm. Value monitoring can be achieved with static values or even with wildcards.

State-based alarming:

In zenon Runtime a variable always consists of the following three things: (1) the variable value, (2) the variable timestamp, and (3) the variable status. The variable status is maintained for every zenon variable and is composed of 64 individual status bits to always give a clear indication of the real-time or recorded variable status, whether it was a good status, communication fault status, alarm suppressed status, etc.

The main benefit of the Reaction Matrix is that not only can it analyze the value of a variable, it can also generate alarms or event conditions based upon a specific status bit. Or sometimes even more important: it can suppress alarms if the status information does not fit. For example, if there is a communication problem no alarm will be triggered. This makes it quite easy to avoid thousands of alarms during a communication problem with the PLC.

See “Alarm Management Challenge 3: Multiple Points of Configuration” here.

Alarm Management Challenge 3: Multiple Points of Configuration

Thursday, August 27th, 2015

Many alarm systems in use today require an additional alarm server or require tags to be configured multiple times, adding to inefficiencies in engineering and hindering the process of creating a proper alarm management system.

zenon’s alarm management solution 3: tags defined one time, object-oriented engineering

With zenon, variables are only defined once. For example, if a pressure transmitter is being read from an Allen Bradley ControlLogix PLC, this is just one variable in zenon. This one pressure transmitter variable can be displayed on HMI screens, recorded in the Historian, plotted in the Extended Trend diagram, or used to generate an alarm. Therefore, if the alarm condition must be modified for the pressure transmitter it must only be done once, in a single location.

To take object-oriented engineering a step further, zenon supports the creation of custom and structured datatypes. All zenon variables are based upon a driver (e.g. Siemens S7), a driver object type (e.g. Ext. Datablock), and a datatype (e.g. Real). There are multiple benefits in creating and using custom datatypes in zenon. For example, it is possible to create a custom datatype for the pressure transmitter. This can be set as a Real datatype and will inherit the properties of the default Real type in zenon. The new pressure transmitter can then be customized even further by adding the measuring units of psi, showing three decimal places, and defining a series of four limits on the datatype.

Custom datatype example in zenon

Custom datatype example in zenon

As you can see in the figure above, the creation of this custom datatype for the pressure transmitter will take an engineer approximately five minutes to configure and check. The savings and benefits come in at the next step, since the engineer must display 150 pressure transmitters in the SCADA system, each with the above configuration and limits configured. This process in zenon will only take the engineer one minute since he is able to create an array of 150 elements for the pressure transmitters which will automatically inherit the properties set on the pressure transmitter datatype set in the figure. Of course, individual instances can still be customized and “unlinked” with the datatype.

Not only is this a huge time saver, it also guarantees that every individual pressure transmitter is configured accurately. If, after two weeks of operation, the operations manager wants the Low-Low limit for the pressure transmitter changed to only alarm at < 56 psi, the engineer only needs to make this change at the pressure transmitter datatype, and all 150 pressure transmitters will be updated automatically with the new Low-Low limit of < 56 psi. After the configuration is changed, the zenon Editor downloads the updated files to the Runtime server via zenon Remote Transport over the network, then the engineer remotely reloads the project with a mouse click. The changes are live and deployed throughout the zenon network to all connected servers, clients, and web clients in just a few moments, all happening without any downtime, operational inconvenience, or concern.

See “Alarm Management Challenge 2: Managing a Diverse Infrastructure” here.

Alarm Management Challenge 2: Managing a Diverse Infrastructure

Friday, August 21st, 2015

Only in very few cases, are plants and facilities built from the ground up with a single turnkey solution that provides both the controls as well as HMI/SCADA. In well-developed markets, many manufacturers have a diverse infrastructure of different PLCs, HMIs, and a general mixture of new and old technology. Each PLC program or HMI system follows its own unique conventions which only adds to the problem.

A good alarm management system must be based on a solid, efficient, and a reliable communication foundation to bring these components together. In a production facility where alarms are provided to operators who must make critical decisions with serious operational or safety implications, the quality of data must be called into question. The fact is that many existing HMI/SCADA systems still rely on additional software components (e.g. a middleware OPC Server) or PLC head stations which adds additional complexity and extra components which may fail.

zenon’s alarm management solution: A software solution for any hardware

With more than 300 native drivers and communication protocols – actively developed and maintained by COPA-DATA – zenon has the unequaled ability to be installed in a production facility that has a mixture of old PLCs, new PLCs, proprietary PLCs, and PLCs supporting standardized communication protocols (Modbus, BACnet, OPC UA, etc.).

Since zenon uses its direct communication drivers, the alarms are always derived from a variable that is being mapped to the logic controller. The zenon variable list provides an overview of all variables at all times, and in Runtime there are 64 dedicated status bits to ensure the communication status and the quality of data.

The functionalities of the core zenon alarming system require no extra configuration, settings, databases, or a dedicated server. When a new zenon project is created, alarming is activated by default, and all the engineer needs to do is define the alarm states and implement the alarm screens.

Alarm Management: Alarm visualization steps in zenon

Alarm Management: Alarm visualization steps in zenon


See “Alarm Management Challenge 1: Too many alarms” here.

Alarm Management with zenon: Save Time and Money with an ergonomic System in place

Thursday, August 13th, 2015

COPA-DATA has more than 100,000 zenon HMI/SCADA installations worldwide. The one zenon feature which is used in nearly every installation is the alarm concept. As a native part of the zenon Runtime, the core zenon alarm functionality is available for all users and all licenses. This article will explain how companies can improve productivity, efficiency, and safety by utilizing zenon HMI/SCADA solutions in combination with international alarm management standards such as ISA 18.2 or IEC 62682.

The task of implementing and maintaining an effective alarm management system compliant to the International Society of Automation (ISA) ISA 18.2-2009 or the International Electrotechnical Commission (IEC) IEC 62682 is by no means a simple one. A successful implementation requires input from plant management, engineering, facilities, information technology and operators. To start a successful alarm management project, we show you which aspects one should consider according to ISA 18.2 / IEC 62682.


Alarm Management Lifecycle

Alarm Management Lifecycle according to ISA 18.2 and IEC 62682.

Alarming has been a crucial and important topic for manufacturers since the days of giant control rooms with massive annunciator panels. In the early days of Human Machine Interfaces (HMI), the annunciator panel offered a limited amount of space to give plant operators only the most crucial information to maintain safety and productive operations. Since the inception of PC-based HMI systems, the amount of alarms which can be configured and shown on HMI screens with relative ease has escalated at Moore‘s Law proportions. This influx of storage and processing capabilities eventually led to one of the biggest problems facing a typical plant operator: the overwhelming amount of information presented by the modern alarm system.

Let’s have a closer look at how engineers can cope with this and some other challenges:

Alarm Management Challenge 1: Too many Alarms

The test of a good alarm management system does not occur when the plant is running smoothly, but instead when there are disruptions in the process. According to the IEC, an average rate of 288 alarms per day or twelve alarms per hour or two alarms per ten minutes is maximum which is manageable. The ISA classifies an alarm flood as more than ten alarms, per ten minute period, per operator. The target alarm volume, over a 30-day monitoring period should be in the range of one alarm, per ten-minute period, per operator.

zenon’s Alarm Management Solution 1: Delay Time, Threshold, and dynamic Alarm Limits

zenon offers features and functionalities to reduce unnecessary alarms. For example, in zenon each variable when activated as an alarm has both a delay time and dead band property. Here we offer a short technical description of each method:

  • Delay Time Example:
    A pressure transmitter is monitored by zenon and is set to alarm when the value reaches or exceeds 350 psi. If the normal operating condition and ideal pressure is 349 psi, the operator may encounter many chattering alarms which takes focus away from more serious alarms. In this case, one is able to define a delay time of 15 seconds. This means that alarm conditions will only be triggered if the pressure transmitter has a value > 350 psi lasting for at least 15 seconds. If the 15 second period has lapsed and the value is still > 350 psi, then zenon will generate the alarm with the timestamp when the limit violation originally occurred. If any time before the 15 seconds the value drops below 350 psi, the alarm will not be generated.
  • Alarm Threshold Example:
    A threshold value can be defined that will be used for clearing a limit violation so unwanted reactions for chattering analog values can be avoided. If an alarm threshold of 5 for the pressure transmitter is set on the limit, which still alarms at > 350 psi, then the alarm will occur as normal at 350 psi or greater. However, now the alarm condition will only clear if the threshold value of 5 has been reached. In our example, this means the alarm will be only cleared if the value returns to < 345 psi.
  • Dynamic Alarm Limits:
    zenon also allows for Runtime-based alarm set point tuning through a functionality called dynamic alarm limit. This can be implemented for any numeric variable, regardless of the PLC. The alarm set point tag can come from the PLC or can even be an internal zenon variable. In Runtime, if we find that the pressure transmitter alarm limit of > 350 psi is too low, the operator or supervisor with appropriate user rights can push the limit up to 355 psi, without changing the engineered configuration or project. Of course, this change will be logged in the zenon Chronological Event List.

In the next blog post you will read about the Alarm Management Challenge 2: Managing a diverse Infrastructure.