How Wrong Units Cost Engineers Millions: Real-World Conversion Disasters
A $327M spacecraft, a powerless 767 mid-flight, a factory shutdown, a near-fatal drug error, and a $40K trading loss. All caused by a single wrong unit. Here is what actually went wrong — and the architecture patterns that prevent it.
A unit error is not a math error. It is a systems architecture failure that looks like a math error after the fact.
The Mars Climate Orbiter did not crash because engineers forgot how to multiply. The Gimli Glider did not run out of fuel because pilots forgot how to subtract. A fentanyl pump did not nearly kill a patient because a developer wrote wrong arithmetic. In every case, the arithmetic was correct. The unit — the thing that gives the number its physical meaning — was wrong. And the system had no mechanism to catch it.
This is a field guide to what unit errors actually look like when they escape into production. Seven cases, from spacecraft to ICUs to factory floors. Each one ends with the architecture fix that would have prevented it.
Case 1: Mars Climate Orbiter (1999)
Cost: $327,600,000 and a spacecraft
On September 23, 1999, the Mars Climate Orbiter fired its main engine to enter Mars orbit. It approached 15–30 km lower than planned. At that altitude, atmospheric friction destroyed it.
The unit error: Lockheed Martin's navigation software output thruster impulse data in pound-force seconds (lbf·s) — the imperial unit. NASA's navigation team at the Jet Propulsion Laboratory expected the data in newton-seconds (N·s) — the metric SI unit. The interface specification required metric. Nobody checked the output unit of the Lockheed module.
1 lbf·s = 4.44822 N·s. The impulse was off by a factor of 4.44 for the entire nine-month cruise. The orbital insertion trajectory drifted by 170 km. The spacecraft entered the upper atmosphere and disintegrated.
The math: Correct on both sides. The unit: wrong at the boundary between two teams.
Root cause: A software interface that accepted a numeric value with no unit validation. The unit was in the specification document. It was not enforced in code.
Architecture fix: Unit-typed APIs. If the function signature is applyThrust(impulse_Ns: NewtonSeconds) — not applyThrust(impulse: float) — the compiler rejects a pound-force-second value at build time. For languages without type-enforced units, validate units at every data handoff point. Lockheed's module and JPL's module shared a numeric interface with no unit contract. That gap was the failure.
Source: NASA JPL Mars Climate Orbiter Mishap Investigation Board Phase I Report, November 1999.
Case 2: Air Canada Flight 143 — The Gimli Glider (1983)
Cost: Emergency landing, 61 passengers, no fatalities (barely)
On July 23, 1983, a Boeing 767 on a Montreal-to-Edmonton flight ran completely out of fuel at 41,000 feet. The crew performed an unpowered glide to an emergency landing at a decommissioned airstrip in Gimli, Manitoba. The aircraft overran the runway, collided with a guardrail, and caught fire in the nose gear area. Miraculously, all 61 passengers and 8 crew survived.
The unit error: Canada had recently converted to metric. The fuel load calculation used a conversion factor of 1.77 — the weight of fuel in pounds per liter. The correct density for jet fuel is 0.803 kg per liter. Ground crew were thinking in pounds; the metric conversion required kilograms. The aircraft boarded 22,300 pounds of fuel instead of the required 22,300 kilograms — less than half the necessary fuel load.
The math: Correct. The conversion factor applied to the right formula. The unit: wrong. Pounds instead of kilograms produces a fuel quantity 2.2× lower than intended.
Root cause: A procedural gap during Canada's metric transition. The fuel density value was available in both unit systems. The procedure did not specify which unit system to use. The technician used the familiar one.
Architecture fix: Unit ambiguity is a procedural design failure. Any measurement procedure that involves a quantity available in two unit systems must specify the unit explicitly — not assume familiarity. In software: fuel quantity fields must carry a unit attribute that is validated, not assumed. In aviation: the conversion procedure must be locked to a single unit system with a mandatory verification step.
Source: Canadian Aviation Safety Board Report 83-H40007, 1985.
Case 3: The Factory Press Shutdown (Industrial Automation)
Cost: $180,000 in 3 days
A pneumatic press calibration script compared a millibar sensor reading against a safety fault threshold that was stored in the configuration file in microbars. The script performed no unit alignment. It evaluated the raw number from the mbar sensor — approximately 850 — against the µbar threshold value — 1,200,000 — using the comparison 850 > 1.2 (the threshold as it appeared in mbar terms after implicit rounding). The comparison evaluated as true. The system locked into an emergency venting cycle on every restart.
The unit error: mbar sensor output compared against a µbar configuration threshold without conversion. 1 mbar = 1,000 µbar. The threshold was 1,200 mbar (normal over-pressure limit). Stored as 1,200,000 µbar. Read by code that assumed mbar. The mismatch was three orders of magnitude.
The math: Correct. The threshold was accurate in both representations. The unit: missing from the comparison logic.
Root cause: A configuration parameter stored as a bare float with the unit encoded only in a column header — not in the data structure. A system upgrade changed the sensor output unit from µbar to mbar. The config file was not audited.
Architecture fix: Configuration parameters for physical quantities must carry their unit as a machine-readable field, not a human-readable column header. { "threshold": 1200000 } is a ticking bug. { "threshold": 1200000, "unit": "ubar" } with a validation layer that converts to the sensor's native unit at comparison time is the fix. See millibar to microbar conversion for the prefix math.
Case 4: IoT Water Meter Recall (Embedded Firmware)
Cost: 500-unit recall, 45-day battery life vs 10-year spec
A batch of 500 smart water meters shipped with a 10-year rated battery life. Forty-five days into deployment, every unit was dead.
The unit error: The firmware team left a debug sensor module in an idle state drawing 2.1 mA instead of the intended deep-sleep current of 2.1 µA. 2.1 mA versus 2.1 µA is a factor of 1,000. The device's 10-year battery life assumed µA-range sleep current. Actual current draw was 1,000× higher.
The math: The battery life calculation was correct for 2.1 µA. The current value inserted into the calculation — 2.1, which the developer read from a register showing mA — was 1,000× the intended value.
Root cause: The power profiling tool reported current in mA. The power budget spreadsheet assumed µA. The unit was never explicitly aligned between the measurement tool output and the budget model.
Architecture fix: Power budget models must state the unit in every cell header and formula. The profiling tool output unit must match the budget model unit — or an explicit conversion must be applied and audited. In firmware: sleep current validation tests must measure actual current draw against a unit-specified tolerance before a production build is signed off. A test that only checks "current < 0.1" without specifying the unit of 0.1 is not a test — it is a false guarantee. See milliampere vs microampere for the full design discipline.
Case 5: Fentanyl Syringe Pump API (Medical Device Software)
Cost: Near-fatal dose, caught by hardware guardrail
A developer integrating a pharmacy system with a syringe pump controller mapped the fentanyl dose field using milligrams (mg). Fentanyl is dosed in micrograms (µg). A standard IV analgesic dose is 25–100 µg. A milligram-level dose of fentanyl is lethal.
The unit error: The API accepted a numeric dose value. The developer passed a value in mg. The pump controller expected µg. The submitted dose was 1,000× the intended level.
The math: Correct. The developer accurately calculated the dose in mg as specified by the pharmacy system. The pump expected µg. The 1,000× gap was invisible in the numeric value.
Root cause: The pump API accepted a bare numeric dose without requiring the caller to specify or validate the unit. The unit was documented in the API specification. It was not enforced by the API contract.
Architecture fix: Any API that accepts a physical quantity — particularly for high-alert medications — must enforce the unit at the schema level. The function signature must reject an ambiguous float. In practice: submitDose({ value: 50, unit: "mcg" }) with server-side validation that rejects any value outside the physiologically plausible µg range for the specified drug. The hardware guardrail (pump's internal safety limits) caught this incident. Relying on a hardware guardrail to catch a software unit error is not a defense in depth — it is a single point of failure that happened to be there. See milligrams to micrograms in medicine for the clinical context.
Related: ISMP high-alert medication guidelines classify fentanyl as requiring independent double-checks and unit-explicit prescribing.
Case 6: High-Frequency Trading Engine (Financial Systems)
Cost: $40,000 in under 2 seconds
A timestamp logging system in a high-frequency trading engine captured network latency rounded to the nearest millisecond. During a high-volatility market event, the algorithm could not accurately sequence incoming orders that arrived within the same millisecond window. It executed trades on stale order-book data. The loss was $40,000 before the circuit breaker triggered.
The unit error: The logging system normalized all timestamps to milliseconds. The market's order sequencing required microsecond resolution. Events separated by 200–800 µs — well within a single millisecond — were treated as simultaneous. The algorithm's execution logic assumed it had full ordering information. It did not.
The math: Correct. Millisecond timestamps were mathematically accurate to the millisecond. The resolution assumption: wrong. The system needed µs precision to correctly sequence sub-millisecond events.
Root cause: A logging infrastructure design decision made without considering the temporal resolution requirements of the downstream algorithm. The unit — milliseconds — was appropriate for human-facing latency metrics. It was not appropriate for HFT order sequencing.
Architecture fix: Timestamp resolution is an architecture decision, not an implementation detail. The unit of time in a logging system must be specified against the finest resolution required by any consumer of that log data. In HFT: nanosecond-resolution hardware timestamps (PTP/IEEE 1588) are standard precisely because the business logic operates on sub-microsecond event ordering. See milliseconds vs microseconds for the full timing discipline.
Case 7: ICU Blood-Gas Dashboard (Clinical Software Integration)
Cost: Misdiagnosis risk, wrong treatment protocol
An ICU patient telemetry dashboard integrated outputs from a blood-gas analyzer. The analyzer reported creatinine in µmol/L and glucose in mmol/L — standard clinical units for these respective biomarkers. A unit label was incorrect in the dashboard integration layer. A clinician reviewing the display could see a creatinine value of 200 — and without explicit unit labels, interpret it as glucose of 200 mmol/L (a dangerous hyperosmolar emergency requiring immediate insulin and fluid management) when the actual reading was 200 µmol/L creatinine (a sign of worsening renal failure requiring a completely different intervention).
The unit error: mmol/L and µmol/L differ by exactly 1,000×. Both are dimensionally equivalent (amount per volume). Displayed as bare numbers on a unified dashboard, they are indistinguishable without explicit unit labels.
The math: Both values were correctly calculated by the analyzer. The unit labels: stripped or corrupted during the integration layer's data normalization.
Root cause: A data pipeline that normalized all concentration values to a single numeric field without preserving the unit metadata. The unit was available at the source. It was lost at the transformation step.
Architecture fix: Unit metadata must be treated as a required field in any data pipeline carrying physical measurements — not an optional annotation. A concentration value stripped of its unit at any pipeline stage is a patient safety hazard. In software: typed measurement objects ({ value: 200, unit: "umol_per_L" }) rather than bare floats, with unit validated against the biomarker's expected scale at the display layer. See millimoles to micromoles in the lab for the clinical chemistry context.
The Common Architecture Pattern Behind Every Failure
Seven incidents, seven industries, seven different physical quantities. One failure pattern:
graph TD
A[Physical measurement<br>with implicit unit] --> B[System boundary<br>no unit validation]
B --> C[Consumer assumes unit<br>different from producer]
C --> D[1,000× error enters system]
D --> E[Consequence: financial / safety / operational]
style A fill:#22d3ee,color:#111
style B fill:#dc2626,color:#fff
style C fill:#7c3aed,color:#fff
style D fill:#d946ef,color:#fff
style E fill:#4c1d95,color:#fff
Every failure above has the same structure:
- A measurement is made correctly in one unit
- It crosses a system boundary (API call, config file, data pipeline, interface spec)
- The receiving system assumes a different unit
- No validation catches the mismatch
- The consequence scales with the physical stakes of the domain
The fix is also the same in every case: enforce units at every system boundary. Not in documentation. Not in comments. In the data contract.
The Fixes That Would Have Prevented All Seven
| Principle | Implementation |
|---|---|
| Unit-typed data | Physical quantities carry their unit as a validated field, not a float |
| Boundary validation | Every API, config file, and pipeline stage validates units at input |
| Schema enforcement | The unit is part of the schema, not the documentation |
| Range sanity checks | Values outside a physically plausible range for the unit trigger rejection |
| Unit-explicit testing | Test cases specify units, not just numbers |
| Interface contracts | Software interfaces define expected units in the function signature or schema — not just in a PDF |
The tools exist. SI prefix conversion is straightforward arithmetic. Converting milli to micro is multiplication by 1,000. The math is not the problem. The systems design — specifically, the decision to treat units as a documentation concern rather than a code concern — is the problem.
Frequently Asked Questions
What caused the Mars Climate Orbiter to crash? Lockheed Martin's navigation software output thruster data in pound-force seconds (imperial). NASA's navigation system expected newton-seconds (metric). The interface between the two systems accepted a bare numeric value with no unit validation. The trajectory error accumulated over nine months, causing the spacecraft to enter the Martian atmosphere 15–30 km lower than planned. Cost: $327.6 million and the spacecraft.
What is the Gimli Glider incident? Air Canada Flight 143 (1983) ran out of fuel mid-flight because the fuel load was calculated using pounds per liter instead of kilograms per liter during Canada's metric transition. The aircraft received less than half its required fuel. The crew performed an unpowered emergency glide to a decommissioned airstrip. All 69 aboard survived.
What is the most common unit error in electronics? Confusing milliamperes (mA) and microamperes (µA) in power budget calculations. This is a 1,000× error that produces wildly inaccurate battery life estimates — and has caused at least one documented IoT product recall involving hundreds of units. See milliampere vs microampere.
How do you prevent unit conversion errors in software? Use typed measurement objects rather than bare floats for any physical quantity. Validate the unit at every system boundary (API input, config file read, database write/read, pipeline transformation). Add range sanity checks — a dose value of 50 in a drug dispensing system means different things in mg vs µg vs g, and only one of those ranges is physiologically plausible for a given drug. Test with explicit units.
What is the most dangerous domain for unit errors? Clinical medicine, specifically high-alert medication dosing (opioids, anticoagulants, insulin) where mg/µg and mL/µL errors are directly lethal. The ISMP and Joint Commission both publish specific guidance on this. See milligrams to micrograms in medicine and milliliters to microliters in the lab.
Is there a general rule for milli to micro conversion? Yes: multiply by 1,000. Micro to milli: divide by 1,000. This applies to every physical quantity — length (mm/µm), current (mA/µA), voltage (mV/µV), mass (mg/µg), time (ms/µs), volume (mL/µL), and all others. The complete SI prefix chart covers every prefix from pico to giga with the same rule applied consistently. Use the dedicated converters for specific unit pairs.
Use the milli to micro converter to verify any value before it crosses a system boundary. The arithmetic is free. The recall is not.
Sources
- NASA JPL: Mars Climate Orbiter Mishap Investigation Board Phase I Report (1999)
- Transportation Safety Board of Canada: Air Canada Flight 143 Report (1985)
- ISMP: List of High-Alert Medications in Acute Care Settings
- The Joint Commission: Do Not Use List of Abbreviations (µg / mcg)
- NIST Special Publication 811 — Guide for the Use of the International System of Units
- BIPM: SI Brochure — The International System of Units (9th edition)
- IEEE 754 Standard for Floating-Point Arithmetic
Ready to run the numbers?
Get your result instantly — private, in your browser.