Fehlertolerante Hardware Systeme

Fehlertolerante Hardware Systeme Am Beispiel des Fault Tolerant Computer ( FTC ) der DaimlerChrysler Aerospace AG Raumfahrt Infrastruktur Bremen Oliver Hoins ( European Electrotechnical Studies EES ) Hochschule Bremen im Wintersemester 1999/2000 Abstract: Dieses Essay beschäftigt sich mit dem Fault Tolerant Computer ( FTC ) welcher für die Internationale Raumstation ( ISS ) von der DaimlerChrysler Aerospace AG Raumfahrt Infrastruktur am Standort Bremen entwickelt wurde. Ziel dieser Ausarbeitung ist es, auf die besonderen Anforderungen an Fehlertolerante Hardware hinzuweisen, die im Bereich der Raumfahrt zu beachten sind. Des weiteren wird der interne Aufbau des FTC und der dem System zugrunde liegende Byzantine- Algorithmus beschrieben. Introduction: Der DaimlerChrysler Aerospace ( Dasa ) Fault Tolerant Computer ( FTC ) wurde für Raumfahrt Applikationen entwickelt, für die eine hohe Zuverlässigkeit (reliability), hohe Verfügbarkeit (availability), sowie hohe Strahlungstoleranz (radiation - tolerance) essentiell sind. Der FTC ist ein modularer Computer, der dem User eine hohe Rechenleistung zur Verfügung stellt und mit bis zu zwei nicht-simultanen ( two non-simultaneous faults ) umgehen kann. Zu Kommunikationszwecken ist der Fault Tolerant Computer mit sechs MIL-STD 1553B Interfaces ausgerüstet und ist vorbereitet, das Synchronous Packet Transfer Protokoll ( SPT ) zu unterstützen, welches für die Kommunikation an Bord der Internationalen Raumstation verwendet werden wird. Der Fault Tolerant Computer besteht aus identischen Computern ( Hard- und Software ), wobei jeder Computer in einem separaten Gehäuse untergebracht ist. Diese Einheiten werden Fault Containment Regions ( FCR ) genannt. Sie operieren simultan und bearbeiten identische User-Applikations Software. Um, wie spezifiziert, mit zwei Fehlern umgehen zu können, werden vier Fehlertolerante Regionen ( FCRs ) benötigt, deren Aufbau und Zusammenspiel in dieser Ausarbeitung beschrieben werden sollen. Oliver Hoins 1

Inhaltsverzeichnis: INHALTSVERZEICHNIS:... 2 ERKLÄRUNG DER GRUNDBEGRIFFE... 3 ANFORDERUNGEN AN RECHNERSYSTEME FÜR DIE RAUMFAHRT... 4 AUFBAU UND FUNKTION DES FTC:... 5 DETAILLIERTE FML BESCHREIBUNG:... 6 FEHLER MANAGEMENT SOFTWARE:... 7 SYNCHRONISATION DER KOMPONENTEN:... 8 CROSS-STRAPPING:... 8 VOTING SERVICES:... 9 AVIONICS BUS SYSTEM:... 11 TECHNISCHE DETAILS DES FTC:... 12 LITERATURVERZEICHNIS:... 13 DANKSAGUNG:... 13 Oliver Hoins 2

