Merge commit 'cfaf67010017eab368216aded483a64126dbcb2e' as 'bahn/wissensdatenbank'

bahn/wissensdatenbank/output/processed/intern/pathos/trassenerstanmeldung.md

@@ -0,0 +1,163 @@
+---
+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: "17"
+meta_fingerprint: "f8016101b3b52f2d"
+url: "https://arija-confluence.jaas.service.deutschebahn.com/spaces/TTSI/pages/490596594/Trassenerstanmeldung"
+last_updated: "2026-06-30"
+review_status: "approved"
+review_notes: ""
+content_hash: "159e198c417ae189"
+---
+
+|   
+---|---  
+Ansprechpartner|   
+Letzte große Aktualisierung|   
+  
+  
+
+
+## Verweise auf weitere Kapitel
+
+Siehe zu Notfallprozessen, z.B. bei Systemausfall die [Dokumentation im Bereich Gelegenheitsverkehr](https://arija-confluence.jaas.service.deutschebahn.com/spaces/TTSI/pages/490600163/Trassenerstanmeldungen+zum+Gelegenheitsverkehr)
+
+## Sonderfall: Änderung der Ausgangsregion oder OffsetToReference in der Konstruktion
+
+Hier geht es um den Ablauf in einem Fall, wenn eine Neuanmeldung notwendig wird, wegen Änderung der Ausgangsregion oder OffsetToReference in der Konstruktion. Dies kann der Fall sein, wenn aufgrund einer Baumaßnahme ein anderer Ausgangpunkt für die Trasse notwendig wird. Problematisch würde dies, wenn durch die prozessual notwendige Abmeldung und Neuanmeldung die Trasse nicht mehr in die NEP1, sondern zeitlich in die NEP2 rutscht. 
+
+Der Ablauf ist vergleichbar mit dem 3-Tagesschreiben.
+
+  * Die DB InfraGO kontaktiert den Kunden (telefonisch oder per Mail) und informiert über die zu tätigende Anpassung.
+  * Der Kunde meldet die ursprüngliche Trassenanmeldung ab und stellt eine neue Trassenanmeldung.
+  * Nach Anmeldeschluss wird die Trassenanmeldung von der DB InfraGO in die richtige Prozessphase (NEP1) gebracht. 
+
+
+
+  
+
+
+Hintergrund ist auch, dass das Verschieben nach NEP1 so gestaltet wird, dass dies auch in der Abrechnung ankommt. Es gab hier in der Vergangenheit größere Herausforderungen, da die Abrechnung anhand des Timestamps der Anmeldung nicht zum NEP1 zuordnete.
+
+  
+
+
+Quellen:
+
+  
+
+
+  
+
+
+## Sonderfall: Trassenanmeldungen über PCS und Übergabe der Trassenangebote und -verträge an nationale Systeme sowie mögliche Änderungsbestellungen
+
+Es handelt sich hier um die Bestellung internationaler Trassen in NEP1 über PCS (Path Coordination System) und die anschließende Datenübernahme über die Schnittstelle (zwischen pathOS und POMaS). Dieser Fall wird insbesondere relevant, wenn Änderungsbestellungen an einem unter PCS geschlossenen Trassenvertrag getätigt werden sollen.
+
+Begriffserklärungen:
+
+  * PCS ist eine Internetanwendung der RNE (RailNetEurope), um Trassenanmeldungen für grenzüberschreitende Schienengüterverkehre auf PaPs (Prearranged paths) durchzuführen. 
+  * Güterverkehrskorridore (RFC) sind ausgewiesene Eisenbahnstrecken innerhalb der Europäischen Union, die zwei oder mehr Staaten miteinander verbinden. 
+
+
+
+  
+
+
+Für Trassenbestellungen auf den Güterverkehrskorridore (RFC) ist eine Bestellung über das Portal PCS verpflichtend. Die DB InfraGO wird die Trassenbestellungen, die in PCS ausgelöst werden, in Ihren Systemen abbilden und ein Angebot erstellen. Dieses wird in PCS bereitgestellt und in pathOS abgelegt. Über eine ObjectInfoMessage (OIM), die durch die DB InfraGO an den bestellenden Geschäftspartner kommuniziert wird, ist der geschlossene (gebuchte) Vertrag abrufbar.
+
+Sobald dieser Prozess abgeschlossen ist, kann ein Folgeprozess (z.B. Änderungsbestellungen, Stornierungen) über einen anderen Kanal ausgelöst werden. Das heißt wenn der Vertrag über PCS geschlossen, in pathOS abgelegt und die Vertragsdaten abgerufen wurden, kann die Modification (z.B. Stornierungen, Änderungsbestellungen) über das pathOS-CI angestoßen werden.
+
+Die theoretische weitere Option den Vertrag auch über das pathOS-CI zu versenden, gibt es bisher nicht. Daher bleibt zunächst die Übernahme des Vertrages mittels einer OIM der verbleibende Lösungsansatz. Die Struktur der OIM wird die DB InfraGO in der SST-Doku anbieten.
+
+  
+
+
+Weitere Einzelheiten zu den Abläufen: 
+
+  * DB InfraGO sendet eine netzausgelöste Änderung immer an den pathOS-Webclient und an maximal ein CI-Modul, wenn ein CI-Modul zu einem CompanyCode hinterlegt ist.
+  * Bei DB InfraGO kann pro CompanyCode maximal ein CI-Modul hinterlegt sein, (wenn ein EVU ein CI hat), an das DB InfraGO netzausgelöste Änderungen sendet
+  * Die Identifikation eines CI-Moduls eines EVU erfolgt bei der DB InfraGO nur anhand des CompanyCodes, nicht anhand der Kombination von CompanyCode und InstanceNumber.  
+D.h.: Pro CompanyCode kann die DB InfraGO eine netzausgelöste Änderung nur an ein CI schicken.  
+Außerdem müssen der CompanyCode des ResponsibleApplicant und der CompanyCode im MessageHeader identisch sein.
+
+
+  * Es gibt einen Kanalzwang: D.h.: Wenn sich ein EVU in einem Prozess als erstes über Kanal X "beteiligt", dann muss der gesamte Prozess über diesen Kanal X ablaufen.  
+Konkret:
+
+
+  * Bei einer EVU-ausgelösten Bestellung, Änderung oder Stornierung gibt das EVU den Kanal mit der ersten Nachricht vor.
+  * Bei einer netzausgelösten Änderung sendet DB InfraGO als erstes eine PathNotAvailableMessage an das CI-Modul. Wenn ein EVU darauf über das CI-Modul mit einer ReceiptConfirmationMessage (RCM) antwortet, ist dadurch das CI-Modul als Kanal vorgegeben.
+
+
+  * Es gibt keinen "Kanalwechsel": Durch eine Nachricht - egal ob ObjectInfoMessage oder eine Modifikation - kann ein EVU nicht die zukünftige Kommunikation über den genutzten Kanal - zum Beispiel ein CI-Modul - festlegen.
+  * Für die Kommunikation gibt es pro CompanyCode ein Zertifikat, das der Absender mitgeben muss, um sich bei DB InfraGO zu authentifizieren.
+
+
+
+  
+
+
+Beispiel zum Anwendungsfall beim DB Cargo Unternehmen RBH Logistics GmbH (RBH): RBH verschickt sowohl aus dem Cargo-CI als auch aus dem eigenen CI Nachrichten an InfraGO. Gemäß unserer Implementierung schicken wir die Nachrichten immer an den Endpunkt, der bei uns je CompanyCode konfiguriert ist. Wir schicken die Nachricht nicht unbedingt an das CI, von dem die PRM gekommen ist. Ebensowenig differenzieren wir beim Endpunkt nach der vom EVU angegebenen InstanceNumber (was man gemäß TTT könnte, was wir aber nie versprochen und auch nicht so implementiert haben). D.h. Cargo muss seine Prozesse mit RBH entsprechend anpassen, dass es passt.
+
+### Handoverpoints bei PaP-Trassen & Grenzbetriebsabkommen
+
+Für die Bestellung NEP1 muss DB InfraGO sicherstellen, dass die Handover mit den Nachbar-EIU abgestimmt sind. 
+
+Wenn die Betriebsstelle, an der die Verantwortung für die Fahrplanerstellung von der DB InfraGO auf das ausländische EIU übergeht in der Infrastruktur der DB InfraGO liegt, dann gibt es eine Differenz der anzugebenen Handoverpoints in PCS und pathOS:
+
+  * Bei einer Trassenanmeldung in PCS ist die Betriebsstelle anzugeben, an der die Verantwortung für die Fahrplanerstellung von der DB InfraGO auf das ausländische EIU übergeht (in der Excel-Tabelle auf [dbinfrago.com/taf-tap-tsi](http://dbinfrago.com/taf-tap-tsi) : Spalten E-H), beim Übertrag in die InfraGO-Systeme wird der Abschnitt zur/ab der Netzgrenze ergänzt.
+  * Bei einer Trassenanmeldung in pathOS (Portal oder CI) sind die Betriebsstellen aus der Excel-Tabelle auf [dbinfrago.com/taf-tap-tsi](http://dbinfrago.com/taf-tap-tsi) in Spalten J-M anzugeben.
+
+
+
+  
+
+
+Quelle: 
+
+  
+
+
+  
+
+
+## Eingabe von Betrieblichen Informationen
+
+Für bestimmte Sonderfälle müssen in einer Maske in RUT-K Informationen eingegeben werden, um daraus betriebliche Hinweise und Regelungen, Halthinweise und Haltegründe aus TTT codierten Informationen erzeugen zu können. Ein Beispiel für einen solchen Fall sind ETCS-Only Fahrzeuge, das heißt Fahrzeuge, die nicht mit PZB 90 ausgerüstet sind, sondern nur über ETCS als Zugsicherungssystem verfügen.
+
+  
+
+
+In der GFD-Z sind Beschreibungsvorlagen für alle notwendigen Fälle angelegt. 
+
+  
+
+
+Quelle:
+
+  
+
+
+## Betriebsstellen mit "istKonstruktionsrelevant=false" in der PathRequestMessage des EVUs 
+
+Das Merkmal "istKonstruktionsrelevant=false" bedeutet, dass es sich bei diesen Betriebsstellen um Betriebsstellen auf einem Fremdnetzanteil handelt, die für die DB InfraGO nicht konstruktionsrelevant sind.
+
+Es gilt Folgendes:
+
+  * Kunden dürfen Betriebsstellen mit istKonstruktionsrelevant=false "bestellen"
+  * Betriebsstellen, die vom Kunden mit istKonstruktionsrelevant=false "bestellt wurden", schreiben wir in das Angebot mit hinein, d.h. geben diese wieder
+  * Innerhalb Deutschlands sollten, müssen aber nicht, die Kunden Fremdbetriebstellen mitbestellen
+  * Im Ausland (gemäß veröffentlichter Liste auf der InfraGO-Webseite ([Fahrplan: EVU-Schnittstelle](https://www.dbinfrago.com/web/schienennetz/netzzugang-und-regulierung/taf-tap-tsi/evu_schnittstelle-11089208))) soll der Kunde dies nicht bestellen
+
+
+
+In einer exakt TTT-konformen zukünftigen Umsetzung, muss dieses Attribut überdacht werden und andere Lösungen in Erwägung gezogen werden (Nutzung von SLC, neben PLC)
+
+Quelle: