this is what we need to build, in long story short:
Replace the manual decision-making steps in the BDMS→COA workflow (what to prioritize, how to resolve conflicts, how to plan ahead) with a data-driven engine, while keeping humans in the loop for final approval!
What is a "block" in railway terms? (the real thing, confirmed from railway sources)
When any department — Engineering (track), Signal & Telecom, or Electrical/Traction — needs to do maintenance work on a track (repairing rails, fixing overhead electric wires, fixing signal equipment, etc.), they cannot do it while trains are running on that section. So they request a "block" — a scheduled window of time where that section of track is taken out of traffic so their crew can safely work.
There are different types, confirmed from Indian Railways' own documentationA line block, or traffic block, blocks a particular track when repair or construction work has to be carried out on the permanent way, points, crossings, interlockings, OHE, or signalling equipment. There's also a specific one for electrical work: a power block is a bar on all traffic using electric traction, for work on the overhead electric (OHE) equipment, and it requires the Traction Power Controller to coordinate exactly when to cut the electricity supply.
OHE - Overhead equipment (uper taare reheti n → to supply high-voltage electrical power (commonly 25 kV AC) to electric trains via a roof-mounted)
Railway rules even specify how long these blocks should be. For track machines, the standard is roughly either one block of at least 4 hours, or two blocks of 2.5 hours, and these engineering maintenance corridor blocks are supposed to be built into the Working Time Tables every year.
So, in plain words: a "block" = a scheduled shutdown window on a piece of track, requested by a maintenance department, approved by railway traffic control, during which trains are held back/rerouted so maintenance crew can work safely.
Why is this a coordination nightmare (which is exactly what the PS is complaining about)?
Three different departments — Engineering (track), Signal & Telecom, and Electrical/Traction — each maintain their own systems for tracking what needs fixing:
- TMS (Track Management System) — tracks track defects, wear, geometry issues.
- SMMS (Signalling Maintenance & Management System) — tracks signal equipment defects.
- TDMS (Traction Distribution Management System) — tracks electric/OHE line defects.
Each of these departments independently decides "we need a block on this section, this day, this time" and requests it. Meanwhile, COA (Control Office Application) — the system that actually tracks live train movement and plans the timetable — is where block availability against actual train traffic is checked. COA is a real, mature, nationwide system: it's implemented across all 68 divisions of Indian Railways to automate control rooms, capture real-time train movements, and provide analytical decision support.
understand some COA stuff
COA is the absolute "nerve center" of train operations across all 68 divisions of Indian Railways. It digitizes the old hand-drawn charts that section controllers used to plot with coloured pencils. It tracks live train movements (near real-time via station data loggers), handles train dispatching, and schedules unscheduled trains
Do we need COA data? Yes, absolutely!
If you schedule a track block without knowing train paths, you will halt major express trains, causing a cascade of delays. Your optimization engine must ingest timetables and goods train forecasts
from a simulated COA database. It uses this to find the "free slots" or "low-traffic windows" where a maintenance block will cause minimal disruption
The problem the PS is pointing at: there's no single brain deciding "given all 3 departments” pending defects/maintenance needs, plus the actual train timetable and goods traffic forecast from COA, what is the OPTIMAL way to schedule blocks across the week/month so that:
(a) critical defects get fixed fast, and
(b) train disruption is minimized ⭐ , and
(c) departments aren't stepping on each other's blocks.
"Right now, each department requests blocks somewhat in isolation, manually, and it's not data-driven or coordinated - which wastes capacity (a block window given for low-priority maintenance while a high-priority defect waits) and causes avoidable disruption.
Now, Based on research, and official confirmation and validation:
ALL usefull Sources & Links that we need ⭐
Economic Times Article (coined the need/demand for this in 2018)
‘block and disconnection management system indian railways’:
official BDMS Rollout published (2025, Sept.) - Rollout! ⭐
Another Rollout Doc Link from Scribd - Rollout ⭐
https://www.scribd.com/document/938691657/BDMS-User-Manual - BDMS Application overview. (official CRIS BDMS User Manual)
BDMS (Block & Disconnection Management System) - this is a real, existing system. From what's publicly indexed, it's a rollout dated around late September 2025,
The Block & Disconnection Management System (BDMS) is a unified digital platform developed by CRIS for Indian Railways to process, monitor, and approve traffic, power, and disconnection blocks in real time
and it appears to be a digital application layer sitting on top of COA for requesting/managing block demands — i.e., it digitizes the process of "department requests a block, gets approved/rejected" instead of doing it manually/on paper.
The PS wants the "AI brain that decides what SHOULD be scheduled and when, based on data across 3 departments" layer — which is a genuinely harder, more valuable, and (as far as I can find in current search results) not something that's been publicly announced as built or deployed. The Economic Times article you found is from 2018 — that's 7-8 years old, which tells you this idea has been floating around Indian Railways for a long time as an aspiration, without a full AI-driven cross-department implementation being announced.
From the letter itself (30.09.2025, Railway Board to all Zonal Railways GMs):
"BDMS application has been developed by CRIS as a unified user interface to TMS, TDMS, SMMS. The application provides a unified digital platform across Engineering, TRD, S&T, and Operating departments for real-time processing, monitoring, and approval of blocks of Traffic, Power, and Disconnection."
And the CRIS internal letter (undated, referencing June 2025) confirms:
"BDMS application has been successfully implemented on all 5 divisions of Central Railway."
And the 30.09.25 Railway Board letter then orders all Zonal Railways to roll out BDMS on all divisions within two weeks, in coordination with CRIS.
What this actually confirms
- BDMS is real, built, and already national. It wasn't just a pilot — Central Railway had it live across all 5 divisions by mid-2025, and the Railway Board ordered nationwide rollout within 2 weeks of 30 Sept 2025. Given it's now August 2026 — 11 months later — you should assume BDMS is live across essentially all zonal railways today, not just Central Railway.
- BDMS is a bigger system than I could confirm earlier through search alone. It's not just a "digitize the request form" tool. It's explicitly described as a unified interface pulling from TMS + TDMS + SMMS, handling real-time processing, monitoring, AND approval of blocks. That directly overlaps with the "integration of maintenance data from TMS, SMMS, TDMS" part of what PS 26027 asks for.
- What's NOT mentioned anywhere in these letters: any AI/ML component, any prioritization logic, any auto-generated optimized scheduling, any criticality scoring. These are pure administrative rollout letters — subject lines are literally "Roll out of BDMS Application" and "Application for Traffic Block/Disconnection Management System." Nothing about intelligence, optimization, or automated scheduling. It reads like a workflow digitization + unification tool: departments submit block requests digitally into one shared system instead of separate silos, and approval/monitoring happens through it.
What this means for your build - the gap is narrower but sharper
Your differentiation is not "integrate TMS/SMMS/TDMS data into one place" — BDMS already did that, nationally, a year ago. If you pitch your project as "we unified the departments' data," a judge who knows about BDMS (and railway-domain judges likely will) will immediately say "that already exists."
Your differentiation is exactly the one thing these letters never mention: the AI/ML-driven prioritization and auto-scheduling brain — taking the now-unified block/defect data (which BDMS already centralizes) and actually deciding, intelligently, what should be scheduled when, based on criticality/urgency/impact, instead of departments just submitting requests that get manually approved.
This is actually a stronger, tighter pitch than before, not a weaker one:
"BDMS (2025, Railway Board mandated, now national) solved the problem of departments requesting and getting blocks approved through one unified system. What it doesn't do — and what our PS is literally asking for — is decide intelligently which requests should be prioritized and how to optimally sequence them across weekly/monthly horizons to maximize asset uptime. That's the layer we're building."
Now based on the actual BDMS application user manual and stuff:
What BDMS actually does (now confirmed, no more guessing)
The flow diagram in "BDMS in COA" doc lays it out exactly:
Demand side (3 departments, 3 separate source systems):
- Engineering dept → raises block demand in TMS
- TRD (Traction) dept → raises block demand in TDMS
- S&T dept → raises block demand in SMMS
All three demands flow into → COA, where:
- Officials can download the demands as PDF/Excel to discuss
- COA does the approval of demanded blocks/disconnections (this is a human approval step, done through the COA interface — NOT an AI decision)
- Once approved, status flows back live to update TMS, TDMS, SMMS
And from the user manual, the actual workflow is:
- Depot Incharge raises a block demand (dropdown: block type, dates, section, etc.)
- Sends it to TPC (Traction Power Controller) for approval
- TPC/CTPC reviews and sends it to COA
- COA either Approves / Sanctions / Rejects
- Once sanctioned, CTPC grants the block to the depot incharge (entering Permit-to-Work time)
- Work happens, block is returned, demand marked Complete
There's also a "Shadow & Integrated Block" feature — if one department's block affects another department's work in the same area/time, they can attach/associate their block to it, so multiple departments can coordinate on a shared block window instead of raising separate conflicting ones. And there's a Reports module with 6 report types: Traffic Block Status, Rolling Block Program, Integrated Blocks, Approved but Not Granted, Extended Blocks, Spilled Over/Burst Blocks.
The critical confirmation
Every single step above is manual, human-decision-driven. Depot Incharge decides what to demand → TPC approves/rejects manually → COA official approves/rejects manually → CTPC grants manually. There is:
- No prioritization scoring anywhere in this workflow
- No automated conflict resolution — the "Shadow/Integrated block" feature is just a manual tagging mechanism so humans can see related blocks, not something that auto-optimizes them
- No AI/ML mentioned anywhere, not even a hint of it
- No defect criticality/urgency data feeding into anything — the block demand form doesn't even reference why the block is needed (defect ID, severity) as a decision input; it's purely date/section/duration/type
- No weekly/monthly auto-generated schedule — it's a reactive, one-request-at-a-time approval pipeline, not a planning/optimization system
This is now 100% confirmed, not inferred: BDMS = digital plumbing + human approval workflow. PS 26027 = the missing intelligence layer on top of that plumbing.
One real design decision this surfaces: should you simulate "integration with BDMS" or "replacement of BDMS"?
Don't replace it — position your system as consuming BDMS-shaped data and adding the missing intelligence layer, the same way COA receives demands from TMS/TDMS/SMMS and adds its own layer (approval). Your system sits at the same architectural position as COA in that diagram — but instead of just "approve/reject," it does "score, prioritize, and auto-schedule across weekly/monthly horizons, and flag conflicts before they become Spilled Over/Burst Blocks."
This is a strong technical narrative for your architecture diagram: TMS/TDMS/SMMS → BDMS/COA (existing, real) → [YOUR AI SCHEDULING ENGINE] → optimized weekly/monthly plan + conflict alerts → back to COA/BDMS for human final approval.
What should we actually build: (JUST THEORY, not final)
The expected output, in plain terms
A system that:
- Ingests maintenance need data — defects and overdue maintenance tasks from the 3 departments (you'll simulate/mock TMS, SMMS, TDMS as data sources — realistic sample data, not real railway data, which you won't have access to).
- Ingests block/corridor availability data — from a mocked "COA-like" source: the train timetable + goods train forecast, so you know which time windows are actually available on which sections without disrupting too much traffic.
- Runs an AI/optimization algorithm that takes all pending maintenance requests + criticality/urgency scores + available time windows, and outputs an optimized block schedule — weekly and monthly — that:
- Prioritizes high-criticality/safety-relevant defects.
- Minimizes overlapping/conflicting block requests between departments.
- Minimizes total train disruption (fewer blocks, or blocks placed in traffic-light windows).
- Maximizes overall asset (track/signal/OHE) uptime.
- A dashboard for railway officials (Section Controller / Divisional Engineer level) to view, adjust, and approve the AI-suggested schedule — because in real infrastructure systems, you never fully remove the human from the loop; you give them an intelligent recommendation they can approve/override.