Die DO-178B - Software Considerations in Airborne Systems and Equipment Certification - ist ein Standard zur Softwareentwicklung im sicherheitskritischen Bereich der Luftfahrt. Er wurde von der RTCA entwickelt. Die EUROCAE hat diesen Standard komplett übernommen, so dass er in Europa offiziell den Namen ED-12B trägt. Die Luftfahrtbehörden FAA und EASA fordern für den Software-Entwicklungsprozess die Einhaltung des Standards. Der Nachweis erfolgt anhand der Dokumentierung und ist Voraussetzung für eine Qualifizierung von Software für den Einsatz in der Luftfahrt. Dieser Artikel soll als kurzer Überblick und Einführung in DO-178B der RTCA dienen und erläutert die Maßnahmen, Techniken und Prozesse im Avionik Standard DO-178B, welche die Sicherheit und Zuverlässigkeit gewährleisten.
Die DO-178B definiert insbesondere Prozesse und Artefakte, um einen Nachweis der Entwicklungen belastbar einzufordern. Nicht jede Software ist gleichermaßen kritisch einzuordnen. Der Ausfall eines Autopiloten kann größere Auswirkungen haben als der Ausfall der Kabinenbeleuchtung. Und darum geht es im Wesentlichen: Um die Wahrscheinlichkeit eines Ausfalls und seiner Auswirkungen. Es werden 5 Sicherheitslevel definiert, die es anhand dieser Wahrscheinlichkeiten zu hinterfragen gilt, wenn es um die Festlegung eines solchen Levels für ein bestimmtes System an Bord eines Flugzeugs geht. Je größer die Auswirkungen sein können, um so höher ist der Aufwand, den diese Norm vom gesamten Entwicklungsprozess fordert.
Der besondere Schwerpunkt liegt auf der Einführung von Test-Strategien. Außerdem werden verschiedene Techniken diskutiert, welche die Zuverlässigkeit eines Avioniksystems erhöhen.

Hintergrund

In den späten 1970er und frühen 1980er Jahren verringerten sich die Kosten für EDV-Systeme. Zur gleichen Zeit begann sich die Leistung der Systeme drastisch zu erhöhen. Avionikhersteller begannen verstärkt, die bestehende Ausrüstung damaliger Flugzeuge mit Software-Funktionalitäten zu erweitern. Der verstärkte Einsatz von Software und Computer-Systemen für sicherheitskritische Anwendungen war der Grund für die Entwicklung des DO-178 Standards in den Vereinigten Staaten im Jahr 1980. Der Standard wurde weiter modifiziert und schließlich im Jahr 1985 als DO-178A veröffentlicht. 7 Jahre später folgte DO-178B im Jahre 1992. Seitdem gab es einige kleine Korrekturen, aber zum größten Teil baut dieser Standard noch immer auf den Software-Entwicklungs-Praktiken und Paradigmen der frühen 1990er Jahre auf.

Software Level

Software Level werden eingesetzt, um den Schweregrad des Ausfalls einer Softwarekomponente zu bewerten. Der entsprechende Software Level wird durch das System Safety Assessment bestimmt. Der Level eines Software-Systems muss früh in der Entwicklung festgelegt werden da er vor allem erhebliche Auswirkungen auf die Architektur der Software hat. Folgende Entscheidungen können davon betroffen sein:

  • Die Programmiersprache
  • Coding Styles und zulässige Paradigmen
  • Die Möglichkeit der Abbildung auf Anforderungen (Requirements Traceability)
  • Testbarkeit einzelner Units
  • Verwendung von Threads und Prozessen

Der Ausfall einer Level A Software führt zu einem sog. katastrophalen Zustand und verhindert den sicheren Weiterflug und/oder die Landung. Software dieser Art muss und wird 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 Software).

Der Ausfall einer Level B Software 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. (Beispiel: Primary Flight Displays (PFD)).

Der Ausfall einer Level C Software 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. (Beispiele: Autopilot und automatische Landesysteme).

Der Ausfall einer Level D Software 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. (Beispiele: Transponder- und Kommunikationstechnik).

