Masterarbeit — Ideen & Modellierung (intern)

Ideen & Modellierung (intern)

Interne Arbeitsnotizen — nicht Teil des Exposés. Hier darf das konkrete Vorgehen (FSM, Graph, ML) voll ausformuliert werden. Dies ist die chronologische Herleitung; der konsolidierte Stand steht in modellkonzept. Siehe arbeit, exposé.

2026-07-22 — Kostenmodell als gerichteter Graph

Ausgangslage (grob, aktueller Stand)

• Modell mit fünf Zonen: PAV Nord, PAV Süd, CI-Halle Nord, CI-Halle Süd (sehr groß), Terminal 2 (T2).
• Geschätzte Schwellwerte rechtfertigen eine Umsteuerung von Zone zu Zone.
• PAVs und CI-Halle liegen nah beieinander → Schwellwerte nah beieinander.
• T2-Sonderregel: Umsteuerung ins T2 nur, wenn im Terminal 1 (CI-Halle + PAVs) die Wartezeiten ausgeglichen sind.
• Schwäche: kommt ganz ohne Kostenrechnung aus → fehleranfällig.
• Ungelöst: Wegzeit von einem spezifischen Standort zu einem spezifischen Ziel.

Idee: Netzwerk aus gerichteten Graphen

• Geografische Knoten festlegen: Treppenhäuser, Lifte, Türen zwischen den Gebäuden, mit mittleren Wegezeitkosten untereinander.
• Jeder Standort/Monitor erhält einen eigenen Knoten mit Wegezeiten zu den nächstgelegenen geografischen Knoten.
• Über kürzeste Wege ergeben sich exakte Wegkosten je Monitor → Ziel.
• Gesamtkosten = Wegkosten + PWT(Ziel).
• Ergebnis: individuelle Zuweisung je Monitor statt grober Zonen.
• Gerichtete Kanten, weil Wege asymmetrisch sind (Einbahn-Schleusen, Rolltreppen-/Fließrichtung).

Bewertung — Stärken

• T2-Regel wird emergent: T2 gewinnt genau dann, wenn Weg(→T2) + PWT(T2) < Weg(→T1) + PWT(T1). Der weite Weg sorgt selbst dafür, dass T2 erst bei hohen T1-Wartezeiten lohnt — korrekter als die hartcodierte Regel und ohne die „ohne Kostenrechnung”-Fehlerquelle.
• Exakte, individuelle Kosten je Monitor (Monitor = ein Standort).
• Sauber verteidigbar: Netzwerkmodell + kürzeste Wege + Kostenaddition.

Offene Punkte / Forschungsgehalt

1. Zeitliche Kopplung Weg ↔ Prognose. Relevant ist die Wartezeit bei Ankunft (nach dem Weg), nicht jetzt. Bei 20 min ins T2 braucht es die PWT „in 20 min”. Frage: Reicht der Prognosehorizont des APLS über die längste Wegzeit? Sonst systematischer Fehler zugunsten weiter Ziele.
2. Rückkopplung / Gleichgewicht. argmin(Weg + PWT) je Monitor löst das Lastproblem nicht (Wardrop/Braess): Zeigen viele Monitore auf dasselbe Ziel, entwertet die Entscheidung ihre eigene PWT-Grundlage. Zu lösen: die Aufteilung der Ströme (anteilig/probabilistisch über Monitore). Der Graph ist notwendig, aber nicht hinreichend.
3. Stringenz — zwei getrennte Probleme:
   • Monitor-Hysterese (zwei Schwellen) verhindert zeitliches Flattern der Monitor-Empfehlung. ✓
   • Commitment-Konsistenz (räumlich, passagier-individuell): „nach 20 min Richtung T2 nicht zurückschicken”. Ein Monitor ist ggü. dem Einzelnen zustandslos; wer los ist, liest ihn nicht mehr. Kritisch nur bei Monitoren auf dem Weg. Frage: Stehen Monitore nur an Startpunkten (Problem klein) oder auch an Zwischenpunkten (dann Pfad-/Commitment- Konsistenz nötig, nicht nur Hysterese)?
   • Schwellen kostenabhängig statt fix: „umsteuern nur, wenn der Gesamtkosten-Vorteil den Mehr-Weg um eine Marge übersteigt” → Stringenz fällt aus dem Modell statt separat gepflegt.
