Welche Betriebssysteme wurden im Space Shuttle verwendet?

Ich war ein NASA-Auftragnehmer, der am selben Vertrag arbeitete, aber mit 3 verschiedenen Firmen, und von 1989 bis 1995 GN&C-Code für die Space Shuttles schrieb. Anfangs war es Ford Aerospace, dann Loral, dann Lockheed-Martin. IBM war die meiste Zeit der Prime. Es ist lange her, dass ich so etwas getan habe, also halten Sie das, was ich unten schreibe, nicht für ein Evangelium. Erinnerungen eines Mannes mittleren Alters.

Ich habe heute Morgen etwas Zeit, also werde ich ein paar Gedanken ausspucken ...

Das Shuttle-Betriebssystem ist nicht für allgemeine Zwecke geeignet. Es wurde speziell entwickelt, um mit 1 Programm geladen zu werden, den Befehlszeiger auf 0 zu setzen und dann zu laufen. Ich weiß ehrlich gesagt nicht, wie das funktioniert hat, da wir nie einen der Flugcomputer berührt haben. Ich habe nur Fotos gesehen und kürzlich eines in einer Vitrine in einem Museum gesehen. Als ich dort arbeitete, hatten wir keinen direkten Zugriff auf die Computer. Da es sich bei der Computerhardware um modifizierte IBM 360-basierte Systeme handelt, ist dies die Maschinensprache, die von allen Hauptsystemen verwendet wird. Es gab 5 GPCs – allgemeine Verarbeitungscomputer. Während des Aufstiegs und der Landung lief auf 4 die PASS - Primary Avionics System Software und auf 1 die BFS (Backup Flight Software). Das BFS wurde von einem anderen Auftragnehmer, Rockwell, geschrieben und gewartet. Ich weiß nichts über das BFS, außer dass es nie benutzt wurde. Ich habe Gerüchte gehört, dass dieser Vertrag schließlich gekündigt wurde, weil der PASS von so hoher Qualität war, dass das BFS nicht benötigt wurde. Vielleicht kann jemand von Rockwell antworten?

Die überwiegende Mehrheit der Programmierung für die GPCs wurde in HAL/S geschrieben. Dies ist eine kompilierte Sprache ähnlich PL/1, jedoch mit Matrixberechnungserweiterungen und einem Scheduling-System mit mehreren Prioritäten. Grundsätzlich wurden 254 Threads unterstützt, aber wir haben nur 3 verwendet. HFE, MFE, LFE - Hi, Mid, Low Frequency Executives. Die Priorität war ebenfalls H, M, L. HFE lief bei 25Hz. MFE lief mit 12,5 Hz und Low mit 0,5 Hz. Während einer Anweisung könnte eine höhere Priorität eine niedrigere unterbrechen. Es war wichtig, Zeit zu lassen, damit Aufgaben mit niedrigerer Priorität ausreichend Zeit zum Ausführen hatten. Einige komplexe Führungscodes würden die zugewiesene Zeit überschreiten und mussten stark optimiert werden. Da es sich um Echtzeitsysteme handelte, ist eine verspätete Antwort genauso schlecht wie eine falsche Antwort.

Die PASS-Software lief in einem redundanten Satz mit Unterbrechungspunkten entlang der Codepfade (außerhalb unseres Anwendungscodes verwaltet). In regelmäßigen Abständen gelangte jeder Computer zu einem Prüfpunkt und vergleicht ihn mit den anderen Computern im "redundanten Satz". Grundsätzlich würden sie abstimmen. Mehrheitsregel. Alle Computer außerhalb der Mehrheit würden gelöscht und alle zukünftigen Werte von diesem würden ignoriert. Wenn nur 2 Systeme in der redundanten Menge sind und sie nicht übereinstimmen, wurde der Computer, der zuerst angekommen ist, als korrekt angesehen. Ich glaube nicht, dass sie jemals weniger als 3 GPCs am Laufen hatten. Grundsätzlich wurde nur 1 wegen Unstimmigkeiten im Codepfad gelöscht (1996 und früher). Nach 1996, als ich das NASA-Gebiet verließ, weiß ich nichts mehr.

