Start with a valid instruction
A transport request should contain enough information to prevent ambiguity before motion begins. The system needs an origin, an authorised destination, a load identity, a permitted vehicle configuration and a useful time window. A flight number alone may be insufficient when stand allocation changes or several loads share a service. The request also needs an owner who can resolve missing or contradictory information.
Validation is not just checking that fields are populated. The destination must exist in the approved map, the vehicle must be suitable for the payload, and the receiving area must be available. If the mission cannot be completed inside its operating boundary, a fleet scheduler should not quietly transform it into a different task. Rejection and escalation are legitimate outcomes.
Distinguish localisation from perception
Localisation estimates where the vehicle is. Depending on the design, it may combine satellite positioning, inertial measurements, wheel motion and observations from cameras or lidar. Airport buildings, covered passages and nearby aircraft can complicate satellite reception and visual interpretation. No single sensor label demonstrates sufficient performance across all routes and conditions.
Perception addresses what is around the vehicle: people, equipment, boundaries and obstacles. A system may locate itself accurately while misunderstanding an obstruction, or detect an obstacle while lacking enough position confidence to continue. Requirements should treat these as related but distinct capabilities. Ask how uncertainty is represented and which thresholds trigger a constrained or stopped state.
Keep maps under operational control
An airside map is an operational asset, not a one-time installation file. Temporary works, changed markings, relocated equipment and revised stand arrangements can invalidate a previously usable route. The airport needs a process for issuing restrictions, updating maps, checking changes and confirming which version is active on each vehicle.
The map should distinguish permitted paths from merely visible pavement. It should also represent waiting points, prohibited zones and locations where a stopped vehicle would create a conflict. A planner should understand whether routes are fixed, selected from approved alternatives or generated dynamically within a constrained area. Those approaches create different change-control and assurance needs.
Separate routing from permission
A route planner can find a geometrically possible path without possessing authority to use it. Movement permissions may depend on local road rules, stand status, access restrictions or coordination with airport operations. The dispatch process must preserve that distinction. A central fleet system should not treat an empty-looking segment as automatically available.
Runway and taxiway interfaces require particular care. ICAO Annex 14 provides aerodrome context, while local procedures define how vehicle access and movement are controlled. A successful service-road demonstration does not establish suitability for a runway crossing. Excluding such crossings can be a sensible and useful boundary rather than an unfinished feature.
Design predictable traffic interaction
Airport roads carry buses, fuel vehicles, tractors and emergency traffic with different stopping distances and priorities. Define how an automated vehicle yields, communicates intent and behaves when another driver acts unexpectedly. A cautious vehicle can still create difficulty if it repeatedly stops where others cannot pass or if its signals are unclear.
Speed selection should account for stopping distance, sensor coverage, payload and towing geometry. Consider the space occupied by every trailer throughout a turn. A route that is technically traversable may be operationally poor if it causes recurring queues. Evaluate congestion and service reliability alongside obstacle avoidance.
Close the movement with evidence
Arrival should generate a clear event, but task completion may require a receiving worker or another system to accept the load. Keep “arrived,” “unloaded” and “accepted” separate where the workflow needs them. This makes it possible to diagnose whether delay arose in travel, queueing or handling rather than attributing every late bag to the vehicle.
Record the task identifier, route version, relevant permissions, interventions and exception states. Use logs proportionately: enough to reconstruct the event without unnecessarily collecting identifiable worker information. ISO 3691-4 offers a relevant starting point for driverless industrial-truck safety, subject to its scope; it does not replace aerodrome approval or a complete assessment of the airport mission.
Finally, test the dispatch chain when information is late or inconsistent. A stale stand assignment, duplicate request or unavailable destination should lead to an understood response. Reliable navigation is not just a vehicle reaching a coordinate. It is a controlled movement whose authority, progress and outcome remain intelligible to the people running the airport.