Blog · arXiv Analysis · Last reviewed July 2, 2026

The Timestamped Plan Becomes the Dispatch Desk

DART turns railway disruption response into temporal planning: trains, gauges, turnouts, blockages, slowdowns, and auxiliary engines become a PDDL 2.1 problem, and the output is a timestamped action plan rather than a vague timetable. That is valuable because it is checkable. It is dangerous if the checkable plan is mistaken for live operational certainty.

The Paper

The paper is A Temporal Planning Framework for Disruption Aware Dynamic Route Optimization in Heterogeneous Railway Systems, arXiv:2606.14582 [cs.AI], by Pollob Chandra Ray, Sabah Binte Noor, and Fazlul Hasan Siddiqui of the Department of Computer Science and Engineering at Dhaka University of Engineering & Technology, Bangladesh. arXiv lists version 1 as submitted on June 12, 2026, with DOI 10.48550/arXiv.2606.14582.

The authors propose the Disruption Aware Railway Temporal Planning framework, or DART. The core move is to encode heterogeneous railway dispatch as a temporal planning problem in PDDL 2.1, then use temporal planners and a validator to generate and check executable plans under multi-gauge constraints and operational disruptions.

The arXiv record and paper link an artifact repository containing the planning domain, problem instances, experimental results, and validation outputs. The public GitHub repository lists problem-instance and experiment-result folders, and its language summary is almost entirely PDDL.

Dispatch as Planning

The paper's practical target is a gap between high-level timetabling and the operational work dispatchers still have to perform. A timetable can say when trains should arrive and depart. It may not say exactly when a turnout should be switched, which train must wait, whether an auxiliary engine should be dispatched, or which compatible gauge route can absorb a disruption without creating a conflict.

This matters most in heterogeneous multi-gauge networks. The paper discusses systems where trains and tracks differ by gauge, including meter, broad, standard, and dual-gauge infrastructure. Gauge compatibility is not a decoration on the route; it is a hard physical constraint. A dispatch plan that ignores it is not merely suboptimal. It can be impossible or unsafe.

DART treats dispatch as a sequence of durative actions with explicit start times, durations, preconditions, and effects. In the paper's small illustrative network, the generated plan includes simultaneous train movement, turnout actions, boarding actions, and gauge-labeled movements. That is the important shift: the output is not only a route, but an operational script.

DART

DART formalizes four disruption types: blocked track, blocked train, slowdown, and engine failure. A blocked track can require waiting or rerouting through gauge-compatible alternatives. A blocked train remains immobilized until resolved. A slowdown increases travel time on affected segments. An engine failure requires dispatching and attaching an auxiliary engine before movement resumes.

The PDDL 2.1 domain defines five object types: track-point, train, gauge-type, engine, and station. It models spatial configuration, infrastructure connectivity, turnout alternatives, gauge compatibility, disruption predicates, numeric functions for distance and speed, boarding time, turnout time, slowdown factors, blockage time, track-clear time, and engine-attach time.

The domain uses ten durative actions across movement, passenger service, disruption recovery, and infrastructure operations. The examples include drive-train, drive-engine, board-passengers, attach-engine, drive-assisted-train, resolve-train-blockage, clear-blocked-track, and turnout. The drive-train action marks a track segment inaccessible during traversal, checks gauge compatibility at start, requires the destination to remain free, and restores track accessibility at the end.

The value of the representation is that safety constraints become machine-checkable conditions. A plan is not judged only by whether it appears efficient. It can be validated against temporal constraints, preconditions, goal conditions, and mutual-exclusion rules.

The Benchmark

The benchmark contains one domain model and 200 problem instances: 100 nominal-operation instances and 100 disrupted-operation instances. The instances scale across Small, Medium, Large, and Very Large categories, with progressively harder sub-levels inside each category.

