| Home | Raumfahrt | Trägeraketen | Space Shuttle | Site Map | |
Als 1972 die Entscheidung für die Entwicklung des Space Shuttles fiel, erhielt der Bordrechner eine missionskritische Aufgabe. Die NASA hatte Computer schon bei den Gemini, Apollo und Skylab Missionen eingesetzt. Bei allen diesen Missionen war der Bordcomputer wichtig für die Mission, aber er war nicht missionskritisch. Sprich: Wenn der Bordrechner von Apollo ausgefallen wäre, so hätte man vielleicht die Mondlandung abbrechen müssen, aber die Besatzung hätte mit Unterstützung der Missionskontrolle noch zur Erde zurückkehren können.
Beim Space Shuttle war dem nicht so. Sowohl während des Starts war der Rechner verantwortlich die Triebwerke zu steuern. Nur er konnte schnell genug reagieren um eine Störung der Triebwerkssteuerung eines SRB auszugleichen. Beim Wiedereintritt hielt er das Shuttle in der idealen Wiedereintrittsposition, auch wenn Störungen es drehen, aufrichten etc. wollten und nur er konnte das Shuttle zu einem Punkt vor der Landebahn bringen in der die Besatzung im Unterschallbereich dann den Orbiter landen konnte.
1972 wurde die Entwicklung des Space Shuttles beschlossen. Die ersten zwei Jahre wurde das Design verfeinert und es gab zahlreiche Änderungen. Danach erfolgten die Entwicklungsaufträge für die einzelnen Systeme. Der Bordcomputer wurde 1973 selektiert und die Entwicklung begann 1974. Der Bordrechner hatte nun eine neue Rolle bekommen. Apollo hatte als Ansatz möglichst viel in Hardware zu verwirklichen und für die Anforderungen einen spezialisierten Rechner zu bauen. Es zeigte aber auch die Grenzen dieses Ansatzes. Er konnte genau das was er sollte, nicht mehr und nicht weniger. Für den Space Shuttle der als Fluggerät viel komplexer ist und der zudem sehr universell einsetzbar sein sollte kam dies nicht in Frage. Man versuchte beim Bordcomputer viel mehr über die Software zu lösen und kommerziell verfügbare Geräte einzusetzen. Der Computer bekam eine neue Rolle beim Space Shuttle. Bisher war der Computer in den Raumfahrzeugen eine Hilfe bei der Steuerung. Wäre er ausgefallen so hätten die Astronauten mit Hilfe der Bodenkontrolle ihr Raumschiff auch ohne ihn fliegen können. Beim Shuttle ist dies nicht möglich. Der Space Shuttle ist als Flugzeug inhärent instabil. Ohne Computersteuerung ist keine Landung möglich. Das Space Shuttle könnte auch ohne de Besatzung starten und landen, wie dies Buran tat - zumindest was die Computersteuerung angeht. Allerdings muss eine Person das Fahrwerk ausführen, da es hier keine direkte Steuerung durch den Computer gibt. Nach dem Verlust der Columbia wurde auch diese letzte Schranke beseitigt. Die einzige Phase wo die Besatzung tatsächlich das Shuttle steuert sind die letzten Minuten vor der Landung wenn es in den aerodynamischen Gleitflug übergeht. Da das Shuttle schon von Anfang an mit Geräten zum Empfang de zivilen Landesystems, das Verkehrsflugzeuge bei Nebel oder schlechtem Wetter auf einem Gleitpfad zur Landeposition führt, hätte er auch unbemannt landen können (Buran tat dies).
Die Abkehr von dem missionsspezifischen Rechner die bei Gemini eingesetzt wurden, gab es schon bei Skylab. In Skylab war der Bordcomputer vor allem für die Ausrichtung des Labors zuständig. Es wurde aber keine besondere Hardware dafür entwickelt, sondern ein Derivat des IBM 360 oder 4Pi Systems von IBM. Die Flexibilität erhielt der Rechner durch die Programmierung. In der Endphase der Mission von Skylab bewährte sich dies, als der Bordrechner eine neues Software erhielt, mit der er besser auf die einwirkenden Kräfte durch die dichter werdende Atmosphäre reagieren konnte. Er erhielt auch ein Notfallprogramm, das die Station zum Taumeln bringen konnte, wenn man sie verglühen lassen wollte. In dieser Raumstation bewährte sich erstmals ein Rechner der seine Flexibilität nicht durch die Hardwareverdrahtung bekam und der erstmals neu programmiert werden konnte. Der Apollo Rechner war dagegen mit einem festen ROM ausgestattet und steuerte die Hardware direkt an. Er war eher mit einem Microcontroller als mit einem Bordrechner zu vergleichen.
Die Erfahrungen bei Skylab wurden im Shuttle verarbeitet. Der Rechner erhielt nun auch einen Namen, der seinen Einsatzzweck klar machte: GPC General Purpose Computer. Doch zuerst musste ein geeignetes Modell und eine geeignete Architektur gefunden werden. Als der GPC selektiert wurde, waren Mikroprozessoren gerade einmal zwei Jahre alt. Intel hatte den 4004, den ersten 4-Bit Mikroprozessor und den 8008, einen einfachen 8-Bit Mikroprozessor herausgebracht. Heute erscheint es schwer vorstellbar, dass die NASA sich nicht für Mikroprozessoren entschied, sondern die CPU auf einigen Boards verteilte. Aber es gab eine Reihe von Gründen die dagegen sprachen. Zum einen wählte man in der Regel bewährte Technologien aus. Die Mikroprozessoren waren noch viel zu neu. Es gab noch keine Erfahrungen mit ihnen und man wusste z.B. nicht wie empfindlich sie auf Strahlung reagieren würden. Der offensichtlichste Grund der gegen die CPU's auf einem Chip sprach war, das sie zu langsam waren. Mikroprozessoren waren langsamer als der Apollo Bordrechner. Der GPC sollte aber erheblich mehr als der AGC von Apollo leisten. Er sollte auch 20 Jahre lang eingesetzt werden. In dieser Zeit würden die Anforderungen ansteigen, so wurde auch die benötigte Leistung gleich zu Beginn höher angesetzt.
In der Tat war der Shuttle GPC slebst als er 1981 zum ersten Mal flog noch schneller als jeder damals kommerziell verfügbare Mikroprozessor. Erst die Generation des 80286 / 68010 war in etwa so schnell wie der GPC. Für Fließkommaoperationen benötigten beide aber noch einen Coprozessor. Erst 1989 kamen die ersten Prozessoren auf den Markt in denen diese auch integriert waren. Beim Erstflug existierten diese Koprozessoren noch gar nicht (der 8087 Prozessor erschien 1983).
Die NASA suchte nach verfügbaren Avionikrechnern, also Rechnern die gebaut wurden um Flugzeuge zu steuern. Die Anforderungen waren bei diesem Einsatz am ehesten vergleichbar mit denen des Shuttle GPC. Man machte sich nicht die Mühe, extra einen Minicomputer oder Großrechner für diese Aufgabe umzukonstruieren, da diese weder gebaut wurden die Belastungen beim Start und der Landung zu wiederstehen, noch waren sie ausgelegt mit dem verfügbaren Volumen oder Strom auszukommen.
Es gab nur wenige Rechner die als Basis dienen konnten: Die erste logische Wahl war der Autonetics D-216. Er war der Bordcomputer für die ersten B-1A Prototypen. (Strategischer Bomber) Der D-216 war ein 16 Bit Rechner mit 16 KWort Speicher. Er war mit 85.000 Dollar recht preiswert und verfügbar. Aber sowohl der kleine Speicherbereich wie auch die kleine Wortebreite waren ungenügend. Selbst wenn man nur mit ganzen Zahlen rechnen würde, wären 16 Bit für die erforderliche Genauigkeit nicht ausreichend. Der Nachfolger des D-216 der für den Einsatz in den Serienexemplaren der B-1A vorgeschlagen wurde war der Singer- Kearfott SKC-2000. Dieser war ein 32 Bit Rechner, dessen Speicher auf 24 KWorte ausgebaut werden konnte (durch die doppelt so große Wortbreite war dies dreimal mehr Speicher als beim D-216). Ein echtes Plus war, dass er über Fließkommafähigkeiten verfügte, was damals ungewöhnlich bei kleineren Rechnern war. Andere Rechner mussten Fließkommarechenoperationen per Software durchführen, was diese sehr stark verlangsamte. Sein Nachteil war das hohe Gewicht von 90 amerikanischen Pfund (41 kg) und dr hohe Stromverbrauch von 430 Watt. Zudem kostete ein Exemplar 185.000 Dollar. Der Einsatz des AP101 im Skylab Programm brachte IBM ins Spiel. Der AP101 sollte anders als bei Skylab nun eine 32 Bit CPU einsetzen und hatte mit 32 Kworten auch mehr Speicher. Er wog 50 Pfund (22,5 kg) und zog nur 370 Watt Strom. Daneben wäre er für 87.000 Dollar pro Exemplar zu haben.
IBM war schon beteilligt bei früheren NASA Programmen. Neben dem Skylab Bordrechner als unmittelbarem Vorgänger (nur mit 16 Bit Breite und nur 16 KWorten Speicher) hatte IBM den Bordrechner für Gemini gebaut und die Missionskontrolle setzte Großrechner von IBM (das System 360 in den höheren Ausbaustufen) ein. Daher war es natürlich, dass man auf IBM zurückkam. Allerdings war Rockwell der Auftragnehmer für den Orbiter und konnte eigentlich selbst den Subunternehmer auswählen. So erteilte die NASA zuerst an IBM nur den Vorentwicklungsauftrag für die Software PASS bis Ende 1973 über 6.618 Millionen Dollar. Rockwell vergab dann logischerweise auch den Hardwareentwicklungsauftrag über 15 Millionen Dollar an IBM.
Eine wichtige Rolle bei der Entwicklung spielte das Dryden-Forschungszentrum mit seinem F-8 Programm. Die NASA hatte eine Vought F-8 Crusader erworben und erprobte an ihr neue Technologien. So wurde in die Maschine der Apollo-Bordrechner eingebaut und damit erstmals eine Computerkontrolle eines Flugzeuges erprobt. Weltbekannt wurde das F-8 Programm als in den frühen siebziger Jahren erstmals die Fly By Wire Technologie eingeführt wurde. Bisher steuerten Piloten ihre Maschinen mechanisch. Mit Pedalen oder Steuerrädern waren Seilzüge oder bei größeren Maschinen hydraulisch betriebene Aktoren verbunden die direkt auf jede Kraft reagierten und Steuerklappen betätigten. Beim Fly by Wire werden die Signale in Stromstärke übersetzt und damit Elektromotoren angetrieben. Es gibt keine direkte Steuerung mehr. Auch diese Technologie war beim Space Shuttle notwendig, da sonst alleine die dafür nötigen Kabel und die Hydraulik über 2 t gewogen hätten. Das Fly-By-Wire Programm führte dazu, dass man diese Technologie nun in militärischen Maschinen zunehmend eisnetzte, etwas verzögert auch in der zivilen Luftfahrt. Später wurde die umgebaute F-8 auch genutzt um die AP-101 zu erproben Zwischen dem 27.8.1976 und dem 16.12.1985 gab es 169 Einsatze der F-8 mit dem AP-101 um ihn und die Software PASS zu erproben.
Es wurde wieder ein Nachfolger des TC-1, der AP-101 verwendet, jedoch diesmal mit einer Wortbreite von 32 Bit um höhere Geschwindigkeit zu erreichen. Auch kam man ab von Assembler als Programmiersprache und schuf eine eigne Programmiersprache für die Software: HAL/S - Die NASA bestreitet übrigens jede Verwandtschaft zu dem Computer HAL aus dem Film "2001 Odyssey im Weltraum". Der AP 101 wurde 1966 eingeführt, so das als 1970 es an das Design ging, der Prozessor schon eingeführt war und auch in den Bombern B-52 und B-1B und dem Jäger F-15 eingesetzt wurde. Kombiniert wurde er mit einem eigenen I/O Prozessor. Zusammen werden beide als das Data Processing System (DPS) bezeichnet.
Das Space Shuttle
verfügt über 5 Computer: 5 identische AP 101 von IBM. Lediglich bei den Erprobungsflügen gab es zur Sicherheit ein sechstes System an Bord.
Die 5 Rechner von IBM synchronisieren sich regelmäßig. Dabei tauschen sie die Rechenergebnisse aus. Gibt es eine Differenz so kann die Besatzung
im Falle eines "Abweichlers" diesen abschalten. Bei zwei "Abweichlern" kann nicht gesagt haben, wer recht hat. Dann müssen alle 4 IBM Rechner
abgeschaltet werden und das Reservesystem in Betrieb genommen werden, Dieses kann nur 2 Funktionen: Beim Start eine Kreisbahn erreichen und
eine Landung durchführen. Dafür ist die Software einfacher und dadurch weniger fehleranfällig. So kann die Mission zwar nicht gerettet werden,
aber das Shuttle und die Besatzung.
Diese seltsame Architektur entstand als man bei der Architekturfestlegung sich Gedanken über Softwarefehler machte. Ursprünglich war ein 5:3 System gedacht. Das bedeutet 5 Rechner werden eingesetzt. Mindestens 3 müssen dasselbe Ergebnis liefern. 2 Rechner können ausfallen. Doch was macht man wenn die Software auf allen 5 Rechnern fehlerhaft ist? In diesem Fall fallen alle 5 Rechner aus (Diese Fehlerursache führte zur Kursabweichung beim Jungfernstart der Ariane 5 und Sprengung der Rakete). So entschloss man sich auf einem der Rechner eine andere Software einzusetzen. Damit war aus dem 5:3 System ein 4:3 System geworden, das nicht sicherer gegen Fehler als ein 3:2 System ist. Ein Synchronisationsfehler zwischen den 4 IBM Rechnern verhinderte auch den ersten Columbia Flug am 10.4.1981.
Der AP 101 hat einen ladbaren Mikrocode von 2048 Instruktionen für max. 48 Bit in der Länge. Belegt wurde dieser Mikrocode mit 154 Opcodes. Durch den Microcode kann man in Grenzen Befehle aus einfacheren Sequenzen selbst definieren. Zudem kann man so leicht Fehler in der Abarbeitung korrigieren. Dies war bei 6 der 154 Instruktionen nötig, die nicht korrekt arbeiteten. Microcode bedeutet: die Befehle sind nicht fest verdrahtet sondern eine Instruktion wird aufgeteilt in ein Programm das abgearbeitet wird. Pro Takt in der Regel ein Schritt des Microcodes. Dies ist flexibler und erlaubt es auch komplexe Befehle einzusetzen, ohne das die Hardware sehr komplex wird. (Es ist im Prinzip ein Interpreter auf dem Mikroprozessor). Der Nachteil ist, dass Microcode langsamer als Hardwareverdrahtung ist. Das IBM 360 System setzte beide Techniken ein. Die meisten Modelle hatten Microcode. Die schnellsten Spitzenmodelle Hardwareverdrahtung (wegen der Geschwindigkeit).
Instruktionen konnten 16 oder 32 Bit Ganzzahlen oder - zum ersten Mal - 32,40 oder 64 Bit Fließkommazahlen bearbeiten. Die Register teilen sich in drei Gruppen ein:
Die Fähigkeit zur nativen Fließkommaberechnung war sehr vorteilhaft. Bei Apollo entfiel ein beträchtlicher Teil der Rechenleistung nur darauf, Fließkommazahlen für Berechnungen in Ganzzahlen umzuwandeln und dann wieder zurückzuwandeln, dabei war die Rechengenauigkeit des Apollo Computers für Fließkommazahlen recht bescheiden. (32 Bit Fließkommazahlen haben in etwa eine Genauigkeit von 7 Stellen wenn man sie in Exponentialschreibweise nutzt, bei Festpunkt-Darstellung sind es 9 Stellen).
Die Geschwindigkeit der ersten Generation betrug 480.000 Instruktionen/sec (Ganzzahlarithmetrik, 325.0000 bei Fließkommaarithmetrik) Die gesamte CPU bestand aus vielen Chips in MSI (Medium Scale Integration, bis zu 100 Gatter pro Chip) in TTL Bauweise. Dazu kamen sehr viele Schaltungen die Hardwarefehler oder Ausfälle erkennen konnten 95 % der Hardwareausfälle konnte die Maschine selbst erkennen. 5 % mussten durch Software oder die Crew erkannt werden.
Die CPU hatte die Fähigkeit Interrupts zu verarbeiten. Es gab 61 Interruptquellen die in 20 Prioritätsstufen unterteilt waren. Jeder Computer hat ein Volumen von 25 l und wiegt 26.3 kg. (19.4 x 25.9 x 49.6 cm). Der IOP ist in etwa genauso groß. Die MTBF sollte 1000 Stunden betragen und betrug 5200 Stunden.
Der Stromverbrauch eines GPC beträgt 350
Watt (600 Watt mit IOP). Jedem Prozessor ist ein I/O Prozessor (IOP) zugeordnet, der für den Datenaustausch über die 24 Busse des Systems
verantwortlich ist und damit den Hauptprozessor entlastet. Im Bild links ist die Organisation der Datenflüsse zwischen CPU und IOP abgebildet.
Der Speicher konnte über zwei Weisen adressiert werden. Der Prozessor selbst hat einen 16 Bit Adressbus. Damit kann er 64 KWorte adressieren (4 Bytes/Wort x 64 KByte = 256 KByte). Der Zugriff kann 16 Bit-weise oder 32 Bit-weise erfolgen (im ersten Fall ist der Speicher nur halb so groß). Ein Register, das Programm Status Word konnte allerdings genutzt werden um den Speicher zu erweitern. 4 Bits dieses Registers gaben an welcher 64 K Block innerhalb eines 256 K Blocks genutzt wird. Diese Adresserweiterung ähnelt ein bisschen der des 8086 Prozessors, nur wird dort eine 4 Bit Zahl an die Adresse angehängt, so das der Speicherbereich nicht nur 4 mal sondern 16 mal größer ist.
Die Größe des Speichers war von Anfang ein ein Problem. Rockwell, Hersteller des Orbiters meinte 32 K wären genug, da die meisten Schätzungen für die Softwaregröße von 1969-1971 von 28 K ausgingen. Die NASA verdoppelte diese Schätzungen und orderte zuerst 64 K. Diese teilten sich in 40 K Speicher für die CPU und 24 K für den I/O Prozessor auf, wobei dieser Speicher nur Halbwortweise organisiert war. Er bestand aus 8 K Halbwort Modulen. 10 waren in der CPU und 6 in dem I/O Prozessor. Der Speicher sollte als bei den ersten Schätzungen 256 KByte umfassen.
Jedes Modul bestand aus Ringkernspeichern aus Ringkernspeichern mit 400 ns Zugriffszeit. Dies war für Ringkernspeicher recht schnell. Obgleich zu diesem Zeitpunkt es schon Speicher auf Basis von Halbleiterelementen gab, blieb die NASA bei dem Ringkernspeicher wegen seiner sehr hohen Zuverlässigkeit. Die Module wurden so verschaltet, dass es abgeschaltet wurde, wenn 20 Mikrosekunden lang kein Zugriff erfolgte. Da Ringkernspeicher auch ohne Strom seine Information nicht verliert (sie ist magnetisch gespeichert) konnte man so 136 Watt an Strom sparen. Jedes Wort bestand aus 18 Bit, wobei 2 Bits der Fehlererkennung dienten. Der Hauptnachteil des Ringkernspeichers, seine hohe Zykluszeit spielte bei dem vergleichsweise langsam getakteten GPC keine Rolle.
Als die Software immer größer wurde erweiterte man die Module in der CPU und baute "double density" Module ein. Jedes double density Modul hat die doppelte Anzahl an Ringkernen. Die endgültige Konfiguration umfasste so 80 KWorte in der CPU und 24 KWorte im I/O Prozessor (entspricht 416 KByte Speicher pro GPC). Die Software konnte im Flug geändert werden. Vom Boden aus konnten 64 Halbworte in einem Burst übertragen werden. Die Besatzung konnte über die Tastatur bis zu sechs 32 Bit Zahlen auf einmal ändern. Alle Eingaben erfolgten in Hexadezimal.
Verbunden wurden die Rechner und der Rest des Shuttles über 24 I/O Busse mit einem zusätzlichen Master Bus. 8 davon waren flugkritisch und verbanden die Computer mit Systemen des Orbiters. 5 dienten der Kommunikation der 5 Rechner, 4 waren mit den Displays verbunden. 2 waren verbunden mit den Speichermodulen, 2 waren mit dem "Launch Processing System" verbunden und an 2 wurden Experimente angeschlossen und an einen die Instrumente.
Ein 25 ster Bus war der Master Controll Bus, der den I/O Fluss auf den 24 Anschlüssen kontrollierte. An jedem Bus hing ein speziell programmierter Mikroprozessor mit eigenem Speicher (Bus Control Element, BCE). Busse waren in den frühen siebziger Jahren noch etwas völlig neues. Alle bisherigen Computer hatten Punkt-zu-Punkt Verbindungen. Man entwickelte damals den MIL-STD 1553 Bus, doch dieser wurde erst 1975 standardisiert - zu spät für den Space Shuttle. Punkt-zu-Punkt Verbindungen scheiden aus, wenn man 5 Rechner verbinden will, sie sind dann viel zu aufwendig. Weiterhin waren an dem Bus auch Sensoren angebracht. Hätte man für jeden Sensor eine Leitung eingesetzt, so wären die Kabel in dem über 30 m langen Orbiter viel zu schwer geworden. Ein digitaler Computerbus erlaubte es die Daten zu digitalisieren und von verschiedenen Sensoren zusammen zu übertragen (Multiplexen).
Man entschied sich für die Kommunikation zwischen den 5 Rechnern für eine Lösung, bei der man ein Problem von Bussen eliminiert: Was passiert wenn mehrere Teilnehmer gleichzeitig Daten senden? Als Folge sind die Daten unbrauchbar, beim Ethernet Protokoll spricht man von einer Kollision. Bei den Space Shuttle Rechnern vermied man dies ganz einfach. Es gab 5 Busse anstatt einem um die 5 Rechner zu verbinden. Bei jedem der Busse hat ein Rechner die Masterkontrolle. Er sendet Daten. Die anderen vier sind passiv und hören nur mit. So braucht man pro Rechner einen Bus, aber es sendet auf jedem Bus auch nur ein Teilnehmer - eine genial einfache Lösung. Die Daten wurden über den Bus halbwortweise transferiert. Die Buscontroller nahmen aus dem Speicher die Halbwörter mit Prüfbits an und serialisierten diese. Die Taktrate betrug 1 MHz. die Bandbreite betrug somit pro Bus 1 MBit.
Um die 24 Busse gleichzeitig zu überwachen enthält jeder IOP 24 einzelne Prozessoren, einen für jeden Bus. Daten auf dem Bus sind immer 28 Bits lang:
3 Bits Synchronisation und Klassifizierung Kommando/Daten
5 Bits Adressat an wen die Daten gehen
19 Bit Daten / Kommando. Bei Kommandos
: 19 Bit für dieses. Bei Daten : 16 Bit Daten, 3 Bit Prüfsumme
Ein und AusgabeAnders als bei allen früheren Missionen gab es nun zum ersten Mal Bildschirme die Text darstellen konnten. Die Bildschirme haben Größen von 5 × 7 Zoll und stellten 51 × 26 Zeichen dar. Vier Stück sind im Cockpit vorhanden. Ein eigener 16 Bit Prozessor mit 8 KWorten RAM kümmert sich um die 4 Displays. Drei der Displays befinden sich im vorderen Teil des Cockpits, eines beim Nutzlastspezialisten hinten. Tastaturen zur Eingabe hatte der Pilot, Copilot und der Nutzlastspezialist.
Die Displays hatten auch bescheidene grafische Fähigkeiten : Linien und Kreise konnten gezeichnet werden und Buchstaben konnten blinken.
Beginnend ab dem Jahre 1998 wurde das Cockpit aller Space Shuttles renoviert. Jeder Orbiter bekommt dieses wenn er zur Generalüberholung kommt. Graphische LCD Displays zeigten nun viel mehr Informationen. Obgleich man die 4 Röhrenmonitore durch 11 LCD (9 bei Pilot und Copilot, 2 beim Nutzlastspezialisten) ersetzte war das neue Cockpit um 34 kg leichter. Entfallen sind auch 32 analoge Anzeigen. (Jedes Cockpit enthält auch 2100 analoge Schalter und Anzeigen). Jedes Display verfügt über einen eigenen Prozessor der sich um die Anzeige kümmert.
Ein Magnetband wurde erst sehr spät in die Spezifikationen aufgenommen, wurde aber bald essentiell, denn die Software sprengte den Arbeitsspeicher. Zwei Bänder, jedes mit einer Kapazität von 8 Millionen 16 Bit Worten nahmen die Flugsoftware auf, die mit 700 KWorten inzwischen das verfügbare RAM weit überschritt. Zugriff auf die redundanten Magnetbänder geschieht in Blöcken von je 512 Halbwörtern (1024 Bytes)
Die Softwareentwicklung gestaltete sich einfacher, da man diese auch auf einem IBM 360/75 System entwickeln konnte.
Computerupgrade1988 wurden die Rechner durch die Leistungsfähigeren AP 101F ersetzt. Der technologische Fortschritt lies nun zum einen ein Upgrade des Speichers auf den vollen Adressbereich von 256 KWorten, also um das zweieinhalbfache zu. Der Speicher besteht nun auch aus normalen Speicherchips, allerdings mit einer zusätzlichen Stromversorgung, damit auch bei Stromausfällen der Speicher erhalten bleibt (Simulation des Verhaltens von Ringkernspeichern). Die Geschwindigkeit des AP-101F wurde auch gesteigert. Er ist nun mit 1.2 Millionen Instruktionen/sec fast dreimal so schnell wie sein Vorgänger. Trotzdem ist es nun möglich CPU und IOP in nur einer Box unterzubringen. Vorher waren es zwei getrennte Boxen.
Der neue Rechner spart so ein Volumen von 123 l und 136 Gewicht ein. Der Stromverbrauch sinkt pro Einheit um 100 Watt. Die MTBF soll 6.000-10.000 Stunden betragen. Die Kosten eines AP-101F (auch die Bezeichnung AP-101S ist gängig) betragen mit 1 Million USD pro Einheit die Hälfte seines Vorfahrs.
Der Space Shuttle Software ist ein Kapitel für sich. Sie wurde erheblich komplexer als gedacht. Damit stiegen auch die Kosten enorm an. Zuerst einmal gab es Diskussionen über das Betriebssystem. Es sollte ein Echtzeitbetriebsystem sein, dass mehrere Dinge zugleich erledigen konnte. Rockwell plädierte für einen einfachen Mechanismus, ein "time slice" Betriebssystem. Dabei hat jeder Prozess eine feste Zeitscheibe die er ausnutzen kann. Der Nachteil solcher fester Zeitscheiben ist aber, dass bei Überlastung ein System versagen kann, weil wichtige Prozesse warten müssen. IBM favorisiert eine aufwendigere Lösung, ein prioriätsgesteuertes System. Hier bekommt auch jeder Prozess eine Zeitscheibe. Aber die Prozesse sind nicht gleichberechtigte. Sehr wichtige (für die Steuerung) haben eine höhere Priorität als unwichtige und können diese unterbrechen. Erst wenn die wichtigen Dinge erledigt sind, werden diese fortgeführt. Bei Überlastung versagt bei dieser Softwarephilosophie nicht das System, sondern es fallen zuerst Prozesse weg die unwichtig sind.
HAL wurde als Programmiersprache für die meiste Software verwandt. Das Betriebssystem wurde in Assembler kodiert. HAL war im Durchschnitt nur 10 bis 15 % langsamer als Assembler.
Die Software des Space Shuttle hieß PASS (Primary Avionics Software System). Sie bestand wiederum aus einem Echtzeitbetriebssystem (Flight Computer Operating System FCOS) sowie dem Benutzerinterface und den Systemkontrollprogrammen als Systemprogrammen und Anwendungsprogramme welche die Gebiete Steuerung, Navigation, Kontrolle, Orbitersubsystem Verwaltung, Nutzlast und Checkprogramme umfasste.
FCOS umfasste zuerst 140K, dann begann man den Umfang zu reduzieren. Bis 1978 hatte IBM die Größe auf 116 K gesenkt. Die NASA forderte eine Reduktion auf 80 K. Doch dies erreichte man nie der kleinste Umfang waren 98840 Worte. Steigende Anforderungen an FCOS ließen die Größe jedoch wieder auf den ursprünglichen Wert anwachsen. Dank des später hinzugenommen Magnetbandlaufwerkes konnte man die Funktionalität in Module spalten, so dass nur 35 K von FCOS permanent belegt wurden. Etwa 60 K blieben frei für nachgeladene FCOS Modulen und Anwendungsprogramme.
FCOS hat für wichtige Prozesse (Steuerung) Zeitscheiben von 30 ms Dauer (Minor Cycle) und für nicht kritische Prozesse Scheiben von 960 ms Dauer (Major Cycle). Major Cycles können von Minor Cycles unterbrochen werden.
Auf dem Magnetband wurden auch Module abgelegt die man für die Mission brauchte, schon vor dem Erstflug gab es 1000 Module. Dank der Komptabilität zu der IBM 360 Serie konnte man die Software auf IBM 360/75 Rechnern entwickeln und testen. Als die Testflüge näher rückten schaffte die NASA zwei IBM 3033 Computer mit jeweils 16 MB Speicher, 20 Magnetbandlaufwerken, 6 Zeilendruckern, 66 MB Trommel und 23.4 MB Plattenspeicher. Diese Rechner bedienten 105 Terminals. Obwohl das für 1981 sehr leistungsfähige Rechner waren musste man bald den Hauptspeicher auf 100 MB erweitern und den Diskspeicher auf 160 MB.
Die Flugsoftware des Shuttles umfasst insgesamt
500.000 Zeilen. Schon vor dem Erstflug war sie enorm teuer geworden. Anstatt 20 über 200 Millionen Dollar. Sie wurde mehrfach geprüft. Zum einen
von den Programmieren auf logische Fehler, zum zweiten von einem externen Team das sich den Code unvoreingenommen ansehen konnte. Dann wurden
Testbedingungen festgelegt und die Software mit diesen geprüft. Von letzten Tests gab es 1020 für die Software des Erstflugs.
Trotzdem war PASS bei den ersten Flügen weit von einer operationellen Software entfernt. Astronauten klagten "Computer sollten uns Arbeit abnehmen, stattdessen arbeiten wir für die Computer". PASS konnte bei dem Verlust des Kontakts zu einer Bodenstation nicht automatisch auf die nächste aufschalten, dass mussten die Astronauten erledigen. Da jeder Shuttle nur etwa 5-10 Minuten Kontakt zu einer Bodenstation hat kann man sich denken wie begeistert die Astronauten davon waren. Eine Analyse ergab dass bei STS-2 die beiden Testpiloten in 58 Stunden 13000 Tastendrücke zu erledigen hatten - Genauso viele wie 3 Apollo Astronauten in einer 7 Tage Mondmission. Anders ausgedrückt war die Arbeitsbelastung durch PASS war viermal so hoch wie bei Apollo.
Ingenieure sahen das PASS Interface als
unnötig komplex und maschinennah anstatt benutzerfreundlich programmiert an. Die Bildschirme waren mit Daten übersäht und dadurch überfrachtet.
Dagegen war der Keyboard Puffer zu klein, das leicht Daten verloren gehen konnten. Noch fehlerträchtiger war, dass man jede Tastatur mit jedem
Bildschirm verbunden konnte und es drei Bildschirme aber nur zwei Tastaturen vorne im Cockpit gab. Astronaut Henry Hartsfield meinte dazu
"Das schreit geradezu nach Fehlern".
Eingaben konnte man wie zu Apollo Zeiten nur hexadezimal machen. Das links abgebildete Keyboard hat nicht mehr Tasten als ein Zehnerblock auf ihrem PC. So war die Software nicht zu brauchen. Von 1982 bis 1989 wurde sie ständig verbessert. So dass die Fehlerzahl sie von 11 Fehlern pro 1000 Zeilen auf 1 Fehler pro 1000 Zeilen sank. Die Kosten dafür waren enorm: Die gesamte Software kostete 200 Millionen Dollar, also 400 Dollar pro Codezeile.
Mit dem ersten Start der Columbia war das Kapitel noch nicht abgeschlossen. Bis zum letzten Start wurde an der Software gearbeitet. Es gab allerdings drei Major Releases für die Flüge STS-1 (350.000 Zeilen Code), STS-2 (78.000 Zeilen) und STS-5 (135.000 Zeilen). Danach gab es noch 34 kleinere Releases, doch hier wurde nur eine kleine Menge an Code angepasst, zwischen 1.200 und 34.400 Zeilen.
Anpassungen waren nötig, weil es neue Missionstypen gab, wie die Kopplung an Raumstationen, das Einfangen von Satelliten, das aussetzen von Satelliten, oder es Änderungen im System gab wie z.B. das "Glas Cockpit" oder die Einführung des AP101S, der Anpassungen am Betriebssystem nötig machte. Während der ganzen Zeit wurde die Software weiter überprüft und Fehler beseitigt.
So betrug das rechnerische Risiko eines Verlusts von Crew und Fähre (ohne Berücksichtigung, dass das Backup System den Fehler erkennen und kompensieren konnte) bei STS 1 1:327 bis 1:409, und ab 2009 lag es bei 1:4930 bis 1:6920.
Ein sehr wichtiger Designpunkt war die Absicherung gegen Ausfälle. Bei dem Space Shuttle dachte man vorwiegend an Hardware Ausfälle. Hardware war damals noch weitgehend unzuverlässiger als heute. Bei den CPU's aus zig einzelnen Chips bedeutete ein Ausfall auch nicht wie heute, dass ein Computer völlig ausfiel, sondern je nachdem wo der Chip ausfiel rechnete er falsch oder arbeitete falsch. Ein Addierer bestand damals z.B. aus einigen parallelen Addierern, die jeder nur einige Bits bearbeiteten. Fiel einer diese aus, dann waren von einer 32 Bit Zahl einige Bits falsch.
Erst später machte man sich Gedanken über Softwarefehler und beauftragte Rockwell neben IBM mit der Softwareentwicklung. Rockwell bekam den Auftrag für einen Computer ein Notprogramm zu entwickeln, dass nur aktiv wurde wenn zwei der 4 IBM Rechner ausfielen. Dieses Notprogramm war dazu gedacht die Besatzung sicher in den Orbit zu bringen oder vom Orbit eine Notlandung durchzuführen. Rockwell implementierte dafür ein Betriebssystem mit festen Zeitscheiben.
Ob ein Rechner aus der Reihe tanzt stellte man über mehrere Mechanismen fest. Immer wenn ein Rechner eine Ein/Ausgabe machte oder einen Prozess anstieß legte er einen 3 Bit Statuscode auf den Bus und wartete 4 ms und empfing dann von den anderen Rechnern ebenfalls einen 3 Bit Statuscode der anzeigte ob diese Rechner genau dasselbe gemacht hatten wie er oder sie Abweichungen beobachteten.
Alle 160 ms legte jeder Rechner auch ein 64 Bit Statuswort auf den Bus, das zusammengesetzt war aus den am wenigsten signifikanten Bits der letzten Ein- und Ausgaben zu wichtigen Shuttle Systemen (Hydraulik, Booster, Haupttriebwerke, Ruder etc).
Von 2004 bis 2006 untersuchte die NASA ob man den Bordcomputer nicht durch etwas moderneres ersetzen könnte. Aufgrund der Investitionen in die Software, war klar, dass die Lösung 100% kompatibel sein musste - nicht nur im Befehlssatz sondern auch im Zeitverhalten. Man kam auf Field programmable Gate Arrays (FPGA). Dies sind Bausteine, deren Funktion per Programm festgelegt wird. Dies geschieht vor dem Einsatz. Da sie die Konfiguration verlieren, wenn die Stromversorgung ausfällt, wird diese meist in einem ROM abgelegt, von dort kann sie dann in das FPGA abgelegt werden. Heute kann man mit einem FPGA komplette Rechner wie eben den Shuttle Bordcomputer "emulieren". Die Studie untersuchte auch, ob man so neben der Legalacy Hardware auch neue Funktionen einbauen kann, so z.B. die Unterstützung weiterer (und neuerer) Bussysteme wie dem A553 Bus, oder RS 422 Bus. Experimentell wurde mittels einer Hardware Description Language der AP101S auf einem Altera FPGA "simuliert". Ein Einsatz hätte rund 30 kg Gewicht und 500 Watt Strom eingespart. Vor allem letzteres ist von Bedeutung, da der Strom aus Brennstoffzellen bezogen wird.
Es wird 1 Kilogramm Sauerstoff und Wasserstoff benötigt um 1,6 KWh zu generieren Allerdings wird der Bordscomputer nicht permanent aktiv sein, ansonsten würde man so pro Tag rund 8 kg Gewicht einsparen. Wie viele andere Aktivitäten kam es durch das ausmustern der Space Shuttle nicht dazu.
Die Hauptrechner bezeichnet die NASA auch als GPC (General Purpose Computers). Jeder Shuttle hat aber noch andere Computer andere Computer an Bord. Die wichtigsten sind die Triebwerkscontroller. Dieser überwacht die Triebwerke. Das Space Shuttle Haupttriebwerk wird damit man mehr Leistung erreicht nahe der Belastungsgrenze gefahren. Damit es trotzdem sicher ist überwachen Controller an den Triebwerken die Messwerte des Triebwerks und schalten es im Falle von ungewöhnlichen Daten sofort ab. Dies geschah einmal im Jahre 1985. Da es sehr spät erfolgte konnte die Challenger aber noch einen Notorbit erreichen.
Der erste von 1981-1988 war der HDC-601. Der HDC-601 von Honeywell war ein 16 Bit Computer mit 16 KWorten RAM. Seit 1988 wurde ein Motorola MC 68000 mit je zwei 64 K großen CMOS RAM Speichern eingesetzt und C als Programmiersprache verwendet anstatt Assembler. Die Triebwerkscontroller hängen direkt an den Triebwerken und sind sehr großen Vibrationen und Schallpegeln ausgesetzt. Sie müssen erheblich robuster als die GPC sein. Ein geplantes Upgrade bis 2005 sollte diese durch digitale Signalprozessoren (DSP) ersetzen und die Sicherheit weiter steigern. Man erhoffte sich von den DSP ein so rechtzeitiges Bemerken von Anomalien, dass man die Triebwerke in jedem Falle sauber abschalten kann bevor der Besatzung eine Gefahr droht. Man erhoffte sich dadurch eine Reduktion des Risikos die Besatzung zu verlieren um die Hälfte.
Mehr über die Triebwerkscontroller in einem eigenen Aufsatz.
Es gibt von mir vier Bücher zum Thema bemannte Raumfahrt. Alle Bücher beschäftigen vor allem mit der Technik, die Missionen kommen nicht zu kurz, stehen aber nicht wie bei anderen Büchern über bemannte Raumfahrt im Vordergrund.
Das erste bemannte Raumfahrtprogramm der USA, das Mercuryprogramm begann schon vor Gründung der NASA und jährt sich 2018 zum 60-sten Mal. Das war für mich der Anlass, ein umfangreiches (368 Seiten) langes Buch zu schreiben, das alle Aspekte dieses Programms abdeckt. Der Bogen ist daher breit gestreut. Es beginnt mit der Geschichte der bemannten Raumfahrt in den USA nach dem Zweiten Weltkrieg. Es kommt dann eine ausführliche technische Beschreibung des Raumschiffs (vor 1962: Kapsel). Dem schließt sich ein analoges Kapitel über die Technik der eingesetzten Träger Redstone, Little Joe und Atlas an. Ein Blick auf Wostok und ein Vergleich Mercury bildet das dritte Kapitel. Der menschliche Faktor - die Astronautenauswahl, das Training aber auch das Schicksal nach den Mercurymissionen bildet das fünfte Kapitel. Das sechs befasst sich mit der Infrastruktur wie Mercurykontrollzentrum, Tracking-Netzwerk und Trainern. Das umfangreichste Kapitel, das fast ein Drittel des Buchs ausmacht sind natürlich die Missionsbeschreibungen. Abgeschlossen wird das Buch durch eine Nachbetrachtung und einen Vergleich mit dem laufenden CCDev Programm. Dazu kommt wie in jedem meiner Bücher ein Abkürzungsverzeichnis, Literaturverzeichnis und empfehlenswerte Literatur. Mit 368 Seiten, rund 50 Tabellen und 120 Abbildungen ist es das bisher umfangreichste Buch von mir über bemannte Raumfahrt.
Mein erstes Buch,
Das Gemini Programm: Technik und Geschichte
Mein zweites Buch,
Das ATV und die Versorgung der ISS: Die Versorgungssysteme der Raumstation
Das Buch
Die ISS: Geschichte und Technik der Internationalen Raumstation
Durch die Beschränkung auf den Technischen und geschichtlichen Aspekt ist ein Buch entstanden, das kompakt und trotzdem kompetent über die ISS informiert und einen preiswerten Einstieg in die Materie. Zusammen mit dem Buch über das ATV gewinnt der Leser einen guten Überblick über die heutige Situation der ISS vor allem im Hinblick auf die noch offene Versorgungsproblematik.
Die zweite Auflage ist rund 80 Seiten dicker als die erste und enthält eine kurze Geschichte der Raumstationen, die wesentlichen Ereignisse von 2010 bis 2015, eine eingehendere Diskussion über die Forschung und Sinn und Zweck der Raumstation sowie ein ausführliches Kapitel über die Versorgungsraumschiffe zusätzlich.
Das bisher letzte Buch
Skylab: Amerikas einzige Raumstation
Mehr über diese und andere Bücher von mir zum Thema Raumfahrt finden sie auf der Website Raumfahrtbücher.de. Dort werden sie auch über Neuerscheinungen informiert. Die Bücher kann man auch direkt beim Verlag bestellen. Der Versand ist kostenlos und wenn sie dies tun erhält der Autor auch noch eine etwas höhere Marge. Sie erhalten dort auch die jeweils aktuelle Version, Bei Amazon und Co tummeln sich auch die Vorauflagen.
| Sitemap | Kontakt | Neues | Impressum / Datenschutz | Hier werben / advert here | Buchshop | Bücher vom Autor | |