Erklärung der Grundbegriffe Im folgenden sollen die Grundbegriffe, die für das allgemeine Verständnis dieser Ausarbeitung notwendig sind erläutert werden. Da vollständige Einführungen in die Begriffswelt den Rahmen dieser Ausarbeitung sprengen würden, wird für detailliertere Ausführungen auf geeignete Literatur [6] verwiesen. Fehlertoleranz: Zuverlässigkeit: Verfügbarkeit: Fehler-Ursachen: Fehler: Ausfall: Fehlertolerant: Fehlerausgrenzung: Fehlerbehebung: ( Fault Tolerance ) Fähigkeit eines Systems, sich trotz einer begrenzten Zahl von Fehlern spezifikationsgerecht zu verhalten. Fehler in diesem Zusammenhang können sein: Betriebsfehler, Entwurfs-, Herstellungs-, Bedienungs- oder Wartungsfehler. ( Reliability ) ist die Wahrscheinlichkeit dafür, daß ein System während einer vorgegebenen Zeitdauer bei zulässigen Betriebsbedingungen die spezifizierte Funktion erbringt. ( Availability ) bezeichnet die Wahrscheinlichkeit dafür, daß ein System zu einem gegebenen Zeitpunkt fehlerfrei ist, also spezifikationsgerecht funktioniert. ( fault ) bezeichnet die physikalische Ursache für Fehlzustände eines betroffenen Systems. Die Ursache hierfür kann im System selbst oder aber in seiner Umgebung liegen; sie kann temporär oder permanent sein. ( error ) bezeichnet den Teil eines fehlerhaften Systemzustandes, der zu einem Systemausfall führen kann, aber nicht zwingend führen muß. ( failure ) bezeichnet den Übergang von einem fehlerfreien in einen fehlerhaftes Erbringen der Dienstleistung. Ein Rechner mit Fehlertoleranz ( reconfiguration ) isoliert oder entfernt fehlerhafte Systemkomponenten, wobei besagte Komponenten aus Software- und Hardwarekomponenten bestehen können. ( recovery ) versetzt das System in einen fehlerfreien Zustand, unter Umständen ohne fehlerhafte Komponenten zu entfernen. Fehlerbehebung ist in erster Linie bei transienten Fehlerursachen angebracht, die definitionsgemäß nicht auf defekte Hardware, sondern auf äußere Einflüsse, wie im Bereich der Raumfahrt beispielsweise kosmische Strahlung zurückzuführen sind, und nur für kurze Zeit wirken. Fehlerkompensation: ( masking ) beläßt sowohl fehlerhafte Komponenten als auch deren fehlerhafte Zustände im System, korrigiert oder maskiert jedoch deren Auswirkungen. Redundanz: ( redundant ) Es sind mehr Betriebsmittel vorhanden, als für die vorgesehene Funktion des Systems benötigt werden. ( Zuverlässigkeitssteigerung ). Strukturelle Redundanz: Erweiterung des Systems um zusätzliche Hard- und Softwarekomponenten, z.b. um Reserve- und Diagnoserechner. Funktionelle Redundanz: Erweiterung des Systems um zusätzliche Funktionen, z.b. um Testfunktionen, Fehlervorhersage oder die Erstellung von Sicherungsdaten. Oliver Hoins 3

Anforderungen an Rechnersysteme für die Raumfahrt Im folgenden werden Gründe für Eigenentwicklungen wie den Fault Tolerant Computer FTC der DASA im Bereich der Raumfahrt aufgezeigt. Auf den ersten Blick ist vielleicht nicht gleich ersichtlich, warum die DASA drei Jahre Entwicklungszeit und immenses Summen investiert, um selber fehlertolerante Rechensysteme für das All zu entwickeln, anstatt auf Systeme von Drittherstellern zurückzugreifen, die universell für einen breiten Massenmarkt zugeschnitten sind und somit wesentlich kostengünstiger sind. Grund hierfür sind spezielle Anforderungen an Systeme für die Raumfahrt, die an universelle Lösungen für den Massenmarkt, wie beispielsweise Flugsicherungssysteme, Reaktorsysteme u.ä. nicht gestellt werden. Hierzu gehört beispielsweise die Tolerierbarkeit von: Vibration Wie sie beim Aus- und Wiedereintritt in die Erdatmosphäre vorkommt. Wärmeableitung Rechensysteme im Luftleeren Raum können nicht wie gewohnte Systeme mit Ventilatoren gekühlt werden. Spezielle Thermische Senken ( thermal vakuum design ) müssen für jedes IC und jeden Transistor errechnet und realisiert werden, um nicht aufgrund von solchen Entwurfsfehlern fehlerhafte Systemzustände oder sogar Ausfälle herbeizuführen. Breitband-Strahlung ( radiation ) Im Weltraum herrscht eine, im Vergleich zur Erdatmosphäre, sehr energriereiche Teilchenstrahlung. Diese primäre Strahlung besteht vorwiegend aus Protonen, daneben aus Alphateilchen, schweren Atomkernen und Elektronen. Der genaue Ursprung dieser Strahlung, die immerhin Energien von bis zu 10 18 Elektronenvolt aufweist, ist nicht bekannt, jedoch ist deren Auswirkung auf die Hardware von Rechensystemen nicht zu unterschätzen. So müssen zum Beispiel wesentlich höhere Abstände der Leiterbahnen eingehalten werden, die im Gegensatz zur heute üblichen Miniaturisierung solcher Komponenten steht. Zusätzlich zu den genannten Anforderungen, die nur einen Bruchteil der tatsächlichen Anforderungen an solche Systeme ausmacht, ist natürlich die Kompatibilität zu- und die Kommunikationsfähigkeit mitallen Systemen der Internationalen Raumstation zu erreichen, die Eigenentwicklungen von fehlertoleranten Computern für diesen Bereich rechtfertigen und sogar zwingend erforderlich machen. Oliver Hoins 4

