Die DO-254 - Design Assurance Guidance for Airbourne Electronic Hardware - ist ein Standard zur Softwareentwicklung im sicherheitskritischen Bereich der Luftfahrt. Das Interesse an einem Entwicklungsleitfaden für Hardwareentwicklung, wie es die DO-254 ist, etablierte sich zuerst in Europa im Zuge der Arbeiten am Großraumflugzeug A380 Anfang der 2000er Jahre. Heute ist die DO-254 auch für die amerikanische Luftfahrtindustrie ins Interesse gerückt. Die beiden wichtigsten Luftfahrtbehörden - sowohl die europäische EASA, als auch die amerikanische FAA fordern heute bei der Entwicklung komplexer elektronischer Hardware die Einhaltung der in der DO-254 geforderten Prozesse. Dieser Artikel ist eine Einführung in den Luftfahrtstandard DO-254, der vor allem die wichtigsten Kernaussagen der Norm und deren Auswirkungen auf Ihre Produkte und Anwendungen verdeutlichen soll.

Was ist die DO-254?

Die DO-254 enthält Leitlinien zur Qualitätssicherung bei der Entwicklung elektronischer Hardware zur Gewährleistung einer sicheren Funktion. Sie bietet einen Rahmen von Überlegungen für die Zertifizierung der gesamten  Entwichlung. Wie dieser Rahmen im einzelnen etabliert wird, schreibt die Norm nicht vor und gleicht sich damit der DO-178B, dem Zwillingsstandard für Softwareentwicklung an. Die DO-254 ist nicht isoliert zu betrachten. Sie ergänzt eine ganze Reihe von anderen Standards und Prozesse, wie z.B. Sicherheits- und Umweltverträglichkeitsprüfungen (DO-160).  Den Schwerpunkt der DO-254 bildet jedoch die elektronischen Hardware. Soweit es diesen Standard betrifft, gibt es nur Hard-und Software (für welche die DO-178B gilt). Einen Mittelweg, wie er lange Zeit in Form von sog. Firmware gern gegangen wurde, sieht die Norm nicht vor. Bis heute konnte auch noch nie Jemand sicher definieren, was genau der Unterschied zwischen Fimware und Software oder zwischen Firmware und elektronischer Hardware sei. Es ist deshalb davon auszugehen, dass für fliegende kommerzielle Hardware und Software die beiden Normen DO-254 und DO-178B ohne Ausnahme anzuwenden sind. Die Kritikalität oder der Fehlerzustand wird mit Hilfe einer Sicherheitsbewertung auf Systemebene bestimmt. Die Bewertung legt die Schwere eines Ausfalls der betroffenen Hardware mit Hilfe von 5 Stufen fest, um davon den Aufwand abzuzleiten, mit dem die Hardware entwickelt und gestested werden muss und welche Einschränkungen während der Enwticklung ggf. zu beachten sind:

Der Ausfall einer Level A Hardware führt zu einem sog. katastrophalen Zustand und verhindert den sicheren Weiterflug und/oder die Landung. Ein Level A Fehler ist nicht öfter als einmal in einer Milliarde Flugstunden zulässig. Hardware dieser Art wird d.h. redundant ausgelegt. Es gibt das selbe System mit den selben Aufgaben also mindestens zweimal. In der Praxis werden Systeme bis zu vierfach redundant ausgelegt. Solche Backup Funktionen und Systeme nehmen in einem Flugzeug sehr viel Platz und vor allem Gewicht ein. Und daher verwundert es auch nicht, dass es nur sehr wenige Level A-Systeme gibt (Beispiel: Engine Control Hardware).

Der Ausfall einer Level B Hardware führt zu einem gefährlichen Zustand und reduziert die Sicherheitsreserven eines Flugzeugs auf ein Minimum. Es kommt zu einer hohen Belastung für die Besatzung um das Flugzeug sicher zu handhaben, und möglicherweise zu schweren oder tödlichen Verletzungen der Insassen. Ein Level B Fehler ist nicht öfter als einmal in zehn Millionen Flugstunden zulässig. (Beispiel: Primary Flight Displays (PFD)).

Der Ausfall einer Level C Hardware führt zu einem größeren Ausfallzustand mit zunehmender Arbeitsbelastung für die Crew und sinkenden Sicherheitsmargen. Der Ausfall führt nicht zu tödlichen Verletzungen, verursacht jedoch möglicherweise Unbehagen und leichte bis mittelschwere Verletzungen der Insassen. Ein Level C Fehler ist nicht öfter als einmal in 100.000 Flugstunden zulässig.(Beispiele: Autopilot und automatische Landesysteme).

Der Ausfall einer Level D Hardware führt zu einem geringen Ausfallzustand. Dennoch ist er im Hinblick auf die Sicherheit spürbar. Von der Besatzung ist eine erhöhte Aufmerksamkeit gefordert. Der Ausfall kann auch zu einigen Unannehmlichkeiten für die Passagiere führen.  Ein Level D Fehler ist, wie ein Level C Fehler nicht öfter als einmal in 100.000 Flugstunden zulässig. (Beispiele: Transponder- und Kommunikationstechnik).

