Case Study 1: The $125 Million Comma: How Type Errors Crash Real Systems

Introduction

Type errors are not academic curiosities. They are not problems that only affect beginners writing homework assignments. Type errors have destroyed spacecraft, grounded fighter jets, and caused financial losses in the hundreds of millions of dollars. In this case study, we examine two of the most famous type-related disasters in computing history and ask a pointed question: would Pascal's strong type system have prevented them?

Case 1: The Mars Climate Orbiter — $125 Million Lost to a Unit Mismatch

What Happened

On September 23, 1999, NASA's Mars Climate Orbiter arrived at Mars after a 286-day journey. As it entered the Martian atmosphere for orbit insertion, ground controllers lost contact. The spacecraft had entered the atmosphere too deeply — about 57 kilometers too low — and either burned up or skipped off the atmosphere back into space. It was never recovered. The total mission cost: $125 million.

The Root Cause

The investigation revealed a shockingly simple cause. The spacecraft's trajectory was computed by two pieces of software:

  1. Ground-based software at Lockheed Martin calculated thruster impulse data in pound-force seconds (an Imperial unit).
  2. Navigation software at NASA's Jet Propulsion Laboratory expected the data in newton-seconds (a metric unit).

One pound-force second equals approximately 4.45 newton-seconds. Over nine months of trajectory corrections, the cumulative error pushed the spacecraft into a fatally low orbit.

The Type System Connection

At its core, this was a type error. The ground software produced values of type "impulse in pound-force-seconds" and the navigation software consumed values of type "impulse in newton-seconds." Both were stored as plain floating-point numbers. Nothing in the system distinguished between the two.

In a strongly typed language, we could define distinct types:

type
  PoundForceSeconds = Real;
  NewtonSeconds = Real;

var
  thrusterImpulse: PoundForceSeconds;
  navInput: NewtonSeconds;
begin
  thrusterImpulse := 4.45;  { from Lockheed Martin software }
  navInput := thrusterImpulse;  { Would this compile? }
end.

In standard Pascal, this would compile because PoundForceSeconds and NewtonSeconds are type aliases — they are both just Real. But Pascal's type system philosophy points us toward the right design. A more disciplined approach would use distinct record types:

type
  PoundForceSeconds = record
    value: Real;
  end;
  NewtonSeconds = record
    value: Real;
  end;

function ConvertToNewtons(pfs: PoundForceSeconds): NewtonSeconds;
const
  CONVERSION_FACTOR = 4.44822;
begin
  ConvertToNewtons.value := pfs.value * CONVERSION_FACTOR;
end;

var
  thrusterImpulse: PoundForceSeconds;
  navInput: NewtonSeconds;
begin
  thrusterImpulse.value := 4.45;
  navInput := thrusterImpulse;  { Compile ERROR: incompatible types }
  navInput := ConvertToNewtons(thrusterImpulse);  { Correct: explicit conversion }
end.

Now the compiler refuses to let you assign a PoundForceSeconds value to a NewtonSeconds variable without going through the explicit conversion function. The $125 million bug becomes a compile-time error caught in seconds.

The Lesson

The Mars Climate Orbiter was not destroyed by incompetent engineers. It was destroyed by a system that allowed two different units to be represented as the same type. The software looked correct. The numbers were right — they were just in the wrong units. A type system that distinguished between units would have caught this automatically.

Case 2: The Ariane 5 — $370 Million Destroyed by Integer Overflow

What Happened

On June 4, 1996, the European Space Agency launched the Ariane 5 rocket on its maiden flight. Thirty-seven seconds after liftoff, the rocket veered sharply off course. The automated self-destruct system activated, and the rocket — along with its payload of four scientific satellites — was destroyed over the Atlantic Ocean. Total loss: approximately $370 million.

The Root Cause

The investigation board determined that the failure originated in the Inertial Reference System (IRS), which measured the rocket's horizontal velocity. The IRS software had been inherited from the Ariane 4, the previous-generation rocket.

Here is what happened at the code level:

  1. A 64-bit floating-point number representing horizontal velocity was converted to a 16-bit signed integer.
  2. On the Ariane 4, the horizontal velocity during the first 40 seconds of flight never exceeded 32,767 — the maximum value a 16-bit signed integer can hold.
  3. The Ariane 5, being a much more powerful rocket, accelerated faster. Its horizontal velocity did exceed 32,767.
  4. The conversion overflowed. The 16-bit integer could not hold the value.
  5. The overflow triggered an exception — an Operand Error — that was not handled.
  6. The IRS shut down. The backup IRS (running identical software) had already shut down for the same reason.
  7. With no guidance data, the flight computer interpreted diagnostic data as navigation data, commanded a hard turn, and structural loads tore the rocket apart.

How Pascal's Type System Helps

Let's model the critical conversion in Pascal:

var
  velocity64: Double;    { 64-bit floating-point }
  velocity16: SmallInt;  { 16-bit signed integer: -32768 to 32767 }
