AIDX vs SSIM vs OOOI: Flight Operations Data Guide

Executive Summary

Aviation Information Data Exchange (AIDX), the Standard Schedules Information Manual (SSIM) and OOOI answer different questions about a flight. SSIM defines schedule and airport coordination exchanges, including the planned service and slot context. ^[1] AIDX is an XML standard for flight information shared among airlines, airports and operational consumers, generally around the flight's operational window. ^[2] OOOI names four actual aircraft movements: gate out, wheels off, wheels on and gate in. ^[3] An integration should therefore retain a schedule baseline, consume operational revisions, and record actual movements with their own provenance. Treating the three as interchangeable produces an ambiguous answer to the simple question, “What time did this flight depart?”

The boundary is about meaning and ownership, not merely file format. IATA's SSIM materials separate scheduling messages from airport coordination messages, and a slot coordinator distinguishes allocated planned on-block and off-block times from actual movements. (Source: www.slotcoordination.ch) An AIDX flight leg carries operational information, with identifiers and operation times that can distinguish scheduled, estimated and actual values. OOOI is an event vocabulary and feed concept, not a universal replacement for a schedule or a complete AIDX message. The US Federal Aviation Administration (FAA) uses a particular source order when assembling Aviation System Performance Metrics (ASPM), but that order applies to its statistics, not to every operator or jurisdiction. ^[4]

As of October 2026, IATA's AIDX page presents a v21.3 schema download, while its linked implementation guide is labeled v22.1; SITA documents v21.2 support for its own AIDX application programming interface (API). These numbers describe different artifacts and product support. They are a reason to verify payload compatibility at each endpoint, not to rank the systems by a single “current version.” ^{[5] [6]} (Source: www.developer.aero) IATA identifies SSIM Edition 36 (2026) in its publication materials and says it publishes SSIM annually. ^[7] The editions and implementations change, but the schedule, operational update and actual-event distinction remains the useful design starting point.

A practical adapter should preserve the operating leg identity, service or origin date, event type, planned versus estimated versus actual status, time zone, source, observation time and revision history. IATA's AIDX guide defines an origin date tied to the scheduled UTC departure of the first leg and treats it as stable even after rescheduling. ^[8] Other products can return times in local airport time, so a visible UTC value needs a conversion rule and its original input retained. ^[9] The hypothetical timeline and acceptance questions below show what to reconcile for codeshares, a midnight rollover, cancellation, diversion and update ownership. They are design checks to settle with each provider and operator, not claims that every standard mandates the same workflow.

Introduction and Background

An airline operations control center, an airport data team and a schedule distribution team can all refer to the same flight while handling different records. The schedule team needs the published service and airport coordination plan. The day-of-operation team needs revised times, stands and leg status. A movement feed reports what the aircraft actually did. Those records may disagree for legitimate reasons: they answer questions at different points in the flight's life, and they may arrive from different systems. IATA places SSIM in schedule management and airport slot standards, while it describes AIDX as operational flight exchange. ^[10]

This report compares the three data boundaries for teams selecting a source feed or building an adapter between packaged systems. OOOI expands to out, off, on and in; in FAA ASPM terminology these are gate out, wheels off, wheels on and gate in. “Departure time” is therefore inadequate as a field name without a qualifier. It might mean scheduled off-block, latest estimated off-block, actual gate out, or actual takeoff. FAA ASPM defines wheels-off as takeoff, and calculates taxi-out from actual gate out to actual wheels off. ^{[11] [12]} That calculation demonstrates why a gate event and a runway event cannot be silently merged.

The intended choice is not a three-way vendor procurement. SSIM is a published IATA manual and message family, AIDX is an IATA XML exchange standard, and OOOI is a set of actual movement concepts commonly supplied through operational feeds. An airport may also use Airport Collaborative Decision Making (A-CDM) milestones; EUROCONTROL describes those milestones as triggers for revised estimates and notifications. (Source: www.eurocontrol.int) The presence of another milestone system reinforces the need to name events precisely at the interface. ACI World also publishes airport-specific definitions for consistent data exchange. (Source: aci.aero)

LANDING.AERO describes its work as custom flight operations software and integration of existing systems into an operational picture. (Source: www.landing.aero) (Source: www.landing.aero) In this comparison it is an adjacent integration builder, not a standards body or a feed provider. The useful first-party perspective is the adapter problem: decide which upstream system owns each field, then make the resulting operational picture explainable to users. This article does not prescribe dispatch or operational control procedures; those remain with the operator's approved processes.

SSIM: The Schedule and Slot Boundary

Capabilities

