Safety Engineering Besser entwickeln mit modellbasiertem Safety Engineering
Anbieter zum Thema
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 dieser Beitrag zeigt.

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
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.
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 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.
So oder so bedeutet die Einführung modellbasierter Ansätze eine Investition.
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.
:quality(80)/images.vogel.de/vogelonline/bdb/1709300/1709361/original.jpg)
Podcast Maschinensicherheit
Was ist eigentlich Maschinensicherheit?
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.
:quality(80)/p7i.vogel.de/wcms/d4/20/d42094fb27d7e79bb0dfe4e17e300162/93244515.jpeg)
Risikobeurteilung
Die Risikobeurteilung als Schnittstelle verstehen
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.-Ing. Daniel Schneider, Department Head Safety Engineering, Fraunhofer-Institut für Experimentelles Software IESE
(ID:47027927)