Masterarbeit ETCS Stellwerke

Fachhochschule für Technik und Wirtschaft Berlin (FHTW)
Fachbereich Ingenieurwissenschaften I
Studiengang Informationstechnik/Vernetzte Systeme
Masterarbeit
zur Erlangung des akademischen Grades
Master of Engineering
Thema: Spezifikation und Design einer Schnittstelle zur Kommunikation zwischen Stell-
werk- und ETCS-Simulation in einer Testanlage
vorgelegt von
Sebastian Hartung
erstellt bei der

Siemens AG
1. Betreuer: Prof. Dr.-Ing. Wolfgang Biella
2. Betreuer: Dr.-Ing. Rolf Detering
- VERTRAULICH -
Berlin, 08. Oktober 2008

Sperrvermerk
Die vorliegende Masterarbeit beinhaltet interne vertrauliche Informationen der Siemens AG.
Die Weitergabe des Inhaltes der Arbeit und eventuell beiliegender Zeichnungen und Daten im
Gesamten oder in Teilen ist grundsätzlich untersagt. Es dürfen keinerlei Kopien oder Ab-
schriften – auch in digitaler Form – gefertigt werden.
Ausnahmen bedürfen der schriftlichen Genehmigung seitens der Siemens AG.
Berlin, 08. Oktober 2008
Dr. Ireneus Suwalski
-I-
Kurzfassung
Dieses Dokument beschreibt den Datenaustausch über eine Schnittstelle zwischen ETCS- und
Fahrdienstleiterschulungsanlage.
Die Fahrdienstleiterschulungsanlage besteht aus einer Stellwerkssimulation, die wichtige

ETCS-Daten erzeugt. Diese Daten mussten bisher manuell in der ETCS-Schulungsanlage
konfiguriert werden. Die Ausgangszustände beider Schulungsanlagen werden zunächst analy-
siert und dabei schwerpunktmäßig auf deren interne Architektur und Kommunikation einge-
gangen. Das Ergebnis der Untersuchungen zeigt Probleme beim Zusammenschluss der Sys-
teme. Es werden spezifische Lösungen entwickelt, die zu einer leistungsfähigen und geeigne-
ten Kommunikation auf dieser Schnittstelle führen. Aufgrund der Lösungsvorschläge und der
Schnittstellendaten zwischen ETCS- und Fahrdienstleiterschulungsanlage, ergeben sich An-
forderungen für das neue Gesamtsystem. Diese beschränken sich nicht nur auf die neue
Schnittstelle, sondern beziehen sich auch auf Erweiterungen in den Systemen. Um die Funkti-
onsweise des Gesamtsystems darzustellen, erfolgt eine Beschreibung der neuen Schnittstelle
und der erweiterten Systeme. Abschließend werden Funktionstests formuliert, die die richtige
Funktionsweise der Schnittstelle überprüfen.
Abstract
This document describes inter process data communication between the interface of ETCS
training system and traffic superintendent training system.
The traffic superintendent training system consists of an interlocking system, which generates
important ETCS data. This data has to be configured manually so far. Analysis of the two
training systems is well covered in this document, which includes specific focus on internal
architecture and communication within them. The result of investigations shows problems in
connecting the two systems. Specific interface solutions are developed, which results in effec-
tive and proper communication between the systems. Requirement specifications are defined
for implementing the above solution. The requirements not only restrict to the new interface
but they refer as well as to the extensions in training systems. Furthermore a description of the
new interface, the transmitted data and the linked systems shows the functionality of the total
system. In the end functional tests are described that check the new developed interface.
- II -
Inhaltsverzeichnis
Abbildungsverzeichnis .............................................................................................................VI
Tabellenverzeichnis ............................................................................................................... VIII
Abkürzungsverzeichnis ............................................................................................................. X
1 Einleitung ...........................................................................................................................1
1.1 Motivation und Zielsetzung........................................................................................2
1.2 Aufbau der Arbeit.......................................................................................................3
2 Grundlagen .........................................................................................................................4
2.1 Zugbeeinflussungssysteme .........................................................................................4
2.2 European Train Control System .................................................................................4
2.2.1 Geschichtlicher Zusammenhang ........................................................................5
2.2.2 Komponenten .....................................................................................................5
2.2.3 Funktionsstufen ..................................................................................................7
2.3 Elektronisches Stellwerk ..........................................................................................10
2.3.1 Betriebszentrale ................................................................................................12
2.3.2 Unterzentrale - SIMIS C...................................................................................13
2.3.3 Unterzentrale - SIMIS W..................................................................................15
2.3.4 Außenanlage .....................................................................................................16
3 Ist-Analyse........................................................................................................................17
3.1 ETCS-Schulungsanlage ............................................................................................17
3.1.1 Softwarearchitektur ..........................................................................................18
3.1.2 Datenherkunft ...................................................................................................22
3.1.3 Kommunikationstechnologie............................................................................23
3.1.4 Bedienung der Schulungsanlage.......................................................................24
3.2 Fahrdienstleiterschulungsanlage...............................................................................25
- III -
3.2.1 Softwarearchitektur ..........................................................................................27
3.2.2 Datenherkunft ...................................................................................................29
3.2.3 Kommunikationstechnologie............................................................................30
3.2.4 Bedienung der Schulungsanlage.......................................................................32
3.3 TuS-Tesys-Projekt ....................................................................................................33
3.3.1 Der Socket Gateway .........................................................................................34
3.3.2 Der A2Mapper..................................................................................................35
3.3.3 Schnittstelle zwischen TuS und Tesys .............................................................36
3.3.4 Funktionsweise des Gesamtsystems.................................................................41
3.4 Problemanalyse.........................................................................................................42
3.4.1 Bezeichnungen der Außenanlagenelemente.....................................................43
3.4.2 Zustände der Außenanlagenelemente...............................................................44
3.4.3 Zugtypen in den Zugsimulationen....................................................................47
3.4.4 Zugposition als Gleisfrei-/Gleisbelegtmeldung................................................48
3.4.5 Zugposition über die Streckentopologie...........................................................49
3.4.6 Daten für die Schnittstelle zwischen TuS und Tesys .......................................55
4 Lösungsansätze.................................................................................................................57
4.1 Synchronisation von Namen und Zuständen der Außenanlage................................57
4.2 Erweiterung der Zugtypen ........................................................................................58
4.3 Erweiterung der TuS um Gleisfrei-/Gleisbelegtmeldungen .....................................58
4.4 Zugpositionsermittlung über die Streckentopologien ..............................................59
4.5 Erweiterung der Schnittstelle zwischen TuS und Tesys...........................................61
5 Anforderungen an die Schnittstelle ..................................................................................62
6 Designkonzept der Schnittstelle .......................................................................................65
6.1 Vorüberlegung für die Schnittstellenentscheidung ..................................................65
6.2 Aufbau des Gesamtsystems ......................................................................................66
- IV -
6.2.1 Identifikation der neuen Schnittstellen .............................................................67
6.2.2 Anforderungszuordnung zu den Schnittstellen und Komponenten..................68
6.3 Schnittstellenbeschreibung .......................................................................................68
6.3.1 Schnittstelle zwischen SOGW und EFS-Gateway ...........................................68
6.3.2 Schnittstelle zwischen EVSS und Tesys ..........................................................72
6.3.3 Schnittstelle zwischen EFS-Gateway und A2Mapper......................................73
6.3.4 Schnittstelle zwischen Zugsimulation und A2Mapper.....................................73
6.3.5 Schnittstelle zwischen Zugsimulation und EFS-Gateway................................74
7 Testkonzept und prototypische Entwicklung ...................................................................76
7.1 Beschreibung des Testkonzepts................................................................................76
7.2 Entwurf eines Prototypen zum Test der Schnittstelle...............................................77
7.2.1 Anforderungen..................................................................................................77
7.2.2 Funktionsweise des Prototypen ........................................................................78
7.3 Durchzuführende Tests.............................................................................................79
8 Zusammenfassung ............................................................................................................80
8.1 Erreichter Stand ........................................................................................................80
8.2 Ausblick....................................................................................................................81
Literaturverzeichnis .................................................................................................................. 82
Schlusserklärung....................................................................................................................... 85
Anhang ..................................................................................................................................... 86
-V-
Abbildungsverzeichnis
Abb. 1 Entwicklungsstufen der Testanlage ................................................................................1
Abb. 2 Untersuchung der Schnittstelle zwischen zwei Schulungssystemen ..............................2
Abb. 3 Schnittstellendaten im Detail..........................................................................................3
Abb. 4 Bildung der UNISIG.......................................................................................................5
Abb. 5 ETCS - Level 0 [SBB04]................................................................................................8
Abb. 6 ETCS - Level STM [SBB04]..........................................................................................8
Abb. 9 ETCS - Level 3 [SBB04]..............................................................................................10
Abb. 10 Stellwerksbauformen ..................................................................................................10
Abb. 11 Allgemeiner Stellwerksaufbau eines ESTW ..............................................................11
Abb. 12 Elektronisches Stellwerk - Betriebszentrale ...............................................................12
Abb. 13 Elektronisches Stellwerk - Unterzentrale SIMIS C ....................................................13
Abb. 14 Elektronisches Stellwerk - Unterzentrale SIMIS W...................................................15
Abb. 15 Elektronisches Stellwerk – Außenanlage ...................................................................16
Abb. 16 Netzwerkarchitektur der ETCS-Schulungsanlage ......................................................17
Abb. 17 Aufbau der TuS ..........................................................................................................19
Abb. 18 Komponenten der ETCS-Schulungsanlage ................................................................22
Abb. 19 Generierung der Dateneingabeformate für die TuS....................................................22
Abb. 20 Kommunikationsschnittstelle zwischen Prozessen in der TuS...................................24
Abb. 21 Schematischer Start der ETCS-Schulungsanlage .......................................................24
Abb. 22 Fahrdienstleiterschulungsanlage – Logischer Aufbau................................................25
Abb. 23 Netzarchitektur der Fahrdienstleiterschulungsanlage.................................................26
Abb. 24 Aufbau der Fahrdienstleiterschulungsanlage..............................................................27
Abb. 25 Kommunikation in der Fahrdienstleiterschulungsanlage ...........................................30
- VI -
Abb. 26 Schematischer Start der Fahrdienstleiterschulungsanlage..........................................32
Abb. 27 Vernetzung TuS und Tesys.........................................................................................33
Abb. 28 Kommunikation des SOGW .......................................................................................34
Abb. 29 Kommunikation des A2Mapper .................................................................................35
Abb. 30 Initialisierung der TuS durch Tesys............................................................................40
Abb. 31 Initialisierung der TuS ................................................................................................42
Abb. 32 TuS - Zugehörigkeit der Außenelemente zum Stellwerk ...........................................43
Abb. 33 TuS - Zustandsdiagramm Weiche ..............................................................................44
Abb. 34 PROSIM - Zustandsdiagramm Weiche ......................................................................45
Abb. 35 Einordnung der Streckentopologie in das EPOS-XML-Schema................................49
Abb. 36 Gleis - Kilometersprung .............................................................................................50
Abb. 37 Gleis - Kilometrierung aufsteigend/absteigend ..........................................................51
Abb. 38 TRPR – Streckentopologieausschnitt .........................................................................51
Abb. 39 TuS - Beispiel für die Zugpositionsangabe ................................................................51
Abb. 40 Bestandteile eines Rasters...........................................................................................53
Abb. 41 BahnsimDB - Streckentopologieausschnitt ................................................................54
Abb. 42 BahnsimDB - Beispiel für die Zugpositionsangabe ...................................................55
Abb. 43 Zugtypenunterscheidung ............................................................................................58
Abb. 44 Erweiterung des EPOS-XML-Schemas......................................................................59
Abb. 45 Möglichkeiten der Zugpositionierung ........................................................................60
Abb. 46 Festlegung der Weichenrichtung ................................................................................61
Abb. 47 BahnsimDB und mehrere Stellwerke .........................................................................65
Abb. 48 Architektur der ETCS- und Fahrdienstleiterschulungsanlagenkoppelung .................66
Abb. 49 Schnittstellentest aus Sicht des Tools SocketTest ......................................................76
- VII -
Tabellenverzeichnis
Tab. 1 Beschreibung der streckenseitigen ETCS-Komponenten ...............................................6
Tab. 2 Beschreibung der zugseitigen ETCS-Komponenten.......................................................7
Tab. 3 Konfigurationsdateien für die Fahrdienstleiterschulungsanlage ...................................29
Tab. 4 Kommunikation zwischen TuS und Tesys....................................................................37
Tab. 5 Ist-Analyse - Parameter für das Einsetzen eines Zuges ................................................37
Tab. 6 Ist-Anlayse - Parameter für die Angabe der Zuggeschwindigkeit ................................38
Tab. 7 Ist-Analyse - Parameter für das Senden der Zugposition (Gleisfreimeldung) ..............38
Tab. 8 Ist-Analyse - Parameter für das Einstellen der Außenanlagenelemente .......................38
Tab. 9 Zustände der Außenanlagenelemente............................................................................39
Tab. 10 Ist-Analyse – Parameter für das Mitschreiben von Daten...........................................40
Tab. 11 Durch das Stellwerk zu stellende Außenanlagenelemente in den Schulungsanlagen.43
Tab. 12 TuS - Bedeutung der Aufträge ....................................................................................45
Tab. 13 PROSIM - Bedeutung der Aufträge und Kommandos................................................46
Tab. 14 TuS - Streckenelemente...............................................................................................50
Tab. 15 BahnsimDB - Streckenelemente .................................................................................54
Tab. 16 Identifikation der Schnittstellen ..................................................................................68
Tab. 17 Kommunikation zwischen SOGW und EFS-Gateway................................................69
Tab. 18 Parameter für das Einsetzen eines Zuges ....................................................................70
Tab. 19 Parameter für das Löschen eines Zuges ......................................................................70
Tab. 20 Parameter für die Zugbewegung .................................................................................71
Tab. 21 Parameter für das Einstellen eines Signals..................................................................71
Tab. 22 Parameter für das Stellen einer Weiche ......................................................................71
Tab. 23 Parameter für das Einstellen eines Balisentegrammes ................................................72
Tab. 24 Kommunikation zwischen EFS-Gateway und A2Mapper ..........................................73
Tab. 25 Datenpaket zwischen BahnsimDB und A2Mapper.....................................................74
- VIII -
Tab. 26 Kommunikation zwischen Zugsimulation und EFS-Gateway ....................................74
Tab. 27 Prototyp - Übergabeparameter ....................................................................................78
- IX -
Abkürzungsverzeichnis
ACC Area Control Component
BMR-PC Busmithörrechner-PC
BPD Bedienplatzdrucker
BPR Bedienplatzrechner
BSTR Bereichsstellrechner
COMS Kommunikationsserver
DMI Driver Machine Interface
DOKU Dokumentationsrechner
DTD Document Type Definition
EFS-Gateway ETCS- und Fahrdienstleiterschulungsanlagen-Gateway
EPOS ETCS-Streckenprojektierungssystem
ESTW Elektronisches Stellwerk
ETCS European Train Control System
EVC European Vital Computer
EVSS European Vital Software Shell
FDLS Fahrdienstleiterschulungsanlage
GeSim Gesamtsimulation
GFM Gleisfreimeldung
GSM-R-Festnetz Global System for Mobile Communication–Railway-Festnetz
IIC/OMC Interlocking and Interface Component / Overhead Management Com-

ponent
LAN Local Area Network
LEU Lineside Electronic Unit
MSTT Modulares Stellteil
MVB Multifunction Vehicle Bus
-X-
MVBG Multifunction Vehicle Bus Gateway
NAV Nachrichtenverteiler
OBUD On Board Unit Diagnosis
PRADES Projektierungstool für die Anlagedatenprojektierung elektronischer

Stellwerke
PROSIM Prozesssimulation
ProVis Prozessvisualisierung
RBC Radio Block Center
REF Referenzrechner
RISI Route Image Simulation
SBS Standard-Bedien-Schnittstelle
SCCO Scenario Controller
SG Security Gateway
SIMIS Sicheres Mikrocomputer-System von Siemens
Sipax Siemens-Software-Produkte für die Automatisierung mit offenen und

verteilten Systemen
SIPC Siemens-Schnittstelle zur Interprozesskommunikation
SQLT Structured Query Language Tracer
SR Servicerechner
STM Specific Transmission Module
STT Stellteil
TCP Transmission Control Protocol
TCTL TuS-Control
TDAP Three D Application
TDGW Three D Gateway
Tesys Test- und Simulationssystem
- XI -
TuS Test- und Simulationsumgebung
TRPR Track Presentation
TSCB Train Simulator Control Board
UDP User Datagram Protocol
UNISIG Union Industry of Signaling
XML Extensible Markup Language
XSD XML-Schema-Definition
ZCOMS Zentraler Kommunikationsserver
ZDOKU Zentraler Dokumentationsrechner
ZeSAR Zentraler Schnittstellen- und Aufrüstrechner
ZLS Zuglenksystem
ZNS Zugnummern-Meldesystem
ZZLO Zentraler Zuglenkserver Operation
- XII -
Einleitung
1 Einleitung
Die Abteilung I MO RA TC STC1 der Siemens AG testet Zugstrecken, die mit einem interna-
tionalen Zugsicherungssystem ausgerüstet werden sollen. Dieses Zugsicherungssystem heißt
European Train Control System (ETCS). Für die Tests befinden sich in den Laboratorien der
Abteilung Arbeitsplätze, die mit einer eigens dafür entwickelten Softwareumgebung ausges-
tattet sind. Die Softwareumgebung wird als Test- und Simulationsumgebung (TuS) bezeich-
net. Sie bietet den Mitarbeitern die Möglichkeit, eine reale ETCS-Zugausrüstung anzuschlie-
ßen oder eine ETCS-Zugausrüstung softwareseitig zu simulieren. Aufgrund der ständigen
Anpassung der Spezifikationen/Kundenwünsche, musste eine Testanlage flexibel anpassbar
und nutzbar sein (Abb. 1).
Abb. 1 Entwicklungsstufen der Testanlage
Eine der Testanlagen wird nicht nur für Testzwecke verwendet, sondern dient auch für Kun-
denpräsentationen. Dazu wurde die TuS um eine 3D-Visualisierung erweitert, mit der man
aus dem Triebfahrzeugführerstand heraus den Blick auf die Gleisstrecke hat. Über ein Be-
dienpult kann der Benutzer den Zug steuern und erhält so einen realistischen Eindruck von
der ETCS-Funktionalität während der Fahrt.
Im Jahr 2007 wurde die Anlage im Rahmen eines internationalen Projektes zu einer Schu-
lungsanlage umgebaut. Dazu musste das System soweit minimiert werden, dass die Anlage
transportabel wird. An dieser Anlage kann Triebfahrzeugführern das Fahren eines mit ETCS
ausgerüsteten Zuges beigebracht werden.
Zusätzlich zur ETCS-Schulungsanlage befindet sich an dem Standort eine Fahrdienstleiter-

schulungsanlage (FDLS). Sie stellt ein eigenes, von der ETCS-Schulungsanlage unabhängiges
System dar. An ihr werden Fahrdienstleiter ausgebildet, die in Stellwerken den Zugverkehr
1
Industry Mobility Rail Automation Test Center Siemens Testcenter
-1-
Einleitung
sichern sollen. Das System besteht aus einem simulierten Stellwerk mit dessen Außenanlage
(Weichen, Signale) sowie aus einzelnen Bedienplatzrechnern. Über diese Rechner kontrolliert
und steuert der Fahrdienstleiter den Zugverkehr.
1.1 Motivation und Zielsetzung
Ziel der Masterarbeit ist, die Schnittstellen zwischen ETCS-Schulungsanlage und Fahrdienst-
leiterschulungsanlage zu spezifizieren und zu vereinheitlichen (Abb. 2), um beide Systeme
miteinander zu verbinden.
Abb. 2 Untersuchung der Schnittstelle zwischen zwei Schulungssystemen
Die Koppelung bietet dabei wesentliche Möglichkeiten:
• Für die Steuerung der Züge durch ETCS werden Informationen aus dem Stellwerk be-
nötigt, die in den bisherigen Testanlagen durch Testdaten spezifiziert und simuliert
werden mussten. Diese Daten werden nun, wie im realen Betrieb, aus dem Stellwerk
bezogen.
• An beiden Schulungssystemen können gleichzeitig Triebfahrzeugführer und Fahr-

dienstleiter ausgebildet werden.
• In der ETCS-Schulungsanlage steuert ein realer Triebfahrzeugführer einen Zug, der in

der Fahrdienstleiterschulungsanlage dargestellt und für den Stellwerksbetrieb verwen-
det wird.
• In beiden Schulungsanlagen besteht weiterhin die Möglichkeit reale Hardware einzu-

setzen.
Für die Lösung der Zielstellung, soll die im Rahmen eines Projekts realisierte Schnittstelle
untersucht werden, um daraus eine allgemeingültige Schnittstelle zu entwickeln. Das Ergebnis
der Masterarbeit ist die Beschreibung eines neuen Systems und dessen Architekturkonzept. Es
soll dadurch dargestellt werden, welche Maßnahmen notwendig sind, um die ETCS- und
Fahrdienstleiterschulungsanlage miteinander zu vernetzen.
-2-
Einleitung
Zwischen der ETCS- und Fahrdienstleiterschulungsanlage sollen im Allgemeinen die Infor-

mationen aus der Abb. 3 ausgetauscht werden.
Abb. 3 Schnittstellendaten im Detail
1.2 Aufbau der Arbeit
Für die Spezifikation und das Design einer Schnittstelle zur Kommunikation zwischen Stell-
werk- und ETCS-Simulation in einer Testanlage ergibt sich der folgende Aufbau der Arbeit.
Zu Beginn werden die notwendigen Grundlagen vermittelt, um die beiden Schulungssysteme

