Geschichten vom Mondcomputer. Teil 2

Hybride Simulationslaborausrüstung. Das Foto zeigt das SDS 9300-Bedienfeld, das zusammen mit mehreren analogen Computern Simulationen des Befehlsmoduls und des Mondmoduls erarbeitet hat.

Jahre vor Apollo 11, als das Steuerungssystem entwickelt wurde, betrachteten sie die eingebettete Software als etwas, das zuletzt getan werden konnte: „Hal wird es tun“, sagten sie. Tatsächlich taten dies Dutzende von Menschen und Hunderte von Support-Mitarbeitern, aber Hal Laning musste zunächst herausfinden, wie die zahlreichen Softwarefunktionen so organisiert werden konnten, dass sie fast gleichzeitig in Echtzeit auf dem Bordcomputer des Raumfahrzeugs ausgeführt werden konnten, dessen Größe und Geschwindigkeit begrenzt sind .

Die Architektur von Hal vermeidet die Fallstricke eines Betriebssystems, in dem Berechnungen klar zwischen Zeiträumen aufgeteilt werden sollten. Solche Systeme sind ziemlich schwierig zu implementieren, da sich Aufgaben beliebig ändern können. Wenn während des Entwicklungsprozesses Aufgaben hinzugefügt oder geändert werden, ist möglicherweise eine Änderung der Aufgabenplanung erforderlich. Das Schlimmste ist, dass das vorhandene Betriebssystem des Bordcomputers sehr zerbrechlich ist, da es vollständig ausfällt, wenn die Aufgabe mehr Zeit in Anspruch nimmt als zugewiesen.

Stattdessen entwickelte Leining ein System, in dem Programmfunktionen in Form von „Aufgaben“ verteilt werden, die eine beliebige Größe haben können, die zur Ausführung dieser Funktionen erforderlich ist. Jeder Aufgabe wird eine Priorität zugewiesen. Das Betriebssystem führt die Aufgabe immer mit der höchsten Priorität aus. Wenn eine Aufgabe mit niedriger Priorität ausgeführt wird und zu diesem Zeitpunkt eine Aufgabe mit hoher Priorität zugewiesen wird, wird die Aufgabe mit niedriger Priorität angehalten, bis die Aufgabe mit hoher Priorität abgeschlossen ist. Ein solches System gibt uns die Illusion, dass Aufgaben gleichzeitig ausgeführt werden, obwohl in Wirklichkeit Aufgaben natürlich nacheinander ausgeführt werden. Ein solches System ist nicht deterministisch, aber seine Funktionen sind verständlich und können überprüft werden. Es erhöht die Zuverlässigkeit, Sicherheit, Flexibilität bei der Verwendung und insbesondere die einfache Entwicklung.

Executive ( das Echtzeitbetriebssystem AGC und LGC. Ca. Transl. ) Organisierte die Ausführung von Aufgaben so, dass jede Aufgabe ihren Status in Form eines Registersatzes beibehielt und der Status beibehalten wurde, während die Aufgabe mit hoher Priorität ausgeführt wurde. LGC enthält ein Array von acht Sätzen mit jeweils 12 Registern, 15 Bit pro Register. Ein Satz von Registern dieser Größe reicht aus, um viele Aufgaben auszuführen. Aufgaben, die den Interpreter verwenden (eine integrierte Interpretationssprache für Aufgaben, die mit Zahlen mit doppelter Genauigkeit arbeiten. Ca. Transl. ), Um Vektor- und Matrixberechnungen durchzuführen, benötigen jedoch mehr Platz. Für solche Aufgaben wird ein separates Array von 43 Registern zugewiesen. LGC enthält fünf solcher Arrays (Vector Accumulator, VAC).

Bei einem derart begrenzten Satz von Arrays zur Aufrechterhaltung des Aufgabenkontexts sollte das Starten von Aufgaben zur Ausführung sehr sorgfältig durchgeführt werden. Funktionen, die nacheinander ausgeführt werden, wurden zu einer Aufgabe zusammengefasst. Die große Aufgabe von SERVICER war während der gesamten Landephase und anderer Phasen des Fluges bei eingeschaltetem Triebwerk aktiv. Dazu gehörten die Navigation mit Beschleunigungsmessern, Bewegungsgleichungen, die Drosselklappensteuerung des Triebwerks, die Anzeige von Daten zur Position des Schiffes, die Anzeige anderer Daten auf dem Display und jede andere Die Funktion verwendete die Ausgabe der vorherigen.

Die Anzahl der verfügbaren Registerarrays und der VAC begrenzt die Anzahl der Aufgaben, die zur Ausführung in die Warteschlange gestellt werden können, auf acht, von denen bis zu fünf VAC-Arrays verwenden können. Während des normalen Betriebs bleibt die Anzahl der ausgeführten Aufgaben konstant, obwohl Aufgaben, die für eine einzelne Ausführung oder asynchron gestartet werden, Schwankungen der Systemlast verursachen können.

Wenn jedoch die Anzahl der gestarteten Tasks mehr als abgeschlossen ist, erhöht sich die Anzahl der verwendeten Registerarrays und der VAC. Wenn diese Situation ausreichend lange anhält, läuft ihre Anzahl ab und die Anforderung zum Starten der nächsten Aufgabe kann nicht erfüllt werden.

Wir werden ein Jahr zuvor, vor dem Start von Apollo 11, zurückkehren, als wir, die Software-Ingenieure, dachten, wir hätten bereits genug Dinge und sie mussten Software für die Landung auf dem Mond so schreiben, dass sie buchstäblich aus- und wieder eingeschaltet werden konnte ohne den Landevorgang und andere wichtige Manöver zu unterbrechen! Dies wurde als "Neustartschutz" bezeichnet. Zusätzlich zu Stromstörungen können andere Faktoren zum Neustart des Systems führen. Ein Neustart erfolgt, wenn die Hardware glaubt, dass das Programm in einer Endlosschleife abgestürzt ist, oder wenn beim Lesen des ROM ein Paritätsfehler aufgetreten ist, oder aus verschiedenen anderen Gründen.

Der Neustartschutz wurde implementiert, indem „Wegpunkte“ an geeigneten Punkten im Programm registriert wurden, die so angeordnet waren, dass die Rückkehr zum letzten „Wegpunkt“ keinen Fehler verursachte, wie im folgenden Beispiel gezeigt:

NEW_X = X + 1

X = NEW_X

Ohne Registrierung des Wegpunkts führt die zweite Ausführung dieses Codes offensichtlich dazu, dass X erneut inkrementiert wird.

Nach dem Neustart nimmt ein solches Programm seine Arbeit wieder auf. Jede Aufgabe beginnt mit dem zuletzt registrierten Wegpunkt. Wenn sich mehrere Kopien derselben Aufgabe in der Warteschlange befanden, wird nur die letzte fortgesetzt. Einige Aufgaben haben keinen Vitalstatus und sind nicht vor einem Neustart geschützt. Sie verschwinden einfach.

Der Neustartschutz hat sehr gut funktioniert. Auf dem Bedienfeld unseres Hybridsimulators in Cambridge befand sich eine Schaltfläche, die den Neustart von AGC verursachte. Beim Testen von Software haben wir diese Taste manchmal zu zufälligen Zeiten gedrückt, fast in der Hoffnung, dass der Fehler uns zu einem weiteren Fehler führen würde. Jedes Mal, wenn der Schutz vor Neustart ausgelöst wurde, wurde die Arbeit ohne Unterbrechung fortgesetzt.

(Der Hybridsimulator enthielt einen SDS 9300-Digitalcomputer und einen Beckmann-Analogcomputer, einen echten AGC-Computer sowie realistische Cockpitmodelle für die Befehls- und Mondmodule.)



Vorbereitung von Apollo vor dem Start.

Nicht nur Eisen kann einen Neustart verursachen, es kann auch programmgesteuert aufgerufen werden, wenn das Programm einen Punkt erreicht, an dem der Computer nicht wusste, wie das Programm weiter ausgeführt werden soll. Dies geschah beim Übertragen der Steuerung unter dem Tag BAILOUT im Modul Alarme und Abbrüche. Der Anruf wurde von einem Fehlercode begleitet.

Diese Maßnahmen wurden vom Exekutivsystem durchgeführt, wenn die Ressourcen erschöpft waren. Wenn die Aufgabe nicht festgelegt werden kann, weil keine freien Arrays zum Speichern von Registern vorhanden sind, hat Executive BAILOUT mit dem Fehlercode 1202 angerufen. Wenn keine freie VAC vorhanden war, wurde BAILOUT mit dem Code 1201 aufgerufen.

Nicht alle von LGC ausgeführten Funktionen wurden als "Aufgaben" ausgeführt. Zusätzlich zu ihnen gab es Hardware-Interrupts, die jederzeit auftreten konnten (wenn sie nicht ausdrücklich verboten waren) und Funktionen mit hoher Priorität ausführten. Interrupts wurden bestimmten Geräten zugewiesen, einschließlich digitalem Autopilot, Uplink und Downlink ( Sende- und Empfangsgerät) Daten auf dem Funkkanal mit der Erde (ca. übersetzt ) und der Tastatur.

Andere Interrupts können verwendet werden, um Codeteile auszuführen, die zu einem bestimmten Zeitpunkt ausgeführt werden müssen. Solche Funktionen wurden als Aufgaben bezeichnet und in einer Unterroutine namens WAITLIST geplant. "Aufgaben" sollten eine sehr kurze Vorlaufzeit haben.

Während "Aufgaben" für die Ausführung mit einer bestimmten Priorität geplant waren, waren "Aufgaben" für den Start zu einem bestimmten Zeitpunkt geplant. Aufgaben und Aufgaben wurden oft geteilt. Die Aufgabe könnte gestartet werden, um die Sensorwerte zu lesen, die zu einem genau definierten Zeitpunkt gelesen werden sollten, und die Aufgabe könnte wiederum eine Aufgabe mit einer bestimmten Priorität für die Verarbeitung dieser Werte starten.

Als Hal Lane Mitte der 1960er Jahre Executive und Waitlist entwarf, tat er alles von Grund auf neu, ohne sich auf Beispiele zu verlassen. Und seine Prinzipien sind heute wahr. Die Verteilung von Funktionen durch eine begrenzte Anzahl von asynchronen Prozessen unter der Kontrolle einer ausführenden Umgebung mit präventivem Multitasking basierend auf Zeitintervallen und Prioritäten liegt modernen Echtzeit-Computersystemen für Weltraumanwendungen nach wie vor zugrunde.



Montage von Gyroskopen.

* * *

Um die Grundursache der Alarme auf Apollo 11 während des Abstiegs zu verstehen, muss das Approximationsverfahren mit dem Befehlsmodul berücksichtigt werden, das nach dem Aufstieg des Mondmoduls von der Mondoberfläche in die Mondumlaufbahn folgt. So wie wir bei der Landung auf dem Mond ein Landeradar verwenden, um Höhe und Geschwindigkeit relativ zur Mondoberfläche zu messen, müssen für die Annäherung an das Befehlsmodul in der Mondumlaufbahn Entfernung, Geschwindigkeit und Richtung relativ zum zweiten Schiff mithilfe des Anflugradars gemessen werden.

Das Näherungsradar verfügt über mehrere Betriebsarten, die über den Modusschalter eingestellt werden. Diese Modi sind wie folgt: SLEW, AUTO und LGC. Im SLEW- und AUTO-Modus arbeitet das Radar unabhängig von der LGC unter Befehlssteuerung. Diese Betriebsart kann beim Start und Anflug bei einem Ausfall des Hauptnavigationssystems verwendet werden. Im SLEW-Modus wird die Radarantenne manuell geführt, der Rest der Zeit ist sie stationär. Wenn die Antenne auf das Ziel gerichtet ist, können Sie den Modus auf AUTO (Auto Tracking) umschalten und das Ziel verfolgen. Das Näherungsradar misst Entfernung und Geschwindigkeit, und die Drehwinkel der Wellen, um die sich die Antenne dreht, werden auf den Cockpit-Displays und auf den Anzeigen in Form von vertikalen Skalen angezeigt. Außerdem wurden Entfernungs- und Geschwindigkeitsdaten in das Abbruchleitsystem (AGS) eingegeben, einen Computer mit nur 6144 Speicherwörtern, der das PGNS-Hauptsystem duplizierte, wenn er auf dem Mond landete und vom Mond abhob.

