# Alarm Management at Operators Workstations

Patrik Urban, Lenka Landryová

► To cite this version:

Patrik Urban, Lenka Landryová. Alarm Management at Operators Workstations. IFIP International Conference on Advances in Production Management Systems (APMS), Sep 2014, Ajaccio, France. pp.307-314, 10.1007/978-3-662-44739-0_38.hal-01388266

HAL Id: hal-01388266

https://inria.hal.science/hal-01388266

Submitted on 26 Oct 2016

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Alarm Management at Operators Workstations

Patrik URBAN, Lenka LANDRYOVÁ

Department of Control Systems and Instrumentation,
VSB-Technical University Ostrava, 17. listopadu, Ostrava - Poruba, Czech Republic, 708 33
patrik.urban@vsb.cz, lenka.landryova@vsb.cz

**Abstract.** This contribution deals with issues regarding alarm management at the operator workstations of industrial automated systems. It is focused on the Object Oriented Programming techniques and data acquisition from controlled processes provided for the human machine interface of these systems, the possibilities to configure the monitored variables of the processes and their parameter definition. It shows the different aspects of decision making over the options for using system functions in applications of operator environments on concrete examples.

**Keywords:** Alarm, System, Management, HMI, Automation

## 1 Introduction to Techniques Applied for Work of Operator Workstations

Operators of control systems work in a field, in which emerging technology is characterized by features allowing implementation of control into processes without direct human intervention. However, automation and supervisory control do not fully exclude all human activity, those who supervise the automatic work of machines, in which it is still required to participate in a task for machine setup, the program upload, optimization of processes and similar areas.

### 1.1 Component object model techniques and server – client architecture

The technology, which has enabled bringing data to an operator workstation, is based on the principle of object-oriented modeling, which allows two or more components of applications to cooperate with each other even if they are created in different programming languages and designed for the use in different operating systems.

This Component Object Model (COM) technology works on the server – client communication principle, where the server sends data only when the client requests them, and uses the already mentioned object- oriented architecture, which brings one of the advantages of the "encapsulated" feature of programs into reusable software components that allows them to hide data and functions into the objects.
The object is an instance of a class, which is linked to a set of member functions and data. The component is a part of the program in a binary form, and as such, it must meet a certain binary standard. As already mentioned above, this object can be connected to different applications or other program components. Due to the packaged data and functions of the object, the client does not care about the internal implementation but the external object behavior, for example, the provided functions, which are defined for the application by COM technology (Bajgar, 2000).

## 1.2 Communication standards in control systems

Integration of business plans and the control systems in the industry would not be possible without standards developed for their communication. Manufacturers rely on the use of Supervisory Control And Data Acquisition (SCADA) or Distributed Control Systems (DCS) to implement their plans into production. This is enabled by open and effective communication architectures with OLE (Object Linking Embedding) for Process Control (OPC) standard, which focuses on data access and not the data type.

The idea of the OPC server is implemented into OPC Historical Data Server, as well as Alarm & Event Handling Server. OPC is a standard for both hardware providers and software developers. It provides a standard mechanism for the transfer of data from hardware devices to any client application, the highly optimized communication of software applications with the data sources, and it defines a mechanism for efficient data exchange between software and hardware.

Together with OPC interface allowing any client to access their device using OLE and COM techniques allow developers to use software components in their programs written in different languages.

# 2 Hierarchy of Industrial Control

The industrial control systems work in a hierarchical structure and consist of levels, see Fig. 1 (Bajgar, 2000):

* The level of **direct** control, from where "smart" sensors and smart devices provide the system with their data through the interface. This data collected from the equipment together with its configuration parameters are presented to the software applications.

* **Process** level, where the data is used by DCS and SCADA systems with Human Machine Interface (HMI). The user of these systems is able to monitor, manage and evaluation processes, from which the data are obtained and can be further used at the information level.

* **Information** level, where data are analyzed and processed by tools and used for management and information systems or economic applications. At this level the users are able to work and connect with SCADA software, databases, word processing, spreadsheets in conjunction with the production system.
<figure><img src="image_2.png" /><figcaption>Fig. 1. Control System Hierarchy</figcaption></figure>

## 3 Services of Control Systems

The service is the OPC server concept, which allows many different OPC servers to be placed under one common server that unifies access to data from different sources. This common server provides one set of OPC compliant interfaces, eliminating the need for client applications to know which OPC server to use for each data item.

The service provides an interface compatible with OPC client applications to use the data. In this case, the control system is designed in functional hierarchical structure for each manufacturing operation and the procedural parts (involving equipment such as engines, tanks, etc.). This enables operators to configure an alarm system, a basic operator support system for managing abnormal situations, and create a simple alarm list of each monitored variable. The control system automatically adds the alarm from an object into a specific section in each alarm list.

