Disruption management & operations recovery (airlines, rail, public transport)

When weather, technical faults, strikes or crew shortages break the plan, operations control centres (airline OCC, rail control centres, transit control rooms) must decide within minutes what to delay, swap or cancel, how to re-use aircraft/trains and crews legally, and where to put stranded passengers. Recovery engines combine ML delay forecasts with MIP, heuristic or reinforcement-learning solvers and present ranked options to a human dispatcher, reducing knock-on delay, compensation cost and manual workload.

Problem & value

• Today: controllers rely on experience, spreadsheets, rule-based tools and phone calls. Resources are recovered sequentially (aircraft first, then crew, then passengers), which is suboptimal because the three problems are coupled. Decisions are time-critical and must respect legality (duty and rest limits, maintenance windows, slot rules, track capacity).
• AI value: (1) predict how a primary delay will propagate through rotations, connections and crew legality; (2) generate and score many recovery alternatives jointly across resources; (3) automate the routine passenger side (rebooking, notifications). Gains are typically reported as fewer cancellations, shorter recovery time and lower cost per disruption day; published figures depend heavily on the operator and are best measured in a shadow-mode pilot rather than assumed.
• Regulatory cost driver: in the EU, Regulation (EC) No 261/2004 imposes care, re-routing and fixed monetary compensation for cancellations and long delays, so every recovery scenario is evaluated against an explicit passenger-rights cost [1]. Rail passengers have comparable rights under Regulation (EU) 2021/782 [2].

Variants

• Airline integrated recovery (OCC): aircraft routing, crew pairing repair, curfew/slot handling, and passenger re-accommodation. Leading solver vendors: Lufthansa Systems, Sabre, Jeppesen (Boeing), Amadeus, SITA, IBS.
• Passenger re-accommodation and re-booking (retail/e-commerce view): self-service rebooking in app/chat, offering alternatives (own flights, partner airlines, rail-air), vouchers and refunds; sub-step of recovery, close to customer service automation (AGENT-010 for corporate travel).
• Rail disruption management and dispatching: conflict resolution on track sections (retime, reorder, reroute, cancel), rolling-stock and crew re-planning, platform reallocation; Deutsche Bahn CTMS-style capacity and traffic management, plus national infrastructure managers (e.g. SBB, ProRail, Trafikverket).

How it works

1. live feeds (ops system, ATC/infra, weather, bookings)
2. disruption detection + delay-propagation forecast (ML on history + rule-based network model)
3. scenario generation (MIP / column generation / heuristics / RL policy / simulation)
4. legality + cost evaluation (duty time, rest, maintenance, slots, EU261, rolling-stock constraints)
5. ranked options to dispatcher (what-if, explanation, KPI deltas)
6. human approval (OCC duty manager / rail dispatcher)
7. execution: roster, schedule, platform/track updates + passenger notifications and rebooking
8. feedback loop: outcome vs. forecast for retraining

• Prediction layer: gradient boosting or sequence/graph neural nets forecast arrival delay, turnaround time and connection loss; this overlaps with PRED-018 (ETA prediction).
• Optimisation layer: mixed-integer programming (Gurobi, CPLEX, HiGHS, OR-Tools CP-SAT) for aircraft/crew recovery; neighbourhood-search heuristics for minute-scale response; for rail, job-shop style models with blocking-time constraints. RL policies (benchmarked on the Flatland rail-network challenge) act as fast proposers whose output is validated by the exact checker [3][4].
• LLM layer (optional, assistive): summarises the situation for the duty manager, drafts passenger messages in multiple languages, and (see OPT-018) translates "what if the hub closes for two hours?" into solver scenarios. LLMs must not decide legality; the solver and rule engine do.
• Human-in-the-loop: dispatcher approves or edits the plan; safety-relevant rail interlocking and signalling stay in certified systems outside the AI loop.

Data preparation

Needed are the planned schedule (flights, trains, rotations), real-time operational status (delays, positions, disruptions), crew rosters and legal duty limits, fleet and maintenance status, passenger bookings and connections, and historic disruption cases. These live in operations-control systems, crew-planning tools, PSS/booking systems, timetable databases and often in e-mail, radio logs and spreadsheets.

