InfoHubPT Schnittstellenspezifikation EVU Formationsdaten · PDF fileSchnittstelle zu Info-Hub PT werden die aktuellen Schnittstellenspezifikationen von SBB zur Verfü- ... Layer 2

InfoHubPT Schnittstellenspezifikation

EVU Formationsdaten

Bei der vorliegenden Spezifikation handelt es sich um eine Musterspezifikation. Es ist zu beachten,

dass die Musterspezifikation in einigen Punkten von der aktuell gültigen Spezifikation abweichen

kann. Die Musterspezifikation dient einem zukünftigen Abnehmer sich eine erste Meinung über die

Realisierung einer Schnittstelle zu Info-Hub PT bilden. Im Falle eines konkreten Bedarfs einer

Schnittstelle zu Info-Hub PT werden die aktuellen Schnittstellenspezifikationen von SBB zur Verfü-

gung gestellt und mit dem Abnehmer die Anforderungen und die mögliche Anbindungen geprüft.

Thema Beschreibung

Titel InfoHubPT Schnittstellenspezifikation EVU Formationsdaten

Dokumentversion 1.3.1

Schnittstellenversion 1.3

XSD-Version 1.3

Release Herbstrelease 2015

Nr. des Dokuments tbd

Art des Dokuments Spezifikation

Autor Walter Oesch, Thomas Buchmüller, Pirmin Suter (SBB)

Thomas Goetz, André Bally, Matthias Günter (BLS)

Status Abgenommen durch BLS, SOB und SBB-P

Klassifikation Öffentlich

Herausgeber Infrastrukturbetreiber Normalspur Schweiz (SBB, BLS, SOB)

InfoHubPT_Schnittstellenspezifikation_EVU_Formationsdaten_v1_3_1.docx 2/67 24.07.2015

Document history

Version Autor Beschreibung Datum

0.1 WOE Erstellt auf Basis RCS RT-EX 05.08.2014

0.2 WOE Vollständiger Draft mit offenen Frage 22.08.2014

0.3 WOE Erster interner Draft 26.08.2014

0.4 WOE Draft für Ceres (für Schätzung) 04.09.2014

0.5 WOE Anpassung Systemqualitäten EVU; Speedkanal Tagesfor-

mationen;

14.09.2014

0.6 WOE Feedback Vorabnahme ISB (BLS) eingearbeitet 23.10.2014

0.7 WOE Aufnahme grundsätzlich überarbeitetes Datenformat. 07.11.2014

0.75 WOE Ergänzung Beschreibung Datenmodell 10.11.2014

0.8 WOE Ergänzungen und Korrekturen Datenmodell. Beschreibung

der Attribute

13.11.2014

0.85 WOE Feedback H. Telley (ELCA) eingearbeitet 21.11.2014

0.86 WOE Befunde BLS eingearbeitet 21.11.2014

0.87 WOE Ausstehende Felder beschrieben 26.11.2014

0.9 WOE Beschreibungen ergänzt und Korrekturen. 27.11.2014

1.0 TGO Finale Version 28.11.2014

1.2 WOE Einarbeitung Befunde EVU. Umbenennung der Klassen

Formationsahrt -> FormationsfahrtTag, Formationsfahrt-

Jahr; Fahrtypelement -> FahrtypelementTag, Fahrtypele-

mentJahr. Umbenennung vMaxEinschraenkung -> vMax-

Abweichung, bremsreiheEinschraenkung -> bremsreiheAb-

weichung. Neues optionales Attribut zugreiheAbweichung in

FahrtypelementTag und FahrtypelementJahr

16.03.2015

1.2.1 WOE Einarbeitung Befunde BLS. Fahrzeugtype.antriebsenergie

ist obligatorisch, dafür gibt es einen zusätzlichen Wert kei-

ne. Feld gibtTraktion ist obligatorisch.

19.03.2015

1.3 WOE erfasstInEvu ist neu Muss-Attribut. Optionale Attribute zur

Zug- und Bremsreihe von Fahrtypelement nach Formations-

fahrt verschoben. Zusätzliche Werte in RolleTraktion. Zu-

sätzliche, optionale Kommentarfelder in ZugJahr und For-

25.05.2015


mationsfahrtJahr. gibtTraktion ist neu ein Muss-Feld. Ver-

knuepfungJahr hat neu eine obligatorische Verkehrsperio-

de, damit eindeutig ist, an welchen Tagen die Verknüpfung

gilt.

1.3.1 WOE Nach Review der Version 1.3 durch die EVUs. Keine Be-

funde der EVUs zur Version 1.3.

12.06.2015

Freigabe

Funktion Name Datum Unterschrift

Referenzierte Dokumente

Kürzel Dokument Version Dok.

Nr.

Glossary https://confluence.sbb.ch/display/CISINFRAE/Glossar

https://confluence.sbb.ch/display/GLO/SBB+Glossar

KE-IMPO KompoEVU: Importierungsprogramm Kompositions-

daten

1.6

KE-SSS KompoEVU: EVU Schnittstellenspezifikation

(beschreibt XML und Importprozess)

1.6

KE-DM KompoEVU: Datenmodellspezifikation vom 20.11.13

(Kapitel 4 Anforderungen)

2.2

FOS-MIG Migrationskonzept von KompoEVU zu FOS In Work

https://confluence.sbb.ch/display/CISINFRAE/Glossar

https://confluence.sbb.ch/display/GLO/SBB+Glossar


Inhaltsverzeichnis

1 Einleitung ................................................................................................................... 6

1.1 Zweck des Dokuments ........................................................................................... 6

1.2 Gültigkeit ................................................................................................................ 6

1.3 Begriffe und Abkürzungen ...................................................................................... 6

2 Ausgangslage ............................................................................................................ 7

2.1 Ausgangslage ........................................................................................................ 7

2.2 Integrationsstrategie von FOS ............................................................................... 7

3 Schnittstellendetailspezifikation .................................................................................10

3.1 Allgemein ..............................................................................................................10

3.2 Kompatibilität zu KompoEVU ................................................................................10

3.3 Transport-Layer ....................................................................................................10

3.3.1 Grundlagen .......................................................................................................10 3.3.2 Accounts und Verzeichnisse .............................................................................10 3.3.3 Filenamen .........................................................................................................12

3.4 Marshalling ...........................................................................................................12

3.4.1 Grundlagen .......................................................................................................12 3.4.2 Datentypen........................................................................................................13

3.5 Application ............................................................................................................13

3.5.1 Einführung.........................................................................................................13 3.5.2 Aufbau des XSD-Schemas ................................................................................14 3.5.3 Tagesformationen .............................................................................................15

3.5.3.1 Betriebspunkt ...........................................................................................19

3.5.3.2 Zuglaufpunkt ............................................................................................20

3.5.3.3 Fahrzeug ..................................................................................................21

3.5.3.4 Fahrzeugidentifikation ..............................................................................22

3.5.3.5 Fahrzeugtyp .............................................................................................23

3.5.3.6 KeyValue..................................................................................................24

3.5.3.7 ZuegeTag.................................................................................................24

3.5.3.8 ZugTag ....................................................................................................26

3.5.3.9 ZugidentifikationTag .................................................................................27

3.5.3.10 FormationsfahrtTag ..................................................................................28

3.5.3.11 ProduktiveLeistungTag.............................................................................29

3.5.3.12 VerknuepfungTag .....................................................................................30

3.5.3.13 FahrtypelementTag ..................................................................................30

3.5.3.14 ElementInLeistungTag .............................................................................33

3.5.3.15 DirekterWagenlaufTag .............................................................................34

3.5.3.16 FahrzeugtypelementTag ..........................................................................35

3.5.4 Jahresformationen ............................................................................................37 3.5.4.1 Verkehrsperiode .......................................................................................39

3.5.4.2 ZuegeJahr ................................................................................................39

3.5.4.3 ZugJahr ....................................................................................................40

3.5.4.4 ZugidentifikationJahr ................................................................................41

3.5.4.5 FormationsfahrtJahr .................................................................................41


3.5.4.6 FahrtypelementJahr .................................................................................42

3.5.4.7 FahrzeugtypelementJahr ..........................................................................44

3.5.4.8 ProduktiveLeistungJahr ............................................................................45

3.5.4.9 ElementInLeistungJahr.............................................................................47

3.5.4.10 VerknuepfungJahr ....................................................................................48

3.5.5 Umgang mit Meldungen ....................................................................................49 3.5.6 Versionierung Schema und Meldungen .............................................................50 3.5.7 Validierungskriterien ..........................................................................................50 3.5.8 Szenarien ..........................................................................................................51

3.6 Hand-Shake ..........................................................................................................52

3.6.1 Meldungsanlieferung und Zeitfenster ................................................................52 3.6.2 Signalisierung und Fileübermittlung...................................................................52 3.6.3 Fehlerbehandlung .............................................................................................53 3.6.4 Alarming und Notifizierung ................................................................................53 3.6.5 Löschung von Files ...........................................................................................54 3.6.6 Initial Load und Nachlieferungen .......................................................................54 3.6.7 Szenarien ..........................................................................................................55

3.7 Migration von KompoEVU nach FOS ....................................................................56

3.8 Zukünftige Änderungen am Schnittstellenkontrakt ................................................57

3.9 Systemqualitäten ..................................................................................................58

3.9.1 Pflichten EVU ....................................................................................................58 3.9.2 Verfügbarkeit FOS ............................................................................................59 3.9.3 Typische Grössenordnungen ............................................................................59

4 Anhang: Codeausprägungen ....................................................................................60

5 Anhang: Fragen und Entscheide ...............................................................................61

6 Anhang: Geschäftsdatenmodell ................................................................................62

6.1 Fahrzeug ..............................................................................................................62

6.2 Trasse ...................................................................................................................63

6.3 Zug… ....................................................................................................................64

Abbildungsverzeichnis

Abbildung 1: Übersicht Integration FOS Architektur im Kontext CIS Infra und IHPT .............. 8

Abbildung 2: Wurzel des XSD Schemas ...............................................................................14

Abbildung 3: Positionen der Direkten Wagenläufe ................................................................18

Abbildung 4: Geschäftsdatenmodell "Formation" ..................................................................63

Abbildung 5: Geschäftsdatenmodell "Trasse" .......................................................................64

Abbildung 6: Zuglauf-Verlängerung ......................................................................................64

Abbildung 7: Geschäftsdatenmodell "Zug" ............................................................................65

Abbildung 8: Formation mit 2 dreiteiligen Gliederfahrzeugen ................................................66

Abbildung 9: RABe 525 „NINA“ dreiteilig der BLS .................................................................67

Abbildung 10: RABe 523 „FLIRT“ vierteilig der SBB .............................................................67

Abbildung 11: RABe 526 „FLIRT“ vierteilig der SOB .............................................................67


1 Einleitung

1.1 Zweck des Dokuments

Dieses Dokument spezifiziert die Formationsdaten-Schnittstelle. Über diese Schnittstelle

liefern die EVU ihre Zugsformationen an die ISB der Normalspur CH.

Nachfolgend wird beschrieben, wie die EVU ihre Formationsdaten (d.h. die Formationen des

Personenverkehrs und die Traktionen des Güterverkehrs) fachlich und technisch an den

Formationsservice (FOS) liefern sollen.

Diese Spezifikation orientiert sich an der aktuell in Produktion befindlichen Schnittstelle von

KompoEVU. Sie wurde jedoch in den wichtigsten Punkten und wo notwendig angepasst.

Das GUI, welches FOS den kleineren EVU und SBB Infrastruktur-internen Stellen für die

Datenerfassung und -korrektur zur Verfügung stellen wird, ist nicht Teil dieser Spezifikation.

Dieses GUI wird sich aber auch an die hier beschriebene bahnspezifische Fachlichkeit hal-

ten.

1.2 Gültigkeit

Diese Spezifikation gilt für das Projekt FOS und alle datenliefernden EVU. Zur Zeit sind dies

SBB P, SBB Cargo, BLS P, BLS C und SOB P.

Eine erste Version der Spezifikation, welche bis Dezember 2014 erstellt wird, soll den be-

troffenen EVU zur Kostenabschätzung der bei ihnen notwendigen Anpassungen dienen und

den Zielbereich vorgeben. Bis März 2015 soll die Spezifikation in gegenseitiger Absprache

Implementationsreife erreicht haben. Ab diesem Zeitpunkt hat sie verbindliche Gültigkeit für

Umsetzung und Betrieb.

1.3 Begriffe und Abkürzungen

Eine vollständige Liste der Abkürzungen und Begriffe liefern die referenzierten Glossare.


2 Ausgangslage

2.1 Ausgangslage

Die Anwendung KompoEVU wird durch FOS abgelöst. Dies ist notwendig, da SYFA (SYs-

temFAhrplan) voraussichtlich per Ende 2017 abgestellt wird und die Zugsidentifikation mit

dem SYFA-Nachfolger NeTS geändert wurde.

Ausserdem sollen bei dieser Gelegenheit weitere wichtige Anpassungen und Änderungen

vorgenommen und vorbereitet werden. Dies soll allerdings nur soweit geschehen, dass die

Auswirkungen auf die Datenlieferanten und –bezüger vertretbar sind. Dazu gehören etwa

Verbesserungen beim Ordnungssystem für Fahrzeuge, Umläufe (nicht-produktive Leistun-

gen in RE 2). Diese Verbesserungen decken zukünftige Anforderungen ab und sichern die

längerfristige Stabilität der Schnittstelle.

Der FOS wird als Teilapplikation von CIS Infra realisiert.

2.2 Integrationsstrategie von FOS

Die EVU liefern XML-Dateien mit den Formationsdaten auf einen FTP-Server der SBB. Der

FOS liest, validiert und verarbeitet diese Datenlieferungen. Anschliessend leitet er die For-

mationsdaten an den Info-Hub PT weiter. Dieser ist für die Verteilung der Formationsdaten

zuständig.


Abbildung 1: Übersicht Integration FOS Architektur im Kontext CIS Infra und IHPT

