📘 Kapazitätsmanagement im Regionalverkehr – SUMO

Bachelorarbeit: Modellbasierter Optimierungsansatz für Dispatching-Strategien im Schienenverkehr
Autor: Caspar Münzinger
Institution: Rheinische Hochschule Köln
Zeitraum: 2025

---

🚀 Quick Start (Neu: Test-Run nach Refactoring!)

Repository wurde komplett aufgeräumt (2025-10-24). Alle Tests grün ✅

Test-Run durchführen:

# Detaillierter Plan
cat .azure/test_run_plan.md

# Quick-Start Commands
cat .azure/test_run_quickstart.md

# One-Liner für echtes Kölner Netz:
powershell -File infrastructure/topology/build_net_signals.ps1 -UseGuessStops
powershell -File timetable/scripts/build_osm_smoke_routes.ps1
powershell -File simulation/runtime/scripts/run_signals.ps1
python -m simulation.runtime.run_greedy_smoke

Status: 220 Unit-Tests passed, 60 Integration-Tests separiert ✅

---

TL;DR (Dev in 1 Kommando)

powershell -ExecutionPolicy Bypass -File scripts/run_dev.ps1

Erzeugt automatisch: Netz, Routes, Stops, SUMO-Run, KPIs und einen Smoke-Test (pytest). Ergebnis: data/output/kpi/kpi_dev_smoke.csv (Header: completed_trips,stop_events_total).

---

🎯 Zielsetzung

Das Projekt modelliert den regionalen Schienenverkehr im Raum Köln in einer mikroskopischen Simulation mit SuMO. Ziel ist es, die Kapazitätsauslastung an Engstellen (z. B. Köln Hohenzollernbrücke) unter verschiedenen Steuerungsansätzen zu analysieren:

1. Greedy Dispatching-Heuristik (Baseline)
2. Gemischt-ganzzahlige Optimierung (MIP)
3. Deep Reinforcement Learning (DRL)

Vergleichskriterien:

• 🟩 Durchsatz (Züge/Stunde durch Engstelle)
• 🟨 Mittlere Verspätung (Sekunden)
• 🟥 Konflikt- und Deadlockhäufigkeit

---

⚙️ Technische Basis

Komponente	Technologie	Version
Simulation Framework	Eclipse SUMO	1.24.0+
Steuerung & Analyse	Python + TraCI	3.13+
Netzaufbau	OpenStreetMap (Rail Layer)	via netconvert
Fahrplandaten	GTFS (General Transit Feed)	SRVD/SFVD 2025
Testframework	pytest	8.4.1+

Szenario:

• Strecke: Köln Hauptbahnhof ↔ Messe/Deutz
• Engstelle: Zweigleisiger Abschnitt bei Hohenzollernbrücke

---

🧩 Pipeline-Übersicht (Steps 1–7)

Die Simulation wird in 7 Hauptschritten aufgebaut:

