Merge commit 'cfaf67010017eab368216aded483a64126dbcb2e' as 'bahn/wissensdatenbank'
This commit is contained in:
+103
@@ -0,0 +1,103 @@
|
||||
---
|
||||
domain: "pathos"
|
||||
tool: "pathos"
|
||||
scope: "intern"
|
||||
tags: ["domain:pathos", "tool:pathos", "scope:intern", "pathos", "taf-tap-tsi"]
|
||||
owners: ["einfachbahn@deutschebahn.com"]
|
||||
contact: "einfachbahn@deutschebahn.com"
|
||||
component_type: "page"
|
||||
source: "confluence"
|
||||
source_version: "8"
|
||||
meta_fingerprint: "f8016101b3b52f2d"
|
||||
url: "https://arija-confluence.jaas.service.deutschebahn.com/spaces/TTSI/pages/495573955/Planning+Handover+Handover+Points"
|
||||
last_updated: "2026-06-30"
|
||||
review_status: "approved"
|
||||
review_notes: ""
|
||||
content_hash: "15d4483ebb0dd8d2"
|
||||
---
|
||||
|
||||
Bearbeitungsstand|
|
||||
---|---
|
||||
Ansprechpartner|
|
||||
Letzte große Aktualisierung|
|
||||
|
||||
|
||||
|
||||
|
||||
## Allgemeine Definition
|
||||
|
||||
Das Sector Handbook der Joint Sector Group (JSG) definiert:
|
||||
|
||||
Responsible IM (RIM), Planning IM (PIM)
|
||||
The RIM is the IM who is the owner of the respective network and responsible for all operational
|
||||
handling of the traffic. The PIM is the IM who is responsible for elaboration and allocation of a path.
|
||||
The responsibility area of PIM is defined by handover points, e.g. used as first/last journey location in
|
||||
PathInformation of PathRequestMessage or of an offered/booked path.
|
||||
|
||||
|
||||
|
||||
|
||||
Es wird also unterschieden nach verantwortlichem EIU, also dem Betreiber der Schienenwege (BdS), und planenden EIU, welches in Einzelfällen, insbesondere in Grenzbereiche, abweichen kann. Die Stellen des Wechsels der Planungszuständigkeit werden Handover Points genannt.
|
||||
|
||||
|
||||
|
||||
|
||||
In der CRD ist das Attribut Handover Point eine Primary Location kurz definiert als
|
||||
|
||||
Handover Point: Point where legal responsibility changes between the Ims. This can
|
||||
be but does not have to be in conjunction with a state border
|
||||
|
||||
|
||||
|
||||
|
||||
Handover Points sind Herausforderungen für die grenzüberschreitende Trassenzuweisung, die durch Taf/Tap Tsi ermöglicht werden soll.
|
||||
|
||||
|
||||
|
||||
|
||||
Quellen:
|
||||
|
||||
* 10.4 Fremdinfrastruktur und Grenzen
|
||||
* [JSG-Handbook-3.6-with-XSD-3.5.0.0.pdf](http://taf-jsg.info/wp-content/uploads/2025/01/JSG-Handbook-3.6-with-XSD-3.5.0.0.pdf)
|
||||
* <https://www.dbinfrago.com/resource/blob/13501726/98781a2e02050f8e3b3e0a80e5a65ee9/Informationen-zu-Fahrplanbearbeitungsgrenzen-Planning-Handover-data.pdf>
|
||||
* <https://www.dbinfrago.com/resource/blob/13501728/456ac34bcce3d7c72f868055b6347e1e/Liste-der-Planning-Handoverpoints-zu-auslaendischen-EIU-data.xlsx>
|
||||
*
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Handover innerhalb des DB‑Netzes: Trasse von/bis Netzgrenze
|
||||
|
||||
Dieses Ticket legt fest, dass bei einem Handover innerhalb des DB‑Netzes die bestellte und zurückgelieferte Trasse den Abschnitt zwischen Handoverpunkt und tatsächlicher Netzgrenze explizit enthalten muss. Ziel ist es, Doppelbestellungen zu vermeiden und gleichzeitig sicherzustellen, dass die Abrechnung alle für Grenzabschnitte benötigten Daten erhält. Fachlich bedeutet dies: Auch wenn ein Zuglauf am innerdeutschen Handover beginnt oder endet, muss der vollständige Laufweg bis zur Netzgrenze in der Bestellung berücksichtigt und im Ergebnis zurückgegeben werden. In der Praxis wird dies etwa bei grenznahen Laufwegen sichtbar, bei denen die Route sowohl den Handover als auch den Grenzpunkt ausweist; das Planungssystem hat den Grenzabschnitt in der Antwort zu führen, damit die Abrechnungsgrundlage vollständig bleibt. Das Ticket verweist zudem auf eine gepflegte Referenzliste der Planning‑Handoverpunkte (inklusive zugehöriger Anhänge) als Validierungsbasis und adressiert die Frage, ob die eingesetzten Systeme den Abschnitt zwischen Handover und Grenze in jedem Fall zuverlässig zurückgeben.
|
||||
|
||||
Quelle:
|
||||
|
||||
|
||||
|
||||
|
||||
## Anwendungsfälle und Veröffentlichungslogik an Handover und Grenzen
|
||||
|
||||
TTTSOL‑429 systematisiert die drei relevanten Handover‑Varianten – auf DB‑Infrastruktur, direkt an der Grenze sowie auf Infrastruktur einer Nachbarbahn – und präzisiert die Angaben in Bestellung und Veröffentlichung. Für die Trassenanmeldung ist in der Route sowohl der Handoverpunkt als auch der tatsächliche Grenzpunkt zu benennen; in der PathRequestMessage werden in Deutschland primär Handover und die für Laufweg und Technologie relevanten Betriebsstellen angegeben. Auf DB‑Seite endet die PathDetailMessage auf Grenzstrecken grundsätzlich an der Grenze, während der weitere Verlauf im Nachbar‑Infrastrukturunternehmen veröffentlicht wird. Damit schafft das Ticket klare Leitlinien für die Kommunikation mit Bestellern und die durchgängige Abbildung grenznaher Abschnitte: Handoverpunkte steuern die fachliche Segmentierung, die Veröffentlichung folgt jedoch bis zum Grenzpunkt, um Transparenz und Abrechnungsfähigkeit sicherzustellen.
|
||||
|
||||
Quelle:
|
||||
|
||||
|
||||
|
||||
|
||||
## Inland–Ausland–Inland: Segmentierung und OTN‑Regel für TTT
|
||||
|
||||
Dieses Ticket bündelt die Regelungen für Verläufe Inland–Ausland–Inland und adressiert insbesondere die Eindeutigkeit der betrieblichen Zugnummer (OTN) im Zuge der TTT‑Einführung. Fachlich bleibt die Segmentierung unverändert: Jeder Abschnitt zwischen zwei Handoverpunkten wird als eigener PathRequest bestellt; die Veröffentlichung erfolgt je Infrastrukturbetreiber bis zum Handover bzw. bis zur Grenze. Entscheidend ist die Festlegung, dass an einem Verkehrstag nicht zwei PathRequests mit derselben OTN bestellt werden dürfen. Diese Vorgabe ist in den Vertrags- und Schnittstellendokumenten (SST) abzubilden, inklusive der Einschränkung der kombinierten Nutzung bestimmter Reason‑Codes und nationaler Besonderheiten (z. B. Ausschluss von Überschneidungen bei DE06). Für das Fahrplanjahr 2027 werden darüber hinaus keine weiteren Anpassungen in TPN erwartet; der Schwerpunkt liegt auf der konsistenten Dokumentation und Kommunikation der OTN‑Regel sowie der korrekten Segmentierung über Handover hinweg.
|
||||
|
||||
Quelle:
|
||||
|
||||
|
||||
|
||||
|
||||
## Nachtsprung auf innerdeutsches Fremd‑EIU: geregelte Ausnahme nach ERegG §51
|
||||
|
||||
Dieses Ticket definiert eine eng begrenzte Ausnahme für Mitternachtsübergänge auf ein innerdeutsches Fremd‑EIU: Die gesamte innerdeutsche Trasse wird bei DB InfraGO bestellt, die gemäß ERegG §51 die Koordination übernimmt und den Laufweg an das Dritt‑EIU weiterleitet. In der PRM ist der Verkehrstag beim Eintritt in die DB‑InfraGO‑Infrastruktur anzugeben; am ersten Laufwegspunkt wird kein Tageswechsel markiert. Der OffsetToReference (OTR) bildet die Differenz zwischen diesem Verkehrstag und der tatsächlichen Abfahrt ab und liegt bei Nachtsprung typischerweise bei 1 (einige Kanäle können initial OTR=0 setzen, die Verarbeitung bleibt sichergestellt). Ist der exakte Handover bekannt, wird er geführt; andernfalls gilt pragmatisch die erste als „konstruktionsrelevant“ gekennzeichnete Betriebsstelle als Handover. Alternativ kann die Bestellung über pathOS erfolgen und der Handover dort gesetzt werden; die PDM wird anschließend über das CI via ObjectInfoMessage abgerufen, OIM dient als Rückfallebene. Restriktionen wie „eine OTN pro Verkehrstag“ und der Verzicht auf Stützbetriebsstellen im Fremdnetz bleiben verbindlich, sodass Bestellung und Veröffentlichung trotz Nachtsprung durchgängig und auswertbar sind.
|
||||
|
||||
Quellen:
|
||||
|
||||
* *
|
||||
Reference in New Issue
Block a user