Aufgrund der schlechten Leistung beim Übergeben von Parametern auf dem Stack haben wir globale Variablen verwendet. Es gab eine strenge Namenskonvention, die besagte, auf welcher Priorität die Variable verwendet werden konnte, zu welchem ​​Subsystem sie gehörte und um welchen Variablentyp es sich handelte (int, skalar, double, bit, hex). Ich glaube, wir waren auf Variablennamen mit 32 Zeichen beschränkt, aber zitieren Sie mich nicht, das war kein Problem. Dynamischer Speicher durfte nicht verwendet werden. Pointer wurden einmal verwendet (in HAL/S als "NAMED"-Variablen bezeichnet) und benötigt, um eine Varianz genehmigen zu lassen. Da viele der Programmierer in Technik (mich eingeschlossen) und nicht in CS ausgebildet waren, wurden Zeiger nicht gut verstanden. Ich habe Zeigerüberläufe ausgenutzt, um auf zusammenhängende Speichervariablen zuzugreifen, die über der vom Compiler für Arrays unterstützten zulässigen Größe lagen. Grundsätzlich, Ich habe mehrere Arrays hintereinander deklariert und einen Zeiger verwendet, um ihren Speicher als 1 Variable zu behandeln. Nichts Besonderes, aber es bedeutete, dass der Compiler den Speicher nicht auf unerwartete Weise optimieren musste. Die Compiler und Linker waren spezifisch für das Shuttle-Programm und nicht fehlersicher. Sie waren jedoch ziemlich hochwertig. Einige unserer Infrastruktur-Jungs führten Compiler-Audits durch, um nach seltsamen Problemen zu suchen. Ein Typ, JY, hatte so viel Erfahrung und Wissen, dass es frustrierend war, ihm Fragen zu stellen. 10 Jahre später wurde ich in meinem Job genau wie er und verstand, dass einfache Fragen nicht immer einfache Antworten bekommen. "Es kommt darauf an" ist eine gültige Antwort, und für die Antwort sind weitere Informationen erforderlich. t Speicher auf unerwartete Weise optimieren. Die Compiler und Linker waren spezifisch für das Shuttle-Programm und nicht fehlersicher. Sie waren jedoch ziemlich hochwertig. Einige unserer Infrastruktur-Jungs führten Compiler-Audits durch, um nach seltsamen Problemen zu suchen. Ein Typ, JY, hatte so viel Erfahrung und Wissen, dass es frustrierend war, ihm Fragen zu stellen. 10 Jahre später wurde ich in meinem Job genau wie er und verstand, dass einfache Fragen nicht immer einfache Antworten bekommen. "Es kommt darauf an" ist eine gültige Antwort, und für die Antwort sind weitere Informationen erforderlich. t Speicher auf unerwartete Weise optimieren. Die Compiler und Linker waren spezifisch für das Shuttle-Programm und nicht fehlersicher. Sie waren jedoch ziemlich hochwertig. Einige unserer Infrastruktur-Jungs führten Compiler-Audits durch, um nach seltsamen Problemen zu suchen. Ein Typ, JY, hatte so viel Erfahrung und Wissen, dass es frustrierend war, ihm Fragen zu stellen. 10 Jahre später wurde ich in meinem Job genau wie er und verstand, dass einfache Fragen nicht immer einfache Antworten bekommen. "Es kommt darauf an" ist eine gültige Antwort, und für die Antwort sind weitere Informationen erforderlich. 10 Jahre später wurde ich in meinem Job genau wie er und verstand, dass einfache Fragen nicht immer einfache Antworten bekommen. "Es kommt darauf an" ist eine gültige Antwort, und für die Antwort sind weitere Informationen erforderlich. 10 Jahre später wurde ich in meinem Job genau wie er und verstand, dass einfache Fragen nicht immer einfache Antworten bekommen. "Es kommt darauf an" ist eine gültige Antwort, und für die Antwort sind weitere Informationen erforderlich.

Das Packen von Bits war üblich, da der Speicher begrenzt war. Ein Großteil meines Codes bestand aus binärer Logik, die auf Bitwerten basierte, um zu entscheiden, welche Berechnung unter den sehr unterschiedlichen möglichen Situationen durchgeführt werden würde.

