Der Space Shuttle Triebwerkscontroller

Eine Neuerung beim SSME war der Triebwerkscontroller. (Space Shuttle Main Engine Controller: SSMEC) Bisher waren Triebwerke von dem Bordcomputer in der Spitze der Rakete kontrolliert. Er hatte auch andere Aufgaben, wie die Berechnung der Aufstiegsbahn und die dadurch nötigen Korrekturen. Die SSME erhielten einen eigenen Computer der nur die Triebwerke überwachte und steuerte. Er erhielt vom Zentralrechner seine Instruktionen. Der Rechner war direkt an den Triebwerken angebracht. Das sparte Gewicht für die Verkabelung und Störungen auf den Leitungen konnten sich so nicht so stark auswirken. Auf der anderen Seite war die Elektronik auch den Belastungen die Triebwerke verursachen ausgesetzt. Das waren Vibrationen und vergleichsweise hohe Temperaturen.

Die Wahl auf einen Triebwerkscontroller fiel primär nicht um den Bordcomputer zu entlasten, sondern um die Triebwerke zu überwachen in einer Form, wie es bisher nicht möglich war. Vorher war es nur möglich, ein Triebwerk wenn es Abweichungen gab, abzuschalten. Doch wenn es soweit war, konnte es schon eine Beschädigung geben. Da die Triebwerke mehrmals verwendet werden sollten, war dies nicht akzeptabel. Darüber hinaus konnte es schon zu spät sein, um Schäden des Orbiters z.B. durch Splitter zu vermeiden. Der vierte Flug einer Falcon 9, bei dem ein Treibwerk so abgeschaltet wurde und Teile der Verkleidung sich ablösten, zeigt den Nachteil dieser Methode. Der Triebwerkskontroller sollte nicht das Triebwerk als ganzes, sondern jedes Einzelbauteil, von dem Druck in den Leitungen über die Ventile, Vorbrenner, Turbinen und Turbopumpen bis zur Brennkammer überwachen und ob die Parameter innerhalb der Vorgaben waren. So sollte ein Defekt, der meist in der Turbine begann und sich dann erst durch Druck- / Flussschwankungen in die Brennkammer fortsetzte, isoliert werden und das Triebwerk sauber heruntergefahren werden, bevor es zu einer Beschädigung kommt.

Weitere Vorteile waren, das anders, als bei bisheriger Steuerelektronik, man Änderungen einfach per Software realisieren konnte. Der digitale Computer war etwas was man heutzutage als Microcontroller verstehen würde – ein Verbund eines Mikrocomputers mit analogen und digitalen Eingängen (für Messwerte) und Ausgänge (für Telemetrie und Steuersignale). So war der SSMEC auch einfacher an den Bordcomputer anbindbar, anstatt einem auf analogen Bauteilen basierendem System, bei dem man Signale erst ins Digitalformat und zurück umwandeln musste. Der SSMEC versprach auch mehr Sicherheit, da die Triebwerke des Shuttles kaum Reserven hatten. Typischerweise legt man jedes System so aus, dass das Überschreiten der Sollwerte nicht sofort zum Ausfall führt. In der Raumfahrt ist ein Sicherheitsfaktor von 1,25 üblich. Bei Triebwerken wird dann oft wenn nach dem Erprobungsprogramm oder einigen Flügen Erfahrungen mit den auftretenden Maximalbelastungen vorliegen, diese Reserve ausgenutzt um den Schub zu steigern. So geschah dies bei den Triebwerken der Atlas, Delta und Ariane 1. Beim SSME gab es diese Möglichkeit nicht. Das Triebwerk war nahe an der Belastungsgrenze. Der Controller sollte so Schäden verhindern und trotzdem das Maximum an Leistung herausholen obwohl die Triebwerke über Stunden anstatt wie bisherige Typen über Minuten laufen mussten.

Den Auftrag für den SSMEC vergab Rocketdyne an Honeywell, da sie nicht die Kompetenz für Steuerungsrechner hatten. Honeywell setzte einen schon damals bewährten, also veralteten Rechner ein. Es war eine Anpassung des HDC-601. Dieser Computer war nicht neu, er wurde als Avionikcomputer schon 1969 entwickelt. Der HDC-601 von Honeywell konnte in 2 Mikrosekunden addieren, in 9 multiplizieren und in 16 dividieren. Die Geschwindigkeit war damit in etwa vergleichbar mit einem Intel 8086, einem der ersten 16 Bit Prozessoren. Wie dieser war er ein 16 Bit Prozessor. Er verfügte aber nur über 16 kWorte (32 Kbyte) RAM. Er basierte in der Architektur auf der Honeywell Serie 16, die 1966 erschien. Die Software war abwärtskompatibel zur 516 Serie. Er wurde als Avionics Rechner bei der Luftwaffe verwendet wie bei einem Zielverfolgungsprogramm.

