Funktionale Sicherheit ist gar nicht schwer

Funktionale Sicherheit ist überall dort gefordert, wo elektrische oder elektronische Geräte jeden Tag den Menschen helfen, ihr Leben sicherer zu machen und oft zugleich auch angenehmer gestalten.

Meist bemerken wir diese kleinen, unauffälligen Systeme im Alltag erst genau dann, wenn sie ihre Stärke ausspielen und es um kritische Lebenssituationen geht. Sei es das Anti-Blockier-System im Auto, das bei Winterwetter die Lenkbarkeit des Fahrzeugs sicherstellen soll, oder die Airbag-Steuerung. Außerdem gibt es den automatischen Notfallmelder, wenn sich trotz ABS die Regeln der Physik nicht außer Kraft setzen ließen. Im schlimmsten Fall das Beatmungsgerät in der Klinik, das über Jahre vielen Menschen das Leben gerettet hat.

Obwohl diese Systeme meist unscheinbar daherkommen, sind sie zum Teil sehr komplex. Das liegt daran, dass sie eine Vielzahl von Parametern verarbeiten und in vielfältiger Weise mit dem Systemkontext interagieren.

Begriffsdschungel

Was zunächst nach einer herausfordernden, technischen Aufgabe klingt, äußert sich im Projekt oft als wirrer Dschungel der Begriffe und Methoden:

Qualitätsmanagement-Plan, Risikoanalyse, Design Description, Safety Goals, Requirements und Safety-Validierungsplan. Das ist nur ein winziger Ausschnitt aus der Vielzahl der Begriffe. Normen-Dschungel und inkonsistente, oberflächliche Prozesse verwässern zusätzlich den Blick auf das, was eigentlich zu tun ist: ein sicheres System entwerfen und umsetzen.

Zwölf Kursteilnehmer nahmen am Training zum iSAQB Certified Professional for Software Architecture – Advanced Level: Sicherheitskritische Eingebettete Systeme in München teil. Sie stellten sich der Aufgabe, das Begriffsdurcheinander zu lichten sowie Grundlagen und Methodik zur erfolgreichen Umsetzung der funktionalen Sicherheit in Entwicklungsprojekten zu erarbeiten.

In der äußerst heterogenen Gruppe mit Teilnehmern aus vielen verschiedenen Industrien wurde schnell klar, dass trotz unterschiedlichen Hardware-Plattformen, Konventionen, Tools und anzuwendender Normen sehr viele Gemeinsamkeiten bestehen. Im regen Austausch unter den Teilnehmern sind sich bald alle einig: Stets dreht es sich um die Anwendung des Stands der Technik, der sich lediglich in unterschiedlichen Normen manifestiert. Sei es eine ISO 26262, IEC 61508, DIN EN 60601 oder DIN EN 62304.

Mit Methodik zum Ziel

Am ersten Tag wiederholten die Teilnehmer Begriffe wie Systementwicklung, V-Modell und den Zusammenhang zwischen Spezifikation und Test. Anschließend ging es um UML, SysML und deren Zusammenhang mit Code-Artefakten. Danach beschäftigten sie sich mit spezifischeren DSLs, die eine Zwei-Wege-Transformation zwischen Modell und Code erlauben.

Danach haben wir uns der Risiko-Analyse, Fault Tree Analysen, Failure Mode and Effect Analysen sowie den Safety-Integrity-Levels gewidmet. Anhand eines Beispiels in Form eines fiktiven Passanten-Airbags für ein Auto haben die Teilnehmer selbst einmal ausprobiert, wie man diese Themen umsetzt und wie man dies dokumentieren kann.

Der Austausch war intensiv, und die Teilnehmer ließen sich selbst in den Pausen nicht davon abhalten, weiter zu diskutieren. Nach der Mittagspause haben wir architekturelle Lösungsansätze und Einschränkungen nach dem Stand der Technik betrachtet. So empfehlen sie zum Beispiel die ISO 26262 oder IEC 61508. Entsprechend haben wir unser durchgehendes Seminar-Beispiel mehrfach überarbeitet, um es funktional sicher zu machen.

Am dritten Tag haben wir uns die Herausforderungen verteilter Systeme, Scheduling und Echtzeitfähigkeit angeschaut. Dabei betrachteten wir die spezifischen Probleme nebenläufiger Systeme am konkreten Beispiel. Ein kurzer Ausflug in das Variantenmanagement hat den Nachmittag abgeschlossen.

Für mich war es wieder einmal toll, die verschiedenen Branchen und deren Blickwinkel auf das Thema „Funktionale Sicherheit“ zusammenzubringen und Impulse zu streuen. Ich freue mich schon auf meinen nächsten Kurs, und hoffe, dass ich wieder ein so buntes Publikum begrüßen darf.