During Operation Desert Storm, on February 25, 1991, a Patriot air-defense battery at Dhahran, Saudi Arabia failed to track and engage an incoming Iraqi Scud missile. The Scud struck a U.S. Army barracks, killing 28 soldiers and injuring many more. The U.S. General Accounting Office investigated and published its findings as report GAO/IMTEC-92-26, “Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia,” in February 1992.
The GAO traced the failure to a software timing error. The Patriot tracked targets by predicting where a detected object should appear next, using its internal clock to compute elapsed time. That clock counted time in tenths of a second as an integer, and the software converted it to a real number to do the range-gate calculation. The conversion involved multiplying by a value (one tenth) that cannot be represented exactly in the system’s binary floating-point format. The small representation error was harmless for short runs, but it accumulated steadily the longer the system ran without being restarted.
By the time of the incident, the Dhahran battery had been operating continuously for over 100 hours. The GAO reported that after about 100 hours the accumulated time error had grown to roughly a third of a second, which at Scud speeds corresponds to a position error of well over half a kilometer. That was enough to place the predicted intercept window in the wrong location: when the radar detected the incoming Scud, the software computed a range gate that did not contain the target, concluded there was no real threat, and never launched an interceptor.
A particularly bitter detail in the GAO account is that the problem was already partly understood. Israeli forces had reported degraded accuracy after the system ran for extended periods, and the Army had developed and was distributing modified software to correct the drift. According to the report, the corrected software did not reach Dhahran until February 26, 1991, the day after the Scud struck. Field crews also had not been clearly told that very long continuous operation degraded accuracy and that periodic restarts were a practical workaround.
The Dhahran failure has become a canonical example of how a tiny floating-point representation error, multiplied across a long uptime, can have lethal consequences. It is studied alongside integer-overflow and other numeric-edge-case failures as evidence that arithmetic precision is a safety property in long-running real-time systems, and that assumptions about how long software will run between restarts must be stated, tested, and communicated to operators.