Autor: Erol Simsek, iSYSTEM AG<\/p>\n
Standards der Funktionalen Sicherheit verlangen bzw. empfehlen die n\u00e4here Vorabbetrachtung der im Softwareentstehungsprozess verwendeten Software-Werkzeuge im Hinblick auf deren „Einsatzrisiko“ und damit negativen Auswirkung auf die Safety eines Systems. \u00a0Als Software-Toolhersteller in diesem Bereich wird man deshalb zunehmend mit Fragen konfrontiert wie z.B. „Ist Ihr Werkzeug zertifiziert?“, „Haben Sie einen ‚T\u00dcV-Stempel‘?“ oder „K\u00f6nnen Sie uns bei der Qualifizierung Ihrer Tools unterst\u00fctzen?“ Was hei\u00dft das konkret, und wie haben wir, Software-Toolhersteller und Kunden, uns bisher mit diesem Thema auseinandergesetzt?<\/strong><\/p>\n Seit dem offiziellen Inkrafttreten der ISO2626 (Road vehicles \u2013 Functional safety) im Jahr 2011[1] ist im Embedded Markt eine zunehmende Sensibilisierung f\u00fcr das Thema Toolqualifizierung zu versp\u00fcren. In anderen Standards der Funktionalen Sicherheit (FuSi) ist Toolqualifizierung schon sehr viel l\u00e4nger pr\u00e4sent. Als \u00fcbergeordnete Norm klassifiziert die IEC 61508:2010 („Funktionale Sicherheit<\/a>\u00a0sicherheitsbezogener elektrischer\/elektronischer\/programmierbarer elektronischer Systeme“, erstmals 1998 ver\u00f6ffentlicht) Software-Tools in drei Kritikalit\u00e4ts-Klassen T1-T3. Je nach Einstufung gem\u00e4\u00df der Fragestellung „Hat das Software-Tool eine negative Auswirkung auf die Safety des Systems?“ werden entsprechende Ma\u00dfnahmen 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.<\/p>\n In diesem Zusammenhang wird das Wort Toolqualifizierung als \u00dcberbegriff f\u00fcr eine ganze Reihe an Aktivit\u00e4ten verwendet. Im Grunde ist die n\u00e4here Betrachtung von Software-Tools im Entstehungsprozess von Embedded Systemen gemeint, die sich in Klassifizierung und vertrauensbildende Ma\u00dfnahmen gruppieren lassen. Letztere k\u00f6nnen auch die Qualifizierung eines Softwaretools zur Folge haben. Dazu sp\u00e4ter mehr.<\/p>\n Im Jahr 2012, also gut 20 Jahre nach der Einf\u00fchrung 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\u00fchrte die RTCA (Radio Technical Commission for Aeronautics<\/a>) 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\u00e4\u00df 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\u00e4nen-unabh\u00e4ngig auch zur Anwendung in anderen M\u00e4rkten [3][4].<\/p>\n Die DO-330 definiert ein Software-Tool wie folgt (aus dem Englischen frei \u00fcbersetzt):<\/p>\n „\u2026 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\u00fctzend verwendet wird bzw. Ver\u00e4nderungen von Daten oder Dokumentation eines Programms bewirkt.“<\/p>\n Beispiele f\u00fcr Software-Tools sind z.B. Code Generatoren, Compiler, Test Tools, selbst entwickelte Software, Skripte, Standard Office Produkte usw.<\/p>\n 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\u00dfnahmen im Prozess kompensiert werden, fordert bzw. empfiehlt der eine oder andere FuSi-Standard die n\u00e4here Betrachtung von Software-Tools im Vorfeld einer Safety-Entwicklung.<\/p>\n Im Prinzip wird vom Systemhersteller konkret verlangt, die historisch gewachsenen Software-Toollandschaften genau unter die Lupe zu nehmen, insbesondere in Bezug auf die Anwendungsf\u00e4lle im Prozess. Zus\u00e4tzlich soll Vertrauen in den Einsatz bestimmter Software-Tools aufgebaut und letztendlich nachweisbar sein. Damit verbunden ist au\u00dferdem 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\u00dfnahmen zur Tool Qualifizierung anwenden, um das Misstrauen und damit das Einsatzrisiko des jeweiligen Software-Tools zu minimieren. Die Art der Ma\u00dfnahme 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).<\/p>\n Wem gegen\u00fcber muss man als Kunde den Nachweis aufzeigen, dass man Software-Tools im Prozess n\u00e4her betrachtet und ggf. qualifiziert hat?<\/strong><\/p>\n 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\u00fcber diesen offiziellen Stellen zu erbringen. Andere M\u00e4rkten 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.<\/p>\n 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:<\/p>\n \u00dcbergeordnete Norm: IEC 61508 und Bahntechnik: EN50128:2011<\/strong><\/p>\n Automotive: ISO26262:2011 Road Vehicles \u2013 Functional Safety<\/strong><\/p>\n 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<\/strong><\/p>\n Medizintechnik: EN ISO 13485 (Qualit\u00e4tsmanagement), EN ISO 14971 (Risikomanagement), EN 62304 (Lebenszyklus medizinischer Software)<\/strong><\/p>\n 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\u00fchrungsumgebung und Testf\u00e4llen 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.<\/p>\n Dem Gedanken, ein Tool-Qualification-Package zu kaufen, sind ein Gro\u00dfteil der Vorabbetrachtungsschritte zum Einsatzrisiko von Software-Tools bereits vorausgegangen. Die Entscheidung f\u00fcr 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\u00f6glich gestaltet. Die Erwartungshaltung, dass mit dem Kauf die Validierung quasi abgeschlossen ist, ist nat\u00fcrlich falsch. Mit dem Kauf beginnt die eigentliche Arbeit. Deshalb versucht man den sehr aufw\u00e4ndigen Prozess der Tool-Validierung wenn m\u00f6glich durch intensive Klassifizierung der Software-Tools zu vermeiden. Die Luftfahrt l\u00e4sst durch eine vorgegebene Kategorisierung nicht viel Spielraum zur Interpretation, wohingegen andere Standards den Systemhersteller sofort in eine Diskussion \u00fcber m\u00f6gliche Risiken, die ein Software-Tool darstellt, Tool-Fehler-Eintrittswahrscheinlichkeiten usw., f\u00fchren. Diese Diskussionen und die damit verbundenen Entscheidungen sind sehr individuell und k\u00f6nnen durchaus von Firma zu Firma und von Projekt zu Projekt unterschiedlich ausfallen. Dokumentieren l\u00e4sst sich dieser Prozess am besten durch Formalisierung des Klassifizierungsvorgangs mittels Toolunterst\u00fctzung, wie in [6][7] beschrieben.<\/p>\n Der Aufwand f\u00fcr den Software-Toolhersteller, ein Tool-Qualification-Package zur Verf\u00fcgung zu stellen, ist durchaus hoch und kann auch variantenreich ausfallen. Entsprechende Serviceleistungen zur Inbetriebnahme bzw. Schulung m\u00fcssen mit angeboten werden. Der Kunde soll letztendlich selbstst\u00e4ndig eine Validierung durchf\u00fchren, so wie vom Standard vorgeschrieben. Ein Tool-Qualification Package wird dadurch zum Produkt mit Consulting-Dienstleistungen, das sich dann auch entsprechend verkaufen soll.<\/p>\n Heute stellen fast alle Hersteller von Software-Tools ein Tool-Qualification-Package zur Verf\u00fcgung. Alleine die Eingabe der beiden W\u00f6rter in eine Suchmaschine f\u00fchrt zu einer ganzen Reihe unterschiedlichster Angebote f\u00fcr diesen Zweck. Des Weiteren finden sich etliche Zertifikate, die den m\u00f6glichen Einsatz eines Software-Tools in einem Safety-Projekt f\u00fcr machbar einsch\u00e4tzen. Vertrauensbildend sind all diese Dinge, die Arbeit der Klassifizierung und eventuellen Qualifizierung\/Validierung bleibt dem Kunden aber dadurch nicht erspart.<\/p>\n 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\u00e4rkte an dem sehr gut ausformulierten Dokument orientieren werden. Nach anf\u00e4nglicher 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\u00e4stig, sondern eher als f\u00f6rderlich auch f\u00fcr die Effizienz von Prozessen bewertet. Andere Industrien betrachten Software-Tools getrennt voneinander und oft nach dem Motto: „Augen auf bei der Toolauswahl“:<\/p>\n \u2026“vorab im Rahmen der Softwareentwicklungsplanung \u2026 Auswahl der verwendeten Werkzeuge \u2026 Werkzeug \u2026 sollte erprobt sein und gut \u00fcberlegt eingesetzt werden. Der Softwareentwicklungsplan sollte die Werkzeuge und deren Versionen dokumentieren.“ [5]<\/p>\n Und was bewegt sich bei den Software-Toolherstellern? Das Angebot f\u00fcr 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\u00f6chte. Nein, eher weil es ein gutes Gef\u00fchl vermittelt, dass der Hersteller Methoden implementiert hat und Dokumentation zur Verf\u00fcgung stellt, die eine Validierung des Software-Tools erm\u00f6glichen. Viele Software-Toolhersteller lassen sich genau in diesem Punkt zus\u00e4tzlich ein Zertifikat z.B. vom T\u00dcV ausstellen. In der Regel wird von extern die grunds\u00e4tzliche Eignung eines Software-Tools f\u00fcr den Einsatz in einem Safety-Projekt best\u00e4tigt. Dahinter stehen dann nicht nur das Audit bzw. Assessment von Prozessen des Software-Toolherstellers, sondern auch umfangreiche Tests des Produkts selbst. Insgesamt f\u00fchren die Erstellung eines Tool-Qualification-Package und Zertifikate zur steigenden Transparenz des Entstehungsprozess eines Software-Tools.<\/p>\n Das Wort „Tool-Qualifizierung“ wird als \u00dcberbegriff f\u00fcr eine ganze Reihe an Aktivit\u00e4ten verwendet. Im Grunde ist die n\u00e4here Betrachtung von Softwaretools im Entstehungsprozess von Embedded Systemen gemeint, die sich in Klassifizierung und vertrauensbildende Ma\u00dfnahmen gruppieren lassen. Letztere k\u00f6nnen auch die Qualifizierung eines Softwaretools zur Folge haben.<\/p>\n Die Luftfahrtindustrie beschreibt in der DO-330 am ausf\u00fchrlichsten, wie eine Software-Tool-Entwicklung gem\u00e4\u00df eines Safety-Standards ablaufen soll. Auch die Vorabbetrachtung und Qualifizierung von zukaufbaren Software-Tools und Software im Allgemeinen sind dort sehr gut beschrieben.<\/p>\n 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\u00fcr jedes Projekt einzeln und immer wieder ist eine zu empfehlende Vorgehensweise. Dadurch kann man ggf. auch im Haftungsfall nachweisen, dass man gem\u00e4\u00df dem Stand der Technik und Wissenschaft gehandelt hat.<\/p>\n Als Software-Toolhersteller ist es im Rahmen der Tool-Qualifizierung wichtig, authentisch zu sein, Entwicklungs- und Testprozesse f\u00fcr den Kunden transparent darzustellen, eine eigene, professionelle Testautomatisierung zu implementieren und zu leben sowie letztendlich sich \u00fcber ein Zertifikat attestieren zu lassen, dass die Software-Tools in Anlehnung an Standards der Funktionalen Sicherheit \u00fcberhaupt qualifizierbar sind. Letzteres ist f\u00fcr den Kunden dahingehend n\u00fctzlich, dass es die grunds\u00e4tzliche Einsatzf\u00e4higkeit eines Software-Tools in einem Safety-Kontext best\u00e4tigt.<\/p>\n [1]\u00a0 Stefan Kriso, ISO 26262 \u2013 Quo vadis?, Center of Competence „Functional Safety“, Robert Bosch GmbH, Abstatt, 2012<\/p>\n [2]\u00a0 Stephen A. Jacklin, Certification of Safety-Critical Software Under DO-178C and DO-278A, NASA Ames Research Center, Moffett Field, CA, 94035<\/p>\n [3]\u00a0 DO-330, Software Tool Qualification Considerations, RTCA.org, 2011<\/p>\n [4]\u00a0\u00a0Fr\u00e9d\u00e9ric Pothon, DO-330\/ED-215 Benefits of the New Tool Qualification Document<\/a>, ACG Solutions,\u00a0 2012<\/p>\n [5]\u00a0 Basiswissen Medizinische Software, dpuntk.verlag, 2. Auflage, 2015<\/p>\n [6]\u00a0 Oscar Slotosch, Martin Wildmoser, Jan Philipps, Reinhard Jeschull \u2013 Validas AG, Rafael Zahlmann – Infineon, ISO 26262 \u2013 Tool Chain Analysis Reduces Tool Qualification Costs, M\u00fcnchen, 2012<\/p>\n [7]\u00a0 Oscar Slotosch, Model-Based Tool Qualification, The Roadmap of Eclipse towards Tool Qualification, Validas AG, Springer-Verlag, 2012<\/p>\n Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualit\u00e4t & Debug.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema\u00a0Test, Qualit\u00e4t & Debug steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nWarum \u00fcberhaupt Tool-Qualifizierung?<\/h2>\n
Was ist Tool-Qualifizierung?<\/h2>\n
Standards der Funktionalen Sicherheit und Tool-Qualifizierung<\/h2>\n
\n
\na. Constructive, z.B. Compiler, Code Generator \u00e0 Level T2
\nb. Analysis\/Verification, z.B. Statische Codeanalyse , Unit Test Tool \u00e0 Level T3<\/li>\n
\na. Untersuchung der Betriebsbew\u00e4hrtheit eines Software-Tools
\nb. Tool-Validierung<\/li>\n<\/ol>\n\n
\na. High
\nb. Mid
\nc. Low<\/li>\n
\na. Untersuchung der Betriebsbew\u00e4hrtheit eines Software-Tools
\nb. Prozess-Audit\/Assessment beim Tool-Hersteller
\nc. Tool-Validierung
\nd.Pr\u00fcfung bzw. Nachweis, dass ein Werkzeug gem\u00e4\u00df eines Safety-Standards entwickelt wurde<\/li>\n<\/ol>\n\n
\na. Constructive (Tool-Kategorie 1, TK1)
\nb. Analysis (TK2)
\nc. Verification (TK3)<\/li>\n
\na. TK1: TQL1-2
\nb. TK2: TQL3-4
\nc. TK3: TQL5<\/li>\n
\na. Tool Operational Requirements (TOR) und
\nb. Tool-Validierung gem\u00e4\u00df dieser Einsatzszenarien
\nc. wowie die Beschreibung von Ma\u00dfnahmen, die einen eventuellen Tool-Fehler im Prozess erkennen bzw. kompensieren<\/li>\n\n
Tool-Qualification-Package<\/h2>\n
Erwartungshaltung von Kunden und Software-Tool-Lieferanten?<\/h2>\n
Wie hat der Markt dieses Thema bisher umgesetzt?<\/h2>\n
Status Quo und Lessons Learned<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\nTest, Qualit\u00e4t & Debug – unsere Trainings & Coachings<\/h2>\n
\nTest, Qualit\u00e4t & Debug – Fachwissen<\/h2>\n