The failure in one paragraph
On 19 October 2016, the ExoMars Schiaparelli entry demonstrator deployed its parachute about three minutes after atmospheric entry, experienced unexpected high rotation rates, and saturated its Inertial Measurement Unit for roughly one second. The guidance, navigation and control software merged that corrupted rotation data into its state estimate, produced a large attitude error, and eventually computed an altitude below ground level. The flight computer then released the parachute and backshell, fired the braking thrusters for 3 seconds instead of 30, and activated the on-ground sequence as if the vehicle had landed. It was still at about 3.7 km. Signal was lost at 14:47:22 UTC, roughly 43 seconds before the expected touchdown, and the module hit the surface at an estimated 540 km/h. The ESA inquiry attributes the loss to saturation handling, modelling, and validation gaps — not to a failed IMU. That distinction is the whole article.
What the inquiry actually established
The primary document is the ESA Inspector General’s ExoMars 2016 – Schiaparelli Anomaly Inquiry (DG-I/2017/546/TTN, Issue 1 Rev 0, 18 May 2017), with a public summary distributed through ESA’s exploration portal. The causal chain below is drawn from those documents and from ESA’s own summary language; where I am interpreting rather than quoting, I say so.
The chain, step by step
- Parachute deploy, then unexpected rotation. ESA’s summary states that around three minutes after entry the parachute deployed and the module experienced unexpected high rotation rates. The deployment itself was not the anomaly; the body rates that followed were.
- IMU saturation. Those rates exceeded the IMU’s measurement range. ESA describes this as a brief saturation “where the expected measurement range is exceeded.” The Planetary Society’s contemporaneous summary of the ESA update puts the duration at about one second — “longer than would be expected.”
- Attitude estimation error. ESA states the saturation “resulted in a large attitude estimation error by the guidance, navigation and control system software.” The IMU is the attitude source; the inquiry notes attitude is obtained by integrating gyroscope measurements.
- Negative altitude. When the erroneous information was merged into the navigation solution alongside radar altimeter data, the estimate went below ground level. ESA’s summary: the computer “calculated that it was below ground level.”
- Irreversible events fire. The negative altitude triggered premature release of the parachute and backshell, a 3-second thruster burn instead of 30 seconds, and activation of on-ground systems as if landed.
- Free-fall. The module was at about 3.7 km, not on the ground. Estimated impact speed: 540 km/h.
The inquiry notes the behaviour was reproduced in computer simulations of the control system’s response to the erroneous information. That matters: this was not an unpredictable physical event. It was a logic path that could be exercised on the ground and wasn’t, at least not with a representative sensor.
Why this is a boundary failure, not a part failure
The tempting read is “bad gyro.” The inquiry does not support that. The IMU did what saturated sensors do: it reported at its limit. The failure lived at the hardware-software boundary, in three places the inquiry names explicitly.
1. The saturation limit was set too high
BBC’s reporting on the inquiry lists “the saturation limit for the IMU was set too high” among the root causes. A range chosen against nominal flight envelopes leaves no headroom for the transient that actually occurs — in this case, parachute inflation. Setting the limit high does not prevent saturation; it only moves the threshold past the point where the flight software might have recognised the event as anomalous. The retrieved sources do not give the numeric limit or the measured peak rates, so I will not invent them. Confidence that the limit was a contributing factor: high, per the inquiry summary. Confidence in any specific number: none.
2. The guidance software handled saturated data badly
“Inadequate handling of IMU data by the guidance software” is another named root cause. The mechanism is visible in the architecture: attitude comes from integrating gyro rates, and altitude comes from fusing that attitude-propagated state with radar measurements. A one-second corruption at the input propagates through the integrator and contaminates the state long after the sensor has recovered. The inquiry’s own framing — “one mistake in any of the sub-models can ruin everything” — is about simulation, but it applies equally to the estimator.
3. The parachute model didn’t include inflation disturbances
The inquiry report states that the parachute model used in the end-to-end simulator and the Avionics Test Bench “does not include disturbances at parachute inflation such as lateral movement and area oscillations.” If the simulation never produces the rates that saturate the IMU, no test campaign built on that simulation will ever exercise the saturation path. The validation gap and the modelling gap are the same gap.
4. The IMU couldn’t be stimulated in closed-loop tests
This is the line that should stop a review cold. From the inquiry’s description of the Avionics Test Bench limitations: “IMU EM are used only for electrical interface and polarity tests – the IMU cannot be stimulated to be included in the navigation function or in the GNC closed-loop tests.” The navigation function was therefore never tested against a representative IMU under closed-loop conditions. The exact failure mode that occurred — saturated rates feeding the estimator — was outside the test envelope by construction.
The negative altitude is the tell
An altitude below ground level is physically impossible. It is also, in software terms, trivially detectable. The fact that a negative altitude propagated into irreversible event triggers tells you there was no plausibility gate between the estimator output and the event logic. The estimator was allowed to be wrong, and the event logic was allowed to believe it.
This is where I move from sourced fact to design argument. The inquiry documents the outcome; the following is my reading of what a defensible architecture would have done differently. Treat it as engineering opinion grounded in the documented chain, not as a finding of the board.
Bench-verifiable design rules
Each rule below is written so it can be tested on a bench, not just asserted in a review.
Rule 1: Saturation flags are fault inputs, not noise
Treat the IMU saturation flag as a first-class fault with an explicit persistence window. If saturation persists beyond a defined threshold — one second is the documented duration here — the estimator should hold, reinitialise, or degrade to a backup attitude source rather than integrating through the event. Bench test: inject a saturation pulse of the measured duration into the IMU interface and verify the estimator’s response is bounded and the flag is latched for the specified window.
Rule 2: Gate irreversible events on multi-sensor agreement
Parachute release, backshell separation, thruster enable, and on-ground mode are one-way doors. Each should require agreement between independent sensors — for Schiaparelli, the integrated IMU altitude and the radar Doppler altimeter — within a plausibility band before the command is issued. Bench test: drive the radar and IMU channels to disagree by more than the band and confirm no irreversible command is issued.
Rule 3: Reject physically impossible states before they reach event logic
Altitude must be non-negative. A negative estimate should raise a fault, not trigger a landing sequence. This is a one-line check with a large blast radius. Bench test: force the estimator to output a negative altitude and confirm the event logic is blocked and a fault is logged.
Rule 4: Set saturation thresholds against measured transients
Choose the IMU range against worst-case measured deployment transients, including parachute inflation, not against nominal flight. If the measured transient exceeds the selected range, that is a finding, not a nuisance. Bench test: replay recorded inflation-rate data through the selected IMU model and confirm the saturation flag asserts where expected and the software handles it.
Rule 5: Closed-loop validation requires a stimulable sensor
An IMU that can only be tested for electrical interface and polarity leaves the navigation function untested against sensor faults. The test bench must be able to inject representative rate profiles — including saturation — into the closed-loop GNC. Bench test: run the full descent sequence with injected inflation transients and verify the estimator and event logic behave as specified.
Rule 6: The simulation must contain the disturbance that matters
If the parachute model omits inflation disturbances, the Monte Carlo campaign cannot discover the failure. Add lateral movement and area oscillation terms to the inflation model and re-run the dispersion analysis. Bench test: confirm the updated model produces body rates that reach the IMU range and that the software response is characterised.
A worked hypothetical
This is a constructed example, not a record of any specific vehicle. A flight computer accepts an integrated altitude of −50 m and, without cross-checking the radar return, commands parachute release. A plausibility gate requiring altitude ≥ 0 and agreement with radar within a defined tolerance would have blocked the command and raised a fault. The gate is cheap; the release is not reversible. The Schiaparelli chain is the same shape at a larger scale.
What the evidence does not settle
Several things would sharpen this analysis and are not in the retrieved material: the numeric IMU saturation limit, the measured peak rotation rates during inflation, the specific altitude plausibility logic (or absence of it) in the GNC software, and which corrective actions were actually implemented for ExoMars 2020. The inquiry notes recommendations and required software upgrades; it does not, in the retrieved excerpts, verify implementation. Claims that the 2020 mission incorporated specific fixes should be treated as unverified until the project’s own documentation says so.
FAQ
Was the IMU defective?
No. The inquiry attributes the loss to saturation handling, modelling, and validation gaps. The IMU reported at its limit, which is what a saturated sensor does.
How long did the saturation last?
About one second, per ESA’s update as summarised by The Planetary Society — longer than expected.
Why did the thrusters fire for only 3 seconds?
Because the flight software believed the vehicle had landed. The negative altitude estimate triggered the on-ground sequence, which cut the burn short. The planned burn was 30 seconds.
Could the landing have succeeded despite the saturation?
The inquiry indicates the module was close to a successful landing at the planned location and that other checks and balances, had they been present, could have prevented the loss. That is the inquiry’s assessment, not a simulation result I can reproduce here.
Design rules, restated
Treat saturation as a fault with a persistence window. Gate irreversible events on multi-sensor agreement. Reject physically impossible states before they reach event logic. Set thresholds against measured transients. Require a stimulable sensor in closed-loop validation. Put the disturbance that matters into the simulation. A one-second sensor saturation should never be able to command a descent sequence; the architecture should make that impossible, and the bench should prove it.