Parameter	Wert
Gewicht:	89,5 kg
mittlerer Stromverbrauch:	693 Watt
Speicher:	16 KWorte
Taktfrequenz	1 MHz
Zykluszeit für eine Messung aller Parameter (Plan / Betrieb)	15,4 ms, 20 ms, davon 19 ms ausgeschöpft.
Kanäle für Drucksensoren	27 aktiv, 30 vorhanden
Kanäle für Temperatursensoren	13 aktiv, 17 vorhanden
Flussgeschwindigkeit und Flussrate Sensoren	6 + 8, von 15 vorhandenen
Sensoren für Ventilpositionen	13
Aktoren: Zünder	6
Aktoren: Ein/Ausschalter für Ventile	12
Aktoren: Ein/Ausschalter für Servoschalter	15
Aktoren für proportionalgeregelte Ventile	10
Kommandokanäle	3
Instruktionen	87
Register	zwei arithmetische, ein Index Register
Speicherzugriff	390 ns Zugriffszeit, 1 Mikrosekunde Zykluszeit
Inteerupts	17 externe
Kompatibel zu	DDP 516 Software und Digital I/O

Der Speicher bestand pro Kanal aus je zwei Modulen von 8 KWorten zu je 17 Bit aus „plated Wire Memory“. Das waren dünne Drähte die mit einer magnetischen Legierung überzogen waren. Sie erlaubten es, ohne Magnetkerne Information in Form einer Magnetisierung der Legierung zu speichern und funktionierten wie diese, waren aber leichter maschinell herzustellen. Eine Platine hatte Drähte in einem Abstand von nur 0,254 mm (1/100 Zoll) aufgespannt. 4 Module eines Stacks hatten auf jeder Seite einen solchen Rahmen und bildeten so 8 x 1024 Bit, eine fünfte bildete aus ihnen mit den Signalen eines zweiten Stacks ein Wort und steuerte das Paritätsbit bei, mit dem Speicherfehler erkannt werden konnten. Der Speicher zerstörungsfrei auslesbar.

Zum Hauptrechner des Shuttles gab es drei redundante Datenleitungen mit einer Datenrate von 1 MBit/s. Daten wurden in Form von 16 Bit Wörtern mit einem Paritätsbit in Form des Manchestercodes übertragen. Pro Zeitscheibe wurden in 2,4 ms ein Block mit 128 Datenwörtern zum GPC übertragen.

Ein Watchdog Timer, angetrieben von einer Realzeituhr lief nach 18 ms aus und gab ein Signal ab, das den Backup-Rechner aktivierte. Damit dies nicht passierte, wurde er vom aktiven Rechner alle 10 ms zurückgesetzt. Die Realzeituhr selbst hing am 1 MHz Taktsignal und zählte bei einem 13 Bit Zählregister von 4999 auf 0 herunter. Erreichte sie 0 löste sie einen Interrupt aus der sie wieder auf den Startwert brachte. Das war alle 5 ms der Fall.

Analoge Daten wurden durch Schaltungen digitalisiert und die Ausgaben waren alle 10 Bits breit und wurden in einem 16 Bit Wort abgelegt. Das Konvertieren dauerte 106 Mikrosekunden für einen Wert. Er repräsentierte eine Spannung von -5 bis +5 Volt. Umdrehungsraten wurden digital gemessen, indem ein Umlauf eines Turbinenblatts das Heraufzählen eines Zählers stoppte, der mit einer Frequenz von 1,5 MHz erhöht wurde. Der Wert wurde in ein 16 Bit Datenwort gespeichert. Temperaturen wurden durch temperaturabhängige Widerstände an 17 Stellen gemessen, Drücke durch 32 Dehnungsmesstreifen. Sie entsprachen 50 bzw.- 80% der Kapazität der Inputschaltungen. Die Daten wurden dann von der Multiplexerschaltung zu einem Packet zusammengefasst, das zusammen in einem Rahmen übertragen wurde.

Ausgaben für die Steuerung bestanden auf einzelnen 16 Bit Worten. 4 Bits waren das Kommando und die restlichen 12 Bits die Daten. Es gab zwei Möglichkeiten. Das eine war das Ein/Ausschalten, dann repräsentierte ein Bit an einer bestimmten Position das Ein/Ausschalten und die Position welches Ventil oder welcher Aktor betroffen war. Das zweite war das Öffnen nach Wert, dann steckte diese Information in den 12 Bits. Sie wurden über eine D/A Schaltung in eine Spannung von -6 bis +6 Volt, was bei einem Ventil der Position zwischen 0 und 100% offen entsprach. Das Digitalisieren dauerte 10 Mikrosekunden und der Wert wurde weitere 80 Mikrosekunden gehalten, damit die Mechanik ausreichend Zeit hatte zu reagieren. 4 Solche Servoschalter gab es, sie waren dreifach redundant.

