I started off my alarm management journey as a Control Systems Engineer being handed a project that had stalled for 5 years and failed to get off the ground. The main basis of the capital expenditure was to get a local integrator to develop a customised database to store alarm information. Rather than dive in and reopen the original proposal I learned about the topic and looked into the tools I had. In that initial learning phase, I purchased EEMUA191 Alarm Systems – A Guide to Design, Management and Procurement and attended some Alarm Management training with what was then Matrikon. Taking those new skills, I worked with what we had, which was a very basic alarm collection tool.
Working with this tool I could export the alarms into Excel and throw them through pivot tables to get out some of the basic data I needed such as the topmost frequent alarms and the alarm frequency data for the ISA 18.2 recommended metric of Alarms per 10 min. But doing this month after month is a tedious process and absorbed many man hours before even starting to look at resolving any issues let alone covering other requirements of the standards.
Alarm Management documentation outlines several activities that should be carried out and a software solution is a good way to ensure they are. Here are several items they can cover.
Performance Monitoring – ISA 18.2 has 13 metrics for measuring the performance of the alarm system. Some of the analysis of data required is beyond my ability with Excel and potentially the quality of the data extracted for reporting. For example, the percentage of time in flood requires the identification of periods between the initiation of a flood (more than 10 alarms in a 10-minute period) and the clearing of a flood (dropping back below 5 alarms in a 10-minute period. Another would be determining the number of occurrences of a chattering alarm (3 occurrences in 1 minute).
|
|
|
| Find out about our INTRODUCTION TO ALARM MANAGEMENT Course HERE! | We offer Consulting Services for LOPA Studies HERE! | Find out about our next PROCESS SAFETY FOUNDATIONS course HERE! |
Bad Actor Identification – We’re not talking about Nicolas Cage! These are alarms that are poorly performing. The most common example of bad actors are the most frequent alarms. These are pretty easy to ascertain but what about other signs of poor performance such as duplicate or hierarchical alarms or chattering? These can all contribute to alarm floods.
Alarm Mechanic – Some systems can even analyse the cause of the problem with poorly performing alarms and suggest how to resolve the issues.
Master Alarm Database – ISA 18.2 says you should have a master alarm database. This is where all the information about each alarm that is gathered during Alarm Rationalisation is stored such as setpoints, operator actions and allocated priority. The standard states this database should be used to audit and enforce the reviewed alarm parameters, this means it is required to be independent of the alarm list in the control system. You could use a spreadsheet or an access database for this exercise but there is a lot of useful information that will quite often remain unused if left in files.
Alarm Help – Alarm Rationalisation gathers a lot of useful information about why the alarm is in place and what the operator's response is to the alarm. Having this information fed back to the control system so they can access it easily is a useful tool.
Audit and Enforce – ISA 18.2 talks about Alarm Attribute Enforcement, which is the automatic verification and restoration of alarm attributes in the control system to the values in the master alarm database.
Alarm Shelving – Alarm shelving is the ability of the operator to temporarily inhibit an alarm. Shelving requires a managed system to identify why an alarm is shelved and how long for to ensure alarm inhibits don’t get forgotten about.
Logic/Model-Based Alarming – These are methods for ensuring alarms are more relevant by applying other conditions to the alarm. These conditions are usually calculated in some way such as First Out alarming, which selects the alarm that caused the event and hides all the others.
Our partners PAS in their Alarm Management Handbook outline the first three steps that they say must be completed for alarm management; Develop a Philosophy, Collect Data and Benchmark, and Perform Bad Actor resolution. It could be argued that these activities can be carried out without dedicated software or an in-house developed system. But in my opinion, the time saved in reducing the effort put into collecting and processing information pays for itself.
Doing just the minimum required is quite likely to solve 80% of your problems but may still not give you a healthy alarm system. PAS outlines a further 4 steps; Documentation and Rationalisation, Audit and Enforce, Real-Time Alarm Management, Control and Maintain. These tasks get a lot harder to do without software solutions.
In my view, yes you can do alarm management using in-house/custom-built systems, but why bother? Custom systems always have hidden costs, if it’s not in the failure to deliver a honed system (bug fixing costs time and effort) it might be in the need to still manually integrate data. These costs continue into the future as the platforms they are built on are upgraded and the original system is found to be obsolete. The companies building Alarm Management Software have been doing it for years, they have developed the interfaces required for your control system to seamlessly interact and they are continuing to evolve their products as technology moves on. Why wouldn’t you take the easy option?
If you would like to self-assess your current performance of alarm management at your site, have a look at this checklist.