Configuration Is Not Rationalisation
If you've read the article on ISA-18.2 alarm rationalisation, you know that rationalisation is the upstream process — it determines what every alarm's setpoint, priority, and required operator response should be, and produces the FDS alarm table. Configuration is the downstream act of implementing those decisions in the SCADA platform. The two are often conflated, and that conflation causes problems.
The most common version of the problem: a SCADA is configured with alarm priorities that were assigned during configuration by whoever happened to be at the keyboard, with no documented rationalisation process behind them. The FDS alarm table doesn't exist, or doesn't match what's in the system. At FAT, QA asks for the document that justifies why that conductivity alarm is High and not Critical. There isn't one. That's a deviation that stops the FAT.
The correct sequence is: rationalisation produces the FDS alarm table → configuration implements it exactly → FAT verifies the configuration matches the FDS table → OQ retests the critical ones in the installed environment. This article covers the configuration side: what the SCADA needs to implement, how suppression and shelving work, and what the OQ tests for.
Priority Configuration — What Each Level Actually Does
Alarm priority in a GMP SCADA is not a cosmetic choice. The priority drives four distinct system behaviours: display colour and flash pattern, audible alert type and repeat cycle, acknowledgement requirement, and suppression access control. All four must be consistent with the Control Philosophy and FDS. If the FDS says Critical alarms use a sustained audible tone and your SCADA plays a single chime, that's a design non-conformance — and it will be found at FAT.
One configuration detail that frequently causes FAT deviations: the audible silence behaviour for Critical alarms. ISA-18.2 and the GMP Control Philosophy both require that a Critical alarm audible cannot be silenced by the operator — only acknowledgement stops the tone. Systems where operators can click a "mute" or "silence" button on the alarm banner without acknowledging the alarm are non-compliant. The test at FAT is simple: activate a Critical alarm and attempt to silence the audible without acknowledging. If the audible stops, it's a deviation.
Platform-specific note: in Ignition the alarm pipeline and notification profiles control this behaviour. In WinCC the alarm class configuration drives it. In FactoryTalk View SE it's the alarm setup in the alarm server. In Wonderware InTouch it's the alarm DB Logger configuration combined with the alarm display scripts. The configuration approach differs across platforms, but the required behaviour is identical.
The ISA-18.2 Five-State Machine — What the SCADA Must Implement
The single most common alarm management configuration failure in pharma SCADA systems is the missing RTN_UNACKNOWLEDGED state. This is the state where the process has returned to normal — the alarm condition is gone — but the operator has not yet acknowledged that it occurred. ISA-18.2 requires this state to exist and to remain visible in the active alarm list until explicitly acknowledged. Many SCADA configurations auto-clear alarms on return to normal, which means an alarm can fire and clear with no operator acknowledgement and no record that it required a response.
The practical consequence of a missing RTN_UNACK state is this: during a night shift, a High conductivity alarm fires briefly and auto-clears. The operator on duty doesn't see it or ignores it. The alarm history shows it occurred, but there's no acknowledgement record, no indication that anyone responded, and — critically — no audit trail entry showing who saw it and decided no corrective action was needed. An inspector reviewing the alarm history asks why there's no acknowledgement for a High quality alarm. There isn't a good answer.
The OQ test for this state is simple and must be executed: activate an alarm, do not acknowledge it, allow the process to return to normal, and verify that the alarm remains visible in the active alarm list with a "RTN Unacknowledged" status marker. Then acknowledge it and verify it moves to closed. Both steps are required in the test protocol — missing the second step is also a common omission.
Suppression vs Shelving — The Difference That Matters
These two terms are used interchangeably in some platforms and loosely in conversation, but in a GMP SCADA they refer to distinct mechanisms with different regulatory implications. Getting the terminology wrong in the FDS or SDS creates confusion at FAT review.
Suppression is applied to an alarm that is currently active — it tells the system "I know this alarm is firing, I have a reason, don't annunciate it for a defined period." The alarm condition still exists. The alarm is still recorded in history. It is visible in a dedicated Suppressed Alarms view. Shelving is applied to an alarm that is not currently active — it pre-emptively prevents a known alarm from annunciating during a planned activity (calibration, maintenance, controlled startup). The difference is timing: suppression is reactive, shelving is proactive. Both require Supervisor authorisation, both require a reason, both have a maximum duration, and both are audit-trailed.
The regulatory concern with both mechanisms is the same: unauthorised alarm suppression is a recurring FDA 483 and MHRA inspection finding. The fix is not to eliminate suppression and shelving — they are legitimate and necessary tools. The fix is to enforce documented controls around them: role restriction, mandatory reason text, maximum duration with auto-expiry, and an always-visible suppressed/shelved alarms view that makes it impossible to claim ignorance of what's been muted.
Suppression Configuration Requirements
- Role enforcement: Supervisor minimum to suppress any alarm. Critical alarms require Administrator role — this must be enforced in the SCADA, not just stated in the SOP. The OQ tests this adversarially: a Supervisor attempting to suppress a Critical alarm must be blocked.
- Mandatory reason text: The SCADA must require a reason entry before accepting the suppression. Minimum 10 characters is a reasonable enforcement threshold. The reason becomes part of the audit trail record. A blank reason field is not acceptable.
- Maximum duration with auto-expiry: Standard suppression maximum is 4 hours, configurable by Administrator. On timer expiry the alarm auto-reactivates and generates a "Suppression Expired" advisory event. There is no indefinite suppression.
- Suppressed Alarms view: All active suppressions must be visible in a dedicated view accessible from the alarm management screen by Read-Only role and above. This view must show: alarm tag, description, suppressing user, start time, expiry time, and reason. Suppressions cannot be hidden.
Shelving Configuration Requirements
- Scope restriction: Shelving applies per-tag, not per-area or per-priority. You can shelve the alarms on instrument AIC-001 while it is out for calibration without shelving all conductivity alarms.
- Maximum duration: 8 hours is a common maximum for shelving — longer than suppression because maintenance windows can extend overnight, but still bounded.
- Shelved Alarms view: Same requirement as the suppressed alarms view — all shelved alarms visible, with who, why, and when.
- Audit trail on activation and deactivation: Both the start and end of shelving must generate audit trail entries, including the instrument returned to service and the user who cleared the shelve.
Alarm Database Configuration — What the Historian Must Record
In a GMP SCADA, the alarm database is a GMP record. Every alarm state transition — not just the activation, but the acknowledgement, the return to normal, and the closure — must be written to the historian with the full set of required fields. Missing fields discovered at OQ are a deviation and may require re-execution of the affected test.
The required fields for every alarm history record are not optional. The historian must capture: alarm tag name (matching the FDS Appendix B ID exactly), alarm description, priority, process area, activation timestamp (NTP-synchronised), acknowledgement timestamp plus the user ID of the acknowledging user, return-to-normal timestamp, and the process value at the time of alarm activation. All fields must be non-null — a historian configuration that allows null acknowledgement fields when an alarm is acknowledged by an unknown or deleted user account is a data integrity failure.
The alarm tag name in the SCADA alarm database must be identical to the alarm ID in FDS Appendix B and to the tag name used in OQ test protocols. Any discrepancy between these three — even a case difference or underscore variation — creates a traceability gap. During OQ you cannot verify "ALM-COND-002 fired at 14:32:01" against a historian record showing "alm_cond_002" without an explanation. Tag names are frozen at FAT baseline. A post-FAT tag name change is a change control event requiring OQ retesting of all affected historian queries and reports. This is documented in the SDS tag naming convention — see the SCADA project structure article for the naming convention design.
OQ Test Cases for Alarm Management
The rationalisation article covers the FAT alarm tests. The OQ retests the critical ones in the installed environment, and adds boundary and adversarial tests that FAT doesn't require. Here are the mandatory OQ test cases for alarm management — these should be in every OQ protocol regardless of system type.
RTN_UNACKNOWLEDGED state test (HIGH risk): Activate an alarm. Allow the process to return to normal without acknowledging. Verify the alarm remains in the active alarm list with RTN_UNACK status. Verify the audible has stopped (because the alarm condition cleared) but the visual indicator remains. Then acknowledge — verify the alarm closes and the acknowledgement record in the historian includes user ID and timestamp.
Suppression access control test (HIGH risk — adversarial): As Operator role, attempt to suppress an active alarm. Must be blocked. As Supervisor, suppress an active non-Critical alarm with a valid reason. Verify the suppressed alarms view, the audit trail entry, and the auto-expiry behaviour. As Supervisor, attempt to suppress a Critical alarm. Must be blocked with a clear message. As Administrator, suppress the Critical alarm — must be permitted.
Alarm history read-only test (adversarial): Attempt to modify or delete an alarm history record directly in the historian database. Must be rejected. This mirrors the audit trail write-once test — the same SQL-level protection that prevents audit trail modification must also cover the alarm history table. The expected result is an explicit SQL permission denied error, not just an absence of change.
Alarm setpoint boundary test: For each Critical and High alarm, set the process value to exactly the alarm setpoint. Verify the alarm activates. Apply the configured deadband — verify the alarm does not clear until the value moves below the deadband threshold. This is a boundary test, not a comfortable mid-range test. The deadband verification step is the one most often missed.
The SDS-SYS-001 Section 5 documents the full alarm management software design: the ISA-18.2 five-state machine implemented in FB_AlarmManager, the alarm database logger configuration with all required field definitions, and the suppression implementation including Supervisor/Administrator role enforcement, mandatory reason text (10-character minimum), maximum duration (4 hours standard, 8 hours Administrator), and auto-reactivation on expiry. The typ_Alarm_GxP UDT in Section 2.3 defines the data structure for each alarm instance — including the b_Suppressed flag and s_AckReason mandatory field. The FDS Appendix B alarm table provides 25 worked entries covering all process and system alarms for the system type, with priority, setpoint, deadband, and acknowledgement requirements pre-filled. The OQ-SYS-001 test cases OQ-051 (RTN_UNACK state machine) and OQ-052 (suppression boundary with adversarial Operator/Supervisor/Admin role tests and Critical alarm suppression block) are the exact test cases described in this article — structured, expected results defined, with FAT cross-reference and evidence attachment fields.