besser zu verstehen.
Anschließend erfolgt eine Analyse der ETCS- und Fahrdienstleiterschulungsanlage nach be-
stimmten Schwerpunkten. Hier wird beschrieben wie die Systeme aufgebaut sind und wie sie
funktionieren. Zusätzlich wird ein bereits bestehendes Projekt betrachtet, das eine Schnittstel-
le zu einem Stellwerk realisiert hat. Weil es sich um eine projektspezifische Schnittstelle han-
delt, soll diese für die ETCS- und Fahrdienstleiterschulungsanlage verallgemeinert werden.
Die Problemanalyse zeigt wesentliche Unterschiede der Schulungsanlagen, die Schwierigkei-
ten bei der Koppelung beider Systeme hervorrufen. Außerdem werden die Daten der projekt-
spezifischen Schnittstelle beschrieben, die zunächst für die neue Schnittstelle nicht genutzt
werden können.
Im Kapitel Lösungsansätze werden für die Probleme entsprechende Lösungen erarbeitet. Da-
nach wird das neue Gesamtsystem beschrieben, das die Schnittstellen beider Schulungsanla-
gen darstellt und die daraus resultierenden Veränderungen innerhalb der Systeme veranschau-
licht.
Anschließend erfolgt die Testkonzeptbeschreibung für die neue Schnittstelle und die Vorstel-
lung eines Softwareprototyps, der die Schnittstelle experimentell testen kann.
Zum Schluss werden alle erreichten Ergebnisse zusammengefasst. Ein Ausblick zeigt, welche
weiteren Entwicklungsmöglichkeiten für den Zusammenschluss der beiden Schulungsanlagen
vorstellbar sind
-3-
Grundlagen
2 Grundlagen
In diesem Kapitel wird das grundlegende Wissen vermittelt, das zum Verständnis der Master-
arbeit beiträgt.
2.1 Zugbeeinflussungssysteme
Signale dienen im Zugverkehr der Gleisabschnittssicherung. Werden sie durch den Triebfahr-
zeugführer nicht beachtet, kann es zu schwerwiegenden Unfällen kommen. Um diese Sicher-
heitslücke zu schließen, wurden Systeme entwickelt, die den Zug hinsichtlich der zulässigen
Fahrvorgaben überwachen. Im Notfall besteht die Möglichkeit, den Zug aktiv zu beeinflussen,
indem er abgebremst wird. Ein solches System wird als Zugbeeinflussungssystem bezeichnet.
Man unterscheidet folgende Betriebsarten2:
• punktförmige Beeinflussung
• linienförmige Beeinflussung
• punkt- und linienförmige Beeinflussung
Bei den punktförmigen Zugbeeinflussungssystemen werden an diskreten Punkten auf der

Strecke Daten an das Fahrzeug übertragen, während das bei der linienförmigen Zugbeeinflus-
sung über einen längeren und kontinuierlichen Weg geschieht. Als Beispiel für die Kombina-
tion beider Systeme ist das ETCS zu nennen. Es vereint beide Betriebsarten und wird im
nachfolgenden Kapitel näher beschrieben.
2.2 European Train Control System
In Europa gibt es mehrere verschiedene nationale Zugsicherungssysteme, die die Aufgabe

haben, einen Zug sicher über das Schienennetz des jeweiligen Landes zu leiten. Bei län-
derübergreifenden Fahrten mit einem Zug führte dies zu Problemen, weil das Zugsicherungs-
system bei Grenzüberschreitungen gewechselt werden musste. Für die einzelnen Bahnbetrei-
ber bedeutete dieser Wechsel einen erheblichen monetären und zeitlichen Aufwand.
2
Vgl. [Pac04], Seite 75, Arten der Zugbeeinflussungsanlagen
-4-
Grundlagen
2.2.1 Geschichtlicher Zusammenhang
Um den Zugwechsel an den Ländergrenzen zu vermeiden und den grenzüberschreitenden

Verkehr zu vereinfachen, wurden seit Mitte der 90’er Jahre von Seiten der EU und der Indust-
rie Anstrengungen zur Harmonisierung der Zugbeeinflussungssysteme unternommen. Das
führte 1998 zur Gründung von Union Industry of Signaling (UNISIG), zu der die sechs be-
deutendsten Unternehmen der Bahnindustrie gehören (Abb. 4): Siemens, Alstom, Alcatel,
Ansaldo Signal, Invensys Rail und Bombardier.
Abb. 4 Bildung der UNISIG
Die UNISIG hatte die Aufgabe ein europäisches Zugsicherungssystem zu entwickeln, das die
nationalen Systeme zukünftig ersetzen soll. Ergebnis war schließlich das ETCS, das einer
ständigen Weiterentwicklung unterliegt.
2.2.2 Komponenten
Das ETCS besteht aus unterschiedlichen Komponenten, die während der Zugfahrt miteinan-
der kommunizieren und den Zug sicher über die Strecke leiten. Sie werden einem strecken-
und einem zugseitigen Teilsystem zugeordnet (Tab. 1 und Tab. 2).
-5-
Grundlagen
Komponente Beschreibung
Eine Eurobalise befindet sich im Gleisbett und wird in belie-

bigen Abständen auf der Strecke angeordnet. Sie dient der
Eurobalise punktförmigen Übertragung von Ortungsdaten (Fixdatenbali-
se) und wird zur punktförmigen Zugbeeinflussung (Transpa-
rentbalise) genutzt.3
Die Euroloop ist ein bis zu 1000 m langes Schienenfußkabel4,

das die gleiche Funktionalität wie die Eurobalise besitzt. Die
Euroloop
Euroloop ist also die linienförmige Ergänzung zur punktför-
migen Datenübertragung durch eine Eurobalise.
Die LEU ist mit einem Signal und der dazugehörigen Euroba-
Lineside Electronic Unit lise oder Euroloop verbunden. In Abhängigkeit vom Signal-
(LEU) begriff am Signal, schaltet die LEU ein eindeutiges Tele-
gramm in der transparenten Eurobalise oder Euroloop.5
Das RBC ist eine Steuereinheit, die Informationen vom elekt-

ronischen Stellwerk (ESTW) und dem Fahrzeug auswertet. Es
Radio Block Center (RBC)
generiert aus diesen Informationen eine Fahrerlaubnis für das
Fahrzeug auf der Strecke.
Das GSM-R-Festnetz ist wie das öffentliche GSM-Netz auf-

Global System for Mobile gebaut. Eine Besonderheit ist, dass es zusätzlich mit bahnspe-
Communication-Railway- zifischen Funktionen ausgestattet ist6. Mit dem GSM-R ist es
Festnetz (GSM-R-Festnetz) möglich kontinuierlich Daten zwischen RBC und Fahrzeug
auszutauschen.
Tab. 1 Beschreibung der streckenseitigen ETCS-Komponenten
3
Vgl. [SBB04], Seite 6/7, Eurobalise
4
Vgl. [SBB04], Seite 6/9, Euroloop
5
Vgl. [SBB04], Seite 6/12, Lineside Electronic Unit (LEU)
6
Vgl. [SBB04], Seite 6/6, GSM-R-Festnetz
-6-
Grundlagen
Komponente Beschreibung
Die Antenne befindet sich unterhalb des Fahrzeuges und

Balisenantenne
empfängt die Telegramme von den Balisen.7
Zum CabRadio gehört die Funkeinrichtung des Zuges,

um mit der RBC über Funk zu kommunizieren. Eine
CabRadio
Komponente ist z.B. die Funkeinheit, über die Sprache
und Daten gesendet werden.
Das DMI ist ein Monitor über den Fahrvorgaben für den
Driver Machine Interface (DMI) Zugführer angezeigt werden. Es ist mit dem European
Vital Computer verbunden.
Der Fahrzeugrechner verarbeitet die Daten zentral, die

von den ETCS-Komponenten an ihn übertragen werden.
Die Ergebnisse dieser Verarbeitung gibt der EVC an das
European Vital Computer (EVC)
Driver Machine Interface in Form von Fahrvorgaben
weiter. Bei Nichteinhaltung der Vorgaben kann der
EVC auch den Zug stoppen.
Zur Odometrie gehören Komponenten, die den zurück-

gelegten Weg und die Geschwindigkeit des Zuges mes-
Odometrie
sen, wie z.B. der Wegimpulsgeber. Er ist an der Fahr-
zeugachse montiert ist.
Tab. 2 Beschreibung der zugseitigen ETCS-Komponenten
2.2.3 Funktionsstufen
Das ETCS besitzt insgesamt fünf verschiedene Funktionsstufen, die als Level8 bezeichnet
werden. In welchem Level ein Zug fährt, hängt dabei von der Komplexität der ETCS-
Infrastruktur und der Art der Datenübertragung zwischen Zug und Strecke ab.
7
Vgl. [SBB04], Seite 5/17, EuroBalisen-Antenne
8
Vgl. [SBB04], Seite 3/2 bis 3/6
-7-
Grundlagen
ETCS Level 0
Im Level 0 (Abb. 5) ist das Fahrzeug mit dem ETCS ausgerüstet, es ist aber keine ETCS-
Streckenausrüstung (z.B. Eurobalise und Euroloop) in Funktion. Die Fahrzeugeinrichtung
überwacht nur eine konstante Höchstgeschwindigkeit des Zuges.
Abb. 5 ETCS - Level 0 [SBB04]
ETCS Level STM
Das Fahrzeug ist im Level Specific Transmission Module (STM) mit ETCS (Abb. 6) ausge-
rüstet. Der Zug fährt auf einer Strecke mit dem herkömmlichen nationalen Zugsicherungssys-
tem und wird von diesem geführt. Zusätzlich ist das nationale System mit ETCS verbunden
und kommuniziert mit dem Fahrer über das Driver Machine Interface.
Abb. 6 ETCS - Level STM [SBB04]
ETCS Level 1
Im Level 1 (Abb. 7) sind die Strecke und das Fahrzeug mit ETCS ausgerüstet. Die Eurobali-
sen übernehmen die Kommunikation von der Stecke zum Fahrzeug und übertragen an diskre-
ten Punkten Informationen. Es werden dabei Transparent- und Fixdatenbalisen unterschieden.
Bei den Transparentbalisen können die Telegramme in Abhängigkeit vom Signalbegriff durch
-8-
Grundlagen
die Lineside Electronic Unit dynamisch geschaltet werden. Bei den Fixdatenbalisen sind die
Telegramme statisch programmiert. Die Telegramme werden von der zugseitigen ETCS-
Ausrüstung empfangen und verarbeitet. Der European Vital Computer ermittelt anhand dieser
Daten ein neues Geschwindigkeitsprofil und teilt es dem Triebfahrzeugführer über das Driver
Machine Interface mit.
ETCS Level 2
Im Level 2 (Abb. 8) besteht eine bidirektionale, kontinuierliche Verbindung zwischen Fahr-

zeug und Streckenüberwachung. Durch die kontinuierliche Datenübertragung können Daten
auch im Stillstand ausgetauscht werden. Das Fahrzeug erhält eine Fahrerlaubnis über GSM-R
von einem Radio Block Center. Die Fahrerlaubnis generiert das Radio Block Center mit Hilfe
von Informationen, die es vom Fahrzeug und vom Stellwerk erhält. Zu den gesendeten Fahr-
zeuginformationen gehören z.B. die Position und die Fahrtrichtung des Zuges. Diese Daten
ermittelt der European Vital Computer mit Hilfe von Eurobalisen, die in diesem Level feste
Daten enthalten und deshalb keine kabelgebundene Kommunikation zu anderen Anlagen be-
nötigen. Zu den Stellwerksinformationen gehören z.B. Signal- und Weichenstellungen.
-9-
Grundlagen
ETCS Level 3
Die Züge werden unabhängig von ortsfesten Gleisfreimeldungen gesteuert (Abb. 9). Im Zug
befindet sich eine Überwachung für die Zugvollständigkeit. Das Radio Block Center und das
Stellwerk ermitteln anhand der Positions- und Fahrtrichtungsdaten des Zuges den optimalen
Abstand zum nächsten Zug. Dadurch ist eine höhere und bessere Streckenauslastung möglich.
2.3 Elektronisches Stellwerk
Im Laufe der bahntechnischen Entwicklung haben sich vier bedeutende Stellwerksbauformen9

herausgebildet, die in Abb. 10 dargestellt sind.
Abb. 10 Stellwerksbauformen
Die mechanischen Stellwerke sind die älteste Bauform und wurden im 19. Jahrhundert ge-
nutzt. Sie wurden mit Hilfe von Muskelkraft bedient, weil die Weichen und Signale über
Drahtzugleitungen mit den Hebeln im Stellwerk verbunden waren. Einen Wandel gab es
schließlich zu Beginn des 20. Jahrhunderts. Die elektromechanischen Stellwerke besaßen zum
9
Vgl. [Pac04], Seite 127 bis 130, Stellwerksbauformen
- 10 -
Grundlagen
Stellen der Außenanlage elektromotorische Antriebe. Zum sicheren Einstellen der Fahrstraßen
diente bis zu diesem Zeitpunkt ein mechanischer Verschlusskasten. Dieser wurde später in
Relaisstellwerken durch Relaisschaltungen ersetzt. Die modernste Stellwerksbauform ist das
elektronische Stellwerk, das rechnergesteuert betrieben wird. Hier ist die Stellwerkslogik
durch Software realisiert.
Im Folgenden wird sich mit den elektronischen Stellwerken (ESTW) befasst, die von der Sie-
mens AG hergestellt werden. Siemens vertreibt insgesamt zwei verschiedene Arten dieser
Stellwerksbauform, die als sicheres Mikrocomputer-System von Siemens (SIMIS) bezeichnet
werden:
• SIMIS C10 (die bisherige Stellwerksbauform, die in Deutschland verwendet wird)
• SIMIS W11 (für den Weltmarkt konzipiert und wird in Deutschland mit SIMIS D be-
zeichnet)
Im Allgemeinen besteht ein elektronisches Stellwerk aus drei verschiedenen Realisierungs-

schichten, die miteinander verbunden sind (Abb. 11). Dazu gehören die Betriebszentrale, die
Unterzentrale und die Außenanlage. Eine Betriebszentrale verwaltet mehrere Unterzentralen
und jede Unterzentrale mehrere Außenanlagen.
Abb. 11 Allgemeiner Stellwerksaufbau eines ESTW
10
Vgl. [SIC07]
11
Vgl. [SID07]
- 11 -
Grundlagen
2.3.1 Betriebszentrale
Die Betriebszentrale bildet die oberste Ebene des elektronischen Stellwerks. Von hier aus
wird die Bahnstrecke überwacht und gesteuert. Dazu gehören einzelne Rechner, die bestimm-
te Aufgaben zu erfüllen haben (Abb. 12).
Abb. 12 Elektronisches Stellwerk - Betriebszentrale
Der Bedienplatzrechner (BPR) bildet in der Betriebszentrale die Schnittstelle zwischen Stell-
werk und Mensch. Der Bediener steuert über Eingabe/Ausgabe-Geräte (E/A-Geräte) den
Schienenverkehr. Zu diesen Geräten gehören z.B. der Lupen- und Bereichsübersichtsmonitor,
mit denen ein Gleisabschnitt überwacht werden kann sowie die Maus und Tastatur zum Ein-
stellen von Fahrstraßen. Möchte man eine Fahrstraße beispielsweise einstellen, wird das
Gleisbild von Lupen- und Bereichsübersichtsmonitor gleichzeitig in den Bedienplatzrechner
und einen Referenzrechner (REF) geschrieben. Nach einer Bedienung bilden beide Rechner
eine Prüfsumme, die an den Stellwerksrechner gesendet wird. Dieser überprüft die beiden
Prüfsummen auf ihre Deckungsgleichheit. Ist das der Fall, wird die Bedienung vom Stellwerk
durchgeführt.
Treten während des Stellwerksbetriebes Störungen auf oder werden Hilfstexte benötigt, wer-
den diese vom Bedienplatzdrucker (BPD) protokolliert. Dieser Drucker befindet sich direkt
am Bedienplatzrechner. Zusätzlich gibt es in der Betriebszentrale Rechner, die zentrale Syn-
chronisations-, Distributions- und Sammelaufgaben im Stellwerk übernehmen. Dazu gehören
der zentrale Zuglenkserver Operation (ZZLO), der zentrale Dokumentationsrechner (ZDO-
KU) und der zentrale Kommunikationsserver (ZCOMS).
- 12 -
Grundlagen
Der zentrale Zuglenkserver Operation ist für die zyklische Erstellung und Aktualisierung der
Zugfahrpläne zuständig und sendet diese an das Zuglenksystem der Unterzentrale. Der zentra-
le Dokumentationsrechner sammelt Daten aus der Unterzentrale, bereitet sie auf und übergibt
sie dem Bedienplatzrechner. Der zentrale Kommunikationsserver hat die Aufgabe alle Rech-
ner der Betriebszentralen zu synchronisieren und zu überwachen. Die Verknüpfung zwischen
der Betriebszentrale und der darunter liegenden Einheit, der Unterzentrale, wird durch das
Security Gateway (SG) realisiert.
2.3.2 Unterzentrale - SIMIS C
Die Unterzentrale des SIMIS C Stellwerks besteht aus zwei Teilen, die über einen Kommuni-
kationsserver (COMS) miteinander verbunden sind (Abb. 13).
Abb. 13 Elektronisches Stellwerk - Unterzentrale SIMIS C
Der Kommunikationsserver hat die Aufgabe, das Local Area Network (LAN) mit dem zentra-
len Schnittstellen- und Aufrüstrechner (ZeSAR) zu koppeln und Kommunikationsprotokolle
zwischen beiden Teilen zu transferieren.
- 13 -
Grundlagen
Zum Local Area Network gehören ein Notbedienplatz, das Zugnummern-Meldesystem

(ZNS), das Zuglenksystem (ZLS) und das Security Gateway. Der Notbedienplatz besteht aus
dem Bedienplatzrechner und dem Referenzrechner mit den dazugehörigen E/A-Geräten, dem
Bedienplatzdrucker und dem Dokumentationsrechner. Dieser zusätzliche Arbeitsplatz befin-
det sich dort, um die Außenanlage auch bei einem Verbindungsausfalls zur Bedienzentrale
steuern zu können. Das Zugnummern-Meldesystem hat im Stellwerk die Aufgabe, Zügen eine
eindeutige Nummer zu vergeben, damit sie der Fahrdienstleiter leichter disponieren kann.
Eine weitere wichtige Funktion hat das Zuglenksystem. Es ermittelt automatisch die Fahrstra-
ßen von Zügen und stellt sie über das Stellwerk ein. Über das Security Gateway ist die Unter-
zentrale mit der Betriebszentrale verbunden.
Das Herzstück des SIMIS C Stellwerks bildet der zentrale Schnittstellen- und Aufrüstrechner.
Er hat folgende Aufgaben im Stellwerk:
• Verwaltung des gesamten Systems und der Rechneradressen
• Verarbeitung der Eingaben vom Bedienplatz, Überprüfung der Zulässigkeit und Ein-
stellung der Fahrstraßen
• Verarbeitung von Bedienkommandos und deren Weiterleitung an die Bereichsstell-

rechner (BSTR)
• Aufrüstung von Bereichsstellrechner mit anlagenspezifischen Daten
• Verarbeitung von Störungsmeldungen, indem eine Weiterleitung zum Servicerechner

