Checklist for piloting RTLS in metro

Indoor location pilots fail for much the same reasons every time, and almost none of them are technological. They fail because nobody checked whether the access points would do the job, because “it works” was never defined, or because the works council found out too late.

This is the list of what needs settling before you start, ordered by when it needs settling.

Before signing anything

1. How many access points can enable FTM

This is the check that decides the entire project, and it is done with an inventory, not a pilot.

Time-of-flight ranging needs the access point to support the FTM protocol and have it enabled. Most professional 802.11ac and 802.11ax equipment supports it, but it ships disabled and has to be enabled from the controller.

Ask your network team for the model and firmware list per station. If the answer is that most of the estate does not support it, the conversation changes entirely: either there is a refresh coming, or this is not the right system. Better to know that in week zero.

2. Which terminals are actually in service

Not which terminals are on the inventory: which ones officers are carrying on a Saturday night shift.

You need Android 10 or later with a compatible chipset. Fleet heterogeneity is normal and not a problem if it is known: an approved model matrix is closed by testing them, and those that do not qualify are either replaced or left outside the pilot scope.

3. What operational decision you will make with the data

It sounds like a consultant’s question, but it is the one that stops you buying accuracy you do not need.

If the decision is “where do I send support and which entrance do they use”, knowing the zone and the direction of travel is enough. If the decision requires distinguishing two positions half a metre apart, you are in a different problem and need a different technology.

Write it in one sentence. That sentence determines the acceptance criteria.

4. Which system it will integrate with

One more portal nobody looks at changes nothing. The data has to reach the system your people already work in: the incident manager, the operational map, the dashboard.

Find out beforehand whether that system accepts API or webhook input, and who maintains it. If it is an external integrator, bring them into the conversation from the start.

Before installing

5. Talk to worker representatives

Beforehand. Always beforehand.

Locating personnel means processing personal data in an employment context, and most European jurisdictions require prior, explicit and unambiguous information to staff and their representatives. Beyond the legal obligation, it is what decides whether the system gets used or the phones stay in the locker.

The framing matters: this is not “we are going to know where you are”, it is “if something happens to you in a tunnel, we want to get there sooner”. But that only holds if the system afterwards does exactly that and nothing else.

6. Agree acceptance criteria in writing, with numbers

This is the check that prevents the argument at the end. Without agreed numeric thresholds, “it worked” is an opinion.

Minimum to agree:

| Criterion | Threshold | |---|---| | Mean accuracy in station | value in metres | | Publication latency | value in seconds | | Availability during the pilot | percentage | | Concurrent terminals | number | | Terminal battery life | a full shift without recharging | | Critical security findings | zero open at closure |

And define how each one is measured: against which reference points, across how many stations, in which time bands and who signs the record.

7. Choose the scope well

One line or a set of stations. Not a single station — it produces no extrapolable evidence — and not the whole network, which fits neither the calendar nor the budget of a pilot.

Pick the line with the most representative mix: large and small stations, an interchange, a problematic stretch. If you only pick the easy parts, the result will not help you decide.

8. Clear the cybersecurity gate early, not late

Your systems team will assess it either way. Have them do it in week one rather than week ten.

What to ask the supplier for: architecture and data flows, identity and access controls, encryption, audit trail, recent external audit results, vulnerability management process and an incident notification commitment. Developed further in what NIS2 requires.

During the pilot

9. Measure against known reference points

Accuracy is not verified by looking at whether the dot on the map “seems about right”. It is verified with reference points marked on the layout, walked to a script, with a record of what the system reported at each instant.

Ideally blind or single-blind: whoever walks the route cannot see the system’s reading while taking it.

10. Measure in the bad conditions, not the good ones

An empty platform at eleven in the morning is not the scenario that matters. The ones that do:

• Rush hour, with a crowded platform absorbing signal.
• With a train stopped in the station taking up half the level.
• In stretches where only one access point is in view.
• At transitions between levels and in interchange corridors.

If the system holds up there, it holds up everywhere else. If it is only tested in favourable conditions, the resulting number is useless for deciding.

11. Check what the system does when it does not know

This is the test that says the most about a system’s quality, and almost nobody runs it.

Walk into a dead zone and watch what the portal shows. Does it flag the reading as degraded? Does it warn that the terminal has not reported for a while? Or does it keep showing the last known position as though it were current?

A system that does not distinguish between “is here” and “was here eight minutes ago” is worse than no system, because it gives you confidence in false data.

12. Test battery life on a real shift

Not in a two-hour lab test. A full shift, with the terminal doing its usual work on top of reporting position.

If the phone does not make it to the end of the shift, the system will not be used, however accurate it is.

At closure

The pilot’s deliverable is not a pretty demo. It is a report with measured numbers against the agreed criteria, the conditions under which they were measured, and any non-conformities found with their action plan.

That document is what your committee can take into the procurement file. Without it, the decision falls back on impressions.

Further reading

• What a deployment actually requires, with the four phases and deliverables
• RTLS with tags, or on smartphones