Der Begriff Toolqualifikation löst bei vielen, die sich mit dem Thema Funktionale Sicherheit beschäftigen, ein unangenehmes Gefühl und Unsicherheit aus. Die IEC 61508 fordert die Zertifizierung von Softwaretools die für die Softwareentwicklung verwendet werden. Auch andere Funktionale Sicherheitsstandards erheben ähnliche Forderungen. Allerdings werden leider nicht immer die gleichen Begrifflichkeiten verwendet. Die IEC 61508 verwendet den Begriff „zertifizierte Werkzeuge“, oft wird auch der Begriff „qualifizierte Werkzeuge“ oder auch Toolqualifikation verwendet.

Neben den unterschiedlichen Begriffen, gibt es auch ganz unterschiedliche, teils sehr individuelle, Interpretationen was genau unter dem Thema zu verstehen ist. Der nachfolgende Beitrag versucht zur Klärung offener Fragen in dem Themenkomplex beizutragen. Folgende 3 Fragen werden dabei beantwortet:

• Warum fordern Funktionale Sicherheitsstandards die Zertifizierung von Softwarewerkzeugen?
• Welche Forderungen stellt die IEC61508?
• Wie geht man sinnvoll mit dem Thema um?

Warum fordern Funktionale Sicherheitsstandards die Zertifizierung von Softwarewerkzeugen?

Alle Funktionalen Sicherheitsstandards lassen sich im Bereich der Entwicklungsprozesse auf den Einsatz des 4-Augen Prinzips verallgemeinern. Jede Tätigkeit soll durch eine zweite Instanz/Person überprüft werden.

Beim Einsatz von Softwaretools, besteht die Möglichkeit dass dieses Prinzip verletzt wird. Anhand der statischen Codeanalysetools lässt sich dies anschaulich darstellen. So ein Tool wird eingesetzt um die Einhaltung der festgelegten Kodierrichtlinien im Source Code zu überprüfen. Sollte so ein Tool einen Fehler beinhalten, werden ggf. Verstöße gegen entsprechende Kodierrichtlinien nicht entdeckt, da keine weitere Überprüfung stattfindet.

Genau in diese Lücke stößt die Toolqualifikation bzw. die Zertifizierung von Softwaretools. Damit wird das 4-Augen Prinzip auch für den Bereich der Softwaretools wieder hergestellt. 

Welche Forderungen stellt die IEC61508?

Leider gibt die IEC 61508 im Vergleich zu anderen Funktionalen Sicherheitsstandards nur wenig Hinweise was genau zu tun ist. Im Teil 3 der Norm werden in der Tabelle A.3 Softwareentwurf und Softwareentwicklung – Werkzeuge und Programmiersprachen folgende zwei Verfahren/Maßnahmen definiert welche im Teil 7 in den Kapitel C.4.3 und C.4.4 weiter ausgeführt werden:

• Zertifizierte Werkzeuge und zertifizierte Übersetzer
• Werkzeuge und Übersetzer: erhöhtes Vertrauen durch die Anwendung

Bezüglich der Zertifizierung sagt die Norm noch folgendes:
„Die Zertifizierung eines Werkzeuges wird im Allgemeinen von einer unabhängigen, meist nationalen Institution nach unabhängigen Kriterien […] ausgeführt. Idealerweise sollten die in allen Entwicklungsphasen (Spezifikation, Entwurf, Codierung, Test und Validierung, Konfigurationsmanagement) verwendete Werkzeuge zertifiziert sein.“

Bezüglich der zweiten genannten Maßnahme führt die Norm folgendes aus:
„Ziel: Vermeidung aller Schwierigkeiten durch Versagen eines Compilers, die während der Entwicklung, Verifikation und Pflege eines Softwarepakets auftreten können.
Beschreibung: Es wird ein Compiler verwendet, bei dem in vielen früheren Projekten keine Anzeichen für nicht korrekte Ausführung auftraten. […] Ebenso gibt es bekanntlich gegenwärtig keine Methode, um die Korrektheit für alle Teile der Werkzeuge oder Compiler nachzuweisen.“

Desweiteren findet man im Teil 3 Kapite 7.4.4 Anforderungen an Werkzeuge einschließlich Programmiersprachen einige Hinweise wie mit welchen Tools zu verfahren ist. Grundsätzlich sollen die Tools in eine der Klassen T1, T2 oder T2 eingestuft werden. Leider ist eine in sich konsistente Argumentation in diesem Kapitel nur schwer zu erkennen.

Wie geht man sinnvoll mit dem Thema zertifizierte Werkzeuge um?

Da die von der IEC61508 genannten Verfahren/Maßnahmen für die Praxis nur wenig hilfreich sind, plädiere ich für folgendes Vorgehen:

1. Beantwortung der Frage: Kann das betrachtete Tool einen Fehler in die operationelle Software einfügen (Beispiel: Compiler)?
2. Wenn nein, kann das betrachtete Tool Fehler die in der operationellen Software drin sind ggf. nicht finden (Beispiel: statische Codeanalysetools, etc.)
3. Wenn eine der Fragen mit „Ja“ beantwortet werden muss, dann Auswahl einer der folgenden Verfahren/Maßnahmen:
   • Analyse von Daten aus historischer Anwendung des Tools
   • Durchführung eines Assessment des Entwicklungsprozesses des Tools
   • Test der Funktionalität des Tools
   • Entwicklung des Tools nach einem Funktionalen Sicherheitsstandard
4. Falls Frage 1 mit „Ja“ beantwortet wird und ein höhere SIL Level eingehalten werden muss dann kommen eher die letzten beiden Maßnahmen zum Einsatz
5. Falls Frage 2 mit „Ja“ beantwortet wird und ein niedriger SIL Level eingehalten werden muss, dann kommen eher die ersten beiden Maßnahmen zum Einsatz
   

Das obige Vorgehen ergibt sich wenn man das Vorgehen der Luftfahrt und Automobilbranche in diesem Themenbereich auf die IEC61508 anwendet.

Weitere HEICON Blog Posts zur Tool Qualifikation

• Wichtigkeit der Toolqualifikation in der FuSi (Teil1)!
• Wichtigkeit der Toolqualifikation in der FuSi (Teil2)!
• EN50128 und EN50657 Unterstützende Werkzeuge

Gerne unterstütze ich Sie z.B. mit einem Workshop zu Ihren projektspezifische Fragen zum Thema und weiteren HEICON Produkten. Senden Sie eine Mail an: info[at]heicon-ulm.de.