(SR) und zum Kommunikationsserver stattfindet
Die empfangenen Stellbefehle leitet der zentrale Schnittstellen- und Aufrüstrechner an einen
Bereichsstellrechner weiter. Dieser stellt, überwacht bzw. löst daraufhin die Fahrstraßen auf.
Zusätzlich überprüft der Bereichsstellrechner in zyklischen Abständen die angeschlossenen
Elemente der Außenanlage auf ihre richtige Funktionsweise. An die Bereichsstellrechner sind
Stellteile (STT) angeschlossen, die für unterschiedlichste Außenanlagenelemente eingesetzt
werden können, wie z.B. für Weichen und Signale. Je nachdem, welches Element ein Stellteil
steuern soll, kann es für dieses Element unterschiedliche Funktionen übernehmen. Ein Signal-
stellteil muss z.B. die Steuerbits des Bereichsstellrechners interpretieren und entsprechend die
Signallampen schalten können. Mit Hilfe des Servicerechners werden die Zustände der Stell-
werksrechner überwacht. Unterstützend laufen auf ihm Diagnoseprogramme, mit deren Hilfe
gezielt Fehler im Stellwerk zu finden sind. Eine weitere Aufgabe in der Unterzentrale über-
- 14 -
Grundlagen
nimmt der Busmithörrechner-PC (BMR-PC). Er ist mit dem Stellwerksbus verbunden und
zeichnet Telegramme zu Registrier- und Prüfzwecken auf.
2.3.3 Unterzentrale - SIMIS W
Die Unterzentrale des SIMIS W Stellwerks (Abb. 14) ähnelt im Aufbau sehr stark dem
SIMIS C Stellwerk. Das Herz der SIMIS W-Unterzentrale ist hier die Interlocking and Inter-
face Component / Overhead Management Component (IIC/OMC). Sie übernimmt die glei-
chen Aufgaben wie der zentrale Schnittstellen- und Aufrüstrechner aus der SIMIS C-
Unterzentrale.
Abb. 14 Elektronisches Stellwerk - Unterzentrale SIMIS W
Die Area Control Component (ACC) ersetzt außerdem den Bereichstellrechner. Sie kann mit
unterschiedlichen Modulen bestückt werden, die bestimmte Außenanlagenelemente steuern
und überwachen. Die IIC/OMC und die Area Control Component besitzen im Gegensatz zu
ihren Gegenstücken in der SIMIS C-Unterzentrale die gleiche Hardwarebasis. Zu den daraus
resultierenden Vorteilen zählen ein schneller Ersatz bei Hardwareausfall sowie ein minimaler
Aufwand bei der Fehlersuche und –beseitigung
- 15 -
Grundlagen
2.3.4 Außenanlage
Die Außenanlage besteht z.B. aus den Elementen Weiche, Signal, modulares Stellteil (MSTT)
und Balise (Abb. 15).
Abb. 15 Elektronisches Stellwerk – Außenanlage
Ein modulares Stellteil erhält vom Stellwerk ein Kommando, das den einzustellenden Signal-
begriff am angeschlossenen Signal beinhaltet. Zusätzlich wird ihm vom Stellwerk mitgeteilt,
welches Telegramm in der Transparentbalise in Bezug auf den Signalbegriff zu schalten ist.
Im Vergleich zu einer Lineside Electronic Unit unterscheidet sich das modulare Stellteil hin-
sichtlich der ETCS-Funktionalität nicht. Das modulare Stellteil ist jedoch im Gegensatz zur
Lineside Electronic Unit direkt mit der Unterzentrale verbunden. Zusätzlich befindet sich die
Logik des modularen Stellteils in der Unterzentrale und nicht wie bei der Line Electronic Unit
im Gerät selbst.
Für den Zusammenschluss der Außenanlage mit der Unterzentrale gibt es bestimmte Richtli-
nien, die zu beachten sind. Ein modulares Stellteil ist direkt mit dem Bereichsstellrechner
(SIMIS C) oder der Area Control Component (SIMIS W) aus der Unterzentrale verbunden,
weil es gleichzeitig auch die Funktionsfähigkeit der angeschlossenen Außenanlagenelemente
überprüft. Ist ein Signal nicht an ein modulares Stellteil angeschlossen, dann muss es mit ei-
nem Stellteil aus der Unterzentrale verbunden sein.
- 16 -
Ist-Analyse
3 Ist-Analyse
Ziel der Masterarbeit ist, die Schnittstelle zwischen der ETCS- und Fahrdienstleiterschu-
lungsanlage zu definieren. Um die Systeme miteinander zu verbinden, ist es daher zunächst
notwendig, die beiden Systeme einzeln zu betrachten und zu analysieren. Die Untersuchung
beschränkt sich dabei auf die Bereiche Softwarearchitektur, Datenherkunft, Kommunikations-
technologie und Bedienung der Schulungsanlage.
Anschließend wird ein Projekt analysiert, das bereits eine ähnliche Schnittstelle zwischen der
TuS und einem Stellwerk realisiert. Mit Hilfe dieser Untersuchung sollen bereits umgesetzte
Konzepte erkannt und ggf. während der Lösungserarbeitung in die neue Schnittstelle integ-
riert werden.
3.1 ETCS-Schulungsanlage
Die Schulungsanlage besteht aus insgesamt zwei Rechnern (Abb. 16):
• TuS-Rechner
• 3D-Rechner
Abb. 16 Netzwerkarchitektur der ETCS-Schulungsanlage
- 17 -
Ist-Analyse
TuS-Rechner
Der TuS-Rechner ist der Arbeitsplatz für den Trainer. Er kann dort die gesamte Schulung mit
Hilfe von TuS-Prozessen überwachen. An diesen Rechner sind gleichzeitig die Hardware-
komponenten für den Schüler angeschlossen, zu denen das Driver Machine Interface und das
Bedienpult gehören. Mit dem Driver Machine Interface können während der Simulation die
Zug-/ETCS-Daten eingegeben werden und über das Bedienpult der simulierte Zug gesteuert
werden. Die Verbindung zwischen TuS-Rechner und Driver Machine Interface ist über den
Multifunction Vehicle Bus (MVB) realisiert. Unter der Bezeichnung MVB ist ein Bussystem
für Schienenfahrzeuge zu verstehen, das bis zu 4096 intelligente Steuerungen und E/A-Geräte
innerhalb eines Wagens miteinander verbinden kann12. Für die Verwaltung der Zugriffsrechte
auf dem Bus, muss ein Busmaster vorhanden sein, der sich in Form einer MVB-Masterkarte
zwischen TuS-Rechner und Driver Machine Interface befindet. Diese Architektur entspricht
dem häufig genutzten Aufbau auf Triebfahrzeugen, bei denen die Displaytechnik über MVB
angesteuert wird.
3D-Rechner
Der 3D-Rechner ist über das LAN mit dem TuS-Rechner verbunden. Er visualisiert die Stre-
cke, die der Schüler abfahren soll. Aus performancetechnischen Gründen wurde die 3D-
Visualisierung vom TuS-Rechner getrennt und auf diesen Rechner ausgelagert.
3.1.1 Softwarearchitektur
Die ETCS-Schulungsanlage benutzt als Softwareumgebung die TuS. Sie ist ein Softwarepa-
ket, das aus verschiedenen Komponenten besteht13. Es können einzelne Komponenten bau-
kastenartig ausgewählt und benutzt werden, um bestimmte Aufgaben zu lösen. Unter einer
Komponente ist an dieser Stelle ein Prozess zu verstehen, der eine Teilaufgabe in der TuS zu
erfüllen hat und dafür mit anderen Prozessen kommuniziert.
12
Vgl. [MVB03], Seite 26, Fahrzeugbus MVB
13
Vgl. [Fie06], Seite 13 bis 17, Structure of the system
- 18 -
Ist-Analyse
Die TuS ist generell in die drei Funktionsgruppen Basissystem, Schnittstelle und Zielsystem
eingeteilt (Abb. 17).
Abb. 17 Aufbau der TuS
Das Basissystem stellt Komponenten zur Steuerung von Tests, für die Simulation und die
Datenerfassung bereit. Einige dieser Komponenten laufen dabei jedoch nicht autark, sondern
sind auf Daten anderer Komponenten angewiesen.
Die zweite Funktionsgruppe bilden die Schnittstellen. Es handelt sich dabei um Adapter zwi-
schen dem Basis- und dem Zielsystem. Werden in beiden Systemen unterschiedliche Übertra-
gungstechnologien benutzt, transferieren sie die Daten in das andere System. Adapter können
als eine Software- oder Hardwarelösung vorliegen.
Zur dritten Gruppe zählen die Zielsysteme, denen zu testende Soft- und Hardware angehören,
wie z.B. ein RBC. Im Fall der ETCS-Schulungsanlage haben die Zielsysteme einen anderen
Zweck. Sie sollen die Simulation um reale Komponenten erweitern.
Um mit Hilfe der TuS die ETCS-Schulungsanlage realisieren zu können, sind bestimmte Pro-
zesse notwendig, die der Reihe nach gestartet werden müssen. Es handelt sich dabei um die
folgenden Komponenten14:
TCTL (TuS-Control)
Der Prozess TCTL ist die zentrale Anwendersoftware in der TuS. Der Benutzer kann die
Software über eine grafische Oberfläche bedienen. Dieser Prozess hat die Aufgabe die Simu-
14
Vgl. [Neß06]
- 19 -
Ist-Analyse
lation zu starten, indem ein zentrales Steuerskript geladen wird, das weitere Prozesse anstößt.
Dieses Skript enthält z.B. die folgenden Daten:
• Name der Strecken, die geladen werden soll
• Zugtyp und die Startposition des Zuges
• Voreinzustellende Signalbilder und Weichenlagen
Über ein Konfigurationsfenster kann außerdem festgelegt werden, auf welchem Rechner ein
Prozess durch TCTL gestartet werden soll.
SCCO (Scenario Controller)
Der Prozess SCCO liest das über TCTL angegebene Steuerskript aus und verarbeitet es. An-
hand der Daten im Skript, teilt er der TCTL mit, welche weiteren Prozesse gestartet werden
sollen, damit die Simulation ablaufen kann. Das Skript ist in der Programmiersprache Ruby
geschrieben, einer objektorientierten Skriptsprache, die seit Mitte der 90’er Jahre als freie
Software verfügbar ist15.
SQLT (Structured Query Language Tracer)
Innerhalb der TuS werden Daten zwischen den Prozessen ausgetauscht, die durch die Kom-
ponente SQLT mitgeschrieben werden. Ein so genannter „Viewer“ bietet zusätzlich die Mög-
lichkeit, sich diese Daten während oder nach der Simulation anzusehen.
RISI (Route Image Simulation)
Der Prozess RISI ist eine Datenbank, die die gesamte Streckentopologie enthält. Es werden
u.a. die Signalbegriffe, Weichenlagen und Zugpositionen gespeichert. Jeder Prozess, der wäh-
rend der Laufzeit Daten aus dieser Datenbank benötigt, muss eine Kopie dieser Datenbank
erzeugen und diese während der Laufzeit in seinem Prozessumfeld verwalten und aktualisie-
ren. Ein direkter Zugriff auf die RISI ist nicht möglich. Eine wichtige Voraussetzung für eine
aktuelle Datenbank innerhalb der TuS ist, dass jeder Prozess seine Veränderungen bezüglich
der Streckentopologie publiziert.
15
Vgl. [Rub02], Seite V
- 20 -
Ist-Analyse
TRPR (Track Presentation)
Die gesamte Strecke wird aus einer 2D-Perspektive (Grundriss) durch die Komponente TRPR
visualisiert. Durch diesen Prozess kann der Benutzer die aktuelle Geschwindigkeit des Zuges,
die zulässige Geschwindigkeit durch ETCS sowie die maximal erlaubte Streckengeschwin-
digkeit beobachten und kontrollieren. Zusätzlich bietet die TCTL die Möglichkeit Signalbeg-
riffe, Weichenlagen und Balisentelegramme während der Simulation einzustellen.
TSCB (Train Simulator Control Board)
Der Prozess TSCB verwaltet das reale Bedienpult, über das der Zug gesteuert wird. Dazu
empfängt er Signale über die Steuerelemente des Bedienpults und leitet sie an die TuS weiter.
MVBG (Multifunction Vehicle Bus Gateway)
Die Datenübertragung von der TuS zum DMI über MVB wird durch den MVBG gesteuert.
EVSS (European Vital Software Shell)
Die Komponente EVSS kapselt die reale EVC-Software von der TuS. Somit kann die EVC-
Software immer projektabhängig ausgetauscht werden, wobei ggf. nur geringe Anpassungen
durchgeführt werden müssen.
OBUD (On Board Unit Diagnosis)
Der Prozess OBUD hat die Aufgabe, die EVSS zur Laufzeit zu überwachen und im Fehlerfall
Aufschluss über die Ursache zu geben.
TDGW (Three D Gateway)
Für die Steuerung der Kommunikation zwischen TuS und der 3D-Anwendung ist die Kompo-
nente TDGW zuständig. Dieser Prozess sammelt Daten aus der TuS, wie z.B. Signalbilder,
Weichenlagen und Zugpositionen, und überträgt sie zur 3D-Anwendung.
TDAP (Three D Application)
Der Prozess TDAP ist eine 3D-Anwendung, bei der der Triebfahrzeugführer aus dem Fahr-
zeugcockpit heraus auf das Gleisbett sieht. Die Visualisierung zeigt eine mit ETCS ausgerüs-
tete Zugstrecke, auf der ein Zug mit Hilfe eines realen Bedienpults gesteuert werden kann.
- 21 -
Ist-Analyse
Nachdem die einzelnen Komponenten innerhalb der ETCS-Schulungsanlage bekannt sind,

können die beschriebenen Prozesse in die Funktionsgruppen Basissystem, Schnittstelle und
Zielsystem, wie in Abb. 18 dargestellt, eingeordnet werden.
Abb. 18 Komponenten der ETCS-Schulungsanlage
3.1.2 Datenherkunft
Als Datenbasis für die TuS wird XML16 benutzt. Es gibt zwei Möglichkeiten, wie in die TuS
Daten eingelesen werden können:
• über EPOS-XML
• über TuS-, RBC- und K-XML
Abb. 19 Generierung der Dateneingabeformate für die TuS
Das EPOS-XML-Format stammt vom ETCS-Streckenprojektierungssystem (EPOS). Die

Aufgabe von EPOS ist, Zugstrecken mit ETCS auszurüsten. Die Ausgabedatei dieser Projek-
tierung ist EPOS-XML (Abb. 19).
16
Extensible Markup Language
- 22 -
Ist-Analyse
Eine weitere Möglichkeit besteht im TuS-,RBC- und K-XML. Es handelt sich dabei um drei
separate Dateien, in denen unterschiedliche Informationen hinterlegt sind. Das TuS-XML
enthält kodierte Balisendaten und das RBC-XML hingegen die topologischen Informationen.
Das K-XML beschreibt die grafische Anordnung der Streckenelemente. Die drei Dateien wer-
den durch das Tool „EPOS2TuS“ generiert, das als Eingabedatei EPOS-XML benötigt.
Die drei Dateien TuS-, RBC- und K-XML enthalten alle Informationen, die EPOS-XML ent-
hält. Zukünftig soll EPOS-XML als standardisiertes Eingabeformat genutzt werden.
3.1.3 Kommunikationstechnologie
Innerhalb der TuS wird die Middleware Talarian® SmartSockets als Kommunikationstechno-
logie benutzt. Sie stellt eine Vermittlerschicht zwischen dem Betriebssystem sowie der An-
wendung dar und bietet eine gemeinsame Schnittstelle für das verteilte System an17. Talarian®
SmartSockets ist eine nachrichtenorientierte Middleware, die folgende Eigenschaften be-
sitzt18:
• dient als Nachrichtenvermittler zwischen Prozessen
• ist eine zuverlässige und gut skalierbare Netzwerkanwendung
• unterstützt verschiedene Netzwerkprotokolle, zwischen denen SmartSockets überset-

zen kann
SmartSockets nutzt das Client-Server-Prinzip, bei dem sich Clientprozesse im verteilten Sys-
tem mit Serverprozessen verbinden. Als Serverprozess dient ein real-time Server, der als
„RTserver“ bezeichnet wird. Clientprozesse sind die einzelnen TuS-Prozesse, die über den
RTserver ihre Kommunikation abwickeln.
Der Datenaustausch findet innerhalb der TuS über Events statt. Damit jeder TuS-Prozess die
Vielzahl von Events kennt und sich mit anderen Prozessen über SmartSockets verständigen
kann, muss eine Bibliothek eingebunden werden, die „comm_client_api“ heißt (Abb. 20).
17
Vgl. [Bakke]
18
Vgl. [Tal99], Seite 1-1, Getting Started
- 23 -
Ist-Analyse
Diese Bibliothek ermöglicht den TuS-Prozessen folgende Funktionen:
• Interpretation der Nachrichten, um auf die Inhalte der Events zugreifen zu können
• Senden von TuS-spezifischen Nachrichten, die in der TuS über SmartSockets ge-
schickt werden
Abb. 20 Kommunikationsschnittstelle zwischen Prozessen in der TuS
Damit jeder TuS-Prozess auch nur die Events erhält, die er benötigt, ist in SmartSockets ein
Publish-Subscribe-Mechanismus19 implementiert. Jeder Prozess muss dem Server mitteilen
(subscribe), welche Events er erhalten möchte. Der RTserver verteilt daraufhin diesen Event
an alle TuS-Prozesse, die sich bei ihm auf diesen Event angemeldet haben (publish).
3.1.4 Bedienung der Schulungsanlage
Die Schulungsanlage wird über die zentrale Anwendung TCTL gesteuert (Abb. 21).
Abb. 21 Schematischer Start der ETCS-Schulungsanlage
Dazu muss zunächst lokal auf dem TuS-Rechner die Anwendung TCTL gestartet werden. Sie
überwacht im späteren Simulationsverlauf die einzelnen Prozesse. Damit TCTL weiß, auf
19
Vgl. [Tal99], Seite 4-1, Publish-Subscribe
- 24 -
Ist-Analyse
welchem Rechner ein TuS-Prozess gestartet werden soll, kann zu Beginn der Simulation eine
Konfiguration bestimmt und ggf. verändert werden. Anschließend ist das Steuerskript auszu-
wählen, das die Szenariodaten enthält. TCTL übergibt dieses Skript dem SCCO, der es aus-
liest und der TCTL mitteilt, welche weiteren Prozesse gestartet werden sollen. Sind alle not-
wendigen Prozesse geladen, ist die ETCS-Schulungsanlage bereit.
3.2 Fahrdienstleiterschulungsanlage
Die Fahrdienstleiterschulungsanlage besteht aus der Unterzentrale SIMIS C (siehe Kapitel

2.3.2), einer Außenanlage (siehe Kapitel 2.3.4) und einer Zug- und Störungssimulation (Abb.
22). Die Zug- und Störungssimulation ist mit der Unterzentrale und der Außenanlage verbun-
den und hat die Möglichkeit beide Teile zu beeinflussen.
Abb. 22 Fahrdienstleiterschulungsanlage – Logischer Aufbau
Diesen Bereichen der Fahrdienstleiterschulungsanlage sind einzelne Rechnerkomponenten

zugeordnet, die die allgemeine Architektur der Anlage (Abb. 23) darstellen:
• Zug- und Störungssimulation BahnsimDB-Rechner
• Unterzentrale zwei Bedienplatzrechner
Referenzrechner
Bedienplatzdrucker
DOKU-Rechner
ZNS- und ZLS-Rechner
COMS-Rechner
Stellwerksrechner
• Außenanlage Außenanlagenrechner
- 25 -
Ist-Analyse
BahnsimDB-Rechner
Der BahnsimDB-Rechner ist der Arbeitsplatz für den Trainer. Er kann über die Anwendung
BahnsimDB eine Stellwerkssimulation anstoßen und manipulieren. Dafür ist der Rechner zum
einen mit dem Stellwerk-/Außenanlagenrechner und zum anderen mit einem der beiden vor-
handenen Bedienplatzrechner über LAN verbunden.
Abb. 23 Netzarchitektur der Fahrdienstleiterschulungsanlage
Bedienplatzrechner
An beiden Bedienplatzrechnern können gleichzeitig zwei Schüler unterrichtet werden. Jeder

dieser Bedienplätze besteht aus mehreren Monitoren, über die der Stellwerksbereich darge-
stellt wird. Mit Hilfe von E/A-Geräten wird der Schienenverkehr überwacht und gesichert.
Stellwerk-/Außenanlagenrechner
Der Stellwerk-/Außenanlagenrechner simuliert die Komponenten des Stellwerks und dessen

Außenanlage. Er ist über einen Kommunikationsserver mit den Bedienplatzrechnern, dem
Referenzrechner, dem Bedienplatzdrucker, dem Dokumentationsrechner und dem ZNS-/ZLS-
Rechner verbunden. Eine Kommunikation über den BahnsimDB-Rechner ist weder vom
Stellwerk-/Außenanlagenrechner noch vom Bedienplatzrechner her möglich, weil dieser
Kommunikationsweg nicht dem realen Datenaustausch innerhalb eines Stellwerks entspricht.
- 26 -
Ist-Analyse
Die weiteren Komponenten der Fahrdienstleiterschulungsanlage entsprechen in ihrer Funktio-

nalität den originalen Stellwerkselementen (siehe Kapitel 2.3) und brauchen an dieser Stelle
nicht weiter beschrieben werden.
3.2.1 Softwarearchitektur
In der Fahrdienstleiterschulungsanlage befinden sich unterschiedliche Softwarekomponenten,

von denen nur die folgenden betrachtet werden sollen, weil sie den Kern für die Simulation
der Schulungsanlage bilden20 (Abb. 24):
• BahnsimDB
• Bedienplatzsoftware
• GeSim SIMIS C (Stellwerkssimulation)
• PROSIM (Außenanlagensimulation)
Abb. 24 Aufbau der Fahrdienstleiterschulungsanlage
20
Vgl. [Ber07], Seite 20, SW-Architektur BahnsimDB
- 27 -
Ist-Analyse
BahnsimDB
BahnsimDB ist die zentrale Anwendung, über die der Trainer die Stellwerkssimulation starten
und manipulieren kann. Sie zeigt dem Trainer den zu verwaltenden Stellwerksbereich, der
identisch mit dem Gleisbild auf den Bedienplatzrechnern der Schüler ist. Mit BahnsimDB ist
der Trainer in der Lage, Züge in die Strecke einzusetzen und diese nach einem Fahrplan fah-
ren zu lassen. Dafür besitzt BahnsimDB eine eigene Streckentopologie, Zugmodelle und Zug-
fahrpläne. Die eigene Streckentopologie ist für die Zugsimulation notwendig, weil Geschwin-
digkeitsberechnungen auf eine Kilometrierung zurückgreifen, die in einem Stellwerk nicht
vorhanden ist. Um die Züge in die Stellwerkssimulation zu integrieren, ist BahnsimDB mit
der Software eines Bedienplatzrechners verbunden21. Über diese Verbindung kann der Trainer
z.B. ZN-Bedienungen am ZNS-/ZLS-Rechner durchführen, als säße er direkt am Bedienplatz-
rechner. Eine weitere Verbindung existiert zur Stellwerkssimulation, über die BahnsimDB
Gleisfrei-/Gleisbelegtmeldungen sendet, sobald ein Zug einen Gleisabschnitt verlässt/befährt.
Von der Stellwerkssimulation erhält BahnsimDB eine Rückmeldung über die Zustände der
simulierten Stellwerkskomponenten. Zusätzlich verfügt die Trainersoftware über eine Verbin-
dung zur Außenanlage, deren Elemente der Trainer manipulieren kann. Er hat z.B. die Mög-
lichkeit festzulegen, ob ein Lampenfaden eines Signals defekt ist. Im Gegensatz dazu infor-
miert die Außenanlage BahnsimDB über die Zustände der einzelnen Elemente.
Bedienplatzsoftware
Die Bedienplatzsoftware wird vom Schüler benutzt. Er kann von diesem Arbeitsplatz aus
Stellwerksbedienungen auslösen und den Zugverkehr sichern.
GeSim SIMIS C
Das Stellwerk wird durch die Software GeSim SIMIS C22 (Gesamtsimulation) simuliert. Zu
den simulierten Stellwerkskomponenten gehören der zentrale Schnittstellen- und Aufrüst-
rechner, die Bereichsstellrechner und die Kommunikationsverbindungen. Kommandos erhält
die GeSim SIMIS C von der Bedienplatzsoftware und dem ZNS-/ZLS-Rechner. Die Kom-
mandos werden von ihr verarbeitet und an die entsprechenden Bereichsstellrechner als Befeh-
21
Vgl. [Ber05], Seite 4, Übersicht
22
Vgl. [GeS06]
- 28 -
Ist-Analyse
le gesendet. Die Bereichsstellrechner führen diese Befehle aus und stellen z.B. ein Element in
der Außenanlage.
PROSIM
Die Außenanlage wird durch die Prozesssimulation (PROSIM) simuliert. Sie kann fehlerhaf-
tes Verhalten der Außenelemente wirklichkeitsnah vortäuschen und Stellbefehle ausführen.
3.2.2 Datenherkunft
Als Datenbasis benötigt die Fahrdienstleiterschulungsanlage unterschiedliche Dateien. Haupt-

sächlich liefert das Projektierungstool für die Anlagedatenprojektierung elektronischer Stell-
werke (PRADES) den Grunddatenbestand23. Wofür die Daten notwendig sind und woher sie
bezogen werden, ist in der folgenden Tabelle aufgelistet.
Komponente Zweck Datenherkunft
Streckentopologie (ohne Kilometrie-

rung)
Beschriftung von Elementen

PRADES24
BahnsimDB Projektierungsdaten der Außenanlage
Eintragen der Zugnummernmeldeorte

in die Strecke
Kilometrierung der Strecke Spurplan25
Bedienplatzsoftware
GeSim SIMIS C Allgemeine Projektierungsdaten PRADES
PROSIM
Tab. 3 Konfigurationsdateien für die Fahrdienstleiterschulungsanlage
23
Vgl. [Pra07]
24
Vgl. [Ber07], Seite 27, PRADES
25
Vgl. [Int05], Seite 35, Spurplan
- 29 -
Ist-Analyse
3.2.3 Kommunikationstechnologie
An dieser Stelle wird der Verbindungsaufbau auf BahnsimDB und dessen Kommunikations-
partner innerhalb der Fahrdienstleiterschulungsanlage beschränkt, weil BahnsimDB die An-
wendung ist, die die gesamte Schulungsanlage steuert. Zu den Kommunikationspartnern ge-
hören (Abb. 25):
• die Bedienplatzsoftware
• GeSim SIMIS C
• PROSIM
Abb. 25 Kommunikation in der Fahrdienstleiterschulungsanlage
Zwischen den Prozessen werden für den Datentransport die Kommunikationstechnologien

Named Pipes und Sockets verwendet. Es handelt sich dabei um Methoden der Interprozess-
kommunikation für den Datenaustausch zwischen Prozessen.
Generell wird bei Sockets zwischen Stream-Sockets und Datagram-Sockets unterschieden.

