Most writing about airport technology looks at one system at a time. Operations don’t work like that. Here is an imagined day at a busy airport, not a record of any real site, to show how sensing, understanding and acting connect.
Before dawn: the runway
At 05:40, before the first departure, a system flags something on the runway. Detection is only the start. A false alarm closes a runway for nothing and a missed object is a safety risk, so one sensor’s weakness has to be covered by another. That’s the job of FODD, which combines AI object detection with mmWave radar and thermal cameras to find metal, plastic or rubber as small as 2 inches. The operations team then needs three things at once: where the object is, how sure the system is, and what an inspection will do to the morning’s arrivals and departures.
Morning: the gate
At 07:15, an aircraft is on stand and its boarding bridge hasn’t docked. Passengers wait, and the aircraft’s next departure starts to look doubtful. JetScope watches the bridge through optical cameras and gives staff a real-time alert while there is still time to do something. That alert is useless unless it reaches the person who can act, so we’d spend more time on the routing than on the model.
Afternoon: the terminal and the apron
At 12:30, security asks about a person seen near a kerbside entrance an hour earlier. Instead of scrubbing through recordings, an investigator types a description into Netra, which searches terminal, kerbside and airside footage in plain language. It runs on the airport’s own GPU servers, fully on-premise and air-gapped, which is often the only acceptable way to handle this footage.
At 16:20, a departure is short of a tug. Somebody knows where one is, but it isn’t the person who needs it. AeroTrack shows tugs and crew on one wireless network, with precision of 2 to 5 metres and a range of up to 7 km, so the controller can pick the nearest free one without phoning around.
Overnight: the systems behind it all
At 23:05, a server behind a terminal system is on course to run out of capacity. Nobody has noticed, because nothing has failed. AIOps gives early warning on the IT estate behind terminal and airside operations, so the team can act during a quiet night. Routine issues can resolve themselves under the airport’s policies, with a full audit trail, and the rest wait for a person.
Each of these can stand alone. The value of connecting them shows up in the joins. A runway closure should change gate plans, a late bridge should change tug demand, and a failing server may explain why a display has gone dark. Those joins need dull foundations: shared flight and stand identifiers, one clock across systems, and a link to the AODB. A digital twin can bring the picture together once those exist. Without them, it’s a nice-looking map.
You don’t need all of this at once, and for many airports it wouldn’t be sensible to try. Fix the problem that hurts most, then ask what it should connect to next.
So write your own version of this day. Take a recent bad day at your airport and list each event in order. Note when it was first known, by whom, and who could have acted. The longest gap between those times is where to start.