Datenbank für Anforderungen -...

Datenbank für AnforderungenProjektplanung

CENELEC-konformes modellbasiertes Systems Engineeri ng von sicherheitskritischen Bahnsystemen auf Betreibersei te am Beispiel des Systems Leit- und Sicherungstechnik

1Copyright DBAG, TET 2, 31.12.2009

München, 14.06.2010

Deutsche Bahn AG, Technik/Beschaffung

Randolf Berglehner (TET 2)

Vortrag zur Rail Automation 201014.06. und 15.06.2010 in Braunschweig


Die Bewältigung von aktuellen Herausforderungen der Deutschen Bahn erfordert ein modernes CENELEC-konformes Systems En gineering

�� Steigerung der Wettbewerbsfähigkeit des schienengeb undenen Personen- und Güterverkehrs

Ganzheitliche funktionale Verbesserung und wirtscha ftliche Optimierung der Leit - und Sicherungstechnik (LST) über den

�� Interoperable wirtschaftliche Integration des Europ ean Train Control Systems (ETCS) in die nationalen Zugsicherungssysteme

Aktuelle Herausforderungen der Deutschen Bahn

Ganzheitlicher Optimierungsansatz zur Bewältigung d ieser Herausforderungen *)

2Copyright Deutsche Bahn AG,TET 2, Randolf Berglehner, 14.06.2010

�� Reduzierung der Investitionskosten (durch anforderungsgerechte Produkte)

�� Reduzierung der Betriebskosten (durch höhere Produktivität und verringerte Energiekosten)

�� Reduzierung der Obsoleszenzkosten (durch Modularisierung)

*) Quelle: DB Netz AG, Ganzheitlicher Optimierungsansatz in NeuPro (Neuausrichtung Produktionssteuerung)

In dem von der Deutschen Bahn AG in den Jahren 2007 bis 2009 durchgeführten Innovationsprojekt "Datenbank für Anforderungen" (DAFA) wurden die Grundlagen für ein optimiertes CENELEC-konformes betreiberseitiges Systems Engineering geschaffen.

Ganzheitliche funktionale Verbesserung und wirtscha ftliche Optimierung der Leit - und Sicherungstechnik (LST) über den gesamten Lebenszyklus *) durch:

Hierzu ist ein optimiertes modernes Systems Enginee ring erforderlich


Das System Leit- und Sicherungstechnik weist in sein er Gesamtheit die Charakteristiken eines System of Systems auf

Das System Leit- und Sicherungstechnik (LST), das si ch aus einer Vielzahl verketteter, größtenteils sicherheitskritischer Systeme zusammensetzt, weist in seiner Gesamtheit wesentlic he Charakteristiken einesSystem of Systems (SoS) auf.

Schlüssel-Charakteristiken eines SoS

�� Emergenz: Das SoS offenbart in seiner Gesamtheit Eigenschaften , die durch keines der beteiligten Systeme zum Ausdruck kommen.

Zielkonformes emergentes Verhalten

Unerwünschtes emergentes Verhalten (Seiteneffekte)

3

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 unwirtschaftliche r, 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.

Copyright Deutsche Bahn AG,TET 2, Randolf Berglehner, 14.06.2010


Die Risiken eines SoS können durch eine evolutionär e SoS- Architektur beherrschbar gemacht werden

�� Standardisierte Schnittstellen (Vorzugsweise basierend auf vorhandenen Industriestandards)

ohne Standardisierung:Schnittstellenanpassung bei Austausch von Systemen erforderlich

mit Standardisierung:Schnittstellenanpassung bei Austausch von Systemen nicht erforderlich

Quelle: Institute for Systems Research, 2008

4

�� Spezielle Schnittstellen-Schichten

�� Kontinuierlicher System- Verifikations- und Validatio nsprozess (Synthese, Evaluation, kontrollierte Evolution)

�� Vermeidung von Anpassungsarbeiten in den Nachbarsys temen�� Ermöglichung der Migration von künftigen modernen S chnittstellenstandards�� Betriebsfreundliche Durchführung von Änderungen inn erhalb kurzer Betriebspausen

