Jens Doppelhamer, Pablo Rodriguez, Benjamin Kloepper ABB Corporate Research Ladenburg, Germany, jens.doppelhamer@de.abb.com, pablo.rodriguez@de.abb.com, benjamin.kloepper@de.abb.com; Dawid Ziobro ABB Corporate Research Västerås, Sweden, dawid.ziobro@se.abb.com; Hadil Abukwaik Former ABB employee
Industrial plants can have a large number of devices that receive or transmit signals associated with the control of production processes. The process control systems of these plants consist of networks of interconnected sensors, actuators, controllers and computers. Monitoring such a complex array of data and equipment and reacting appropriately to the events and alarms they produce is not a trivial challenge. Human operators on-site and in remote control rooms must pay close attention so that undesirable situations are quickly detected and their causes identified →01. Failure to rapidly detect and interpret alarms and remedy critical situations can lead to safety risks, unnecessary costs and environmental damage.
Traditionally, alarms and events are displayed in tabular form in an alarm list, allowing operators to monitor them as they occur and to perform operations in reaction →02. This task can place a considerable cognitive load on the operator since the number of alarms and associated parameters can be high.
While a traditional alarm list offers a comprehensive way to access information related to alarms, it lacks the context needed to identify topological and chronological relationships between them, often making it difficult for the operator to interpret a particular situation.
Response difficulties are exacerbated during an alarm flood – ie, situations where the rate of alarms arising exceeds the operator’s ability to handle them. An alarm flood is often inevitable and is always serious. Such floods require operators to manually analyze the correlation of alarms in potentially complex process networks – eg, on operator screens that mimic the plant and process topology – in order to derive information on possible relations between alarms, including their chronology. This latter aspect necessitates the determination of start point for the analysis, the construction of a mental model representing the sequence of the topologically relevant alarms and the identification of the alarm that started the cascade. In large, complex plants, this sudden, event-rich situation can quickly overwhelm operators, impairing their ability to react appropriately.
To improve the operator’s alarm handling capabilities, ABB has developed an approach that enriches event and alarm history data with engineering information from a process topology model.
Process topology model
Process engineers use piping and instrumentation diagrams (P&IDs) to create blueprints for industrial processes. These diagrams specify the equipment needed and describe directed relationships between elements. Some vendors of CAD tools are pushing for the digitalization of P&ID documents so computer algorithms can process them.
On the other hand, a process or plant topology model is a formal model based on a domain-specific class library that captures the types of model elements, their semantics and their hierarchy. For example, a reference model for chemical plants will have special equipment such as a “chemical reactor” that is a subtype of “tank.” Having the P&IDs created as object-oriented models using these semantics opens the door to the automation of many engineering and operational tasks →03. Pending the support of CAD tool vendors in directly exporting P&IDs into topology models, research groups have themselves built tools to achieve this useful transformation [2,3].
![03 Example of a P&ID used as a source for generating a process topology model. Information and material flows are shown as dotted and solid lines, respectively [1].](https://resources.news.e.abb.com/images/2022/7/12/0/Informed_choice_m1102-03.jpg)
Topology-based contextual enrichment – the smart alarm list
ABB’s novel, dynamic, topology-based approach to industrial process alarms presents an effective alarm list summary enriched with contextual information, thus reducing the operators’ challenge in finding the information necessary to make decisions. This method utilizes both engineering information (ie, the process topology model described above) and operational information (ie, event and alarm history data) to derive the context for a set of triggered alarms.
The “smart alarm list” so derived presents a simultaneous integration of both the alarms’ topological relations and chronological information on the alarm summary view by:
• Utilizing the existing engineering artifacts – including the topological information about the controlled process (ie, P&IDs) – to infer the physical connections of the process equipment associated with the triggered alarms.
• Employing operational information (ie, event and alarm history data) to derive the chronological order of the topology-connected alarms.
The result of this contextual analysis is presented on the user interface as a smart alarm list in which topology-connected alarms are linked and ordered over the timeline →04. The vertical dimension of the chart represents different objects that refer to an industrial component where the alarm was triggered. If different signals belong to the same object, they are displayed on the same row. The alarm properties – active time, duration, acknowledged time, object name and priority level – are presented in a rectangle, whose width reflects the alarm’s duration. One of the key features of the chart is the visualization, using connecting lines, of alarm relationships (dependencies) based on contextual alarm analysis. This visualization aids the user in distinguishing which alarms have topological and chronological relations – thus providing vital information for root-cause analysis – and decreases operator cognitive load. The presentation format is loosely based on cause-and-effect diagrams, also known as fishbone or Ishikawa Diagrams.
User scenario
→05 shows the user and system activities associated with analyzing a specific alarm with the help of the smart alarm list. The starting point is the traditional alarm list. For example, the operator selects an alarm from a pressure transmitter, P4, in the water reinjection system on an oil rig →06. The Smart Alarm History application programming interface (API) queries the so-called Topology Navigator API for connected elements. The Topology Navigator API will perform its search across the plant topology model and will find other actuators and measurements upstream. The Smart Alarm History API combines the search results from the Topology Navigator API with the recent alarm history and finds that other pressure and flow transmitters (P1, P2, P3 and F3) show alarms. The Smart Alarm History API constructs the alarm graph and returns it to the Web front-end, where the alarm graph is drawn. The operator can then see that a pressure problem originating from the booster pump in the suction side (P1) has propagated to the whole injection system, affecting the pressure at the well (P4).
Validation
To validate the topology-based smart alarm list, ABB designed and implemented both a prototype tool that interfaces with ABB’s Extended Automation System 800xA control system and an importer that uses machine-readable P&IDs to create a topology model. →07 shows the tool’s high-level software architecture as a Unified Modeling Language (UML) component diagram.
The topology information, here stemming from P&IDs created in Microsoft Visio, is converted to a standard CAEX (a vendor-neutral data format) plant topology format by the Topology Importer. Other sources of topology information, eg, other formats of P&IDs, or even information extracted from the process representation and visualization in the control system, can be used [2].
Using the prototype tool and importer, ABB’s topology-based smart alarm list approach was successfully validated in a real-world case in a pilot plant.
Context-rich alarm lists for any process industry
Context-rich alarm lists support the process operator’s reasoning concerning a triggered alarm by putting it in a chronological relational context to other alarms that are topologically relevant to it. Compared to established alarm lists in control systems, this visualization approach can, for example, bundle alarms caused by the same disturbance, such as a stuck valve. The approach informs postmortem alarm root-cause analysis and, because it is generalizable and does not depend on specific hardware, is applicable in all segments of the process industry.
The smart alarm list concept can be used for any continuous or batch process. ABB applied it to a water reinjection pump on an oil rig and achieved a reduction of 95.5 percent in critical events presented to the operator when looking for causes of a pump trip alarm. This improvement significantly reduces the cognitive load on operators and boosts alarm management usability.
Future work will focus on, for example, integration of the alarm philosophy into future human-machine interfaces (HMIs), perhaps as a side-by-side display with a traditional alarm list. This approach would make it possible to leverage a conventional alarm list’s filter and search capabilities to retrieve a particular alarm or event of interest and then explore alarm relationships in a smart alarm list.
References
[1] H. Koziolek et al., “Industrial Plant Topology Models to Facilitate Automation Engineering,” International Conference on Systems Modelling and Management, 2020.
[2] E. Arroyo et al., “Automatic derivation of qualitative plant simulation models from legacy piping and instrumentation diagrams,” Computers & Chemical Engineering, vol. 92, pp. 112 – 132, 2016.
[3] H. Koziolek et al., “Rule-Based Code Generation in Industrial Automation: Four Large-Scale Case Studies Applying the CAYENNE Method,” Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: Software Engineering in Practice, 2020.
