February 2016, Vol. 243, No. 2
Features
Importance of Management of Change in Alarm Modifications
For process plants and gas pipeline networks, 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.
It is widely recognized throughout the process industries that making changes to assets can be prone to error. This is equally true for energy pipelines and managing alarms across a distributed network of pipelines, often over vast distances with multiple aboveground installations (AGIs).
Indeed, some pipeline 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 pipeline alarms and alarm systems. Alarms within the system are one level of mitigation against the potential for any safety or environmental incidents on the pipeline network.
On a gas pipeline, one inappropriately modified alarm could be responsible for an incident that attracts regulatory attention, or results in a significant loss of gas.
A robust MoC process must not only allow an operator to manage and track changes, but should also incorporate checks and balances to ensure the changes are appropriate and safe, and must include appropriate levels of review and authorization.
Management of change is a fundamental process within the alarm-management lifecycle as defined in the relevant standards and guidance. 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 changes. It is indeed is relevant when considering an alarm philosophy that may need to be updated as systems are modified, upgraded or replaced.
It is reasonable to conclude management of change is applicable to the whole alarm management life cycle throughout the life of the system; don’t forget that when developing an alarm philosophy in compliance with the alarm-management standards, a section detailing management of change is required content.
Alarm Rationalization
Alarm rationalization is the arduous but necessary process of reviewing every alarm in the system for its suitability. This is valid for both new and existing pipeline installations. Unnecessary alarms greatly reduce the effectiveness of operators, and further compromise the operator’s ability to address critical alarms, which can be extremely costly.
During an alarm-rationalization 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. Appropriate response to the alarm should also be documented.
Considering that during an alarm-rationalization project, tens of thousands of changes could be made to alarms and associated parameters, it is essential that changes are managed using a robust, structured and auditable MoC process.
For any alarm system, all the information associated must be managed, including the tag name, descriptor, priority and deadband. In addition, all the ancillary information must be managed such as possible causes of the alarm, operator actions and consequences of failing to respond.
Other information such as P&ID references, cause and effects references, instrument type and location, and computerized maintenance management system (CMMS) cross references must be collated and manage. But where should this information be kept?
Master Alarm Database
A huge amount of information needs to be stored and managed. On many pipelines, 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 set points, may even be available only in a textual format within operational manuals.
In some cases, the explanation is that 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 frequently the case that personnel know they should have a single, centralized, 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 sought out, it isn’t there.
Somehow, all this 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 an “authorized list of rationalized alarms and associated attributes.” Without such a database containing all the alarms, it will be impossible to adequately manage an alarm system.
For most energy pipelines, the starting point for a master alarm database is simply a complete control system configuration dump. While this may not deliver a database of all alarms, for example, those associated with standalone emergency shutdown (ESD), it will generate a complete list of all alarms that could be presented to the operator through the control system human machine interface (HMI), whether or not they are documented or known about.
Databases vs. Spreadsheets
Many alarm databases are held as spreadsheets because most people are comfortable using a spreadsheet; they are said to be 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; however, unlike databases, they are not designed as data management tools, which is what we need.
Aside from the size of the spreadsheet, as more data is added (tags, parameters and ancillary information), it becomes slower and more unwieldy. Also, only one person can edit a 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 the cell of a spreadsheet, the previous data are lost. There is no audit trail. How do you identify the one change made in 5 million cells when you need to? To keep track of the original values as well as those modified, a user must either keep another version of the spreadsheet, or add an “original values” tab to the existing spreadsheet.
There are many other drawbacks to spreadsheets, 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 the control system.
So, using a spreadsheet as the master alarm database proves to be a logistical nightmare. In order to manage alarms and alarm systems, it is essential to have both a robust MoC process and a comprehensive, fully populated master alarm database.
Use Your Head
Once the need for a database has been determined to be the foundation of master alarm database, it must be determined if it is best to create an in-house tool, or purchase a third-party tool.
In-house may sound like an excellent option, as it avoids filling out a purchase order for expensive software, and allows the database to be tailored to individual requirements. However, the following points must be considered:
- 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?
- Will needs and requirements be understood?
While creating an internal 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 customized applications.
Creating a master alarm database tool is not a straightforward task. It is more than a list of alarms. There are many elements to consider before deciding to create a customized own tool, not least of which is creating a comprehensive set of user requirement specifications (URS), without which needs will not be met. For example, how will users:
- Import the data from the control system into the master alarm database?
- Export the modified data back out and into the control system?
- Employ the tool to carry out reviews and alarm-rationalization projects?
- Determine the priority of alarms?
Also, does the tool simplify the creation of the alarm-response manual, allow the user to carry out multiple rationalizations on multiple systems or allow tracking and progress of rationalization projects?
Don’t forget about the need for ongoing support for the tool. With the best intentions in the world, most internal tools are created by enthusiastic people who have a modicum of knowledge. However, the code they write is often messy, uncommented, undocumented and in most cases, not robust.
Consider what happens if the tool crashes and the person who wrote the code has left the company. Who then will have the time or ability to resolve the problems? Most certainly, it will not be the IT department!
Conclusion
For those serious about alarm management and who wish to comply with standards, managing change is a requirement. Also, alarms can only be truly managed with a dedicated master alarm database in which all data resides.
For further information, visit www.processvue.com.
Written by Ian Brown, M.A.C. Solutions
Comments