Airport Digital Twin

Airport capacity is not a property of any single subsystem. Check-in, security, gates, stands, runways, ground handling and baggage each have their own limit, and the one that binds changes with the schedule, the weather and whatever went wrong that morning. Studying them separately produces answers that do not survive contact with an irregular operation, which is precisely the case worth studying.

This system models them together in one clock. It is an internal system built and published by Alsadaany Industries. It is not a customer deployment, and the operation it models is illustrative.

A terminal and its airside, generated at runtime from layout and scenario data rather than authored as a scene. Passenger processing, aircraft rotations, stands, runways, ground service fleets, baggage handling and weather run as one connected model, presented through an operations dashboard where every parameter is a live control.

A passenger carries a flight, a destination, a boarding time, a walking speed, a stress level, a waiting tolerance, a luggage count and a priority. They arrive on a demand curve, walk a navigation graph, choose the shortest queue, wait, grow impatient, use facilities, board, and miss the flight if the gate closes first. Arriving passengers deplane, clear passport control, and wait at the carousel for their own bag.

A flight is a complete rotation rather than an event: inbound movement, landing, rollout, taxi, stand, unload, clean, cater, refuel, board, pushback, taxi out, hold, take off. Runway access is serialised through a per-runway next-free time, so reducing runway capacity produces a real queue at the holding point and the delay cascades into the departure schedule the way it does in practice.

Every parked aircraft generates a task list dispatched to the nearest idle vehicle of the right type, with fleet sizes set from the dashboard. Bags are tracked individually from desk to hold and hold to carousel, on conveyor lines that can fail and be repaired.

Twelve incident types are modelled, from heavy rain and fog through runway closure, security incidents, conveyor failures and power outages. Each applies a real effect to a real system and reverses it on resolution. A security incident closes screening lanes and applies a routing penalty to the area, and the queue growth that follows appears in the same metric an operator would be watching. Nothing is written directly to the dashboard.

Weather is coupled rather than decorative: visibility drives runway separation, rain drives taxi speed, and wind decides the working direction of the runways. Incidents can be generated at a configurable rate, scripted at fixed times, or injected by hand.

Passenger movement runs in Burst-compiled jobs over struct-of-arrays storage with neighbour avoidance from a spatial grid, and rendering is GPU-instanced with three distance levels of detail and a vertex-shader walk cycle. The crowd costs a handful of draw calls rather than ten thousand scene objects, which is what makes an operationally interesting population size real-time rather than aspirational.

The control panel is generated from a parameter registry rather than authored, so the interface cannot drift away from the model it controls. Twenty-three KPIs carry rolling history, alert thresholds and trends, and any entity in the model can be inspected down to an individual passenger.

The system is built to a target scale of 10,000 passengers, 100 aircraft and 500 ground vehicles in real time. It demonstrates that a coupled operational model of this size can be driven interactively, that a disruption injected into one subsystem propagates into the others through the mechanism rather than through a scripted response, and that the resulting behaviour is legible in operational measures rather than only in a visualisation.

Unity 6 with the universal render pipeline, Burst-compiled jobs for the crowd, GPU instancing with distance levels of detail, a navigation graph for pedestrian routing, runtime generation of the environment from layout data, and a parameter registry driving both the model and its controls.

The airport is illustrative. No real terminal, schedule or resource plan is represented, and no output has been validated against a real airport's recorded performance.

It has no live operational data feed. Connecting one is engineering work scoped per site.

The stated scale is the design target of the build rather than a certified benchmark, and sustained frame rate depends on the machine it is run on. The browser build is trimmed relative to the desktop build.

Demonstration. Built, runnable and published, and used as evidence that operations of this complexity can be represented in one coherent model. Running in a browser makes it a demonstration; it does not make it a deployment.