Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03309.jsonl.gz/1527

Profibus (Process Field Bus) ist ein beliebter, robuster Industrie-Standard für die Feldbus-Kommunikation. Mit dem Wunsch nach höheren Datenraten werden jedoch Alternativen gesucht. Airbus setzt in ihren Flugzeugen auf den AFDX-Standard (Avionics Full-Duplex Switched Ethernet). Die Komplexität von AFDX ist sehr hoch und eignet sich darum für kleinere Flugzeuge nicht. Das Institut für Mikroelektronik FHNW wurde von Mercury Systems beauftragt, eine einfachere, kostengünstigere Lösung zu suchen.
Weil die zu entwickelnde Kommunikationseinheit höchsten Sicherheitsansprüchen gerecht werden muss, ist eine Entwicklung nach dem Standard RTCA DO-254 DAL-A Pflicht. Das entspricht der höchsten von fünf Sicherheitsstufen (siehe Kasten «Glossar») 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.
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 absolviren. 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.
Bei der Entwicklung von Hardware-Komponenten nach der Sicherheitsstufe DAL-A ist eine klare Rollenaufteilung wichtig. Ein System Engineer definiert in Zusammenarbeit mit dem Kunden die Anforderungen an die Hardware. Der Kunde validiert die Richtigkeit des Dokuments. Ein Designteam implementiert die definierten Anforderungen, während ein Verifikationsteam überprüft, ob alle Anforderungen korrekt umgesetzt werden.
Die zwei Teams müssen zwingend unabhängig voneinander operieren. Missverständnisse eines der Teams sollten bei der Verifikation zum 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 Verifikationsteam geklärt werden.
Beim Designteam kommt noch eine Zusatzaufgabe hinzu, die vom Verifikationsteam 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 Datenpacket mit einer Checksumme versehen wird oder dass ein kritisches Bit mehrfach redundant implementiert wird. Ein Safety Engineer hilft dem Designteam bei dieser Aufgabe.
Die grosse Herausforderung für das Verifikationsteam besteht darin, 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.
Potentielle Fehlerfälle müssen simuliert und die daraus resultierenden Fehlermeldungen analysiert werden. Auch die Code-Abdeckung 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.
Begleitet wird das Projekt von einem Configuration Engineer, der jederzeit einen beliebigen Stand im Projekt aus dem Repository zurückspielen kann und von 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 ein Musterprozess. Für jedes Projekt muss der Prozess explizit definiert werden. 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:
Das Projekt steht gegenwärtig beim Institut für Mikroelektronik FHNW mitten in der Implementation. Bereits jetzt ist der immense Aufwand für die Entwicklung einer elektronischen Komponente mit dem Sicherheitsstandard DAL-A 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 im Verlauf des Projektes ändern, müssten die ganze Verifikation und Validation neu beginnen. Der Aufwand wäre so noch grösser.
Fachhochschule Nordwestschweiz FHNW, Hochschule für Technik
5210 Windisch, Tel. 056 202 99 55
<email-pii>
Wofür steht RTCA DO-254 DAL-A?
RTCA steht für «Radio Technical Commision for Aeronautics»; US-amerikanische Organisation, die technische Leitlinien für die Luftfahrt aufstellt. DO-254 bedeutet «Design Assurance Guidence für Airborne Electronic Hardware»; ein Dokument mit Richtlinien zur Entwicklung elektronischer Hardware in der Luftfahrt. DAL-A steht für «Design Assurance Level», die Sicherheitsstufe der jeweiligen Hardware. Die Skala geht von E (kein Effekt; Beispiel: Entertaining-System eines Flugzeugs) bis zu A (katastrophaler Effekt; Beispiel: Flugkontrollen).
MAS Mikroelektronik
Die Hochschule für Technik FHNW bietet verschiedene Weiterbildungsmöglichkeiten an. Der Master of Advanced Studies (MAS) in Mikroelektronik richtet sich an Entwicklerinnen und Entwickler sowie Projektleitende, die ein elektronisches System von den Anforderungen bis zum fertigen Produkt begleiten.
Nächster Start: 22. September 2017
Nächste Infoabende:
26. Juni und 23. August in Windisch,
30. Oktober 2017 in Basel.
fhnw.ch/weiterbildung-technik