Patriot Missile at Dhahran: When 0.1 Seconds Was Not 0.1 Seconds

This is the sixth accident in this series, and it is the only one where nobody used the wrong unit. Every other case here follows the same shape: a correct number carrying an incorrect unit, through a machine with no way to complain. At Gimli the number 22,300 was right and the unit behind it was wrong. On the Mars Climate Orbiter the impulse values were arithmetically perfect and silently denominated in pound-force-seconds. At Dhahran, the unit was right on both sides of the calculation. The gunner's system and the weapon both knew what a second was. What failed was narrower and stranger: a computer that could not hold a tenth of a second in its memory, and a software patch that was applied to some of the places that needed it and not the others.

That makes this the hardest case in the series to reduce to advice, and the one with the clearest lesson. A wrong label is a clerical problem: fix the label, add a check, move on. Dhahran is not a clerical problem. It is a case where the arithmetic itself degraded in proportion to how long the machine had been switched on, and where the people who knew that had fifteen days to act and did not manage it. The roundup of eight cases gives Dhahran four paragraphs. The problem deserves a great deal more, because the mechanism is not a curiosity of 1991 hardware — it is the same mechanism that decides whether your own timestamp arithmetic is safe.

The Number the Register Could Not Hold

Start with the unit, because the unit is not the problem — the representation of the unit is. A tenth of a second is a perfectly well defined quantity: 100 milliseconds, one ten-thousandth of an hour, the standard granularity of decimal timekeeping. Human beings chose to divide the second into ten because we count in ten. Computer registers do not.

A binary fraction can represent a half, a quarter, an eighth, a sixteenth, and any sum of those. It cannot represent a tenth, because 0.1 in base two is a repeating fraction:

0.1₁₀ = 0.0001100110011001100110011001100…₂

That pattern of 0011 never terminates, for exactly the reason that one third never terminates in decimal: the base does not divide the denominator. Ten is two times five, and five has no place in a binary register. So a machine that wants to hold a tenth must hold something close to a tenth, and the closeness is set by how many bits it is willing to spend.

The Patriot's weapons control computer, as the General Accounting Office described it in February 1992, was a 1970s design with limited capacity for high-precision calculation, and its registers were 24 bits long. Truncate the expansion above to fit, and the value the machine actually stored was 0.1 × (1 − 1/1,048,576). The shortfall is one part in 2 to the 20 — one part in 1,048,576, or 0.0000954%. Applied to a single tenth of a second, that is an error of about 0.0000000954 seconds.

Now multiply by time, which is the step that turns a curiosity into an accident. The clock did not keep one tenth of a second; it kept every tenth of a second since the system was started, counting them. After one hour the system had counted 36,000 of them. After 100 hours it had counted 3,600,000. One part in a million, multiplied 3.6 million times, is no longer one part in anything:

0.0000000954 s × 3,600,000 = 0.3433 s

The GAO's own table, reproduced further down this page, runs the whole curve: 0.0034 seconds of error after an hour, 0.0275 seconds after eight hours, 0.1648 after two days, 0.3433 after four. Nothing in that progression is surprising once you see it, and nothing in it is visible from the operator's console either. The Patriot displayed a track and a range gate like it always did. It had no independent way to know that its own arithmetic had been quietly losing a ten-millionth of a second every tenth of a second, forever.

What was not wrong

Two descriptions of this accident circulate widely, and both are wrong in ways that matter for anyone trying to learn from it.

The first is that the Patriot's clock drifted. It did not. A drifting clock runs fast or slow because its oscillator does — a real physical fault in a real physical component. The Patriot's clock counted tenths of a second exactly and continuously, and the GAO is careful with its language: the loss of precision was in the conversion of time from an integer to a real number. Mislabel this and you learn the wrong lesson, which is that you need a better clock. You do not. You need arithmetic that does not silently round.

The second is that the failure was a floating-point bug of the kind described in modern IEEE 754 terms. The Dhahran computer was not doing IEEE 754 arithmetic; that standard was published in 1985 and this design predates it. What the GAO describes is the older and simpler problem of a 24-bit fixed-point register, which is the reading Robert Skeel drew from the GAO's own table: an integer count of ticks, multiplied by a truncated fractional constant. The distinction matters because fixed-point truncation is a live hazard today in embedded systems, DSPs, flight computers and timers, where floating point is avoided deliberately — for determinism, for speed, or because there is no floating-point unit to spare. The Dhahran failure was not an obsolete mistake. It was a mistake in a technique that is still in use, and still worth checking.