(Die Namen der drei Annäherungsradar-Betriebsarten waren für einige Kommentatoren eine Quelle der Verlegenheit. Auf Wunsch der Besatzung wurden die Bezeichnungen nach der Mission LM-1 und vor der Landung der Mission auf dem Mond geändert. Der Modus, den Apollo 11 LGC nannte, hieß früher AUTO Auf Apollo 11 hieß es AUTO, früher MANUAL. Der Name des SLEW-Modus blieb unverändert. Obwohl dies in keiner Weise zum Problem auf Apollo 11 beitrug, hieß die interne LUMINARY-Dokumentation im Abschnitt über den diskreten Kanal 33 zu diesem Zeitpunkt noch re LGC-Benchmark mit eingeschaltetem Näherungsradar von RR AUTO-POWER ON.)

Wenn das PGNS-System funktionierte (wie es tatsächlich war), steuerte die LGC das Radar. In diesem Fall wurde der Näherungsradarmodusschalter auf LGC eingestellt. Die Elektronik der Radarschnittstelle ermöglichte es der Software, Daten über die vom Radar gemessene Entfernung und Geschwindigkeit sowie über die Winkel der Drehwelle der Antenne zu erhalten, aus denen die Richtung zum Ziel ermittelt werden kann. Das LGC-Programm verwendete diese Informationen, um die LGC näher an das Befehlsmodul heranzuführen.

Es stellte sich heraus, dass das Anflugradar auch während des Abstiegs funktionieren kann, und dies geschah während des Abstiegs von Apollo 11. Die Anweisungen der Besatzung erforderten, dass das Radar unmittelbar vor Beginn der P63-Phase eingeschaltet wurde und während des gesamten Landemanövers im SLEW- oder AUTO-Modus bleibt.

Es wurden viele Erklärungen gegeben, warum das Radar so eingestellt wurde, dass es auf dem Mond landet. Zum Beispiel könnten einige Leute in Houston ein ausgefallenes Landeüberwachungsschema in Betracht gezogen haben, indem sie Radardaten mit einem Diagramm der erwarteten Messwerte verglichen haben. Es gibt jedoch eine einfachere Erklärung: Das Radar wurde vor der Landung nur eingeschaltet, um im Falle eines Unfalls während der Unterbrechung warm zu bleiben, und befand sich im AUTO-Modus (wenn sich das Mondmodul in einer Position befand, in der Sie das Befehlsmodul verfolgen können) oder nur in SLEW (zu anderen Zeiten) um unnötige Bewegungen der Antenne zu verhindern.



Abbildung 7. PGNS-, ATCA- und Proximity-Radarschnittstellen

Dieses Problem wurde oft (auch vom Autor früher) einfach als Fehler in der Checkliste zugeschrieben. Dies ist eine ungenaue Formulierung, genauso wie es ungenau ist, ein vorzeitiges Herunterfahren des Monitors zu nennen
Die Delta-V-Engine des Mondmoduls ist ein "Computerfehler", während der Fehler tatsächlich in der Dokumentation enthalten war. Tatsächlich sollte die Position des Apollo 11-Näherungsradarschalters keine Probleme verursacht haben. Von hier aus können Sie jedoch einen weiteren Fehlerfall in der Dokumentation verfolgen.

