Airport digital twin use case

The operational question

Consider an evening wave when three inbound flights are late. The airport operations centre needs to know which stands will be occupied, whether the baggage system can absorb the combined load, how security queues will build and whether the jet bridges and pre-conditioned air units at the affected stands are serviceable. Each answer sits in a different system, often with different identifiers for the same flight.

Sources and transports

• Airport-CDM milestones (target off-block, actual in-block and others) from the A-CDM platform, usually through a message interface or REST API.
• AODB flight records and AIDX messages for schedules, stands and gates.
• ADS-B and, where provided by the ANSP, ASTERIX surveillance data for aircraft positions on approach and surface.
• Baggage handling system throughput and fault states, typically exported from the BHS controls via OPC UA or a database interface.
• Terminal building systems over BACnet/IP for HVAC and lighting, and jet bridge or ground power status via PLCs.
• Passenger flow counts from security lanes and sensors, delivered as aggregate counts without personal data.
• METAR and TAF weather reports.

What the twin records

Every observation is stored with its source, a source timestamp and a receive timestamp. Flight identity is reconciled by flight number, scheduled date and registration so A-CDM, AODB and surveillance records can be joined. Milestone values keep their type, so an estimated time is never displayed as an actual. Surveillance positions are treated as situational context only. Passenger counts are aggregated per lane and interval.

Prerequisites

• Data sharing agreements with each data owner, including airlines and the ANSP.
• Interface specifications for A-CDM and AODB, and a reference list of stands, gates and resources.
• Network paths approved by airport IT and OT security, often requiring the Enterprise deployment option.
• A pilot scope: for example one pier, its stands, its baggage make-up area and its security lanes.

Limitations

• The twin supports awareness and planning. It is not an air traffic or safety system, and it does not replace certified ATM or A-CDM tools.
• Surveillance data accuracy and update rates depend on the provider and licensing.
• Catalogue connectors such as ASTERIX, AMHS or ACARS are listed as possible paths; their implementation and validation are confirmed per project.
• Prediction models require historical data and are outside the basic integration.

Outcome to aim for

A first phase should deliver one reliable timeline per flight and stand, with gaps and late data visible. Only when that timeline is trusted should dashboards, alerts or forecasts be layered on top.

Further reading

• Digital twin guide
• Supply chain twin guide
• Edge cloud guide
• All resources
• Connector catalogue
• Industries
• Products

Catalogue listings describe possible integration paths. Implementation and validation status is confirmed for each source during project scoping; no certification, service level or price is implied by this page.