Safety Engineering Besser entwickeln mit modellbasiertem Safety Engineering

Autor / Redakteur: Dr. Daniel Schneider* / Jan Vollmuth

Modellbasierte Entwicklung bietet viele Vorteile wie verbesserte Wartbarkeit, Wiederverwendbarkeit, Qualität und der Effizienz. Auch für das Safety Engineering ist die Adressierung dieser Aspekte durch die Einführung von modellbasierten Ansätzen möglich, wie diese Artikelserie zeigt. (Teil 1/4).

Firmen zum Thema

(Bild: gemeinfrei / Pixabay )

Bei der Entwicklung sicherheitskritischer Systeme ist die Gewährleistung der funktionalen Sicherheit (Safety) unabdingbar. Zu diesem Zweck müssen entlang der Vorgaben einschlägiger Standards (z.B. ISO 12100, IEC 61508, ISO 13849, EN 50128, ISO 26262, ISO 25119) unterschiedliche Analysen und Entwicklungsartefakte erstellt werden. Zu nennen sind in dieser Hinsicht insbesondere Gefahren- und Risikoanalysen, Safety-Analysen, Safety-Anforderungen, Sicherheitskonzepte und Sicherheitsnachweise.

Steigende Komplexität der Systeme setzt Grenzen

Traditionelles Safety Engineering im Überblick.
Traditionelles Safety Engineering im Überblick.
(Bild: Fraunhofer IESE / Daniel Schneider)

In der Praxis werden diese Artefakte aktuell meist mit Dokumentenverarbeitungs- und Tabellenkalkulationswerkzeugen wie Microsoft Word, Excel oder Visio erstellt und verwaltet. Bei immer weiter steigender Komplexität der Systeme stößt man hier jedoch an Grenzen, da wichtige Eigenschaften wie Wartbarkeit, Nachvollziehbarkeit und Nachverfolgbarkeit nicht adäquat gewährleistet werden können. Letztlich resultiert dies in Problemen bezüglich Effizienz und Qualität der Entwicklungsartefakte und folglich auch des gesamten Systems, was im günstigsten Fall lediglich Geld kostet und im schlimmsten Fall Menschenleben.

Ergänzendes zum Thema
Modellbasiertes Safety Engineering – die Serie

Von den Vorteilen der modellbasierten Entwicklung kann auch das Safety Engineering profitieren, wie diese vierteilige Serie zeigen will. Nach einer allgemeinen Einführung im ersten Artikel zeigt der Autor in den folgenden Beiträgen dieser Serie entlang des Safety Engineering Lebenszyklus exemplarisch, wie typische Aktivitäten des Safety Engineering modellbasiert umgesetzt werden können.

Im zweiten Artikel wird es entsprechend darum gehen, die Gefährdungen und Risiken eines zu entwickelnden Systems zu analysieren und wie dies in einen modellbasierten Ansatz integriert werden kann.

Aufbauend darauf wird im dritten Artikel beschrieben, wie sich die Safety-Analyse bezüglich der zuvor identifizierten Gefährdungen mit Hilfe des modellbasierten Ansatzes und Komponentenfehlerbäumen realisieren lässt.

Abschließend wird im vierten Artikel gezeigt, wie ein modellbasierter Sicherheitsnachweis mit den benötigten Verknüpfungen der Entwicklungsartefakte erstellt werden kann.

Dieses Problem ist nicht ausschließlich auf das Safety Engineering beschränkt, sondern gilt für die Systementwicklung im Allgemeinen. Als mögliche Lösung hat sich hier über die letzten 20 Jahre der Ansatz der modellbasierten Entwicklung etabliert. Es gibt mittlerweile ein umfangreiches und erprobtes Angebot an Techniken (z.B. SysML1 und UML2 für die System- und Softwaremodellierung), Methoden (z.B. das V-Modell 97/XT) und Werkzeuge (insb. CASE Werkzeuge3).

Modellbasierte Entwicklung bietet viele Vorteile

Die Vorteile der modellbasierten Entwicklung sind vielfältig, liegen aber insbesondere in einer Verbesserung der Wartbarkeit, Wiederverwendbarkeit, Qualität und, ganz allgemein, der Effizienz. Auch für das Safety Engineering ist die Adressierung dieser Aspekte durch die Einführung von modellbasierten Ansätzen möglich, ein kurzer Überblick dazu soll im Rahmen dieser Artikelserie gegeben werden. Nach dieser allgemeinen Einführung werden nach und nach anhand eines kleinen Fallbeispiels die typischen Schritte in einem modellbasierten Safety Engineering Lifecycle vorgestellt.

In der Praxis ist es oftmals ein Problem über die Entwicklung und spätere Weiterentwicklung von Systemen hinweg alle Dokumentationen und Spezifikationen stets aktuell und konsistent zu halten. Komplexe Versionierung kann das nochmals deutlich erschweren. Generell gibt es bei Änderungen (entsprechend auch bei Versionen/Konfigurationen) in einem System oftmals komplexe Abhängigkeiten und Querbezüge, welche allein auf Basis von textbasierten Spezifikationen schwer zu erkennen und zu verwalten sind. Insbesondere bezüglich des Safety Engineerings kann dies sehr problematisch sein und hinsichtlich Safety die Konfidenz in ein Produkt negativ beeinträchtigen. So kann bspw. das Aufarbeiten erst spät erkannter Änderungen kostspielig sein und zu unsicheren Systemen führen. Des Weiteren können häufigen Änderungen im Safety Engineering nicht adäquat berücksichtig werden, was zu Abweichungen zwischen dem entwickelten System und dessen Spezifikationen führen und demzufolge ein erhebliches Sicherheitsrisiko darstellen kann.

Änderungen werden überall sichtbar

Ein modellbasierter Ansatz kann hier Abhilfe schaffen, indem Elemente zwischen den unterschiedlichen Analysen und Spezifikationen formal verknüpft werden. Ändert man an einer Stelle etwas, können alle relevanten Querbezüge direkt ersichtlich gemacht oder auch Änderungen automatisch durch die Spezifikationen durchpropagiert werden.

Modellbasiertes Safety Engineering im Überblick.
Modellbasiertes Safety Engineering im Überblick.
(Bild: Fraunhofer IESE / Daniel Schneider)

Modellbasiertes Safety Engineering erfolgreich einzuführen bedarf natürlich einer passenden Unternehmenskultur und einer nahtlosen Integration in existierende Vorgehensweisen und Prozesse. Ferner ist eine adäquate Werkzeugunterstützung entscheidend, denn nur dadurch lassen sich die Vorteile modellbasierter Ansätze voll ausschöpfen. Folglich müssen immer sowohl die Implikationen bezüglich der existierenden Vorgehensweisen und Prozesse als auch die Implikationen bezüglich der existierenden Werkzeugketten berücksichtigt werden.

Seminartipp

Das Seminar „Risikobeurteilung und Betriebsanleitung“ hilft bei der Umsetzung der wichtigsten Anforderungen der Maschinenrichtlinie 2006/42/EG.

So oder so bedeutet die Einführung modellbasierter Ansätze eine Investition. Die eventuell nötige Anpassung von Vorgehensweisen und Strukturen, die Beschaffung und Einbindung von Werkzeugen, die Qualifizierung des Personals und vielleicht sogar das Nachziehen von bestehenden Entwicklungsartefakten – all das kann sich schnell zu einer signifikanten Investition aufsummieren. Abzuwägen ist diese Investition gegenüber den erwarteten Einsparungen bezüglich gesteigerter Effizienz, dem Mehrwert einer gesteigerten Qualität und der idealerweise höheren Konfidenz bezüglich der Gewährleistung der Safety.

Erfolgsfaktor Commitment

In einer schönen und umfassenden Studie des Systems Engineering Research Centers (SERC)4 wurden bezüglich einer erfolgreichen Einführung modellbasierter Ansätze die Unternehmenskultur und die (MBSE-)Kenntnisse der Mitarbeiter als größte Hinderungsgründe genannt. Die wesentlichsten positiven Faktoren waren:

  • der Wille der Mitarbeiter die Ansätze einzusetzen, und
  • das Commitment des Managements.

Zusammenfassend ist es demnach hochgradig von den jeweiligen Gegebenheiten und insbesondere den Mitarbeiter eines Unternehmens abhängig, ob die Einführung modellbasierter Ansätze Sinn macht und sich lohnt - oder eher nicht. Tendenziell ist es aber bei immer komplexer werdenden Systemen zunehmend wichtiger die Ingenieure optimal in ihren Aufgaben zu unterstützen.

Gefahren- und Risiken bei der Einführung modellbasierter Ansätze

Die Einführung modellbasierter Ansätze im Allgemeinen, und von modellbasiertem Safety Engineering im Besonderen, ist natürlich trotzdem nicht immer und nicht für jeden sinnvoll. Abgesehen von Abwägungen bezüglich des „Return on Investment“ gibt es einige grundsätzliche Probleme, welche sich über die Jahre bei der Einführung modellbasierter Ansätze gezeigt haben.

