Oliver Hoins 1

Fehlertolerante Hardware Systeme

Am Beispiel des

Fault Tolerant Computer ( FTC )

der

DaimlerChrysler Aerospace AG Raumfahrt InfrastrukturBremen

Oliver Hoins

( European Electrotechnical Studies EES )

Hochschule Bremen im Wintersemester 1999/2000

Abstract:Dieses Essay beschäftigt sich mit dem FaultTolerant Computer ( FTC ) welcher für dieInternationale Raumstation ( ISS ) von derDaimlerChrysler Aerospace AG RaumfahrtInfrastruktur am Standort Bremen entwickeltwurde. Ziel dieser Ausarbeitung ist es, auf diebesonderen Anforderungen an FehlertoleranteHardware hinzuweisen, die im Bereich derRaumfahrt zu beachten sind. Des weiterenwird der interne Aufbau des FTC und der demSystem zugrunde liegende Byzantine-Algorithmus beschrieben.

Introduction:Der DaimlerChrysler Aerospace ( Dasa ) FaultTolerant Computer ( FTC ) wurde fürRaumfahrt Applikationen entwickelt, für dieeine hohe Zuverlässigkeit (reliability), hoheVerfügbarkeit (availability), sowie hoheStrahlungstoleranz (radiation - tolerance)essentiell sind.Der FTC ist ein modularer Computer, der demUser eine hohe Rechenleistung zur Verfügung

stellt und mit bis zu zwei nicht-simultanen ( twonon-simultaneous faults ) umgehen kann.Zu Kommunikationszwecken ist der FaultTolerant Computer mit sechs MIL-STD 1553BInterfaces ausgerüstet und ist vorbereitet, dasSynchronous Packet Transfer Protokoll ( SPT )zu unterstützen, welches für dieKommunikation an Bord der InternationalenRaumstation verwendet werden wird.

Der Fault Tolerant Computer besteht ausidentischen Computern ( Hard- und Software ),wobei jeder Computer in einem separatenGehäuse untergebracht ist. Diese Einheitenwerden Fault Containment Regions ( FCR )genannt. Sie operieren simultan undbearbeiten identische User-ApplikationsSoftware.

Um, wie spezifiziert, mit zwei Fehlern umgehenzu können, werden vier FehlertoleranteRegionen ( FCRs ) benötigt, deren Aufbau undZusammenspiel in dieser Ausarbeitungbeschrieben werden sollen.

Oliver Hoins 2

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 3

Erklärung der Grundbegriffe

Im folgenden sollen die Grundbegriffe, die für das allgemeine Verständnis dieser Ausarbeitungnotwendig sind erläutert werden. Da vollständige Einführungen in die Begriffswelt den Rahmen dieserAusarbeitung sprengen würden, wird für detailliertere Ausführungen auf geeignete Literatur [6]verwiesen.

Fehlertoleranz: ( Fault Tolerance ) Fähigkeit eines Systems, sich trotz einer begrenzten Zahlvon Fehlern spezifikationsgerecht zu verhalten. Fehler in diesemZusammenhang können sein: Betriebsfehler, Entwurfs-, Herstellungs-,Bedienungs- oder Wartungsfehler.

Zuverlässigkeit: ( Reliability ) ist die Wahrscheinlichkeit dafür, daß ein System während einervorgegebenen Zeitdauer bei zulässigen Betriebsbedingungen die spezifizierteFunktion erbringt.

Verfügbarkeit: ( Availability ) bezeichnet die Wahrscheinlichkeit dafür, daß ein System zueinem gegebenen Zeitpunkt fehlerfrei ist, also spezifikationsgerechtfunktioniert.

Fehler-Ursachen: ( fault ) bezeichnet die physikalische Ursache für Fehlzustände einesbetroffenen Systems. Die Ursache hierfür kann im System selbst oder aber inseiner Umgebung liegen; sie kann temporär oder permanent sein.

Fehler: ( error ) bezeichnet den Teil eines fehlerhaften Systemzustandes, der zueinem Systemausfall führen kann, aber nicht zwingend führen muß.

Ausfall: ( failure ) bezeichnet den Übergang von einem fehlerfreien in einenfehlerhaftes Erbringen der Dienstleistung.