The Standard Schedules Information Manual is IATA's framework for exchanging airline schedules, airport coordination information and minimum connecting time data. Its current public description lists schedule data requirements in Chapter 2, standard schedule messaging in Chapter 4, ad hoc schedule messaging in Chapter 5, airport coordination in Chapter 6 and schedule data-set transfer in Chapter 7. ^[13] An architect should use the manual and the counterparty's implementation specification for field-level design; the public description establishes scope but is not a complete message specification.

• Published plan: Store the planned service identity, operating days and planned station times as a baseline. IATA's Schedule Data Exchange Program accepts SSIM, Standard Schedules Message (SSM) and Ad hoc Schedules Message (ASM) files. ^[14]
• Coordination context: Keep airport slot requests and responses separate from passenger-facing or OCC timing. IATA assigns coordinator-airline slot messaging to SSIM Chapter 6.
• Time interpretation: Carry the source's time basis into the adapter. Slot Coordination Switzerland says its slot request dates, days and times use UTC, which establishes that coordinator's practice, not a universal rule for every SSIM message. (Source: www.slotcoordination.ch)

Adoption and exchange setting

SSIM is published annually, so a receiver should record the edition it validates. ^[15] A counterparty agreement then identifies the message subset and effective date; publication alone does not establish when that partner deploys a change.

• Coordinator practice: Slot Coordination Switzerland says allocated slot times represent planned on-block and off-block times, while actual arrival and departure can differ. (Source: www.slotcoordination.ch) (Source: www.slotcoordination.ch)
• Message acceptance: That coordinator accepts Slot Clearance Request (SCR) messages for its own slot requests and changes rather than ASM or SSM; this is a local counterparty rule, not a blanket ban elsewhere. (Source: www.slotcoordination.ch)
• Regional variation: European Airport Coordinators Association guidance names SMA, SCR and GCR message types under SSIM for facilitated airports. An interface contract must identify the actual counterparty and message type. ^[16]

Strengths and limitations

SSIM is strongest as the planned-service record and the airport coordination exchange. It is the wrong sole source for actual wheels-off or gate-in simply because those events occur after a schedule is published. A coordinator's distinction between planned slot time and actual movement makes that boundary explicit. (Source: www.slotcoordination.ch) (Source: www.slotcoordination.ch) A flight delayed on the day need not automatically cause a new slot transaction in Slot Coordination Switzerland's workflow, although a next-day postponement has separate slot handling there. (Source: www.slotcoordination.ch) (Source: www.slotcoordination.ch) These are useful examples of why “schedule changed” and “operational estimate changed” need different flags.

• Strength: A common manual gives partners a shared basis for scheduled services and coordination data.
• Boundary: A schedule feed may be current for the published plan yet still be stale for the latest estimated gate event.
• Check: Confirm edition, message family, source of local or UTC times, effective dates and whether a cancellation removes a service or only changes a daily operation.

AIDX: The Operational Flight-Leg Boundary

Capabilities

Aviation Information Data Exchange is IATA's XML messaging standard for flight data shared with airlines, airports and other operational consumers. IATA says it is generally used in the operational window, although some implementations extend beyond that window. The AIDX guide makes the flight leg, one departure airport to one arrival airport, its principal structure. ^[17] It distinguishes operation-time event qualifiers and time types, which lets a receiver retain scheduled, estimated and actual values instead of overwriting one generic timestamp. ^[18]

• Leg identity: The guide's commercial leg identifier includes airline, flight number, origin date, departure airport and scheduled arrival airport, with optional components. ^[19]
• Codeshare relationship: The guide places codeshare information under the operating flight leg. That makes an operating-leg key a useful anchor while marketing displays retain their own labels.
• Time basis: The guide requires AIDX date and time references in UTC with a trailing Z. A receiver should validate that requirement for the agreed version and preserve the original message. ^[20]

Adoption and exchange setting

AIDX covers more than movement times, so an airport database or display must agree which elements it consumes. The published schema and guide have distinct version labels; a receiver should test its provider’s supported payload. ICAO’s Asia-Pacific A-CDM plan presents AIDX as an optional exchange format for one regional arrangement. (Source: www.icao.int)

• Provider version: SITA says its AIDX API supports v21.2. That is a documented endpoint capability and does not change IATA's download label. (Source: www.developer.aero)
• Transport choice: SITA documents a REST XML service; IATA's guide recommends a bilateral agreement on exchanged data and interface expectations. (Source: www.developer.aero)
• Consumer path: SITA says its service makes updated flight details available through its Flight Status API. That is one product's workflow, not a universal AIDX transport pattern. (Source: www.developer.aero)