Stream-Sockets verwenden für die Kommunikation das Transmission Control Protocol (TCP),
sind verbindungsorientiert und haben eine hohe Verlässlichkeit. Datagram-Sockets verwenden
hingegen das User Datagram Protocol (UDP), arbeiten verbindungslos und haben eine niedri-
gere Verlässlichkeit als TCP. Im weiteren Verlauf ist unter einer Socket-Verbindung eine auf
TCP basierende Kommunikation zu verstehen.
- 30 -
Ist-Analyse
BahnsimDB kommuniziert über Pipes mit Hilfe spezieller Tools, die Pipes in eine Socket-
Verbindung umsetzten. Die Daten werden anschließend über Sockets an den Empfänger ge-
sendet. Die Softwarekomponenten BahnsimDB, GeSim SIMIS C und PROSIM benötigen für
die Kommunikation über Pipes eine Bibliothek namens SIPC.DLL26.
Im Folgenden werden die Verbindungen zwischen den Softwarekomponenten beschrieben:
BahnsimDB – Bedienplatzsoftware
BahnsimDB verbindet sich mit der Bedienplatzsoftware, um mit dem ZNS-/ZLS-Rechner

kommunizieren zu können. Über diesen Kommunikationsweg täuscht BahnsimDB dem
ZNS-/ZLS-Rechner die Identität eines Bedienplatzes vor. Innerhalb des Bedienplatznetzes
werden Daten über die Standard-Bedien-Schnittstelle (SBS) ausgetauscht, durch die sich die
Komplexität der Kommunikation enorm erhöht. Für die umfangreiche Verbindungsverwal-
tung und den Datenaustausch über diese Schnittstelle, wird das Tool Sipax27Com als Hilfsmit-
tel benutzt.
Die Grundidee ist, sich über dieses Tool mit dem Nachrichtenverteiler (NAV) auf dem Be-
dienplatzrechner zu verbinden. Es handelt sich beim NAV um einen lokalen Prozess, der zwi-
schen den Bedien- und Anzeigenprozessen und den Stellwerksrechnern vermittelt. Auf ihn
können sich beliebig viele Bedien- und Anzeigenprozesse anmelden, wie auch in diesem Fall
BahnsimDB. Der NAV versteht das Sipax-Protokoll, weil er die Anwendung SipaxCom eben-
falls nutzt.
BahnsimDB – GeSim SIMIS C
Bei der Verbindung zwischen BahnsimDB und GeSim SIMIS C findet ebenfalls ein Wechsel
der Kommunikationsart von Pipe zu Socket statt, jedoch auf einem anderen Weg. Hier wird
das Tool Network Coupling Unit (NCU) eingesetzt, das sich auf dem BahnsimDB- und
GeSim SIMIS C-Rechner befindet. Beide Softwarekomponenten besitzen je vier verschiedene
26
Siemens-Schnittstelle zur Interprozesskommunikation
27
Siemens-Software-Produkte für die Automatisierung mit offenen und verteilten Systemen
- 31 -
Ist-Analyse
Pipes28, die unterschiedliche Daten übertragen und sich mit der Network Coupling Unit ver-
binden. Beide Network Coupling Unit verbinden sich schließlich über Socket miteinander.
BahnsimDB – PROSIM
Zwischen BahnsimDB und PROSIM wird der gleiche Mechanismus verwendet, wie bei der
Verbindung von BahnsimDB mit der GeSim SIMIS C. Der einzige Unterschied besteht darin,
dass nur eine Pipe zwischen Softwarekomponente und Network Coupling Unit existiert.
3.2.4 Bedienung der Schulungsanlage
Die Anlage befindet sich vor Schulungsbeginn standardmäßig in einem Modus, in dem alle
Rechner eingeschaltet und betriebsbereit sind. Es soll aber an dieser Stelle der ungünstige Fall
beschrieben werden, bei dem dies nicht der Ausgangszustand ist.
Zunächst müssen alle Rechner der Fahrdienstleiterschulungsanlage hochgefahren und auf

ihnen die entsprechende Hauptanwendung gestartet werden. Für die Softwareteile auf dem
Stellwerk-/Außenanlagenrechner ist es wichtig, dass zuerst PROSIM und dann
GeSim SIMIS C gestartet werden. Diese Aufgabe übernimmt ein Skript, das vom Trainerar-
beitsplatz aufgerufen wird und über Netzwerk die Anwendungen startet. Anschließend wird
die Anwendung Cockpit aufgerufen (Abb. 26), um das gewünschte Schulungsszenario einzu-
stellen.
Abb. 26 Schematischer Start der Fahrdienstleiterschulungsanlage
28
Vgl. [Stw05], Seite 6, NCU
- 32 -
Ist-Analyse
Nachdem das Szenario ausgewählt wurde, wird die NCU, eine Debug-Oberfläche, SipaxCom
und BahnsimDB gestartet. BahnsimDB sendet nach dem Start eine Aufrüstaufforderung an
die Außenanlage, die daraufhin alle Weichenlagen und Signalbilder schickt, damit das Trai-
nergleisbild mit dem des Bedienplatzes synchronisiert wird. Dem Trainer erscheint anschlie-
ßend auf seinem Monitor das aktuellste Streckenabbild, über das er nun beliebig viele Züge
einsetzen kann. Er sieht während der gesamten Simulation an seinem Arbeitsplatz das gleiche
Gleisabbild, wie der Schüler am Bedienplatzsystem.
3.3 TuS-Tesys-Projekt
Im Rahmen eines internationalen Projektes war gefordert, dass eine zugseitige ETCS-
Hardware im Zusammenhang mit einem Stellwerk getestet wird. Dabei war jedoch nicht nur
die ETCS-Hardware Testobjekt, sondern auch die Stellwerkslogik. Deshalb wurde in diesem
Projekt die TuS mit einer Stellwerkssimulation verknüpft.
Die Stellwerkssimulation wird durch das Test- und Simulationssystem (Tesys) realisiert. Te-
sys ist ein Softwaresystem, das u.a. für die Prüfung und Inbetriebnahme von Stellwerken ein-
gesetzt wird. Es ist wie ein Baukasten aufgebaut, der allgemeine Komponenten enthält, die je
nach Anwendungsfall benutzt und konfiguriert werden.
Das TuS-Tesys-Projekt (Abb. 27) wird im Folgenden analysiert, um zu erkennen wie diese
Koppelung funktioniert und welche Daten zwischen beiden Systemen ausgetauscht werden.
Abb. 27 Vernetzung TuS und Tesys
- 33 -
Ist-Analyse
Als hierarchisches Konzept wurde beim Zusammenschluss von TuS und Tesys festgelegt,
dass die TuS durch Tesys gesteuert wird. Die TuS ist in diesem Projekt als Testanlage (siehe
Kapitel 1) und nicht als Schulungsanlage integriert. Das bedeutet, dass Tesys z.B. die Züge
steuern muss, weil dafür kein menschlicher Triebfahrzeugführer in der TuS vorhanden ist.
Die Projektierungsdaten erhält Tesys durch das Tool PRADES, wodurch es möglich ist ein
SIMIS D-Stellwerk zu simulieren. Die Datenbasis in der TuS bilden die Dateien
TUS-/RBC-/K-XML.
Für den Datenaustausch zwischen den beiden Systemen besitzen TuS und Tesys Prozesse, die
die Schnittstellen umsetzen:
• Socket Gateway29 (SOGW)
• Außenanlagenzustandsspeicher30 (A2Mapper)
3.3.1 Der Socket Gateway
Der SOGW ist ein Prozess der TuS, der eine Socket-Verbindung zwischen dem SCCO und
einer externen Anwendung herstellt (Abb. 28).
Abb. 28 Kommunikation des SOGW
Der SOGW ist als Socket-Server implementiert, um Prozessen die Möglichkeit zu geben, sich
mit ihm zu verbinden. Zwischen ihnen tauscht er Daten bidirektional aus. Das macht er, in-
dem die Daten zwischen der TuS-internen Kommunikation SmartSockets und der Technolo-
gie Socket umgewandelt werden. Es wird also zwischen Daten transformiert, die in Events
enthalten sind und aus einem sequentiellen Datenstrom stammen.
29
Vgl. [Krö05]
30
Vgl. [Sch06]
- 34 -
Ist-Analyse
Da die Daten auf einer Socket-Verbindung sequentiell gesendet werden, ist es erforderlich
eine Regelung zu treffen, um die Datensätze voneinander zu trennen. Dazu wurde im Rahmen
des Projektes festgelegt, dass die Datensätze jeweils mit dem Zeichen „0x0A“ abgeschlossen
werden.
Für den Informationsaustausch auf SmartSocket-Ebene gibt es zwei Events, die als Datencon-
tainer dienen:
• SogwSccoCommandEvent
• SccoSogwMessageEvent
Das SogwSccoCommandEvent wird verwendet, wenn Daten vom Socket gelesen und an den
SCCO gesendet werden sollen. Das SccoSogwMessageEvent hingegen wird benutzt, um Da-
ten vom SCCO an den externen Prozess über die Socket-Verbindung zu verschicken.
3.3.2 Der A2Mapper
Der Außenanlagenzustandsspeicher ist ein Prozess des Test- und Simulationssystems, der
Meldungen und Kommandos der Außenanlage über eine Socket-Verbindung an ein externes
System schickt. Beim Zusammenschluss von TuS und Tesys ist es problematisch, dass Mel-
dungen und Kommandos der Außenanlage so detailliert sind, dass andere Anwendungen diese
nicht verstehen. Deshalb ist es die Aufgabe des A2Mappers, die detaillierten Meldungen und
Kommandos zu abstrakten, einfachen Meldungen und Kommandos mit Hilfe des so genann-
ten Mappings zuzuordnen. Das Gleiche gilt auch für den umgekehrten Fall, wenn Daten aus
dem externen System in außenanlagenspezifische Daten umgewandelt werden müssen. Als
Meldungen und Kommandos sind hier z.B. die Zustände der Außenanlagenelemente zu ver-
stehen. Diese Zustände erhält der A2Mapper durch den Prozess Prozessvisualisierung (Pro-
Vis), mit dem er verbunden ist. ProVis kommuniziert mit der Außenanlage und kann gezielt
Zustände von Elementen abfragen und verändern (Abb. 29).
Abb. 29 Kommunikation des A2Mapper
- 35 -
Ist-Analyse
Für die konkreten Zuordnungsaufgaben besitzt der A2Mapper Tabellen, die die einzelnen
Zustände, Kommandos sowie Elementbezeichnungen der unterschiedlichen Systeme beinhal-
ten.
Das Mapping eines Elementzustandes kann z.B. wie folgt aussehen: Für ein Signal der Au-
ßenanlage ist in ProVis die rote Lampe ausgeschaltet und die grüne Lampe an. Das externe
System könnte mit diesen Zuständen nichts anfangen. Darum würde der A2Mapper diesen
Zustand schließlich für das andere System auf „Grün“ oder „Fahrt“ übersetzen. Das Namens-
mapping eines Elements kann z.B. so aussehen, dass ein Signalname „Lod_SOM_10“ zu
„Signal_10“ umgewandelt wird.
Der A2Mapper ist ein Socket-Client und kann sich mit anderen Prozessen verbinden. Um die
Datensätze zwischen A2Mapper und dem Prozess des externen Systems voneinander zu tren-
nen, wurde festgelegt, das Zeichen „0x0A“ am Ende eines vollständigen Datensatzes anzufü-
gen.
3.3.3 Schnittstelle zwischen TuS und Tesys
Um zu erkennen welche Daten zwischen dem SOGW und dem A2Mapper ausgetauscht wer-
den, soll des Weiteren diese Schnittstelle analysiert werden. Die Zeichenketten, die über diese
Schnittstelle gesendet werden dürfen, sind dazu im Anlagenverzeichnis der Anlage A be-
schrieben.
Zu den übermittelten Informationen auf dieser Schnittstelle gehören Daten31 für den Zug, die
Streckentopologie, das ETCS, die TuS-Steuerung und zur Synchronisation (Tab. 4).
Datenflussrichtung
Bereich Aktion
TuS ? Tesys
Zug einsetzen
Zug Zuggeschwindigkeit vorgeben
Zugposition senden (Gleisfreimeldung)
Streckentopologie Signalbegriff einstellen
31
Vgl. [Bei05]
- 36 -
Ist-Analyse
Datenflussrichtung
Bereich Aktion
TuS ? Tesys
Weichenstellung verändern
Balisentelegramm einstellen (Level 1)

ETCS Daten über RBC senden/empfangen (hier nur
Level 2)
Einleiten der Initialisierung des Systems
Zurücksetzen des Systems

TuS-Steuerung
Mitschreiben von Daten einschal-
ten/ausschalten
Synchronisation Streckenelemente (Signal, Weiche, Balise)
Tab. 4 Kommunikation zwischen TuS und Tesys
Zug einsetzen
Um einen Zug von Tesys aus in die TuS einsetzen zu können, sind bestimmte Parameter not-
wendig (Tab. 5). Die ETCS-ID ist eine Identifikationsnummer für die ETCS-Einheit an Board
eines Zuges. Jede ETCS-Einheit hat eine eindeutige Nummer. Sie ist z.B. notwendig, um den
Zug in Level 2 über eine RBC zu identifizieren. Zusätzlich ist es wichtig, dass bei der Zuger-
zeugung der Zugtyp angegeben wird. Für die Positionierung ist die Angabe von Zugkopf und
Zugende mit Angabe des Kilometers im Gleis notwendig.
Parameter Datentyp
ETCS-ID String
Zugtyp Integer
Name des Gleises auf dem der Zugkopf steht String
Position [km] des Zugkopfes auf dem Gleis Double
Name des Gleises auf dem das Zugende steht String
Position [km] des Zugendes auf dem Gleis Double
Tab. 5 Ist-Analyse - Parameter für das Einsetzen eines Zuges
- 37 -
Ist-Analyse
Zuggeschwindigkeit vorgeben
Für die Vorgabe einer bestimmten Zuggeschwindigkeit werden die Parameter Zielgeschwin-
digkeit und Beschleunigung/Verzögerung benutzt (Tab. 6).
Parameter Datentyp
Zielgeschwindigkeit Integer
Beschleunigung/Verzögerung Double
Tab. 6 Ist-Anlayse - Parameter für die Angabe der Zuggeschwindigkeit
Zugposition senden (Gleisfrei-/Gleisbelegtmeldung)
Anhand von Gleiskreisen im TuS-XML, kann die TuS entsprechend der Zugposition Gleis-
frei-/Gleisbelegtmeldungen generieren und an die Tesys senden. Unter einem Gleiskreis ist
dabei ein Bereich zu verstehen, der aus Gleisen und Weichen besteht, und auf eine Zugbele-
gung durch ein Stellwerk überwacht wird. Der Parameter Abschnitt benennt den Gleisbereich
eines freien/belegten Gleisabschnitts und der Parameter Zustand, ob der angegebene Ab-
schnitt frei oder belegt ist (Tab. 7).
Parameter Datentyp
Abschnitt String
Zustand String
Tab. 7 Ist-Analyse - Parameter für das Senden der Zugposition (Gleisfreimeldung)
Signalbegriff/Weichenlage/Balisentelegramm einstellen
Für die Veränderung des Zustandes eines Signals, einer Weiche oder einer Balise ist die Ele-
ment-ID und der Zielzustand notwendig (Tab. 8). Die Element-ID identifiziert ein Strecken-
element über einen eindeutigen Namen.
Parameter Datentyp
Element-ID String
Zielzustand Integer
Tab. 8 Ist-Analyse - Parameter für das Einstellen der Außenanlagenelemente
Als Zielzustand sind bei einem Signal der Signalbegriff, bei einer Weiche die Weichenlage
und bei einer Balise die Balisentelegrammnummer zu verstehen (Tab. 9).
- 38 -
Ist-Analyse
Streckenelementtyp Zielzustand
Signal Signal::[STOP| PROCEED| DARK]
Weiche Switch::[LEFT_KNOWN| RIGHT_KNOWN| UNKNOWN]
Balise Balise::TEL[0...255]
Tab. 9 Zustände der Außenanlagenelemente
Daten über RBC
Damit zwischen Tesys und TuS Level 2-Daten über die RBC ausgetauscht werden können, ist
Tesys mit der RBC und die RBC zusätzlich mit dem TuS-Prozess EVSS verbunden. Die
EVSS kapselt die reale EVC-Software (siehe Kapitel 3.1.1) und wird immer dann verwendet,
wenn ein softwareseitig simulierter Zug in die TuS eingesetzt wird. Für jeden Softwarezug
muss eine EVSS in der TuS existieren, die sich mit dem RBC verbindet. Die Kommunikation
zwischen RBC und EVSS findet über ein serielles Kabel statt. Im realen Umfeld würde die
kabelgebundene Strecke über Funk umgesetzt sein. Diese ist jedoch für Simulationszwecke
auf eine Kabellösung reduziert worden. Die Daten, die über die RBC gesendet werden, sind
bereits durch die UNISIG in den Dokumenten der „Software Requirement Specification“32
spezifiziert und werden deshalb an dieser Stelle nicht weiter behandelt.
Einleiten der Systeminitialisierung
Die TuS kann über den Befehl „initTus“ von der Tesys aus initialisiert werden. Demzufolge
startet die TuS, nach erfolgreichem Empfang der Zeichenkette, die Prozesse SCCO, SQLT,
RISI und TRPR hintereinander. Hat die TuS das Starten der Prozesse beendet, signalisiert sie
es der Tesys mit der Antwort „initTusOk“.
32
Vgl. [UNI03], Seite 12-16, Management of Radio Communication
Vgl. [UNI07], Seite 29-31, PACKETS: TRAIN TO TRACK
Vgl. [UNI07], Seite 32, PACKETS: TRACK TO TRAIN or TRAIN TO TRACK
- 39 -
Ist-Analyse
Über die Schnittstelle zwischen TuS und Tesys ist es möglich, die TuS ohne Neuinitialisie-
rung gezielt zu stoppen. Dafür muss der Befehl „resetTus“ von der Tesys aus gesendet wer-
den.
Mitschreiben von Daten einschalten/ausschalten
Eine weitere Funktionalität, die über die Schnittstelle realisiert wurde, ist das Mitschreiben
von Daten der TuS. Mit der Angabe eines Zielpfades können z.B. Informationen über Sys-
temzustände lokal auf dem TuS-Rechner archiviert werden (Tab. 10).
Parameter Datentyp
Zielpfad String
Tab. 10 Ist-Analyse – Parameter für das Mitschreiben von Daten
Synchronisation der Streckenelemente
Ein wichtiger Bestandteil bei der Kommunikation zwischen mehreren Systemen ist die Syn-
chronisation bestimmter Aktionen. Das bedeutet, dass sich zwei Systeme miteinander ab-
stimmen und ihre Aktionen gegenseitig zeitlich koordinieren. Zwischen TuS und Tesys findet
eine Synchronisation hinsichtlich der Außenanlagenelementzustände statt (Abb. 30).
Abb. 30 Initialisierung der TuS durch Tesys
Die Tesys meldet der TuS, dass die Außenelemente miteinander synchronisiert werden sollen.
Ist die TuS dazu bereit, bestätigt sie die Synchronisationsanfrage. Ihr werden daraufhin alle
- 40 -
Ist-Analyse
aktuellen Zustände der Signale, Weichen und Balisen von der Tesys gesendet. Die Synchroni-
sation wird mit einer entsprechenden Information durch Tesys abgeschlossen. Die TuS über-
prüft, ob alle Zustände für die Außenanlagenelemente übertragen wurden und bestätigt oder
verneint die Anfrage. Im Fall einer missglückten Übertragung erfolgt eine erneute Synchroni-
sation.
3.3.4 Funktionsweise des Gesamtsystems
Zunächst müssen in der TuS die Prozesse TCTL und SOGW zusammen gestartet werden.
TCTL ist die zentrale Anwendersoftware in der TuS und befindet sich nach dem Start im
Ausgangszustand. Dieser Zustand ist dadurch definiert, dass eine Konfiguration voreingestellt
ist, die den Start der einzelnen TuS-Prozesse beschreibt. Der SOGW stellt nach dem Start eine
Socket-Verbindung bereit und wartet darauf, dass sich SCCO und A2Mapper mit ihm verbin-
den. Um nun in TCTL die Zugsimulation anzustoßen, muss ein Skript geladen werden, dass
beschreibt, welche zusätzlichen TuS-Prozesse geladen werden sollen. Dafür gibt es in der TuS
insgesamt drei verschiedene Möglichkeiten:
• über die Menüsteuerung der grafischen Oberfläche
• mit Übergabeparameter in der Textkonsole beim Programmstart
• über eine Eventsteuerung
Für die Koppelung von TuS und Tesys wird die dritte Variante, das Laden eines Skriptes über
Eventsteuerung, benutzt. Dabei wird immer nur eine Befehlszeile an den SCCO durch den
SOGW gesendet. Dieser Befehl wird aus dem Event extrahiert und an eine interaktive Ruby-
Shell übergeben. Die interaktive Ruby-Shell ist eine Eingabekonsole, die Ruby-Befehle von
der Konsole sofort einliest und zur Verarbeitung an den Ruby-Interpreter übergibt.
Anschließend muss Tesys gestartet werden. Daraufhin verbindet sich der A2Mapper mit dem
SOGW. Wird ein Szenario gestartet, dann muss die TuS von der Tesys aus mit dem Befehl
„initTus“ initialisiert werden (Abb. 31). Demzufolge startet TCTL den SCCO, der wiederum
über TCTL die Prozesse SQLT, RISI und TRPR aufruft. Danach wird an Tesys die Nachricht
„initTusOk“ gesendet. Damit weiß Tesys, dass die TuS ihre Initialisierung abgeschlossen hat.
Anschließend muss die Tesys noch die einzelnen Signale, Weichen und Balisen senden.
Es können je nach Leistung des Rechners, auf dem die TuS läuft, ein oder mehrere Züge in
die TuS eingesetzt und gesteuert werden. Dafür ist es wichtig, dass in der TCTL-
Konfiguration ausreichend Softwarezüge eingerichtet wurden. Nachdem ein Softwarezug ein-
- 41 -
Ist-Analyse
gesetzt wurde, wird für ihn eine EVSS, OBUD und ein Software-Bedienpult in der TuS ge-
startet. Wird der Zug beschleunigt und überquert er Gleisabschnitte, die durch Gleisfreimelder
überwacht werden, dann wird eine Gleisbesetzt- bzw. Gleisfreimeldung von der TuS an die
Tesys gesendet.
Abb. 31 Initialisierung der TuS
3.4 Problemanalyse
Im Hinblick auf die Zielsetzung dieses Dokumentes, haben sich während der Analyse der
ETCS- und Fahrdienstleiterschulungsanlage Bereiche gezeigt, die hinsichtlich des Zusam-
menschlusses näher untersucht werden müssen. In Bezug auf die Schnittstelle zwischen TuS
und Tesys ist ebenfalls eine Problemanalyse durchzuführen. Es ist hier zu überprüfen, ob die
zu übertragenden Daten in gleicher Weise für die neue Schnittstelle verwendet werden kön-
nen. Zusammenfassend gehören zu den untersuchenden Bereichen:
• Bezeichnungen der Außenanlagenelemente
• Zustände der Außenanlagenelemente
• Zugtypen in den Zugsimulationen
• Zugposition als Gleisfrei-/Gleisbelegtmeldung
• Zugposition über die Streckentopologie
• Daten für die Schnittstelle zwischen TuS und Tesys
Die genannten Bereiche sind entscheidend für den Zusammenschluss der Schulungsanlagen
und werden in diesem Kapitel näher betrachtet.
- 42 -
Ist-Analyse
3.4.1 Bezeichnungen der Außenanlagenelemente
Eine Herausforderung beim Zusammenschluss beider Schulungsanlagen bilden die unter-