Jahre zuvor wurde eine Dokumentation über das Interface Control Document (ICD) geschrieben, das die elektrische Schnittstelle zwischen dem PGNS und der ATCA-Elektronik (Attitude and Translation Control Assembly) definiert, die von Grumman Aerospace, dem Hersteller des Landemoduls, geliefert wurde. ICD hat festgelegt, dass die 28-V-Stromversorgungskreise mit einer Frequenz von 800 Hz in zwei Systemen in der Frequenz ausgerichtet sein sollten, es wird jedoch nicht geschrieben, dass sie in Phase synchronisiert werden sollen. Tatsächlich waren die beiden Systeme frequenzausgerichtet mit dem von LGC gesendeten "Frequenzsynchronisations" -Signal. Sie hatten eine konstante Phasenbeziehung. Die Phase zwischen den beiden Spannungen war jedoch eine völlig zufällige Variable, abhängig von dem Moment, zu dem die LGC, die immer nach ACTA mit Strom versorgt wurde, ein Synchronisationssignal zu senden begann. Diese Schnittstellen sind in Abb. 2 dargestellt. 7.

Beim Testen des LM-3-Landemoduls wurde ein Problem mit der 800-Hz-Phase festgestellt, das dokumentiert ist, jedoch nie behoben wurde. Wenn sich der Radarmodusschalter in der Position AUTO oder SLEW befand, wurde der Drehmechanismus des Radars durch ein Signal von 800 Hz von der ATCA angeregt, das mit hoher Wahrscheinlichkeit nicht in Phase mit dem Signal von 800 Hz zusammenfällt, das als Referenz in CDUs verwendet wird, von denen Signale konvertiert werden einen Mechanismus zum Umwandeln in Daten für den Computer und zum Dekrementieren (oder Dekrementieren) der Zähler im Computer, die dem Programm mitteilen, wie die Antenne gedreht wird.

Bei Apollo 11 funktionierten CDUs jedoch anders. Da sie die separat erzeugte Spannung als Referenzsignal verwendeten, zeigten die von der CDU empfangenen Antennenwinkelsensorsignale einen unbekannten Winkel. Der Fehler war am größten, wenn die Phasendifferenz nahe 90 oder 270 Grad lag und Apollo 11 offensichtlich einen dieser interessanten Punkte traf. Als Reaktion darauf begann die CDU, LGC-Zähler mit einer nahezu konstanten Geschwindigkeit zu erhöhen oder zu verringern, etwa 6400 Impulse pro Sekunde für jede der Ecken. Dies geschah jedes Mal, wenn sich der Schalter im SLEW- oder AUTO-Modus befand, unabhängig davon, ob das Näherungsradar eingeschaltet war.

Die CDU-Zähler in LGC wurden durch externe Signale, die im Computer verarbeitet wurden, inkrementiert oder dekrementiert. Dies war zeitaufwändig, in diesem Fall jeweils ein Speicherzyklus von 11,7 µs. Wenn die Zähler mit maximaler Geschwindigkeit erhöht wurden, dauerte dies ungefähr 15% der Gesamtzeit (diese Streuzeit wird als TLOSS bezeichnet). Wir liefern derzeit eine konservative Schätzung der aufgewendeten Zeit von 13%, was mit dem beobachteten Verhalten übereinstimmt.

Nach dem Flug von Apollo 11 führten die Grumman-Ingenieure Tests durch, um das im Flug beobachtete Computerverhalten zu reproduzieren. Sie bestätigten, dass CDUs selbst im schlimmsten Fall keine Impulse mit maximaler Geschwindigkeit senden konnten. Sie kamen zu dem Schluss, dass die maximale Computerlast mit diesen Messgeräten (TLOSS) 13,36% betragen könnte. Während der Simulation wurden ähnliche Fehler wie im Flug reproduziert. Somit ist der angegebene TLOSS-Wert die am besten dokumentierte Schätzung der Apollo 11-Computerlast. [Clint Tillman, „Simulation der RR-CDU-Schnittstelle, wenn sich die RR im FMES / FCI-Labor im SLEW- oder AUTO-Modus (nicht LGC) befindet“, 9. August 1969]

