Faultory

Case file 30 · Engineering & technology

Software that replaced the interlocks

Therac-25, 1985–87: when software took over safety checks, what failed?

Subject
Therac-25 radiation overdoses
Reading
14 min
Evidence
5 exhibits
Reasoning
4 steps
Level
Advanced
A large white radiotherapy machine with a rotating gantry arm above a treatment couch.
Photographed 2006 A later medical linear accelerator (a Varian Clinac at Motol University Hospital, Prague, 2006), shown to illustrate the kind of machine. It is not a Therac-25. Photo: Egg (Wikimedia Commons user) · CC BY-SA 2.5 · Wikimedia Commons.
Illustrative signature. A shared-state reading that stays quiet during normal operation, then jumps when two tasks interleave during a rapid edit sequence. Drawn to explain the case, not plotted from source data.

01 · The briefing

Begin with the question.

The Therac-25 was a computer-controlled medical linear accelerator that could deliver a high-energy electron beam or an X-ray beam for cancer treatment. Between June 1985 and January 1987, six known accidents involved massive overdoses, with deaths and serious injuries. Investigators and the manufacturer offered different explanations. One view blamed a faulty microswitch that tracked the turntable position. A second placed the emphasis on the operators' fast data entry. A third treats the accidents as one programming error, which would leave the design and reporting questions unanswered. Leveson and Turner's 1993 investigation, based on publicly available documents, asks how the machine's design, software and reporting process interacted. Your task is to separate what the design choices made possible from the specific sequences that triggered the overdoses, and to test which explanation accounts for the timing of the reports, not only for the messages the machine displayed. The paper draws on publicly available documents from the manufacturer, the hospitals and the regulators, and its stated aim is to help engineers learn rather than to assign simple blame. Keep the question concrete: which sequence of events, which design choice and which response to reports could each explain the accidents you are reading about?

The timeline

  1. AECL produces the first hardwired prototype of the Therac-25.

  2. The first recorded overdose occurs in Marietta, Georgia.

  3. An overdose occurs in Hamilton, Ontario; AECL is notified.

  4. An overdose occurs in Tyler, Texas; AECL states that an overdose was impossible and that no other accidents had occurred.

  5. A second overdose occurs at the Tyler clinic. The machine shows Malfunction 54, which a physicist later reproduces by rapid editing.

  6. The FDA declares the Therac-25 defective and asks for a corrective action plan.

  7. A second overdose occurs in Yakima, Washington; the six known accidents in the paper's period end in January 1987.

A researched reconstruction for learning. These reasoning steps simplify a complex record; no score can capture the full history.

02 · The evidence

What does the record show?

Schematic of a circular turntable: a blue disc with a grey segment, a mirror, a flattening filter with a target at its center, and labelled switch assemblies and a piston.
On the evidence table2023-03-12 A diagram of the Therac-25 turntable, which moved different components into the beam for each treatment mode (labels in Vietnamese). Photo: Ajzh2074 · CC BY-SA 4.0 · Wikimedia Commons.

Read each exhibit before settling on an explanation. The source links below every exhibit lead to the record behind it.

Exhibit 01

A design that moved safety into software

The paper says the Therac-25 relied more on software for safety functions than its predecessors did, and that AECL chose not to duplicate all existing hardware safety mechanisms and interlocks. This describes the design choice. It does not by itself show which software behavior caused each overdose.

Source record s2cs.columbia.edu

Exhibit 02

Reused software

The authors report that Therac-6 software was used as a starting point for the Therac-25, and that some Therac-20 routines were also used. The quality assurance manager was apparently unaware of the Therac-20 routines until a bug related to a Therac-25 accident was found in the Therac-20 software. The paper treats reuse as a possible contributor, not a proven cause.

Source record s2cs.columbia.edu

Exhibit 03

Shared variables and race conditions

The paper describes concurrent tasks that shared memory with no real synchronization beyond shared variables, and notes that test-and-set operations on those variables were not indivisible. It concludes that these race conditions played an important role in the accidents. The public reconstruction does not show every interleaving, so this is the mechanism the paper supports, not a full timeline.

Source record s2cs.columbia.edu

Exhibit 04

Malfunction 54 and fast editing

At Tyler, the investigators found that the Malfunction 54 message appeared when prescription data was edited rapidly, and that the physicist had to practice before he could reproduce it. AECL engineers could not reproduce the error at first, and produced a similar malfunction only after the physicist explained that the procedure had to be done quickly.

Source record s2cs.columbia.edu

Exhibit 05

The chronology and the impossibility claim

The paper's chronology lists overdoses at Marietta on 3 June 1985, Hamilton on 26 July 1985 and Tyler on 21 March 1986, and it records AECL's claim that an overdose at Tyler was impossible. The FDA declared the Therac-25 defective on 2 May 1986.

