Comment by rbanffy
3 hours ago
You make it robust by making it simple. Simple to implement, simple to reason about, and simple to debug. They were not only programming an existing computer, they were also more or less defining the computer and this allows some hardware-software co-evolution. In cases like these, the hardware is frozen well before the software is close to ready, so you might need to do some workarounds.
> Handling an expected error condition under normal operation
Nothing in the Apollo program was "normal operation" by any standard. The thing is the alarm elegantly - and correctly - handled a situation that should never have happened in the operation, that only happened because the simulators the procedures were developed against did not accurately account for the workload of having both docking and landing radars on at the same time (IIRC, this was the issue).
This kind of robustness in the face of unexpected misuse is required if you want to qualify your hardware as "man-rated".
That’s the missing bit in the original post; if exactly 7 tasks was intended to ever be possible to run (as in, it logically doesn’t make sense for an 8th to exist), and they tossed in a scheduler anyways, then that’s man-rated thinking.
I had read the setup as the 8th task being user error (you have 20 things to do, I can only run 7 at a time, and it’s an user error to submit the 8th task while the 7 are running)