4. Datengrundlage der Wegezeiten. Statt Grundriss × Gehgeschwindigkeit ggf. Transitzeiten empirisch aus APLS-Trackingdaten schätzen — stark belegbar, empirischer Baustein.

2026-07-22 (Forts.) — Wegezeiten & Prognosehorizont

Transitzeiten (zu Punkt 4): per Experiment.

• Ablaufen mit Stoppuhr oder stichprobenartige PAX-Messung.
• Anmerkung: Stoppuhr = Punktschätzer; PAX-Messung (zwei Zeitstempel je Person via APLS-Tracking) = Verteilung → belastbarer, erlaubt Streuung/Perzentile statt nur Mittelwert. v1: Mittelwert genügt; Verteilung als Ausbaupfad.

Prognosehorizont (zu Punkt 1): differentielle PWT-Auswertung.

• Idee: nicht die aktuelle PWT nutzen, sondern extrapolieren — PWT_Ankunft ≈ PWT_jetzt + (dPWT/dt) · Wegzeit.
• Im Kern ein Constant-Velocity-Vorhersagemodell. Trifft die Asymmetrie: jetzt günstiges, aber schnell vollaufendes Ziel wird für weite Wege korrekt abgewertet; leerlaufendes Ziel aufgewertet.
• Haken: Lineare Extrapolation ist am unzuverlässigsten bei langen Horizonten (T2, 20 min) — genau dort, wo man sie braucht. Wartezeit wächst nicht linear (Sättigung, Spitze vorbei).
• Gegenmittel: (a) PWT vor dem Ableiten glätten (exp. Glättung; dämpft auch das Flattern → koppelt an Hysterese); (b) Trendterm mit wachsender Wegzeit dämpfen/deckeln.
• Validierung (starker Thesis-Baustein): APLS loggt PWT-Zeitreihen. Trend für historische Zeitpunkte τ min vorausrechnen, mit Ist-Verlauf vergleichen → Fehlerkurve über τ → Aussage „bis zu welcher Wegzeit ist die Extrapolation vertrauenswürdig?“.
• Spektrum: Persistenz (PWT konstant) → Trend/Constant-Velocity (diese Idee, Baseline) → Zeitreihen-/ML-Prognose (Ausbau, passt zu „ansatzoffen inkl. ML”).

2026-07-22 (Forts. 2) — System-KPIs: PWT (prädiktiv) & WT (realisiert)

Das System speichert (u. a.) zwei Kern-KPIs je Kontrollstelle:

• PWT — geschätzte Wartezeit des nächsten PAX, der sich jetzt anstellt (prädiktiv, vorwärts).
• WT — tatsächliche Wartezeit des letzten PAX, der die Schlange gerade verlassen hat (realisiert, rückwärts, um ~eine Wartezeit lagged).

Konsequenz A — WT = kostenlose Ground Truth für PWT. Der gerade austretende PAX hatte beim Anstellen eine PWT; jetzt ist seine WT bekannt. Diese matched pairs (PWT-beim-Anstellen ↔ WT-beim-Verlassen) liefern laufend und automatisch den echten PWT-Vorhersagefehler. → Fehlerkurve/Kalibrierung (Punkt 1) ohne separates Experiment; nutzbar auch für die Non-Inferioritäts-Evaluation (realisierte Wartekosten messbar, nicht nur simuliert).

Konsequenz B — PWT − WT als rauscharmes Trend-Signal. Statt dPWT/dt zu differenzieren:

• PWT > WT ⇒ Schlange wächst (Neuankömmling wartet länger als der gerade Gegangene).
• PWT < WT ⇒ Schlange schrumpft. Differenzähnliche Größe über Lag ≈ eine Wartezeit; sofort verfügbar, ohne Glättung. Alternative/Ergänzung zur dPWT/dt-Idee.

Betriebsregel: Entscheiden mit PWT (vorwärts, um τ extrapoliert); kalibrieren/entzerren mit WT (Bias-Korrektur); nicht auf WT steuern (doppelt verzögert, Rückspiegel).

Offene Frage (modellierungsentscheidend): Wie wird PWT berechnet — modellbasiert (Schlangenlänge × Servicerate / Little) oder aus jüngster WT-Historie fortgeschrieben? Ist PWT aus WT abgeleitet, sind beide nicht unabhängig, und PWT − WT misst teils die System-interne Glättung statt echten Trend.

2026-07-22 (Forts. 3) — Kein Direktvergleich PWT/WT: der „Kamelhöcker”

Korrektur zu Forts. 2: PWT(t) − WT(t) bei gleichem Zeitstempel vergleicht verschiedene Kohorten und ist so nicht sauber.

Formal: Ein PAX, der bei t₀ mit PWT eintritt, erzeugt seine WT erst bei t₀ + WT. Also gehört WT(t) zu PWT(t − WT) — der Lag zwischen einer PWT und ihrer realisierten WT ist die Wartezeit selbst (zustandsabhängiger Verzug: klein bei kurzen, groß bei langen Wartezeiten).

Kamelhöcker: Die WT-Kurve ist eine um den höhenabhängigen Lag verschobene Echo-Kopie der PWT-Kurve — erst PWT-Höcker, dann verzögert WT-Höcker; niedrig ⇒ Höcker nah beieinander, hoch ⇒ weit auseinander, beim Abklingen wieder zusammen. Der horizontale Höckerabstand ist die Wartezeit → zugleich Selbstkonsistenz-Check (Abstand ≈ PWT-Wert an der Stelle; sonst Vorhersage-Bias).

Konsequenzen (korrigiert):

• Validierung/matched pairs: nicht bei gleichem t. Entlaggen — jede PWT um ihren eigenen Wert nach vorn schieben, dann überlagert sie die WT-Kurve. Höhenabgleich ⇒ Vorhersagefehler.
• Trend: PWT(t) − WT(t) ist kein Momentan-Gradient, sondern eine Differenz über ein Fenster ≈ einer Wartezeit (variabel) → während Rampen aufgebläht. Für sauberen Trend dPWT/dt über festes kleines Fenster (oder PWT(t) − PWT(t−Δ)); PWT − WT nur als „Veränderung über die letzte Wartezeit-Länge” lesen.

Entscheidende Datenfrage: Loggt das System pro Passagier (je PAX: PWT-beim-Anstellen + WT-beim-Verlassen)?

• Ja ⇒ matched pairs direkt vorhanden, Kamelhöcker-Lag für Validierung irrelevant.
• Nein (nur zwei Zeitreihen) ⇒ über den zustandsabhängigen Shift entlaggen; der Kamelhöcker ist dafür das Werkzeug.

2026-07-22 (Forts. 4) — PWT = L/μ (volatil) vs. WT (gemessen, glatt)

PWT-Berechnung geklärt: PWT = Warteschlangenlänge L (PAX) / Abflussrate μ (PAX/h) — ein Fluid-/Persistenz-Nowcast („wenn L und μ so bleiben …”). L und μ springen (Reisegruppe rein → L; zwei Spuren auf → μ) ⇒ PWT volatil. WT = reiner Messwert der durchlaufenen Zeit ⇒ Integral über den echten Verlauf ⇒ glatt, aber verzögert.

Kern-Einsicht: Die Höcker sind nie gleich, weil PWT die Bedingungen beim Anstellen einfriert, während μ/L innerhalb des Lags driften:

(gemessene WT) − (PWT beim Anstellen) = Netto-Prozessänderung während genau dieser Wartezeit. Die Höcker-Asymmetrie ist Information, kein Rauschen (PWT zu hoch ⇒ es wurde besser/Spur auf; zu niedrig ⇒ schlechter/Gruppe rein).

Konsequenz Steuerung: Weite Ziele (T2) sind doppelt unsicher — langer Weg-Horizont plus langes Wartefenster, über das μ/L driften. Dort ist die Persistenz-Annahme am schwächsten (mechanistische Erklärung für den T2-Problemfall).

Ausbau (Thesis-Beitrag): μ-Sprünge sind großteils bekannt/gesteuert (Spuröffnung!). ⇒ Deterministisches Fluid-Modell mit vorausschauendem μ(t): „Zeit, um L abzubauen, gegeben den erwarteten μ-Verlauf (geplante Spuröffnungen)” schlägt naives L/μ_jetzt. Prozessänderungen werden vom Fehler zum Modelleingang. WT bleibt glatte Kalibrier-Referenz; Residuen WT − PWT, zerlegt nach bekannten Events (Spur auf/zu, Gruppe), trennen erklärbaren (modellierbaren) vom stochastischen Fehler.

Trend endgültig: dPWT/dt ist von L/μ-Sprüngen dominiert, kein sauberer Gradient ⇒ ereignisbewusst (Spur-/Gruppen-Marker) oder über die glatte WT ankern.

2026-07-22 (Forts. 5) — Beobachter-Rolle, Linearisierung, Zielhierarchie, Reversalfreiheit

Korrektur: Nur Messung/Auswertung, kein Prozesseingriff (keine Spuröffnung). ⇒ „vorausschauendes μ(t) mit geplanten Öffnungen” (Forts. 4) entfällt. Beobachter-taugliche Ersatzlösung = robuste Trend-Extrapolation + Risikozuschlag (s. u.).

Entscheidungsregel (linearisierte dPWT/dt): Kosten(Ziel) = Wegzeit τ + PWT_jetzt + Steigung·τ + Risikozuschlag; umsteuern, wenn günstiger als andere Option. Steigung = lineare Regression der PWT über langes Fenster (z. B. 1 h, +5 min/h) → glättet L/μ-Sprünge.

• Feinheit Fenster ↔ Horizont: Stundendrift ist träge; Spitzen auf 10–30-min-Skala. Schätzfenster an τ koppeln (~2·τ) oder exp. gewichten.
• Wendepunkt: Linear sieht keine Wende. WT (glatt, verzögert, wahr) als Wendesignal — fällt WT, während PWT-Steigung noch positiv ist ⇒ Spitze bricht.
• Risikozuschlag horizontabhängig (weit = unsicherer = größerer Zuschlag) → operationalisiert „weite Ziele unsicherer”, verhindert 20-min-Umsonst-Wege.

Zielhierarchie (zentral): gleichmäßige Auslastung > individuelle Experience.

• Zielfunktion nicht Summe individueller Zeiten (→ Herden/Braess), sondern Minimierung der Auslastungs-Ungleichheit über die Prozessstellen (Varianz oder Max-Wartezeit). Balancieren ist das Ziel ⇒ Rückkopplung wird Mechanismus, nicht Bug ⇒ stabil.
• Nebenbedingung Fairness: kein Einzelner mehr als Toleranz (z. B. +2 min) über seinem Individualoptimum („PAX hat keinen Vergleich” liefert den Slack). Schützt davor, jemanden für die Balance zu opfern.

Stringenz = reversalfreies Empfehlungsfeld (getrennt von zeitlicher Hysterese):

• Monitor ist ggü. dem Einzelnen zustandslos ⇒ „nicht zurückschicken” kann nicht pro PAX greifen, sondern strukturell: das gesamte Empfehlungsfeld so, dass niemand, der den Pfeilen folgt, rückwärts über bereits gelaufene Wege geschickt wird. Umlenkung nur auf strikt vorwärts kürzere Ziele.
• Bild: Empfehlungen = Vektorfeld; entlang jeder Route reversalfrei (kein Knoten zweimal). Hysterese = zeitliches Flattern eines Monitors; Feld-Constraint = räumliches „A hin, B zurück”.
• Vorbedingung: Monitor-Topologie (welche Monitore auf dem Weg zu welchen Zielen).

