This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

Managing change in alarm rationalisation

29 March 2016

It is essential to manage change when making modifications to process alarms and alarm systems. Management of Change (MoC) should,  therefore,  be a fundamental process within the alarm management lifecycle, argues Ian Brown.

It is widely recognised throughout the process industries that making changes to assets can be prone to error. Indeed, some incidents have been attributed to poorly executed or unapproved changes. Making any change, no matter how large or small, poses risk unless the associated risks are comprehensively evaluated and documented within a structured, well defined MoC process.

It is essential to manage change when making modifications to alarms and alarm systems. They are one level of mitigation against the potential for any safety, environmental, financial or product quality incidents in a plant.

On any process plant, one inappropriately modified alarm could be responsible for an incident that attracts regulatory attention, or results in production losses. A robust MoC process should also  allow for the tracking and management of any changes, but should also incorporate checks and balances to ensure that the changes are appropriate and safe, and must include appropriate levels of review and authorisation within its structure.

MoC is a fundamental process within the alarm management lifecycle as defined in the relevant standards and guidance. In reality, it covers the processes from alarm identification through to implementation, and is also valid and necessary in the operation and maintenance phases when alarm modifications may be required due to process or plant changes. It is also relevant when considering an alarm philosophy that may need to be updated as systems are modified, upgraded or replaced.

So, it is reasonable to conclude that MoC is applicable to the whole alarm management lifecycle, throughout the life of a system. When developing an alarm philosophy in compliance with the alarm management standards, a section detailing management of change is required content.

Alarm rationalisation?
Alarm rationalisation covers the process of reviewing every alarm in the system for its suitability. This is valid for both greenfield and existing installations. Unnecessary alarms reduce operator effectiveness, and further compromise the operators’ ability to address critical alarms.

During an alarm rationalisation project, every alarm state, (high, LoLo, bad PV, status etc.), should be reviewed to determine whether it meets the criteria for a good alarm as defined in the alarm philosophy. If it does not, it should either be demoted to an event, or removed from the alarm population. If an alarm is to be kept, set points, priority and deadbands should be reviewed and modified where necessary; and the appropriate response to the alarm, the consequence of failure to respond to the alarm, and many other related attributes need to be documented.

During an alarm rationalisation project, it may be necessary to make tens of thousands of changes to alarms and associated parameters, so it is vital to manage those changes using a robust, structured and auditable MoC process.

What are we going to manage?
For any alarm system, it is necessary to manage all the information associated with the alarm. In addition, it is necessary to manage all the ancillary information such as possible cause of the alarm, operator actions andconsequence of failure to respond. Collating and managing other information could also be done, such as P&ID references, cause and effects references, instrument type and location, and computerised maintenance management system (CMMS) cross references. But where should all this information be kept?

On many plants, an alarm database is actually a collection of spreadsheets, each of which holds different data in differing numbers of rows and columns and in different formats. Some data, such as alarm setpoints, may even be available only in a textual format within operational manuals.

It is often the case that plant personnel are aware of need for a single, centralised, up to date list of alarms, perhaps including trip points and interlock settings, but no-one ever has the time to collate all the sources of information. 

Somehow, all these data need to be brought together into a single, dedicated repository, which is easily accessed and robustly managed. This repository is defined in the alarm management standards as ‘authorized list of rationalized alarms and associated attributes’. This is often called a master alarm database and makes it possible to adequately manage alarm systems.

For most process plants, the starting point for a master alarm database is simply a control system configuration dump. While this may not deliver a database of all alarms, for example, those associated with standalone ESD or F&G packages, it will generate a complete list of all alarms that could be presented to the operator through the control system HMI, whether or not they are documented or known about.

Databases versus spreadsheets
Many ‘alarm databases’ are held as spreadsheets because people are more comfortable with this format –they are easy to use and the learning curve is not as steep as trying to understand the vagaries of a database. In a spreadsheet, you can ‘add another column’. With a database, you must consider the design and interactions of your tables.

Spreadsheets undoubtedly have their place in the office environment, but were fundamentally designed as data analysis tools. Unlike databases, they are not designed as data management tools which is what is needed.

Aside from the size of the spreadsheet, as you add and store more data your spreadsheet becomes slower and more unwieldy. Also, only one person can edit data at any one time. With a properly designed database, multiple, concurrent users are able to access and edit the database, although individual records are locked to individual users as they are updated.

Once data are changed in a cell in a spreadsheet, the previous data are lost. There is no audit trail. How do you identify the one change made in 5,000,000 cells when you need to? If you wish to keep track of the original values as well as those modified; you either keep another version of the spreadsheet, or add an ‘original values’ tab to the existing spreadsheet.

There are so many other drawbacks to using a spreadsheet, such as how to create an alarm response manual from modified data, or export a list of modifications for review or re-import back into your control system.

To best manage alarms and alarm systems a robust MoC process and a comprehensive, fully populated master alarm database is a good solution.

Many companies will consider creating their own, bespoke, master alarm database. However, this does require careful consideration:
 Who is going to create the database?
 How long will it take before it is ready for use?
 Who will maintain the code and fix bugs as they become apparent?
• Will the creator understand exactly what the needs and requirements or the project are?

Creating a Master Alarm Database tool is not straightforward. It is not just a list of alarms. There are many elements to consider, not least of which is the need to create a comprehensive user requirement specification (URS). This explains how to:
• Import data from the control system into the master alarm database.
• Export the modified data back out and into the control system?
• Use the tool to carry out reviews and alarm rationalisation projects? 
• Use the tool to determine the priority of alarms?
• Is there a ‘priority wizard’ embedded in the tool?

Also ask whether the tool allows for the creation of an alarm response manual; whether it enables multiple rationalisations to be carried out on multiple systems; whether it allows for progress tracking of rationalistion projects; and whether it displays the distribution of alarm priorities and compares this to the target.

Don’t forget about ongoing support for the tool.  It is important to consider what will happen if the tool crashes and the person who wrote it is no longer available. 

For those who are serious about alarm management and wish to comply with the standards, managing change is a requirement. It is only possible to manage alarms with a dedicated master alarm database where all the data resides.

Ian Brown is alarm rationalisation & services manager at MAC Solutions.

Contact Details and Archive...

Print this page | E-mail this page