Step	Ziel	Input	Output
1 – OSM Import	Bahnnetze aus OpenStreetMap mit Signalen & Weichen	data/input/osm/export_Koeln_*.osm	infrastructure/network/koeln_rail.net.xml
2 – GTFS Mapping	GTFS-Haltestellen mit OSM-Stop-Nodes abgleichen	data/input/gtfs/SRVD_GTFS.zip + data/input/gtfs/SFVD_GTFS.zip	data/input/timetable/stop_lookup.csv, data/input/timetable/trainstops.add.xml
3 – Smoke Test	4 Testzüge auf minimalem Fahrplan	timetable/routes/smoke.rou.xml	data/output/tripinfo/tripinfo_smoke.xml, data/output/stopinfo/stopinfo_smoke.xml
4A – KPI Collector	Kennzahlen für Durchsatz & Haltedauer	data/output/tripinfo/*.xml, data/output/stopinfo/*.xml	data/output/kpi/kpi_smoke_summary.csv
4B – Rail-KPIs	Auswertung von Signal- & Blockdaten	data/output/railsignal/railsignal_block_*.xml	data/output/kpi/kpi_blocks_summary.csv
5 – GTFS Integration	Fahrplanbasierte Simulation & KPIs	timetable/routes/gtfs_routes.rou.xml	data/output/tripinfo/tripinfo_gtfs.xml, data/output/kpi/kpi_gtfs_smoke.csv
6 – Greedy Baseline	TraCI-basierte FIFO-Dispatching-Strategie	Bottleneck-Zone	data/output/tripinfo/tripinfo_greedy.xml, Vergleichs-KPIs
7 – MIP Optimization	Gemischt-ganzzahlige Optimierung (Pyomo + HiGHS)	GTFS-Zeitfenster	Optimale Departzeiten, 3-Wege-Vergleich

📖 Detaillierte Dokumentation:

• docs/README_DETAIL.md - Technische Details & Architektur
• docs/PROJECT_STATUS.md - Vollständige Projekt-Timeline (Phase 1-9)
• docs/ - Alle Dokumentationen organisiert nach Kategorien

---

📊 Aktueller Stand (Step 7 abgeschlossen)

✅ Alle Module und Tests lauffähig (pytest: 30 PASSED / 2 SKIPPED)
✅ GTFS-Integration erfolgreich (20 Züge aus GTFS, Halte korrekt erkannt)
✅ Greedy FIFO Baseline implementiert (TraCI-basierte Bottleneck-Steuerung)
✅ MIP-Optimierung funktionsfähig (Pyomo + HiGHS Solver)
✅ 3-Wege-Vergleich verfügbar (Passive vs. Greedy vs. MIP)

🧮 KPI-Vergleich (Dev-Netz, 0-1800s Fenster):

Metrik	Passive	Greedy	MIP	🏆 Winner
Throughput	46	46	46	= (alle gleich)
Mean travel time	123.15s	123.76s	122.57s	MIP 🥇
p95 travel time	218s	200s	200s	Greedy = MIP 🥈
Stop events	8	8	8	= (alle gleich)

Erkenntnisse:

• MIP erreicht beste mittlere Reisezeit (-0.5% vs. Passive, -1.0% vs. Greedy)
• Greedy und MIP verbessern p95-Reisezeit um -8.3% gegenüber passiver Kontrolle
• Bei niedriger Verkehrsdichte (dev-Netz) sind Unterschiede gering
• Höhere Dichte im Köln-Netz wird größere Differenzen zeigen

---

� Voraussetzungen

Tools

• SUMO 1.24.0+ installiert (siehe DLR-Docs). Prüfen:

  sumo --version   # sollte >= 1.24.0 anzeigen

• Python 3.13+ mit venv:

  python --version
  python -m venv .venv
  .\.venv\Scripts\activate
  pip install -r requirements.txt

• MIP-Solver (optional, für Step 7):

  pip install highspy  # HiGHS solver (empfohlen)
  # Alternativen: conda install -c conda-forge glpk

Hinweis Pfade

SUMO löst Pfade relativ zum Speicherort der .sumocfg auf. Unsere zentrale Config liegt in config/, deshalb verweisen Pfade darin mit ../ zurück ins Repo-Root (z. B. ../infrastructure/network/...).

---

🔧 Bootstrap

Dieses Repo ignoriert generierte Artefakte (.gitignore). Bevor die Smoke-/GTFS-Runs funktionieren, müssen wir ein Minimal-Netz + Placeholder erzeugen:

powershell -ExecutionPolicy Bypass -File scripts/bootstrap_min.ps1

Ergebnis:

• infrastructure/network/dev_min.net.xml (kleines Grid-Netz zum Tool-Check)
• config/koeln.sumocfg (zeigt korrekt relativ auf ../infrastructure/network/... und ../data/input/...)
• data/input/timetable/trainstops.add.xml (Placeholder, damit KPIs/Parser nicht sofort scheitern)

Schnelltest:

sumo -c config/koeln.sumocfg

Wenn SUMO ohne Fehler endet, ist die Toolchain bereit (ohne Fahrzeuge endet die Sim sofort – erwartetes Verhalten).

Typische Fehler & Fix:

• Could not access configuration ... → config/koeln.sumocfg fehlt → Bootstrap ausführen.
• File 'config/../infrastructure/network/...' not accessible → relative Pfade falsch → in config/koeln.sumocfg müssen Pfade mit ../ beginnen.
• ... sumo_net not found ... → das „echte" Köln-Netz wurde noch nicht erzeugt → erst mit Minimalnetz arbeiten (Bootstrap), später Köln-Netz bauen (siehe unten, „Köln-Netz generieren").

---

🚀 Simulation ausführen

1) Smoke-Test (Minimalnetz) – Tool-Check

Ziel: SUMO-Run läuft, KPIs/Parser können ausgeführt werden (ggf. mit leeren Outputs).

sumo -c config/koeln.sumocfg

Hinweis: Ohne Routen werden keine Fahrzeuge erzeugt. Im nächsten Schritt (WIP) fügen wir eine kleine Dev-Routen-Datei hinzu, um tripinfo.xml/stopinfo.xml zu füllen.

(WIP) KPIs/Parser:

python scripts/kpi_collect_smoke.py       # erwartet trainstops.add.xml (vorhanden), erzeugt bei 0 Zügen leere/kleine Outputs
python scripts/kpi_parse_blocks.py        # nur falls rail-block-output vorhanden ist

(WIP) Tests:

pytest tests/test_smoke*.py -v

2) GTFS-Run (fahrplanbasiert)

Voraussetzungen: Köln-Netz & GTFS-Ableitung vorhanden (wird lokal generiert; nicht im Repo).

python scripts/gtfs_to_routes.py    # erzeugt Routen aus GTFS (setzt net/koeln_rail.stops.net.xml voraus)

powershell scripts/run_gtfs.ps1     # führt den fahrplanbasierten Run aus

python scripts/kpi_collect_gtfs_smoke.py  # KPIs aus GTFS-Outputs

pytest tests/test_gtfs*.py -v

---

🌍 Köln-Netz generieren

Anleitung folgt im separaten Abschnitt (docs/net_koeln.md), inkl. Import-Pfade, OSM-/Rail-Konvertierung, und Railsignal-Outputs (für kpi_parse_blocks.py).

---

Dev-Pipeline

Für lokale Funktions-/Tool-Checks steht ein kompletter Ein-Kommando-Runner bereit:

powershell -ExecutionPolicy Bypass -File scripts/run_dev.ps1

Was passiert:

1. Bootstrap: erzeugt infrastructure/network/dev_min.net.xml, config/koeln.sumocfg, Placeholder-Files
2. Random Routes: timetable/routes/dev.rou.xml (standardmäßig 50 Trips über 1800s)
3. Stops & fixe Routen: data/input/timetable/dev_stops.add.xml, timetable/routes/dev_fixed.rou.xml (4 Fahrzeuge × 2 Stops)
4. GTFS-Filtering: data/output/benchmark/gtfs_filtered_*.csv (20 Züge aus SRVD-Daten, 6:00-6:30 Uhr Fenster)
5. GTFS→Routes: timetable/routes/dev_gtfs.rou.xml (20 GTFS-basierte Fahrzeuge)
6. SUMO-Run (Passive): schreibt data/output/tripinfo/tripinfo_dev.xml, data/output/stopinfo/stopinfo_dev.xml
7. Window-KPIs: data/output/kpi/kpi_window_dev.csv (Throughput, Mean/p95 travel time, 0-1800s)
8. Robustness-KPIs: data/output/kpi/kpi_robustness_dev.csv (Teleports, Railsignal-Events)
9. Conflict-Proxy: data/output/kpi/kpi_conflicts_dev.csv (Foe-driveway overlaps)
10. Normalized Rates: data/output/kpi/kpi_window_plus.csv (Teleports/Conflicts per 100 arrivals)
11. Dev Report: data/output/reports/report_dev.md (Aggregierter Markdown-Report)
12. Greedy FIFO Run: data/output/tripinfo/tripinfo_greedy.xml (TraCI-basierte Bottleneck-Steuerung)
13. Greedy KPIs: data/output/kpi/kpi_window_greedy.csv
14. Greedy vs Passive: data/output/reports/report_greedy_vs_passive.md (Delta-Vergleich)
15. MIP Instance: config/mip_instance.yml (20 Züge aus GTFS, Release/Due-Fenster)
16. MIP Solve: data/output/benchmark/mip_schedule.csv (Optimale Departzeiten via Pyomo + HiGHS)
17. MIP Routes & Run: timetable/routes/dev_mip.rou.xml, data/output/tripinfo/tripinfo_mip.xml
18. MIP KPIs & Report: data/output/kpi/kpi_window_mip.csv, data/output/reports/report_mip_vs_pg.md (3-Wege-Vergleich)

Optionales Clean:

powershell -ExecutionPolicy Bypass -File scripts/run_dev.ps1 -Clean

Löscht data/output/ vor dem Run.

Typische Fehler & Fix

• randomTrips.py nicht gefunden → SUMO_HOME setzen (neues Terminal öffnen):

  setx SUMO_HOME "C:\Program Files (x86)\Eclipse\Sumo"

• Could not access configuration ... → config/koeln.sumocfg fehlt → erst Bootstrap/Runner ausführen.
• File 'config/../infrastructure/network/...' not accessible → Pfade in config/koeln.sumocfg müssen mit ../ beginnen (relativ zu config/).

---

Nächste Schritte (Köln-Netz & DRL)

• Köln-Netz generieren: Import/Build gemäß docs/net_koeln.md (OSM/Rail → net.xml, signals, blocks).
• Höhere Verkehrsdichte: Mehr GTFS-Züge, engere Taktung → stärkere MIP/Greedy-Differenzen.
• Deep Reinforcement Learning: DRL-Agent als 4. Baseline (PPO/DQN mit ray/gymnasium).
• 4-Wege-Vergleich: Passive / Greedy / MIP / DRL über alle KPIs.

---

📂 Projektstruktur (vereinfacht)

02_railNetKoeln/
├── 📄 README.md                    # Dieser Einstieg
├── 📄 README_DETAIL.md             # Technische Details
├── 📄 requirements.txt             # Python-Dependencies
│
├── 📁 config/                      # YAML-Konfigurationen
│   ├── run_smoke.yml               # Smoke-Test Config
│   ├── kpi_smoke.yml               # Smoke-KPI-Schwellen
│   ├── gtfs_timetable.yml          # GTFS-Konvertierung
│   ├── kpi_gtfs.yml                # GTFS-KPI-Schwellen
│   ├── kpi_window_dev.yml          # Zeitfenster-Definition (0-1800s)
│   ├── greedy_dev.yml              # Greedy FIFO Bottleneck-Config
│   ├── mip_dev.yml                 # MIP Minimal-Instanz (Test)
│   └── mip_instance.yml            # MIP GTFS-Instanz (generiert)
│
├── 📁 data/
│   ├── input/                      # Rohdaten (OSM, GTFS, Stop-Mappings)
│   │   ├── osm/export_Koeln_LinesSwitchesSignalsDerailsBuffers.osm
│   │   ├── gtfs/SRVD_GTFS.zip, SFVD_GTFS.zip
│   │   └── timetable/stop_lookup.csv, trainstops.add.xml, …
│   └── output/                     # Simulationsergebnisse & KPIs
│       ├── tripinfo/
│       ├── stopinfo/
│       ├── railsignal/
│       ├── kpi/
│       ├── reports/
│       └── benchmark/
│
├── 📁 infrastructure/
│   ├── network/                    # SUMO-Netze (dev, heuristisch, Köln)
│   └── topology/                   # Zwischenstände & heuristische Artefakte
│
├── 📁 timetable/
│   └── routes/                     # SUMO-Routen (dev, GTFS, MIP …)
│
├── 📁 simulation/
│   ├── assets/                     # `.sumocfg` & weitere Sim-Ressourcen
│   └── runtime/                    # (geplant) TraCI-/Runner-Skripte
│
├── 📁 scripts/                     # Python & PowerShell Tools (werden noch einsortiert)
│   ├── gtfs_to_routes.py           # GTFS → SUMO-Routen
│   ├── gtfs_filter_srvd.py         # GTFS-Zeitfenster-Filter
│   ├── gtfs_to_routes_dev.py       # GTFS → Dev-Routen
│   ├── gtfs_to_mip_instance.py     # GTFS → MIP-Instanz
│   ├── run_dev.ps1                 # Dev-Pipeline-Runner (18 Steps)
│   ├── run_greedy_dev.py           # Greedy FIFO TraCI-Runner
│   ├── run_mip_dev.py              # MIP SUMO-Runner
│   ├── mip_skeleton.py             # Pyomo MIP-Modell
│   ├── mip_build_routes_dev.py     # MIP-Schedule → SUMO-Routen
│   ├── kpi_collect_smoke.py        # Smoke-KPI-Collector
│   ├── kpi_window_dev.py           # Fenster-KPI-Collector (Passive)
│   ├── kpi_window_greedy.py        # Fenster-KPI-Collector (Greedy)
│   ├── kpi_window_mip.py           # Fenster-KPI-Collector (MIP)
│   ├── kpi_robustness_dev.py       # Teleports & Railsignal-Events
│   ├── kpi_conflicts_dev.py        # Conflict-Proxy (Foe-Overlaps)
│   ├── kpi_window_plus.py          # Normalized Rates
│   ├── report_dev_md.py            # Dev-Report-Generator
│   ├── report_greedy_vs_passive_md.py  # 2-Wege-Vergleich
│   └── report_mip_vs_pg_md.py      # 3-Wege-Vergleich
│
├── 📁 tests/                       # pytest-Tests (30 PASSED)
│   ├── test_gtfs_to_routes.py
│   ├── test_gtfs_run_and_kpis.py
│   ├── test_kpi_blocks.py
│   ├── test_smoke_dev_kpi.py
│   ├── test_kpi_window_greedy.py
│   ├── test_mip_skeleton.py
│   ├── test_mip_pipeline_dev.py
│   └── ...
│
└── 📁 docs/                        # Detaillierte Dokumentation
    ├── 01_osm_smoke_import.md
    ├── 02_stop_sighting.md
    ├── 03_trainstops_build.md
    ├── 04_smoke_test.md
    ├── 05_kpi_collector_smoke.md
    ├── 06_rail_outputs_activation.md
    ├── 07_gtfs_run_and_kpis.md
    ├── 08_rail_kpi_eval.md
    ├── 09_window_sensitivity.md        # Fenster-basierte KPI-Analyse
    └── README_OSM_PIPELINE.md

---

🧭 SUMO-Grundlagen für Einsteiger

SUMO (Simulation of Urban MObility) ist ein Open-Source-Simulationswerkzeug des DLR (Deutsches Zentrum für Luft- und Raumfahrt) für Verkehrssysteme.

Schienenverkehr in SUMO:

• Spezialisierte Knotentypen: rail_signal, rail_crossing
• Blockbasierte Signalsteuerung: Automatische Konfliktdetektion
• Fahrpläne & Haltestellen: trainStop, stopinfo
• TraCI-Interface: Python-API zur Echtzeitkontrolle

Projekt-Pipeline in SUMO-Begriffen:

1. netconvert → OSM-Daten in simuliertes Schienennetz umwandeln
2. duarouter / Python → Strecken aus GTFS generieren
3. sumo / sumo-gui → Simulation ausführen
4. TraCI / XML-Outputs → Daten extrahieren (tripinfo, stopinfo, railsignal)
5. Python-KPIs → Kennzahlen berechnen (Durchsatz, Verspätung, Blockbelegung)

📚 SUMO-Dokumentation: https://sumo.dlr.de/docs/

---

🧪 Tests

Das Projekt hat eine umfassende Test-Suite:

# Alle Tests ausführen
pytest tests/ rl/tests/ -v

# Nur GTFS-Tests
pytest tests/test_gtfs*.py -v

# Nur KPI-Tests
pytest tests/test_kpi*.py -v

Aktueller Status: ✅ 30 PASSED, 2 SKIPPED

---

⚠️ Bekannte Limitationen & Einschränkungen

1. Modell-Vereinfachungen

Fahrgastwechselzeiten

• Konstante Haltezeiten (60s) für alle Züge
• Keine Variation nach Tageszeit (Rush-Hour vs. Off-Peak)
• Keine Unterscheidung nach Zugtyp (S-Bahn vs. Regionalzug)
• Impact: Optimistische Durchsatzschätzung

Weichen-Dynamik

• SUMO-Standard-Modell ohne manuelle Weichensteuerung
• Keine explizite Modellierung von Weichenstellzeiten
• Impact: Konfliktauflösung evtl. unrealistisch schnell

Verspätungsquellen

• Nur konfliktbedingte Verspätungen (Signalhalte)
• Keine externen Störungen (Baustellen, technische Defekte, Fahrgastprobleme)
• Impact: Baseline (Passive) zeigt bessere Performance als in Realität

2. SUMO-spezifische Limitationen

Bidirektionale Gleise

• SUMO-Feature bidi="..." noch experimentell (SUMO 1.24.0)
• Routing nutzt evtl. nur Vorzugsrichtung bei eingleisigen Abschnitten
• Workaround: Manuelle Prüfung mit --railway.topology.repair empfohlen
• Referenz: SUMO Rail Tutorial

RailSignal-Constraints

• ❌ AKTUELL NICHT IMPLEMENTIERT: Fahrplan-basierte Constraints fehlen
• Tool generateRailSignalConstraints.py verfügbar, aber nicht integriert
• Impact: Policies (DRL/MIP) ignorieren geplante Zugfolgen → unrealistisch
• Status: Auf P0-Roadmap (siehe docs/PROJECT_GAPS_AND_IMPROVEMENTS.md)

Deadlock-Handling

• SUMO erkennt Deadlocks (--time-to-teleport.railsignal-deadlock), aber Auflösung ist Teleportation
• Keine automatische Backtracking-Logik
• Realität: Dispatcher würde Konflikte manuell auflösen
• Impact: Teleports verfälschen Throughput-KPIs

3. Skalierungsprobleme

Netzgröße

• Entwicklungs-Netz (dev_min.net.xml): 10×10 Knoten, ~46 Züge → funktioniert gut
• Köln-Knoten (infrastructure/network/): ~30 Knoten, ~100 Züge → Performance-Engpässe
• Vollnetz Köln: ~200 Züge/h → Nicht getestet (erwartete Laufzeit >1h/Simulation)

MIP-Laufzeit

• OR-Tools CP-SAT Solver: Exponentielles Wachstum mit Anzahl Züge
• Beobachtung:
  • 46 Züge: ~2-5 Sekunden pro Optimierungsschritt
  • 100 Züge: ~10-30 Sekunden (extrapoliert)

  • 150 Züge: Potentiell nicht praktikabel für Echtzeitsteuerung

• Mitigation: Sliding-Window-Ansatz (nur nächste N Züge optimieren)

DRL-Training

• Training-Zeit: 100.000 Steps ≈ 48h auf Standard-Laptop (ohne GPU)
• Skalierung: Exponentiell mit State-Space (mehr Signale → mehr Features)
• Einschränkung: Nur für Offline-Training praktikabel

4. Fahrplandaten (GTFS)

Datenqualität

• GTFS-Feed SRVD/SFVD: Planfahrplan, keine Echtzeitdaten
• Abweichungen zur realen Betriebsführung (z.B. kurzfristige Änderungen)
• Validierung: Nur Stichproben gegen Google Maps durchgeführt

Zeitfenster-Limitierung

• Benchmark-Runs: 06:00–10:00 Uhr (4h Simulation)
• Keine Abend-/Nachtverkehr-Szenarien getestet
• Impact: Ergebnisse evtl. nicht auf 24h-Betrieb übertragbar

5. Policy-spezifische Einschränkungen

DRL-Agent

• ❌ Aktuell nicht in Final-Benchmarks: Code vorhanden, aber Training unvollständig
• Keine Multi-Objective-Reward-Funktion (nur simple Summe)
• Keine Generalisierung auf andere Netze getestet
• Status: Als "Future Work" deklariert

MIP-Optimierung

• Keine Berücksichtigung von Fahrplan-Constraints (siehe oben)
• Annahme: Perfekte Informationslage (alle Züge bekannt)
• Realität: Dispatcher hat nur begrenzte Vorausschau

Greedy-Heuristik

• Nur lokale Optimierung (längste Wartezeit)
• Keine Vorausschau auf nachfolgende Konflikte
• Ergebnis: Fast identisch mit MIP → MIP-Modell evtl. zu simpel

6. Validierung & Verifikation

Fehlende Real-World-Validierung

• ✅ Plausibilitätsprüfung: Reisezeiten stimmen grob mit Google Maps überein
• ❌ Keine Validierung gegen historische VRR-Betriebsdaten
• ❌ Keine Abgleich mit realen Verspätungsstatistiken
• Grund: OpenData-Zugang zu historischen Echtzeitdaten nicht verfügbar

Statistische Signifikanz

• ❌ Aktuell: Nur Mittelwerte über Seeds (Mean/P95/IQR)
• ❌ Keine p-Werte (t-Test, Mann-Whitney) für Policy-Vergleiche
• Impact: Unklar ob Unterschiede statistisch signifikant
• Status: Auf P2-Roadmap

7. Reproduzierbarkeit

Plattform-Abhängigkeit

• Entwickelt auf: Windows 11, SUMO 1.24.0
• PowerShell-Scripts: Nur Windows-kompatibel
• Mitigation: Makefile vorhanden, Docker geplant (P2)

SUMO-Versions-Sensitivität

• RailSignal-Verhalten ändert sich zwischen SUMO-Versionen
• Empfehlung: SUMO 1.24.0+ (ältere Versionen nicht getestet)

---

🚧 Bekannte Bugs & Workarounds

ID	Beschreibung	Workaround	Status
#1	duarouter Fehler bei manchen GTFS-Routes	Manuelle Route-Bereinigung	⚠️ Offen
#2	TraCI-Disconnect bei langen Runs (>2h)	Checkpoint-System geplant	🔜 P3
#3	pyomo nicht in requirements.txt installiert	Manuell: pip install pyomo	✅ Dokumentiert

---

📊 Impact auf Thesis-Ergebnisse

Kritisch (Ergebnisse evtl. ungültig):

• ❌ RailSignal-Constraints fehlen → Policies unrealistisch
• ❌ Statistische Signifikanz nicht geprüft → Vergleich fraglich

Hoch (Ergebnisse eingeschränkt gültig):

• ⚠️ Keine Real-World-Validierung → Absolute Werte unsicher
• ⚠️ Skalierung auf Vollnetz unbekannt → Nur Aussagen für kleine Netze

Mittel (Qualität beeinträchtigt):

• ⚠️ DRL fehlt → Nur 2-Wege-Vergleich (Greedy vs. MIP)
• ⚠️ Konstante Haltezeiten → Optimistische Schätzungen

Niedrig (Akzeptabel für Thesis):

• ✅ Modell-Vereinfachungen transparent dokumentiert
• ✅ Relative Vergleiche (Greedy vs. MIP) valide trotz Limitationen

---

🔜 Geplante Verbesserungen

Siehe docs/PROJECT_GAPS_AND_IMPROVEMENTS.md für priorisierte Liste.

Top-3 vor Thesis-Abgabe (P0/P1):

1. ✅ RailSignal-Constraints integrieren (6-10h) → P0
2. ✅ Deadlock-KPIs aktivieren (2-3h) → P1
3. 🔄 Statistische Signifikanz-Tests (4-6h) → P1

---

📖 Weiterführende Dokumentation

Haupt-Dokumentation

Dokument	Inhalt
docs/README_DETAIL.md	Technische Details, Architektur, Code-Struktur
docs/PROJECT_STATUS.md	Vollständige Projekt-Timeline (Phase 1-9, konsolidiert)
docs/ELI5.md	Projekt-Erklärung für Nicht-Techniker

Nach Kategorien organisiert

Kategorie	Dokumente
Architektur	architecture/LIMITATIONS.md - Bekannte Einschränkungen
Evaluation	evaluation/STATISTICAL_VALIDATION_RESULTS.md - Statistische Tests (n=5)
Implementation	implementation/P0_P1_IMPLEMENTATION_SUMMARY.md - P0/P1-Tasks implementation/P0_P1_WORKAROUND_SUMMARY.md - Workarounds
Guides	guides/pre-commit-hooks.md - Git Pre-Commit Hooks

Ordner-Dokumentation (mit Code-Snippets)

• config/README_config.md - YAML-Konfigurationen
• data/input/README_input.md - OSM/GTFS-Daten
• net/README_net.md - SUMO-Netzwerke
• scripts/README_scripts.md - Script-Kategorien
• docs/RESTRUCTURE_PLAN.md - Migration vom Legacy-Szenario-Paket
• tests/README_tests.md - Test-Struktur & Coverage

---

📝 Zitation

@thesis{muenzinger2025capacity,
  author = {Münzinger, Caspar},
  title = {Kapazitätsmanagement im regionalen Schienenverkehr: Ein modellbasierter Optimierungsansatz},
  school = {Rheinische Fachhochschule Köln},
  year = {2025},
  type = {Bachelor's Thesis}
}

---

📜 Lizenz & Datenquellen

• Code: MIT License (siehe LICENSE)
• OpenStreetMap-Daten: ODbL
• GTFS-Daten: SRVD/SFVD (Schienenpersonennahverkehr Rhein-Sieg / NRW)

---

👤 Kontakt

Caspar Münzinger
🔗 GitHub: @cmuenzin

---

✨ Hinweis: Dieses Projekt befindet sich in aktiver Entwicklung (Stand: Oktober 2025). Step 8 (DRL) in Vorbereitung.