Deutsche BlogsLuftfahrt

RTCA DO330 – Der Standard für die Toolqualifikation

Luftfahrt

Mit der Weiterentwicklung des RTCA DO178B zum RTCA DO178C sind auch vier sogenannte Supplementes entstanden. Der RTCA DO330 ist eines dieser vier Supplements und er beschreibt die Anforderungen an die Toolqualifikation in der Luftfahrt. Dieser Standard nimmt eine gewisse Sonderrolle ein im Vergleich zu den gleichzeitig entstandenen RTCA DO331, DO332 und DO333. Das Thema Toolqualifikation, wurde, im Gegensatz zur Modell-basierten, Objekt-orientierten Entwicklung oder den Formalen Methoden, auch schon im RTCA DO178B behandelt. Der nachfolgende Beitrag gibt Antworten auf folgende Fragen:

  • Was ist die Idee bei der Toolqualifikation?
  • Wie ist der RTCA DO330 strukturiert?
  • Was sind die 3 wichtigsten Aspekte des Standards?

Was ist die Idee bei der Toolqualifikation?

Das 4-Augen Prinzip ist ein wesentlicher Aspekt der sicherheitsrelevanten Entwicklung gemäß RTCA DO178C, um eine Minimierung der systematischen Fehler zu erreichen. Wenn Softwaretools eingesetzt werden und diese eine Verifikationstätigkeit übernehmen, dann sind sie integraler Bestandteil des 4-Augen Prinzips. Ein Beispiel dafür ist die automatisierte Überprüfung der Codier Richtlinien. Wenn das Tool hier einen Verstoß gegen die Regeln nicht erkennt, dann wird dieser Fehler auch nicht mehr aufgedeckt werden. Tools können also Fehler in einem System nicht erkennen.

Noch schwerwiegender sind Fehler einzustufen, die durch den Einsatz von Tools in das System eingebracht werden können. Ein Source Codegenerator kann so ein Beispiel sein. Wenn der Codegenerator fehlerhaft ist, und der generierte Source Code nicht mehr weiter überprüft wird, dann erzeugt der fehlerhaft Codegenerator Fehler im ausführbaren Code.

Der Grundgedanke der Toolqualifikation ist, dass man nicht „einfach“ davon ausgehen kann, dass ein Softwaretool ohne weiteres korrekt funktioniert. Eine Toolqualifikation ist gemäß dem RTCA DO178C immer dann erforderlich ist, wenn ein im Standard definierter Prozess durch ein Softwaretool ersetzt wird.

Der RTCA DO330 enthält Vorgaben für Softwaretools in der Luftfahrt. Der Standard erhebt aber auch den Anspruch in anderen Industriebereichen eingesetzt werden zu können.

Wie ist der RTCA DO330 strukturiert?

Der RTCA DO330 ordnet das Thema Toolqualifikation in Allgemeiner Form wie folgt ein:

Softwaretools unterscheiden sich von der Embedded Software, für die diese Softwaretools verwendet werden, und bilden eine eigenständige Domäne, daher sind Softwaretool-spezifische Vorgaben sowohl für Tool-Entwickler als auch für Tool-Anwender erforderlich. Weiter wird ausgeführt, dass Softwaretools oft von anderen Teams entwickelt werden als denjenigen, welche die Softwaretools verwenden. Diese Softwaretools-Entwicklungsteams haben häufig keinen Hintergrund in der Entwicklung sicherheitsrelevanter Software gemäß RTCA DO178C oder vergleichbaren Standards.

Der RTCA DO330 definiert folgenden Lebenszyklus für ein Tool:

DO330 Tool QualificationDie Gliederung des DO330 orientiert sich anhand dieses Lebenszykluses.

DO330 Tool Qualification

Wichtiger Aspekt 1: Einstufung des zu qualifizierenden Tools

Am Beginn einer jeden DO330 Toolqualifikation, steht die Einstufung des zu qualifizierenden Tools. Diese Einstufung erfolgt gemäß folgender Matrix:

DO330 Tool QualificationUm den Tool Qualification Level bestimmen zu können, benötigt man den Design Assurance Level (DAL) der Software für deren Entwicklung das zu qualifizierende Softwaretool eingesetzt werden soll. In der Tabelle ist dies der Software Level A-E.

Desweiteren muss man das Criteria 1-3 anhand folgender Definition bestimmen:

Criteria 1: Ein Softwaretool, dessen Ausgabe Teil der Flugsoftware ist und daher einen Fehler einfügen könnte.

Criteria 2: Ein Softwaretool, das Verifikationsprozesse automatisiert und daher einen Fehler nicht erkennen könnte und dessen Ausgabe dient zur Rechtfertigung der Eliminierung oder Reduzierung von

  1. andere als die durch das Werkzeug automatisierten Verifizierungsprozesse.
  2. Entwicklungsprozesse, die einen Einfluss auf die flugzeuggestützte Software haben könnten.

Criteria 3: Ein Softwaretool, das im Rahmen seiner beabsichtigten Verwendung einen Fehler nicht entdecken könnte.

Als Ergebnis erhält man dann den Tool Qualification Level (1-5). Anhand des TQL lassen sich dann alle Maßnahmen bestimmen, die im Rahmen der Toolqualifikation durchgeführt werden müssen.

Wichtiger Aspekt 2: Bedeutung des Tool Qualification Level 5 (TQL-5)

Wenn man die Gesamtmenge aller Softwaretools betrachtet, für welche die Anwendung des RTCA DO330 in Frage kommen, dann stellt man fest, dass die überwältigende Mehrheit dieser Tools Criteria 3 erfüllen. Es handelt sich dabei vor allem um Verifikationstools für das dynamische und statische Testen. Gemäß der obigen Matrix müssen für all diese Tools die Verfahren und Maßnahmen gemäß TQL-5 in der DO330 Toolqualifikation umgesetzt werden. Dies sind im Wesentlichen folgende Maßnahmen:

Folgende Planungsdokumente werden benötigt:

  • Ergänze im PSAC (Plan for Software Aspects of Certification) die zu qualifizierenden Softwarettools
  • Definiere die Tool Qualifikationsstrategie im Tool Qualification Plan (TQP)
  • Tool-spezifische informationen im in Software Life Cycle Environment Configuration Index (SECI)

Folgende Spezifikationsdokumente werden benötigt:

  • Tool Operational Requirementsdokument/-Daten

Folgende Testdaten werden benötigt:

  • Testspezifikation inklusive der Traceability zu den Tool Operational Requirements
  • Testprozeduren
  • Testergebnisse für jede zu verifizierende Softwaretoolversion
  • Review der Tool Operational Requirements bezüglich deren Vollständigkeit und Korrektheit

Da keine Architektur- und Designdokumente für TQL-5 erstellt werden müssen und auch nur wenige Planungsaspekte dokumentiert werden, können kommerzielle Toolhersteller diese Forderungen recht gut erfüllen. In der Praxis erhält man von den kommerziellen Herstellern meist kostenpflichte sogenannte Toolqualifikationspakte, welche die obigen Dokumente inklusiver automatisch durchführbarer Testfälle enthält. Diese Testfälle muss man dann in genau der Umgebung ausführen, in der das zu qualifizierende Softwaretool auch eingesetzt wird. Da die Tests automatisiert sind, ist dies aber meist mit wenig Aufwand machbar. Wenn alle Tests erfolgreich durchgeführt werden können, ist die Toolqualifikation bestanden. Falls Fehler auftreten, müssen diese bewertet werden und geeignete Maßnahmen für das weitere Vorgehen abgeleitet werden.

Wichtiger Aspekt 2: Bedeutung der Tool Qualification Level 1-4 (TQL-1, TQL-2, TQL-3, TQL-4)

