RailSynQ
Rail traffic orchestration combining a digital twin, constrained scheduling and delay-propagation models.
2025
SIH 2025 · Dynamic Train Orchestration and Throughput Maximization.
Scheduling across a changing rail network
RailSynQ organizes rail traffic around a live network state, a discrete-event digital twin and two scheduling horizons. Strategic planning allocates movements under operational constraints. Tactical rescheduling addresses a local disruption while retaining unaffected assignments, reducing the scope of each new optimization problem.
The architecture connects position/signalling feeds, track topology and environmental context to prediction and scheduling modules. Recommendations remain connected to their constraints, controller choices and decision history. A delay is represented as a network event whose effects can extend beyond the initially affected train.
Technology and role
Scroll horizontally to compare.
| Component | Responsibility |
|---|---|
| RailML 3.2 · Kafka · FastAPI | Normalize heterogeneous railway feeds, distribute events and expose live service updates. |
| Redis · MongoDB Atlas | Provide fast reference/state access and document/geospatial storage. |
| SimPy | Run discrete-event simulations and branch network state for what-if comparisons. |
| MILP · QUBO / D-Wave Ocean | Express strategic scheduling constraints and a separate local disruption-optimization path. |
| GNN · BiLSTM · Prophet · XGBoost | Separate delay propagation, maintenance signals, demand seasonality and conflict classification. |
| React · TypeScript · Three.js · Flutter | Present network state, decision explanations and controller/field interfaces. |
| Hyperledger Fabric | Retain recommendations, controller overrides and their justifications. |
Architecture walkthrough
- Adapters translate GPS, signalling, topology, weather and legacy-source records into RailML representations before the scheduler consumes them. Adding a source stays an adapter responsibility.
- Kafka distributes normalized events. Redis serves frequently accessed reference/live state, while MongoDB Atlas holds document and geospatial records.
- The SimPy twin mirrors the scheduling state and tests alternate holds, reroutes and movements in a separate scenario branch. Predicted consequences can be compared before surfacing an action.
- MILP handles the strategic horizon. The local QUBO path changes the affected allocation during disruption handling; Gurobi, CPLEX and OR-Tools are alternative strategic solver choices.
- The controller interface presents the candidate action and its justification. Approval or override becomes part of decision history, with observed outcomes returning to the prediction and simulation layers.
Core mechanisms
- Track conflicts, minimum headways, platform capacity, train priorities and speed profiles are explicit scheduling constraints.
- Strategic and tactical scheduling use different horizons so a local incident does not require treating every unaffected movement as a new decision.
- A GNN represents stations and track dependencies to model propagation across connected sections, beyond the first delayed train.
- Separate BiLSTM maintenance and Prophet demand branches keep equipment condition and traffic seasonality distinct from conflict resolution.
- A simulation-trained DQN branch explores recurring conflict-resolution policies within the twin. XGBoost and explanation logic provide a separate classification/interpretation path.
- During a GPS gap, kinematic estimates use last-known velocity, acceleration and topology. Confidence flags distinguish estimated positions from confirmed telemetry.
Engineering decisions
Scroll horizontally to compare.
| Decision | Reason |
|---|---|
| Canonical interchange schema | Feed-specific formats stay outside the planning and simulation core. |
| Hot-state cache plus document storage | Responsive reference access and longer-lived geospatial records serve different workloads. |
| Constraint optimization plus network prediction | Feasible allocation and downstream delay propagation are different questions. |
| Scenario testing and controller approval | Alternate decisions can be examined without changing the operational state. |
System deliverables
The SIH 2025 architecture brings ingestion, replication, optimization, trust and controller interaction into one decision workflow. The documented outputs include scheduling constraints, a digital-twin scenario sandbox, feed-loss handling and an auditable recommendation path. Each model has a defined responsibility rather than competing to produce the same generic risk score.