Dynamic Forecast of Expected Time of Arrival (ETA) for Coaching Trains

1. Executive Snapshot

Summary

The Ministry of Railways requires a dynamic, data-driven Estimated Time of Arrival (ETA) forecasting system for coaching (passenger) trains across Indian Railways [PS]. Current ETA estimations rely primarily on static schedules, current delays, and fixed recovery times, failing to adapt to real-world variables like track congestion, signal halts, unscheduled stoppages, weather disruptions, and downstream delay propagation [PS]. This dossier presents an actionable architectural blueprint for a 4–6 student team competing in the Smart India Hackathon (SIH 2026) to design, build, and demonstrate a production-grade prototype [INFERENCE]. The proposed solution combines a Gradient Boosted Decision Tree (LightGBM/XGBoost) model for point-to-point delay estimation with a Spatio-Temporal Graph Network for section-level cascading delay propagation, exposed via high-throughput REST/WebSocket APIs to feed mobile applications, station display boards, and control room dashboards [INFERENCE].

Metadata

2. Problem Deconstruction

The official problem statement description from the Ministry of Railways is decomposed into the following atomic requirements [PS]:

• REQ-1: Continuous Real-Time Tracking Integration [PS]

  • Source Text: "The challenge is to create a system that can dynamically forecast the ETA of trains at various points in their journey using real-time data feeds. These may include GPS-based location data..." [PS]
  • Interpretation: System must ingest streaming location updates (e.g., 30-second interval RTIS/GPS feeds or station pass events) and update train position state [INFERENCE].
  • Implementation Implication: High-throughput ingestion pipeline using Apache Kafka/MQTT and Redis spatial caching [INFERENCE].
  • Tag: [PS]

• REQ-2: Multi-Factor Condition Monitoring [PS]

  • Source Text: "...signal aspects, average sectional running times, weather conditions, historical delay patterns, and congestion levels on downstream tracks." [PS]
  • Interpretation: Static timetable lookup is insufficient. Features must include signal state, section speed restrictions, downstream train density, and localized weather (e.g., fog) [INFERENCE].
  • Implementation Implication: Feature engineering pipeline fusing spatial line topology with temporal operational metrics [INFERENCE].
  • Tag: [PS]

• REQ-3: Continuous Dynamic Prediction Refinement [PS]

  • Source Text: "The system must dynamically update ETAs in response to real-time events and delays. Machine learning or statistical forecasting techniques should be employed to improve accuracy over time." [PS]
  • Interpretation: ETAs must re-calculate dynamically when unexpected delays or recovery events occur, outputting predicted arrival times with confidence intervals [INFERENCE].
  • Implementation Implication: ML inference pipeline triggering predictions on incoming movement telemetry or section state changes [INFERENCE].
  • Tag: [PS]

• REQ-4: Scalability Across Network & Zones [PS]

  • Source Text: "The system must also be scalable to cover thousands of trains simultaneously and adaptable to the Indian Railways diverse operational zones." [PS]
  • Interpretation: System architecture must support ~12,000+ daily trains, 8,000+ stations, and 17 Zonal Railways concurrently without performance degradation [KNOWN].
  • Implementation Implication: Microservices architecture with horizontal scaling, database partitioning by rail division/zone, and caching layers [INFERENCE].
  • Tag: [PS]

• REQ-5: Downstream Operational & Stakeholder API Integration [PS]

  • Source Text: "The solution should feature APIs for integration with mobile apps, station displays, and control room dashboards, ensuring that passengers and staff receive reliable, up-to-date information..." [PS]
  • Interpretation: API endpoints must serve diverse consumers: low-latency JSON REST APIs for passenger apps, WebSockets/MQTT for station IPIS boards, and analytical feeds for division controllers [INFERENCE].
  • Implementation Implication: API Gateway with rate limiting, WebSocket pub/sub server, and role-based access control [INFERENCE].
  • Tag: [PS]

3. Stakeholders & User Needs

4. Requirements Traceability

5. Constraints & Environment Realities

• Connectivity & Bandwidth in Rural Sections: [KNOWN] Trains travel through remote rural corridors (e.g., dense forests, hilly terrains) where cellular connectivity drops [KNOWN]. Satellite RTIS (ISRO NavIC/GAGAN) logs data locally during dead zones and flushes bursts upon re-establishing connection [RESEARCHED]. System must gracefully handle bursty, out-of-order telemetry [INFERENCE].
• Network Scale & Heterogeneity: [KNOWN] Indian Railways operates over 68,000 route kilometers, 8,000+ stations, and ~13,000 passenger trains daily [KNOWN]. Track configurations vary from quadruple electrified trunk lines (e.g., Delhi–Howrah) to single-line diesel sections with tokenless block working [RESEARCHED].
• Mixed Traffic Dynamics: [INFERENCE] Coaching trains share infrastructure with slower freight trains [KNOWN]. Freight train overrides and unscheduled loops significantly affect coaching train ETAs, creating non-linear delay spikes [INFERENCE].
• Station Display Hardware Limitations: [RESEARCHED] Existing station IPIS display boards rely on serial/RS-485 connections or light-weight MQTT brokers over regional network links [RESEARCHED]. Data payloads must be lightweight JSON/Protobuf [INFERENCE].
• Language & Digital Literacy: [KNOWN] Passenger interfaces must support multi-lingual displays (Hindi, English, Regional languages) and clear visual iconography for delays [INFERENCE].

6. Research Questions

1. How does Indian Railways currently track train movement in real time?
   • Answer: Via the Real-Time Train Information System (RTIS) developed by CRIS in collaboration with ISRO, using GSAT satellite transponders and GAGAN/NavIC GPS devices mounted on locomotives, pushing 30-second position updates to the Control Office Application (COA) [RESEARCHED].
2. What open datasets exist for historical delay analysis on Indian Railways?
   • Answer: Indian Railways schedule and station data are available on public portals like Kaggle ("Indian Railways Train Schedule & Delay Data") and data.gov.in, while live status is accessible via NTES web wrappers [RESEARCHED].
3. What machine learning models work best for railway network delay prediction?
   • Answer: Literature demonstrates that LightGBM/XGBoost excels at tabular station-to-station delay regression, while Graph Convolutional Networks (GCN) or LSTM-based Spatio-Temporal models capture cross-network delay cascading across shared track sections [RESEARCHED].
4. How are signal aspects and speed restrictions logged in Indian Railways?
   • Answer: Station Data Loggers capture signal movements and point switches, which are being progressively linked to division COA servers [RESEARCHED]. Temporary Speed Restrictions (TSRs) are issued via digital Caution Orders in COA [RESEARCHED].

7. Data Requirements & Sources

Data Classification Breakdown

• A. Explicitly Mentioned: GPS location data, signal aspects, average sectional running times, weather conditions, historical delay patterns, downstream track congestion [PS].
• B. Required by Inference: Station geographic coordinates (lat/long), railway line network topology graph, train priority classification (Rajdhani vs Express vs Passenger), day-of-week/holiday flags [INFERENCE].
• C. Data That Must Be Collected: Historical NTES running logs across key railway corridors over 3–6 months [INFERENCE].
• D. Data That Can Be Synthetically Generated: Real-time signal aspect changes, live track maintenance blocks (TSRs), out-of-order RTIS telemetry bursts [ASSUMPTION].
• E. Data That Still Needs Validation: Direct production integration access to live CRIS/COA feeds for non-railway entities [NEEDS VALIDATION].

8. Existing Solutions & Gap Analysis

9. Candidate Solution Approaches

Approach 1: Heuristic & Rule-Based Sectional Delay Projection

• Mechanism: Computes live delay at current station and projects forward using historical mean sectional running times adjusted by static time-of-day multipliers [INFERENCE].
• Pros: Extremely simple, zero training required, instant execution, low compute cost [INFERENCE].
• Cons: Cannot adapt to complex non-linear delay factors such as downstream track congestion, weather, or train precedence [INFERENCE].
• Hackathon Feasibility: 100/100 | Production Feasibility: 30/100 [INFERENCE].

