Assign responsibility at every boundary
An airport transport service can involve the airport operator, an airline, a ground handler, a fleet supplier and a maintenance provider. Autonomous operation does not simplify those responsibilities automatically. Write down who requests the service, who authorises movement, who supervises the vehicle and who accepts delivery. Assign someone to resolve conflicts between those roles.
Include less visible decisions. Who can cancel a mission already in progress? Who may change a mapped route? Who decides that weather is outside the operating boundary? Who owns a vehicle that stops between two organisations’ work areas? A responsibility map should describe actual shift arrangements, including nights and disruptions, rather than rely on a daytime project team.
Connect operational data without confusing authority
An airport operational database can supply flight and stand information, but that information is not necessarily a direct movement instruction. A stand reassignment may need validation by the handler before the vehicle receives a revised destination. Separate operational facts, service requests and movement permissions in the interface design.
Use stable identifiers for tasks, vehicles, loads and handover points. Define what happens when messages are late, duplicated or received out of order. A status labelled “complete” should have a documented meaning shared by both systems. Otherwise, one system may report success while the receiving team is still waiting for a load to be unloaded or accepted.
Design the physical handover
Digital integration cannot compensate for a badly arranged collection point. Provide enough space for people to work without entering the vehicle’s path unexpectedly. Mark where equipment should wait, where the vehicle stops and how readiness is signalled. For towing, coupling and inspection responsibilities need particular clarity.
Observe the real workflow before deciding that an interaction can be removed. Drivers often perform informal checks, move stray equipment or confirm destinations with colleagues. If those actions remain necessary, assign them explicitly. A deployment that silently depends on nearby staff providing unplanned assistance has not fully defined its service model.
Include charging and maintenance in the schedule
An electric autonomous vehicle has to be available when the service needs it, not just when its battery is charged. Charging locations, queueing, connector availability and battery condition affect fleet capacity. A plan should account for the complete duty cycle, including travel to charging, waiting and returning to service.
Maintenance goes beyond the propulsion system. Sensor cleaning, calibration checks, software configuration, tyres, brakes and towing equipment can all affect operational availability. Establish who can release a vehicle after maintenance and how configuration changes are recorded. A software update may require more than routine installation if it changes behaviour relevant to the approved operating boundary.
Treat cybersecurity as an operational dependency
Remote access, fleet scheduling and map distribution create interfaces that need controlled access and monitoring. Apply appropriate authentication, least-privilege permissions and change records. Separate maintenance privileges from routine dispatch wherever practicable. The recovery plan should include unavailable or suspect digital services, not only mechanical faults.
Logs and camera feeds may also contain personal information about workers or other airport users. Define the purpose, access controls and retention arrangements before collecting data. ISO/IEC 27001 can inform information-security management, but certification alone would not settle the safety implications of a particular remote-control or dispatch architecture.
Procure a service outcome, not a demonstration
Contract requirements should describe availability, task completion, intervention handling and support responsibilities in terms that match airport operations. Ask how downtime is measured and whether planned restrictions, blocked routes and unavailable handlers are reported separately. This avoids arguments caused by a headline availability figure with an unclear denominator.
Compare the automated service with an observed baseline. Useful measures include accepted loads per shift, missed handover windows, queue time, recovery duration, energy use and total staff effort. Intervention rate should include context: a request for routine approval is not the same as an urgent recovery. Do not publish a single productivity percentage without explaining the conditions and work included.
Read deployment evidence in phases
Schiphol and Aurrigo, Changi Airport Group, and Toulouse-Blagnac Airport and EasyMile offer useful public research trails for airport autonomy. Distinguish supplier descriptions from airport statements, and check whether the source describes a demonstration, a supervised trial or a service phase. Current status may differ from an older announcement.
A staged rollout can begin with a limited route and service window, then expand only after agreed evidence is reviewed. Keep a manual fallback that is realistic at the intended scale. EUROCONTROL’s Airport Collaborative Decision Making framework illustrates the broader value of shared operational information, but ground-vehicle integration still needs its own task-level controls. The endpoint is not a vehicle operating alone; it is an accountable service working coherently with the rest of the airport.