Alarm Flood, Operator Credit, and Fatigue in a Batch Plant
At a specialty chemicals batch plant, a 2019 DCS migration reduced configured alarm deadbands and left many points at default priority. The console now has 1,150 configured alarms across three reactor trains. During a recent exothermic runaway, 438 alarms annunciated in 12 minutes; the first-out high-temperature alarm was buried under 60 low-priority messages, and the operator did not close the jacket cooling-water block valve for 24 minutes. The LOPA for the reactor high-temperature trip credits an operator response to the high-high temperature alarm with a 10-minute response time and a PFD of 0.1. The board is normally staffed by two operators, but during breaks one operator covers both console areas. The shift in question was the sixth consecutive 12-hour night shift for the lead operator. The plant's alarm philosophy document has not been updated since 2012 and does not define alarm performance metrics. EEMUA 191 suggests fewer than 1 alarm per 10 minutes per operator on average and fewer than 10 per 10 minutes during upsets.
1. Is the LOPA operator-response credit defensible? Explain the criteria you would apply.
Read the worked answer
The credit is not defensible as written. A LOPA credit for operator response requires an independent, specific, auditable, and timely action. Here the alarm was not unique or diagnosable: 438 alarms in 12 minutes is about 36 per minute, far above the EEMUA 191 upset target of fewer than 10 per 10 minutes, and the first-out alarm was buried. The credited 10-minute response was not achievable; actual response was 24 minutes. The action was also not independent of the initiating event because the same DCS and operator workload were affected by the runaway.
Human reliability evidence supports reducing or removing the credit. A PFD of 0.1 is typically justified only with a clear alarm, written response procedure, adequate response time, and trained operator under normal workload. With alarm flood, a sixth consecutive night shift, and one operator covering two consoles during breaks, the human error probability is more plausibly 0.3–0.5 or higher. If the credit is reduced to 0.5 or removed, the LOPA IPL count changes and the required risk reduction may no longer be met. The correct response is to re-run the LOPA with a defensible human failure probability, then add an independent engineered protection layer - for example, an automatic high-temperature trip that closes the cooling-water block valve or a redundant temperature sensor with independent logic - rather than relying on the operator.
2. Prioritize the alarm system improvements. What should be done first, and what metrics would show improvement?
Read the worked answer
First, rationalize the alarm system using a master alarm database: assign priority by consequence and time to respond, restore meaningful deadbands, suppress chattering and stale alarms, and configure first-out and dynamic suppression so safety-critical alarms remain visible during upsets. Do not simply delete alarms; deleting low-priority messages without analyzing operator load can hide the next first-out event.
Second, fix the human-machine interface: group alarms by process area, provide a dedicated first-out display, and ensure the high-high temperature alarm is distinguishable from routine messages. Third, write and validate operator response procedures for the credited actions, including expected response time and the specific valve or controller to use.
Metrics should include: average alarm rate per operator per 10 minutes (target <1 average, <10 during upsets); peak alarm rate; percentage of standing and chattering alarms; number of alarms per batch; operator workload assessments; and response-time drills for safety-critical alarms. ISA 18.2 and EEMUA 191 provide useful benchmarks, but the site should adopt its own targets and track them monthly. Until the alarm system is improved, the LOPA must not credit the operator response, and interim manual controls such as reduced batch size or additional staffing should be considered.
3. What should management conclude about staffing and fatigue, and what management-system changes are needed?
Read the worked answer
Management should not treat the 24-minute delay as solely operator error. The shift pattern - a sixth consecutive 12-hour night shift - and break coverage by a single operator for two console areas are performance-shaping factors that increase error probability and violate the assumptions behind the LOPA credit. Fatigue also slows diagnosis during a high-alarm-rate upset.
The management-system changes are: define minimum console staffing and relief coverage for breaks and absences; set limits on consecutive night shifts and overtime; conduct a workload assessment covering normal and upset conditions; and include fatigue as a recognized hazard in the human factors element of the PHA. The alarm philosophy should be updated to define performance metrics, ownership, and management of change for alarm configuration. DCS changes that affect alarm behavior should require MOC review, including human factors review.
Finally, the incident investigation should classify the event as a near miss with a potential for reactor overpressure, not as a training deficiency. Corrective actions should address alarm design, staffing, and engineered protection. Effectiveness should be verified by observing alarm performance and response drills over several months, not by confirming that training records are complete.