STEP 1: Lock the geography (do this first — everything else depends on it) ✅
Pick ONE real Indian Railways division to base the whole project on (so your data isn't floating/generic).
- Do: Just decide — (like Central Railway - Mumbai division).
- Output needed from you: just tell me the division name, or say "you pick."
STEP 2: Find these answers by internet search or if you could talk to someone (i’ll do from my side talking to my relative) ⭐ IMP! ✅
Ask these specific questions, write down whatever he says even if it's rough/informal:
- When there are multiple pending maintenance issues (track/signal/electric), how do real teams actually decide what gets fixed first?
- Is there any formal severity/priority classification used in practice (like Priority 1/2/3, Critical/Major/Minor)?
- Roughly, how far in advance are maintenance blocks normally planned — days? weeks? Is there a "weekly/monthly" planning cycle in practice?
- What usually causes conflicts between departments wanting the same time window?
Any real terms/jargon he uses that we should reflect in our project (adds authenticity).
imp images for better understanding:
STEP 3: Search for existing datasets (Kaggle + Hugging Face + government sources)
What we're actually hunting for, and why:
# | Data | What it does in our system | Without it we… |
1 | Train timetable | Tells us when the track is free. This generates candidate windows for the AI while avoiding scheduled train movements. | …have no windows to schedule into. |
2a | Section / corridor master data | Static infrastructure data: section names, directions, line categories, number of lines, and electrification status. | …can't determine where a block can physically happen. |
2b | Conflict / adjacency rules | Rules derived from the section data to identify which blocks conflict or restrict each other. | …can't accurately model infrastructure conflicts. |
3 | Maintenance tasks & defects | The work queue to prioritise — the actual maintenance requirements given to the AI. | …have nothing to prioritise. |
4 | Historical block records — synthetic, schema-grounded | Synthetic operational records based on the real BDMS field structure (Block Type, Status, COA ID, Reason Code, etc.) for training, testing, and validation. | …can't realistically train or test the system against block outcomes. |
5 | Goods / freight forecast | Accounts for freight movements that consume otherwise usable track windows. | …miss a stated PS requirement. |
6 | National statistics | Used only for context and impact metrics (e.g., track length, availability). Not used by the scheduling engine. | …have a weaker impact/pitch slide. |
7 | Machine / crew resource pool — synthetic | Tracks availability of scarce maintenance machines and crews (BCM, tampers, PQRS, etc.) and their required working durations. | …could schedule multiple jobs requiring the same unavailable machine. |
8 | Pre-committed corridor block calendar | Captures pre-approved recurring block windows already reserved in the annual working timetable, separate from ad-hoc train schedules. | …could treat already-reserved windows as available for competition. |
9 | Seasonal / working-season constraints | Defines which work types can be scheduled during specific months or seasons, including monsoon restrictions for heavy machine work. | …can't properly plan across the required monthly horizon. |
theory
Just search these terms yourself and tell me what you find (even if nothing relevant comes up — that's useful info too):
On Kaggle (kaggle.com/datasets, search bar):
railway maintenance
train delay India
railway defects
train schedule dataset India
On Hugging Face (huggingface.co/datasets, search bar):
railway
infrastructure maintenance(low expectation here, just checking)
On Google (general):
Indian Railways open data portal
data.gov.in railways
Indian Railways Year Book statistics PDF
- Output needed from you: links/screenshots of anything that looks even slightly related, or just tell me "found nothing useful" if that's the case.
STEP 4: Search for the technical/domain reference documents (grounds your synthetic data in reality)
Search these one at a time, just skim results, save anything that looks official/detailed:
RDSO track defect classification manual
Indian Railways permanent way manual
Ultrasonic Flaw Detection rail defect Indian Railways
IRICEN track maintenance guidelines PDF
signal maintenance manual Indian Railways S&T defect
Indian Railways Working Time Table [your chosen division] PDF
- Output needed from you: any PDFs/pages you find, even partial ones — screenshots are fine, same as you did with BDMS.
STEP 5: Academic literature check
To see if this exact problem has been studied elsewhere:
railway maintenance window scheduling optimization research paper
track possession planning optimization
- Search on Google Scholar (scholar.google.com) instead of regular Google for these — it's specifically for research papers.
- Output needed from you: paper titles/links, doesn't need to be read in depth, just flag them.
STEP 6: Bring it all in one place (here in notion make your individual sections and put every thing!!)
Once you've got whatever you found from steps 1-5 (doesn't need to be complete — partial is fine), bring it back and I'll:
- Fill gaps where research came up empty (I'll search too)
- Finalize the exact data schema together
- Lock the MCDA scoring formula using your dad's real input
- Then we start Phase 1 coding for real
bdms schema and fields
This is very useful — you've actually got the real manual now, and it hands you exact field names, which is better than anything I could infer from search snippets. Let me pull out what matters for your build.
Real field names for your Block Demand schema (use these instead of my earlier guesses)
From the actual Power Block Request form:
Power Block Date
Depot Incharge
Power Block Type(dropdown — e.g. Normal)
COA Block Section
Direction
COA Line
Carrier
Traffic Block required?(Y/N)
Type of Block required
Train Allowed Upto?
- Tower Wagon sub-fields:
Entered At,Exit,Offering,Moving,Arrived at site
From the demand lifecycle table:
Block Section/Station,Sub Section,Direction,Line,Approval Start Time,Approval End Time,Status,COA ID
Demand Start Time,Demand End Time
PB Granted Time(From/To),Permit to Work(Issued Time, Returned Time)
Block type is literally binary in the real system, and this matters for your scheduler constraints:
"Major: Traffic Blocks for longer duration of planned works. Regular: Traffic Blocks for day to day routine track maintenance works."
That maps directly onto the "1×4hr or 2×2.5hr" rule — use
block_type ∈ {Major, Regular} as a real field, not something you invented.Confirms the Integrated Block mechanism exactly
Assistance Required (dropdown: ASAM, BTN, ENGG, OHE, SNT) + Integrated Block? (Yes/No) — so a demand explicitly declares which other department it needs, and there are colour-coded block categories: TRD Blocks, Ongoing Blocks, S&T Blocks, Other Blocks. This is a real categorical field you should replicate in your dataset (initiating_dept ∈ {ENGG, OHE/TRD, SNT, ASAM, BTN}).Confirms the report types verbatim (use for your "why this matters" slide)
Traffic Block Status, Rolling Block Program, Integrated Blocks – No Associated Block Demanded, Approved but Not Granted, Extended Blocks, Spilled Over/Burst Blocks — filterable by Railway, Division, Date range, Sub-Section, Block Section/Station, Status, Rolling Block (Period-wise), Shadow/Integrated Blocks, Reason Code, Organization.Notably there's a real
Reason Code field for withdrawn/rejected blocks — worth adding to your Sanctioned Blocks table so your conflict-resolution demo can show why something got rejected, not just that it did.So, updated first step: before your team splits into pairs, spend 10 more minutes replacing the schema field names from my earlier answer with these real ones above — it's a small change now, expensive to change later once code is written against it. Want me to rewrite Section 4 of the build-plan file with this real schema so it's the single source of truth your team codes against?
route data json zips
I dug into both archives. Here's exactly what's inside and where it points.
Archive 1 (1787740612443_archive__1_.zip) — three train-category files
EXP-TRAINS.json— 2,533 Express trains
PASS-TRAINS.json— 4,545 Passenger trains
SF-TRAINS.json— 1,412 Superfast trains
Each record:
trainNumber, trainName, route, runningDays (day-of-week flags), and a full trainRoute array with every stop's arrival/departure time and distance.Archive 2 (1787740612446_archive.zip) — three linked files
stations.json— 8,990 stations as GeoJSON points, each withcode,name,zone,state,address
trains.json— 5,208 train routes as GeoJSON LineStrings, withnumber,zone,from/to_station,departure,arrival,duration, seat-class flags
schedules.json— 417,080 individual station-stop records (train_number,station_code,arrival,departure,day)
Which division is this for? None — it's nationwide, not division-specific
I cross-referenced every station code from Archive 1's routes against Archive 2's zone data. The result:
Zone | Stop count |
NR (Northern) | 8,834 |
WR (Western) | 6,469 |
NWR (North Western) | 5,991 |
SCR (South Central) | 5,935 |
SWR (South Western) | 5,728 |
SR (Southern) | 5,511 |
NER, ECR, WCR, ER, NFR, CR, SER, NCR, SECR | 1,700–4,200 each |
Every one of India's 17 zones is represented — this is a national dataset, most likely scraped from a public train-enquiry source (it matches the shape of the open "Indian Railways Dataset" on Kaggle I flagged earlier). It's not scoped to Central Railway or any single division, even though your BDMS research is Central-Railway-anchored.
How this maps to your project — and what to do with it
This is exactly your Section Traffic Profile and Section Master data, just not pre-filtered. Two things to do:
1. Pick one zone/division to scope your demo around (this was already a Day-1 decision you owe yourselves). Given your BDMS research was Central Railway-specific, I'd pick CR (Central Railway) — it only has 2,123 stop mentions here, small enough to hand-curate into 10–15 realistic sections, and it directly matches the "BDMS already live on CR" narrative in your pitch.
2. Derive real hourly traffic density per section from
schedules.json — group stops by station_code + hour-of-day, count trains, and that becomes your real (not fabricated) low-traffic-window signal for the optimizer, instead of a made-up timetable.Want me to write the filtering script now — pull just Central Railway stations/trains out of these three files and produce a clean
section_traffic_profile.csv your AI/backend pair can load directly into Day 2's work?how cp-sat schedule things
The system doesn't "know" or "feel" that a rail fracture is dangerous the way a human engineer does. Instead, it translates human language and request forms into numbers using three core techniques:
1. Structured Data Fields (Dropdowns & Standard Codes)
In real railway apps like BDMS, requests are rarely just empty text boxes. Depot Incharges select from standardized dropdowns:
- Department:
ENGG
- Asset Type:
Track / Rail
- Defect Category:
IMR (Immediate Removal Fracture)
The system bypasses reading text entirely for these fields—it receives exact system code IDs (e.g.,
DEFECT_CODE_402).2. Domain Lookup Tables (How Words Become Numbers)
Railway experts pre-program a Mapping Table (dictionary) directly into the system's database. This table acts as the system's "domain knowledge":
Defect Code / Keyword | Department | Mapped Severity | Reason / Rule |
IMR_RAIL_FRACTURE | ENGG | 10 | Derailment risk |
OHE_CANTILEVER_FLASH | TDMS | 10 | Power failure / line down |
TRACK_CIRCUIT_FAIL | SNT | 9 | Signal turns red / stops trains |
ROUTINE_TAMPING | ENGG | 3 | Preventive maintenance |
STATION_LAMP_REPAIR | SNT | 1 | Non-operational |
When a request arrives with
IMR_RAIL_FRACTURE, the system does a simple database lookup and instantly assigns Severity = 10.3. NLP & Keyword Extraction (For Free-Text Description)
If an engineer types a free-form comment like "Crack noticed near Km 432/11 on mainline, speed restricted to 20 kmph", the system uses Natural Language Processing (NLP) or keyword matching:
- Entity Extraction: It scans for key domain terms:
"Crack"$\rightarrow$ Flagged as Track Defect"Mainline"$\rightarrow$ Flagged as High Density Route"speed restricted to 20 kmph"$\rightarrow$ Flagged as Active Speed Restriction (TSR)
- Rule Trigger: The system sees
Active Speed Restriction = Trueand automatically bumps the urgency score to 10.
Summary Flow
Human Input ("Rail fracture near Km 432") ↓ NLP / Dropdown Mapper ↓ Identifies Code: "IMR_RAIL_FRACTURE" ↓ Database Lookup Table ↓ Numerical Output: Severity = 10 (Feed into CP-SAT Engine)
The system simply relies on human domain experts who built the lookup table beforehand to know that
IMR_RAIL_FRACTURE = 10.Yes, one more thing. Like when a block is scheduled and there is a block on a line, then definitely trains are diverted on other tracks. So, is this system handles that thing?
Yes, this is exactly the kind of edge-case question the SIH judges (who are actual railway officers) will test you on.
When a maintenance block is granted on a double-line section (for example, the UP line is closed), the Section Controller usually implements Temporary Single Line (TSL) working on the other line (the DOWN line), meaning both UP and DOWN trains take turns using the single open track.
Here is exactly how your system handles this, and the boundary between your AI and the existing Railway systems:
1. What Your AI System Does (The Planning Phase)
Your AI system does not dynamically route or drive the trains—that is the job of the Control Office Application (COA). However, your AI must account for the capacity drop before approving the block.
When your CP-SAT solver looks for a 4-hour window, it doesn't just look for an empty track. It runs a Capacity Constraint Check:
- Normal Capacity: A double line might handle 6 trains per hour.
- TSL Capacity: During a block, running trains in both directions on one line drops the capacity to, say, 2 trains per hour.
- The AI Decision: The AI checks the COA train timetable. If only 1 or 2 trains are scheduled to pass through during that 4-hour window, it approves the block, knowing the single open line can handle the diverted traffic. If 5 trains are scheduled, the AI rejects the window because diverting them would cause a massive traffic jam, and instead searches for a late-night window.
2. What COA Does (The Execution Phase)
Once your AI generates the optimized schedule and the Chief Controller clicks "Approve," that schedule is pushed to the Control Office Application (COA).
From there, the existing CRIS infrastructure takes over:
- COA alerts the Section Controllers.
- The Station Masters issue the physical diversion authorities (like the T/A 912 forms for Temporary Single Line working) to the Loco Pilots.
- COA automatically updates the National Train Enquiry System (139 / NTES) so passengers see the expected delay.
How to Pitch This (The "Integration" Slide)
If a judge asks: "Does your AI reroute the trains when you shut down a line?"
Your Answer:
"Sir, we purposely kept dynamic train rerouting out of the AI's scope to respect the existing COA architecture. Our AI performs 'Capacity-Aware Scheduling.' It knows that blocking the UP line forces Temporary Single Line working on the DOWN line. Therefore, our constraint solver ensures that a block is only scheduled if the remaining line's reduced capacity can handle the forecasted COA train load. Once scheduled, the actual diversion execution remains inside COA where it belongs."
Judges love this answer because it proves you aren't trying to overwrite their billion-dollar COA system with a hackathon script; you are just feeding it smarter, capacity-aware data.