Sicherheit und Zuverlässigkeit der Computersysteme des Space Shuttles

Transkript

1 Sicherheit und Zuverlässigkeit der Computersysteme des Space Shuttles Malte Diehl Department für Informatik Carl-von-Ossietzky-Universität Oldenburg The faulty Solid Rocket Motor joint and seal must be changed. [...] The joints should be fully understood, tested and verified. The Presidential Commission on the Space Shuttle Challenger Accident Abstract Sicherheit und Zuverlässigkeit stehen bei bemannten Flügen ins Weltall ganz oben auf der Anforderungsliste. Dieser Artikel befaßt sich daher mit den Techniken, die eingesetzt wurden, um die US-amerikanischen Space Shuttles so zuverlässig und sicher wie möglich zu machen. Das Augenmerk wird dabei auf Hard- und Software sowie die Überwachung der Raumfähren vom Boden aus gelegt. Schließlich soll untersucht werden, inwieweit die Raumfähren den in sie gesetzten Erwartungen gerecht wurden, auch im Hinblick auf die beiden schweren Unglücke, bei denen Shuttles abgestürzt sind. 1. Einleitung Das 1972 gestartete Space-Shuttle-Programm der NASA (National Aeronautics and Space Administration) ist das wohl bekannteste und eines der wichtigsten Raumfahrtprojekte unserer Zeit. Ziel war es, ein kostengünstiges, flexibles und sicheres System zu entwickeln, um Lasten und Personen in den Weltraum zu transportieren. Besonderes Interesse verdienen die Space Shuttles, weil sie zu den wenigen bemannten Raumfahrzeugen weltweit gehören und die einzigen sind, die nach einer Mission wiederverwendet werden können. Höchste Ansprüche an Sicherheit und Zuverlässigkeit kennzeichnen Entwicklung und Einsatz der Shuttles, da Abstürze nicht nur Geld, sondern auch Menschenleben kosten. Um so interessanter ist es daher, genauer zu betrachten, was getan wurde, um die korrekte Funktionalität der Raumfähren sicherzustellen. Welche möglichen Fehler können auftreten? Welchen Gefahren muß begegnet werden? Welche Vorsichtsmaßnahmen sind sinnvoll und machbar? Wie lassen sie sich mit beschränkten Rechnerleistungen umsetzen? All dies sind Fragen, die die Ingenieure nicht nur bei der Entwicklung, sondern auch bei allen Verbesserungen des Shuttles zu beantworten hatten. Das Ziel dieses Artikels ist nachzuvollziehen, wie sie möglichen Problemen im Bereich der Informatik begegnet sind. Zunächst aber folgt ein kurzer chronologischer Abriß, in dem die Meilensteine des Projektes bis heute dargestellt werden [8, 9, 12]. 5. Januar 1972: Offizieller Start des Space-Shuttle- Programms 17. September 1976: Auslieferung des ersten Shuttles Enterprise für Landungstests Oktober 1977: Beginn der Entwicklung des Primary Flight Software Systems 25. März 1979: Auslieferung des ersten voll funktionsfähigen Shuttles 12. April 1981: Erster Raumflug eines Shuttles 28. Januar 1986: Explosion der Raumfähre Challenger kurz nach dem Start 12. September 1992: 50. Space-Shuttle-Mission 11. Oktober 2000: 100. Space-Shuttle-Mission 1. Februar 2003: Verglühen der Raumfähre Columbia beim Wiedereintritt in die Atmosphäre Frühjar 2005: Wiederaufnahme der Flüge geplant 2. Untersuchung der Computersysteme Bevor wir mit der Analyse beginnen, sollen noch drei Begriffe definiert werden, mit denen wir im folgenden immer wieder zu tun haben [16]:

2 Sicherheit: Abwesenheit von Gefahren für Mensch und Maschine Zuverlässigkeit: Fähigkeit eines Systems, in vorgegebenen Zeiträumen und Einsatzbedingungen eine bestimmte Aufgabe zu erfüllen Fehlertoleranz: Fähigkeit eines Systems, seine Aufgabe trotz einer bestimmten Anzahl von Fehlern zu erfüllen 2.1. Fehler- und Gefahrenanalyse Während die Außenhaut eines Raumschiffs etwa den enormen Hitzebelastungen beim Eintritt in die Atmosphäre gewachsen sein muß, so darf die Bordelektronik nicht durch etwaige Hardware- oder Softwarefehler lahmgelegt und das Space Shuttle somit manövrierunfähig werden. Gerade in kritischen Situationen wie bspw. direkt nach dem Start, wenn noch keine stabile Umlaufbahn eingenommen wurde, entstünde dadurch eine enorme Gefährdung. Die Hardware des Shuttles muß daher eine hohe Fehlertoleranz aufweisen. Die physische Beschädigung oder Zerstörung eines einzelnen Rechners oder einer seiner Komponenten darf keine Auswirkungen auf die Sicherheit der Besatzung haben. Um einem solchen Fall begegnen zu können, müssen wenigstens die für die Steuerung und die Lebenserhaltung nötigen Rechner mehrfach vorhanden sein, und es muß die Möglichkeit geben, nach dem Ausfall eines solchen Rechners die jeweiligen Programme sicher auf irgendeinem anderen auszuführen. Auch stellt sich die Frage, ob einfache Redundanz bei kritischen Systemen ausreicht oder nicht, da während des Fluges keine Reparaturen an der Hardware vorgenommen werden können. Ein weiteres sicherheitskritisches Problem sind fehlerhafte Berechnungen seitens der Hardware. Wenn ein Computer bei korrekten Eingabedaten falsche Ergebnisse liefert, so dürfen diese keinesfalls an die Besatzung weitergeleitet werden. Eine falsche Anzeige des Eintrittswinkels in die Atmosphäre z.b. könnte die Piloten zu fatalen Kurskorrekturen veranlassen. Unabdingbar ist also an dieser Stelle eine Fehlererkennung und -unterdrückung durch die anderen redundant arbeitenden Rechner, am besten aber durch den verursachenden Rechner selbst. Die Anforderungen an die Software beschränken sich im wesentlichen auf völlige Fehlerfreiheit (die aber bei realistischer Betrachtung unmöglich zu erreichen ist). Durch Fehler verursachte falsche Anzeigen auf den Displays im Cockpit könnten ähnlich schlimme Folgen haben wie Rechenfehler der Hardware. Am gefährlichsten sind fehlerhafte Algorithmen, deren Ergebnisse falsche Befehle an die Steuerung des Shuttles auslösen und kaum von internen Testprogrammen erkannt werden können. Unter Umständen könnten unerkannte Fehler gar alle redundanten Rechner gleichzeitig zur Abschaltung zwingen, was den Absturz der Raumfähre bedeuten würde. Eine weitere potentielle Gefahr besteht schließlich darin, daß die Software vor ihrem Einsatz nur unzureichend auf die Hardware abgestimmt wird. Eine andere, oft unterschätze Gefahrenquelle stellt auch das Cockpit dar. Mangelhafte Ergonomie der sogenannten Mensch-Maschine-Schnittstelle kann dazu führen, daß die Piloten z.b. durch völlige Überflutung mit momentan irrelevanten Informationen dazu verleitet werden, wichtigere Daten zu ignorieren, so daß flugkritische Steuerungsbefehle ggf. unterbleiben. In den folgenden Abschnitten werden wir näher betrachten, wie die verantwortlichen NASA-Mitarbeiter an diese und andere Probleme herangingen und sie bewältigten Shuttle-Hardware Grundlegende Informationen Das Rückgrat der Hardware der Raumfähren bilden fünf identische digitale Mehrzweckrechner (engl. general purpose computer, GPC), die jeweils mit den Avioniksystemen kommunizieren und kritische wie auch unkritische Aufgaben erledigen können [8]. Ein GPC wiederum besteht aus einer CPU vom Typ IBM AP und einem Input/Output-Prozessor (IOP). Jeder IOP ist an verschiedene 1-MHz-Busse angeschlossen, über die er mit digitalen und analogen Subsystemen sowie den anderen IOPs kommuniziert (siehe Abbildung 1). Die Busse werden zu Gruppen zusammengefaßt, wobei niemals zwei redundante Subsysteme 2 am selben Bus hängen, damit bei einem Busausfall nie zwei gleiche Subysteme mit ausfallen. Der Grad der Redundanz eines (Sub)systems hängt von seiner Wichtigkeit ab. So kümmern sich insbesondere in kritischen Flugphasen (Start, Landung etc.) vier GPCs um dieselben kritischen Berechnungen, während nur ein GPC für den Rest zuständig ist. Das Subsystem zur Trägheitsmessung ist hingegen nur dreifach vorhanden. Damit wird gewährleistet, daß das Gesamtsystem unter bestimmten Bedingungen auch mehr als einen Ausfall einer Komponente gleichzeitig tolerieren kann. Manche Subsysteme wie z.b. die Handsteuerung weisen auch interne Redundanzen [2] auf, d.h., sie sind mit zusätzlichen Schaltkreisen ausgestattet und erhalten statt einer einzigen Eingabe Daten von allen zu einer redundanten Gruppe zusammengefügten Rechnern und erzeugen unter Verwendung interner Algorithmen eine einzige, fehlerbereinigte Ausgabe. Dieses Vorgehen hat den Vorteil, daß es i.a. nichts ausmacht, wenn ein Computer falsche Daten an 1 Der IBM AP-101 mit 424 KB Hauptspeicher [3] wurde bereits im US- Langstreckenbomber B-52 eingesetzt und befindet sich nach Verbesserungen Anfang der 90er Jahre als AP-101s noch immer im Space Shuttle. 2 Redundante Subsysteme sind z.b. die Radar-Höhenmesser, die Trägheitsmesser oder die Luftdatenmeßgeräte.

3 Abbildung 1. Rechnerarchitektur im Space Shuttle [2, S. 21] solch ein System sendet, da Fehler beseitigt werden. Somit ist die Erkennung und Wiederherstellung ausgefallener Rechner zwar noch immer wichtig, jedoch nicht mehr zeitkritisch. Im übrigen ist das Bussystem so ausgelegt, daß jeder GPC Zugriff auf alle übertragenen (kritischen) Daten hat, womit Berechnungen leicht verglichen und somit auf ihre Korrektheit überprüft werden können. Die Kommunikation zwischen den GPCs erfolgt über fünf Inter-computer channel-busse (ICC), an die keine Subsysteme angeschlossen sind. Neben der Identifikation fehlerhafter Ausgaben auch bedeutsam und vor allem zeitkritisch ist die Synchronisation der Rechner, da die Kontrolle über die Subsysteme auf die GPCs verteilt ist. Diese geschieht teils mittels spezieller Signale, die zwischen den GPCs ausgetauscht werden, teils mittels Synchronisationssoftware Anforderungen an das Redundanzmangement (RM) Für die GPCs ergaben sich seitens der NASA die folgenden fünf Anforderungen an das Redundanzmanagement (vgl. [2]): Ein ausfallender GPC muß mit 96%iger Wahrscheinlichkeit durch Selbsttests erkannt (Hardwareabdeckung) und der Besatzung gemeldet werden, bevor er der redundanten Gruppe zugeordnet wird, damit z.b. die Mission rechtzeitig vor dem Start abgebrochen werden kann. Bei vier redundanten GPCs müssen zwei bei Versagen sofort identifiziert und angezeigt werden. Gleiches gilt - sofern mit angemessenem Ressourcenverbrauch möglich - für den dritten Rechner. Dies bezweckt, daß die Besatzung rechtzeitig Gegenmaßnahmen wie Abschaltung, Neukonfiguration etc. einleiten kann. Ein fehlerhaft arbeitender GPC soll in der Lage sein, automatisch all seine Übertragungen zu unterbinden, sofern die Besatzung diese Option eingeschaltet hat (zwecks automatischer Neukonfiguration). Fehler eines GPCs dürfen nicht dazu führen, daß ein anderer GPC als fehlerhaft erkannt wird, damit sich Fehler nicht fortpflanzen. GPCs, die wegen einer vorübergehenden Fehlfunktion falsche kritische Daten liefern, sollen baldmöglichst rekonfiguriert werden, um Auswirkungen temporärer Fehler gering zu halten. Darüber hinaus kam man zu dem Schluß, daß es nützlich sei (vgl. [2]),

