Patriot at Dhahran: how truncated arithmetic became a 687-metre miss

Twenty-eight soldiers died because a computer could not write one-tenth of a second in binary. Not slowly. Not occasionally. The number does not fit, the code truncated it, and nobody had run the machine long enough in one sitting for the shaving to matter. Dhahran, Saudi Arabia, 25 February 1991. The post-mortem is public – the US General Accounting Office published it as report IMTEC-92-26 – and I was nowhere near it, which is the point: every number below comes from the record, not from memory. The lessons transfer to any floor I have ever worked.

The situation

By late February 1991 the Patriot was the celebrity of the Gulf War. Nightly television carried interceptions over Riyadh and Tel Aviv, and the batteries around Dhahran protected the air base around the clock. That is the detail that matters. The Patriot was designed in the 1970s to kill aircraft: short engagements, frequent relocations, regular restarts. No design study imagined a battery sitting static on one pad for four days. The Dhahran battery had been up for roughly 100 hours when the Scud launched, closing at about two kilometres per second. The barracks in its path was full of sleeping soldiers.

How it unfolded

The radar saw the Scud; that is not in dispute. To sort targets from clutter, the software predicts where the target should be, opens a narrow range gate on that patch of sky, and waits for the echo to land inside it. The prediction runs off system time – tenths of a second since last boot.

At Dhahran the prediction sat 687 metres from the truth. The Scud flew through the blind spot. The return fell outside the gate, so the software classed it as clutter and never formed a track. No track, no solution, no launch. Impact came at about half past midnight.

Two facts make it worse. Israeli operators had flagged timing drift on 11 February, after long continuous stints defending Tel Aviv. And the programme office had a software fix moving to units by 16 February. Dhahran's copy arrived on the 26th. One day late. The patch, for what it is worth, reduced the error; it did not eliminate it.

Root-cause anatomy

The Patriot counted time in tenths of a second and converted the count by multiplying by one-tenth. One-tenth in binary is a repeating fraction; stored in 24-bit fixed point it comes out as 0.0999999046325684. Each tick shaved off roughly ninety-five billionths of a second. One hundred hours is 3.6 million ticks. Multiply it out: the clock ran 0.34 seconds behind reality – linear, monotonic, invisible to anything that did not run long enough to notice. At two kilometres per second, 0.34 seconds is 687 metres.

The arithmetic is boring. The assumption behind it was not. The truncation was a known trade-off from an era when eight-hour missions and frequent reboots reset the error before it could grow. The war changed the duty cycle; nobody re-validated the assumption envelope that came with it.

A defect that costs ninety-five billionths of a second per transaction cannot be found by any test that runs for eight hours – and cannot be missed by any test that runs for a hundred.

Where the quality system failed

Four links broke. Any one holding would have saved twenty-eight people.

Requirements rot came first. The system was fine for its 1970s profile. When static, continuous operation became the norm, nobody re-ran the PFMEA against the new duty cycle. The failure mode had been there all along; the mission simply had not lasted long enough to reach it.

Field data came second. The Israeli report of 11 February was test data from production conditions, and it travelled at the speed of bureaucracy. In 8D terms, D1 to D3 sat in an inbox while D5 was in transit.

Patch-as-logistics came third. Once a defect is known, a fix in transit does nothing for the unit still waiting. The software had change management; the exposure had no containment. A standing order to reboot every eight hours would have reset the clock at zero cost. It never became doctrine.

The test gap closed the chain. The software had been exercised at 8–14-hour scenarios, never a hundred. I have run this anatomy on civilian lines: a press tool drifting a few microns an hour, invisible in the two-hour capability study, scrap by shift six. Same shape, cheaper ending.

What would have caught it

An endurance run at twice the expected continuous mission, with the clock checked against an external reference, would have flagged the drift inside one shift. GPS existed in 1991; a comparison harness is an afternoon's work. Endurance testing at operational extremes is the cheapest control in this whole story.

After that, discipline. A known defect with a fix in transit is a containment decision, not a shipping decision, and the interim workaround travels with the patch's priority, not freight's. An observation that recurs across two independent units stops being anecdote and becomes data – triaged within 24 hours. QRQC teams do this on stamping lines every week; the method is not exotic. It is just faster than mail.

My take

The arithmetic is innocent. Binary one-tenth has been repeating on programmers since the first stored-program machines, and every engineer who has debugged a floating-point comparison knows it by heart. The guilt is organisational: an assumption envelope that expired when the duty cycle changed and was never re-validated, field data demoted to chatter, a fix that moved like freight while the risk it carried was live.

This is why I insist that quality management, ethical hacking and systems engineering are one discipline. All three study how complex systems fail – at the seams, through accumulation, quietly. Dhahran failed at a boundary: between what the software was told about time and what the war actually did with it.

Your plant has that boundary too. Go find it before it finds you.