Fehlertolerant: Ein Rechner mit Fehlertoleranz

Fehlerausgrenzung: ( reconfiguration ) isoliert oder entfernt fehlerhafte Systemkomponenten,wobei besagte Komponenten aus Software- und Hardwarekomponentenbestehen können.

Fehlerbehebung: ( recovery ) versetzt das System in einen fehlerfreien Zustand, unterUmständen ohne fehlerhafte Komponenten zu entfernen. Fehlerbehebung istin erster Linie bei transienten Fehlerursachen angebracht, diedefinitionsgemäß nicht auf defekte Hardware, sondern auf äußere Einflüsse,wie im Bereich der Raumfahrt beispielsweise kosmische Strahlungzurückzuführen sind, und nur für kurze Zeit wirken.

Fehlerkompensation: ( masking ) beläßt sowohl fehlerhafte Komponenten als auch derenfehlerhafte Zustände im System, korrigiert oder maskiert jedoch derenAuswirkungen.

Redundanz: ( redundant ) Es sind mehr Betriebsmittel vorhanden, als für die vorgeseheneFunktion des Systems benötigt werden. ( Zuverlässigkeitssteigerung ).§ Strukturelle Redundanz: Erweiterung des Systems um zusätzliche

Hard- und Softwarekomponenten, z.B. um Reserve- undDiagnoserechner.

§ Funktionelle Redundanz: Erweiterung des Systems um zusätzlicheFunktionen, z.B. um Testfunktionen, Fehlervorhersage oder die Erstellungvon Sicherungsdaten.

Oliver Hoins 4

Anforderungen an Rechnersysteme für die Raumfahrt

Im folgenden werden Gründe für Eigenentwicklungen wie den Fault Tolerant Computer FTC derDASA im Bereich der Raumfahrt aufgezeigt.

Auf den ersten Blick ist vielleicht nicht gleich ersichtlich, warum die DASA drei Jahre Entwicklungszeitund immenses Summen investiert, um selber fehlertolerante Rechensysteme für das All zuentwickeln, anstatt auf Systeme von Drittherstellern zurückzugreifen, die universell für einen breitenMassenmarkt zugeschnitten sind und somit wesentlich kostengünstiger sind.Grund hierfür sind spezielle Anforderungen an Systeme für die Raumfahrt, die an universelleLö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ärmeableitungRechensysteme im Luftleeren Raum können nicht wie gewohnte Systeme mit Ventilatorengekühlt werden. Spezielle Thermische Senken ( thermal vakuum design ) müssen für jedes ICund jeden Transistor errechnet und realisiert werden, um nicht aufgrund von solchenEntwurfsfehlern fehlerhafte Systemzustände oder sogar Ausfälle herbeizuführen.

§ Breitband-Strahlung ( radiation )Im Weltraum herrscht eine, im Vergleich zur Erdatmosphäre, sehr energriereicheTeilchenstrahlung. Diese primäre Strahlung besteht vorwiegend aus Protonen, daneben ausAlphateilchen, schweren Atomkernen und Elektronen. Der genaue Ursprung dieser Strahlung,die immerhin Energien von bis zu 1018 Elektronenvolt aufweist, ist nicht bekannt, jedoch istderen Auswirkung auf die Hardware von Rechensystemen nicht zu unterschätzen. So müssenzum Beispiel wesentlich höhere Abstände der Leiterbahnen eingehalten werden, die imGegensatz zur heute üblichen Miniaturisierung solcher Komponenten steht.

Zusätzlich zu den genannten Anforderungen, die nur einen Bruchteil der tatsächlichen Anforderungenan solche Systeme ausmacht, ist natürlich die Kompatibilität zu- und die Kommunikationsfähigkeit mit-allen Systemen der Internationalen Raumstation zu erreichen, die Eigenentwicklungen vonfehlertoleranten Computern für diesen Bereich rechtfertigen und sogar zwingend erforderlich machen.

Oliver Hoins 5

Aufbau und Funktion des FTC:

