Dynamic Forecast of Expected Time of Arrival (ETA) for Coaching Trains
Ministry of Railways · Disaster Management · Software
The best data availability and the most independently verifiable demo of any railway statement here, but the schedule-plus-delay baseline is genuinely competitive, so start collecting running data immediately and make beating that baseline by a stated margin your entire claim.
What it actually is
The arrival time shown for a running train is mostly the printed timetable adjusted for the delay so far, which is why it keeps being wrong. The ask is a prediction that actually learns from how trains really run on that route, at that time of year, behind that traffic. It has to update continuously and work for thousands of trains at once.
What to build
An ETA service that ingests live train position and current delay, and for each remaining station on the run predicts arrival as a distribution rather than a point, using features grounded in real running behaviour — sectional running time history for that route, delay of the preceding train on the same section, downstream congestion, station-specific dwell behaviour, day of week and seasonal effects, and the recovery time actually built into the schedule — refreshing predictions on each new position update, degrading gracefully when position data is stale, and exposed through an API sized for network-wide operation with an accompanying view for passengers and control room staff showing predicted arrival with an uncertainty band.
Smallest thing that wins the room
Take a train currently running, show the official ETA next to yours for the next four stations with a confidence band, and put up the held-out backtest where your mean absolute error beats the schedule-plus-delay baseline by a stated number of minutes.
How crowded this one gets
A guess, projected from the 2025 statements — the last year where both the submission counts and the winners were published.
Quieter than 46% of the 226 · #122 of 226 by expected field
A normal-sized field. Your idea has to be good, not miraculous.
Why: central ministry statements sat below the average.
This is a guess, not a fact
Nobody has published 2026’s numbers yet. This is an analysed estimate from last year’s pattern, so please do not take it as the truth — check the live counter on the SIH portal before you decide anything. The range covers the middle half of likely outcomes, so one statement in two lands outside it. Entry closes at 500 ideas per statement, so no range goes past that — a statement that reaches the cap fills and shuts rather than drawing an unlimited crowd. The model reads only three things a team can see before choosing — software or hardware, the theme, and what kind of body posted it — and those explain about a quarter of the variation in last year’s field sizes (R² 0.25 on held-out statements). Trust the band more than the number, and the ordering more than either. It cannot see how good your idea is, which is the part that actually decides it.
The scores
The number is the shorthand. The line under it is the reason.
Acceptance potential
4/5Real obtainable data, an objectively measurable target, a demo a judge can independently verify and obvious daily-life impact make this genuinely strong, with the only real drag being that train delay prediction has been attempted before and you must beat the naive baseline convincingly rather than merely build a model.
Feasibility
4/5This is one of the very few railway statements with genuinely obtainable data — the published timetable, station and route master data and live running status are all accessible, and historical delay records have been collected and studied publicly, so you can train on real journeys and validate against real arrivals rather than a simulation.
Innovation scope
4/5The statement suggests candidate signals but prescribes no architecture at all, so the modelling approach, the feature construction, whether you predict point estimates or distributions, and how you handle cascading multi-day journeys are all yours.
Clarity
4/5The objective is unambiguous and, unusually, naturally measurable — arrival time error in minutes against a stated baseline — and the delivery requirements including APIs and network-wide scale are explicit, though no accuracy target is named.
Effort
HeavyA running-status collection pipeline, historical dataset assembly, feature engineering over sectional behaviour, model training and evaluation, a continuously updating serving layer and APIs is five workstreams, and assembling a clean historical delay corpus is slower than the modelling.
Demo-ability
EasyThis is the rare demo a judge can verify independently — they can check your prediction against the actual arrival on their own phone — and being right in front of a sceptical audience is far more persuasive than any interface.
In its favour
- Green flag: The success metric is naturally quantified in minutes of error, so unlike most statements you can prove you succeeded instead of arguing it
- Green flag: A judge can independently check a live prediction against the real arrival, which is an extraordinarily strong demo property that almost nothing else on the portal offers
- Green flag: Historical Indian Railways running data has been collected and analysed publicly, so you can train on real journeys instead of a simulator
- Green flag: The theme is filed under Disaster Management, so nobody browsing Transportation and Logistics will find this statement despite it being squarely a transport problem
Against it
- Red flag: The baseline is stronger than it looks — schedule plus current delay plus built-in recovery time is already reasonably good on short horizons, so a model that ties it has achieved nothing and you must report the comparison honestly
- Red flag: Delay propagation is the whole problem and it is cascading and network-wide; a per-train model that ignores the preceding train on the same section will plateau quickly
- Red flag: Collecting a historical running corpus takes calendar time you may not have if you start late, so begin the data collection before you write any modelling code
- Red flag: Multi-day long-distance runs are where errors compound most and are the hardest case, and a team that evaluates only on short suburban runs has demonstrated the easy half
What you will be writing
- LightGBM / Temporal Fusion Transformer sequence forecasting
- quantile regression for uncertainty bands
- live running status ingestion pipeline
- Redis-backed incremental prediction serving
- FastAPI ETA endpoints
- MAE against schedule-plus-delay baseline
- Railway operations
- Time-series forecasting
- Passenger information systems
Prior art to read before you start
train arrival time prediction · delay propagation modelling · real-time transport forecasting
Analysed by Claude Opus. Every score above is a judgment call with its reasoning attached — kindly cross-check this against the official statement on the SIH portal before your team commits to it.