Approach 2: Feature-Engineered Gradient Boosted Decision Trees (LightGBM / XGBoost)

• Mechanism: Formulates ETA prediction as a tabular regression problem. Features include current delay, section distance, day of week, hour of day, rolling average section speed, local weather (fog visibility), and downstream train density [INFERENCE].
• Pros: Highly accurate for point-to-point station arrivals, fast inference latency (<5ms per train), handles non-linear interactions, robust to missing features [INFERENCE].
• Cons: Evaluates each train semi-independently; does not explicitly model full network graph interactions [INFERENCE].
• Hackathon Feasibility: 90/100 | Production Feasibility: 85/100 [INFERENCE].

Approach 3: Hybrid Spatio-Temporal Graph Neural Network (ST-GNN) + LightGBM Ensemble

• Mechanism: Represents the railway network as a directed graph $G = (V, E)$ where nodes $V$ are stations and edges $E$ are track sections [INFERENCE]. Uses a Graph Convolutional Network (GCN) combined with GRU/LSTM temporal units to capture network-wide spatial delay propagation across all active trains, combined with a LightGBM regressor for localized train-specific features [INFERENCE].
• Pros: State-of-the-art prediction accuracy; captures cascading delay effects (e.g., Train A delay causing Train B hold-up at a junction 50 km ahead) [INFERENCE].
• Cons: High computational complexity, longer training time, complex graph setup for hackathon timeline [INFERENCE].
• Hackathon Feasibility: 65/100 | Production Feasibility: 95/100 [INFERENCE].

10. Recommended Approach & Why

Selected Strategy: Hybrid LightGBM + Network Section Congestion Model

The team will implement Approach 2 augmented with a Network Section Congestion Matrix [INFERENCE].

                                +-----------------------------------+
                                |    Live Telemetry & RTIS Feed     |
                                +-----------------------------------+
                                                  |
                                                  v
+-----------------------+       +-----------------------------------+
|  Spatial Topology     | ----> |  Feature Engineering Engine       |
|  & Station Distances  |       |  - Section Speed Trend            |
+-----------------------+       |  - Downstream Train Density       |
                                |  - Weather Impact Factor          |
+-----------------------+       |  - Historical Section Delay       |
|  OpenMeteo Weather    | ----> +-----------------------------------+
|  API Feed             |                         |
+-----------------------+                         v
                                +-----------------------------------+
                                |  LightGBM Dynamic ETA Regressor   |
                                +-----------------------------------+
                                                  |
                                                  v
                                +-----------------------------------+
                                | Quantile Forecast Engine          |
                                | (P10 / P50 / P90 Arrival Window)  |
                                +-----------------------------------+

Why Alternatives Were Rejected

• Pure Heuristic (Approach 1): Rejected because it offers zero statistical learning and represents the exact status quo limitation described in the problem statement [PS].
• Full ST-GNN (Approach 3): Rejected as the primary hackathon build due to excessive training overhead and data dependency risks within a 36-hour hackathon window [INFERENCE]. However, the graph network structure is designed into the production data architecture as a drop-in upgrade [INFERENCE].

11. Technical Architecture

Layered Architecture Diagram

+-----------------------------------------------------------------------------------+
|                                 CLIENT LAYER                                      |
|  +--------------------+    +-----------------------+    +----------------------+  |
|  | Passenger Web/App  |    | Station IPIS Displays |    | Control Dashboard    |  |
|  | (React / Next.js)  |    | (WebSockets / MQTT)   |    | (Leaflet.js Maps)    |  |
|  +--------------------+    +-----------------------+    +----------------------+  |
+-----------------------------------------------------------------------------------+
                                          ^
                                          | JSON REST / WebSockets (Port 8000)
+-----------------------------------------------------------------------------------+
|                                API & GATEWAY LAYER                                |
|  +-----------------------------------------------------------------------------+  |
|  | FastAPI Gateway (Rate Limiting, CORS, OpenAPI Docs, JWT Auth)             |  |
|  +-----------------------------------------------------------------------------+  |
+-----------------------------------------------------------------------------------+
                                          |