It's a very effective and fast way from the point of view of cost, and also easier for operators, who are able to monitor “their” alarms, alarms in their competence under their login into a system, and not long unsorted list of alarms of all control systems. When a new alarm appears, it is added to the functional structure of the object automatically. Operators can monitor unacknowledged alarms recorded in the event list. The visible part of the control system alarm list also contains a "live tracking values" feature, which displays actual values and parameters that triggered the alarm, for example when the level in the tank falls below a certain minimum.

In the list it can also be seen, what the current value of a monitored variable is, which carried out the alarm. This feature can be identified as Alarm Grouping, meaning drawing up lists of key attributes, and thus creating manageable lists. The result is the one alarm in the alarm list for all alarms in the whole group presented to the operator screen.
<figure><img src="image_3.png" /><figcaption>Fig. 2. A Single Alarm List</figcaption></figure>

This example shows how alarm grouping can help operators better understand the implications of a particular alarm in the control system, and its impact on the process. In systems without this feature, the decision and resolution of the alarm conditions rely on the knowledge of an operator, and under circumstances when several processes are monitored at the same time it is quite time consuming and/or risky.

<figure><img src="image_4.png" /><figcaption>Fig. 3. Alarm Grouping Tool Applied for Alarm List</figcaption></figure>

## 4 Alarm Issues which Operators deals with in Control Systems

The basis for the work is to describe the situation and processes in which the alarm system is deployed. The correct description of the system facilitates further work with alarms and their management. An important idea of the methodology is a combination of the qualitative and quantitative approach to the research applied to the alarm system development. Data collection in the form of alarm records from different applications and process systems help us to find weaknesses in the management of alarms.

The data here are evaluated from two different process systems, resulting in a different number of events in them. This also shows that it is necessary to obtain the
largest amount of findings possible to be able to evaluate better the management of alarms. The first records are taken from 15 minutes of monitoring, during which 27 alarms came, 25 of which were alarms on values exceeding the limits, and 2 were system failures alarm in first control system. Another system was examined as well and for the same period of 15 minutes the operator received 500 events on the work-station screen. This is an increased burden for the operator. Of the 500 events, 433 events were acquired as changes of monitored values and confirmed alarms, remaining events were alarms that showed an exceeded limit of 25 monitored variables, and a group of other system alarms, which consisted of changes in the valves/actuators of manual → automatic mode, a small change of reference values, changes from true → false values of binary variables.

Rationalization of alarm issues, listed in Table 1, should help operators manage stressful situations. The objective of configuration of the alarm management system is to allow operators to remove standing or nuisance alarms that are re-occurring on the main alarm list of their screens.

<table><caption>**Table 1.** Alarm Issues (Atkinson, T., 2011)</caption><thead><tr><th>Alarm Issues</th><th>Symptoms</th><th>Effects</th><th>Implications</th></tr></thead><tbody><tr><td>Alarm Load</td><td>High number of alarms per operator per minute, 1 per minute is unacceptable, Highest seen 40 per minute, Operators accept alarms without review</td><td>Devaluing of the Alarm System<br>Decision making impaired<br>Poor operator responses<br>Adds to operator stress<br>Masks high priority alarms<br>More outages<br>Loss of protective layer</td><td>Texaco Milford<br>Haven<br>Alaska North<br>Slope<br>Esso Longford<br>explosion</td></tr><tr><td>Burst Alarms</td><td>High number of alarms from a single cause e.g. Compressor trip<br>Shutdown/Startup<br>Often see 100+<br>Occasionally see 500+</td><td>Incorrect/delayed diagnosis of causal event<br>Incorrect response to incident<br>Delayed response to incident<br>Miss key alarms hidden in list<br>E.g. failure to shut down safely<br>Poor operator 'situational awareness' following event<br>Increased likelihood of subsequent errors</td><td>Three Mile<br>Island</td></tr></tbody></table>
<table><thead><tr><th>Alarm Issues</th><th>Symptoms</th><th>Effects</th><th>Implications</th></tr></thead><tbody><tr><td>Nuisance alarm handling</td><td>High number of alarms per operator per minute<br>Repeating alarms<br>Instrument Fault alarms<br>System alarms</td><td>Alarms defeated<br>Safety alarms<br>'Unofficial' defeats<br>Ignoring the alarm system<br>Poor control room environment<br>High operator stress<br>Devaluing of work request system</td><td>BP Prudhoe Bay<br>Maryland rail<br>Accident<br>BP Grange-mouth<br>Esso Longford</td></tr><tr><td>Poor Design</td><td>High numbers of high priority alarms<br>Safety alarms not differentiated<br>No defined operator response<br>Standing Alarms<br>Out of use or standby equipment</td><td>Operators respond to inappropriate alarms<br>Delayed or no response to important alarms<br>Inconsistent or incorrect operator response</td><td>BP Texas city explosion<br>Helios crash<br>Explosion at Texaco Milford Haven</td></tr><tr><td>Poor management</td><td>Alarms disabled inappropriately<br>Without risk assessment<br>Without regular review<br>Alarms ignored<br>Faulty alarms not addressed</td><td>Removal of a layer of protection<br>Safety<br>Environmental<br>Economic<br>Regulator attention</td><td>BP Texas city explosion<br>Maryland Rail<br>Accident</td></tr></tbody></table>