FOS kann grundsätzlich nur das verteilen, was auch durch die Datenlieferanten geliefert

wird. Dabei nimmt FOS keine Umrechnungen und Veränderungen der gelieferten Formati-

onsdaten vor.

«external system»

EVU

FTP Serv er

Streamworks

Agent

Streamworks

Serv er

SBB Batch Serv er

WAS

EVUX Batch

Mainframe

Oracle

MQ WMB

FOS GUI

Kleine EVU

Dispatcher

Flow

«executi...

Distributed

Cache

Webserv ice

Flow

«external system»

Abnehmer

Anwendung

Queue

Topic«external

system»

ZLR

CIS Infra

FOS Backend

Aufbereitung

Tagesformation

KompoEVU

Konv erter

«external system»

KompoEVU

Req.

Queue

Fahrtyp

Import

EVU's

Fachbus CIS

«external

system»

Info-Hub PT

T: Tagesformation

J: Jahresformation

Oracle

Sollfahrplan

Staging

FOS DB

T + J

Req Initial

G + P Fahrplan

neues File

Req. Initial

Fahrtyp

T + J single Record

T + J

T

TF + JF

T + J;

Fahrplan

Fahrplan

TF

T + J

TF + JF

Req.

Initialload

Stammdaten

Fahrtyp

T + J

T + J Alt

T + J

T

T + J (XML);

Fahrtyp

Start Batch

J


Im Folgenden sollen die Festlegungen für die EVU-FOS Schnittstelle vorgestellt werden.

Dabei wird ein 4-Layer-Schichtenmodell zur Strukturierung verwendet:

Layer Bezeichnung Beschreibung

Layer 0 Transport Transportmechanismus, mit dem die Daten übermittelt werden (z.B. JMS, FTP, JDBC)

Layer 1 Marshalling Form, in der die Daten übermittelt werden (z.B. XML, JSON, CSV)

Layer 2 Application Struktur, in der die Daten übermittelt werden (I-DOM gegeben) und Art, wie die Struktur beschrieben ist (z.B. DTD oder XML-Schema)

Layer 3 Handshake Form der Interaktion, welche bei der Schnittstelle eingesetzt wird (z.B. Publish/Subscribe, Request/Reply)


3 Schnittstellendetailspezifikation

3.1 Allgemein

Die EVU liefern Jahres- und Tagesformationen als getrennte Meldungen an den FOS. Der

FOS verwendet für die Jahres- und Tagesformationen dieselbe Schemadefinition (XSD):

- Die Jahresmeldungen beschreiben alle Formationen eines EVU einer kompletten

Fahrplanperiode.

- Die Tagesmeldungen beschreiben alle Formationen für einen Zeitraum von mehreren

Tagen oder Aktualisierungen der Formationen für einzelne Züge an bestimmten Ta-

gen.

3.2 Kompatibilität zu KompoEVU

Die vorliegende Schnittstelle orientiert sich an der bestehenden Schnittstelle zu KompoEVU

[KE-IMPO, KE-SSS und KE-DM]. Wesentliche Konzepte wurden übernommen.

Unterschiede ergeben sich aber insbesondere bei den folgenden Punkten:

- Struktur der gelieferten Daten in den XML-Files der EVU

- Handling der XML-Files der EVU auf dem FTP-Server

3.3 Transport-Layer

3.3.1 Grundlagen

ID Beschreibung M/K1 Bemerkung

TR-01 Als Transportservice wird FTP/SSL einge-setzt.

M Grund: Nur minimale Änderungen ge-genüber KompoEVU.

TR-02 FOS muss bis maximal 10 EVU ohne Per-formanceeinbussen anbinden und bedie-nen können.

M

TR-03 Die Formationsmeldungen müssen in der korrekten Reihenfolge (gemäss Fachlich-keit EVU) verarbeitet werden.

M Insbesondere dürfen keine neueren Daten überschrieben werden.

TR-04 Zugriff auf FTP-Account wird durch User-name und Passwort geschützt.

M Minimaler, aber zweckmässiger Schutz.

3.3.2 Accounts und Verzeichnisse

Pro EVU wird ein eigener FTP-Account auf einem SBB FTP-Server eingerichtet. Der Zugriff

auf den FTP-Server erfolgt über FTP/SSL. Auf den FTP-Account müssen sowohl EVU als

auch FOS schreibenden Zugriff haben. Dies kontrastiert zur bisherigen Praxis von Kompo-

1 M: muss, K: kann


EVU, wo nur die EVU Schreibrecht hatten und ein beliebiger FTP-Server im Internet verwen-

det werden konnte. Der Application Operation Manager FOS richtet die FTP-Accounts ein

und teilt den EVU die Zugangsdaten mit.

Der Zugriff auf den FTP-Account erfolgt durch ein EVU mit seinem Username und Passwort

(welche separat verteilt werden) über die folgende URL:

ftps://ftp.sbb.ch/fos/ (Details siehe Betriebskonzept)

Für jedes EVU wird ein separater Bereich mit der folgenden Verzeichnisstruktur eingerichtet:

Ordner Beschreibung

jahr Verzeichnis für die von den EVU gelieferten Jahresformationen (XML-Files).

jahr/archiv FOS verschiebt Files mit Jahresformationen hierhin, wenn sie die strukturelle Prü-fung (siehe Kap. 3.6.3) bestehen und vom FOS eingelesen werden konnten. Nach einer vordefinierten Zeitspanne (siehe Kap. 3.6.5) werden die Daten gelöscht.

jahr/error FOS verschiebt Files mit Jahresformationen hierhin, welche die strukturelle Prü-fung (siehe Kap. 3.6.3) nicht bestehen und vom FOS nicht eingelesen werden konnten. Files, welche eingelesen werden konnten, werden immer nach

jahr/archiv verschoben, unabhängig davon, ob fachlich fehlerhafte Datensätze

im File enthalten sind. Nach einer vordefinierten Zeitspanne (siehe Kap. 3.6.5) werden die Daten gelöscht.

tag Verzeichnis für die von den EVU gelieferten Tagesformationen (XML-Files).

tag/archiv Verwendung analog zu jahr/archiv

tag/error Verwendung analog zu jahr/error

speed Verzeichnis für Tagesdaten-Updates, welche möglichst rasch durch FOS verarbei-tet werden sollen. Hier dürfen nur die Tagesdaten-Updates von Zügen angeliefert werden, die in den nächsten 90 Minuten am Fahren sind.

speed/archiv Verwendung analog zu tag/archiv

speed/error Verwendung analog zu tag/error

Auf ein Verzeichnis wie status kann verzichtet werden, weil der Handshake zwischen EVU

und FOS anders gelöst wird (siehe Kapitel 3.6).

ftp://ftp.sbb.ch/fos/%3cevu%3e/


3.3.3 Filenamen

Die Filenamen der übermittelten XML-Files müssen der folgenden Konvention entsprechen:

<evu>_<YYYYMMDD>-<hhmmss.mmm>.<ext>

Jede EVU muss ein vom FOS vorgegebenes <evu> Kürzel für den Filenamen verwenden:

Ordner Beschreibung

bls BLS Personenverkehr und Cargo

sbbp SBB Personenverkehr

sbbc SBB Cargo

sob SOB (Schweizerische Südostbahn)

Der verwendetet Zeitstempel (Zeit und Datum) <YYYYMMDD>-<hhmmss> im Dateinamen

entspricht dem Zeitpunkt der Datengenerierung seitens EVU (siehe auch Kapitel 3.6.2).

Der Extension <ext> kommt besondere Bedeutung zu, weil die liefernde EVU damit den Zu-

stand ihrer Übermittlung an FOS kommuniziert: Während der Übermittlung ist <ext> auf „par-

tial“ gesetzt und wird nach abgeschlossener Übermittlung durch das EVU auf „xml“ geändert.

Weitere Informationen zum Verarbeitungsablauf finden sich im Kapitel 3.6.2. Alle im Datei-

namen verwendeten Buchstaben müssen klein geschrieben sein.

Mögliche Filenamen für die Datenlieferungen der EVU sind damit zum Beispiel:

SBB P BLS SOB

sbbp_19991231-235959.123.partial

sbbp_19991231-235959.348.xml

bls_19970101-000001.821.partial

bls_19970101-000001.724.xml

sob_20131111-235959.283.partial

sob_20131111-235959.562.xml

3.4 Marshalling

3.4.1 Grundlagen

ID Beschrieb M/K Bemerkung

MA-01 Zeichensatz ist UTF-8. M

MA-02 Beschreibung der Struktur erfolgt im XML-Schema [FOS-IN].

M Übersicht und zusätzliche Erläute-rungen im vorliegendem Dokument.


3.4.2 Datentypen

Es werden die im XML-Schema definierten Datentypen verwendet; im Speziellen gilt für Zeit-

und Datumsangaben:

ID Beschrieb Format Beispiel

DT-01 dateTime [YYYY-MM-DD]T[HH24:MI:SS].[MS][Time Offset UTC]

2011-10-03T13:29:14.306+02:00

DT-02 date [YYYY-MM-DD] 2011-10-03

Insbesondere muss Time Offset UTC immer mitgeliefert werden.

3.5 Application

3.5.1 Einführung

Das EVU liefert folgende Daten an den FOS:

Jahresformationen aller Züge für eine Fahrplanperiode

Tagesformationen aller Züge für den Tag, der neu in die Betrachtungsperiode fallen

Updates der Tagesformationen in der Betrachtungsperiode

Als Betrachtungsperiode wird die Zeitspanne bezeichnet, für die das EVU Formationsände-

rungen an den FOS liefern muss.

Für die in der EVU-FOS Schnittstelle zu verwendenden Schlüssel gilt:


AP-01 Tagesformationen: Die liefernden EVU verwendet als Schlüssel für die Zugfahrt die TrassenID (von NeTS) und den Betriebstag.

M

AP-02 Jahresformationen: Die liefernden EVU verwenden als Schlüssel für den Zug die TrassenID, eine Verkehrsperi-ode sowie die Fahrplanperiode. Die Verkehrs-periode muss nicht mit der Verkehrsperiode des Zuges im Grundfahrplan übereinstimmen.

M

AP-03 Die liefernden EVU müssen keinen SYFA-Identifikator mehr liefern und verwenden statt-dessen ausschliessliche die NeTS TrassenID.

M



AP-04 Die liefernden EVU nutzen für den Fahrtyp einen Identifikator, welcher durch SBB Infra-struktur (Rollmaterialdatenbank) erfasst und genehmigt wurde. Die zulässigen Werte für den Fahrtyp können durch das EVU beim Formationsservice bezo-gen werden.

M

3.5.2 Aufbau des XSD-Schemas

Das XML-Schema FOS_Import_EVU.xsd enthält alle Klassen und Aufzählungstypen, die

in den Schnittstellen zwischen den EVU und dem FOS verwendet werden.

Das Schema definiert genau ein Wurzelelement: FosRoot. FosRoot enthält immer ein

Headerelement sowie immer genau eine der Klassen ZuegeTag oder ZuegeJahr (choice).

FosRoot ist die umhüllende Klasse. Eine Datei enthält immer nur ein Element ZuegeTag

oder ZuegeJahr.

Abbildung 2: Wurzel des XSD Schemas

Klasse Beschreibung

ZuegeTag Wird für die Übertragung der Tagesformationen verwendet. Bestandteil dieser Spezifikation.

ZuegeJahr Wird für die Übertragung der Jahresformation verwendet. Bestandteil dieser Spezifikation.

Header Metadaten zu den übertragenen Daten wie Schnittstellenversion.

Die Klasse Header enthält Metainformationen zu den übertragenen Daten.

FosRoot

ZuegeJahrZuegeTag

Header

{choice}

0..10..1

1


Klasse Attribut Typ M/K Beschreibung Beispiel

Header schemaVersion xs:string M Version des Schemas, das dem XML Instanz-Dokument zugrunde liegt.

2.3.1

Das XSD definiert mehrere xs.group. Solche Gruppen bündeln Attribute, die von mehreren

Klassen verwendet werden. Diese Gruppen haben keine fachliche Relevanz und dienen

ausschliesslich der Vermeidung von Redundanzen bei den Klassendefinitionen. Die Gruppen

werden nicht separat beschrieben. Die Attribute der Gruppen werden in den Klassen be-

schrieben, welche die Gruppen verwenden.

Tages- und Jahresformationen werden durch unterschiedliche Klassen abgebildet, sofern

Unterschiede bestehen. Sind die Konzepte identisch, werden in den Jahres- und Tagesfor-

mationen die gleichen Klassen verwendet.

Das nächste Kapitel beschreibt im Detail die Tagesformationen. Für die Jahresformationen

werden die sofern möglich die gleichen Konzepte verwendet. Unterschiede in den Tagesfor-

mationen werden anschliessend behandelt.

3.5.3 Tagesformationen

Das nachfolgende Modelle zeigt die fachliche Struktur der Tagesformationen.


Die Klasse FosRoot ist die Wurzelklasse der Tagesformation. Diese Klasse enthält die

Klasse Header. Die Headerklasse enthält Metainformationen zu den übermittelten Daten. Im

Falle der Tagesformation enthält FosRoot genau eine Klasse ZuegeTag. ZuegeTag hat je

eine Liste von Fahrzeugtyp, Fahrzeug und ZugTag.

Fahrzeugtyp enthält Informationen, die zu einem bestimmten Typ von Fahrzeug gehören

und für alle Fahrzeuge des gleichen Typs identisch sind. Fahrzeugtypen sind die Platzhalter

der EVU in der Planung für konkrete Fahrzeuge. Die EVU legen die Fahrzeugtypen fest und

vergeben den fachlichen Schlüssel (in der Schnittstelle ist das Attribut Kennung der fachli-

che Schlüssel für Klassen, die über keinen eindeutigen Bezeichner für den fachlichen

Schlüssel verfügen.). Die fachlichen Schlüssel der Fahrzeugtypen müssen pro Datei eindeu-

tig sein.