Strengths and limitations

AIDX is the useful operational leg envelope when systems need revised estimates, actual event fields, stand or resource context, or other leg details. Its XML shape can carry a movement time, but the presence of an “actual” value alone does not prove how it was observed or which system is authoritative. The integration contract must name the event owner and observation source. IATA's guide distinguishes an omitted element, which conveys no new information, from an explicitly nil value, which clears a stored value; blindly replacing the whole record can therefore lose meaning. ^[21]

• Strength: Event qualifiers let one leg carry more than a single departure or arrival time.
• Boundary: AIDX can transport an actual off-block value, but a particular OOOI feed may have a different sensor, reporting definition or correction path.
• Check: Test schema version, optional fields, null-versus-absent behavior, duplicate messages, ordering and record deletion against each endpoint. SITA documents endpoint-specific create, update and deletion methods; verify them against the contracted API.

OOOI: The Actual-Movement Boundary

Capabilities

The FAA's ASPM glossary defines OOOI as actual gate out, wheels off, wheels on and gate in aircraft movements. ^[3] For an operator, these four events are a useful minimum vocabulary for movement history. They are not themselves an XML schema, a published airline schedule, or proof that a timestamp came from a particular onboard or airport source. The feed contract must identify the collection method. FAA ASPM separately defines actual wheels-off as takeoff and actual wheels-on as runway landing. ^{[11] [22]}

• Out: Actual departure from a gate or stand under the selected reporting definition. The US Bureau of Transportation Statistics (BTS) 2026 directive uses parking-brake release after loading and door closure for its gate departure report. ^[23]
• Off and on: Runway takeoff and landing, which bracket the airborne interval in an OOOI timeline.
• In: Actual arrival at the stand or gate under the selected reporting definition. The BTS directive uses brake engagement, with a door-opening fallback. ^[24]

Adoption and measurement setting

OOOI feeds serve operational review, performance analysis and downstream status displays, but published statistical systems may fill gaps differently. FAA ASPM says it uses Airline Service Quality Performance (ASQP) OOOI when available, followed by other named sources. It also estimates times when observations are missing. ^{[4] [25]} That is ASPM's statistical assembly rule only. It does not instruct an airline, airport, charter operator or another jurisdiction to rank its sources the same way.

• Reporting context: BTS distinguishes actual gate and wheels times from scheduled fields in its 2026 reporting directive. ^[26]
• Gate return: For that BTS report, the last gate departure before wheels-off is used after a return to gate. A system that retains all movements should still preserve the earlier out-and-return events for its own agreed use. ^[27]
• Other jurisdictions: EUROCONTROL's A-CDM specification defines actual off-block around commencement of pushback or taxi, and its A-DPI message is triggered by that event. These are A-CDM semantics, not an automatic definition for every OOOI supplier. (Source: www.eurocontrol.int) (Source: www.eurocontrol.int)

Strengths and limitations

Actual movement timestamps let a team compute intervals rather than infer them from a scheduled departure. FAA ASPM defines taxi-out as actual gate out to actual wheels off, and its estimation help describes using wheels-off and median taxi-out when direct gate-out data are missing. ^{[12] [28]} A measured field and a modeled field should have different provenance labels even if both populate a downstream “actual” column. In the absence of a direct observation, a display can say “estimated” instead of implying the event was sensed.

• Strength: Four concrete milestones support reproducible gate-to-gate, taxi and airborne calculations when all four are observed.
• Boundary: Different reporting programs can define the out or in trigger differently, so do not equate field names without a contract. ^[23] (Source: www.eurocontrol.int)
• Check: Retain observation source, event trigger, correction history and whether a return to gate, diversion or second attempt creates another event.

Feature Comparison

Table 1 maps the decision. Its owner and consumer columns are integration choices to confirm with counterparties; standards do not designate one owner for every field.

A schedule remains the baseline after an estimate changes, and a movement event later closes the timeline. A slot coordinator distinguishes allocated from actual times; Cirium exposes scheduled, estimated and actual status fields. (Source: www.slotcoordination.ch) ^[29]

Table 2 is a hypothetical example of one operated leg crossing midnight in UTC. Its planned and estimated values are illustrative, as are the four OOOI events. The stable service-date key matters when the event date rolls over.

Actual out to in is 95 minutes, off to on is 72 minutes, and gate departure is 28 minutes later than scheduled. These are calculations from invented values. A join on the observed out date would split this leg on 16 October. The adapter should map the schedule, AIDX and status-provider keys to the same operating leg.

Performance and Benchmarks

The three boundaries do not have a meaningful common “speed” benchmark. SSIM's publication and coordination workflow, AIDX's operational updates, and OOOI's event observations have different clocks and success criteria. A fair integration test measures freshness, completeness, identity match rate and correction handling for each actual endpoint. EUROCONTROL says A-CDM milestones trigger revised estimates and notifications, while SITA describes its particular AIDX endpoint as a REST XML service. Neither statement provides a universal delivery-latency guarantee. (Source: www.eurocontrol.int)

For a schedule feed, test whether the expected service and subsequent schedule changes arrive before the consumer's planning cut-off. For an AIDX leg feed, measure the time between publisher event, message issue, adapter receipt and consumer display. For OOOI, measure the time from observed movement to accepted event, then count later corrections separately. Heathrow's developer portal advertises near-real-time flight information and publish-subscribe services, but that product description is not a benchmark for IATA AIDX or another airport's stack. ^[30] FAA's SWIFT portal likewise describes near-real-time System Wide Information Management (SWIM) messaging, a distinct service with its own access conditions. The FAA says access to Collaborative Decision Making data elements is limited and separately requested. ^{[31] [32]}

• Freshness metric: Report the median and upper-tail receipt delay for each named feed and event type; set thresholds in the bilateral service contract.
• Completeness metric: Count legs with all required schedule keys, estimates and four movement observations separately. Do not treat a modeled gate event as observed.
• Identity metric: Measure codeshare consolidation, date rollover and diversion matching against a labeled sample. ICAO explains that a marketed codeshare can carry another airline's code alongside the operating carrier's code. (Source: wasa.icao.int)
• Correction metric: Count superseded estimates, explicit clears and late actual corrections; IATA's AIDX guide distinguishes omitted from explicitly cleared elements.

Public pages document capabilities, not a controlled head-to-head throughput test across these categories. The actionable benchmark is therefore an acceptance test using the operator's messages and display requirements. A provider may expose a delta response, as Cirium documents for its Flight Status API, but that is a feature of that API and should be tested in its own terms. ^[33] If the task is a full dispatch, crew or maintenance system, teams should evaluate those established product categories separately; a data adapter does not supply their operational functions.

Data Analysis and Evidence

The quantitative comparison here is deliberately narrow. The standards and reporting sources support four OOOI event types, about 180 AIDX elements on IATA's public page ^[34], two schema-set releases a year in IATA's stated cadence ^[35], and the named current version labels. ^[3] These figures measure different things. Four is an event vocabulary count; 180 is approximate schema breadth; two is a publication cadence. None measures vendor adoption, accuracy, message latency or integration cost.

Table 3 is a field-provenance matrix for the hypothetical leg. It translates the standards' meanings into an acceptance record. The event-owner and update policy cells are questions to resolve locally. OAG's documented Flight Info API returns scheduled alongside actual or estimated values and says one of its API time fields is local airport time, making source time basis a concrete integration check. ^{[36] [9]}

The matrix prevents an attractive but lossy “flight status” object from hiding distinctions. In the hypothetical example, the adapter would retain at least two planned gate times, two revised estimates, four actual movement events, and one persistent operating-leg key. These are counts of illustrative fields, not a standard's mandatory minimum. An operator can choose a smaller payload, but a smaller payload cannot answer every later audit or display question. The AIDX guide's leg structure and FAA's four movement definitions support the categories, while the matrix is the report's proposed design.

A useful interval calculation also exposes semantic differences. From the invented values, taxi-out is 14 minutes, airborne time 72 minutes, taxi-in 9 minutes, and gate-to-gate time 95 minutes. FAA ASPM defines taxi-out using actual gate-out and wheels-off, while EUROCONTROL's published taxi-time methodology uses reported off-block, takeoff, landing and in-block times. ^[12] (Source: www.eurocontrol.int) Before comparing those intervals between sources, agree on what counts as out and in. The BTS 2026 gate-return instruction demonstrates that even a familiar gate-departure label can carry reporting-specific selection logic. ^[27]

Implications and Future Directions

An airline or airport can combine a scheduling product, flight feed, airport database and display, then need an adapter for identity, time and correction rules. Heathrow describes operational and third-party data in its developer services; Amadeus describes a display drawing flight, gate and baggage data from an airport database. ^{[37] [38]} These are possible system boundaries, not a universal architecture.

LANDING.AERO describes tailored operations software and system integration. (Source: www.landing.aero) A custom adapter can fit operator-specific reconciliation and screens. It does not supply schedule rights, a flight-status feed, an airport system, a dispatch service or approved procedures. Choose software against an agreed field map and tested ownership rules.

