Blog

So nun zum dritten Teil über das primäre Computersystem von Galileo, das CDS. Nachdem sich die ersten beiden Teile nur mit dem RCA 1802, warum er gewählt wurde und seiner Architektur befassten geht es heute um das Computersystem selbst. Der Artikel schließt so an seine beiden Vorgänger gestern und vorgestern an.

Das CDS besteht nicht aus einem Computer, sondern wegen der Langsamkeit des 1802 Prozessors aus deren drei. Dieses System ist nochmals doppelt ausgelegt (aus Redundanzgründen), so das an Bord von Galileo 6 Mikroprozessoren die Steuerung haben. Ein JPL-Dokument spricht davon, dass sie für die Programmierung als eine virtuelle Maschine erscheinen.

Die Aufteilung ist folgendermaßen: Es gibt zuerst einmal zwei Strings mit eigenen Bussen. Es gibt keine feste Zuordnung zu den Bussen. Experimente, Bankrekorder, Sender- und Empfangssystem oder Verbindungen zu Subsystemen des Raumfahrzeugs können jeweils einem Bus zugeordnet werden aber auch dem anderen. Pro String gibt es jeweils ein HLM-Modul, und zwei LLM-Module. Dazu gibt es pro String zwei Bulk-Speicher die Daten zwischenspeichern. Die Bulk-Speicher haben keinen Mikroprozessor. Man kann sie als eine Speichererweiterung ansehen die zwischen den Modulen ausgetauscht werden kann.

Insgesamt gibt es so im CDS (beide Strings zusammen) 6 RCA 1802 Prozessoren (2 in den HLM und 4 in den LLM). Die HLM haben jeweils 32 KByte Speicher, die LLM nur 16 KByte Speicher, die Bulkspeicher haben 8 bzw. 16 KByte. Bei 2 HLM, 4 LLM und 4 Bulkspeichern beträgt der Gesamtspeicher so 176 KByte, Ob es ROM (Read Only Memory, unveränderlicher Speicherbaustein mit dem Betriebssystem) gab, wird unterschiedlich angegeben. Die meisten Quellen weisen kein ROM aus. Auf der anderen Seite ist bei der Teileliste ein 1 KBit ROM angegeben und summiert man das ROM der Experimente auf und vergleicht dies mit der Summenangabe von 41 KByte, so fehlen 9,75 KB. Wenn es ein ROM gab, dann war es sehr klein und wohl nur dafür da, Software ins RAM zu laden. Nötig war ein ROM in der Tat nicht, denn durch die RTG gab es eine dauerhafte Stromversorgung, die anders als bei Solarzellen nie ausfallen konnte oder an Leistung verlor, wenn die Raumsonde durch ein unvorhergesehenes Ereignis fehlorientiert war. 12 KByte des HLM Speichers sollen aber schreibgeschützt sein und ersetzen so ein ROM. Die Software nutzt maximal 85 % des Speichers. 48 KByte des Gesamtspeichers werden für die Flugsoftware genutzt. Sie verarbeitet 600 verschiedene Kommandos. 32 KByte dienen als Datenspeicher und Kommando-Sequencer.

Die HLM (High-Level Modules) steuern wichtige Funktionen des Raumfahrzeuges wie Datenbustransfer, Überwachung des Busses, Fehlererkennung und Schutz. Die HLM sind die Verbindung von Galileo mit den Bodenstationen. An sie werden Kommandos und Programme gesendet, die festlegen was Galileo macht. Sie sind aber nicht direkt mit irgendeinem Subsystem verbunden, sondern nur über den Bus. Jedes HLM hat 32 KByte CMOS Speicher und einen 1802 Prozessor mit einem Buscontroller. Offen ist die Aufteilung. Es gibt sowohl Angaben, dass die HLM redundant sind, also nur eines jeweils aktiv ist und das andere in Bereitschaft einzuspringen wenn das erste ausfällt. Eine andere Angabe ist das ein HLM Realzeitkommandos ausführt, der zweite gespeicherte Kommandos. Es kann sein das beides zutrifft: auch bei Voyager waren die Rechner zuerst nur Stand-By und redundant, dann wurde um die wissenschaftliche Ausbeute zu erhöhen dies beim Vorbeiflug von Voyager 2 aufgegeben und der zweite Rechner übernahm andere Aufgaben wie die Datenkompression die vor dem Start nicht vorgehen war. Jeder HLM konnte einem von zwei Bussen zugeschaltet werden.