Im Orbit wurden Programme wie bei den alten MS-DOS-"Overlay"-Methoden überlagert. Ich habe nicht am Vehicle Utility Code, VU, gearbeitet, aber er behandelte die Armsteuerung und andere Dinge außerhalb der Flugsteuerung (HiFE), der Lebenserhaltung (LoFE) und der Führung (MedFE).

Wenn Sie sich für die Menschen interessieren, die die Arbeit machen, haben wir im Laufe der Jahrzehnte einige Artikel über uns geschrieben. Ein Mitarbeiter verließ das Projekt, um für AMD zu arbeiten. Nach einem Jahr kehrte er zurück, weil AMD nach „gut genuger“ Technik suchte, nicht nach perfekter Technik. Seine Geschichte ist in „Fast Company“ – „The Write the Right Stuff“ https://www.fastcompany.com/28121/they-write-right-stuff

Einige andere an Bord verwendete "Sprachen" waren nicht wirklich Sprachen. DFG - Display Format Generator (oder so ähnlich). Es war die Sprache, die die DEUs für die Astronauten antrieb, um den Status zu sehen und die Computer zu verwalten. Es war äußerst rudimentär mit Vergleichsoperationen vom Typ BE (Zweig gleich) und BNE (Zweig ungleich). Kein Label-Springen - es wurden nur Anweisungen verwendet. Grundsätzlich, wenn X wahr ist, springe 15 Anweisungen und fahre fort. Es war sehr einfach, aber schwierig, beim ersten Mal eine korrekte Anzeige zu bekommen. Wir hatten keine interaktiven Möglichkeiten, um die Bildschirmausgabe basierend auf unserem Code anzuzeigen. Musste auf Ausdrucke der Chargentestläufe warten, um die Zeichnungen zu sehen.