+-----------------------------------------------------------------------------------+
|                               CORE SERVICES LAYER                                 |
|  +-----------------------+  +-----------------------+  +-----------------------+  |
|  | Live Ingestion Service|  | Dynamic ETA ML Engine |  | Delay Cascade Solver  |  |
|  | (RTIS/NTES Parser)    |  | (LightGBM Pipeline)   |  | (Graph Bottlenecks)   |  |
|  +-----------------------+  +-----------------------+  +-----------------------+  |
+-----------------------------------------------------------------------------------+
                                          |
+-----------------------------------------------------------------------------------+
|                                 DATA & CACHE LAYER                                |
|  +-----------------------+  +-----------------------+  +-----------------------+  |
|  | PostgreSQL + PostGIS  |  | Redis Stream & Cache  |  | Model Artifact Store  |  |
|  | (Master Routes/Logs)  |  | (Live Spatial States) |  | (ONNX / Joblib)       |  |
|  +-----------------------+  +-----------------------+  +-----------------------+  |
+-----------------------------------------------------------------------------------+

Detailed Data-Flow Narrative

1. Ingestion: Telemetry events (lat/long, speed, timestamp, current station status) arrive via RTIS stream or simulated telemetry producer into the Ingestion Service [INFERENCE].
2. State Sync & Caching: Ingestion Service updates current train position in Redis spatial cache and calculates actual arrival/departure time against master timetable [INFERENCE].
3. Feature Generation: Spatial engine queries PostGIS to identify the current block section, section length, downstream train count within 100 km, and weather visibility metrics from OpenMeteo [INFERENCE].
4. ML Inference: Feature vector is passed to the pre-trained LightGBM Regressor. The model predicts remaining sectional run times for all upcoming stations along the train's route [INFERENCE].
5. Confidence Quantification: LightGBM Quantile Loss outputs P10 (optimistic), P50 (expected), and P90 (pessimistic) arrival timestamps for each upcoming station [INFERENCE].
6. Publishing: Predicted ETAs are written to PostgreSQL and broadcast via WebSockets to connected Station Display boards and Control Room dashboards [INFERENCE].

12. Technology Stack

13. AI/ML Justification

AI Component 1: Sectional Run Time & Delay Regressor (LightGBM)

1. Exact Problem Solved: Predicts exact run-time (in seconds) for a train across upcoming track sections under dynamic network conditions [INFERENCE].
2. Input: Current delay (min), distance to target station (km), train priority class (1–5), historical median section speed, downstream train count (density), visibility/fog index [INFERENCE].
3. Output: Predicted section travel time (seconds) and P10/P50/P90 arrival timestamp windows [INFERENCE].
4. Why Simpler Rule Fails: Standard schedules use fixed recovery times. They cannot account for exponential delay buildup when multiple trains enter a congested section simultaneously [PS].
5. Data Required: Historical train movement logs (~500,000 station pass records), line distance schedules, weather logs [INFERENCE].
6. Evaluation Metric: Mean Absolute Error (MAE in minutes) and Mean Absolute Percentage Error (MAPE) against ground truth arrivals [INFERENCE].
7. Failure Handling: If model inference fails or features are corrupt, system gracefully falls back to static schedule + current delay extrapolation (NTES baseline) [INFERENCE].
8. Training Required: Yes, trained offline on historical movement logs [INFERENCE].
9. Fine-tuning Required: No [INFERENCE].
10. RAG Required: No [INFERENCE].
11. Computer Vision: No [INFERENCE].
12. Speech Processing: No [INFERENCE].
13. Forecasting Required: Yes, multi-step time-series forecasting [INFERENCE].
14. Human Oversight: Division train controllers can manually override ETA outputs during major network disruptions (e.g., accidents or line blockages) [INFERENCE].

Where AI Should NOT Be Used

• Timetable Lookup: Exact scheduled arrival/departure times must be queried directly from static database tables, not generated by AI models [INFERENCE].
• Distance Calculations: Track distances between stations must be computed deterministically using GIS spatial math (ST_Length on track linestrings) [INFERENCE].