Die Platinen steckten in einem inneren Käfig und waren mit zwei Platinen für die Verbindungen zwischen den Platinen abgedeckt. Die Signalwege waren maximal 1,20 m lang. Dieser innere Kasten saß in einem äußeren Kasten an dem die Anschlüsse nach Außen und die redundante Stromversorgung angebracht war, welche aus Wechselstrom die drei Betriebsspannungen von 5,8 und 20 Volt generiert. Diese war dann von Verkleidungsplatten die mit Teflonschaum zur Reduktion der Wärmeübertragung und Erschütterungen ausgekleidet war, abgedeckt. Der Innere Kasten mit dem Computer hatte Abmessungen von 30 x 30 cm, der äußere 30 x 46 cm. Insgesamt bestand der Rechner aus 72 einzelnen Platinen mit 12.000 Teilen, davon 3.000 integrierten Schaltungen. Gummi isolierte den so verpackten Rechner zusätzlich vor Vibrationen.

Die Zahl der Anschlüsse war enorm: 449 zur Bodenausrüstung, 339 Eingangskanäle, 227 Ausgangskanäle zur Steuerung, 23 Leitungen zum Bordrechner und 12 Stromanschlüsse.

Die NASA war nicht sehr erfreut mit der Wahl, da Honeywell zum gleichen Zeitpunkt massive Probleme bei der Fertigung des Viking Bordrechners hatte. Rocketdyne konnte auch nicht die Firma in dem Maße beaufsichtigen, weil Computer nicht ihre Kernkompetenz waren. So war beim ersten Review die Software zu langsam, sie hatte eine Zykluszeit von 18,34 ms anstatt 15,4 ms in den Designvorgaben. Honeywell reagierte darauf, dass diese auf einer Software mit minimalem Ressourcenverbrauch beruhe und es ohne Verlust an Sicherheit möglich sein die Antwortzeit auf 25 bis 30 ms zu erhöhen. Das war zwar immer noch kürzer als die Zykluszeit des Bordcomputers (GPC) von 40 ms, aber doch doppelt so lang wie geplant. Diese Zeitscheibe bedeutete: In dieser Zeit nahm das System eine Messung von Betriebsparametern vor, bewertete sie und konnte reagieren z. B. Abschalten oder den Fluss reduzieren, aber auch Triebwerke Schwenken oder den Schub regulieren. Je kürzer sie war desto geringer war die Gefahr, dass ein Ereignis zu einer Katastrophe führen konnte. Später wurde da Honeywell das Ziel von 15,4 ms nicht erreichen konnte die Dauer der Zeitscheibe auf 20 ms erhöht. Sie hatte vier kleinere Zeitscheiben von 5 ms für einzelne Subaufgaben.

Der Zyklus begann mit einem Selbsttest gefolgt von dem Steuern der Triebwerke und zwei kurzen Perioden in denen Eingabesignale eingelesen wurden. Das waren die ersten 5 ms des Zyklus. In den zweiten 5 ms wurde zuerst das Triebwerke auf Überscheiten von Grenzwerten überwacht, dann folgten zwei Ausgabesektionen, die sich bis in den dritten 5 ms Block erstreckten. Im Rest dieses und des nächsten Frames folgte das Verarbeiten von Eingabedaten die man im ersten Zyklus gewann, kurz unterbrochen von der Überwachung der Betriebsspannung. Am Schluss folgte ein erneuter Selbsttest und die letzte Millisekunde war „Freizeit“.  Dies korrespondierte mit der Arbeit der Input-elektronik, die zwischen 0 und 6 ms Eingangsdaten anlegte, zwischen 7 und 9 ms Ausgangsdaten akzeptierte und zwischen 11,5 und 13,5 ms die Eingangsspannungen zur Kontrolle ablegte. Es gab keinen Bootzyklus, sondern diesen einen Zyklus. So konnte der B-Rechner auch innerhalb von 20 ms einspringen.

Der HDC-601 war fail operational, fail safe ausgelegt. Das bedeutet, es gab zwei Rechner A und B mit zwei Bussystemen. Es konnte jederzeit einer ausfallen und dies konnte vom zweiten aufgefangen werden (fail operational). Fiel auch der zweite aus, so schalteten die Haupttriebwerke kontrolliert ab, ohne dabei beschädigt zu werden (fail safe). Dazu war ein Rechner A verantwortlich für die Steuerung der Triebwerke und der zweite überwachte zum einen die Werte der Triebwerke wie auch das Funktionieren des ersten Rechners und schaltete diesen bei einer Fehlfunktion ab und übernahm das Kommando. Der Bus wurde von beiden gemeinsam genutzt. Diese Konstruktion war erheblich effizienter als eigenständige Rechner die jeweils individuell mit den Triebwerken verbunden waren.