schiedlichen Bezeichnungen der Außenanlagenelemente. Während der Simulation müssen die
Zustände der Außenanlagen von der Fahrdienstleiterschulungsanlage an die ETCS-
Schulungsanlage übertragen werden. Dafür ist es notwendig, dass die Elementnamen einer
Weiche oder eines Signals in beiden Systemen identisch sind. Ist das nicht der Fall, kann eine
Synchronisation der Außenanlagenzustände nicht stattfinden. Die unterschiedlichen Namens-
bezeichnungen sind in den Schulungsanlagen auf die Datenursprünge zurückzuführen.
Die TuS benutzt das EPOS- und das TuS-/RBC-/K-XML. Die Fahrdienstleiterschulungsanla-
ge verwendet hingegen hauptsächlich Projektierungsdateien von PRADES. Jedes Tool, das
die Datenbasis für die Schulungsanlagen erstellt, nutzt dabei eine andere Konvention in der
Namensgebung.
Die folgende Tabelle (Tab. 11) gibt einen Überblick über alle Außenanlagenelemente, die in
den Schulungsanlagen durch das Stellwerk gestellt werden. Ausnahme bilden die Balisen,
wenn sie an eine Lineside Electronic Unit angeschlossen sind. In diesem Fall benötigen sie
keinen Stellwerksnamen zum Einstellen des Telegramms. Sind Balisen hingegen an ein mo-
dulares Stellteil angeschlossen, .werden sie durch das Stellwerk konfiguriert.
Außenanlagenelement ETCS-Schulungsanlage FDLS
Weiche
Signal
Balise (Level 1) (LEU) / (MSTT) (LEU) / (MSTT)
Tab. 11 Durch das Stellwerk zu stellende Außenanlagenelemente in den Schulungsanlagen
Eine wichtige Rolle spielt der Stellwerksname in der TuS (Abb. 32).
Abb. 32 TuS - Zugehörigkeit der Außenelemente zum Stellwerk
- 43 -
Ist-Analyse
Weichen und Signale sind dort einem virtuellen Stellwerk zugeordnet, über das die Außen-
elemente in der TuS angesprochen werden. Voraussetzung für das erfolgreiche Stellen eines
dieser Außenelemente ist, dass zusätzlich die Stellwerksnamen in beiden Schulungssystemen
identisch sind.
3.4.2 Zustände der Außenanlagenelemente
Die ETCS- und Fahrdienstleiterschulungsanlage besitzen Außenanlagenelemente, deren Zu-

stände nicht identisch sind. Dieser Sachverhalt ist problematisch, wenn ein Element in der
Fahrdienstleiterschulungsanlage gestellt wird und einen Zustand erreicht, der für das gleiche
Element in der anderen Schulungsanlage nicht existiert. Betroffen sind davon die Außenanla-
genelemente Weiche und Signal. Am Beispiel des Zustandsdiagramms einer Weiche soll der
Unterschied zwischen beiden Systemen dargestellt werden.
ETCS-Schulungsanlage
Die Elemente der Außenanlage werden im ETCS-Schulungssystem von der TuS verwaltet.
Die Weiche besitzt insgesamt vier stabile Zustände Z1 bis Z4 (Abb. 33). Unter einem stabilen
Zustand ist ein Elementstatus zu verstehen, in dem sich das Element solange befindet bis ein
Ereignis einen Zustandswechsel bewirkt. Welche Ereignisse notwendig sind, um in einen an-
deren Zustand zu wechseln, ist in dem nachfolgenden Zustandsdiagramm dargestellt.
Abb. 33 TuS - Zustandsdiagramm Weiche
Ein Ereignis wird dort als Auftrag („A“) bezeichnet. Charakteristisch für das Weichendia-
gramm ist, dass von jedem Zustand in einen anderen gewechselt werden kann. Es ist z.B.
möglich, von einer nach rechts eingestellten Weiche (Z2) über die Aufträge A1, A3 und A4
(Tab. 12) in die anderen Zustände überzugehen.
- 44 -
Ist-Analyse
Auftrag Bedeutung
A1 Wechseln nach Linkslage
A2 Wechseln nach Rechtslage
A3 Wechseln nach Linkslage gestört
A4 Wechseln nach Rechtslage
Tab. 12 TuS - Bedeutung der Aufträge
Fahrdienstleiterschulungsanlage
Die Außenanlage in der Fahrdienstleiterschulungsanlage wird durch die PROSIM verwaltet.

Eine Weiche kann dort elf verschiedene Zustände („Z“) erreichen33. Sie werden im Diagramm
in Abb. 34 mit ihren Ereignissen dargestellt.
Abb. 34 PROSIM - Zustandsdiagramm Weiche
33
Vgl. [PRO06]
- 45 -
Ist-Analyse
Ein Ereignis kann in PROSIM ein Auftrag („A“) oder ein Kommando („K“) sein. Ein Auftrag
wird durch den PC ausgelöst und ein Kommando vom Stellwerk. Der PC simuliert dabei über
einen Auftrag Störungs- und Betriebsaufträge vor Ort. Es wird im Allgemeinen zwischen sta-
bilen Zuständen (Z1, Z2, Z3, Z6, Z7, Z8 und Z9) und Übergangszuständen (Z4, Z5, Z10 und
Z11) unterschieden. Ein stabiler Zustand ist ein dauerhafter Zustand und ein Übergangszu-
stand ist hingegen zeitlich begrenzt („T“), der anschließend in den nächsten Zustand übergeht.
In den Zuständen Z6 und Z7 werden die Zustände einer Bauweiche beschrieben. Unter einer
Bauweiche versteht man eine Weiche, die durch einen Stecker im Stellwerk auf eine feste
Weichenlage eingestellt ist und nicht mehr verändert werden kann. Sie kommt zum Einsatz,
wenn z.B. aus Sicherheitsgründen ein bestimmter Weichenzweig bei Bauarbeiten nicht mehr
befahren werden darf.
Die Bedeutung der Aufträge und Kommandos ist in der nachfolgenden Tabelle (Tab. 13) be-
schrieben.
Auftrag Kommando Bedeutung
A1 - Endlage Rechts wird nicht erreicht
A2 - Endlage Links wird nicht erreicht
Weiche wird aufgefahren oder Verbindung zum Stellteil

A3 -
unterbrochen
A4 - Betriebszustand Bauweiche einnehmen
- K1 Umstellen nach rechts
- K2 Umstellen nach links
- K3 Antrieb abschalten
Tab. 13 PROSIM - Bedeutung der Aufträge und Kommandos
Anhand eines Beispiels soll die Funktionsweise des Zustandsdiagramms erklärt werden:
Eine Weiche befindet sich in Linkslage und ist in Rechtslage zu bringen. Dazu wird ein
Kommando K1 vom Stellwerk ausgelöst, das die Weiche für die Zeit T nach rechts umlaufen
lässt (Z5). Nach Ablauf der Zeit erreicht die Weiche ihre Rechtslage (Z1).
- 46 -
Ist-Analyse
3.4.3 Zugtypen in den Zugsimulationen
Ein weiteres Problem stellen die Zugtypen bzw. Zugmodelle in den beiden Schulungssyste-
men dar. Jedes der Schulungsanlagen benötigt für die Zugtypen andere Parametersätze, die
die Eigenschaften des Zuges genau spezifizieren. Das ist darauf zurückzuführen, dass jedes
Schulungssystem mit seiner Zugsimulation ein anderes Ziel verfolgt.
Die TuS ist eine Zugsimulation, die einen ETCS ausgerüsteten Zug vortäuscht. Ihre Haupt-
aufgabe ist, Triebfahrzeugführer im Umgang mit ETCS zu schulen. Deshalb legt sie weniger
Wert auf die Simulation eines realen Fahrverhaltens, sondern auf die Simulation eines Zuges,
der mit ETCS ausgestattet ist. Die Zugtypen in der TuS werden deshalb z.B. durch die fol-
genden Parameter beschrieben:
• Anzahl der Führerstände
• Balisenantennendaten
• Weg-Impuls-Geber-Informationen
• Radarinformationen
• Zuglänge
Die Fahrdienstleiterschulungsanlage trainiert Fahrdienstleiter in Stellwerken. Die Zugsimula-

tion ist hier eine Teilkomponente des Schulungssystems und soll Züge nach realem Fahrver-
halten bewegen. ETCS spielt hier hinsichtlich der Zugtypen keine Rolle. Zu den Parametern34
eines Zugtypen in der Fahrdienstleiterschulungsanlage gehören z.B.
• Reisezug/Güterzug
• Maximalgeschwindigkeit des Zuges
• Zuglänge
• Anzahl der Waggons
34
Vgl. [Int05], Seite 38, Zugtyp
- 47 -
Ist-Analyse
• Gesamtmasse des Zuges
• Vollzug/Leerzug
• Zugbaureihe
Wie man an den Parametersätzen für die Zugtypendefinition beider Systemen erkennt, unter-
scheiden sie sich sehr stark voneinander. Es ist daher notwendig, diese Modelle zu vereinheit-
lichen oder ggf. aufeinander abzustimmen.
3.4.4 Zugposition als Gleisfrei-/Gleisbelegtmeldung
Sollen ETCS- und Fahrdienstleiterschulungsanlage miteinander gekoppelt werden, muss die

TuS die Möglichkeit besitzen die Zugposition an die Fahrdienstleiterschulungsanlage zu sen-
den. Diese Informationsübertragung kann u.a. über Gleisfrei-/Gleisbelegtmeldungen realisiert
werden.
Gleisfrei-/Gleisbelegtmeldungen werden in der TuS nur durch das TuS-/RBC-/K-XML-

Format unterstützt, wobei diese Information im TuS-XML enthalten ist. Im EPOS-XML gibt
es die Gleisfrei-/Gleisbelegtmeldungen nicht. Sie werden erst durch den Benutzer über das
Tool „EPOS2TUS“ (siehe Kapitel 3.1.2) in das TuS-XML-Format automatisiert eingefügt.
In BahnsimDB sind die Gleisfrei-/Gleisbelegtmeldeinformationen in den Streckentopologie-

daten enthalten. Bewegt sich ein Zug in der Zugsimulation auf einem Gleisabschnitt, der
durch Gleisfreimelder überwacht wird, sendet BahnsimDB an die GeSim SIMIS C eine ent-
sprechende Information.
In Bezug auf die Gleisfrei-/Gleisbelegtmeldungen der Schulungssysteme ist zu erkennen, dass

nicht in allen Eingabedateien der TuS Gleisfrei-/Gleisbelegtmeldungen hinterlegt sind. Es
wurde zusätzlich festgelegt, dass in Zukunft nur noch die EPOS-XML-Schnittstelle für die
Dateneinspielung in die ETCS-Schulungsanlage durchgeführt werden soll. Es muss deshalb
für die Integration der Gleisfrei-/Gleisbelegtmeldung in EPOS-XML eine Lösung gefunden
werden.
- 48 -
Ist-Analyse
3.4.5 Zugposition über die Streckentopologie
Eine weitere Möglichkeit die Zugposition an die Fahrdienstleiterschulungsanlage zu übertra-

gen, ist die Angabe der Zugposition auf dem Gleis. Dieses Verfahren wird in beiden Schu-
lungssystemen unterstützt. Dazu müssen jedoch die Streckentopologien in der ETCS- und
Fahrdienstleiterschulungsanlage zunächst näher betrachtet werden.
Die Streckentopologiedaten sind für die TuS im Eingabeformat EPOS-XML enthalten und
werden durch das Projektierungstool EPOS erzeugt. Wie schon im vorherigen Kapitel festge-
legt, soll dieses Eingabeformat nur noch betrachtet werden.
EPOS unterscheidet zwischen länderspezifischen und projektspezifischen Daten35. Die län-

derspezifischen Daten werden in diesem Dokument vernachlässigt, weil sie für die Strecken-
topologie nicht relevant sind. Die projektspezifischen Daten sind jedoch sehr wichtig. Zu ih-
nen gehören Bahnhöfe36, denen jeweils ein Teil der gesamten Streckentopologie zugeordnet
ist (Abb. 35).
Abb. 35 Einordnung der Streckentopologie in das EPOS-XML-Schema
Innerhalb der Streckentopologie wird zwischen den drei Streckenelementen Gleis, Weiche
und Verbinder unterschieden, von denen jedes Element bestimmte Eigenschaften besitzt (Tab.
14). Die Kombination der Elemente bildet einen Elementverbindungsplan, der beschreibt, wie
ein Element mit einem anderen verbunden ist.
35
Vgl. [Ole07], Seite 20, EPOS-XML-Struktur
36
Bahnanlage mit mindestens einer Weiche, wo Züge beginnen, enden, ausweichen oder wenden dürfen. Vgl.
[Pac04], Seite 264, Bahnhof
- 49 -
Ist-Analyse
Streckenelement Symbol Beschreibung
Ein Gleis hat zwei Konnektoren A und B,

denen ein Kilometerwert zugeordnet ist.
Die Länge des Gleises ergibt sich aus dem
Gleis
Absolutbetrag der Differenz B-A. Ein
Gleis enthält zusätzlich Gradienten- und
Geschwindigkeitsabschnitte.
Eine Weiche hat keine räumliche Ausdeh-

nung und stellt ein Punkt auf der Strecke
Weiche dar. Sie hat eine Spitze A und zwei Enden
L/R (L = linke Abzweigung, R = rechte
Abzweigung).
Ein Verbinder führt Weichen und Gleise

Verbinder zusammen. Er verbindet zwei Konnektoren
von Gleisen und/oder Weichen.
Tab. 14 TuS - Streckenelemente
Als charakteristische Merkmale für die Streckentopologie in der TuS, sind folgende Eigen-
schaften zu nennen:
1. Die Kilometrierung muss nicht von einem Gleis zum anderen kontinuierlich fortge-
setzt sein, wodurch Kilometersprünge die Folge sind. In Abb. 36 ist ein Kilometer-
sprung von „Gleis_1“ (1,2 km) zu „Gleis_2“ (1,4 km) dargestellt.
Abb. 36 Gleis - Kilometersprung
2. Es gibt keine absolute Kilometerangabe, die sich auf die gesamte Strecke bezieht und
verwendet werden kann.
3. Streckenelemente haben das Längenmass Kilometer.
- 50 -
Ist-Analyse
4. Kilometer können auf einem Gleis aufsteigend und auf dem anderen Gleis absteigend
projektiert sein (Abb. 37).
Abb. 37 Gleis - Kilometrierung aufsteigend/absteigend
Der TuS-Prozess TRPR baut mit Hilfe der RISI die Streckentopologie grafisch auf (Abb. 38).
Anhand der Visualisierung ist nicht erkennbar, ob und wie stark ein Gleis gestückelt ist. In
der Abbildung sind die Gleise und Weichen als Teil der Streckentopologie abgebildet. Signale
und Balisen (gelbe Quadrate) werden ebenfalls visualisiert.
Abb. 38 TRPR – Streckentopologieausschnitt
Die Zugposition wird über den Gleisnamen und dem entsprechenden Kilometer im Gleis an-
gegeben. Ein Zug besteht aus einem Kopf und einem Ende, für die entsprechende Positionen
angegeben werden müssen.
Im folgenden Beispiel (Abb. 39) soll die Zugpositionierung in der TuS gezeigt werden:
• Zugkopf auf „Gleis_1“ bei 1,4 km
• Zugende auf „Gleis_1“ bei 1,1 km
Abb. 39 TuS - Beispiel für die Zugpositionsangabe
- 51 -
Ist-Analyse
BahnsimDB erhält die Daten für die Streckentopologie durch PRADES. Alle relevanten Ele-
mentinformationen sind dazu in der Datei „ELEMBEZ.dat“ enthalten, die ursprünglich für
das Leitsystem gedacht war. Sie wird benutzt, um in der Projektierungsphase von BahnsimDB
die Streckentopologie zu erstellen. In dieser Phase sind manuelle Eingriffe notwendig, weil
z.B. eine Kilometrierung in „ELEMBEZ.dat“ nicht vorhanden ist. Die Kilometrierung ist für
Stellwerke generell nicht relevant, weil sie für die Sicherungsaufgabe des Zugverkehrs nicht
benötigt wird. Über einen Spurplan kann die Kilometrierung jedoch nachträglich in Bahn-
simDB eingepflegt werden. Das Ergebnis der Projektierungsphase wird schließlich in den
beiden Dateien „Elements.bsi“ und „Symbols.bsi“ gespeichert und zur Laufzeit ausgelesen.
Die Datei „Elements.bsi“ enthält für die Beschreibung der einzelnen Streckenelemente fol-
gende Eigenschaften:
• den Elementtyp
• die Stranglänge
• die maximal zulässige Geschwindigkeit
• die maximal zulässige Rangiergeschwindigkeit
• die Zuordnung zu einem Stellwerk
• die topografischen Nachbarelemente
• die Gleisfreimelder
Die Anordnung der Elemente basiert in BahnsimDB auf einem Rasternetz, in dem die einzel-
nen Elemente liegen. Die Datei „Symbols.bsi“ beinhaltet die Zuordnung jedes einzelnen Stre-
ckenelements zu einem quadratischen Feld im Rasternetz sowie die Position der einzelnen
Pins am Rasterrand.
Ein Streckenelement besteht im Allgemeinen aus mindestens zwei Strängen37 und zwei Pins
(Abb. 40). Stränge haben ihren Ursprung im Rastermittelpunkt und laufen strahlenförmig zum
Rand. Dort bildet ein Pin den Abschluss eines Stranges. Jeder Strang erhält eine Bezeichnung.
37
Vgl. [Ber07], Seite 30, BahnsimDB-Elemente
- 52 -
Ist-Analyse
Der Strangname wird nach dem Muster „PIN_<Pin>“ gebildet. <Pin> ist dabei die Bezeich-
nung des Pins, der am Ende des Stranges angeheftet ist.
Abb. 40 Bestandteile eines Rasters
Innerhalb der Streckentopologie von BahnsimDB wird zwischen den Elementen Gleis, Wei-
che, Kreuzung und Signal unterschieden. Im Gegensatz zur TuS, gehört das Signal mit zur
Streckentopologie.
Der Aufbau der einzelnen Elemente wird in der nachfolgenden Tabelle (Tab. 15) dargestellt.
Ein Gleis besteht aus zwei Strängen, die

Gleis am Rand in zwei Pins enden. Diese werden
mit A und B bezeichnet.
Eine Weiche besitzt drei Stränge und drei

Pins (A, B und C). Es existieren unter-
Weiche
schiedliche Anordnungsmöglichkeiten der
Gleisstränge einer Weiche.
Eine Kreuzung hat insgesamt vier Gleis-

Kreuzung stränge. Die Pins A, B, C und D befinden
sich am Ende des Stranges.
- 53 -
Ist-Analyse
Ein Signal befindet sich immer an einem

Signal Gleis. Es gelten deshalb die gleichen Ei-
genschaften, wie für ein Gleiselement.
Tab. 15 BahnsimDB - Streckenelemente
Für die Streckentopologie von BahnsimDB gelten folgende charakteristischen Merkmale:
1. Die Strecke ist in Raster unterteilt.
2. Jedes Raster ist gleich groß und enthält ein Streckenelement. Jedes Streckenelement
innerhalb eines Rasters kann unterschiedlich lang sein.
3. Jeder Strang eines Streckenelements ist gleich lang.
4. Die Längenangabe ist in Meter.
Nachdem BahnsimDB die beiden Dateien „Elements.bsi“ und „Symbols.bsi“ ausgelesen hat,
wird die Streckentopologie wie in Abb. 41 dargestellt. Es sind Gleise, Weichen, Kreuzungen
und Signale auf der Grafik zu erkennen. Zusätzlich werden Gleisfreimelder als schwarze
Kreise an den Enden der Gleise dargestellt.
Abb. 41 BahnsimDB - Streckentopologieausschnitt
Die Zugposition wird innerhalb eines Rasters mit Hilfe des Gleisstranges und der entspre-
chenden Kilometrierung auf dem Gleisstrang angegeben. Der Zug besteht in BahnsimDB, wie
auch in der TuS, aus einem Zugkopf und einem Zugende. Deshalb müssen für den Zug zwei
Positionen angegeben werden.
Im folgenden Beispiel (Abb. 42) wird die Zugpositionierung in BahnsimDB gezeigt:
• Zugkopf auf „PIN_B“ bei 600 m in Richtung aus dem Raster hinausfahrend
- 54 -
Ist-Analyse
• Zugende auf „PIN_B“ bei 200 m in Richtung aus dem Raster hinausfahrend
Abb. 42 BahnsimDB - Beispiel für die Zugpositionsangabe
Anhand der beiden Analysen wird deutlich, dass sich die Streckentopologien sehr stark von-
einander unterscheiden. Besonders problematisch ist die unterschiedliche Stückelung der Stre-
cken, weil sie die Zugpositionsangabe sehr komplex werden lässt. Zusätzlich nutzen beide
Schulungsanlagen unterschiedliche Bezugspunkte, um den Zug in das Gleisbild zu setzen:
• TuS setzt den Zug auf einen relativen Kilometerpunkt in der Gleiskante.
• BahnsimDB setzt den Zug im Raster auf einen Gleisstrang. Die Kilometerangabe ist
der Abstand vom Rastermittelpunkt des Elements bis zum Zug.
3.4.6 Daten für die Schnittstelle zwischen TuS und Tesys
Über die Schnittstelle zwischen TuS und Tesys werden teilweise Daten gesendet, die in der
Form, wie sie im TuS-Tesys-Projekt verwendet werden, nicht auf die neue Schnittstelle über-
tragbar sind. Dazu gehören:
• Zug einsetzen
• Zugposition (Gleisfrei-/Gleisbelegtmeldung)
• Einstellen von Weichen und Signalen in der TuS
Zug einsetzen
Soll diese Schnittstelle bei der Koppelung zwischen ETCS- und Fahrdienstleiterschulungsan-
lage wieder verwendet werden, ist es erforderlich, dass sich in den Zugsimulationen von
BahnsimDB und TuS die gleiche Anzahl von ETCS-Zügen befindet. Um diese Aufgabe zu
- 55 -
Ist-Analyse
erfüllen, muss ein Quittierungsmechanismus verwendet werden, der diese Funktion gewähr-
leistet. Außerdem müssen die Züge eindeutig identifiziert werden können.
Zugposition (Gleisfrei-/Gleisbelegtmeldung)
Die TuS sendet an Tesys die Zugposition als Gleisfrei-/Gleisbelegtmeldungen, weil als Da-
teneingabeformat TuS-XML benutzt wird. In der ETCS-Schulungsanlage soll jedoch zukünf-
tig auf EPOS-XML umgestellt werden, das keine Gleisfrei-/Gleisbelegtmeldungen zulässt.
Ohne Gleisfrei-/Gleisbelegtmeldungen im Eingabeformat besteht auch keine Möglichkeit der
Erzeugung dieser Information über diese Schnittstelle.
Einstellen von Weichen und Signalen in der TuS
Weichen-, Signal- und Balisenzustände werden über die Schnittstelle von Tesys nach TuS
über einen gemeinsamen Befehl gesendet, dem zwei Parametern übergeben werden. Dazu
gehören die Identifikation des Außenelements und der Zustand, den dieses Element annehmen
soll. Problematisch ist, dass die TuS die Elemente Weiche und Signal in dem TuS-Tesys-
Projekt fest einem einzigen virtuellen Stellwerk zuordnet. Normalerweise ist es möglich, dass
mehrere Stellwerke eine Strecke überwachen und die Außenanlagenelemente einstellen. Nur
durch die zusätzliche Angabe des Stellwerks ist es dann möglich, eines dieser Streckenele-
mente zu verändern.
Soll die Schnittstelle für den Zusammenschluss von ETCS- und Fahrdienstleiterschulungsan-
lage wieder verwendet werden, muss sie erweitert werden, weil in zukünftigen Projekten auch
mehrere Stellwerke die Strecke sichern können.
- 56 -
Lösungsansätze
4 Lösungsansätze
In der Problemanalyse wurden Schwerpunkte sichtbar, die dem Zusammenschluss der beiden
Schulungsanlagen entgegenstehen. In diesem Kapitel werden Lösungsvorschläge zu den ein-
zelnen Problemen spezifiziert bzw. erarbeitet.
4.1 Synchronisation von Namen und Zuständen der Außenanlage
Während der Ist-Analyse wurde mit den Entwicklern der ETCS- und Fahrdienstleiterschu-
lungsanlage regelmäßig Kontakt gehalten, um über Veränderungen in den Systemen rechtzei-
tig informiert zu werden. Dadurch sollte gewährleistet werden, dass die zu spezifizierende
Schnittstelle nach aktuellsten Systemeigenschaften der Schulungsanlagen entwickelt wird.
Auf Seite der Fahrdienstleiterschulungsanlage ergab sich während der Kontaktaufnahmen

