Hat der 1202-Fehler und der damit verbundene Neustart eine Katastrophe bei der Landung von Apollo 11 verhindert?

Ich stimme Ihrem Kommentar zu: "Es ist nicht klar, wann oder ob diese Situation tatsächlich aufgetreten ist." Durch das Lesen von Klumpps Bericht und dem Buch seines Kollegen Don Eyles, Sunburst and Luminary, glaube ich nicht, dass wir genügend Informationen haben, um zu wissen, ob die Situation bei Apollo 11 existiert haben könnte . Ich denke, wir wissen, dass sie bei Apollo 11 nicht existiert hat, weil das Radar Stromversorgung war nicht in Phase, und Klumpp sagt

Aber wenn die Energieversorgung des Radars in Phase war , konnten in der Warteschlange stehende Befehle, die nur zu einem fernen Zeitpunkt in der Vergangenheit gültig waren, vervollständigt und in umgekehrter Reihenfolge ausgegeben werden, wobei sie vorübergehend die Kontrolle übernahmen, um das LM von seiner normalen Landebahn abzubringen.

(Hervorhebung von mir)

Hier ist Eyles' Darstellung des Problems auf den Seiten 215-16 von S&L.

Als das Jahr 1970 anbrach, P66 Auto fertiggestellt und für die bevorstehende Mission an Bord war, fanden Allan und ich Zeit, das Problem zu überdenken, das die Landung von Apollo 11 so beinahe ruiniert hätte – Entzug von Prozessorzeit, den wir TLOSS nannten –, aber wir haben es in Angriff genommen verschiedene Wege.

Allan ließ den IBM 360 summen, während er Simulationen am Apollo-13-Seil durchführte, um zu sehen, wie es sich unter unterschiedlichen Mengen an TLOSS verhielt. Wir wussten bereits, dass, wenn die TLOSS-Menge genau richtig ist, sich während einer Phase hoher Aktivität unvollständige SERVICER-Jobs in der Executive-Warteschlange ansammeln können. Das Letzte, was der SERVICER bei jedem Durchgang tat, war, Informationen zur Anzeige an DSKY zu senden. Kurz bevor es das tat, gab es Lagebefehle und davor Gasbefehle aus. Was Allan beunruhigte, war, was passieren würde, wenn ein SERVICER-Job abgebrochen würde, bevor der Gas- oder Lagebefehl gesendet wurde. Wenn sich genügend dieser angehaltenen Jobs angesammelt hätten, würde ein Software-Neustart erfolgen, wie es bei Apollo 11 der Fall war, und die angehaltenen Jobs würden verschwinden. Aber was wäre, wenn die Rechenlast nachließ, bevor sie gespült wurden?

Was passieren könnte, fand Allan, war, dass die ausgesetzten Jobs (Allan nannte sie „Lurkers“) wieder zum Leben erweckt werden konnten, ohne zu wissen, dass sie sich im Winterschlaf befanden, und fortfahren, einen Einstellungs- oder Drosselbefehl zu erteilen, der auf einen früheren Zeitpunkt im Jahr anwendbar war Flugbahn . Plötzlich könnte der LM in die falsche Lage manövrieren. Die schlimmsten Fälle traten auf, wenn angehaltene Jobs, die sich während P64 angesammelt hatten, nach dem Übergang zu P66 ausgeführt wurden.

Am 4. März veröffentlichte Allan ein sorgfältig geschriebenes Memo, in dem er „eine Sammlung bekannter Manifestationen von Zeitverlust“ beschrieb. Allan beschrieb acht verschiedene Arten von schlechtem Benehmen, beginnend bei einem TLOSS von etwa 8 Prozent. In einer ungewöhnlichen Vorsichtsmaßnahme unterschrieb Allan das Memo und bat Gerry Levine zu unterschreiben, da er es genehmigt hatte.

(Hervorhebung von mir)

Meine Interpretation ist, dass, damit das Problem auftritt,

1. Die Stromversorgung des Rendezvous-Radars müsste synchron sein
2. Es müsste etwas passieren, das dazu führt, dass die SERVICER-Jobs lange laufen und nicht abgeschlossen werden
3. Was auch immer 2) verursacht hat, musste verschwinden, bevor die Situation schlimm genug wurde, um die Warteschlange zu leeren

Wir wissen, dass bei Apollo 11 1) nicht der Fall war, aber ich weiß nicht, ob wir genügend Informationen haben, um zu wissen, ob 2) passiert ist oder nicht.

Diese Antwort versucht, den Teil über die Phasenverschiebung der Radarstromversorgung zu erklären.

Die Mondlandefähre hatte zwei Computer. Der 1202-Alarm ereignete sich auf dem Lunar Guidance Computer, der viele verschiedene Aufgaben erledigte – tatsächlich war der 1202-Alarm eine Warnung, dass sein Multitasking-System Gefahr lief, (aber noch nicht vollständig) überlastet zu werden.

Es gab auch das Abort Guidance System. Sein Computer und seine Software waren völlig andere Designs als das LGC, das von anderen Auftragnehmern entwickelt wurde. Das AGS hatte nur eine Aufgabe: das LM zurück in den Weltraum zu bringen, wo es vom CSM abgeholt werden konnte. Es konnte nicht durch die zusätzlichen Aufgaben, die das LGC zu erledigen hatte, überlastet werden. Obwohl das AGS nie bei einer tatsächlichen Mission eingesetzt werden musste, wurde es gründlich getestet, und es gibt keinen Grund zu der Annahme, dass es versagen würde.

Apollo-Crews übten, zu erkennen, wann ein Abbruch erforderlich war, und das AGS zu aktivieren. Der ArsTechnica-Artikel, den Sie zitieren, sagt sogar so viel:

Und um es klar zu sagen, ein Abbruch während der Landung war keine Kleinigkeit. Das Verfahren hätte dazu geführt, dass Armstrong die Taste "ABORT STAGE" auf dem Bedienfeld des LM gedrückt hätte, wodurch Sprengbolzen und Guillotinen abgefeuert und die Aufstiegsstufe des LM von seiner Abstiegsstufe getrennt worden wären. Dann würde der Aufstiegsmotor zünden und sein Bestes tun, um dem absteigenden Schiff wieder Geschwindigkeit zu verleihen, und versuchen, es zurück in eine Art stabile Umlaufbahn zu schieben, damit die Besatzung das Kommandomodul finden und sich mit ihm treffen kann. Es war etwas, wofür die Besatzungen trainiert waren – aber es wäre nicht einfach gewesen. Und es hätte das Stigma einer abgebrochenen Mission mit sich gebracht.

Das 1202-Problem beeinträchtigte die Steuerung des Raumfahrzeugs nicht, und deshalb erhielt die Besatzung grünes Licht zur Landung. Sollte es jedoch tatsächlich irgendwie die Steuerung des Raumfahrzeugs beeinträchtigt haben, bestand Armstrongs Training darin, das AGS sofort zu aktivieren. Es wäre also keine Katastrophe passiert , aber die Gelegenheit, auf dem Mond zu landen, wäre verloren gegangen.