A live dot on a map proves very little by itself. An operator may need vehicle positions, predicted arrivals, service alerts, boarding notifications, performance evidence, or a Bus Open Data Service feed. Each outcome needs different data, interfaces, and operating controls.
Define the decision before comparing products. This guide sets out what to specify and how to pilot it. MoveCore does not provide live vehicle tracking today.
Separate the capabilities
Ask suppliers to state which of these are live, included, optional, or unavailable:
| Capability | Practical test |
|---|---|
| Automatic vehicle location | Can the operator see the correct active vehicle and journey? |
| Arrival prediction | Does the system calculate and update expected arrival times at relevant stops? |
| Passenger view | Can passengers reach the information without an operator-only account? |
| Service alerts | Can authorised staff publish a delay, cancellation, or route change? |
| Boarding notification | Does a separate event tell an authorised recipient that a pass was scanned? |
| Historical analysis | Can the operator review route adherence, gaps, and data quality after the journey? |
| Open-data feed | Does the product publish the required standard and pass the receiving service’s checks? |
Do not treat one capability as evidence of another. A GPS position does not automatically create a reliable ETA. A scan event is not a vehicle-location feed. An operator dashboard is not passenger information.
Define the location data contract
For local bus data in England, the Department for Transport’s SIRI-VM technical guidance shows the level of precision involved. It connects a position to operator, line, direction, journey, vehicle, timestamp, and timetable data. It also specifies update and heartbeat expectations for Bus Open Data Service feeds.
Even when BODS does not apply to your service, use the same discipline:
- identify the active service and journey;
- define the coordinate and timestamp source;
- record update frequency and expected delay;
- distinguish scheduled from predicted times;
- define what “vehicle unavailable” means;
- keep identifiers stable enough to join location and timetable data; and
- state how duplicate, late, or impossible positions are handled.
Ask for raw examples. A screenshot of a moving marker cannot show whether the data is current, correctly matched, or complete.
Specify the passenger information
Decide exactly what a passenger should see:
- current vehicle position, predicted arrival, or both;
- the age of the last update;
- the scheduled time when no prediction is available;
- confidence or uncertainty where the product supports it;
- cancellation, diversion, and service-change messages;
- an accessible fallback when the live interface is unavailable; and
- a clear distinction between “not yet reporting” and “service not running”.
For in-scope local services in Great Britain, the accessible information regulations guidance sets separate requirements for audible and visible route and stop information. The phased dates depend on when a vehicle was first used on local services. A passenger tracking page is useful only if it meets its own purpose; it should not be presented as a substitute for the onboard duty.
Design for failure
Run the pilot through bad conditions, not only a prepared demonstration:
- Start a journey with the wrong vehicle or route selected.
- Interrupt the device’s data connection.
- Pause location permission or close the driver application.
- Send delayed and out-of-order positions.
- Resume after a device restart.
- End the journey and confirm that the public view stops updating.
For each failure, define what the driver, operator, passenger, and support team see. The system should expose stale or missing data instead of presenting an old position as live.
Confirm battery use, device mounting, charging, replacement, mobile-data responsibility, supported operating systems, and whether the driver must interact with the device while working. A software subscription does not remove the hardware and operational dependencies.
Protect workers and passengers
Vehicle location can become personal information when it identifies a driver or another worker. The ICO says organisations using vehicle monitoring must inform workers and passengers, and that private use will rarely justify continued monitoring. See the ICO’s guidance on monitoring work vehicles.
Before collection starts:
- document the purpose and lawful basis;
- decide whether the same outcome needs less precise or less persistent data;
- give clear privacy information;
- restrict who can see live and historical positions;
- define retention and deletion;
- separate working and private use where relevant;
- assess any linkage to named passengers or boarding events; and
- record supplier access, incident handling, and data-return terms.
Do not use a tracking feature for a new purpose merely because the data already exists. Reassess the legal basis, necessity, proportionality, and notice.
Run a route-level pilot
Choose a route with the devices, signal conditions, stops, and staff expected in live operation. Record:
- the proportion of the journey with current, correctly matched positions;
- update latency and the age shown to passengers;
- arrival-prediction error at selected stops;
- missing, duplicate, and stale updates;
- the time needed to diagnose a failure;
- passenger access and accessibility problems; and
- driver actions required before, during, and after the journey.
Set the acceptance threshold before the pilot. If a supplier cannot expose enough data to measure the requirement, mark it untested rather than passed.
Where MoveCore stands
MoveCore currently records pass-validation events and presents scan activity to authorised operators. It does not collect live vehicle positions, calculate arrival times, publish a passenger tracking view, send passenger alerts, or provide a SIRI-VM feed. Live tracking remains a roadmap item.
If live tracking or BODS vehicle-location publishing is a current requirement, choose a product that demonstrates it now. If your immediate need is digital period passes, QR validation, and boarding records, use the transport software buyer’s guide to test that narrower workflow.