A destination sign showing the wrong route. A bus that never appears in the real-time app because the system doesn't know which run it's actually running. A driver who has to guess which service they've been handed today. These are small failures on paper, but they're exactly the kind of thing that erodes trust in public transport — for riders checking an app, and for controllers trying to manage a network in real time.
At the root of all of them is the same operational question: is this vehicle correctly paired to its service? Getting that pairing right, every time, without depending on a single point of failure, is what Pysae calls vehicle-to-service pairing: turning a raw GPS position into a service someone can actually be held accountable for. It's built as four layers, each one catching what the previous layer might miss.
Layer 1: Pre-assignment — the vehicle already knows before it leaves the depot
The first layer happens before a single wheel turns. Once the depot has assigned services to vehicles for the day, each on-board unit reads its own assignment the moment it powers on and labels itself — service number, route, destination — with no manual step required. This works even offline: a vehicle that starts its shift with no connectivity yet still knows exactly what it's supposed to be doing.
This auto-labeling from planning removes the most common source of error: a manual step that depends on someone remembering to configure the right run on the right vehicle, every single morning, across an entire depot.
Layer 2: Central override — dispatch keeps the last word
Plans change, at any moment. A reserve vehicle gets pressed into service, a reinforcement run gets added, two services get swapped between vehicles at short notice. When that happens, the controller needs to be able to assign or reassign a vehicle to a service right away — without waiting for the driver to do anything, and without a re-plan cycle.
With central labeling, a controller reassigns a vehicle to a different service directly from the control room, and the change propagates to the vehicle and to real-time passenger information straight away. This is what lets dispatch absorb the inevitable disruptions of a live network without a lag between the decision and reality on the road.
Layer 3: On-board confirmation — the driver closes the loop
Not every vehicle arrives at the depot with a pre-assignment already in place, and not every operator wants every case handled centrally. Whenever there's no pre-assignment yet — or whenever the operator's own process calls for it — the driver needs to be able to select or confirm the service themselves.
On-board labeling gives drivers that control directly from the Pysae Driver terminal: select or confirm the service they're running, and the vehicle, the AVM, and passenger information all fall back in step. It's the human layer — necessary precisely because not everything can or should be pre-assigned or handled centrally.
Layer 4: Automatic identification — one click away from certainty
The last layer doesn't need anyone to start from a blank page. AVM continuously compares a vehicle's depot, GPS position, time of day, and vehicle type against the schedule, and proposes the single most likely service. Confirming it — for a controller or a driver — takes one click.
This is the safety net underneath the other three: even if pre-assignment, central labeling, and driver confirmation all get skipped or arrive late, automatic identification narrows the guesswork down to a near-certain match, ready to confirm in a moment.
A vehicle is never just "probably" running the right service. It's pre-assigned, it can be reassigned from the control room, it can be confirmed on board, and it's checked automatically against what's really happening on the road. Four chances to get it right, zero silent failures.
Underneath these four layers, the actual behavior adapts to what planning already knows: three configurations — vehicle and driver both pre-assigned, vehicle only, or neither — each with configurable priority rules, and always a strict one-to-one link between a vehicle and its service. No vehicle is ever paired to two services at once, and no service is ever silently left without one.
None of these four layers exists to replace the others — together, they're what makes real-time passenger information something operators can actually stand behind: accurate destination signs, accurate positions on the map, and a control room that always knows which vehicle is doing what. That's the difference between an AVM that tracks vehicles and one that understands the service they're running — which is exactly the kind of reliability Pysae builds into every layer of its real-time CAD/AVL platform.