Industrial Automation Field Frameworks: The Control Lifecycle
Industrial Automation Part 3 of 8

What Three Process Safety Disasters Still Teach Automation Engineers

Flixborough 1974, Buncefield 2005, Texas City 2005. What the official records actually say, what they carefully refuse to conclude, and the three lessons that transfer to anyone who specifies, builds or maintains automation.

Article cover: What three process safety disasters still teach automation engineers.

The industry’s most instructive safety literature isn’t new. Three well-documented accidents — 1974, 2005, 2005 — keep teaching because the organizational patterns behind them keep recurring, in plants with far better technology than the ones that failed.

None of what follows assigns a simple cause. Each investigation documented many contributing conditions, and the reports are careful to say so. But each carries one lesson that transfers directly to anyone who specifies, builds, or maintains automation today.

Flixborough, 1974: the modification nobody checked

A UK chemical works needed to bypass a reactor that had been removed. The bypass was installed. On 1 June 1974 it ruptured, releasing cyclohexane; the explosion killed 28 people on site, injured 36 more on site, and caused 53 reported injuries off site.

The HSE record is specific about what the modification lacked: full consequence assessment, complete calculations, a drawing, and a pressure test.

Read that list again, because it is not a list about 1970s piping. It is a list about engineering review — and it is the same list you would use today to judge whether a change had been properly assessed. No calculations. No drawing. No test.

The transferable lesson is that temporary is a risk category, not a comfort word. Every site has temporary modifications right now — jumpers, bypassed interlocks, forced points, rerouted flows, a permissive defeated for a trial that ended in March. Every one past its expiry date is an unmanaged-risk condition waiting for review.

A modification that would never survive the design process on the way in should not survive indefinitely because it arrived through a different door.

This week: open your management-of-change log and filter to temporary modifications past their expiry. Escalate them through the site MOC process according to consequence and authorization. The discipline that Flixborough bought at terrible cost is precisely the discipline that feels bureaucratic on a good day.

Buncefield, 2005: the protection that wasn’t being maintained

At a UK fuel storage depot in December 2005, Tank 912 was being filled. Its automatic tank gauge stuck. The independent high-level switch — the protection layer sitting behind that gauge, whose entire purpose was to catch this — was inoperable.

Filling continued. Petrol overflowed. The resulting vapour cloud ignited. More than 40 people were injured; there were no fatalities, but the damage was extensive, the site was evacuated, and the fire burned for days. The official reports record management and maintenance causes alongside the two failed instruments.

The transferable lesson: protection layers are claims about maintained systems, not installed ones.

A high-level switch that exists but isn’t proof-tested is a diagram feature, not a protection layer. It occupies a box in the risk analysis, it earns risk-reduction credit in the arithmetic, and it does nothing at all. Independence, effectiveness, and test status have to be demonstrated for the specific scenario — and several nominally separate layers can share a common cause that defeats them together.

This week: if your area credits protection layers in any risk analysis, ask two questions of each. When was it last tested? Does the demand assumption behind it still hold, given how the plant actually runs now?

Texas City, 2005: the startup, the full column, and the stack

At a US refinery in March 2005, a distillation column was overfilled during startup. The release found its way out through an atmospheric blowdown system. It ignited, killing 15 people and injuring about 180 — many of them working in trailers sited near the release point. The CSB documented deficiencies across equipment, procedures, supervision, culture and process-safety management.

Three lessons transfer, and the third is the one automation engineers most often skip.

Transitions concentrate risk. Startup, shutdown and changeover carry hazards far beyond steady-state operation, and deserve commissioning-grade discipline every time — not only on day one. Authorized transitions with entry criteria, hold points and abort authority are not project ceremony. They are the operating model that steady-state luck lets plants forget.

Instrumentation earns its keep during transitions, not during steady state. A level measurement that reads wrong at startup deserves more attention than a dashboard of healthy steady-state trends. The measurement you trust least when the plant is moving is the one worth fixing first.

Where the material goes when protection acts is a design decision. The release path mattered here. Disposal and relief routing tends to get treated as somebody else’s discipline — piping, process, safety — but the automation that initiates a trip, opens a path, or fills a drum is part of that scenario. Knowing what your interlock does is not the same as knowing where the contents end up.

What these reports refuse to say

The careful reader will notice what the official records decline to conclude, and the discipline is worth copying.

The Flixborough record does not establish that this event caused HAZOP’s adoption, however often that claim gets repeated at conferences. The Buncefield record does not support explosion-ranking claims. The CSB did not assign a retrospective SIL to Texas City, and no honest reading can supply one.

Each investigation resists the single tidy moral that people attach to it afterwards. That resistance is itself the lesson: real incidents have many contributing conditions, and the ones that transfer to your plant are rarely the ones that make the best story.

Why re-read them now

It is comfortable to assume modern systems have engineered these lessons in. The systems, mostly, have. The organizations, repeatedly, have not.

Temporary modifications still outlive their reviews. Protection layers still lose their test status quietly, with nobody deciding to let it happen. Startups still run on procedures that drifted from the plant years ago.

None of these accidents was caused by a lack of automation. Each involved automation and protection that existed but was bypassed, unmaintained, or not trusted with the truth.

That is why they belong to automation engineers and not only to process-safety specialists. The layers we build are as real as the lifecycle that keeps them tested, reviewed and honest — and no more real than that.

Read the reports. They are careful documents, and they are free.

Which of the three describes a condition that exists in your plant this week?

These cases, with their documented boundaries and the lifecycle framework they inform, are examined across the functional-safety and commissioning parts of Industrial Automation: Real-World Frameworks & Implementation Guide.

Lokesh Chennuru
Lokesh Chennuru
Industry Digits Author

Lokesh Chennuru writes Industry Digits field notes for industrial decision makers, focused on automation, IIoT, condition monitoring, predictive maintenance, and industrial AI.

Connect on LinkedIn
Frequently asked

Questions industrial leaders ask about this

Why should automation engineers read process safety accident reports?

None of these accidents was caused by a lack of automation. Each involved automation and protection that existed but was bypassed, unmaintained, or not trusted with the truth. The protection layers an automation team builds are only as real as the lifecycle that keeps them tested, reviewed and honest.

What is the automation lesson from Flixborough?

The HSE record is specific that the bypass modification lacked full consequence assessment, complete calculations, a drawing and a pressure test. The transferable lesson is that temporary is a risk category, not a comfort word — every temporary modification past its expiry date is an unmanaged-risk condition awaiting review.

What is the automation lesson from Buncefield?

A protection layer is a claim about a maintained system, not an installed one. A high-level switch that exists but is not proof-tested is a diagram feature — it earns risk-reduction credit in the arithmetic and does nothing at all. Independence, effectiveness and test status must be demonstrated for the specific scenario.

What do these reports deliberately not conclude?

The Flixborough record does not establish that the event caused HAZOP's adoption. The Buncefield record does not support explosion-ranking claims. The CSB did not assign a retrospective SIL to Texas City. Each investigation resists the single tidy moral attached to it afterwards, and that resistance is itself the lesson.

Go deeper

Industrial Automation — Real-World Frameworks & Implementation Guide

The ten-part guide this series draws on: project framing, system architecture, the field, control and supervisory layers, OT networks and cybersecurity, functional safety, integration, delivery and operations — with 28 technical figures and a 38-asset working pack.