# Iteration 01 — Gesamtbild pathOS > Stand: 2026-04-22 | Quellen: 167 GitLab-Projekte + 143 Confluence-Seiten --- ## 1. Was ist pathOS? pathOS (ehemals "Bestellsystem") ist die Nachfolgeplattform des **Trassenportal Netz (TPN)** — dem seit 2002 produktiven System zur Trassenbestellung bei DB InfraGO. pathOS modernisiert den gesamten Bestellprozess fuer Zugtrassen. ### Kernaufgabe EVU-Kunden (Eisenbahnverkehrsunternehmen) bestellen ueber pathOS Trassen (Fahrwege) auf dem deutschen Schienennetz. Das System verarbeitet Anmeldungen, koordiniert mit dem Fahrplan, erstellt Angebote und verwaltet Vertraege. ### Kanaele - **Web-Portal** (portal-ui) — Benutzeroberflaeche fuer EVU-Sachbearbeiter und DB-Kundenbetreuer - **API / Common Interface** — TAF/TAP TSI-konforme Schnittstelle fuer EVU-Drittsysteme - **Click&Ride** — Vereinfachte Bestellung fuer eintaegigen Gelegenheitsverkehr --- ## 2. Systemlandschaft (aus GitLab + Confluence) ### Kern-Services (bestellsystem1/apps) ``` portal-ui ──> portal-middleware ──> steuerung-vertrieb (Camunda) │ ┌────────────────────┼────────────────────┐ ▼ ▼ ▼ auftrags-verwaltung common-interface kundendaten- -trasse (TAF/TAP TSI) bereitstellung │ │ │ ▼ ▼ ▼ Auftrag-Service ifp-connector stammdaten- │ bereitstellung ▼ vertragsdaten-verteiler archivierungsservice tbv-absicherung-konverter taftap-tdm-konverter rabattnummern-bereitstellung ``` ### Externe Systeme (22 Schnittstellen laut Vorstudie) | System | Funktion | Richtung | |--------|----------|----------| | **TPN** (Trassenportal Netz) | Altsystem, paralleler Betrieb | Bidirektional | | **BaDiFa** (Fahrplankonstruktion) | Fahrplanauftraege, Kapazitaetsbuchung | Bidirektional | | **KonBel-K / M13** | Bestelleingangspruefung (BEP), Routensuche | Consumer | | **AC** (AbrechnungsCockpit Trasse) | Preise, Abrechnung, Belege | Consumer | | **KDV** (Kundendatenverwaltung) | Kundenstammdaten | Consumer | | **IM / M15** (Infrastruktur-Manager) | Betriebsstellen, Strecken, Stammdaten | Consumer | | **CRD** (Common Reference Data / RNE) | Company_ID, Location_ID | Consumer | | **GeoServer** | Kartendarstellung, Routenvisualisierung | Consumer | | **eBRS-AD / iMan** | Benutzerverwaltung (intern/extern) | Consumer | | **NuR** (Nutzer- und Rechteverwaltung) | Einfachbahn-Berechtigungen | Consumer | | **Netzmonitor / SAPBINe** | Auftragsdaten-Bereitstellung | Provider | | **Stationsportal** | Vertragsdaten | Provider | | **Click&Ride** | Vereinfachte Bestellung | Bidirektional | | **TraPo** | Trassenportal (neu, ADR 72) | Geplant | | **KOMBau** | Kommunikation Bau | Geplant | ### Technologie-Stack | Schicht | Technologie | |---------|-------------| | Frontend | TypeScript, Angular(?), SCSS | | Backend | Java, Spring Boot | | Workflow | Camunda 8 (Upgrade auf 8.8/8.9 geplant) | | Messaging | Apache Kafka (AWS MSK) | | Datenbank | PostgreSQL | | Identity | Keycloak | | Container | Docker, Kubernetes (AWS EKS) | | CI/CD | GitLab CI, Helm, Cloud Native Buildpacks | | Monitoring | Prometheus, Grafana, Netcool (geplant) | | Security | Trivy, OWASP ZAP, Fortify, SonarQube | | Datenformat | TAF/TAP TSI (europaeischer Standard) | --- ## 3. Fachliche Kernobjekte Aus der Confluence-Dokumentation (Kapitel 4.3): | Objekt | Ersteller | Beschreibung | |--------|-----------|-------------| | **Train** | EVU (Kunde) | Grundlegendes Objekt fuer Kundensicht. Beschreibt den Geschaeftsvorfall. | | **PathRequest** | EVU (Kunde) | Konkrete Trassenanmeldung, abgeleitet vom Train. 1:n Beziehung. | | **Path** | IM (DB InfraGO) | Zeit-Wege-Linie durch das Netz. Wird vom Infrastruktur-Manager erstellt. | | **PathDetailsMessage** | IM | Zuordnung Path zu PathRequest (1:n). | | **CaseReference** | Bilateral | Buendelung von Objekten (Taktverkehre, Baumassnamen, etc.) | ### Lebenszyklus 1. EVU erstellt **Train** (Planungsphase) 2. Train wird in **PathRequests** aufgesplittet (Anmeldung) 3. IM erstellt **Path**-Objekte und sendet **PathDetailsMessages** 4. Vertragsschluss fixiert die Objekte 5. Nach Vertragsschluss: Aenderungen erfordern neue Train-Objekte --- ## 4. Technische Roadmap 2026 — Zusammenfassung 53 technische Themen, davon 17 MUSS (UKA/GELV), 24 MUSS 2026, 12 SOLL. ### Kritischste Themen (MUSS UKA/GELV) - Kubernetes-Cluster-Umstellung (1.1) - Betriebsueberwachung Netcool (1.2) - ECR statt Artifactory (1.3) - Vereinfachung Staging (2.1) - Security-Groups egress (3.1) - Secret-Rotation (3.2) - Monitoring-Konzept (4.1) - Camunda Point-in-Time-Recovery (5.1) - Disaster-Recovery-Tests (5.2, 5.3) - Spring Boot 4 Upgrade (8.1) — EOL Spring Boot 3.5: Juni 2026! - Camunda 8.8 Upgrade (8.2) - Runbook-Ausarbeitung (10.1) ### Deployment-Probleme (bestaetigt durch Confluence) - Deployment-Dauer auf TTT-ITU/TTT-KTU zu hoch - Keine dedizierte Verantwortung fuer Releases - Pipeline-Komplexitaet zu hoch - Code-Dopplung in Deployment-Scripten - Fehlende Automatisierung Release & Deployment --- ## 5. Identifizierte Problemfelder ### P1: Deployment-Komplexitaet (KRITISCH) - 47 Infra-Projekte (28% aller Repos) - 5+ separate Keycloak-Projekte - Deployment als "ein einziges Kubernetes-Deployment" ist Ziel, aber noch nicht erreicht - Manuelle Release-Orchestrierung ueber Teams-Kanal - Keine automatisierten Smoketests nach Deployment (erst seit 03/2026 in Arbeit) ### P2: Fehlende Dokumentation (HOCH) - ~60% der GitLab-Projekte ohne Beschreibung - Architektur-Dokumentation verweist auf Runbook (wird gerade neu erstellt) - Vorstudie von 2019 ist teilweise veraltet ### P3: Technische Schulden (HOCH) - Spring Boot 3.5 EOL Juni 2026 — Upgrade auf 4 noch im Funnel - Full-Table-Scans in Auftrags-Verwaltung-Trasse - Bidirektionale Abhaengigkeit CI/TTK - SV (ADR-56) - AppMesh AWS EOL 2026 — Alternative noch nicht umgesetzt - 30 von 53 Roadmap-Items haben noch kein Ticket ### P4: Altsystem-Abhaengigkeit (HOCH) - TPN (seit 2002) laeuft parallel - Datensynchronisation TPN <> pathOS noetig - Gleiche Ressourcen/Mitarbeiter fuer beide Systeme - TTTneo als Uebergangsloesung ### P5: Team-Struktur & Wissen (MITTEL) - DevOps-Know-How wird gerade aufgebaut - Rollierendes Deployment-Verantwortungssystem erst seit 06/2025 - Teams: Zero, 404, CIB, STeam, BSSUPPORT (aus Confluence) --- ## 6. Abkuerzungen (geklaert aus Confluence) | Abkuerzung | Bedeutung | |------------|-----------| | TPN | Trassenportal Netz (Altsystem seit 2002) | | BEP | TrassenProduktPruefenUndErgaenzen (Bestelleingangspruefung) | | IFP | Integrierte FahrPlanbearbeitung (Schnittstelle) | | TADEF | TAF/TAP DEFinition (Connector) | | PMW | Portal MiddleWare | | IM | Infrastruktur-Manager (M15) | | NuR | Nutzer- und Rechteverwaltung (Einfachbahn) | | TPS | Trassenpreis-Service (Rabatt) | | KDV | Kundendatenverwaltung | | AC | AbrechnungsCockpit Trasse | | BaDiFa | Bahndigitale Fahrplanung | | RuT-K | Rechnerunterstuetzte Trassenkonstruktion | | GFD-Z | Gelegenheitsfahrdienstleistung Zentral | | TTT | TAF/TAP TSI (Telematics Applications for Freight/Passengers - Technical Specification for Interoperability) | | TTTneo | Neue Umsetzungsstrategie fuer Trassenmanagement | | UKA | Unternehmenskritische Anwendung | | GELV | Gelegenheitsverkehr (Meilenstein) | | CI | Common Interface (TAF/TAP TSI) | | SV | Steuerung Vertrieb (Camunda-Prozess) | | CNP | Cloud Native Platform | | ADR | Architecture Decision Record | | PI | Program Increment (SAFe) | --- ## 7. Naechste Schritte 1. **Architektur-Diagramm** — Mermaid-Diagramm der Systemlandschaft erstellen 2. **Team-Mapping** — Welches Team besitzt welche Projekte? 3. **Dependency-Analyse** — pom.xml/build.gradle der Kern-Services analysieren 4. **Runbook lesen** — Aktuelle Architektur-Dokumentation aus dem Runbook 5. **Confluence vertiefen** — Weitere Seiten zu Geschaeftsprozessen, Vorstudie Kapitel 3-5