Airport operational software — AODB vs RMS vs A-CDM vs AMS, and how they fit together?

Airport operations software is sold under a confusing pile of acronyms — AODB, RMS, ACDM, AMS — and procurement teams often buy overlapping capability or leave gaps because the categories blur. The clean way to think…

Airport operations software is sold under a confusing pile of acronyms — AODB, RMS, A-CDM, AMS — and procurement teams often buy overlapping capability or leave gaps because the categories blur. The clean way to think about it: the AODB is the single source of truth for flight data; the RMS allocates physical resources against that data; A-CDM is a process (and the data exchange that supports it), not a product; and AMS is the umbrella platform that ties them together. This brief explains each layer, how they connect, and who the credible vendors are — vendor-neutrally.

The four layers

AODB — Airport Operational Database

The AODB is the central, real-time database of flight-related information — schedules, actual movements, aircraft, stands, and the operational events around each flight. It is routinely described as the "heart" of airport operations because almost every other system reads from or writes to it. It feeds passenger information displays, billing/invoicing, and resource planning. If you only buy one core system, this is the foundation the rest hang off.

RMS — Resource Management System

The RMS allocates the airport's physical and human resources against the flight data in the AODB: stand/gate allocation, check-in desk and bag-belt planning, baggage reclaim, and sometimes staff rostering. It answers "which aircraft goes to which stand, which flight uses which desks, when." It depends on the AODB for its inputs — without accurate flight data it cannot plan. AODB and RMS are very commonly bought and deployed together as a combined operations-and-resource platform.

A-CDM — Airport Collaborative Decision Making

A-CDM is not a single software product — it is an operational concept and a data-exchange standard for getting the airport operator, airlines, ground handlers, and air traffic management to share a common, accurate picture so turnaround and pre-departure sequencing improve. In Europe it is defined by a EUROCONTROL Specification for A-CDM, built around a set of milestones (the EUROCONTROL A-CDM milestone approach) and key data elements such as TOBT (Target Off-Block Time), TSAT (Target Start-Up Approval Time), and DPI (Departure Planning Information) messages exchanged with the Network Manager. Implementing A-CDM means your AODB/RMS platform must be able to produce and consume these data and milestones — so A-CDM compliance is a capability you require of your core systems, not a box you buy separately.

AMS — Airport Management System

AMS is the broad umbrella term for the integrated platform that brings the above together — typically AODB + RMS + the operational dashboards/decision tools, often with A-CDM support, FIDS (flight information displays), and billing. Tier-1 hubs increasingly buy a single integrated AMS rather than stitching point solutions, precisely to avoid the integration gaps described below.

How they fit together

        A-CDM  (process + data exchange: TOBT / TSAT / DPI, milestones)
          |   shared situational picture across airport, airlines, handlers, ANSP
   +------+----------------------------------------------+
   |                  AMS (umbrella platform)            |
   |   AODB  --->  single source of flight truth         |
   |     |                                               |
   |     v                                               |
   |   RMS   --->  stands / gates / desks / belts        |
   +-----------------------------------------------------+

The AODB holds the truth; the RMS plans resources against it; A-CDM is the collaborative process that consumes and enriches that truth across stakeholders; the AMS is the integrated platform delivering all of it.

Vendor landscape (representative, non-exhaustive)

These are established, real suppliers in the airport operations software space:

Vendor	Known for (in this space)
SITA	Airport platforms incl. AODB/RMS, common-use, A-CDM-related solutions
Amadeus	Airport Operational Data Base and airport management products
ADB SAFEGATE	Airport operations / AODB and airside integration
TAV Technologies	AODB and airport operations products (strong regional presence)
Collins Aerospace (RTX)	Airport database and resource management
Veovo	Passenger-flow analytics and resource/operations optimisation
EUROCONTROL	Not a vendor — publishes the A-CDM Specification and operates the Network Manager interface

Inclusion here is not an endorsement; shortlist against your own requirements. Several other regional and niche integrators also operate in this market.

What this means for a GCC buyer

Decide the platform boundary first. Are you buying an integrated AMS, or AODB + RMS as separate procurements you will integrate? Integrated reduces interface risk; best-of-breed maximises per-module fit.
Make A-CDM a requirement, not a product line. If you intend to run A-CDM-style collaborative operations, specify that your AODB/RMS must support the relevant milestones and data elements (TOBT/TSAT/DPI-type exchange) and integrate with the relevant air-traffic-management interface for your region.
Mind the integration seams. The expensive failures are at the joins — AODB-to-RMS, AODB-to-FIDS, and the A-CDM data exchange. Specify interfaces and data ownership explicitly.

Bottom line

AODB = the flight-data source of truth. RMS = resource allocation against it. A-CDM = a collaborative process and data standard your core systems must support, not a separate purchase. AMS = the integrated platform that unifies them. Buy the foundation (AODB) deliberately, treat A-CDM as a capability requirement, and scrutinise the integration seams — that is where airport operations software projects succeed or fail.