Für Anfangswerte der Zehntausende von Parametern gab es zwei verschiedene Vorprozessoren – I-Load und K-Loads. Ich habe nie irgendwelche K-Load-Sachen angerührt. Das I-Load-Zeug spezifizierte Anfangswerte, die entweder an eine Speicherstelle kopiert wurden, oder es wurden Berechnungen basierend auf anderen Eingaben durchgeführt, die dann an eine Speicherstelle kopiert wurden. Diese Orte könnten sich im RAM oder auf einem Bandspeicher befinden, der während größerer "OPS"-Änderungen geladen wurde. OPS 1/6 zum Start. OPS 3 für Landungen. OPS 2/8 für Sachen im Orbit. I-Ladungen sind vor der Mission passiert. Der Vorrang des i-load-Operators war nicht der normale, der weltweit im Mathematikunterricht überall gelehrt und verwendet wurde. PMDAS - Klammern, Multiplikation, Division, Addition und dann Subtraktion. Normalerweise haben Multiplikation oder Division die gleiche Priorität, aber nicht mit dem i-load-Tool. Gleiches gilt für Addition und Subtraktion. Aus diesem Grund habe ich eine Reihe von Fehlern im Code meines Mentors gefunden, als ich dort nur ein paar Monate gearbeitet habe. Ich las das i-load-Handbuch und war neu genug, um NICHTS anzunehmen. Mein Mentor, DC, arbeitete dort seit mindestens 5 Jahren, vielleicht 10. Er war EXTREM schlau. Sie hatten eine formelle Codeüberprüfung, die ich verpasst habe, war nicht vorbereitet. Ein paar Tage später war ich mit der Überprüfung seines Codes fertig und fragte, warum diese Aussagen in Ordnung seien, und verwies auf das I-load-Benutzerhandbuch. Er las es sorgfältig durch und sagte dann, ich hätte eine Reihe von Fehlern gefunden, die alle anderen übersehen hätten. Die formelle Überprüfung bei IBM (wir waren ein Sub für sie) verzögerte sich und er behob die Probleme, überprüfte sie intern erneut und schickte eine neue Überprüfung an IBM. Übrigens war es äußerst selten, Fehler in Code-Reviews zu finden. Alle haben sich sehr bemüht, sich gegenseitig zu helfen. Nach den ersten Monaten der Arbeit in der Gruppe würden die meisten Programmierer selbst bei unseren internen Überprüfungen keine Fehler in ihrem Code finden. Einige von uns würden 1 oder 2 Fehler pro Jahr intern finden. Es war äußerst seltsam, dass IBM-Rezensionen jemals Fehler gefunden haben. Wir haben die statistischen Prozesskontrollmethoden von Deming verwendet, um unsere internen Prozesse nach Bedarf zu optimieren, um alle gefundenen Fehler zu beheben. Als ich das Team verließ, wurde alle zwei Jahre ein Fehler im Code gefunden. Es wurde allgemein angenommen, dass null SEV-1-Bugs in der Software verblieben seien. Jim Orr erstellte etwa 2010 einen Bericht, der zeigte, dass es 1994 über 100 SEV-1-Bugs im Code gab, die später im FSW-Programm gefunden würden. Ein SEV-1-Fehler ist der Verlust von Besatzung/Fahrzeug, glaube ich. Wir haben selbst bei unseren internen Überprüfungen keine Fehler in ihrem Code gefunden. Einige von uns würden 1 oder 2 Fehler pro Jahr intern finden. Es war äußerst seltsam, dass IBM-Rezensionen jemals Fehler gefunden haben. Wir haben die statistischen Prozesskontrollmethoden von Deming verwendet, um unsere internen Prozesse nach Bedarf zu optimieren, um alle gefundenen Fehler zu beheben. Als ich das Team verließ, wurde alle zwei Jahre ein Fehler im Code gefunden. Es wurde allgemein angenommen, dass null SEV-1-Bugs in der Software verblieben seien. Jim Orr erstellte etwa 2010 einen Bericht, der zeigte, dass es 1994 über 100 SEV-1-Bugs im Code gab, die später im FSW-Programm gefunden würden. Ein SEV-1-Fehler ist der Verlust von Besatzung/Fahrzeug, glaube ich. Wir haben selbst bei unseren internen Überprüfungen keine Fehler in ihrem Code gefunden. Einige von uns würden 1 oder 2 Fehler pro Jahr intern finden. Es war äußerst seltsam, dass IBM-Rezensionen jemals Fehler gefunden haben. Wir haben die statistischen Prozesskontrollmethoden von Deming verwendet, um unsere internen Prozesse nach Bedarf zu optimieren, um alle gefundenen Fehler zu beheben. Als ich das Team verließ, wurde alle zwei Jahre ein Fehler im Code gefunden. Es wurde allgemein angenommen, dass null SEV-1-Bugs in der Software verblieben seien. Jim Orr erstellte etwa 2010 einen Bericht, der zeigte, dass es 1994 über 100 SEV-1-Bugs im Code gab, die später im FSW-Programm gefunden würden. Ein SEV-1-Fehler ist der Verlust von Besatzung/Fahrzeug, glaube ich. s statistische Prozesskontrollmethoden, um unsere internen Prozesse nach Bedarf zu optimieren, um gefundene Fehler zu beheben. Als ich das Team verließ, wurde alle zwei Jahre ein Fehler im Code gefunden. Es wurde allgemein angenommen, dass null SEV-1-Bugs in der Software verblieben seien. Jim Orr erstellte etwa 2010 einen Bericht, der zeigte, dass es 1994 über 100 SEV-1-Bugs im Code gab, die später im FSW-Programm gefunden würden. Ein SEV-1-Fehler ist der Verlust von Besatzung/Fahrzeug, glaube ich. s statistische Prozesskontrollmethoden, um unsere internen Prozesse nach Bedarf zu optimieren, um gefundene Fehler zu beheben. Als ich das Team verließ, wurde alle zwei Jahre ein Fehler im Code gefunden. Es wurde allgemein angenommen, dass null SEV-1-Bugs in der Software verblieben seien. Jim Orr erstellte etwa 2010 einen Bericht, der zeigte, dass es 1994 über 100 SEV-1-Bugs im Code gab, die später im FSW-Programm gefunden würden. Ein SEV-1-Fehler ist der Verlust von Besatzung/Fahrzeug, glaube ich.http://www.slideshare.net/JamesOrr4/space-shuttle-flight-software-pass-loss-of-crew-errors-jk-orr-20150827-52150515