Therefore two functions were configured for the above mentioned control system: Alarm Hiding and Alarm Shelving. Alarm shelving lets operators decide whether or not to put an alarm 'on the shelf' for a defined period of time or a certain occurrence. This temporarily removes it from the main alarm list to a special list, but the alarm itself is not affected. It will later require attention from the operator. In the meantime, the operator can concentrate on tasks judged to require their immediate focus. The question remains if alarm shelving makes a valuable and much-appreciated tool that helps operators work with maximum efficiency. The shelving is time limited to prevent important alarms to be removed or forgotten

Alarm hiding is set up during the engineering phase. Its main purpose is to suppress alarms that are either expected or not relevant in a particular situation, or that are based on a known process state, e.g. low temperatures or flow during a controlled shutdown. As the name suggests, 'hidden' alarms are never visible to operators. They only see alarms that require action on their part.
# 5 Conclusion

Automation is the field, in which modern technology is being developed, characterized by features allowing implementation of control processes without direct human intervention. However, automation and supervisory control do not fully exclude people, who supervise the direct work of machines. The motivation for the research is filled in the gap between practice – the daily operation of operators supervising control systems, and an analysis of such processes. As an example of supervisory control we describe here the area of an alarm management system. Such system is dealing with alarm logs giving a feedback for better understanding at the level of the human-machine interface in order to improve and support the engineering work on the design, configuration and implementation of the system for an operator supervising the production and managing alarms. As the production processes get very complex, there are increasing numbers of things, which can go wrong when controlling them. This research was also aimed to find out about the alarms from actual cases, how they are defined, what types are used, and how much their configuration in practice matches the ISA 18.2 standard, which defines alarm management for conditions in different control systems. The operators who are the immediate users and the engineers who configure the control systems features at the site during their implementation need to cooperate. The evaluation of process alarms in the control system from system operator point of view was described. Alarms are displayed, depending on whether the configured monitored variable exceeds the set limits. The alarm prioritizing during their configurations and design in terms of the frequency for requests for alarm acknowledgement by a single operator and alarm handled by operators during stressful situations remains a big task of control systems engineers to prevent hazardous consequences.

# 6 References

1. AAMD, Advances in Alarm Management [online] [cit. 2014 - 5] Retrieved from www.<URL: http://www.ece.ualberta.ca/~aamd/

2. ABB. 2014. ABB data in progress, [online] [cit. 2014 - 5] Retrieved from www. <URL: http://inside.abb.com/ >

3. Alarm management problem solved [online] [cit. 2014 - 5] Retrieved from : https://www.asmconsortium.net/Documents/Alarm%20Management%20Wasnt%20that%20problem%20solved%20years%20ago_DeWildeReising_2011HUGAmericas.pdf

4. Atkinson, T. Human Factors in the Process Industries Blog. [online] [cit. 2011 - 12] Retrieved from www. <URL: http://www.abb.com/blog/gad00540/3F0E.aspx>

5. Bajgar, D. Administration of alarm events with the use of OPC object technology. Ostrava: Department of Control Systems And Instrumentation, Technical University of Ostrava, 2000. 62 pages. Final thesis, Supervisor: Landryová, L.

6. Crawford, W., Hollifield, B. Energy-tech, [online] [cit. 2014 - 5] Retrieved from www.<URL: http://www.energy-tech.com/article.cfm?id=28019>2010

7. Data analysis [online] [cit. 2014 - 5] Retrieved from: http://ori.hhs.gov/education/products/n_illinois_u/datamanagement/datopic.html
8. Data analysis example [online] [cit. 2014 - 5] Retrieved from: http://www.ats.ucla.edu/stat/dae/

9. Data Collection Method [online] [cit. 2014 - 5] Retrieved from: http://people.uwec.edu/piercech/researchmethods/data%20collection%20methods/data%20collection%20methods.htm

10. Difference between Scada and HMI [online] [cit. 2014 - 5] Retrieved from:http://www.indusoft.com/blog/2013/04/19/what-is-the-difference-between-scada-and-hmi/

11. ISA norm 18.2 [online] [cit. 2014 - 5] Retrieved from: https://www.isa.org/.../DownloadAsset.aspx?id=1233...

12. Marchelli, M. Situation Awareness in Scada, 2011 [online] [cit. 2014 - 5] Retrieved from www.<URL:http://www.emmos.org/prevconf/2011/Training_2_Situational%20Awareness%20in%20SCADA%20 EMS_GMS_DMS_Rev3_1.pdf>

13. Research in alarm management communication [online] [cit. 2014 - 5] Retrieved from www.http://ieeexplore.ieee.org/xpl/abs_all.jsp?arnumber=6339920&tag=1

14. What do mean Scada [online] [cit. 2014 - 5] Retrieved from www.<URL: http://www.reliance.cz/cs/products/what-does-scada-hmi-mean