IEC 61508 – Funktionsabsicherung

Bild 2. Auswahl an semi-formalen und formalen Spezifikationsdiagrammen und -Tabellen für die Definition von Anforderungen.

© Mathworks

Im Standard ‚IEC 61508 – Part 3: Software Requirements‘ sind in Anhang A und B eine Reihe von Tabellen aufgeführt, die empfohlene Techniken und Maßnahmen zur Absicherung des Softwareentwicklungs-prozesses benennen. Zur Spezifikation von Sicherheitsanforderungen empfiehlt der Standard in den Tabellen A.1 und B.7 verschiedene semi-formale oder formale Methoden. Aus der Vielzahl von möglichen Formalismen sind in Simulink die Folgenden implementiert: Sequenzdiagramme, Zeitdiagramme (Dialog-basiert konstruiert), formalisierte Anforderungstabellen sowie Datenfluss-basierte Spezifikation mit temporalen Blockelementen (Bild 2). Durch die Verwendung solcher Diagramme anstelle von textuellen Darstellungen werden Mehrdeutigkeiten oder Interpretationsspielräume vermieden und die Verständlichkeit durch die Gehirn-gerechte visuelle Darstellung erleichtert. Aufgrund der Einbettung dieser Methoden in Simulink liegt der größte Vorteil jedoch in der automatisierten Auswertbarkeit, insbesondere für die Testauswertung.

Die vollständige Nachverfolgbarkeit der textuellen oder graphisch semiformal spezifizierten Anforderungen gestaltet sich einfach, sowohl hinsichtlich ihrer Abhängigkeiten untereinander als auch bei der Modellierung des Systems und der Erstellung und Durchführung von Testfällen (Bild 3).

Bild 3. Nachverfolgbarkeit der Anforderungen für Software-Architektur und Testfälle.

© Mathworks

Für die Verifikation finden sich in Tabelle A.5 des Standards IEC 61508-3 Empfehlungen zu Softwaremodultests. Neben der Nachverfolgbarkeit empfiehlt diese Tabelle Methoden wie funktionale Tests, Black-Box-Tests, modellbasierte Tests und Schnittstellentests unter Verwendung von Testverwaltungs- und Testautomatisierungswerkzeugen. Für die Softwareverifikation ist zusätzlich die Animation von Spezifikation und Design sehr hilfreich (Tabelle A.9 in IEC 61508-3).

Modellierung, Simulation und Tests

Eine integrierte Umgebung zur Erstellung, Verwaltung und automatisierten Ausführung von Tests bietet für Entwickler viele Vorteile für die Verifikation von Software – hinsichtlich Verständlichkeit und Effizienz. Alle Elemente und Module des Systems lassen sich animieren, zum Beispiel die Zustandsautomaten im Rahmen des Debuggings oder spezifizierte Sequenzdiagramme zur Prüfung der Spezifikationen. Darüber hinaus ist die formale Verifikation des Systems gemäß Tabellen A.5 und A.9 des Standards IEC 61508-3 möglich. Diese erfolgt mit semiformalen Anforderungsspezifikationen und kann innerhalb der Simulink-Umgebung mit dem ‚Simulink Design Verifier‘ durchgeführt werden; dieser übernimmt auch die statische Analyse auf Modellebene (Tabelle A.9 der IEC 61508-3).

Der Prozess für die Definition von Anforderungen und deren Verfeinerung sowie Modellierung, Simulation und Testdurchführung wurden bislang noch nicht betrachtet. Aus dem Fundus agiler Methoden des SAFe-Rahmenwerks wird ein möglicher Workflow für das Vorgehen im Rahmen von Model-Based Design vorgestellt.

Verhaltensgetriebene Entwicklung (BDD)

Anforderungsermittlung ist Teamarbeit und liegt n der Verantwortung mehrerer Rollen. Erst die Anforderungsermittlung führt zu einem klaren Verständnis darüber, was und warum etwas getan werden muss und wann es gut genug sein wird. Dies ist ein iterativer Prozess, der erfordert, sich diverse Anwendungsfälle des Endnutzers vor Augen zu führen, den Kunden einzubeziehen und in kurzen Zeitabständen funktionierende Prototypen zu demonstrieren.

SAFe ist ein Framework für agile Softwareentwicklung, das in verschiedenen Branchen genutzt wird. Laut SAFe ist „Behavior-Driven Development (BDD) eine Test-First-, Agile-Testing-Praxis, die eingebaute Qualität bietet, indem Tests definiert (und potenziell automatisiert) werden, bevor oder als Teil der Spezifizierung des Systemverhaltens. BDD ist ein kollaborativer Prozess, der ein gemeinsames Verständnis der Anforderungen [..] schafft.“ Der Fokus liegt dabei auf der korrekten Erfassung der Anforderungen und dem iterativen Abgleich der Anforderungen mit dem Design. Die Kombination von BDD mit den Fähigkeiten zur Systemsimulation von Model-Based Design erlaubt es, sehr früh virtuelle Prototypen zu erstellen und das Systemverhalten aus der Sicht des Endbenutzers zu erforschen. BDD erfordert die Modellierung der Funktionalität des Systems sowohl in Bezug auf den Controller (Software) als auch die Anlage (Nicht-Software) und deren gemeinsame Simulation, um das vollständige Verhalten des Systems zu verstehen.