Aufgrund der Anforderungen an die Internationale Raumstation wurde ein Zwei-Fehler-tolerantes FTCDesign erwartet. Dieses soll die Möglichkeit bieten, sich von einem beliebigen (arbitrary) Fehler zurZeit, und von einem zweiten, jedoch deterministischen Fehler zu erholen. Der Umgang mit zweisimultan 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 ohneApplikationssoftware-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 sindgetrennt. 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-kompatiblenChipsatz und benutzt das off-the-shelf Betriebssystem VxWorks, das die Plattform für die UserApplikationssoftware bietet.

§ Ein Transputer T805/20MHz Netzwerk für den FML und AVI Layer

§ Das Byzantine Protokoll [ 2 ] als Fehler Management Algorithmus, um Übereinstimmung zwischenden 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 andereKomponenten, je nach Projekt-Anspruch, ersetzt werden.

Da Marketinganalysen zeigten, daß Kunden ein großes Interesse daran haben, ihre eigene Hardwareinnerhalb 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. Sowurden bereits Tests mit einem AL Board der Firma LORAL, basierend auf einem strahlungsfestenRS6000 Prozessor und einem AL Board der Firma FORCE, basierend auf einer SPARC Architekturgefahren.

Oliver Hoins 6

Detaillierte FML Beschreibung:

Das Kernelement des FTC ist der FML Layer, der den Algorithmus für das Byzantine Protokollbeinhaltet, welches zwischen den Lanes benutzt wird.

Da eine flexible, FCR redundante Konfiguration einen großen Vorteil für Fehlertolerante Computer inder 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 erzieltwerden, da bezugnehmend auf diesen Algorithmus ein Computer F willkürliche ( Byzantine ) Fehlerisolieren 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 ) Pfadeverbunden sein.

§ Die Daten zwischen den FCRs müssen ( F + 1 ) mal ausgetauscht werden undentsprechend 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 TolerantComputer 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 undFirmware 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 gesamteSoftware ist in der OCCAM II Sprache implementiert. Diese Lösung weicht zwar von der üblichenPraxis, ADA als bewährte Sprache zu benutzen, ab, jedoch rechtfertigen die Größe, sowie dieLaufzeiteffiziente Implementierung von OCCAM II diese Lösung. Des weiteren gibt es nur wenigeBenutzer, die Erfahrung mit ADA für Transputer haben, und das Risiko eines Ausfalls aufgrund vonTool-Problemen wurde als zu groß angesehen.

Oliver Hoins 7

Fehler Management Software:

Die Fehler Management Software beinhaltet Funktionen für Lane ( FCR ) – Isolation, Re-Integrationvon FCRs und das FML System Konfigurations Management.Das Design der Fehler Management Software basiert auf einem FML Status Vektor, der in zweiSchritten verbreitet, gevoted und über die Fehlertolerante Clock synchronisiert wird. Die Verbreitungdes 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 anderendrei Lanes und sammelt die Status-Informationen der anderen drei Lanes. In jeder Lane resultiert diesin einem Status-Vektor mit einem Eintrag für jede Lane.

Im zweiten Schritt des Protokolls werden die Status-Vektoren unter den Lanes ausgetauscht. Darausresultierend hat jede korrekt operierende Lane eine verläßliche Information über die Status-Vektorender anderen korrekt operierenden Lanes.

Solange höchstens ein Byzantine Fehler auftritt, genügt dieses Verfahren um Übereinstimmung unterden korrekt operierenden Lanes zu erreichen, die alle die gleichen Votingprozeduren an den Vektorenausführen.Es ist zu beachten, daß das Byzantine Protokoll zwar die Übereinstimmung korrekt operierenderKomponenten anhand der Voting-Vektoren garantieren kann, es jedoch keine Fehlererkennunggarantieren kann, sofern die fehlerhafte Komponente ihr fehlerhaftes Verhalten ausschließlich aufeiner anderen Lane zeigt.Um dieses Problem zu umgehen, kopiert jede Lane die zur Verteilung bereitstehenden Vektoren voneiner „Storage-Location“ zu den Tranputer Links. Ferner ist jeder Vektor mit einer CRC Checksummeassoziiert, bevor er in der „Storage-Location“ plaziert wird. Als Konsequenz hieraus erhalten dieanderen Lanes entweder identische Vektoren von der fehlerhaften Komponente oder sie erhaltenVektoren mit inkonsistenten CRC Werten. Dieses Konzept bietet eine große Wahrscheinlichkeit fürdas Aufspüren fehlerhafter Lanes ( FCRs ).

