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.

Source: https://habr.com/ru/post/de471330/


All Articles