14. Data Architecture & Offline/Low-Network Design

Database Schema (PostgreSQL/PostGIS)

-- Stations Table
CREATE TABLE stations (
    station_code VARCHAR(10) PRIMARY KEY,
    station_name VARCHAR(100) NOT NULL,
    division VARCHAR(50),
    zone VARCHAR(10),
    location GEOMETRY(Point, 4326) NOT NULL
);

-- Master Train Schedule
CREATE TABLE train_schedules (
    id SERIAL PRIMARY KEY,
    train_number VARCHAR(10) NOT NULL,
    station_code VARCHAR(10) REFERENCES stations(station_code),
    stop_sequence INT NOT NULL,
    scheduled_arrival TIME,
    scheduled_departure TIME,
    distance_from_source_km NUMERIC(6,2)
);

-- Live Telemetry Log
CREATE TABLE train_telemetry (
    id BIGSERIAL PRIMARY KEY,
    train_number VARCHAR(10) NOT NULL,
    timestamp TIMESTAMPTZ NOT NULL,
    current_lat NUMERIC(9,6),
    current_lon NUMERIC(9,6),
    speed_kmh NUMERIC(5,2),
    current_delay_mins INT,
    last_passed_station VARCHAR(10)
);

-- Predicted Dynamic ETAs
CREATE TABLE dynamic_etas (
    train_number VARCHAR(10) NOT NULL,
    station_code VARCHAR(10) NOT NULL,
    p10_eta TIMESTAMPTZ NOT NULL,
    p50_eta TIMESTAMPTZ NOT NULL,
    p90_eta TIMESTAMPTZ NOT NULL,
    updated_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (train_number, station_code)
);

Offline & Low-Network Optimization Strategy

• Client Local Caching: Station IPIS displays and mobile apps store full static timetable and station geo-data locally in IndexedDB / LocalStorage [INFERENCE].
• Delta Sync Payloads: Updates transmitted over WebSockets/MQTT carry only dynamic changes: {"train": "12301", "stn": "NDLS", "p50": "14:25", "delay": 15} (payload size <80 bytes) [INFERENCE].
• Exponential Backoff & Offline Resilience: Mobile passenger app caches the last known ETA and displays a visual indicator ("Updated 4 mins ago") if network connectivity is lost [INFERENCE].

15. Security, Privacy & Governance

• Personal Data Protection: The system tracks train movement, not individual passengers. PNR lookup features (if integrated) sanitize all passenger personal identification before processing [INFERENCE].
• API Security & Rate Limiting: Public endpoints are protected via token-bucket rate limiting (100 req/min per IP) to prevent denial-of-service scraping attacks [INFERENCE].
• Operational Control Security: Dashboard controls for division managers require JWT authentication with Role-Based Access Control (RBAC) [INFERENCE].
• Governance Disclaimer: The prototype system outputs predictions labeled as "Experimental AI Forecast - Subject to Railway Operational Controls" [INFERENCE].

16. MVP Scope (Hackathon Build)

===================================================================
                       HACKATHON MVP SCOPE
===================================================================

[MUST BUILD]
 - Complete dataset ingestion for 1 major corridor (e.g., New Delhi to Howrah - 1,450 km).
 - Static GTFS/CSV schedule loader for all stations on the corridor.
 - Real-Time Telemetry Simulator (streams live GPS updates for 10-20 concurrent trains).
 - LightGBM Dynamic ETA ML Model predicting station arrival times.
 - Interactive Leaflet GIS Map tracking trains live with color-coded delay status.
 - Passenger ETA view with P10/P50/P90 prediction intervals.
 - Controller Dashboard showing section congestion heatmaps.

[SHOULD BUILD]
 - Weather API Integration (OpenMeteo) injecting real-time fog/rain metrics.
 - Station IPIS Electronic Display Board simulation component.
 - Delay Push Notification trigger simulation.

[NICE TO HAVE]
 - Synthetic Speed Restriction (TSR) live event injector.
 - Multi-lingual passenger view (English + Hindi).

===================================================================
                  OUT OF SCOPE (PRODUCTION ONLY)
