iRFP
Startseite iRFP FBS Aktuelles Service Intern
FBS
iPLAN
iFRANK
iLOK
Zusatzprogramme
Schnittstellen
  RailML®
  Technische Hinweise
  Trassenportal DB Netz
  Zugdaten Text
Betrachter
Systemanforderungen
Lieferumfang
Bestellung
Referenzen

FBS-railML-Schnittstelle: Hinweise für Entwickler

 

Umfang der FBS-railML-Schnittstelle
Die FBS-railML-Schnittstelle ermöglicht momentan

  • einen Export von ausgewählten Infrastruktur- sowie nahezu allen Fahrplandaten aus FBS in das railML-Format (momentan: railML 2.0, 2.1 und 2.2)
  • sowie einen Import von Fahrplandaten aus dem railML-Format (momentan: railML 2.0; Unterstützung von railML 2.2 ab 2015)

in strukturierter, systematischer Form zur technischen Auswertung und Nutzung in Drittprogrammen. Fahrzeugdaten aus FBS sind in den exportierten railML-Dateien in dem (grundlegenden) Umfang enthalten, der zum Auswerten der oben genannten Fahrplandaten erforderlich ist. Es werden nicht alle technischen Daten exportiert, da der Hauptzweck der momentanen FBS-railML-Schnittstelle im Export der in FBS erstellten Fahrplandaten gesehen wird. Zum Bearbeiten von railML-Fahrzeugdaten und zum Eingeben von Fahrzeugdaten für FBS steht Ihnen ein spezielles Fahrzeugdatenprogramm des iRFP zur Verfügung.

Hintergrundinformationen zur Implementierung
Bitte beachten Sie, dass eine Nutzung des railML-Standards nicht automatisch bedeutet, dass zwei Programme mit Sicherheit fehlerfrei Daten austauschen können. Das liegt einerseits daran, dass der railML-Standard zwar die allgemeine Struktur von Infrastruktur- und Fahrzeugdaten definiert - jedoch sind zum einen der Umfang der Daten (die Vollständigkeit) und zum anderen die Details einiger spezieller Daten allein durch railML nicht zweifelsfrei definiert. Aus diesem Grunde gibt es eine spezielle Schnittstellenbeschreibung für die FBS-Implementierung des railML-Formats. Hierin werden die konkret von FBS verwendeten Datenfelder und deren Inhalt beschrieben. Die gegenwärtige Version der FBS-railML-2.0-Schnittstelle basiert auf einer speziellen Adaption der allgemeinen railML-Formatbeschreibung. Diese FBS-railML-2.0-Schemendateien (XSD/ZIP; 48 kByte) basieren auf den allgemeinen railML-2.0-Schemendateien (XSD/ZIP; 940 kByte).

Weitere Hinweise zur Verwendbarkeit siehe weiter unten.

An Entwickler von RailML-Import-Schnittstellen, die (auch) RailML-Dateien aus FBS einlesen können sollen: Voreinstellung von Export-Optionen
Üblicher Weise bestehen je nach Anwendungsfall individuelle Anforderungen an Inhalte von RailML-Dateien. Diese können i. d. R. beim Export vom Anwender eingestellt werden. Wegen der vielfältigen Optionen besteht die Möglichkeit, für bestimmte Anwendungsfälle (Programm-Paarungen wie z. B. "Export aus FBS zur Fahrgastinformation mit …") konkrete Voreinstellungen fest zu hinterlegen, so dass inhaltliche Abhängigkeiten festgesetzt sind oder durch FBS bereits beim Export geprüft werden. Wenn Sie eine Import-Schnittstelle entwickeln, bitten wir Sie, mit uns Kontakt aufzunehmen zur Abstimmung der notwendigen Inhalte und eventuellen Voreinstellung der Optionen in FBS.