Typical gaps: data silos between crew, fleet and passenger systems, inconsistent identifiers, delayed or incomplete real-time feeds, poorly documented rules and union agreements, and almost no labelled "good recovery decisions". Passenger and crew data are personal.

Preparation steps: (1) build a common data model and reliable event streams (PREP-005), (2) write down rules and constraints in machine-readable form (PREP-012), (3) assemble historic disruptions as a test and replay set (PREP-018), (4) pseudonymise passenger and crew data (PREP-022), (5) monitor feed quality (DATA-008). Tools: streaming layer (Kafka), data warehouse, simulation environment. Expect 60 percent or more of the effort in data integration and quality.

Implementation paths

Which path for whom

• Enterprise: Path B. Recovery is a core, safety-relevant operation tied to proprietary crew, fleet and passenger systems; most operators combine vendor suites with their own optimisation and LLM layers via APIs, so integration matters more than a pure product purchase.
• Developer: Path C. Open-source solvers and simulation (OR-Tools, HiGHS, SimPy) are the usual base for building and testing recovery components without licence lock-in.
• Public: Path C. Transit authorities and public operators profit from sovereign, self-hosted or German/EU cloud setups because of procurement rules, operational criticality and data control.

Path A — Buy

• Airline OCC / recovery suites: Lufthansa Systems (Lido, Netline; Germany/EU), Sabre (Schedule Manager and disruption-recovery products), Jeppesen/Boeing crew and ops solutions, Amadeus (Altéa ecosystem and ops-control products; EU), SITA (OCC tooling, Air Transport IT; Swiss/EU-rooted), IBS Software. Passenger rebooking engines are often part of the PSS (Navitaire, Amadeus, Sabre).
• Rail / transit: Siemens Mobility, Hitachi Rail, Alstom, Thales traffic management systems with conflict-detection and resolution modules; Deutsche Bahn's own digital capacity and traffic management efforts; Trapeze, Hacon/Siemens (HaCon, Germany), INIT (Germany) and GIRO for public transport control.
• Choose A when: you are an airline/operator with a certified OCC stack already; the recovery engine needs deep integration with crew rules, maintenance and PSS that cannot be rebuilt.

Path B — Build on cloud APIs

• Solver-as-a-service: Gurobi Cloud, Google OR-Tools (CP-SAT, routing library) on managed compute, Timefold Solver (open core, Belgium) for scheduling constraints.
• Choose B when: public transport operators or regional carriers need a tailored tool on top of existing timetable and AVL data without a full OCC suite.

Path C — Self-host (open source)

• Solvers: HiGHS (MIP), OR-Tools CP-SAT, Timefold, SCIP; simulation with SimPy or SUMO/OpenTrack-like tools.
• RL / research: Flatland (AIcrowd) for rail environments, PyTorch with RLlib/Stable-Baselines3 [3].
• Hardware: HW1 (CPU servers) suffice for solving; a GPU (HW2) only for RL training or an on-prem LLM assistant. Operations effort: solver tuning, data pipelines and 24/7 availability dominate.

Path D — Custom training

Worth it for RL or learned proposers when the network is large and response must be sub-minute. Needs years of operational history (planned vs. actual), a high-fidelity simulator, and a legality checker as a safety net. Typical approach: learn to warm-start or prune the exact solver instead of replacing it.

State of the art (2026)

• Hybrid decision support dominates: ML forecasts + exact/heuristic optimisation + human approval. Pure end-to-end RL is still mostly research and pilots, as seen in the Flatland and related rail-rescheduling competitions [3][4].
• Integrated recovery (aircraft + crew + passengers solved jointly) is an established research topic; production systems still often decompose it sequentially for speed and explainability [5].
• Generative AI has entered at the edges: situation summaries, multilingual passenger comms, natural-language what-if queries, and automated rebooking dialogue.
• Limits and failure modes: stale or inconsistent live data; solutions that are legal but operationally fragile (no buffer, high knock-on risk); rare events (airspace closures, cyber incidents) that lie outside training data; dispatcher over-reliance; fairness issues when passengers are prioritised by commercial value without transparent rules.

Shared resources & combinations

• Same solver stack: OPT-013 (timetabling), OPT-003 (workforce scheduling), OPT-002 (APS) and OPT-019 (field dispatch) share MIP/CP-SAT tooling and rule-modelling skills.
• Upstream/downstream: OPT-018 (LLM what-if), OPT-028 (bridging transport); PRED-018 (ETA/delay prediction), weather and OPT-026 (flight trajectory optimisation).

Effort, cost & KPIs

• Path A: quarters; licence plus integration with crew, maintenance and PSS systems dominates.
• Path B: 6-12 months for a focused scope (e.g. bus/tram or single-hub recovery).
• KPIs: punctuality (on-time performance), total delay minutes, cancellations avoided, recovery time to normal schedule, crew-legality violations (target zero), passenger misconnections, cost of compensation and care, dispatcher acceptance rate of proposals, solve time.

People & change

Involve management, the operations-control (OCC) lead and the end-users, controllers and dispatchers, from the outset; they carry responsibility during disruptions and must trust the proposals. IT and IT security secure real-time interfaces (critical infrastructure may add sector rules), legal/compliance checks passenger rights and duty-time rules, and the DPO covers passenger and crew data. Customers are affected indirectly through rebooking.

Works council: yes. Crew rescheduling and tools logging controller actions are suited to monitor behaviour and performance, so §87(1) no. 6 BetrVG applies (BAG: objective suitability suffices); working-time effects add further rights. Inform under §90(1) no. 3 and consider an expert under §80(3). Public operators involve the staff council (Personalrat) under BPersVG or state law.

Data protection: a DPIA is likely; conclude AVVs with every processor. AI literacy: train controllers in simulation, so they know the limits and can override, supporting Art. 4 AI Act. Run a shadow-mode pilot on one network or hub, where the system proposes and humans decide, and replay past disruptions before going live. Typical concern: responsibility in a crisis; answer with clear human decision authority and an audit trail. See GUIDE-009, GUIDE-004 and GUIDE-013.

Risks, regulation & compliance

• EU AI Act: classification depends on scope. Pure operations planning for airlines is generally minimal risk. AI that acts as a safety component in managing and operating critical digital infrastructure or road traffic falls under Annex III point 2; rail signalling and aviation safety systems have separate sector safety law (and aviation/rail products under Annex I rules). Keep AI outside the safety-critical interlocking and flight-safety loop, and document the boundary [6]. If crew allocation uses worker monitoring or evaluation of individuals, Annex III point 4 (employment) may be triggered. No Art. 5 prohibited practice is involved unless passenger scoring or emotion analysis is added, which should be avoided.
• GDPR: passenger data (PNR, contact, special-assistance needs which may be health data under Art. 9) and crew data (duty hours, absence). Minimise, limit purposes, apply works-council co-determination (in Germany, BetrVG section 87) for crew-related tools. PNR data transfers to non-EU actors need a lawful basis.
• Passenger rights and labour law: EU261 care and compensation, EU rail passenger rights, EU flight-time limitations (EASA FTL rules) and collective agreements encoded as hard constraints [1][2].
• Operational risks and mitigations: fall-back to manual procedures when the tool fails; shadow mode before go-live; versioned rule base; explanation of why an option is ranked first; audit log for regulators and disputes.

Getting started

1. Map the recovery decisions and who owns them (aircraft/train, crew, passengers); log current response times and costs.
2. Assemble a historical dataset of planned vs. actual operations, disruptions and the manual decisions taken.
3. Encode the hard rules (duty time, rest, maintenance, track occupation, EU261) as a validated constraint layer first.
4. Build a baseline: ML delay-propagation forecast plus a solver on a single hub or line; run in shadow mode.
5. Add passenger re-accommodation and LLM-assisted messaging only after the core plan quality is proven.

Sources

1. Regulation (EC) No 261/2004 (air passenger rights) — https://eur-lex.europa.eu/eli/reg/2004/261/oj
2. Regulation (EU) 2021/782 (rail passengers' rights and obligations) — https://eur-lex.europa.eu/eli/reg/2021/782/oj
3. Flatland challenge (AIcrowd), multi-agent rail rescheduling benchmark — https://flatland.aicrowd.com/
4. Google OR-Tools documentation — https://developers.google.com/optimization
5. Timefold Solver documentation — https://docs.timefold.ai/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. HiGHS open-source solver — https://highs.dev/