What Alarm Rationalisation Is — and Is Not
Alarm rationalisation is frequently confused with alarm configuration. Configuration is the technical act of entering a setpoint and priority into the SCADA alarm database. Rationalisation is the upstream process that determines what that setpoint and priority should be — and whether the alarm should exist at all. On a pharma project, rationalisation happens before configuration, and it produces the FDS alarm table that configuration is built from.
ISA-18.2 (IEC 62682) defines alarm management as a lifecycle, not a configuration task. The lifecycle includes alarm philosophy, identification, rationalisation, detailed design, implementation, operation, maintenance, and continuous improvement. On a new pharma project, the relevant phases are: philosophy (documented in the Control Philosophy), rationalisation and detailed design (documented in the FDS alarm table), and implementation (SCADA configuration verified at FAT).
ISA-18.2 defines an alarm as valid only if all three of the following are true: (1) the abnormal condition requires operator awareness — if no operator action is needed, it is not an alarm; (2) the operator has time to respond — an alarm that fires faster than an operator can react is not an alarm, it is an interlock input; (3) the operator can do something meaningful — if the only correct response is "wait and see," it is not an alarm. Applying this test during rationalisation removes the majority of nuisance alarms that plague systems built without a formal rationalisation process.
The Four Priority Levels — What Each Means
ISA-18.2 recommends a four-tier priority system. On a GMP SCADA the priority assignments must be documented in the Control Philosophy and consistently applied across the FDS alarm table. The priority is not a preference — it drives the SCADA display behaviour, the audible alert pattern, the acknowledgement requirement, and the operator response expectation.
The Rationalisation Process — Seven Questions Per Alarm
The formal rationalisation process for each alarm asks seven questions. The answers populate the FDS alarm table and justify every design decision. This process is typically conducted as a structured workshop with the process engineer, automation engineer, and QA representative present — not a solo desk exercise by the SCADA programmer.
- Is this an alarm or an event? Events (system status changes, operator actions) belong in the event log, not the alarm list. Only conditions requiring operator action are alarms.
- What is the process consequence if this alarm is missed? If the consequence is patient safety or product quality impact → Critical or High. If the consequence is process inefficiency with no GMP impact → Medium or Low. If there is no meaningful consequence → delete the alarm.
- What specific action should the operator take? If you cannot write a specific operator response (not "investigate" — a specific action), the alarm is not ready to be added to the system.
- What is the setpoint, and why is it at that value? The setpoint must reference a process specification, a validated operating range, or an engineering justification. "Default" is not a justification.
- What deadband prevents chattering? A setpoint of 75°C with no deadband will generate alarms continuously near the trip point. The deadband must be defined and documented.
- How much time does the operator have to respond before the situation worsens? This determines whether the alarm response time (detection to display) in the FDS is adequate.
- Does an automatic system action accompany this alarm? If yes — what action, and is it documented in the interlock register?
The FDS Alarm Table — The Output of Rationalisation
The rationalisation output is the FDS Appendix B alarm table. Every alarm that exists in the SCADA configuration must have a corresponding row in this table. The FDS alarm table is not the SCADA alarm database export — it is the design document that the SCADA alarm database is built from, and it exists before the SCADA is configured. This sequencing is important: if the table is populated after configuration by exporting from the SCADA, it is documentation of what was done, not a specification of what should be done.
| Field | Content | Rationalisation Question It Answers |
|---|---|---|
| Alarm Tag ID | e.g. ALM_TT_R01_101_H — matches SCADA tag exactly | Is this in the tag naming convention? |
| Description | Plain-language text matching HMI alarm display exactly | Will the operator understand this alarm? |
| Priority | Critical / High / Medium / Low per CP-SYS-001 Section 3.1 | What is the process consequence? |
| Setpoint | Numerical value + EU + justification reference | Why is the setpoint at this value? |
| Deadband | Hysteresis value preventing chattering | Will this alarm chatter near the setpoint? |
| Detection time | Maximum detection cycle (e.g. 1 second per FUNC-ALM-001) | Is the detection fast enough for the response time? |
| System action | Automatic action triggered, or "None" | Is there an automatic response, and is it in the interlock register? |
| Required operator response | Specific action — not "investigate" | What should the operator do? |
| Acknowledgement required | Yes / No (Yes for all GMP alarms) | Does the operator need to confirm awareness? |
| URS reference | URS requirement ID this alarm traces to | Is this alarm required? |
Alarm Flooding — The GMP Risk
ISA-18.2 defines alarm flooding as more than 10 alarms in a 10-minute period. On a well-designed system this should be rare — a genuine emergency might produce 10–15 alarms in a short window. On a poorly rationalised system, a single process upset can generate hundreds of alarms as every downstream consequence cascades through the alarm list, overwhelming the operator with noise precisely when they need clarity.
On a pharma system, alarm flooding has an additional consequence beyond operator confusion: every alarm in the flood generates an audit trail record. A 200-alarm flood creates 200 audit trail entries, each requiring acknowledgement. An operator who acknowledges 200 alarms in a few minutes is not reviewing each one — they are clicking through to clear the banner. The audit trail shows this pattern, and QA reviewers who examine alarm history will notice. It is difficult to argue that product quality was protected by operators who mass-acknowledged 200 alarms in five minutes.
The rationalisation process prevents flooding by removing alarms that don't meet the ISA-18.2 validity test — particularly consequence-free alarms, duplicate alarms that fire simultaneously for the same root cause, and alarms that should be events. A good target for a pharmaceutical SCADA of typical complexity is 150–400 alarms total. A system with 1,200 configured alarms that has never been rationalised is a compliance risk regardless of how well each individual alarm is documented.
Suppression — Another Rationalisation Output
Alarm suppression on a GMP SCADA is not a workaround for nuisance alarms — it is a documented, controlled capability for legitimate use cases: suppression during maintenance windows, suppression during equipment cleaning (when the system is intentionally offline), or suppression of an alarm whose condition is known and acknowledged while corrective action is in progress.
The rationalisation process should identify which alarms are legitimately suppressible and under what conditions. This feeds into the FDS alarm table (a "suppressible" flag and conditions column) and into the operational SOPs. An alarm that is routinely suppressed because its setpoint is wrong is not a suppression candidate — it is a setpoint change through change control. Suppression as a substitute for correct configuration is a GMP deviation waiting to be discovered at a periodic review.
The Control Philosophy (CP-SYS-001) Section 3 defines the alarm management philosophy — the four priority levels with display behaviour (Critical: red + flashing + sustained audible; High: orange + solid + 30-second repeat; Medium: yellow + solid + single tone; Low: blue + no audible), the critical alarm definitions for this system type, and the suppression strategy including the maximum suppression duration (4 hours, configurable by Administrator) and the requirement that Critical alarm suppression requires Administrator role. The FDS Appendix B is the alarm table — pre-structured with all ten fields described in this article, populated with 25 worked entries for the system's process alarms covering conductivity, temperature, pressure, level, pump faults, and system alarms. The FUNC-ALM-001 through FUNC-ALM-005 functional descriptions in FDS Section 3 define the detection cycle (1 second for process alarms), display requirements, acknowledgement rules, history retention (7 years minimum, read-only), and suppression controls.