DO-178 Software Considerations in Airborne Systems and Equipment Certification

Veröffentlicht auf 16. Oktober 2018

Die DO-178 "Software Considerations in Airborne Systems and Equipment Certification" spielt in der Softwareentwicklung für die Luftfahrt eine wichtige Rolle. Herausgeber der Richtlinie ist die RTCA (Radio Technical Commission for Aeronautics).

Diese Richtlinie wird von den jeweiligen Zulassungsbehörden FAA (Federal Aviation Administration) oder EASA (European Aviation Safety Agency) als Standard anerkannt und zur Feststellung der "airworthiness" herangezogen. Eine Zertifizierung der Software ist nicht vorgesehen, da die Behörden dies nur für das komplette Flugzeug kennen. In Europa wird der Standard auch als ED-12 bezeichnet.


Sie beschäftigt sich hauptsächlich mit dem SW-Entwicklungsprozess und definiert Prozesse und zugehörige Dokumente (Auszug):

* Planung:

  • Plan for Software Aspects of Certification (PSAC)
  • Software Development Plan (SDP)
  • Software Verification Plan (SVP)
  • Software Configuration Management Plan (SCMP)
  • Software Quality Assurance Plan (SQAP)


* Entwicklung:

  • Software Requirements Standards (SRS)
  • Software Requirements Data (SRD) (Spezifikation)
  • Software Code/Design Standard (SCS/SDS)
  • Software Design Description (SDD)
  • Software (Lifecycle) Configuration Index (SCI)
  • Tool Qualification


* Verifikation

  • Software Verification Cases and Procedures (SVCP)
  • Software Verification Results (SVR)
  • Software Quality Assurance Records (SQAR) (Fehler, Reviews, Aufzeichnungen)
  • Software Accomplishment Summary (SAS)

Wichtig ist hierbei die komplette Traceability und eine Impact Analyse. Anforderungen müssen "vertrauenswürdig" sein. Wird eine Anforderung spät im Prozess geändert, müssen alle Prozesse erneut durchlaufen werden.

Entsprechend anderer Standards für Funktionale Sicherheit (z.B. IEC 61508) werden auch hier Safety Levels (Design Assurance Levels, kurz DAL) definiert.
Diese werden aus der DO-254 übernommen, die eigentlich für Hardware gilt.
* Level A
Fehlerauswirkung: Katastrophal
Fehlerrate: 10hoch-9 pro h
Codeabdeckung: Modified Decision Condition Coverage (MCDC)
Sicherer Weiterflug oder Landung nicht wahrscheinlich, viele ernsthafte Beschädigungen Material oder Personen.
* Level B
Fehlerauswirkung: Gefährlich
Fehlerrate: 10hoch-7 pro h
Codeabdeckung: Decision Condition Coverage
Wenige, relativ wahrscheinliche, ernsthafte Beschädigungen von Material und Personen.
* Level C
Fehlerauswirkung: Schwer
Fehlerrate: 10hoch-5 pro h
Codeabdeckung: Statement Coverage
Beeinträchtigung der Einsatzeffizienz. Mögliche Personenschäden.
* Level D
Fehlerauswirkung: Gering
Fehlerrate: 10hoch-3 pro h
Eingeschränkter Sicherheitsbereich, aber durch Einsatzpersonal handhabbar.
* Level E
Fehlerauswirkung: Keine
Keine Auswirkung auf die Sicherheit.


Die genauen Anforderungen der Safety Levels an die Entwicklung und die erforderlichen Dokumente sind in ANNEX A definiert. Schwerpunkt ist die SW-Verifikation, bei der neben der Funktionsprüfung auch unbeabsichtigtes oder Fehlverhalten ausgeschlossen werden muss. Festgelegt werden die Levels in einem System Safety Assessment (SSA), wobei genau begründet werden muss, warum ein bestimmtes Level für die Software gültig sein soll.

Links:
https://en.wikipedia.org/wiki/DO-178B
https://en.wikipedia.org/wiki/DO-178C
https://my.rtca.org/nc__store

 

Geschrieben von Robert Bullinger

Veröffentlicht in #Methoden und Standards, #Expertise, #Softwarequalität

Repost0
Um über die neuesten Artikel informiert zu werden, abonnieren:
Kommentiere diesen Post