Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Dann kaufen wir mal ein Tool-Qualification Package ...

Tool-Qualifizierung für Safety-Standards

Autor: Erol Simsek, iSYSTEM AG

Beitrag - Embedded Software Engineering Kongress 2015

 

Standards der Funktionalen Sicherheit verlangen bzw. empfehlen die nähere Vorabbetrachtung der im Softwareentstehungsprozess verwendeten Software-Werkzeuge im Hinblick auf deren "Einsatzrisiko" und damit negativen Auswirkung auf die Safety eines Systems.  Als Software-Toolhersteller in diesem Bereich wird man deshalb zunehmend mit Fragen konfrontiert wie z.B. "Ist Ihr Werkzeug zertifiziert?", "Haben Sie einen 'TÜV-Stempel'?" oder "Können Sie uns bei der Qualifizierung Ihrer Tools unterstützen?" Was heißt das konkret, und wie haben wir, Software-Toolhersteller und Kunden, uns bisher mit diesem Thema auseinandergesetzt?

Warum überhaupt Tool-Qualifizierung?

Seit dem offiziellen Inkrafttreten der ISO2626 (Road vehicles – Functional safety) im Jahr 2011[1] ist im Embedded Markt eine zunehmende Sensibilisierung für das Thema Toolqualifizierung zu verspüren. In anderen Standards der Funktionalen Sicherheit (FuSi) ist Toolqualifizierung schon sehr viel länger präsent. Als übergeordnete Norm klassifiziert die IEC 61508:2010 ("Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme", erstmals 1998 veröffentlicht) Software-Tools in drei Kritikalitäts-Klassen T1-T3. Je nach Einstufung gemäß der Fragestellung "Hat das Software-Tool eine negative Auswirkung auf die Safety des Systems?" werden entsprechende Maßnahmen vorgeschlagen bzw. notwendig, die zur Minimierung des Einsatzrisikos eines Software-Tools beitragen. In der Luftfahrt wird bereits in der letzten Fassung der DO-178 B von 1992 vorgegeben, wie man mit Eigenentwicklungen bzw. zugekauften Software-Tools innerhalb eines Safety-Projekts umgehen soll.

In diesem Zusammenhang wird das Wort Toolqualifizierung als Überbegriff für eine ganze Reihe an Aktivitäten verwendet. Im Grunde ist die nähere Betrachtung von Software-Tools im Entstehungsprozess von Embedded Systemen gemeint, die sich in Klassifizierung und vertrauensbildende Maßnahmen gruppieren lassen. Letztere können auch die Qualifizierung eines Softwaretools zur Folge haben. Dazu später mehr.

Im Jahr 2012, also gut 20 Jahre nach der Einführung der DO-178 B, wurde die DO-178 C [2] verabschiedet. Nach einer so langen Zeit und dem einhergehenden technischen Fortschritt musste die Formulierung des aktuellen Stands von Wissenschaft und Technik in Bezug auf die Entwicklung sicherheitskritischer Software angepasst werden. Neben modellbasierter und objektorientierter Entwicklung sowie formalen Methoden führte die RTCA (Radio Technical Commission for Aeronautics) auch ein umfangreiches Dokument zum Thema "Software Tool Qualification Considerations", die DO-330, ein. Es handelt sich hierbei in erster Linie um ein Prozessmodell, das die Entwicklung von Software-Tools (meist Eigenentwicklungen innerhalb eines Unternehmens) gemäß eines FuSi-Standards beschreibt. Des Weiteren wird systematisch dargestellt, wie mit sogenannten COTS-Tools und Software (Commercial of-the-shelf, also zugekauften Standard-Tools und Software-Komponenten) umzugehen ist. Die RTCA empfiehlt das Dokument als Domänen-unabhängig auch zur Anwendung in anderen Märkten [3][4].

Was ist Tool-Qualifizierung?

Die DO-330 definiert ein Software-Tool wie folgt (aus dem Englischen frei übersetzt):

"… ein Software-Tool ist ein Computerprogramm oder ein funktioneller Teil davon, das zur Entwicklung und Umwandlung, zum Testen, Analysieren sowie Erzeugen eines anderen Programms im Prozess unterstützend verwendet wird bzw. Veränderungen von Daten oder Dokumentation eines Programms bewirkt."

