Failsafes and Safety Fails: How to crash a train and other lessons for software engineers
summary
A detailed postmortem of the Broady runaway traces 5264’s unintended movement, the POTS telemetry gaps, and the ATSB investigation that reconstructs a 16m33s timeline culminating in a 9:33 collision at about 75 km/h with four passengers hospitalized and all injured discharged next day. Concrete fixes: amending procedures and park brake mandated when changing ends, recognition that dependent fail‑safes require an active cab, and that fragmented observability and unclear control paths turn recoverable faults into runaway incidents.
AI-written summary · about
chapters (18)
- 0:00Welcome
- 1:08Talk overview
- 3:21Broad Meadows station incident
- 6:08Documentation gaps in rail ops
- 7:32Train starts uncontrollably
- 10:22Fail-safe mechanisms explained
- 13:11Fail-safes failed on runaway
- 15:59Metrol’s delayed response
- 17:25Routing to Spencer Street
- 21:40Near-miss at North Melbourne
- 22:22Train crash final routing
- 23:51Aftermath and consequences
- 24:31Lessons for software engineers
- 26:40Observability and third-party APIs
- 27:01Incident management failures
- 27:43Documentation prevents safety fails
- 28:26Learning from rail reports
- 29:09Q&A and closing
related talks
29mFailsafes and Safety Fails
53mMayday! Software lessons from aviation disasters
53mMayday Mark 2! More Software Lessons From Aviation Disasters.
48mMove fast Build things… Safely!
28m"TOGA: Checklists and Safety Measures for "Yoloing" in Prod"
36mMove fast Build things… Safely!
42mHow to not kill people
29mLearning from incidents: how things went right