How a Time Error Becomes a Hole in the Sky

To understand why 0.3433 seconds mattered, you have to know what the Patriot's radar was doing with the time. It was not continuously staring at the Scud. Like every pulse-Doppler radar, it sent out pulses and listened for returns, and between returns it had to guess where to listen next. The GAO's description of that guess is worth reading closely, because it is the entire mechanism of the accident in one paragraph:

"After the Patriot's radar detects an airborne object that has the characteristics of a Scud, the range gate — an electronic detection device within the radar system — calculates an area in the air space where the system should next look for it."

"Velocity is a real number that can be expressed as a whole number and a decimal (e.g., 3750.2563… miles per hour). Time is kept continuously by the system's internal clock in tenths of seconds but is expressed as an integer or whole number (e.g., 32, 33, 34…)."

"The effect of this inaccuracy on the range gate's calculation is directly proportional to the target's velocity and the length of time the system has been running."

— GAO/IMTEC-92-26, Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia, February 1992

Two details in that passage are easy to skim past and are the crux of the case. The first is the units: velocity is quoted in miles per hour against a clock counting tenths of seconds, so the range gate is a place in the sky computed from a multiplication of two numbers in unrelated units, one of which had a representation error baked into it. The second is the phrase directly proportional. The error is not a fixed offset that an operator could learn to allow for. It grows with uptime, which means that a battery that was accurate at breakfast was outside its own tracking envelope by the afternoon, without any change in configuration, calibration or hardware.

And because the stored multiplier was slightly small, the computed elapsed time was slightly shorter than the true elapsed time. The system therefore believed less time had passed than really had, which in turn means the range gate was placed behind the missile — where the Scud had been, not where it was going. The radar looked, found empty sky, and drew the only conclusion available to it.

What that conclusion cost is worth stating precisely, because the GAO's account is more specific than most retellings. Six Patriot batteries were protecting the airfields around Dhahran. Alpha Battery, the one with the engagement, detected the Scud but could not hold it long enough to confirm that it was an incoming ballistic missile; it classified the contact as a false positive and did not fire. A battery further along the missile's flight path had tracked the Scud as it passed on its way to Dhahran. The operators at Alpha saw no indication of the missile on their displays — not because the radar never found it, but because the arithmetic had moved the place it was looking.

The Patch That Removed the Cancellation

Here is the part of the Dhahran investigation that a reader can actually take to work, and it is not the rounding. On its own, a constant fractional error in a clock reading is nearly harmless to a tracking radar, for a reason that Robert Skeel set out in SIAM News in July 1992. What a tracking radar needs is not the absolute time; it is the elapsed time between two radar pulses. Subtract one timestamp from another, and a fractional error that shortens both by the same proportion largely cancels out of the difference. The residual error in the interval would have been about 0.0001% of the interval — physically irrelevant.

That is what should have happened. What actually happened is that the software had been modified for the Gulf deployment, repeatedly, to cope with targets far faster than the Patriot had been designed against. One of those modifications added a subroutine that converted clock time to a real number more accurately. The subroutine was needed in roughly half a dozen places in the program, and the call to it was not inserted at every place it was needed.

The consequence is the whole accident. One of the two timestamps being subtracted was now converted accurately; the other was still converted by the truncated 24-bit multiply. The error stopped cancelling. Instead of a 0.0001% error in the interval, the system had the full accumulated error of the less accurate conversion sitting inside a subtraction — and at 100 hours of uptime that error was 0.3433 seconds.

The general rule is uncomfortable and it is worth stating flatly, because it inverts the normal instinct about software fixes. An error that is common to both terms of a subtraction cancels; make it a property of only one term and it stops cancelling. A partial fix to a cancelling error is therefore not a partial improvement — it is a new defect, and a worse one than the condition it was written to address. The safest version of the Dhahran software was not the patched version. It was the unpatched version, which was uniformly wrong and therefore, for the purposes of measuring an interval, right.

The testable form of that rule is simple and rarely followed: when you change a conversion used in more than one place, verify the difference of two converted values, not the values. Checking that each timestamp is individually close to correct tells you nothing about whether they are close to correct in the same direction.

