Implementing Alarm Management
on a Pharma PLC

Why Alarms Are a GxP Control, Not Just a Feature

EU GMP Annex 11 requires that computerised systems include alarms to alert operators to deviations from established limits. That requirement sounds simple but has significant design implications. An alarm that alerts an operator to a deviation is only useful if: the deviation limit is scientifically justified, the alarm is reliably detected within a defined response time, the operator can take a meaningful action when it fires, and there is an audit trail that records the alarm event, the acknowledgement, and the operator's response.

Each of those four elements — justification, detection, response, and audit trail — has a corresponding design, documentation, and validation requirement. The alarm table in the FDS is where the design lives. The FDS alarm table is not a list of alarm names and setpoints copied from the SCADA configuration — it is a controlled document that records the engineering basis for every alarm limit on a GxP system.

Alarm Classification — Four Levels

Pharma alarm management uses a four-level classification that maps to both the severity of the process excursion and the required system or operator response. The classification is defined in the FDS and implemented in the PLC UDT and alarm evaluation logic.

The critical distinction that first-time pharma engineers often miss is that all four alarm levels require an audit trail entry — not just the critical HH/LL alarms. An unacknowledged H alarm is not a minor event on a GMP system; it is a documented deviation from the operating limit that an operator chose not to address. The audit trail must capture the alarm activation timestamp, the process value at activation, the alarm acknowledgement (or lack thereof), and the operator ID.

The FDS Alarm Table — What Must Be in It

The alarm table is Section 5 (or equivalent) of the FDS and is one of the most scrutinised sections during QA review. Every GxP alarm on the system must appear in the table with the following fields — all populated, none left blank or marked TBD at IQ:

The setpoint justification reference is the field most commonly left blank. It is not sufficient to state that the temperature high-high alarm is set at 85°C — the FDS must reference why 85°C is the limit. That justification lives in the process development documentation, the risk assessment, or the product specification. The FDS alarm table references it; it does not contain it in full. But the reference must be there. An alarm setpoint without a documented engineering basis is not a GxP-compliant alarm regardless of how well it is implemented in the PLC.

PLC Implementation — The Alarm State Machine

The alarm in the PLC lives in the UDT_AnalogInput_GxP (or equivalent) as a set of limit values and status bits. The evaluation logic runs in a fixed-interval cyclic OB — not OB1 — to guarantee the response time specified in the FDS is deterministic. The alarm state machine has four states that must be explicitly handled:

The rule that an alarm cannot clear without acknowledgement is not universal in industrial automation but is mandatory for GxP alarms. The reason is ALCOA+: if the alarm can self-clear without operator acknowledgement, there is no evidence that the operator was aware of the exceedance. A temperature that briefly exceeded the HH limit and self-cleared without acknowledgement looks identical to a temperature that never exceeded the limit — unless the audit trail captured the active state and the fact that it was never acknowledged before clearing.

Audit Trail — What Gets Logged and When

The audit trail requirements for alarms under 21 CFR Part 11 and EU GMP Annex 11 are specific about the minimum content of each alarm record. Three distinct events must each generate a separate audit trail entry:

• Alarm activation — timestamp (system clock, not operator-entered), process variable value at the moment of activation, alarm tag ID, alarm classification, operator ID (system-generated for automatic alarms)
• Alarm acknowledgement — timestamp, alarm tag ID, operator ID (the authenticated user who acknowledged), time elapsed between activation and acknowledgement
• Alarm clearance — timestamp, process variable value at clearance, alarm tag ID, confirmation that the value returned within limits plus the defined deadband

The time-elapsed field between activation and acknowledgement is a derived value but is specifically required by some site QA teams — verify this with the client QA during the FDS review. If it is required, it must be calculated in the PLC (not the SCADA historian) and included in the audit trail record at acknowledgement time.

Alarm Setpoint Changes — Change Control Territory

Alarm setpoints on a validated system are GxP parameters. They were set at a specific value with a documented engineering justification, and that value was verified in the OQ. A change to an alarm setpoint is therefore a change to a validated parameter — it requires change control, a risk assessment of the change, and retest evidence.

The implementation must enforce this. Alarm setpoints must be stored in configurable data blocks with access restricted to the engineering access level — not operator level. Any write to an alarm setpoint must trigger an audit trail entry logging the old value, the new value, the user ID, and the timestamp. The audit trail entry alone is not sufficient to satisfy change control; it is the trigger that alerts QA that a change control record must be raised. The SOP for alarm setpoint changes should specify that the audit trail entry is evidence of the change, not a substitute for the change control record.

OQ Testing — What the Alarm Test Cases Must Cover

The OQ protocol must verify every GxP alarm at its defined setpoint with a defined acceptance criterion. The test is not "the alarm activated" — it is "the alarm activated within the defined response time, at the correct setpoint value, triggered the correct system action, generated an audit trail record with the required fields, and cannot be cleared without acknowledgement." Each of those sub-criteria needs an explicit pass/fail check in the test case.

• Inject a simulated process value exceeding the alarm setpoint — verify alarm activates within the FDS-defined response time
• Verify the audit trail record is generated at activation with the correct timestamp, PV value, and alarm tag
• Return the simulated value to normal — verify the alarm does not auto-clear without acknowledgement
• Acknowledge the alarm with a test user account — verify the audit trail records the acknowledgement with operator ID and timestamp
• Verify the alarm clears only after acknowledgement and process value returning within limits plus deadband
• For HH/LL critical alarms — verify the automatic system action (shutdown, interlock) was triggered at the correct setpoint
• For configurable setpoints — verify that a setpoint change generates an audit trail entry with old value, new value, and user ID

The simulation bit in the UDT_AnalogInput_GxP is what makes these test cases executable without live process conditions. The IQ verification step confirms all simulation bits were activated and cleared correctly. The OQ alarm tests use the simulation bit exclusively — connecting live process inputs to verify alarm thresholds during an OQ is not repeatable and creates risk for product in the facility.