Autor: Markus Schacher, KnowGravity Inc.<\/p>\n
Die Europ\u00e4ische Norm f\u00fcr den Nachweis der Zuverl\u00e4ssigkeit, Verf\u00fcgbarkeit, Instandhaltbarkeit und Sicherheit von Bahnanwendungen definiert Sicherheit als „Freiheit von f\u00fcr Menschen oder die Umwelt nicht akzeptierbaren Risiken“ und Risiko als die „Kombination aus der erwarteten H\u00e4ufigkeit eines Verlustes und der erwarteten Schwere dieses Verlustes“. Dieser Artikel zeigt auf, wie sich solche Risiko\u00fcberlegungen in Form eines UML-Modells erarbeiten lassen.<\/strong><\/p>\n Der Betrieb einer Eisenbahn birgt schon aufgrund der hohen Zahl der transportierten Passagiere ein inh\u00e4rentes Betriebsrisiko. Sowohl technisches als auch menschliches Versagen kann zu fatalen Unf\u00e4llen f\u00fchren, die hohe Sachsch\u00e4den verursachen oder gar Menschenleben gef\u00e4hrden k\u00f6nnen. Aus diesem Grund hat sich im Bahnumfeld \u00fcber viele Jahrzehnte eine Sicherheitskultur entwickelt, die heute in Form der europ\u00e4ischen CENELEC-Norm [EN50126] niedergeschrieben ist. In dieser Norm sind nicht nur Techniken zur Identifikation und Begrenzung von Risiken beschrieben, sondern es wird auch das grunds\u00e4tzliche Zusammenspiel zwischen Bahnbetreiber dessen Lieferanten geregelt.<\/p>\n Zentrales Konzept ist die Gef\u00e4hrdung: eine Situation, die zu einem Unfall f\u00fchren kann, aber nicht unbedingt muss. Dies kann beispielsweise ein Signal sein, das auf Gr\u00fcn steht, obwohl sich auf dem dahinter liegenden Gleis ein Zug befindet. Eine Gef\u00e4hrdung bezieht sich immer auf einen spezifischen Systemkontext, beispielsweise das Signal sowie dessen dahinter stehende Steuerlogik (Stellwerk) inklusive weiterer Sensoren. Auf dieser Basis lassen sich nun Szenarien analysieren, die zu verschiedenen Unf\u00e4llen f\u00fchren k\u00f6nnten.<\/p>\n Umgekehrt haben Gef\u00e4hrdungen auch immer Ursachen, die aus dem Inneren des Systemkontexts herr\u00fchren: Ein Sensor ist defekt, die Steuerlogik weist unter gewissen Umst\u00e4nden fehlerhaftes Verhalten auf oder das Wartungspersonal hat eine fehlerhafte Konfiguration vorgenommen. Die Anwendung dieser Analysetechnik wird auch als „Fehlerbaumanalyse“ (engl. Fault Tree Analysis, FTA) bezeichnet.<\/p>\n Die Analyse der Folgen einer Gef\u00e4hrdung liegt nach EN50126 haupts\u00e4chlich in der Verantwortlichkeit des Bahnbetreibers: Er muss Zulassungsbeh\u00f6rden und damit der \u00d6ffentlichkeit gegen\u00fcber nachweisen, dass er mit den aus der Gef\u00e4hrdung resultierenden Risiken leben, d.h. mit ihnen umgehen kann. Dies kann er aber nur, wenn die H\u00e4ufigkeit dieser Gef\u00e4hrdungen (die „Gef\u00e4hrdungsrate“) ein gewisses Ma\u00df nicht \u00fcberschreitet. Dem gegen\u00fcber liegt die Verantwortlichkeit f\u00fcr die Analyse der Ursachen einer Gef\u00e4hrdung beim Lieferanten des Systems, welches durch den Systemkontext begrenzt ist. Er muss nachweisen, dass sein System die geforderte Gef\u00e4hrdungsrate unter keinen Umst\u00e4nden \u00fcberschreitet. F\u00fcr den Lieferanten sind also Gef\u00e4hrdungsraten sicherheitsrelevante Anforderungen, die er einhalten muss, um f\u00fcr sein System eine Zulassung zu erhalten (siehe dazu Abbildung 1,\u00a0PDF<\/a>).<\/p>\n Wird eine Risikoanalyse modellbasiert vorgenommen, so werden die wichtigen Konzepte der Risikoanalyse in Form von Modellelementen erfasst und zueinander in Beziehung gesetzt. Die wichtigsten Zusammenh\u00e4nge zwischen diesen Konzepten sind in der folgenden Abbildung (Abb. 2,\u00a0PDF<\/a>) zusammengefasst.<\/p>\n Thematisch l\u00e4sst sich eine modellbasierte Risikoanalyse in drei Bereiche gruppieren:<\/p>\n Eine f\u00fcr den Systembetreiber zentrale Technik ist die „Risikomatrix“. Ein Risiko in der Risikomatrix ist eine m\u00f6gliche Folge (typischerweise ein Unfall), die aus einer Gef\u00e4hrdung resultiert. Dazu werden die erwarteten H\u00e4ufigkeiten der Folgen mit dem erwarteten Schadensausma\u00df multipliziert und in die Risikomatrix eingetragen. Dies erlaubt die Klassifikation von Risiken bez\u00fcglich ihrer H\u00e4ufigkeit (vertikale Achse) und ihrem Schadensausma\u00df (horizontale Achse). Die beiden Achsen werden typischerweise in ein paar wenige sprechende Bereiche unterteilt.<\/p>\n Durch die Quantifizierung der Achsen lassen sich die den Zellen zugeordneten Risiken quantifizieren und deren Akzeptierbarkeit beurteilen (siehe Abbildung 3,\u00a0PDF<\/a>): Mit der Ma\u00dfeinheit „Geld pro Zeiteinheit“ illustrieren diese Zahlen die jeweiligen Risiken sehr deutlich: Dieser Betrag weist ein enormes Spektrum auf und ist jeweils pro angegebener Zeiteinheit durch den Betreiber „auf die Seite zu legen“, um ein Risiko zu decken, welches der jeweiligen Zelle zugeordnet ist.<\/p>\n Typischerweise wird eine Risikomatrix in drei farblich getrennte Bereiche unterteilt:<\/p>\n Das Ergebnis dieses Prozesses wird auch als „Risikoakzeptanz“ bezeichnet, da es die Risikobereitschaft des Systembetreibers deklariert. Werden die einzelnen in der Risikoanalyse untersuchten Risiken in die Risikomatrix eingetragen, so wird dies als „Risikoevaluation“ bezeichnet. Dies zeigt Abbildung 4 (siehe\u00a0PDF<\/a>) anhand dreier Risiken.<\/p>\n In der Abbildung ist jedes Risiko zweimal aufgezeigt, einmal ohne Ber\u00fccksichtigung von Schutzma\u00dfnahmen (hellblau) und einmal mit deren Ber\u00fccksichtigung (dunkelblau). Gegen Risiko 1 ist offenbar eine Schutzma\u00dfnahme zur Reduktion der H\u00e4ufigkeit in Kraft. Demgegen\u00fcber wirkt bei Risiko 2 offenbar eine Schutzma\u00dfnahme zur Reduktion des Schadensausma\u00dfes. Bei Risiko 3 wirken offenbar beide Arten von Schutzma\u00dfnahmen, so dass das Risiko vom inakzeptablen Bereich wenigstens in den ALARP-Bereich zu liegen kommt.<\/p>\n UML-Profiling ist ein Mechanismus, der schon seit \u00fcber 10 Jahren Bestandteil der UML ist. Er erlaubt die Entwicklung dom\u00e4nenspezifischer Modellierungssprachen, die sich dann mit den meisten UML-Werkzeugen nutzen lassen. Ein UML-Profil ist ein spezielles Package, welches sogenannte Stereotypen definiert. Diese lassen sich auf Standard-Elemente der UML (wie Packages, Klassen, Anwendungsf\u00e4lle etc.) anwenden, um damit eine dom\u00e4nenspezifische Bedeutung auszudr\u00fccken. Ein Stereotyp kann zudem spezifische Eigenschaften f\u00fcr diese Modellelemente einf\u00fchren (sogenannte „Tag Definitions“) und sogar ein eigenes Symbol besitzen.<\/p>\n Im Rahmen eines Projektes f\u00fcr die Schweizerischen Bundesbahnen haben wir nun ein UML-Profil f\u00fcr die Modellierung der wichtigen Konzepte aus Abbildung 2 entwickelt. Abbildung 3 (beide Abbildungen siehe\u00a0PDF<\/a>) zeigt einen Ausschnitt dieses Profils. Was in diesem Diagramm auff\u00e4llt ist, dass die Namen vieler Tag-Definitions mit einem Slash („\/“) beginnen. Dies bedeutet, dass die Werte dieser Eigenschaften nicht durch den Modellierer festgelegt m\u00fcssen, sondern durch das UML-Werkzeug automatisch berechnet werden. Dazu sind diesen Eigenschaften entsprechende Formeln aus der Risikoanalyse hinterlegt (siehe Abbildung 5,\u00a0PDF<\/a>).<\/p>\n Abbildung 6 (siehe\u00a0PDF<\/a>) zeigt einen Ausschnitt aus einem vereinfachten Risikomodell f\u00fcr einen fiktiven Bahn\u00fcbergang (die echten Risikomodelle sind wesentlich komplexer). Das Diagramm nutzt das oben eingef\u00fchrte UML-Profil und zeigt sowohl Ursachen (gelb) als auch Gef\u00e4hrdungen (orange), die zu verschiedenen Kollisionen (rot) f\u00fchren k\u00f6nnen. Die Kollisionen zeigen zudem einige der automatisch berechneten Eigenschaften mit und ohne Ber\u00fccksichtigung von Schutzma\u00dfnahmen (gr\u00fcn) und Sicherheitsanforderungen (blau).<\/p>\n Bei der projektspezifischen Ausarbeitung konkreter Risikoanalysen sind aber auch gewisse Schwierigkeiten aufgetreten:<\/p>\n Die Risiken komplexer, heterogener Systeme k\u00f6nnen und m\u00fcssen quantifiziert werden, damit sie nachvollziehbar, akzeptierbar und damit auch vertretbar gemacht werden k\u00f6nnen. Die modellbasierte Risikoanalyse erm\u00f6glicht eine strukturierte Identifikation von Systemrisiken sowie die systematische Ableitung von Gegenma\u00dfnahmen und Sicherheitsanforderungen aus diesen Risiken. Mittels UML-Profiling l\u00e4sst sich eine modellbasierte Risikoanalyse mit einem herk\u00f6mmlichen UML-Werkzeug durchf\u00fchren und bei Bedarf eng mit anderen Modellen verkn\u00fcpfen. Der Autor ist auch in die Weiterentwicklung des UML Testing Profiles [UTP] der OMG f\u00fcr modellbasiertes Testen involviert. Hier ist insbesondere die Integration von Risikoanalysen mit Techniken des risikobasierten Testens von gro\u00dfem Interesse.<\/p>\n [EN50126] [SysML] [UTP] Beitrag als PDF downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema\u00a0Qualit\u00e4t, Safety & Security<\/strong>.<\/p>\n Hier\u00a0<\/a><\/strong>finden Sie au\u00dferdem Schulungen zum Thema Software- und Vertragsrecht.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Qualit\u00e4t, Safety & Securitysteht\u00a0hier\u00a0<\/a><\/strong>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nRisiken im Bahnumfeld<\/h2>\n
Modellbasierte Risikoanalyse<\/h2>\n
\n
Risikoakzeptanz und Risikoevolution<\/h2>\n
\n
Dom\u00e4nenspezifische Modellierungssprachen mittels UML-Profiling<\/h2>\n
Anwendung<\/h2>\n
Erfahrungen im praktischen Einsatz<\/h2>\n
\n
Zusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n
\nCENELEC: Railway applications – The specification and demonstration of Reliability, Availability, Maintainability and Safety (RAMS) – Part 1: Generic RAMS Process, CENELEC – European Committee for Electrotechnical Standardization, WG14, prEN 50126-1, DRAFT, 04-SEP-2012<\/p>\n
\nObject Management Group: OMG Systems Modeling Language (OMG SysML\u2122) \u2013 version 1.3, ptc\/2012-06-01, Juni 2012<\/p>\n
\nObject Management Group: UML Testing Profile (UTP) \u2013 version 1.2, ptc\/2012-09-13, September 2012<\/p>\n
\nUnsere Trainings & Coachings<\/h2>\n
\nQualit\u00e4t, Safety & Security – Fachwissen<\/h2>\n