Testgetriebene Entwicklung (TDD)

Auf Komponentenebene existiert der Ansatz der testgetriebenen Entwicklung (Test-Driven Development), welcher typischerweise eine Softwarekomponente oder Unit isoliert und mit möglichst vollständiger struktureller Abdeckung testet. Auf dieser Ebene ist ebenfalls das automatisierte Testen von formalisierten Anforderungen zentral. So werden zuerst die Komponententests spezifiziert und automatisiert ausführbar eingerichtet – erst anschließend wird die Implementierung begonnen. Somit kann der Entwickler jederzeit automatisiert überprüfen, ob die Komponente bereits die spezifizierten Anforderungen erfüllt.

BDD und TDD mit Model-Based Design

Bild 4. Vereinfachtes Aktivitätsdiagramm von BDD und TDD im Model-Based Design Entwicklungsprozess, mit dem System Composer modelliert.

© Mathworks

In Bild 4 ist ein möglicher Gesamtprozess von Anforderungsdefinition bis zur fertigen Software in Entwurf und Test dargestellt. Nachdem Systemanforderungen und Systemarchitektur definiert wurden (Phase A und B) beginnt das Schreiben von Testfällen auf Systemebene einschließlich des Aufsetzens einer Testumgebung, die Test jederzeit automatisiert wiederholen kann (Phase C). Es gibt zu diesem Zeitpunkt noch keine Verhaltensmodellierung der Komponenten der Architektur. Typischerweise deckt dieser Schritt Inkonsistenzen, fehlende Anforderungen oder Unzulänglichkeiten in der Architektur auf, sodass von Phase C wieder über die Phasen A und B iteriert werden muss.

Nach Erstellung der Systemtests wird auf die Komponentenebene gewechselt, wo nun parallel für alle Komponenten mit TDD erneut der Test-first-Ansatz umgesetzt wird: Die Erstellung automatisiert ausführbarer Tests für die jeweilige Komponente noch vor dem Entwurf des Komponentenverhaltens (Phase D).

Erst dann wird das Komponentenverhalten entwickelt – bis die angelegten Testfälle funktionieren (Phase E). Weitere Optimierungen oder Code Generierung erfolgen später.

Sind alle Komponenten modelliert, wird wieder auf die Systemebene gewechselt, wo die fertig integrierten Komponenten nun das Gesamtverhalten definieren und die Systemtests aus Phase C einfach wiederholt werden können (Phase F). Bereits hier kann das System auch den Stakeholdern vorgeführt werden, um das gegenseitige Verständnis weiter abzusichern – unterstützt durch eine visuelle Systemanimation (Bild 5), wie im Standard IEC 61508-3 in Tabelle B.3 erwähnt. Hierdurch wird frühestmöglich ein hohes Vertrauen in die Anforderungsdefinition, der Systemarchitektur und den Komponentenbeschreibungen erreicht. Nachdem Phase F abgeschlossen wurde, kann das Vertrauen in den Systementwurf weiter erhöht werden, indem der Softwareteil des Systems mit realer Hardware mittels Rapid Prototyping getestet wird (Phase G).

Nun erst, nachdem die Systemfunktion und das Systemzusammenwirken abgesichert sind, wird in Phase H die Finalisierung der Komponenten bezüglich der Optimierung des Algorithmus, Sicherstellung der Modellqualität und schließlich der Code Generierung umgesetzt. Es werden nun vollständige Komponententests mit dem Ziel einer hohen Testabdeckung durchgeführt, die im Standard IEC 61508-3 in Tabelle B.2 gefordert sind. Zum Abschluss werden in den Phasen I und J das Systemverhalten im Software-in-the-Loop und Hardware-in-the-Loop Test final überprüft.

IEC 61508 und Testen mit agilen Methoden

Bild 5. Systemsimulation und -test mit Animation.

© Mathworks

Sicherheitsanalysen mit Fehlermodellierung und Simulation, semi-formale und formale Spezifikationsmethoden und Verhaltens- und testgetriebene Entwicklung lassen sich direkt in Model-Based Design umsetzen. Ein entscheidender Vorteil ist die frühzeitige Simulation des Gesamtsystems kombiniert mit den Möglichkeiten zur Automatisierung. Damit lässt sich auf einfache Weise eine virtuelle Inbetriebnahme realisieren.

Insbesondere der Einsatz agiler Test- und Entwicklungsmethoden mit automatisch auswertbaren semi-formalen Requirements-Definitionen tragen zur Qualitätssteigerung und Beschleunigung des Entwicklungsprozesses bei. Dadurch können frühestmöglich hohes Vertrauen in das Systemdesign erreicht und spätere kostspielige Korrekturen reduziert werden.

Die Autoren: Dr. Marc Segelken Principal Application Engineer bei Mathworks.
Jens Lerche ist Senior Application Engineer bei Mathworks.