Um den HDC zu entlasten, der erheblich langsamer als der Bordrechner GPC war, verfügte der GPC über einen direkten Hauptspeicherzugriff auf den Speicher des SSMEC.

Das Testprogramm umfasste 35 Minuten Belastung unter einem Druckspektrum von 153 dbi Druck mit 10 bis 10.000 Hz. Die Empfindlichkeit gegenüber Vibrationen wurde mit einem Schütteltest mit zufällige verteilten Frequenzen zwischen 20 und 20000 Hz getestet. Dabei wurde auch die Gummiisolierung angebracht, die das operationelle Exemplar vor Erschütterungen schützen soll. Es folgten 60 Zyklen in der Vakuumkammer, bei der verschiedene Temperaturzyklen bei Start, Landung und im Weltraum simuliert wurden. Die maximalen Temperaturunterschiede lagen bei -62 bis +93°C. Die elektromagnetische Empfindlichkeitstest erfolgten ebenfalls in der Flugkonfiguration, in der eine Aluminiumfolie elektromagnetische Störeinflüsse um den Faktor 2 reduzierte. Dem folgten dann mit den Serienexemplaren Akzeptanztests, bei dem die Flughardware ebenfalls getestet wurde. Nur waren die Bedingungen nicht so extrem und erreichten bei den Temperaturtests z.B. nur Extreme von -21 bis + 52°C.

Der SSMEC musste schon vor dem Jungfernflug bereit stehen. Er war bei allen 630 Hot-Fire Tests der Haupttriebwerke beteiligt und steuerte diese. Damit hatte er schon vor dem Jungfernflug 100.000 Betriebssekunden auf dem Buckel. Vorher nutzte man für die gleichen Tests DDP-516 Minicomputer in Racks, zu denen die Rechner softwarekompatibel waren. Ausgeliefert wurden drei Batches. Beim Jungfernflug hatten alle A-Rechner zusammen 40.000 Betriebsstunden absolviert, die B-Rechner 42.000 Stunden. Die C-Exemplare waren für den operationellen Betrieb vorgesehen. 15 Exemplare wurden dafür bestellt.

Die Software wuchs beim Shuttle GPC rasch an. Vor dem Jungfernflug waren noch 500 Worte frei, 1975 belegte sie noch 10.203 Worte. Sie passte immerhin noch in den Speicher. Beim Shuttle Bordrechner war dies nicht der Fall.

Wie der Rechner im Orbiter wurde auch der SSMEC nach wenigen Jahren durch den SSMEC Block II ausgetauscht. Der Sprung in der Entwicklung war noch größer als beim GPC, vor allem wagte man den Austausch der Hardware gegen eine neue, nicht befehlskompatible. Seit 1988 wurde ein Motorola MC 68000 mit je zwei 64 K großen CMOS RAM Speichern eingesetzt. der SSMEC Block II wird in C als Programmiersprache anstatt Assembler programmiert. Ein geplantes Upgrade bis 2005 sollte diese durch digitale Signalprozessoren (DSP) ergänzen 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.

Das Advanced Health Monitor System (AHMS), das als Ersatz geplant war, sollte den SSMEC nicht ersetzen, sondern als HMC (Health Monitor Computer) ihn ergänzen. Es sollte die Wahrscheinlichkeit das ein Orbit erreicht wird erhöhen und die Sicherheit bei Abbrüchen erhöhen. Eine verstärkte Überwachung der Triebwerke erlaubte eine neue Strategie. Vorher war es so, dass abnormale Werte zu einem Abschalten der Triebwerke führten. Nun wollte man stattdessen das betroffene Triebwerk im Schub herunterfahren, Es konnte ja bis auf 65% des Schubs reduziert werden. Geplant waren zwei Level von 67 und 85%. Damit stieg die Wahrscheinlichkeit, dass man einen Orbit erreichte deutlich an. Das Risiko eines Abbruchs sollte um 23% sinken. Die DSP erlaubten das Monitoring von Parametern, also ob sie sich über längere Zeit auffällig veränderten und lösten dann die Anpassung der Leistung aus, bevor es zum Abschalten kam. Das war bei dem alten System nicht möglich. Hier gab es definierte „Red Lines“. Unterschritt oder überschritt ein Meßwert einen vorgegebenen Grenzwert löste er eine Aktion aus, die meistens das Abschalten des ganzen Triebwerks bedeutete. Es wurde nur der wert bestimmt der in diesem 20 ms Zyklus anlag, aber keine Historie geführt, ob z. B. der Druck langsam anstieg.

Der HMC besteht aus vier Karten mit DSP Prozessoren und vier Karten mit Speicher. Auf diesen befinden sich unter anderem 1 GByte NAND-Flash Speicher. Die Signale werden durch eine weitere I/O Platine auf den Bus übertragen