Wir haben MVS-basierte Mainframes vor Ort verwendet, um die gesamte Software zu erstellen, auf der TSO/ISPF ausgeführt wird. Die Versionskontrolle wurde von einer IMS-Datenbank verwaltet. JCL wurde verwendet, um Kompilier-, Link-, Test- und Druckaufgaben an das System zu senden. Wir hatten eine Reihe verschiedener Tools, um den Code zu recherchieren - im Grunde genommen wurden verschiedene Menüs, die in ISPF-Makrosprachen oder REXX (nachdem ich weitergegangen war) geschrieben, verwendet, um die verschiedenen Codebasen zu durchsuchen. Jeder Flug hatte einen anderen Code, aber die meisten basierten auf Operational Increments, OIs. Ich habe an OI8D-OI24 gearbeitet und ein wenig an OI25 geplant. Mein Lieblingstool hieß HALSTAT. Es lieferte Berichte über alle Variablen, die in einem Modul (einer Datei) im gesamten restlichen Code verwendet wurden. Referenzen, Aufgaben und beide hatten unterschiedliche Codes. Ich glaube, die Codes waren 2, 4 bzw. 6. Seitdem vermisse ich HALSTAT in all meinen Codierungen,

Einige Systeme, an denen ich in diesen Jahren gearbeitet habe, waren:

• Neugestaltung der Bugradlenkung (JP und JV)
• 2-Engine Out Abort (Erinnern Sie sich nicht an das gesamte Team)
• 3-Engine Out Abort (SM, JP, LP waren primär, aber JEDER hat geholfen).
• Mir Docking (BW und PD)
• Drag Chute Deployment (PD primär)
• Hauptverbesserungen bei der Landung – im Grunde platzten die Reifen, daher waren sanftere Landungen erforderlich. Wenn Sie sich die Landungen nach 1992 ansehen, sind sie dank dieses Codes alle SEHR, SEHR, glatt.

Nur um das klarzustellen, ich habe in meiner Zeit dort 1 DR eingeführt (1 Fehler, der alle internen und IBM-Reviews bestanden hat) – zu den Verbesserungen des Main Gear Landing. Es wurde etwa ein Jahr später in Level 6/7-Tests entdeckt. In meinem ersten Jahr hatte ich viele Fehler, die von meinen Kollegen intern gefunden wurden. Nach 1 wirklich schlechten Bewertung mit etwa 10 Fehlern fragte mein Chef, ob ich mit der Arbeit zufrieden sei. Ich hatte die Anforderungen aufgrund einiger Einrückungen anders gelesen als alle anderen. Wirklich war es 1 Fehler, aber ich war konsequent. Im Code waren es jedoch ungefähr 10 Fehler. Es macht demütig, wenn andere deine Fehler bemerken. Wir waren sehr enge Mitglieder desselben Teams. Unsere Unterschriften auf den Bewertungsbögen bedeuteten etwas Wichtiges. Wir haben nie vergessen, dass Leben und Nationalstolz auf dem Spiel standen.

Es gab viele, viele andere Projekte und Korrekturen.

Ich vermisse das Tragen von Krawatten nicht. ;) Ich vermisse die meistens 8-5 Stunden.

Auch die Missionskontrollsoftware und die Nutzlast-Operationszentren auf der ganzen Welt sind völlig unterschiedlich. Arbeitete in dem Team, das die Kontrollzentren der Apollo-Ära durch Star Trek NG-ähnliche Systeme ersetzte, auf denen hauptsächlich DEC Alpha-Systeme mit einigen SunOS-, HP-UX-, AIX- und Irix-Systemen in den Hinterzimmern liefen. Als Referenz gab es etwa 600 Alphas und weniger als 20 andere Systeme. Als wir sie installierten, liefen sie mit OSF/1, einer Unix-Variante, aber dieser Name änderte sich in Digital Unix ... das war, bevor Compaq DEC kaufte. Ich habe die MSFC vor ein paar Jahren besucht und ihren POC für die Unterstützung der Raumstation gesehen. Konnte nicht sehen, welches Betriebssystem ausgeführt wurde, und der Reiseleiter wusste es nicht. Die Konsolenmöbel waren alle anders als die, die wir Anfang bis Mitte der 1990er Jahre eingesetzt haben.