4 eher die Auswirkungen von Hardwarefehlern auf die Ausgabeschnittstellen als die Hardwarefehler an sich zu entdecken, da sich GPCs oder Teile davon im Weltall ohnehin kaum austauschen lassen, durch spezielle, zusätzliche Hardware die Abhängigkeit davon zu minimieren, daß Computer sich selbst als fehlerhaft erkennen, Software zu benutzen, um den Zustand eines GPCs zu beurteilen, indem z.b. von ihr der Vergleich von Outputs (s.o.) durchgeführt wird, Prüfsummen für kritische Outputs zu generieren und zu überwachen, ein Vergleichswort über die ICC-Busse zu übertragen und Fehler in der zusätzlichen RM-Hardware durch Testprogramme, die in jeder CPU ausgeführt werden, aufzuspüren, zumal diese Fehler systemkritisch sind Implementierung des Redundanzmangements Wie wurden diese Anforderungen und Überlegungen nun beim Systemdesign umgesetzt? Prinzipiell muß zwischen zwei Arbeitsmodi unterschieden werden, für die jeweils unterschiedliche Maßnahmen getroffen wurden (vgl. [2]): 1. drei/vier GPCs in der redundanten Gruppe 2. zwei GPCs in der redundanten Gruppe Im ersten Fall werden zwei kooperative Tests durchgeführt, die zusammen vollständige Abdeckung aller möglichen flugkritischen Ausfälle gewährleisten. Einer davon ist ein Timeout-Test, bei dem nach der Synchronisation der GPCs eine bestimmte Zeit darauf gewartet wird, daß die Rechner eine Eingabetransaktion auf ihrem Bus ausführen. Tut ein GPCs dies nicht, wird er als fehlerhaft behandelt. Eine andere Methode sind Tests mittels eines Vergleichsworts. Hierzu wird ein Vergleichswort aus kritischen GPC- Ausgaben gebildet und über die ICC-Leitungen den anderen redundanten Computern übermittelt. Danach werden Vergleichsworte von anderen Rechnern empfangen, gespeichert und eine Zeit gewartet, damit gewährleistet ist, daß alle Rechner die Wörter empfangen. Schließlich werden empfangene Worte mit dem berechneten verglichen. Ein Computer wird als fehlerhaft erkannt, wenn er durch seine Vergleichswörter zwei fehlgeschlagene Vergleiche in Folge ausgelöst hat. Der Input/Output-Prozessor jedes GPCs verfügt über ein 4-Bit-Register. Jedes dieser Bits steht für einen der anderen Computer und wird gesetzt, sobald der zugehörige GPC aus Sicht des urteilenden Rechners fehlerhaft arbeitet. Jedes dieser vier Bits steuert einen Treiber, der in Verbindung steht mit dem IOP des jeweils anderen GPCs sowie mit Anzeigen im Cockpit. Außerdem existieren pro GPC vier Empfänger, die anzeigen, welche der anderen Computer die Entscheidung über den Ausfall eines anderen GPCs akzeptieren oder eben nicht. Bei mindestens zweifacher Akzeptanz erzeugt die sogenannte Voter logic ein Signal, so daß der Besatzung ein kritischer Ausfall angezeigt wird. Um ein solches Problem zu beheben, kann der betroffene Rechner je nach Lage entweder rekonfiguriert, aus der redundanten Gruppe genommen oder von den Failure votes ausgeschlossen werden. Falls nur zwei GPCs redundant arbeiten, werden in bestimmten Abständen Selbstests durchgeführt, und zwar auf drei Arten: Ein Überwachungstimer im Input/Output- Prozessor wird regelmäßig von der CPU geladen und kann Ausfälle, die die Programmausführung durch die CPU betreffen, entdecken. Zusätzlich gibt es mikrocode- und softwarebasierte Selbsttestprogramme (STP), die von der Besatzung ausgeführt werden können, um CPU-Versagen festzustellen. Außerdem existieren fest eingebaute Tests (ET), die aus der Hardware oder dem Mikrocode bestehen, die Interrupts verursachen, sobald CPU-Versagen festgestellt wird. Einen Überblick hierzu verschafft Tabelle 1. Art des Abdeckung Speicher- Rechenzeit Selbsttests der kritischen verbrauch- Hardware (%) (Halbworte) (ms) ET 36,9 0 0 ET+Timer 68,5 4 0,005 ET+Timer+STP 88,7 14 0,15 (nur Mikrocode) ET+Timer+STP 96, ,3 Tabelle 1. Beziehung zwischen Selbsttests, Hardwareabdeckung und Ressourcenverbrauch [2, S. 27] 2.3. Shuttle-Software HAL/S Eine Sprache für den Weltraum Für ein derart komplexes und sicherheitskritisches Projekt wie das Space Shuttle benötigte die NASA eine Programmiersprache, die es erlaubte, echtzeitfähige, robuste und gut zu wartende Programme zu schreiben [1, 10, 8]. Die bisherigen Programme waren entweder schwer verständlich und unhandlich (Assemblersprachen) oder nicht robust genug und zu langsam (Interpretersprachen). Um die NASA-Anforderungen zu erfüllen, wurde die Sprache HAL/S entwickelt, die neben bewährten Kon-

