Datenbank für Anforderungen Projektplanung

Transkript

1 für Anforderungen CENELEC-konformes modellbasiertes Systems Engineering von sicherheitskritischen Bahnsystemen auf Betreiberseite am Beispiel des Systems Leit- und Sicherungstechnik Vortrag zur Rail Automation und in Braunschweig Deutsche Bahn AG, Technik/Beschaffung Randolf Berglehner (TET 2) München, Copyright DBAG, TET 2,

2 Die Bewältigung von aktuellen Herausforderungen für Anforderungen Deutschen Bahn erfordert ein modernes CENELEC-konformes Systems Engineering Aktuelle Herausforderungen der Deutschen Bahn Steigerung der Wettbewerbsfähigkeit des schienengebundenen Personen- und Güterverkehrs Interoperable wirtschaftliche Integration des European Train Control Systems (ETCS) in die nationalen Zugsicherungssysteme Ganzheitlicher Optimierungsansatz zur Bewältigung dieser Herausforderungen *) Ganzheitliche funktionale Verbesserung und wirtschaftliche Optimierung der Leit- und Sicherungstechnik (LST) über den gesamten Lebenszyklus *) durch: Reduzierung der Investitionskosten (durch anforderungsgerechte Produkte) Reduzierung der Betriebskosten (durch höhere Produktivität und verringerte Energiekosten) Reduzierung der Obsoleszenzkosten (durch Modularisierung) Hierzu ist ein optimiertes modernes Systems Engineering erforderlich In dem von der Deutschen Bahn AG in den Jahren 2007 bis 2009 durchgeführten Innovationsprojekt " für Anforderungen" (DAFA) wurden die Grundlagen für ein optimiertes CENELEC-konformes betreiberseitiges Systems Engineering geschaffen. *) Quelle: DB Netz AG, Ganzheitlicher Optimierungsansatz in NeuPro (Neuausrichtung Produktionssteuerung) 2

3 Das System Leit- und Sicherungstechnik für Anforderungen weist in seiner Gesamtheit die Charakteristiken eines System of Systems auf Das System Leit- und Sicherungstechnik (LST), das sich aus einer Vielzahl verketteter, größtenteils sicherheitskritischer Systeme zusammensetzt, weist in seiner Gesamtheit wesentliche Charakteristiken eines System of Systems (SoS) auf. Zielkonformes emergentes Verhalten Unerwünschtes emergentes Verhalten (Seiteneffekte) Schlüssel-Charakteristiken eines SoS Emergenz: Das SoS offenbart in seiner Gesamtheit Eigenschaften, die durch keines der beteiligten Systeme zum Ausdruck kommen. Evolution: Das SoS verändert sich im Laufe der Zeit, wenn Systeme hinzugefügt, entfernt oder ausgetauscht werden. Risiken eines SoS Das SoS wird in seiner Gesamtheit unwirtschaftlicher, wenn Systeme optimiert werden (Emergenz). Die Komplexität des SoS nimmt zu, wenn Systeme hinzugefügt, entfernt oder ersetzt werden. Systeme des SoS müssen angepasst werden, wenn Systeme hinzugefügt, entfernt oder ersetzt werden. 3

4 Die Risiken eines SoS können durch für eine Anforderungen evolutionäre SoS- Architektur beherrschbar gemacht werden Standardisierte Schnittstellen (Vorzugsweise basierend auf vorhandenen Industriestandards) ohne Standardisierung: Schnittstellenanpassung bei Austausch von Systemen erforderlich Quelle: Institute for Systems Research, 2008 mit Standardisierung: Schnittstellenanpassung bei Austausch von Systemen nicht erforderlich Spezielle Schnittstellen-Schichten Vermeidung von Anpassungsarbeiten in den Nachbarsystemen Ermöglichung der Migration von künftigen modernen Schnittstellenstandards Betriebsfreundliche Durchführung von Änderungen innerhalb kurzer Betriebspausen Quelle: Institute for Systems Research, 2008 Kontinuierlicher System- Verifikations- und Validationsprozess (Synthese, Evaluation, kontrollierte Evolution) Korrektheit von Systemspezifikation und Systementwurf Vermeidung des Abweichens der SoS-Evolution von der geplanten Zielrichtung (Kontrollierte Evolution) Zeit- und Kostenoptimierung: Planbare Zuordnung wiederkehrender Zeit- und Kostenaufwendungen 4