Ich kenne keine Möglichkeit, die PASS HAL/S-Software auszuführen oder die Hardware heute (im Jahr 2017) zu verwenden. Das Betriebssystem ist nicht interaktiv. Es kommuniziert nur mit spezieller Hardware, die niemand zu Hause haben oder bekommen kann. Ohne ein DEU und ein Flugschlüssel-Eingabesystem, Steuerknüppel und Hunderte von Avionikschaltern/-knöpfen sehe ich nicht, wie ich diese Software nutzbar machen soll. Jemand müsste für all das eine Emulationsschicht erstellen. Angenommen, es wäre machbar.

Bitte denken Sie daran, dass mein gesamtes direktes Wissen Mitte der 1990er Jahre endete. Dinge wurden wahrscheinlich später im Programm aktualisiert, was viele Dinge hätte ändern können. Zum Beispiel denke ich, dass die DEUs irgendwie durch LCD-Bildschirme ersetzt wurden. Jegliche Codeänderungen, die dies unterstützen, wenn sie nicht nur eine Emulationsschicht für DEUs einfügen, sind mir unbekannt.

In den 1990er Jahren fand ich einen IBM 360/370 ASM-Emulator für Intel-CPUs. Zu der Zeit war es nicht einmal gut genug, um meine IBM 360 ASM-Hausaufgaben auf Anfängerniveau auszuführen. Es ist schwer zu erklären, wie komplex die Softwareentwicklung war. Alles wurde aus dem MVS-System für die AP101/s-Rechner crosskompiliert und vernetzt.

Ich habe heute die öffentlichen NASA-Codearchive durchgesehen und bei einer Suche keinen "Shuttle" -bezogenen Code gefunden. Würde gerne sehen, wie sich GPE (ein Modulname) im Laufe der Jahre geändert hat.

Lesen Sie an anderer Stelle, dass der frühe HAL-Sprachführer verfügbar war, aber die HAL/S-Sprache ist anders. Ich kann mich zum Beispiel nicht erinnern, in HAL/S eine Möglichkeit gesehen zu haben, irgendetwas zu "drucken" - das bedeutet nicht, dass die Anweisung entfernt wurde, aber es gab kein Gerät zum "Drucken". Eingaben kamen von HW-Geräten und wurden in Variablen gespeichert. Ausgänge wurden auf HW-Geräte geschrieben. Als ich dazu kam, war das ganze E/A-Zeug schon lange geschrieben und funktionierte, also musste ich nie lernen, wie es tatsächlich passiert ist.

Außerdem kenne ich mich nicht mit bestimmten Missionen aus. Meine tägliche Arbeit war weit entfernt von aktuellen Einsätzen. Wir haben während des Arbeitstages nicht angehalten, um Starts / Landungen zu beobachten. Unser Code wurde im Allgemeinen ein oder zwei Jahre vor jeder Missionsverwendung geschrieben. Ich vermute, dass IBM alle engeren Per-Mission-Code-Änderungen vorgenommen hat. Um 1995/96 wurde die IBM-Gruppe an Loral verkauft und diese beiden Gruppen wurden zu einem einzigen Team zusammengeführt. Einige Leute wechselten innerhalb von IBM, aber andere liebten die Arbeit und blieben.

Eine grundlegende HAL-Sprache würde wahrscheinlich mit einer Übersetzungsschicht in fast jeder der heute gängigen Sprachen geschrieben werden. Perl, Python, Ruby, Java, C++ könnten damit umgehen. Zumindest für einfache 1-Modul-Programme. Vielleicht ähnlich wie C++ als C-Präprozessor begann.

Das Erstellen einer Übersetzungsschicht, die die gesamte Interrupt-fähige Shuttle-Software mit mehreren Prioritäten handhaben könnte, wäre ein völlig anderes, riesiges Projekt.

Entschuldigung, dass ich vom Thema abgekommen bin. Hoffentlich findet das jemand etwas interessant.

Für die Flugsteuerungscomputer, auch bekannt als General Purpose Computers (GPCs), gibt es eine gute Beschreibung zu diesem Thema im immer nützlichen Shuttle Crew Operations Manual , Seite 2.6-20.

DPS steht in diesem Zitat für Data Processing System

DPS-Software wird in zwei Hauptgruppen unterteilt, Systemsoftware und Anwendungssoftware. Die beiden Gruppen werden zu einer Speicherkonfiguration für eine bestimmte Missionsphase zusammengefasst. Die Programme sind in HAL/S (High-Order Assembly Language/Shuttle) geschrieben, das speziell für Echtzeit-Raumfluganwendungen entwickelt wurde .

