Airport Operational Database Software: Why One Flight Record Has to Win

Why the flight record is the only object that matters at an airport

It is 06:10 at a two terminal airport. An A321 is on short final. The airline moved the aircraft registration overnight, the ground handler's system still holds yesterday's tail, and the AODB took its update from the ATC feed which carries neither. The allocator has put the aircraft on a contact stand sized for the original type, the jet bridge operator finds the door position wrong, and the aircraft holds for eleven minutes while somebody telephones the apron desk. Three weeks later the landing fee arrives calculated from a maximum take off weight attached to a registration that never flew, and the airline's revenue team disputes the invoice. Nobody in the building can say with confidence which of the three records was correct.

Around that moment sits a stack most airports will recognise. An AODB installed by an integrator six years ago and configured by people who have since left. A FIDS from a different supplier. A baggage handling system from Vanderlande or Siemens that speaks its own dialect. A resource management module nobody trusts, so the terminal duty manager keeps the real check in desk plan in Excel. Aeronautical billing done monthly by exporting movements to a finance system. An A-CDM portal added later that needs milestones the AODB was never designed to emit. Each product is competent at its own job. None of them owns the question that actually matters, which is: for this movement, right now, what is true, and who decided?

That question is the whole product. Across airport projects we have delivered, the recurring damage is the same shape: aeronautical revenue leaking because movements are missed, misclassified or billed on stale weights, stand allocation done by a human overriding the system because the system does not know the local rules, and every tenant integration built as a one off file drop that breaks when a source changes. The leak is not dramatic on any single day. It is a permanent tax on an operation that has no margin for it.

Problem 1: three sources of truth and no written arbitration rule

Your flight data arrives from the airline schedule in SSIM, from ATC and network feeds, from the ground handler, from surveillance, and from a human on the apron radio. They contradict each other constantly, and the contradictions are not random. The airline is authoritative on registration and passenger figures. ATC is authoritative on actual movement times. The handler is authoritative on ground events. Surveillance is authoritative on where the aircraft physically is.

Packaged AODBs from Amadeus Airport Management and SITA Airport Management do carry source priority configuration, and that is genuinely useful. What they configure is a generic priority ladder. What an airport actually needs is a rule set that says: accept registration from the airline until forty minutes before estimated landing, then freeze it; accept actual on block from the handler unless surveillance disagrees by more than three minutes, in which case raise an exception rather than pick a winner silently; never let a billing relevant field change after the movement is invoiced without producing an audit entry. That is your operating policy, not a vendor default, and it changes when your handler mix changes.

What a custom build does: make arbitration an explicit, versioned, testable rule set with an exception queue a duty officer can work. Every field on the flight record carries its source, its timestamp and the rule that let it win. When the airline disputes a bill, you do not argue from memory, you replay the record. Building this as an append only event log rather than a mutable row is the single decision that makes the rest of the system defensible.

Problem 2: stand allocation runs on your geometry, not a generic model

Stand allocation looks like a solved problem until you write down your own rules. Adjacency restrictions where a code E aircraft on one stand blocks the neighbour. MARS stands that split into two narrowbody positions or combine into one widebody. Wingspan and tail height limits per position. Pushback conflicts on a single taxilane. Jet bridge compatibility by door position and aircraft type. Towing rules that decide whether a four hour turn stays on a contact stand or goes to remote parking, and who pays for the tow. Customs and border requirements that force certain arrivals onto certain piers. Night curfew parking. De-icing pad access in winter.

ADB SAFEGATE is strong on the physical layer, docking guidance and gate hardware, and Veovo is genuinely good at passenger flow and queue prediction. Neither of them owns your stand rulebook, and neither claims to. The packaged AODB allocators do hold rules, but expressing your local constraint set inside their configuration model is where projects stall, because the model was built for the constraints that were common when it was designed.

What a custom build does: treat allocation as a constraint problem with your geometry loaded as data. Stands, wingspan codes, adjacency pairs, bridge compatibility, tow costs and walking distances all become inputs, and the solver produces a plan that respects hard constraints and optimises soft ones such as contact stand utilisation and minimum tows. The allocator keeps a manual override, because they always will, but the override is recorded with a reason and feeds back into the rules. A day of disruption is where this pays: when a runway closes for two hours, a solver rebuilds the plan in seconds and the humans arbitrate the twenty hard cases instead of all two hundred.