eine wichtige Entwicklung. Sie hat Einfluss auf den Lösungsansatz für die Synchronisation
der Namen und Zustände der Außenanlagenelemente. Um mit der Fahrdienstleiterschulungs-
anlage für neuere Schulungsprojekte attraktiv zu sein, soll die Stellwerkssoftware
GeSim SIMIS C durch den neueren Typ GeSim SIMIS D ausgetauscht werden. Diese Archi-
tekturumstellung wirkt sich positiv auf das Namens- und Zustandssynchronisationsproblem
aus, weil es sich bei der GeSim SIMIS D um die Tesys handelt.
Historisch gesehen, ist die Entwicklung der Tesys aus der GeSim SIMIS C hervorgegangen.
Nachdem die GeSim SIMIS C erstellt wurde, entstand die Nachfrage nach Simulationen ande-
rer Stellwerkstypen. Es hat sich daher angeboten, die vorhandene Stellwerkssimulation so zu
verändern, dass sie modular und flexibel ist. Das Ergebnis dieser Entwicklung war schließlich
die Tesys. Durch Konfiguration und Auswahl bestimmter Tesys-Komponenten ist es möglich,
verschiedene Stellwerkstypen zu simulieren.
Die Entwicklung der Fahrdienstleiterschulungsanlage erlaubt es, den A2Mapper im Zusam-

menhang mit der GeSim SIMIS D wieder zu verwenden. Mit dieser Variante kann das Na-
mens- und Zustandssynchronisationsproblem der Außenanlagenelemente behoben werden.
Hätte diese Entwicklung der Fahrdienstleiterschulungsanlage nicht stattgefunden, wäre eine

ähnliche Variante als Lösung erforderlich gewesen. Bei einer Namens- und Zustandssynchro-
nisation zwischen zwei Systemen lässt es sich jedoch nicht vermeiden, auf eine Lösung mit-
tels Mappingtabelle zurückzugreifen.
- 57 -
Lösungsansätze
4.2 Erweiterung der Zugtypen
In Kapitel 3.4.3 wurde beschrieben, dass ETCS- und Fahrdienstleiterschulungsanlage unter-

schiedliche Zugtypen besitzen, die sich in ihren Parametern und Bezeichnungen unterschei-
den. Ziel ist, die Zugtypen beider Schulungssysteme zu vereinigen.
In BahnsimDB ist dafür zwischen Zugtypen von ETCS und BahnsimDB (Abb. 43) zu unter-
scheiden. Es ist dabei wichtig, dass ein ETCS-Zugtyp in BahnsimDB hinsichtlich seiner Be-
zeichnung mit den Typen der TuS konsistent ist, damit der entsprechende Zugtyp in der TuS
auch eingesetzt werden kann.
Abb. 43 Zugtypenunterscheidung
Außerdem besteht in BahnsimDB die Möglichkeit, zur Laufzeit neue Zugtypen zu definieren.
Für ETCS-Zugtypen darf die Erstellung und Änderung zur Laufzeit nicht möglich sein, weil
die Zugtypen in der TuS softwareseitig hinterlegt sind.
4.3 Erweiterung der TuS um Gleisfrei-/Gleisbelegtmeldungen
Die Problematik der Zugpositionsmeldung mit Hilfe der Gleisfrei-/Gleisbelegtmeldung ist

etwas umfangreicher. Für den Lösungsansatz ist es erforderlich, sich die Realisierung der
Gleisfrei-/Gleisbelegtmeldung zunächst in der Document Type Definition (DTD) des TuS-
XML anzusehen. Die DTD bietet die Möglichkeit, in XML-Dokumenten für Elementtypen
Attribute und Entitäten zu definieren, die schließlich im XML verwendet werden können. Sie
bildet die Grundlage für die Struktur der TuS-XML-Datei, in der die Gleisfrei-/Gleisbelegt-
meldungen hinterlegt sind.
In der DTD der TuS gibt es für die Definition von Gleisbereichen, die durch Gleisfrei-/Gleis-
belegtmelder überwacht werden, ein Gleiskreis-XML-Element. Dieses Element besitzt als
Attribut eine ID, über die der Gleiskreis eindeutig benannt wird. Es handelt sich dabei um
eine Bezeichnung, die mit den Gleiskreisnamen im Stellwerk identisch sein muss. Innerhalb
des Gleiskreis-Elements können beliebig viele Abschnitt-Elemente angegeben werden. Ein
Abschnitt ist durch eine ID und zwei Kilometerangaben definiert. Sie geben an, welches Gleis
- 58 -
Lösungsansätze
und welcher Bereich des Gleises zum Abschnitt gehören. Über diese Art der Elementdefiniti-
onen können demnach beliebig große Gleisbereiche einem Gleiskreis zugeordnet werden.
Für EPOS-XML gibt es eine XML-Schema-Definition (XSD), die keine Gleisfrei-/Gleis-

belegtmeldungen beinhaltet. XSD ist der Nachfolger von DTD und lässt sich, wie auch DTD,
auf seine Gültigkeit überprüfen. Die Vorteile liegen in seiner Erweiterbarkeit und der Mög-
lichkeit neue Datentypen zu erstellen. Um eine Lösung für die Gleisfrei-/Gleisbelegt-
meldungen zu erhalten, müssen die projektspezifischen Daten der Bahnhöfe um die Gleis-
kreis-Elemente erweitert werden (Abb. 44).
Abb. 44 Erweiterung des EPOS-XML-Schemas
Der Gleiskreis soll ein optionales Element in der XSD sein, weil dieses Element nur für Pro-
jekte benötigt wird, die die Koppelung der ETCS- und Fahrdienstleiterschulungsanlage ver-
wenden. Die Struktur des Gleiskreis-Elements ist dabei genauso aufzubauen, wie bereits beim
Element der DTD beschrieben.
4.4 Zugpositionsermittlung über die Streckentopologien
In Kapitel 3.4.5 wurde bereits die Schwierigkeit der Zugpositionierung beschrieben, wenn der
Zug in die Streckentopologe beider Schulungssysteme eingesetzt wird. Grund dafür ist die
unterschiedliche Stückelung der Strecke in der TuS und in BahnsimDB. Für die Problemlö-
sung stehen zwei Varianten zur Verfügung:
• Beide Strecken werden identisch aufgebaut.
• Die Zugposition bezieht sich nicht auf die Position in einem Gleis, sondern auf ein an-
deres Streckenelement.
Die erste Variante scheint auf den ersten Blick der einfachste Weg zu sein. Es müsste jedoch
bei jedem neuen Projekt ein großer Aufwand betrieben werden, um die beiden Streckentopo-
logien deckungsgleich zu halten. Es wäre ein enormer Aufwand notwendig, weil die Datenba-
sis aus unterschiedlichen Projektierungstools stammt.
- 59 -
Lösungsansätze
Der Lösungsansatz der zweiten Variante sind Referenzpunkte in der Streckentopologie. Von
hier aus wird schließlich die Zugposition angegeben. Als Referenzpunkte bieten sich die Stre-
ckenelemente Signal und Weiche an. Signale scheinen auf den ersten Blick ein guter Lö-
sungsansatz zu sein, dürfen jedoch nicht verwendet werden, weil sie nicht in allen ETCS-
Level ein Teil der Strecke sind. Sie gehören nur in den Funktionsstufen Level 0, Level STM,
Level 1 und Level 2 zur Strecke (Kapitel 2.2.3). Im Level 2 dienen die Signale nur als Rück-
fallebene auf Level 1 und Level STM. In Level 3 kommt es zu Problemen bei der Zugpositio-
nierung, weil die Strecke nicht mit Signalen ausgerüstet ist. Demnach würden sie auch nicht
in der Streckentopologie der TuS vorhanden sein.
Somit bleibt die einzige Möglichkeit, die Weichen als Referenzpunkte zu nehmen, weil sie
unabhängig von den ETCS-Funktionsstufen sind. Die Lösung stellt sich folgendermaßen dar:
Ein Zug wird in die Streckentopologie eingesetzt, indem die in Fahrtrichtung nächstliegende
Weiche mit Entfernung von der Weichenspitze angegeben wird. Wichtig ist die Information,
auf welchem Weichenzweig sich der Zug befindet, weil sonst keine Positionierung möglich
ist (Abb. 45).
Abb. 45 Möglichkeiten der Zugpositionierung
Für die Weichenzweigangabe gibt es drei Möglichkeiten:
• auf dem Weichenspitzenzweig
• auf dem linken Weichenzweig (von der Weichenspitze aus gesehen)
• auf dem rechten Weichenzweig (von der Weichenspitze aus gesehen)
Die Bezeichnungen der Weiche ergeben sich wie folgt (Abb. 46): Der Gabelungsursprung
einer Weiche in zwei Zweige wird als Weichenspitze bezeichnet. Der linke und rechte Wei-
chenzweig wird durch die Sicht aus der Gabelung in die Zweige bestimmt.
- 60 -
Lösungsansätze
Abb. 46 Festlegung der Weichenrichtung
Hat der Zug eine Weiche überfahren, wird als Positionsreferenz die Weichenspitze der nächst-
liegenden Weiche in Fahrtrichtung benutzt.
4.5 Erweiterung der Schnittstelle zwischen TuS und Tesys
Wie im Kapitel 3.4.6 beschrieben, existieren Probleme bei der Umsetzung der Schnittstellen-
daten zwischen TuS und Tesys. Für diese werden im Folgenden Lösungsansätze vorgestellt.
Zug einsetzen
Damit in TuS und BahnsimDB die gleiche Anzahl an Zügen existiert, muss eine Rückantwort
vom System gegeben werden, nachdem ein Zug erfolgreich eingesetzt wurde. Wird z.B. in
BahnsimDB ein Zug positioniert, sendet die Fahrdienstleiterschulungsanlage der TuS die
notwendigen Informationen über die Schnittstelle. Danach wartet BahnsimDB auf eine Bestä-
tigung der TuS, dass der Zug erfolgreich eingesetzt wurde. Ist das nicht der Fall, wird dieser
Zug auch nicht in BahnsimDB eingefügt. Zusätzlich vergibt ein interner Zähler für jeden ein-
gesetzten Zug eine ID, die den Zug eindeutig in beiden Schulungssystemen identifiziert.
Zugposition (Gleisfrei-/Gleisbelegtmeldung)
Zwischen TuS und Tesys werden Daten über die Schnittstelle gesendet, die alle auf die neue
Schnittstelle anwendbar sind. Ein Problem ist jedoch EPOS-XML, in der keine Gleiskreise
implementiert sind. Wird die Erweiterung von EPOS-XML umgesetzt, wie es im Kapitel 4.3
beschrieben wurde, ist dieser Teil der Schnittstelle ebenfalls wieder verwendbar.
Einstellen von Weichen und Signalen in der TuS
Die Schnittstelle zum Übertragen von Weichen- und Signalzuständen kann nur benutzt wer-
den, wenn sie um den Parameter des Stellwerksnamen erweitert wird. Dadurch wird es er-
möglicht, die Streckenelemente im laufenden Betrieb von mehreren Stellwerken zu stellen.
- 61 -
Anforderungen an die Schnittstelle
5 Anforderungen an die Schnittstelle
Durch die erarbeiteten Lösungsvorschläge haben sich neue Anforderungen ergeben, die nicht
nur die Schnittstelle zwischen ETCS- und Fahrdienstleiterschulungsanlage betreffen, sondern
auch einzelne Komponenten in den Systemen.
Die Problematik der Zugpositionierung durch Generierung von Gleisfrei-/Gleisbelegt-

meldungen wird aus den Lösungsansätzen nicht weiter beachtet, weil BahnsimDB Gleisbe-
legtmeldungen automatisch generieren kann. Dazu muss der Software die genaue Position des
Zuges (siehe Kapitel 4.4) über die Schnittstelle mitgeteilt werden. Wird ein Zug daraufhin in
der BahnsimDB-internen Zugsimulation bewegt, dann generiert die Software aus der Zugsi-
mulation heraus die Gleisfrei-/Gleisbelegtmeldungen und sendet sie an die GeSim (siehe Abb.
24 in Kapitel 3.2.1). Ein zusätzlicher Vorteil ist, dass mit einer genauen Positionsangabe des
Zuges, ein ETCS-Zug als Zugobjekt in der grafischen Oberfläche von BahnsimDB dargestellt
wird.
Die Anforderungen werden mit /ANFXXX/ bezeichnet, wobei XXX eine dreistellige laufende
Nummer ist. Um für unvorhersehbare Ergänzungen vorzusorgen, wird die Nummerierung der
Anforderungen in Zehnerschritten gewählt. Diese Anforderungen stellen eine Art Anforde-
rungsspezifikation an die ETCS- und Fahrdienstleiterschulungsanlage, um die beiden Anlagen
koppeln zu können.
Schnittstelle ETCS- und Fahrdienstleiterschulungsanlage
/ANF010/ Von BahnsimDB aus kann der Benutzer einen ETCS-Zug einsetzen, der auto-
matisch ebenfalls in der TuS erzeugt wird.
/ANF020/ Von BahnsimDB aus kann der Benutzer einen ETCS-Zug löschen, der automa-
tisch auch in der TuS gelöscht wird.
/ANF030/ Die Zugposition aus der TuS wird alle 200 ms an BahnsimDB übermittelt.
/ANF040/ Signalbilder werden von BahnsimDB an die TuS gesendet.
/ANF050/ Weichenlagen werden von BahnsimDB an die TuS übertragen.
/ANF060/ Die Nummer des aktuell geschalteten Telegramms einer Balise wird von Bahn-
simDB an die TuS verschickt (Level 1).
/ANF070/ Daten für Level 2 und Level 3 werden vom Tesys über eine reale oder simu-
lierte RBC zur TuS übertragen.
- 62 -
/ANF080/ Die TuS muss über die Schnittstelle zwischen ETCS- und Fahrdienstleiterschu-
lungsanlage in einen definierten Ausgangszustand gebracht werden können.
Komponentenerweiterungen
/ANF090/ Es gibt eine Schnittstelle zur Kommunikation mit dem externen System Fahr-
dienstleiterschulungsanlage.
/ANF100/ Die Schnittstelle kann Daten senden und empfangen.
/ANF110/ Es werden Daten empfangen, die vom SCCO der TuS direkt interpretiert wer-
den können.
/ANF120/ Implementierung einer neuen Komponente mit dem Namen ETCS- und Fahr-
dienstleiterschulungsanlagen-Gateway (EFS-Gateway) in BahnsimDB.
/ANF130/ EFS-Gateway besitzt eine Verbindung zum SOGW (TuS), zur Zugsimulation
(BahnsimDB) und zum A2Mapper (Tesys).
/ANF140/ EFS-Gateway transferiert die Daten zwischen A2Mapper (erhält er durch

BahnsimDB) und SOGW.
/ANF150/ Zugsteuerungsinformationen werden zwischen der Zugsimulation von Bahn-

simDB und der TuS über den EFS-Gateway ausgetauscht.
Erweiterung der Zugtypen
/ANF160/ BahnsimDB ist die zentrale Anwendung, von der sowohl die ETCS- als auch
die Fahrdienstleiterschulungsanlage gesteuert werden.
/ANF170/ Zugtypenerweiterung wird in BahnsimDB realisiert.
/ANF180/ BahnsimDB setzt die Zugmodelle der eigenen Zugsimulation und die von der
TuS ein.
/ANF190/ Konventionelle Züge der Fahrdienstleiterschulungsanlage sollen in der ETCS-

Schulungsanlage nicht bekannt sein, also auch nicht visualisiert werden. Diese
Festlegung ist notwendig, um den Aufwand für die Realisierung des Lösungs-
ansatzes möglichst gering zu halten.
- 63 -
Zugposition über die Streckentopologien
/ANF200/ Zugpositionsangabe, indem die in Fahrtrichtung nächstliegende Weiche mit

Entfernung von der Weichenspitze angegeben wird.
/ANF210/ Die Entfernung wird in Kilometer angegeben.
/ANF220/ Um zu erkennen, über welchen der Weichenzweige die Zugposition abgetragen

werden muss, gibt es die drei Möglichkeiten: Weichspitzenzweig, linker Wei-
chezweig und rechter Weichenzweig.
/ANF230/ Der Zug nimmt immer als Positionsreferenz die Weichenspitze der nächstlie-
genden Weiche in Fahrtrichtung.
/ANF240/ Die TuS hat die Möglichkeit, die Zugpositionierung zu interpretieren.
/ANF250/ Die Zugsimulation in BahnsimDB kann die Zugpositionierung interpretieren.
Bezeichnungen der Außenanlagenelemente
/ANF260/ Das neue Stellwerk GeSim SIMIS D besteht aus den Komponenten des Tesys.
/ANF270/ Die Tesys-Komponente A2Mapper ist Teil der Gesim SIMIS D.
/ANF280/ A2Mapper kann die folgenden Elemente übersetzen: Weichenname, -stellung,

Signalname, -begriff, Balisenname, -telegramm, Stellwerksname.
/ANF290/ Anfragen für die Übersetzung zwischen Außenanlagenelementen können auch

von einem externen System durchgeführt werden.
Allgemeine Anforderungen
/ANF300/ Befehlszeichenketten werden immer mit dem Zeichen „0x0A“ abgeschlossen.
/ANF310/ Zwischen den Komponenten der beiden Schulungsanlagen und in den Schu-
lungsanlagen werden die Daten über Sockets ausgetauscht.
- 64 -
Designkonzept der Schnittstelle
6 Designkonzept der Schnittstelle
Die im vorherigen Kapitel aufgeführten Anforderungen bilden die Grundlage für das Design-
konzept der Schnittstelle zwischen ETCS- und Fahrdienstleiterschulungsanlage. In diesem
Kapitel wird nicht nur diese Schnittstelle beschrieben, sondern auch auf das gesamte System
näher eingegangen. Diese Arbeit ist erforderlich, weil Änderungen bzw. Erweiterungen in
beiden Systemen die Folge des Schnittstellendesigns sind. Es wird auf die Architektur der
beiden Systeme eingegangen und deren neue Schnittstellen dargestellt.
6.1 Vorüberlegung für die Schnittstellenentscheidung
Ein wichtiger Bestandteil der Architekturentscheidung beim Zusammenschluss beider Schu-

lungssysteme ist die Suche nach einer Lösung, an welcher Stelle innerhalb der Fahrdienstlei-
terschulungsanlage die Schnittstelle zu realisieren ist. BahnsimDB hat die Möglichkeit, meh-
rere Stellwerke zu verwalten und baut dafür mit jedem Stellwerk separat die notwendigen
Verbindungen auf (Abb. 47).
Abb. 47 BahnsimDB und mehrere Stellwerke
Zusätzlich kann BahnsimDB eine Verbindung mit einer Bedienzentrale (siehe Kapitel 2.3.1)
aufbauen, falls es in einem Projekt verlangt wird.
Diese Vorüberlegung zeigt, dass es am besten ist, die Schnittstelle als Modul in BahnsimDB
zu implementieren. Dadurch werden das Verbindungsmanagement und die verschiedenen
Kommunikationswerkzeuge (NCU, SipaxCom) in BahnsimDB gekapselt und unterliegen der
Verantwortung von BahnsimDB. Zusätzlich ist das Modul dadurch unabhängig von den un-
terschiedlichen Stellwerkszusammenschlüssen.
- 65 -
6.2 Aufbau des Gesamtsystems
Das neue Gesamtsystem besteht aus der ETCS- und Fahrdienstleiterschulungsanlage, die je-
weils um einige Komponenten erweitert worden sind (Abb. 48). Die Übertragungstechnolo-
gien haben sich in beiden Systemen nicht verändert. Die ETCS-Schulungsanlage nutzt wei-
terhin die Middleware Talarian® SmartSockets und die Fahrdienstleiterschulungsanlage die
Technologien Pipes und Sockets zur internen Kommunikation.
Abb. 48 Architektur der ETCS- und Fahrdienstleiterschulungsanlagenkoppelung
Die TuS besteht aus den Standardkomponenten für eine Schulungsanlage, zu denen TCTL,
SCCO, SQLT, RISI, TRPR, TSCB, MVBG, EVSS, OBUD, TDGW sowie TDAP gehören.
Neu hinzu kommt der SOGW, der eine Schnittstelle zur Fahrdienstleiterschulungsanlage be-
reitstellt. Über diese Schnittstellen erhält er Daten, die er an den SCCO weiterleitet. Dort wer-
den die Daten an die interaktive Ruby-Shell übergeben und von der TuS interpretiert. Über
den SOGW können aber auch Daten an das externe System übermittelt werden, die der SCCO
sendet. Zusätzlich wurde die TuS um die Verbindung zu einem RBC erweitert. Über diesen
Kanal tauscht der simulierte Zug mit dem RBC ETCS-Daten für Level 2 und 3 aus.
Die Fahrdienstleiterschulungsanlage besitzt als Schnittstelle zur ETCS-Schulungsanlage den