Der Austausch dieser Status-Vektoren informiert jede Lane über den Operationsstatus aller anderenLanes. In einer fehlerfreien Situation sind die operationellen states aller Lanes gleich, jedoch nichtbitweise identisch. Eine fehlerhafte Lane in einer 4–FCR-Konfiguration kann im Falle einerNichtübereinstimmung des Status-Vektors durch ein Remote-Reset der korrekt arbeitenden Lanesisoliert 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 seinenOperationen fort, sofern der Fehler von temporärer Natur ist. Bei n – fachem Auftreten des Fehlers ineinem 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 dieserKonfiguration ist er immer noch fehlertolerant in Hinsicht auf einen deterministischen Fehler durchsogenanntes 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 dieIsolation einer potentiell korrupten FCR. Selbst ein willkürlicher ( arbitrary ) Fehler kann in diesemFalle toleriert werden, sofern die Statusvektoren, wie oben beschrieben, in zwei Schritten gevotetwurden.

Nach Ausfall einer FCR, also in einer 3-FCR–Konfiguration, wird sich eine fehlerhafte FCR selbstresetten, sobald eine permanente Nichtübereinstimmung der Votingergebnisse auftritt. Dies jedochsetzt ein deterministisches Verhalten der betroffenen Komponente im Falle eines Fehlers voraus. Mitanderen Worten, es muß sich in der 3-FCR-Konfiguration beim zweiten Fehler um einendeterministischen Fehler handeln.

Oliver Hoins 8

Nach Ausfall einer zweiten FCR, also in einer 2-FCR–Konfiguration, wird im Falle einerNichtübereinstimmung der Votingergebnisse keine Isolation mehr vorgenommen, und der FTC arbeitetselbst bei einem Fehler weiter, bis ein hardware-buit-in Test-Reset ausgelöst wird.

Die Rekonfiguration geschieht in einer vordefinierten Reihenfolge. Die Rekonfigurarion von einerquadruplex zur triplex, zur duplex und schließlich zur simplex geschieht völlig autonom, ohne eineService Unterbrechung der Applikationssoftware. Dies kann von einem Operator, aus Gründen derEnergieeinsparung etc. eingeleitet werden, oder von der FML selbst, um eine fehlerhafte Lane zuisolieren.

Synchronisation der Komponenten

Der FTC besteht aus einem lose gekoppeltem Prozessor-Netzwerk des MIMD Typs. Alle Prozessorenwerden über einen separaten, fehlertoleranten Takt ( fault-tolerant clock ) mit einer 10 Hz Frequenzsynchronisiert. Diese Taktung basiert auf der Frequenz des TTP Protokolls an Bord derInternationalen Raumstation ISS.Zwischen den Synchronisations-Events operieren alle Prozessoren unabhängig. Dieses Designerlaubt somit einen Grad an Heterogenität zwischen den FCRs.

Die Fault Tolerant Clock ist in einem FPGA Schaltkreis implementiert und erlaubt eine Präzision derSynchronisation 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 gesamtenFTC 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 - cross-strappingØ Fault Tolerant Clock - cross-strappingØ Remote-Reset - cross-strapping

Abbildung: 5 Cross-Strapping Verbindungen in einer 4 FCR-Konfiguration

Oliver Hoins 9

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 dieBenutzung eines time-tagged protocol ( TTP ) zusammen mit bit-seriellen Bussen. Um jedoch demByzantine Protokoll nachzugeben und einen Vorteil aus der mächtigen TransputerKommunikationsfähigkeit zu erhalten, wurde die geforderte Point-to-Point Verbindung mit denTransputer links geschaffen.

Folglich findet der Datenaustausch völlig asynchron und parallel auf allen seriellen Transputerlinksstatt.

Ø Es kann somit eine totale Kommunikations-Bandbreite von über 48 Mbit / Sekunde erreichtwerden.

Zwar scheint diese Bandbreite recht hoch zu sein, jedoch ist das Byzantine Protokoll sehrKommunikationsintensiv und ein Byzantine-Fehlertoleranter Computer von beispielsweise F=2 scheintmit den derzeit zur Verfügung stehenden Hardware Komponenten des FTC nicht einmal möglich zusein.

Voting Services:

Wie bereits angesprochen sind die Voting-Services in Software implementiert. Die Voting-Servicesvergleichen Daten, die zu Nachrichten von maximal 756 Byte gruppiert werden. Die Datengröße paßtin ein subframe time slot des TTP Protokoll des Avionics Bus Systems.Die Voting-Services sind mit einem sogenannten time-out Management ausgestattet, um verloreneoder gestörte Nachrichten zu erkennen.

Nachrichten kommen asynchron von dem Applikations-Layer, dem Avionics-Interface-Layer und demCross-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-Identifierbeinhaltet. Zusätzlich beinhaltet der Message-Header eine Message-Class, um die Voting- undDatenaustausch Strategie zu spezifizieren.

Es wird unterschieden in:

Ø Quasi Congruent DataIdentische Daten

Ø Congruent DataApplikationsdaten, die „dicht“ beieinander liegen ( Typisches Beispiel: Sensor-Daten )

Ø N-type DataApplikations 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-Servicesinstalliert, um die asynchron ankommenden Daten zu empfangen, speichern und zu vergleichen.Die Message-Classes sind Tabellengesteuert und können über die Applikationssoftware konfiguriertwerden. Eine Message-Class ist gültig für genau einen subframe time slot im TTP Protokoll. Jedersubframe time slot hat seine eigene Message-Class, unabhängig von den anderen slots. Diebeschriebene Methode erlaubt eine Optimierung zwischen Datendurchsatz und Fehlertoleranz-Level.

Oliver Hoins 10

Aus der Tabelle in Abbildung [ 6 ] ist zu erkennen, daß unterschiedliche Message-Classes und derenunterschiedliche 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 votendenNachrichtenlä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 von160,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 dieDaten-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 auf25,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 Nicht-kritischen Daten definiert, der nicht gevotet wird, um System-Overhead für nicht-kritische Daten zuvermeiden.

Oliver Hoins 11

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. DerMIL-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 12

Der FTC ist Busmaster auf vier Bussen und gleichzeitig ein Slave auf den zwei anderen Bussen. Dasfür das System geforderte time tagged protocol TTP definiert timeframes von 10 Sekunden, 1Sekunde, 100mSekunden, 12,5mSekunden.

Das 100mSekunden Frame wird Processing-Frame genannt und ist akzentuiert mit einem BroadcastSynchronisations Kommando, welches vom Busmaster ausgeführt wird.

Ø Einerseits, ist die FTC Fault Tolerant Clock zu diesem Frame fern-synchronisiert ( über dasempfangene 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 ) 295 mm * 160 mm * 250 mmGewicht 6,5 kg / pro FCRSpannungsversorgung 28 Vcd +/- 4 VdcLeistungsverbrauch1-FCR Operation 41 W / pro FCR2-FCR Operation 39 W / pro FCR3-FCR Operation 39 W / pro FCR4-FCR Operation 37 W / pro FCROperations-UmgebungDruck 0 ... 1 bar ( 105 Pa)Umgebungstemperatur -20 0C ... 60 0CBasis-Platten-Temperatur -20 0C ... 40 0CRechenleistung 9 MIPS / 2,5 MFLOPSSpeichergrößeRAM 8 MbyteFlashPROM 4 MByte

Oliver Hoins 13

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 TheTwenty-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 onProgramming 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 ) Applyingthe Byzantine Algorithm, Leaflet

[ 5 ] S.-T. Levi, A.K. Agrawala: Fault Tolerant System Design, MCGraw-Hill Series on ComputerEngineering, 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 & AvionicsSoftware, im Bereich Orbital Systems & Operations der DaimlerChrysler Aerospace SpaceInfrastructure Bremen, ohne dessen freundliche Unterstützung in der Beschaffung technischerSchriften und der Erklärung technischer Zusammenhänge diese Ausarbeitung nicht möglich gewordenwäre.

Vielen Dank,

Oliver Hoins