Die Infrastruktur speichert die Fahrzeugtypen nicht als Stammdaten ab. Sie legt lediglich

fest, welche Attribute der Fahrzeugtyp umfassen muss. Andere Klassen in der XML-Datei

FosRoot Header

ZuegeTag

Fahrzeug

FahrzeugtypKeyValue

BetriebspunktDirekterWagenlaufTag

FahrzeugIdentifikation

ElementInLeistungTag

Produktiv eLeistungTag

VerknuepfungTag

ZugTag

ZugidentifikationTag

Zuglaufpunkt

durchgezogene Linie: XML-Include Beziehung

gestrichelte Linie (--->) Fremdschlüsselbeziehung

FormationsfahrtTag

FahrzeugtypelementTag

FahrtypelementTag

1

1

*

1

0..1

0..1

1

*

0..1

1

1..*

2..*

0..*

0..1

1

1

*

1..*

1

1

0..1

*

1

1..*

*

*

1

1

1

0..*

1

*

0..*


referenzieren Fahrzeugtypen. Der Schlüssel für die Referenzierung ist das Attribut Kennung

des Fahrzeugtyps. Allgemein haben Attribute, die auf eine andere Klasse verweisen, das

Präfix ref im Namen.

Fahrzeug enthält Informationen, die zu einem konkreten Fahrzeug gehören. Fahrzeuge

haben eine eindeutige fachliche Identifikation in Form der European Vehicle Number (EVN)-

Nummer.

Neben der fachlichen Identifikation verfügen die Fahrzeuge zusätzlich über den technischen

Schlüssel Nummer. Diese Nummer kann beliebig vergeben werden, muss jedoch innerhalb

der XML-Datei eindeutig sein. Klassen, welche Fahrzeuge referenzieren, verwenden dazu

die Nummer als Fremdschlüssel.

ZugTag repräsentiert einen Zug gemäss dem Planungssystem NeTS an einem bestimmten

Betriebstag. ZugTag enthält die Klasse ZugidentifikationTag. Zugidentifikation-

Tag besteht aus den Attributen TrassenID, Betriebstag und Zugnummer. TrassenID

und Betriebstag sind eindeutig und müssen immer gesetzt sein, sofern die Trasse bereits

existiert. In Ausnahmefällen (Bestellverfahren 5), in denen die TrassenID noch nicht be-

kannt ist, kann nur die Zugnummer geliefert werden.

ZugTag enthält Listen der Klassen Formationsfahrt, ProduktiveLeistungTag, Zug-

laufpunkt und VerknuepfungTag.

Die Formationsfahrt beschreibt einen Strecke zwischen zwei Betriebspunkten des Zu-

ges, auf der keine Änderungen an den Formationen vorgenommen werden. Dazu gehören

auch Änderungen in der Reihung wie z.B. Wenden eines Zuges.

ProduktiveLeistungTag umfasst Elemente des gleichen Umlaufs, die diesem Zug zuge-

ordnet sind und als Einheit vor und nach dem produktiven Einsatz im Zug zusammenbleiben.

Die ProduktiveLeistungTag referenziert einen Anfangs- und Endzuglaufpunkt.

Die Klasse Zuglaufpunkt stellt einen Punkt des Zuglaufes dar. Zuglaufpunkt verfügt

über einen technischen Schlüssel und wird von anderen Klassen referenziert.

VerknuepfungTag bildet eine Verknüpfung eines Elements von oder zu einem anderen

Zug ab. Die Klasse legt also fest, von welchem Zug ein Element (Fahrzeug) kommt oder zu

welchem Zug ein Element anschliessend gehört. VerknuepfungTag verfügt über den tech-

nischen Schlüssel Nummer und wird von ElementInLeistungTag referenziert.

ProduktiveLeistungTag enthält ein oder mehrere ElementInLeistung. Ein Elemen-

tInLeistung beschreibt ein Element/Fahrzeug der Produktiven Leistung. Jedes Elemen-

tInLeistung kann je eine Referenz (Fremdschlüssel) auf eine Vorgänger- oder Nachfol-

gerverknüpfung (refVonVerknuepfungNummer und refBisVerknuepfungNummer) ha-

ben. Dabei bestimmt der Anfangszuglaufpunkt der Produktiven Leistung, zu dem das Ele-

mentInLeistung gehört, den Punkt, an dem das Element dem Zug hinzugefügt wurde.

Entsprechend legt der Endzuglaufpunkt der Produktiven Leistung den Punkt fest, an dem

das Element dem nachfolgenden Zug zugeordnet wird.


In bestimmten Fällen jedoch entsprechen der Anfangs- oder Endzuglaufpunkt der Produkti-

ven Leistung nicht dem Punkt des Vorgänger- oder Nachfolgerzuges, von dem das Element

kommt oder zu dem das Element geht. Daher verfügt VerknuepfungTag über ein optiona-

les Attribut Betriebspunkt. Dieses Attribut legt den Punkt des Vorgänger beziehungswei-

se Nachfolgerzuges fest, vom dem das Element kommt oder zu dem das Element geht. Das

Attribut muss nur gesetzt werden, wenn der Punkte des Vorgänger- oder Nachfolgerzuges

nicht mit dem Punkt des Zuges übereinstimmt.

Eine ProduktiveLeistungTag kann zwei oder mehr DirektenWagenlaufTag enthal-

ten. Der DirekteWagenlaufTag verweist auf einen Vorgänger- oder Nachfolgerzug, dem

die Fahrzeuge zugordnet werden, ohne dass die Reisenden die Fahrzeuge verlassen müs-

sen.

Abbildung 3: Positionen der Direkten Wagenläufe

Eine Formationsfahrt besteht aus einem oder mehreren Fahrtypelementen. Ein Fahrtypele-

ment beschreibt ein betrieblich nicht trennbares Element des Zuges und enthält die fahrdy-

namisch relevanten Attribute. Insbesondere verfügt ein Fahrtypelement über den fachlichen

Schlüssel des Fahrtyps. Der Fahrtyp wird von der Infrastruktur vergeben und muss von den

EVU in den Fahrtypelementen verwendet werden. Mit Hilfe des mitgelieferten Fahrtypschlüs-

sel können die fahrdynamisch relevanten Informationen ermittelt werden. Diese wiederum

ermöglichen eine genaue Zuglaufrechnung.

Zudem ist der Fahrtyp die Basis für die zukünftige Trassenabrechnungen. Die Trassenkosten

werden basierend auf den übermittelten Fahrtypen berechnet. Zu den Fahrtypen werden die

für die Trassenpreisberechnung relevanten Parameter gespeichert. Details dazu können den

Regeln für die Trassenpreisberechnung entnommen werden. Ein Fahrtypelement kann über

eine Referenz (Fremdschlüssel) auf ein Fahrzeug verfügen. Die Referenz ist gesetzt, sofern

das konkrete physische Fahrzeug bekannt ist. Ein Fahrtypelement hat eine Referenz auf

ein ElementInLeistungTag. ElementInLeistungTag wiederum kann über Verknüp-

fungen zu Vorgänger-, oder Nachfolger-Zügen verfügen. Ein ElementInLeistungTag re-

präsentiert ein Element einer Produktiven Leistung.

Jedes Fahrtypelement verfügt über genau ein oder mehrere Fahrzeugtypelemente. Ein

Fahrzeugtypelement beschreibt die für die Kundeninformation relevanten Attribute. Stellt

das Fahrtypelementen ein einzelner, betrieblich trennbarer Wagen oder Traktion dar, verfügt


das Fahrtypelementen über genau ein Fahrzeugtypelement. Handelt es sich beim Fahr-

typelement um ein Gliederfahrzeug, also um eine Einheit, die im Betrieb zusammen bleibt

und über mehrere Untereinheiten verfügt, so verfügt das Fahrtypelement über mehrere

Fahrzeugtypelemente, eines pro Untereinheit. Jedes Fahrzeugtypelement referenziert

(Fremdschlüssel) einen Fahrzeugtyp.

Die nachfolgenden Abschnitte beschreiben Klassen und Attribute der Tagesformationen.

3.5.3.1 Betriebspunkt

Die Klasse Betriebspunkt beschreibt einen Betriebspunkt. Betriebspunkte liegen als Lis-

te vor und werden von anderen Klassen über den technischen Schlüssel nummer referen-

ziert.

Attribut Typ M/K Beschreibung Beispiel

nummer Integer M Technischer Schlüssel des Betriebspunktes. 1, 4

uicLaendercode Integer M Ländercode des Betriebspunktes. 85

uicCode Integer M UIC Code des Betriebspunktes. 4017

abkuerzung String K Kürzel des Betriebspunktes „BN“, „ZUE“


3.5.3.2 Zuglaufpunkt

Die Klasse Zuglaufpunkt beschreibt einen Punkt des Zuglaufs.


position Integer M Technischer Schlüssel für die Identifikation des Zuglaufpunktes. . Beschreibt Reihenfolge inner-halb des Zugdatensatzes. Position wird als Fremdschlüssel in anderen Klassen verwendet.

2, 4

refBpNummer Integer M Referenz (Fremdschlüssel) auf die technische Nummer des Betriebspunkts.

2

zusatzId String K Zusätzliche ID, gemäss dem Trassenplanungs-system NeTS für die Detektion von Mehrfachbe-fahrungen des gleichen Betriebspunktes. Muss gesetzt sein, wenn der Zuglaufpunkt Teil der Trasse von NeTS ist. Punkte im Ausland, die

nicht zur Trasse gehören, haben keine zu-

satzID.

„1“

zeitAn Integer M Ankunftszeit des Zuges an diesem Punkt. Se-kunden ab Mitternacht des Betriebstages.

2618

zeitAb Integer M Abfahrtszeit des Zuges an diesem Punkt. Se-kunden ab Mitternacht des Betriebstages.

2648

erfasstInEvu Boolean M Legt fest, ob der Punkt als Verlängerung des Zuglaufes vom EVU angelegt wurde. Üblicher-weise handelt es sich bei solchen Punkten um Verlängerungen des Zuglaufs im Auslands. Die EVU sind nicht verpflichtet, diese Information zu liefern.

true


3.5.3.3 Fahrzeug

Die Klasse Fahrzeug beschreibt ein physisches Fahrzeug mit einer eindeutigen Nummer.


nummer Integer M Technische Nummer für die Fahrzeugidentifikation. Eindeu-tig innerhalb der XML. Datei. Ist als Fremdschlüssel in anderen Klassen enthalten.

1, 213, 234

fahrzeugIdentifikation Fahrzeug-identifikation

M EVN Fahrzeugidentifikation.

anzahlRestaurantPlaetze Integer K Anzahl der Restaurantplätze im Fahrzeug.

8, 10

anzahlRollstuhlPlaetze Integer K Anzahl der Rollstuhlplätze im Fahrzeug.

1, 3

anzahlBetten Integer K Anzahl der Betten im Fahrzeug. 10, 15

anzahlVelohaken Integer K Anzahl der Velohaken im Fahr-zeug.

3, 5

hatVeloplattform Boolean K Flag, ob des Fahrzeug über eine Veloplattform verfügt.

true, false

anzahlRollstuhlToiletten Integer K Anzahl der rollstuhlgängigen Toiletten im Fahrzeug. Resul-tiert aus Anforderungen von Top-Programm Kundeninforma-tion.

2

rollstuhlgaengigRestaurant Boolean K Flag, ob Fahrzeug über ein rollstuhlgängiges Restaurant verfügt. Resultiert aus Anforde-rungen von Top-Programm Kundeninformation.

true

notrufeinrichtung Boolean K Flag, ob Fahrzeug über eine Notrufeinrichtung verfügt. Re-sultiert aus Anforderungen von Top-Programm Kundeninforma-tion.

true

niederflurwagen Boolean K Flag, ob Fahrzeug über ein Niederflurwagen verfügt. Resul-tiert aus Anforderungen von Top-Programm Kundeninforma-tion.

true

zusatzData KeyValue, Liste

K Zusätzliche Daten in Form von Schlüssel- Wertepaaren.


3.5.3.4 Fahrzeugidentifikation

Die Klasse Fahrzeugidentifikation identifiziert ein physische Fahrzeug. Die Identifika-

tion besteht aus der European Vehicle (EVN) Nummer. Diese Nummer besteht aus mehre-ren Teilen. Aktuell können die EVU noch nicht für alle Fahrzeugen die vollständige EVN Nummer liefern. Daher sind die einzelnen Teile der EVN optionale Attribute. Sofern dem EVU alle Teile der EVN bekannt sind, müssen die EVU die zusammengesetzte EVN Num-

mer liefern. Sind nicht alle Teile der EVN bekannt, muss mindestens die seriennummer

geliefert werden.


bauartcode String K Bauartcode (Loks) oder Austauschre-gime (Wagen) des Fahrzeugs der EVN-Identifikation. Zwei Stellen, falls nötig vorangestellt 0.

90, 91, 98

uicLaendercode String K UIC Ländercode. Zwei Stellen. 85, 80

fahrzeugtypNummer Integer K Nummer des Typs des Fahrzeugs. Die-ser Typ hat keine Beziehung zum Fahr-zeugtyp, der als Platzhalter für die kon-kreten Fahrzeuge verwendet wird. 4 Stellen, falls nötig vorangestellt 0.

8194, 0170

seriennummer Integer K Seriennummer des Fahrzeugs zum ge-gebenen Typ. 3 Stellen, falls nötig vo-rangestellt 0

052

pruefziffer Integer K Prüfziffer. 1 Stelle. Wikipedia: „Die Prüf-ziffer wird aus den ersten elf Stellen be-rechnet. Dazu wird die Quersumme der Ziffernfolge gebildet, die sich ergibt, wenn man die Ziffern abwechselnd mit 2 und 1 multipliziert (erste Stelle mit 2, zweite mit 1, dritte wieder mit 2 usw.); die Differenz dieser Quersumme zum nächsten Vielfachen von Zehn bildet die Prüfziffer. (Berechnungsbeispiel siehe Artikel zur Wagennummer) Bei der Ein-gabe in Computer wird über die Prüffzif-fer eine Plausibilitätskontrolle durchge-führt.“