Problem 3: aeronautical billing is only as good as the record beneath it

Landing fees by maximum take off weight. Parking beyond the free period at a rate that differs between contact and remote stands. Passenger charges split by domestic, international and transfer, which requires a transfer volume you may never have measured properly. Noise and emissions surcharges by aircraft certification data. Bridge usage, ground power, security and de-icing. Each is a formula over the flight record with an exception list negotiated into a specific airline contract, and finance usually applies it by exporting movements into a spreadsheet once a month. That method leaks in three predictable places: movements missing from the export, weights taken from a fleet table last updated when the airline flew a different subfleet, and parking durations the airport cannot evidence when challenged.

What a custom build does: calculate the charge when the movement closes, from the same authoritative record, with tariffs held as versioned data so a mid year change needs no code release. Every invoice line links back to the exact record and the exact rule version. Disputes then take minutes rather than a fortnight, and most of them stop happening, because the airline can see the same evidence you can.

Problem 4: every tenant wants a feed and today it is a file on a share

Airlines, handlers, retail concessions, car parking, the border agency, the fuel supplier and the taxi rank all want flight data in their own shape. Most airports end up with a graveyard of scheduled exports, several of them running from a machine under somebody's desk, each one a silent integration that breaks without anyone noticing until a tenant complains.

What a custom build does: one publish layer with a documented event stream and a small number of supported shapes, including IATA AIDX for partners who can consume it, plus a plain API and a webhook option for those who cannot. New tenants get onboarded in days by subscribing rather than in weeks by commissioning another export. This is unglamorous work and it is usually the piece that makes the operations team believe the platform is real.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for airport operations platforms. A first release covering source reconciliation into one authoritative flight record, constraint based stand and gate allocation, and the tenant publish layer runs $120,000 to $260,000 and ships in 16 to 24 weeks. That is a system the apron and allocation teams use in production, not a pilot. Adding aeronautical billing with versioned tariffs, resource allocation for desks and belts, A-CDM milestone emission and a tenant portal takes the total to $300,000 to $800,000, phased across 9 to 18 months.

What drives the number up at an airport specifically: the number of legacy systems that must keep working, because each one is its own protocol archaeology project. Surveillance and BHS integration, where the interface is a decade old and the vendor charges for the specification. A-CDM, if you are joining a network programme, because milestone definitions and message quality get audited by parties outside your control. Multiple terminals with genuinely different operating models. And the one nobody budgets for, which is the discovery effort of writing down rules that currently live in the heads of two allocators who have worked there for fifteen years.

Build versus buy, and the hybrid that usually wins

Buy outright if you are a single terminal airport under roughly two million passengers with a stable carrier mix. Amadeus and SITA will sell you a configured AODB that does the job, the integration surface is small enough to manage, and the money you would spend on a build is better spent on the apron.

Build the layer, not the whole stack, if you are mid sized and already own a vendor AODB you cannot rip out. This is the most common honest answer we give. Keep the vendor system as a system of record for the fields it holds well, and build the arbitration, allocation and publish layer around it. You get your rules, your exception handling and your integrations without a migration that would consume two years.

Build properly when three things are true. Your stand and resource rules cannot be expressed in the vendor's configuration model and are therefore being applied by humans. Your aeronautical revenue is large enough that a one percent billing leak exceeds the cost of the project. And you have more than about ten tenant systems consuming flight data, which means the integration layer is already your biggest operational risk. At that point the coordination logic between sources, stands, charges and tenants is the airport's operating system, and no vendor is going to encode your apron for you.

How to choose a developer for airport operations software

Ask them to model the flight record on a whiteboard before you sign anything. A team that has done this will separate the scheduled flight, the operational movement, the turnaround linking an arrival to a departure, and the resource assignments, and they will immediately ask which source wins for which field. A team that draws one flights table with an editable status column has built a booking system and is about to learn aviation on your budget.

Ask what they have genuinely integrated, by name and by protocol. Type B messaging, AIDX, a BHS interface, a surveillance feed and a finance system are five different problems with five different failure modes. Ask them to describe a time a source feed went silent overnight and what the system did about it, because that is a Tuesday at an airport.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the unrestricted right to hire another firm to continue the work. Airports are long lived institutions buying twenty year systems, and a developer who wants to hold the repository is selling you a dependency. At Digital Heroes the code is yours from the first commit, and we would tell you to walk away from anyone who hedges on that.