Beispiele für Software-Tools sind z.B. Code Generatoren, Compiler, Test Tools, selbst entwickelte Software, Skripte, Standard Office Produkte usw.

Software-Tools definieren, charakterisieren, automatisieren, harmonisieren, standardisieren, vereinfachen und realisieren heute einen Software-Entwicklungs- und Testprozess. Wenn potentielle Fehler in einem Software-Tool eine negative Auswirkung auf die Safety eines Systems haben und/oder solche Tool-Fehler innerhalb eines Prozesses nicht erkannt bzw. durch alternative Maßnahmen im Prozess kompensiert werden, fordert bzw. empfiehlt der eine oder andere FuSi-Standard die nähere Betrachtung von Software-Tools im Vorfeld einer Safety-Entwicklung.

Im Prinzip wird vom Systemhersteller konkret verlangt, die historisch gewachsenen Software-Toollandschaften genau unter die Lupe zu nehmen, insbesondere in Bezug auf die Anwendungsfälle im Prozess. Zusätzlich soll Vertrauen in den Einsatz bestimmter Software-Tools aufgebaut und letztendlich nachweisbar sein. Damit verbunden ist außerdem die Darstellung der Vermeidung von Fehlinterpretationen bei der Anwendung der Software-Tools durch den Tool-User. Es geht hier insbesondere um den Abgleich von Vorstellungen des Tool-Entwicklers und des eigentlichen Tool-Users. Im Falle von nachweisbaren Misstrauen in ein Softwaretool wird ein Unternehmen weitere Maßnahmen zur Tool Qualifizierung anwenden, um das Misstrauen und damit das Einsatzrisiko des jeweiligen Software-Tools zu minimieren. Die Art der Maßnahme richtet sich nach der Safety-Einstufung des Systems (z.B. SIL1-3 IEC 61508 oder ASIL A-D ISO 26262) und wird in den jeweiligen Standards beschrieben (siehe weiter unten).

Wem gegenüber muss man als Kunde den Nachweis aufzeigen, dass man Software-Tools im Prozess näher betrachtet und ggf. qualifiziert hat?

Eine Frage, die man nicht pauschal beantworten kann. In der Luftfahrt wird ein Systemhersteller begleitet von der FAA (Federal Aviation Administration) oder der EASA (European Aviation Safety Agency). Nachweise im Allgemeinen und auch zur Tool-Qualifizierung sind gegenüber diesen offiziellen Stellen zu erbringen. Andere Märkten sind nicht so strikt in Bezug auf die Tool-Qualifizierung. Der Standard empfiehlt quasi die Vorgehensweise, und erst im Haftungsfall muss man dann entsprechende Nachweise erbringen.

Standards der Funktionalen Sicherheit und Tool-Qualifizierung

Um das Einsatzrisiko von Software-Tools zu bestimmen, wird in der Regel mit der Klassifizierung dieser Tools im Rahmen eines Projekts begonnen. Die verschiedenen Standards der Funktionalen Sicherheit gehen unterschiedlich an dieses Thema heran:

Übergeordnete Norm: IEC 61508 und Bahntechnik: EN50128:2011

  1. Hat das eingesetzte Software-Tool eine Auswirkung auf die Safety eines Systems?
  2. Wenn nein, keine Maßnahmen zur Qualifizierung notwendig. Tool Classification Level T1
  3. Wenn ja, um welche Art von Werkzeug handelt es sich?
    a. Constructive, z.B. Compiler, Code Generator à Level T2
    b. Analysis/Verification, z.B. Statische Codeanalyse , Unit Test Tool à Level T3
  4. Für T2 und T3 müssen immer Maßnahmen beschrieben werden, die einen eventuellen Tool-Fehler im Prozess erkennen bzw. kompensieren. T3 ist dabei die strengste Einstufung-
  5. Für T3 bestehen zusätzliche Möglichkeiten, Vertrauen aufzubauen über
    a. Untersuchung der Betriebsbewährtheit eines Software-Tools
    b. Tool-Validierung