7

EVN String K Vollständige EVN Nummer zusammen-gesetzt aus den einzelnen Teilen. Muss vom EVU nicht geliefert werden!

„9181 1216 141-2“

http://de.wikipedia.org/wiki/UIC-Wagennummer#Beispiele


3.5.3.5 Fahrzeugtyp

Die Klasse Fahrzeugtyp repräsentiert einen bestimmten Typ Fahrzeug aus Sicht der EVU.

Die EVU vergeben und verwalten ihre Fahrzeugtypen. Fahrzeugtypen werden in der Um-

laufplanung immer dann eingesetzt, wenn das konkrete Fahrzeug noch nicht bekannt ist.


kennung String M Fachlicher Schlüssel des Fahr-zeugtyps aus Sicht des EVU. Schlüssel muss eindeutig sein pro XML-Datei. Der Schlüssel muss dem Formationsservice nicht bekannt sein.

"Re456"

zbpBezeichnung String M Bezeichnung des Typs gemäss Zugbildungsplan.

"T"

verwalter String M EVU, das der Besitzer dieses Fahrzeugtyps ist. (KTU-Code gemäss SYFA). Es muss der gleiche Code wie heute bei KompoEVU verwendet werden. Aktuell ist der SYFA Verwal-tungscode Teil des fachlichen Schlüssels des Fahrzeugtyps. Die-ser fachliche Schlüssel wird von den ISB An-wendungen beim Aufruf der Zuglaufrech-nung benötigt.

„980“, „11“, "981"

steuertyp Steuertyp M Der Steuertyp des Fahrzeugs: Mögliche Werte: triebfahrzeug, steuerwagen, andere

triebfahrzeug

fahrzeugGattung String K Gattung, zu welcher der Fahr-zeugtyp gehört. Kann von von den EVU frei vergeben werden.

„GattungLe“

gewicht decimal K Gewicht der Fahrzeuge dieses Typs in Tonnen.

10.56

laenge decimal K Länge der Fahrzeuge dieses Typs in Metern.

20.45

achszahl Integer K Anzahl Achsen der Fahrzeuge dieses Typs.

8

vMax Integer K Maximal Geschwindigkeit der Fahrzeuge dieses Typs in Kilo-meter pro Stunde.

120

anzahl1Klasse Integer K Anzahl Plätze erster Klasse der Fahrzeuge dieses Typs.

20


anzahl2Klasse Integer K Anzahl Plätze zweiter Klasse der Fahrzeuge dieses Typs.

30

hatBehindertenabteil Boolean K Flag, ob Fahrzeuge dieses Typs ein Behindertenabteil haben.

true

istKlimatisiert Boolean K Flag, ob Fahrzeuge dieses Typs klimatisiert sind.

true

antriebsenergie Antriebsenergie M Angabe zur Antriebsenergie der Fahrzeuge dieses Typs. Mögli-che Werte: keine, elektrischMit-Rekuperation, elektrischOh-neRekuperation, diesel, dampf Für Fahrzeugtypen obligato-risch. Fahrzeugtypen, die über keine Antriebsenergie verfügen, haben den Wert keine.

„diesel“

zusatzData KeyValue Liste K Zusätzliche Daten zum Fahr-zeugtyp in Form von Schlüs-sel/Wertepaaren.

3.5.3.6 KeyValue

Die Klasse KeyValue beschreibt ein Schlüssel-Wertepaar. Diese Klasse wird verwendet,

um zusätzliche Attribute übertragen zu können, ohne vorgängige Anpassungen am XSD-

Schema.


key String M Eindeutiger Schlüssel „key“

value String M Wert zum gegebenen Schlüssel „value“

3.5.3.7 ZuegeTag

ZuegeTag beschreibt eine Liste von ZugTag. Neben den einzelnen ZugTag Datensätze

enthält diese Klasse Metainformationen, die für alle ZugTag Datensätze gültig sind.



zugTag ZugTag, Liste M Siehe ZugTag

fahrzeug Fahrzeug, Liste

K Siehe Fahrzeug

fahrzeugtyp Fahrzeugtyp, Liste

K Siehe Fahrzeugtyp

bp Betriebspunkt, Liste

K Siehe Betriebspunkt


3.5.3.8 ZugTag

Beschreibt einen Zug eines bestimmten Betriebstages, für den die Formationsdaten geliefert

werden.


identifikationTag ZugIdentifikationTag M Siehe ZugidentifikationTag

versionsID Integer M Eindeutige, aufsteigende technische Übertragungs-ID des Zugdatensatzes. Kann von den Abnehmern verwendet werden, um veraltete Updates zu de-tektieren.

1, 2

evu String M Bezeichnung des anlie-fernden EVU. Möglicher Werte: bls, sbbp, sbbc, sob

bls

aenderungszeitpunkt dateTime M Änderungszeitpunkt des Zugdatensatzes.

Siehe dateTime

erfasstInEvu Boolean M Legt fest, ob der Zug im EVU ohne zugrundelie-gende Trasse erfasst wur-de. Tritt nur auf, wenn das EVU sehr kurzfristige Än-derungen einplanen muss.

true

formationsfahrtJahr FormationsfahrtJahr, Liste

M Sieht Formationsfahrt

produktiveLeistungTag ProduktiveLeistungTag. Liste

K Siehe ProduktiveLeis-tungTag

verknuepfungTag VerknuepfungTag, Liste

K Siehe VerknuepfungTag

zuglaufPunkt Zuglaufpunkt, Liste M Siehe Zuglaufpunkt


3.5.3.9 ZugidentifikationTag

Die Klasse ZugidentifikationTag beschreibt die Identifikation eines Zuges an einem

bestimmten Betriebstag.


trassenID String K Trassen-ID des Zuges. Darf nur in Ausnahmefällen nicht gesetzt sein, wenn der Zug im EVU erfasst wurde.

„4711-001“

betriebstag Date M Betriebstag des Zuges gemäss NeTS.

siehe Da-tentyp date

zugnummer Integer M Zugnummer des Zuges. „4711“


3.5.3.10 FormationsfahrtTag

Die Klasse FormationsfahrtTag beschreibt ein von zwei Betriebspunkten begrenzte

Strecke eines Zuges, auf der keine Änderungen an den Formation stattfinden. Am Startpunkt

der Strecke können die Fahrzeuge dem Zug hinzugefügt werden. Am Endpunkt können

Fahrzeuge vom Zug entfernt werden.

Ein allfälliger Richtungswechsel führt zu einer neuen Formationsfahrt, da die Reihung der

Fahrzeuge ändert.


position Integer M Lückenlose Position der Formationsfahrt. Auf-steigend in Fahrtrich-tung. Bei einem Fahrt-richtungswechsel müs-sen die Positionen ge-spiegelt werden.

1

refVonZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das Attri-but Position des Zug-laufpunktes. Startpunkt der Formationsfahrt.

3

refBisZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das Attri-but Position des Zug-laufpunktes. Endpunkt der Formationsfahrt.

5

bremsreiheEVU Integer K Der von der EVU gelie-ferte Wert für die Bremsreihe der Forma-tionsfahrt

115

zugreiheEVU String K Der von der EVU gelie-ferte Wert für die Zug-reihe der Formations-fahrt

„R“

istPendelfaehig Boolean K Legt fest, ob die Forma-tion pendelfähig ist oder nicht.

true

fahrtypelementTag FahrtypelementTag, Liste

K Siehe Fahrtypelement-Tag


3.5.3.11 ProduktiveLeistungTag

ProduktiveLeistungTag umfasst Elemente (Fahrzeuge, Fahrzeugtypen) des gleichen

Umlaufs, die diesem Zug zugeordnet sind und als Einheit vor und nach dem produktiven

Einsatz im Zug zusammenbleiben.


nummer Integer M Technischer Schlüs-sel.

1, 501

refVonZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das Attribut Position des Zuglaufpunktes. Startpunkt der Pro-duktiven Leistung. Punkt, an dem Fahr-zeuge dieser Produk-tiven Leistung dem Zug hinzugefügt wur-den.

3

refBisZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das Attribut Position des Zuglaufpunktes. End-punkt der Produktiven Leistung. Punkt, bis zu dem Fahrzeuge dieser Produktiven Leistung dem Zug zugeordnet sind.

5

umlaufnummer Integer K Technischer Schlüssel auf den Umlauf, zu dem diese Produktive Leistung gehört. Um-läufe werden nicht geliefert.

6

tagesleistungNummer Integer K Technischer Schlüssel auf die Tagesleistung, zu der die Produktive Leistung gehört.

7

umlaufart Umlaufart K Möglicher Werte: grobplan, feinplan, unterhalt. Die Um-laufart bezieht sich auf das Planungssys-tem CERES von SBB-P. Die Umlaufart muss nicht geliefert werden.

„grobplan“


rolleTraktion RolleTraktion K Mögliche Werte: D, DD, DDD, DDDD, DDL, DL, DP, DV, L, LD, P, Q, QD, QDD, S, SS, V, VDD, VV, VVVV (D: unter Trak-tion ziehend, V: Vor-spann, d.h. ge-schleppt, P: unter Traktion stossend)

„DD“

direkterWagenlaufTag DirekterWagenlaufTag, Liste

K Siehe DirekterWagen-laufTag

elementInLeistung ElementInLeistungTag, Liste

K Siehe ElementInLeis-tung

3.5.3.12 VerknuepfungTag

Die Klasse VerknuepfungTag beschreibt eine Verknüpfung eines Elements mit einem vor-

herigen oder nachfolgenden Zug.


nummer Integer M Technischer Schlüssel für die Verknüpfung. Aufsteigend und eindeutig innerhalb des Zug-datensatzes.

3

zugidentifikationTag ZugidentifikationTag M Siehe ZugidentifikationTag

refBpNummer Integer M Referenz (Fremdschlüssel) auf die technische Nummer des Betriebspunkts.

2

rolleTraktion RolleTraktion K Mögliche Werte: D, DD, DDD, DDDD, DDL, DL, DP, DV, L, LD, P, Q, QD, QDD, S, SS, V, VDD, VV, VVVV (D: unter Traktion ziehend, V: Vorspann, d.h. geschleppt, P: unter Traktion stossend)

„D“

3.5.3.13 FahrtypelementTag

Ein FahrtypelementTag beschreibt ein betrieblich nicht trennbares Element des Zuges

(Einzel- oder Gliederfahrzeug) und enthält die fahrdynamisch relevanten Attribute. Insbeson-

dere verfügt ein FahrtypelementTag über den fachlichen Schlüssel des Fahrtyps. Der

Fahrtyp wird von der Infrastruktur vergeben sowie verwaltet und muss von den EVU in den

Fahrtypelementen verwendet werden.


.

Die zulässigen Werte für den Fahrtyp können durch das EVU beim Formationsservice bezo-

gen werden. Die Fahrtypen stehen als Excelliste und ab 31.01.2016 als Webservice zur Ver-

fügung.



position Integer M Position des Ele-ments innerhalb der Formationsfahrt

1, 5

fahrtypKennung String M Fachlicher Schlüssel des Fahrtyps. Dieser Schlüssel wird von der Infrastruktur vergeben und muss von den EVU gelie-fert werden.

"RBDe565"

refFzNummer Integer K Referenz (Fremd-schlüssel) auf das Attribut Nummer des Fahrzeuges.

4

gibtTraktion Boolean M Flag für die Angabe, ob ein Element tat-sächlich Traktion gibt oder nicht. Wer-den Traktionen oder Triebfahrzeuge nur geschleppt, ist der Wert false.

false

refProdLeistungNummer Integer M Referenz (Fremd-schlüssel) auf das Attribut Nummer der Produktiven Leis-tung.

3

refElementInLeistungNummer Integer M Referenz (Fremd-schlüssel) auf das Attribut Nummer von ElementInLeistung

2

vMaxAbweichung Integer K Temporäre Abwei-chung von vMax gegenüber dem in dem Fahrtypstamm-daten gespeicherten Wert. In Kilometer pro Stunde

80

fahrzeugtypelementTag Fahrzeugtypelement,Tag Liste

M Siehe Fahr-zeugtypElement


3.5.3.14 ElementInLeistungTag

Die Klasse ElementInLeistungTag beschreibt ein Element einer Produktiven Leistung.

Dieses Element ist eine betrieblich nicht trennbare Einheit.


nummer Integer M Technischer Schlüssel. Aufstei-gend und eindeutig innerhalb der Produktiven Leistung.

3

vonUnterhaltsLeistung String K Bezeichnung der vorangehenden Unterhaltsleistung. Z.B "HR/26." für Hauptreinigung am 26. des heutigen Monats. Nur wenn ref-VonVerknuepfungNummer NULL ist. Bezeichnung/Codierung kann vom EVU frei gewählt werden. Muss nicht geliefert werden!

"HR/26."

fuerUnterhaltsLeistung String K Bezeichnung der nachfolgenden Unterhaltsleistung. Nur wenn ef-FuerVerknuepfungNummer NULL ist. Bezeichnung/Codierung kann vom EVU frei gewählt werden. Muss nicht geliefert werden!

"HR/26."

refVonVerknuepfungNummer Integer K Referenz (Fremdschlüssel) auf das Attribut Position von Verknue-pfungTag. Gesetzt, wenn das Element von einem Vorgängerzug kommt.

3

refFuerVerknuepfungNummer Integer K Referenz (Fremdschlüssel) auf das Attribut Position von Verknue-pfungTag. Gesetzt, wenn das Element von einen Nachfolgerzug hat.

4


3.5.3.15 DirekterWagenlaufTag

Die Klasse DirekterWagenlaufTag verknüpft die Produktive Leistung eines Zuges mit

einem Nachfolgerzug, sofern die Reisenden in den Fahrzeugen bleiben können.