Ein Problem ist hier die unzureichende Homogenität von Ansätzen. Trotz standardisierender Spezifikationen, wie es sie zum Beispiel von der OMG für UML und SysML gibt, oder safety-spezifisch bezüglich Safety and Reliability5 und bezüglich Assurance Cases6, tendieren viele Anwender und Unternehmen dazu Methoden und Werkzeuge spezifisch für ihren Kontext anzupassen. Zudem sind auch die Interpretationen der Hersteller solcher Werkzeuge durchaus etwas unterschiedlich. Beides hat einerseits den Vorteil der Individualisierung und Maßschneiderung, andererseits aber Nachteile bezüglich Austauschbarkeit und Zusammenarbeit, etwa entlang der Supply-Chain.

Unrealistische Erwartungen vermeiden

Ein weiteres Problem sind unrealistische Erwartungen, zu welchen es gerade in der Hype-Phase der modellbasierten Entwicklung häufiger gekommen ist. Dieser Hype ist nun seit längerem abgeklungen und leider hat sich teilweise auch Ernüchterung eingestellt. Zu guten Teilen kann diese Ernüchterung aber sicherlich auf die anfangs zu hohen Erwartungen und auch eine zu naive Herangehensweise zurückgeführt werden. Ungünstig ist hier insbesondere, wenn unter den Mitarbeitern eine negative Grundeinstellung bezüglich modellbasierter Ansätze herrscht. Wie in der oben referenzierten Studie des SERC aufgeführt ist dies ein ganz wesentlicher Hinderungsgrund.

Ein letztes und sehr safety-spezifisches Problem ist die Integrität der Werkzeuge selbst und das Vertrauen, welches in ihre korrekte Funktionsweise gelegt werden kann. In jedem Fall muss ausgeschlossen werden, dass etwaige Fehlfunktionen des Entwicklungswerkzeugs zu einem Safety-Problem im zu entwickelnden System führen können.

Integrität der Werkzeuge sicherstellen

Ein allgemeines Vorgehen diesbezüglich (welches so oder so ähnlich auch von Safety Standards wie der ISO 26262 vorgeschlagen wird) lässt sich in die folgenden Schritte gliedern:

  • Wo und wie wird das Werkzeug in der Entwicklung verwendet? Was sind die relevanten Prozesse?
  • Welche konkrete technische Anwendungsfälle gibt es bezüglich des Werkzeugs?
  • Welche Werkzeugfehler sind vorstellbar und wie wirkt sich jeder dieser Fehler in jedem der Anwendungsfälle aus?
  • Was ist die jeweils mögliche Auswirkung auf die Sicherheit des zu entwickelnden Systems?
  • Wie hoch ist die Wahrscheinlichkeit diese Auswirkung (auf Basis der bestehenden Prozesse, Reviews, sonstige Maßnahmen) zu entdecken?
  • Falls es relevante Auswirkungen gibt, die nicht mit einer sehr hohen Wahrscheinlichkeit entdeckt werden, muss entweder das Werkzeug qualifiziert sein, oder es müssen die umramenden Prozesse und Maßnahmen verbessert werden, um die Entdeckung zu gewährleisten.

Diese Betrachtungen sind natürlich nicht nur für Werkzeuge der modellbasierten Entwicklung relevant, sondern eigentlich für jegliche verwendeten Werkzeuge bis hin zu Microsoft Word und Excel.

Unter dem Strich

Zunehmende Komplexität von Systemen, große Mengen an Varianten und häufige Änderungen bringen das Safety Engineering basierend auf Microsoft Word, Excel und Visio an seine Grenzen. Abhilfe schaffen modellbasierte Ansätze, welche idealerweise mit einer modellbasierten Systementwicklung integriert sind. Generell bedeutet deren Einführung aber zunächst einmal zusätzlichen Aufwand und Investitionen und will daher sorgfältig geplant sein. Letztlich ist das Potential für Einsparungen und bessere Qualität aber in vielen Fällen hoch.

Quellen:

1 http://www.omgsysml.org
2 https://www.omg.org/spec/UML/About-UML
3 https://de.wikipedia.org/wiki/Computer-aided_software_engineering
4 https://sercuarc.org/wp-content/uploads/2020/03/SERC-SR-2020-001-Benchmarking-the-Benefits-and-Current-Maturity-of-MBSE-3-2020.pdf
5 https://elib.dlr.de/129753/1/2019%20-%20Biggs%2CG%20-%20OMG%20standard%20for%20integrating%20safety%20and%20reliability.pdf
6 https://www.omg.org/spec/SACM/About-SACM/

* Dr. Daniel Schneider, Department Head Embedded Systems Quality Assurance, Fraunhofer IESE

(ID:47027927)