Der Ausfall einer Level E Hardware hat keine nachteiligen Auswirkungen auf die Sicherheit des Fluges oder die Flugzeuginsassen. (Beispiele: Entertainment-Funktionen, Satelliten-Telefon und Internetzugang).

Die Klassifizierung von Systemen wird vor allem aus Kostengründen vorgenommen. Flugzeuge wären wohl sicherer, wenn ausnahmslos jedes Bauteil an Bord eines Flugzeugs mit maximalem Aufwand, was die Sicherheitsbestimmungen angeht, entwickelt würde. So ein Vorgehen liegt jedoch weder in der Natur des Menschen, noch im Budget eines Flugzeugherstellers. Um so wichtiger ist es jedoch, ein System wirklich richtig zu klassifizieren. Wie schwierig dies ist, zeigt folgendes Flugzeugunglück: Als am 2. September 1998 die Swissair 111 abstürzte, war die Ursache ein Kabelbrand der Stromversorgung des Entertainmentsystems, welches üblicherweise als Level E Hardware eingestuft wird. - Sollten Entertainmentsysteme deshalb als Level A Hardware eingestuft werden? Es gilt zu beachten, dass nicht der Ausfall des Entertainmentsystems zum Absturz führte, sondern der von ihr verursachte Brand, der wiederum andere Systeme in Mitleidenschaft zog. Man stellte fest, dass das verwendete metallisierte Polyethylenterephthalat (kurz MPET), welches als Isolationsmaterial eingesetzt wurde, nicht ausreichend feuerfest war. Am 25. Dezember 2003 hat das Luftfahrt-Bundesamt in Braunschweig als Konsequenz aus der Katastrophe den Austausch aller MPET-beschichteten Isolationen für Flugzeuge in Deutschland angeordnet.

Die DO-254 unterscheidet weiterhin zwischen einfacher und komplexer elektronischer Hardware und definiert dies wie folgt:

- Einfache elektronische Hardware (Simple Electronic Hardware) muss in der Anzahl Ihrer Zustände derart begrenzt sein, dass die Korrekte Funktion der Hardware in jedem Zustand getestet werden kann (wohlgemerkt: mit vertretbarem Aufwand)

- Komplexe elektroinische Hardware (Complex Electronic Hardware) erfüllt genau dieses Kriterium nicht - die Anzahl aller möglichen Zustande ist zu hoch, um die Funktion in jedem Zustand prüfen zu können. Aus diesem Grund sind die meisten FPGA und ASIC Systeme komplex. Ein komplexes Level-A System erfährt daher den maximalen Entwicklungs- und Testaufwand, den die DO-254 fordert.

Planung

Fünf wichtige Planungsunterlagen sind erforderlich, um die Entwicklung der Hardware mit einer Behörde abstimmen zu können. Diese Pläne definieren die Vorgehensweisen während der Design- und Entwicklungsphase, der Validierung und Verifikation gegen die Spezifikation sowie das Konfigurationsmanagement und die Prozess- und Qualitätssicherung. Wie die Informationen zur Verfügung gestellt werden, ob in einem oder mehreren Dokumenten ist nicht wesentlich. Die DO-254 schlägt aber ein Packaging vor:

  • Plan for Hardware Aspects of Certification (PHAC)
  • Hardware Development Plan (HDP)
  • Hardware Verification Plan (HVeP)
  • Hardware Validation Plan (HVaP)
  • Hardware Configuration Plan (HCP)
  • Hardware Process Assuarnce Plan (HPAP)

Die Planung soll folgende Punkte abdecken:

  • Defintion des Hardware Levels
  • Definition aller Entwicklungsprozesse und der Strategien zur ProzesssicherungAuswahl der anzuwendenden Entwiclungsstandards und Richtlinien
  • Festlegen der Hardware Entwicklungsumgebung sowie der Testaufbauten einschließlich der zu verwendenden Tools

Die Behörde erhält in erster Instanz den sog. Plan for Hardware Aspects of Certification (kurz: PHAC), die alle Planungen zusammenfaßt und verdeutlicht. Ein sog. Certification Plan (nicht Teil der DO-254) beschreibt im voraus evtl. die Strategien zur Zertifizierung des gesamten Gerätes.  Ein gut geschriebener und übersichtlicher PHAC erspart viele Nachfragen zu weiteren Planungsdokumenten. Die zertifizierende Behörde ist an der Sicherheit des neuen Geräts interessiert - alles, was nicht oder in sehr geringem Maße dazu beiträgt liegt allein in den Händen des Herstellers und seiner Kunden. Oberstes Gebot: Offenheit und Ehrlichkeit gegenüber dem Behördenvertreter sind die wichtigsten Voraussetzungen für einen erfolgreichen Ablauf des Projekts.

