For the process industries, it is essential to manage change when making modifications to alarms and alarm systems. Management of Change (MoC) should therefore be a fundamental process within the alarm management lifecycle, says Ian Brown
It is widely recognised throughout the process industries that making changes to assets can be prone to error. Indeed, some plant accidents and incidents have been attributed to poorly executed or unapproved changes. Making any change, no matter how large or small, is an inherently risky business, 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 your alarms and alarm systems. Alarms within your alarm system are one level of mitigation against the potential for any safety, environmental, financial or product quality incidents on your plant.
On any process plant, one inappropriately modified alarm could be responsible for an incident that attracts regulatory attention, or results in a significant loss of production or generating capacity.
A robust MoC process must not only allow you to manage and track any changes you may make, but should also incorporate checks and balances to ensure the changes are appropriate and safe, and must include appropriate levels of review and authorisation within its structure.
Management of change is a fundamental process within the alarm management lifecycle as defined in the relevant standards and guidance (see Fig1: “Alarm Management Lifecycle”). In reality, it not only covers the processes from alarm identification through to implementation, but is also valid and necessary in the operation and maintenance phases when alarm modifications may be required due to process or plant changes, and indeed is relevant when considering an alarm philosophy that may need to be updated as systems are modified, upgraded or replaced.
It is therefore reasonable to conclude that management of change is applicable to the whole alarm management lifecycle, throughout the life of your system; and don’t forget, when developing an alarm philosophy in compliance with the alarm management standards, a section detailing management of change is required content.
What is alarm rationalisation?
Alarm rationalisation is the arduous but necessary process of reviewing every alarm in your system for its suitability. This is valid for both Greenfield and existing installations. Unnecessary alarms greatly reduce the effectiveness of operators, and further compromise the operators’ ability to address critical alarms, which can be extremely costly.
During an alarm rationalisation project, every alarm state, (High, LoLo, Bad PV, Status etc.), should be reviewed to determine if it meets the criteria for a good alarm as defined in your alarm philosophy. If it does not, it should either be demoted to an event, or removed entirely from the alarm population. If an alarm is to be kept, set points, priority, deadbands, etc. should be reviewed and modified where necessary; and we should also document the appropriate response to the alarm, the consequence of failure to respond to the alarm and many other related attributes.
If we consider that during an alarm rationalisation project, we could be making some tens of thousands of changes to our alarms and associated parameters, it is absolutely essential that we manage those changes using a robust, structured and auditable MoC process.
What are we going to manage?
For any alarm system, we need to manage all the information associated with our alarms, such as tag name, descriptor, priority, deadband, etc. In addition, we will need to manage all the ancillary information such as possible cause(s) of the alarm, operator action(s), consequence of failure to respond, etc. We may also choose to collate and manage other information such as P&ID references, cause and effects references, instrument type and location, computerised maintenance management system (CMMS) cross references, etc. But where should we keep all this information?
What and where is our Master Alarm Database?
Considering the points above, a huge amount of information needs to be stored and managed. 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 disparate formats. Some data, such as alarm setpoints, may even be available only in a textual format within operational manuals.
In some cases, these spreadsheets are “on the network somewhere”, or “Bill has it on his PC, he’s been working on it”. Often, there’s a trip and alarm register that was “started a few years ago, but needs updating”. It is very often the case that plant personnel know they should have a single, centralised, up to date list of alarms, perhaps including trip points and interlock settings, but no-one has the time to collate all the sources of information. It’s out there somewhere, but when it’s looked for, it isn’t there.
Somehow, all these data need to be brought together into a single, dedicated repository, which is easily accessed and robustly managed. This repository is more often known as a Master Alarm Database, and is defined in the alarm management standards as ‘authorized list of rationalized alarms and associated attributes’. Without a Master Alarm Database containing all our alarms, it will be impossible to adequately manage our alarm systems.
For most process plants, the starting point for any Master Alarm Database is simply a complete control system configuration dump. Whilst 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 most people are comfortable with using a spreadsheet; 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 they have been fundamentally designed as data analysis tools. They do have some database functionality included but, unlike databases, they are not designed as data management tools and this is what we need.
Aside from the size of the spreadsheet, as you add and store more data (tags, parameters and ancillary information), your spreadsheet becomes slower and more unwieldy. Also, only one person can edit data in your spreadsheet at any one time. With a properly designed database, multiple, concurrent users can 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.
So, we can use a spreadsheet as our Master Alarm Database, but it will be a logistical nightmare. In order to manage alarms and alarm systems, it is essential that we have both a robust MoC process and a comprehensive, fully populated Master Alarm Database.
Use your head: use a database
Once we’ve realised that we need to use a database and not a spreadsheet as the foundation of our Master Alarm Database, do we create our own in-house tool, or purchase a third party tool such as Guardian from M.A.C. Solutions?
In-house may sound like an excellent option, as we won’t have to raise a purchase order for expensive software and we can tailor our database to our individual requirements. However, we need to stop and think carefully about the following:
* Who is going to create our database?
* How long will it take before it’s ready for use?
* Who will maintain the code and fix bugs as they become apparent?
* Will they understand exactly what our needs and requirements are?
While creating your own internal, bespoke tool may seem like the ideal option, doing so is fraught with difficulty. Who will carry out the work? Most IT departments do not employ staff to write bespoke applications.
Creating a Master Alarm Database tool is not a straightforward task. It is not just a list of alarms. There are many elements you must consider before you decide to create your own tool, not least of which is the need for you to create a comprehensive user requirement specification (URS), without which, your tool will fail to meet your needs. For example, how do you:
* Import the data from your control system into your Master Alarm Database?
* Export the modified data back out and into your control system?
* Use your tool to carry out reviews and alarm rationalisation projects?
* Use your tool to determine the priority of your alarms?
* Is there a ‘priority wizard’ embedded in your tool?
Does your tool:
* Allow / simplify the creation of your Alarm Response Manual? (The information is all in there).
* Allow you to carry out multiple rationalisations on multiple systems?
* Allow you to track progress of your rationalistion projects?
* Display the distribution of alarm priorities and comapare to to your target?
Don’t forget about ongoing support for your tool. With the best will in the world, most internal tools are created by enthusiastic people who have a modicum of knowledge. But the code they write is often messy, uncommented and undocumented, and in most cases, not robust. Consider what will happen when the tool crashes and the person who wrote it is in a different role or has left the company. Who then will have the time or ability to resolve the problems you are experiencing? Most certainly, it will NOT be your IT department!
Conclusion
If you are serious about alarm management and wish to comply with the standards, managing change is a requirement. Also, you can only truly manage your alarms if you have a dedicated Master Alarm Database where all your data resides.
Ian Brown, Alarm Rationalisation & Services Manager at M.A.C. Solutions.