Automotive: ISO26262:2011 Road Vehicles – Functional Safety

  1. Hat das eingesetzte Software-Tool eine Auswirkung auf die Safety eines Systems?
  2. Wenn nein, keine Maßnahmen zur Qualifizierung notwendig. Tool Classification Level TCL1
  3. Wenn ja, dann muss entschieden werden, mit welcher Wahrscheinlichkeit man in der Lage ist, einen eventuellen Tool-Fehler im Prozess zu erkennen bzw. zu kompensieren.
  4. Hierfür gibt es drei Stufen
    a. High
    b. Mid
    c. Low
  5. Bei High fällt das Tool in TCL1
  6. Bei Mid in TCL2 und bei Low in TCL3
  7. In den beiden letzteren Fällen beschreibt der Standard vier mögliche Methoden der Qualifizierung:
    a. Untersuchung der Betriebsbewährtheit eines Software-Tools
    b. Prozess-Audit/Assessment beim Tool-Hersteller
    c. Tool-Validierung
    d.Prüfung bzw. Nachweis, dass ein Werkzeug gemäß eines Safety-Standards entwickelt wurde

Luftfahrt: DO-178C:2012 Software Considerations in Airborne Systems and Equipment Certification, DO-278A Software Integrity Assurance Considerations for Communication, Navigation, Surveillance and Air Traffic Management (CNS/ATM) Systems

  1. Um welche Art von Werkzeug handelt es sich?
    a. Constructive (Tool-Kategorie 1, TK1)
    b. Analysis (TK2)
    c. Verification (TK3)
  2. Tool-Kategorie 1 ist die strengste Einstufung. Je nach Kategorie ergeben sich die jeweiligen "Tool Qualficiation Level" 1-5:
    a. TK1: TQL1-2
    b. TK2: TQL3-4
    c. TK3: TQL5
  3. Die DO-330 beschreibt dann in Form von Tabellen die für das jeweilige TQL notwendigen Maßnahmen.
  4. Die Anforderung für das niedrigste Level sind bereits
    a. Tool Operational Requirements (TOR) und
    b. Tool-Validierung gemäß dieser Einsatzszenarien
    c. wowie die Beschreibung von Maßnahmen, die einen eventuellen Tool-Fehler im Prozess erkennen bzw. kompensieren
  5. Für alle höheren Level gelten die Maßnahmen von TQL 5 und weitere Maßnahmen, die im Prinzip dann schon die Entwicklung und den Test eines Software-Tools gemäß der DO-330 entsprechen.

Medizintechnik: EN ISO 13485 (Qualitätsmanagement), EN ISO 14971 (Risikomanagement), EN 62304 (Lebenszyklus medizinischer Software)

  1. Die Standards der Medizintechnik erwähnen Tool-Qualifizierung nicht explizit wie andere Standards
  2. Grundsätzlich wird die Auswahl der einzusetzenden Software-Tools im Rahmen der Festlegung des Softwareentwicklungsplans gefordert.
  3. Dabei findet man im Standard Hinweise wie: "Jedes verwendete Werkzeug sollte erprobt sein und gut überlegt eingesetzt werden. Der Softwareentwicklungsplan sollte die Werkzeuge und deren Versionen dokumentieren", aus [5], Seite 112.

Tool-Qualification-Package

Ein Tool-Qualification-Package ist im Grunde also ein Tool-Validation-Package. Es besteht je nach Software-Tool aus Dokumentationen/Anleitungen zur Klassifizierung eines Tools, Einsatzszenarien des Tools im Prozess (Tool Operational Requirements, Use Cases) und einer Testausführungsumgebung und Testfällen zur Validierung des Software-Tools. Letzteres ist eine Art Referenzumgebung mit entsprechendem Reportgenerator zur Dokumentation des Validierungsprozesses. Die eigentliche Validierung eines Software-Tools findet dann beim Kunden, vom Kunden und in dessen Entwicklungsumgebung statt. Ein Tool-Qualification-Package kann deshalb immer mit Consulting zur individuellen Anpassung beim Kunden eingekauft werden.

Erwartungshaltung von Kunden und Software-Tool-Lieferanten?