Wenn Softwaretools das Criteria 1 erfüllen, d.h. es kann ein Fehler in die Flugsoftware eingebracht werden, dann hängt er TQL gemäß der Entscheidungsmatrix vom DAL Level der Flugsoftware ab. Ein Softwaretool für die Entwicklung einer DAL A Flugsoftware eingesetzt wird, muss dann gemäß den Verfahren und Maßnahmen von TQL-1 qualifiziert werden. Eine DAL B Flugsoftware bedeutet TQL-2 für das Softwaretool, DAL-C entspricht TQL-3 und DAL-D entspricht TQL-4.

Die Anzahl der Softwaretools, welche in der Praxis diese Voraussetzungen erfüllen ist klein. Es wurden bisher nur wenige kommerzielle Tools gemäß diesen Vorgaben qualifiziert. Ein Beispiel stellt die Scade Toolsuite dar. Ein Grund, dafür liegt sicher auch darin, dass der Aufwand einer solchen DO330 Toolqualifikation sicher um einen Faktor 3-10 größer ist, als eine Qualifikation nach TQL-5. Eine Analyse der Verfahren und Maßnahmen für TQL-1 zeigt, dass diese nahezu identisch sind, zu den Maßnahmen, die für eine DAL A Flugsoftware Entwicklung ergriffen werden müssen. Die Maßnahmen für TQL-2 bis TQL-4 entsprechen dementsprechend DAL B bis DAL D.

Criteria 2 ist für Softwaretools anzuwenden, welche zwar „nur“ einen Fehler nicht finden können, dessen Ergebnis aber im weiteren Verlauf der Entwicklung dafür verwendet werden, dass weitere Verifikationsschritte weggelassen werden. Die Toolqualifikation für solche Softwaretools entspricht in etwa dem Aufwand einer DAL D Flugsoftware, wenn diese Softwaretools für eine DAL A oder DAL B Flugsoftware Entwicklung eingesetzt werden.

Fazit

Der RTCA DO 330 beschreibt sehr ausführlich und detailliert die Maßnahmen, welche für eine Softwaretoolqualifikation aufgewendet werden müssen. Viele Missverständnisse welche durch die recht knappe Beschreibung im DO 178B in der Praxis enthalten waren, konnten dadurch aus dem Weg geräumt werden.

Im Vergleich zur ISO26262 der Funktionalen Sicherheitsnorm der Automobilindustrie zeigt, dass in der Luftfahrt (DO330) nur zwei Verfahren akzeptiert werden. Dies ist die Validierung des Softwaretools (entspricht DO330 TQL-5) und die Entwicklung eines Softwaretools gemäß eine Funktionalen Sicherheitsstandards (entspricht DO330 TQL-1 bis TQL-4). Die ISO26262 Toolqualifikationsmaßnahmen: Betriebsbewährtheit des Softwaretools und die Evaluierung des Softwaretool Entwicklungsprozesses werden in der Luftfahrt nicht akzeptiert.

In den Funktionalen Sicherheitsnormen für die Bahnindustrie EN50128 und EN50657 werden für die Softwaretoolqualifikation die Toolklassen T1, T2 und T3 definiert. T2 ist dabei zumindest vergleichbar mit dem DO330 TQL-5. Die Toolklasse T3 wird für Tools angewendet welche Fehler in ein System einbringen können, allerdings sind die Maßnahmen in keiner Weise mit denen der DO330 (TQL-1 bis TQL-4) vergleichbar. Vielmehr sind die anzuwendenden Maßnahmen auch für T3 denen des DO330 TQL-5 sehr ähnlich. Die EN50128 und EN50657 lassen damit in der Praxis viel Raum für Interpretation der anzuwendenden Maßnahmen insbesondere für Softwaretools welche Fehler in ein System einbringen können.

Weitere HEICON Blog Beiträge zum Thema

Wenn Sie weitere Fragen zum Thema haben, dann unterstützt Sie HEICON gerne. Senden Sie eine Mail an: info[at]heicon-ulm.de.