The software bug that changed medical safety forever
In the mid-1980s, a radiation therapy machine called the Therac-25 delivered massive, lethal overdoses of radiation to several cancer patients. Unlike its predecessors, which relied on physical hardware interlocks to prevent accidents, the Therac-25 relied solely on software. A subtle "race condition" bug in the code occurred when operators typed commands too quickly, bypassing safety checks and firing high-energy electron beams directly at patients without the necessary protective filters.
The Shift from Hardware Interlocks to Code
In the late 1970s and early 1980s, Atomic Energy of Canada Limited developed the Therac-25, a state-of-the-art dual-mode radiation therapy machine designed to treat cancer patients using targeted electron beams or high-energy X-rays. Earlier models, such as the Therac-6 and Therac-20, had been built as hybrid machines. They integrated a computer for convenience, but they still retained electro-mechanical switches, physical relays, and independent hardware interlocks that physically blocked dangerous operating states regardless of what instructions the software issued.
With the design of the Therac-25, the engineering team made a fateful architectural pivot. Believing that computer control had matured to the point where mechanical redundancies were unnecessary, AECL eliminated the independent hardware interlocks to cut costs and simplify the machine's mechanical layout. Safety was delegated almost entirely to a software system written in assembly language for a 16-bit minicomputer. If the code failed to detect a hazard or commanded an invalid state, no independent physical failsafe existed to interrupt the electrical circuits and halt the beam.
Two Operating Modes and the Physical Danger
To understand the catastrophic nature of the failures, one must look at how the dual-mode accelerator functioned physically. In electron mode, the machine emitted a low-intensity, low-energy electron beam directly at shallow tumors on the patient's body. In X-ray mode, the accelerator required a vastly more powerful electron beam—operating at roughly one hundred times higher current—directed at a heavy tungsten target. This tungsten target absorbed the raw electron beam and converted it into a dispersed, deeply penetrating shower of therapeutic X-ray photons, which were then shaped by a flattening filter.
The fundamental hazard occurred when the machine entered an unintended hybrid state. If the accelerator fired its high-current electron beam without the tungsten target and flattening filter rotated into the beam path, the patient received the raw, highly concentrated electron stream at full power. Instead of a carefully calibrated dose, the machine delivered massive radiation overexposures—frequently estimated at tens of thousands of rads in just a fraction of a second—causing acute radiation sickness, severe internal tissue destruction, and agonizing, fatal injuries.
The Keystroke Race Condition
The first critical software defect was a race condition triggered by the interface routine used by clinical operators. Operators were trained to enter treatment parameters through a video terminal. When configuring the machine for X-ray therapy, an experienced technician might accidentally type 'X' for X-ray mode, realize the error, and immediately press the cursor-up key to change the mode to 'E' for electron beam before pressing enter to confirm the setup.
If this editing sequence occurred within an eight-second window while the computer was executing a background routine to position the heavy physical turntable magnets, the software failed to synchronize its internal states. The input-parsing subroutine updated the display and flagged the machine as ready for an electron treatment, but it bypassed the command that dialed down the electron gun's power level. When the operator pressed the 'B' key to fire the beam, the machine energized the electron gun at high X-ray current while leaving the protective target retracted.
Arithmetic Overflows and Cryptic Errors
A second fatal defect stemmed from an arithmetic overflow bug in the software's safety-checking routine. The operating system tracked whether the mechanical turntable was properly aligned by incrementing a single-byte counter variable every time a check was performed. In computer arithmetic, an 8-bit unsigned integer can only store numbers from 0 to 255 before rolling over back to zero.
If a clinical technician pressed the 'set' key to initiate treatment at the exact moment this counter variable overflowed to zero, the control software interpreted the zero value as a confirmation that the safety verification had passed successfully. Consequently, the beam fired without verifying whether the collimator and target assembly had finished moving into their designated positions. Compounding this design failure, the user interface provided no clear explanation when errors occurred, displaying only obscure codes such as 'MALFUNCTION 54' or 'MALFUNCTION 42' while indicating that the beam had merely shut down on an underdose.
The False Assumption of Reused Code
When AECL engineers designed the Therac-25, they reused significant modules of assembly code from the older Therac-6 and Therac-20 systems under the assumption that software proven in the field was inherently reliable. What the designers failed to understand was that the underlying bugs had always been present in the earlier codebases. In the Therac-20, however, independent hardware interlocks had silently tripped whenever the software attempted an illegal beam configuration, preventing any harm and masking the flaws from the developers.
By stripping away the hardware safeguards and deploying the inherited code into a machine that lacked physical safety circuits, AECL exposed those latent bugs directly to patients. When initial reports of radiation burns surfaced at several treatment facilities, the manufacturer repeatedly insisted that a software-induced overdose was impossible, attributing early patient complaints to mechanical failure, electrical shocks, or unrelated clinical complications until independent hospital physicists systematically recreated the software timing bugs.
The Legacy in Safety-Critical Engineering
The Therac-25 disaster became one of the most thoroughly analyzed case studies in the history of software engineering, human factors design, and medical technology. Investigations led by government regulatory bodies, including the United States Food and Drug Administration, established that AECL's software had been developed by a single programmer without formal specifications, rigorous independent peer code reviews, or comprehensive modular testing.
The tragedy permanently altered the regulatory landscape for computerized medical equipment and safety-critical embedded systems. Regulatory agencies established strict standards requiring formal hazard analyses, rigorous software validation, independent verification of source code, and clear user interface designs. Most fundamentally, it cemented a core rule of modern safety engineering: software must never serve as the sole barrier protecting human life from hazardous physical machinery.
Key takeaways
•The Therac-25 removed physical hardware interlocks that had protected earlier models, relying entirely on software to prevent lethal machine states.
•A race condition caused by rapid operator keystrokes allowed the machine to fire a high-current electron beam without the required tungsten target in place.
•Reusing software from older models masked critical bugs that had previously been contained by independent mechanical switches.
•The disaster led to strict modern standards for safety-critical systems, establishing that software alone should never be the sole line of defense against physical harm.