Aufbau und Funktion des FTC: Aufgrund der Anforderungen an die Internationale Raumstation wurde ein Zwei-Fehler-tolerantes FTC Design erwartet. Dieses soll die Möglichkeit bieten, sich von einem beliebigen (arbitrary) Fehler zur Zeit, und von einem zweiten, jedoch deterministischen Fehler zu erholen. Der Umgang mit zwei simultan auftretenden Fehlern ist hierbei jedoch nicht vorgesehen. Darüber hinaus soll eine Prozessor Pool Technologie die Operation des FTC in einer Ein-, Zwei-, Drei-, oder Vier Lane Konfiguration erlauben und eine On-Line Rekonfiguration ohne Applikationssoftware-Service-Unterbrechung ermöglichen. Besagte Lanes werden auch als FCRs ( Fault Containment Regions ) bezeichnet. Um den gestellten Anforderungen gerecht zu werden, wurde ein Vier-Lane FTC Design gewählt, welches an die klassische multiple instruction, multiple data ( MIMD ) Methode [ 3 ] angelehnt ist. Im DASA FTC sind die Prozessoren die die User Application Software (UAS) bearbeiten von denen, die für Fehlermanagement und das Management des MIL-STD 1553B Bus-Interfaces zuständig sind getrennt. Dies resultiert in einer 3 Layer Architektur der FCR. Abbildung: 1 3 Layer Design der FCR Drei voneinander unabhängige Layer ( Hard- und Software ) in einer Lane ( FCR ): AVI -Layer Avionics Interface Layer FML -Layer Fault Management Layer AL -Layer Application Layer Das Design des AL-Boards basiert auf einem strahlungstoleranten SPARC-kompatiblen Chipsatz und benutzt das off-the-shelf Betriebssystem VxWorks, das die Plattform für die User Applikationssoftware bietet. Ein Transputer T805/20MHz Netzwerk für den FML und AVI Layer Das Byzantine Protokoll [ 2 ] als Fehler Management Algorithmus, um Übereinstimmung zwischen den Lanes zu erreichen und um Lane-Fehler zu erkennen. Die zwei Layer AVI und AL wurden um den FML Kernel designed und können durch andere Komponenten, je nach Projekt-Anspruch, ersetzt werden. Da Marketinganalysen zeigten, daß Kunden ein großes Interesse daran haben, ihre eigene Hardware innerhalb des FTC zu installieren, wurde ein Standard VME Bus für das AL-FML Interface spendiert. Dies erlaubt die Benutzung einer großen Palette von VME basierten Prozessor-Boards im FTC. So wurden bereits Tests mit einem AL Board der Firma LORAL, basierend auf einem strahlungsfesten RS6000 Prozessor und einem AL Board der Firma FORCE, basierend auf einer SPARC Architektur gefahren. Oliver Hoins 5