Jedes HLM hatte einen Buscontroller, der den Transfer auf den Bus durchführte und den Bus überwachte. Daten wurden in Paketen übermittelt, die einen Kopf mit drei Worten hatten – der Quelle/Empfänger, die Startadresse im Speicher wo das Paket landen sollte und Füller für das Timing, Die Datenübertragung wird von dem Realzeitinterrupt gesteuert. Es wechseln sich jeweils ein Interrupt für Eingaben mit einem für Ausgaben ab. Der Bus hatte eine Datentransferrate von 403,2 Klobit/s. Die maximale Datenrate im Raumfahrzeug war höher: zwei Experimente und der Bandrekorder hatten Modi in denen sie schneller Daten übertrugen. Bei dem Kamerasystem erfolgte das Auslesen direkt durch die Hardware, hier konnte eine Spitzendatenrate von 806,4 KBit/s erreicht werden. Ebenso hatte der Bandrekorder eine maximal Datenrate von 787,6 Kbit/s. 806,4 Kbit/s war auch die maximale Datenrate des Telemetriesystems. Es besteht die Möglichkeit, dass zwei LLM und zwei Strings genutzt wurden, also abwechselnd ein Paket auf jeden Bus gelegt wurde. Sowohl die maximale Datenrate wie auch die Busdatenrate leiteten sich vom Prozessortakt von 1,6 MHz durch Teilen durch zwei bzw. vier ab.

Die beiden Strings von HLM hatten verschiedene Operationsmodi. Während der CRUISE-Phase und unkritischen Missionsphasen war nur ein HLM aktiv. Während kritischer Missionsphasen arbeiteten beide HLM dasselbe Programm ab und sandten beide Kommandos zu den Subsystemen. Daneben gab es noch einen Tandem Mode, in dem die Aufgaben auf beide HLM verteilt wurden z.B. das eine sich nur um die Eingaben und das andere um Ausgaben kümmerte. Tritt in diesem Modus ein Fehler in einem String auf, so wird der zweite Bus angehalten.

An jedem der beiden Busse hingen je zwei LLM (Low Level Module). Ein LLM führte spezialisierte Aufgaben aus. Es gab pro String zwei LLM. Ein LLM sandte Daten und Telemetrie mit niedriger Datenrate zur Erde. ein LLM empfing die Daten von den Experimenten mit niedriger Datenrate und gewann die Daten über den Zustand des Raumschiffs. Nach den Diagrammen unterscheiden sich zumindest zwei LLM in den Daten die sie senden, während die anderen beiden die Daten gewinnen identische Aufgaben haben. Je zwei LLM befanden sich in der dreiachsenstabilisierten Sektion und in der rotierenden Sektion. Das erste Paar kontrollierte den Status der Raumsonde, das zweite überwachte die Atmosphärenprobe und hielt Verbindung mit der IUS Oberstufe. Jedes LLM Sektion hatte einen RCA 1802 Prozessor mit 16 KByte Speicher.

Dazu kamen vier Speichermodule, ohne Prozessor. Auch hier waren es zwei Module die jeweils redundant waren. Diese Speichermodule hießen Bulk Memory (BUM) und Data Bulk Memory (DBUM). Die DBUM hatten jeweils 8 KByte. DBUM wurde von den Instrumenten zum Ablegen der Daten benutzt. DBUM diente auch als Datenbuffer zum Zwischenspeichern von Realzeitdaten und für den Transfer zum Bandlaufwerk. Die LLM und HLM hatten über DMA Zugriff auf diesen Speicher. In den BUM wurden Kommandos von der Erde zwischengespeichert und es diente als Puffer für die Daten die mit hoher Datenrate übertragen wurden. Die BUM hatten 16 KByte Speicher. Die BUM und DBUM dienten auch zum Transfer von Daten zwischen den LLM und HLM. Nutzbar waren zu einem Zeitpunkt aus Programmierersicht 80 KByte.

