Your Simulator Only Fails the Way You Told It To

In one of the last training runs before Apollo 11 flew, a simulation supervisor named Dick Koos fed the flight control team a computer alarm nobody had briefed them on. Steve Bales, the 26-year-old guidance officer, read it as a fault and called an abort — and Koos told him the call was wrong, that aborting a landing the computer could survive would have been the real failure. Weeks later, at about 33,000 feet over the Sea of Tranquility, Apollo 11's guidance computer threw the same class of alarm for real.

This time the room said go. The 1202, and the 1201 that followed lower in the descent, were the guidance computer overloading — the rendezvous radar was stealing cycles it should never have been given, and the machine was shedding low-priority work to keep the landing math running. That behavior was in the design. What was not in the design was the confidence to trust it in real time, with the descent underway and no chance to stop and study it. That came from a training run, from a man whose job was to invent the failure the team had not prepared for, and from the argument he won afterward.

The landing was not saved by a faster computer or a higher-fidelity simulator. It was saved because someone had already made the room live through the exact bad day, and lost, and learned. That is the part of simulation the space industry keeps underfunding, and it is worth being precise about why.

A simulator measures your imagination, not your system

A test bench measures the hardware. A simulator measures something narrower and easier to forget: the set of situations someone thought to put in front of the software. A green run does not mean the system is correct. It means the cases you modeled passed. The distance between those two statements is where missions are lost.

This matters most in the off-nominal region, because that is where the modeling stops. Teams specify the nominal timeline to the millisecond — separation, ignition, the burn, the staging sequence — and exercise it until it is boring. The failure cases get a fraction of the same attention, not because engineers are lazy, but because the nominal path is finite and the failure space is not. There is one way for a descent to go right and a thousand ways for it to go wrong, and no schedule funds a thousand scenarios.

The simulation covers the timeline and grazes the envelope. The run comes back green, and the green is honest about a narrow question: the situations we imagined, we survived. Nobody asked the machine about the rendezvous radar left in the wrong mode, because nobody imagined it. The computer met that one for the first time at 33,000 feet.

Coverage is a creative act, not a checklist

We have argued in this space that an ICD must specify its failure half — what a producer emits when it cannot compute a valid value, and what a consumer owes a value it has no reason to trust. That is necessary. It is not sufficient. A specified failure is not a rehearsed one, and the Apollo landing is the cleanest proof we have.

The guidance computer's response to overload was designed, documented, and correct. It did exactly what its builders at the MIT Instrumentation Laboratory intended: it dropped the low-priority jobs and kept the guidance loop alive. Every part of that was written down. And the flight controllers still nearly threw a good mission away, because knowing a system can survive a fault on paper is a different thing from having watched it survive and knowing where the line is. The scenario that mattered was not in any document. It had to be invented.

You cannot enumerate the dangerous scenarios from the interface spec, because the ones that end missions are combinations — a radar mode times a compute load times a phase of flight that no single requirement owns. Coverage metrics will not surface them. Someone with a hostile imagination has to sit down and ask what would happen if.

A simulator measures the failures you imagined. The one that ends the mission is the one you didn't.

The missing role is the adversary

Space programs will spend a year standing up a real-time simulator and not one week deciding who is paid to break it. The tooling gets a budget line. The scenario library gets whatever attention is left after the nominal cases are green. There is a role missing from most integration efforts, and it is not an engineer who builds the simulation — it is an engineer whose entire job is to defeat it.

Other high-consequence industries already staff this. Automotive functional-safety programs run structured fault-injection campaigns under ISO 26262, where the point is to force every failure mode the hardware can produce and confirm the software degrades the way the design claims. Aviation runs the same discipline. Apollo had Koos and a room of simulation supervisors whose reputation depended on finding the case the flight controllers had not thought of. The simulator is a tool. The adversary is a person, and the person is what most programs cut first.

This is not a plea for more testing in the abstract. It is a specific claim about who is accountable. When the scenario that fails you shows up in flight, the postmortem always finds it was imaginable — a switch in the wrong position, a message arriving late, a sensor reading valid garbage. It was imaginable. The question is whether anyone on the program was paid to imagine it.

Put the scenarios where the interface lives

The adversary needs somewhere to keep the work, or it dies with them. This is the same argument we make about interfaces: if the scenario exists only in one engineer's head or one afternoon's manual test, it is not an asset the program owns. The off-nominal cases should be versioned artifacts, sitting beside the interface definitions they exercise, diffed and reviewed like any other code.

# fault_scenarios/adcs_star_tracker.yaml — versioned with the ICD it exercises
scenario: star_tracker_stale_during_slew
inject:
  at: t+142.0s              # mid-slew, high rate
  fault: freeze_last_valid  # tracker holds its last quaternion, keeps the valid flag high
expect:
  adcs_response: reject_and_flag   # must not act on a value it cannot trust
  fault_declared_within: 500ms
owner

# fault_scenarios/adcs_star_tracker.yaml — versioned with the ICD it exercises
scenario: star_tracker_stale_during_slew
inject:
  at: t+142.0s              # mid-slew, high rate
  fault: freeze_last_valid  # tracker holds its last quaternion, keeps the valid flag high
expect:
  adcs_response: reject_and_flag   # must not act on a value it cannot trust
  fault_declared_within: 500ms
owner

# fault_scenarios/adcs_star_tracker.yaml — versioned with the ICD it exercises
scenario: star_tracker_stale_during_slew
inject:
  at: t+142.0s              # mid-slew, high rate
  fault: freeze_last_valid  # tracker holds its last quaternion, keeps the valid flag high
expect:
  adcs_response: reject_and_flag   # must not act on a value it cannot trust
  fault_declared_within: 500ms
owner

A scenario written this way runs in continuous integration, not once at a review. When someone changes the star tracker interface, the fault case runs against the new definition and fails if the consumer no longer rejects a frozen reading. The adversary's imagination stops being a one-time event and becomes a regression suite. The bad day gets rehearsed on every commit, by machines, so the room does not meet it for the first time in flight.

What changes if you accept this

The measure of a simulation program is not the fidelity of its models or the fraction of runs that pass. Both can be excellent while the coverage is a map of the team's optimism. The measure is whether someone is accountable for inventing the scenario that ends the mission, and whether that scenario is written down where a build can run it. Fidelity tells you the answer is trustworthy. Coverage tells you whether you asked the question at all, and only one of those is on the critical path to a lost vehicle.

Apollo 11's computer was built to survive the overload it hit, and it did. The landing still came down to whether someone had forced the flight controllers to live through it first, in a simulator, against a supervisor trying to make them fail. He did his job, they lost the sim, and two weeks later they put a crew on the Moon. The simulator did not save the landing. The person writing the scenarios did.