Der Ausfall einer Level E Software hat keine nachteiligen Auswirkungen auf die Sicherheit des Fluges oder die Flugzeuginsassen. Da Avionik Hersteller oft nur Safety Anforderungen denken, wird vor diesem Hintergrund oft vergessen, dass ein ausreichender Test der Software dennoch sinnvoll und einzufordern ist. Um diesem Denken entgegenzuwirken definierte Airbus für alle Level E Systeme den Level E+, welcher letztlich einem abgespeckten Level D Anforderungskatalog entspricht. (Beispiele: Entertainment-Funktionen, Satelliten-Telefon und Internetzugang).

Prozesse

Der Software-Entwicklungsprozess in der DO-178B besteht aus drei Hauptprozessen:

  • Planung
  • Entwicklung
  • Test

Der Planungsprozess definiert das Vorgehen während des gesamten Entwicklungsprojekts bis zum Abschluss der Zertifizierung. Das Hauptdokument, welches in der Planungsphase entsteht, ist der Plan for Software Aspects of Certification (PHAC). Er referenziert i.d.R. alle anderen Planungsdokumente und soll den gesamten Entwicklungsprozess in Kurzform wiedergeben. Wichtig sind dabei alle sicherheitskritischen Elemente sowie der Ablauf des Entwicklungsprozesses insgesamt. Außerdem werden mit der Behörde Abnahmekriterien und Termine vereinbart. Daher ist es besonders sinnvoll, den PHAC, sowie alle anderen Planungsdokumente so früh wie möglich bereitzustellen und mit der Behörde abzustimmen. Behörden wie die EASA legen großen Wert auf eine gute und offene Kommunikation und Kooperation mit der Industrie. Für jeden Avionikhersteller lohnt sich daher ein offener Dialog so früh wie möglich, um spätere Missverständnisse von vornherein aus dem Weg zu räumen.

Die DO-178B überlässt es grundsätzlich dem Anwender, welches Lebenszyklus-Modell er einsetzt. Entgegen der weit verbreiteten Meinung wird nicht zwingend ein strenges V-Modell gefordert, welches überwiegend zum Einsatz kommt. Agile Softwareentwicklungsmethoden sind dagegen höchst selten oder werden gar nicht eingesetzt. Das hat zur Folge, dass Softwareentwicklung in der Luftfahrt meist sehr träge ist und Änderungen nur langsam zum Tragen kommen. Nicht selten habe ich erlebt, dass Fehler lieber dokumentiert werden, anstatt sie zu beheben, da der damit verbundene Aufwand, den ein V-Modell mit sich bringt gefürchtet wird.

Grundsätzlich fordert die DO-178B eine anforderungsbasierte Entwicklung (Requirements Engineering). Diese werden auf zwei Ebenen abverlangt: Top Level und Low Level Requirements. Top Level Requirements beschreiben die Software an Ihren äußeren Schnittstellen und definieren grundsätzliche Anforderungen, welche das komplette Design betreffen. Low Level Requirements definieren die Software in einzelnen Komponenten. In der Praxis werden hierzu oft Methoden verwendet. Dabei wird oft vergessen, dass eine einzelne Methode oft nie einen kompletten logischen Zusammenhang definiert. Sinnvoller wäre es daher, Low Level Requirements auf der Ebene von Funktionsgruppen zu definieren (Beispielhaft sei hier die Definition einer Stack-Datenstruktur genannt, welche sich aus den Methoden PUSH, POP, TOP, usw. zusammensetzt. Nur in Kombination dieser Methoden ergibt sich auch eine in sich logische und konsistente Darstellung).

Der Software Verifikations-Prozess (Test) ist von größtem Interesse innerhalb der DO-178B. Sie definiert ihn als Kombination von Bewertungen, Analysen und Tests. Die erforderlichen Tests, Prüfungen und Nachweise hängen vom definierten Software Level ab. Sinn und Zweck ist es, Fehler in der Software zu erkennen. Ein Fehler ist ein Verhalten der Software, welches von den Anforderungen (Requirements) abweicht. Erkannte Fehler sollen entfernt werden und betroffene Entwicklungsschritte (Design, Programmierung, Test, etc.) müssen ggf. aktualisiert werden.

Software Reviews und Analysen

Bewertungen der Software-Entwicklungsdokumentation sorgen für eine qualitative Bewertung ihrer Richtigkeit. Analysen bieten die Möglichkeit einer quantitativen Bewertung. Solche Analysen werden oft unter Verwendung von definierten Checklisten durchgeführt. Die Checklisten bieten die Grundlage ganz bestimmte Aspekte der Funktionalität im Detail zu untersuchen und sicherzustellen, dass die Anforderungen an die Analyse überprüft wurden.

High-Level-Requirements und Low-Level-Requirements (Anforderungen) werden untersucht, um festzustellen, ob Fehler oder Unstimmigkeiten in den Anforderungskatalog eingeflossen sind. Jedes Requirement wird überprüft, um sicherzustellen, dass es klar und eindeutig die Anforderungen an das Gesamtsystem erfüllt. Um dies sicherzustellen, muss jedes Requirement eindeutig auf Anforderungen des Gesamtsystems zurückzuverfolgen sein (Traceability). Ein Requirement muss außerdem testbar sein und die Darstellung muss einheitlichen, frei definierbaren Standards genügen. Die verwendeten Algorithmen werden auf Genauigkeit und deterministisches Verhalten überprüft.

Die Software-Architektur wird überprüft und analysiert, um Fehler und Widersprüche aufzudecken. Konflikte mit High-Level-Requirements müssen identifiziert und aufgelöst werden. Alle Architektur-Komponenten müssen auf Konsistenz und Kompatibilität mit der Hardware/Embedded Computer überprüft werden.

Der Source Code wird überprüft und analysiert um Fehler aufzudecken und die Konformität zu den Software Code-Standards zu gewährleisten. Je nach festgelegtem Coding Standard wird der Sprachumfang der verwendeten Programmiersprache beschränkt um Laufzeitfehler von vornherein auszuschließen. Der Code muss mit der Hardware/Embedded Computer kompatibel sein und alle Low-Level-Requirements abdecken. Datenfluss und die Ablaufsteuerung soll der Software-Architektur entsprechen. Der Code soll leicht verständlich sein und darf eine bestimmte Komplexität nicht übersteigen.

Software Testing

Die Software wird getestet, um sicherzustellen, dass sie den Anforderungen entspricht und um alle möglichen Ursachen, die zu einem nicht definierten Fehlerzustand oder Absturz führen können zu eliminieren.

Testfälle im Normalbereich (Normal Range Test Cases) sollten zu jedem Low-Level-Requirement entwickelt werden um gültige Eingabesequenzen und Grenzwerte zu testen. Die Testfälle sollen dabei möglichst alle Zustandsübergänge während des normalen Betriebs abdecken. Darüber hinaus sieht die DO-178B Testfälle für ungültige Eingabesequenzen vor (Robustness Test Cases). Wichtig in diesem Zusammenhang ist die Reaktion von arithmetischen Funktionen für ungültige Eingabewerte und die Überprüfung auf Überlaufbedingungen.

Die Test-Coverage-Analyse soll durchgeführt werden, um sicherzustellen, dass es mindestens einen Testfall für jede Anforderung an die Software gibt und dass sowohl im Normalbereich als auch außerhalb des normalen Eingabebereichs Testfälle definiert wurden.

Die Structural-Coverage-Analyse stellt sicher, dass jede Code-Sequenz mindestens einmal bei der Durchführung der Tests durchlaufen wurde. Gelingt dies nicht, so müssen die verbliebenen Code-Sequenzen analysiert und ggf. entfernt werden. Es besteht auch die Möglichkeit, nicht durchlaufene Code-Sequenzen gewollt zu deaktivieren. Geschieht dies nicht, so spricht man von sog. dead Code. Dieser wird im normalen Zustand des Systems zwar nicht angesteuert, in einem ungewollten Fehlerzustand befürchtet man hier jedoch ein ungewolltes und unvorhersagbares Verhalten des Systems.

Weitere Techniken

Die DO-178B gibt zusätzliche Empfehlungen für die Architektur von sicherheitskritischen Systemen, um die Zuverlässigkeit des Systems zu erhöhen. Drei von ihnen werden im Folgenden kurz beschrieben. Im jeweiligen Projekt muss bewertet werden, ob und welche Architekturen dazu geeignet sind die Sicherheit und Zuverlässigkeit zu erhöhen.

Partitioning

Partitioning trennt funktional unabhängige Komponente des Systems, so dass bei einem Ausfall einer dieser Komponenten die anderen ungehindert weiterlaufen können. Eine geringe Kopplung zwischen den Komponenten und auch den Daten von den verwendeten Komponenten ist der Schlüssel für ein erfolgreiches Partitioning.

Partitioning kann eine reine Softwarelösung, eine Hardwarelösung oder eine Kombination von Hardware- und Softwarepartitioning sein. Wenn zusätzliche Software erforderlich ist, um Partitioning zu ermöglichen, muss sie ordnungsgemäß dokumentiert werden; entsprechend dem höchsten Software Level der zu partitionierenden Komponenten.

Multiple-Version Dissimilar Software

Diese Technik wird häufig als N-Version Programmierung bezeichnet. Die zentrale Idee ist die Bereitstellung redundanter Komponenten, die die gleiche Funktionalität bieten, aber in verschiedener Art und Weise umgesetzt wurden.

Diese Strategie ermöglicht redundante Funktionalität indem die Implementierung der einen Komponente keinen Einfluss auf die Implementierung auf ihre Schwesterkomponente hat. Sind jedoch die Eingabedaten beschädigt, dann kann auch die N-Version Programmierung das System nicht schützen.

Ein weiteres Problem besteht in der Lösung von Konflikten, wenn eine Schwesterkomponente ausfällt oder andere Werte zurückliefert. Das System stellt im ersten Schritt nur fest, dass es einen Fehler gibt. Es ist jedoch nicht klar, welche Komponente fehlerfrei gearbeitet hat.

Deshalb kommen wir nun auf die dritte Technik zu sprechen: das Safety Monitoring.

Safety Monitoring

Safety Monitoring bedeutet das Verhalten einer Komponente permanent zu überwachen. Im Problemfall soll das Versagen der Komponente frühzeitig erkannt werden bevor es zum Crash kommt – der Rest des Systems bleibt auf diese Art und Weise geschützt.

Dazu muss das Verhalten der Komponente in der Art bewertet werden, ob sie richtige Ergebnisse unter allen Umständen liefern kann. Dies ist zum Beispiel durch definierte Testanfragen möglich. Das Resultat dieser Anfragen ist im voraus bekannt und das System muss die richtigen Werte zurückliefern.

Die Funktionalität kann durch den Einsatz von Software, Hardware oder einer Kombination aus Beiden implementiert werden (Watchdog, Built-In-Test, etc.).

Anwendung

In der Anwendung und im Verständnis der DO-178B gibt es immer wieder Probleme und Einschränkungen, welche die aktuellen Möglichkeiten der Softwareentwicklung nicht berücksichtigen. Diese Probleme sind vor allem auf die 20jährige Historie des Standards zurückzuführen. Die DO-248B, die im Jahr 2000 einige Aktualisierungen und Klarstellungen zur DO-178B mitbrachte, ändert daran nicht viel. Einige Überlegungen in der Software-Entwicklung haben sich erst in den letzten Jahren etabliert.

Die DO-178B stellt keine Anleitung zu Projektmanagement-Techniken bereit. Sie beschreibt die Planung und welche Aktivitäten während des Prozesses durchlaufen werden sollen. Jedoch fehlt es in ausreichendem Maße an Techniken zu Risiko Management, Kosten- und Zeitplan, Ressourcenplanung und Leistungsüberwachung. Darüber hinaus gibt es keine Empfehlungen zu Mitarbeiter Qualifikationen, Kompetenzen, oder Personal Anforderungen.

2Solution GmbH
Rungwisch 9
22523 Hamburg
Germany

 

Telefon
+49 (0) 40 609 418 61

info@2solution.de

 
 
2Solution GmbH © 2024. All Rights reserved.