Twenty Hours Was the Line, and Everyone Had the Data

The most damning fact in the GAO report is not the arithmetic. It is the timeline. The Army did not learn about this failure on 25 February 1991; it learned about it on 11 February, two weeks earlier, when the Patriot Project Office received Israeli data identifying a 20% shift in the radar range gate after eight consecutive hours of operation. Israeli forces had been reporting degraded accuracy after long runs, and had done the work of quantifying it.

A 20% shift matters because the tracking geometry has no slack. The GAO's account is specific: the target needs to be centred in the range gate for the highest probability of tracking, and the Patriot will not track a Scud when there is a range gate shift of 50% or more. Since the shift is proportional to uptime, a 20% shift at eight hours extrapolates directly to a 50% shift at about twenty hours. Twenty hours was the number at which the system stopped being able to do its job, and it was derivable on 11 February with a pencil.

Set that against the two facts that determine the outcome. On 25 February, the battery at Dhahran — Alpha Battery — had been in operation for over 100 consecutive hours, five times past the line at which it could no longer track a Scud. And the corrected software, developed in response to the Israeli data, did not reach Dhahran until 26 February 1991 — the day after the attack. Between those two dates sit fifteen days in which the system's degradation was known, quantified, documented and understood, and in which the battery stayed switched on.

The GAO's table is the clearest artefact of the whole investigation, because it is short enough to read in one glance and complete enough to be used.

Table as published in GAO/IMTEC-92-26 (February 1992). The 20-hour row is the point at which the GAO states the target falls outside the range gate; the 100-hour row is Alpha Battery's state at Dhahran on 25 February 1991.

Two honest footnotes to the GAO's numbers, because the site's habit is to show where the figures come from rather than smooth them over. First, the inaccuracy column is exactly what the arithmetic predicts: every value is 2 to the minus 20 of the elapsed seconds, to four decimal places. The 100-hour row is 360,000 × 0.0000009537 = 0.3433. That is the great virtue of a proportional error — it is completely predictable, and entirely invisible without arithmetic.

Second, the metres column and the commonly quoted miss distance do not agree, and it is worth knowing why. Dividing 687 metres by 0.3433 seconds gives a missile speed of about 2,000 m/s. The figure usually quoted for an Al Hussein on re-entry is 1,676 m/s — Mach 5 — which over the same 0.3433 seconds gives 575 metres. The GAO's shift column is a range-gate displacement, not a miss distance, and the two are not the same quantity; both numbers are in circulation and both trace back to the same report. If you need one figure for the geometry of the failure, use 0.3433 seconds, which is not an estimate of anything: it is the arithmetic.

Why Nobody Had Restarted It

The natural question is why a system with a known, time-dependent accuracy problem had been left running for four days. The GAO answers it, and the answer is not negligence at the console.

The Patriot was designed to be mobile, and — in the GAO's words — to operate for only a few hours at one location. Its threat model was Soviet medium- and high-altitude aircraft and cruise missiles in Europe, travelling at up to about Mach 2, and its survival strategy was to shoot and move. Continuous operation was never a design case; there was no requirement that said the system should stay accurate indefinitely, because nobody expected it to be asked. In Saudi Arabia it sat on a fixed site through weeks of nightly alerts while ballistic missiles arrived at unpredictable intervals. There is no natural moment in that duty cycle to power down the air-defence system protecting a barracks, and nobody had written down a rule saying when to.

That absence is the organisational failure underneath the arithmetic, and the timeline is worth setting out because almost nothing in it is ambiguous. On 11 February 1991 the Patriot Project Office received Israeli data quantifying a 20% range-gate shift after eight consecutive hours. On 16 February a corrected software version was released. On 21 February Patriot users were notified about the range-gate shift and told that an update was on the way — but they were not told how long a battery could safely run before the shift became significant. The Army's later explanation for that omission was that it had assumed deployed batteries would not run long enough for the inaccuracy to matter, and had never gathered real data on how long they actually ran. As an immediate workaround, Israeli forces recommended restarting the system's computers periodically, because the error resets with the counter; the advice never became a restart schedule that anyone owned. The update itself left MacGuire Air Force Base in New York on 23 February and reached Riyadh on 24 February without the highest delivery priority. It arrived in Dhahran on 26 February, the day after the attack, and the GAO attributes the delay to the time it took to arrange air and ground transportation in a wartime environment.

So the crews had twice been told that a fix was coming, and had not been told the number that mattered: that tracking degraded past the point of usefulness after about twenty hours, so a battery that had been up for a hundred was not merely imprecise but out of specification, in a way its own display did not show. The information was inside the Army on 11 February. It reached the people who could act on it in the wrong form — a notification that something was being done, rather than a threshold they could count against.

The 14th Quartermaster Detachment had arrived in Dhahran six days before the attack — a water-purification unit from Greensburg, Pennsylvania, mobilised in January, quartered in a converted warehouse while it waited for its equipment. Of its 69 soldiers, 13 were killed and 43 wounded: 81% of the unit, the heaviest proportional loss of any coalition unit in the war. Field interviews recorded by the Department of Defense ten years later describe the sirens as routine, the Scuds as something soldiers stood outside to watch, and the week of 25 February as the week the launches resumed after a month of quiet. None of that is a critique of anyone at the console. It is what makes the case worth studying: the people with the least information were the people in the position to act, and the people with the most information were two weeks and one airlift away from them. Casualty figures for the strike are given as 99 wounded in the Department of Defense account and 98 in others; the count of the dead, 28, is the same in every source.

There is a coda that explains why the investigation was as laborious as it was. The Patriot battery at Dhahran had no embedded data recorder, and no Patriot system did. Across 26 batteries in Saudi Arabia and Israel the Army had 14 portable recorders, several installed weeks into the war and some never, and in Saudi Arabia commanders did not permit their use. The post-mortem therefore rested on assembly-language analysis and interviews rather than recorded telemetry — which is the same lesson as the arithmetic, one level up: a system you cannot measure is a system you cannot diagnose.

Was the Software the Whole Story?

The GAO's conclusion is precise: the battery failed to track and intercept the Scud because of a software problem in the weapons control computer, and the inaccuracy was serious enough to cause the system to look in the wrong place. That is a finding about why the engagement did not happen. It is often reported as though it were a finding that a correct clock would have saved the barracks, and that is a different claim, resting on different evidence, which the report does not make.

The distinction is not pedantry. The Patriot's ability to destroy a re-entering Scud was a live controversy before Dhahran and remains one, and the software error sits inside a wider picture that is unfavourable to the system. The Patriot had been designed against aircraft and cruise missiles; the PAC-2 interceptor and its blast-fragmentation warhead were being used against a target class travelling at roughly Mach 5. Al Hussein missiles were structurally fragile and frequently broke apart during re-entry, arriving as a cloud of debris that a radar must discriminate from a warhead. And the public claims made during the war were, on the later evidence, overstated: President Bush told a Raytheon plant on 15 February 1991 that the Patriot was "41 for 42," a success rate above 97%. In April 1992 Theodore Postol of MIT and Reuven Pedatzur of Tel Aviv University testified to a House committee that the true intercept rate was under 10% and possibly zero, a conclusion Peter Zimmerman and Charles Zraket disputed on methodological grounds. A House Government Operations Committee investigation that year settled on roughly 9%. The Army's own later assessments acknowledged confirmed kills only in a single-digit percentage of engagements. Even the first engagement of the war, on 18 January 1991, which was widely reported as the first ballistic-missile interception in history, turned out to have been a computer glitch: no Scud had been fired at Saudi Arabia that day.

Set beside all that, the Dhahran software error explains something narrower and quite unambiguous. The battery detected the Scud, computed a range gate that did not contain it, concluded the contact was spurious, and never fired. Not "fired and missed" — never fired. That is the event the GAO investigated and the event the arithmetic explains exactly. Whether a PAC-2 launched at that Scud would have destroyed the warhead is a question the record cannot answer, because the launch never happened; and given the interceptor's record against Scud-class targets, the honest answer is that it might well not have. Two things are true at once. The clock error is why the engagement did not occur, and the engagement's absence is not the same as a saved barracks. Keeping those apart is the difference between quoting this accident and learning from it.

What This Case Teaches That the Other Five Cannot

The five earlier accidents in this series are all versions of one failure: a quantity written in the wrong unit. They teach labelling, interfaces, and the discipline of checking that the number you received means what you think it means. Dhahran teaches something the others structurally cannot, because at Dhahran every unit was correct and the number was still wrong in the only way that mattered.