position Integer M Beschreibt die Reihenfolge der direkten Wagenläufe. Direkter Vorgängerzug hat den Wert -1. Weitere Vorgängerzüge haben kleiner werdende Ganze Zah-len. Direkter Nachfolgerzug hat den Wert 1. Weitere Nachfolger haben aufsteigende Nummern.

-1, 1

zugidentifikationTag ZugidentifikationTag M Siehe Klasse Zugidentifikation-Tag

refVonBpNummer Integer M Referenz (Fremdschlüssel) auf die technische Nummer des Von-Betriebspunkts.

2

vonZeit Integer M Sekunden ab Mitternacht des Betriebstages.

3521

refBisBpNummer Integer M Referenz (Fremdschlüssel) auf die technische Nummer des Bis-Betriebspunkts.

2

bisZeit Integer M Sekunden ab Mitternacht des Betriebstages.

3591


3.5.3.16 FahrzeugtypelementTag

Dies Klasse FahrzeugtypelementTag enthält die für die Kundeninformation relevanten

Daten. Ein Fahrtypelement enthält immer mindestens ein Fahrzeugtypelement. Ein Einzel-

fahrzeug (autonomes, kuppelbares Fahrzeug) wird als ein Fahrtypelement, mit einem Fahr-

zeugtypelement abgebildet. Ein Gliederfahrzeug (eine betrieblich nicht trennbare Einheit aus

mehreren Teilfahrzeugen) besteht im Modell aus einer Fahrtypelement mit mehreren Fahr-

zeugtypelementen.


position Integer M Technischer Schlüssel. Aufsteigend und ein-deutig innerhalb Fahr-typelement

3

refFztypKennung String M Referenz (Fremd-schlüssel) auf das Attri-but Kennung der Klasse Fahrzeugtyp.

"Bj"

refFzNummer Integer K Referenz (Fremd-schlüssel) auf das Attri-but Kennung der Klasse Fahrzeug.

2

fzNummerFuerReservation String K 4

fahrzeugZustandKunde FahrzeugZustandKunde K Mögliche Werte: nor-mal, betrieblichGe-schlossen, technisch-Geschlossen, restau-rantUnbedient, deklas-siert

„normal“

zusatzData KeyValue, Liste K Zusätzliche Daten in Form von Schlüssel- Wertepaaren.

Das nachfolgende Diagramm zeigt die komplette Modellierung der Tagesformationen mit

allen Klassen und Attributen.


FosRoot Header

schemaVersion: string

ZuegeTag

Fahrzeug

nummer: integer

anzahlRestaurantPlaetze: integer [0..1]

anzahlRollstuhlPlaetze: integer [0..1]

anzahlBetten: integer [0..1]

anzahlVelohaken: integer [0..1]

hatVeloplattform: boolean [0..1]

anzahlRollstuhlToiletten: Integer [0..1]

rollstuhlgaengigRestaurant: boolean [0..1]

notrufeinrichtung: boolean [0..1]

niederflurwagen: boolean [0..1]

Fahrzeugtyp

kennung: string

zbpBezeichnung: string

verwalter: string

steuertyp: string

fahrzeugGattung: string [0..1]

gewicht: decimal [0..1]

laenge: decimal [0..1]

achszahl: integer [0..1]

vMax: Integer [0..1]

anzahl1Klasse: integer [0..1]


hatBehindertenabteil: boolean [0..1]

istKlimatisiert: boolean [0..1]

etcsFaehig: boolean [0..1]

antriebsenergie: Antriebsenergie [0..1]

KeyValue

key: string

value: string

Betriebspunkt

nummer: Integer

uicLaendercode: integer

uicCode: integer

abkuerzung: string [0..1]

DirekterWagenlaufTag

position: integer

vonZeit: integer

bisZeit: integer

refVonBpNummer: Integer

refBisBpNummer: Integer

FahrzeugIdentifikation

bauartcode: string [0..1]

uicLaendercode: string [0..1]

fahrzeugtypNummer: string [0..1]

seriennummer: string [0..1]

pruefziffer: string [0..1]

EVN: string [0..1]

ElementInLeistungTag

nummer: integer

vonUnterhaltsLeistung: string [0..1]

fuerUnterhaltsLeistung: string [0..1]

refVonVerknuepfungNummer: Integer [0..1]

refFuerVerknuepfungNummer: Integer [0..1]

Produktiv eLeistungTag

nummer: integer

refVonZuglaufpunktPosition: integer

refBisZuglaufpunktPosition: integer

umlaufnummer: integer [0..1]

tagesleistungNummer: integer [0..1]

umlaufArt: Umlaufart [0..1]

rolleTraktion: RolleTraktion [0..1]

VerknuepfungTag

nummer: integer


refBpNummer: Integer [0..1]

ZugTag

versionsId: integer

evu: string

aenderungszeitpunkt: dateTime

erfasstInEvu: boolean

ZugidentifikationTag

trassenId: string [0..1]

betriebstag: date

zugnummer: integer

Zuglaufpunkt

position: integer

refBpNummer: integer

zusatzId: string [0..1]

zeitAn: integer

zeitAb: integer




FormationsfahrtTag

position: integer



istPendelfaehig: boolean [0..1]

bremsreiheEVU: Integer

zugreiheEVU: String [0..1]

FahrtypelementTag

position: integer

fahrtypKennung: string

refFzNummer: integer [0..1]

gibtTraktion: boolean [0..1]

refProdLeistungNummer: integer

refElementInLeistungNummer: integer

vMaxAbweichung: integer [0..1]

FahrzeugtypelementTag

position: integer

refFztypKennung: string

refFzNummer: integer [0..1]

fzNummerFuerReservation: string [0..1]

fahrzeugZustandKunde: FahrzeugZustandKunde [0..1]

1..*

1

*

1

1

1

1

*

1..*

1..*

*

1

1

0..1

1

1

0..1

1

1

1

1

*

1..*

*

*

0..*

0..1

*

0..*

0..1 0..1

2..*

1


3.5.4 Jahresformationen

Das Diagramm zeigt die fachliche Struktur der Jahresformation. Klassen mit gleichen Namen

wie in der Tagesformation sind identisch. Diese Klassen werden sowohl in den Tages- wie

auch in den Jahresformationen verwendet.

ElementInLeistungJahr

FosRoot Header

ZuegeJahr Fahrzeug FahrzeugIdentifikation

Fahrzeugtyp

KeyValue

ZugJahr

Produktiv eLeistungJahr

Zuglaufpunkt

ZugidentifikationJahr Betriebspunkt

VerknuepfungJahr



Verkehrsperiode

FormationsfahrtJahr

FahrtypelementJahr FahrzeugtypelementTag

1

*

1..*

1

1

*

bis dwl

0..1

*

1

2..*

1..*

1

1..*

0..1

1

1

*

1

1

*

1

*

*

1

von dwl

0..1

*

0..1

0..*

*

1

*

1


Im Falle der Jahresformation enthält FosRoot genau eine Klasse ZuegeJahr. ZuegeJahr

ist die Containerklasse für ZugJahr und enthält zusätzlich Listen der Klassen Fahrzeug,

Fahrzeugtyp und Verkehrsperiode. Diese Klassen werden von anderen Klassen über

Schlüssel referenziert. Ein ZugJahr verfügt über die eindeutige Identifikation Zugidenti-

fikationJahr bestehend aus TrassenID, Zugnummer (nur relevant für Züge, die im EVU

erfasst werden mussten und noch über keine TrassenID verfügen), Fahrplanperiode

und Verkehrsperiode. Im Gegensatz zum alten Planungssystem SYFA werden im neuen

Planungssystem NeTS keine explizite Jahreszüge geplant. Als Ersatz für die Jahreszüge

wird der sogenannte Grundfahrplan zur Verfügung gestellt. Der Grundfahrplan wird algorith-

misch ermittelt und verfügt über kein analoges Konstrukt wie die SYFA-Zusatzzugnummer.

Die einzelnen Varianten der Zug des Grundfahrplans werden lediglich über die Verkehrspe-

riode identifiziert.

ZugJahr kann je über Listen aus VerknuepfungJahr, ProduktiveLeistungJahr,

Formationsfahrt und Zuglaufpunkt verfügen. Eine Verknüpfung enthält ein ZugIden-

tifikationJahr, welche den betroffenen Zug beschreibt. VerknuepfungJahr verfügt

über eine eindeutige Nummer. ElementInLeistungJahr verwendet diese Position als

Fremdschlüssel.

ProduktiveLeistungJahr verfügt über eine Verkehrsperiode mit den Gültigkeitstagen.

Die folgenden Abschnitte beschreiben die Klassen, die ausschliesslich in den Jahresformati-

onen verwendet werden. Klassen, die in den Tages- und Jahresformationen verwendet wer-

den, sind im Kapitel zu den Tagesformationen beschrieben.


3.5.4.1 Verkehrsperiode

Die Klasse Verkehrsperiode beschreibt die Tage, an denen ein bestimmter Zug fährt o-

der eine bestimmte Produktive Leistung eingesetzt wird. Die Verkehrsperiode besteht im

Wesentlichen aus ein Bit-String, eine Abfolge von Nullen und Einsen. Eine Eins bedeutet,

dass der an diesem Tag ein Zug fährt. Bei einer Null fährt der Zug an diesem Tag nicht. Der

Bit-String beginnt am ersten Tag der jeweiligen Fahrplanperiode. Die erste Ziffer legt also

fest, ob der Zug am Tag des Fahrplanwechsels fährt.


nummer Integer M Technischer Schlüssel für die Verkehrsperi-ode.

1, 3, 5

fahrplanperiode Integer M Fahrplanperiode des Zuges gemäss NeTS. siehe Datentyp date

bitString String M Bit-String mit 0 und 1. „01011101“

beschriftungD String K Beschreibung der VP auf Deutsch

beschriftungF String K Beschreibung der VP auf Französisch

beschriftungI String K Beschreibung der VP auf Italienisch

3.5.4.2 ZuegeJahr

ZuegeJahr beschreibt eine Liste von ZugJahr. Neben den einzelnen ZugJahr Datensät-

zen enthält diese Klasse Metainformationen, die für alle ZugJahr Datensätze gültig sind.


zugJahr ZugJahr, Liste M Siehe ZugJahr

fztyp Fahrzeugtyp, Liste

K Siehe Fahrzeugtyp

vp Verkehrsperiode, Liste

K Siehe Verkehrsperiode

bp Betriebspunkt Liste

K Siehe Betriebspunkt


3.5.4.3 ZugJahr

Beschreibt einen Zug eines bestimmten Betriebstages, für den die Formationsdaten geliefert

werden.


identifikationJahr ZugIdentifikationJahr M Siehe Zugidentifikation-Jahr

versionsId Integer M Eindeutige, aufsteigende technische Übertra-gungs-ID des Zugdaten-satzes. Kann von den Abnehmern verwendet werden, um veraltete Updates zu detektieren.

2345663

Evu String M Bezeichnung des anlie-fernden EVU. Möglicher Werte: bls, sbbp, sbbc, sob

sbbp

aenderungszeitpunkt dateTime M Änderungszeitpunkt des Zugdatensatzes.

Siehte dateTime

kommentar String K Kommentar zum Zug

Formationsfahrt FormationsfahrtJahr, Liste

M Siehe Formationsfahrt

produktiveLeistungJahr ProduktiveLeistungJahr, Liste

K Siehe ProduktiveLeis-tungJahr

verknuepfungJahr VerknuepfungJahr, Liste

K Siehe VerknuepfungJahr

zuglaufPunkt Zuglaufpunkt, Liste M Siehe Zuglaufpunkt


3.5.4.4 ZugidentifikationJahr

Die Klasse ZugidentifikationJahr beschreibt die Identifikation einer bestimmten Vari-

ante eines Zuges.


trassenID String Trassen-ID des Zuges. „4711-001“

refVpNummer Integer M Referenz (Fremdschlüssel) auf das Attribut Nummer der Klasse Verkehr-speriode. Legt die Tage fest, an de-nen der Zug fährt.

2

zugnummer Integer M „4711“

3.5.4.5 FormationsfahrtJahr

Die Klasse FormationsfahrtJahr beschreibt eine Formationsfahrt in den Jahresformati-

onen. Beschreibung siehe FormationsfahrtTag.



position Integer M Lückenlose Position der Formationsfahrt. Aufsteigend in Fahrt-richtung. Bei einem Fahrtrichtungswechsel müssen die Positionen gespiegelt werden.

1

refVonZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das At-tribut Position des Zug-laufpunktes. Startpunkt der Formationsfahrt.

3

refBisZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das At-tribut Position des Zug-laufpunktes. Endpunkt der Formationsfahrt.

5

bremsreiheEVU Integer K Der von der EVU gelie-ferte Wert für die Bremsreihe der Forma-tionsfahrt

115

zugreiheEVU String K Der von der EVU gelie-ferte Wert für die Zug-reihe der Formations-fahrt

„R“

istPendelfaehig Boolean K Legt fest, ob die For-mation pendelfähig ist oder nicht.

true

fahrtypelementJahr FahrtypelementJahr, Liste

K Siehe Fahrtypelement-Jahr

3.5.4.6 FahrtypelementJahr

Die Klasse FahrtypelementJahr beschreibt ein Fahrtypelement in den Jahresformatio-

nen. Beschreibung siehe FahrtypelementTag.

Die Fahrtypelemente haben implizit eine Verkehrsperiode mit Gültigkeitstagen. Die Forma-

tionsfahrt enthält alle Elemente, die an mindestens einem Tag verwendet werden. Jedes

FahrtypelementJahr enthält eine Referenz auf ein ElementInLeistungJahr. Ein

ElementInLeistungJahr ist einer ProduktiveLeistungJahr zugeordnet. Produkti-

veLeistungJahr verfügt über eine Verkehrsperiode. Diese Verkehrsperiode legt fest, an

welchen Tagen ein Fahrtypelement in der Formationsfahrt enthalten ist



position Integer M Position des Ele-ments innerhalb der Formationsfahrt

1, 5

