Home

Raumfahrt

Raumsonden

Voyager

Site Map

Voyagers Bordcomputer

Computer im heutigen Sinn, also frei programmierbare Systeme, wurden vor Voyager erstmals bei den Viking-Sonden eingesetzt. Die Mariners flogen noch mit Sequencern. Ein Sequencer ist eine programmierbare Zeitschaltuhr. Jede Raumsonde wird durch Kommandos gesteuert. Sie schalten Systeme an oder aus, wählen Modi etc. Ein Sequencer führt diese Kommandos zu einem bestimmten Zeitpunkt aus. Mit einem Sequencer konnte die letzte Mariner-Sonde, Mariner 10, durchaus komplexe Abläufe durchführen. Bei ihren Vorbeiflügen an Venus und Merkur gewann sie Tausende von Bilder. Doch ein Sequencer konnte nur das, was beim Start vorgesehen war. Ein Computer kann dagegen umprogrammiert werden. Bei Voyager wurde vor der Uranuspassage ein Kompressionsalgorithmus für die schnellere Übertragung von Bildern implementiert.

Da bei Voyager das Budget begrenzt war, entschied sich das JPL für die Adaption bestehender Viking-Technologie. Voyager ist eine Vorbeiflugsonde und hat deswegen erheblich mehr zu erledigen als die Viking Orbiter. Es wurden die Aufgaben auf drei redundante Computersysteme aufgeteilt. Sie unterteilen sich in:

• CCS: Communication & Command Subsystem: Verantwortlich für die Kommunikation mit der Erde und die Ausführung von Befehlen zur Steuerung der Sonde und der Beobachtungen. Das CCS überwacht die Sondensysteme und enthält Algorithmen zum Abfangen von Fehlern. Bei einem Fehler bringt es die Sonde in einen sicheren Modus. Das CCS stammt vom Viking ab und erledigt die Aufgaben, die auch der Viking Bordcomputer hatte.

• AACS: Attitude and Articulation Control System: Dieses System war für die punktgenaue Ausrichtung der Kameras und der anderen Instrumente auf der Scanplattform zuständig. Weiterhin mussten die Flugbahn und die Ausrichtung der Sonde durch kleine Schubdüsen kontrolliert werden. Es war direkt mit dem Lageregelungssystem verbunden, das zum AACS hinzuzählte.

• FDS: Flight Data Subsystem: Die Voyager Raumsonden verfügten über elf Experimente, die Daten lieferten. Die Daten wurden mit bis zu 115,2 KBaud zur Erde übertragen (mit Kompression und Fehlerkorrekturinformationen) oder auf Magnetband gespeichert. Das machte ein weiteres Computersystem notwendig. Es nahm die Daten von den Experimenten entgegen, und formatierte sie für die Übertragung zur Erde. Das FDS war primär für die Kameras verantwortlich.

Für die TOPS-Raumsonden entwickelte das JPL einen Self-Test And Repair Computer: STAR. Er sollte weiter entwickelt sein als alle bisherigen Computer, die in Raumsonden eingesetzt wurden. So sollte er die Fähigkeit haben, eine Raumsonde über zehn Jahre lang autonom zu steuern. Der STAR-Computer war eine byteserielle Maschine mit einer Bitbreite von 32 Bit. Bei einem Takt von 0,5 MHz hätte der Rechner eine Leistung von 28.000 Befehlen/s erreicht und über 16 KWorte ROM sowie 4 KWorte RAM verfügt. Ein redundant ausgelegtes STAR-System hätte eine Ausfallrate von 0,00018 über sechs Monate und 0,21 über zehn Jahre erreicht.