5 Die kontinuierliche Validation und Verifikation des SoS erfolgt durch einen Prozess zur Synthese, Evaluation und kontrollierten Evolution für Anforderungen SoS Definition und Anwendungsbedingungen (Black-Box-Systemsicht) Zyklus wird bei Änderungen in den SoS Systemen durchlaufen - SoS - Kontext - Funktionen an den Schnittstellen - Risikoanalyse - RAMS Anforderungen - Kosten SoS Synthese (White-Box-Systemsicht) - Struktur, Funktion, Vernetzung - Kosten - Erstellung System-Modelle - Anpassung System-Modelle - Schnittstellenstandards - Schnittstellenschichten System-Modell des Systems A System-Modell des Systems B 5 SoS - Entwurf Formale Modelle der im SoS vernetzten Systeme - Validation der Kompatibilität - Identifikation der emergenten Eigenschaften - Identifikation der erforderlichen SoS - Schnittstellen SoS - Implementierung - Implementierung oder Anpassung Die in den einzelnen Prozessstufen verwendeten Modellsichten werden in einem Architekturrahmenwerk definiert, durch das ein SoS in seiner Gesamtheit durch unterschiedliche Sichten ausgedrückt werden kann, wie z.b. DoDAF (Department of Defense Architecture Framework). Quelle: Toward an Evolutionary System of Systems Architecture, Institute for Systems Research, 2008

6 Im Innovationsprojekt DAFA wurden für die Grundlagen Anforderungen für ein optimiertes betreiberseitiges CENELEC-konformes Systems Engineering geschaffen Prototypischer Aufbau und Evaluation einer auf das SoS Engineering erweiterbaren Systems Engineering Technologieplattform zur optimierten Durchführung des modellbasierten betreiberseitigen Systems Engineering Grundlage für die Technologieplattform bildet ein dreistufiges Optimierungsmodell 6

7 Die Systems Engineering-Technologien bestehen jeweils aus Beschreibungsmittel, Methode und Werkzeug (BMW-Prinzip) für Anforderungen Systems Engineering Technologie Das Ziel des Systems Engineering ist es, das einzelne System (möglicherweise als Komponente eines SoS) zu optimieren, d.h. richtig zu spezifizieren und zu entwickeln. Bestandteil der prototypischen Technologieplattform Know-how BMW-Prinzip *) Technologieplattform Technologie Technik SoS Engineering Technologie Das Ziel des SoS Engineering ist es, ein Netzwerk von unterschiedlichen, untereinander kommunizierenden Systemen zu optimieren, d.h. die optimale SoS Architektur und die optimalen Kommunikationsverbindungen orientiert an den Anforderungen an das SoS auszuwählen. Die prototypische Technologieplattform muss um Technologien erweitert werden Beschreibungsmittel Methode Werkzeug Beispiele: Systems Modeling Language (SysML) Vorgehensmodell / Prozess Artisan Studio Aussagenlogik, Entscheidungstabellen Vorgehensmodell / Prozess OBLH Tool **) *) Quelle: Einer, Schnieder. Formale Techniken für die Eisenbahnsicherungstechnik, Anforderungskatalog Zusammenfassung der Arbeitsunterlagen. Technische Universität Braunschweig, Institut für Regelungs- und Automatisierungstechnik, Version 1.0: **) Quelle: Hon, Yuen Man. An Engineering-Oriented Formal Framework for Railway Interlocking Systems Requirements Specification. Braunschweig, Germany: Braunschweig University Library,

8 Für die Erstellung des Systemmodells für wird Anforderungen als Basis die standardisierte Systems Modeling Language (SysML) eingesetzt Die SysML stellt drei Diagramme zur Beschreibung der Systemstruktur, vier Diagramme zur Beschreibung des Systemverhaltens und jeweils ein Diagramm zur Beschreibung der Anforderungen und der Systemparametrierung bereit. Quelle: 8

9 Die SysML ist eine speziell für das Systems Engineering konzipierte Erweiterung der Unified Modeling Language (UML) für Anforderungen bdd Übersicht [Begriffe] UML basier t auf Met amodell Kern der SysML: Metamodell, das die Konzepte der Sprache, ihre Charakteristiken und die Beziehungen der Elemente, aus denen es besteht, beschreibt. erweitert UML Pr ofil ist UML -Pr ofil SysML Profil: Mechanismus, um die Unified Modeling Language (UML) anzupassen und zu erweitern (System Engineering- Erweiterungen der UML werden mittels des SysML-Profils beschrieben). Architektur-Rahmenwerk was muß gemacht werden wie muss es gemacht werden Modellier ungsr ichtlinie SysML (ebenso wie UML) sind Notationen: sie beinhalten keine Methode. Sie sagen also z.b. nichts darüber, wann welche Diagramme erstellt werden sollen oder wie viel oder wie wenig bei einem bestimmten Aspekt modelliert werden soll. Zusätzlich erforderlich: - Architektur-Rahmen (was ist zu modellieren?) - Modellierungsrichlinie (wie ist zu modellieren?). Quelle: 9