EFS-Gateway, mit dessen Hilfe Daten empfangen und gesendet werden. Die Aufgabe des
- 66 -
Moduls ist die Weiterleitung von Stellwerksinformationen und von Daten für die Zugsteue-
rung. Dazu besitzt sie eine Verbindung zum A2Mapper und zur Zugsimulation. Innerhalb von
BahnsimDB befindet sich die Zugsimulation, die zwischen konventionellen und ETCS-Zügen
unterscheidet. Konventionelle Züge werden nur in der Fahrdienstleiterschulungsanlage darge-
stellt, ETCS-Züge hingegen nur in der ETCS-Schulungsanlage.
Die Tesys ist in diesem Schulungssystems eine Neuentwicklung, um den Stellwerkstyp

SIMIS D simulieren zu können. Ein wichtiger Teil dieses Stellwerks ist der A2Mapper, der
Namen und Zustände von Außenanlagenelementen der Fahrdienstleiterschulungsanlage in
Namen und Zustände von Außenanlagenelementen der ETCS-Schulungsanlage übersetzt.
Dafür erhält der A2Mapper über die Tesys-Komponente ProVis die notwendigen Informatio-
nen, die mit den einzelnen Außenelementen verbunden ist. Der A2Mapper besitzt eine Ver-
bindung zum EFS-Gateway, über die er die übersetzten Elementzustände sendet. Diese Daten
werden schließlich über den EFS-Gateway an die ETCS-Schulungsanlage weitergeleitet. Eine
weitere Funktion des A2Mappers ist, konkrete Anfragen nach Außenelementübersetzungen
von der Zugsimulation in BahnsimDB zu beantworten. Dazu wird ihm zum einen der Ele-
mentname eines Systems mitgeteilt und zum anderen das System, aus dem der entsprechende
Name durch den A2Mapper ermittelt werden soll. An Tesys ist zusätzlich ein RBC ange-
schlossen, an das es Signal- und Weicheninformationen sendet, damit aus ihnen ETCS-Daten
generiert werden.
6.2.1 Identifikation der neuen Schnittstellen
Zwischen den beiden Schulungsanlagen und innerhalb der Systeme gibt es neue Schnittstel-
len, die sich durch den Zusammenschluss herausgebildet haben. In der folgenden Tabelle
(Tab. 16) sind die Schnittstellen mit ihren Kommunikationspartnern aufgelistet und werden
im weiteren Verlauf der Designkonzeptbeschreibung näher betrachtet.
Schnittstelle Status Kommunikationspartner
Neu SOGW EFS-Gateway
Neu EVSS RBC
Neu RBC Tesys
Neu EFS-Gateway A2Mapper
Neu Zugsimulation A2Mapper
- 67 -
Schnittstelle Status Kommunikationspartner
Neu Zugsimulation EFS-Gateway
Tab. 16 Identifikation der Schnittstellen
6.2.2 Anforderungszuordnung zu den Schnittstellen und Komponenten
Für die Spezifikation und das Design der Schnittstelle zwischen ETCS- und Fahrdienstleiter-
schulungsanlage ist es notwendig, den Anforderungskatalog aus dem Kapitel 5, den neuen
Schnittstellen und den Komponenten beider Systeme zuzuordnen. Die entsprechende Über-
sicht ist im Anhang der Anlage B hinterlegt. Anhand dieser Zuordnung ist erkennbar, welche
Maßnahmen in bestimmten Systemteilen durchzuführen sind, um die Koppelung beider Schu-
lungssysteme durchzuführen.
6.3 Schnittstellenbeschreibung
Mit Hilfe der Schnittstellenanforderungen und den Lösungsansätzen ist es möglich, die
Schnittstellen genau zu definieren bzw. zu beschreiben. Da noch keine Implementierung statt-
gefunden hat, kann im Anhang der Anlage C nachgelesen werden, wie die Befehle auf dieser
Schnittstelle aussehen könnten.
Die Informationen werden über die Schnittstelle als sequentieller Datenstrom gesendet und
müssen voneinander getrennt werden können. Aus diesem Grund wird ein Befehl immer mit
dem Zeichen „0x0A“ abgeschlossen.
6.3.1 Schnittstelle zwischen SOGW und EFS-Gateway
Die nachfolgende Tabelle (Tab. 17) zeigt, welche Aktionen auf dieser Schnittstelle durchge-
führt werden und in welche Richtung diese Aktionen stattfinden.
Datenflussrichtung
Bereich Aktion
SOGW ? EFS-Gateway
Zug einsetzen
Zug Zug entfernen
Zugposition senden
Streckentopologie Signalbegriff einstellen
- 68 -
Datenflussrichtung
Bereich Aktion
SOGW ? EFS-Gateway
ETCS Balisentelegramm einstellen (Level 1)

TuS-Steuerung
Streckenelemente (Signal, Weiche,

Synchronisation
Balise)
Tab. 17 Kommunikation zwischen SOGW und EFS-Gateway
Zug einsetzen
Um einen Zug von BahnsimDB aus in beide Streckentopologien einsetzen zu können, sind
bestimmte Parameter notwendig. Die ETCS-ID ist eine Identifikationsnummer für die ETCS-
Einheit an Board eines Zuges. Jede ETCS-Einheit hat eine eindeutige Nummer. Sie ist z.B.
notwendig, um den Zug in Level 2 über eine RBC zu identifizieren. Zusätzlich ist es wichtig,
dass bei der Zugerzeugung der Zugtyp angegeben wird. Dieser muss in der TuS existieren,
weil er sonst nicht eingesetzt werden kann. Für die Positionsangabe ist die Angabe von Zug-
kopf und Zugende mit Angabe der nächstliegenden Weiche in Fahrtrichtung und dem Wei-
chenstrang notwendig. Für den Fall, dass sich der Zug auf einer Weiche befindet, ist es wich-
tig, dass zwei Weichenreferenzen für die beiden Zugenden angegeben werden.
Parameter Datentyp
ETCS-ID String
Zugtyp String
Nächste Weiche mit Namen für den Zugkopf String
Weichenstrang String
Entfernung des Zugkopfes von der Weiche Double
Nächste Weiche mit Namen für das Zugende String
- 69 -
Parameter Datentyp
Entfernung des Zugendes von der Weiche Double
Tab. 18 Parameter für das Einsetzen eines Zuges
Um Züge innerhalb von BahnsimDB und der TuS referenzieren zu können, müssen in beiden
Systemen identische eindeutige interne Zug-IDs vergeben werden. Nach erfolgreichem Ein-
setzen des Zuges in die TuS, muss der Fahrdienstleiterschulungsanlage eine Quittierung ge-
sendet werden. Diese Quittierung enthält die Zug-ID.
Zug entfernen
Das Entfernen eines Zuges aus der Zugsimulation erfolgt über den Parameter der internen
Zug-ID. In BahnsimDB und TuS sind diese IDs für einen bestimmten ETCS-Zug identisch.
Dadurch ist es möglich, einen spezifischen Zug in beiden Systemen gleichzeitig zu entfernen.
Die TuS hat die Aufgabe, nach erfolgreichem oder fehlgeschlagenem Entfernen der Fahr-
dienstleiterschulungsanlage, eine Quittierung zu schicken
Parameter Datentyp
Zug-ID Integer
Tab. 19 Parameter für das Löschen eines Zuges
Zugposition senden
Von der TuS werden die Bewegungsinformationen des ETCS-Zuges an BahnsimDB gesen-
det. Befinden sich mehrere Züge in der TuS, muss abgesichert sein, dass nur ein bestimmter
Zug bewegt wird. Deshalb muss immer eine interne Zug-ID für den Zug angegeben werden.
Über die weiteren Parameter gibt die TuS die Zugposition mit Hilfe des Zugkopfes und Zug-
endes an.
Parameter Datentyp
Zug-ID Integer
Nächste Weiche mit Namen für den Zugkopf String
Entfernung des Zugkopfes von der Weiche Double
- 70 -
Parameter Datentyp
Nächste Weiche mit Namen für das Zugende String
Entfernung des Zugendes von der Weiche Double
Tab. 20 Parameter für die Zugbewegung
Signalbegriff einstellen
Um einen Signalbegriff an einem Signal einzustellen, sind der Stellwerksname, der Name des
Signals und der entsprechende Signalbegriff anzugeben. In der TuS können Signale nur über
das Stellwerk verändert werden, mit dem sie verbunden sind.
Parameter Datentyp
Stellwerksname String
Signalname String
Signalbegriff Integer
Tab. 21 Parameter für das Einstellen eines Signals
Eine Weiche kann über den Namen des Stellwerks eingestellt werden, an das sie angeschlos-
sen ist. Zusätzlich ist der Weichenname und die entsprechende Weichenstellung anzugeben.
Parameter Datentyp
Stellwerksname String
Weichenname String
Weichenlage Integer
Tab. 22 Parameter für das Stellen einer Weiche
Balisentelegramm einstellen (ETCS-Level 1)
Für das Einstellen eines Balisentelegramms ist das Telegramm anzugeben. In einer Balise
können bis zu 256 verschiedene Telegramme hinterlegt sein. Mit der Angabe der Telegramm-
nummer wird ein bestimmtes Telegramm aktiviert.
- 71 -
Parameter Datentyp
Stellwerksname (nur Nutzung eines MSTT) String
Balisenname String
Balisentelegrammnummer Integer
Tab. 23 Parameter für das Einstellen eines Balisentegrammes
Um die TuS zu Beginn der Simulation in einen definierten Zustand zu bringen, wird sie über
die Befehlszeichenkette „initTus“ initialisiert. Die TuS startet daraufhin die TuS-Prozesse
SCCO, SQLT, RISI und TRPR. Anschließend meldet sie der Zugsimulation in BahnsimDB
mit der Antwort „initTusOk“, dass sie die Initialisierung beendet hat.
Die TuS kann durch die Befehlszeichenkette „resetTus“ zurückgesetzt werden. Die TuS
stoppt daraufhin alle TuS Prozesse bis auf TCTL und den SOGW und wartet auf neue Befeh-
le.
Für den Zusammenschluss beider Schulungsanlagen ist es wichtig, dass die Streckentopologie
synchronisiert werden kann. In beiden Systemen befinden sich Elemente, die unterschiedliche
Namen und Zustände besitzen. Damit in der TuS die Streckenelemente die gleichen Zustände
besitzen, kann von der Tesys aus eine Synchronisation eingeleitet werden. Die Kommunikati-
on geht dafür den Weg vom A2Mapper über den EFS-Gateway zum SOGW. Für die Syn-
chronisation werden der gleiche Befehlssatz und die gleiche Befehlsabfolge wie im TuS-
Tesys-Projekt (siehe Kapitel 3.3.3) verwendet.
6.3.2 Schnittstelle zwischen EVSS und Tesys
Die Kommunikation zwischen der EVSS und Tesys findet über ein reales oder simuliertes
RBC statt. Über diese Schnittstelle werden original Daten für Level 2 und Level 3 übertragen.
Diese Schnittstelle wurde bereits in durch die UNISIG spezifiziert. Die Verbindungsverwal-
tung zwischen RBC und Triebfahrzeug sowie die Daten sind in der „Software Requirement
Specification“ [UNI03] [UNI07] beschrieben.
- 72 -
6.3.3 Schnittstelle zwischen EFS-Gateway und A2Mapper
Die nachfolgende Tabelle (Tab. 24) zeigt, welche Aktionen über diese Schnittstelle ablaufen.
Datenflussrichtung
Bereich Aktion
EFS-Gateway ? A2Mapper
Signalbegriff einstellen
Streckentopologie
Balisentelegramm einstellen
ETCS
(Level 1)
Streckenelemente
Synchronisation
(Signal, Weiche, Balise)
Tab. 24 Kommunikation zwischen EFS-Gateway und A2Mapper
Der A2Mapper sendet dem EFS-Gateway Zustände der Streckenelemente Weiche, Signal und
Balise, die er vom Stellwerk erhält. Bevor der A2Mapper die Information jedoch sendet, wer-
den die Streckenelemente von Stellwerksbezeichnungen in TuS-Bezeichnungen mit Hilfe
einer Mapping-Tabelle umgewandelt. Damit der A2Mapper seine Mapping-Aufgabe erfolg-
reich durchführt, kann er die Elemente Stellwerk, Weiche, Signal, Balise, Signalbegriff und
Weichenstellung übersetzen. Die Daten, die der A2Mapper zum EFS-Gateway sendet, sind
genauso aufgebaut wie die Daten für das Einstellen der Weiche, des Signals und der Balise
zwischen SOGW und EFS-Gateway (siehe Kapitel 6.3.1).
6.3.4 Schnittstelle zwischen Zugsimulation und A2Mapper
Die Zugsimulation ist in der Lage, die Bezeichnungen von bestimmten Stellwerkselementen
beim A2Mapper zu erfragen, wie z.B. von Weichen. Diese Abfrage ist notwendig, wenn ein
Zug in beiden Simulation eingesetzt werden soll bzw. sich die Zugposition ändert. Bei der
Kommunikation zwischen Zugsimulation und A2Mapper handelt es sich um einen asynchro-
nen Datenaustausch.
Unter dieser Art der Kommunikation ist ein Datentransfer zu verstehen, bei dem der erfragen-
de Prozess nicht auf eine Antwort wartet bevor er eine neue Anfrage stellen kann. Der Vorteil
ist, dass der erfragende Prozess bei zeitkritischen Ausführungen nicht blockiert.
- 73 -
Eine Nachricht zwischen beiden Komponenten besteht aus sechs Feldern, deren Bedeutungen
in der Tab. 25 beschrieben sind. Die Zugsimulation sendet immer eine Nachricht vom Typ
„Anfrage“ und der A2Mapper immer eine vom Typ „Antwort“. Es wird von der Zugsimulati-
on zu Beginn die Übersetzungsrichtung festgelegt, indem der entsprechende Wert im Feld
gesetzt wird. Die Längenfelder geben an, wie groß das nächste Feld ist, in dem der Strecken-
elementname gespeichert ist. Dadurch ist die Länge des Elementnamens dynamisch. Bei einer
Anfrage durch die Zugsimulation ist das Feld, das den Streckenelementnamen vom
A2Mapper enthält, Null Byte lang und wird bei einer Antwort vom A2Mapper gefüllt.
Feldbezeichnung Länge [Byte] Datentyp Wert
Nachrichtentyp 1 Integer 0 = Anfrage / 1 = Antwort
0 = TuS zu Stellwerk
Übersetzungsrichtung 1 Integer
1 = Stellwerk zu TuS
Länge des nächsten Feldes 1 Integer 0 – 255
Streckenelementname von
dynamisch String ‚Zeichenkette’
BahnsimDB
Länge des nächsten Feldes 1 Integer 0 – 255
Streckenelementname vom
dynamisch String ‚Zeichenkette’
A2Mapper
Tab. 25 Datenpaket zwischen BahnsimDB und A2Mapper
6.3.5 Schnittstelle zwischen Zugsimulation und EFS-Gateway
Auf der Schnittstelle zwischen Zugsimulation und EFS-Gateway werden die Datenflüsse in
der nachfolgenden Tabelle (Tab. 26) dargestellt.
Datenflussrichtung
Bereich Aktion
Zugsimulation ? EFS-Gateway
Zug einsetzen
Zug Zug entfernen
Zugposition senden
Tab. 26 Kommunikation zwischen Zugsimulation und EFS-Gateway
- 74 -
Die Daten liegen in gleicher Form vor wie auf der Schnittstelle zwischen SOGW und EFS-
Gateway. Da die Daten über einen Gateway gesendet werden, findet nur eine Weitergeleitung
der Daten statt, aber keine Veränderung. Die Zugsimulation in BahnsimDB hat die Aufgabe,
Züge einzusetzen, zu löschen, zu bewegen sowie die Bewegung eines Zuges zu senden.
- 75 -
Testkonzept und prototypische Entwicklung
7 Testkonzept und prototypische Entwicklung
Ein wichtiger Gedanke während der Softwareentwicklung sollte sein, wie spätere Tests für
das System aussehen können. Die Tests in der Entwicklung von Softwaresystemen haben ei-
nen großen Einfluss auf die Qualitätssicherung. Sie gewährleisten, dass das Testobjekt voll-
ständig definiert ist. Fallen Tests negativ aus, muss die Implementierung überarbeitet und neu
angepasst werden.
Um frühzeitig Fehler zu erkennen, gibt es für die unterschiedlichen Phasen der Softwareent-
wicklung signifikante Tests. Beispiele hierfür sind die Unit-, Funktions-, Integrations-,
Regressions- und System- sowie Betreibbarkeitstest. Jeder von ihnen überprüft einen be-
stimmten Bereich der Software bzw. des Softwaresystems.
Dieses Kapitel befasst sich mit dem Funktionstest der Schnittstelle zwischen ETCS- und
Fahrdienstleiterschulungsanlage. Er gibt Aufschluss darüber, ob die spezifizierten Anforde-
rungen an die Schnittstelle erfüllt worden sind. Darüber hinaus werden in diesem Kapitel ein
Testkonzept und eine prototypische Softwareentwicklung vorgestellt, mit denen der Funkti-
onstest durchgeführt werden kann. Das Klassendiagramm des Prototyps ist im Anhang der
Anlage D hinterlegt. Anschließend wird beschrieben, welche Test im Einzelnen durchzufüh-
ren sind.
7.1 Beschreibung des Testkonzepts
Ziel des Tests ist, die Schnittstellen zur ETCS- und Fahrdienstleiterschulungsanlage vor der
Integration der beiden Systeme zu überprüfen. Dazu sind jeweils beide Systeme als eine
„Black-Box“ anzusehen und deren Schnittstellen zu untersuchen (Abb. 49).
Abb. 49 Schnittstellentest aus Sicht des Tools SocketTest
- 76 -
Die Basis für die Überprüfung der Schnittstellen ist die prototypische Entwicklung des Soft-
waretools SocketTest, das an eine der Schulungsanlagen angeschlossen wird. Dabei verbindet
sich das Tool mit der Schnittstelle, die getestet werden soll. Es kann Daten an das zu testende
System senden und vom System empfangen. Auf jede Aktion an der Schulungsanlage wird
mit Hilfe des Tools eine bestimmte Reaktion über diese Schnittstelle erwartet. Die Ergebnisse
werden aufgezeichnet und können in einem Ist-Soll-Vergleich gegenübergestellt und ausge-
wertet werden.
7.2 Entwurf eines Prototypen zum Test der Schnittstelle
Um die Schnittstelle der jeweiligen Schulungsanlage mit dem Tool überprüfen zu können,
müssen einige Funktionen des Prototyps in Form von Anforderungen beschrieben werden.
7.2.1 Anforderungen
SocketTest ist ein Tool für den Test der Schnittstelle zu den Zielsystemen SOGW der TuS
und dem EFS-Gateway von BahnsimDB. Er erhält seine Daten wahlweise aus einer Datei
oder über einen Eingabeprompt und kann diese über eine TCP-Schnittstelle an eines der Ziel-
systeme senden. Eigene gesendete Daten sowie Reaktionen des Kommunikationspartners über
diese Schnittstelle werden in einer separaten Datei mitgeschrieben und in der Textkonsole
angezeigt.
Das Programm SocketTest ist eine Window-basierte Anwendung, die die Möglichkeit besitzt,
eine Socket-Verbindung als Server bereitzustellen oder sich als Client mit einem Kommuni-
kationspartner zu verbinden. Die Anwendung besteht aus zwei parallelen Ausführungssträn-
gen (Multithreading), mit denen es gleichzeitig Daten von der Socket-Verbindung lesen und
über diese Verbindung schicken kann. Bedingt durch das parallele Mitschreiben der Sende-
und Empfangsdaten in einer Datei ist es notwendig, den beiden Ausführungssträngen exklusi-
ven Zugriff auf diese Ressource zu erlauben.
Der SocketTest soll mindestens auf einem Rechner mit einem Intel Pentium IV-Prozessor 2,0
GHz und 512 Megabyte RAM laufen. Als Betriebssystem ist Windows XP vorgesehen, das
mit dem Service Pack 2 ausgestattet ist.
- 77 -
Es wird über die Textkonsole konfiguriert, indem Übergabeparameter angegeben werden kön-
nen. In Tab. 27 sind diese kurz zusammengefasst.
Parameter Beschreibung Defaultwert
/S:<ip> Angabe des Zielrechners 127.0.0.1
/P:<port> Angabe des Ports 1234
/L:<log flag> Ein- und Ausschalten der Datenerfassung true
/I:<input file> Angabe der Datei, die zeilenweise gesendet werden soll. -
Mit dem Parameter wird festgelegt, ob die Software als Client

/M:<modus>
Socket-Server oder Socket-Client gestartet wird.
Es wird ein Hilfetext über die möglichen Parametersätze -

/H
ausgegeben.
/V Der Parameter gibt die Version des Prototyps aus. -
Tab. 27 Prototyp - Übergabeparameter
Die gesendeten und empfangenen Daten werden in einer Datei aufgezeichnet und können
nach Abschluss des Tests ausgewertet werden. Die Datei besteht aus einzelnen Datensätzen,
die zeilenweise untereinander angeordnet sind. Jeder Datensatz setzt sich aus den folgenden
Teilen zusammen:
• Zeitstempel als Uhrzeit (bestehend aus Stunde, Minute und Sekunde)
• Kennzeichnung, ob es sich um Sende- oder Empfangsdaten handelt
• Sende- oder Empfangsdaten
Der Dateiname trägt zur Identifikation eine eindeutige Bezeichnung. Er besteht aus dem aktu-
ellen Datum, der Uhrzeit des Erstellzeitpunktes und dem Modus.
7.2.2 Funktionsweise des Prototypen
Das Programm SocketTest kann über seine Parametersätze beim Programmstart individuell
gestartet werden.
Bsp.: SocketTest.exe /P:4343 /I:testSkript.txt /M:server
Der Prototyp initialisiert in diesem Beispiel zunächst das Programm, indem die Übergabepa-
rameter beim Programmstart analysiert werden und die Datenaufnahme in eine Datei aktiviert
- 78 -
wird. Danach startet er den Übergabeparametern entsprechend einen Socket-Server auf dem
lokalen Rechner, der über den Port 4343 erreichbar ist. Nachdem sich ein Client mit ihm ver-
bunden hat, kann er die erste Zeile aus dem Skript testSkript.txt senden. Mit Betätigung der
Eingabetaste wird eine neue Zeile aus der Datei ausgelesen und an den Kommunikationspart-
ner gesendet.
7.3 Durchzuführende Tests
Aufgrund der noch durchzuführenden Implementierung in der ETCS- und Fahrdienstleiter-

