Die Firma Mercury Systems entwickelt in Genf Komponenten für die Flugindustrie. Dem Trend zu höheren Datenraten bei der Kommunikation in den Flugzeugen wollen sie mit eigenen Produkten folgen. Zusammen mit dem Institut für Sensorik und Elektronik der FHNW entwickeln sie eine Lösung, die im Vergleich zum Profi bus (Process Field Bus) oder dem AFDX-Standard (Avionics Full-Duplex Switched Ethernet) eine höhere Datenrate erreicht und gleichzeitig einfacher aufgebaut ist.
Hoher Sicherheitsstandard braucht Weiterbildung
Weil die zu entwickelnde Kommunikationseinheit höchsten Sicherheitsansprüchen gerecht werden muss, ist eine Entwicklung nach dem Standard RCTA DO-254 DAL-A Pfl icht. Das entspricht der höchsten von fünf Sicherheitsstufen und bedeutet, dass ein Fehler der Einheit zu einer Katastrophe, beispielsweise zu einem Flugzeugabsturz, führen kann. Damit es nicht so weit kommt, muss eine Fehlerwahrscheinlichkeit von <10–9 erreicht werden (weniger als ein Fehler in 100 000 Jahren). Das Entwicklungsteam durchlief ein intensives Training, um die speziellen Arbeitsprozesse eines solchen Projekts kennenzulernen. Ein Grossteil der Entwicklungsarbeit wird von jungen wissenschaftlichen Assistenten durchgeführt, die parallel den Master of Science in Engineering MSE absolvieren. Aber auch für die erfahrenen Projektmitglieder ist der Prozess nach DO-254 neu. Die meisten kennen jedoch die Bedeutung von «First-Time-Right» aus der ASIC-Entwicklung, wo Fehler sehr teuer sind und zu riesigen Projektverzögerungen führen.
Unabhängige Rollen sind zwingend
Bei der Entwicklung von Hardware-Komponenten nach der Sicherheitsstufe DAL-A ist eine klare Rollenaufteilung wichtig. Ein System Engineer defi niert in Zusammenarbeit mit dem Kunden die Anforderungen an die Hardware. Der Kunde validiert die Richtigkeit des Dokuments. Ein Designteam implementiert die defi nierten Anforderungen, während ein Verifi kationsteam überprüft, ob alle Anforderungen korrekt umgesetzt werden. Dabei ist es zwingend, dass Verifi kationsteam und Designteam unabhängig voneinander operieren. Missverständnisse von einem der Teams sollten bei der Verifi kation zu Fehler führen und nach der Klärung mit dem System Engineer korrigiert werden. Unklarheiten bei den Anforderungen dürfen nicht zwischen dem Design- und Verifi kationsteam geklärt werden.
Massnahmen gegen Single Event Upsets
Beim Designteam kommt noch eine Zusatzaufgabe hinzu, die vom Verifi kationsteam nicht überprüft werden kann. Speziell in der Avionik ist die Wahrscheinlichkeit von Single Event Upsets (SEU) gegeben. Dabei kommt es beim Durchgang hochenergetischer ionisierender Teilchen zu Zustandsänderungen in Speicherelementen. Das Designteam hat somit die Aufgabe, jedes gespeicherte Bit zu klassifizieren und zu bestimmen, welche Auswirkungen ein SEU haben kann. Danach müssen für jede Kategorie entsprechende Massnahmen ergriffen werden. Denkbar ist, dass ein Datenpaket mit einer Checksumme versehen wird oder dass ein kritisches Bit mehrfach redundant implementiert wird. Ein Safety Engineer hilft dem Designteam bei dieser Aufgabe.
Tests müssen alle Designfehler erkennen
Die grosse Herausforderung beim Verifikationsteam ist, dass eine hundertprozentige Fehlerabdeckung erreicht werden muss. Sie stellen sich die Fragen «Entwickeln wird das richtige System?» (Validierung) und «Entwickeln wird das System richtig?» (Verifizierung). Gemessen wird die funktionale Abdeckung, wo alle in der Spezifikation definierten Anforderungen erfolgreich getestet werden müssen. In den Spezifikationen müssen die Anforderungen zwingend so definiert werden, dass ein entsprechender Test Case eine automatische Überprüfung ausführen kann.
Potenzielle Fehlerfälle müssen simuliert und die daraus resultierenden Fehlermeldungen analysiert werden. Auch die CodeAbdeckung darf keine Lücken aufweisen. Alle Befehle, alle Verzweigungen, alle Bedingungen sowie alle Zustände und Transaktionen müssen bei der Simulation mindestens einmal ausgeführt werden. Nur wenn beide Metriken der Fehlerabdeckung erfüllt sind, kann mit grosser Wahrscheinlichkeit behauptet werden, dass keine Fehler im Design mehr übrig sind.
Dokumentation entscheidet über Zertifizierung
Begleitet wird das Projekt von einem Configuration Engineer, der jederzeit einen beliebigen Stand im Projekt aus dem Repository zurückspielen kann und einem Quality Engineer, der den Ablauf des Projekts und die Einhaltung der definierten Prozesse überprüft. Die Einhaltung des Standards wird anhand der Dokumentation nachgewiesen. Dabei gibt es weder Standardvorlagen noch einen Musterprozess. Für jedes Projekt muss man den Prozess explizit definieren. Anhand des PHAC (Plan for Hardware Aspects of Certification) erkennt die externe Zertifizierungsstelle, ob das Vorgehen den Anforderungen von DO-254 genügt. In einem weiteren Planungsdokument, dem DAP (Design Assurance Plan), werden vier Prozesse detailliert beschrieben:
■ Design Process
■ Validation & Verification Process
■ Configuration Process
■ Process Assurance.
Projektablauf nach dem Wasserfallmodell
Das Projekt steht gegenwärtig beim Institut für Sensorik und Elektronik FHNW kurz vor Abschluss. Der immense Aufwand für die Entwicklung einer elektronischen Komponente nach dem Sicherheitsstandard DAL-A wurde sichtbar. Im Vergleich zu einem nicht-sicherheitsrelevanten Projekt erhöht sich der Aufwand etwa um den Faktor fünf. Der Sicherheitsaspekt ist auch der Grund, warum das Projekt nach dem Wasserfallmodell durchgeführt wird und nicht mit agilen Methoden. Würden sich die definierten Anforderungen während dem Projekt ändern, müssten die ganze Verifikation und Validation neu beginnen. Der Aufwand wäre noch grösser.
Wofür steht RTCA DO-254 DAL-A?
RTCA steht für Radio Technical Commision for Aeronautics, einer US-amerikanischen Organisation, die technische Leitlinien für die Luftfahrt aufstellt.
DO-254, mit vollem Namen Design Assurance Guidence für Airborne Electronic Hardware, ist ein Dokument mit Richtlinien zur Entwicklung von elektronischer Hardware in der Luftfahrt.
DAL-A bedeutet Design Assurance Level, also die Sicherheitsstufe der jeweiligen Hardware.
Infoservice
Swiss Engineering
Fachgruppe für Elektronik & Informatik
Im Hochrain 6, 8102 Oberengstringen
Tel. 076 521 09 10