Detaillierte FML Beschreibung: Das Kernelement des FTC ist der FML Layer, der den Algorithmus für das Byzantine Protokoll beinhaltet, welches zwischen den Lanes benutzt wird. Da eine flexible, FCR redundante Konfiguration einen großen Vorteil für Fehlertolerante Computer in der Raumfahrt darstellt, unterstützt der FTC eine Ein-, Zwei-, Drei-, oder Vier Lane ( FCR ) Konfiguration. Abbildung: 2, 3, 4 Redundante, austauschbare FCR - Box Die Byzantine Fehlertoleranz kann jedoch ausschließlich mit einer Vier-Lane Konfiguration erzielt werden, da bezugnehmend auf diesen Algorithmus ein Computer F willkürliche ( Byzantine ) Fehler isolieren kann, wenn folgende Bedingungen ( conditions ) erfüllt sind: Der Computer muß aus ( 3 F + 1 ) Fault Containment Regions ( FCRs ) bestehen. Die FCRs müssen durch ( 2 F + 1 ) disjunkte ( voneinander unabhängige ) Pfade verbunden sein. Die Daten zwischen den FCRs müssen ( F + 1 ) mal ausgetauscht werden und entsprechend dem Byzanzine Algorithmus gevoted werden. Die FCRs müssen synchronisiert sein. Dieses Konzept wurde durchgehend in das Design der Hard- und Software für den Fault Tolerant Computer FTC implementiert. Für die spezifizierte Fehlertoleranz von einem Fehler zur Zeit ( F = 1 ), ergeben sich somit: ( 3 * ( F = 1 ) + 1 ) = 4 FCRs. Der FML Layer ist ein VME kompatibles Board, welches folgende funktionale Charakteristiken und Firmware beinhaltet: Fehler Management ( Softwareseitig gelöst ) Synchronisation Cross Strapping Voting Services Die FML Hardware basiert auf einem T805 Transputer in MIL883 level C Abschirmung. Die gesamte Software ist in der OCCAM II Sprache implementiert. Diese Lösung weicht zwar von der üblichen Praxis, ADA als bewährte Sprache zu benutzen, ab, jedoch rechtfertigen die Größe, sowie die Laufzeiteffiziente Implementierung von OCCAM II diese Lösung. Des weiteren gibt es nur wenige Benutzer, die Erfahrung mit ADA für Transputer haben, und das Risiko eines Ausfalls aufgrund von Tool-Problemen wurde als zu groß angesehen. Oliver Hoins 6

Fehler Management Software: Die Fehler Management Software beinhaltet Funktionen für Lane ( FCR ) Isolation, Re-Integration von FCRs und das FML System Konfigurations Management. Das Design der Fehler Management Software basiert auf einem FML Status Vektor, der in zwei Schritten verbreitet, gevoted und über die Fehlertolerante Clock synchronisiert wird. Die Verbreitung des Vektors geschieht in jeder Lane basierend auf dem Oral Message Protokoll [ 2 ]. Im ersten Schritt des Protokolls verbreitet jede Lane ihre lokale Status-Information zu den anderen drei Lanes und sammelt die Status-Informationen der anderen drei Lanes. In jeder Lane resultiert dies in einem Status-Vektor mit einem Eintrag für jede Lane. Im zweiten Schritt des Protokolls werden die Status-Vektoren unter den Lanes ausgetauscht. Daraus resultierend hat jede korrekt operierende Lane eine verläßliche Information über die Status-Vektoren der anderen korrekt operierenden Lanes. Solange höchstens ein Byzantine Fehler auftritt, genügt dieses Verfahren um Übereinstimmung unter den korrekt operierenden Lanes zu erreichen, die alle die gleichen Votingprozeduren an den Vektoren ausführen. Es ist zu beachten, daß das Byzantine Protokoll zwar die Übereinstimmung korrekt operierender Komponenten anhand der Voting-Vektoren garantieren kann, es jedoch keine Fehlererkennung garantieren kann, sofern die fehlerhafte Komponente ihr fehlerhaftes Verhalten ausschließlich auf einer anderen Lane zeigt. Um dieses Problem zu umgehen, kopiert jede Lane die zur Verteilung bereitstehenden Vektoren von einer Storage-Location zu den Tranputer Links. Ferner ist jeder Vektor mit einer CRC Checksumme assoziiert, bevor er in der Storage-Location plaziert wird. Als Konsequenz hieraus erhalten die anderen Lanes entweder identische Vektoren von der fehlerhaften Komponente oder sie erhalten Vektoren mit inkonsistenten CRC Werten. Dieses Konzept bietet eine große Wahrscheinlichkeit für das Aufspüren fehlerhafter Lanes ( FCRs ). Der Austausch dieser Status-Vektoren informiert jede Lane über den Operationsstatus aller anderen Lanes. In einer fehlerfreien Situation sind die operationellen states aller Lanes gleich, jedoch nicht bitweise identisch. Eine fehlerhafte Lane in einer 4 FCR-Konfiguration kann im Falle einer Nichtübereinstimmung des Status-Vektors durch ein Remote-Reset der korrekt arbeitenden Lanes isoliert werden. Die Entscheidung für diesen Remote-Reset basiert ebenfalls auf dem gevoteten Status-Vektor. Bei Erkennung einer solchen Fehlerursache wird der Fehler maskiert und der FTC fährt mit seinen Operationen fort, sofern der Fehler von temporärer Natur ist. Bei n fachem Auftreten des Fehlers in einem Zeitfenster von 100ms wird die FCR als fehlerhaft erkannt und automatisch isoliert (deaktiviert). Der FTC führt seine Operationen dann in einer 3-FCR Konfiguration aus. Selbst in dieser Konfiguration ist er immer noch fehlertolerant in Hinsicht auf einen deterministischen Fehler durch sogenanntes majority voting und erfüllt in diesem Zusammenhang immer noch die spezifizierte 2- Fehlertoleranz. Nachdem das Byzantine Protokoll sicherstellt, daß alle korrekt arbeitenden FCRs dasselbe Voting- Ergebnis erhalten, entscheiden entweder alle oder keine der korrekt arbeitenden FCRs über die Isolation einer potentiell korrupten FCR. Selbst ein willkürlicher ( arbitrary ) Fehler kann in diesem Falle toleriert werden, sofern die Statusvektoren, wie oben beschrieben, in zwei Schritten gevotet wurden. Nach Ausfall einer FCR, also in einer 3-FCR Konfiguration, wird sich eine fehlerhafte FCR selbst resetten, sobald eine permanente Nichtübereinstimmung der Votingergebnisse auftritt. Dies jedoch setzt ein deterministisches Verhalten der betroffenen Komponente im Falle eines Fehlers voraus. Mit anderen Worten, es muß sich in der 3-FCR-Konfiguration beim zweiten Fehler um einen deterministischen Fehler handeln. Oliver Hoins 7

