Three pieces, none of them new to your infrastructure

This is where the technical difference starts. Most Wi-Fi location systems estimate distance from received signal strength (RSSI), which depends on the phone model, how it is held, how many people are around and what stands in between. Metrosafe uses Wi-Fi RTT/FTM: it measures how long the signal takes to travel to the access point and back, and turns that into a distance.

• Three fused sources: Wi-Fi RTT/FTM, cellular and GPS where it surfaces at station entrances or surface sections.
• Dynamic selection: the app picks whichever source has the best measurement quality at each moment, and degrades in a controlled way when none is good, rather than publishing an invented position.
• Power management: duty cycling, batched uploads and background policies so a full shift fits in one battery.
• Offline persistence: whatever cannot be sent is stored and retried. A tunnel with no backhaul does not punch a hole in the history.
• Continuous service: the app restarts itself and publishes its own health telemetry, so the control room knows when a terminal has stopped reporting.

Operating system

Android 10 or later

Radio requirement

Wi-Fi 802.11mc (FTM) on terminal and AP

Publication rate

configurable · 15-30 s recommended

Recommended battery

≥ 4,000 mAh

Fleet management

MDM compatible (optional)

A single distance measurement is not a position. The server combines measurements from several access points using probabilistic filters and, above all, with something no generic system has: the station layout.

• EKF/UKF filters: integrate successive measurements and carry an uncertainty estimate, not just a point.
• Map matching: positions are constrained to the real graph of platforms, concourses, corridors and tunnels. A position that would land inside a wall or across the track is discarded before publication.
• NLOS and multipath detection: when the signal arrives reflected rather than direct, the measurement stretches and lies. Those measurements are detected and downgraded instead of contaminating the result.
• Quality rules: every position is published with quality indicators, so the portal can tell a solid reading from a doubtful one.

The practical effect of constraining to the layout is that the operational error ends up smaller than the instantaneous geometric error of the measurements. The station contributes information the system does not have to guess.

The control room sees positions on a map, along with each terminal’s status and any active alerts. Once the incident is over, the history and event replay remain, so you can reconstruct what happened and in what order.

• Live view with terminal status and alerts
• History and event replay for post-incident review
• User and role management (RBAC) with two-factor authentication
• Audit trail of who looked at what, and when
• CSV/JSON export of the history

The three pieces above cover the station. When an officer boards a train the reference moves and a different answer is needed: the on-board layer, which fits one BLE beacon per carriage and publishes which train, which car and which station they are at.

It is optional and gets added when on-board service justifies it. The beacons sit inside the rolling stock — adhesive, battery-powered and fitted during a depot visit — so the network infrastructure is still untouched.

Full detail in On-board tracking.

The portal does not aim to replace the operator’s incident management system or its operational map. Positions are published over a REST API and webhooks so the data lands where the work already happens.

Full detail of endpoints, data contracts and exports in API & integration.