Der STAR war als bis zu fünffaches System ausgelegt. Die CPU war doppelt ausgelegt (eine dreifach redundante CPU wurde auch erwogen, sie hätte die Wahrscheinlichkeit das ein Computer nach zehn Jahren noch aktiv ist, von 79 auf 95 Prozent erhöht). Der Speicher war bis zu fünfmal vorhanden, weil ein Ausfall bei ihm am wahrscheinlichsten war. Zum Vergleich: Zur selben Zeit, als der STAR entwickelt wurde, starteten die Raumsonden Mariner 6+7 mit einem Sequenzer. Er verfügte über 128 Worte RAM bei einer Ausfallrate von 0,072 über sechs Monate und 0,775 über zehn Jahre. Ein eigenes System namens TARP (Test and Repair Processor überwacht den STAR-Computer und wird bei Fehlfunktionen aktiv. Es kann 99,5 bis 100 Prozent der Fehler erkennen und innerhalb von 50 ms auf ein redundantes System umschalten.

Die Konzeption des Speichers von STAR wurde später bei der Raumsonde Galileo verwendet. Er unterteilte den Speicher in High Level und Low Level Module. Letztere steuern elementare Systeme des Computers und erstere die Experimente und die Kommunikation.

Das Konzept des STAR war zu teuer. Die Adaption des Viking CCS sparte Kosten. Dadurch brauchten die Computersysteme weniger Strom, was einen RTG einsparte. Zusätzliche Sicherheit wurde erreicht, indem Voyager jedes System doppelt einsetzte. Es wurden Schaltungen hinzugefügt, welche den Ausfall eines Computers erkannten und automatisch auf das Reservesystem umschalteten (damals hieß das "Selbstheilende Schaltungen"). Zudem sollten die Rechner nur noch fünf anstatt zehn Jahre lang arbeiten. Auch für das FDS gab es mit dem MPS bei TOPS einen Vorläufer. Schon Viking hatte ein FDS, das jedoch deutlich weniger leisten musste. Das AACS war nötig, weil das CCS diese Aufgaben nicht zusätzlich übernehmen konnte. Auch das zentrales Element des AACS, HYPACE, wurde schon für TOPS entwickelt.

Die Erkenntnisse von Pioneer 10 über den Strahlungsgürtel Jupiters kamen zu spät, um das gesamte Konzept zu ändern. Der Computer befand sich schon in der Entwicklung. Doch es war bei Tests die Strahlung simulierbar, um dem Problem zu begegnen. So wurde die Elektronik durch einen Tantalschild geschützt.

Die Rechner entstanden vor der Erfindung des Mikroprozessors und wurden wie andere Rechner dieser Zeit aus einzelnen Bausteinen zusammengesetzt. Dafür gab es die 74xx Serie von integrierten Schaltkreisen, die jeweils eine bestimmte Funktion hatten. Es gab relativ einfache Bausteine wie den ersten Vertreter 7400, ein vierfaches NAND-Gatter. Doch es gab auch komplexe Bausteine, wie die 4-Bit-Alu 74181, die z. B. auch der Minicomputer VAX oder der Xerox Alto einsetzte. Bei der damaligen Technologie hatten die Bausteine maximal 1.000 Elemente (MSI: Medium Scale Integration, Bezeichnung für die Komplexität eines Chips). MSI war von Mitte der Sechziger bis Mitte der Siebziger Jahre die vorherrschende Technologie der Chipfertigung. Sie ermöglichte 100 bis 1000 Transistoren auf einem Chip. Vorher gab es SSI (Small Scale Integration) mit unter 100 Elementen und danach LSI (Large Scale Integration). In LSI entstanden die 4- und 8-Bit-Mikroprozessoren. Die 16-Bit-Generation basierte dann schon auf VLSI (Very Large Scale Integration). Verwendet wurden Bausteine der 54Lxx Serie, ein Pendant der 74xx Serie für Militärelektronik, die unempfindlicher gegenüber Strahlung und Temperaturschwankungen war, in dem FDS auch die CMOS-Serie 40xx.

Beim Speicher wurde eine andere Technologie eingesetzt. Bei Computer dominierten damals Ringkernspeicher. Die Information wird in einer Matrix aus Ferritringen gespeichert, die auf Drähten aufgefädelt sind. Dabei wird die Information magnetisch gespeichert. Sie kann nur schwer durch geladene Teilchen verändert werden und geht auch ohne Stromversorgung nicht verloren.

Eine Variation des Prinzips von Ringkernspeichern war die Plated Wire Technologie oder Plated Wire Memory. Dabei wurde ein mit einer ferromagnetischer Legierung beschichteter Draht als Speicher benutzt. Ein Draht konnte mehrere Bits speichern. Quer zu seiner Richtung wurde er mit Lesebändern umwickelt, die zusammen mit dem Draht eine Matrix bildeten. Pro Leseband gab es eine Speicherzone. Für das Schreiben wird der Draht unter Strom gesetzt und an das Leseband eine Spannung angelegt, die ein Magnetfeld mit einer bestimmten Richtung induziert. Die Magnetfeldrichtung ist bei Einserbits um 180 Grad im Vergleich zu Nullbits gedreht. Beim Auslesen wird nur der Speicherdraht unter Strom gesetzt. Je nachdem, wie das Magnetfeld beschaffen ist, verändert er den Strom im Lesedraht.

Das physikalische Prinzip von Plated Wire war das gleiche wie bei Ringkernspeichern. Die Drähte benötigten aber mehr Platz. Der wichtigste Vorteil von Plated Wire war, dass eine maschinelle Fertigung möglich war. Beim Ringkernspeicher dominierte lange das manuelle Auffädeln der Ferritkerne. Plated Wire war auch etwas schneller als Ringkernspeicher, aber erheblich langsamer als RAM aus Transistoren. Plated Wire Memory wurde im CCS/AACS und im Viking Bordcomputer eingesetzt. Plated Wire Speicher war auch für TOPS vorgesehen. Das JPL hob als Vorteil hervor, dass das Auslesen nicht-destruktiv erfolgte. Der Speicher konnte auslesen werden, ohne ihn neu schreiben zu müssen.

Lediglich das FDS, der schnellste Rechner von Voyager, verwendet die heutige Technologie von Halbleiterbausteinen. Sie speichert die Daten in einem Flip-Flop, einem Schaltelement aus vier bis sechs Transistoren.

Noch ein Wort zu der Technologie: Rechner griffen damals wortweise auf den Speicher zu. Ein "Wort" war die kleinste adressierbare Einheit. Es entspricht der Verarbeitungsbreite des Rechners, also 18 Bit bei dem CCS/AACS und 16 Bit beim FDS. Die byteweise Adressierung kam erst mit den Mikroprozessoren auf. Entsprechend wurde der Adressbereich und die Speichergröße in Kiloworten und nicht Kilobytes angegeben. Zu den 16/18 Bits pro Datenwort kommen noch Bits mit Paritätsinformationen hinzu, um eine Verfälschung der Daten zu erkennen. Diese zählen nicht zur Speicherkapazität. CCS/AACS haben je 9 KByte Speicher, das FDS 16 KByte Speicher pro Rechner.

Das zweite Konzept, das sich in den Bordcomputern findet, ist das serielle Konzept. Während die meisten damaligen und alle heutigen Computer parallel arbeiten, waren die Bordcomputer seriell ausgelegt. Das heißt, dass das CCS die 18 Bits, die ein Datenwort umfasst, zunächst mit 18 Zugriffen holen muss. Erst dann kann eine Instruktion ausgeführt werden. Der Vorteil ist eine drastische Reduktion der Komplexität bei der Speicheranbindung. Es mussten im Rechner weder 18 Bits verarbeitet werden, noch entsprechende Leitungen gezogen werden. Der Preis ist eine enorme Verlangsamung. Voyagers CCS benötigte 88 Mikrosekunden, um einen Befehl auszuführen. Auch das CCS von TOPS war seriell organisiert, aber mit 4 Bits pro Zugriff, 4 Bits pro Zugriff holten auch das FDS und AACS. Beim TOPS-CCS, von dem die Taktfrequenz bekannt war, benötigte eine Addition 18 Zyklen. Davon entfielen acht auf die Speicherzugriffe. Ein wortweiser Speicherzugriff würde in diesem Falle die Geschwindigkeit verdoppeln. Trotzdem war das CCS von TOPS dreimal schneller als das von Voyager, das jedes Bit einzeln aus dem Speicher abrief.

Der Begriff Befehlszyklus ist heute ebenfalls aus dem Sprachgebrauch verschwunden. Er gibt die Zeit an, die ein Prozessor braucht, um ein Datenwort aus dem Speicher abzurufen, den Befehl festzustellen und ihn auszuführen. Davon zu unterscheiden ist der Taktzyklus oder Maschinenzyklus. Jeder Befehlszyklus besteht aus einem oder mehreren Taktzyklen. Dieser Zyklus ist durch die Kommunikation mit dem Speicher diktiert: Zuerst legt der Prozessor Spannung an Signalleitungen an, die dem Speicher signalisieren, dass er aktiv ist und der Prozessor eine Aktion (Lesen oder Schreiben) durchführen möchte. Bei mehreren Speicherbausteinen liegen diese Signale nicht an jedem Chip an. In einem zweiten Takt werden nun die Daten auf den Bus gelegt entweder durch den Prozessor (Schreiben) oder Speicherbaustein (lesen), in einem dritten Takt werden die Signale für das Ansprechen des Bausteins zurückgenommen. In einem oder zwei Taktzyklen wird ein einfacher Befehl ausgeführt. Komplexe Befehle wie Sprünge, indizierte Adressierung, Multiplikationen oder Divisionen benötigen mehrere Zyklen. Bei einem 8080 oder Z80 Mikroprozessor umfasste z.B. ein Maschinenzyklus vier Takte, ein Befehlszyklus je nach Komplexität des Befehls 6 bis 21 Takte (zwei bis sechs Taktzyklen).

CCS (Communication & Command System)

Das CCS wurde aus Kostengründen vom Viking Orbiter übernommen, jedoch mit Adaptionen, was die Zusammenarbeit mit dem AACS angeht. Es verwendet einen 4 KWort (1 Wort zu 18 Bit) großen Plated Wire Speicher. Die Befehlsbreite ist fest bei 18 Bit. Davon entfallen sechs Bit auf den Opcode (64 Instruktionen) und 12 Bit auf eine Adresse (ergibt die 4 KWorte). Ein 18 Bit Datenwort hat den Wertebereich von -131.071 bis +131.072. In der CPU standen 13 Register für das Speichern und Berechnen von Werten zur Verfügung. Darunter ein 18 Bit breiter Akkumulator, ein 12 Bit Programmzähler und ein 12 Bit breites Adressregister. Rechenoperationen setzten Flags im 4 Bit breiten Flagregister mit den Statusflags für Überlauf, Minus/Plus, Gerade/Ungerade und Null/Nicht-Null. Der Prozessor war bitseriell. Ein Befehlswort musste erst in 18 Zyklen, Bit für Bit, aus dem Speicher geholt werden. Daher ist der Computer so langsam.

Es gab drei Zeitgeber, die einen Impuls pro Stunde, pro Sekunde und alle 10 ms aussandten. Sie kamen zuerst in einen Interrupt-Prozessor. Der prüfte und verarbeitete sie, bevor sie zum Hauptprozessor gelangten. Der Interrupt-Prozessor hatte 32 Interrupt-Ebenen und prüfte dauernd, welches der Task mit der höchsten Priorität ist.

Der Speicher wurde in vier gleich große Teile von je einem KWort unterteilt. Die ersten drei konnten entweder auf Nur-Lesen oder Lesen/Schreiben gesetzt werden, der letzte war immer beschreibbar. Beim Start waren die ersten 2K nur lesbar und die zweiten 2K auch beschreibbar. Der Speicher des CCS war zwischen Instrumenten- und Sondensteuerung frei aufteilbar. Zu Beginn der Mission waren 2.810 Worte mit Programmen für die Steuerung belegt. Für das wissenschaftliche Messprogramm und die Steuerung der Instrumente waren 1.286 Worte frei. Beim Neptun Vorbeiflug gab es in beiden CCS zusammen 2.500 Worte für das Messprogramm. Als erster Computer an Bord einer Raumsonde konnte das CCS Probleme erkennen und darauf reagieren. Die beiden CCS konnten parallel dasselbe Programm abarbeiten oder getrennte Programme. Ab Uranus wurde ein einzelnes Messprogramm auf beide CCS-Speicher aufgeteilt.

Es gab kein Betriebssystem im eigentlichen Sinn. Alle Routinen sprangen eine TRAP Routine an, die 32 Speicheradressen für die 32 Interrupts hatte. Jede Adresse enthielt eine Instruktion oder Sprungadresse, die bei einem Interrupt ausgeführt wurde.

Die größte Routine war der Master Table Driver. Er enthielt bis zu 20 Tabellen, in der die Ereignisse standen, die abgearbeitet werden sollen. Das CCS ging diese Tabellen zyklisch durch und zählte die Zeitgeber in den Tabellen herunter, bis sie auf Null standen. Dann wurde das Programm ausgeführt. Es war sozusagen ein "Software-Sequencer". Er war aber um Größenordnungen leistungsfähiger. Das bei Jupiter 1.290 Worte lange Encounterprogramm konnte insgesamt 300.000 Kommandos absetzen, da es viele Schleifen enthielt. Beim Jupitervorbeiflug waren 175 Schleifen (bei Voyager "Links" genannt) definiert. Während des Uranusvorbeifluges waren es 1.400 Schleifen über die gesamte Encounterphase von 114 Tagen in zehn Programmen.

Dieses Programm definierte die Arbeit von 98 Tagen in der Cruisephase bis zu 18 Stunden während der Jupiterpassage. Bei Voyagers Jupitervorbeiflug, der sich über knapp drei Monate hinzog, wurde 18-mal ein Programm hochgeladen. Es wurden 1.000 einzelne Anweisungen geschickt, die nachträglich Speicherstellen im Programm abänderten. Der Jupitervorbeiflug hatte einen Gesamtumfang von 18.000 Anweisungen. Ein einzelnes TCM umfasste 283 Anweisungen. Eine Anweisung war 15 Bits lang.

Die wesentlichen Änderungen des CCS gegenüber Viking lagen in der Software. So war das CCS verantwortlich, die Speicher der anderen Computer zu beschreiben. Außerdem machte die Anbindung dieser Rechner Änderungen der Hardware nötig. So sandte das AACS alle zwei Sekunden einen "Herzschlag". Den musste der CCS prüfen, um festzustellen, ob das AACS noch aktiv war. Sonst musste er auf das zweite AACS umschalten.

Der CCS war durch die Übernahme der schon mehrere Jahre alten Viking Hardware der langsamste Rechner von Voyager. Die Zykluszeit betrug 88 Mikrosekunden. Er konnte nicht mehr als rund 10.000 Befehle pro Sekunde ausführen. Doch das war gar nicht notwendig, denn der Rechner sollte nur Kommandos an die jeweilige Hardware weitergeben. Das beanspruchte ihn typisch mit 4 bis 5 Prozent der Zeit. In der restlichen Zeit ging er in einer Endlosschleife die Master-Table durch. Trotzdem gab es Besorgnis, ob der Rechner nicht überlastet wäre. Das Pendant bei Viking hatte mit weniger Experimenten und weniger Systemen nur eine Auslastung von 0,4 bis 0,5 Prozent.

Fünf Fault-Proection Algorithmen (FPA) waren im CCS nach dem Start aktiv. Sie überprüften laufend folgende Systeme:

Kommunikationsverlust: Überwacht die S- und X-Band Verstärker- sowie die Senderhardware und schaltet auf redundante Einheiten um, wenn ein Ausfall festgestellt wird.

Befehlsverlust: Schaltet auf redundante Befehlsempfangs-Hardware um. So wird die Empfangsfähigkeit wiederhergestellt, wenn ein Befehl innerhalb eines bestimmten Intervalls nicht empfangen wurde. (Command Loss Timer).

AACS-Powercode-Verarbeitung: Überwacht die AACS-Statusinformationen und startet vorprogrammierte Wiederherstellungs-Anweisungen im Falle von AACS-Anomalien. Das AACS sendet, wenn es nicht überlastet ist, regelmäßig ein Statussignal zum CCS. Bei Überlastung oder Ausfall bleibt dieses Signal über längere Zeit aus.

CCS-Fehler: Reagiert auf kritische anomale CCS-Hardware- und Softwarebedingungen. Das CCS stoppt in der Regel alle laufenden Sequenzaktivitäten, versetzt das
CCS in einen sicheren Ruhezustand und wartet auf Kommandos von der Bodenstation.

Power Check: Reagiert auf die Auslösung des CCS-Toleranzdetektors oder auf eine Unterspannung des Raumfahrzeugs. Es wird auf redundante Hardware umgeschaltet, um den elektrischen Fehler zu isolieren. Schaltet danach die Stromverbraucher in einer vorgegebenen Reihenfolge wieder ein, falls erforderlich.

Intelligenterweise implementierten Programmierer in die FPA auch Rückkehrroutinen (Rollbacks). Sonst wäre Voyager 2, nachdem die Missionskontrolle im April 1978 vergaß, sie regelmäßig zu kontaktieren, verloren gewesen. Später kamen noch zwei weitere FPA hinzu.

Über das CCS wurden die Programme für die beiden anderen Rechner hochgeladen. Das dauerte wegen der niedrigen Uplink-Datenrate schon bei Saturn bis zu 12 Stunden. Die immer länger dauernden Uplinks führten dazu dass man ab Uranus die beiden CCS mit unterschiedlichen Programmen betrieb um einen Uplink einzusparen. Später wurden auch CCS-Programme in den FDS-Speicher ausgelagert.

AACS (Attitude and Articulation Control System)

Aufgabe des AACS war die Kontrolle der räumlichen Ausrichtung der Raumsonde. Es war das erste System, das aktiv war, denn es überwachte schon den Betrieb des Feststoffantriebs. Während der Brennphase des Propulsion Modules korrigierte es die Ausrichtung mit den Triebwerken am Antriebsmodul. Prompt meldete es schon in den ersten Minuten des Starts von Voyager 1 Fehler aus die Vibration durch die Feststoffbooster stärker als vermutet war.

Die genaue Ausrichtung der Kameras auf Planeten und Monde, die sich mit bis zu 20 km/s relativ zur Raumsonde bewegen, machte ein eigenes Computersystem notwendig. Zuerst war geplant, das entsprechende System von Viking zu verwenden. Doch die Verwendung von Hydrazin als Treibstoff anstatt Stickstoff-Druckgas und der veränderte Schwerpunkt ließen das nicht zu. Das AACS ist nicht nur das Computersystem. Es umfasst auch alle Sensoren und Triebwerke, um die Lage festzustellen und zu ändern.

HYPACE ist der eigentliche Computer. HYPACE steht für Hybrid Programmable Attitude Control Electronics. HYPACE wurde bereits für TOPS entwickelt. Es ersetzte die vorherige direkte Hardwareverdrahtung, die unflexibler war. Sie musste für jede Mission neu erstellt werden und wurde bei den zunehmend komplexeren Missionen immer aufwendiger. Bei HYPACE wurde die Verdrahtung durch eine Programmierung ersetzt. So sind wesentliche Parameter des AACS durch Programmierung änderbar.

HYPACE war nötig, weil Voyager komplexer ist als frühere Raumsonden. Sie hat eine unsymmetrische Gestalt mit zwei Massen, die weitab vom Zentralkörper angebracht waren (Instrumentenplattform und RTG). Dadurch reagiert Voyager anders auf Schubimpulse als die vergleichsweise symmetrischen Mariners und Vikings. Zusätzlich musste Voyager während der knappen Minute, in der die Burner II Oberstufe arbeitete, die Ausrichtung des gesamten Gespanns überwachen und korrigieren. Dieser Task diktierte die Anforderungen: Das System musste innerhalb einer kritischen Phase von 20 ms reagieren. Es musste dreimal schneller sein als das CCS. Verwendet wurde für HYPACE vom CCS der 4 KWort Plated-Wire Speicher und seine 18 Bit Architektur. Es kamen Indexregister hinzu, um Speicherstellen schneller ansprechen zu können.

HYPACE bestand aus MSI und TTL-Bausteinen. Beim Prototyp, der 1973 entstand, waren es 1.150 Chips und 1.200 diskrete Elemente. HYPACE war 18 Bit breit orientiert, arbeitete aber mit 4 Bit großen "Bytes". Damit wurde ein Wort in fünf Zugriffen anstatt 18 geladen. Als Folge dauerte ein Zyklus nur noch 28 anstatt 88 Mikrosekunden. So erreichte HYPACE die nötige Geschwindigkeit, ohne den Computer von Grund auf neu zu designen. Der Takt betrug 607,5 kHz. Eine einfache Anweisung benötigte 17 Takte, entsprechend 28 Mikrosekunden. Es gab 32 Befehle, von denen 14 indiziert waren. Die Indizierung beschleunigte den Datentransfer vom und zum Speicher. Ein einfache Interruptsteuerung wurde implementiert. Es gab aber keine Priorität. Eine Interrupt-Serviceroutine musste vollständig abgearbeitet werden, bevor ein neuer Interrupt aktiv werden konnte.

Die externe Hardware, die kontrolliert wurde, generierte vier Basisereignisse. Auf diese "Flags" genannten Ereignisse reagierte HYPACE. Zwei kamen von Außen: Ein Power Flag, das HYPACE in einen eingefrorenen Zustand versetzte, damit es keine Aktion durchführte, welche die Situation verschlimmerte. Außerdem ein Timing Flag, auf das HYPACE reagierte. Die beiden anderen Flags waren Input- und Outputflags. Inputflags kamen von der angeschlossenen Hardware und werden von der Software beobachtet. Output-Flags wurden von der Software generiert. Einige Input-Flags wurden genutzt, um ein Prioritätssystem für Interrupts zu etablieren. HYPACE hatte acht Interrupt-Flags, zwölf Input-Flags und 20 Output-Flags. HYPACE war ausgelegt, mit Stern- und Sonnensensoren, Gyroskopen und Reaktionsschwungrädern zu arbeiten. Bei Voyager kam als weitere Anforderung die Steuerung der Scanplattform und der Betrieb der Triebwerke des Propulsion Modules hinzu. Das Programm für die Lageregelung der Sonde war beim Start 1.500 Worte lang und belegte weitere 700 Worte für die Daten. Beim Start war der Speicher des AACS bis auf zwei Worte belegt, weil noch das Programm für die Scanplattform und die Korrektur des Propulsion Moduls dazukam. Nachdem letzteres nach dem Start gelöscht werden konnte, entspannte sich die Situation.

Das 4,8 kHz Referenzsignal von HYPACE wurde als Ausgangsbasis für zahlreiche andere Zeitbasen genommen. So wurde die Wechselspannung von 2,4 kHz aus diesem Signal generiert. HYPACE stellte vier Zeitbasen von 10, 20, 60 und 240 ms Dauer für die Bewegung der Scanplattform und die Kontrolle der Lage zur Verfügung. Nach acht der 240 ms Zyklen wurde der Synchronisationsimpuls gesandt, auf den alle Rechner reagieren mussten. Die Routinen waren nach Priorität geordnet - die 10 ms Routinen wurden immer nach 10 ms ausgeführt, dann folgten die 20 ms, 60 und 240 ms Routinen. War HYPACE überlastet, konnte die Ausführung von 240 ms Routinen auch nach 350 ms erfolgen. Doch diese Routinen waren nicht systemkritisch. Die 10 ms Routinen steuerten den Schrittmotor der Scanplattform und die Betätigung der Triebwerke. Die 20 ms Routinen berechneten die Lage und stellten fest, welche Triebwerke aktiv sein mussten. Ob die Scanplattform die gewünschte Endlage und Drehgeschwindigkeit hatte, wurde in der 60 ms Gruppe berechnet. Die 240 ms Tasks sandten den Heartbeat aus und riefen den Kommandointerpreter auf.

Mit dem CCS war der AACS über sechs Leitungen verbunden, die zusammen ein 6 Bit Signal übertrugen. Das geschah alle 8 × 240 ms = 1,92 Sekunden. Der Code 31 (Dezimal) war z. B. der Heartbeat, anhand dessen der CCS feststellte, ob das AACS noch korrekt arbeitete. Code 54 stand dagegen für einen bevorstehenden Ausfall, bei dem das CCS "Distaster parameter" sichern sollte. Zwischen den Heartbeats führt das AACS Selbsttests durch. Scheiterte ein Selbsttest, so entfiel das Senden des Heartbeats. Erhielt der CCS fünfmal keinen Heartbeat (10 Sekunden), so wechselte er automatisch auf den Backup-Computer. Das kam schneller vor als befürchtet, schon beim Start von Voyager 2 geschah es. Das AACS ist viel ausgelasteter als das CCS. Typisch arbeitete es während 95 Prozent seiner Zeit Programme ab. Daher war eine Verlängerung der letzten Zeitbasis möglich und es wurde die Information des CCS über eine bevorstehende Überlastung eingeführt.

Das AACS hatte zwei Modi, den Gyro-Modus und den Sternenmodus. Der Gyromodus war einige Stunden, maximal einige Tage aktiv, während die Sonde den Planeten am nächsten war. Er erlaubte es, die Instrumentenplattform genau auszurichten. In diesem Modus lieferten schnell rotierende Kreisel, die Gyroskope, ein Referenzsignal. Veränderte die Raumsonde ihre Ausrichtung im Raum, so induzierte dies ein Signal bei den Kreiseln, die ihre Ausrichtung im Raum beibehalten wollten. Ohne Kalibration gab es einen systembedingten Shift von 0,5 Grad pro Stunde. Mit Kalibration konnte der Drift auf 0,05 Grad pro Stunde reduziert werden.

Den Sternenmodus benutzte die Sonde während der übrigen Zeit. Dazu wurde ein Sonnensensor an der Spitze der parabolischen Antenne und ein seitwärts angebrachter Sternsensor benutzt. Die Sensoren sind redundant vorhanden. Sobald die Sonne oder der Stern außerhalb eines bestimmten Bereiches ist, feuerte das AACS die Korrekturdüsen. Der Sonnensensor war ein optisches Potentiometer mit einem Cadmiumsulfid-Detektor. Er hatte einen Ausrichtungsfehler von 0,01 Grad und ab einer Abweichung von 0,05 Grad wurde eine Korrektur veranlasst. Der Sternsensor war eine Photomultiplier Röhre mit einem Cäsiumdetektor mit demselben Messfehler und Korrekturfeld.

Voyager hatte keine Reaktionsschwungräder wie andere Sonden. Reaktionsschwungräder sind schnell rotierende, schwere Räder. Werden Reaktionsschwungräder aus ihrer Ruhelage gedreht, so geben sie einen Drehimpuls ab, der genau entgegengesetzt der Veränderung der Achse ist. Dadurch dreht sich die ganze Raumsonde. Reaktionsschwungräder sparen so Treibstoff. Sie sind als mechanisches System aber erheblich anfälliger gegen Ausfälle. Da Voyager nur wenige Drehungen durchführen musste und der Treibstoff ausreichend war, verzichtete das JPL auf Reaktionsschwungräder. Das sparte 500.000 Dollar ein.

FDS (Flight Data Subsystem)

Die hohen Datenraten machten ein eigenes Subsystem notwendig. Ein solches war bereits für TOPS geplant. Schlussendlich erreichte Voyager die siebenfache Datenrate von Viking. Für TOPS hatte Richard J. Rice auf einem "Breadboard" aus 150 TTL Bausteinen und dem 4 KWort 18 Bit Plated Wire Speicher von Viking einen Prototyp geschaffen. Der Prototyp hatte eine Zykluszeit von 12 Mikrosekunden und eine Instruktion benötigte maximal zwei Zyklen. In TOPS Dokumenten wird diese "Rice Machine" erwähnt. Sie führte den Kompressionsalgorithmus aus. Dieser Prototyp zeigte, dass das FDS mit vorhandener Technologie entwickelbar war. Er war aber zu langsam und so wechselte man auf CMOS-Chips, damals eine neue Technologie, die zudem den Vorteil hatte, das ein Schaltkreis, wenn er nicht schalten soll nur sehr wenig Strom verbraucht. Daneben ist die Technologie relativ unauffällig gegenüber Spannungsschwankungen die vor allem in Jupiters Strahlengürtel durch elektrostatische Aufladung entstehen würden. Der im Speicher des FDS verbaute IC, ein RCA 256×1-bit CD4061A CMOS SRAM verkraftet z.B. bis zu 45 % der Nennspannung auf den Eingangssignalen ohne das es diese als aktiv ansieht.

Dazu gab es zwei Verbesserungen. Die erste Verbesserung war der DMA Zugriff. DMA - Direct Memory Access - erlaubt es, dass Daten von den Instrumenten direkt in den Speicher geschrieben werden können, ohne das der Prozessor involviert ist. DMA steigert die Geschwindigkeit dieser Aufgabe enorm. Eine Z80 DMA konnte bei 4 MHz z. B. 2 Millionen Bytes pro Sekunde transferieren, die CPU gerade mal 0,2 Millionen. Beim FDS ergab sich bei der höchsten Datenrate die Problematik, dass die CPU nicht mehr zu ihren eigenen Zugriffen kam. Denn bei dem DMA-Zugriff musste sie warten, bis dieser abgeschlossen war. Dies wurde so gelöst, dass alle Instruktionen, die keinen Speicherzugriff hatten, einen weiteren Zyklus erhielten, in dem die nächste Instruktion gelesen wurde.

Die zweite Neuerung war für die damalige Zeit revolutionär. Bisher war das JPL sehr konservativ in der Wahl der Bauteile für ihre Computer. Der Speicher der anderen Rechner war Plated Wire, erfunden 1957. Gate Arrays für die Logik wurden bei TOPS untersucht, aber nicht eingesetzt. Das JPL setzte für den Speicher des FDS CMOS Bausteine ein. Diese waren noch relativ neu. Das erste CMOS-SRAM mit 288 Bit erschien 1968, 1974 erschienen die ersten 1 Kbit CMOS-RAM. Das war aber schon nach Abschluss der Designphase von Voyager, sodass nach Ansicht des Autors, das FDS RCA 256×1-bit CD4061A CMOS SRAM Bausteine einsetzt, Galileo nutzte die 1 Kbit Generation. RCA war die einzige Quelle für diese IC, welche die 40xx Linie bildeten. Beim Projektstart von Voyager gab es 60 verfügbare CMOS-Bausteine. Voyager verwandte 28 unterschiedliche Typen. Diese wurden speziell strahlungsgehärtet. Sie sollten einem Fluss von 5 x 10¹² Elektronen/s/cm² widerstehen, das schafften die kommerziellen Exemplare nicht. Wenn man die Temperatur beim Oxidieren des Gates von 1.100 auf 950 Grad Celsius absenkte, arbeiteten sie auch bei diesem hohen Elektronenfluss. Allerdings sank die maximale Dosis auf 150 kRad ab. Bei den Speicherbausteinen war eine solche Maßnahme nicht möglich, sie waren daher nur für 10 krad qualifiziert. Die Speicher wurden daher durch Schilde geschützt. Die CD 4000A Serie war für eine MTBF von 64 Millionen Stunden qualifiziert. Schon im Oktober 1980 hatten die Bausteine aber 193 Millionen Sekunden hinter sich, heute sind es 4.350 Millionen Stunden, allerdings gab es vor allem beim Speicher schon mehrere Ausfälle.

CMOS war ideal, weil die Technologie unempfindlich gegenüber Spannungsschwankungen ist. Das der Speicher anders als Plated-Wire-Speicher nicht permanent ist (also bei Stromausfall die Daten verlor) störte nicht, denn Voyager hatte mit den RTG eine konstante Gleichstromquelle an Bord. Das FDS hatte den doppelten Speicher der beiden anderen Rechner: 8 KWorte. Damit nicht das bisherige Konzept der Speicheradressierung, die von einem 4 KWort Speicher ausging, grundlegend verändert werden musste, wurden zwei weitere Leitungen eingeführt. Je eine Leitung selektierte die untere und die obere Hälfte des Speichers für Instruktionen und Daten. Dieses Konzept hatte den Vorteil, das zwischen den beiden FDS der obere Teil des Speichers gewechselt werden konnte. So konnte in der erweiterten Mission, als das JPL auf die Redundanz verzichtete, ein FDS beide obere Speicher ansprechen. In den unteren Speichern war beim Start der Programmcode (redundant) untergebracht.

Anders als beim AACS gab es durch das CCS keinen Wechsel auf das Backup-FDS, wenn es einen Fehler gab. Eine Schaltung stellte aber einen elektrischen Ausfall fest und schaltete auf das zweite FDS um. Bei einem anderen Fehler musste das Umschalten durch ein Kommando der Bodenstation erfolgen. Anders als das AACS war das FDS nicht missionskritisch - ohne funktionierendes AACS konnte die Ausrichtung der Hauptantenne auf die Erde verloren gehen. Das wäre fatal - ein falsch arbeitendes FDS bedeutet nur verlorene Daten. So arbeitete das FDS beim Uranusencounter weiter, obwohl im Speicher ein Bit umgekippt war und die Bilder mit Streifen durchzogen waren.

Es transferierte das FDS vier Bits pro Zugriff, wie beim AACS. Ein weiterer Vorteil war das die Zugriffszeit erheblich niedriger als bei Plated Wire Speicher war und so eine geringere Zykluszeit zuließ. Bei 256 Bit pro Baustein benötigte das FDS für den 8 KWort großen Speicher 512 Chips. PC haben zum Vergleich typisch 8 bis 32 Speicherbausteine. Insgesamt sind in beiden Voyagern 10.346 CMOS Chips verbaut, je 5.173 pro Sonde, davon 1.024 Speicherbausteine. Das ist eine enorme Zahl, wer mal ein Motherboard gesehen hat, wird bei allen rund 100 Chips entdecken, bei heutigen Motherboards sind es nur wenige. Und obwohl mehr Bausteine natürlich auch ein höheres Ausfallrisiko bedeuten arbeiten die Voyagers seit nahezu 50 Jahren, auch wenn es schon einige Ausfälle im Speicher gab. Mir erscheint die Zahl als relativ hoch. Normalerweise machen die Speicherbausteine bei einem Computer den Großteil der Chips aus, auch halte ich den Sprung von 150 TTL-Bausteinen beim Evaluationsboard (entspricht 600 für alle vier FDS in den Voyagern) zu 8.298 Chips (ohne die Speicherbausteine) doch für sehr groß. Eine plausible Erklärung wäre, dass damit auch die Bausteine gemeint sind die im AACS und CCS verbaut sind. Es würde auch Sinn machen, alle Chips in den Rechnern von einem Hersteller zu beziehen und diese denselben Strahlungshärtungsprozess durchlaufen lassen. Da der Prototyp des AACS 1.150 Chips umfasst, wäre das eine plausible Größe, dann würden im Mittel auf CCS und FDS rund 500 Chips auf die CPU entfallen.

Um die vielen Chips unterzubringen waren die Boards vollgestopft mit Chips. Zwei Abbildungen zeigen voll bestückte 7 x 14 Zoll Boards mit einem 27 x 12 Chiplayout oder rund 324 Chips pro Board. So benötigt man mindestens acht Platinen für den Computer. Der Speicher bestand aus vier Platinen (4 Signalebenen) im 3 x 3-Zoll-Format jede mit 128 Chips und 12 Treiber IC bestückt. Die Kosten lagen in einem "low hundred-thousand-dollar range". Ein Wort ist in 16 Bausteinen gespeichert, das bedeutet, dass wenn ein Speicherchip defekt ist, gleich 256 Worte des Speichers wegfallen.

Die CPU aus 150 Bausteinen verbraucht nur 0,33 Watt, das ganze FDS 14 Watt bei 16,3 kg Gewicht. Wäre das FDS aus TTL-Bausteinen aufgebaut, so würde es 27 kg wiegen und 60 Watt konsumieren! Die CPU ist auf den Datentransfer zugeschnitten. Sie verfügt über 128 Register, die im Speicher liegen und nur 36 Instruktionen: Die meisten Instruktionen sind Dekrement-, Inkrement- und Shift- bzw. Rotationsbefehle. Dazu kamen Anweisungen für Addition, Subtraktion, logische Verknüpfungen und Sprungbefehle. Alle Anweisungen, die nicht die internen Register nutzten, waren wegen der 4 Zyklen für einen Speichertransfer langsam.

Über die Geschwindigkeit des FDS gibt es verschiedene Angaben. Zum einen eine Geschwindigkeit von 80.000 Befehlen/s und Zykluszeiten von 12 oder 15 Mikrosekunden. Die 12 Mikrosekunden passen zu den 80.000 Befehlen/s (1 s / 0.000012 Sekunden = 83.333). Auf der anderen Seite gibt ein Aufsatz über die Programmierung des Kompressionsalgorithmus die Geschwindigkeit mit 1.008 Maschinenzyklen in 2,5 ms an. Das wären 403.200 Befehle pro Sekunde. Ein Befehl, der bei 403,2 kHz fünf Zyklen benötigt, wird in 12 Mikrosekunden ausgeführt. Das Einlesen eines Pixels der Kamera erfordert bei dieser Annahme bei 115.200 Bit/s genau sechs Instruktionen. Die vielen Zyklen resultieren daraus, das der Bus nur 4 Bit breit waren. Alleine das Einlesen eines 16 Bit Wortes dauert so 4 Zyklen. Der Takt muss dann höher sein. Bei sehr vielen der frühen Mikroprozessoren dauert ein Maschinenzyklus 4 Takte, bei dem Einsatz von statischen RAMs wie bei Voyager entfällt das Zurückschreiben der Daten in den DRAM, dann kann ein Takt eingespart werden. Den Takt würde ich daher auf 1,2 bis 1,6 MHz einschätzen.

Alle Tasks dauern ein Vielfaches von 24 × 2.5 ms. In dieser Zeit (P-Code) ist eine Zeile der Kamera ausgelesen und im Speicher abgelegt. Danach beginnt das Auslesen der nächsten Zeile mit einem Sprung an Adresse 0000. Teile einer Zeile waren auslesbar, indem während nur eines Teils der 24 Zeitschlitze die Daten eingelesen wurden. Die anderen Instrumente wurden am Ende einer Zeile (alle 60 ms) abgefragt. Der Elektronenstrahl brauchte etwas Zeit, um wieder zum Zeilenanfang zu springen.

Die Aufzeichnung auf Band oder die Übertragung zur Erde wird mit diesen Perioden synchronisiert. Die beiden FDS konnten parallel arbeiten oder als Cold-Spare, bei dem eine Schaltung den Ausfall eines FDS feststellte und dann den zweiten startete. In der Praxis betrieb das JPL die FDS nach dem Start parallel. Erst beim Uranus Encounter wagte die Missionsleitung, das zweite FDS mit anderen Aufgaben zu betrauen. Das war auch nötig, weil das Hochladen von Software immer länger dauerte. Die Uplink-Datenrate nahm permanent ab. 1984 dauerte der Upload von Software für das FDS schon vier Stunden. Mit dem Aufheben der Redundanz hatten die Programmierer einen doppelt so großen Speicher für die Programme. Das reduzierte die Softwareupdates.

Zusätzlich nutzte das JPL den FDS Speicher ab Uranus als Speicher für CCS-Programme. Eine CCS-Routine FDSDAT transferierte Daten vom FDS in das CCS. Für den umgekehrten Weg war keine Routine nötig, da alle Bordrechner über das CCS ihre Programme erhielten. Im FDS-Speicher wurde unter anderem die CCS-Backupmission für den Ausfall des Empfängers untergebracht.

Eine wichtige Zeiteinheit des FDS sind die 48 Sekunden Auslesezeit eines Bildes. Bilder in den Archiven haben als Aufnahmezeitpunkt immer ein Vielfaches von 48 Sekunden. Bei Jupiter wurden zwei Bilder oft im Abstand von 96 Sekunden gemacht. Die Bilder bekamen eine ID, die heute Bestandteil des Dateinamens ist. Sie wird im 48-Sekunden-Intervall hochgezählt. PRA und PWS mit ihren Modi mit hoher Datenrate zeichneten immer 48 Sekunden lang auf. Die Instrumente IRIS und PPS haben einen 48 Sekunden Messzyklus. Und natürlich sind alle Auslesezeiten von Bildern immer Vielfache von 48 Sekunden. Diese 48 Sekunden für einen Frame werden auch beibehielten bei kleineren Datenraten, so gab es 2010 ein Problem das ein Frame 75 Bit zu lange war, weil er 48,46 anstatt 48 Sekunden lang dauerte. Die Datenrate betrug damals nur noch 160 Bit/s.

Der Speicher der FDS wurde unterteilt in einen Programmspeicher und einen Datenspeicher von jeweils 4 KWort Größe. Im Hot-Swap-Mode spiegelte das zweite FDS laufend den Datenspeicher (obere 4 KWorte) des ersten FDS in seinem eigenen Speicher. Das FDS verfügte über Selbsttestroutinen und konnte festzustellen, ob die angeschlossenen Instrumente noch reagieren. Allerdings dauerten Checks der Instrumente lange.

Das FDS sammelte die Daten der Instrumente ein und sandte sie in einem einheitlichen Format zur Erde: dem GS&E Format (General Science & Engineering). Dieses Format bestand beim Encounter aus zwei Datenraten von 4.800 und 7.200 Baud. Das FDS mischte die Daten der Instrumente zusammen und versah sie mit Fehlerkorrekturbits. Beim 7.200 Bit Format gab es 3.600 Datenbits und 3.600 Korrekturbits des Golay Codes. Der zweite Korrekturcode war der Reed-Solomon (RS) Code, der auf 223 Datenbits nur 32 Korrekturbits erfordert. Der Einsatz des RS-Codec entsprach einer Datenrate von 4,8 KBaud. Seine Hardware war nicht redundant vorhanden. Deshalb setzte die Missionskontrolle den RS-Codec beim Uranus-Encounter zum ersten Mal ein (außerdem dauerte das Kodieren im RS-Code länger, sodass diese Codierung nur bei Datenraten unter 50 KBaud einsetzbar war). Die 3.600 Bits waren ein gemischter Datenstrom, so stammten z. B. 1.120 Bits/sec von IRIS und 266 Bits/sec von PRA. Es gab insgesamt 30 Datamodi die in 16 Programmen abgelegt waren. Ein Programmwechsel konnte minimal alle 48 s erfolgen. Für die Experimente PRA, LECP und ISS gab es spezielle Parametertabellen, die eine Veränderung der Betriebsparameter zuließen. So konnten neue Datenmodi für Uranus und Neptun angelegt werden.

Die Kameras und das RSS nutzten das GS&E Format nicht. Die Datenraten der Kameras waren dafür zu hoch. Das RSS sandte zum Durchleuchten der Atmosphären kein Nutzsignal, sondern nur die Trägerwelle. PRA und PWS hatten ebenfalls Modi mit hohen Datenraten, die aber nur zum Speichern auf Band genutzt wurden. Von dort aus wurde dann langsam ausgelesen und im GS&E Format gesandt. Auch alle weiteren Datenraten wurden vom FDS definiert. Das erlaubte es, nach Saturn weitere Kameramodi einzuführen. Ohne diese gäbe es bei Uranus und Neptun weitaus weniger Ergebnisse.

Das FDS von Voyager war ein Zwischenschritt hin zur heutigen Architektur. Galileo als Nachfolger setzte bereits Mikroprozessoren ein. Bei Galileo (und bis heute) hat jedes Experiment einen eigenen Computer, DPU (Data Processing Unit) genannt. Die DPU steuert das Experiment, sammelt die Daten, verarbeitet diese vor und überträgt sie über einen Bus an den Bordcomputer. Die DPU ist das Gegenstück zum FDS. Auch das Lageregelungssystem verfügt heute über eine eigene Logik. Sie wertet z. B. Bilder von Star Tracker Kameras aus, um die Position und Lage festzustellen. Das entspricht zum Teil den Aufgaben des AACS. Heute steuert der Bordcomputer eine Raumsonde, anders als das AACS, dass die direkte Kontrolle über die Gyroskope und die Triebwerke hatte. Galileo, Magellan und Cassini hatten jeweils ein CCS und AACS.

Massenspeicher

Bilder und Daten konnten vom FDS auf ein Halbzollmagnetband (Digital Tape Recorder, DTR) geschrieben werden. Der DTR wurde von Odetics gefertigt. Er musste eine hohe Zuverlässigkeit haben. Odetics gab an, dass das Band mindestens 2.700 km zurücklegen würde, bevor es einen erkennbaren Verschließ gab. Das entspricht rund 8.200 kompletten Umspulvorgängen. Der DTR hielt erheblich länger durch. Bis zum Neptun-Encounter wurde das Band von Voyager 2 schon 36.000- mal umgespult.

Der DTR war an die Fähigkeiten des FDS angepasst. Die maximale Schreibgeschwindigkeit betrug 115,2 KBaud - damit konnte ein Bild im schnellsten FDS-Mode auf den Recorder geschrieben werden. Die Datenrate war bereits damals langsam. Vikings DTR schrieb die Daten mit 2.112 KBaud auf Band. Doch die Daten durchliefen bei Viking kein Computersystem. Der DTR von Viking war direkt an die Kamera angeschlossen und wurde synchron zum Auslesen und A/D Wandeln der Frames betrieben. Beim Nachfolger Galileo schrieb der DTR mit 787,6 KBaud. Galileos DTR stammte auch von Odetics, machte in der Mission aber erheblich mehr Probleme als der DTR von Voyager.

Die zweite Schreib-Datenrate von 7,2 KBaud unterstützte die anderen Experimente, die niemals mehr Daten pro Sekunde lieferten. Dabei wurde auch Telemetrie von den Systemen des Raumfahrzeugs gespeichert. Gab es von einzelnen Experimenten keine Daten, so wurden die Blöcke mit Nullen aufgefüllt. Ausgelesen wurde mit maximal 57,6 KBaud. Es gab keinen Speicher, um größere Datenmengen zwischenzuspeichern. Daher konnte der Bandrekorder auch gleichzeitig lesen und schreiben. Dann aber nur mit 7,2 KBaud. Bei der Lesedatenrate von 7,2 KBaud wurden die Bandaufzeichnungen mit GS&E Daten gemischt. Die Lesedatenraten von 33,6 und 57,6 KBaud ermöglichten bei Jupiter und Saturn das gleichzeitige Auslesen und Übertragen von Realzeit GS&E Daten (33,6 + 7,2 KBaud → 44,8 KBaud, 57,6 + 7,2 KBaud + Fülldaten → 67,2 KBaud. Bei Uranus und Neptun war die Kombination cder Übertragung mit Bildern möglich, wenn die Datenrate 21,6 KBaud betrug (14,4 KBaud Bilddaten + 7,2 KBaud Bandrekorderdaten → 21,6 KBaud.

Pro Spur konnte der DTR zwölf Bilder speichern, insgesamt maximal 96. Der Rekorder kam während der Encounter Phase zum Einsatz, wenn es keine Funkverbindung gab oder die Zeit knapp war, z. B. bei einem Fotomosaik eines Mondes. In der "Cruise-Phase" wurde er regelmäßig aktiviert, da die Instrumente PWS und PRA einen Modus mit hoher Datenrate hatten. Dann legten sie die Daten direkt auf den DTR ab, von wo aus sie langsam ausgelesen und übertragen wurden.

Ausfälle

In den nunmehr (im November 2024) 47 Jahren der Mission gab es einige Ausfälle:

Der größte Ausfall ereignete sich schon für in der Mission am 6. Oktober 1981 bei Voyager 1, als der komplette Speicher von FDS-B ausfiel. Ein solcher Ausfall spricht gegen das Versagen von Speicherchips, wahrscheinlicher ist das irgendwo im Interface zu der CPU es einen Ausfall gab.

Bis zum Januar 1985 fiel ein 256 Byte Block bei FDS-B von Voyager 2 aus.

Während des Flugs zu Uranus fiel am 18. Januar 1986 ein weiteres Bit bei Voyager 2 aus. Die Bilder wurden von weißen und schwarzen Streifen durchzogen. Ein Memory Dumpf des FDS-Speichers B zeigte, dass ein Bit 12 bei Adresse 0F90₁₆ auf 1 anstatt 0 war. Dass Programm wurde umgeschrieben, um die Speicherzelle zu umgehen und am 20-sten Januar funktionierte die Übertragung wieder. Man setzte das Bit per Befehl zurück, es blieb aber permanent auf 1.

Im April 2010 kippte erneut ein Bit im FDS bei Voyager und die Sonde sandte unleserliche Daten zur Erde. Das Bit konnte diesmal erfolgreich wieder gesetzt werden. Aufgrund der nun schon großen Entfernung von der Erde (bis ein Befehl die Sonde erreicht vergeht rund ein Tag und die Antwort braucht einen weiteren Tag zur Erde und die geringe Datenrate) dauere es Wochen den Fehler zu beheben und Monate bis alle Instrumente wieder in Betrieb waren.

Zusammenfassung

Hier nochmals die wesentlichen Daten der Voyager Bordcomputer:

Links

http://www.geonius.com/writing/other/voyager.html

https://ntrs.nasa.gov/api/citations/19880069935/downloads/19880069935_Optimized.pdf

https://www.eejournal.com/article/jpl-software-update-rescues-failing-voyager-1-spacecraft/

https://ntrs.nasa.gov/citations/19780007219

https://www.jameco.com/Jameco/Products/ProdDS/2297231.pdf

https://apps.dtic.mil/sti/citations/ADB010611

https://arc.aiaa.org/doi/pdf/10.2514/6.2016-2415

https://arc.aiaa.org/doi/10.2514/6.1988-550

https://ntrs.nasa.gov/citations/19940019397

https://arc.aiaa.org/doi/abs/10.2514/6.1985-287

Das Buch zu den Sonden

Nach vielen Jahren - mit den Voyagersonden fing mein Interesse an Raumfahrt an - habe ich mich 2022 zum 45-sten Jubiläum des Starts aufgerafft, doch ein Buch über die Sonden zu schreiben. Anfangs meinte ich, den doch sehr ausführlichen Artikeln auf der Website nicht mehr viel hinzufügen zu können, aber beim Stöbern in den NASA-Archiven und den Voyager-Messengern, von denen auch 100 erschienen, ist es doch ein ziemlich umfangreiches Buch geworden.

Auf 600 Seiten findet sich so ziemlich alles, was man zu den Sonden wissen muss, vielleicht sogar einiges was man nicht wissen muss. Es ist damit etwa dreimal umfangreicher als die Webaufsätze, besser gegliedert, mit mehr Bildern und ich hoffe auch leichter zu lesen.

Hier der Link zur Verlagsseite, wer online bestellt, dem rate ich bei BOD, meinem Verlag, zu bestellen, da dann die Marge für mich etwas größer ist. Dank Buchpreisbindung wird es woanders auch nicht billiger sein und der Versand ist kostenlos. Aber es gibt das Buch auch bei Amazon. Das Buch kostet als Printausgabe 49,99 Euro, als E-Book 29,99 Euro.

Artikel verfasst 14.11.2024

Sitemap

Kontakt

Neues

Impressum / Datenschutz

Hier werben / advert here

Buchshop

Bücher vom Autor