Systemsoftware ist die GPC-Betriebssystemsoftware, die die Schnittstellen zwischen den Computern und dem Rest des DPS steuert. Es wird bei der ersten Initialisierung in den Computer geladen. Es befindet sich immer im GPC-Hauptspeicher und ist allen Speicherkonfigurationen gemeinsam. Die Systemsoftware steuert die GPC-Eingabe und -Ausgabe, lädt neue Speicherkonfigurationen, hält die Zeit, überwacht Diskrete in die GPCs und führt viele andere DPS-Betriebsfunktionen aus. Die Systemsoftware besteht aus drei Programmsätzen. Das Flight Computer Operating System (FCOS) (die Exekutive) steuert die Prozessoren, überwacht wichtige Systemparameter, weist Computerressourcen zu, sorgt für geordnete Programmunterbrechungen für Aktivitäten mit höherer Priorität und aktualisiert den Computerspeicher. Die Programme der BenutzeroberflächeAnweisungen zur Bearbeitung von Befehlen oder Anfragen der Flugbesatzung erteilen. Das Systemsteuerprogramm initialisiert jeden GPC und sorgt für einen Multi-GPC-Betrieb während flugkritischer Phasen.

Eine der Systemsoftwarefunktionen besteht darin, die GPC-Eingabe- und -Ausgabeoperationen zu verwalten, was das Zuweisen von Computern als Kommandanten und Zuhörer auf den Datenbussen und das Ausführen der Logik umfasst, die beim Senden von Befehlen an diese Datenbusse mit spezifizierten Raten und auf Anfrage von der involviert ist Anwendungssoftware.

Die Anwendungssoftware führt die zum Fliegen und Betreiben des Fahrzeugs erforderlichen Funktionen aus. Um Hauptspeicher zu sparen, ist die Anwendungssoftware in drei Hauptfunktionen unterteilt: Führung, Navigation und Steuerung (GNC), Systemverwaltung (SM) und Nutzlast (PL).

(Den letzten Satz habe ich im letzten Absatz zusammengefasst, es ist kein direktes Zitat. Auch die Fettschrift stammt von mir.)

Lesen Sie den Fragentitel " im Space Shuttle verwendet " noch einmal, können Sie eine andere Antwort für die Astronauten-Laptops Mitte der 1990er Jahre hinzufügen.

Die Astronauten-Laptops waren IBM-Thinkpads (es war 1996), kannte Thinkpad-Modelle nie. Sie liefen mit einer Art Windows, definitiv NICHT mit win95, das zu dieser Zeit für den Fluggebrauch zu neu war. Könnte Windows für Workgroups 3.12 oder NT gewesen sein. Nicht sicher. Nichts wirklich Seltsames an dem Betriebssystem, soweit ich mich erinnere. Die Laptops hatten zusätzliche Batterien, die unter dem normalen Laptop angebracht waren.

War Teil eines Teams, das ein Dokumentenverwaltungssystem, Hyperman, für alle Flugkontrollräume und Computer der Nutzlast-Operationszentren sowie Laptops für Shuttles und Raumstationen schrieb.

Es wurde zum Start in C++ für SunOS, Solaris, HP-UX, AIX, Irix, OSF/1 geschrieben, der Code wurde aber auch auf Windows und MacOS portiert.

Borland C++ wurde verwendet, um den Code für Windows mithilfe der win32s-Bibliotheken zu kompilieren, so wie es jeder andere Windows-Programmierer der damaligen Zeit für diese Plattform tun würde, wenn er 32-Bit-Software wollte. Erinnern Sie sich nicht an die verwendete Version. Also, wenn Sie das lernen möchten, lernen Sie einfach die Windows-Programmierung. Borlands alter Compiler ist heutzutage ein kostenloser Download.

Hyperman wurde unter Verwendung kommerziell erhältlicher plattformübergreifender Bibliotheken, Faircom C-Tree und Visix Galaxy , erstellt . Wir hatten eine Forderung nach einer lizenzgebührenfreien Verteilung im gesamten Sonnensystem. ;) Galaxy war ein tolles Tool - wahnsinnig toll, aber sehr teuer. Scheint jetzt etwa 10x günstiger zu sein.