fahrtypKennung String M Fachlicher Schlüssel des Fahrtyps. Dieser Schlüssel wird von der Infrastruktur vergeben und muss von den EVU gelie-fert werden.

"RBDe565"

gibtTraktion Boolean M Flag für die Angabe, ob ein Element tat-sächlich Traktion gibt oder nicht. Wer-den Traktionen oder Triebfahrzeuge nur geschleppt, ist der Wert false-

false

refProdLeistungNummer Integer M Referenz (Fremd-schlüssel) auf das Attribut Nummer der Produktiven Leis-tung.

3

refElementInLeistungNummer Integer M Referenz (Fremd-schlüssel) auf das Attribut Position von ElementInLeistung

2

vMaxAbweichung Integer K Temporäre Abwei-chung von vMax gegenüber dem in dem Fahrtypstamm-daten gespeicherten Wert. In Kilometer pro Stunde

80

kommentar String K Kommentar zum Fahrtypelement

fahrzeugtypelementJahr FahrzeugtypelementJahr, Liste

M Siehe Fahr-zeugtypElement


3.5.4.7 FahrzeugtypelementJahr

Die Klasse FahrzeugtypelementJahr beschreibt ein Fahrzeugtypelement in den Jahres-

formationen. Beschreibung siehe FahrzeugtypelementTag.


position Integer M Technischer Schlüssel. Aufsteigend und ein-deutig innerhalb Fahr-typelement

3

refFztypKennung String M Referenz (Fremd-schlüssel) auf das Attri-but Kennung der Klas-se Fahrzeugtyp.

"Bj"

fzNummerFuerReservation String K 4

fahrzeugZustandKunde FahrzeugZustandKunde K Mögliche Werte: nor-mal, betrieblichGe-schlossen, technisch-Geschlossen, restau-rantUnbedient, deklas-siert

„normal“

zusatzData KeyValue, Liste K Zusätzliche Daten in Form von Schlüssel- Wertepaaren.


3.5.4.8 ProduktiveLeistungJahr

ProduktiveLeistungJahr umfasst Elemente des gleichen Umlaufs, die diesem Zug zu-

geordnet sind und als Einheit vor und nach dem produktiven Einsatz im Zug zusammenblei-

ben.


nummer Integer M Technischer Schlüs-sel.

4

refVonZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das Attribut Position des Zuglaufpunktes. Start-punkt der Produktiven Leistung. Punkt, an dem Fahrzeuge dieser Produktiven Leistung dem Zug hinzugefügt wurden.

3

refBisZuglaufpunktPosition Integer M Referenz (Fremd-schlüssel) auf das Attribut Position des Zuglaufpunktes. End-punkt der Produktiven Leistung. Punkt, bis zu dem Fahrzeuge dieser Produktiven Leistung dem Zug zugeordnet sind.

5

umlaufnummer Integer K Technischer Schlüssel auf den Umlauf, zu dem diese Produktive Leistung gehört. Um-läufe werden nicht geliefert.

675

tagesleistungNummer Integer K Technischer Schlüssel auf die Tagesleistung, zu der die Produktive Leistung gehört.

345

gueltigVon Date M Tag, ab dem die Pro-duktive Leistung gültig ist.

Siehe date

gueltigBis Date M Tag, bis zu dem die Produktive Leistung gültig ist.

Siehe date

refVpNummer Integer M Referenz auf die Ver- 5


kehrsperiode

tageverschiebung Integer K Unterschied zwischen Datum des Zuges und Datum des Umlaufs in Tagen.

tagart Integer K Indikative Tagart der Produktiven Leistung. Unabhängig zur tat-sächlichen Verkehrs-periode. Dient der besseren Lesbarkeit. Mögliche Werte siehe unten.

34

rolleTraktion RolleTraktion K Mögliche Werte: D, DD, DDD, DDDD, DDL, DL, DP, DV, L, LD, P, Q, QD, QDD, S, SS, V, VDD, VV, VVVV (D: unter Traktion zie-hend, V: Vorspann, d.h. geschleppt, P: unter Traktion stos-send)

refVonBpNummerDwl Integer K Referenz (Fremd-schlüssel) auf den Startbetriebspunkt der Produktiven Leistung.

refBisBpNummerDwl Integer K Referenz (Fremd-schlüssel) auf den Endbetriebspunkt der Produktiven Leistung.

elementInLeistung, Liste ElementInLeistungJahr K Siehe ElementInLeis-tungJahr

Mögliche Werte des Attributs Tagart (XSD Enumeration):

11, 12, 13, 14, 15, 16, 17

22, 23, 24, 25, 26, 27

31, 33, 34, 35, 36, 37

41, 42, 44, 45, 46, 47

51, 52, 53, 55, 56, 57

61, 62, 63, 64, 66, 67

71, 72, 73, 74, 75, 77


3.5.4.9 ElementInLeistungJahr

Die Klasse ElementInLeistungTag beschreibt ein Element einer Produktiven Leistung.

Dieses Element ist eine betrieblich nicht trennbare Einheit (Einzel- oder Gliederfahrzeug).


position Integer M Technischer Schlüssel. Aufsteigend und eindeutig.

4

refVerknuepfungNummer Integer K 3

refVpNummerAusschluss Integer K Referenz Fremdschlüssel auf eine Ver-kehrsperiode. Enthält die Tage, den denen das Element nicht zur Produktiven Leis-tung gehört. Die Verkehrsperiode enthält immer ein Subset der Gültigkeitstage der Verkehrsperiode der Produktiven Leistung, zu der das Element gehört.

5

fakultativ Boolean K Zeigt an, ob des Element fakultativ ist. true


3.5.4.10 VerknuepfungJahr

Die Klasse VerknuepfungJahr beschreibt eine Verknüpfung eines Elements mit einem

vorherigen oder nachfolgenden Zug.


position Integer M Position der Verknüpfung, technischer Schlüssel

4

istVorgaenger Boolean M Legt fest, ob es sich um eine Verknüpfung zu einem Vor-gängerzug handelt.

true

zugidentifikationJahr ZugidentifikationJahr M Legt fest, ob es sich um eine Verknüpfung zu einem Vor-gängerzug handelt.

refVpNummer Integer M Verkehrsperiode mit den Tagen, an denen die Ver-knüpfung gültig ist.

1001010

tagedifferenz Integer K Anzahl Tage zwischen den verknüpften Zügen. Von: Tagdifferenz <= 0 Für: Tagdifferenz >= 0

1

refBpNummer Integer K Referenz (Fremdschlüssel) auf die technische Nummer des Betriebspunkts.

2

rolleTraktion RolleTraktion K Mögliche Werte: D, DD, DDD, DDDD, DDL, DL, DP, DV, L, LD, P, Q, QD, QDD, S, SS, V, VDD, VV, VVVV (D: unter Traktion ziehend, V: Vorspann, d.h. ge-schleppt, P: unter Traktion stossend)

„P“


Das nachfolgende Diagramm zeigt die komplette Modellierung der Jahresformationen mit

allen Klassen und Attributen.

3.5.5 Umgang mit Meldungen

Eine Meldung zu einem Zug enthält immer alle aktuellen Daten und ist in sich vollständig,

d.h. es werden nie partielle Updates zu einem Zug geliefert. Änderungen am Zug oder der

Formation führen immer dazu, dass immer ein kompletter Zugdatensatz übermittelt werden

muss.

Jeder Zugdatensatz verfügt über ein Attribut aenderungszeitpunkt, welches im Normal-

fall den Zeitpunkt der letzten Änderung im Lieferantensystem enthält (sofern bekannt). Durch

den FOS werden Meldungen nur übernommen, wenn der mitgelieferte aenderungszeit-

punkt jünger ist als der im FOS gespeicherte Wert. Deswegen ist wichtig, dass der aende-

ElementInLeistungJahr

position: integer

refVerknuepfungNummer: integer

refVpNummerAusschluss: Integer [0..1]

fakultativ: Integer [0..1]

FosRoot Header

schemaVersion: string

ZuegeJahr

Fahrzeugtyp

kennung: string

zbpBezeichnung: string

verwalter: string

steuertyp: string

fahrzeugGattung: string [0..1]

gewicht: decimal [0..1]

laenge: decimal [0..1]

achszahl: integer [0..1]

vMax: Integer [0..1]



hatBehindertenabteil: boolean [0..1]

istKlimatisiert: boolean [0..1]

etcsFaehig: boolean [0..1]

antriebsenergie: Antriebsenergie [0..1]

KeyValue

key: string

value: string

ZugJahr

versionsId: integer

evu: string

aenderungszeitpunkt: dateTime

kommentar: String [0..*]

Produktiv eLeistungJahr

nummer: integer

gueltigVon: date

gueltigBis: date

refVpNummer: integer



umlaufnummer: integer [0..1]

tagesleistungNummer: integer [0..1]


umlaufArt: UmlaufArt [0..1]

refVonBpNummerDwl: Integer [0..1]

refBisBpNummerDwl: Integer [0..1]

tageverschiebung: Integer [0..1]

tagart: Tagart [0..1]

Zuglaufpunkt

position: integer

refBpNummer: integer

zusatzId: string [0..1]

zeitAn: integer

zeitAb: integer


ZugidentifikationJahr

trassenId: string

refVpNummer: integer

zugnummer: integerBetriebspunkt

nummer: Integer

uicLaendercode: integer

uicCode: integer

abkuerzung: string [0..1]

VerknuepfungJahr

nummer: integer

istVorgaenger: boolean

refBpNummer: Integer [0..1]


tagedifferenz: Integer [0..1]



Verkehrsperiode

nummer: integer

bitString: string

fahrplanperiode: integer

beschriftungD: string [0..1]

beschriftungF: string [0..1]

beschriftungI: string [0..1]

FormationsfahrtJahr

position: integer



istPendelfaehig: boolean [0..1]

bremsreiheEVU: Integer [0..1]

zugreiheEVU: String [0..1]

FahrtypelementJahr

position: integer

fahrtypKennung: string

gibtTraktion: boolean [0..1]

refProdLeistungNummer: integer

refElementInLeistungNummer: integer

vMaxAbweichung: integer [0..1]

kommentar: String [0..1]

FahrzeugtypelementJahr

position: integer

refFztypKennung: string

fzNummerFuerReservation: string [0..1]

fahrzeugZustandKunde: FahrzeugZustandKunde [0..1]

1

1

1

1

1

2..*

*

1..*

1..*

0..1

1

1

1

1..*

1

0..1

bis dwl

0..1

1

**

*

0..*

*

1*

1

von dwl

0..1

*

1..*


rungszeitpunkt den tatsächlichen Zeitpunkt der fachlichen Änderung beschreibt und nicht

den Zeitpunkt der Meldungsgenerierung.

3.5.6 Versionierung Schema und Meldungen

Die Versionsnummer besteht aus einer Major, Minor und Hotfix Nummer:

- Die Major-Versionsnummer wird hochgezählt, wenn das XSD-Schema gegenüber der

vorherigen Version einen Schemabruch aufweist. Ein Schemabruch erfolgt dann,

wenn ein Instanzendokument der vorherigen Version nicht mehr gegen das neue

Schema validiert werden kann.

- Eine Erhöhung der Minor-Versionsnummer dagegen führt zu keinem Schemabruch.

Die Versionsnummern werden von SBB Infrastruktur vergeben.

Die Major-Versionsnummer ist im Namespace der Schemadefinition enthalten. Der Aufbau

des Namespaces ist wie folgt: http://www.sbb.ch/schemas/sbb-i/famos/fos/in/vx

Dabei bezeichnet x die Nummer der Major Version.

Im XSD Schemadokument ist die vollständige Version im version Attribut des Schemas

enthalten. Major und Minor Versionsnummern sind durch einen Punkt getrennt und enthalten

keine vorangestellten Nullen.

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementForm-

Default="unqualified" attributeFormDefault="qualified" version="1.2.1">

Das XML-Instanzendokument verfügt im Wurzelelement TFormRoot über das Attribut

schemaVersion. Dieses Attribut enthält die Version des Instanzendokuments. Dieses Attri-

but wird vom Lieferanten gesetzt und ist gleich aufgebaut wie das version Attribut des

Schemadokuments Major.Minor.Hotfix

Eine bestimmte Version des Formationsservices kann angelieferte XML Instanzendokumen-

te mit gleicher Major-Versionsnummer verarbeitet. Die Minor-Versionsnummer des angelie-

ferten XML-Dokuments darf dagegen kleiner sein als die Minor-Versionsnummer des Forma-

tionsservice, jedoch nie grösser. Lieferanten müssen mit der Einführung einer neuen Minor-

Version warten, bis sie beim FOS eingeführt worden ist.

SBB Infrastruktur legt fest, welche Versionen durch FOS verarbeitet werden können (siehe

auch Kapitel 3.8).

3.5.7 Validierungskriterien

Damit eine Meldung einer EVU von FOS verarbeitet werden kann, müssen die folgenden

Bedingungen erfüllt sein:

1. Die Meldung/File muss dem gültigen XML-Schema entsprechen und dagegen vali-

diert werden können.

2. Die Versionsnummer der Meldung muss korrekt sein (siehe Kapitel 3.5.6).

http://www.w3.org/2001/XMLSchema


3. Eine Meldung enthält einen oder mehrere Zuge. Es gibt keine leeren Meldungen. Je-

de Meldung zu einem Zug muss alle Daten der enthaltenen Züge beinhalten (inkl.

Verkehrsperioden, Fahrzeuge und Fahrzeugtypen).

4. Die Formationen dürfen nur gültige und vom ISB zugelassene Fahrtypen enthalten.

5. Örtliche und Zeitliche Konsistenz bei der Abfolge der Betriebspunkte muss sicherge-

stellt sein.

6. Alle Referenzen müssen innerhalb der Meldung aufgelöst werden können.

7. Attribute für Jahres- und Tagesformationen müssen konsistent gesetzt werden. Ein

Datensatz darf nur tages- oder jahresrelevante Attribute gesetzt haben: bei Tages-