5 strollstrukturen spezielle Echtzeitanweisungen wie WAIT, SCHEDULE und PRIORITY enthielt und leicht verständlich auch für jene Ingenieure war, die bislang keine oder nur wenig Programmiererfahrung hatten. Überdies verzichtete man bei der Implementierung von HAL/S auf bestimmte, fehleranfällige Befehle wie GOTO. Zudem wurde die Durchführung raumfahrttypischer Berechnungen wie etwa Matrix-Arithmetik möglichst einfach gehalten. Das Vertrauen in die neue Sprache war so groß, daß die gesamten Bordprogramme des Shuttles ausschließlich in HAL/S geschrieben wurden. Jedoch wurden ab Mitte der 80er Jahre neue Projekte der NASA in ADA realisiert [1], da sich das US-Militär für diese Sprache entschieden hatte, so daß die Weltraum-Sprache weitgehend in Vergessenheit geriet PASS Das Primary Avionics Software System Das Primary Avionics Software System ist die Flugsteuerungssoftware für die Space Shuttles. Es besteht aus acht getrennt voneinander ausführbaren Modulen (siehe Abbildung 2), die auf einem Speicherband liegen und bei Bedarf von der Besatzung in den Hauptspeicher von GPCs geladen werden können [12]. Sie enthalten jeweils die Funktionen für eine bestimmte Flugphase sowie die Systemüberwachung und teilen sich ein gemeinsames Betriebssystem, das Flight computer operating system (FCOS) [3], welches typische Aufgaben wie das Prozeßmanagement übernimmt. Zudem ist PASS ist der Lage, mit dem Startsystem am Boden sowie über das Network signal processing (NSP) - Interface während des Fluges mit dem Kontrollzentrum in Houston zu kommunizieren. Für die Zuverlässigkeit von PASS ist die Tatsache von Bedeutung, daß das gerade benötigte Modul immer komplett in den Hauptspeicher geladen wird, damit keine Verzögerungen durch Nachladen von Daten oder gar kritische Fehler durch Unauffindbarkeit von Programmteilen entstehen. Gleichzeitig wird damit der Datenverkehr zwischen Hauptspeicher des jeweiligen GPCs und dem Massenspeicher auf das absolut Nötigste reduziert, was freie Kapazitäten schafft. Die wichtigste Anforderung an die Flugsoftware war und ist bis heute Fehlerfreiheit, da Ausfälle während eines Fluges mit unkalkulierbaren Sicherheitsrisiken verbunden sind. Um dies zu gewährleisen, muß PASS in kritischen Flugphasen in mehreren GPCs redundant arbeiten. Wie bereits in Abschnitt erwähnt, sind dazu Synchronisationen der Computer in der redundaten Gruppe unabdingbar. Das FCOS sorgt dafür, daß dies bis zu 330mal in der Sekunde geschieht, und kontrolliert zusätzlich die Eingabedaten, um Fehler auszuschließen. Wie bei sicherheitskritischen Komponenten üblich, wurde bei der Entwicklung der Flugsteuerungssoftware PASS ganz besonderer Wert auf ingenieurmäßiges Vorgehen gelegt, um die Fehleranfälligkeit bereits vor den Tests zu minimieren. Dafür bediente man sich zahlreicher, mitunter neuartiger Techniken, die von vielen damals üblichen Programmiersprachen nur unzureichend oder gar nicht unterstützt wurden wie z.b. Modularisierung, Datenkapselung zwischen den Prozessen, klare Programmstrukturierung, Entwurfsdokumentation und Kommentare im Quellcode. Darüber hinaus gab es abschließende Prüfungen der Übereinstimmung mit diesen Methoden und Abweichungsberichte. Bei der Implementierung der Komponenten wurde eine Top-down-Vorgehensweise gewählt (vgl. [12]. Am Anfang wurden die Strukturen der Kontrollsegmente entworfen, die zusammen mit bereits existierender Software installiert wurden. Die NASA hatte vor Beginn der PASS- Entwicklung bereits Anflug- und Landungstests mit speziell dafür entwickelten Programmen durchgeführt. Programmteile, für die noch keine klaren Anforderungen vorlagen, wurden zunächst als Stümpfe implementiert, damit schon Tests durchgeführt werden konnten, und erst später, nachdem sich die Bedürfnisse herauskristallisiert hatten, ausprogrammiert. Die Anforderungen an die Flugsoftware mußten dabei mehrfach angepaßt werden. Zum einen stellte sich heraus, daß die Ressourcen der Bordcomputer nicht ausreichten, so daß Funktionen wieder gelöscht und Ausführungsraten von Programmen herabgesetzt werden mußten. Zum anderen war die verwendete Hardware zur Software nicht vollständig kompatibel. Vor allem aber war kein Testshuttle verfügbar. Die Softwareentwicklung für den ersten richtigen Flug des Space Shutte dauerte insgesamt 31 Monate und umfaßte insgesamt 17 inkrementelle Releases, wobei bereits nach dem neunten Release im Dezember 1978 alle Funktionen integriert waren. Jedoch bedurfte es acht weiterer Releases, um alle Anforderungen, die sich teilweise immer noch änderten, zu erfüllen. Aus den Erfahrungen mit der Entwicklung von PASS, das ungeahnte Komplexität entwickelt hatte, entstand auch die Forderung nach besseren Möglichkeiten des Software- Engineerings [8], wie sie heute als selbstverständlich gelten BFS - Das Backup Flight System Die Software des Backup Flight System kommt nur in kritischen Flugphasen wie z.b. beim Eintritt in die Atmosphäre aktiv zum Einsatz [4]. Es beansprucht lediglich einen der fünf GPCs für sich und dient als Rückfallebene, wenn es im PASS zu schweren Fehlern kommen sollte. Noch vor dem Start wird das BFS in den Hauptspeicher des ihm zugewiesenen GPCs geladen und dort bis zum Ende des Fluges

6 Abbildung 2. Module der Flugsteuerungssoftware [12, S. 915] gehalten, um ggf. nicht von der Funktionstüchtigkeit der externen Massenspeicher abhängig zu sein. In normalen Flugphasen arbeitet das BFS im Hintergrund und wertet die Datenströme von Computern und Sensoren aus, so daß es stets auf dem neuesten Stand ist und somit zu jeder Zeit in der Lage, die Kontrolle der Raumfähre zu übernehmen. Dies geschieht jedoch nicht automatisch, sondern nur, nachdem von einem der Piloten im Cockpit ein entsprechender Befehl per Knopfdruck erteilt worden ist. Sinn einer Kontrollübernahme durch das BFS ist es vor allem, das PASS währenddessen neu zu starten, um damit weiterarbeiten zu können. Um die Übernahme eventueller Fehler zu vermeiden, wurde die BFS-Software unabhängig von der des PASS entwickelt und programmiert. Gleichwohl ist sie ähnlich wie das PASS zu bedienen, damit so wenig Umstellung wie möglich seitens der Astronauten vonnöten ist Das Testmodell der Shuttle-Software Ein großes Projekt wie die Flugsoftware des Space Shuttles ist erfahrungsgemäß nur mit durchdachten Testverfahren zu realisieren. Schon damals kamen viele Methoden zum Einsatz, die noch heute angewandt werden, wie etwa Coderewievs, formale Verifikationen und Systemtests (vgl. [12]). Sämtliche Ergebnisse wurden dokumentiert und festgehalten. Der Testplan für die Entwicklungsphase des PASS vor seiner Verifikation und Validation gliedert sich in insgesamt fünf inkrementelle Ebenen: Einheitentests (1. Stufe): In dieser Stufe werden vor allem Gleichungen und Algorithmen auf Richtigkeit und Genauigkeit überprüft und ihre Ergebnisse mit den Erwartungen verglichen. Funktionalitätstests (2. Stufe): Im Gegensatz zur ersten Phase werden nun mehrere Einheiten, die miteinander verbunden sind, auf ihre korrekte Zusammenarbeit hin getestet. Subsystemtests (3. Stufe): Hier zeigt sich, ob die Software auch tatsächlich den Anforderungen gerecht wird. Die kleinen Einheiten aus Teststufe 2 werden zu kompletten Subsystemen zusammengefaßt und daraufhin überprüft, inwieweit sie ihre jeweilige Aufgabe (z.b. eine bestimmte Flugbahn zu halten) erfüllen. Systemtests (4. Stufe): In Stufe 4 wird die Zusammenarbeit des gesamten Systems getestet, d.h., Datentransfers, Schnittstellen zwischen den Computern etc. Releasetests (5. Stufe): Die letzte Testphase umfaßt die Erprobung des Systems, das in einen Hardwaremassenspeicher geladen wird, unter möglichst realen Bedingungen in einer Testeinrichtung der Nasa, um sicherzustellen, daß die ausgelieferte Software tatsächlich funktioniert. Weitere Details zum Testmodell in Abbildung Missionsabbruch im Notfall Für den Fall, daß es zu Störungen oder Unfällen kommt, die einen Missionsabbruch erforderlich machen, unterstützt PASS insgesamt fünf verschiedene Abbruchmodi, von denen je nach Zeitpunkt des Unglücks einer gewählt wird. Allerdings ist kein Abbruch möglich, bevor die beiden äußeren Feststoffbooster ausgebrannt sind.[5] Für Fehler direkt nach dem Start ist eine Rückkehr zur Basis vorgesehen. Nach dem Abbrennen und Abwerfen der Booster wird das Shuttle gewendet. Bald darauf wird auch der externe Tank abgeworfen, so daß die Raumfähre im Gleitflug die Landebahn des jeweiligen Raumfahrtzentrums ansteuern kann. Wenn eine Rückkehr nicht mehr möglich ist, das Shuttle aber nicht auf eine sichere Umlaufbahn gelangen kann, ist eine Atlantiküberquerung mit anschließender Landung in Spanien oder Marokko vorgesehen. Im Modus Abort to Orbit wird versucht, das Raumschiff auf eine sichere, niedrige Umlaufbahn zu bringen, wenn es z.b. durch Triebwerksausfall nicht mehr auf die ursprünglich geplante Umlaufbahn kommen kann. Dies ist der einzige Abbruchmodus, der jemals aktiviert wurde, und zwar als sich während des Fluges STS-51F eines der Haupttriebwerke vorzeitig abschaltete.

7 Abbildung 3. Testmodell der Shuttle-Software [12, S. 924] Als vierte Abbruchmöglichkeit (bei Leistungsabfall, Lecks in der Außenhaut etc.) ist eine einmalige Weltumrundung mit anschließender Landung in der Luftwaffenbasis Edwards oder dem Kennedy Space Center vorgesehen. In Notfällen, wenn weder eine stabile Umlaufbahn erreicht werden kann noch eine sichere Landung durchführbar ist, besteht zudem die sehr riskante Möglichkeit einer Notwasserung Überwachung von der Erde aus Das Mission Control Center Seit 1965 überwacht das Mission Control Center der NASA in Houston sämtliche bemannten Raumflüge der US- Amerikaner, so auch die der Shuttle-Flotte. Obwohl die Bordcomputer der Besatzung einen großen Teil der Überwachungsarbeit selbst übernehmen, ist das Kontrollzentrum nicht überflüssig, sondern stellt einen wichtigen Beitrag zur Sicherheit der Missionen dar. Da zwei funktional identische Kontrollräume existieren, ist es möglich, zwei Flüge gleichzeitig zu überwachen. Während einer Mission sitzen in einem dieser Räume etwa 20 bis 30 Flugüberwacher, die ständig durch Daten aus dem Shuttle über den Zustand der Bordsysteme und den Fortgang des Fluges informiert sind und zusammen mit der Besatzung größere Manöver planen oder versuchen, möglichst schnell auf unvorhergesehene Ereignisse zu reagieren. Einige der wichtigsten Kontrolleure sind (jeweils mit amerikanischen Titeln): Der Flight director, der das Team leitet und für den Ausgang der Mission im Ganzen und alle sicherheitskritischen Entscheidungen zuständig ist. Der Space communicator, der als Ansprechparter für die Astronauten dient. Der Data processing systems engineer, der insbesondere die fünf lebenswichtigen GPCs, die Fehler- und Ausfallanzeigen und flugkritische Daten überwacht. Der Guidance, navigation and control systems engineer, von dem alle Kurs-, Navigations- und Kontrollsysteme des Shuttles überwacht werden. Der Instrumentation and communications systems engineer, der alle während des Fluges benutzten Kommunikations-, Televisions- und Instrumentensysteme kontrolliert Die Zuverlässigkeit des Shuttle Ground System (SGS) Das SGS ist die Software, die die Mitarbeiter des Kontrollzentrums in Houston bei der Überwachung und Steue-

8 rung des Space Shuttles unterstützt. Dazu untersucht und verifiziert es jede Aktion der Bordcomputer und führt Analysen durch, die deren Kapazität weit überschreiten würden. Um das SGS zu testen, werden vorwiegend zwei Verfahren angewandt: Verifikationen, um die korrekte Funktionalität von Programmteilen nach Beseitigung von Fehlern oder Hinzufügung von Features zu überprüfen, und Missionssimulationen, in denen komplette Missionen oder Teile davon durchgespielt werden können. Zwar würde das Shuttle, dessen Arbeit von SGS überwacht wird, bei dessen Ausfall nicht sofort abstürzen wie etwa bei einem Totalausfall von PASS und BFS, doch wäre es in seiner Operationsfähigkeit eingeschränkt. Zuverlässigkeit ist daher auch beim SGS oberstes Gebot. Daß das SGS sicher arbeitet, legt Tabelle 4 nahe, die die Summe der in 38 Wochen aufgetretenen Fehler nach Schwere enthält, von denen nur sehr wenige kritisch sind. Allerdings wird im zugrundeliegenden Text [13], einer Zuverlässigkeitsanalyse, nicht genannt, wann genau die Untersuchung durchgeführt wurde und wie die Fehlerklassen definiert sind. Während des Zeitraums dieser Datenerfassung fanden auch die Missionen STS-2 und STS-3 statt, für die das SGS benutzt wurde und die ohne Komplikationen zu Ende gingen. Abbildung 4. Anzahl der aufgetretenen SGS- Fehler nach Kategorie [13, S. 265] 2.6. Verbesserungen der Computersysteme Die Entwicklung der Raumfähren begann 1972, der Erstflug fand 1981 statt. Seitdem sind viele kleine und große Änderungen am System vorgenommen worden. Zwei der wichtigsten werden im folgenden kurz vorgestellt. Gläsernes Cockpit [7]: Zur Jahrtausendwende hielt auch im Cockpit des Space Shuttle Atlantis moderne Digitaltechnik Einzug. Insgesamt 32 Instrumente und elektromechanische Anzeigen sowie vier Röhrenbildschirme konnten durch nur 11 flache Farbbildschirme ersetzt werden. Dadurch werden die Piloten nicht mehr mit sämtlichen Informationen gleichzeitig konfrontiert, sondern nur mit den momentan wichtigen. Auch dies ist ein Beitrag zur Zuverlässigkeit der Shuttles, denn wenn keine Gefahr mehr besteht, daß Piloten durch die Informationsflut zu falschen Entscheidungen angeleitet werden, erhöht sich damit auch die Sicherheit des Raumschiffs vor dem menschlichen Faktor. Als Nebeneffekt reduziert das neue Cockpit das Gesamtgewicht um 34 Kilogramm, so daß auch weniger Energie verbraucht wird. Bis 2002 wurden alle Raumfähren mit den neuen Cockpits ausgestattet, und weitere Verbesserungen sind in Vorbereitung. Global Positioning System (GPS) [6]: Zuverlässige und exakte Positionsbestimmung ist bei Weltraumflügen und - manövern von höchster Wichtigkeit. Bereits Mitte der 70er Jahre wurde ernsthaft in Betracht gezogen, das damals neue Global Positioning System in der Shuttleflotte einzusetzen. Die enormen Kosten und der Aufwand, das System zu integrieren, verhinderten dies aber und ließen die Entwickler auf schon vorhandene Lösungen zurückgreifen. Erst in den 90er Jahren griff man das Thema GPS wieder auf, weil die bisherigen Navigationssysteme veraltet waren und zu Beginn des neuen Jahrtausends ausgemustert werden sollten. Man entschied sich für einen GPS-Empfänger, der bereits für das US-Militär produziert wurde. Ein Hauptvorteil besteht darin, daß er Daten von einem Trägheitsnavigationssystem nutzen kann. Bei der Genauigkeit der Geschwindigkeitsbestimmung werden allerdings die Anforderungen des Mission Control Center verfehlt, die hinsichtlich Manöverplanung und Rendezvous z.b. mit der internationalen Raumstation (ISS) gestellt wurden, so daß GPS nur genutzt wird, während sich das Shuttle auf einer stabilen Umlaufbahn befindet und keine Andockmanöver durchführt. Für die Navigation beim Wiedereintritt in die Atmosphäre wird weiterhin das PASS genutzt, das parallel zu GPS arbeitet. Die Testflüge mit einer Vorversion des GPS-Empfängers begannen im Dezember 1993, und erst im August 2002 wurde der Empfänger nach Einbau und Flügen in den vier Raumfähren endgültig zertifiziert. Inzwischen sind die eingebauten GPS-Geräte, die den technischen Stand Anfang der 90er Jahre repräsentieren, auch überholt und könnten durch bessere Empfänger ersetzt werden, die z.b. auch bei Rendezvous genutzt werden können. Was zur Zeit eingesetzt wird, stellt also keinesfalls das Optimum an Sicherheit und Zuverlässigkeit dar.

9 2.7. Angewandte Konzepte aus der Informatik im Überlick Das Shuttle-Programm wurde vor über 30 Jahren begonnen, so daß heutige Standards in der Informatik noch unbekannt waren oder es keine befriedigenden Möglichkeiten gab, sie umzusetzen. Dies betrifft vor allem den Bereich des Software-Engineering, wo objektorientierte Programmierung oder formale Modellierung z.b. in UML, die heute in den allermeisten Projekten zum Einsatz kommen, damals weit weniger üblich waren, oder aber die Ergonomie der Mensch-Maschine-Schnittstelle (Cockpit), der erst mit dem Einbau des Glas-Cockpits Rechnung getragen wurde. Von den damals bekannten Möglichkeiten wurden aber etliche auch genutzt, wie insbesondere während der Beschreibung von Hard- und Softwarearchitektur der Shuttles deutlich geworden sein sollte (siehe 2.2,2.3). Was an Konzepten angewandt wurde, soll an dieser Stelle kurz zusammengefaßt werden: Hardware: bis zu vierfache Redundanz aller kritischen Systeme zur Überbrückung von Ausfällen Prüfsummen, Failure votes, Timeouts, Selbsttestprogramme zur Erkennung falsch rechnender GPCs; zweifache Überwachung (Shuttle und Kontrollzentrum) Software: Modularisierung, Datenkapselung, klare Programmstrukturierung inkl. ausführliche Dokumentation zur Fehlervermeidung bei der Entwicklung inkrementelles Testmodell, Langzeittests, formale Verifikaton im Anschluß an die Entwicklung spezielle Backup-Software zur Fehlerüberbrückung während des Einsatzes zweifache Überwachung (s.o.) 3. Zuverlässigkeit in der Praxis Wie beurteilt man die Zuverlässigkeit der Space Shuttles? Bei einem derart komplexen System kann man sicherlich nicht von Unzuverlässigkeit sprechen, wenn für wenige Sekunden eine einzelne unkritische Softwarekomponente ausfällt. Es bietet sich vielmehr an, die von der NASA als erfolgreich gewerteten Missionen als Maßstab zu nehmen. Demnach waren die Shuttles in 108 von 113 Einsätzen zuverlässig. Zwei der fünf nicht erfolgreichen Missionen endeten bekanntermaßen mit dem Verlust des Raumfahrzeugs und der Besatzung. Die anderen drei gescheiterten Einsätze waren STS-46, bei dem eine Führungsleine für einen Satelliten klemmte, so daß dieser nicht ausgesetzt werden konnte, sowie STS-2 und STS-83, bei denen Problemen mit den Treibstofftanks auftraten [9]. Insgesamt ergibt sich eine Zuverlässigkeitsquote von 95, 6%. Vergleichen wir diesen Wert mit den insgesamt 17 bemannten Missionen des vorangegangenen Apollo- Programms. Apollo 1 und 13 scheiterten - bei Apollo 1 brach vor dem Start ein Feuer an Bord der Raumkapsel aus und tötete die Besatzung, Apollo 13 mußte nach zahlreichen Systemausfällen zur Erde zurückkehren und notwassern. Die Zuverlässigkeit beträgt bei 15 erfolgreichen Flügen 88, 2%. Bei gleicher Zuverlässigkeit wären von den insgesamt 113 Missionen nur 100 erfolgreich verlaufen. Somit stellt das Space Shuttle in Sachen Zuverlässigkeit und Sicherheit einen Sprung nach vorn da, wenngleich natürlich auch eine Zuverlässigkeit von 95, 6% für die zivile Luftfahrt völlig indiskutabel ist. Im Folgenden wollen wir uns noch mit den beiden tödlich verlaufenen Abstürzen, ihren Ursachen und ihren Konsequenzen beschäftigen. Das erste Unglück - die Explosion der Challenger am 28. Januar ereignete sich nicht etwa wegen eines Computerausfalls, sondern weil eine Dichtung am rechten Feststoffbooster Treibstoff austreten ließ, der sich an den Triebwerksstrahlen entzündete und eine Kettenreaktion auslöste, so die Schlußfolgerung der Untersuchungskommission [14]. Das Bauteil, das den Verlust eines viele Millionen Dollar teuren Raumschiffs verursachte, war also zugleich eines der einfachsten und billigsten. Als Folge dieses Unglücks wurden zahlreiche Veränderungen angemahnt und weitestgehend umgesetzt, um die Sicherheit der Shuttles und der Besatzungen zu gewährleisten. So wird ein neues Design für die Feststoffbooster verlangt, wobei explizit erwähnt wird, daß die NASA alle Scharniere, Dichtungen und Ventile vorher vollständig verstehen (sic!) und testen sollte. Daß eine derartige Selbstverständlichkeit explizit in einem offiziellen Bericht erwähnt wird, wirft kein gutes Licht auf die Arbeit der zuständigen Ingenieure. Ansonsten werden insbesondere die zu geringen Abstände zwischen einzelnen Flügen gerügt und ebenso die Praxis, bei Bedarf Teile von einem Shuttle zu entfernen und sie in ein anderes einzubauen. Das zweite Unglück geschah beim Wiedereintritt der Raumfähre Columbia in die Atmosphäre am 1. Februar Die diesbezüglich eingesetzte Untersuchungskommission [15] ermittelte als Auslöser des Absturzes ein etwa 750g schweres Schaumstoffteil, das vom Außentank abgerissen war und mit über 250 m s gegen die linke Tragfläche des Shuttles prallte. Dadurch wurden einige Kacheln

10 des Hitzeschutzschildes beschädigt, so daß der betroffene Teil der Raumfähre beim Eintritt in die Atmosphäre der extrem großen Reibungshitze ungeschützt ausgesetzt war. Infolge dessen wurde die Struktur der Columbia so stark beschädigt, daß diese auseinanderbrach und verglühte. Hier stellt sich die Frage, ob das Unglück nicht durch eine bessere Videoüberwachung des Fluges hätte verhindert werden können, wie sie auch von der Kommission empfohlen wird. Hätte man den Aufprall des Schaumstoffs 82 Sekunden nach dem Start sofort gesehen, hätte man einen sofortigen Missionsabbruch anordnen können (2.4). Wäre die Beschädigung des Hitzeschildes rechtzeitig erkannt worden, wäre es u.u. möglich gewesen, binnen weniger Tage ein zweites Shuttle hinterherzuschicken, um die Besatzung der Columbia ggf. zu evakuieren. (Wie in ausgeführt, kann das Kontrollzentrum zwei Flüge gleichzeitig überwachen.) Dies alles ist jedoch nicht geschehen - mit den allgemein bekannten Folgen. Unter anderem dürfte dabei die finanzielle Not der NASA eine Rolle gespielt haben, die - wie die Kommission findet [15] - mit sinkendem Budget immer mehr Projekte koordinieren muß (siehe Abbildung 5). Bei beiden Abstürzen fällt also auf, daß nicht hochkomplizierte Bauteile oder das hier vorgestellte Computersystem ihren Dienst versagt haben. Vielmehr waren es einfache, billige Komponenten, nämlich eine Dichtung und ein Stück Schaumstoff. Daß es in bislang 113 Flügen keinen kritischen Hard- oder Softwareausfall gab, der einen Missionsabbruch erforderlich gemacht oder die Besatzung in Gefahr gebracht hätte, läßt auf eine hohe Zuverlässigkeit der Systeme schließen. Hingegen scheint es bei Wartung und Überwachung gravierende Mängel gegeben haben, die inzwischen beseitigt sein sollten. 4. Zusammenfassung Wir haben aus der Sicht eines Informatikers untersucht, wie die für die Space Shuttles verantwortlichen Ingenieure die an Hardware, Software und Ergonomie gestellten Anforderungen bewältigt haben und möglichen Fehlern und Gefahren begegnet sind, um einen Flug mit einer der Raumfähren so sicher wie möglich zu machen. Wir haben gesehen, daß schon während der Entwicklung der Raumfähren, als es noch keine PCs gab, zahlreiche Techniken angewandt wurden, wie sie noch heute in Theorie und Praxis üblich sind. Und die Tatsache, daß noch nie eine Mission aufgrund defekter Rechner oder Programme fehlgeschlagen ist, zeigt, daß die beteiligten Informatiker ihren Beitrag zur Sicherheit der Shuttles erfolgreich geleistet haben. Jedoch scheint es, wie insbesondere die beiden tragischen Abstürze zeigen, an anderen Stellen, die wir aufgrund unseres Schwerpunktes nur am Rande betrachtet haben, erhebliche Defizite gegeben zu haben oder immer noch zu geben. Insgesamt kann man also nicht von einem rundrum sicheren System sprechen, wie es die NASA sich vorgestellt hatte. In finanzieller Hinsicht sind die wiederverwendbaren Raumfähren sogar ein Desaster. Schließlich sind die Kosten pro Flug von ehemals geplanten 10 bis 20 Mio. Dollar auf rund 500 Mio. gestiegen [9], obwohl es auch Ziel der NASA war, ein günstiges System zu entwickeln. Und die Flexibilität ist geringer als ursprünglich vorgegeben, weil nicht zuletzt durch die Unglücke die Wartungsintervalle zwischen den Einsätzen drastisch angestiegen sind. Nur aus wissenschaftlicher Sicht, auch in Anbetracht der vielen geglückten Experiment an Bord der Raumfähren, ist die bisherige Geschichte der Space Shuttles als sehr erfolgreich anzusehen. Literatur [1] James E. Tomayko et al., NASA Contractor Report : Computers in Spaceflight. The NASA Experience, NASA, März [2] J. R. Sklaroff, Redundancy Management Technique for Space Shuttle Computers, IBM Journal of Research and Development, Ausg.: Januar 1976, S. 20ff. [3] Paul Schneck, Architecture of the Space Shuttle Primary Avionics Software System, Communications of the ACM, Vol. 27, Nr. 9, September 1984, S. 926ff. Abbildung 5. Prozentualer Anteil der NASA- Gelder am US-Bundeshaushalt [15] [4] NASA Office of Logic Design 504/contents.htm, NASA SP-504, Space Shuttle Avionics System, aktualisiert: 16. März 2004, zuletzt besucht: 28. November 2004, Kontakt: richard.b.katz@nasa.gov.

11 [5] NSTS Shuttle Reference Manual, NASA, 1988, Kontakt: Jim Dumoulin [6] John L. Goodman, A GPS Receiver Upgrade For The Space Shuttle - Rationale And Considerations, 40th AIAA/ASME/SAE/ASEE Joint Propulsion Conference and Exhibit, Fort Lauderdale, Florida, Juli [7] The 21st Century Space Shuttle, aktualisiert: 4. Juli 2002, zuletzt besucht: 30. Oktober 2004, Kontakt: John Ira Petty (HSFWeb- Ma@ems.jsc.nasa.gov). [8] Alfred Spector und David Gifford, The Space Shuttle Primary Computer System, Communications of the ACM, Vol. 27, Nr. 9, S. 874ff, September [9] Shuttle program, Space Shuttle program - Wikipedia, the free encyclopedia, aktualisiert: 29. Oktober 2004, letzter Besuch: 30. Oktober [10] HAL/S - Wikipedia, the free encyclopedia, aktualisiert: 3. September 2004, letzter Besuch: 30. Oktober [11] Autor unbekannt, STS-107, Report # 21, NASA, 3. Februar [12] William A. Madden und Kyle Y. Rone Design, Development, Integration: Space Shuttle Primary Flight Software System, Communications of the ACM, Vol. 27, Nr. 9, S. 914ff., September [13] P. N. Misra Software Reliability Analysis, IBM Systems Journal, Vol. 22, Nr. 3, [14] The Presidential Commission on the Space Shuttle Challenger Accident Report to the President, Vorsitzender: William P. Rogers, 1986/87. [15] Columbia Accident Investigation Board Report Volumes I - VI, Vorsitzender: Admiral Hal Gehman, letzter Besuch: 27. Januar 2005 Oktober [16] K. Echtle Fehlertoleranzverfahren, Springer Verlag, 1990, Kap. 1.