It is commonly touted that once a plant rationalizes their alarms, they have completed the alarm management lifecycle. Nothing could be further from the truth. So what can an organization do to keep the alarm lifecycle alive and evergreen?
Alarm management is the collection of processes and practices for determining, documenting, designing, operating, monitoring, and maintaining alarm systems. It is characterized by design principles including hardware and software design, good engineering practices, and human factors. Tying the alarm management lifecycle into process safety management and other work processes that already exist will help ensure it remains evergreen and delivers the intended benefits. While the integration of these activities will look different for each company, time has shown that success comes most easily when the management of change process, testing and training activities have been integrated into what is already being accomplished.
The alarm management lifecycle is essentially a circle; there is no beginning or ending. There are different places an organization may choose to enter it, but the overall lifecycle process never really ends. An organization may have developed a philosophy, rationalized alarms, and implemented them, but that does not mean they have ‘completed’ alarm management. As processes and equipment evolve and change (e.g., removing or introducing equipment, changing flow rates, changing chemicals, etc.), different steps of the lifecycle come back into importance. The goal of alarm management should be to keep the lifecycle updated and evergreen.
Integrating the alarm management, functional safety, and cybersecurity lifecycles is a key to success and will help avoid costly rework. There are similarities in all three lifecycles (e.g., asses, implement, operate & maintain phases, management of change, testing and training requirements, etc.). The process hazards analysis (PHA) feeds the other lifecycles. When assessing items in cybersecurity, one is considering scenarios first identified in PHAs. The same is true in alarm management when an alarm is used as a protection layer.
A change in one lifecycle may, and most likely will, impact all three lifecycles. Something as minor as altering a chattering alarm (e.g., because its setpoint was too close to a shutdown value) will impact the alarm, the master alarm database, the other lifecycles, and many different process safety information documents. If normalization of deviation is allowed (i.e., not tracking and reviewing the impact of what are believed to be minor changes), alarms will eventually become unrationalized, and things will revert back to their original, un-managed state.
To learn more about the ISA 18.2 standard and how to keep the alarm management lifecycle evergreen, read the full paper “Breathing life into the alarm management lifecycle” .
