| Home | Raumfahrt | Sonstige Raumfahrtaufsätze | Raumfahrt & Computer | Site Map | |
Dieser Artikel behandelt die Hardware von Computern die in benannten Raumfahrzeugen eingesetzt werden und wurden. Leider liegen mir nicht sehr viele ausführliche Informationen vor, ich habe mich trotzdem bemüht diese in diesen kleinen Text zusammen zu tragen.
Der Artikel basiert neben anderen persönlichen Aufzeichnungen, vor allem auf dem Buch Computers in Spaceflight The NASA Experience. Dieses ist online unter NASA Histories verfügbar.
Dies alles macht Hardware für den Weltraumeinsatz nötig. Alle größeren Weltraumorganisationen entwickeln heute spezielle Hardware für den Einsatz im Weltraum. Grund dafür sind neben den obigen Gründen auch spezielle Anforderungen hinsichtlich Raumfahrzeuges.
Die meisten Rechner für die Raumfahrt waren bis Anfang der achtziger Jahre Spezialanfertigungen, die kein kommerzielles Gegenstück hatten. Daher versuchte man die Architektur sehr einfach zu machen. Eine Besonderheit war, dass die Hardware den Speicher meistens wortweise adressierte und feste Wortbreiten hatte. Heute wird der Speicher byteweise adressiert (das bedeutet, dass die kleinste Einheit die man ansprechen kann ein Byte beträgt). Der Code eines Prozessors ist unterschiedlich lang, wobei häufig benutzte Befehle meistens kürzer als selten benutzte sind.
Das Problem dieser Architektur ist, dass es sehr aufwendig ist festzustellen wo der nächste Befehl anfängt und auch die Dekodierung aufwendig ist. Wenn man die Architektur einfacher gestalten will, so nimmt man eine Architektur fester Breite. Benötigte ein Befehl Daten so lagen die diese im nächsten Wort. Der Speicher wurde dann auch nur wortweite angesprochen. Die Dekodierung vereinfachte sich enorm, da ein Befehlswort immer gleich lang war und das nächste ein Wort weiter sich im Speicher befand. Dafür braucht man mehr Speicher.
Wenn in den folgenden Artikeln also von "Kiloworten" oder "KWorte" die Rede ist, so muss man um auf die Speichergröße in Bytes zu kommen dieser Wert mit der Wortbreite in Bits multiplizieren und durch 8 teilen. Ein Prozessor mit 24 Bit Wortbreite und 128 KWorten Speicher hat also einen Speicher von 24 * 128 / 8 = 384 KByte. Der letzte Prozessor mit fester Wortbreite der in der Raumfahrt eingesetzt wurde war der MIL-STD 1750A, der Anfang der achtziger Jahre entwickelt wurde und bis Mitte der neunziger Jahre als Basis für neue Designs diente.
Eine wichtige Rolle war die Sicherheit bei bemannten Projekten, aber auch unbemannten Sonden. In den Sechzigern und frühen Siebziger Jahren war Hardware noch viel unzuverlässiger als heute und fiel öfters aus. Wie sichert man sich dagegen ab ? Nun der einfachste Weg ist der der Redundanz. Das bedeutet, dass man sicherheitskritische Systeme mehrfach einbaut.
Doch damit ist es nicht getan. Man muss auch einen Defekt erkennen können. Heute erscheint dies trivial. Wenn ihre CPU ausfällt, so funktioniert der Rechner nicht mehr. Das gleiche gilt auch für die Festplatte. Doch wer einmal einen Defekt in einem Speicher hatte, weiß wie es ist wenn von 8 dieser kleinen Käfer einer defekt ist. Dann arbeitet der Computer manchmal normal und manchmal stürzt er ab.
Früher war die Situation noch schlimmer, denn ein Computer bestand nicht aus einem Baustein wie heute sondern vielen. Der Apollo Guidance Computer zum Beispiel aus 5760 Bausteinen mit jeweils wenigen Transistoren. Ein einfacher Addierer für 16 Bit bestand aus vielen Einzeladdierern für einige Bits. Wenn nun eine dieser Schaltungen defekt war rechnete der Computer einfach falsch aber fiel nicht aus.
So führte man in den meisten Systemen der ersten Generation Voting Systeme ein. Im einfachsten Fall hat man 3 Systeme. Eine Schaltung vergleicht dann die Ergebnisse regelmäßig und mindestens 3 von 3 müssen identisch sein. Bei Abweichungen wird dann der dritte Rechner abgeschaltet. Später erfand man komplexere Routinen die es erlaubten die Anzahl der Rechner zu reduzieren. Eine Möglichkeit ist es z.B. eine einfache Schaltung zu entwickeln die ein Register in einem Computer laufend dekrementiert. Sobald das Register Null erreicht schaltet sie den Computer ab. Ein regelmäßiger Task im Computer muss daher den Wert laufend erneuern. Diese Vorgehensweise gewährleistet dass die Grundfunktionen - das regelmäßige aufrufen von Systemtasks funktionieren.
Im Mercury Programm wurden noch keine Computer eingesetzt. Das Mercury Programm wurde relativ schnell aufgezogen und die Computer Hardware war noch nicht leistungsfähig genug um sie ins Raumfahrzeug zu integrieren. Dies war auch nicht nötig: Um auf Risiken weitgehend zu verzichten wurde die Mission vom Boden aus geflogen. Der Pilot war nur als passiver Passagier eingeplant und die Missionen selbst auf maximal 1 Tag ausgelegt. Mercury Kapseln flogen auch mit Schimpansen als Passagieren. In ähnlicher Weise wurden auch sowjetische Missionen bis in die achtziger vom Boden aus geflogen und auch heute noch wird bei amerikanischen Missionen eine höhere Verantwortung auf die Crew gelegt.
Das Bild links zeigt die Instrumente von Mercury - Es gab viel zu Beobachten und einige Schalter, aber keinen Computer. Immerhin: Das "User Interface" war so einfach, das es sogar dressierte Affen bedienen konnten, die man vor den Menschen in den Orbit schoss!
Der Pilot konnte zwar sein Raumfahrzeug fliegen (Steuerdüsen betätigen, Wiedereintritt einleiten), doch konnte man genauso dies vom Boden aus tun. Auch dies resultierte daraus, dass man zuerst Schimpansen vor den Menschen ins All schoss.
Im Gemini Programm wurde die Mission schon komplizierter. Hier sollten nahe der Erde alle Manöver geübt werden, die im Mondprogramm nötig sind: Koppeln von Raumfahrzeugen im Orbit, Langzeitflüge bis 14 Tagen, Arbeit außerhalb des Raumschiffes. Das ganze wäre auch vom Boden aus möglich gewesen, jedoch war ein Computer eine Unterstützung und im Mondprogramm musste es ja auch weitgehend ohne Bodenkontrolle gehen. Der Gemini Computer sollte in allen Phasen der Mission eingesetzt werden: Beim Check vor dem Start, als Backup zum Autopilot der Titan 2, Locken auf eine Bodenstation, Rendezvous Manöver und Wiedereintrittsteuerung. Man versprach sich vor allem für die letzten beiden eine höhere Genauigkeit. Beim Start konnte er jederzeit übernehmen, wenn der Computer der Titan 2 ausfiel und er hatte alle Aufstiegsdaten und konnte so die Daten für Feinkorrektur nach dem Erreichen des ersten Orbits an die Mannschaft weitergeben. Durch den Computer waren Rendezvous Manöver auch möglich, wenn man nicht im Empfangsbereich einer Bodenstation war und die Genauigkeit der Landung stieg, wodurch man die Bergungsflotte verkleinern konnte.
Der Gemini Rechner war der
erste Computer der im Orbit eingesetzt wurde. Er war noch auch diskreten Bauteilen aufgebaut, d.h. einzelnen Transistoren, nicht integrieren
Schaltungen. Er hatte Abmessungen von 48 × 37 × 32 cm und eine Masse von 26.6 kg. Er bestand aus fünf Boards und war mit 510 Modulen aufgebaut.
Die Auslegung war noch nicht redundant. Er fiel bei Gemini 4 aus, als man die Kapsel landen wollte. Die Landung musste so verschoben und von
der Besatzung durchgeführt werden. Die Gemini Kapseln waren auch völlig ohne Computer steuerbar.
Der Rechner hatte eine Taktrate von 140 Mikrosekunden, konnte also maximal 7000 Befehle/Sekunde abarbeiten. Eine Multiplikation dauerte 420 Mikrosekunden. Diese auch zur damaligen Zeit langsame Rechengeschwindigkeit resultierte aus der seriellen Verarbeitung der Daten. Sie ermöglichte aber eine große Vereinfachung des Designs. Daten wurden innerhalb des Rechenwerkes mit 500.000 Bit/sec übertragen, zum Speicher mit 250.000 Bit/sec.
Der Speicher bestand aus 39 Modulen von Ringkernspeichern à 64 × 64 Bits, zusammen also 19968 Byte. IBM bekam den Auftrag für den Computer, weil sie für den OAO Satelliten einen sehr zuverlässigen Speicher bauten.
Ein Wort bestand immer aus 39 Bits die in 3 einzelne 13 Bit Scheiben unterteilt wurden. Üblicherweise wurden die ersten 13 Bits für ein Befehlswort verwendet und die restlichen 26 Bit für die Daten. Der Rechner hatte also eine 13/26 Bit Architektur. Alternativ konnte man auch 3 Befehlsworte von jeweils 13 Bits in einem 39 Bit Wort platzieren. Alle Daten wurden als Festpunktzahlen verarbeitet. Es gab nur 16 Befehle.
Derartige "krumme" Architekturen
waren damals üblich, so war der erste Supercomputer die Cyber 6600 z.B. ein 6/18 Bit System. Ringkernspeicher
(Core Memory) war vor Einführung der Halbleiterspeicher Anfang der siebziger Jahre der normale Speicher bei Computern. Er besteht aus kleinen
Eisenringen die auf einem Geflecht von Kupferdrähten sitzen. Durch jeden Kern laufend 3 Drähte. Zwei Drähte bilden eine Matrix in deren Kreuzungspunkten
die Kerne liegen. Ein dritter ist ein Auslesedraht.
Ein starker Stromstoß kann an einem Kreuzungspunkt die Magnetisierung des Eisenrings ändern und so ein Bit speichern. Mit einem schwächeren Strom kann man den Speicher auslesen. Das Magnetfeld des Ringes ändert dabei die Stromstärke im Lesedraht. Die Speicherung ist anders als heute magnetisch und damit permanent wie bei einer Festplatte.
Ringkernspeicher ist relativ teuer zu fertigen, langsam im Zugriff, aber extrem zuverlässig. Die größten Module Anfang der siebziger Jahre hatten bis zu 1024 Bits auf einer Fläche von einigen Quadratzentimetern.
Bei Gemini wurde von jedem Wort ein Bit ein einem der Module gespeichert. Die Gesamte Software konnte so 4096 Worte groß sein. Ab Gemini 8 kam ein zusätzliches Bandlaufwerk zur Datenspeicherung zum Einsatz. Ihren Weltraumeinsatz feierten diese schon beim ersten Satelliten der USA Explorer 1 der seine Daten auf ein kleines Band (damals allerdings analog) aufzeichnete und dann in der Nähe der Bodenstation abspielte. Das Bandlaufwerk war ursprünglich nicht Bestandteil des Computers, doch die Software passte nicht komplett in den Speicher.
Ein Problem war die Datensicherheit, die damals
bei einem fehlerhaften Bit auf 100.000 Bit lag. Man erhöhte diese indem man die Daten dreifach aufzeichnete. War ein Bit defekt, so waren
die anderen beiden doch lesbar und über Mehrheitsentscheidung konnte so das dritte korrigiert werden. Nur wenn zwei Bits falsch waren wurde
die Information verfälscht. Diese Wahrscheinlichkeit lag aber bei 1:1 Milliarde und somit 10.000-mal kleiner als bei einem einzelnen Bitfehler.
Die Speicherkapazität des 26 kg schweren Bandlaufwerks lag bei 1.17 Megabit, also 7 mal größer als der Hauptspeicher. Bedingt durch das dreifache Lesen dauerte es aber 6 Minuten um ein Programm in den Speicher zu lesen. Die Datenrate lag so nur bei 440 Baud.
Die Software wurde angesichts der Rechengeschwindigkeit und Speicherkapazität in Assembler geschrieben und bestand aus anfangs Modulen: Aufstieg, Einfangen, Rendezvous und Wiedereintritt. Durch das Bandlaufwerk kamen weitere drei Module hinzu die vor allem bei den Rendezvoursmanövern Den Astronauten Vorgaben über die Manöver machten, um so Treibstoff zu sparen. Im Endanflug musste der Pilot nur zwei Anzeigen für die beiden Richtungen "nullen". Beim unbemannten Gemini 2 Test belegte die Software 12250 von 12288 Worten. Das Booten des Rechners dauerte 20 Sekunden. Ursprünglich war geplant für jede Mission ein eigenes Programm zu schreiben. Es zeigte sich aber, dass sehr viele Dinge immer gleich waren, z.B. das Programm für den Aufstieg und die Landung. So begann man die Software in einzelne Module zu zerlegen. Die Software wurde immer größer und so brauchte man bald das Bandlaufwerk. Es gab mehrere Revisionen der Software. Insgesamt 7. Bei IBM benutzte man ein FORTRAN Programm um die kritischen Berechnungen der Steuerung zu kontrollieren. Erstmals eingesetzt wurden Diagnose Unterprogramme und Fehlerschutzroutinen.
Das User Interface Manual Data Insertion Unit (MDIU) bestand aus einem 10 Ziffern Keyboard für numerische Eingaben und einer 7 stelligen Digitalanzeige - Der Rechner ähnelte mehr einem Taschenrechner als einem Computer. Die ersten 2 Stellen der Digitalanzeige waren die Speicheradresse. 99 Speicheradressen konnten abgefragt werden. Die anderen 5 Ziffern stellten die Daten dieser Speicherstelle an. Bei einem Fehler zeigte die Speicherstelle eine 00 an. Daten wurden ebenso eingegeben, negative Daten indem man als erste Ziffer eine "9" eintippte und dann die Zahl ohne Vorzeichen.
Der Computer war bei Gemini nicht dauernd an, sondern er wurde nur nach dem Start für besondere Manöver hochgefahren. Das Selbststart und Testprogramm brauchte 20 Sekunden dazu. Da Ringkernspeicher ihre Daten nicht verlieren wenn sie keinen Strom haben, gab es alle Daten noch. Bei Gemini 4 klappte das Abschalten des Computers nach Eingabe der Reentry Daten nicht und das Manöver musste manuell durchgeführt werden. Zusätzlich zu den Berechnungen des Computers nahmen auch die Astronauten eine Berechnung mit Papier und Bleistift vor und die Bodenstation ebenso. noch traute man dem Computer alleine nicht.
Für IBM bedeutete der Computer eine große technische Herausforderung. Er war der erste IBM Computer der vollständig aus Silizium Halbleitern gefertigt wurde. Er musste extrem klein und zuverlässig sein. Bei einem Test schaltete man den Computer wieder ein, nachdem er 2 Wochen in Salzwasser lag - und er arbeitete genauso wie vorher.
Der Computer für Apollo
musste erheblich mehr leisten als der von Gemini. Zum einen war da die Funkverzögerung von je 1.5 Sekunden beim Mond. (Hin und zurück also
mindestens 3 Sekunden). Dies konnte in kritischen Situationen das Scheitern der Mission bedeuten, wenn sofort reagiert werden musste. Zum
anderen fanden bestimmte Manöver wie das Einschießen in die Umlaufbahn ohne Funkkontakt hinter dem Mond statt. Ohne einen Computer wäre die
Mondmission in der geplanten Art nicht durchführbar gewesen.
Schon 1961 machte man sich daher an die ersten Konzepte für den Apollo Bordrechner. Man entschied sich schließlich für identische Rechner in der Kapsel (CM) und im Mondlander (LM). Die Software war jedoch unterschiedlich, da der Lander auf dem Mond landen sollte, während das CM zum Mond starten und zurückkehren sollte.
Erstaunlicherweise kam der Rechner nicht von einem Computerhersteller sondern von dem MIT. Ausschlaggebend war die Erfahrung des MIT Instrumentation Labs mit dem Borcomputer der Polaris Rakete, dem ersten miniaturisierten Computer für militärische Anwendungen (und damit sowohl von den Umweltbedingungen wie auch den Anforderungen am ehesten mit Apollo vergleichbar. 1962 wechselte dann auch das gesamte Polaris Entwicklungsteam zur Entwicklung des AGC (Apollo Guidance Computer). Der Auftrag für den AGC war der erste Großauftrag der im Apolloprogramm vergeben wurde.
Der Rechner hatte Abmessungen von 61 × 32 × 15 cm. Er wog 31.7 kg und verbrauchte 70 Watt Strom bei 28 V Spannung. Im Standby Modus waren es noch 15 Watt. Dazu kamen die hier abgebildeten Bedienungseinheiten die je 20 × 20 × 17.5 cm groß waren und 8 kg wogen. Zwei davon waren im CM und eines im LM.
Während der jahrelangen Entwicklung gab es zwei Muster,
genannt Block I und Block II. Block I kam niemals in bemannten Flügen zum Einsatz. Block I bestand aus einzelnen Transistoren, Block II dagegen
weitgehend aus Gattern in integrierten Schaltungen, auch wenn diese nur wenige Transistoren bei der damals verfügbaren Integrationsdichte
beinhalteten. Block I hatte einige gravierende Nachteile:
Das MIT entschloss sich 1962 Block I zu entwickeln um die
Software und das Konzept zu überprüfen, aber die eigentlichen Flugrechner in integrierten Schaltungen zu fertigen, die damals gerade einmal
3 Jahre alt waren, weil die Vorteile einfach auf der Hand lagen: Das Block I Konzept war schlicht und einfach zu langsam. Block I flog bei
den Missionen Apollo 6
Für den Rechner wurde eine Wortbreite von 16 Bit gewählt. Alle Berechnungen erfolgten in diesem Format, d.h. es gab keine Fließkommazahlen. Für höhere Genauigkeiten gab es Doppelwort und Triplewortberechnungen, die jedoch nur für bestimmte Navigationsvariablen gewählt wurden, diese konnte man dann als Festpunktvariablen interpretieren. Die Taktfrequenz betrug 1 MHz.
Der gesamte Rechner bestand aus zwei Packs mit je 24 Modulen die jedes 60 logische Flatpacks mit je zwei Gattern in 72 Pin Einschüben enthielten, insgesamt also bis zu 5760 einzelne Chips. Jeder Chip war dabei identisch, es war ein einfaches Gatter: bestehend aus drei Transistoren und vier Widerständen. Dies war ein Gatter in NOR Logik, das eine boolesche Nicht - Oder Operation auf die 3 Eingänge durchführt. Zusammen hatte der ganze Rechner etwa 5000 dieser Chips, (nicht alle der 5760 Plätze wurde genutzt) mit insgesamt 15.000 Transistoren. Apollo hatte dadurch einen enormen Bedarf an integrierten Schaltungen. Es wurden unzählige davon für Prototypen, zum Testen der Verdrahtung und für die Auslese ("space qualified" wurden nur die besten) benötigt. 1963 erreichte dies einen Spitzenwert: 60 % der Schaltungen, welche die USA fertigten, gingen in irgendeiner Weise ins Apollo Programm.
Die Instruktionsbreite war fest. Von den 16 Bits war immer Bit 0 als Paritätsbits genutzt um Verfälschungen der Daten zu erkennen. Reine Datenworte nutzten 14 Bits für die Daten und ein Bit für das Vorzeichen. Instruktionen nutzten 3 Bits für den Opcode und 12 Bits für die Adresse.
Der Rechner verfügte über 6 Register mit 12 Bits
Breite. Die Register waren in Flip-Flops ausgeführt. Eine Verschiebung und Addition eines Offset (wie beim
8086 10 Jahre später) ergab dann den vollen Adressbereich von 16 Bits also 64 KWorten oder 128 KByte.
Der Takt lag bei einem Megahertz. Die Zeit für eine Addition betrug 20 µs. Im Mittel wurden 42.000 Instruktionen pro Sekunde abgearbeitet.
Der Speicher wurde im Laufe der Entwicklung immer mehr erweitert. Anfangs meinte man mit 4 K Worten Nur-Lese Speicher und 256 Worten löschbaren Speicher auszukommen. Zuletzt umfasste der Speicher schließlich 36 KWorte (72 KByte) ROM und 2 KWorte (4 KByte) RAM.
Der gesamte Speicher bestand aus Ringkernspeichern, allerdings vollkommen unterschiedlicher Architektur. Der löschbare speicher" (äquivalent unserem RAM) verwandte einen Ringkernspeicher um ein Bit zu speichern. Sie waren wie in Großrechnern auf einer Matrix von Drähten aufgehängten und neben den X und Y Drähten war ein dritter, der auslesedraht durch jeden Kern geführt.
Der "feste Speicher", äquivalent unserem ROM
speicherte pro Ringkern dagegen 64 Bits. Jeder Ringkern fungierte als Miniaturtransformer. Jeder Kern wurde von 64 Drähten, gehörend zu vier
16 Bit Worten umflossen. Führte der Draht durch den Ring durch, so stand dies für eine "1", führte der Draht um den Kern herum, so war dies
eine "0". Jeder Ringkern konnte so für 64 Bits genutzt werden. Das Verdrahten führten zuerst Frauen mittleren Alters durch, da es als eine
Arbeit galt für die man viel Geduld, aber auch Konzentration aufbringen musste und sie (wohl durch Familie und Kinder abgehärtet) die geringste
Fehlerquote hatten. Später gab es Hilfen in Form von Maschinen welche die Verdrahtung übernahmen, sodass nur noch das Bitmuster vorgegeben
werden musste. Das "weben" von Software war aber eine besondere Fähigkeit, das Raytheon den dafür spezialisierten Arbeiterinnen (im Fachjargon
"Litte old Ladies LOL genannt") sogar bezahlte wenn sie nichts zu tun hatten, weil die Softwareauslieferung sich verspätete und sie nicht
in andere Projekte abzog um ihre Qualifikation nicht absinken zu lassen. Bedingt durch die Mehrfachverwendung von Ringkernen konnte man 2000
Bits pro Kubikzoll speichern. Der Festwertspeicher bestand aus insgesamt 1.024 Speicherbänken. Die Verdrahtung erhöhte nicht nur die Speicherdichte
sondern machte ihn auch zu einem Permanantspeicher.
Bei Apollo Missionen waren die Astronauten schwer damit beschäftigt
Werte in den Rechner einzutippen die ihnen die Bodenstation funkte. Als man bei Apollo 13 durch den Missionsabbruch zahlreiche zusätzliche
Manöver durchzuführen hatte, wurde das Papier an Bord recht knapp. 10500 Tastendrücke erforderte im Mittel eine Mission - Die NASA hatte am
Boden zwar alle Werte, die der Rechner ausgab. Es gab aber keine Möglichkeit den Computer zu programmieren. Da hatten die Astronauten durchgesetzt, die nicht wollten, das etwas über ihren Kopf
hinweg entscheiden wurde. Die Astronauten gaben ein Verb und einen nummerischen
Wert ein wie "DISPLAY + VELOCITY" oder "LOAD + ANGLE".
Der Speicher bestand wieder aus Ringkernspeichern: 6 Modulen mit je 6144 Worten à 16 Bit. Jedes Modul zerfiel zudem in 6 Bänke. Von den 36 Bänken konnten die ersten 2 direkt mit 12 Bit Adressiert werden der Rest über eine Verschiebung. Der Speicher musste Monate vor der Mission programmiert werden, wobei es keine Möglichkeit gab, die Software am Original zu testen. Telemetriedaten wurden mit 51.2 KBit/sec zur Erde gesandt.
Zusätzlich zum Hauptrechner gab es im LM noch den AGES: Ein Computersystem, welches bei einem Landeabbruch den Lander in einen sicheren Mondorbit einschießen sollte. Man konnte ihn von einem Schalter im LM aus aktivieren. Der Rechner war eine 18 Bit Maschine (5 Bit Instruktionen, 27 verfügbar und 13 Bit Adressen). Die Ausführungszeit umfasste 10-70 Mikrosekunden. Der Rechner hatte je 2 KWorte ROM und RAM und wog 15 kg. Er musste niemals zum Abbruch eingesetzt werden, aber wurde zur Kopplung von LM und CM bei Apollo 11 eingesetzt.
Die Softwareentwicklung fand vorwiegend auf Papier statt - es gab einfach keinen Computer zum Testen. In späteren Projektphasen stand ein Honeywell 1800 Minicomputer zur Verfügung, der mit einem Zehntel der AGC Geschwindigkeit diesen emulieren konnte. Später nutzte man eine IBM 360 für diese Zwecke, jedoch niemals Flughardware. Es gab damals eine große Auseinandersetzung wer die Software schreiben sollte: Das MIT plädierte für Programmierer, welche von den Ingenieuren erklärt bekamen wie die Instrumente und Aktoren funktionierten. Die Entwickler des Apolloraumschiffs und das Manned Space flight Center plädierten für den umgekehrten Weg: Die Ingenieure, welche ihre Hardware viel besser kannten als die Programmierer sollten einfach Programmieren lernen. Da MIT die Hardware fertigten konnte sie sich jedoch mit ihrer Philosophie durchsetzen. Die einzige Dokumentation die es beim Start von Apollo 11 gab bestand allerdings in einem Listung des Computercodes, den Aldrin und Armstrong lesen können mussten und dieses Listing flog auch zum Mond und zurück.
Um eine erhöhte Zuverlässigkeit zu erreichen
implementierte man ein einfaches Multitasking System: Die Aufgaben wurden in Tasks eingeteilt und alle 20 ms wurde nachgesehen ob ein Task
mit höherer Priorität die Aufmerksamkeit benötigte. In diesem Fall hätte man die Ergebnisse des unwichtigeren Tasks verworfen. Trotzdem kam
es bei der Apollo 11 Landung zu einer Überlastung des Rechners des LM, als das Landeradar 85 mal pro Sekunde die Aufmerksamkeit erforderte.
15 % der Zeit war der AGC nur noch mit dem beantworten dieser einen Anfrage beschäftigt und er signalisierte dies mit einem Überlastungsfehler.
Man hatte dies allerdings schon bei einer Übung bemerkt und wusste, das der Computer seine Aufgabe erfüllen konnte, solange es nicht zu einer
dauerhaften Überlastung kam. Dies rettete die erste Mondlandung. Im Mittel gab es 40 Prozesse gleichzeitig abzuarbeiten. Die Software wurde
missionsspezifisch geschrieben, beginnend 10.5 Monate vor der Mission, mit einem Einfrieren des Standes 2.5 Monate vor dem Start.
Gefertigt wurden 75 AGC und 138 Display/Keyboard Einheiten. Davon 57 Block II Geräte mit den zugehörigen 102 DSKY. Gefertigt wurde der Computer von Raytheon, bei dem die Belegschaft durch diesen Auftrag von 800 auf 2000 über einige Jahre anstieg. Als man die Computer testete fielen 2 der Block II Geräte und 50 % der Block I Geräte durch die Vibrationstests. Dies lag an der Kontamination durch Partikel. Später gab es bei den Block II Probleme durch die zu langsame Ausbreitungsgeschwindigkeit von Signalen in den Schaltungen und dadurch zu Ausführungsproblemen. Dies konnte durch den wechseln von Nickel-Verbindungskabeln auf eine Zwischenschaltung gelöst werden.
Durch seine lange Entwicklungszeit war der Apollo Guidance Computer wie die meisten Computer an Bord von Raumfahrzeugen schon technisch überholt als Apollo 11 1969 zum Mond flog. Im Jahre 1982 erreichten Heimcomputer wie der C-64 das Leistungsniveau einen AGC. Im Jahre 2002 baute John Pultorak ihn in vierjähriger Arbeit nach und investierte dabei rund 3.000 Dollar für die Einzelteile.
Bei Skylab fand zum
ersten Mal "normale" Industrietechnologie für den Bordrechner Anwendung: Er war eine weltraumtaugliche Version des IBM 4Pi oder IBM 360 Systems.
Vorherige Computer in bemannten Raumfahrzeugen, wie auch in Raumsonden, waren Spezialentwicklungen gewesen, mit eigener Architektur und eigenem
Befehlssatz. Das IBM 360 System war der damalige Verkaufsschlager von IBM. Es war ausgelegt, um weit skalierbar zu sein – reichte die Rechenleistung
nicht aus, so konnte die Zentraleinheit ausgetauscht werden, die Programme musste nicht verändert werden. IBM 360 Rechner in den höheren Ausbaustufen
wurden schon in der Missionskontrolle in Houston eingesetzt. Die Entwicklung der Hardware erfolgte von 1968 bis 1972. Erste Prototypen wurden
1971 ausgeliefert.
Anders als beim Zentralprozessor des 360 Systems, wurde eine 16 Bit anstatt 32 Bit Technologie gewählt, um das Design einfacher zu halten. Die CPU „TC-1“ war aber auf Softwareseite kompatibel zum AP 101, einer militärischen Version des IBM 360 Systems, welches z.B. in den B-52 Bombern und F105 sowie F-15 Jagdflugzeugen eingesetzt wurde. Eine Variante dieses Rechners, der AP101F wurde danach im Space Shuttle eingesetzt.
Der Skylab Computer war konzipiert als Apollo Telescope Mount Digital Computer (ATMDC). Er war missionskritisch. Daher war er redundant vorhanden. Zwei Rechner mit je 16 Kiloworten Speicher teilten sich die Arbeit. Sie waren Bestandteil des Kontrollsystems (Attitude and Pointing Control System (APCS). Der Speicher bestand aus zwei Modulen mit jeweils 8 KWorten RAM, realisiert in Ringkernspeichern. Der Gesamtspeicher betrug somit 32 KByte, da ein Wort 16 Bit breit war, also zwei Bytes umfasste.
Der Speicher bestand aus Ringkernspeichern. Ringkernspeicher waren vor Einführung von Halbleiterspeichern (den heute üblichen RAM Bausteinen) der übliche Speicher für Großrechner bis Anfang der siebziger Jahre. Sie bestehen aus vielen kleinen Eisenringen, die auf einer Matrix von Drähten aufgehängt sind. Zusätzlich durchzieht ein Lesedraht jeden Ring. Beschrieben wird ein Ringkern, indem die entsprechende Spalte und Zeile unter Strom gesetzt wird. Nur am Kreuzungspunkt reicht der Strom aus, die Magnetisierung des Eisenrings zu verändern. Ausgelesen wird ein Ringkernspeicher, indem je nach vorheriger Magnetisierung ein Strom im Lesedraht induziert wird oder nicht. Bei Skylab war der Speicher so ausgelegt, dass ein Auslesen den Inhalt zerstörte. Daher verfügte jedes Speichermodul über Pufferregister, das das letzte ausgelesene Wort aufnahm, bevor es zum Prozessor weitergeleitet wurde. Danach wurde der Inhalt des Datenwortes neu geschrieben, um den Speicherinhalt wiederherzustellen. Durch diese Vorgehensweise und die bei Ringerkernspeichern systembedingten langsamen Zugriffszeiten war der Prozessor von Skylab nicht besonders schnell.
Eine Logik schaltete zwischen beiden Modulen um. Adressiert konnte direkt nur eines der beiden Module. Es gab pro Prozessor eine I/O Sektion und für beide Computer eine Stromversorgung und eine „Common Section“. Nur jeweils einer der beiden Rechner war an den I/O Bus angebunden und wurde mit Strom versorgt.
Die gemeinsame Sektion verband beide Computer und beinhaltete ein 64 Bit Transferregister, das aus dreifach redundanten Schaltkreisen bestand. Weiterhin gab es dort redundante Timer und eine Logik für Mehrheitsentscheidungen: Signale von drei Ein-/Ausgabeleitungen (desselben Signals) wurden verglichen und bei einer Abweichung die abweichende Leitung abgeschaltet.
Anders als bei Apollo oder Gemini, wo die Missionen maximal 14 Tage dauerten, war eine Zuverlässigkeit über 600 Stunden gefordert, die das System auch bei Tests erfüllte. Man schaltete bei den Einsatzrechnern nach 630 Stunden von einem auf den anderen Rechner um. Dieser arbeitete dann die nächsten 271 Tage ununterbrochen. (über 6.500 Stunden). Um dies zu gewährleisten, baute IBM zehn Rechner, obgleich nur zwei für den Flugbetrieb gebraucht wurden. Das System übertraf die geforderte Lebensdauer und konnte auch nach 4 Jahren und 30 Tagen ohne Kontrolle der Umweltbedingungen reaktiviert werden. Kurz vor dem Wiedereintritt wurden erneut auf den ersten Computer umgeschaltet und auch probeweise das Bandlaufwerk erneut aktiviert: Beide Komponenten arbeiteten nach 6 Jahren noch einwandfrei.
Wie bei Gemini wurde die Anlage zuerst ohne einen Bandspeicher konzipiert. Doch Ingenieure banden ein Bandlaufwerk ein, um die Zuverlässigkeit von 0.87 auf 0.96 während der nominellen Mission zu erhöhen. Das Bandlaufwerk hatte einen eigenen 16 KWort Zwischenspeicher und einen 8 KWort Transferpuffer zur Übertragung in eines der Module. Durch diesen Speicher dauerte ein Upload des gesamten Computerprogramms vom Band nur 11 s und man konnte den Computer noch betreiben, wenn drei der vier 8 KWort Speichermodule ausgefallen waren.
Ein Problem war von Anfang an der knappe Speicher. Der TC-1 hatte nur halb so viel Speicher wie der Apollo Guidance Computer. Die ersten Anforderungskataloge an die Software zeigten, dass diese zwischen 9.000 und 20.000 Worte groß war. Ein Schrumpfen war also unumgänglich. Es gab zudem ein Problem: Wenn nun ein Speichermodul auffallen sollte, lief dann der Computer noch? So baute IBM zwei Programme. Eines das den vollen Speicher beanspruchte und ein Back-up-Programm nur mit den nötigsten Einstellungsmöglichkeiten das nur 8 KWorte also ein Modul beanspruchte. Am Schluss beanspruchte die „große“ Software 16.329 von 16.384 Speicherzellen.
Sie teilte die Aufgaben nach zwei Gebieten ein: den wesentlichen Systemaufgaben, die prioritätsgesteuert abliefen (Interrupt abarbeiten, Multitasking Betriebssystem, Steuerung des Intervalltmers und wesentliche "Housekeeping" Funktionen). Die zweite Gruppe waren die "Anwendungen": zeitabhängige Aufgaben, synchrone Aufgaben und Hilfsprogramme. Für diese gab es zwei Zeitschleifen, die einmal oder fünfmal pro Sekunde aufgerufen wurden. Zweimal pro Sekunde wurde die Routine zum Wechseln des Prozessors (falls nötig) aufgerufen.
Die wichtigste asynchrone Aufgabe war das Senden von Telemetrie. Die Datenrate betrug 50 Bit/s. Gesendet wurde auf 24 Kanälen. Ein Datenwort hatte eine Länge von 35 Bit. Der Computer steuerte die Gyroskope, das ATM, führte Selbsttests aus etc. 15 % der Zeit entfielen auf Leerlauf. Dadurch gab es eine Reserve, wenn eine Aufgabe mehr Rechenzeit erforderte.
Das Back-up-Programm war am Schluss 8001 Worte groß. Die wesentlichsten Einschränkungen, die es hatte, waren Einbußen bei der Lagereglung, der Steuerung des Sonnenteleskops und der Datenverarbeitung. Die gesamte Software wurde in Maschinensprache (Hexadezimalzahlen) codiert. Man erwog 1978 für eine Reaktivierung Skylabs Assembler einzusetzen, fand dies jedoch zu riskant. Gesichert wurde es am Boden in 2516 Lochkarten.
1366 Worte des Programms dienten Selbsttests. Sie schrieben in Register Werte und lassen sie wieder aus, sie testeten, ob die OR-Funktion korrekt ausgeführt wurde oder das Carry Flag gesetzt wurde. Damit konnten Teiledefekte der aus vielen Chips bestehenden CPU erkannt werden oder Fehler in den Speichermodulen. Weiterhin gab es drei Timer, die einmal pro Sekunde zurückgesetzt werden mussten, sonst liefen sie auf 0 herunter. Kam dies bei zwei der drei Timer vor, so ging die Logik von einem Ausfall des Computers aus und schaltete auf den Sekundärcomputer um. Da dieser erst hochgefahren werden musste, brauchte er noch die wesentlichen Statusdaten des ersten Computers. Dazu gab es ein 64-Bit-Transferregister, welches die wesentlichsten Informationen enthielt, die der zweite Computer brauchte. Dieses Register aus TMR (Triple Modular Redundant) Bausteinen wurde besonders vor unbeabsichtigten Schreibzugriffen geschützt. Das Schreibintervall war nur über eine Dauer von 675 Mikrosekunden möglich, dies war 20% länger als ein Schreibzugriff dauerte und es war nur beschreibbar in einem Intervall von 1,5 – 2,75 s nach dem letzten Schreibzugriff. Zudem war ein Schreibzugriff nur möglich nach einer erfolgreichen Ausführung des Fehlererkennungsprogramms.
Beim Skylab bestand das User Interface in einer einfachen 10-Tasten Tastatur: Werte wurden in Oktal (0..7) eingegeben. Dazu gab es eine Tastatur mit 8 Ziffern für die Eingabe einer Oktalziffer, eine Taste um die Eingabe zu löschen (Clear-Key) und eine Übergabetaste (Enter-Key). Ein Kommando war fünf Zeichen lang. Eine Neuausrichtung des ATM erforderte 20 Eingaben. Dazu kam ein Schalter um den Computer auszuwählen. Er hatte drei Positionen: Aus, Computer 1, Computer 2.
Der Computer war in die Steuerkonsole des ATM eingebaut und in die Bedienung der Experimente integriert. Obwohl die ATM Konsole sehr ergonomisch aufgebaut war (von oben nach unten Aufgaben/Experimentsteuerungen, von links nach rechts Tasten/Anzeigen/Schalter in der zeitlichen Reigenfolge der Aktivierung/Einstellung) fanden die Besatzungen es verwirrend, dass die Eingabe immer in Oktal erfolgte, manche Ausgaben aber in Dezimal und andere im Oktalsystem.
Am Boden erlaubte es die Ähnlichkeit zum IBM 360 System dieses als Simulator für den ATMDC einzusetzen oder diese als Ersatz für einen ATMDC für das Crewtraining zu benutzen. Eine ICM 360/75 wurde eingesetzt um Programme für den TC-1 zu erproben, wobei diese in der Simulation 3,5-mal schneller war und daher Simulationen schneller abliefen als der ATMDC in Realzeit. Eine IBM 360/44 simulierte die Originalhardware in den Simulatoren für die Besatzung.
Skylab Computer |
|
|---|---|
Wortbreite: |
16 Bit Datenworte, |
Speicher (pro Rechner) |
16 KWorte = 16.384 Worte = 262.144 Bit. |
Zugriffszeit: |
1,2 µs |
Technologie: |
Ringerkernspeicher |
Technologie: |
TTL Logik, integrierte Schaltkreise, mehrlagige Verbindungsboards. |
Verarbeitung: |
Byte-Parallel |
Befehle: |
54 |
Geschwindigkeit |
0,06 MIPS |
Arithmetik: |
Festkomma |
Besonderheiten: |
Interruptunterstützung |
Stromverbrauch: |
165 Watt |
Gewicht: |
44,3 kg |
Volumen: |
62 l |
Apollo hatte als Ansatz möglichst viel in Hardware zu verwirklichen und einen für die Anforderungen spezialisierten Rechner zu bauen. Es zeigte aber auch die Grenzen dieses Ansatzes. 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 nun 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 stuert sind die letzten Minuten vor der Landung wenn es in den aerodynamischen Gleitflug übergeht.
Die Erfahrungen bei Skylab wurden im Shuttle verarbeitet: 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 - 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 einen der Rechner von einem anderen Hersteller zu ordern und 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.
Instruktionen konnten 16 oder 32 Bit Ganzzahlen oder - zum ersten Mal - 32,40 oder 64 Bit Fliesskommazahlen umfassen. Die Register teilen sich in 3 Gruppen ein:
Die Fähigkeit zur nativen Fliesskommaberechnung war sehr vorteilhaft. Bei Apollo entfiel ein beträchtlicher Teil der Rechenleistung nur darauf Fliesskommazahlen für Berechnungen in Ganzzahlen umzuwandeln und dann wieder zurückzuwandeln, dabei war die Rechengenauigkeit des Apollo Computers für Fliesskommazahlen recht bescheiden. (32 Bit Fliesskommazahlen haben in etwa eine Genauigkeit von 7 Stellen).
Die Geschwindigkeit betrug 480.000 Instruktionen/sec (Ganzzahlarithmetrik, 325.0000 bei Fliesskommarithmetrik) Die gesamte CPU bestand aus vielen kleinen 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 DGC 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 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 Diskussion 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.
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). 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.
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 Grafiische 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" Betriebsystem. 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.
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. Deise 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 USD. 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 USD, also 400 Dollar pro Codezeile.
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).
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 Meßwerte 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.
Weiterhin flogen auf jeder Mission auch kleinere Rechner mit: vom HP-41C Rechner bis zu speziellen IBM Notebooks die für Daten genutzt wurden die einfach nicht auf den wenigen Displays unterzubringen waren oder missionsspezifischen Programmen.
In den Raumanzügen für die Tätigkeit außerhalb des Shuttles, den EMU's steuert ein relativ bescheidener Computer alle Funktionen die für das Leben des Astronauten notwendig sind: Ein NSC-800 (8 Bit) mit 2 MHz, 32 K ROM und 2 K RAM. Die Software ist in PL/M geschrieben und benötigt 30 der 32 K ROM.
Im Jahre 2000/2001 durchforstete die NASA Internet Auktionen von ebay und anderen Anbietern nach angebotenen IBM-PC und anderen Rechnern mit dem 8086 Prozessor: Diagnosesysteme auf der Erde verwenden diesen Prozessor und er wird seit Jahren nicht mehr hergestellt.
Da Buran nicht nur unbemannt Starten
und Landen können sollte, sondern auch Missionen unbemannt durchführen konnte, war das Computersystem für die Sowjetunion eine große Herausforderung.
Es musste zum einen bei unbemannten Missionen mehr können, als das US Pendant wo der Mensch noch eingreifen konnte. Zum anderen setzte die
Sowjetunion bislang Computer nicht besonders oft in ihrem Raumfahrtprogramm ein und galt im Westen in diesem Bereich als technologisch rückständig.
Das Computersystem musste wie beim US Space Shuttle mehrfach redundant sein. Gefordert war eine Funktionsfähigkeit bei zwei ausgefallenen Komponenten. Das führte zu einem System aus vier Computern. Wenn mehrere Rechner an einem Problem arbeiten, müssen sie synchronisiert werden und sich in regelmäßigen Abständen abstimmen. Das US Shuttle setzte dazu ein prioritätsgesteuertes Betriebssystem ein, also eine Softwarelösung, die alle 40 ms zu einer Synchronisation führte. Derartige Systeme sind komplex und fehleranfällig, wie sich bei dem Erststart der Columbia zeigte, als der Countdown wegen eines Synchronisationsfehlers abgebrochen werden musste. Die russische Lösung bestand aus einer Hardware Lösung. Es gab einen zentralen Quarzzeitgeber mit einer Taktfrequenz von 4 MHz der alle 32.8 ms ein Synchronisationssignal zu den vier Bordcomputern sandte. Dann wurden die Ergebnisse verglichen und falls ein Rechner abwich, wurde er von den drei anderen abgeschaltet. Gab es zweimal jeweils zwei gleiche Ergebnisse oder blieben nach dem Abschalten von 2 Rechnern nur noch 2 übrig und differierten auch diese in ihren Rechenergebnissen, so wurde einer per Zufall deaktiviert, was zumindest die 50 % Chance einer richtigen Lösung ergab.
Die Softwareentwicklung erfolgte getrennt für die OnBoard Software ("Prol-2") und Bodenanlagen / Tests ("Dipol"). eine dritte objektorientierte Sprache namens "Flok" verband dann beide Softwaresysteme. Die folgende Tabelle informiert über die Computer von Space Shuttle und Buran. Ein Vergleich ist schwierig, weil die beiden Systemen sich unterscheiden. Das Space Shuttle System gliedert sich in Rechenprozessoren und Ein/Ausgabeprozessoren mit eigener Intelligenz. Bei Buran gibt es diese Unterteilung nicht. Hinsichtlich Rechengeschwindigkeit und Speicherkapazität sind beide Systeme aber vergleichbar. Buran verfügt sogar über mehr Speicher und eine weitaus höhere Busübertragungsrate.
Das Cockpit orientierte sich an den Erfahrungen
die man vorher mit anderen Raumstationen wie Saljut machte. Es gab zahlreiche analoge Anzeigeinstrumente und Schalter, aber nur drei Monitore.
Die US Space Shuttles hatten deutlich mehr Monitore eingebaut, die allerdings seit 1998 auch auf drei reduziert wurden (allerdings mit erheblich
verbesserten Anzeigefähigkeiten).
| Parameter | Buran | Space Shuttle |
|---|---|---|
| Geschwindigkeit | 370.000 Operationen/s | 480.000/s |
| Bitbreite | 32 Bit | 32 Bit |
| Speicherkapazität RAM | 132 KWorte | 80+24 KWorte |
| Speicherkapazität ROM | 16 KWorte | 0 |
| Speicherkapazität Magnetband | 800 KWorte | 700 KWorte |
| Gesamtzahl an Prozessoren | 74 | |
| davon I/O Prozessoren | 4 | 24 |
| Bussysteme | 21 | 24 |
| Busbreite | 36 Bits | 28 Bits |
| Übertragungsrate Bus | 61440 Worte à 36 Bits = 2.2 MBit/s | 1 MHz |
| Meßfrequenz für Sensoren | 0.25 MHz | |
| Stromverbrauch | 270 Watt | 350 Watt (600 mit IOP) |
| Nominalspannung | 27 V | 28 V |
| Betriebstemperatur | -10 bis +50°C | |
| Gewicht | 33.6 kg | 27.3 kg ohne IOP |
Von der ISS sind seitens der ESA die Daten
ihrer Computerhardware bekannt. Die ESA ist mit zwei Computersystemen beteiligt: Zum einen dem DMS. Es steuert das russische Modul Swesda
und übernimmt Lenkungs- und Navigationsaufgaben für die ganze Station. Kernstück des 50 kg schweren DMS sind vier Rechner: Zwei zur Steuerung
der Swesda und zwei zur Steuerung des Außenarmes und für Andockvorgänge. Jeder der Rechner hat einen SPARC Prozessor mit 6 MB RAM und 8 MB
ROM - wenig im Vergleich zu irdischer Hardware, aber viel im Vergleich zum Space Shuttle. Die Rechner sind fehlertolerant und bestehen aus
3 Untereinheiten die separat ausgetauscht werden können. Jeder der vier Rechner benötigt nur 40 Watt Strom.
Die Kommunikation geschieht über den MIL STD Bus, einem Bus den die NASA für ihren Prozessor MIL 1750 A eingeführt hatte. Der Bus ist heute veraltet, doch reicht die Geschwindigkeit von 1 MBit/s für die Stationsdaten aus. Er ist dafür durch besondere Protokolle sehr sicher.
Weiterhin gibt es auf dem europäischen Labor Columbus einen weiteren Rechner der sich an den DMS anlehnen wird. Für die Steuerung der Experimente hat die ESA wird der SPLC eingesetzt. Dieser Rechner soll die Experimente steuern und als Neuerung soll er es erlauben sich an jedem Ort der Station mit Notebooks einzuwählen und von dort aus die Daten abzurufen.
Basis des SPLC genannten Computer ist eine Architektur auf dem VME BUS. Er basiert auf dem SPARC V7 Prozessor, besitzt 8 MB SRAM und 4 MB EEPROM Speicher. Als Massenspeicher wird eine 50 MB große EEPROM "Disk" benutzt. Sie hat Interfaces für mehrere Filesysteme, darunter auch DOS. Die Kommunikation geschieht über 6 serielle RS 422 Schnittstellen und Anschlüsse für 6 Mezzantine Boards. Als Betriebssystem findet VxWorks Verwendung.
Die Mezzantine Boards sind die wechselbaren Stechkarten des Systems, ähnlich wie bei einem PC. Es gibt 5 verschiedene:
Spaceref: Space Shuttle Computer
Cooper, Chow: Development of On-board Space Computer Systems
Ein Buchtipp zu diesem Thema: The Apollo Guidance Computer und Digital Apollo
| Sitemap | Kontakt | Neues | Impressum / Datenschutz | Hier werben / advert here | Buchshop | Bücher vom Autor | |