The following are acceptance questions, not unverified requirements of SSIM, AIDX or every OOOI feed:

• Operating identity: Which system assigns the canonical operating-leg key?
• Codeshare: Which marketing designators map to one operated movement? ICAO distinguishes the designated and operating carrier codes. (Source: wasa.icao.int)
• Origin date: Does the source retain its original service date after a UTC rollover? The AIDX guide does for its origin date.
• Station pair: Does the key preserve scheduled destination after a diversion, and where is actual destination recorded?
• Cancellation: Which message cancels the planned service, and which merely cancels a day's operation?
• Update owner: Who can revise planned, estimated and actual fields after publication?
• Time basis: Are original local times, UTC conversion, daylight-saving rule and trailing Z retained? OAG documents local airport time in one API, while AIDX specifies UTC. ^[9]
• Event trigger: Does “out” mean brake release, pushback start, stand exit or another documented trigger? ^[23] (Source: www.eurocontrol.int)
• Missing value: Is an omitted field unchanged, unknown or cleared? AIDX's guide distinguishes omission from explicit nil.
• Reordering: How are late, duplicated and corrected messages replayed without changing the wrong leg?
• Gate return: Is the event history retained even if a reporting extract selects one departure? ^[27]
• Evidence: Can a displayed actual time be traced to a named source and observation timestamp?

Build a labeled corpus of ordinary, codeshare, rollover, cancellation, diversion, gate-return and corrected legs. Replay it through the adapter and compare consumer displays with the field map. EUROCONTROL describes milestone-driven estimate updates; ACI World describes interface practices. (Source: www.eurocontrol.int) (Source: store.aci.aero) Their examples support an exchange contract, while the corpus is a local test choice. EUROCONTROL says target off-block time reflects aircraft-operator or handler delays, another reason to name each estimate publisher. (Source: www.eurocontrol.int)

Frequently Asked Questions (FAQs)

What is the difference between AIDX and SSIM?

SSIM addresses airline schedule and slot-related exchange; AIDX addresses operational flight-leg data exchange. IATA's own descriptions put SSIM in schedule and airport coordination work and AIDX in the operational window. A schedule update can change the planned service, while an AIDX update can report a new estimate for the same leg. The receiving system must retain which kind of change occurred.

Is OOOI a competing message standard?

OOOI is the out, off, on and in movement concept used by FAA ASPM and other operational data contexts; it is not the full schedule or flight-leg message described by SSIM or AIDX. AIDX may carry actual operation times, but the observation method and correction authority of a particular OOOI feed must be established separately. The operator should not assume identical semantics because two systems call a field “actual.”

How do OOOI events relate to AIDX?

An OOOI observation may become an actual operation-time value in an AIDX leg message, if the sender's interface maps it that way. IATA's AIDX guide supports operational time qualifiers, and FAA ASPM defines the four movement events. The mapping must state which event trigger was used, whether the timestamp was directly observed or modeled, and how later corrections propagate. That mapping is a bilateral integration design, not a universal transformation supplied by the standard.

What should an integration architect verify first?

Begin with the operated leg key, source edition or schema version, time basis and field ownership. IATA's guide makes origin date part of commercial leg identity and requires UTC date-time references. Then test cancellation, diversion, codeshare, date rollover and corrections against real messages from each provider. SITA's stated v21.2 support alongside IATA's separately labeled schema download illustrates why a version label belongs in the endpoint agreement. (Source: www.developer.aero)

Conclusion

SSIM is the planned-service and coordination boundary; AIDX is the operational flight-leg exchange boundary; OOOI supplies actual movement events. None of the three, by name alone, determines which local system owns every timestamp or how a downstream screen should resolve conflicting updates. The correct integration records the baseline, the latest estimate and the observed event separately, along with the operating-leg identity and source provenance.

The hypothetical overnight leg demonstrates the common failure mode: a calendar-date join can split one operated leg into two records after midnight, while an unqualified departure field can overwrite a schedule with an estimate or a gate event with a runway event. IATA's AIDX origin-date convention offers a stable clue within that exchange, and FAA's OOOI definitions keep gate and runway movements distinct. The interface still needs its own tested key map and field-level ownership rules.

For a buyer, the useful question is “Which record do we need to answer this operational question, and who can correct it?” A schedule source, an operational leg publisher and a movement observer may all be needed. A packaged product should be evaluated for the records and interfaces it actually exposes; a custom adapter is justified when reconciliation and presentation rules are specific to the operator. The acceptance checks above turn that decision into a reviewable data contract rather than an assumption that one label, one file or one API can describe the entire flight.