Metro and Passenger
Information Telematics
A full-stack metro tracking system that drives next-train and ETA data onto platform boards and onboard displays, integrates your GTFS timetable with live GTFS-Realtime position, monitors car-by-car occupancy, and feeds the operations control centre over MQTT and WebSocket. Scope runs from the trainborne unit to the control room.
THE CHALLENGEA Train Position Is Worthless Until It Reaches the Right Display at the Right Second
A raw GNSS fix means nothing inside a tunnel where the satellites disappear, and a timetable means nothing once a train runs three minutes late. Passengers on the platform need an accurate next-train countdown, the control centre needs a live picture of every consist, and the displays scattered across the network need to agree to the second. The metro tracking system holds position through tunnels using dead reckoning, reconciles the GTFS schedule against live movement, measures crowding per car, and synchronizes every display with NTP so the whole network tells one consistent story.
Sits inside the Telematics and GPS Tracking stack and shares hardware and platform building blocks with Public Transport Bus Tracking.
WHAT'S INCLUDED
Passenger Information and Train Tracking Stack
Passenger Information System Engine
The PIS engine turns a live train position into a next-train countdown and ETA for every station. It computes arrival predictions per platform, handles short-turns and skipped stops, and pushes the result to platform boards and onboard displays so the number a passenger reads matches the train actually coming.
GTFS and GTFS-Realtime Integration
Your static GTFS timetable feeds the planned schedule, and GTFS-Realtime trip updates and vehicle positions carry live movement. The two are reconciled on the backend so a delayed train updates its predicted arrivals everywhere at once, and downstream apps and third-party feeds consume one standard format.
Display Boards Over RS-485 and Ethernet
Platform display boards and onboard car displays are driven over RS-485 or Modbus on legacy lines and Ethernet where the network supports it. The controller handles the display protocol, brightness, scrolling messages, and audio announcement triggers, so one feed updates LED boards and TFT panels alike.
Car-by-Car Occupancy Monitoring
Crowding per car is measured using weight-based load sensing on the bogie air suspension or IR people counters at each door. The trainborne unit aggregates counts into a load level per car and publishes it so the platform board can tell waiting passengers which car has space before the train arrives.
Trainborne Telematics Unit
The onboard unit runs on STM32 with FreeRTOS, with a u-blox NavIC and GPS receiver for surface positioning, a Quectel EC200 modem for the backhaul, and RS-485 and Ethernet ports for displays and door sensors. It runs the dead-reckoning position estimate that keeps the train located through tunnels.
Control Centre and OCC Feed
Every train position, delay, and occupancy state streams to the operations control centre over MQTT and WebSocket. The feed plugs into SCADA-adjacent dashboards and a dedicated control view, giving controllers a live map of the line, headway gaps, and crowding hotspots in one place.
HOW IT WORKS
From Trackside Position to Platform Countdown
The data path starts under the train and ends on a board a passenger trusts. Every stage is designed so a position fixed deep in a tunnel produces the same accurate ETA as one taken on a surface viaduct, and every display on the line agrees to the second.
Locate Through Tunnels
Where NavIC and GPS are available at the surface the fix is taken directly. In tunnels the system falls back to dead reckoning from wheel odometer pulses and beacon or balise-style references, so the position never goes blind between stations.
Reconcile and Predict
The backend matches live position against the GTFS schedule, recomputes ETA per station, and folds in occupancy from weight sensing or IR door counters. Trip updates go out as GTFS-Realtime and over MQTT to every subscriber.
Drive and Synchronize Displays
Platform boards and onboard displays receive the countdown over RS-485 and Ethernet, all clocked to a common NTP time base so the numbers and announcements stay synchronized across the network.
STANDARDS AND COMPLIANCE
Built to Transit Data and Indian Navigation Standards
GTFS and GTFS-Realtime
The GTFS specification governs the static timetable and GTFS-Realtime governs trip updates, vehicle positions, and service alerts, so your feed stays interoperable with passenger apps, journey planners, and aggregators without a proprietary bridge.
NTP Time Synchronization
The trainborne units, display controllers, and backend are clocked to a common NTP time base. Synchronized time is what lets a countdown on the platform and the announcement onboard stay aligned across an entire line.
NavIC and IRNSS Positioning
NavIC and IRNSS positioning runs alongside GPS for surface segments, which improves fix reliability for Indian metro and suburban networks and aligns the tracking stack with regional navigation policy.
FAQ
Common Questions
How is a train kept located inside a tunnel where GNSS does not work?
At the surface the u-blox NavIC and GPS fix is used directly. Underground the system switches to dead reckoning, integrating wheel odometer pulses against beacon or balise-style position references along the track. The position estimate stays continuous between stations so the ETA never freezes when a train enters a tunnel.
Does it integrate with an existing GTFS timetable?
Yes. Your static GTFS feed is ingested as the planned schedule, and GTFS-Realtime trip updates and vehicle positions are emitted from live movement. The backend reconciles the two, so when a train runs late its predicted arrivals update everywhere, and your passenger apps and third-party feeds keep consuming one standard format.
How is car-by-car occupancy actually measured?
Two methods are supported. Weight-based load sensing reads the air suspension pressure on each bogie to infer load, and IR people counters at the doors count boardings and alightings. The trainborne unit aggregates either source into a load level per car and publishes it to the platform board and the control centre.
What drives the platform and onboard displays?
A display controller drives platform boards and onboard panels over RS-485 or Modbus on older installations and Ethernet where the network allows. One feed updates LED boards and TFT panels, handles scrolling messages and brightness, and triggers audio announcements, all clocked to a shared NTP time base.
How does the operations control centre receive the data?
Every train position, delay, and occupancy state streams to the OCC over MQTT and WebSocket. The feed plugs into SCADA-adjacent dashboards or a dedicated control view, giving controllers a live line map with headway gaps and crowding hotspots in real time.
Why does NTP time sync matter for passenger information?
Displays scattered across a network drift apart without a common clock, so a platform countdown and an onboard announcement can disagree. The trainborne units, display controllers, and backend are synchronized over NTP so every number and announcement stays aligned to the second across the whole line.
Can it work with existing trains and trackside equipment?
Yes. The trainborne unit on STM32 with FreeRTOS exposes RS-485, Modbus, and Ethernet, so it talks to existing display boards, door sensors, and odometer feeds. The unit retrofits onto current rolling stock rather than requiring a full equipment replacement.
Ready to Build Your Metro Passenger Information System?
Share your lines, your display equipment, and how your control centre works today to get a tailored positioning, GTFS-Realtime, and occupancy architecture and a realistic timeline.
Schedule a Free Consultation