Ich weiß nicht, was mit Hyperman passiert ist. Denken Sie, die NASA hat die Verwendung eingestellt, nachdem die Fluglotsen eine Papierdokumentation in den FCRs und POCs gefordert hatten.

Während diese Antwort mehrere Probleme anspricht, möchte ich einen dort angesprochenen Punkt klarstellen:

Eine grundlegende HAL-Sprache würde wahrscheinlich mit einer Übersetzungsschicht in fast jeder der heute gängigen Sprachen geschrieben werden. Perl, Python, Ruby, Java, C++ könnten damit umgehen. Zumindest für einfache 1-Modul-Programme. Vielleicht ähnlich wie C++ als C-Präprozessor begann."

Dies scheint nicht der Fall zu sein. Die Software des Mars-Rover (MER) ist in C (2000) geschrieben.

Laut Glenn E. Reeves, MER Flight Software Architect bei JPL/CalTech:

Die Flugsoftware ist hauptsächlich in ANSI C codiert, mit etwas gezieltem Assemblercode und etwas C++. Die Größe des Systems in Quellcodezeilen (SLOC) beträgt [300 KB], aber dieser Wert enthält nicht das Betriebssystem.

Obwohl viele Aspekte des Designs objektorientiert sind, werden die Merkmale der Sprache, die Vererbung und Polymorphie beinhalten, nicht ausgenutzt. Wir haben festgestellt, dass diese Konstrukte, wenn sie vollständig in C++ implementiert werden, zu einer nachteiligen Codegröße führen und das Potenzial für nicht deterministisches Verhalten hinzufügen.

Ich suche gerade nach der Originalquelle dafür ...

Ich bin nicht SE-erfahren genug, um einen Kommentar hinzuzufügen, aber diese erste Antwort war sehr gründlich, aber wie jemand darauf hingewiesen hat, war das BFS bis zum Ende im Shuttle. Es gab mindestens 2 Gründe für das BFS. Sie haben einen angedeutet, aber soweit ich weiß, die falsche Antwort gegeben. Wenn der PASS nur noch aus 2 Saiten besteht, fällt es ihnen schwer, abzustimmen. First-in war nicht die Antwort, das BFS-Engagement war die eigentliche Antwort des NASA-Verfahrens. Der andere Grund war in gewisser Weise ähnlich. Wenn der PASS einen generischen SW-Bug hätte, der zwangsläufig alle 4 Boxen betreffen würde, würde das BFS eingeschaltet werden. (Wir hatten den Luxus, tatsächlich mit dem GPC zu arbeiten. Wir hatten eine Laborprozedur, um uns mit einem neuen Build zu laden und zum Laufen zu bringen, als wir in die HW/SW- und Volllast-Anforderungstests gingen.) Ich muss zugeben, dass wir, Rockwell, einen Fehler gemacht haben bis zu unserer ersten Lieferung der verbesserten NW-Steuerung an die NASA, wo wir eine vollständig dokumentierte Funktion der IO-SW hatten, die den HW-NW-Steuerungsbefehl von 2 verschiedenen Anwendungs-SW-Standorten schrieb, von denen einer einen Wert von 0,0 hatte. Aufgrund dieser Art von Fehler konnten wir ihn in unseren Tests, bei denen es sich um eine Anwendung von SW zu SW handelte, nicht finden. Die NASA sah es natürlich sofort, als der NW auf einen korrekten Wert befohlen wurde und dann mit einer niedrigeren Verarbeitungsrate auf Null umgeschaltet wurde.

Es scheint, dass keine der anderen Antworten dies erwähnt, aber es gab ein Space Shuttle Cockpit Avionics Upgrade-Projekt in ~ 2004, von dem ein Teil eine Auswahl eines neuen Betriebssystems für das Space Shuttle war.

Der Entscheidungsprozess war an und für sich schon faszinierend, da Bayes'sche Netze verwendet wurden , um das beste System auszuwählen, Sie können die Details in diesem Dokument sehen .

Das gewählte System war VxWorks von Wind River Systems , dicht gefolgt von Integrity von Green Hills Software . Trotz aller potenziellen Vorteile wurde das Projekt schließlich abgebrochen und eine Fallstudie von der NASA veröffentlicht.