===================================================================
 - Direct hardware integration with physical ISRO RTIS locomotive devices.
 - Direct database integration with CRIS COA internal servers.
 - Pan-India scale (all 13,000+ daily trains running simultaneously).
 - Automated physical platform allocation signal interlocking systems.
===================================================================

17. Live Demo Simulation Plan

To present a compelling live demonstration without requiring live CRIS production credentials, the team will execute a Physics-Based Event Simulator [INFERENCE]:

1. Simulated Route: New Delhi (NDLS) to Howrah Junction (HWH) covering major junctions (Kanpur Central, Prayagraj, Pt. Deen Dayal Upadhyaya) [KNOWN].
2. Telemetry Streamer: A Python background worker publishes RTIS-compliant GPS messages to Redis every 5 seconds, advancing virtual trains along realistic spatial paths [INFERENCE].
3. Live Injection of Real-World Bottlenecks (The Demo Pitch):
   • Step 1: Show Train 12301 (Kolkata Rajdhani) running on-time with ETA at Kanpur Central shown as 21:35 [INFERENCE].
   • Step 2: Inject a sudden bottleneck event: "Unscheduled Freight Stoppage at Bhaupur Section" + "Heavy Fog Visibility <50m" [INFERENCE].
   • Step 3: Observe the Naive NTES model: Still predicts 21:35 because the train hasn't reached the next station yet [INFERENCE].
   • Step 4: Observe OUR System: Immediately recalculates ETA to 22:12 (P50) with P10-P90 range (22:05–22:25), updating the Station IPIS display and Controller Map in real time [INFERENCE].

18. Implementation Roadmap

Target Completion Deadline: 30 September 2026 [PS]

Phase 1: Research & Data Prep (Weeks 1-2) | Deadline: Sep 12, 2026
 - Clean Kaggle/data.gov.in timetable datasets.
 - Extract GeoJSON spatial coordinates for test corridor.
 - Train baseline LightGBM model on historical delays.

Phase 2: Core Backend & Ingestion Pipeline (Weeks 2-3) | Deadline: Sep 19, 2026
 - Build FastAPI microservices & PostgreSQL schema.
 - Implement Redis stream buffer and Telemetry Simulator.
 - Integrate LightGBM inference pipeline into backend.

Phase 3: Frontend & Integration (Weeks 3-4) | Deadline: Sep 25, 2026
 - Develop Next.js Passenger App & Controller Dashboard.
 - Wire WebSockets for real-time station display updates.
 - Perform end-to-end simulation testing & UI polish.

Phase 4: Final Validation & Demo Prep (Final Week) | Deadline: Sep 30, 2026
 - Verify prediction MAE against held-out historical logs.
 - Record demo walkthroughs and finalize submission dossier.

19. Testing & Validation Plan

20. Risk Register

21. Cost & Scalability

Hackathon Prototype Cost

• Cloud Infrastructure: $0 (Free tiers on Vercel, Render, ElephantSQL / Render PostgreSQL) [INFERENCE].
• Data & APIs: $0 (OpenMeteo free tier, OpenStreetMap, Kaggle public datasets) [INFERENCE].
• Total Hackathon Cost: ₹0 / $0 [INFERENCE].

Production System Cost (Indian Railways Scale)

• Compute: Kubernetes Cluster (EKS/GKE or CRIS On-Prem) - 16 Nodes (64 vCPU, 256 GB RAM) to serve ~13,000 trains and 100,000+ concurrent app connections [INFERENCE].
• Database: Managed Multi-AZ PostgreSQL Cluster + Redis Cluster [INFERENCE].
• Bandwidth & Satellite Link: Existing ISRO GSAT/RTIS infrastructure [RESEARCHED].

22. Differentiation

23. Future Scope

1. Integration with Kavach Automatic Train Protection (ATP): Ingest direct cab-signaling telemetry for meter-level speed profiling [RESEARCHED].
2. Automated Platform Re-allocation Engine: Recommend dynamic platform changes at major junctions when incoming train ETAs conflict [INFERENCE].
3. Driver Advisory System (DAS): Provide eco-driving speed recommendations to loco pilots based on forecasted downstream delays to conserve traction power [INFERENCE].

