Bringing formal methods “on the rail

 Bringing formal methods “on the rail” Modellbasierte Systemanalyse in der
Sicherheitsnachweisführung
Ein Prozess zur Vereinfachung des formalen Sicherheitsnachweises mithilfe
werkzeuggestützter Analysen am Beispiel der Punktförmigen
Zugbeeinflussung
Prof. Dr. Frank Ortmeier ([email protected]) Institutsleiter, Institut für Software Engineering, Fakultät für Informatik, Otto­von­Guericke Universität Magdeburg Dipl. Ing. Mario Fietze ([email protected]) Technischer Regierungsrat, Eisenbahn­Bundesamt Dipl. Ing. Rolf Schumacher ([email protected]) EBA zertifizierter Gutachter Marco Filax, M.Sc. ([email protected]) wissenschaftlicher Mitarbeiter, Institut für Software Engineering, Fakultät für Informatik, Otto­von­Guericke Universität Tim Gonschorek, M.Sc. ([email protected]) wissenschaftlicher Mitarbeiter, Institut für Software Engineering, Fakultät für Informatik, Otto­von­Guericke Universität Tanja Hebecker, M. Sc. ([email protected]) wissenschaftlicher Mitarbeiter, Institut für Software Engineering, Fakultät für Informatik, Otto­von­Guericke Universität Dr. Agnes Madalinski ([email protected]) Projektleiter VIP­MoBaSA, Institut für Software Engineering, Fakultät für Informatik, Otto­von­Guericke Universität Dipl. Ing. Michael Lipaczewski ([email protected]) wissenschaftlicher Mitarbeiter, Institut für Software Engineering, Fakultät für Informatik, Otto­von­Guericke Universität Sicherheit ist eine zentrale Anforderung an fast alle technischen Systeme. Diese ist im Besonderen bereits beim Systementwurf zu berücksichtigen und nachzuweisen. Je nach Anwendungsdomäne schreiben unterschiedliche Normen Art und Umfang der Nachweisführung vor. Domänenübergreifend werden, speziell für höhere Sicherheitsintegritätslevel (SIL1), formale Methoden empfohlen. Darüber hinaus kann der Einsatz formaler Methoden die Qualität der Sicherheitsanalyse signifikant erhöhen sowie manuell erstellte Ergebnisse objektivieren. Nach EN50129 müssen für alle Teilsysteme im Eisenbahnsektor Qualitäts­ und Sicherheitsmanagement sowie funktionale und technische Sicherheit nachgewiesen werden. Die Dokumentation dieser Nachweise, auch als Sicherheitsnachweis bezeichnet, ist ein entscheidender Teil der gesamten Nachweisdokumentation, die der zuständigen Sicherheitsbehörde für die Erteilung einer Zulassung vorzulegen ist. Der Teil des Sicherheitsnachweises, welcher die Erfüllung aller geforderten Funktionen im ausfallfreiem Zustand bescheinigt, wird auch als technischer Sicherheitsbericht bezeichnet. Der technische Sicherheitsbericht ist für SIL eins bis vier verbindlich. Für Systeme der Sicherheitslevel drei und vier empfiehlt die Norm [EN50129 Tab. E2] für die Systemspezifikation explizit eine hierarchische Trennung mithilfe formaler Methoden. Dennoch werden formale Methoden heutzutage selten eingesetzt, wofür folgende ursächliche Faktoren beobachtet werden können: Einerseits bringen formale Methoden oft hohe Einstiegshürden mit sich. Dies liegt an der Vielzahl verfügbarer Methoden, Modellierungssprachen und Verifikationsprogramme sowie dem oft notwendigen sehr spezifischen Expertenwissen zur Anwendung dieser Verfahren und den meist fehlenden standardisierten Prozessen zu ihrer Anwendung. Andererseits stehen formale Methoden in dem Ruf, mit steigender Komplexität des untersuchten Systems schnell an ihre Grenzen zu stoßen. Selbst wenn diese beiden Probleme gelöst sind, bleibt die Frage nach der Verlässlichkeit der für die Analysen verwendeten formalen Modelle. Es muss gezeigt werden, dass das formale Modell das Verhalten des realen Systems ausreichend abbildet, um für die Sicherheitsanalyse verwendbar zu sein. Formale Verifikation von Systemanforderungsspezifikationen
Um den ​
Einsatz formaler Methoden in der Entwicklung sicherheitsrelevanter Systeme zu vereinfachen, wurden innerhalb des VIP­MoBaSa2 Projektes in den letzten 3 Jahren konkrete Lösungen ­ gemeinsam durch die Otto­von­Guericke­Universität Magdeburg (OvGU), das Eisenbahn­Bundesamt (EBA) und einen unabhängigen vom EBA zertifizierten Gutachter ­ entwickelt und bewertet. Zentrales Ziel dabei war es, Möglichkeiten zu schaffen, formale Methoden im Kontext des Eisenbahnwesens einfacher und effizienter anwendbar zu machen. Als Ergebnis entstand ein Durchführungsprozess für die industrielle Praxis, mit dessen Hilfe sich die modellbasierte Analyse in bestehende Entwicklungsabläufe besser integrieren lässt. Um die Umsetzung dieses Prozesses zu unterstützen, wurde außerdem ein bedienerfreundliches Spezifikationswerkzeug (VECS3)​
​
[1]​
entwickelt. 1 ​
engl Safety Integrity Level Validierung des Innovationspotenzials: Modellbasierte Sicherheitsanalyse 3 ​
engl. Verification Environment for Critical Systems 2 ​
2 Die praktische Anwendung des vorgeschlagenen Prozesses wurde anhand der Punktförmigen Zugbeeinflussung (PZB) validiert. In diesem Zusammenhang wurde die Systemanforderungsspezifikation (SRS4) einschließlich der dazugehörigen Sicherheitsanforderungen vom EBA bereitgestellt. Eine detailliertere Beschreibung der Fallstudie ist unter​
​
[2]​
zu finden. Der im Rahmen des VIP­MoBaSa Projektes entwickelte Prozess gliedert sich in drei Phasen: Informelle Phase, Semi­Formale Phase und die Formale Phase. Diese Segmentierung erlaubt es, die vollständige Nachvollziehbarkeit der geschaffen Teil­ und Endergebnisse über den gesamten Prozess zu gewährleisten. Die notwendigen Prozessschritte sind in Abbildung 1 dargestellt. Der Prozess wurde gemeinsam mit dem Gutachter so entwickelt und definiert, dass sich daraus möglichst vollständige und nachvollziehbare Sicherheitsnachweise erstellen lassen. Abbildung 1: Schematische Darstellung der im Verifikationsprozess notwendigen Aufgaben Informelle Phase: Klassifikation von Requirements
Arbeitsgrundlage für die informelle Phase ist die Systemanforderungsspezifikation. Ziel dieser Phase ist die Aufbereitung der Anforderungsdokumente für eine teil­automatisierte Weiterverarbeitung. ​
Um die Spezifikationen nachvollziehbar in ein formales Modell zu überführen, wird die natürlichsprachliche Systemanforderungsspezifikation mithilfe eines exakt definierten Anforderungsschemas ​
[3]​
,​
[4] ​
klassifiziert. Diese werden automatisiert in ein Anforderungsmanagementwerkzeug (hier IBM DOORS) integriert. In der Fallstudie wurden insgesamt 777 betrachtet und klassifiziert. Semi-Formale Phase: Überführung nach UML
Nach der Klassifikation können alle Anforderungen in die semiformale Phase übertragen werden. Dazu werden alle Anforderungen vollautomatisch in ein UML­Werkzeug (im konkreten Fall Enterprise Architect) übertragen, um die Nachvollziehbarkeit zu gewährleisten. In herkömmlichen Prozessen wird häufig nur die geplante Systemarchitektur modelliert. Dazu werden die in den Anforderungen beschriebenen Systemmodule in Komponenten 4 ​
engl. System Requirement Specification 3 überführt. Diese bestimmen die grundlegende Struktur der Subsysteme. Um zu definieren, welche Informationen Komponenten austauschen können, werden Schnittstellen genutzt. Jede Schnittstelle enthält eine Menge an Methoden mit den jeweiligen Parameter­ und Rückgabedefinitionen. Exemplarisch zeigt Abb. 2 dies für das Fallbeispiel anhand des Indusi Teilsystems. Abbildung 2: Systemübersicht der PZB im semi­formalen Modell Dieses Vorgehen fokussiert aber sehr stark auf den Gesichtspunkt Architektur. Dynamische Abläufe und Verhalten werden in dieser Modellierung oft vernachlässigt und erst durch das Systemdesign bzw. die Umsetzung weiter ausgearbeitet. Dies resultiert oft in hohen Aufwänden zum Sicherstellen der Nachvollziehbarkeit und bringt auch während des Entwicklungsprozesses Risiken mit sich. Deshalb schlägt der Prozess vor, neben der Architektur auch die in den SRS enthaltenen Verhaltensbeschreibungen bereits auf der UML­Ebene zu modellieren ­ selbst wenn diese teils fragmentarisch sind. Um das Verhalten eines Systems zu beschreiben, werden Sequenzdiagramme genutzt. Jede Sequenz stellt dabei eine zeitliche Funktionsabfolge des Systems dar, indem es den Nachrichtenaustausch zwischen Komponenten beschreibt. Die Sequenzen werden genutzt um das formale Modell zu validieren. Ein Beispiel ist in Abbildung 3 dargestellt. Hier ist visualisiert, dass das Überfahren eines aktiven 2000Hz­Magneten eine Zwangsbremsung auslöst und entsprechende Leuchtmelder gesetzt werden müssen. Die Menge der zu extrahierenden Verhaltensbeschreibungen leitet sich dabei aus den entsprechend klassifizierten Anforderungen ab. 4 Abbildung 3: Exemplarische Sequenz zur Darstellung der Zwangsbremsung der PZB Bedingt durch ihre Definition können Sequenzdiagramme das Verhalten nicht vollständig beschreiben, da sie lediglich einen Beispielablauf ­ vergleichbar einem Test ­ darstellen. Aus diesem Grund ist es notwendig, das ganzheitliche Verhalten des mathematisch zu verifizierenden Systems auf eine andere Weise in der formalen Phase zu formalisieren. Die Sequenzen beschreiben dabei das Verhalten, welches durch das formale Systemmodell erfüllt werden muss und können zur Validierung genutzt werden. Diese Aufteilung entspricht im Wesentlichen der Aufteilung Testdefinition und Implementierung. Formale Phase: Vervollständigung des formalen Modells
Die geschaffene semiformale Architektur­ und Verhaltensbeschreibung kann mithilfe der Verifikationsumgebung VECS vollautomatisch formalisiert werden. Dies ermöglicht die Überführung der Architektur in ein Gerüst für das formale Modell, welches sowohl die Komponentenstruktur als auch das Vorhandensein und die Nutzung der Interfaces abbildet. Um die Nachvollziehbarkeit zu gewährleisten, werden die erzeugten Komponenten automatisch mit Links zu den zugrunde liegenden UML­Artefakten und Anforderungen annotiert. Analog zur Implementierung muss dieses Gerüst nun vervollständigt werden, indem das interne Verhalten der Komponenten vollständig und eineindeutig beschrieben wird. Diese Implementierung des formalen Modells ist häufig fehleranfällig ­ wie bei der Programmierung auch ­ und muss deshalb qualitätsgesichert werden. Hier helfen die bereits in UML spezifizierten Abläufe, da diese intendiertes Verhalten beschreiben und ausschließlich auf Komponentenschnittstellen definiert sind, können sie vollautomatisch formalisiert werden. Technisch werden dabei die semi­formalen Sequenzen in Akzeptorautomaten überführt. Ein Akzeptorautomat zählt dafür die einzelnen Zustände, die genau dann erreicht werden, wenn die in der Sequenz vorgegebene Nachricht von einer Schnittstelle gesendet bzw. empfangen wird. Durch einen Modellprüfer kann anschließend 5 voll­automatisch verifiziert werden, ob das geschaffene Modell den generierten Verhaltensbeschreibungen entspricht. Dabei wird für jede Sequenz ein beispielhafter Ablauf des Modells generiert, der diese erfüllt. Dieses Vorgehen erlaubt eine sehr intuitive und nachvollziehbare Validierung des Modells. Werden einzelne Abläufe nicht erfüllt, kann das mehrere Gründe haben. So kann das Modell fehlerhaft sein. Dies bedeutet einen Fehler/Irrtum des Modellierers, der natürlich korrigiert werden muss. Andererseits kann aber auch die Abbildung der informellen, textuellen Anforderung in eine Sequenz auf einem Missverständnis beruhen. In diesem Fall ist die Formalisierung in UML anzupassen. In jedem Fall ist natürlich ein dokumentierter, nachvollziehbarer Change­Management­Prozess notwendig. Der zentrale Nutzen liegt aber in dem frühen Aufdecken solcher Fehler und Missverständnisse, da zwei vollkommen unterschiedlichen Spezifikationssichten eingenommen werden. Im Rahmen der PZB Fallstudie wurden insgesamt 36 Sequenzen durch Domainenexperten beispielhaft modelliert und in Akzeptorautomaten überführt. Um die Konsistenz zwischen semi­formaler und formaler Ebene zu zeigen wurden über 400 Testläufe durchgeführt. Dabei konnten kleinste Fehler innerhalb des formalen Modells behoben werden. Allerdings konnten so auch Inkonsistenzen auf semi­formaler Ebene aufgedeckt und behoben werden. Nachdem alle Fehler gefunden und behoben sind, lässt sich dadurch auf die Korrektheit des formalen Modells schließen. Verwendung der formalen Modelle im Entwurfsprozess
Nachdem die Übereinstimmung des formalen und des semi­formalen Modells überprüft worden ist, kann dieses für eine ganze Reihe verschiedener Ziele verwendet werden. Zum einen ist die formale Verifikation gewünschter funktionaler (Sicherheits­)Anforderungen mit einem Modellprüfer möglich. Ein anderer Ansatz ist durch Fehlerinjektion Fault Tree (FTA) und Failure Mode and Effects (FMEA) Analysen formal zu erstellen bzw. mit den manuell erstellten Ergebnissen abzugleichen. Werden quantitative Aspekte wie Ausfallwahrscheinlichkeiten oder Nutzungsraten mit modelliert, können konkrete Aussagen über Fehlerwahrscheinlichkeiten berechnet werden. Auch ist eine Verwendung zur Testfallgenerierung und Testdatengenerierung möglich. Schließlich können die formalen, ausführbaren Modelle auch als äußerst präzise Spezifikation für die Implementierung verwendet werden. Der Weg der automatischen Code­Generierung ist theoretisch möglich, jedoch stellt sich in der Praxis immer wieder die Frage nach einem zertifizierten Code­Generator, sodass diese Verwendungsmöglichkeit eher mittelfristig möglich ist. Technischer Hintergrund
Sämtliche Modelltransformationen und ­generatoren sind als Plug­In in die Eclipse­Toolsuite integriert. Für die Verifikation ermöglicht VECS die Nutzung einer Vielzahl von Modellprüfern. Für das Beispielsystem wurde die Verifikation mit nuXmv5 unter Verwendung des IC3­Algorithmus ​
[6] durchgeführt. Dieser Modellprüfer stellt für die Verifikation die gebräuchlichsten Methoden, basierend auf Binary­Decision­Diagrams oder SAT­Abstraktionen, zur Verfügung. Die Umwandlung des formalen Modells in die Eingabesprache von nuXmv erfolgt durch exakt spezifizierte Transformationsregeln [5]​
. 5 ​
https://nuxmv.fbk.eu/ 6 Abbildung 4 zeigt einen Screenshot des Werkzeugs aus der PZB­Fallstudie. Links wird immer ein Überblick über alle im Modell enthaltenen Subsysteme/Komponenten dargestellt. Im zentralen Bereich bietet ein kontextsensitiver Editor mit Syntax Highlighting und Autovervollständigung effiziente Unterstützung bei der Modellerstellung. Im unteren Bereich befinden sich Ausgaben für Debugging oder Simulation des Modells. Abbildung 4: Ausschnitt des formalen Modells der PZB innerhalb von VECS In der Fallstudie wurden aus dem Spezifikationsdokument insgesamt 34 Sicherheitsanforderungen extrahiert, die ein Verhalten beschrieben, welches in der Fallstudie erklärt wurde. Im Voraus wurden 11 Sicherheitsanforderungen als nicht prüfbar befunden, da ihre Funktionalitäten aufgrund von fehlenden Beschreibungen in der Fallstudie nicht modelliert werden konnten. Tests zeigten Fehler in weiteren 10 Sicherheitsanforderungen, die auf Unvollständigkeiten in den Sicherheitsanforderungen beruhten. Nach einer entsprechenden Anpassung lieferten 22 der 23 Sicherheitsanforderungen innerhalb von 3 bis 796 Sekunden ein positives Ergebnis. Die Sicherheitsanforderung “​
Immer wenn der Hauptschalter aus ist, oder eine Zwangsbremsung vorliegt, müssen die Leuchtmelder PZB, Üf85, Üf70 ​
und Üf55 ​
des MMI dunkel sein.​
” zeigte bei der Überprüfung durch den Modelchecker dennoch ein Gegenbeispiel. Nachdem die verwendeten formalen Elemente zu ihren informellen Ursprüngen in der Systemanforderungsspezifikation zurückverfolgt wurden, stellte sich heraus, dass das Deaktivieren des Leuchtmelders ​
PZB bei einer Zwangsbremsung nicht in den Anforderungen des Fallstudiendokumentes spezifiziert wurde. Somit konnte durch diesen Ansatz Definitionslücken in der Fallstudie gefunden und beseitigt werden. Zusammenfassung und Ausblick
Formale Methoden haben ein sehr großes Potential, um fehlerfreie Systeme zu entwickeln. Sie werden auch in vielen Standards empfohlen oder sogar vorgeschrieben. Trotzdem finden sie in der industriellen Praxis nur bedingt Einsatz. Das liegt primär an der hohen 7 Einstiegshürde und dem erheblichen Mehraufwand. Um diese Probleme zu reduzieren wurde ­ speziell mit Blick auf das Eisenbahnwesen ­ die Toolsuite VECS entwickelt. Ziel von VECS ist eine benutzerfreundliche und vor allem praktisch anwendbare Möglichkeit der Verwendung formaler Methoden in der Produktentwicklung und damit auch der Vereinfachung des späteren Zulassungsprozesses. Um dies zu erreichen wurde eine Integration in andere Standardwerkzeuge geschaffen. Um die zentrale Frage: "Entspricht das formale Modell nachweislich dem, was es vorgibt?" zu beantworten, wurden eine Reihe von Traceability­Methoden integriert. Mit dem hier erprobten Verfahren lassen sich diese beiden Aspekte in einen praktikablen Rahmen projizieren. Durch stufenweise Kombination von informellen­, semi­formalen­ und formalen Methoden wird das Nützliche aus der jeweiligen Sphäre praktisch anwendbar. Die Rückverfolgbarkeit des formalen Modells zu den Anforderungen wird über die semi­formale Darstellung möglich und handhabbar. Produktiv gestaltet sich der Gesamtprozess durch das Werkzeug VECS, das sich auf Standardsoftware stützt. Durch die T2­Einstufung (EN50128) der Werkzeuge kann der Nachweis ihrer Eignung mit vertretbarem Aufwand erbracht werden. Die tatsächliche Einbindung in den Entwicklungsprozess und damit die Vorlage der Ergebnisse einer formalen Prüfung bei der Sicherheitsbehörde kann den Verlauf des Zulassungsverfahrens vereinfachen, da damit entsprechende Nachweise bezüglich der Konsistenz und Vollständigkeit des Systems und der Spezifikation erbracht und gestellte Sicherheitsanforderungen überprüft werden können. Letztlich wird prüfbar belegt, dass Sicherheitsanforderungen eingehalten werden, wenn das zu begutachtende Gerät oder System entsprechend dem formalen Modell, das nachweislich den Anforderungen genügt, realisiert ist. Als einen weitereren Schritt, für die Erprobung der Werkzeuge und des Verfahrens, werden aktuell die Spezifikationen des europäischen Zugsicherungssystems ETCS in UML überführt, um daraus ein formales Modell erstellen zu können; und an diesem dann die Sicherheitsanforderungen für ETCS und die Konsistenz der Spezifikation selbst zu überprüfen. Quellen
1. Gonschorek T, Filax M, Lipaczewski M, Ortmeier F. VECS ­ Verification Enviroment for Critical Systems ­ Tool Supported Formal Modeling an Verification. IMBSA 2014: short & tutorial proceedings of the 4th international symposium on model based safety assessment ­ Magdeburg : Univ. 2014. pp. 63–64. 2. Fallstudienbeschreibung PZB. Available: https://cse.cs.ovgu.de/vecs/index.php/product/achievements/casestudies/pzb 3. Filax M, Gonschorek T, Lipaczewski M, Ortmeier F. On Traceability of Informal Specifications for Model­Based Verification. 4th International Symposium on Model Based Safety Assessment. 2014;4: 11–18. 4. Chiappini A, Cimatti A, Macchi L, Rebollo O, Roveri M, Susi A, et al. Formalization and validation of a subset of the European Train Control System. Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering ­ ICSE ’10. 2010. 8 doi:​
10.1145/1810295.1810312 5. Güdemann M. Qualitative and Quantitative Formal Model­Based Safety Analysis. 2011. 6. Bradley AR. SAT­Based Model Checking without Unrolling. Lecture Notes in Computer Science. 2011. pp. 70–87. Abbildungen 1.
2.
3.
4.
Schematische Darstellung der im Verifikationsprozess notwendigen Aufgaben () Systemübersicht der PZB im semi­formalen Modell () Exemplarische Sequenz zur Darstellung der Zwangsbremsung der PZB () Ausschnitt des formalen Modells der PZB innerhalb von VECS () Abstract
Funktionen sicherheitskritischer Systeme im Eisenbahnsektor werden entsprechend ihrer tolerierbaren Gefährdungsraten in sogenannte Sicherheitsintegritätslevel (SIL 1­4) eingestuft. In der europäischen Norm EN50129 besteht, für die Stufen drei und vier, die dringende Empfehlung, im Entwicklungs­ und Spezifikationsprozess, formale Methoden anzuwenden. Die Otto­von­Guericke­Universität Magdeburg hat dazu, begleitet durch das Eisenbahn­Bundesamt (EBA) und Gutachtern des EBA, einen Satz unterstützender Werkzeuge und Verfahren entwickelt, welche in diesem Artikel, am Beispiel der Punktförmigen Zugbeeinflussung (PZB), vorgestellt werden sollen. Diese Werkzeuge ermöglichen die Portierung einer natürlichsprachlichen Systemanforderungsspezifikation in ein formales Modell, mit dessen Hilfe die Konsistenz und Vollständigkeit der Systembeschreibung, sowie die definierten Sicherheitsanforderungen formal überprüft werden können. Bereits in frühen Entwicklungsphasen können automatisiert qualitative und quantitative Abschätzungen über die Sicherheit und Zuverlässigkeit mit präzisen und aussagekräftigen Resultaten berechnet werden. Gleichzeitig wird der Aufwand zur endgültigen, sicherheitstechnischen Bewertung durch vollständige Traceability als Teil des Zertifizierungs­ und Zulassungsprozesses reduziert. 9