10 Die CENELEC-Normen fordern eine durchgängige horizontale und vertikale Traceability für Anforderungen Um ein optimales horizontales und vertikales Tracing zu ermöglichen, werden Systemmodell und Testmodell in einem gemeinsamen Modell integriert Horizontales Tracing Vertikales Tracing RAMS-Lebenszyklus EN50126 Systemmodell Testmodell 10

11 Die Darstellungs-Komplexität des Systemmodells wird durch eine dekompositive stakeholderoptimierte Sichtenbildung reduziert für Anforderungen 11

12 In einem in DAFA entwickelten Metamodell für Anforderungen werden die unterschiedlichen Modellsichten definiert und den CENELEC-Phasen zugeordnet 12

13 Ein in DAFA entwickelter Modellierungsprozess für Anforderungen wird durchgängig auf den CENELEC- Phasen 1 bis 4 abgebildet Input der Phasen 1 bis 4: Betriebsstruktur und Betriebsprozess bilden die Grundlage für die Systemdefinition RAMS-Lebenszyklus EN50126 (Phase 1 bis Phase 4) Output der Phasen 1 bis 4: Systemmodell und Testmodell in einem gemeinsamen Modell 13

14 Ein in DAFA entwickelter Validationsfür und Anforderungen Verifikationsprozess ermöglicht eine frühzeitige Aufdeckung von Spezifikationsfehlern Systemkontext System-Use-Cases EN 50126: Phase 2 Systemdefinition Hohe Kostensenkung durch den Fehlerverminderungseffekt in den frühen Phasen der Systementwicklung! Validation des Systemmodells Sicherheitsanforderungen EN 50126: Phase 3 Risikoanalyse Durchgängige Integration der Risikoanalyse in den Modellierungsprozess Formaler Beweis EN 50126: Phase 4 Systemanforderungen Ausführbares Systemmodell (Systemverhalten) 14

15 Stakeholdergerechte Validierungssichten für Anforderungen erhöhen die Transparenz und optimieren die Kommunikation Ausführbares Modell der Weichen-Vierdrahtanschaltung Validierungs-GUI zur interaktiven bildlichen Repräsentation des komplexen Verhaltens des ausführbaren Modells Stakeholder Stakeholdergerechte Validierungssichten ❶ Modell ❷ Modell + Visualisierung Verhaltens-Simulation des formalen Modells (Animation der Zustandsautomaten) ❸ Visualisierung Komplexitätsreduzierende Visualisierung des Modell-Verhaltens (bildliche Repräsentation der Semantik der Zustandsautomaten) 15

16 Die in der Systems Engineering Technologieplattform für Anforderungen vernetzt integrierten Technologien sind auf unterschiedliche Anwendungsfälle skalierbar Stufe 1 ❶ Strukturierte Erfassung von Anforderungen ❷ Vernetzte Verwaltung der Anforderungen in einer gemeinsamen Datenbasis Import/Export (RIF, DOORS) Import/Export (RIF, DOORS) Datenaustausch: RIF (Requirements Interchange-Format) DOORS-Format 1 Stufe 2 ❶ Spezifikation von Bahnsystemen durch Systemmodelle: (Struktur, Verhalten, Parametrierung) 3 6 Datenaustausch: XMI - Schnittstelle ❷ a) Ausführbare Spezifikation ❷ b) Spezifikation von komplexer Logik OBLH-Tool ❸ Validation durch Modell-Simulation 6 5 EXITE ACE Co-Simulation 16 ❹ Formaler Beweis der Erfüllung von Sicherheitseigenschaften durch die Spezifikation 2 Altia Design GUI Simulink Design Verifier Stufe 3 ❶ Generierung von Testfällen aus validierten bzw. verifizierten ausführbaren Spezifikationen Simulink Design Verifier Vernetzung der Technologien ARTISAN DOORS Synchronizer Requirements Management Interface OBLH DOORS Kopplung (noch zu implementieren) Altia Simulink Connector Simulinkinterne Kopplung Noch zu implementieren Noch zu implementieren Mathematical Model Synchronizer EXITE ACE-ARTISAN-Kopplung EXITE ACE-Simulink-Kopplung EXITE ACE-Kopplung zum ERSA- Verkehrssimulator (noch zu impl.)

17 für Anforderungen Vielen Dank für Ihr Interesse Randolf Berglehner Tel.: