Über die TÜV-Zertifizierung hinaus

Tool-Qualifikation für besonders kritische Applikationen

6. Oktober 2022, 8:30 Uhr | Mark Pitchford
Regulations, Compliance, Standards, concept words. Folder concept. Ring binders.
© allexxandarx – stock.adobe.com

Die meisten Normen für funktionale Sicherheit verlangen für anspruchsvolle Anwendungen irgendeine Art projektspezifischer Tool-Qualifikation, aber nur die Normen ISO 26262 und DO-330 enthalten Einzelheiten darüber, wie hierbei vorzugehen ist. Beide Methoden eignen sich auch für andere Branchen.

Die Entwicklung softwarebasierter, sicherheitskritischer Systeme heutiger Prägung ist ohne zertifizierte Softwaretools und Prozesse nicht denkbar. In vielen Anwendungen ist die Tool-Qualifikation ein absolutes Muss, wenn sichergestellt sein soll, dass die Qualität des von den Tools hervorgebrachten Codes ausreicht, um die Anforderungen der einschlägigen Sicherheitsnormen zu erfüllen. Auch wenn die Verwendung TÜV-zertifizierter Tools in vielen Fällen ausreichen mag, gibt es doch immer mehr Applikationen, in denen viel auf dem Spiel steht und in denen die Normen für funktionale Sicherheit höhere Anforderungen stellen (Bild 1).

Anbieter zum Thema

zu Matchmaker+
Normen über funktionale Sicherheit.
Bild 1. Die meisten Normen über funktionale Sicherheit sind direkte Abkömmlinge der IEC 61508 und gehören damit zur IEC-61508-Familie.
© LDRA

In besonders kritischen Anwendungen, bei denen eine TÜV-Zertifizierung zu kurz greifen würde, bieten die Normen ISO 26262 und DO-330 einen gangbaren Weg zur Qualifikation. Indem Entwickler-Teams ein Verständnis dafür entwickeln, weshalb andere Normen unzureichend sind, und indem sie darauf aufbauend ausloten, wie sich die Normen ISO 26262 und DO-330 so anpassen lassen, dass sie auch außerhalb der eigentlich für sie vorgesehenen Branchen anwendbar sind, lässt sich ein Tool-Qualifikationsprozess ausarbeiten, der über den Rahmen der TÜV-Qualifikation hinausgeht.

Die Qualifikation von Tools für sicherheitskritischen Code

Als Tool-Qualifikation wird die Sicherstellung eines akzeptabel niedrigen Risikos verstanden. Ein Fehler in einem Tool darf die funktionale Sicherheit eines Systems nur dann beeinträchtigen, wenn entweder nur wenige Fehler auftreten oder die Funktion von vornherein keine Auswirkungen auf die Sicherheit hat. In der Norm IEC 61508 (Funktionale Sicherheit sicherheitsbezogener elektrischer/elektronischer/programmierbarer elektronischer Systeme) heißt es:

»Beispiele sind die Deaktivierung einer medizinischen Infusionspumpe im Fall einer Fehlfunktion oder die automatische Aktivierung eines Überlaufventils, sobald ein bestimmter Flüssigkeitsstand oder Druck erreicht ist.«

Software-Kassifizierung
Bild 2. Mit dieser Klassifizierung der Software wird dafür gesorgt, dass der Verifikations- und Validierungsaufwand in einem gesunden Verhältnis zu den Risiken steht.
© LDRA

Die Mehrzahl der Normen für funktionale Sicherheit gewährleistet durch die Definition von Qualifikationsprozessen, dass potenzielle Fehler entweder gänzlich vermieden oder aber bei der Anwendung der Tools festgestellt werden. Nur wenige Normen enthalten jedoch irgendwelche Details für besonders kritische Anwendungen. Obwohl hinter allen diesen Standards das gemeinsame Ziel steht, Vertrauen in das jeweilige Tool aufzubauen, besteht nur wenig Klarheit in Bezug darauf, was die Entwicklungs-Teams genau tun sollen.

Dies wiederum stellt eine echte Herausforderung dar, denn die Tool-Qualifikation (Bild 2) ist zu komplex und zeitaufwändig, als dass sie halbherzig angegangen werden könnte.

Die Normen ISO 26262 und DO-330

Die Norm ISO 26262 (Road vehicles – Functional safety) ist ein speziell auf die Automobilindustrie abgestimmter Abkömmling der Norm IEC 61508. Für die Tool-Qualifikation setzt die Norm ISO 26262 ein Maß an Vertrauen voraus, das von den Rahmenbedingungen der jeweiligen Bereitstellung (Deployment) abhängig ist, wie in §11.2 zu lesen ist:

»…die Möglichkeit, dass das falsch funktionierende Softwaretool und seine entsprechend fehlerhaften Ausgaben zur Folge haben, dass in einem entwickelten sicherheitsrelevanten Gegenstand oder Element ein Fehler entsteht oder ein vorhandener Fehler nicht entdeckt wird, sowie das Vertrauen in die Fähigkeit zum Verhindern oder Aufdecken solcher Fehler in seinen Ausgaben.«

Von besonders kritischen Anwendungen abgesehen, ebnet diese Norm einen Weg zur dramatischen Reduzierung des mit der Qualifikation einhergehenden Aufwands, denn es wird zugelassen, dass sich die Evaluierung des Tools auf den Nachweis stützt, dass ein geeigneter Softwareentwicklungs-Prozess angewandt wurde. Eine Möglichkeit für Entwicklungs-Teams, hiervon zu profitieren, ist der Einsatz von Tools mit einer Zulassung durch eine Zertifizierungsorganisation wie dem TÜV, wie es beispielsweise bei der LDRA Tool Suite der Fall ist.

Für jene Anwendungen, bei denen die Normen eine rigorosere Qualifikation im Kontext der Projekt-Entwicklungsumgebung verlangen, bieten die Lieferanten oftmals Tool Qualification Support Packs – auch als Suites, Packages, Kits o.ä. bezeichnet. Korrekt angewendet, können diese Pakete tatsächlich den Nachweis liefern, dass das Tool richtig konfiguriert wurde, um in der Toolchain und der vorgesehenen Einsatzumgebung die korrekten Ergebnisse zu liefern.

Auszug aus dem LDRA Tool Qualification Plan gemäß DO-330 TQSP.
Bild 3. Auszug aus dem LDRA Tool Qualification Plan gemäß DO-330 TQSP.
© LDRA

Die Norm RTCA/DO-330 (Software Tool Qualification Consideration) wurde eingeführt, um die Tool-Qualifikationsanforderungen zur Entwicklung von Software für die Luftfahrt zu ergänzen, wie sie in der Norm RTCA/DO‑178C (Software Considerations in Airborne Systems and Equipment Certification) formuliert sind. Laut DO-330 erfordert jedes Projekt eine Tool-Qualifikation – unabhängig davon, wie kritisch es ist.

Die in beiden Normen beschriebenen Prinzipien lassen sich auch auf andere Branchen anwenden, und tatsächlich ist dies in der DO-330 (§1.2) explizit so formuliert:

»Dieses Dokument bietet Leitlinien für luft- und bodengestützte Software, kann jedoch auch in anderen Bereichen angewandt werden (z.B. Automobiltechnik, Raumfahrt, Systeme, elektronische Hardware, Luftfahrt-Datenbanken und Sicherheitsbewertungs-Prozesse).«

Wo liegen die Mängel anderer Normen?

Obwohl die branchenspezifischen Sicherheitsstandards meist anspruchsvolle Tool-Qualifikationsanforderungen für besonders kritische Applikationen enthalten, finden sich in vielen dieser Normen keine genauen Einzelheiten darüber, wie diese Vorgaben erfüllt werden können. Dazu diese Beispiele:

  • IEC 61508 – Hier ist es vielleicht am überraschendsten, bildet diese Norm doch die Grundlage für die sektorspezifische ISO 26262. In Teil 3, §7.4.4.5, steht die folgende Aussage: »Werden derartige Ausfallmechanismen festgestellt, sind entsprechende Gegenmaßnahmen zu ergreifen.« Einzelheiten zu diesen Maßnahmen sucht man jedoch vergebens.
  • EN 50128 (Bahnanwendungen – Telekommunikationstechnik, Signaltechnik und Datenverarbeitungssysteme) – Hier findet sich in Abschnitt 6.7.4.2 die folgende Aussage: »Die Begründung hat die Identifikation potenzieller Ausfälle, die sich in die Ausgabe der Tools einschleichen können, ebenso einzubeziehen wie die Maßnahmen zur Vermeidung solcher Ausfälle oder den Umgang damit«. Auch hier fehlen jegliche Details zu diesen Maßnahmen.
  • IEC 62304 (Medizingeräte-Software – Software-Lebenszyklus-Prozesse) – Diese Norm enthält gleich mehrere Aussagen, die eine Tool-Verifikation verlangen, ohne jedoch spezifische Anweisungen zu geben. Unter anderem heißt es in §3.3: »Bestätigung durch Vorlage objektiver Nachweise, dass die spezifizierten Anforderungen erfüllt wurden«. Was fehlt, sind Leitlinien dazu, worum es sich bei diesen Nachweisen zu handeln hat.

Anpassung der Normen ISO 26262 und DO-330 an andere Bereiche

In der Praxis sind die Entwicklungsteams dafür verantwortlich, herauszufinden, worin die angemessene »Bewertung«, »Begründung« und »Verifikation« für die Zertifizierung gemäß der jeweiligen Norm besteht. Da die getroffenen Entscheidungen nicht einfach zu fällen, geschweige denn zu verteidigen sind, lohnt sich ein Blick darauf, wie die bestehenden Lücken durch Tool-Qualifikationsprozesse für ISO 26262 oder DO-330 gefüllt werden können.

Nichts an den von beiden Normen definierten Qualifikationsprozessen macht sie sektorspezifisch, und für beide gibt es von zahlreichen Anbietern entsprechende Unterstützung für die Tool-Qualifikations. Welcher Weg der richtige ist, hängt von den Eigenschaften des Projekts ab. Um aber die beste Wahl zu treffen, ist es sinnvoll, sich fünf wichtige Unterschiede und Ähnlichkeiten der Normen ISO 26262 und DO-330 vor Augen zu führen:

  1. Potenzielle Auswirkungen von Fehlern – Bei beiden Normen müssen bei der Bestimmung des Konfidenzniveaus für das Tool die potenziellen Auswirkungen von Fehlern berücksichtigt werden, die mit den vom Tool unterstützten Methoden und Prozessen zusammenhängen.
  2. Art des Tools – Beide Normen unterscheiden zwischen Tools, die einen Fehler in das System einbringen können, z.B. Codegeneratoren, und Tools, die einen vorhandenen Fehler möglicherweise nicht entdecken, z.B. Prüf-Tools.
  3. Konfidenz-Anforderungen – Beide Normen klassifizieren die Konfidenz-Anforderungen. In der DO-330 werden diese als Kriterien 1, 2 und 3 bezeichnet, in der ISO 26262 dagegen als Tool Confidence Levels (TCL) 1, 2 und 3.
  4. Alternative Qualifikationsmethoden – In beiden Normen dienen Tabellen dazu, Software entsprechend ihrer Kritikalität den jeweiligen Qualifikationsmethoden zuzuordnen. Die DO-330 verlangt, dass Prüf-Tools, bei denen das Risiko der Nichterkennung von Fehlern besteht, ihrem eigenen Qualifikationsprozess folgen, die ISO 26262 dagegen gestattet unter bestimmten Umständen die Verwendung anderer Qualifikationsprozesse.
  5. Testverifikations-Technik – Der Tool-Qualifikationsprozess der Norm ISO 26262 besteht vorrangig aus Prüfungen und Analysen. Im Gegensatz dazu schreibt die Norm DO-330 On-Target-Tests vor, um die Effektivität und Compliance des Tools für höhere DAL (Design Assurance Level) nachzuweisen.

Um sich zwischen den beiden Normen ISO 26262 und DO-330 zu entscheiden und die beste Lösung für die jeweilige Anwendung zu finden, müssen Unternehmen über die gemeinsamen Prinzipien und Unterschiede beider Normen Bescheid wissen. Qualifikations-Pakete der Anbieter können ihnen helfen, den Aufwand zu reduzieren und die Arbeit zu rationalisieren. Ein typischer Satz Artefakte für ein Prüf-Tool könnte zum Beispiel Testcode für die jeweils geprüfte Funktion, erwartete Ergebnisse und die zugehörige Dokumentation umfassen, um den Zielsetzungen der gewählten Norm gerecht zu werden.

 

Der Autor

Mark Pitchford von LDRA
Mark Pitchford, LDRA Software Technology
© LDRA

Mark Pitchford

verfügt über mehr als 30 Jahre Erfahrung in der Softwareentwicklung für technische Anwendungen. Er hat an vielen bedeutenden Industrie- und Handelsprojekten in den Bereichen Entwicklung und Management gearbeitet, sowohl in Großbritannien als auch international.

Seit 2001 arbeitet Pitchford mit Entwicklungsteams zusammen, die eine konforme Softwareentwicklung in sicherheitskritischen Umgebungen anstreben, mit Standards wie DO-178, IEC 61508, ISO 26262, IIRA und RAMI 4.0. Er studierte an der Nottingham Trent University mit dem Abschluss Bachelor of Science und wurde vor über 30 Jahren Chartered Engineer. Pitchford arbeitet jetzt als technischer Spezialist bei LDRA Software Technology.

mark.pitchford@ldra.com


Das könnte Sie auch interessieren

Verwandte Artikel

LDRA Inc.

Themenwoche Embedded-Systeme Okt.22