Apollo 11: off-nominal behaviour as a requirement
When the guidance computer overloaded during lunar descent, the software shed low-priority work and the landing continued.
- Programme
- Apollo 11 guidance computer software
- Year
- 1969
- Sector
- Space
- Outcome
- Landing continued through 1202/1201 alarms
What happened
During the lunar descent, the Apollo guidance computer raised 1202 and 1201 alarms caused by processing overload.
The flight software developed at MIT prioritised its tasks and restarted, shedding low-priority work so that the essential functions kept running. The landing continued.
What was found
The NASA Apollo 11 Mission Report records the alarms and the computer's response. The behaviour was not improvised in the moment: the software had been designed to protect its most important work when resources ran short.
Off-nominal behaviour had been treated as a design requirement, not as an afterthought.
Engineering lesson
Requirements that describe only nominal behaviour leave the most important questions unanswered. What the system does when it is overloaded, degraded or surprised is part of what it must do.
Because the overload response was specified, it could be designed, reasoned about and verified like any other function.
The practice this points to
Write explicit requirements for off-nominal and degraded conditions, including what work the system may shed and what it must protect.
Trace those requirements to verification in the same way as nominal functions, so they are tested deliberately rather than discovered in operation.
Where Kelvora fits
Kelvora is a requirements and assurance platform that treats degraded-mode and off-nominal requirements as first-class requirements, each traced to its verification. It can help teams see where nominal behaviour is specified but the off-nominal case is not.
Sources
- NASA, Apollo 11 Mission Report (1969).