Source record s2cs.columbia.edu

03 · Your reasoning

Follow the strongest explanation.

Choose an interpretation, then compare it with the evidence. You can revise your choice. The goal is understanding, not a perfect score.

Reasoning step 01 of 04

Which design change most clearly separates the Therac-25 from its predecessors in the paper's account?

Evidence-based explanation

The paper stresses that the Therac-25 relied more on software and omitted duplicate hardware interlocks, which made software errors more consequential. PDP-11 control was shared with earlier models, so it cannot be the distinguishing change. The microswitch explanation is partial: the paper discusses it, but it does not account for the wider pattern.

Weigh it against

Exhibit 01A design that moved safety into software

Reasoning step 02 of 04

Which observation best supports a timing-dependent software mechanism rather than a simple hardware fault?

Evidence-based explanation

The Malfunction 54 error was reproduced only when data entry was fast, which points to a timing dependence in software rather than a constant hardware fault. Replacing a microswitch did not end the overdoses, and the accidents were not confined to one clinic. The strongest support comes from the paper's account of how the error could be elicited.

Weigh it against

Exhibit 03Shared variables and race conditionsExhibit 04Malfunction 54 and fast editing

Reasoning step 03 of 04

Which design practice would most directly reduce the risk the paper identifies?

Evidence-based explanation

The paper identifies two missing defenses: independent hardware checks that were not duplicated, and unsynchronized concurrent tasks. A design that keeps hardware interlocks for critical conditions and analyzes timing interactions targets both. The other options either move more burden onto software or test the wrong conditions.

Weigh it against

Exhibit 01A design that moved safety into softwareExhibit 03Shared variables and race conditions

Reasoning step 04 of 04

What was the most reasonable response to the early overdose reports?

Evidence-based explanation

The early reports were dismissed as impossible before the mechanism was understood, and later reproduction showed the error could occur. A response that checks logs, user reports and reproduction tests is the best-supported approach. Blaming operators alone, or waiting for a pattern at one site, ignores the evidence in the paper.

Weigh it against

Exhibit 04Malfunction 54 and fast editingExhibit 05The chronology and the impossibility claim

04 · The findings

The chain behind the outcome.

The overdoses arose from an interaction of design, software and reporting. The Therac-25 relied more on software for safety functions and did not duplicate all the hardware interlocks of its predecessors. Software from earlier models was reused in part, and the quality assurance process was apparently unaware of some of the reused code. In the software, concurrent tasks shared variables without real synchronization, and test-and-set operations were not indivisible, so timing could produce states the designers had not anticipated. The Malfunction 54 message, which the operators and the manufacturer could not explain at first, appeared when prescription data was edited quickly after a mode change. That sequence allowed the machine to deliver a dose far beyond the intended level. The manufacturer initially said overdoses were impossible, and the FDA later declared the machine defective. The paper reconstructs the accidents from publicly available documents and says its aim is to help others learn, not to criticize one company. Established facts include the design choices, the reuse, the shared-variable concurrency and the fast-editing sequence. Interpretive claims include how strongly each factor contributed in each accident and how much weight to place on organizational response. The central lesson is that safety depended on a combination of conditions, and no single component explains it.

Contributing causes and conditions

  1. The Therac-25 moved safety functions into software and did not duplicate all the hardware interlocks of earlier machines.
  2. Software was reused from earlier models, and some reused routines were not identified by the quality assurance process.
  3. Concurrent tasks shared memory without real synchronization, so test-and-set operations could interleave.
  4. Rapid editing after a mode change reproduced Malfunction 54 and allowed the machine to deliver an overdose.
  5. Early reports were treated as implausible, and the machine's messages were not explained to operators.

OutcomeTherac-25 radiation overdoses

Take the method with you

  1. Removing an independent safety layer makes the remaining layers carry more weight, so their failure modes need explicit analysis.
  2. Reused software carries assumptions from its original environment, so a reuse decision needs its own safety analysis.
  3. A report that seems impossible deserves an investigation of logs and reproduction before it is dismissed.

You can read findings at any time. Exploring every reasoning step marks this case as complete in your notebook.

Open another investigation

The open record

Sources & further reading

Read the original record and its scope before relying on a conclusion. Source references support the exhibit summaries; Faultory’s reasoning prompts are editorial reconstructions.

  1. s1
  2. s2
  3. s3

Written and curated for Faultory by Yunus Emre Vurgun, with AI-assisted research and drafting. Sources and interpretations can need correction. Read our editorial standards or report an issue.

From the journal

Field notes that use this case

Keep investigating