Die Synchronisation von so vielen Prozessoren ist eine komplexe Aufgabe. Normalerweise stimmen sich die Bausteine in einem Multiprozessorsystem über Interrupts ab. Wenn ein Ein-/Ausgabe-Baustein ein Ereignis registriert, z.B. weil der Anwender auf eine Taste bei der Tastatur tippt, sendet sie ein Signal an den Mikroprozessor das ihn veranlasst das laufende Programm abzubrechen und er springt in eine Interrupt-Service Routine, in der er feststellt was den Interrupt ausgelöst hat und ihn behandelt. Danach setzt er das Programm an der Stelle fort wo er vorher aufgehört hat. Bei so vielen Bausteinen ist das sehr komplex und die Gefahr ist groß das der Rechner abstürzt weil er mit dem Abarbeiten von Interrupts nicht nachkommt. Die Lösung bei Galileo war dieselbe wie bei einfachen Multi-Tasking Betriebssystemen. Es gab nur einen systemweiten Interrupt der zyklisch alle 2,5 ms zu allen Komponenten gesandt wurde. Jede Aufgabe musste so programmiert werden das sie in 2,5 m s abgearbeitet ist. Mit dieser Periode wurden auch Datentransfers durchgeführt. Die Systemsoftware hatte zwei Zeitscheiben, einen von ¹/₁₅ Sekunde Dauer für Vordergrundprozesse und einen zweiten von einer ²/₃ Sekunde für Hintergrundprozesse die sich wiederum in privilegierte und nicht-privilegierte Prozesse einteilen. Es gab nur drei Vordergrundprozesse, den Selbsttest, die Softwarezeituhr und die Buskontrolle. Hintergrundprozesse waren deutlich komplexer und nutzten eine „virtuelle Maschine“ (VM). Es wurde darauf geachtet, das ein typischer Prozess nicht mehr als 150 Assembleranweisungen hatte. Es gab drei VM, die in den 12 KByte schreibgeschütztem Speicher saßen, und privilegiert waren. Nicht-privilegierte Prozesse können gestoppt werden wenn sie nach ihrer Zeitscheibe von ²/₃ Sekunden nicht fertig sind. Auch nicht privilegierte Prozesse nutzten eine VM. Privilegierte VM führten Kommandos direkt aus, entdecken Fehler und kontrollierten allgemein, nicht privilegierte VM waren für das Speichern und Sequenzen von Kommandos zuständig. Daten zwischen den VM wurden über den Bus ausgetauscht. Ein Transfer musste in ¹/₁₅ Sekunde beendet sein. Jede VM konnte mehrere Programme (bis zu 10) ausführen. Nicht-Privilegierte Prozesse wurden typisch einmal pro Woche mit Softwareupdates versorgt.

Die Software des LLM ist deutlich beständiger. Sie haben mehr die Aufgabe eines Mikrocontrollers. Sie fragen die Experimente ab, überwachen die Subsysteme des Orbiters, tragen Telemetrie zusammen und kommunizieren während der Startphase mit der IUS-Stufe.

Das Busystem hatte einen Takt von 403,2 kHz, die Hälfte des Prozessortaktes von 806,4 kHz. Es arbeitete ohne Handshake mit synchroner Datenübertragung, das heißt Empfänger und Sender mussten zum richtigen Zeitpunkt den Bus auslesen. Für Interrupts gab es eine Echtzeituhr, die an den Prozessor 15-mal pro Sekunde einen Interrupt sandte.

Man fand keinen adäquaten Compiler für die schon in anderen Projekten eingesetzte Sprache HAL-S (in ihr wurde die Space Shuttle Software geschrieben und sie wurde eigens für Raumfahrtprojekte entworfen) für den 1802, so dass die gesamte Software mit „strukturierten Makros“ in Assembler erstellt wurde, die Namen wie „IF“, „DO“ oder „ASSIGN“ hatten. Die Software des CDS ist interruptgesteuert.

Diese Einteilung ist jedoch Geschichte, denn der Ausfall der HGA machte eine völlige Neuprogrammierung der Sonde notwendig. Im Mai und Juni 1996 wurde eine neue Software auf das System aufgespielt, welche von der Einteilung in einzelne Stränge abrückte. Nun hatte jeder der 6 Prozessoren eine eigene Aufgabe zu erledigen. Darunter die Kompression verlustlos (Faktor 2.54) oder verlustbehaftet nach dem DCT Verfahren (Faktor 3-31). Die Plasmadaten mussten sogar um den Faktor 80 komprimiert werden. Neben den Prozessoren im CDS gab es noch 11 weitere RCA 1802 in den Experimenten an Bord.

Die Experimente sind auch an das CDS angeschlossen, das bei Galileo sowohl für die Verarbeitung von Kommandos (das können auch „Programme“ mit Schleifen sein) wie auch die Verarbeitung der Daten der Experimente verantwortlich ist. Hier war die Integration der Mikroelektronik ein großer Fortschritt: Jedes Experiment ist über eine isolierte Schnittstelle mit einem Busadapter für direkten Speicherzugriff an den Datenbus des CDS angeschlossen. Steuerungs- und Datenleitungen des Mikroprozessors liefern Interrupts, serielle und/oder parallele Daten von Instrumentenkomponenten wie Registern, Puffern, Analog-Digital-Wandlern, Multiplexern und Halbleitersensoren. Diese Datensysteme nutzen das Kommunikationsprotokoll der CDS-Hardware und -Software, decodieren und verarbeiten Instrumentenbefehle, stellen Instrumentenbetriebsmodi zur Verfügung, steuern die Instrumentenmechanismen und erfassen, verarbeiten, formatieren und geben wissenschaftliche Instrumentendaten aus. Dieser Ansatz hat zu vielen konkreten Verbesserungen gegenüber früheren Missionen geführt. Zu den wichtigsten zählen: erhöhte Instrumentenautonomie, funktionale Befehlssteuerung und Makromodus-Generierung; verbesserte Telemetrieausgabe sowohl aus operativer als auch aus wissenschaftlicher Sicht; zusätzliche Flexibilität für die Optimierung während des Fluges, Problemumgehungen und die Instrumentengeneralisierung zur Unterstützung mehrerer Missionen. Experimente hatten typisch 3 bis 8 Betriebsmodi, während man früher oft Experimente nur aktivieren und wieder abschalten konnte. Es wurde das Experiment überwacht uns so Defekte erkannt, wenn z.B. ein Filter steckenblieb. Die Experimente nutzten die DMA des 1802 und transferierten die Daten direkt in den Speicher des CDS. So kamen sie auch mit dem vergleichsweise langsamen Systembus aus.

Galileo verwandte im CDS TC255 RAM von RCA, das waren 1 Kilobit RAM organisiert in 256 Bit x 4. Ein Baustein speicherte die vierfache Menge der CD4061 RAM Bausteine von Voyager. Noch besser war die Organisation: Voyager setzte 256 x 1 Bit RAM ein. Um ein Wort zu speichern benötigt man weil es nur eine Datenleitung pro Baustein gab, 16 Bausteine. Fiel in einem auch nur ein Bit aus, so musste man 16 Bausteine mit 512 Bytes abschreiben. Beide Voyager haben inzwischen solche defekten Blöcke. Bei Galileo gibt es 4 Datenleitungen und der Prozessor hat eine Wortbreite von 8, das bedeutet das nur zwei Bausteine ein Byte speichern und bei defekten ein 256 Byte Block ausfällt gemessen am größeren Gesamtspeicher ein kleinerer Verlust.

Trotz einige Ausfälle während der erweiterten Missionen hat das CDS ein Vielfaches (etwa das achtfache) der Strahlendosis ausgehalten für das es ausgelegt war (150 krad, etwa die 3000-fache für einen Menschen tödliche Dosis). Trotzdem hat die Sonde, selbst noch als sie am 28.9.2003 gezielt auf Jupiter gelenkt wurde, Daten gefunkt. Es wurden aber gerade bei den interessanten nahen Vorbeiflügen an Io während der letzten Orbits viele Daten verloren weil es temporäre Ausfälle gab die dann zu dem Übergehen in den Safemode gingen oder Bilder unbrauchbar waren.