Ich bin dem Experten für das Mondmodul-Leitsystem George Silver für seine geduldige Erklärung der Radarschnittstelle für den Mondmodul-Ansatz zu Dank verpflichtet. Er spielte eine zentrale Rolle in der Apollo 11-Mission. Zum Zeitpunkt des Starts war er am Cape Canaveral und flog dann nach Boston, nach Cambridge, um den Start vom Mond zu überwachen. Er sah den Mond am 20. Juli zu Hause im Fernsehen landen. Er hörte die Geräusche von Alarmen, vermutete, dass etwas die Zeit des Computers in Anspruch nahm, und erinnerte sich an einen Fall, den er beim Testen der LM-3-Systeme gesehen hatte, als das Näherungsradar eine hektische Aktivität der Zähler verursachte. Nach einigen weiteren Analysen durch das Cambridge Mission Monitoring Team kontaktierte Silver schließlich am Morgen des 21. Juli, weniger als eine Stunde vor dem Start vom Mond, die MIT-Vertreter in Houston.



Manuelles Kontrollfragment

* * *

Die Landung auf dem Mond war die intensivste Flugphase. Das Landekontrollsystem musste ein Ziel mit bestimmten Koordinaten erreichen, mit einer bestimmten Geschwindigkeit, Beschleunigung, einem bestimmten Ruckgrad (Grad der Änderung / Beschleunigung). Klumpp nannte die Änderungsrate des "Ruck" ("Ruck") "Snap" (Snap), und die nächsten beiden Ableitungen wurden "Crackle" und "Pop" (Pop) genannt. In der Phase der Sichtbarkeit ( dh als die Oberfläche des Mondes sichtbar war) Bullauge des Schiffes (ca. übersetzt ) Das Programm ermöglichte es der Besatzung, den Landeplatz zu wechseln. Die Drosselklappe wurde kontinuierlich gesteuert. Die Navigation umfasste Messungen mit dem Landeradar. Abb. 8 zeigt ein typisches Lastprofil zwischen der Wahl der Phase P63 und dem Berühren der Mondoberfläche.



Abb. 8: Laden während der Landung (Simulatordaten)

Selbst unter diesen Bedingungen haben wir versucht, unsere Programme schnell genug zu machen, um im Falle eines großen TLOSS genügend Zeit zu haben. Die Hauptbeschränkung war die Zwei-Sekunden-Periode, die in das während der Flugphase verwendete „Durchschnitts-G“ -Programm eingebaut wurde.Dies war der Zeitraum, in dem die READACCS-Aufgabe die Messwerte der Beschleunigungsmesser las und die SERVICER-Aufgabe startete, die diese Werte als Anfangsdaten für eine neue Iteration der Flugbahnberechnungen verwendete, den Motor drosselte, die Position des Schiffes bestimmte und auf dem Display anzeigte. Während der Landung zeigte der Grad der Computerlast lediglich, wie viel Zeit für Aufgaben und Unterbrechungen in jedem Zeitraum von zwei Sekunden aufgewendet wurde.

Während der Bremsphase betrug die Reservezeit mindestens 15%, bis das Landeradar die Oberfläche sah. Nach der Inbetriebnahme des Radars beginnen zusätzliche Berechnungen, die mit der Übertragung von Koordinaten vom Radarreferenzsystem zum Koordinatensystem für die Navigation verbunden sind und den Spielraum um 13% verringern. Wenn die Anzeige beginnt (Verb 16, Substantiv 68), verringert sich der Rand auf 10% oder weniger. Baz Aldrin war scharfsinnig, als er nach dem Signal 1202 sagte: "Es scheint, als wäre er erschienen, als wir 1668 eintraten" [16].

Wenn die Marge 10% beträgt und 13% weggenommen werden, hat LGC nicht genügend Prozessorzeit, um alle erforderlichen Funktionen auszuführen. Aufgrund der Flexibilität des Executive-Designs und anders als bei einer starren Architektur gab es keine Katastrophe.

Tabelle 1. Aufgaben, die bei der Landung auf dem Mond aktiv sind.


