Qualität mit Brief und Siegel
Zertifizierung industrieller Systeme gemäß IEC 61508
Fortsetzung des Artikels von Teil 1
Feuerprobe für den Code
IEC 61508 schreibt die statische Analyse bindend als ersten Schritt einer umfassenden Software-Qualitätskontrolle vor. Bei der statischen Analyse wird der Quellcode anhand von Programmierstandards wie MISRA und CERT geprüft, um latente Fehler und Schwachstellen wie etwa Arraygrenzen, Divisionen durch Null oder nicht initialisierte Zeiger aufzudecken, die bei der Ausführung der Software ausgenutzt werden könnten. In dieser Phase werden die Konsistenz des Quellcodes geprüft und das etwaige Vorhandensein von totem Code oder nicht aufgerufenen Prozeduren gecheckt. Die Qualität der Software wird hier mithilfe von Parametern wie zum Beispiel Klarheit, Wartungsfreundlichkeit, Prüfbarkeit und Komplexität quantifiziert.
Eine Datenfluss-Analyse generiert eine Reihe analytischer Verifikationen der Variablennutzung sowie von Prozedur-Interaktionen und Interrupts im Quellcode. Ein Kontrollflussdiagramm enthält einen Teilbereich zur Wiedergabe sequenzieller Schritte mit If-Then-Else-Bedingungen, Wiederholungen und/oder Case-Bedingungen. Entsprechend beschriftete geometrische Figuren geben Befehle, Daten oder Equipment wieder, während der sequenzielle Ablauf durch Pfeile symbolisiert wird. Mit welcher Stringenz der Standard durchgesetzt wird, hängt vom SIL ab, den das jeweilige sicherheitsrelevante System erfüllen muss. Tabelle 1 verdeutlicht die verschiedenen Techniken und Maßnahmen für die statische Analyse und die Empfehlung entsprechend dem jeweiligen SIL.
Jobangebote+ passend zum Thema
| Technik/Maßnahme | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Grenzwert-Analyse |
R |
R |
HR |
HR |
| Checklisten |
R |
R |
R |
R |
| Kontrollfluss-Analyse | R |
HR |
HR |
HR |
| Datenfluss-Analyse | R |
HR |
HR |
HR |
| Error Guessing | R |
R |
R |
R |
| Formale Inspektionen einschl. spezifischer Kriterien |
R |
R |
HR |
HR |
| Walk-through (Software) |
R |
R |
R |
R |
| Symbolische Ausführung |
- |
- |
R |
R |
| Designprüfung |
HR |
HR |
HR |
HR |
| Statische Analyse des Laufzeit-Fehlverhaltens |
R |
R |
R |
HR |
| Analyse der Worst-Case-Verarbeitungszeit |
R |
R |
R |
R |
Tabelle 1. Liste der Techniken und Maßnahmen im Rahmen der statischen Analyse sowie der Empfehlungen für die einzelnen SILs. Legende: HR: Highly Recommended (sehr empfohlen); R: Recommended (empfohlen); NR: Not Recommended (nicht empfohlen); -: No Recommendation (keine Empfehlung)
Laufzeit-Analyse
Nachdem die statische Analyse erfolgt ist, wird eine dynamische Analyse durchgeführt, um subtile Defekte oder Schwachstellen aufzudecken. Unter der dynamischen Analyse versteht man das Testen und Evaluieren eines Programms durch Verarbeitung der Daten in Echtzeit. Ziel ist hierbei das Auffinden von Fehlern im Programm während des Betriebs anstatt durch wiederholte Offline-Inspektion des Codes. Diese Analyse wird auf Unit-, Modul- und Systemebene durchgeführt, damit die gesamten Sicherheits-Funktionen für den geforderten SIL erzielt werden.
Der Validierungstestplan wird entwickelt, indem Testfälle für die Unit-, die Modul- und die Systemebene entworfen werden, um die gesamte Funktion der Software komplett abzudecken. Die Testfälle müssen für alle Eingangs-Kombinationen, Randbedingungen, Wertebereiche, Timing-Mechanismen usw. ausgearbeitet und dem erwarteten Output gegenübergestellt werden, um die Sicherheits-Funktionen des Systems zu validieren. Der Validierungsplan und die Testfälle müssen ferner zu den Anforderungen zurückverfolgt werden, um sicherzustellen, dass der gewünschte Grad an Integrität und Sicherheit erreicht ist. Die dynamische Analyse muss in zwei Phasen erfolgen:
- Funktions-Analyse (Black-Box-Test),
- Strukturelle Code-Analyse (White-Box-Test).
Im Black-Box-Test werden die Testdaten (d.h. die Inputs und die erwarteten Outputs) für die Testfälle von den festgelegten Anforderungen abgeleitet. Die Grenzwert-Analyse nutzt eine Funktionstest-Technik, in der extreme Grenzwerte (Maximum, Minimum, knappes Über- oder Unterschreiten von Grenzen, typische Werte und Fehlerwerte) im System angewendet werden, um sicherzustellen, dass keine Defekte vorliegen.
Beim White-Box-Test dagegen wird die Struktur des Quellcodes getestet, indem man dafür sorgt, dass die Inputs alle Pfade durch den Code aktivieren, und die entsprechenden Outputs bestimmt. Getestet werden die Pfade innerhalb einer Unit, die Pfade zwischen den Units während der Integration sowie die Pfade zwischen den Subsystemen während eines System-Level-Tests. Das Design der Testfälle erfolgt mit folgenden Zielsetzungen:
- Verwendung unabhängiger Pfade in einer Unit oder einem Modul,
- Verwendung der logischen Entscheidungen bei True und False,
- Ausführung von Schleifen mit ihren Randbedingungen und betrieblichen Bindungen,
- Verwendung der internen Datenstruktur zur Sicherstellung ihrer Validität.
White-Box-Tests umfassen Überdeckungs-Kennzahlen wie Einsprungpunkte, Statement, Verzweigung, Bedingungen und Modified Condition/Decision Coverage (MC/DC), um zu gewährleisten, dass jeder Teil der Software erfasst ist und anhand der Anforderungen geprüft wurde, um die Konformität zum geforderten SIL zu erreichen. Diese Überdeckungs-Kennzahlen sind im SIL des Systems umrissen (siehe Tabelle 2).
| Technik/Maßnahme | SIL 1 | SIL 2 | SIL 3 | SIL 4 |
|---|---|---|---|---|
| Testfall-Ausführung aus Grenzwert-Analyse |
R |
HR |
HR |
HR |
| Testfall-Ausführung aus Error Guessing |
R |
R |
R |
R |
| Testfall-Ausführung aus Error Seeding | - |
R |
R |
R |
|
Testfall-Ausführung aus modellbasierter Testfall-Generierung |
R |
R |
HR |
R |
| Performance Modeling | R |
R |
R |
HR |
| Equivalenzklassen und Input Partition Testing | R |
R |
R |
HR |
| Strukturelle Testüberdeckung (Einsprungpunkte) 100% |
HR |
HR |
HR |
HR |
| Strukturelle Testüberdeckung (Statements) 100% |
R |
HR |
HR |
HR |
| Strukturelle Testüberdeckung (Verzweigungen) 100% |
R |
R |
HR |
HR |
| Strukturelle Testüberdeckung (Zustände, MC/DC) 100% |
R |
R |
R |
HR |
Tabelle 2. Liste der Techniken und Maßnahmen im Zuge der dynamischen Analyse und zugehörige Empfehlungen nach den Definitionen der einzelnen SILs. Legende: HR: Highly Recommended (sehr empfohlen); R: Recommended (empfohlen); NR: Not Recommended (nicht empfohlen); -: No Recommendation (keine Empfehlung)
Während der Testphase wird die Software daraufhin geprüft, ob alle Sicherheits-Funktionen realisiert sind. Ist die Sicherheit der Software validiert, müssen möglicherweise noch bestimmte Korrekturen und/oder Ergänzungen vorgenommen werden, damit die Einhaltung der Anforderungen gewährleistet ist. Auch die Ergänzungen und Korrekturen müssen vollständig auf die Anforderungen zurückgeführt werden können. Sämtliche Modifikationen müssen dokumentiert werden.
Außerdem muss eine Impact-Analyse vorgenommen werden, aus der hervorgeht, welche Software-Module und Verifikations-Aktivitäten betroffen sind. In der Impact-Analyse wird bestimmt, welche Module oder Funktionen von einer Änderung betroffen sind und wie viele neue Tests erstellt werden müssen, um die neue(n) Funktion(en) abzudecken. Ebenso wird festgestellt, ob irgendwelche weiteren Systemanforderungen in das Testen der neuen Änderung involviert sind.
Nachdem die Modifikation des Quellcodes vorgenommen ist, muss eine Regressionsanalyse des gesamten Quellcodes erfolgen, um sicherzustellen, dass keine bereits vorhandenen Sicherheitsfunktionen von der Modifikation betroffen sind. Beim Regressionstest wird ein System oder eine Komponente selektiv neu getestet, um zu verifizieren, dass die Modifikationen keine unerwünschten Effekte hervorgerufen haben und das System bzw. die Komponente den festgelegten Anforderungen nach wie vor entspricht.
Vorteile überwiegen
Die Einführung der Norm IEC 61508 hat einst isoliert voneinander operierende Unternehmen, die sich mit der Entwicklung von Systemen oder Komponenten für industrielle Systeme befassen, auf die gleiche Weise in einen gemeinsamen Prozess eingebunden, wie es bei Unternehmen aus dem Luftfahrt- und Wehrtechnik-Bereich schon länger der Fall ist. Sämtliche Disziplinen unterliegen nunmehr den gleichen Qualitätssicherungs-Vorgaben, um die Konformität zu einem anspruchsvollen Standard zu gewährleisten. Die Forderung nach dieser Konformität hat eine Weiterentwicklung in Gang gesetzt, die dadurch gekennzeichnet ist, dass Prozesse und Projektpläne dokumentiert und die Anforderungen erfasst werden, dass Implementierung und Verifikation nach Maßgabe dieser Anforderungen erfolgen und dass sämtliche Artefakte in einem Konfigurationsmanagement-System vollständig kontrolliert werden.
Die Anwendung der Norm IEC 61508 auf die Software-Entwicklung für industrielle Systeme verlangt nach Konformität zu den im Standard definierten Prozessen, Aktivitäten und Aufgaben. Grundsätzlich setzt die IEC 61508 voraus, dass die Rückverfolgbarkeit der Anforderungen in sämtlichen Phasen des Software-Entwicklungsprozesses gewährleistet ist. Qualifizierte, sorgfältig integrierte Tools stellen sicher, dass die Entwickler den Prozess einfacher und effizienter automatisieren können.
Zweifellos ist der Umstieg auf auto-matisierte Compliance mit Kosten und potentiellen Änderungen an den bestehenden Verfahrensweisen verbunden. Die Unternehmen profitieren im Gegenzug jedoch davon, dass sie leichter zu hochwertigerer Software und zur Konformität zur IEC 61508 gelangen und dadurch den Aufwand an teuren manuellen Verfahren reduzieren können. Das hochwertigere und sicherere Produkt vermeidet kostspielige Rückrufe und stellt sicher, dass der Entwicklungsprozess auch den Wartungs- und Upgrade-Prozess unterstützt. All diese Aspekte kommen nicht nur direkt dem Gewinn des Herstellers zugute, sondern rechnen sich auch durch die erhöhte Glaubwürdigkeit und das bessere Renommee des Unternehmens.
Der Autor:
| Shrikant Satyanarayan |
|---|
| arbeitet als Technical Consultant bei LDRA in Indien. Er hat sich auf Entwicklung, Integra-tion und Zertifizierung sicherheitskritischer Systeme für die Bereiche Avionik, Nukleartechnik, industrielle Sicherheit und Automo-tive spezialisiert. Er berät Organisationen bei Auswahl, Integration und Unterstützung ihrer Embedded-Systeme von der Entwicklung bis zur Zertifizierung. |
- Zertifizierung industrieller Systeme gemäß IEC 61508
- Feuerprobe für den Code
Lesen Sie mehr zum Thema
