Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
@@ -0,0 +1,199 @@
|
||||
# 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
|
||||
Reference in New Issue
Block a user