---
domain: "pathos"
tool: "pathos"
scope: "intern"
tags: ["domain:pathos", "tool:pathos", "scope:intern", "pathos", "anhang"]
owners: ["einfachbahn@deutschebahn.com"]
contact: "einfachbahn@deutschebahn.com"
component_type: "pdf"
source: "confluence"
source_version: ""
meta_fingerprint: "6e059c8d8e5c1a8a"
url: "https://arija-confluence.jaas.service.deutschebahn.com/download/attachments/355496791/Anl1_Datenfelder_EVU-Schnittstelle_Bestellsystem_V4.6.2.pdf"
kind: "attachment"
parent_url: "https://arija-confluence.jaas.service.deutschebahn.com/spaces/BES/pages/355496791/FAQ+pathOS+prim%C3%A4r+f%C3%BCr+intern+gedacht"
attachment_name: "Anl1_Datenfelder_EVU-Schnittstelle_Bestellsystem_V4.6.2.pdf"
last_updated: "unknown"
review_status: "approved"
review_notes: "redigiert: (?**Bearbeiter**|**Art der Bearbeitung**|**Datum**|
|---|---|---|---|
|4.0.0||Initialfassung|16.03.2015|
|4.1.0||Überarbeitungauf Basis xsd Version 2.2.3 und Änderungen im Sector-Handbuch TAF/TAP-TSI der RNE|23.07.2019|
|4.1.1||Überarbeitungauf Basis xsd Version 2.2.4 und Änderungen im Sector-Handbuch TAF/TAP-TSI der RNE.|25.02.2020|
|4.2.0||Einarbeitungder Änderungen in den xsd-Versionen [REDACTED] und 2.5.0.0.|26.02.2021|
|4.3.0||Einarbeitung der Änderungen in der xsd-Version [REDACTED] der RNE sowie aller Änderungen im Zusammenhang mit der Neumodellierungdes Train-Objekts.|16.08.2021|
|4.4.0||Einarbeitung der Änderungen in der xsd-Version [REDACTED] der RNE. Einarbeitung der Regelungen und Ergänzung zur Bestellung und Zuweisung des Marktproduktes „Rahmenver- tragskapazität“ für Rahmenverträge.|28.02.2022|
|4.4.1||Einarbeitung der Änderungen in der xsd-Version [REDACTED] der RNE.|22.08.2022|
|4.4.2||Einarbeitung der Änderungen aus der xsd-Version [REDACTED] der RNE|10.05.2023|
|4.5.0||Einarbeitung der Änderungen aus der xsd-Version [REDACTED] der RNE •|17.07.2024|
|4.6.0||Fachliche und redaktionelle Anpassungen|17.04.2025|
|4.6.1||Fachliche und redaktionelle Anpassungen •|14.07.2025|
|4.6.2|DB InfraGO AG Fabian Sommer|Fachliche Anpassungen • Aufnahme TemporaryCapacityRestrictionID und ObjectType • Anpassung MessageRoutingID für ujBau Prozess • Änderung Verwendung Attribut ResponsibleIM • Änderung Verwendung BrakingRatio • Änderung Verwendung achTractionMode • Änderung Verwendung JourneyLocationTypeCode „05“ Interchange • Änderung Verwendung TrainActivityCode „0004“ („Systemwechselhalt“) und DE02 („konstruktionsbe- dingter Richtungswechsel“) • Redaktionelle Anpassungen • Anpassung Vorgaben für ExceptionalGaugingCode • Schärfung der Verwendungshinweise bei BrakeType und azchBrakeType • Schärfung Verwendung ReasonofReferenceCode 1009 • Ergänzung Ausprägung „BaubedingteZusatzleistung“ bei „VerkehrsartKundeZusatz • Ergänzung Defaultwert bei OffsettoReference • SchärfungVerwendungTrainActivityCode DE13|11.09.2025|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 2
DB Intern / DB internal
### **Inhaltsverzeichnis**
|**Änderungshistorie**|**2**|
|---|---|
|**Inhaltsverzeichnis**|**3**|
|**Tabellenverzeichnis**|**6**|
|**Abbildungsverzeichnis**|**8**|
|**1 Hinweise zu diesem Dokument**|**9**|
|1.1 Dokumentenaufbau|9|
|1.2 Bezug zu anderen Dokumenten|9|
|**2 Nachrichten**|**10**|
|2.1 Geschäftsvorfälle und Basisprozesse|11|
|2.1.1 Basisprozesse|11|
|2.1.2 Kanalzwang|11|
|2.1.3 Geschäftsvorfälle und zu verwendende TAF-TSI/TAP-TSI Nachrichtentypen|11|
|2.2 Hauptstrukturen der Nachrichten|18|
|2.2.1 PathRequestMessage|18|
|2.2.2 PathDetailsMessage|22|
|2.2.3 PathDetailsRefusedMessage|24|
|2.2.4 PathConfirmedMessage|26|
|2.2.5 PathCanceledMessage|28|
|2.2.6 PathNotAvailableMessage|30|
|2.2.7 ReceiptConfirmationMessage|32|
|2.2.8 ErrorMessage|35|
|2.2.9 ObjectInfoMessage|36|
|2.2.10 UpdateLinkMessage|40|
|**3 Datenfeldbeschreibungen**|**42**|
|3.1 Spalten der Datenfelder-Tabellen|43|
|3.2 Struktur „MessageHeader“|44|
|3.2.1 Übersicht über die Struktur „MessageHeader“|44|
|3.2.2 Datenfelder der Struktur „MessageHeader“|45|
|3.3 Struktur „AdministrativeContactInformation“|46|
|3.3.1 Übersicht über die Struktur „AdministrativeContactInformation“|46|
|3.3.2 Datenfelder der Struktur „AdministrativeContactInformation“|46|
|3.4 Struktur „Identifiers“|47|
|3.4.1 Übersicht über die Struktur „Identifiers“|47|
|3.4.2 Datenfelder der Struktur „Identifiers“|50|
|3.5 Attribute und Strukturen auf Messageebene|51|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 3
DB Intern / DB internal
|3.6 Oberstruktur TrainInformation|53|
|---|---|
|3.6.1 Übersicht über die Oberstruktur „TrainInformation“|53|
|3.6.2 Strukturen der Oberstruktur „TrainInformation“|53|
|3.7 Oberstruktur PathInformation|54|
|3.7.1 Übersicht über die Oberstruktur „PathInformation“|54|
|3.7.2 Strukturen der Oberstruktur „PathInformation“|54|
|3.8 Struktur „PlannedJourneyLocation“|55|
|3.8.1 Übersicht über die Struktur „PlannedJourneyLocation“ und deren Unterstrukturen|56|
|3.8.2 Datenfelder der Struktur „PlannedJourneyLocation“ und deren Unterstrukturen|61|
|3.9 Struktur „PlannedCalendar“|74|
|3.9.1 Übersicht über die Struktur „PlannedCalendar“|74|
|3.9.2 Struktur „ReferenceTrainIDSubCalendar“ und Attribut „OffsetToReference“:|75|
|3.9.3 Datenfelder der Struktur „PlannedCalendar“|75|
|3.9.4 Datenfelder der Struktur „ReferenceTrainIDSubCalendar“|77|
|3.10 Struktur „RequestedCalendar“|78|
|3.10.1 Übersicht über die Struktur „RequestedCalendar“|78|
|3.10.2 Datenfelder der Struktur „RequestedCalendar“|79|
|3.11 PathPlanningReferenceLocation|80|
|3.12 AffectedSection|81|
|3.12.1 Übersicht über die Struktur „AffectedSection“|81|
|3.12.2 Datenfelder der Struktur „AffectedSection“|83|
|3.13 InterruptionInformation|85|
|3.13.1 Übersicht über die Unterstruktur „InterruptionInformation“|85|
|3.13.2 Datenfelder der Unterstruktur „InterruptionInformation“|85|
|3.14 NetworkSpecificParameter|86|
|3.14.1 Übersicht über die Struktur „NetworkSpecificParameter“|86|
|3.14.2 Datenfelder der Struktur „NetworkSpecificParameter“|86|
|3.14.3 Vorgehensweise bei der Nutzung nationaler Parameter|86|
|3.14.4 Befüllung der Struktur|87|
|3.14.5 Attribute der Struktur „NetworkSpecificParameter“ auf Message-Ebene|88|
|3.14.6 Attribute der Struktur „NetworkSpecificParameter“ auf Location-Ebene|90|
|3.14.7 Attribute der Struktur „NetworkSpecificParameter“ in der Struktur „AffectedSection“|96|
|3.15 CaseReference-Objekte|97|
|3.15.1 CaseReference-Objekt „Taktverbund“|98|
|3.15.2 CaseReference-Objekt „Abstellung“|99|
|3.15.3 CaseReference-Objekt „Rahmenvertrag“|99|
|3.15.4 CaseReference-Objekt „Baubetroffenheit“ (Umsetzung pausiert, siehe Anlage 10)|100|
|3.15.5 CaseReferemce-Objekt „ETCS-Zugdaten“|100|
|3.16 Codelisten|102|
|3.16.1 TAF-TSI/TAP-TSI-Codelisten|102|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 4
DB Intern / DB internal
|3.16.2 Codeliste TrainActivity|115|
|---|---|
|**4 Bereitstellung der Ordnungsrahmenstände und Stammdaten**|**118**|
|4.1 Ordnungsrahmenstände|119|
|4.2 Stammdaten|119|
|4.2.1 Grundstruktur der Stammdaten|119|
|4.2.2 StammdatenHeader|120|
|4.3 Datenfelder der Stammdaten|121|
|4.3.1 Betriebsstellen|121|
|4.3.2 Strecken|123|
|4.3.3 Triebfahrzeuge|125|
|4.3.4 Zuggattungen|126|
|4.3.5 Streckenklassen|127|
|4.3.6 VerkehrsartKundeZusaetz|127|
|4.3.7 Flexibilitaeten|128|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 5
DB Intern / DB internal
### **Tabellenverzeichnis**
Tabelle 1: Geschäftsvorfälle und TAF-TSI/TAP-TSI Nachrichtentypen 17 Tabelle 2: PathRequestMessage Hauptstruktur Beschreibung 21 Tabelle 3: PathDetailsMessage Hauptstruktur Beschreibung 23 Tabelle 4: PathDetailsRefusedMessage Hauptstruktur Beschreibung 25 Tabelle 5: PathConfirmedMessage Hauptstruktur Beschreibung 27 Tabelle 6: PathCanceledMessage Hauptstruktur Beschreibung 29 Tabelle 7: PathNotAvailableMessage Hauptstruktur Beschreibung 31 Tabelle 8: ReceiptConfirmationMessage Struktur Beschreibung 34 Tabelle 9: ErrorMessage Struktur Beschreibung 36 Tabelle 10 ObjectInfoMessage Struktur Beschreibung 39 Tabelle 11 UpdateLinkMessage Struktur Beschreibung 41 Tabelle 12 Spalten Datenfeldertabellen 43 Tabelle 13 Übersicht verwendete Codierungen in Tabelle 12 44 Tabelle 14 MessageHeader Datenfelder 45 Tabelle 15 AdministrativeContactInformation Datenfelder 46 Tabelle 16 Identifiers Datenfelder 50 Tabelle 17 Attribute und Strukturen auf Messageebene 52 Tabelle 18 TrainInformation Oberstruktur Beschreibung 53 Tabelle 19 PathInformation Oberstruktur Beschreibung 54 Tabelle 20 Struktur PlannedJourneyLocation Datenfelder 73 Tabelle 21 PlannedCalendar Datenfelder 76 Tabelle 22 ReferenceTrainIDSubCalendar Datenfelder 77 Tabelle 23 RequestedCalendar Datenfelder 79 Tabelle 24 AffectedSection Datenfelder 84 Tabelle 25 InterruptionInformation Datenfelder 85 Tabelle 26 NetworkSpecificParameter Datenfelder 86 Tabelle 27 NetworkSpecificParameter Message-Ebene Datenfelder 90 Tabelle 28 NetworkSpecificParameter Location-Ebene Datenfelder 95 Tabelle 29 NetworkSpecificParameter AffectedSection Datenfelder 96 Tabelle 30: Allgemeine Struktur der ObjectInfoMessage bei der Nutzung für ein CaseReference-Objekt 97 Tabelle 31: Fachliche Parameter CaseReference-Objekt „Taktverbund“ 98 Tabelle 32: Fachliche Parameter des CaseReference-Objektes "Abstellung" 99 Tabelle 33: Fachliche Parameter CaseReference-Objekt „Rahmenvertrag“ 99
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 6
DB Intern / DB internal
|Tabelle 34: Fachliche Parameter CaseReference-Objekt „Baubetroffenheit“|100|
|---|---|
|Tabelle 35 TAF-TSI/TAP-TSI Codelisten Übersicht|103|
|Tabelle 36 TAF-TSI/TAP-TSI Codelisten|115|
|Tabelle 37 TrainActivity Codeliste|117|
|Tabelle 38: Ordnungsrahmenstände Datenfelder|119|
|Tabelle 39 Datei „StammdatenList“ Datenfelder|119|
|Tabelle 40 StammdatenHeader Datenfelder|120|
|Tabelle 41 Betriebsstellen Datenfelder|122|
|Tabelle 42 Strecken Datenfelder|124|
|Tabelle 43 Triebfahrzeuge Datenfelder|125|
|Tabelle 44 Zuggattungen Datenfelder|126|
|Tabelle 45 Streckenklassen Datenfelder|127|
|Tabelle 46: VerkehrsartKundeZusaetze Datenfelder|127|
|Tabelle 47 Flexibilitaeten Datenfelder|128|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 7
DB Intern / DB internal
### **Abbildungsverzeichnis**
|Abbildung 1 PathRequestMessage Hauptstruktur|19|
|---|---|
|Abbildung 2 : PathDetailsMessage Hauptstruktur|22|
|Abbildung 3 PathDetailsRefusedMessage Hauptstruktur|24|
|Abbildung 4 PathConfirmedMessage Hauptstruktur|26|
|Abbildung 5 PathCanceledMessage Hauptstruktur|28|
|Abbildung 6 PathNotAvailableMessage Hauptstruktur|30|
|Abbildung 7 ReceiptConfirmationMessage Struktur|33|
|Abbildung 8 ErrorMessage Struktur|35|
|Abbildung 9 ObjectInfoMessage Struktur|37|
|Abbildung 10 UpdateLinkMessage Struktur|40|
|Abbildung 11 MessageHeader Struktur|44|
|Abbildung 12 AdministrativeContactInformation Struktur|46|
|Abbildung 13 Identifiers Struktur|47|
|Abbildung 14 TrainInformation Oberstruktur|53|
|Abbildung 15 PathInformation Oberstruktur|54|
|Abbildung 16 PlannedJourneyLocation Strukturübersicht|56|
|Abbildung 17 LocationSubsidiaryIdentification Unterstruktur|57|
|Abbildung 18 TypeOfService Unterstruktur|57|
|Abbildung 19 PlannedTrainTechnicalData Struktur|58|
|Abbildung 20 ExceptionalGaugingIdent Unterstruktur|59|
|Abbildung 21 DangerousGoodsIndication Unterstruktur|59|
|Abbildung 22 CombinedTrafficLoadProfile Unterstruktur|59|
|Abbildung 23 StatusOfHarmonization Unterstruktur|60|
|Abbildung 24 TrainActivity Unterstruktur|61|
|Abbildung 25 PlannedCalendar Struktur|74|
|Abbildung 26 ReferenceTrainIDSubCalendar Struktur|75|
|Abbildung 27 RequestedCalendar Struktur|78|
|Abbildung 28 PathPlanningReferenceLocation Struktur|80|
|Abbildung 29 AffectedSection Struktur|82|
|Abbildung 30 InterruptionInformation Struktur|85|
|Abbildung 31 NetworkSpecificParameter Struktur|86|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 8
DB Intern / DB internal
## **1 Hinweise zu diesem Dokument**
- Die EVU-Schnittstelle des Bestellsystems der DB InfraGO orientiert sich ab Version 4.0.0 am TAF-TSI/TAP-TSI-konformen Nachrichtenaustausch zwischen den beteiligten Bahngesellschaften
- Eisenbahnverkehrsunternehmen (EVU) und
- Eisenbahninfrastrukturunternehmen (EIU).
Grundlage dieser Schnittstellendokumentation ist die gültige XSD-Version der TAF-TSI/TAP-TSI-Dokumentation der RNE, die als Anlage 4 dieser Dokumentation beigefügt ist.
In diesem Dokument werden die von TAF-TSI/TAP-TSI vorgegebenen Strukturen der Nachrichtentypen zum Nachrichtenaustausch in der Planungsphase (Trassenbestell- und Zuweisungsprozess) sowie detaillierte Beschreibungen der den einzelnen Nachrichtentypen zugeordneten Attribute dokumentiert.
##### **1.1 Dokumentenaufbau**
- In Kapitel 2 werden die in den TAF-TSI/TAP-TSI-Dokumenten verwendeten Nachrichtentypen (Messages) und deren Strukturen auf Toplevel-Niveau (Hauptstrukturen) beschrieben
- Kapitel 3 enthält für jede TAF-TSI/TAP-TSI-Struktur und deren Unterstruktur(en) die detaillierten Datenfeldbeschreibungen.
- Kapitel 4 beschreibt die Nachrichten und Dateistrukturen zur Bereitstellung von Stammdaten.
##### **1.2 Bezug zu anderen Dokumenten**
Die folgenden Referenzdokumente sind für das Verständnis des vorliegenden Dokuments wichtig und sollten bekannt sein:
- [1] Schnittstellendokumentation_EVU-Schnittstelle_Bestellsystem_V4.x.x.pdf
- [2] Anl2_Technische_Funktionsbeschreibung_
- [3] Anl3_ Übersicht xsd-Versionen_EVU-Schnittstelle_BestellsystemV4.x.x.pdf
- [4] Anl4_taf_tap_cat_complete_sector_Vx.x.x.x.xsd
- [5] Anl5_WSDL für Austausch von TAF/TAP-TSI Nachrichten-und-Heartbeat.zip
- [6] Anl6_Technische_Funktionsbeschreibung_Stammdatenbereitstellung_V4.x.x.pdf
- [7] Anl7_stammdatenEVU.openapi.yaml [8] Anl8_Fachliche_Anwendungsfaelle_V4.x.x.pdf
- [9] Anl9_Fehlernachrichten_der_DB InfraGO_EVU-Schnittstelle_Bestellsystem_V4.x.x.pdf
Dokumentation der EVU-Schnittstelle (Hauptdokument)
Anlage 2: Technische Funktionsbeschreibung der EVU-Schnittstelle des Bestellsystems Anlage 3: Übersicht der Kompatibilität der xsd-Versionen Anlage 4: Aktuelle XSD-Datei “taf_tap_cat_complete_sector” Anlage 5: WSDL-Datei für den Austausch von TAF/TAP-TSI Nachrichten und Heartbeat Anlage 6: Technische Funktionsbeschreibung für die Stammdatenbereitstellung Anlage 7: OpenAPI Spezifikation für die Stammdatenbereitstellung Anlage 8: Fachliche Anwendungsfälle Anlage 9: Fehlernachrichten der DB InfraGO
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 9
DB Intern / DB internal
## **2 Nachrichten**
Die TAF-TSI/TAP-TSI-konforme EVU-Schnittstelle (ab Version 4.0.0) orientiert sich an dem IT-basierten Nachrichtenaustausch zwischen den beteiligten Bahngesellschaften (EVU und EIU), bei dem die nachfolgend genannten Nachrichten verwendet werden sollen. Diese Nachrichtentypen gehören zum Standard von TAF-TSI/TAP-TSI:
##### Kommunikation von EVU nach DB InfraGO:
##### PathRequestMessage:
Die Nachricht dient zur Bestellung eines Produktes der DB InfraGO einschließlich gewünschter Änderungen oder Abmeldung der Bestellung. Dies kann die Bestellung einer Trasse, einer RV-Kapazität für einen Rahmenvertrag oder einer Kurzfristigen Fahrlagenberatung mit Buchungsoption sein, aber auch die Beantragung einer Fahrzeitberechnung oder einer Fahrplan- und Betriebsprogrammstudie sowie die Änderung eines bestehenden Trasseneinzelnutzungsvertrages.
PathConfirmedMessage:
Die Nachricht dient der Bestätigung eines von DB InfraGO an das EVU übergebenen Trassenangebotes und somit dem Abschluss eines Trasseneinzelnutzungsvertrages durch das EVU. Sie wird ebenfalls für die Bestätigung eines RVKapazitätsangebots als Voraussetzung für den Abschluss eines Rahmenvertrages genutzt.
##### PathDetailsRefusedMessage:
Sie dient der Ablehnung eines Angebots für eine Trasse oder eines RV-Kapazitätsangebots bzw. der Ablehnung eines Angebots für eine Trasse mit nochmaliger Überarbeitung (sofern das Angebot nicht der Bestellung des EVU entspricht). Die Nachricht wird auch für die Übermittlung der Berechtigten Beanstandung zu einem übergebenen Vorläufigen Netzfahrplanentwurf genutzt.
##### PathCanceledMessage:
Die Nachricht wird verwendet für die Stornierung von gebuchten Trassen, d. h. Stornierung eines Trasseneinzelnutzungsvertrages durch das EVU, oder der Stornierung einer RV-Kapazität als Teil eines Rahmenvertrages.
Kommunikation von DB InfraGO nach EVU:
##### PathDetailsMessage:
Die Nachricht dient der Übermittlung eines Trassenangebots, eines RV-Kapazitätsangebots bzw. des Ergebnisses für eine Kurzfristige Fahrlagenberatung mit Buchungsoption, für eine Fahrzeitberechungsanfrage oder für eine Fahrplanbzw. Betriebsprogrammstudie, sowie der Übermittlung der Buchungsbestätigung, der Bestätigung verbleibender Trassenanteile nach Änderungen und Stornierungen und der Information über die Nichtkonstruierbarkeit.
##### PathNotAvailableMessage:
Die Nachricht wird von DB InfraGO übermittelt, wenn eine Trasse (räumlich und/oder zeitlich ganz oder teilweise) nicht mehr verfügbar ist und ein bestehender Trasseneinzelnutzungsvertrag ganz oder teilweise netzbedingt storniert werden muss. Die Nachricht dient ebenfalls der Stornierung einer RV-Kapazität als Teil eines Rahmenvertrages durch DB InfraGO.
Kommunikation von DB InfraGO nach EVU bzw. von EVU nach DB InfraGO:
##### ReceiptConfirmationMessage:
Die Nachricht wird übermittelt, wenn eine vorab empfangene Nachricht erfolgreich durch den Empfänger entgegengenommen wurde und weiterverarbeitet werden kann.
##### ErrorMessage:
Die Nachricht wird verwendet, wenn eine vorab empfangene Nachricht durch den Empfänger nicht entgegengenommen oder verarbeitet werden kann. Hierbei kann es sich um erkannte Fehler bei der fachlichen Eingangsprüfung oder um technische Probleme handeln.
##### ObjectInfoMessage:
Die Nachricht wird verwendet, um Informationen zu neuen oder bestehenden Objekten anzufragen und breitzustellen.
##### UpdateLinkMessage:
Die Nachricht wird zur Änderung, Auflösung oder Neubegründung der Verlinkung zwischen den Objekten Train (Zug) und Path (Trasse) verwendet. Innerhalb der Planungsphase wird diese Nachricht für die Kommunikation zwischen EVU und DB InfraGO nicht verwendet
Die Nachrichten werden über eine XML-Schnittstelle ausgetauscht.
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 10
DB Intern / DB internal
##### **2.1 Geschäftsvorfälle und Basisprozesse**
##### **2.1.1 Basisprozesse**
Es werden in TAF-TSI/TAP-TSI drei verschiedene Basisprozesse unterschieden
Request: Erstbestellprozess
Der Lebenszyklus des Basisprozesses beginnt mit der Erstbestellung und endet mit dessen Abschluss durch einen finalisierenden Geschäftsvorfall (z.B. Buchungsbestätigung, Abmeldung).
Modification: Änderungsprozess nach Vertragsschluss für Trassen und RV-Kapazitäten, auch Stornierungen von Trassen und RV-Kapazitäten.
Der Lebenszyklus des Basisprozesses beginnt mit einer Änderungsbestellung oder Stornierung und endet mit deren Abschluss durch einen finalisierenden Geschäftsvorfall (z.B. Buchungsbestätigung für die Änderungsbestellung).
Study: Studien
Der Lebenszyklus des Basisprozesses beginnt mit einer Studienbestellung und endet mit deren Abschluss durch einen finalisierenden Geschäftsvorfall (z.B. Übergabe des Studienergebnisses).
Details hierzu sind im nachfolgenden Kapitel zu finden.
##### **2.1.2 Kanalzwang**
Ein über die EVU-Schnittstelle (Vertriebskanal „EVU-Schnittstelle“ des Bestellsystems der DB InfraGO) begonnener Basisprozess muss auch über diesen Kanal finalisiert werden. Dies gilt für alle drei Basisprozesse. Nähere Erläuterungen zu den Basisprozessen finden Sie in Kapitel 2.1.1.
Für einen über den Kanal „EVU-SST“ begonnenen und finalisierten Basisprozess „Request“ könnte hingegen ein nachfolgender Basisprozess „Modification“ über den Vertriebskanal „Client“ des Bestellsystems der DB InfraGO abgewickelt werden, falls dieser initial vom EVU ausgelöst wird. Netzausgelöste Geschäftsvorfälle im Basisprozess „Modification“ werden jedoch über den gleichen Vertriebskanal abgewickelt wie der Geschäftsvorfall, auf den sich der netzausgelöste Geschäftsvorfall bezieht.
##### **2.1.3 Geschäftsvorfälle und zu verwendende TAF-TSI/TAP-TSI Nachrichtentypen**
Mit den oben genannten zehn Nachrichtentypen der TAF-TSI/TAP-TSI können alle bei der DB InfraGO für den Fahrplanbestell- und Bearbeitungsprozess definierten Geschäftsvorfälle abgewickelt werden.
Nachfolgend werden die einzelnen Geschäftsvorfälle (GV) und die jeweils zu verwendenden TAF-TSI/TAP-TSI-Nachrichtentypen samt weiterer qualifizierender TAF-TSI/TAP-TSI-Merkmale dokumentiert.
Die Geschäftsvorfälle sind nach den von DB InfraGO angebotenen Produkten „Trasse“ (TRA, im Netzfahrplan und Gelegenheitsverkehr), „RV-Kapazität“ (RVK), „Kurzfristige Fahrlagenberatung mit Buchungsoption“ (KFB), „Fahrzeitberechnung“ (FZB) und „Fahrplanstudie / Betriebsprogrammstudie“ (FPS) geordnet.
Zur eindeutigen Identifizierung des über eine TAF-TSI/TAP-TSI-Nachricht transportierten Geschäftsvorfalls sind erforderlich:
- die eigentliche Nachricht (TAF-TSI/TAP-TSI-Message), Details siehe Kapitel 2.2
- die Angabe des jeweiligen Produkts der DB InfraGO. Diese Information wird in der Struktur „NetworkSpecificParameter“ auf Messageebene als Mussangabe im Element „marktProdukt“ hinterlegt (siehe Kapitel 3.14.5)
- nachfolgende, die jeweilige Nachricht zusätzlich qualifizierende Attribute MessageStatus, TypeOfRequest und TypeOfInformation, die in der Nachricht enthalten und Muss-Attribute sind:
- **„MessageStatus“ (MS)**
Das Attribut der Message gibt den Bearbeitungsstatus der Message innerhalb des jeweiligen Basis-Prozesses an. Das Attribut hat die Ausprägungen:
- 1 = creation: Gibt an, dass die Message innerhalb des jeweiligen Prozesses das erste Mal verwendet/gesendet wurde. D. h. das Objekt/die Message wurde neu erstellt, der Identifikator bisher noch nicht verwendet
- 2 = modification: Gibt an, dass die zuvor gesendete Message des gleichen Typs bzw. das in der Message enthaltene Objekt innerhalb des aktuellen Prozesses verändert bzw. zum wiederholten Mal gesendet wurde. Der bisherige Datenstand wird vollständig durch den neuen Datenstand ersetzt.
- 3 = deletion: Die durch den angegebenen Identifikator identifizierte Message (z. B. PathRequestMessage) bzw. das referenzierte Objekt (z. B. Path offer) wird widerrufen und vollständig annulliert/gelöscht. Es erfolgt keine Weiterbearbeitung. Weitere Folgeaktionen sind nicht zulässig.
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 11
DB Intern / DB internal
##### **“TypeOfRequest“ (TOR)**
Das Attribut der Message gibt den Basis-Prozess an, in welchem die gesendete Nachricht ausgelöst/gesendet und bearbeitet wurde.
Es bleibt für alle gesendeten Messages innerhalb des Basis-Prozesses vom Start des Prozesses mit der jeweils den Prozess beginnenden/auslösenden Message bis zum Ende des Prozesses mit der letzten und den Prozess abschließenden (finalisierenden) Message unverändert.
Die definierten Basis-Prozesse und die möglichen Ausprägungen sind:
- 1 = Study: Studienprozess
- Beginnt immer mit einer initialen PathRequestMessage (MS: Creation)
- Endet mit
- der Bereitstellung eines Ergebnisses/Angebotes für die (Studien-)anfrage durch eine PathDetailsMessage mit TOI „final offer“.
- dem Senden einer ErrorMessage (als Antwort auf eine PathRequestMessage)
- der Abmeldung der PathRequestMessage durch Senden einer PathRequestMessage mit MS: Deletion und TOI “withdrawn“
- der Bestätigung der Nichtkonstruierbarkeit durch Senden einer PathDetailsMessage mit TOI „no alternative available“
###### 2 = Request: Erstanmeldeprozess für Trassen und RV-Kapazitäten
- Beginnt immer mit einer initialen PathRequestMessage (MS: Creation)
- Endet mit
- der Bestätigung einer zuvor durch das EVU erfolgten Angebotsannahme für ein übergebenes Trassenangebot bzw. RV-Kapazitätsangebot durch Senden einer PathDetailsMessage mit TypeOfInformation „booked“
- der Bestätigung der Nichtkonstruierbarkeit durch Senden einer PathDetailsMessage mit TOI „no alternative available“
- der Ablehnung eines (finalen) Angebots durch Senden einer PathDetailsRefusedMessage mit TOI „offer rejected (without revision)“
- dem Senden einer ErrorMessage als Antwort auf die PathRequestMessage
- der Abmeldung der PathRequestMessage durch Senden einer PathRequestMessage mit MS: Deletion und TOI “withdrawn“
Erst nach Abschluss des Basis-Prozesses „Request“ kann ein Basis-Prozess „modification“ gestartet werden.
- 3 = Modification: Prozess für die Änderung eines bestehenden Trassenvertrages bzw. der Änderung einer RV-Kapazität als Teil eines Rahmenvertrages. Der Prozess umfasst Änderungen und Stornierungen von Trassen bzw. RV-Kapazitäten durch das EVU (Modification process) und durch das EIU (Alteration process). Voraussetzung ist die Existenz einer gebuchten Trasse mit mindestens einem Verkehrstag bzw. einer RV-Kapazität als Teil eines Rahmenvertrages.
Dabei werden folgende Fälle unterschieden:
###### - Fall Trassenänderung bzw. RV Kapazitätsänderung durch das EVU (modification):
- Beginnt immer mit einer PathRequestMessage (MS: Creation) mit Referenz auf die zu ändernde Trasse bzw. RV-Kapazität (Angabe der PathID als PTID)
- Endet mit
- der Bestätigung einer zuvor durch das EVU erfolgten Angebotsannahme für ein übergebenes Trassenangebot bzw. RV-Kapazitätsangebots durch Senden einer PathDetailsMessage mit TypeOfInformation „booked“ und neuer PathID sowie Referenz auf die bisherige Trasse bzw. RV-Kapazität (PathID als RPTID)
- der Bestätigung der Nichtkonstruierbarkeit durch Senden einer PathDetailsMessage mit OI „no alternative available“
- der Ablehnung eines (finalen) Angebots durch Senden einer PathDetailsRefusedMessage mit TOI „offer rejected (without revision)“
- dem Senden einer ErrorMessage als Antwort auf die PathRequestMessage
- der Abmeldung der PathRequestMessage durch Senden einer PathRequestMessage mit MS: Deletion und TOI “withdrawn“
###### - Fall Trassenänderung bzw. RV Kapazitätsänderung durch das EIU (alteration):
- Beginnt immer mit einer PathNotAvailableMessage mit TOI „preparation of alternative offer in progress“ mit Referenz auf die durch DB InfraGO geänderte Trasse bzw. RV-Kapazität (Angabe PathID als PTID)
- `o` Endet mit
- der Bestätigung einer zuvor durch das EVU erfolgten Angebotsannahme für ein übergebenes Trassenangebot bzw. RV-Kapazitätsangebots durch Senden einer PathDetailsMessage mit TypeOfInformation „booked“ und neuer PathID sowie Referenz auf die bisherige Trasse bzw. RV-Kapazität (PathID als RPTID)
- der Bestätigung der unveränderten Beibehaltung der Trasse bzw. RV-Kapazität durch wiederholtes Senden einer PathDetailsMessage für die bisherige Trasse bzw. RV-Kapazität (PathID als PTID) mit TOI „booked“ (nur nach Ablehnung eines (finalen) Angebots, welche zuvor mit einer PathDetailsRefusedMessage mit TOI: Alternative offer rejected (without revision) durch das EVU gesendet wurde)
- dem Senden einer PathNotAvailableMessage mit TOI „no alternative available“ (nur nach Ablehnung eines (finalen) Angebots, welche zuvor mit einer PathDetailsRefusedMessage mit TOI: Alternative offer rejected (without revision) durch das EVU gesendet wurde). Diese Reaktion ist bereits Teil der Trassenstornierung durch das EIU.
###### Fall Trassenstornierung durch das EVU (modification):
- Beginnt immer mit einer PathCanceledMessage mit TOI „path canceled, full“ oder „path canceled, partial“ mit Referenz auf die zu stornierende Trasse bzw. RV-Kapazität (Angabe PathID als PTID)
- `o` Endet mit dem
- Senden einer PathDetailsMessage mit TOI „booked“ für die ganz oder teilweise stornierte Trasse bzw. RV-Kapazität (Angabe PathID als PTID).
- ▪ dem Senden einer ErrorMessage
###### Fall Trassenstornierung durch das EIU (alteration):
- Beginnt mit dem Senden PathNotAvailableMessage mit TOI „no alternative available“ mit Referenz auf die zu stornierende Trasse bzw. RV-Kapazität (Angabe PathID als PTID)
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 12
DB Intern / DB internal
- Endet mit dem Senden einer PathDetailsMessage mit TOI „booked“ für die ganz oder teilweise stornierte Trasse bzw. RV-Kapazität (Angabe PathID als PTID)
##### **„TypeOfInformation“ (TOI)**
Gibt eine besondere ergänzende Information zur Nachricht entsprechend des jeweiligen Status oder Bearbeitungsschrittes innerhalb des Basisprozesses (Liste der Ausprägungen siehe Kapitel 3.16.1)
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 13
DB Intern / DB internal
|**Produkt der DB In-** **fraGO**|**Produkt** **Kurz**| **Richtung**|**Geschäftsvorfall (GV)**|**Message**|**Message-** **Status** **TypeOfRequest**|**TypeOfInformation**|**Bemerkungen**|
|---|---|---|---|---|---|---|---|
|Alle|Alle|EVU➔DB InfraGO und DB InfraGO➔ EVU|(technische) Empfangsbe- stätigung|ReceiptConfirmationMessage|n/a Basisprozess “Study” = 1; Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3| n/a|TypeOfInformation wird in dieser Nachricht nicht verwendet.|
|Trasse|TRA|EVU➔DB InfraGO|Erstanmeldung|PathRequestMessage|1 2|04 - harmonisation com- pleted/request ready oder 19 pre-accepted of- fer|TOI = 19 – nur bei Trassenanmeldung mit Annahmeerklärung und bei Nutzung der Buchungsoption nach KFB|
|Trasse|TRA|EVU➔DB InfraGO|Änderung vor Angebotsan- gabe|PathRequestMessage|2 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|04 - harmonisation com- pleted/request ready oder 19 pre-accepted of- fer|TOI = 19 – nur bei Trassenanmeldung mit Annahmeerklärung und bei Nutzung der Buchungsoption nach KFB|
|Trasse|TRA|EVU➔DB InfraGO|Abmeldung|PathRequestMessage|3 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|29 - withdrawn|Abmeldung muss im Prozess vor der Angebotsabgabe erfol- gen|
|Trasse|TRA|DB InfraGO➔EVU |Zurückweisung|ErrorMessage|1 n/a|n/a|Verwendung von ErrorCodes gemäß Codeliste und Anlage 9|
|Trasse|TRA|DB InfraGO➔EVU|Nichtkonstruierbarkeit|PathDetailsMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|21 - no alternative avail- able||
|Trasse|TRA|DB InfraGO➔EVU|Vorläufiger Netzfahrplan- entwurf|PathDetailsMessage|1 2|09 - draft offer|Nur gültig für Nfpl|
|Trasse|TRA|DB InfraGO➔EVU|Endgültiger Netzfahrplan- entwurf|PathDetailsMessage|2 2|16 - final offer|Nur gültig für Nfpl|
|Trasse|TRA|EVU➔DB InfraGO|Berechtigte Beanstandung|PathDetailsRefusedMessage|1 2|27 – offer rejected (revi- sion required)|Nur gültig für Nfpl|
|Trasse|TRA||Netzausgelöste Berech- tigte Beanstandung||||1. Nur gültig für Nfpl 2. DB InfraGO -interner Geschäftsvorfall, der zu einem Tras- senangebot führt|
|Trasse|TRA|DB InfraGO➔EVU|Trassenangebot|PathDetailsMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|16 - final offer|1. Gültig im Nfpl als Ergebnis nach Berechtigter Beanstandung oder Netzausgelöster Berechtigter Beanstandung 2. Gültig für GelV als Trassenangebot|
|Trasse|TRA|EVU➔DB InfraGO|Ablehnung|PathDetailsRefusedMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|25 – offer rejected (with- out revision) (bei Ablehnung Trassen-an- gebot) 26 – alternative offer re- jected (without revision) (nach netzausgelöstem Angebot)||
|Trasse|TRA|EVU➔DB InfraGO|Ablehnung mit Überarbei- tungswunsch|PathDetailsRefusedMessage|1 Basisprozess „Request“: = 2|27 – offer rejected (revisi Ablehnung Trassen-ange|on required) (bei bot) Nur gültig für GelV|
||||||Basisprozess „Modification“: = 3|28 – alternative offer reje quired) (nach netzausgelö|cted (revision re- stem Angebot)|
|Trasse|TRA|DB InfraGO➔EVU|Netzausgelöste Ablehnung nach Fristablauf zur Ange- botsannahme|PathDetailsMessage|3 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|29 -withdrawn|Wird gesendet, wenn vom EVU zu einem Trassenange- bot/ENP weder eine Angebotsannahme noch eine Ablehnung gesendet wurde|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 14
DB Intern / DB internal
|**Produkt der DB In-** **fraGO**|**Produkt** **Kurz**| **Richtung**|**Geschäftsvorfall (GV)**|**Message**|**Message-** **Status**|**TypeOfRequest**|**TypeOfInformation**|**Bemerkungen**|
|---|---|---|---|---|---|---|---|---|
|Trasse|TRA|EVU➔DB InfraGO|Angebotsannahme|PathConfirmedMessage|1|Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|17 - final offer accepted 18 – alternative offer ac- cepted|Gültig für Nfpl, GelV|
|Trasse|TRA|DB InfraGO➔EVU|Buchungsbestätigung|PathDetailsMessage|1 (bei Aufträ- gen mit An- nahmeerklä- rung) 2 (nach Ein- gang Ver- tragsbestäti- gung)|Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|22 - booked|bei Aufträgen mit Annahmeerklärung erfolgt mit dem Senden der PathDetailsMessage die Übermittlung von Trassenange- bot und Buchungsbestätigung in einer Nachricht|
|Trasse|TRA|EVU➔DB InfraGO|Änderung nach Vertrags- schluss|PathRequestMessage|1|3|04 - harmonisation com- pleted oder 19 pre-ac- cepted offer (bei Tras- senanmeldung mit An- nahmeerklärung)|Nur gültig für GelV|
|Trasse|TRA|DB InfraGO➔EVU|Ankündigung Netzausge- löste Änderung|PathNotAvailableMessage|1|3|23 – preparation of al- ternative offer in pro- gress|1. Nur gültig für GelV 2. Netzausgelöste Stornierung mit Ankündigung eines netz- ausgelösten Trassenangebots in Folge des DBInfraGOinternen Geschäftsvorfalls netzausgelöste Änderung|
|Trasse|TRA|DB InfraGO➔EVU|Netzausgelöstes Trassen- angebot|PathDetailsMessage|1|3|24 – alternative offer triggered by IM|Nur gültig für GelV|
|Trasse|TRA|EVU➔DB InfraGO|Stornierung|PathCanceledMessage|1|3|32 – path canceled, full; 33 – path canceled, par- tial|Nur gültig für GelV|
|Trasse|TRA|DB InfraGO➔EVU|Stornierungsbestätigung|PathDetailsMessage|3|3|22 -booked|Nur gültig im GelV; Bestätigung der Ausführung einer Stornie- rung durch das EVU|
|Trasse|TRA|DB InfraGO➔EVU|Netzausgelöste Stornie- rung|PathNotAvailableMessage|1|3|21 – No alternative available|Nur gültig für GelV|
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Erstanmeldung einer RVK|PathRequestMessage|1|2|04 - harmonisation com- pleted/request ready||
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Änderung vor Abgabe ei- nes RVK-Angebots|PathRequestMessage|2|Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“:| 04 - harmonisation com- pleted/request ready||
|||||||= 3|||
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Abmeldung einer RVK-An- meldung|PathRequestMessage|3|Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“: = 3| 29 - withdrawn|Abmeldung muss im Prozess vor der Abgabe des RVK-Ange- bots erfolgen|
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Zurückweisung einer RVK- Anmeldung|ErrorMessage|1|n/a|n/a|Verwendung von ErrorCodes gemäß Codeliste und Anlage 9|
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Nichtkonstruierbare RVK- Anmeldung|PathDetailsMessage|1|Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“: = 3| 21 - no alternative avail- able||
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 15
DB Intern / DB internal
|**Produkt der DB In-** **fraGO**|**Produkt** **Kurz**| **Richtung**|**Geschäftsvorfall (GV)**|**Message**|**Message-** **Status** **TypeOfRequest**|**TypeOfInformation**|**Bemerkungen**|
|---|---|---|---|---|---|---|---|
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|RVK-Angebot|PathDetailsMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“: = 3| 16 - final offer||
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Widerruf des abgegebe- nen RVK-Angebots|PathDetailsMessage|2 Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“: = 3| 21 - no alternative available|Netzausgelöste Stornierung des abgegebenen RVK-Angebots nach Beanstandung durch BNetzA|
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Netzausgelöste Änderung eines abgegebenen RVK- Angebots|PathDetailsMessage|2 Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“: = 3| 24 - alternative offer triggered by IM|Netzausgelöste Änderung des abgegebenen RVK-Angebots nach Beanstandung durch BNetzA|
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Ablehnung eines RVK-An- gebotes|PathDetailsRefusedMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“:| 25 – offer rejected (with- out revision)||
||||||= 3|||
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Netzausgelöste Ablehnung nach Fristablauf zur An- nahme eines RVK-Ange- bots|PathDetailsMessage|3 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|29 -withdrawn|Wird gesendet, wenn vom EVU zu einem RVK-Angebot weder eine Angebotsannahme noch eine Ablehnung gesendet wurde|
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Bestätigung eines RVK-An- gebotes|PathConfirmedMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modifica- tion“: | 17 - final offer accepted||
||||||= 3|||
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Buchungsbestätigung|PathDetailsMessage|2 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|22 - booked|nach Ablauf der Prüffrist der BNetzA, sofern keine Beanstan- dung erfolgt ist.|
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Änderung einer RVK nach Vertragsschluss|PathRequestMessage|1 3|04 - harmonisation com- pleted/request ready||
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Netzausgelöste Änderung einer RVK|PathDetailsMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|24 - alternative offer triggered by IM|Netzausgelöste Änderung einer RVK|
|Rahmenvertragskapazität|RVK|EVU➔DB InfraGO|Stornierung einer RVK|PathCanceledMessage|1 3|32 – path canceled, full; 33 – path canceled, par- tial||
|Rahmenvertragskapazität|RVK|DB InfraGO➔EVU|Netzausgelöste Stornie- rung einer RVK|PathNotAvailableMessage|1 Basisprozess „Request“: = 2 Basisprozess „Modification“: = 3|21 - no alternative available|Netzausgelöste Stornierung einer RVK|
|Kurzfristige Fahrlagenbe- ratung mit Buchungsop- tion|KFB|EVU➔DB InfraGO|Erstanmeldung einer Kurz- fristigen Fahrlagenbera- tung mit Buchungsoption|PathRequestMessage|1 1|05 - path study request||
|Kurzfristige Fahrlagenbe- ratung mit Buchungsop- tion|KFB|DB InfraGO➔EVU|Zurückweisung|ErrorMessage|1 n/a|n/a|Verwendung von ErrorCodes gemäß Codeliste und Anlage 9|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 16
DB Intern / DB internal
|**Produkt der DB In-** **fraGO**|**Produkt** **Kurz**| **Richtung**|**Geschäftsvorfall (GV)**|**Message**|**Message-** **Status**|**TypeOfRequest**|**TypeOfInformation**|**Bemerkungen**|
|---|---|---|---|---|---|---|---|---|
|Kurzfristige Fahrlagenbe- ratung mit Buchungsop- tion|KFB|DB InfraGO➔EVU|Nichtkonstruierbarkeit|PathDetailsMessage|1|1|21 - no alternative avail- able||
|Kurzfristige Fahrlagenbe- ratung mit Buchungsop- tion|KFB|DB InfraGO➔EVU|Ergebnis einer Kurzfristi- gen Fahrlagenberatung mit Buchungsoption|PathDetailsMessage|1|1|16 - final offer||
|Fahrzeitberechnung, Fahrplanstudie, Betriebs- programmstudie|FZB FPS BPS|EVU➔DB InfraGO|Erstanmeldung|PathRequestMessage|1|1|05 - path study request||
|Fahrzeitberechnung, Fahrplanstudie, Betriebs- programmstudie|FZB FPS BPS|EVU➔DB InfraGO|Änderung vor Ergebnisbe- reitstellung|PathRequestMessage|2|1|05 - path study request||
|Fahrzeitberechnung, Fahrplanstudie, Betriebs- programmstudie|FZB FPS BPS|EVU➔DB InfraGO|Abmeldung (Stornierung der Anfrage)|PathRequestMessage|3|1|29 - withdrawn|Abmeldung muss im Prozess vor der Ergebnisabgabe erfolgen|
|Fahrzeitberechnung, Fahrplanstudie, Betriebs- programmstudie|FZB FPS BPS|DB InfraGO➔EVU|Zurückweisung|ErrorMessage|1|n/a|n/a|Verwendung von ErrorCodes gemäß Codeliste und Anlage 9|
|Fahrzeitberechnung, Fahrplanstudie, Betriebs- programmstudie|FZB FPS BPS|DB InfraGO➔EVU|Nichtkonstruierbarkeit|PathDetailsMessage|1|1|21 - no alternative avail- able||
|Fahrzeitberechnung, Fahrplanstudie, Betriebs- programmstudie|FZB FPS BPS|DB InfraGO➔EVU|Ergebnis|PathDetailsMessage|1|1|16 - final offer||
Tabelle 1: Geschäftsvorfälle und TAF-TSI/TAP-TSI Nachrichtentypen
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 17
DB Intern / DB internal
##### **2.2 Hauptstrukturen der Nachrichten**
Die laut XSD vorgegebenen TAF-TSI/TAP-TSI-Nachrichten sind vom Haupt-Element (Bezeichnung der Nachricht, z.B. PathRequestMessage) über Haupt- und Unterstrukturen (teilweise auch verschachtelt) bis zu den jeweiligen zugeordneten Attributen strukturiert. Die Gesamtstruktur pro Nachricht ist zu komplex, um diese Struktur in einer einzigen Übersicht zu dokumentieren. Daher werden in Kapitel 2.2 zunächst nur die Hauptstrukturen der Nachrichten gezeigt. Details zu weiteren Unterstrukturen und deren Attributen werden in Kapitel 3 „Datenfeldbeschreibungen“ beschrieben.
Die Abbildungen zeigen in Aufklapptechnik die Hauptstrukturen und die jeweiligen Unterstrukturen. Die Tabellen dokumentieren das Vorkommen und die Beschreibungen der jeweiligen Struktur.
Die senkrechten Striche in der Spalte „Strukturelement“ symbolisieren dabei die Ebene der Struktur. Striche auf gleicher Höhe bedeuten die Zuordnung der Unterstruktur/des Attributs zur gleichen Ebene. Die Spalte „Vorkommen“ gibt an, wie häufig ein Attribut bzw. eine Unterstruktur in der übergeordneten Struktur IT-technisch vorkommt:
- 0..1 = Kannfeld
- 1 = Mussfeld
- 0..N = Wiederholstruktur (optional)
- 1..N = Wiederholstruktur (mindestens eine Ausprägung der Struktur)
- _<_ zahl>..N = Wiederholstruktur (optional), mindestens durch _<_ zahl> angegebene Anzahl von Ausprägungen; _<_ zahl> stellt dabei den Index (lfd. Nr.) der Ausprägung dar
##### **2.2.1 PathRequestMessage**
Die Nachricht wird vom EVU an die am Gesamtzuglauf beteiligten EIU gesendet (im Sinne dieser EVU-Schnittstellen-Dokumentation also an DB InfraGO) und enthält neben den Standardinformationen und -strukturen (Kopfangaben, Identifikatoren, Status- und Typangaben, EVU) als wichtigste Informationen
- in der Struktur „TrainInformation“ die geplante Route des Zuges, dargestellt als geplanter Gesamtzuglauf (u. a. mindestens Start- und Zielbahnhof mit den Übergängen zwischen den beteiligten EIU (Handover-points), weitere für den Gesamtzuglauf geltende Angaben, überregionale Zeitangaben) und
- in der Struktur „PathInformation“ den bei einem konkreten EIU gewünschten und zu bestellenden Zugtrassenverlauf (Fahrlage).
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 18
DB Intern / DB internal
Abbildung 1 PathRequestMessage Hauptstruktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 19
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung**|**Bemerkungen**|
|---|---|---|---|
|PathRequestMessage|1|Die Nachricht wird vom EVU an das jeweils beteiligte EIU gesendet und stellt Informationen zum Gesamtzuglauf und ausgewählten Zugdaten (TrainInformation) sowie Angaben zur gewünschten Fahrlage des Zuges im Bereich eines Infrastrukturbetreibers (PathInformation) zur Verfügung.||
|I....MessageHeader|1|Für alle Nachrichten erforderlich|Siehe Kapitel 3.2|
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifiers|0..1|Eindeutige Identifizierung der Nachricht selbst, der Nachricht, auf die sich die Nachricht bezieht und ggf. auf Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen.|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRe- questID, CaseReferenceID|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase|Angabe von ReferenceTRID, RouteID, PathRequestID (alle verpflichtend) und ggf. CaseReferenceID.|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Angabe von ID anderer Objekte, die mitberücksichtigt wer- den sollen oder im Kontext zu bearbeiten sind bzw. auf die referenziert wird (z. B. geänderte Trasse). Bei Trassenanmeldungen mit Bezug auf ein Ergebnis einer Fahrplan- oder Betriebsprogrammstudie oder einer Fahrla- genberatung mit Buchungsoption ist die PathID des Ergeb- nisses anzugeben.|
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportIdentifiers, so- fern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation, 2=modification, 3=deletion|
|I....TypeOfRUHarmonization|0..1|Typ der EVU-Harmonisierung|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: Full, Part, None|
|I....TypeOfIMHarmonization|0..1|Typ der EIU-Harmonisierung|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: Full, Part|
|I....CoordinatingIM|0..1|CompanyCode des koordinierenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16"Codelisten"|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durchführenden EVU (Responsib- leRU); Angabe ist nur bei interoperablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfRequest|1|Typ der Nachricht (Basisprozess)|1. Identifiziert den Basisprozess der Nachricht in der Pla- nungsphase 2. Siehe Kapitel 3.5 "Attribute auf Messageebene" 3. Ausprägungen: 1=Study, 2=Request, 3=Modification|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|1|Typ der Information|1. Kennzeichnet besondere Ausprägung der Nachricht für den jeweiligen Status innerhalb des Basisprozesses 2. Indikation, zu welchem Prozessschritt in der Planungs- phase die Nachricht gehört 3. Liste der Ausprägungen siehe Kapitel 3.16.1 "|
|I....TrainInformation|1|Überregionale und allgemeine Zuginformationen des EVU über den gesamten geplanten Zuglauf||
|I.... I....PlannedJourneyLocation|2..N|Zuglaufpunkte||
|I.... I....PlannedCalendar|1|Kalender; gibt den Verkehrszeitraum und die Verkehrstage der Gültigkeit des Routenobjekts an. In Abhängigkeit vom Wert im Attribut OffsetToReference können sich die Verkehrstage im Kalender der Route im Vergleich zu den Verkehrstagen des ReferenceTrains um die Anzahl der Tageswech- sel verschieben.|Gilt abfahrtsbezogen am Startbahnhof des Gesamtzuglaufs (Route).|
|I.... I....PathPlanningReferenceLocation|1|Referenzbetriebsstelle; Laufpunkt des Zuges, ab welchem die Konstruktion beginnen soll||
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 20
DB Intern / DB internal
|**Strukturelement** |**Vor-** **kom-** **men** |**Beschreibung** |**Bemerkungen**|
|---|---|---|---|
|I....PathInformation|1|enthält Angaben zum gewünschten Zugtrassenverlauf (Fahrlage) innerhalb des Zuständigkeitsbe- reiches eines konkreten am Zuglauf beteiligten EIU||
|I.... I....PlannedJourneyLocation|2..N|Zuglaufpunkte||
|I.... I....PlannedCalendar|1|Kalender; gibt den Verkehrszeitraum und die Verkehrstage des Zuges innerhalb des Infrastruktur- bereiches des jeweiligen Infrastrukturbetreibers an. In Abhängigkeit vom Wert im Attribut Offset- ToReference können sich die Verkehrstage im Kalender der PathInformation im Vergleich zu den Verkehrstagen des ReferenceTrains oder der Route um die Anzahl der Tageswechsel verschieben.|Gilt abfahrtsbezogen am Startbahnhof des gewünschten Zugtrassenverlaufs im Bereich des EIU, für welches die Trassenbestellung bzw. RV-Kapazitätsbestellung erfolgt.|
|I.... I....RequestedCalendar|0..1|Gibt die in einer PathRequestMessage übergebene Struktur PlannedCalendar unverändert zurück|Keine Verwendung dieser Struktur in der Trassenerstbe- stellung. Verwendung entsprechend Kap 3.10.1 bei Ände- rungen nach Vertragsschluss|
|I....NetworkSpecificParameter|0..N|Spezifische Parameter (Attribute, Felder) des EIU|Die ggf. in der Kommunikation mit DB InfraGO zu verwen- denden NetworkSpecificParameter sind in Kap, 3.14.5 ent- halten.|
|I....FreeTextField|0..6|Frei definierbarer Text|Durch max. 6 Wiederholungen kann die Textlänge variiert werden; das Freitextfeld darf nur Angaben enthalten, die nichtin einem definierten Attribut (Strukturelement) der Nachricht angegeben werden können.|
Tabelle 2: PathRequestMessage Hauptstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 21
DB Intern / DB internal
##### **2.2.2 PathDetailsMessage**
Die Nachricht wird vom EIU gesendet, um die Angebote und Ergebnisse (z. B. Trassenangebot, RV-Kapazitätsangebot, Studienergebnis, sonstige Rückmeldungen) in der Struktur „PathInformation“ an das EVU zu kommunizieren. Die Nachricht wird ebenso für die Übermittlung netzausgelöster Angebote und Ergebnisse verwendet.
Wird die PathDetailsMessage zur Übermittlung des Geschäftsvorfalls „Nichtkonstruierbarkeit“ verwendet, erhält sie ebenfalls eine PathID, die jedoch in diesem Fall keine Trasse bzw. RV-Kapazität referenziert. Die Struktur PlannedCalendar enthält die Verkehrstage, an welchen keine Trasse bzw. RV-Kapazität zugewiesen werden kann, in der Struktur „PlannedJourneyLocation“ wird die bestellte Start- und Zielbetriebsstelle wiederholt.
Abbildung 2 : PathDetailsMessage Hauptstruktur
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung**|**Bemerkungen**|
|---|---|---|---|
|PathDetailsMessage|1|Die Nachricht wird vom EIU gesendet, um Angebote oder Ergebnisse (Path) des EIU an das EVU zu kommunizieren||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifiers|0..1|Eindeutige Identifizierung der Nachricht selbst, der Nachricht, auf die sich die Nachricht bezieht und ggf. auf Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen.|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRe- questID, CaseReferenceID|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase; Angabe der PathID der angebotenen Trasse, des RV-Kapazitäts- angebots bzw. des Ergebnisses (Pflichtangabe)|Zusätzlich Angabe von ReferenceTRID, RouteID, PathRe- questID (außer bei netzausgelösten Angeboten) und ggf. CRID aus der PathRequestMessage, auf welche sich das Angebot bezieht|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 22
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung**|**Bemerkungen**|
|---|---|---|---|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase; bei Angeboten nach berechtigten Beanstan- dungen, bei Änderungen nach Vertragsschluss oder netzausgelösten Angeboten Angabe der Pa- thID der vorherigen (angebotenen oder gebuchten) Trasse bzw. RV-Kapazität, sowie bei Änderun- gen durch Baumaßnahmen die auslösende BKE|Angabe von ID anderer Objekte, die mitberücksichtigt wer- den sollen oder im Kontext zu bearbeiten sind.|
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportIdentifiers|Siehe Kapitel 3.16"Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation|
|I....TypeOfRUHarmonization|0..1|Typ der EVU-Harmonisierung|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: Full, Part, None|
|I....TypeOfIMHarmonization|0..1|Typ der EIU-Harmonisierung|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: Full, Part|
|I....CoordinatingIM|0..1|CompanyCode des koordinierenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16"Codelisten"|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durchführenden EVU (Responsib- leRU); Angabe ist nur bei interoperablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfRequest|1|Typ der Nachricht (Basisprozess)|1. Identifiziert den Basisprozess der Nachricht in der Pla- nungsphase 2. Siehe Kapitel 3.5 "Attribute auf Messageebene" 3. Ausprägungen: 1=Study, 2=Request, 3=Modification|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|1|Typ der Information|1. Kennzeichnet besondere Ausprägung der Nachricht für den jeweiligen Status innerhalb des Basisprozesses 2. Indikation, zu welchem Prozessschritt in der Planungs- phase die Nachricht gehört 3. Liste der Ausprägungen siehe Kapitel 3.16.1) "|
|I....PathInformation|1|Trassendaten||
|I.... I....PlannedJourneyLocation|2..N|Trassenlaufpunkte||
|I.... I....PlannedCalendar|1|Kalender; gibt den Verkehrszeitraum und die Verkehrstage der Zugtrasse, der RV-Kapazität bzw. des Ergebnisses an. In Abhängigkeit vom Wert im Attribut OffsetToReference können sich die Ver- kehrstage im Kalender der PathInformation im Vergleich zu den Verkehrstagen des Refe- renceTrains oder der Route um die Anzahl der Tageswechsel verschieben.|Gilt abfahrtsbezogen am Startbahnhof der Zugtrasse|
|I.... I....RequestedCalendar|0..1|Gibt die in der referenzierten PathRequestMessage in der Struktur PathInformation übergebene Struktur PlannedCalendar unverändert zurück|Wird nur angegeben, wenn die Zugtrasse nicht an dem (den) bestellten Verkehrstag(en) konstruiert wurde, son- dern am jeweiligen Vor- oder Folgetag.|
|I....NetworkSpecificParameter|0..N|Spezifische Parameter (Attribute, Felder) des EIU (in diesem Dokument die der DB InfaGO)|Die ggf. in der Kommunikation mit DB InfarGO zu verwen- denden NetworkSpecificParameter sind in Kap, 3.14.5 ent- halten.|
|I....FreeTextField|0..6|Frei definierbarer Text|Durch max. 6 Wiederholungen kann die Textlänge variiert werden; das Freitextfeld darf nur Angaben enthalten, die nichtin einem definierten Attribut (Strukturelement) der Nachricht angegeben werden können.|
Tabelle 3: PathDetailsMessage Hauptstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 23
DB Intern / DB internal
##### **2.2.3 PathDetailsRefusedMessage**
Die Nachricht wird vom EVU gesendet, um das EIU zu informieren, dass das übergebene Angebot bzw. Ergebnis (Path) nicht akzeptabel ist, da es nicht der übergebenen Bestellung entspricht. Mit der Übermittlung dieser Nachricht können die Geschäftsvorfälle „Ablehnung ohne Überarbeitung“, „Ablehnung mit Überarbeitung“ oder „Berechtigte Beanstandung“ für ein übergebenes Trassenangebot oder RV-Kapazitätsangebot bzw. zum „Vorläufigen Netzfahrplanentwurf“ realisiert werden. Die Nutzung dieser Nachricht für den Geschäftsvorfall „Ablehnung mit Überarbeitung“ ist nur als Reaktion auf Angebote des Gelegenheitsverkehrs zulässig. Die Nutzung dieser Nachricht für den Geschäftsvorfall „Berechtigte Beanstandung“ ist nur als Reaktion auf den Geschäftsvorfall „Vorläufiger Netzfahrplanentwurf“ gestattet.
Ein von der DB InfraGO übergebenes Angebot darf nur komplett abgelehnt bzw. beanstandet werden. Daher ist die Angabe eines Start- und Zielbahnhofs für einen Zugtrassenabschnitt (StartOfSection und EndOfSection) und einer Verkehrszeitregelung in der Struktur „AffectedSection“ nicht erforderlich und kann entfallen. Die Struktur „AffectedSection“ ist nicht zu befüllen und wegzulassen.
Das Attribut „FreeTextField“ muss in den Geschäftsvorfällen „Berechtigte Beanstandung“ (Typ 26) und „Ablehnung mit Überarbeitung“ (Typ 14) verwendet werden, um eine Begründung für die Beanstandung bzw. Überarbeitung zu hinterlegen.
Abbildung 3 PathDetailsRefusedMessage Hauptstruktur
|**Strukturelement** |**Vor-** **kom-** **men** |**Beschreibung** |**Bemerkungen**|
|---|---|---|---|
|PathDetailsRefusedMessage|1|Die Nachricht wird vom EVU gesendet, um das EIU zu informieren, dass das Trassenangebot, RV- Kapazitätsangebot bzw. Studienergebnis oder Ergebnis der Fahrzeitberechnung nicht akzeptabel ist.||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifiers|0..1|Eindeutige Identifizierung der Nachricht selbst, der Nachricht, auf die sich die Nachricht bezieht und ggf. auf Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRe- questID, CaseReferenceID|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase; Angabe der PathID des abgelehnten Angebots (Pflichtangabe)|Zusätzlich Angabe der ReferenceTRID, RouteID und Path- RequestID des ablehnten Angebots möglich|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente.|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 24
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung**|**Bemerkungen**|
|---|---|---|---|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Ggf. Angabe der PathID anderer abgelehnter Angebote.|
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportIdentifiers, so- fern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation|
|I....TypeOfRequest|0..1|Typ der Nachricht (Basisprozess)|1. Identifiziert den Basisprozess der Nachricht in der Pla- nungsphase 2. Siehe Kapitel 3.5 "Attribute auf Messageebene" 3. Ausprägungen: 1=Study, 2=Request, 3=Modification|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|0..1|Typ der Information|1. Kennzeichnet eine besondere Ausprägung der Nach- richt für den jeweiligen Status innerhalb des Basisprozes- ses 2. Indikation, zu welchem Prozessschritt in der Planungs- phase die Nachricht gehört 3. Liste der Ausprägungen siehe Kapitel 3.16.1) "|
|I....CoordinatingIM|0..1|CompanyCode des koordinierenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durchführenden EVU (Responsib- leRU); Angabe ist nur bei interoperablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....RevisedRequest|0..1|Hinweis für das EIU, dass das EVU beabsichtigt, einen überarbeiteten Request bzw. eine Alterna- tive zu senden|Dieses Attribut ist nicht zu verwenden; bei fachlichem Än- derungsbedarf kann das EVU das übergebene Angebot ab- lehnen und eine Neubestellung auslösen oder das überge- bene Angebot annehmen und eine Änderung nach Ver- tragsschluss senden.|
|I....AffectedSection|0..N|Beschreibt den abgelehnten Trassenabschnitt eines übergebenen Trassenangebots, RV-Kapazi- tätsangebots bzw. Studienergebnisses und dessen Verkehrszeitregelung|Von DB InfaGO übergebene Trassenangebote, RV-Kapazi- tätsangebote bzw. Studienergebnisse dürfen nur vollstän- dig (ggf. zur Überarbeitung) abgelehnt werden. Daher ist die Angabe nicht erforderlich und wegzulassen.|
|I....FreeTextField|0..6|Frei definierbarer Text|Durch max. 6 Wiederholungen kann die Textlänge variiert werden; das Freitextfeld darf nur Angaben enthalten, die nichtin einem definierten Attribut (Strukturelement) der Nachricht angegeben werden können. Ggf. kann hier durch das EVU zusätzlich eine Begründung für die Berech- tigte Beanstandung (im Netzfahrplanprozess) bzw. Ableh- nung mit Überarbeitung (im Gelegenheitsverkehr) angege- ben werden.|
Tabelle 4: PathDetailsRefusedMessage Hauptstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 25
DB Intern / DB internal
##### **2.2.4 PathConfirmedMessage**
Die Nachricht wird vom EVU gesendet, um ein von DB InfraGO übergebenes Trassenangebot oder einen endgültigen Netzfahrplanentwurf gesamthaft zu bestätigen und anzunehmen. Dadurch kommt ein Trasseneinzelnutzungsvertrag zustande. Mit der Übermittlung dieser Nachricht wird der Geschäftsvorfall „Angebotsannahme“ ausgeführt. Die Nachricht wird ebenso zur Bestätigung eines RV-Kapazitätsangebots als Voraussetzung für den Abschluss eines Rahmenvertrages genutzt.
Ein von der DB InfraGO übergebenes Angebot für eine Zugtrasse bzw. RV-Kapazität darf nur komplett angenommen werden. Daher ist die Angabe eines Start- und Zielbahnhofs und einer Verkehrszeitregelung für einen Abschnitt des Trassenangebots in der Struktur „AffectedSection“ nicht erforderlich und kann entfallen. Die Struktur „AffectedSection“ ist nicht zu befüllen und wegzulassen.
Abbildung 4 PathConfirmedMessage Hauptstruktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 26
DB Intern / DB internal
|**Strukturelement** |**Vor-** **kom-** **men**|**Beschreibung** |**Bemerkungen**|
|---|---|---|---|
|PathConfirmedMessage|1|Die Nachricht wird vom EVU gesendet, um ein vom EIU gesendetes Angebot für eine Trasse bzw. RV-Kapazität zu bestätigen. Dadurch kommt ein Trasseneinzelnutzungsvertrag zustande bzw. wird der Abschluss eines Rahmenvertrages vorbereitet.||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifiers|0..1|Eindeutige Identifizierung der Nachricht selbst, der Nachricht, auf die sich die Nachricht bezieht und ggf. auf Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen.|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRe- questID, CaseReferenceID|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase; Angabe der PathID des angenommenen Angebots (Pflichtan- gabe)|Zusätzlich Angabe der ReferenceTRID und RouteID des an- genommenen Angebots möglich|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente.|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Ggf. Angabe der PathID anderer angenommener Ange- bote.|
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportIdentifiers, so- fern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation|
|I....TypeOfRequest|0..1|Typ der Nachricht (Basisprozess)|1. Identifiziert den Basisprozess der Nachricht in der Pla- nungsphase 2. Siehe Kapitel 3.5 "Attribute auf Messageebene" 3. Ausprägungen: 2=Request, 3=Modification|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|0..1|Typ der Information|1. Kennzeichnet eine besondere Ausprägung der Nach- richt für den jeweiligen Status innerhalb des Basisprozes- ses 2. Indikation, zu welchem Prozessschritt in der Planungs- phase die Nachricht gehört 3. Liste der Ausprägungen siehe Kapitel 3.16.1) "|
|I....CoordinatingIM|0..1|CompanyCode des koordinierenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durchführenden EVU (Responsib- leRU); Angabe ist nur bei interoperablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....AffectedSection|0..N|Beschreibt den angenommenen Abschnitt eines übergebenen Trassenangebots bzw. RV-Kapazi- tätsangebots und dessen Verkehrszeitregelung|Von DB InfraGO übergebene Angebote für Trassen und RV-Kapazitäten dürfen nur vollständig angenommen wer- den. Daher ist die Angabe nicht erforderlich und wegzulas- sen.|
Tabelle 5: PathConfirmedMessage Hauptstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 27
DB Intern / DB internal
##### **2.2.5 PathCanceledMessage**
Die Nachricht wird vom EVU an das EIU gesendet, um einen Vertrag ganz oder teilweise zu stornieren. Mit der Übermittlung dieser Nachricht werden der Geschäftsvorfall „Stornierung“ (einer Trasse bzw. RV-Kapazität) ausgeführt. In der Struktur „PlannedCalendar“ der Struktur „AffectedSection“ sind die zu stornierenden Verkehrstage der mit der PathID referenzierten gebuchten Trasse bzw. RV-Kapazität anzugeben. Zusätzlich können noch weitere Angaben in der Struktur „NetworkSpecificParameter“ erforderlich sein (siehe Kapitel 3.14).
Abbildung 5 PathCanceledMessage Hauptstruktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 28
DB Intern / DB internal
|**Strukturelement** |**Vor-** **kom-** **men**|**Beschreibung** |**Bemerkungen**|
|---|---|---|---|
|PathCanceledMessage|1|Die Nachricht wird von EVU an das EIU gesendet, um eine Trasse bzw. RV-Kapazität ganz bzw. teil- weise zu stornieren.||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifiers|0..1|Eindeutige Identifizierung der Nachricht selbst, der Nachricht, auf die sich die Nachricht bezieht und ggf. auf Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen.|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRe- questID, CaseReferenceID|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase; Angabe der PathID der gebuchten Trasse bzw. RV-Kapazität, die storniert werden soll (Pflichtangabe)|Zusätzlich Angabe der ReferenceTRID und RouteID der Trasse, die storniert werden soll|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente.|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Ggf. Angabe der PathID anderer Stornierungen von Tras- sen bzw. RV-Kapazitäten des gleichen Zuges|
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportIdentifiers, so- fern zutreffend.|Siehe Kapitel 3.16 "Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation|
|I....TypeOfRequest|0..1|Typ der Nachricht (Basisprozess)|1. Identifiziert den Basisprozess der Nachricht in der Pla- nungsphase 2. Siehe Kapitel 3.5 "Attribute auf Messageebene" 3. Ausprägungen: 3=Modification|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|0..1|Typ der Information|1. Kennzeichnet eine besondere Ausprägung der Nach- richt für den jeweiligen Status innerhalb des Basisprozes- ses 2. Indikation, zu welchem Prozessschritt in der Planungs- phase die Nachricht gehört 3. Liste der Ausprägungen siehe Kapitel 3.16.1)|
|I....CoordinatingIM|0..1|CompanyCode des koordinierenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durchführenden EVU (Responsib- leRU); Angabe ist nur bei interoperablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....AffectedSection|1..N|enthält Angaben zu Start- und Zielbf. der zu stornierenden Trasse bzw. RV-Kapazität und der zu stornierenden Verkehrstage|Trassen können über den gesamten Verkehrszeitraum oder für einen Zeitabschnitt oder an einzelnen Verkehrsta- gen über den gesamten Laufweg oder nur auf einem Teil- abschnitt der Trasse storniert werden (Geschäftsvorfall „Stornierung“). Der in der Nachricht angegebene Kalender bezieht sich auf den in StartOfSection angegebenen TLP. RV-Kapazitäten können nur für vollständige, in der Zukunft liegende Fahrplanjahre gesamthaft storniert werden. Bei der DB InfraGO ist pro Nachricht nur eine AffectedSec- tion erlaubt.|
|I....FreeTextField|0..6|Frei definierbarer Text|Durch max. 6 Wiederholungen kann die Textlänge variiert werden; das Freitextfeld darf nur Angaben enthalten, die nichtin einem definierten Attribut (Strukturelement) der Nachricht angegeben werden können.|
Tabelle 6: PathCanceledMessage Hauptstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 29
DB Intern / DB internal
##### **2.2.6 PathNotAvailableMessage**
Die Nachricht wird vom EIU an das EVU gesendet, um zu signalisieren, dass eine Trasse bzw. RV-Kapazität nicht (mehr) verfügbar ist. Sofern von DB InfraGO nicht im Anschluss daran mit einer PathDetailsMessage ein neues, netzausgelöstes Angebot übergeben wird, entspricht dies einer netzausgelösten Stornierung. Diese Nachricht dient zur Ausführung der Geschäftsvorfälle „Netzausgelöste Stornierung“ (einer Trasse bzw. RV-Kapazität) oder zur Ankündigung der nachfolgenden Übergabe eines netzausgelösten Angebots.
In der Struktur „PlannedCalendar“ der Struktur „AffectedSection“ sind die zu stornierenden Verkehrstage der mit der PathID referenzierten gebuchten Trasse bzw. RV-Kapazität anzugeben.
Zusätzlich können noch weitere Angaben in der Struktur „NetworkSpecificParameter“ erforderlich sein (siehe Kapitel 3.14.7).
Abbildung 6 PathNotAvailableMessage Hauptstruktur
|**Strukturelement** |**Vor-** **kom-** **men** |**Beschreibung** |**Bemerkungen**|
|---|---|---|---|
|PathNotAvailableMessage|1|Die Nachricht wird vom EIU an das EVU gesendet, um zu signalisieren, dass eine Trasse bzw. RV- Kapazität nicht (mehr) verfügbar ist.||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifiers|0..1|Eindeutige Identifizierung der Nachricht selbst, der Nachricht, auf die sich die Nachricht bezieht und ggf. auf Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRe- questID, CaseReferenceID|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase; Angabe der PathID der gebuchten Trasse bzw. RV-Kapazität, die netzausgelöst storniert oder mit einem nachfolgenden netzausgelösten Angebot geändert wer- den soll (Pflichtangabe)|Zusätzlich Angabe der ReferenceTRID und RouteID der Trasse bzw. RV-Kapazität, die netzausgelöst storniert oder geändert werden soll|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente.|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Ggf. Angabe der PathID anderer Stornierungen bzw. netz- ausgelösten Änderungen zu Trassen bzw. RV-Kapazitäten des gleichen Zuges|
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportIdentifiers, so- fern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 30
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung**|**Bemerkungen**|
|---|---|---|---|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation|
|I....TypeOfRequest|0..1|Typ der Nachricht (Basisprozess)|1. Identifiziert den Basisprozess der Nachricht in der Pla- nungsphase 2. Siehe Kapitel 3.5 "Attribute auf Messageebene" 3. Ausprägungen: 3=Modification|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|0..1|Typ der Information|1. Kennzeichnet eine besondere Ausprägung der Nachricht für den jeweiligen Status innerhalb des Basisprozesses 2. Indikation, zu welchem Prozessschritt in der Planungs- phase die Nachricht gehört 3. Liste der Ausprägungen siehe Kapitel 3.16.1) "Identifi- ziert|
|I....CoordinatingIM|0..1|CompanyCode des koordinierenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durchführenden EVU (Responsib- leRU); Angabe ist nur bei interoperablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16 "Codelisten"|
|I....AffectedSection|1..N|enthält Angaben zu Start- und Zielbf. der zu stornierenden Trasse und der zu stornierenden Ver- kehrstage|Trassen können über den gesamten Verkehrszeitraum oder für einen Zeitabschnitt oder an einzelnen Verkehrsta- gen über den gesamten Laufweg oder nur auf einem Teil- abschnitt der Trasse storniert werden (Geschäftsvorfall „netzausgelöste Stornierung“). Der in der Nachricht ange- gebene Kalender bezieht sich auf den in StartOfSection an- gegebenen TLP. RV-Kapazitäten können nur für vollstän- dige, in der Zukunft liegende Fahrplanjahre gesamthaft storniert werden.|
|I....InterruptionInformation|1|Unterbrechungsinformationen bei Nichtverfügbarkeit|Siehe Kapitel 3.13|
|I....FreeTextField|0..6|Frei definierbarer Text|Durch max. 6 Wiederholungen kann die Textlänge variiert werden; das Freitextfeld darf nur Angaben enthalten, die nichtin einem definierten Attribut (Strukturelement) der Nachricht angegeben werden können. Ggf. wird hier durch DB InfraGO zusätzlich eine Begründung für die netzausge- löste Stornierung der Trasse bzw. der beabsichtigten Über- gabe eines alternativen Angebots angegeben.|
Tabelle 7: PathNotAvailableMessage Hauptstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 31
DB Intern / DB internal
##### **2.2.7 ReceiptConfirmationMessage**
Gemäß der TAF-TSI/TAP-TSI-Dokumentation erfolgt bei einem erfolgreichen Empfang einer Nachricht vom Empfänger eine Bestätigung mittels einer „ReceiptConfirmationMessage“ an den Absender der Nachricht. Alle gesendeten Nachrichten seitens DB InfraGO sind nach erfolgreichem Eingang durch das empfangene EVU mit einer „ReceiptConfirmationMessage“ zu bestätigen. Umgekehrt bestätigt DB InfraGO ebenfalls immer den erfolgreichen Empfang einer nachricht gegenüber dem absendenden EVU.
DB InfraGO sendet eine „ReceiptConfirmationMessage“ immer nach dem erfolgreichen Empfang folgender Nachrichten:
- PathRequestMessage
- PathConfirmedMessage
- PathDetailsRefusedMessage
- PathCanceledMessage
- ObjectInfoMessage
- UpdateLinkMessage
In der Gegenrichtung erwartet DB InfraGO vom empfangenden EVU eine „ReceiptConfirmationMessage“ immer nach dem erfolgreichen Empfang folgender Nachrichten:
- PathDetailsMessage,
- PathNotAvailableMessage
- ObjectInfoMessage
- UpdateLinkMessage
In einer „ReceiptConfirmationMessage“ zu einer „PathRequestMessage“ für den Geschäftsvorfall Trassenerstanmeldung übermittelt DB InfraGO nur dann eine OTN, wenn diese durch das sendende EVU bereits mitgeteilt wurde. Bei Bestellungen ohne OTN sendet die DB InfraGo AG keine OTN. Die OTN wird in der Struktur „AffectedSection“ angegeben. Nur für diesen Zweck ist die Nutzung der Struktur „AffectedSection“ in der „ReceiptConfirmationMessage“ sinnvoll. In allen anderen o. g. Fällen bezieht sich die „ReceiptConfirmationMessage“ immer vollständig auf die zuvor empfangene Nachricht. Einschränkende Angaben hinsichtlich des Zug- oder Trassenverlaufs oder der Verkehrstage sind weder sinnvoll noch zulässig. Die Struktur „AffectedSection“ ist in diesen Fällen nicht zu befüllen und wegzulassen.
Weitere Informationen zu den Strukturen „MessageHeader“, „Identifiers“, „TypeOfRequest“, TypeOfInformation“ und „AffectedSection“ sind den jeweiligen Unterkapiteln zu Kapitel 3 zu entnehmen.
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 32
DB Intern / DB internal
Abbildung 7 ReceiptConfirmationMessage Struktur
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung /** **Name bzw. Wert des Parameters in NetworkSpecificPara-** **meter**|**Bemerkungen / Regeln**|
|---|---|---|---|
|ReceiptConfirmationMessage|1|Die Nachricht wird nach erfolgreichem Empfang einer Nachricht vom Empfänger an den Absender der Nachricht gesendet.|Die Nachricht ist auch dann zu senden, wenn die Nachrichtenabfolge eine quali- fizierte Antwort des Empfängers auf die empfangene Nachricht vorsieht.|
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....Identifiers|0..1|Eindeutige Identifizierung der empfangenen Nachricht.|Alle Identifier aus der empfangenen Nachricht werden unverändert übernom- men|
|I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase|Übernahme der PlannedTransportIdentifiers aus der empfangenen Nachricht|
|I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eige- nen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Elemente.|
|I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase||
|I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportI- dentifiers, sofern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....TypeOfRequest|0..1|Typ der Nachricht (Basisprozess)|Der Wert in der vorab vom EVU bzw. EIU gesendeten Nachricht wird unverän- dert übernommen (sofern angegeben)|
|I....TypeOfInformation|0..1|Typ der Information|Der Wert in der vorab vom EVU bzw. EIU gesendeten Nachricht wird unverän- dert übernommen (sofern angegeben)|
|I....AffectedSection|0..1|Enthält den in der empfangenen Nachricht angegebenen Start- und Zielbf. und deren Verkehrszeitregelung|Die Struktur wird nur in der Antwort auf eine erfolgreich übernommene „Path- RequestMessage“ für den Geschäftsvorfall Trassenerstanmeldung zur Angabe der OTN genutzt. In allen anderen Fällen wird die Struktur nicht befüllt und weg- gelassen.|
|I....I....StartOfSection|1|Erster Zuglaufpunkt (ZLP) aus der empfangenen Nachricht|Unveränderte Übernahme der analogen Informationen entweder aus der ersten PlannedJourneyLocation der Struktur „PathInformation“ oder aus dem Element „StartOfSection“ der Struktur AffectedSection in der vorab empfangenen Nach- richt|
|I....I....I....CountryCodeISO|1|CountryCode des LocationPrimaryCodes|Gemäß ISO 3166|
|I....I....I....LocationPrimaryCode|1|LocationPrimaryCode||
|I....I....I....PrimaryLocationName|0..1|Name des ZLP/TLP||
|I....I....I....LocationSubsidiaryIdentification|0..1|LocationSubsidiaryIdentifikation||
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 33
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung /** **Name bzw. Wert des Parameters in NetworkSpecificPara-** **meter**|**Bemerkungen / Regeln**|
|---|---|---|---|
|I....I....I....BookedLocationDateTime|0..1|Angabe der Abfahrt-/Durchfahrtszeit mit Tagesdatum|Angabe wird nur in betrieblichen Meldungen der betrieblichen Phase bei Nut- zung von Tagesobjekten der Zugtrasse verwendet.|
|I....I....I....BookedLocationTime|0..1|Angabe der Abfahrt-/Durchfahrtszeit|Angabe wird nur in Meldungen des Planungsprozesses mit einem Bezug auf das Kalenderobjekt (PlannedCalendar) der Zugtrasse verwendet. Die Angabe ist im- mer dann zu befüllen, wenn der als StartOfSection ausgewählte ZLP/TLP im Zug- lauf bzw. in der Zugtrasse mehrfach vorkommt.|
|I....I....EndOfSection|1|Letzter Zuglaufpunkt (ZLP) aus der empfangenen Nachricht|Unveränderte Übernahme der analogen Informationen entweder aus der letz- ten PlannedJourneyLocation der Struktur „PathInformation“ oder aus dem Ele- ment „EndOfSection“ der Struktur AffectedSection in der vorab empfangenen Nachricht|
|I....I....I....CountryCodeISO|1|CountryCode des LocationPrimaryCodes|Gemäß ISO 3166|
|I....I....I....LocationPrimaryCode|1|LocationPrimaryCode||
|I....I....I....PrimaryLocationName|0..1|Name des ZLP/TLP||
|I....I....I....LocationSubsidiaryIdentification|0..1|LocationSubsidiaryIdentifikation||
|I....I....I....BookedLocationDateTime|0..1|Angabe der Ankunfts-/Durchfahrtszeit mit Tagesdatum|Angabe wird nur in betrieblichen Meldungen der betrieblichen Phase bei Nut- zung von Tagesobjekten der Zugtrasse verwendet.|
|I....I....I....BookedLocationTime|0..1|Angabe der Ankunfts-/Durchfahrtszeit|Angabe wird nur in Meldung des Planungsprozesses mit einem Bezug auf das Ka- lenderobjekt (PlannedCalendar) der Zugtrasse verwendet. Die Angabe ist immer dann zu befüllen, wenn der als EndOfSection ausgewählte ZLP/TLP im Zuglauf bzw. in der Zugtrasse mehrfach vorkommt.|
|I....I....OperationalTrainNumber|0..1|Zugnummer (OTN) aus der vorab vom EVU gesendeten Nachricht|Der erste angegebene Wert für „OperationalTrainNumber“ in der Struktur „Pa- thInformation“ in „PlannedJourneyLocation“ in der vorab vom EVU/EIU gesen- deten Nachricht „PathRequestMessage“ wird unverändert übernommen, sofern eine Angabe durch das EVU erfolgte.|
|I....I....PlannedCalendar|1|Kalender der PathInformation aus der vorab vom EVU gesendeten Nachricht|Unveränderte Übernahme des PlannedCalendar der Struktur „PathInformation“ aus der vorab vom EVU/EIU gesendeten Nachricht|
||….AffectedLocation|0..1|Enthält die betroffene Betriebsstelle|Wird bei der DB InfraGO nicht verwendet|
||….|….Location|1|||
|I....I....I....CountryCodeISO|1|CountryCode des LocationPrimaryCodes|Gemäß ISO 3166|
|I....I....I....LocationPrimaryCode|1|LocationPrimaryCode||
|I....I....I....PrimaryLocationName|0..1|Name des ZLP/TLP||
|I....I....I....LocationSubsidiaryIdentification|0..1|LocationSubsidiaryIdentifikation||
||….|….LocationDateTime||Angabe der Ankunfts-/Durchfahrtszeit mit Tagesdatum||
|I....I....OperationalTrainNumber||Zugnummer (OTN) aus der vorab vom EVU gesendeten Nachricht||
||….Remarks|0..1|Freitextfeld|Wird bei der DB InfraGO nicht verwendet|
||InternalReferenceIdentifier|0..1|Angabe einer IT Referenz zur internen Weiterleitung|Wird bei der DB InfraGO nicht verwendet|
|I....RelatedReference|1|Identifikation der Nachricht, auf welche sich diese quittierende Nachricht bezieht.||
|I....I....RelatedType|1|MessageType der referenzierten Nachricht des EVU oder EIU|Unveränderte Übernahme des MessageType aus der vorab vom EVU oder EIU gesendeten Nachricht|
|I....I.... RelatedIdentifier|1|MessageIdentifier der referenzierten Nachricht des EVU oder EIU|Unveränderte Übernahme des MessageIdentifiers der vorab vom EVU oder EIU gesendeten Nachricht|
|I....I.... RelatedMessageDateTime|1|MessageDateTime der referenzierten Nachricht des EVU oder EIU|Unveränderte Übernahme der MessageDateTime aus der vorab vom EVU oder EIU gesendeten Nachricht|
|I....I.... RelatedSenderReference|0..1|Referenzdaten des absendenden Systems|In dem Feld kann das originäre System des Absenders, welches Auslöser der Nachricht ist, angegeben werden, z. B. dann, wenn ein weiteres System als Zwi- schensystem verwendet wurde (z. B: PCS als Broker)|
Tabelle 8: ReceiptConfirmationMessage Struktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 34
DB Intern / DB internal
##### **2.2.8 ErrorMessage**
Die Nachricht wird vom Empfänger einer Nachricht an den Absender der Nachricht übermittelt, wenn eine vorab empfangene Nachricht vom Empfänger nicht verarbeitet werden kann. Hierbei kann es sich um erkannte Fehler bei der automatischen fachlichen / technischen Eingangsprüfung oder um technische Probleme handeln.
Die Nachricht wird von DB InfraGO vor allem zur Ausführung des Geschäftsvorfalls „Zurückweisung“ verwendet. Sie enthält die erkannten Fehler und übermittelt unter Verwendung von Kodierungen detaillierte Informationen zu den Fehlern und Hinweise für eine erforderliche Korrektur. Im Nachgang kann das EVU die Nachricht mit korrigierten Angaben und gleichem Identifier, MessageStatus und TypeOfRequest noch einmal schicken.
In den meisten Fällen wird der laufende Prozess nicht abgebrochen (außer bei Anwendung der Nachricht für den Geschäftsvorfall „Zurückweisung“. Der Empfänger der ErrorMessage muss jedoch die fehlerhafte Nachricht korrigieren und erneut senden, damit der Prozess fortgesetzt werden kann. In bestimmten Fällen wird jedoch eine mit einer ErrorMessage zurückgewiesene Message als nicht empfangen betrachtet bzw. der laufende Prozess ggf. beendet. In diesem Fall kann der Prozess durch erneutes Senden der korrigierten Nachricht ggf. unter Verwendung eines neuen Identifiers neu begonnen werden. Detaillierte Aussagen dazu können aus den Erläuterungen zu den betreffenden Nachrichten bzw. der Tabelle 2 des Hauptdokuments entnommen werden.
Weitere Informationen zu den Strukturen „MessageHeader“, „MessageStatus“, „AdministrativeContactInformation“ und „Identifiers“ sind den jeweiligen Unterkapiteln zu Kapitel 3 zu entnehmen.
Abbildung 8 ErrorMessage Struktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 35
DB Intern / DB internal
|**Strukturelement**|**Vorkom-** **men**|**Beschreibung**|**Bemerkungen / Regeln**|
|---|---|---|---|
|ErrorMessage|1|Wird von DB InfraGO übermittelt, wenn eine vorab vom EVU gesendete Nachricht bei DB InfraGO nicht verarbeitet werden kann. Hierbei kann es sich um erkannte Fehler bei der automatischen fachlichen und technischen Ein- gangsprüfung oder um technische Probleme handeln.|Die Nachricht enthält detaillierte Informationen zum Feh- ler und Hinweise über eine erforderliche Korrektur.|
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Sender bereit gestellt|Ausprägungen: 1 = creation|
|I....AdministrativeContactInformation|1|Kontaktinformationen des Senders (hier DB InfraGO)||
|I....ErrorCauseReference|0..1|Referenziert die vorab empfangenen Nachricht, die den Fehler verursacht hat||
|I....I....MessageReference|1|Identifiziert die vorab empfangenen Nachricht|Unveränderte Übernahme der Struktur „MessageRefe- rence“ des „MessageHeader“ aus der vorab vom EVU ge- sendeten Nachricht|
|I....I....MessageSenderReference|0..1|Referenzdaten des absendenden Systems zu der zuvor empfangenen Nachricht|Kann angegeben werden, wenn ein weiteres System als Zwischensystem verwendet wurde, z. B: PCS als Broker ge- nutzt wurde.|
||….Error|1..N|Auflistung von erkannten Fehlern||
|I....I....TagReference|0..1|Name desjenigen Elements der Original-Nachricht, welches den Fehler verursacht hat.||
|I....I….TypeOfError|1|Typ des Fehlers|1 = FUNCTIONAL 2 = TECHNICAL 0 = BOTH|
|I....I….Severity|1|Schweregrad des Fehlers|1 = WARNING 2 = ERROR DB InfraGO verwendet vorerst nur den Schweregrad 2.|
|I....I….ErrorCode|1|Fehler-Code|1. Zwischen 5000 und 6000 = Standard-Werte, zentral ver- waltet 2. Größer als 6000 = national vereinbart (Anlage 9)|
|I....I….FreeTextField|1|Frei definierbarer Text|Das Freitextfeld darf nur Angaben enthalten, dienichtin einem definierten Attribut (Strukturelement) der Nach- richt angegeben werden können.|
|I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase|Unveränderte Übernahme der Identifier aus der vorab vom EVU gesendeten Nachricht|
|I....TransportOperationalIdentifiers|0..N|Identifiers des EIU in der operativen Phase|Wird in einer ErrorMessage als Reaktion auf Messages der Planungsphase nicht angewendet.|
Tabelle 9: ErrorMessage Struktur Beschreibung
##### **2.2.9 ObjectInfoMessage**
Die Nachricht kann sowohl vom EVU als auch von DB InfraGO gesendet werden und dient dem Austausch von Informationen zu bestehenden Objekten. In der Planungsphase wird die ObjectInfoMessage für den Austausch von Informationen zu einem CaseReferenceObjekt und für den Route-Updateprozess genutzt. Für Änderungen an gebuchten Zugtrassen ist ausschließlich der Änderungsprozess zu nutzen (siehe Hauptdokument Kap. 5.3.15).
Die Strukturen TrainInformationExtended bzw. PathInformationExtended ermöglichen die Angabe von Detailinformationen zu mehreren Objekten. Damit ist es möglich mit einer Anfrage z. B. zu einer TrainFamily (Angabe der ReferenceTRID im Element Identifier) alle aktuell vorhandenen Route-Objekte, PathRequest-Objekte und die verlinkten Trassen in der Antwort bereitzustellen.
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 36
DB Intern / DB internal
Abbildung 9 ObjectInfoMessage Struktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 37
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung /** **Name bzw. Wert des Parameters in NetworkSpecificPara-** **meter**|**Bemerkungen / Regeln**|
|---|---|---|---|
|ObjectInfoMessage|1|Message zur Anfrage zur Übermittlung von Informationen zu bestehenden Objekten, deren Übermittlung selbst und zur Aktualisierung von Inhalten von Objekten||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation, 2=modification, 3=deletion|
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Identifier|1|Eindeutiger Identifier des Objektes, zu welchem Informationen angefordert bzw. ausgetauscht werden.|Bei Angabe einer RouteID, PathRequestID oder PathID ist zusätzlich die referen- zierende ReferenceTRID anzugeben.|
|I....ReferenceTRID|0..1|ReferenceTRID des ReferenceTrains, auf welchen sich die in der Nachricht enthalte- nen Objekte beziehen.||
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....ObjectInfoType|1|Typ der ObjectInfoMessage|Angabe des Nutzungszwecks|
|I....I....Code|1|Codierung des Nutzungszweckes|R = request info about object; I = Information about object; U = Update information on object (Verwendung in der Planungsphase nur für Update der Objekte CaseReference und Route) N = information about a new object, O = request about object and linked objects|
|I....CoordinatingIM|0..1|CompanyCode des federführenden EIU|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16"Codelisten" 3. Die Information kann bei interoperablen Zügen angegeben werden, sofern die beteiligten EIU ein federführendes EIU benennen.|
|I....LeadRU|0..1|CompanyCode des federführenden bzw. koordinierenden EVU; muss nicht identisch sein mit dem Besteller/Vertragspartner (ResponsibleApplicant) oder mit dem durch- führenden EVU (ResponsibleRU); Angabe ist nur bei interoperablen Zügen verpflich- tend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungsphase übernimmt.|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfRequest|0..1|Typ der Nachricht (Basisprozess)|Wird nicht verwendet|
|I....ProcessType|0..1|Kodierte Angabe des Prozesstyps. Mit dieser Angabe kann der mit TypeOfRequest angegebene Prozess detaillierter spezifiziert werden.|Siehe Kapitel 3.16"Codelisten"|
|I....TypeOfInformation|0..1|Typ der Information|Wird nicht verwendet|
|I....TrainInformationExtended|0..N|Zusammenfassung von TrainInformationen eines oder mehrerer Objekte, die durch die Anfrage oder Antwort betroffen sind|Struktur dient der Gruppierung, sofern mehrfach Angaben zu Routen oder Path- Requests in der Message übermittelt werden sollen.|
|I....I....Identifiers|1|Eindeutige Identifizierung eines oder mehrerer Objekte, die durch die Anfrage oder Antwort betroffen sind|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRequestID, CaseReferenceID|
|I....I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase|Angabe von ReferenceTRID und RouteID und ggf. CaseReferenceID.|
|I....I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eige- nen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Elemente.|
|I....I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Angabe von ID anderer Objekte, die mitberücksichtigt werden sollen oder im Kontext zu bearbeiten sind bzw. auf die referenziert wird (z. B. geänderte Trasse).|
|I....I....I….I....ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportI- dentifiers, sofern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....I....TrainInformation|1|TrainInformation eines PathRequests, der durch die Anfrage oder Antwort betroffen ist||
|I....I....I....PlannedJourneyLocation|2..N|Zuglaufpunkte des Zuges||
|I....I....I....PlannedCalendar|1|Verkehrstageregelung des Zuges, gültig für den gesamten Zuglauf||
|I....I....I....PathPlanningReferenceLocation|1|Referenzbetriebsstelle; Laufpunkt des Zuges, ab welchem die Konstruktion beginnen soll||
|I....I....PathInformationExtended|0..N|Zusammenfassung von PathInformationen eines oder mehrerer PathRequest-Ob- jekte, die durch die Anfrage oder Antwort betroffen sind|Struktur dient der Gruppierung, sofern Angaben zu mehreren PathRequests in der Message übermittelt werden sollen.|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 38
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung /** **Name bzw. Wert des Parameters in NetworkSpecificPara-** **meter**|**Bemerkungen / Regeln**|
|---|---|---|---|
|I....I....I....Identifiers|1|Eindeutige Identifizierung eines oder mehrerer Objekte, die durch die Anfrage oder Antwort betroffen sind|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRequestID, CaseReferenceID|
|I....I....I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase|Angabe von ReferenceTRID, RouteID, PathRequestID (alle verpflichtend) und ggf. CaseReferenceID.|
|I....I....I....I....komplexe Struktur ohne Bezeich- nung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eige- nen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Elemente.|
|I....I....I....I....I....RelatedPlannedTransportIdentifi- ers|1|Bezug auf andere Identifiers in der Planungsphase|Angabe von ID anderer Objekte, die mitberücksichtigt werden sollen oder im Kontext zu bearbeiten sind bzw. auf die referenziert wird (z. B. geänderte Trasse).|
|I....I....I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportI- dentifiers, sofern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....I....I....PathInformation|1|PathInformation eines PathRequest-Objekts, das durch die Anfrage oder Antwort be- troffen ist||
|I....I....I....I....PlannedJourneyLocation|2..N|Zuglaufpunkte der Fahrlage||
|I....I....I....I....PlannedCalendar|1|Verkehrstageregelung des PathRequests||
|I....I....I....I....RequestedCalendar|0..1|Bleibt leer||
|I....PathInformationExtended|0..N|Zusammenfassung von PathInformationen eines oder mehrerer Objekte Path, die durch die Anfrage oder Antwort betroffen sind|Struktur dient der Gruppierung, sofern mehrere Paths in der Message übermit- telt werden sollen.|
|I....I....Identifiers|0..1|Eindeutige Identifizierung eines oder mehrerer Objekte, die durch die Anfrage oder Antwort betroffen sind|Siehe Kapitel 3.4 "Identifiers" Mögliche ID: ReferenceTRID, RouteID, PathID, PathRequestID, CaseReferenceID|
|I....I....I....PlannedTransportIdentifiers|1..N|Identifiers in der Planungsphase|Angabe der PathID|
|I....I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eige- nen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Elemente.|
|I....I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase|Angabe von ID anderer Objekte, die mitberücksichtigt werden sollen oder im Kontext zu bearbeiten sind bzw. auf die referenziert wird (z. B. geänderte Trasse).|
|I....I....I….I....ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportI- dentifiers, sofern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....I....PathInformation|1|PathInformation eines Paths, der durch die Anfrage oder Antwort betroffen ist|Wird nur angegeben, wenn durch die Antwort Angaben zu einem Objekt erfol- gen bzw. zugeordnet werden können.|
|I....I....I....PlannedJourneyLocation|2..N|Zugtrassenlaufpunkte||
|I....I....I....PlannedCalendar|1|Verkehrstageregelung des Paths||
|I....I....I....RequestedCalendar|0..1|Unveränderte Wiederholung der Struktur PlannedCalendar in der PathInformation der zu einem Path gehörenden PathRequestMessage||
|I....FreeTextField|0..6|Frei definierbarer Text|Zur Übermittlung ergänzender, unstrukturierter Informationen, für die kein defi- niertes Element vorhanden ist und genutzt werden kann. Durch max. 6 Wieder- holungen kann die Textlänge variiert werden.|
|I....Parameters|0..N|Nationale spezifische Parameter (Attribute, Felder) des EIU|Wird ausschließlich zur Übermittlung der Parameter eines CaseReference-Objek- tes genutzt, sofern dieses Objekt Gegenstand der Antwort auf eine Anfrage zur Informationsbereitstellung ist.|
|I....I....Name|1|Name des Parameters|Generischer Name des Parameters|
|I....I....Value|1|Wert des Parameters|Wert des Parameters|
Tabelle 10 ObjectInfoMessage Struktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 39
DB Intern / DB internal
##### **2.2.10 UpdateLinkMessage**
Die UpdateLinkMessage dient primär der Änderung der Verlinkung zwischen einem Objekt Zug (Train) einer Zugfamilie, referenziert durch die ReferenceTRID, und einer gebuchten Trasse (Path). Diese Option wird jedoch in der Kommunikation zwischen EVU und DB InfraGO in der Planungsphase nicht genutzt. Änderungen der Verlinkung zwischen den Objekten Zug und Zugtrasse erfolgen ausschließlich unter Nutzung der für den Basisprozess „Modification“ definierten Nachrichtenabfolgen. DB InfraGO wird in der Planungsphase ausschließlich die Reportfunktion zur Nutzung anbieten, die der Abfrage der aktuellen Verlinkungen zwischen Zugobjekten einer Train-Family (ReferenceTRID) und deren gebuchten Trassen (Paths) dient.
Abbildung 10 UpdateLinkMessage Struktur
|**Strukturelement** |**Vor-** **kom-** **men** |**Beschreibung /** **Name bzw. Wert des Parameters in NetworkSpecificPara-** **meter**|**Bemerkungen / Regeln**|
|---|---|---|---|
|UpdateLinkMessage|1|||
|I....MessageHeader|1|Für alle Nachrichten erforderlich||
|I....MessageStatus|1|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt|1. Siehe Kapitel 3.5 "Attribute auf Messageebene" 2. Ausprägungen: 1=creation, 2=modification, 3=deletion|
|I....AdministrativeContactInformation|1|Kontaktinformationen des Absenders.||
|I....Operation|1..N|Beschreibung der auszuführenden Operation||
|I....I....Type|1|Codierung der Operation; ist in der xsd als Attribut des Elementes „Operation“ ange- geben.|Mögliche Ausprägungen: - break the link (keine Nutzung in der Planungsphase), - establish the link (keine Nutzung in der Planungsphase, - information (report) about the link|
|I....I....Identifiers|1..2|Identifiers in der Planungsphase||
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 40
DB Intern / DB internal
|**Strukturelement**|**Vor-** **kom-** **men**|**Beschreibung /** **Name bzw. Wert des Parameters in NetworkSpecificPara-** **meter**|**Bemerkungen / Regeln**|
|---|---|---|---|
|I....I....I....PlannedTransportIdentifiers|1..N|Angabe der Identifier der betroffenen Objekte Zug und Trasse|Identifier eines oder mehrerer durch die Nachricht betroffenen Objekte, für wel- che die Verlinkung geändert oder neu etabliert werden soll, d. h. es sind die zu- treffenden ReferenceTRID, RouteID und PathID anzugeben.|
|I....I....I....komplexe Struktur ohne Bezeichnung|0..N|komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eige- nen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Elemente.|
|I....I....I....I....RelatedPlannedTransportIdentifiers|1|Bezug auf andere Identifiers in der Planungsphase||
|I....I....I....I….ReasonOfReference|0..1|Angabe eines Grundes für die Verwendung des Elements RelatedPlannedTransportI- dentifiers, sofern zutreffend.|Siehe Kapitel 3.16"Codelisten"|
|I....ReferenceTrainIDSubCalendar|0..1|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.||
|I....I....Action|0..1|Angabe der auszuführenden Aktion; ist in der xsd als Attribut des Elementes „Action“ angegeben.||
|I....I....I....Type|1|Kodierung der auszuführenden Aktion|TS = Train shifting (keine Nutzung in der Planungsphase) TC = Train cancellation (keine Nutzung in der Planungsphase) COT = Change of train (keine Nutzung in der Planungsphase) LR = Link report|
|I....I....Status|0..1|Angabe des Bearbeitungsstatus der UpdateLinkMessage¸; ist in der xsd als Attribut des Elementes „Status“ angegeben.||
|I....I....I....Type|1|Kodierung des Status; diese dienen dazu, die fachlichen Fälle zu benennen, in denen eine Bestätigung der UpdateLinkMessage erforderlich ist.|P = proposed R = requested C = confirmed LNC = link not confirmed LR = Link refused E = exists|
|I....I....Procedure|0..1|Ergänzende Angabe zur auszuführenden Operation.|NP = New path EP = Existing path PK = Path kept PNK = Path not kept TC = Train cancelled TNC = Train not cancelled|
|I....I....TrainInformation|0..1|Zuginformationen des EVU über den gesamten Zuglauf|TrainInformation (Route) des durch die ReferenceTRID referenzierten Zuges|
|I....I....I....PlannedJourneyLocation|2..N|Zuglaufpunkte||
|I....I....I....PlannedCalendar|1|Verkehrstageregelung des Zuges, gültig für den gesamten Zuglauf||
|I....I....I....PathPlanningReferenceLocation|1|Referenzbetriebsstelle; Laufpunkt des Zuges, ab welchem die Konstruktion beginnen soll||
|I....I....PathInformation|0..1|Zugtrassendaten|PathInformation der durch die PathID referenzierten Zugtrasse|
|I....I....I....PlannedJourneyLocation|2..N|Zugtrassenlaufpunkte||
|I....I....I....PlannedCalendar|1|Kalender; gibt den Verkehrszeitraum und die Verkehrstage der Zugtrasse an. In Ab- hängigkeit vom Wert im Attribut OffsetToReference können sich die Verkehrstage im Kalender der PathInformation im Vergleich zu den Verkehrstagen des Refe- renceTrains oder der Route um die Anzahl der Tageswechsel verschieben.|Gilt abfahrtsbezogen am Startbahnhof der Zugtrasse|
|I....I....I....RequestedCalendar|0..1|Nur für das Objekt Path: Unveränderte Wiederholung der Struktur PlannedCalendar in der PathInformation der zu einem Path gehörenden PathRequestMessage||
|I....Parameters|0..N|Nationale spezifische Parameter (Attribute, Felder) des EIU|Aktuell existieren keine definierten NSP|
|I....I....Name|1|Name des Parameters|Generischer Name des Parameters|
|I....I....Value|1|Wert des Parameters|Wert des Parameters|
|I....FreeTextField|0..6|Frei definierbarer Text|Zur Übermittlung ergänzender, unstrukturierter Informationen, für die kein defi- niertes Element vorhanden ist und genutzt werden kann. Durch max. 6 Wieder- holungen kann die Textlänge variiert werden|
Tabelle 11 UpdateLinkMessage Struktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 41
DB Intern / DB internal
## **3 Datenfeldbeschreibungen**
- In diesem Kapitel werden alle Datenfelder der Haupt- und Unterstrukturen der in der Planungsphase genutzten und in Kapitel 2.2 aufgeführten Nachrichten detailliert beschrieben.
- Da die TAF-TSI/TAP-TSI-Strukturen verschachtelt sind und teilweise Wiederholungen aufweisen, werden die Haupt- und Unterstrukturen und deren Datenfelder in getrennten Kapiteln behandelt.
- Um die Unterstrukturen den jeweiligen Nachrichtentypen zuordnen zu können, sind im Kapitel 2.2 „Hauptstrukturen“ diese Unterstrukturen in der Darstellung der Hauptstruktur der Nachricht integriert.
- In diesem Kapitel werden folgende Strukturen inklusive der wiederum darin enthaltenen Unterstrukturen samt Datenfelder erläutert:
- MessageHeader
- AdministrativeContactInformation
- Identifiers
- Attribute auf Messageebene
- TrainInformation
- PathInformation
- PlannedJourneyLocation
- AffectedSection
- InterruptInformation
- NetworkSpecificParameter
- Codelisten
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 42
DB Intern / DB internal
##### **3.1 Spalten der Datenfelder-Tabellen**
|**Spalte**|**Bedeutung**|
|---|---|
|Struktur|Struktur der Information ab oberster Ebene der Struktur inklusive aller Unterstrukturen. Die senkrechten Striche symbolisieren dabei die Anordnung jeweils eine Ebene tiefer. Striche auf gleicher Höhe bedeuten die Zuordnung der Unterstruktur/des Attributs zur gleichen Ebene|
|Strukturelement|Strukturelement, zu dem die als Attribut deklarierte Information gehört|
|Attribut|Attribut|
|Beschreibung|Beschreibung des Attributs|
|Bemerkungen / Regeln|Bemerkungen und Regeln der DB InfraGO für das Attribut, ggf. präzisierend zu den Regeln der TAF-TSI/TAP-TSI|
|Vorkommen|Vorkommen des Attributs bzw. einer Unterstruktur in der (übergeordneten) Struktur, i. d. R. gemäß XSD der TAF-TSI/TAP-TSI (außer Strukturen „NetworkSpecificParameter“); davon für DB InfraGO definierte Abweichungen sind in der Spalte „Bemerkungen/Regeln“ aufgeführt. 0..1 = Kannfeld 1 = Mussfeld 0..N = Wiederholstruktur (optional) 1..N = Wiederholstruktur (mindestens eine Ausprägung der Struktur) _<_zahl>. N = Wiederholstruktur (optional), mindestens durch_<_zahl> angegebene Anzahl von Ausprägungen;_<_zahl> stellt dabei den Index (lfd. Nr.) der Ausprägung dar|
|Typ|Datentyp des Attributs gemäß XML Schema (https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/datatypes.html#built-in-primitive-datatypes)|
|Länge|Länge des Attributs|
|MinWert|Minimalwert des Attributs|
|MaxWert|Maximalwert des Attributs|
|Ausprägung|Die für das betreffende Attribut gültigen Ausprägungen (verschiedene Darstellungen) Als Werteauflistung Als Verweis auf das Kapitel 3.16„Codelisten“ Als Verweis auf die Stammdaten (siehe dazu auch Kapitel 4)|
|Muster|Muster (Pattern) zur Bildung des Attributwerts bzw. Beispiel|
|EVU➔EIU|Auf**„**Message“-Ebene dokumentieren die Spalten „EVU➔EIU“ und „EIU➔EVU“, für welche Nachrichtenrichtung („Von EVU nach InfraGO“ bzw. „Von InfraGO nach EVU“) das jeweilige Attribut genutzt werden muss/kann|
|EIU➔EVU|Auf „Message“-Ebene dokumentieren die Spalten „EVU➔EIU“ und „EIU➔EVU“, für welche Nachrichtenrichtung („Von EVU nach InfraGO“ bzw. „Von InfraGO nach EVU“) das jeweilige Attribut genutzt werden muss/kann|
|Train / Path in PR|Auf „Location“-Ebene (Struktur „PlannedJourneyLocation“ und Unterstrukturen) dokumentiert diese Spalte, wie in der Message „**PathRequestMessage**“ (PR) in den Strukturen „TrainInforma- tion“ bzw. „PathInformation“ das jeweilige Attribut genutzt werden muss/kann|
|Path in PD|Auf „Location“-Ebene (Struktur „PlannedJourneyLocation“ und Unterstrukturen) dokumentiert diese Spalte, wie in der Message „**PathDetailsMessage**“ (PD) in der Struktur „PathInformation“ das jeweilige Attribut genutzt werden muss/kann.|
|Relevant|Sagt aus, ob das Attribut verwendet wird bzw. wie es genutzt werden kann/muss|
Tabelle 12 Spalten Datenfeldertabellen
Die Codierung der letzten fünf genannten Spalten („EVU → EIU“, „EIU → EVU“, „Train / Path in PR“, „Path in PD“ und „Relevant“) haben folgende Werte und Bedeutung:
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 43
DB Intern / DB internal
|M|Das Attribut muss vorhanden sein und einen gültigen Wert haben|
|---|---|
|M (Gn)|Hier wird eine Gruppe von Attributen zusammengefasst, von denen genau eine angegeben werden muss. Die Notation „Gn“ bedeutet: „G“ steht für „Gruppe“, „n“ ist eine laufende Nummer ab 1 und gruppiert die zusammengehörenden Attribute, aus denen der sendende Partner genau einen angeben muss (z.B.: G1). Gibt es mehrere Gruppen, haben diese dann die Qualifizierung G2, G3, usw.|
|bM|Hiermit wird ein Attribut ausgewiesen, das bedingt angegeben werden muss (Abhängigkeit von anderen Attributen). Die Bedingungen sind in den Bemerkungen / Regeln hinterlegt.|
|K|Das Attribut kann bei Bedarf genutzt werden|
|n/a|Das Attribut ist in der Kommunikation über die EVU-Schnittstelle des Bestellsystems der DB InfraGO nicht anwendbar bzw. wird nicht genutzt. Sofern es trotzdem über die EVU-Schnittstelle an DB InfraGO übergeben wird, wird es im Bestellsystem ignoriert.|
|Ja|Das Attribut oder der Wert oder die Kodierung kann/muss in der Kommunikation über die EVU-Schnittstelle des Bestellsystems der DB InfraGO je nach fachlichem Kontext angewendet oder genutzt werden.|
Tabelle 13 Übersicht verwendete Codierungen in Tabelle 12
Sowohl in der vom EVU an das EIU (DB InfraGO) gesendeten Nachricht „PathRequestMessage“ als auch in der vom EIU (DB InfraGO) an das EVU als Antwort darauf bereitgestellten Nachricht „PathDetailsMessage“ sind einige Strukturen und Attribute identisch. In bestimmten Fällen werden die Angaben unverändert zurückgegeben, in anderen Fällen haben die Angaben in den Attributen einen anderen Wert oder eine andere Ausprägung und auch eine andere fachliche Bedeutung. Sofern dies zutreffend ist, wird in der Spalte Bemerkungen/Regeln gesondert darauf hingewiesen. Bei der Übernahme der Daten in das EVU-System muss somit darauf geachtet werden, dass es sich in diesen Fällen eigentlich um zwei unterschiedliche Attribute handelt, die in Hin- bzw. Rückrichtung jeweils eine andere Bedeutung haben können.
##### **3.2 Struktur „MessageHeader“**
##### **3.2.1 Übersicht über die Struktur „MessageHeader“**
Diese Struktur identifiziert die Nachricht und ist für jede Nachricht (Message) erforderlich.
Abbildung 11 MessageHeader Struktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 44
DB Intern / DB internal
##### **3.2.2 Datenfelder der Struktur „MessageHeader“**
|**Struktur**|**Strukturelement**|**Attribut**|**Beschreibung**|**Bemerkungen / Regeln**|**Vor-** **kom-** **men** **Typ**|**Länge** **Min-** **Wert**|**Max-** **Wert** **Muster**|
|---|---|---|---|---|---|---|---|
|I....MessageHeader||MessageHeader|Für alle Nachrichten erforderlich||1|||
|I....I....MessageReference|MessageHeader|MessageReference|Identifiziert die Nachricht||1|||
|I....I....I....MessageType|MessageReference|MessageType|Typnummer der übermittelten Nachricht|Ausprägungen siehe Kapitel 3.16„Codelisten"|1 string|1-4||
|I....I....I....MessageTypeVersion|MessageReference|MessageTypeVersion|Version des Nachrichtentyps|Entspricht der Version der XSD (z.B.: [REDACTED]). Kann der Emp- fänger die angegebene Version nicht verarbeiten, erfolgt eine Zurückweisung (ErrorMessage).|1 string|25||
|I....I....I....MessageIdentifier|MessageReference|MessageIdentifier|Durch das sendende System zu generierende eindeutige ID der Nachricht|1. Wird vom absendenden System festgelegt 2. Sollte der UUID aus dem SOAP-Header entsprechen 3. Bei Nutzung eines Common Interface (CI) wird diese In- formation vom CI generiert. Die DB InfraGO nutzt eine Schnittstelle, die der Spezifikation des CI entspricht (siehe Anlage 2)|1 string|255|[a-fA-F0-9-]{1,255}|
|I....I....I....MessageDateTime|MessageReference|MessageDateTime|Durch das sendende System zu generierender Zeitstempel in lokaler Zeit|1. Wird von Absender festgelegt 2. Es belegt den Zeitpunkt, an dem die Nachricht verschickt wurde 3. Bei Nutzung des Common Interface (CI) wird diese Infor- mation vom CI generiert Die DB InfraGO nutzt eine Schnittstelle, die der Spezifikation des CI entspricht (siehe Anlage 2)|1 dateTime|||
|I....I....MessageRoutingID|MessageHeader|MessageRoutingID|Ergänzende Information für die korrekte Weiterleitung der Nachricht an das Zielsystem|z.B. um eine bestimmte Applikation zu adressieren; nur rele- vant für den jeweiligen Absender; Empfänger sendet in einer Antwort die Information unverändert zurück. Bisher ist im Rahmen ds ujBau Prozesses für die Kommunika- tion mit der KOMBau die „45“ reserviert. (s. Anlage 10)|0..1 integer|2 01|99|
|I....I....SenderReference|MessageHeader|SenderReference|Durch den Absender genutzte Referenz auf ein internes System|z. B. Dateiname oder Nachrichtenbezeichnung aus dem IT- System des Absenders|0..1 string|255||
|I....I....Sender|MessageHeader|Sender|Die CompanyCode des Absenders der Nachricht.|Zum Beispiel ist in der PathRequestMessage der Com- panyCode des Bestellers (ResponsibleApplicant) anzugeben. Siehe Kapitel 3.16"Codelisten"|1 string|4 0001|ZZZZ [0-9A-Z]{4}|
|I....I....I....CI_InstanceNumber|Sender|CI_InstanceNumber|Nummer der Common Interface Instanz des Absenders|1. In der XSD ist diese Information ein Attribut 2. Defaultwert ist "1" (auch bei Nichtnutzung des CI) 3. Bezüglich der Identifikation des IT-Verfahrens des EVU siehe Anlage 2|1 integer|2 1|99|
|I....I....MessageDateTimeCreated|MessageHeader|MessageDateTimeCrea- ted|Datum und Uhrzeit der Erstellung der Nachricht im originären System des Absenders (Erstellers) der Nachricht||0..1 dateTime|||
|I....I....Recipient|MessageHeader|Recipient|Die CompanyCode des Empfängers der Nachricht.|Siehe Kapitel 3.16"Codelisten"|1 string|4 0001|ZZZZ [0-9A-Z]{4}|
|I....I....I....CI_InstanceNumber|Recipient|CI_InstanceNumber|Nummer der Common Interface Instanz des Empfängers|1. In der XSD ist diese Information ein Attribut 2. Defaultwert ist "1" (auch bei Nichtnutzung des CI) 3. Bezüglich der Identifikation des IT-Verfahrens des EVU siehe Anlage 2|1 integer|2 1|99|
Tabelle 14 MessageHeader Datenfelder
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 45
DB Intern / DB internal
##### **3.3 Struktur „AdministrativeContactInformation“**
##### **3.3.1 Übersicht über die Struktur „AdministrativeContactInformation“**
##### Diese Struktur beinhaltet Kontaktinformationen des jeweiligen Absenders.
Für die Richtung EVU ➔ EIU beinhalten die Attribute Informationen zur Firma bzw. zum Ansprechpartner des die Nachricht absendenden EVU. Im Kontext dieses Dokuments ist das in der Planungsphase immer das bestellende EVU (ResponsibleApplicant)
Für die Richtung EIU ➔ EVU beinhalten die Attribute Informationen zum Ansprechpartner beim EIU (DB InfraGO).
Abbildung 12 AdministrativeContactInformation Struktur
##### **3.3.2 Datenfelder der Struktur „AdministrativeContactInformation“**
|**Struktur**|**Strukturelement**|**Attribut**|**Beschreibung**|**Bemerkungen / Regeln**|**Vor-** **kom-** **men** **Typ**|**Länge** **Min-** **Wert**|**Max-** **Wert** **Muster**|
|---|---|---|---|---|---|---|---|
|I....AdministrativeContactInformation||AdministrativeContactIn- formation|Kontaktinformationen des Absenders||1|||
|I....I....Name|AdministrativeContactInfor- mation|Name|EVU➔EIU: Name des Kunden EIU➔EVU: Name des Ansprechpartners|Muss immer angegeben werden|1 string|255||
|I....I....Address|AdministrativeContactInfor- mation|Address|Postadresse des Absenders|wird nicht verwendet|0..1 string|255||
|I....I....eMail|AdministrativeContactInfor- mation|eMail|EVU➔EIU: Email-Adresse des Kunden EIU➔EVU: Email-Adresse des Ansprechpartners|Muss in der Kommunikation mit DB InfraGO immer angege- ben werden. Das Format der E-Mail Adresse wird auf Gültig- keit geprüft.|0..1 string|70||
|I....I....PhoneNumber|AdministrativeContactInfor- mation|PhoneNumber|EVU➔EIU: Telefonnummer des Kunden EIU➔EVU: Telefonnummer des Ansprechpartners|Muss in der Kommunikation mit DB InfraGO immer angege- ben werden|0..1 string|70||
|I....I....FaxNumber|AdministrativeContactInfor- mation|FaxNumber|EVU➔EIU: Faxnummer des Kunden EIU➔EVU: Faxnummer des Ansprechpartners|Ist nur anzugeben, wenn eine Übermittlung von Unterlagen (z. B: Fplo) per Fax vorgesehen ist.|0..1 string|70||
|I....I....FreeTextField|AdministrativeContactInfor- mation|FreeTextField|Frei definierbarer Text||0..1 string|255||
Tabelle 15 AdministrativeContactInformation Datenfelder
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 46
DB Intern / DB internal
##### **3.4 Struktur „Identifiers“**
##### **3.4.1 Übersicht über die Struktur „Identifiers“**
Diese Struktur enthält eindeutige Identifizierungen von Objekten,
- die in der Nachricht selbst,
- die in der Nachricht, auf die sich die Nachricht bezieht oder
- die in Nachrichten, die bei der Bearbeitung berücksichtigt werden sollen
enthalten sind.
Abbildung 13 Identifiers Struktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 47
DB Intern / DB internal
Die aktuelle TAF-TSI/TAP-TSI-Regulierung fordert ab dem Endtermin für die europaweite Umsetzung die Nutzung der Identifier als Pflichtangabe, außer CaseReferenceID, die nur bei Vorliegen einer entsprechenden bilateralen Vereinbarung zur Nutzung von CaseReference-Objekten anzugeben ist. Die vorliegende Dokumentation beschreibt daher die Nutzung der Identifikatoren, soweit es für die EVU-Schnittstelle des Bestellsystems der DB InfraGO erforderlich ist. Die gültigen Identifier sind:
- ReferenceTRID
- Die ReferenceTRID identifiziert ein imaginäres Objekt ReferenceTrain, dem alle Züge einer Train-Family zugeordnet sind, und dessen Gültigkeit durch einen eigenen Kalender (ReferenceCalendar) definiert ist.
Der in den Nachrichten angegebene ReferenceTRIDSubCalendar stellt eine Teilmenge dieses Kalenders dar. Die ReferenceTRID wird ausschließlich vom EVU festgelegt und muss für je EVU (CompanyCode) und Fahrplanjahr ohne weitere ergänzende Angaben für sich eindeutig sein. Die ReferenceTRID hat als Variantennummer immer „00“ (Null Null), welche exklusiv für diesen Identifier reserviert ist.
Bei mehreren beteiligten EVU erfolgt die Festlegung i. d. R. durch das federführende EVU (Lead RU).
Sie bleibt über den gesamten Planungsprozess für den Zug bzw. die Züge der Train-Family und darüber hinaus auch im operativen Geschäft erhalten.
- TrainID
- Die TrainID identifiziert ein konkretes, durch das EVU definiertes Zugobjekt (Train).
Sie wird ausschließlich vom EVU festgelegt und muss je EVU (CompanyCode) und Fahrplanjahr ohne weitere ergänzende Angaben für sich eindeutig sein. Dem Zugobjekt sind ein oder mehrere Routen zugeordnet.
Bei mehreren beteiligten EVU erfolgt die Festlegung i. d. R. durch das federführende EVU (Lead RU).
- Die TrainID wird nur in den Systemen des EVU und im Datenaustausch mit anderen EVU verwendet, jedoch nicht zwischen EVU und EIU ausgetauscht. Für die TrainID darf die Variantennummer „00“ nicht verwendet werden.
- RouteID Die RouteID identifiziert ein Route-Objekt, welches vom EVU für einen Zug definiert wird.
Die Route beschreibt den globalen Gesamtzuglauf mit den Mindestangaben Start- und Zielbahnhof sowie möglichen Handover-points.
Die RouteID wird ausschließlich vom EVU festgelegt und muss für jedes EVU (CompanyCode) und Fahrplanjahr ohne weitere ergänzende Angaben für sich eindeutig sein.
Bei mehreren beteiligten EVU erfolgt die Festlegung i. d. R. durch das federführende EVU (Lead RU).
Sie bleibt über den gesamten Planungsprozess für den Zug und darüber hinaus auch im operativen Geschäft erhalten
- PathID Die PathID wird ausschließlich vom EIU festgelegt und muss für jedes EIU (CompanyCode) eindeutig sein
Sie wird beim Übersenden des Trassenangebots oder des Ergebnisses an das EVU übergeben.
- PathRequestID Die PathRequestID wird ausschließlich vom EVU festgelegt und muss für jedes EVU (CompanyCode) eindeutig sein.
Werden von mehreren an der Planung des Zuges beteiligten EVU eigene PathRequestMessages abgegeben, so vergibt jedes dieser EVU seine eigene PathRequestID.
- Sie bleibt von der erstmaligen Übersendung eines PathRequests bis zum Ende des jeweiligen Basisprozesses (Study, Request, Modification – siehe auch Kapitel 2.1) erhalten. Der jeweilige Basisprozess endet:
- in den Basisprozessen „Request“ und „Modification“ mit der Annahme oder Ablehnung eines übergebenen Angebots, mit der Abmeldung oder Zurückweisung des PathRequests (für die Anmeldung bzw. Änderung einer Trasse bzw. RV-Kapazität),
- im Basisprozess „Study“ für die Produkte „Fahrzeitberechnung“ und „Fahrplan- und Betriebsprogrammstudien“ mit der Übergabe eines Ergebnisses, mit der Abmeldung oder Zurückweisung des PathRequests (für die FZB bzw. FPS),
- Im Basisprozess PathStudy für das Produkt „Kurzfristige Fahrlagenberatung“ mit der Ablehnung des Ergebnisses bzw. mit der Umwandlung des Ergebnisses der Kurzfristigen Fahrlagenberatung in eine Trassenanmeldung, mit der Mitteilung, dass kein Ergebnis bereitgestellt werden kann, oder mit einer Zurückweisung des PathRequests (der Trassenstudienbestellung).
- CaseReferenceID Die CaseReferenceID kann sowohl vom EVU als auch vom EIU benutzt werden und muss eindeutig sein.
Die CaseReferenceID kann benutzt werden, um einen BusinessCase (Anwendungsfall) zu identifizieren, der z. B. mehrere PathRequests als zusammengehörig kennzeichnet.
Die CaseReferenceID kann für die Kennzeichnung mehrerer PathRequests genutzt werden, deren Abfolge von Aktionen gesamthaft gestartet, ausgeführt und beendet werden sollen. Zwischen den beteiligten EVU und EIU sind entsprechende Vereinbarungen zu treffen.
Die CaseReferenceID ist z. B: zur Kennzeichnung von Fahrlagen, die zu einer Fahrplan- oder Betriebsprogrammstudie oder zu einem Messprogramm gehören sollen, zu verwenden und anzugeben.
In der CaseReferenceID kann auch die DossierID des PathCoordinationSystems (PCS) abgebildet werden.
Die CaseReferenceID kann zur Übermittlung der Rahmenvertragsnummer einer RV-Kapazität genutzt werden
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 48
DB Intern / DB internal
##### TemporaryCapacityRestrictionID Die TemporaryCapacityRestrictionD wird ausschließlich vom EIU festgelegt und muss eindeutig sein.
Sie beschreibt eine Baumaßnahme aus der Umsetzung des Annex VII und wird hauptsächlich im Prouess ujBau nach Anlage 10 verwendet. Die Beschreibung der einzelnen Attribute ist in Anlage 10 aufgeführt.
Die Eindeutigkeit des Identifiers ergibt sich aus der Nutzung und Befüllung der Attribute , , , , .
Die Attribute sind wie folgt definiert:
- enthält den jeweiligen Objekttyp (ReferenceTrain (TR), Route (RO), Path (PA), PathRequest (PR) oder CaseReference (CR)).
- ist mit dem CompanyCode (siehe Kapitel 3.16"Codelisten") des Absenders zu füllen.
- bildet das Kernelement ab und ist vom Absender frei gestaltbar.
- bildet eine Variante zum Kernelement ab. Der Wert „00“ ist exklusiv für die Bildung von Gruppierungen, z. B. Train-Family (ReferenceTRID) vorgesehen. Die Variantennummer der PathID´s für alle während des Fahrplanbearbeitungsprozesses erstellten Trassen, RV-Kapazitäten bzw. Ergebnissen bestimmter Marktprodukte beginnt immer mit einem Buchstaben, die Variantennummer für operativ zugewiesene Trassen des Betriebs beginnt immer mit einer Ziffer.
- enthält das jeweilige Fahrplanjahr, dem das Objekt zugeordnet ist. Somit kann der gleiche Identifier für Folgejahre mit geändertem wiederverwendet werden.
- ist in der Planungsphase nicht zu verwenden, da es nur im Betrieb (bei der produktiven Durchführung der Zugfahrt) genutzt wird.
##### PlannedTransportIdentifiers
- In der Wiederholstruktur „PlannedTransportIdentifiers“ darf es die ObjectType TR, RO, PA, PR nur jeweils einmal geben. Der ObjectType CR kann mehrmals angegeben werden.
##### RelatedPlannedTransportIdentifiers und ReasonOfReference
- In der Wiederholstruktur „RelatedPlannedTransportIdentifiers“ können andere Objekte (Züge (Fahrlagen), Trassen oder Nachrichten) referenziert werden, die in Beziehung zum Zug in der Nachricht oder zur Nachricht selbst stehen. Es können mehrere Beziehungen definiert werden (z.B. CaseReferenceID’s mehrerer CaseReference Objekte, welche durch eine Trassenbestellung referenziert werden). Eine Begründung für die Angabe eines RelatedPlannedTransportIdentifiers kann durch Angabe eines Codes für das Element ReasonOfReference erfolgen. Sofern sich die Nutzung des Elements RelatedPlannedTransportIdentifiers nicht aus dem Kontext der Messageabfolge oder dem Nachrichtentyp ergibt, ist die Angabe einer Begründung erforderlich. Sofern mehrere RelatedPlannedTransportIdentifier angegeben werden, gilt der ReasonofReference immer nur für die jweils zuvor übergebene ID.
- Beispiele für Nutzungsmöglichkeiten:
- CaseReferenceID: Der PathRequest oder die PathDetailsMessage bezieht sich auf einen Geschäftsfall (CaseReference Objekt) mit der angegebenen CaseReferenceID, dem ggf. weitere Objekte (i. d. R. des gleichen Typs) zugeordnet sind. Das Objekt CaseReference enthält weitere detaillierte Informationen.
- ReferenceTRID: Der PathRequest bezieht sich auf einen oder mehrere einzelne Züge einer durch die ReferenceTrain-ID bezeichneten Train-Family, z. B. auf einen ähnlichen Zug in einem vorherigen Zeitabschnitt
- PathID: Der PathRequest bezieht sich auf einen oder mehrere andere Paths, die ersetzt werden oder als Vorlage dienen sollen. Die PathDetailsMessage ist eine von mehreren PathDetailsMessages zu einem PathRequest.
- PathRequestID: Der PathRequest bezieht sich auf einen anderen (z. B. früheren) PathRequest oder ist im Zusammenwirken mit anderen PathRequestMessages für den gleichen Zug oder andere Züge zu bearbeiten (z. B. Zug verkehrt DB InfraGO – fremde Infrastruktur – DB InfraGO; Y-Zugverbund bei Zugvereinigungen oder -trennungen; bei Abweichungen an einzelnen Verkehrstagen eines Zuges, aus denen sich die Notwendigkeit separater PathRequests ergibt)
- Für einige Folgegeschäftsvorfälle (z. B: Angebote zu einer Änderung nach Vertragsschluss oder nach einer netzausgelösten Änderung oder nach Stornierungen) ist eine konkrete Referenz auf ein bisher gültiges Objekt durch die Angabe dessen Identifier in der Struktur „RelatedPlannedTransportIdentifiers“ erforderlich. Detaillierte Angaben enthalten das Dokument [1] „Schnittstellendokumentation_EVU-Schnittstelle_Bestellsystem.pdf“ (insbesondere Kapitel 5) und
- Die Codeliste in dieser Anlage für das Element ReasonOfReference (siehe Kapitel 3.16)
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 49
DB Intern / DB internal
##### **3.4.2 Datenfelder der Struktur „Identifiers“**
|**Struktur**|**Strukturelement**|**Attribut**|**Beschreibung**|**Bemerkungen / Regeln**|**Vor-** **kom-** **men** **Typ**|**Länge** **Min-** **Wert**|**Max-** **Wert** **Muster**|
|---|---|---|---|---|---|---|---|
|I....Identifiers||Identifiers|Eindeutige Identifizierung der Objekte, die in der Nachricht enthalten sind|Siehe auch Kapitel 3.4.1 Ausprägungen: ReferenceTRID, PathID, PathRequestID, Case- ReferenceID|0..1|||
|I....I....PlannedTransportIdentifiers|Identifiers|PlannedTransportIden- tifiers|Identifiers in der Planungsphase|Für das Produkt „FPS“ ist in „PathRequestMessage“ immer eine CaseReference-ID anzugeben|1..N|||
|I....I....I....ObjectType|PlannedTransportIdentifiers|ObjectType|Objekttyp des Identifiers|TR = ReferenceTrain RO = Route PA = Path PR = PathRequest CR = CaseReference TC = TemporaryCapacityRestriction|1 string|2|[0-9A-Z]{2}|
|I....I....I....Company|PlannedTransportIdentifiers|Company|Der CompanyCode des Erstellers des Objekts|siehe Kapitel 3.16"Codelisten"|1 string|4 0001|ZZZZ [0-9A-Z]{4}|
|I....I....I....Core|PlannedTransportIdentifiers|Core|Vom Ersteller zu definierendes Kernelement des Identifiers|Es müssen alle 12 Stellen gefüllt werden. Nicht genutzte Stel- len sind mit „-„ auszufüllen|1 string|12|[\-\*0-9A-Z]{12}|
|I....I....I....Variant|PlannedTransportIdentifiers|Variant|Vom Ersteller zu definierende Variante||1 string|2|[0-9A-Z]{2}|
|I....I....I....TimetableYear|PlannedTransportIdentifiers|TimetableYear|Fahrplanperiode||1 integer|4 2012|2097|
|I....I....I....StartDate|PlannedTransportIdentifiers|StartDate|Startdatum des Zuges oder Paths. Das Datum ist ein konkreter Ver- kehrstag des Zuges oder Paths entsprechend des PlannedCalendars für den ersten Zug- bzw. Trassenlaufpunkt, wobei die für diesen Punkt gültige geplante Abfahrtszeit maßgebend ist.|wird nur im Betrieb bei Tagesfahrplänen genutzt|0..1 date|10 2012-01- 01|2097-12- 31|
|I....I....komplexe Struktur ohne Bezeichnung|Koplexe Struktur ohne Be- zeichnung||komplexe Struktur RelatedPlannedTransportIdentifiers innerhalb der xsd ohne eigenen Namen, die die beiden nachfolgenden Elemente enthält.|Dient nur der Gruppierung der beiden nachfolgenden Ele- mente RelatedPlannedTransportIdentifiers und ReasonOfRe- ference|0..N|||
|I....I....I....RelatedPlannedTransportIdentifiers|Identifiers|RelatedPlannedTrans- portIdentifiers|Bezug auf andere Objekte in der Planungsphase durch Angabe deren Identifier||1|||
|I....I....I....I....ObjectType|RelatedPlannedTransportI- dentifiers|ObjectType|Objekttyp des Identifiers (TrainID, PathID, PathRequestID, CaseRefer- enceID)|TR = ReferenceTrain RO = Route PA = Path PR = PathRequest CR = CaseReference|1 string|2|[0-9A-Z]{2}|
|I....I....I....I....Company|RelatedPlannedTransportI- dentifiers|Company|Der CompanyCode des EVU / EIU|siehe Kapitel 3.16 "Codelisten"|1 string|4 0001|ZZZZ [0-9A-Z]{4}|
|I....I....I....I....Core|RelatedPlannedTransportI- dentifiers|Core|Kernelement des Identifiers|Es müssen alle 12 Stellen gefüllt werden. Nicht genutzte Stel- len sind mit „-“ aufzufüllen|1 string|12|[\-\*0-9A-Z]{12}|
|I....I....I....I....Variant|RelatedPlannedTransportI- dentifiers|Variant|Variante||1 string|2|[0-9A-Z]{2}|
|I....I....I....I....TimetableYear|RelatedPlannedTransportI- dentifiers|TimetableYear|Fahrplanperiode|Bei RV-Kapazitäten ist immer das erste Fahrplanjahr des Ver- kehrszeitraums der RV-Kapazität anzugeben.|1 integer|4 2011|2097|
|I....I....I....I....StartDate|RelatedPlannedTransportI- dentifiers|StartDate|Startdatum der geplanten Abfahrt innerhalb des Zuständigkeitsberei- ches eines EIU|wird nur im Betrieb bei Tagesfahrplänen genutzt|0..1 date|10 2023-12- 10|2097-12- 31|
|I....I....I....ReasonOfReference|Identifiers|RelatedPlannedTrans- portIdentifiers|Angabe eines Grundes für die Verwendung des Elements Rela- tedPlannedTransportIdentifiers|Das Element kann nur in Verbindung mit einem RelatedPlan- nedTransportIdentifiers angegeben werden. Es dient der Identifikation bestimmter Prozessschritte oder der Begrün- dung des Verweises auf andere Objekte. Sofern einer der in der Codeliste aufgeführten Begründungen zutreffend ist, sollte der Code immer angegeben werden. Siehe Kapitel 3.16 "Codelisten".|0..1 String|4||
Tabelle 16 Identifiers Datenfelder
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 50
DB Intern / DB internal
##### **3.5 Attribute und Strukturen auf Messageebene**
Es gibt einige Attribute bzw. Strukturen, die keiner Struktur angehören und auf Messageebene ausgewiesen werden.
In nachfolgender Tabelle ist in der Spalte „Nachricht“ angegeben, in welcher Nachricht das jeweilige Attribut/Struktur anzuwenden ist.
|**Nachricht**|**Attribut**|**Beschreibung**|**Bemerkungen / Regeln**|**Vor-** **kom-** **men** **Typ**|**Länge** **Min-** **Wert**|**Max-** **Wert** **Ausprägun-** **gen**|
|---|---|---|---|---|---|---|
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathConfirmedMessage PathCanceledMessage PathNotAvailableMessage ErrorMessage ObjectInfoMessage UpdateLinkMessage|MessageStatus|Aktueller Status der Nachricht, wird durch den Absender bereit gestellt||1 token|1|1 = creation 2 = modification 3 = deletion|
|PathRequestMessage PathDetailsMessage|TypeOfRUHarmonization|Typ der EVU-Harmonisierung||0..1 string|4|Full, Part, None|
|PathRequestMessage PathDetailsMessage|TypeOfIMHarmonization|Typ der EIU-Harmonisierung||0..1 string|4|Full, Part|
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathConfirmedMessage PathCanceledMessage|CoordinatingIM|CompanyCode des koordinierenden EIU||0..1 string|4 0001|ZZZZ [0-9A-Z]{4} Siehe Kapitel 3.16"Codelisten"|
|PathNotAvailableMessage|||||||
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathConfirmedMessage PathCanceledMessage PathNotAvailableMessage|LeadRU|CompanyCode des federführenden EVU|Ist das mit der Planung und/oder Harmonisierung beauf- tragte EVU; muss nicht identisch sein mit dem Besteller/Ver- tragspartner (ResponsibleApplicant) oder mit dem durchfüh- renden EVU (ResponsibleRU); Angabe ist nur bei interope- rablen Zügen verpflichtend, wenn eines der beteiligten EVU die Harmonisierung und Koordination in der Vorplanungs- phase übernimmt.|0..1 string|4 0001|ZZZZ [0-9A-Z]{4} Siehe Kapitel 3.16"Codelisten"|
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathConfirmedMessage PathCanceledMessage PathNotAvailableMessage ReceiptConfirmationMessage ObjectInfoMessage|TypeOfRequest|Typ der Nachricht|Identifiziert die drei verschiedenen Basisprozesse in der Pla- nungsphase|0..1 short|1 1|Siehe Aus- prägungen 1 = Study 2 Request 3 = Modification|
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathConfirmedMessage PathCanceledMessage PathNotAvailableMessage ReceiptConfirmationMessage ObjectInfoMessage|TypeOfInformation|Typ der Information|Indikation, zu welchem Prozessschritt des Basisprozesses in der Planungsphase die Nachricht gehört|1 integer|2 1|Siehe Ka- pitel 3.16"Code listen" Siehe Kapitel 3.16"Codelisten"|
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 51
DB Intern / DB internal
|**Nachricht**|**Attribut**|**Beschreibung**|**Bemerkungen / Regeln**|**Vor-** **kom-** **men** **Typ**|**Länge** **Min-** **Wert**|**Max-** **Wert** **Ausprägun-** **gen**|
|---|---|---|---|---|---|---|
|PathDetailsRefusedMessage|RevisedRequest|Hinweis für das EIU, dass das EVU beabsichtigt, einen überarbeiteten Request bzw. eine Alternative zu senden| Dieses Attribut ist nicht zu verwenden; bei fachlichem Ände- rungsbedarf kann das EVU das übergebene Angebot ableh- nen und eine Neubestellung auslösen oder das übergebene Angebot annehmen und eine Änderung nach Vertragsschluss senden.|0..1 boolean||0, false (= falsch) 1, true (=wahr)|
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathCanceledMessage PathNotAvailableMessage ObjectInfoMessage UpdateLinkMessage|FreeTextField|Frei definierbarer Text|1. Das Attribut ist für die Nachricht „PathDetailsRefused- Message“ und „PathNotAvailableMessage“ für definierte Ge- schäftsvorfälle zu verwenden. Siehe hierzu Kapitel 2.2.3.. Z. B. zur Begründung der Berechtigten Beanstandung (Netz- fahrplan) bzw. der Ablehnung mit Überarbeitung (Gelegen- heitsverkehr) 2. Ansonsten ist das Attribut nur für ergänzende Informatio- nen zu verwenden, wenn dafür kein Datenelement oder Code vorhanden ist.|0..6 string|255||
|ErrorMessage|TypeOfError|Fehlertyp||1 integer||1 = functional 2 = technical 0 = both|
|ErrorMessage|Severity|Schweregrad des Fehlers|DB InfraGO verwendet vorerst nur den Schweregrad 2.|1 integer||1 = warning 2 = error|
|ErrorMessage|ErrorCode|Fehlercode|Neben den standardisierten Errorcodes der RNE im 5000er- Bereich nutzt die DB InfraGO AG Errorcodes im 6000er-Be- reich nach Anlage 9.|1 integer|1|9999|
|ErrorMessage|FreeTextField|||1 string|255||
|PathRequestMessage PathDetailsMessage PathDetailsRefusedMessage PathConfirmedMessage PathCanceledMessage PathNotAvailableMessage ReceiptConfirmationMessage ObjectInfoMessage UpdateLinkMessage|ReferenceTrainIDSubCalendar|(Teil-)Kalender des ReferenceTrain, der durch die ReferenceTRID identifiziert wird.|Der (Teil-)Kalender kann zusätzlich angegeben werden und dient primär der Konsistenzprüfung. Er enthält mindestens eine Teilmenge der Verkehrstage des ReferenceTrains, auf die sich die in der jeweiligen Nachricht enthaltenen Objekte beziehen. Die Verkehrstage des Kalenders der Route (enthal- ten in PlannedCalendar der TrainInformation) oder der Ka- lender des PathRequest bzw. des Paths (enthalten in Plan- nedCalendar der PathInformation) müssen in Verbindung mit dem OffsetToReference im (Teil-)Kalender des Refe- renceTrain vorhanden sein. Kann einer der Verkehrstage der Route, des PathRequests oder des Paths nicht einem Ver- kehrstag des ReferenceTrains zugeordnet werden, liegt ein Fehler vor.|0..1 Kalen- derobjekt aus Bit- mapDays und Validi- tyPeriod|||
Tabelle 17 Attribute und Strukturen auf Messageebene
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 52
DB Intern / DB internal
##### **3.6 Oberstruktur TrainInformation**
##### **3.6.1 Übersicht über die Oberstruktur „TrainInformation“**
Die Struktur enthält die vom bestellenden EVU gewünschten Zuginformationen über den gesamten Zuglauf. Der Zuglauf sollte dabei nicht vollständig angegeben werden, enthält aber verpflichtend Start- und Zielbahnhof und wichtige Zuglaufpunkte, wie z. B. im internationalen bzw. interoperablen Verkehr Übergänge zwischen den beteiligten EIU (Handover-Points) und Netzgrenzen sowie die PathPlanningReferenceLocation (Startpunkt für die Trassenkonstruktion). Die in der Struktur „PlannedCalendar“ angegebenen Verkehrstage gelten für den Gesamtzuglauf. Ggf. an den Zuglaufpunkten angegebene Fahrplanzeiten müssen auch über die Infrastrukturgrenzen hinweg konsistent sein, wobei ggf. angegebene Tageswechsel (Attribut „offset“), anhand derer die konkreten Verkehrstage am Zuglaufpunkt ermittelt werden können, zu berücksichtigen sind.
Die Struktur ist nur in der Nachricht „PathRequestMessage“ enthalten.
Abbildung 14 TrainInformation Oberstruktur
##### **3.6.2 Strukturen der Oberstruktur „TrainInformation“**
|**Strukturelement** |**Vorkom-** **men** |**Beschreibung** |
|---|---|---|
|I....TrainInformation|1|Zuginformationen des EVU über den gesamten Zuglauf|
|I....I....PlannedJourneyLocation|2..N|Zuglaufpunkte (siehe Kapitel 3.8|
|I....I....PlannedCalendar|1|Verkehrstageregelung des Zuges, gültig für den gesamten Zuglauf (siehe Kapitel 3.9|
|I....I....PathPlanningReferenceLocation|1|Referenzbetriebsstelle; Laufpunkt des Zuges, ab welchem die Konstruktion beginnen soll; für diesenZuglaufpunkt ist die Angabe einer Fahrplanzeit im Element TimingAtLoca- tion innerhalb der PathInformation der PathRequestMessage verpflichtend, sofern der Laufwegspunkt innerhalb des Konstruktionsbereichs der DB InfraGO liegt (siehe Kapitel 3.11).|
Tabelle 18 TrainInformation Oberstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 53
DB Intern / DB internal
##### **3.7 Oberstruktur PathInformation**
##### **3.7.1 Übersicht über die Oberstruktur „PathInformation“**
##### Diese Struktur enthält
- in der Nachricht „PathRequestMessage“: Die für ein am Zuglauf (gemäß der TrainInformation) beteiligtes EIU für dessen Konstruktionsbereich relevanten Zug- und Fahrlageninformationen des bestellenden EVU
- in der Nachricht „PathDetailsMessage“: Die vom EIU bereitgestellten Angebots- bzw. Ergebnisinformationen
In beiden Nachrichtentypen enthält die Struktur, soweit erforderlich, genaue Informationen zum gewünschten Zuglauf (Fahrlage) bzw. zur Zugtrasse, zur RV-Kapazität oder zum Ergebnis einer Fahrzeitberechnung bzw. Fahrplanstudie, jeweils innerhalb des Zuständigkeitsbereiches eines konkreten EIU.
Die in der Struktur „PlannedCalendar“ und in den Fahrzeiten an den Zuglaufpunkten angegebenen Verkehrstage und Fahrzeiten gelten genau für diesen räumlichen Bereich. Auch hier sind ggf. angegebene Tageswechsel (Attribut „offset“) bei der Ermittlung der konkreten Verkehrstage am Trassenlaufpunkt zu beachten.
Abbildung 15 PathInformation Oberstruktur
##### **3.7.2 Strukturen der Oberstruktur „PathInformation“**
|**Strukturelement**|**Vorkom-** **men**|**Beschreibung**|
|---|---|---|
|I....PathInformation|1|In der PathRequestMessage: Zug- und Fahrlageninformationen des bestellenden EVU für den gewünschten Zuglaufabschnitt; in der PathDetailsMessage: Zugtrasseninformationen des EIU für die angebotene Zugtrasse bzw. RV-Kapazität; gültig für den Laufweg im Zuständigkeitsbereich des EIU bzw. Ergebnis für eine Fahrplan- oder Betriebsprogrammstudie oder Fahrzeitberechnung.|
|I....I....PlannedJourneyLocation|2..N|Zuglaufpunkte (in PathRequestMessage); Zugtrassenlaufpunkte (in PathDetailsMessage) – siehe Kapitel 3.8|
|I....I....PlannedCalendar|1|Verkehrstageregelung der Route, der Fahrlage des Zuges bzw. der Zugtrasse oder RV-Kapazität; für Fahrlage bzw. Zugtrasse oder RV-Kapazität gültig für den Laufweg im fahrplanerischen Zuständigkeitsbereich eines EIU (siehe Kapitel 3.9. In Abhängigkeit vom Wert im Attribut OffsetToReference können sich die Verkehrstage im Kalender der PathInformation im Vergleich zu den Verkehrstagen des ReferenceTrains oder der Route um die Anzahl der Tageswechsel verschieben.|
|I....I....RequestedCalendar|0..1|Nur in der PathDetailsMessage: Ggf. Wiederholung der Struktur PlannedCalendar der PathInformation in der zugehörigen PathRequestMessage.|
Tabelle 19 PathInformation Oberstruktur Beschreibung
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 54
DB Intern / DB internal
##### **3.8 Struktur „PlannedJourneyLocation“**
Die Struktur „PlannedJourneyLocation“ (Zug-/Zugtrassenlaufpunkte“) enthält weitere, z. T. wiederholbare Unterstrukturen. In der Gesamtheit erfolgt damit je nach Geschäftsvorfall und Produkt eine umfassende Darstellung des Zuglaufs bzw. des Verlaufs einer Trasse oder RV-Kapazität bzw. des Ergebnisses für eine Fahrzeitberechnung oder Fahrplan- bzw. Trassenstudie.
Die Struktur „PlannedJourneyLocation“ ist in dem Nachrichtentyp PathRequestMessage sowohl in der Oberstruktur „TrainInformation“, als auch in der Oberstruktur „PathInformation“ enthalten. Die Angaben in der Oberstruktur „TrainInformation“ beschreiben den globalen Zuglauf (Route), die Angaben in der Oberstruktur „PathInformation“ beschreiben den geplanten Zuglauf (Fahrlage) im Bereich eines EIU mit allen erforderlichen Angaben zu den Betriebsstellen, Halten und Zugbehandlungen sowie gewünschten Fahrplanzeiten, Anschlussbeziehungen etc. und enthalten Informationen zum Zug (Zugcharakteristik). D. h., alle genannten Betriebsstellen sind Zuglaufpunkte (ZLP).
Im Nachrichtentyp „PathDetailsMessage“ ist die Struktur „PlannedJourneyLocation“ nur in der Oberstruktur „PathInformation“ vertreten. Diese Oberstruktur beschreibt den sich aus den Angaben zu dem geplanten Zuglauf (Fahrlage) ergebenden Verlauf der Trasse bzw. RV-Kapazität mit allen erforderlichen Angaben zu den Betriebsstellen, Halten, Betriebshalten und Zugbehandlungen sowie den konstruktiven Fahrplanzeiten und enthalten Informationen zur Nutzung der Zugtrasse für eine Zugfahrt, resultierend aus den technischen Angaben zum Zug (Zugcharakteristik) und den sich aus der Infrastruktur ableitenden Angaben der Trassencharakteristik, die in der Zugtrassencharakteristik zusammengefasst werden. Alle in der Zugtrasse aufgeführten Betriebsstellen sind Zugtrassenlaufpunkte (TLP).
Die mit der Struktur „PlannedJourneyLocation“ dargestellten Zuglauf- bzw. Trassenlaufpunkte müssen in der TrainInformation bzw. PathInformation in räumlich logischer Reihenfolge angegeben werden.
Die nachfolgenden Abbildungen zeigen
- Eine Übersicht über die Struktur „PlannedJourneyLocation“
- die Strukturen der zugeklappten Objekte (Unterstrukturen)
- LocationSubsidiaryIdentification
- TypeOfService
- PlannedTrainTechnicalData
- ExceptionalGaugingIdent
- DangerousGoodsIndication
- CombinedTrafficLoadProfile
- StatusOfHarmonization
- TrainActivity
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 55
DB Intern / DB internal
##### **3.8.1 Übersicht über die Struktur „PlannedJourneyLocation“ und deren Unterstrukturen**
Nachfolgend wird die Struktur “PlannedJourneyLocation“ als Übersicht dargestellt.
Abbildung 16 PlannedJourneyLocation Strukturübersicht
Im Nachfolgenden werden weitere Unterstrukturen der Struktur „PlannedJourneyLocation“ als Übersicht dargestellt.
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 56
DB Intern / DB internal
##### **[REDACTED] PlannedTrainData**
- Die Unterstruktur „PlannedTrainData“ darf nur in der Oberstruktur „PathInformation“ genutzt werden und ist optional.
- Die Struktur muss in der Struktur PathInformation am ersten ZLP/TLP immer angegeben werden.
- Die Struktur muss im weiteren Zuglauf immer dann an einem ZLP/TLP angegeben werden, sobald sich auch nur ein Attribut im Vergleich zu der an einem Vorgänger-ZLP/TLP zuletzt hinterlegten „PlannedTrainData“-Struktur ändert.
- Hat ein ZLP/TLP keine „PlannedTrainData“-Struktur, gilt automatisch diejenige, die am letzten Vorgänger-ZLP/TLP mit hinterlegter Struktur „PlannedTrainData“ definiert ist.
- Die Struktur darf am letzten ZLP/TLP der Struktur PathInformation nicht angegeben werden.
- Die Struktur enthält das Element „PushPullTrain“, welches eine Aussage zur Wendezugfähigkeit des Zugverbands macht.
##### **[REDACTED] NetworkSpecificParameter**
Die Unterstruktur „NetworkSpecificParameter“ wird für die Angabe EIU-spezifischer Attribute genutzt. Dabei werden unterschieden:
- NetworkSpecificParameter auf Message-Ebene (siehe Kap. 3.14.5). Diese NSP gelten, sofern sie angegeben sind, immer für die gesamte Nachricht.
- NetworkSpecificParameter auf Location-Ebene (siehe Kap. 3.14.6). Diese NSP müssen am ersten konstruktionsrelevanten ZLP/TLP immer angegeben werden, sofern die Angaben bereits dort zutreffen. Sie müssen im weiteren Zuglauf immer dann an einem ZLP/TLP angegeben werden, wenn sie in diesem lokal bzw. erst ab oder bis zu diesem ZLP/TLP gelten. Tabelle 28 NetworkSpecificParameter Location-Ebene Datenfelder enthält detaillierte Aussagen, welche NSP nur lokal im betreffenden ZLP/TLP, für den nachfolgenden Streckenabschnitt oder für einen durch eine Beginn- und Ende-Kennzeichnung definierten räumlichen Bereich gelten.
- NetworkSpecificParameter auf AffectedSection-Ebene (siehe Kap. 3.14.7). Diese NSP gelten ausschließlich für die betreffende AffectedSection-Struktur, sofern diese Struktur in einer Nachricht angegeben ist.
##### **[REDACTED] LocationSubsidiaryIdentification**
- In der Unterstruktur „LocationSubsidiaryIdentification“ können ergänzende Angaben zur Lokalität innerhalb des angegebenen Zug- bzw. Trassenlaufpunktes erfolgen.
- Mit der Angabe eines LocationSubsidiaryCodes in Verbindung dem LocationSubsidiaryTypeCode 41 wird für Betriebsstellen der DB InfraGO AG die bisherige Ril100-Abkürzung referenziert.
Abbildung 17 LocationSubsidiaryIdentification Unterstruktur
##### **[REDACTED] TypeOfService**
- In der Unterstruktur „TypeOfService“ können ergänzende Angaben zu im Zug verfügbaren Services erfolgen.
- Die Struktur wird in der Planungsphase des Trassenbestell- und -zuweisungsprozesses durch DB InfraGO generell nicht genutzt.
Abbildung 18 TypeOfService Unterstruktur
##### **[REDACTED] PlannedTrainTechnicalData**
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 57
DB Intern / DB internal
- Die Unterstruktur „PlannedTrainTechnicalData“ enthält im Nachrichtentyp
- PathRequestMessage Angaben zur Beschreibung der technischen Parameter des Zuges (Zugcharakteristik),
- PathDetailsMessage technische Angaben der Zugtrassencharakteristik, die sich aus den technischen Angaben des Zuges (Zugcharakteristik) und der Trasse/RV-Kapazität (Trassencharakteristik), ggf. abgeleitet aus Infrastrukturparametern, ergeben.
Abbildung 19 PlannedTrainTechnicalData Struktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 58
DB Intern / DB internal
##### **[REDACTED] ExceptionalGaugingIdent**
Die Unterstruktur „ExceptionalGaugingIdent“ enthält Angaben zu Beförderungsbesonderheiten (z. B. BZA, Beförderungsanordnungen, Dauer-LÜ oder Lademaßüberschreitung) im Bereich eines EIU.
Abbildung 20 ExceptionalGaugingIdent Unterstruktur
##### **[REDACTED] DangerousGoodsIndication**
- In der Unterstruktur „DangerousGoodsIndication“ sind Angaben zum Gefahrgut zu machen, sofern im Zugverband Wagen mit Gefahrgut enthalten sind.
- Die Angabe der RID-Nr. (Attribut RID_Class) ist dabei verpflichtend.
Abbildung 21 DangerousGoodsIndication Unterstruktur
##### **[REDACTED] CombinedTrafficLoadProfile**
Die Unterstruktur „CombinedTrafficLoadProfile“ enthält Angaben zu KV-Profilen, sofern im Zugverband Wagen mit abweichenden Fahrzeugbegrenzungslinien (insbesondere bei Wechselbehältern, Containern oder Sattelaufliegern), d. h. kodifizierte Ladeeinheiten auf kodierten Tragwagen, vorhanden sind.
Abbildung 22 CombinedTrafficLoadProfile Unterstruktur
##### **[REDACTED] StatusOfHarmonization**
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 59
DB Intern / DB internal
Die Angaben in der Unterstruktur „StatusOfHarmonization“ geben Auskunft über den Stand der Harmonisierung der Zuglaufangaben zwischen den beteiligten EVU und EIU.
Abbildung 23 StatusOfHarmonization Unterstruktur
Anlage 1 Datenfelder der Schnittstelle Bestellsystem – EVU, Version 4.6.2
Seite 60
DB Intern / DB internal
##### **[REDACTED] TrainActivity**
##### Die Unterstruktur „TrainActivity“
- ist eine Wiederholstruktur, die auf Ebene „PlannedJourneyLocation“ (ZLP/TLP) in den Strukturen „TrainInformation“ und „PathInformation“ vorhanden ist, aber aus fachlichen Gründen fast ausschließlich nur in der Struktur „PathInformation“ genutzt wird.
- TrainActivity beinhaltet im Attribut eine eindeutige Kodierung der Zugaktivität als Mussangabe sowie die Möglichkeit der Referenzierung auf einen anderen Zug durch die Angabe der OTN (optional) oder der ReferenceTRID (optional).
- wird genutzt, um auf Locationebene (ZLP/TLP) die gewünschte/erforderliche Haltart sowie gewünschte Haltegründe zu hinterlegen. Die gültigen Ausprägungen für das Attribut (verschlüsselte Haltearten und Haltegründe) sind in Kapitel 3.16.2 zu finden. Zur Angabe der Haltearten und Haltegründe sind die Unterstruktur „AssociatedAttachedTrainID“, das Attribut „AssociatedAttachedOTN“ und das Attribut „AssociatedAttachedLocationIdent“ nicht erforderlich.
- Kann genutzt werden, um Zugübergänge (vorheriger oder nachfolgender Zug, z. B: Tfz-Leerfahrt, oder Anschlussbeziehungen und Zugverknüpfungen, z. B. Zugzusammenführungen oder -trennungen bei „Y-Zugverbund“, anzugeben.
Abbildung 24 TrainActivity Unterstruktur
##### **3.8.2 Datenfelder der Struktur „PlannedJourneyLocation“ und deren Unterstrukturen**
In diesem Kapitel werden alle Datenfelder der Struktur PlannedJourneyLocation inklusive aller Unterstrukturen im Detail beschrieben.
- In diesen Strukturen werden alle Zug- bzw. Trassenlaufpunkt abhängigen Daten angegeben.
- Die Struktur steht an jedem Zug- bzw. Trassenlaufpunkt, der in den Nachrichten PathRequestMessage bzw. PathDetailsMessage zur Beschreibung des Zug- bzw. Trassenverlaufs aufgeführt ist.
- In der Oberstruktur PathInformation des Nachrichtentyps „PathRequestMessage“ müssen mindestens an einem konstruktionsrelevanten ZLP im Bereich der DB InfraGO in der Struktur „Timing“ im Feld eine der Ausprägungen „ELA“ (früheste Ankunftszeit), „LLA“ (späteste Ankunftszeit), „ELD“ (früheste Abfahrtszeit) oder „LLD“ (späteste Abfahrtszeit) angegeben und das zugeordnete Attribut