Nächste Schritte (Vorschlag)

• Datenfrage klären: Logging pro Passagier oder nur zwei Zeitreihen?
• Datenfrage: μ-Reihe (Abfluss) und Spur-/Öffnungszustand als beobachtete Daten vorhanden? (Für Residuen-Zerlegung/Erklärung, nicht mehr für Vorausschau.)
• Zielfunktion festschreiben: Auslastungs-Ungleichheit minimieren u. NB Fairness-Toleranz.
• Monitor-Topologie kartieren (Start- vs. Zwischenpunkte) → Vorbedingung für Reversalfreiheit.
• Risikozuschlag- und Fenster-Parameter an historischen Daten kalibrieren.
• Knoten-/Kantenmodell für die fünf Bereiche skizzieren (welche Geo-Knoten, welche Monitor-Knoten).
• Monitor-Standorte kartieren: nur Start- oder auch Zwischenpunkte (Punkt 3).
• PWT-Fehler via matched pairs auswerten (ggf. nach Entlaggen) → klärt Punkt 1.
• Trend: dPWT/dt (festes Fenster) vs. PWT − WT (variables Fenster) vergleichen.

2026-07-23 — ML-Wartezeit-Prädiktor (Rolle A, gewünschtes Experiment)

Idee (Alex will das ausprobieren): statt linearer PWT-Extrapolation ein überwachtes ML-Modell (Gradient Boosting / LSTM), das aus der jüngsten Verlaufs-Historie (PWT, WT, L, μ, Tageszeit, Flugplan-Last) die tatsächliche Wartezeit τ Minuten später vorhersagt (τ = Laufweg).

• Labels geschenkt: die gemessene WT liefert für jeden historischen Moment die realisierte Wartezeit → jeder Zeitpunkt ist ein gelabeltes Beispiel (matched pairs, s. o.). Trainingsdaten: bis zu 250 Tage APLS/Xovis-Historie.
• Gewinn: fängt Nichtlinearitäten ein, die der lineare Trend verfehlt (Sättigung, kippende Spitzen, Tagesmuster, Spuröffnungen).
• Baseline: linearer Trend / PWT − WT. Schlägt ML das nicht → sauberes Ergebnis (methoden-offen).
• Risiko niedrig: offline auf historischen Daten, in sich abgeschlossen.
• Einordnung: Feld 5 Rolle A (Prädiktor, nicht Steuerung); Belege Ma/Lee/Félix Patrón (literatur-kandidaten).
• Achtung Systemgrenze: Xovis liefert PWT schon; ML verbessert hier den Input (Prognose auf Horizont τ), ist nicht der Kern der Arbeit.

2026-07-23 (Forts.) — KPI „Anzahl offener Spuren” (Feature + Event-Analyse)

Verfügbarer KPI: Anzahl offener Spuren; Spuröffnung/-schließung in Echtzeit binär messbar.

• Als Prädiktor-Feature (Rolle A): erklärt die μ-Sprünge direkt → der Prädiktor kann die auf eine Öffnung folgende Wartezeit-Senkung (bzw. Schließung → Anstieg) antizipieren, statt sie als Rauschen zu behandeln.
• Beobachter-kompatible Version der früher (Forts. 4) verworfenen „vorausschauendes μ”-Idee: nicht geplant/gesteuert, aber im Moment der Öffnung beobachtet + aus Historie gelernter Effekt.
• Als eigene Analyse (Event-Study): „Wirkung von Spuröffnung/-schließung auf PWT und WT” (Lag + Magnitude) → quantifiziert die μ-getriebene PWT-Volatilität und zerlegt Residuen nach bekanntem Event.