In Tabelle 1 sind die Aufgaben aufgeführt, die bei der Landung von Apollo 11 aktiv sind. SERVICER hat die niedrigste Priorität und wird am längsten ausgeführt. Aufgaben mit hoher Priorität können den SERVICER stoppen, haben jedoch eine relativ kurze Vorlaufzeit.

Da SERVICER aufgrund seiner Größe eine niedrige Priorität hatte, fiel es aufgrund mangelnder Rechenzeit aus. Mit einem negativen Zeitrahmen gelang es SERVICER nicht, eine Antwort zu geben, als READACCS, das nach einem Zeitplan gestartet wurde, erneut gestartet und SERVICER erneut gestartet wurde. Da die vorherige Kopie von SERVICER die Berechnung nicht abgeschlossen hat, wurden das Register und die VAC-Arrays nicht freigegeben, und READACCS rief FINDVAC an Executive an, um ein neues Register und ein neues VAC-Array zuzuweisen und SERVICER zu starten. Dieser SERVICER hat den Auftrag auch nicht rechtzeitig beendet. Nach einem kurzen Zyklus solcher Operationen endeten die Register- und VAC-Arrays. Als die folgende Anfrage an Executive kam, wurde BAILOUT mit dem Code 1201 oder 1202 aufgerufen.



Abb. 9: SERVICER-Betrieb ohne und mit TLOSS

Abb.Abbildung 9 zeigt, wie sich SERVICER mit einem starken TLOSS verhält. Abbildung 10 zeigt einen Vergleich der Register und VAC-Sätze während des normalen Betriebs und mit starkem TLOSS, während dessen ein Neustart erfolgt.



Abb.10. Die Auswirkung von TLOSS auf die Ressourcen von Führungskräften und Wartelisten während der Landung auf dem Mond (Simulatordaten beginnen mit der Phase P63 vor dem Empfang von Geschwindigkeitsdaten vom Radar und enden mit der Landung [17].)

Eine interessante Auswirkung dieser Abfolge von Ereignissen während der Phase P63 war, dass sich das Problem von selbst beseitigte. Bei einem Neustart der Software wurde nur die letzte Kopie der SERVICER-Task wiederhergestellt und alle unvollständigen Kopien von SERVICER gelöscht. Darüber hinaus hat er alle Funktionen ausgeführt, die keinen Schutz gegen Neustart bieten, weil sie nicht kritisch sind, einschließlich des DELTAH-Monitors (Verb 16, Substantiv 68). Dies führte dazu, dass die Anzeige nach zwei Alarmen in P63 von „Nomen 68“ auf „Nomen 63“ umschaltete.

Das Neustartschutzsystem wurde ursprünglich aufgrund möglicher Hardwarefehler entwickelt und ermöglichte eine Reduzierung der Rechenlast mit einem großen TLOSS. Das von uns entwickelte Echtzeitsystem erwies sich unter bestimmten Bedingungen als fehlertolerant.

Während der P64-Phase war die Situation anders. Zusätzlich zu den üblichen Bewegungsgleichungen wurde eine zusätzliche Verarbeitung hinzugefügt, die die Möglichkeit beinhaltete, den Landeplatz neu zuzuweisen. Zusätzliche Softwarefunktionen lassen eine Zeitspanne von weniger als 10%. Es traten weiterhin Alarme auf. Innerhalb von 40 Sekunden traten drei Alarme von 1201 und 1202 auf. Jedes Mal wurde die Software neu gestartet, wodurch die Task-Warteschlange gelöscht wurde, die Last jedoch nicht reduziert werden konnte.

Missionszeit 102: 43: 08, in Erwartung des nächsten Alarms, schaltete Armstrong den Autopiloten von AUTO in den ATT HOLD-Modus um, wodurch die Rechenlast geschwächt wurde, und wechselte dann in den halbmanuellen P66-Modus, in dem die Computerlast gering war. Nach 2 Minuten und 20 Sekunden Manövrieren in Phase P66 setzte sich das Mondmodul.