Profil-Versionen der FBS-railML-Schnittstelle
Seit Mai 2012 kann außer dem Format railML 2.0 testweise auch das Format railML 2.1 aus FBS ausgegeben werden. Die Kompatibilität des FBS-Profils der Schemendateien zu den allgemeinen RailML-Schemen ist bei Version 2.1 etwas höher, dies ist jedoch mit inhaltlichen Einschränkungen gegenüber Version 2.0 verbunden (betrifft insbesondere Betriebsstellen-Nummern und eindeutige Bezeichnung von Strecken). Insgesamt empfehlen wir daher nicht die Verwendung von Version 2.1. Inbesondere ist die FBS-railML-2.1-Schnittstelle nicht für den Produktiveinsatz vorgesehen und kommerziell lizenziert.
Seit April 2012 befand sich die railML-Version 2.2 in einer Vorab-Implementierungsphase bei iRFP. Mit railML 2.2 wurden die noch bestehenden Beschränkungen aufgehoben werden, so dass wir hierin einen vollwertigen und vollständig kompatiblen Nachfolger von railML 2.0 sehen. Erste Test-Exporte von FBS-railML-2.2-Daten waren seit Mai 2012 möglich. Die Implementierung ist nunmehr abgeschlossen; seit Anfang 2015 auch die Verifizierung durch das railML-Konsortium. Damit ist railML 2.2 nunmehr seitens iRFP veröffentlicht.

Übersicht über die unterstützten Versionen
Folgende Versionen können derzeit aus FBS exportiert werden:

Version

Profil

Kompa­tibi­litäts­nummer

Bemerkungen

Revision

<railml>.

version

<metadata>.

format

<metadata>.

identifier

 

 

2.0

2.0.0

4

nur sehr eingeschränkt verwendbar (s. u.)

270

2.0

2.0.5

1

iRFP-eigene Anpassungen

(270)

2.1

2.1.0

4

unveränderte Original-Schemen

409

2.2

2.2.0

4

unveränderte Original-Schemen

602

2.2r611

4

unveränderte Original-Schemen

611

Hinweis: Version 2.2r611 ist bisher vorläufig und noch nicht offiziell veröffentlicht. Inhalte können sich bis zur endgültigen Veröffentlichung ohne Kompatibilität ändern.


Versions-Verlauf der Kompatibilitätsnummer (<metadata>.identifier):

<metadata>. identifier

seit

fortgeschrieben wegen

2

23.05.2012

Wechsel der Einheit von <ocpTT>.<sectionTT>.distance von km auf m

3

06.05.2015

Orientierungswechsel auf dir='down' bei km-abwärtigen <speedChange>s

4

15.09.2015

Reihenfolgetausch von Längen- und Breitengrad in Koordinaten

Sollten Sie als Anwender Kompatibilitätsprobleme durch den Reihenfolgetausch der Koordinaten haben, bitten wir um Kontaktaufnahme mit dem iRFP-Büro Dresden.


Übersicht über die verwendeten Schemen und Namensräume:

Version

/ Profil

URI des Namensraums (xmlns)

URL des Schemas (xsi:schemaLocation)

Bemerkungen

alle

http://www.w3.org/2001/XMLSchema-instance (xmlns:xsi)

http://purl.org/dc/elements/1.1/ (xmlns:dc)

 

http://schema.fbsbahn.de/2.x/fbs_railml_extension (xmlns:fbs)

http://schema.fbsbahn.de/2.x/fbs_railml_extension.xsd

iRFP-eigene

Erweiterungen

2.0.0

http://www.railml.org/schemas/2009

http://www.railml.org/schemas/2009/railML-2.0/railML.xsd

 

2.0.5

http://schema.fbsbahn.de/2.0.5

http://schema.fbsbahn.de/2.0.5/fbs-railML.xsd

iRFP-eigene

Anpassungen

2.1.0

http://www.railml.org/schemas/2011

http://www.railml.org/schemas/2011/railML-2.1/railML.xsd

 

2.2.0

http://www.railml.org/schemas/2013

http://www.railml.org/schemas/2013/railML-2.2/railML.xsd

 

Darüber hinaus kann der Anwender beim Export eigene Schemen-Erweiterungen für benutzerdefinierte Felder aus FBS hinzufügen.


Hinweise zu Verwendbarkeit und Einschränkungen der RailML-Versionen

Version

Hinweise

2.0.0

-   keine Geschwindigkeitsprofile

-   Fahrwege der Züge nicht eindeutig nachvollziehbar, daher:

-   kein Re-Import der Daten aus Version 2.0.0 nach FBS möglich

-   Die Last von Zügen (mit Wagen) wird nicht explizit exportiert (Attribut <formationTT>.load fehlt). Sie wird jedoch indirekt über <formationTT>.weight exportiert, wo die Gesamtmasse eines Zugteils steht.

-   Bedarfszüge können nicht als solche gekennzeichnet werden, da das Attribut <operatingDay>.onRequest fehlt.

-   In RailML 2.0 wurde noch nicht zwischen Schnell- und Betriebsbremshundertsteln unterschieden. Es werden daher nur die Betriebsbremshundertstel exportiert. Da beide aber i. d. R. unterschiedlich sind, gehen hier wichtige Informationen verloren.

-   Es können Zugteile, die trotz vorhandener Sitzplätze nicht zur Fahrgastbeförderung freigeben sind (leerüberführte Wagen einschl. Triebwagen - DLt am Vollzug) nicht als solche gekennzeichnet werden, weil das Attribut <passenger­Usage>.places zwingend >0 sein muss. (<passengerUsage> wird daher bei abgesperrten Wagen weggelassen.)

-   Die verkehrliche Linienbezeichnung von Zugteilen wird nicht ausgegeben.

-   keine Wagenreihungsnummern

-   keine Umlaufpläne

2.0.5

-   von iRFP angepasste Schemendateien, um die Nachteile der Version 2.0.0 zu vermeiden

[2.0.5]

alle Versionen außer V2.0.5:

Es fehlt das erste <mileageChange>-Element am Anfang eines Streckengleises in der <mileageChanges>-Struktur. Es ist damit nicht möglich, die Kilometrierung einer Strecke im Zusammenhang zu erfassen. Die initiale absolute Position eines Gleises ist jedoch aus dem Element <trackBegin> ersichtlich.

2.1.0

-   <ocp>.number wird für IBNR verwendet entgegen der Deklaration als "deprecated", da ansonsten keine Betriebsstellennummern exportierbar wären

-   keine Fahrzeugindizes und Gruppennummern in Umlaufplänen

2.2.0

-   keine der o. g. Einschränkungen außer initialer <mileageChange>

alle, optional

mit iRFP-eigenen Erweiterungen: Die Erweiterungen ermöglichen

-   den Export benutzerdefinierter Felder aus FBS (z. B. mit Verwaltungsinformationen wie Besteller, Aufgabenträger, Vertragsnummer, durchführendes EVU) in flexiblerer Art als mit Standard-RailML-Feldern und auch an Stellen, an denen entsprechende Standard-RailML-Felder fehlen,

-   ein Wiedergeben "gefalteter" Umlaufplan-Darstellungen, d. h. mehrere "innere" Wochentage auf einem Blatt zusammengefasst.


Änderungsübersicht

Rot kennzeichnet entfallene Elemente oder Attribute, blau kennzeichnet neu hinzugekommene, wobei betreffende Elemente/Attribute i. d. R. optional sind. Es handelt sich nur um eine Grobübersicht; Details entnehmen Sie bitte der Schnittstellenbeschreibung. Alle Änderungsangaben beziehen sich auf die jeweils vorhergehende Version.

ab Profil-

Version

Änderung

2.0.0

nachträglich für RailML 2.0 gemäß unveränderten Original-Schemen

2.0.1

erste veröffentlichte Basis-Version

2.0.2

keine Änderungen in der Ausgabe ggü. V2.0.1

2.0.3

<trainPart>.remarks hinzugekommen

Bei Wechsel der Bemerkungen (Attribut remarks) innerhalb des Laufwegs eines Zugteils wird dieser in zwei Zugteile aufgeteilt.

2.0.5

<train>.additionalTrainNumber hinzugekommen

2.1.0

<trackGroup>.<line>.uicNumber --> code (zusammengefasst)

<trackGroup>.<line>.lineNumber --> code (zusammengefasst)

<ocp>.abbreviation --> code (umbenannt)

<ocp>.number wird für IBNR verwendet entgegen der Deklaration als "deprecated", da ansonsten keine Betriebsstellennummern exportierbar wären

<category>.abbreviation --> code (umbenannt)

<ocpTT>.<sectionTT>.trackRef zu <ocpTT>.<sectionTT>.<trackRef>.ref verschoben

<ocpTT>.<sectionTT>.<trackRef>.dir hinzugekommen

<ocpTT>.<sectionTT>.distance Einheit von km auf m geändert (verbunden mit der Erhöhung von <metadata>.identifier von 1 auf 2)

<train>.<trainPartSequence>.categoryRef (neu) - zur Unterscheidung Produkt (verkehrlich = <trainPart>.categoryRef) und Gattung (betrieblich = <trainPartSequence>.categoryRef)

<circulation>.vehicleIdx entfallen (ersatzlos, s. jedoch 2.2.0)

<circulation>.groupIdx entfallen (ersatzlos, s. jedoch 2.2.0)

2.2.0

<metadata>.<dc:language> umgestellt von Codepage auf BCP47-script

<metadata>.<organizationalUnits> (neu)

<line>.code (Inhalt geändert)

<line>.infrastructureManagerRef (neu)

<mileageChange>.dir --> absDir (umbenannt)

<speedChange>.profileRef (neu)

<speedChange>.status (entfallen)

<speedChange>.trainRelation, mandatoryStop, signalised (neu)

<ownerChanges>.ownerName (entfallen)

<ownerChanges>. infrastructureManagerRef (neu)

<ocp>.code (entfallen) --> <ocp>.<designator> (neu)

<ocp>.number (entfallen) --> <ocp>.<designator>.register=’IBNR’... (neu)

<ocp>.<propOther>.<additionalName> --> <ocp>.<additionalName>... (verschoben)

<ocp>.<propOther>.zip (neu optional)

<ocp>.<geoCoord>.coord --> Höhenangabe umgezogen zu extraHeight

<ocp>.<geoCoord> <gradientChange>.<geoCoord>: Koordinaten und Höhen werden nur noch mit Angabe eines EPSG-Codes exportiert (EPSG-Code ist Pflichtfeld geworden)

<train>.trainNumber (neu bei type='commercial')

<trainPart>.<formationTT>.orientationReversed (neu)

<trainPart>.<formationTT>.load --> timetableLoad (umbenannt)

<trainPart>.<ocpsTT>.<ocpTT>.sequence (neu)

<trainPart>.<ocpsTT>.<ocpTT>.ocpType: Entfall der Werte begin und end

<trainPart>.<ocpsTT>.<ocpTT>.<stopDescription>.operationalStopOrdered (neu)

<trainPart>.<organizationalUnitBinding> <-> benutzerdefinierte Felder aus FBS

<circulation>.vehicleCounter (wiedereingeführt als Nachfolge von vehicleIdx)

<circulation>.vehicleGroupCounter (wiedereingeführt als Nachfolge von groupIdx)

allgemein 12/2014

alle Versionen außer 2.0.5:

kein initiales <mileageChange>-Element am Anfang eines Gleises

allgemein 05/2015

alle Versionen:

<metadata>.<dc:source> erweitert auf Quelldateinamen aus FBS; auch unter <infrastructure> und <rollingstock> (nicht nur unter <railML>)

<geoCoord>.coord: Höhenangabe vom dritten Wert in coord umgezogen zu extraHeight

<geoCoord>.epsgCode/heightEpsgCode hinzugefügt (optional bis V2.1, obligatorisch ab V2.2)

<speedChange>s werden fahrtrichtungsbezogen exportiert (dir='down', <metadata>.identifier=3)

<speedProfile>.influence bei Grundprofilen immer ='decreasing'

<train>.scope='secondary' als möglicher Wert entfallen (bei type='operational')

<train>.type='commercial': in zwei Modi möglich - optional mit 1:1-Zugteil-Zuordnung

<trainPart>.remarks, debitcode, operator <-> benutzerdefinierte Felder aus FBS

<trainPart>.<ocpsTT>.<ocpTT>.<times>: Genauigkeit der Zeitangaben wählbar

<trainPart>.<ocpsTT>.<ocpTT>.<times>.scope='published' (neuer Wert möglich)

<circulation>.fbs:blatt, fbs:zeile (neu)

allgemein 09/2015

alle Versionen außer 2.0.5:

Reihenfolgetausch von Längen- und Breitengrad bei Koordinaten nach Festlegung der Reihenfolge durch das railML-Konsortium. Um dies für externe Programme erkennbar zu machen, wurde <metadata>.identifier auf =4 erhöht.

Bitte kontaktieren Sie iRFP, wenn Sie als Anwender Kompatibilitätsprobleme durch diese nachträgliche Änderung haben (Koordinaten werden falsch herum eingelesen).


Weitere Dokumente
Nachfolgende Dateien unterstützen Sie bei der Implementierung:

Bitte nutzen Sie für allgemeine Anfragen zu railML die Foren und das Wiki des railML-Konsortiums. Für spezielle Anfragen in Bezug auf den Austausch von railML-Daten mit FBS nehmen Sie bitte Kontakt mit unserem Büro Dresden auf.

 



 Startseite | iRFP | FBS | Aktuelles | Service | Intern
 Impressum/Copyright | Disclaimer | Kontakt | Stand: 11.02.2016