A Patriot Battery Ran 100 Hours Without a Reboot. A Third-of-a-Second Drift Meant It Never Fired at the Scud.

Patriot missiles streaking into the night sky over Tel Aviv in February 1991, beside a retro-style graphic of a clock count drifting away from true time.


On 25 February 1991, a U.S. Army Patriot missile battery guarding Dhahran Air Base in Saudi Arabia had been running for more than 100 consecutive hours, and the time its computer calculated was off by about a third of a second. That day an Iraqi Scud, a short-range ballistic missile, came in. The battery did not engage it. The Scud struck an Army barracks and killed 28 American soldiers.

A software version that compensated for the error had been released nine days earlier. It reached Dhahran the next day.

An article in the journal Science in March 1992 called the cause a “minute mathematical error.” That is true but incomplete. A computer scientist who looked closer argued that the tiny error, on its own, should have been harmless.

A tenth of a second has no exact binary form

According to the U.S. General Accounting Office (GAO), the investigative arm of Congress, the Patriot’s weapons control computer was “based on a 1970s design with relatively limited capability to perform high precision calculations.” Its registers were 24 bits long. Its clock counted whole tenths of a second, starting from zero whenever the computer was restarted.

The software multiplied that count by 0.1 to get seconds. But one-tenth has no exact binary form: in base 2 it is 0.000110011001100…, repeating forever. The Patriot’s copy of 0.1 was chopped to fit a 24-bit fixed-point register, leaving it too small by roughly one part in a million.

That is about 0.000000095 seconds lost on every tick, far too little to matter over a minute. But the total grows with the count. By GAO’s figures, the calculated time was off by 0.0275 seconds after 8 hours of continuous operation and 0.3433 seconds after 100 hours.

Why a tiny error became a big one

Once the radar detects an object that behaves like a Scud, a “range gate” predicts the small area of airspace where that object should appear next, from its velocity and the time of the last detection. The system processes only what falls inside. Finding the object there confirms it is a Scud.

Tracking should depend on the time between two radar pulses, not on the absolute clock. If both timestamps carry the same tiny relative error, it nearly cancels when one is subtracted from the other. Robert Skeel, a computer scientist at the University of Illinois, made that point in July 1992 in SIAM News, the newsletter of the Society for Industrial and Applied Mathematics: with consistent errors, the time difference “should be in error by only 0.0001%, a truly insignificant amount.”

“Further inquiries cleared up the mystery,” he wrote. When Patriots were sent to the Gulf, their roughly 20-year-old assembly-language software was modified several times to cope with fast ballistic missiles. At least one change added a subroutine that converted clock time more accurately. The program needed that conversion in about half a dozen places, but not every one got the new call. “Hence, with a less accurate truncated time of one radar pulse being subtracted from a more accurate time of another radar pulse,” Skeel wrote, “the error no longer cancelled.”

By Skeel’s account, that partial change is why the error mattered: the difference between two pulse times now carried the whole drift since the last restart, about a third of a second at Dhahran. GAO’s report, which does not mention the change, puts the range gate’s shift after 100 hours at about 687 meters.

A warning without a number

The Patriot was built for a different war. GAO says it was originally designed for Europe, against Soviet aircraft and cruise missiles flying at up to about Mach 2, and “to be mobile and operate for only a few hours at one location.” In the Gulf, batteries generally stayed in permanent positions and faced Scuds flying at about Mach 5.

On 11 February 1991, the Army’s Patriot Project Office received Israeli data showing a 20 percent shift in the range gate after 8 consecutive hours of operation. Project officials said a Patriot will not track a Scud once the shift reaches 50 percent; extrapolating the Israeli figures, GAO put that point at about 20 hours. Army officials considered the Israeli experience atypical. They still made a compensating software change, released on 16 February, but did not use the Israeli data to work out how long a Patriot could run before the error made it ineffective.

On 21 February, the project office warned users that very long run times could shift the range gate and that a software change was coming. “However,” GAO wrote, “the message did not specify what constitutes very long run times.” Army officials presumed users would not run batteries that long, so they saw no need for more detailed guidance.

A reboot, which took 60 to 90 seconds, set the clock back to zero, and GAO said restarting every few hours could have eliminated significant shifts. Four days after the warning, the Dhahran battery had been up for more than 100 hours. Army officials said the time needed to arrange transport in wartime delayed the new software until 26 February.

What the record does and does not say

In May 1991, Army officials quoted by The New York Times called the failure “an anomaly that never showed up in thousands of hours of testing.” But total test hours say little about a fault that appears only after one long, unbroken run, and the Israeli data had shown the shift two weeks before the strike.

The record has limits, too. GAO says the error made the system look in the wrong place and made a successful intercept “less likely.” Whether a battery with correct timing would have destroyed this Scud is a separate question. A later GAO report, from September 1992, was titled “Data Does Not Exist to Conclusively Say How Well Patriot Performed.”

The lesson that outlasts the Patriot

Read as a story about one bad constant, Dhahran teaches you to distrust 0.1. Read through Skeel’s account, it teaches something broader: a small error applied the same way everywhere tends to cancel when you subtract one timestamp from another. Fix it in some places but not others, and you are quietly comparing two different clocks.

The other lesson is about uptime. The error grew with every tick: small over a few hours, but, by GAO’s extrapolation, after about 20 hours enough to push a Scud out of the range gate. A warning about “very long run times” gave crews nothing concrete to act on. A number would have.

Which part of your system has only been tested for as long as it was designed to run, not as long as it actually runs?

Related stories

Sources

Share this article
FacebookThreadsLinkedInX

Leave a Reply

Your email address will not be published. Required fields are marked *