Dem Gedanken, ein Tool-Qualification-Package zu kaufen, sind ein Großteil der Vorabbetrachtungsschritte zum Einsatzrisiko von Software-Tools bereits vorausgegangen. Die Entscheidung für ein Tool-Qualification-Package geht einher mit der Entscheidung, ein Software-Tool zu validieren. Der Kunde erhofft sich einen Automatismus einzukaufen, der ihm den "letzten" Schritt in der Gesamtbetrachtung der Software-Toolkette so zeit- und kosteneffizient wie möglich gestaltet. Die Erwartungshaltung, dass mit dem Kauf die Validierung quasi abgeschlossen ist, ist natürlich falsch. Mit dem Kauf beginnt die eigentliche Arbeit. Deshalb versucht man den sehr aufwändigen Prozess der Tool-Validierung wenn möglich durch intensive Klassifizierung der Software-Tools zu vermeiden. Die Luftfahrt lässt durch eine vorgegebene Kategorisierung nicht viel Spielraum zur Interpretation, wohingegen andere Standards den Systemhersteller sofort in eine Diskussion über mögliche Risiken, die ein Software-Tool darstellt, Tool-Fehler-Eintrittswahrscheinlichkeiten usw., führen. Diese Diskussionen und die damit verbundenen Entscheidungen sind sehr individuell und können durchaus von Firma zu Firma und von Projekt zu Projekt unterschiedlich ausfallen. Dokumentieren lässt sich dieser Prozess am besten durch Formalisierung des Klassifizierungsvorgangs mittels Toolunterstützung, wie in [6][7] beschrieben.

Der Aufwand für den Software-Toolhersteller, ein Tool-Qualification-Package zur Verfügung zu stellen, ist durchaus hoch und kann auch variantenreich ausfallen. Entsprechende Serviceleistungen zur Inbetriebnahme bzw. Schulung müssen mit angeboten werden. Der Kunde soll letztendlich selbstständig eine Validierung durchführen, so wie vom Standard vorgeschrieben. Ein Tool-Qualification Package wird dadurch zum Produkt mit Consulting-Dienstleistungen, das sich dann auch entsprechend verkaufen soll.

Wie hat der Markt dieses Thema bisher umgesetzt?

Heute stellen fast alle Hersteller von Software-Tools ein Tool-Qualification-Package zur Verfügung. Alleine die Eingabe der beiden Wörter in eine Suchmaschine führt zu einer ganzen Reihe unterschiedlichster Angebote für diesen Zweck. Des Weiteren finden sich etliche Zertifikate, die den möglichen Einsatz eines Software-Tools in einem Safety-Projekt für machbar einschätzen. Vertrauensbildend sind all diese Dinge, die Arbeit der Klassifizierung und eventuellen Qualifizierung/Validierung bleibt dem Kunden aber dadurch nicht erspart.

Status Quo und Lessons Learned

Von der Luftfahrt kann man wieder einmal und insbesondere zum Thema Tool-Qualifizierung viel lernen. Mit der DO-330 wird die Luftfahrt ihrer Prozess-, Technologie- und Methoden-Vorreiterrolle gerecht. Bleibt abzuwarten, ob sich andere Märkte an dem sehr gut ausformulierten Dokument orientieren werden. Nach anfänglicher Hysterie ist nun auch in der Automobilindustrie bzgl. dem Thema Tool-Qualifizierung Ruhe eingekehrt. Man scheint eine angemessene Antwort auf das Einsatzrisiko von Software-Tools im Entstehungsprozess eines Safety-Systems gefunden zu haben. Jedenfalls wird die Vorabbetrachtung nicht mehr als lästig, sondern eher als förderlich auch für die Effizienz von Prozessen bewertet. Andere Industrien betrachten Software-Tools getrennt voneinander und oft nach dem Motto: "Augen auf bei der Toolauswahl":

…"vorab im Rahmen der Softwareentwicklungsplanung … Auswahl der verwendeten Werkzeuge … Werkzeug … sollte erprobt sein und gut überlegt eingesetzt werden. Der Softwareentwicklungsplan sollte die Werkzeuge und deren Versionen dokumentieren." [5]