24. Assumptions & Open Items Log

Consolidated Assumptions [ASSUMPTION]

• [ASSUMPTION-1] A 4–6 student team has access to standard Python/Node development machines and cloud free-tier hosting.
• [ASSUMPTION-2] A physics-based telemetry simulator is acceptable for SIH evaluation provided open historical schedules are real.
• [ASSUMPTION-3] Synthetic injection of Temporary Speed Restrictions (TSRs) accurately mirrors division caution orders.

Consolidated Open Items Needing Validation [NEEDS VALIDATION]

• [NEEDS VALIDATION-1] Official CRIS permission requirements for production REST API consumption by third-party apps.
• [NEEDS VALIDATION-2] Exact update latency and packet loss rate of ISRO RTIS satellite terminals in dense Himalayan/tunnel routes.

Final Recommendation

The team MUST SOLVE this problem. It addresses a real-world national challenge affecting millions of daily commuters [PS]. The optimal strategy is a Hybrid LightGBM + Section Congestion Regressor demonstrated on a key high-density corridor (New Delhi – Howrah) with a physics-based telemetry simulator [INFERENCE].

Recommended Stack

Next.js 14, Tailwind CSS, Leaflet.js, Python FastAPI, PostgreSQL + PostGIS, Redis Streams, LightGBM, Docker [INFERENCE].

Biggest Dependency

Availability and clean formatting of historical train schedule and station coordinate data [INFERENCE].

Biggest Risk

Judges suspecting simulated real-time data is being passed off as real CRIS production feeds [INFERENCE].

Biggest Technical Challenge

Real-time feature calculation of downstream section congestion density across multiple moving trains [INFERENCE].

First 5 Actions

1. Download and clean the Kaggle Indian Railways station & schedule dataset [INFERENCE].
2. Build the PostgreSQL + PostGIS spatial schema for station coordinates and track geometries [INFERENCE].
3. Develop the Python Telemetry Simulator to stream RTIS-like GPS points along the NDLS–HWH corridor [INFERENCE].
4. Train the LightGBM Regressor on historical delay features [INFERENCE].
5. Wire the FastAPI WebSocket server to update the Next.js Passenger & Controller UI in real time [INFERENCE].

Validation Before Coding

Verify that the selected historical dataset contains valid arrival/departure timestamps across intermediate stations for training [INFERENCE].

Buildability Score /100

92/100 (Extremely high feasibility within hackathon constraints using open-source tools and simulated streams) [INFERENCE].

Confidence

High (Strong alignment between problem requirements, data availability, and ML methodology) [INFERENCE].

Research Sources

1. Press Information Bureau (PIB), Ministry of Railways: Real Time Train Information System (RTIS) (2020/2023). https://www.pib.gov.in/newsite/PrintRelease.aspx?relid=200405. Supports claim regarding ISRO GSAT/GAGAN satellite tracking integration with COA. [Official Government Source]
2. Centre for Railway Information Systems (CRIS): Control Office Application (COA) System Overview. https://cris.org.in/loadpage?page=proCOA. Supports claim regarding divisional control room automation and station data logger integration. [Official Organization Documentation]
3. PyPI Python Repository: ntes-client - Unofficial Client for National Train Enquiry System (2026). https://pypi.org/project/ntes-client/. Supports claim regarding programmatic access to NTES train running status. [Open Source Documentation]
4. ResearchGate / IJEAT: Train Delay Prediction in Indian Railways through Machine Learning Techniques (Arshad & Ahmed, 2019/2022). https://www.researchgate.net/publication/332113402_Prediction_of_Train_Delay_in_Indian_Railways_through_Machine_Learning_Techniques. Supports claim regarding Random Forest, XGBoost, and Neural Network performance on train delay regression. [Academic Publication]
5. SIH Buddy Catalogue: SIH 2026 Problem Statement Evaluation - SIH26028. https://sih-buddy.vercel.app/. Supports claim regarding problem score and hackathon buildability. [Secondary Analysis Source]