formationen etwa Betriebstag des Zuges, bei Jahresformationen etwa die Verkehrs-

periode. Ein Zug darf nicht gleichzeitig einen Betriebstag und eine Verkehrsperiode

aufweisen.

3.5.8 Szenarien

Die folgenden Szenarien sind im Bereich der Schnittstelle von Interesse (nicht abschlies-

send, für umfassendere Szenarien vgl. Testfälle):

ID Was Übermittlung Schnittstelle

Bemerkungen

SZ01 Technische Probleme seitens EVU (mit EVU Ressource Planning Tool).

Nichts Nachführen der wichtigsten Daten über FOS GUI.

SZ02 Löschungen von kompletten Zügen werden nicht an FOS übermittelt.

Nichts FOS kennt den Sollfahrplan, Löschungen von Trassen (Aus-fälle) müssen durch EVU nicht an FOS übermittelt werden.


3.6 Hand-Shake

In diesem Kapitel sind die notwendigen Vereinbarungen zwischen FOS und liefernden EVU

dokumentiert um einen reibungslosen Betrieb zu gewährleisten.

3.6.1 Meldungsanlieferung und Zeitfenster

Die EVU liefern separate Dateien für Tages- und Jahresformationen. Eine Datei darf nicht

gleichzeitig Tages- und Jahresformationen enthalten.

Die Tagesformationen müssen durch das EVU für ein Zeitfenster von -2 Tage (in die Ver-

gangenheit) bis +20 Tage (in die Zukunft) geliefert werden. Die Basis dazu erfolgt mit Ganz-

tageslieferung zwischen 2 und 3 Uhr morgens und beinhaltet die Tagesformationen für den

(ab heute) 20 Tag. Diese Anforderung stammt vom Top-Programm Kundeninformation. Rund

um die Uhr werden anschliessend Updates zu den geänderten Tagesformationen (im Zeit-

fenster -2+20 Tage) nachgeliefert und so die bestmögliche Aktualität sicher gestellt. Die E-

VUs dürfen Formationen bis höchsten -5 Tage anliefern. Ältere Tagesformationen werden

vom FOS ignoriert.

Der Formationsservice muss nicht in der Lage sein, fehlende Formationsdaten zu erkennen.

Es ist Aufgabe der EVU sicherzustellen, dass alle Tagesformationen für den angegebenen

Zeithorizont geliefert werden.

Alle zwei Wochen liefert das EVU den gesamten, vollständigen und aktuellen Jahresfahr-

plan der aktuellen Fahrplanversion, ab Oktober zusätzlich denjenigen des Folgejahres.

3.6.2 Signalisierung und Fileübermittlung

Um beim Einlesen die richtige Reihenfolge sicher zu stellen, um Überschreibefehler durch

alte Daten zu verhindern und um nur vollständig transferierte Files zu lesen, sind die folgen-

den Regeln durch die EVU einzuhalten. Dabei kommt dem Zeitstempel im Filenamen eine

zentrale Bedeutung zu, weil damit die Reihenfolge beim Einlesen gesteuert und ältere Files

vor neueren eingelesen werden:

1. Die Übermittlung der Dateien durch das EVU an den FOS muss in der Reihenfolge

der Datengenerierung (Zeitstempel im Filenamen) erfolgen.

2. Jedes neu übermittelte File muss einen Zeitstempel tragen der grösser ist als die

Zeitstempel der bereits gelieferten Files.

Ein typischer Ablauf sieht dabei wie folgt aus: Im hektischen Tagesgeschäft werden bei der

EVU verschiedene Formationen (allenfalls auch wiederholt) geändert. Für die geänderten

Formationen werden durch die EVU- Software entsprechende Meldungen generiert, auf den

FOS FTP-Server geladen und nach Übermittlung die Endung auf .xml geändert. FOS wird in

konfigurierbaren Zeitintervallen die neuen und vollständig transferierten Files (erkennbar an

der Endung .xml) in der Reihenfolge ihres Alters (Altes zuerst, Neuste zuletzt) importieren.


3.6.3 Fehlerbehandlung

Die Prüfung der gelieferten Formationsfiles geschieht in zwei Schritten: Erstens eine struktu-

relle Prüfung (durch Info-Hub PT) und zweitens eine inhaltliche Prüfung und Validierung (bei

CIS Infra).

Strukturelle Prüfung

Bei der strukturellen Prüfung wird:

- die Version des gelieferten Files geprüft

- das gelieferte File gegenüber dem Schema verifiziert

- bei Dateien im speed-Ordner geprüft, ob es sich beim Betriebstag der Tagesformati-

on um den heutigen Tag handelt

- bei Dateien im tag-Ordner geprüft, ob es sich um Tagesformationen handelt

- bei Dateien im jahr-Ordner geprüft, ob es sich um Jahresformationen handelt

Falls dabei ein Fehler auftritt, wird das File nicht weiter verarbeitet und in den error-Ordner

des FTP Verzeichnis verschoben.

Inhaltliche Prüfung

Nach bestandener struktureller Prüfung werden bei der inhaltlichen Prüfung, welche im

Rahmen der Persistierung der Daten erfolgt, alle Punkte gemäss Kapitel 3.5.7 geprüft. Aller-

dings wird nicht mehr das ganze File als Entität behandelt, sondern jeder Zug für sich geprüft

und eingelesen.

Ein fehlerhafter Zug wird nicht abgelegt und auch nicht weiterverarbeitet, stattdessen wird

die liefernde EVU über den Fehler alarmiert. Der Prüfungsprozess wird anschliessend beim

nächsten Zug fortgesetzt. Das alarmierte EVU muss in der Folge den beanstandeten Zug

neu einliefern.

Nachdem beide Prüfungen erfolgt sind, wird – falls Fehler aufgetreten sind - das liefernde

EVU informiert (E-Mail Alarming). Die EVU haben Zugriff auf das Fehlerlog des Formations-

service. Sie müssen den entsprechenden Fehler schnellstmöglich beheben und neue und

korrekte Daten in der korrekten Struktur nachliefern. Weil solche Fehler vor allem während

Entwicklung und Test auftreten und nur selten im Betrieb, genügt eine einfache Alarmierung.

3.6.4 Alarming und Notifizierung

Eine Alarmierung wird im Fehlerfall, sowohl bei der strukturellen als auch bei der inhaltlichen

Prüfung ausgelöst. Im Falle eines Fehlers bei der strukturellen oder inhaltlichen Prüfung wird

eine E-Mail an den entsprechenden E-Mail-Verteiler mit folgendem Mindestinhalt geschickt:

Zeitpunkt des Fehlers,

Filename der fehlerhaften Datei

Fehlercodes

Fehlermeldungen

Bei fachlicher Prüfung: fachlicher Schlüssel der betroffenen Tages- oder Jahresfor-

mation


3.6.5 Löschung von Files

FOS ist für die Löschung der gelieferten, verarbeiteten oder fehlerhaften Files verantwortlich,

die liefernde EVU muss sich nicht darum kümmern. FOS wird die gelieferten Files mindes-

tens 15 Tage aufbewahren.

3.6.6 Initial Load und Nachlieferungen

Im Fall von Problemen, Katastrophen oder Teilausfällen muss FOS ausgewählte Formati-

onsdaten der EVU neu einlesen können. Die EVU müssen aus diesem Grund fähig sein, auf

Anfrage des FOS die folgenden Daten zeitnah liefern zu können:

- Tagesformationen aller Züge für einen bestimmten Betriebstag

- Tagesformation eines einzelnen Zuges für einen bestimmten Betriebstag

- Vollständige Jahresformation der aktuellen oder der nächsten Fahrplanperiode

Die Bestellung dazu erfolgt manuell, z.B. via Telefon oder E-Mail. Die anschliessende Auslie-

ferung durch das EVU muss über die hier beschriebene Schnittstelle erfolgen.

Problemstellung Möglichkeiten für die Behebung

Teildatenausfall, Integritäts-probleme

Einspeisung von ausgewählten Tagen, vollständig (Tag x).

Einspeisung von ausgewählten Jahren, vollständig (Jahr y).

Einspeisung von einzelnen Zügen (Zug 3498 vom 1.1.18)

Katastrophenszenario, Vollständiger Datenverlust

Primär Einspeisung der aktuellen Tagesdaten (heute). Sekundär auch für weitere Tage bis zur Vollständigen Auffüllung des Zeitfens-ters. Analog und sekundär die Jahresdaten.

Gestörter Datenkanal Anderer Datenkanal (FTP Server) in Betrieb nehmen oder Daten über improvisierte Kanäle übertragen und einspeisen (als Übergangslö-sung)

Bei einer Nachlieferung werden nur die Records an die Abnehmer des Formationsservice

übertragen, die einen neueren Timestamp / Laufnummer und inhaltliche Änderungen gegen-

über den als die vorhandenen Daten haben.


3.6.7 Szenarien

Die folgenden Szenarien sind hinsichtlich Handshaking der Schnittstelle von Interesse (nicht

abschliessend, für umfassendere Szenarien vgl. Testfälle):

ID Was Übermittlung Schnittstelle

Bemerkungen

HS01 Normale Tagesdatenlieferung. Normal Das EVU liefert jede Nacht zwischen 2 und 3 Uhr morgens die vollständigen Tagesformati-onen für den Tag heu-te+20Tage

HS02 Update Tagesdaten nach Änderungen Normal Normales Verhalten, FOS macht keine Unterscheidung zwischen neuen und bestehen-den Daten (update, insert). Bestehende Daten werden durch die neuen Daten ersetzt.

HS03 Alle zwei Wochen liefert das EVU den gesamten, vollständigen und aktuel-len Jahresfahrplan der aktuellen Fahrplanversion, ab Oktober zusätz-lich denjenigen des Folgejahres.

Normal Normales Verhalten

HS04 Initial Load Jahresdaten: SBB bean-tragt bei EVU die Lieferung von Jah-resformationen für die aktuelle oder nächste Fahrplanperiode.

Normal EVU muss fähig sein, diesen auf Wunsch zu erstellen und über diese Schnittstelle bis maximal 24 Stunden ab Bestel-lung zu liefern. Analog zur normalen Jahresdatenlieferung.

HS05 Initial Load Tagesdaten: SBB bean-tragt bei EVU die Lieferung aller For-mationen zu einem Tag.

Normal EVU muss fähig sein, diesen bis maximal 2 Stunden ab Be-stellung innerhalb der Bürozei-ten zu erstellen und über diese Schnittstelle zu liefern.

HS06 EVU liefert Tagesformationsdaten ausserhalb Zeitfenster.

Normal Fehler. Daten werden nicht verarbeitet. Normales Fehler-handling tritt in Kraft.

HS07 Löschungen von kompletten Zügen (Ausfälle) müssen nicht an FOS übermittelt werden.

Nichts FOS kennt den Sollfahrplan, Löschungen von Trassen müs-sen durch EVU nicht an FOS übermittelt werden.

HS08 Alte Daten (z.B. Tagesformationen, welche mehr als 5 Tage in die Ver-gangenheit zurückreichen) löschen.

Nichts Wird durch FOS selbständig gemacht, keine Interaktion durch EVU notwendig.


3.7 Migration von KompoEVU nach FOS

Die Migration von KompoEVU nach FOS und alle damit einhergehenden Punkte und Aspek-

te für alle Umsysteme (Datenlieferanten und Datenabnehmer) werden in einem separaten

Dokument behandelt und ausgeführt [FOS-MIG]. Für alle Details sei auf dieses Dokument

verwiesen, nachfolgend nur die aktuell (September 2014) gültigen Eckdaten:

September 14: Draft EVU-FOS Inputschnittstelle (dieses Dokument)

Ende 14: Version 1.0 der Input- und Output-Schnittstellen

Juli 15: FOS Integrations- und Testumgebung für Lieferantensysteme bereit

September 15: FOS Produktionsumgebung für Lieferantensysteme bereit

Dezember 16: Alle datenliefernden EVU sind auf FOS migriert. Abnehmersysteme

können FOS-Daten in der Produktionsumgebung beziehen.

Juli 17: Alle Datenabnehmer sind auf FOS migriert, KompoEVU wird abgestellt


3.8 Zukünftige Änderungen am Schnittstellenkontrakt

Bei der vorliegenden Interface Spezifikation wurde neben der Rückwärtskompatibilität gros-

ser Wert darauf gelegt, mögliche zukünftige Anpassungen und Änderungen zu antizipieren

oder vorweg zu nehmen bzw. zu entschärfen.

Zukünftige Änderungen an der Schnittstelle sollen aber geordnet durchgeführt werden kön-

nen. Dazu dienen folgende Voraussetzungen:


MS-01 FOS Release und Migrationsfenster sind mit den Umsystemen rechtzeitig (d.h. > 6 Monate) abzustimmen.

M

MS-02 FOS bietet (genau) eine standardisierte Schnittstelle an – benötigen Schnittstel-lennutzer ggf. Varianten, implementieren sie diese (rechtzeitig) durch Adaptoren.

M

MS-03 Wird die EVU-FOS Schnittstelle durch eine neue Version ersetzt, müssen allen-falls auch die Abnehmersysteme upgra-den. FOS muss dies entsprechend koor-dinieren.

M

MS-04 FOS kennt folgende Arten der Schnittstel-lenanpassung bei Release-Wechseln:

keine Änderungen

Daten-Modell-Änderung

Parameter-Änderung

Protokoll-Änderung

Technologie-Änderung

Die Migrationsart wird gemeinsam mit den Liefersystemen zu Beginn der Release-Entwicklung festgelegt.

K

MS-05 XML Daten enthalten eine Versionsnum-mer. SBB Infrastruktur legt fest, welche Major-Versionen durch FOS zu einem bestimmten Zeitpunkt verarbeitet werden können und kommuniziert dies im Rah-men der Migrations- und Release-Planung.

M


3.9 Systemqualitäten

3.9.1 Pflichten EVU

Die rahmenorganisatorschen Aspekte der Schnittstelle zwischen EVU und ISB werden im

