Inspiration
Every day, Kochi Metro Rail Limited (KMRL) has to decide which trainsets go into revenue service, when they run, and which stay back for maintenance. Doing this by hand means juggling passenger demand, safety headways, turnaround times, and Certificate of Fitness (CoF) status all at once, which is slow and hard to audit. We picked this up from the Government of Kerala problem statement FSJ28-INTERN-060 and asked: what if planners got an AI-generated draft schedule that is already conflict-free, and still had the final say?
What it does
MetroMind is a web-based decision-support platform for KMRL operations staff.
- Forecasts demand by station, direction, time window, and weather using an XGBoost model.
- Generates conflict-free daily timetables and assigns trains across the 25-trainset fleet (TS-01 to TS-25), automatically excluding trains under maintenance.
- Enforces safety rules: a minimum headway floor of 420 seconds (7 min), 3-minute turnaround buffers, and platform capacity limits.
- Keeps humans in control: every schedule goes through a role-based approval workflow (Operations Controller, SADA, with Maintenance Manager and Admin roles). Approvers can approve, reject, or request changes.
- Monitors operations: alerts are evaluated every 30 seconds (SEV1/SEV2/SEV3), with dashboards and downloadable PDF reports.
MetroMind is not a train-control or signalling system. It never touches trains or trackside equipment, and it only uses aggregated ridership data, never individual passenger data.
How we built it
- Frontend: React, with a dedicated console per role.
- Backend: Java 17 / Spring Boot 3.3.4 microservices for users, fleet, maintenance, scheduling, approvals, alerts, and reports.
- Infrastructure: Netflix Eureka for service discovery, Spring Cloud Gateway as the single entry point, and JWT authentication with role-based access control.
- AI service: Python FastAPI (port 8001) serving an XGBoost regressor.
- Data layer: Oracle Database for user data and MongoDB for operational data.
Model details: trained on 277,440 synthetic half-hourly records across 5 stations and 384 simulated operating days, with an 80/20 split. Test results:
- MAE: 41.24 passengers
- RMSE: 61.56 passengers
- R-squared: 0.9649
The most influential feature is the hour of day (about 69.9% of importance), followed by station effects. Post-processing then converts predicted demand into a surge multiplier, recommended headway, and recommended fleet size.
Challenges we ran into
- No public real-world ridership data. We built a synthetic dataset that models diurnal travel curves, Kerala holidays, monsoon weather, and stadium-event footfall. Because of this, our metrics measure fit to the synthetic distribution, not real-world accuracy, and we say so openly.
- Model and runtime feature mismatch. The trained model's one-hot station features didn't perfectly match the stations the runtime accepts. We handled it with feature-column alignment in the inference layer.
- Resilience across microservices. If the forecast service is down, scheduling must not stop. We added timeouts and a fallback that generates timetables from baseline weekday/weekend headway templates.
- Safety-critical constraints. Combining headway floors, turnaround buffers, and maintenance exclusions without producing conflicting train allocations took careful design and collision auto-resolution.
- Integration overhead. Keeping ports, CORS, Eureka registration, and JWT validation consistent across many services during local development.
Accomplishments that we're proud of
- A complete, working pipeline from forecast to timetable to approval, not just a model in isolation.
- A strict human-in-the-loop design: no schedule goes live without SADA approval.
- Graceful degradation, so the system keeps scheduling even when the AI service fails.
- A full IEEE 830-style SRS with API reference, database design, and a risk register.
What we learned
- Designing and securing a distributed Spring Boot architecture with service discovery, an API gateway, and JWT.
- Integrating a Python ML service into a Java enterprise stack.
- Using polyglot persistence (relational plus document store) where each fits best.
- That in safety-critical domains, AI should advise and humans should approve, and that honest reporting of limitations matters as much as accuracy.
What's next for MetroMind
- Retrain on real AFC gate-entry data (the system already logs actuals for this) and extend coverage from 5 stations to all 25.
- Fix the station-feature alignment with a clean retrain, and enable continuous retraining.
- Replace the heuristic assignment with a constraint optimizer for better fleet and mileage balancing.
- Activate the background auto-scheduler for planner-triggered daily runs.
- Containerized deployment and event-driven communication between services.
Log in or sign up for Devpost to join the conversation.