Nominal instances contain no unexpected disturbances and scale up to 107 to 120 trains, 134 to 150 stations, 906 to 1000 track points, and 87 to 100 junctions in the VL3 group. Disrupted instances add blocked trains, blocked tracks, slowdown segments, engine failures, and auxiliary engines. The largest disrupted group includes 107 to 120 trains, 134 to 150 stations, 914 to 1008 track points, 87 to 100 junctions, 10 blocked trains, 38 to 42 blocked tracks, 8 engine failures, 57 to 63 slowdown segments, and 8 auxiliary engines.

The experiments use POPF3 and OPTIC, with generated plans checked by the VAL plan validator. The planners ran with default parameters, a 30-minute time limit per problem instance, and one deterministic solve per instance. The reported machine was a 7th-generation Intel Core i7 workstation with 32 GB RAM, an M.2 SSD, and Ubuntu 24.04.3 LTS.

Results

The headline result is not that one planner wins. POPF3 and OPTIC produced identical makespan, plan length, and total-delay values across solved instances. The authors attribute this to shared heuristic structure and to a tightly constrained solution space created by gauge compatibility and single-track mutual exclusion.

Both planners solved all 100 nominal instances and 99 of the 100 disrupted instances. The one failure was the largest configuration: 120 trains, 1000 track points, and 108 concurrent disruptions. All 199 generated plans were verified by VAL, with no mutex violations, precondition failures, or goal-achievement errors detected.

The delay decomposition is more interesting than a single success rate. Slowdowns account for 60.1 percent of total delay across disrupted instances, engine failures for 30.4 percent, and blockages for 9.5 percent. In the VL3 group, slowdown delay reaches 69.8 percent. Computation time rises from about 0.06 seconds to about 45 seconds for nominal instances, and from 0.28 seconds to 619.00 seconds for disrupted instances. The largest disrupted instance hits the 30-minute limit.

The monotonic benchmark design also produces predictable stress curves. Network size metrics and computation time show perfect positive correlations in the reported Spearman analysis, while disruption quantities correlate strongly with total delay. That makes the benchmark useful as a scaling instrument, not only as a demonstration.

Safety Case

The best governance reading of DART is that it turns dispatch into a safety-case artifact. The artifact should include the domain file, problem instance, network-state snapshot, train inventory, gauge map, turnout state, disruption report, source of disruption duration estimates, planner name and version, search parameters, time limit, objective metric, generated plan, VAL validation output, failed-instance records, and human override path.

For real rail operations, the receipt would need more. It should name the sensor feeds or dispatcher inputs that created the problem instance, the authority that can approve a plan, the fallback when planning fails, the stale-data rule, the rollback or hold instruction, the passenger-impact policy, the incident-reporting path, and the boundary between advisory planning and automatic control.

This connects directly to AI Governance, AI Evaluations, AI Audits and Assurance, AI Safety Cases, AI Incident Reporting, The Factory Twin Becomes the Control Room, The Robotaxi Becomes the Street Interface, and The Safety Case Becomes the Release Gate. Critical infrastructure planning is not just optimization. It is accountable control over physical consequences.

Limits

The paper's own assumptions are the main boundary. The formulation assumes a fully observable and deterministic system, requires all trains to reach destinations and terminal conditions, treats disruption durations as known a priori, and uses constant-speed kinematics without acceleration and deceleration for tractability. Those are sensible modeling choices, but they are not the world.

That is why the "real-time" claim should be read carefully. A validated temporal plan is strong evidence that the encoded scenario has a feasible solution. It is not proof that the current railway has been observed correctly, that the disruption will last as predicted, that passengers and crews behave as modeled, or that a new event will not invalidate the plan before it is executed.

The authors name the next step: plan repair under uncertainty, adaptive replanning for incomplete or evolving operational information, derailment modeling, and integration with real-time data streams. That is exactly where governance pressure increases. Once the planner is connected to live data and operational authority, the question becomes who can stop it, who sees its assumptions, and who owns the consequences when the timestamped plan is wrong.

Sources

Return to Blog