Betriebshandbuch ausführlich behandelt und sind nicht Bestandteil der technischen Spezifi-

kation.


L-01 Die EVU sind für die Qualität ihrer gelie-ferten Daten verantwortlich. Daten dürfen in Notfällen oder bei offensichtlichen Feh-lern aber durch den Infrastrukturbetreiber nach Absprache mit dem EVU korrigiert werden.

M

L-02 Tagesformationsänderungen an Zügen, die in den nächsten 90 Minuten am Fah-ren sind, müssen spätestens 5 Minuten nach der Änderung durch das EVU an den FOS geliefert werden. Davon ausgenom-men sind Änderungen, die während einer vollständigen Tageslieferung auftreten. In diesem Fall dürfen die Änderungen erst nach Abschluss der Tageslieferung über-mittelt werden.

M

L-03 Tagesformationsänderungen an Zügen, die nach 90 Minuten am Fahren sind, müssen spätesten 30 Minuten nach der Änderung durch das EVU an den FOS geliefert werden.

M

L-04 Kurze Nichtverfügbarkeiten von FOS müssen durch die EVU schadlos und oh-ne Datenverluste überwunden werden können.

M Z.B. indem das EVU Reconnects macht und sich aktiv um die Wieder-aufnahme des Normalbetriebes be-müht.


3.9.2 Verfügbarkeit FOS

Die Verfügbarkeitsaspekte von FOS aus Sicht der datenliefernden EVU beschränkt sich auf

die Verfügbarkeit der FTP Plattform der SBB:


VE-01 Die Verfügbarkeit von FOS aus Sicht der liefernden EVU ist identisch mit dem Ser-vice Level Agreement der FTP Plattform der SBB.

M Bei temporärer Nichtverfügbarkeit des FTP-Services ist das EVU verpflichten, die Lieferung zu einem späteren Zeit-punkt erneut zu starten.

3.9.3 Typische Grössenordnungen

Die folgenden Angaben zeigen die ungefähren Grössenordnungen, mit welchen FOS zurecht

kommen muss:

ID Beschrieb Wert

SQ-01 Maximale Grösse der angelieferten XML Dateien

2 GB. Grössere Datenmengen müssen in mehreren Dateien übermittelt werden.


4 Anhang: Codeausprägungen

Der FOS zeichnet die verschiedenen Verarbeitungsschritte in einem Logging-System auf.

Die Lieferanten des FOS erhalten Zugriff auf dieses Logging-System. Dadurch sind die Liefe-

ranten in der Lage, die Verarbeitungsschritte einzusehen. Bei Problemen in der Verarbeitung

der angelieferten Daten hilft eine lückenlose Aufzeichnung bei der Fehlersuche.

Die nachfolgende Tabelle listet die Verarbeitungsschritte auf, die vom FOS aufgezeichnet

werden. Die genauen Ausprägungen der Tags werden im Rahmen der Implementierung

festgelegt.

Begriff, Wert Beschreibung

FOS_<EVU>_READ_FILE_BEGIN_<FILENAME> Beginn Einlesen File

FOS_<EVU>_READ_FILE_ENDE_<FILENAME> Ende Einlesen File

FOS_<EVU>_BEGIN_PROCESSING_<ZUGIDENTIFIKATION> Beginn der Verarbeitung eines einzelnen Datensat-zes.

FOS_<EVU>_END_PROCESSING_<ZUGIDENTIFIKATION> Ende der Verarbeitung ei-nes einzelnen Datensatzes. Daten wurden gespeichert und an den Info-Hub PT verteilt.


5 Anhang: Fragen und Entscheide

Nr. Beschreibung Wer Status / Termin

1.


6 Anhang: Geschäftsdatenmodell

In diesem Teilkapitel sind für das Verständnis der Schnittstelle wichtige Konzepte der über-

tragenen geschäftlichen Informationen dargestellt. Die Darstellung erfolgt mithilfe von Ge-

schäftsdatenmodellen2, welche relevante Ausschnitte aus dem gesamten Datenmodell zei-

gen.

6.1 Fahrzeug

Die Formation eines Zuges besteht aus einer geordneten Menge von Formationselementen.

Sowohl die Formation als Ganzes wie auch jedes einzelne Formationselement haben eine

Laufrichtung3. Ein Formationselement repräsentiert ein Fahrzeug des Zuges.

Ein Fahrzeug ist entweder ein Einzelfahrzeug (z.B. ein EW IV) oder ein Gliederfahrzeug (z.B.

ein Flirt), das aus Teilfahrzeugen besteht. Gliederfahrzeuge werden betrieblich nicht aufge-

trennt, aber für die Kundeninformation unterschieden. Ihre Teilfahrzeuge haben möglicher-

weise keine betriebliche Identifikation4.

Wenn ein EVU aus der Jahresplanung die Formation über FOS an den ISB liefert, kennt es

das konkrete Fahrzeug noch nicht, aber den Fahrzeugtyp. Das konkrete Fahrzeug wird erst

wenige Tage vor dem Verkehrstag festgelegt und dann über FOS geliefert.

Einem Fahrzeugtyp wird vom ISB ein Fahrtyp zugeordnet. Dieser beschreibt die fahrdynami-

schen Eigenschaften einer Klasse und wird durch den ISB für die Zuglaufrechnung verwen-

det. Das EVU liefert mit dem Fahrzeugtyp eine Referenz auf den zugehörenden Fahrtyp.

Der ISB ordnet Fahrtypen in Fahrtypgruppen ein. Diese sind für das EVU nicht von Bedeu-

tung.

2 Geschäftsdatenmodelle werden auch als „Konzeptionelle Datenmodelle“ oder „Business Object Models“

bezeichnet. 3 Formation: „Formationselement 1 in Laufrichtung vorne“, Formationselement: „Führerstand 1 in Laufrich-

tung vorne“ 4 Sie haben eventuell keine European Vehicle Number (EVN), aber eine Seriennummer z.B. für die Instand-

haltung.


Abbildung 4: Geschäftsdatenmodell "Formation"

6.2 Trasse

Ein EVU bestellt nach einem durch trasse.ch vorgegebenen Bestellverfahren5 beim ISB eine

Trasse für seinen Zug. Über FPS wird dem EVU die Trasse zurückgeliefert. Eine Trasse

kann mehrere unterschiedliche Trassenläufe besitzen. Die Verkehrsperioden der einzelnen

Trassenläufe ergänzen sich zur Verkehrsperiode der gesamten Trasse.

Damit ein Zug verkehren kann, braucht er eine Trasse. Bei einer sehr kurzfristigen Bestel-

lung kann jedoch der Fall auftreten, dass das EVU die Trasse noch nicht elektronisch erhal-

ten hat und damit die Trassen-ID noch nicht kennt. Es liefert deshalb den Zug und die For-

mation zuerst ohne zugehörige Trasse und – sobald die Trassen-ID bekannt, den Zug mit

der Referenz auf seine Trasse.

Ein Zug kann mehrere Teiltrassen haben. Über FOS muss das EVU den Zug zu jeder Teil-

trasse einzeln liefern. Die Multiplizität Zug – Trasse ist also 1:1.

5 Die Bestellung erfolgt z.B. für BV1 – 4a über NeTS AVIS.

class Formation

Fahrzeug

+ FahrzeugID :ID

EinzelfahrzeugGliederfahrzeug

Teilfahrzeug

Formation

FormationsElement

+ position :Integer

Fahrtyp

FahrtypGruppe

FahrzeugTyp

Basisdaten (Länge, Gewicht, ...)

Komfortdaten (1./2. Klasse,

Niederflureinstieg, ...)

0..* 1

1

1..* 1

2..*

{ordered}

1..*

{ordered}

0 .. 1


Abbildung 5: Geschäftsdatenmodell "Trasse"

6.3 Zug…

Ein Zug weist einen oder mehrere Zugläufe auf. Die einzelnen Zugläufe haben Verkehrsperi-

oden, welche sich zur Verkehrsperiode des Zuges ergänzen.

Die Verkehrsperiode des gesamten Zuges muss derjenigen der zugehörenden Trasse ent-

sprechen. Die Verkehrsperioden der einzelnen Zugläufe entsprechen aber nicht zwingend

denjenigen der einzelnen Trassenläufe, da das EVU die Verkehrstage des Zuges möglich-

erweise anders gruppiert als der ISB dies für die Trasse durchführt.

Ein Zuglauf wird als geordnete Liste von Zuglaufpunkten dargestellt. Die Zuglaufabschnitte

ergeben sich daraus implizit, indem auf einem Zuglaufpunkt die Distanz zum nächsten Zug-

laufpunkt (Länge) angegeben wird. Für den Endpunkt ist die Länge gleich 0. Ein Zuglaufab-

schnitt führt über 1 oder mehrere Betriebspunktverbindungen.

Als Zuglaufpunkte sind nur Betriebspunkte zulässig, welche im Trassenlauf enthalten sind.

Das EVU muss nur diejenigen Zuglaufpunkte angeben, welche für es von Bedeutung sind.

Neben dem Zuglauf, welche dem Trassenlauf entspricht, kann das EVU den Zuglauf am An-

fang und/oder am Ende mit zusätzlichen Zuglaufpunkten erweitern („Verlängerung“). Damit

kann der Ausgangs- oder der Zielbahnhof für die Kundeninformation angegeben werden

(z.B. Berlin HBf bei einem Trassenlauf Interlaken Ost - Basel SBB).

Abbildung 6: Zuglauf-Verlängerung

Diese Angaben sind für Betriebsführung und Trassenverrechnung nicht relevant.

class Trasse

Trasse

+ trassenID :ID

Trassenlauf

Trassenlaufpunkt

Verkehrsperiode

Betriebspunkt

Zug

+ zugID :ID

1..*

{disjunkt}

1

1

1..*

1

1

2 .. *

{ordered}

0..* 1

1 0..*

Trassenlauf

Zuglauf Verlängerung

Interlaken Ost Basel SBB

Berlin HBf


Eine Formationsfahrt ist derjenige Teil eines Zuglaufes, bei dem die Formation des Zuges

unverändert bleibt, also kein Flügeln und keine Stärkung / Schwächung durchgeführt wird.

Für einen bestimmten Zuglauf und eine Formationsfahrt kann ein EVU an verschiedenen

Verkehrstagen unterschiedliche Formationen einplanen, also den Formationen ebenfalls eine

Verkehrsperiode zuordnen. Diese muss eine Teilmenge der Verkehrsperiode des Zuges

(und damit der Trasse) sein.

Abbildung 7: Geschäftsdatenmodell "Zug"

Die Fahrzeuge werden - beginnend beim ersten Fahrzeug in Laufrichtung - aufsteigend

nummeriert. Ihre Nummer wird als Position in der Formation bezeichnet. Die Formation än-

dert, wenn die Laufrichtung der Fahrzeuge wechselt.

class Zug

Trasse

+ trassenID :ID

Zug

+ zugID :ID

Zuglauf

Betriebspunkt

Verkehrsperiode

ZuglaufPunkt

+ Haltecode

Formationsfahrt

Formation

Trassenlaufpunkt

Trassenlauf

Verkehrsperiode

FormationsElement

+ position :Integer

1 1

0..*

1

2 .. *

{ordered}

Trassenlauf

1..*

{disjunkt}

von / bis2

1

1

1 0..*

0..*

1

1..*

{disjunkt}

1

2 .. *

{ordered}

1..*

1

Verlängerung

0..*

1..*

{disjunkt}

1

1

1..*

{ordered}

1

1..*

{ordered}


Beispiel einer Formation

Eine Formation bestehend aus zwei dreiteiligen Gliederfahrzeugen wird durch Aufzählung

der beiden Gliederfahrzeuge in der Fahrtrichtung, sowie ihrer 3 Teilfahrzeugen in der aktuel-

len Fahrtrichtung beschrieben.

Abbildung 8: Formation mit 2 dreiteiligen Gliederfahrzeugen

Wenn die Formation in Richtung Teilfahrzeug a fährt, wird sie wie folgt angegeben:

- Position 1: Teilfahrzeug a (mit 1.Klassabteil)

- Position 2: Teilfahrzeug b

- Position 3: Teilfahrzeug c

- Position 4: Teilfahrzeug d

- Position 5: Teilfahrzeug e

- Position 6: Teilfahrzeug f (mit 1.Klassabteil)

Wenn die Formation in Richtung Teilfahrzeug f fährt, wird sie wie folgt angegeben:

- Position 1: Teilfahrzeug f (mit 1.Klassabteil)

- Position 2: Teilfahrzeug e

- Position 3: Teilfahrzeug d

- Position 4: Teilfahrzeug c

- Position 5: Teilfahrzeug b

- Position 6: Teilfahrzeug a (mit 1.Klassabteil)

a cb d e f

Fahrzeug 1 Fahrzeug 2


Beispiele asymmetrischer Fahrzeuge

Die Laufrichtung der Fahrzeuge muss beachtet werden, damit die asymmetrisch angeordne-

ten 1.Klass-Abteile am Perron richtig angezeigt werden.

Abbildung 9: RABe 525 „NINA“ dreiteilig der BLS

6

Abbildung 10: RABe 523 „FLIRT“ vierteilig der SBB

7

Abbildung 11: RABe 526 „FLIRT“ vierteilig der SOB

8

6 http://www.schueck.ch/pura/assets/images/bls-nina-trebzug-rabe-482219.jpg

http://mw2.google.com/mw-panoramio/photos/medium/7015024.jpg 7

http://bahnpics.com/nil/09.08.07%20SZU%20SOB/DSC_2564k%20copy.jpg 8 http://www.stadlerrail.com/media/tmp/uploads/stadler/flirt/Schweizerische_Suedostbahn_AG_SOB_Schweiz_JPG_960x350_crop_q95.jpg

Documents

InfoHubPT Schnittstellenspezifikation EVU Formationsdaten · PDF fileSchnittstelle zu Info-Hub PT werden die aktuellen Schnittstellenspezifikationen von SBB zur Verfü- ... Layer 2