Und was bewegt sich bei den Software-Toolherstellern? Das Angebot für Tool-Qualification-Packages steigt, insbesondere bei Herstellern von Verifikations-, Anforderungsmanagement-Tools, Compilern, Codegeneratoren usw. Schon alleine deshalb, weil die Anzahl der Anfragen nach solchen Packages steigt. Nicht weil ein Kunde dieses Produkt gleich kaufen möchte. Nein, eher weil es ein gutes Gefühl vermittelt, dass der Hersteller Methoden implementiert hat und Dokumentation zur Verfügung stellt, die eine Validierung des Software-Tools ermöglichen. Viele Software-Toolhersteller lassen sich genau in diesem Punkt zusätzlich ein Zertifikat z.B. vom TÜV ausstellen. In der Regel wird von extern die grundsätzliche Eignung eines Software-Tools für den Einsatz in einem Safety-Projekt bestätigt. Dahinter stehen dann nicht nur das Audit bzw. Assessment von Prozessen des Software-Toolherstellers, sondern auch umfangreiche Tests des Produkts selbst. Insgesamt führen die Erstellung eines Tool-Qualification-Package und Zertifikate zur steigenden Transparenz des Entstehungsprozess eines Software-Tools.

Zusammenfassung

Das Wort "Tool-Qualifizierung" wird als Überbegriff für eine ganze Reihe an Aktivitäten verwendet. Im Grunde ist die nähere Betrachtung von Softwaretools im Entstehungsprozess von Embedded Systemen gemeint, die sich in Klassifizierung und vertrauensbildende Maßnahmen gruppieren lassen. Letztere können auch die Qualifizierung eines Softwaretools zur Folge haben.

Die Luftfahrtindustrie beschreibt in der DO-330 am ausführlichsten, wie eine Software-Tool-Entwicklung gemäß eines Safety-Standards ablaufen soll. Auch die Vorabbetrachtung und Qualifizierung von zukaufbaren Software-Tools und Software im Allgemeinen sind dort sehr gut beschrieben.

Alleine mit dem Kauf eines Tool-Qualification-Package ist die Vorabbetrachtung von Software-Tools in einem Safety-Projekt nicht zu stemmen. Eine genaue Klassifizierung der Tools durch intensive Betrachtung der Einsatzszenarien (Use Cases oder auch Tool Operational Requirements genannt) im Prozess und für jedes Projekt einzeln und immer wieder ist eine zu empfehlende Vorgehensweise. Dadurch kann man ggf. auch im Haftungsfall nachweisen, dass man gemäß dem Stand der Technik und Wissenschaft gehandelt hat.

Als Software-Toolhersteller ist es im Rahmen der Tool-Qualifizierung wichtig, authentisch zu sein, Entwicklungs- und Testprozesse für den Kunden transparent darzustellen, eine eigene, professionelle Testautomatisierung zu implementieren und zu leben sowie letztendlich sich über ein Zertifikat attestieren zu lassen, dass die Software-Tools in Anlehnung an Standards der Funktionalen Sicherheit überhaupt qualifizierbar sind. Letzteres ist für den Kunden dahingehend nützlich, dass es die grundsätzliche Einsatzfähigkeit eines Software-Tools in einem Safety-Kontext bestätigt.

Literatur- und Quellenverzeichnis

[1]  Stefan Kriso, ISO 26262 – Quo vadis?, Center of Competence "Functional Safety", Robert Bosch GmbH, Abstatt, 2012

[2]  Stephen A. Jacklin, Certification of Safety-Critical Software Under DO-178C and DO-278A, NASA Ames Research Center, Moffett Field, CA, 94035

[3]  DO-330, Software Tool Qualification Considerations, RTCA.org, 2011

[4]  Frédéric Pothon, DO-330/ED-215 Benefits of the New Tool Qualification Document, ACG Solutions,  2012

[5]  Basiswissen Medizinische Software, dpuntk.verlag, 2. Auflage, 2015

[6]  Oscar Slotosch, Martin Wildmoser, Jan Philipps, Reinhard Jeschull – Validas AG, Rafael Zahlmann - Infineon, ISO 26262 – Tool Chain Analysis Reduces Tool Qualification Costs, München, 2012

[7]  Oscar Slotosch, Model-Based Tool Qualification, The Roadmap of Eclipse towards Tool Qualification, Validas AG, Springer-Verlag, 2012

 

Beitrag als PDF downloaden

Test, Qualität & Debug - unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualität & Debug.

 

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.

Test, Qualität & Debug - Fachwissen

Wertvolles Fachwissen zum Thema Test, Qualität & Debug steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.