EN 50128 und EN 50657 Unterstützende Werkzeuge

Das Kapitel 6.7 der EN 50128 und EN 50657 Unterstützende Werkzeuge und Sprachen definiert Anforderungen an Software Werkzeuge, welche in einem Sicherheits-relevanten Entwicklungsprozess eingesetzt werden. Projektmitarbeiter in Sicherheitsprojekten diskutieren immer wieder den Inhalt und die Bedeutung dieses Kapitels. Der nachfolgende Beitrag fasst die wesentlichen Anforderungen zusammen und leitet eine Praxisleitfaden für die Anwendung im Projekt ab. Was die EN 50128 und EN 50657 Unterstützende Werkzeuge nennt, wird oft auch als Tool Qualifikation bezeichnet.

Weitere Blogbeiträge zu verwandten Themen sind:

• Toolqualifikation der Phantomschmerz der Funktionalen Sicherheit (Teil2)!
• Toolqualifikation der Phantomschmerz der Funktionalen Sicherheit (Teil1)!
• IEC 61508 – zertifizierte Werkzeuge – Wann? Warum? Wie?
• Compiler für sicherheitsrelevante Software – Was ist zu tun?

Einteilung von Software Werkzeugen

Die EN 50128 und die EN 50657 definieren im Kapitel 3.1 folgende drei Toolklassen:

Werkzeug der Klasse T1: Werkzeug, das keine Ausgaben erzeugt, die direkt oder indirekt zum ausführbaren Code (einschließlich Daten) der Software beitragen.

Beispiele sind: Texteditoren, oder Anforderungs- oder Entwurfswerkzeuge ohne automatische Code-Generierung; Werkzeuge für das Konfigurationsmanagment

Werkzeug der Klasse T2: Werkzeug, das den Test oder die Verifikation des Entwurfs oder des ausführbaren Codes unterstützt, bei dem Fehler im Werkzeug zur Nicht-Erkennung von Fehlern führen können, jedoch in der ausführbaren Software keine Fehler direkt erzeugen können.

Beispiele sind: Generator für die Testumgebung, Werkzeug zur Messung der Testabdeckung, Werkzeug zur statischen Analyse

Werkzeug der Klasse T3: Werkzeug, das Ausgangsdaten erzeugt, die direkt oder indirekt zum ausführbaren Code (einschließlich Daten) des Systems beitragen.

Beispiele sind: Quellcodecompiler, Daten-/Algorithmencompiler, Werkzeug zur Veränderung von Sollwerten während des Systembetriebs, Optimierungscompiler, wenn die Beziehung zwischen dem Quellcodeprogramm und dem generierten Objektcode nicht offensichtlich ist, Compiler der ein ausführbares Laufzeitpaket in den ausführbaren Code einbindet.

Für T1 Werkzeuge müssen, gemäß beider Normen, keine weitergehenden Maßnahmen getroffen werden.

T2 Werkzeuge müssen im Wesentlichen eine Spezifikation oder Handbuch besitzen, in der bzw. dem das Verhalten des Werkzeuges klar definiert ist und alle Anweisungen oder Randbedingungen hinsichtlich der Anwendung aufgeführt sind. Darüber hinaus muss die Auswahl des Tools begründet werden und ein Konfigurationsmanagement Prozess muss vorhanden sein.

T3 Tools müssen darüber hinaus folgende Aspekte erfüllen:

• Chronik des bisherigen Einsatzes des Tools
• Diversitär, redundanter Code der die Aufdeckung von Fehlfunktionen erlaubt
• Übereinstimmung mit dem SIL Level, die aus der Risikoanalyse des Prozesses und der Verfahren, einschließlich der Werkzeuge abgeleitet werden
• Validierungsergebnisse
  • Aufzeichnung der Aktivitäten
  • Version des Handbuchs des Werkzeuges
  • Validierte Werkzeugversionen
  • Verwendete Hilfsmittel und Geräte
  • Ergebnisse der Validierungsaktivitäten
  • Testfälle und deren Ergebnisse für die anschließende Analyse
  • Nichtübereinstimmung zwischen erwarteten und tatsächlichen Ergebnissen

Praxisbewertung

Für erfahrene Funktionale Sicherheitsexperten definieren die EN 50128 und EN 50657 einen ganz guten Handlungsrahmen. Allerdings zeigt die Projektpraxis immer wieder, dass es trotzdem immer wieder viele Fragen gibt.

Die EN 50128 und die EN 50657 fordern, stärker als andere Funktionale Sicherheitsnormen, den Black-Box Test des eingesetzten Tools. Diese Tests müssen dokumentiert sein (Testfälle, Test Prozeduren, Test Ergebnisse). Nicht eindeutig definiert ist, wie die Spezifikation des Tools auszusehen hat. Eine Requirement Spezifikation und das Benutzerhandbuch werden mehr oder weniger gleich bewertet. Allerdings ist der Aufwand für eine Spezifikation mit atomaren, testbaren Requirements ist in der Regel aufwändig und teuer. Das Benutzerhandbuch wird kostenlos mit dem Tool geliefert. Über die Qualität bzw. den Detailgrad der Traceability zwischen Spezifikation und Tests wird keine direkte Aussage getroffen.

Ein weiterer Aspekt in der Praxis ist, dass häufig die Hersteller kommerzieller Tools, sogenannte Tool Qualifikationspakete anbieten. Diese Pakete sind in der Regel attraktiv, da die Tests sowie die dazugehörigen Dokumente schon fertig sind und Sie „nur“ die Tests einmal in Ihrer Umgebung ausführen müssen. Allerdings haben Sie in dem Fall kaum einen Einfluss auf den Inhalt des gelieferten Tool Qualifikationspaketes. Aus Sicht des Gutachters sind Sie aber trotzdem verantwortlich für den Inhalt, d.h. Sie müssen den Inhalt kennen und bewerten.

Praxisleitfaden für den Einsatz unterstützender Werkzeuge gemäß EN 50128 und EN 60567

Unabhängig davon wer das Tool Qualifikationspaket erstellt, ist folgendes zu empfehlen:

1. Erstellung einer Übersicht aller verwendeten Software Werkzeuge im Projekt mit einer Begründung der Toolklasse (T1, T2, T3). Für die überwiegende Mehrzahl der Tools wird hier das Ergebnis T1 sein.
2. Erstellung von funktionalen Requirements welche das Verhalten des Tools beschreiben
3. Erstellung von Testfällen welche Beschreiben was der nachfolgende Test konkret testet
4. Nachvollziehbare und plausible Verlinkung zwischen Requirements und Testfällen
5. Dokumentation von Requirement und Testfällen in einer Datenbank
6. Erstellung automatisierter Testskripte inklusive der Definition
7. Einsatz eines professionellen Konfigurations- und Änderungsmanagement

Mit diesem Vorgehen werden Sie 80% – 90% aller in der Praxis relevanten Software Werkzeuge erfolgreich einsetzen können. Das Vorgehen für den Compiler habe ich im Blog Compiler für sicherheitsrelevante Software beschrieben. Eine weitere Einschränkung möchte ich für Tools machen, welche Fehler in eine ausführbare SIL3/SIL4 Software direkt erzeugen können. Auch wenn die Norm hier nicht so eindeutig ist, kann es in der Praxis gut sein, dass hier weitere Maßnahmen gefordert werden.

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