The HSE Report and the Vital Importance of Specifications: Where Control System Failures Really Begin
Engineering is as much about defining what a system must do when it fails as it is about how it runs.
When an industrial accident or unexpected plant shutdown occurs, our immediate reflex is to look directly at the shop floor: Did an operator push the wrong button? Did the maintenance team miss an inspection step? While these questions feel natural in the heat of an incident, the landmark “Out of Control” report published by the UK Health and Safety Executive (HSE) proves that our perspective needs fundamental re-examination. According to the findings, 44% of control system failures are introduced during the initial specification phase. When design errors are added, approximately 60% of accident risks take shape on the engineer’s desk before hardware ever enters the facility. This analysis examines why specifications in functional safety must serve as a binding safety constitution rather than a simple procurement checklist.
The Root Cause of Field Accidents Begins at the Desk
When an incident occurs in an industrial facility, initial post-mortem inquiries typically focus on the point of operation and the human interface. However, the UK Health and Safety Executive’s (HSE) “Out of Control” study demonstrates that systemic vulnerabilities originate much earlier across the control lifecycle. An analysis of the investigation’s incident sample reveals a striking root cause distribution:
| Lifecycle Phase | Share of Failures and Incidents |
|---|---|
| Specification | 44% |
| Design and Implementation | 15% |
| Changes After Commissioning | 20% |
| Operation and Maintenance | 15% |
| Installation and Commissioning | 6% |
In the HSE’s root-cause study of industrial control system failures (analyzing 34 major incident case studies), 44% of primary causes originated directly from specification defects. Factoring in design and implementation errors (15%), roughly 60% of operational safety risk was determined on the engineering desk before the equipment ever reached the facility floor.
This statistic does not suggest poor engineering capability. Rather, it underscores that unaddressed ambiguity is the most dangerous hazard in systems engineering.
Why Specifications Fail: Blind Spots That Leak to the Field
A closer look at the case studies behind the HSE report reveals that specification failures rarely stem from intricate mathematical oversights. Instead, they occur when specification authors overlook four foundational boundaries:
- Undefined Safe States: Actuators, isolation valves, or motor drives are frequently specified solely by operating torque and speed, without defining whether they should fail-closed, fail-open, or lock-in-place upon communication timeout or power loss.
- Overlooked Hazardous Scenarios: Systems are routinely designed exclusively for nominal operating envelopes, disregarding edge conditions such as sensor loss, pressure transients, reverse flow, or short circuits across emergency stop channels.
- Interface Timing Misalignments: Discrepancies between timeout thresholds and confirmation latencies across PLCs, DCS networks, emergency shutdown systems, and field transmitters remain unclarified in specifications, causing spurious trips or blind spots during critical transitions.
- Management of Change Gaps: The 20% failure share attributed to post-commissioning changes stems from uncontrolled field modifications. When temporary software bypasses or parameter alterations are never back-propagated into the safety specification and hazard log, the system behaves unpredictably during the next real emergency.
The Best-Case Fallacy and Safe State Definitions
Engineers frequently concentrate on designing for the ideal scenario under the assumption that the system must operate without fault. However, functional safety discipline emphasizes a different core principle:
Engineering is as much about defining what a system must do when it fails as it is about how it operates normally, and that contract must be established in the specification.
When fail-safe behaviors are not explicitly defined during specification, that risk is silently transferred to the field. If the system’s safe state is unmapped when a sensor cable severs, a fieldbus network disconnects, or a controller hits an unhandled edge case, expecting operators to intervene safely is an impossible demand.
From a Procurement Checklist to a Safety Constitution
Treating technical specifications merely as procurement lists or catalogue parameter summaries accepts operational vulnerability by default.
A robust Safety Requirements Specification (SRS) is the foundational safety constitution that defines operational boundaries, hazard scenarios, and required safety functions. As formulated in the IEC 61508 safety lifecycle, functional safety is not an add-on hardware device deployed at commissioning; it is a closed-loop discipline executed from initial specification through decommissioning. Saving lives on the plant floor begins by eliminating ambiguity at the engineering desk.
📚 References
HSE — Health and Safety Executive (2003). Out of Control: Why Control Systems Go Wrong and How to Prevent Failure (HSG238, 2nd ed.). HSE Books.
IEC (2010). IEC 61508: Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems. International Electrotechnical Commission.
📋 Related Links
🔗 Systems With No Luxury to Crash: Red Lines and Forbidden Coding Rules in Safety-Critical Software
🔗 You Cannot Solve a Problem Without Sitting at Customer’s Desk: From Product Demos to Process Architecture
🔗 The Big Picture and Systems Engineering: Project Failures Through the Puzzle Analogy
Last updated: December 2025 | Version: 1.1