Nach Ausfall einer zweiten FCR, also in einer 2-FCR Konfiguration, wird im Falle einer Nichtübereinstimmung der Votingergebnisse keine Isolation mehr vorgenommen, und der FTC arbeitet selbst bei einem Fehler weiter, bis ein hardware-buit-in Test-Reset ausgelöst wird. Die Rekonfiguration geschieht in einer vordefinierten Reihenfolge. Die Rekonfigurarion von einer quadruplex zur triplex, zur duplex und schließlich zur simplex geschieht völlig autonom, ohne eine Service Unterbrechung der Applikationssoftware. Dies kann von einem Operator, aus Gründen der Energieeinsparung etc. eingeleitet werden, oder von der FML selbst, um eine fehlerhafte Lane zu isolieren. Synchronisation der Komponenten Der FTC besteht aus einem lose gekoppeltem Prozessor-Netzwerk des MIMD Typs. Alle Prozessoren werden über einen separaten, fehlertoleranten Takt ( fault-tolerant clock ) mit einer 10 Hz Frequenz synchronisiert. Diese Taktung basiert auf der Frequenz des TTP Protokolls an Bord der Internationalen Raumstation ISS. Zwischen den Synchronisations-Events operieren alle Prozessoren unabhängig. Dieses Design erlaubt somit einen Grad an Heterogenität zwischen den FCRs. Die Fault Tolerant Clock ist in einem FPGA Schaltkreis implementiert und erlaubt eine Präzision der Synchronisation von +/- 5 µ Sekunden zwischen den FCRs. Die Fault Tolerant Clock ist mit einer eigenen cross-strapping ( etwa: Kreuz-Koppelleitung ) ausgestattet, um eine Zwei-Fehler-Toleranz aufrecht zu erhalten. Zusätzlich hat jede Clock-FPGA die Möglichkeit einer Remote-Synchronisation, um dem gesamten FTC System zu ermöglichen, als Slave-System auf einem Master-Command-Bus zu operieren. Cross-Strapping Cross-Srapping, zu Deutsch etwa: Kreuz-Koppelleitung ( Für Daten- Takt- und Resetsignale ) Die FTC Kreuz-Koppelleitung besteht aus drei, voneinander völlig unabhängigen Kreuz-Koppel- Komponenten: ( ( 2 F + 1 ), siehe Seite 6 ) Data Fault Tolerant Clock Remote-Reset - cross-strapping - cross-strapping - cross-strapping Abbildung: 5 Cross-Strapping Verbindungen in einer 4 FCR-Konfiguration Oliver Hoins 8

Alle cross-strapping Verbindungen sind galvanisch voneinander getrennt, um einer Fehler- Propagierung vorzubeugen. Der Informationsaustausch geschieht hierbei bi-direktional. Die gebräuchlichste Art, Daten in fehlertoleranten Computer Systemen auszutauschen, ist die Benutzung eines time-tagged protocol ( TTP ) zusammen mit bit-seriellen Bussen. Um jedoch dem Byzantine Protokoll nachzugeben und einen Vorteil aus der mächtigen Transputer Kommunikationsfähigkeit zu erhalten, wurde die geforderte Point-to-Point Verbindung mit den Transputer links geschaffen. Folglich findet der Datenaustausch völlig asynchron und parallel auf allen seriellen Transputerlinks statt. Es kann somit eine totale Kommunikations-Bandbreite von über 48 Mbit / Sekunde erreicht werden. Zwar scheint diese Bandbreite recht hoch zu sein, jedoch ist das Byzantine Protokoll sehr Kommunikationsintensiv und ein Byzantine-Fehlertoleranter Computer von beispielsweise F=2 scheint mit den derzeit zur Verfügung stehenden Hardware Komponenten des FTC nicht einmal möglich zu sein. Voting Services: Wie bereits angesprochen sind die Voting-Services in Software implementiert. Die Voting-Services vergleichen Daten, die zu Nachrichten von maximal 756 Byte gruppiert werden. Die Datengröße paßt in ein subframe time slot des TTP Protokoll des Avionics Bus Systems. Die Voting-Services sind mit einem sogenannten time-out Management ausgestattet, um verlorene oder gestörte Nachrichten zu erkennen. Nachrichten kommen asynchron von dem Applikations-Layer, dem Avionics-Interface-Layer und dem Cross-Strapping-Interface her an. Folglich können die Voting-Services Nachrichten parallel voten. Jede Nachricht ist mit einem Message-Header versehen, der einen einmaligen Message-Identifier beinhaltet. Zusätzlich beinhaltet der Message-Header eine Message-Class, um die Voting- und Datenaustausch Strategie zu spezifizieren. Es wird unterschieden in: Quasi Congruent Data Identische Daten Congruent Data Applikationsdaten, die dicht beieinander liegen ( Typisches Beispiel: Sensor-Daten ) N-type Data Applikations Daten, bei denen (n-1)-out-of voting angebracht ist. Für jede einzelne Message-Class sind bis zu 20 parallel votende Einheiten in den Voting-Services installiert, um die asynchron ankommenden Daten zu empfangen, speichern und zu vergleichen. Die Message-Classes sind Tabellengesteuert und können über die Applikationssoftware konfiguriert werden. Eine Message-Class ist gültig für genau einen subframe time slot im TTP Protokoll. Jeder subframe time slot hat seine eigene Message-Class, unabhängig von den anderen slots. Die beschriebene Methode erlaubt eine Optimierung zwischen Datendurchsatz und Fehlertoleranz-Level. Oliver Hoins 9

Aus der Tabelle in Abbildung [ 6 ] ist zu erkennen, daß unterschiedliche Message-Classes und deren unterschiedliche Voting-Strategien zu unterschiedlichen Datendurchsatzwerten führen. Abbildung: 6 Message-Classes und deren Voting-Strategien Darüber hinaus hängt die Datendurchsatz-Kapazität des FML Layers von der zu votenden Nachrichtenlänge ab. Für eine durchschnittliche Nachrichtenlänge von 256 Bytes und einem Mix von 50% Single Path Input, 25% Lane Local Output und 25% Quasi Congruent Output kann ein FML Datendurchsatz von 160,9kbyte / Sekunde angenommen werden. Hierbei werden bereits die Grenzen des Avionics Bus Inerfaces erreicht. Die Fehlertoleranz des FTC kann umgangen werden, wenn die Single-Path-Message Class nur für die Daten-Akquisition und die Lane-Local-Message Class ausschließlich für den Data Output benutzt wird. In diesem Fall kann eine totale Datendurchsatzrate von 212 kbyte / Sekunde erreicht werden. Wenn jedoch die Byzantine-Fehlertoleranz verwendet wird, reduziert sich der FML Datendurchsatz auf 25,8 kbyte / Sekunde und eine durchschnittliche Datengröße von 256 Byte. Dieses Beispiel zeigt, wie ein optimaler Datendurchsatz durch das tunen der Parameter: Datengröße Fehlertoleranzlevel Avionics Interface Kommunikationsrate erreicht werden kann. Zusätzlich zu den Applikationsdaten, die zwischen den Lanes gevotet werden, ist ein Typ von Nichtkritischen Daten definiert, der nicht gevotet wird, um System-Overhead für nicht-kritische Daten zu vermeiden. Oliver Hoins 10

Folgende Abbildung soll noch einmal den Zusammenhang von Message-Länge und Message-Klasse ( Class ) veranschaulichen. Abbildung: 7 FML Datendurchsatz als Funktion von Message-Länge und Message-Klasse Avionics Bus System Das Avionics Bus System besteht aus sechs voneinander unabhängigen MIL-STD 1553 Bussen. Der MIL-STD 1553 Bus unterstützt eine Master- ( Bus-Controller ) und eine Slave- ( Remote Terminal ) Architektur und erlaubt eine synchrone Datenübertragung / Akquisition. Abbildung: 8 Avionics Bus System Oliver Hoins 11

Der FTC ist Busmaster auf vier Bussen und gleichzeitig ein Slave auf den zwei anderen Bussen. Das für das System geforderte time tagged protocol TTP definiert timeframes von 10 Sekunden, 1 Sekunde, 100mSekunden, 12,5mSekunden. Das 100mSekunden Frame wird Processing-Frame genannt und ist akzentuiert mit einem Broadcast Synchronisations Kommando, welches vom Busmaster ausgeführt wird. Einerseits, ist die FTC Fault Tolerant Clock zu diesem Frame fern-synchronisiert ( über das empfangene Broadcast Synchronisations Kommando auf den FTC Remote Terminal Interfaces ). Andererseits verarbeiten die FTC Busmaster ihrerseits das Broadcast Synchronisations- Kommando auf den Bus Controller Interfaces. Diese FTC Eigenschaft erlaubt somit eine simultane Operation sowohl als Slave-, als auch als Master- System auf den Avionics Bussen, wie aus folgender Abbildung ersichtlich wird. Abbildung: 9 Master-Slave Synchronisation Technische Details des FTC: FCR Abmessungen ( L * B * H ) Gewicht Spannungsversorgung Leistungsverbrauch 1-FCR Operation 2-FCR Operation 3-FCR Operation 4-FCR Operation Operations-Umgebung Druck Umgebungstemperatur Basis-Platten-Temperatur Rechenleistung Speichergröße RAM FlashPROM 295 mm * 160 mm * 250 mm 6,5 kg / pro FCR 28 Vcd +/- 4 Vdc 41 W / pro FCR 39 W / pro FCR 39 W / pro FCR 37 W / pro FCR 0... 1 bar ( 10 5 Pa) -20 0 C... 60 0 C -20 0 C... 40 0 C 9 MIPS / 2,5 MFLOPS 8 Mbyte 4 MByte Oliver Hoins 12

Literaturverzeichnis: [ 1 ] Gerd Urban ( Daimler-Benz Aerospace Bremen ) Hans-Joachim Kolinowitz ( Daimler-Benz Aerospace Bremen ) Jan Peleska ( JP Software Consulting and Bremen Institute of Safe Systems (BISS) IEEE Computer Society Technical Comitee on Fault Tolerant Computing: FTCS-28 The Twenty-Eight Annual International Symposium on Fault-Tolerant Computing, June 23-25, 1998, Munich, Germany [ 2 ] Lamport, Shostak and Pease: The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, Vol 4, No 3, (1982) [ 3 ] H.Kopetz: Real-Time Systems, Kluver Academic Publishers, 1997 [ 4 ] Daimler-Benz Aerospace Space Infrastructure: Fault Tolerant Computer ( FTC ) Applying the Byzantine Algorithm, Leaflet [ 5 ] S.-T. Levi, A.K. Agrawala: Fault Tolerant System Design, MCGraw-Hill Series on Computer Engineering, 1994 [ 6 ] Douglas Kiuntke: Fehlertolerante Architekturen, Hochschule Bremen, http://www.weblearn.hs-bremen.de/risse/rst/ss99/faulttol.rnc/ft_archt.html, 1999 Danksagung: Diese Danksagung gilt Herrn Dipl.-Ing. Hans-Joachim Kolinowitz, Head of New Products & Avionics Software, im Bereich Orbital Systems & Operations der DaimlerChrysler Aerospace Space Infrastructure Bremen, ohne dessen freundliche Unterstützung in der Beschaffung technischer Schriften und der Erklärung technischer Zusammenhänge diese Ausarbeitung nicht möglich geworden wäre. Vielen Dank, Oliver Hoins Oliver Hoins 13