Faultory

Case file 32 · Engineering & technology

A clock that drifted with uptime

Dhahran, 1991: how a clock error grew the longer the system ran

Subject
Patriot missile failure at Dhahran
Reading
9 min
Evidence
5 exhibits
Reasoning
3 steps
Level
Intermediate
Night photograph of three bright missile trails rising from the lights of a city toward a dark sky.
12 February 1991 Patriot missiles are launched to intercept an Iraqi Scud over the city of Tel Aviv on 12 February 1991; this is not the Dhahran battery. Photo: Nathan Alpert (Government Press Office, Israel) · CC BY-SA 3.0 · Wikimedia Commons.
Illustrative signature. Stylized, not data: a timing error that grows steadily with uptime, pushing the search window away from the target until a restart resets the clock. Drawn to explain the case, not plotted from source data.

01 · The briefing

Begin with the question.

On 25 February 1991, during the Gulf War, an American Patriot battery at Dhahran, Saudi Arabia, failed to track and intercept an incoming Iraqi Scud missile. The Scud struck an Army barracks and 28 American soldiers were killed. The Patriot had been built to defend against aircraft and cruise missiles and had later been adapted for short-range ballistic missiles. It had not been expected to run for long periods without restart. Several explanations seemed plausible at first. One held that the Scud had simply outperformed the interceptor. Another held that the radar had failed to see the target. A third suggested that the battery calculations were wrong in a way that would affect every battery equally. Your investigation has to separate the tracking calculation from the radar and the interceptor, and then ask what changed in the battery over time. Consider what the system stored as time, how precisely it converted that number, and what a prediction depended on. Treat the people involved with care, and keep the focus on how the system behaved.

Military personnel stand around the damaged body of a Scud missile lying on desert sand, with a pickup truck behind them.
Where it happened1991 Military personnel examine a Scud missile shot down by a Patriot during Operation Desert Storm. Photo: U.S. Department of Defense · Public domain · Wikimedia Commons.

The timeline

  1. The Patriot Project Office receives Israeli data showing a range-gate shift after eight consecutive hours of operation.

  2. A modified software version that compensates for the timing error is released.

  3. The Dhahran battery fails to track and intercept an incoming Scud, which strikes an Army barracks; 28 American soldiers are killed.

  4. The modified software reaches Dhahran, the day after the incident.

  5. The General Accounting Office report IMTEC-92-26 is issued on the software problem at Dhahran.

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?

A Patriot launcher on a heavy truck in a parade, with uniformed marchers ahead and a classical white memorial visible behind the trees.
On the evidence table8 June 1991 A MIM-104 Patriot launcher is towed on a heavy truck in the National Victory Celebration parade honoring the Desert Storm coalition. Photo: Michael Buchanan · Public domain · 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 24-bit clock conversion

GAO reports that the Patriot internal clock counted tenths of a second as an integer, and that converting that count to a real number used registers only 24 bits long, limiting precision. The error in the conversion grew with the length of continuous operation. This explains why uptime mattered; it does not, on its own, quantify the Scud track.

Source record s1web.archive.org

Exhibit 02

Growth with run time

Appendix II of the report tabulates calculated timing inaccuracy against hours of operation: about 0.0034 seconds after one hour, 0.0275 after eight, 0.0687 after twenty, and 0.3433 after about one hundred hours. The corresponding range-gate shifts are roughly 7, 55, 137 and 687 meters. These are calculated values from the stated precision, not measured track data.

Source record s1web.archive.org

Exhibit 03

A worked explanation

A university mathematics page reproduces the GAO passage and explains the binary truncation of one tenth in a 24-bit register. Multiplying the small per-conversion error by the large count of tenths of a second yields an error of about 0.34 seconds after about 100 hours. The page is an explanatory summary and gives no operational data of its own.

Source record s3web.archive.org

Exhibit 04

A warning that arrived early

GAO reports that Army officials received Israeli data indicating a 20 percent range-gate shift after eight consecutive hours, modified the software, and that the modified version reached Dhahran the day after the incident. The report says the officials did not use the Israeli data to determine how long the system could run before the error became critical. This shows a known warning; it does not show that software delivery alone caused the failure.

Source record s1web.archive.org

Exhibit 05

The official summary

The GAO product summary describes the same chain of events: operation for over 100 hours, a tracking calculation that became worse with run time, and a software change that arrived after the incident. The summary is short and omits the appendix values, but it is consistent with the full report.

Source record s2web.archive.org

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 03

What evidence would most directly distinguish a time-dependent error from a missile that simply evaded the interceptor?

Evidence-based explanation

An error that depends on run time predicts a shift that grows with uptime, which is what the stated register precision and the calculated table produce. Speed or training alone would not produce that dependence.

Weigh it against

Exhibit 02Growth with run timeExhibit 01A 24-bit clock conversion

Reasoning step 02 of 03

The clock count is stored as integer tenths of a second and must be converted to a real number. Why does the error grow with uptime?

Evidence-based explanation

Because the register cannot represent one tenth exactly, each conversion carries a tiny error. Multiplying that error by a count that grows with run time produces a shift that grows with uptime.

Weigh it against

Exhibit 01A 24-bit clock conversionExhibit 03A worked explanation

Reasoning step 03 of 03

Which lesson is strongest for systems that must run continuously for long periods?

Evidence-based explanation

GAO notes that rebooting every few hours could have eliminated the significant shifts, since it resets the clock. The case shows that a known warning and a long-run test were both needed, and that a fix must reach the field in time.

Weigh it against

Exhibit 04A warning that arrived earlyExhibit 05The official summary

04 · The findings

The chain behind the outcome.

The most convincing reconstruction is that the Patriot tracking calculation drifted because it converted a count of tenths of a second into a real number using 24-bit registers. The conversion error for each step is small, but the time count grew with uptime, so the error grew with it. GAO ties the magnitude to run time. After about 20 hours of continuous operation, the calculated shift would have been large enough to place the range gate away from the target, and after about 100 hours the calculated timing error was 0.3433 seconds, corresponding to a shift of about 687 meters. The search window therefore moved away from the Scud. Israeli data had reported a 20 percent shift after eight hours. The Army modified the software in mid-February 1991, but the new version reached Dhahran only on 26 February. GAO also notes that rebooting, which resets the clock, could have prevented significant shifts. The established points are the mechanism, the calculated magnitudes from the stated precision, and the timing of warnings and software. The interpretation lies in the exact track geometry at the moment of the attack, which the summaries do not reconstruct. The durable lesson is that a system can be correct at restart and still drift during continuous use, so long-run behavior needs its own test.

Contributing causes and conditions

  1. A 24-bit register that cannot represent one tenth of a second exactly
  2. A clock count that grows with continuous uptime, so the conversion error scales with run time
  3. A prediction that depends on time and velocity, so the timing error shifted the range gate away from the target
  4. A system not expected to run for long periods against Scud-class targets
  5. A software correction that reached the field after a known anomaly and after the incident

OutcomePatriot missile failure at Dhahran

Take the method with you

  1. A component can be correct at restart and still drift during continuous use.
  2. Compare a sequence of warning signs with the system operating envelope before deciding that a warning is atypical.
  3. Small numerical errors matter when they are multiplied by large counts, so check their magnitude across the full operating range.

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