3 ms·

Astronauts would have been aware of Apollo era automation problems. The most notable the Apollo 11 Rendezvous Radar Switch eating all available CPU and nearly a

Astronauts would have been aware of Apollo era automation problems. The most notable the Apollo 11 Rendezvous Radar Switch eating all available CPU and nearly aborting the mission. There's also a cultural problem here. Many of the early astronauts were test pilots, who came from a "I fly this" culture. Taking away their autonomy was difficult and every screw up that engineers made caused further rifts between the two. Engineers vs astronauts was a common narrative back then.

creshal 11y ago
> The most notable the Apollo 11 Rendezvous Radar Switch eating all available CPU and nearly aborting the mission. Except that it wasn't. The Apollo Guidance Computer had full multitasking, and it was reporting that the rendezvous radar, which the crew had accidentally left on, was trying to eat up CPU and was denied it by the scheduler. The (correct) reaction was ignoring it and letting the scheduler continue booting the radar off the task list.
- paulmd 11y ago
  Actually, leaving the rendezvous radar active was the checklisted procedure. Remember that in the event of an aborted landing they would be needing the rendezvous radar right away to try and find the CSM, so the idea was to have it powered up and locked on. The problem was that the computer that guided the radar antenna controlled the orientation by phase angle. Everything was running on 28V AC, but the computer and the radar mount were on separate AC feeds. The documentation specified that the supplies needed to be frequency-locked, but failed to specify the need for being phase-locked as well. So basically the two systems could be at any phase angle relative to each other. In this case, when they flipped the switch they were really out of phase and the computer was commanding traverses that were entirely out of range. The invalid angle caused the radar antenna to continuously issue interrupts. I'd imagine the system basically works like an open-loop system. That would mask the fault, since usually the radar would just lose some of its field-of-view around the edges but work fine in the center. Or that usually it would just cause the antenna to slew a bit off-target at first before the control loop guided it back, but this time it was so far out of range the antenna wouldn't even accept it. It's probably a good thing they didn't need to abort, because with such a fault I doubt the rendezvous radar would have functioned properly. Even if they knew about the design problem (I don't think they did?) they probably would have a hard time power-cycling it. There is no "off" setting for that switch, only SLEW (on) and AUTO (computer controlled). During an abort I would imagine that AUTO would have the computer keep the radar online, so they would have had to use the DSKY to have the computer turn it off and back on. Who knows what effect that might have on an active abort program. Source (good read): http://arstechnica.com/science/2015/07/no-a-checklist-error-did-not-almost-derail-the-first-moon-landing/2/ http://arstechnica.com/science/2015/07/no-a-checklist-error-... Yes, the executive was a great piece of engineering and definitely saved the mission. Margaret Hamilton was a great systems engineer, and NASA as a whole has a track record of rigorous software engineering practices. As a result, in the last 11 versions of the Shuttle's 420k-line software package they have had a total of 17 bugs. Another good read, "They Write The Right Stuff": http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff
  - EvanAnderson 11y ago
    I was going to say much of the same, but I won't echo you. I just recently watched this really interesting video from London Code Mesh 2015 on the Apollo Guidance Computer where the radar antenna-generated interrupts were discussed (among other interesting bugs). https://www.youtube.com/watch?v=xY45YE7ggng https://www.youtube.com/watch?v=xY45YE7ggng

creshal 11y ago

> The most notable the Apollo 11 Rendezvous Radar Switch eating all available CPU and nearly aborting the mission. Except that it wasn't. The Apollo Guidance Computer had full multitasking, and it was reporting that the rendezvous radar, which the crew had accidentally left on, was trying to eat up CPU and was denied it by the scheduler. The (correct) reaction was ignoring it and letting the scheduler continue booting the radar off the task list.

paulmd 11y ago
Actually, leaving the rendezvous radar active was the checklisted procedure. Remember that in the event of an aborted landing they would be needing the rendezvous radar right away to try and find the CSM, so the idea was to have it powered up and locked on. The problem was that the computer that guided the radar antenna controlled the orientation by phase angle. Everything was running on 28V AC, but the computer and the radar mount were on separate AC feeds. The documentation specified that the supplies needed to be frequency-locked, but failed to specify the need for being phase-locked as well. So basically the two systems could be at any phase angle relative to each other. In this case, when they flipped the switch they were really out of phase and the computer was commanding traverses that were entirely out of range. The invalid angle caused the radar antenna to continuously issue interrupts. I'd imagine the system basically works like an open-loop system. That would mask the fault, since usually the radar would just lose some of its field-of-view around the edges but work fine in the center. Or that usually it would just cause the antenna to slew a bit off-target at first before the control loop guided it back, but this time it was so far out of range the antenna wouldn't even accept it. It's probably a good thing they didn't need to abort, because with such a fault I doubt the rendezvous radar would have functioned properly. Even if they knew about the design problem (I don't think they did?) they probably would have a hard time power-cycling it. There is no "off" setting for that switch, only SLEW (on) and AUTO (computer controlled). During an abort I would imagine that AUTO would have the computer keep the radar online, so they would have had to use the DSKY to have the computer turn it off and back on. Who knows what effect that might have on an active abort program. Source (good read): http://arstechnica.com/science/2015/07/no-a-checklist-error-did-not-almost-derail-the-first-moon-landing/2/ http://arstechnica.com/science/2015/07/no-a-checklist-error-... Yes, the executive was a great piece of engineering and definitely saved the mission. Margaret Hamilton was a great systems engineer, and NASA as a whole has a track record of rigorous software engineering practices. As a result, in the last 11 versions of the Shuttle's 420k-line software package they have had a total of 17 bugs. Another good read, "They Write The Right Stuff": http://www.fastcompany.com/28121/they-write-right-stuff http://www.fastcompany.com/28121/they-write-right-stuff
- EvanAnderson 11y ago
  I was going to say much of the same, but I won't echo you. I just recently watched this really interesting video from London Code Mesh 2015 on the Apollo Guidance Computer where the radar antenna-generated interrupts were discussed (among other interesting bugs). https://www.youtube.com/watch?v=xY45YE7ggng https://www.youtube.com/watch?v=xY45YE7ggng