schulungsanlage durch die Entwickler der beiden Systeme, ist es schwierig, konkrete Tests zu
beschreiben. Aus diesem Grund werden allgemeine Testfälle genannt und dargestellt, die
durch die jeweiligen Tester verfeinert werden müssen. Für beide Anlagen wird jeweils das
Tool SocketTest angeschlossen. Es sind dabei die folgenden Funktionen zu testen:
• Zug einsetzen
• Zug entfernen
• Zugposition senden
• Signal stellen
• Weiche stellen
• Balisentelegramm schalten
• Einleiten der Systeminitialisierung
• Zurücksetzen des Systems
• Synchronisation der Streckenelemente
Die Details für die einzelnen Funktionstests sind im Anhang der Anlage E hinterlegt und kön-
nen nachgelesen werden.
- 79 -
Zusammenfassung
8 Zusammenfassung
In diesem Kapitel werden die Ergebnisse der Schnittstellenspezifikation und des Schnittstel-
lendesigns zusammengefasst. Außerdem wird für das Projekt ein Ausblick gegeben, der zei-
gen soll, was nach dieser Arbeit für Schritte folgen müssen.
8.1 Erreichter Stand
Der Aufgabenstellung zufolge wurde eine Schnittstelle zwischen ETCS- und Fahrdienstleiter-
schulungsanlage entwickelt, die speziell für die Interprozesskommunikation dieser beiden
Schulungssysteme verantwortlich ist.
Des Weiteren wurden Probleme erörtert, die dem Zusammenschluss entgegenstehen. Zu ihnen
gehörten:
• Probleme bei der Namens- und Zustandssynchronisation der Außenanlage
• Verwendung unterschiedlicher Zugtypen in beiden Systemen
• Probleme bei der Zugpositionsbestimmung, weil unterschiedlich aufgebaute Strecken-

topologien existieren und Informationen in der Datenbasis fehlen
• Schwierigkeiten, um bestimmte Daten einer ähnlichen Schnittstelle wieder zu verwen-

den
Für diese Probleme wurden optimale Lösungen erarbeitet, die auch auf Konzepte bereits vor-
handener Projekte zurückgreifen.
Um die Schnittstelle umsetzen zu können, mussten Anforderungen an die ETCS- und Fahr-
dienstleiterschulungsanlage formuliert werden. Diese Anforderungen beziehen sich auf die
Schnittstellendaten und auf die Komponenten in den Schulungssystemen.
Eine Beschreibung des neuen Gesamtsystems zeigt, wie das System aufgebaut sein soll und
wie es funktionieren wird. In diesem Zusammenhang wird u.a. genau veranschaulicht, welche
Daten auf der Schnittstelle gesendet werden müssen. Die Daten werden durch Aktionen zwi-
schen den Systemen übermittelt. Zu den Aktionen gehören:
• Zug einsetzen
• Zug entfernen
• Zugposition senden
- 80 -
Zusammenfassung
• Signalbegriff einstellen
• Weichenstellung verändern
• Balisentelegramm einstellen (Level 1)
• RBC-Daten austauschen (Level 2)
• Einleiten der Systeminitialisierung
• Zurücksetzen des Systems
• Synchronisation der Streckenelemente (Signal, Weiche, Balise)
Zusätzlich wurden Funktionstests für jeden dieser Vorgänge definiert. Die Tests beschreiben
einen bestimmten Befehlsstring, der über die Schnittstelle zu senden ist, und die zu erwarten-
de Reaktion des zu testenden Systems. Für die Durchführung dieser Test, wurde im Rahmen
der Masterarbeit ein Prototyp entwickelt, der die Schnittstellen beider Systeme überprüfen
kann.
8.2 Ausblick
Dieses Dokument bildet die Basis für den Zusammenschluss der beiden Schulungsanlagen
und dient als Rahmen für die Realisierung des Projektes. Es enthält das Grundkonzept des
neuen Gesamtsystems und die damit verbundenen neuen Anforderungen. Bei der Entwicklung
des Grundkonzeptes, wurden regelmäßige Rücksprachen mit den Entwicklern gehalten, um
den Zusammenschluss später auch umsetzen zu können.
Als nächsten Schritt sollte das neue Gesamtkonzept den Schulungsanlagenentwicklern in Ber-
lin und Braunschweig in einem gemeinsamen Meeting vorgestellt werden. Danach könnte die
Umsetzung der Erweiterungen, der Anlagentest und letztendlich die Systemintegration erfol-
gen.
Sind die beiden Schulungsanlagen dann schließlich miteinander verbunden, ist es denkbar,
parallel Triebfahrzeugführer und Fahrdienstleiter auszubilden. Als dieses Dokument angefer-
tigt wurde, konnte jedoch nur ein Triebfahrzeugführer an der ETCS-Schulungsanlage geschult
werden. An dieser Stelle müsste die ETCS-Schulungsanlage weiterentwickelt werden, damit
wie in der Fahrdienstleiterschulungsanlage mehrere Schüler gleichzeitig ausgebildet werden
können.
- 81 -
Literaturverzeichnis
[Pac04] Pachl, Jörn
Systemtechnik des Schienenverkehrs 4. Auflage
Teubner Verlag, 2004
[SBB04] Alstom, Inovex/Steag, SBB
ERTMS/ETCS-Systemaufbau und –Komponenten (P1/P2)
SBB AG, 4. Juni 2004
[SIC07] Instandhaltungshinweise für El S Simis C (DB AG) Typ 9
Siemens AG, 8. Mai 2007
[SID07] Instandhaltungshinweise für El S in Version Simis D
Siemens AG, November 2007
[MVB03] Giolda
Einführung in die Kommunikation mit TCN bei Siemens TS
Siemens AG, 10. November 2003
[Fie06] Fiedler, Remo
System Architecture Specification Testsystem TuS
Siemens AG, Berlin, 2. Mai 2006
[Neß06] Neß, Holger
User Guide for the Test and Simulation Tool of ETCS Components (TuS)
Siemens AG, Berlin, 13. Dezember 2006
[Rub02] Röhrl, Armin; Schmiedl, Stefan und Wyss, Clemens
Programmieren mit Ruby
dpunkt.verlag, Heidelberg, 2002
- 82 -
[Bakke] Prof. David E. Bakken
Middleware
Washington State University
[Tal99] SmartSockets User’s Guide Version 5.2
Talarian Corporation, 1999
[Ber07] Berndt, Werner
System-/SW-Architekturspezifikation
Siemens AG, Braunschweig, 11. Januar 2007
[Ber05] Berndt, Werner
Schnittstelle BahnsimDB – Bedienplatznetz
Siemens AG, Braunschweig, 01. September 2005
[GeS06] GeSim SIMIS C
Siemens AG, 10. Oktober 2006
[Pra07] PRADES – Allgemein
[Int05] Berndt, Werner
Schnittstelle BahnsimDB - DB
Siemens AG, Braunschweig, 06. September 2005
[Stw05] Berndt, Werner
Schnittstelle BahnsimDB - Stellwerksnetz
Siemens AG, Braunschweig, 20. Juni 2005
[Krö05] Kröger, Simon
Software Design Specification Socket Gateway HSL (SOGW)
Siemens AG, Berlin, 25. April 2004
- 83 -
[Sch06] Schurr, Matthias
A2Mapper
Siemens AG, Braunschweig, 30. Oktober 2006
[Bei05] Beier
SIG Anforderungsspezifikation Integration Testsystem
Siemens AG, 05. August 2005
[UNI03] UNISIG
System Requirement Specification Chapter 3
UNISIG, 1. Februar 2002
[UNI07] UNISIG
System Requirement Specification Chapter 7
UNISIG, 1. Februar 2002
[PRO06] PROSIM – Modellierung der Außenanlage
[Ole07] Oleneva, Marina
Schnittstellenspezifikation EPOS-XML
Siemens AG, Berlin, 16. Februar 2007
- 84 -
Schlusserklärung
Ich versichere, dass ich die vorliegende Arbeit selbstständig ohne fremde Hilfe verfasst und
keine anderen als die angegebenen Quellen und Hilfsmittel verwendet habe.
Die eingereichte Arbeit wurde bisher in gleicher oder ähnlicher Form nicht anderweitig als
Prüfungsleistung verwandt.
Berlin, 08.10.2008
- 85 -
Anhang
Anlagenverzeichnis
Anlage A: Schnittstelle zwischen TuS und Tesys ....................................................................87
Anlage B: Anforderungszuordnung zu den Schnittstellen und Komponenten.........................89
Anlage C: Schnittstelle zwischen ETCS- und Fahrdienstleiterschulungsanlage......................90
Anlage D: Klassendiagramm des Prototyps zum Test der Schnittstelle ..................................92
Anlage E: Schnittstellentests ....................................................................................................93
Anlage F: CD-Übersicht...........................................................................................................97
- 86 -
Anlage A: Schnittstelle zwischen TuS und Tesys
Zug einsetzen
Tesys an TuS: train = Train.create(‚ETCS-ID’,Zugtyp,Position.new(Name des Gleises auf /
dem der Zugkopf steht, Position),Position.new(Name des Gleises auf dem /
das Zugende steht,\Position))
Zuggeschwindigkeit vorgeben
Tesys an TuS: train.increaseSpeed(Zielgeschwindigkeit,Beschleunigung)
Tesys an TuS: train.decreaseSpeed(Zielgeschwindigkeit,Verzögerung)
Zugposition senden (Gleisfreimeldung)
TuS an Tesys: command(Abschnitt,Zustand)
Tesys an TuS: #!track.setElement(‚Element-ID’, state)
Tesys an TuS : initTus
Antwort von TuS: initTusOk
Tesys an TuS: resetTus
Mitschreiben von Daten einschalten/ausschalten
Tesys an TuS: TestcaseStart(Zielpfad)
Tesys an TuS: TestcaseEnd(Zielpfad)
1. Tesys an TuS: synchronizeElements
2. TuS an Tesys: sendAllStates
- 87 -
3. Tesys an TuS: #!allStatesTransmitted
4. TuS an Tesys: Ok: synchronizeElementsOk
Fehler: Element-Typ Element-ID is not initialized
synchronzeElements: error(s) occured
- 88 -
Anlage B: Anforderungszuordnung zu den Schnittstellen und Komponenten
Anforderungszuordnung zu den Schnittstellen
Schnittstelle Anforderung
/ANF010/, /ANF020/, /ANF030/, /ANF040/, /ANF050/, /ANF060/,

/ANF300/, /ANF310/
/ANF070/
/ANF070/
/ANF040/, /ANF050/, /ANF060/, /ANF280/, /ANF300/, /ANF310/
/ANF280/, /ANF290/, /ANF300/, /ANF310/
/ANF010/, /ANF020/, /ANF030/, /ANF300/, /ANF310/
Anforderungszuordnung zu den Komponenten
Komponente Anforderung

TuS
/ANF220/, /ANF230/, /ANF240/

BahnsimDB /ANF180/, /ANF190/, /ANF200/, /ANF210/, /ANF220/, /ANF230/,
/ANF250/
Tesys /ANF260/, /ANF270/, /ANF280/
- 89 -
Anlage C: Schnittstelle zwischen ETCS- und Fahrdienstleiterschulungsanlage
Im Folgenden sind die Befehle für die Schnittstelle zwischen ETCS- und Fahrdienstleiter-
schulungsanlage beschrieben. Da noch keine Implementierung der Schnittstelle stattgefunden
hat, stellt diese Befehlsdarstellung eine mögliche Lösung dar.
Zug einsetzen
FDLS an ETCS: train = Train.create(‚ETCS-ID’,Zugtyp,Position.new(Nächste Weiche mit\
Namen für den Zugkopf,Weichenstrang,Entfernung),Position.new(Nächste\
Weiche mit Namen für das Zugende,Weichenstrang,Entfernung))
ETCS an FDLS: insertTrainOk(Zug-ID)
Zug entfernen
FDLS an ETCS: removeTrain(Zug-ID)
ETCS an FDLS: removalTrainOk(Zug-ID)
Zugposition senden
FDLS an ETCS: trainPosition(Zug-ID, Nächste Weiche mit Namen für den Zugkopf,\
Weichenstrang,Entfernung,Nächste Weiche mit Namen für das Zugende,\
Weichenstrang, Entfernung)
FDLS an ETCS: #!track.setElement(Element-ID’, state,Interlocking-ID)
Interlocking-ID ist ein optionaler Parameter, da Balisen keinem Stellwerk zugeordnet sind.
FDLS an ETCS: initTus
ETCS an FDLS: initTusOk
FDLS an ETCS: resetTus
- 90 -
1. FDLS an ETCS: synchronizeElements
2. ETCS an FDLS: sendAllStates
3. FDLS an ETCS: #!allStatesTransmitted
4. ETCS an FDLS: Ok : synchronizeElementsOk
Fehler: Element-Typ Element-ID is not initialized
synchronzeElements: error(s) occured
- 91 -
Anlage D: Klassendiagramm des Prototyps zum Test der Schnittstelle
- 92 -
Anlage E: Schnittstellentests
Zug einsetzen
Aktion: In BahnsimDB wird ein ETCS-Zug eingesetzt.
Reaktion: Der entsprechende Befehl wird über diese Schnittstelle geschickt.
Zug entfernen
Aktion: In BahnsimDB wird ein ETCS-Zug gelöscht
Reaktion: Der entsprechende Befehl wird über diese Schnittstelle geschickt.
Zugposition senden
Aktion: Es wird von SocketTest ein Befehl gesendet, der einen vorhandenen ETCS-Zug
in BahnsimDB auf eine neue Position setzt.
Reaktion: Der Zug wird in BahnsimDB auf eine neue Position gesetzt.
Signal stellen
Aktion: In BahnsimDB wird ein Signal auf „Fahrt“ gestellt.
Reaktion: Über die Schnittstelle wird ein Befehl empfangen, der das entsprechende TuS-
Signal auf „Fahrt“ setzt.
Weiche stellen
Aktion: In BahnsimDB wird eine Weiche auf „Linkslage“ gestellt.
Reaktion: Über die Schnittstelle wird ein Befehl empfangen, der die entsprechende TuS-
Weiche auf „Linkslage“ setzt.
- 93 -
Balisentelegramm schalten
Aktion: Es wird in BahnsimDB ein Signal auf „Fahrt“ gestellt, an dem eine Transparent-
balise angeschlossen ist.
Reaktion: Der entsprechende Befehl wird empfangen, der die Balisentelegrammnummer

enthält.
Aktion: BahnsimDB setzt das TuS-System mit dem Befehl „resetTus“ zurück.
Reaktion: Mit Hilfe des Tools SocketTest wird auf dieser Schnittstelle der Befehl „initTus“
empfangen.
Aktion: In BahnsimDB wird ein ETCS-Zug eingesetzt.
Reaktion: Der Befehl „resetTus“ wird auf dieser Schnittstelle empfangen.
Aktion: Der A2Mapper löst eine Synchronisation aus, indem er den Befehl „synchroni-
zeElements“ absendet.
Reaktion: Der Befehl „synchronizeElements“ wird auf der Schnittstelle empfangen.
- 94 -
Zug einsetzen
Aktion: Es wird mit Hilfe von SocketTest der Befehl gesendet, um einen Zug in die TuS
einzusetzen.
Reaktion: In der TuS werden die Prozesse EVSS, OBUD, TSCB, TDGW, TDAP und
MVBG gestartet. Nach erfolgreichem Einsetzen des Zuges wird von der TuS die
Quittierung „insertTrainOk(Zug-ID)“ gesendet.
Zug entfernen
Aktion: Der SocketTest sendet den Befehl, dass ein Zug aus den Simulationen entfernt
werden soll.
Reaktion: In der TuS werden die Prozesse EVSS, OBUD, TSCB, TDGW, TDAP und
MVBG gestoppt. Nach erfolgreichem Löschen des Zuges wird von der TuS die
Quittierung „removalTrainOk(Zug-ID)“ gesendet.
Zugposition senden
Aktion: Der ETCS-Zug in der TuS wird über das Bedienpult beschleunigt.
Reaktion: Auf der Schnittstelle zum SOGW wird die richtige Zugposition empfangen.
Signal stellen
Aktion: Es wird der Signalbegriff „Fahrt“ für ein TuS-Signal zum SOGW gesendet.
Reaktion: Das entsprechende TuS-Signal wird in der TuS auf „Fahrt“ gestellt.
Weiche stellen
Aktion: Für eine TuS-Weiche wird die Weichenlage „Linkslage“ zum SOGW geschickt.
Reaktion: Die entsprechende TuS-Weiche wird in der TuS auf „Linkslage“ gestellt.
- 95 -
Balisentelegramm schalten
Aktion: Über die Schnittstelle zum SOGW wird für eine transparente TuS-Balise die
Balisennummer 0 gesendet.
Reaktion: In der TuS wird für diese Balise das Telegramm 0 eingestellt.
Aktion: Das Testtool sendet den Befehl „initTus“ an die ETCS-Schulungsanlage.
Reaktion: Die TuS startet die Prozesse SCCO, SQLT, RISI und TRPR. Anschließend
schickt die TuS die Nachricht „initTusOk“.
Aktion: Mit Hilfe des Tools SocketTest wird der Befehl „resetTus“ gesendet.
Reaktion: Alle TuS-Prozesse bis auf TCTL und SOGW werden gestoppt.
Aktion: Der Befehl „synchronizeElements“ wird über die Schnittstelle zur TuS ge-
schickt.
Reaktion: Die TuS reagiert auf diesen Befehl mit der Antwort „sendAllStates“.
- 96 -
Anlage F: CD-Übersicht
Die beigelegte CD enthält verschiedenes Material, dass während der Schnittstellenentwick-

lung entstanden ist. In den Ordnern sind folgende Dateien enthalten:
CD
Masterarbeit Die aktuelle Version der Masterarbeit ist in diesem Ord-

ner abgespeichert.
Abbildungen Alle Abbildungen, die im Rahmen der Masterarbeit an-

gefertigt wurden, sind hier als Dateiformat von Microsoft
Office Visio Professional 2003 und .png abgelegt.
Quellen Die Quellen der Masterarbeit sind als pdf-Dateien hier

hinterlegt.
OpenSourceTools Programme, die für die für die Erstellung der Masterar-
beit benutzt wurden und die unter der GNU-Lizenz ste-
hen, sind in diesem Ordner gespeichert.
SocketTest Der Ordner enthält das Programm SocketTest, das für

den Test der Schnittstelle zwischen ETCS- und Fahr-
dienstleiterschulungsanlage entwickelt wurde.
- 97 -

Sprache

Masterarbeit ETCS Stellwerke

Hochgeladen von

Dokumentinformationen

Copyright

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Masterarbeit ETCS Stellwerke

Hochgeladen von

Copyright:

Fachhochschule für Technik und Wirtschaft Berlin (FHTW)

erstellt bei der

1. Betreuer: Prof. Dr.-Ing. Wolfgang Biella

2. Betreuer: Dr.-Ing. Rolf Detering

Berlin, 08. Oktober 2008

Ausnahmen bedürfen der schriftlichen Genehmigung seitens der Siemens AG.

Berlin, 08. Oktober 2008

Dr. Ireneus Suwalski

Die Fahrdienstleiterschulungsanlage besteht aus einer Stellwerkssimulation, die wichtige

Tabellenverzeichnis ............................................................................................................... VIII

1.1 Motivation und Zielsetzung........................................................................................2

1.2 Aufbau der Arbeit.......................................................................................................3

2.1 Zugbeeinflussungssysteme .........................................................................................4

2.2 European Train Control System .................................................................................4

2.2.1 Geschichtlicher Zusammenhang ........................................................................5

2.2.2 Komponenten .....................................................................................................5

2.2.3 Funktionsstufen ..................................................................................................7

2.3 Elektronisches Stellwerk ..........................................................................................10

2.3.1 Betriebszentrale ................................................................................................12

2.3.2 Unterzentrale - SIMIS C...................................................................................13

2.3.3 Unterzentrale - SIMIS W..................................................................................15

2.3.4 Außenanlage .....................................................................................................16

3.1 ETCS-Schulungsanlage ............................................................................................17

3.1.1 Softwarearchitektur ..........................................................................................18

3.1.2 Datenherkunft ...................................................................................................22

3.1.4 Bedienung der Schulungsanlage.......................................................................24

3.2.2 Datenherkunft ...................................................................................................29

3.2.4 Bedienung der Schulungsanlage.......................................................................32

3.3 TuS-Tesys-Projekt ....................................................................................................33

3.3.1 Der Socket Gateway .........................................................................................34

3.3.2 Der A2Mapper..................................................................................................35

3.3.3 Schnittstelle zwischen TuS und Tesys .............................................................36

3.3.4 Funktionsweise des Gesamtsystems.................................................................41

3.4.1 Bezeichnungen der Außenanlagenelemente.....................................................43

3.4.2 Zustände der Außenanlagenelemente...............................................................44

3.4.3 Zugtypen in den Zugsimulationen....................................................................47

3.4.4 Zugposition als Gleisfrei-/Gleisbelegtmeldung................................................48

3.4.5 Zugposition über die Streckentopologie...........................................................49

4.1 Synchronisation von Namen und Zuständen der Außenanlage................................57

4.2 Erweiterung der Zugtypen ........................................................................................58

4.3 Erweiterung der TuS um Gleisfrei-/Gleisbelegtmeldungen .....................................58

4.4 Zugpositionsermittlung über die Streckentopologien ..............................................59

4.5 Erweiterung der Schnittstelle zwischen TuS und Tesys...........................................61

5 Anforderungen an die Schnittstelle ..................................................................................62

6 Designkonzept der Schnittstelle .......................................................................................65

6.1 Vorüberlegung für die Schnittstellenentscheidung ..................................................65

6.2 Aufbau des Gesamtsystems ......................................................................................66

6.2.2 Anforderungszuordnung zu den Schnittstellen und Komponenten..................68

6.3 Schnittstellenbeschreibung .......................................................................................68

6.3.1 Schnittstelle zwischen SOGW und EFS-Gateway ...........................................68

6.3.2 Schnittstelle zwischen EVSS und Tesys ..........................................................72

6.3.3 Schnittstelle zwischen EFS-Gateway und A2Mapper......................................73

6.3.4 Schnittstelle zwischen Zugsimulation und A2Mapper.....................................73

6.3.5 Schnittstelle zwischen Zugsimulation und EFS-Gateway................................74

7 Testkonzept und prototypische Entwicklung ...................................................................76

7.1 Beschreibung des Testkonzepts................................................................................76

7.2 Entwurf eines Prototypen zum Test der Schnittstelle...............................................77

7.2.2 Funktionsweise des Prototypen ........................................................................78

7.3 Durchzuführende Tests.............................................................................................79

8.1 Erreichter Stand ........................................................................................................80

Abb. 1 Entwicklungsstufen der Testanlage ................................................................................1

Abb. 2 Untersuchung der Schnittstelle zwischen zwei Schulungssystemen ..............................2

Abb. 3 Schnittstellendaten im Detail..........................................................................................3

Abb. 4 Bildung der UNISIG.......................................................................................................5

Abb. 5 ETCS - Level 0 [SBB04]................................................................................................8

Abb. 6 ETCS - Level STM [SBB04]..........................................................................................8