Es ist z.B. nicht wesentlich, wann Sie Ihren Planungsprozess durchführen. Die DO-254 schlägt vor den Prozess zu Beginn durchzuführen, was auch schon vom Begriff her Sinn macht. Es ist aus Sicht der Zertifizierung aber nicht erforderlich, dass dieser Prozess abgeschlossen sein muss, bevor Sie mit der tatsächlichen Arbeit beginnen. Diese Annahme gehört zu einer der weit verbreitendsten Mythen über die DO-254. Beginnen Sie mit der Planung also wann Sie wollen - das Risiko, dass Ihr Unternehmen einen Weg einschlägt, der dann nicht akzeptiert wird erhöht sich durch diese Vorgehensweise natürlich. Je früher Sie Kontakt mit der Behörde aufnehmen und je offener Sie die Kommunikation gestalten, umso leicher können Sie auf Anmerkungen des ehördenvertrters eingehen und den Erfolg Ihres Projekts sichern. Der veeinbarte PHAC ist kein Dogma. Änderungen, die sich im Projektverlauf ergeben können Sie später im Hardware Accomplishment Summary zusammenfassen. Erklären Sie in diesem Fall die Gründe, die zu der Änderung geführt haben und zeigen Sie auf, dass die notwendigen Änderungen die Sicherheit der Etwicklung Ihrer Hardware nicht gefährden.

Entwicklung und Test

Die Erfassen der Anforderungen (Requirements) und die Abbildung dieser Anforderungen auf Systemrequirements auf der einen Seite und dem Hardwaredesign und den Testfällen auf der anderen Seite sind der Schlüssel zur DO-254. Viele Unternehmen verwenden spezielle Tools für diese Aufgabe. Das kann produktiv sein. Bedenken Sie jedoch, dass die Verwenduung von Tools Ihre eigene Entscheidung ist und dieser Schritt entbindet Sie auch nicht von der Pflicht revisionssichere Dokumentationen zu erstellen. Irrtümlicherweise sind einige Unternehmen der Meinung, die Nutzung einer Datenbank entbinde Sie von der Pflicht zur schriftlichen druckbaren und vollständigen Dokumentation. Dem ist nicht so.

Anforderungen, die, sich nicht auf Systemrequirements beziehen oder darauf zurückzuführen sind, müssen als "derived Requirements" ausgewiesen werden. DO-254-Adressen hierarchisch, High-Level-und abgeleitete  Anforderungen. Eine abgeleitete Forderung ist eine zusätzliche  Anforderung aus dem Hardware-Entwicklung abgeleitet  Prozess.

Während der Konzeptphase erarbeiten Sie eine grundlegende Architektur in der Weise, dass alle Anforderungen auf einzelne Architekturelemente abzubilden sind. In der Auswahl geeigneter Darstellungen sind Sie frei. Dieser Entwicklungsschritt soll Sie vor späteren Überraschungen schützen. Nicht selten passiert es, das erst während der Verifikation  herauskommt, dass die entwickelte Hardware ungeeignet ist, bestimmte Anforderungen zu erfüllen oder sie sogar zu großen Teilen mißachtet.

Nach Fertigstellung des detaillierten Designs entsteht der erste Prototyp des  Gerätes. Dieser wird anhand der definierten Anforderungen und der abgeleiteten Testfälle getestet. Echte Testfälle stellen den wichtigsten Nachweis für die korrekte Funktion und Einhaltung aller Umweltanforderungen dar. Prinzipiell ist die Verifikation aber auch mit Hilfe von Simulationen und Analysen möglich. Dabei muß schlüssig erklärt werden, dass die Aussagekraft dem eines echten Tests entspricht. Für eine Simulation bedeutet dies eine Qualifikation der verwendeten Tools entpsrechend DO-178B. Die Analyse sollte nur dann verwendet werden, wenn Sie keine andere Möglichkeit zum Nachweis haben oder der Nachweis ansich trivial in seiner Natur ist.

Abschließend verlangt die DO-254 Nachweise zur Überführung in die Serienproduktion (Product Transition). Der sog. "Product Transition Process" beginnt bereits während der Konzept- und Designphase. Dieser schafft die Grundlage, um die Hardware bei gleichbleibend hoher Qualität und Sicherheit herstellen zu können. Wichtig ist vor allem die Erstellung einer geeigneten möglichst automatisierten Abnahmenprüfung (Acceptance Test). Die Abnahmeprüfung stellt sicher, dass das hergestellte Gerät mit den wichtigsten Anforderungen übereinstimmt. Die Entwicklungsabteilung muß entscheiden, auf welche zentralen Anforderungen das Gerät getestet werden muss.

2Solution GmbH
Rungwisch 9
22523 Hamburg
Germany

 

Telefon
+49 (0) 40 609 418 61

info@2solution.de

 
 
2Solution GmbH © 2024. All Rights reserved.