�� Korrektheit von Systemspezifikation und Systementwur f�� Vermeidung des Abweichens der SoS-Evolution von der geplanten Zielrichtung (Kontrollierte Evolution)�� Zeit- und Kostenoptimierung: Planbare Zuordnung wiede rkehrender Zeit- und Kostenaufwendungen


Quelle: Institute for Systems Research, 2008


Die kontinuierliche Validation und Verifikation des SoS erfolgt durch einen Prozess zur Synthese, Evaluation und kontrollie rten Evolution

SoS – Definition und Anwendungsbedingungen(Black-Box-Systemsicht)

- SoS - Kontext- Funktionen an den Schnittstellen

- Risikoanalyse- RAMS – Anforderungen- Kosten

SoS – Synthese(White-Box-Systemsicht)

- Struktur, Funktion, Vernetzung

- Erstellung System-Modelle

SoS - Entwurf

- Validation der Kompatibilität

Zyklus wird bei Änderungen in den SoS–Systemen durc hlaufen

5

- Kosten - Erstellung System-Modelle- Anpassung System-Modelle- Schnittstellenstandards- Schnittstellenschichten

- Validation der Kompatibilität- Identifikation der emergenten Eigenschaften

- Identifikation der erforderlichenSoS - Schnittstellen

SoS - Implementierung

- Implementierung oder Anpassung

System-Modelldes Systems A

System-Modelldes Systems B

Formale Modelleder im SoS vernetzten Systeme

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


Im Innovationsprojekt DAFA wurden die Grundlagen fü r ein optimiertes betreiberseitiges CENELEC-konformes Systems Enginee ring 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



TechnologieKnow-how

Technologieplattform

SoS Engineering TechnologieDas Ziel des SoS Engineering ist es, ein Netzwerk von unterschiedlichen, untereinander kommunizierenden Systemen zu optimieren, d.h. die optimale SoS–Architektur und die optimalen Kommunikationsverbindungenorientiert an den Anforderungen an das SoS auszuwählen.

Die Systems Engineering-Technologien bestehen jewei ls aus Beschreibungsmittel, Methode und Werkzeug (BMW-Prinzi p)

Systems Engineering TechnologieDas 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 derprototypischen

7

Technik

Beschreibungsmittel Methode Werkzeug

BMW-Prinzip*)

*) 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: 22.07.1999

Systems Modeling Language (SysML) Vorgehensmodell / Prozess Artisan Studio

Aussagenlogik, Entscheidungstabellen Vorgehensmodell / Prozess OBLH Tool **)Beispiele:

**) Quelle: Hon, Yuen Man. An Engineering-Oriented Formal Framework for Railway Interlocking Systems Requirements Specification. Braunschweig, Germany:Braunschweig University Library, 2009

Technologieplattform

Die prototypischeTechnologieplattform muss um Technologien erweitert werden



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.

Für die Erstellung des Systemmodells wird als Basis die standardisierte Systems Modeling Language (SysML) eingesetzt

8

Quelle: http://www.omgsysml.org/



bdd Übersicht [Begriffe]

MetamodellUML

erweitert UML

basier t auf

Die SysML ist eine speziell für das Systems Engineer ing konzipierte Erweiterung der Unified Modeling Language (UML)

�� Kern der SysML:Metamodell, das die Konzepte der Sprache, ihre Charakteristiken und die Beziehungen der Elemente, aus denen es besteht, beschreibt.

�� Profil: Mechanismus, um die Unified Modeling Language (UML) anzupassen und zu erweitern

9

Architektur-Rahmenwerk Modellierungsr ichtlinie

SysMLPr ofilist UML-Profil

wie muss es gemacht werdenwas muß gemacht werden

Language (UML) anzupassen und zu erweitern (System Engineering- Erweiterungen der UML werden mittels des SysML-Profils beschrieben).

�� SysML (ebenso wie UML) sind Notationen:sie beinhalten keine Methode. Sie sagen also z.B. nichts darüber, wann welche Diagrammeerstellt 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: http://www.omgsysml.org/



Horizontales Tracing

Die CENELEC-Normen fordern eine durchgängige horizon tale und vertikale Traceability

Um ein optimales horizontales und vertikales Tracing zu ermöglichen, werden Systemmodell und Testmodell i n einem gemeinsamen Modell integriert

10

Vertikales Tracing

Systemmodell Testmodell

RAMS-Lebenszyklus EN50126



Die Darstellungs-Komplexität des Systemmodells wird durch eine dekompositive stakeholderoptimierte Sichtenbildung reduziert



In einem in DAFA entwickelten Metamodell werden die unterschiedlichen Modellsichten definiert und den CENELEC-Phasen zugeo rdnet



Ein in DAFA entwickelter Modellierungsprozess wird d urchgä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

13

Output der Phasen 1 bis 4:Systemmodell und Testmodell in einem gemeinsamen Modell

RAMS-Lebenszyklus EN50126(Phase 1 bis Phase 4)



Systemkontext System-Use-Cases

EN 50126: Phase 2Systemdefinition

EN 50126: Phase 3Risikoanalyse

Ein in DAFA entwickelter Validations- und Verifikati onsprozess ermöglicht eine frühzeitige Aufdeckung von Spezifikationsfehlern

14

Sicherheitsanforderungen

Formaler Beweis

Validation desSystemmodells

EN 50126: Phase 4Systemanforderungen

Risikoanalyse

Ausführbares Systemmodell (Systemverhalten)


Hohe Kostensenkungdurch denFehlerverminderungseffektin den frühen Phasen der Systementwicklung!

Durchgängige Integration der Risikoanalyse in den Modellierungsprozess


Validierungs-GUI zur interaktiven bildlichen Repräs entationdes komplexen Verhaltens des ausführbaren Modells

Ausführbares Modell der Weichen-Vierdrahtanschaltun g

Stakeholder

StakeholdergerechteValidierungssichten

Stakeholdergerechte Validierungssichten erhöhen die Transparenz und optimieren die Kommunikation

15

Komplexitätsreduzierende Visualisierung des Modell- Verhaltens(bildliche Repräsentation der Semantik der Zustandsautomaten)

Verhaltens-Simulation des formalen Modells(Animation der Zustandsautomaten)

� Modell � Modell + Visualisierung

� Visualisierung

Validierungssichten



Simulink Design Verifier

� Strukturierte Erfassung von Anforderungen

� Vernetzte Verwaltung derAnforderungen in einergemeinsamen Datenbasis

Stufe 1 � Generierung von Testfällenaus validierten bzw. verifizierten ausführbaren Spezifikationen

Stufe 3Stufe 2

1

� Spezifikation von Bahnsystemen durch Systemmodelle: (Struktur, Verhalten, Parametrierung)

Datenaustausch:� XMI - Schnittstelle

�

�

�

Die in der Systems Engineering Technologieplattform vernetzt integrierten Technologien sind auf unterschiedliche Anwendungsfä lle skalierbar

16

Import/Export(RIF, DOORS)

Datenaustausch:� RIF (Requirements

Interchange-Format)� DOORS-Format

Import/Export(RIF, DOORS)

� a) Ausführbare Spezifikation

� Validation durch Modell-Simulation

Formaler Beweis der Erfüllung von Sicherheitseigenschaften durch die Spezifikation

� b) Spezifikation von komplexer Logik

2 �

�

3�

�

OBLH-Tool

�

Simulink Design Verifier�

EXITE ACE–Co-Simulation

�

Altia Design GUI

Vernetzung der Technologien

1

2

3

�

�

�

��

�

ARTISAN DOORS Synchronizer

Requirements ManagementInterfaceOBLH DOORS Kopplung(noch zu implementieren)

Altia – Simulink ConnectorSimulinkinterne Kopplung Noch zu implementieren

Noch zu implementieren

Mathematical Model SynchronizerEXITE ACE-ARTISAN-Kopplung

EXITE ACE-Simulink-KopplungEXITE ACE-Kopplung zum ERSA-Verkehrssimulator (noch zu impl.)



Vielen Dank für Ihr Interesse

17

Randolf BerglehnerEmail: [email protected].: 089 13085276


Datenbank für Anforderungen -...

Documents

Transcript of Datenbank für Anforderungen -...