Choose a counting unit your hardware can hold. This is the deepest and most transferable point. The Patriot counted time in tenths of a second, which forced a division by ten — the single most awkward divisor in a binary machine, because ten is two times five and five cannot be expressed in bits. A designer who instead counted ticks, integer milliseconds, or any power of two would have had no representation error at all, because those units convert to each other by shifting a register. The choice of counting unit is a conversion decision, and it is made once, early, and paid for forever. It is the same class of decision as the one behind the Year 2038 problem, where a 32-bit counter of seconds overflows in 2038: in both cases the fatal property is the unit the system counts in rather than the arithmetic performed on it.

A partial fix to a cancelling error is a new defect. The unpatched Patriot was uniformly inaccurate, and a uniform inaccuracy cancels when you subtract one timestamp from another. Patching one of the two terms destroyed the cancellation. If you change a conversion that appears in more than one place, the only meaningful test is on a difference, and the only safe assumption is that you have not found every call site.

Uptime is an input to accuracy, and therefore belongs in the manual. Any system whose error grows with runtime needs that fact written down in three places: the test plan, which must exercise the maximum expected runtime rather than a comfortable one; the operating procedure, which must say when to restart and why; and the operator's checklist, in the form of a number the crew can act on. The Army had the number — about twenty hours — and it stayed inside the project office. The battery went to a hundred.

And a fourth, which is really a habit rather than a rule: the error was proportional, documented and predictable, and that is exactly why it was dangerous. Errors that grow smoothly with a variable nobody is watching — hours of uptime, number of restarts, days since calibration, megabytes of log — do not announce themselves at the moment they cross the threshold at which the system stops working. They announce themselves afterwards, in a report with a table in it. If you want the units of time themselves — the second, the leap second, and the two ways international timekeeping already corrects for clocks that do not agree — that guide is the companion to this one.

Related Converters

Every number in this accident is a conversion between time units, or between the speed of a missile and the distance it covers while a computer is wrong. These are the tools for working them out precisely:

• Seconds to milliseconds — a tenth of a second is 100 ms, the unit the Patriot counted in
• Milliseconds to seconds — the reverse direction, and the conversion the truncated register performed badly
• Hours to seconds — 100 hours is exactly 360,000 seconds, and 3,600,000 tenths of a second
• Seconds to hours — where the accumulated error sits relative to total runtime
• Minutes to seconds — the interval scale in which the range gate was computed
• Hours to days — 100 hours is 4.17 days: the battery had not been restarted in four days
• Meters per second to mph — 1,676 m/s is about 3,749 mph, the "Mach 5" of the Scud
• km/h to mph — 6,034 km/h against the GAO's quoted velocities in miles per hour
• Meters to feet — 687 m of range-gate shift is 2,254 ft; 575 m is 1,886 ft
• km to miles — the same distances in the unit the GAO used for velocity
• Time converters — seconds, minutes, hours, days, weeks and months in one place

Related Guides

• The 8 Most Expensive Unit Conversion Mistakes in Engineering History — the roundup that places Dhahran alongside the Vasa, the Gimli Glider, Deepwater Horizon and four more.
• Time Conversion Guide — the second, the leap second, TAI and UTC, and the offset arithmetic that keeps the world's clocks in agreement.
• The Year 2038 Problem — the other way a machine breaks time: a 32-bit counter of seconds running out of room, the same family as a 24-bit register that cannot hold a tenth.
• Mars Climate Orbiter: When 1 N·s Was Read as 1 lbf·s — the newest case in the series, and the one closest in spirit: a system that was internally consistent and still wrong, with no way for the machine to notice.
• Gimli Glider: The 22,300 kg That Arrived as 22,300 lb — a right number carrying a wrong unit, and a machine with no way to complain.
• Speed Conversion Guide — m/s, km/h, mph, knots and Mach: the units in which a Scud's speed is stated, and why the Mach number changes with altitude.

Frequently Asked Questions

What caused the Patriot failure at Dhahran?

The weapons control computer kept elapsed time as an integer count of tenths of a second and converted that count to seconds by multiplying by 0.1 held in a 24-bit register. Because 0.1 has no finite binary expansion, the stored multiplier was short by one part in 1,048,576, an error of 0.0000954% that grew in proportion to how long the system had been running. After 100 hours of continuous operation the clock was effectively 0.3433 seconds slow, which shifted the radar's range gate by an amount large enough to place the incoming Scud outside it. The battery detected the missile, found nothing where it looked, treated the contact as spurious, and never launched an interceptor.

Why can a computer not store one tenth of a second exactly?

Because 0.1 in binary is a repeating fraction: 0.0001100110011001100110011001100… with no terminating end, for the same reason that one third never terminates in decimal. A binary register can hold one half, one quarter, one eighth and sums of those, but a tenth requires dividing by five, which has no representation in base two. A 24-bit register therefore stores something very slightly less than 0.1 — specifically 0.1 multiplied by one minus 1/1,048,576. The error is one part in a million, which sounds negligible until you multiply it by every tenth of a second in a hundred hours of uptime.

How fast did the Patriot's timing error grow?

The error was directly proportional to uptime, at one part in 1,048,576 of the elapsed time. The GAO's published table gives 0.0034 seconds after one hour, 0.0275 seconds after eight hours, 0.0687 seconds after twenty hours, 0.1648 seconds after 48 hours, 0.2472 seconds after 72 hours, and 0.3433 seconds after 100 hours. The Patriot Project Office said the system will not track a Scud once the range-gate shift reaches 50%, which the same proportionality places at about twenty hours of continuous operation.

Did the Patriot's radar detect the Scud at Dhahran?

Yes. The radar detected the incoming missile and the range gate computed an area of sky in which to look for it next, but the accumulated timing error placed that area behind the missile rather than around it. The follow-up search found no target, so the system concluded that the original detection had been a spurious track and removed it. No interceptor was launched — this was a failure to engage, not a launch that missed.

Why was the software fix not installed in time?

Army officials received Israeli data on 11 February 1991 showing a 20% range-gate shift after eight consecutive hours of operation, and released a corrected software version on 16 February. Users were notified on 21 February that an update was coming, but were not told how long a battery could safely run. The update left MacGuire Air Force Base in New York on 23 February and reached Riyadh on 24 February; it did not reach Dhahran until 26 February 1991 — the day after the attack, which killed 28 soldiers on 25 February. The GAO attributes the delay to the time needed to arrange air and ground transportation in a wartime environment, and records that Israeli forces had recommended periodic restarts as an immediate workaround.

Would the Patriot have shot down the Scud if the software had been correct?

That question cannot be answered from the record, and it should not be assumed. The software error explains why the engagement never happened: the battery detected the Scud and then dropped the track, so no interceptor was fired. Whether a PAC-2 would have destroyed the warhead is a separate matter, and the evidence there is unfavourable — the interceptor was designed against aircraft and cruise missiles rather than Mach 5 ballistic targets, Scuds frequently broke up during re-entry into debris that confused tracking, and later congressional and academic analyses of the war put the Patriot's confirmed intercept rate in the single digits.

Sources

Primary sources

• U.S. General Accounting Office, GAO/IMTEC-92-26, Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia (B-247094, 4 February 1992) — the range-gate mechanism, the 24-bit register finding, the Israeli 20% data of 11 February, the 50% tracking limit at about 20 hours, the published truncation table, and the arrival of the modified software on 26 February 1991
• Robert Skeel, "Roundoff Error and the Patriot Missile" (SIAM News, July 1992) — the analysis showing that the relevant radar quantity is the interval between pulses rather than absolute clock time, and the incompletely applied accurate-conversion subroutine that stopped the error from cancelling
• U.S. Department of Defense, "Scud Alert: After the Blast" (DVIDS, 2001) — the casualty figures for the 14th Quartermaster Detachment, and first-hand accounts from the soldiers in the barracks

Secondary references

• U.S. House Committee on Government Operations investigation, 1992 — the estimate that Patriot missiles destroyed about 9% of the Scuds engaged
• Testimony of Theodore Postol (MIT) and Reuven Pedatzur (Tel Aviv University) before the House Committee on Government Operations, 7 April 1992, and the rebuttal by Peter Zimmerman and Charles Zraket — the dispute over the Patriot's Desert Storm intercept rate
• Al Hussein airframe specifications, and the GAO's note that the Patriot's weapons control computer used in Desert Storm was a 1970s design with limited high-precision calculation capability