begin
  velocity64 := 37000.0;  { Ariane 5's actual velocity }

  { Direct assignment: Pascal compiler would flag this }
  velocity16 := velocity64;  { Compile Error: Incompatible types }

  { Even with explicit conversion, range checking catches it }
  {$R+}  { Enable range checking }
  velocity16 := Trunc(velocity64);  { Runtime Error 201: Range check error }
end.

Pascal provides two layers of protection:

  1. Compile-time: You cannot assign a Double to a SmallInt without explicit conversion. The compiler forces you to write Trunc(velocity64) or Round(velocity64), making the conversion visible.

  2. Runtime: With {$R+} (range checking enabled), if the converted value does not fit in the target type, Pascal raises a runtime error instead of silently overflowing.

The Ariane 5 software (written in Ada, which also has strong typing) actually did have the type conversion flagged. But the engineers had disabled the overflow check for that specific variable to save processing time — a decision the investigation board called "inadequate" and one that cost $370 million.

The moral: even the best type system cannot protect you if you deliberately circumvent it. Pascal's type discipline is only valuable if you respect it.

The Deeper Lesson

The Ariane 5 disaster reveals something profound: the software was correct for the Ariane 4. The bug only appeared when the software was reused in a new context with different performance characteristics. The horizontal velocity assumption (that it would fit in 16 bits) was undocumented — it lived only in the engineers' heads.

If the code had used a more appropriately sized integer (a 32-bit LongInt instead of a 16-bit SmallInt), the bug would not have occurred. And if the type system had forced the engineer to justify the choice of SmallInt — to document why 16 bits was sufficient — the reuse team might have caught the assumption before launch.

Case 3: The Patriot Missile — 28 Soldiers Killed by Floating-Point Drift

What Happened

On February 25, 1991, during the Gulf War, an Iraqi Scud missile struck a US Army barracks in Dhahran, Saudi Arabia, killing 28 American soldiers and injuring 98 others. A Patriot missile battery was stationed at the base and should have intercepted the Scud. It failed to do so.

The Root Cause

The Patriot's targeting system tracked time using a 24-bit integer register that counted in tenths of a second. To compute elapsed time in seconds, the software multiplied this count by 1/10. But 1/10 cannot be represented exactly in binary floating-point. The small error — about 0.000000095 seconds per tenth — accumulated over time.

The Patriot battery at Dhahran had been running continuously for approximately 100 hours. Over that period, the timing error accumulated to approximately 0.34 seconds. A Scud missile travels at approximately 1,676 meters per second. In 0.34 seconds, the Scud traveled over half a kilometer beyond where the Patriot's targeting system expected it to be. The Patriot fired at empty sky.

The Type System Connection

This is the Real number precision problem from Section 3.4 writ large. If the time-tracking system had used an Integer counter in tenths of a second (which it did) and converted to a Real only at the moment of computation (instead of accumulating a floating-point representation), the error would not have drifted.

{ Problematic approach: accumulating floating-point time }
var
  elapsedTime: Real;
begin
  elapsedTime := 0.0;
  { Every tick: }
  elapsedTime := elapsedTime + 0.1;  { Error accumulates! }
end.

{ Better approach: integer counting, late conversion }
var
  tickCount: LongInt;  { counts tenths of a second }
  elapsedTime: Real;
begin
  tickCount := 0;
  { Every tick: }
  tickCount := tickCount + 1;
  { Only convert when needed: }
  elapsedTime := tickCount / 10.0;  { Single conversion, minimal error }
end.

This is the principle: use integers for accumulation, convert to floating-point only at the last moment. The type system reminds us of this distinction — tickCount is an Integer because it is a count, and counts are naturally whole numbers.

Discussion Questions

  1. The Cost of Convenience: The Ariane 5 engineers disabled the overflow check to save processing time. Under what circumstances (if any) is it justified to disable safety checks? How should such decisions be documented?

  2. Units as Types: The Mars Climate Orbiter disaster could have been prevented by making units part of the type system. Why do you think most programming languages (including Pascal) do not build unit tracking into their type systems? What would be the trade-offs?

  3. Reuse and Assumptions: The Ariane 5 software was reused from the Ariane 4 without revalidating all assumptions. What processes could prevent this kind of failure? How does strong typing help document assumptions?

  4. Your Own Experience: Have you ever been bitten by a type-related bug (in any language)? What happened, and how did you find it? Would Pascal's type system have caught it at compile time?

  5. Integer vs. Real for Accumulation: The Patriot missile failure resulted from accumulating floating-point error. Think of three other scenarios where choosing Integer over Real (or vice versa) has real-world consequences.

Key Takeaways

  • Type errors are not trivial — they have caused the loss of spacecraft, rockets, and human lives.
  • Strong typing catches bugs at compile time, but only if you respect the type system and avoid circumventing it.
  • Making units, ranges, and precision requirements explicit in your type declarations is not bureaucracy — it is engineering discipline.
  • The choice between Integer and Real types is not merely a matter of convenience; it has real consequences for correctness, precision, and safety.
  • Pascal's insistence on explicit type conversion is directly aligned with the engineering principle of making assumptions visible and verifiable.