AVIATION

INFORMATION
DATA
EXCHANGE
INTERFACE

RECOMMENDED
PRACTICE

INTERNATIONAL AIR TRANSPORT ASSOCIATION

RECOMMENDED PRACTICE 1797A

AIR TRANSPORT ASSOCIATION

RECOMMENDED PRACTICE 30.201A

AIRPORTS COUNCIL INTERNATIONAL

RECOMMENDED PRACTICE 501A07

AIDX Version: 01.00 *** DRAFT ***

Document Issue: 01.00.0000
Last Updated: 07AUG2008
 AVIATION
INFORMATION
DATA
EXCHANGE
INTERFACE

RECOMMENDED
PRACTICE

INTERNATIONAL AIR TRANSPORT ASSOCIATION

RECOMMENDED PRACTICE 1797A

AIR TRANSPORT ASSOCIATION

RECOMMENDED PRACTICE 30.201A

AIRPORTS COUNCIL INTERNATIONAL

RECOMMENDED PRACTICE 501A07

AIDX Version: 01.00 *** DRAFT ***

Document Issue: 01.00.0000
Last Updated: 07AUG2008
 2005-2008, IATA, ATA, ACI. All rights reserved.

First edition: 03JUN2007

Acknowledgments:
ActiveX is a registered trademark of Microsoft Corporation.
Acrobat is a registered trademark of Adobe Systems Incorporated.
Citrix is a registered trademark of Citrix Systems, Inc.
Intel is a registered trademark of Intel Corporation.
Intel Core is a trademark of Intel Corporation.
Java and JRE are trademarks of Sun Microsystems, Inc.
Windows is a registered trademark of Microsoft Corporation.
Windows Vista is a trademark of Microsoft Corporation.
 1

Contents

1. Introduction.................................................................................................................. 3

1.1. Use of the AIDX Information .........................................................................................3

1.2. Senders and Receivers ....................................................................................................4

2. Usage Scenarios............................................................................................................ 5

2.1. Normal Mode ..................................................................................................................5

2.2. Potential Areas of Usage.................................................................................................5
2.2.1. Possible Usage 1............................................................................................6
2.2.2. Possible Usage 2............................................................................................6
2.2.3. Possible Usage 3............................................................................................6

3. AIDX Technical Specification Summary................................................................... 7

3.1. Data Exchanged ..............................................................................................................7

3.1.1. Data Structure ................................................................................................7
3.1.2. Data Elements................................................................................................7
3.1.3. XML Schema.................................................................................................8
3.1.4. Resolving Data Differences...........................................................................8
3.1.5. Proprietary Data.............................................................................................8
3.2. Data Transport.................................................................................................................8

4. Management of the Schema ........................................................................................ 9

4.1. Availability of Standard ..................................................................................................9

5. Roles and Responsibilities of AIDX Parties............................................................. 11

5.1. Data Senders Responsibility ........................................................................................11

5.2. Data Receivers Responsibility.....................................................................................11
5.3. Certification ..................................................................................................................12

6. Bilateral Interface Agreement .................................................................................. 13

7. References................................................................................................................... 15

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

7.1. Standards.......................................................................................................................15
7.2. Definitions.....................................................................................................................15
 3

Aviation Information Data Exchange (AIDX) Interface

Recommended Practice

RECOMMENDED that, when an airline, airport or associated service provider plan to exchange
Domestic or International flight or flight related information for the purposes of displaying or
accruing such information, the specifications and standards as described in this Recommended
Practice shall be applied.

1. Introduction

The Aviation Information Data Exchange (AIDX) Interface Recommended Practice describes the
use of interface specifications and standards by which airlines, airports and other participants
exchange information within or between their systems and organizations. The data exchanged is
intended to be used for Domestic or International flights in the current Operational Window, and
not for sending monthly schedules.

1.1. Use of the AIDX Information

This RP does not state or define how the AIDX data will be used. However examples of the
applications that will make use of the data might be Flight Information Display System (FIDS),
Resource Management System (RMS) or Baggage Handling Systems (BHS). Any data that may
be shared by or provided to a 3rd party have to be agreed upon in bilateral agreements between
sender and receiver. It is possible that information will be communicated to areas outside the
airport.

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

4 Chapter 1: Introduction

1.2. Senders and Receivers

AIDX assumes there will be at minimum a Data Sender and a Data Receiver who exchange
AIDX data over networks using predetermined protocols and formats. The Senders typically
would be airlines, and the Receivers would be airports or FIDS vendors. Other Senders of data
might be the FAA and other third-party providers of real time air traffic data. The expectation is
that all Senders and Receivers of AIDX data exchange will use the IATA PADIS XML
Schema(s). The objective of this RP is to ensure that the Data Receiver obtains the correct flight
information in a timely and reliable manner.
 5

2. Usage Scenarios

2.1. Normal Mode

AIDX assumes there will be at minimum a Data Sender and a Data Receiver who exchange
AIDX data over networks using predetermined protocols and formats defined in a Bilateral
Interface Agreement. This is the expected mode of operation for the directions contained within
this RP for one data sender and one data receiver. The illustration shows the expected data flow -
Data Sender to Data Receiver.

2.2. Potential Areas of Usage

This document does not define or make any recommendations as to the implementation of the
potential additional usage of the AIDX data. Below are examples that might exist. There may be
an Intermediate Receiver which receives AIDX data from the Data Sender and passes it on to one
or more Data Receivers. In such a case, the Intermediate Receivers responsibilities will be
similar to both a Data Receiver and Data Sender.

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

6 Chapter 2: Usage Scenarios

2.2.1. Possible Usage 1

2.2.2. Possible Usage 2

2.2.3. Possible Usage 3

 7

3. AIDX Technical Specification Summary

To exchange the data as described in this Recommended Practice, the below description and
definitions form the AIDX requirements for the data exchange.
The AIDX standard does not dictate stringent requirements on the information sent and instead
relies on the participants to clarify their data requirements based upon what data is described in
the standard.
Different operational windows may and probably will exist for each data sender transmitting data
to a receiver.

3.1. Data Exchanged

This section defines the data to be exchanged and its structure.

3.1.1. Data Structure

The Unique Flight Identifier is made up of the minimum data fields needed to uniquely identify a
flight leg. The unique flight identifier may include carrier code, flight number (and suffix),
departure data, departure airport code, and arrival airport code as defined in the schema.

3.1.2. Data Elements

The Schema identifies an extensive set of optional data elements, which are held in groups based
on operational type e.g. arrival times and airport resources. The data elements cover public and
non-public aspects. The intent is that this RP will be employed for a number of different
applications. Therefore each time the RP is employed the potential sub-set of optional data will
probably differ. With the exception of the Unique Flight Identifier, all of the data elements in the
Schema are optional.

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

8 Chapter 3: AIDX Technical Specification Summary

3.1.3. XML Schema

The XML Schema will follow the IATA PADIS XML best practices and standards and will be
developed, maintained and published by IATA PADIS XMLWG under the PADIS Board.

3.1.4. Resolving Data Differences

In some cases there could be multiple parties sending the same flight information, for example
estimated arrival time sent from an airline or FAA or third party. There may be differences in the
data depending on the Sender. It is the responsibility of the Receiver to resolve this issue.

3.1.5. Proprietary Data

As many of the fields are optional, it will be at the discretion of the Sender and Receiver to agree
what data elements will be sent. Within the standard there are a set of minimum data
requirements that has to be sent. Outside of the minimum requirements, the Sender and Receiver
shall agree on how the data is to be used, stored, shared and secured. A bilateral agreement shall
be established between sender and receiver on data exchanged and responsibilities for recipient of
data, such as (but not limited to) 3rd party access, confidentiality of data, storage of data and
usage of data.

3.2. Data Transport

The recommended practice does not specify a method of data transport of the XML data. This
will be an agreement between the Sender and Receiver. Common protocol such as web services,
HTTPS, SOAP, or FTP are expected to be used. The transport could be through a B2B VPN over
the internet or a leased line. Uni-directional serial connections should be avoided; rather an
architecture of standard open connections is recommended. It is the responsibility of the Sender
and the Receiver to set up their transport method and determine the level of security required in
their Interface Agreement.
 9

4. Management of the Schema

The XML Standard is developed, maintained and published by PADIS XMLWG under the IATA
PADIS Board. The request for changes to the developed standard shall be requested by or through
the CUSS Management Group and its associated Working Groups.

4.1. Availability of Standard

IATA shall produce, update, and make available the IATA PADIS standard XML Schema(s) and
supporting documentation for AIDX Data exchange standard in electronic format and make it
available to potential Senders and Receivers using existing screening and access rules to the
IATA PADIS XML release site. The PADIS XML standards will be published on a separate
IATA Extranet site, URL is https://extranet.iata.org/sites/padis_xml_typex_releases/default.aspx.

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

 11

5. Roles and Responsibilities of AIDX Parties

This section addresses the roles and responsibilities of the various AIDX parties, as they pertain
to overall interface provisioning and maintenance during live operation.

5.1. Data Senders Responsibility

The Sender will ensure that:

Transmitted flight records conform to the IATA AIDX methods and schema as defined in
the IATA PADIS XML release site.

When a flight message is sent, it contains the latest information and that it is sent in a
timely manner.

Every time the sender sends a message, it will include every data item within the agreed
subset with values known at the time of message transmission. The message will contain
no indication of what data may have changed from previous transmissions.

Messages are sent within the window agreed between the sender and receiver.

5.2. Data Receivers Responsibility

The Receiver will ensure that:

Optional acknowledgment message are sent as agreed in the interface agreement.

Use of the data conforms to any commercial restrictions as agreed with the sender of the
information ( i.e. Passenger figures are to be used only on airport staff screens)

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

12 Chapter 5: Roles and Responsibilities of AIDX Parties

5.3. Certification

There is no certification required. This is an agreement between the parties to deploy the IATA
PADIS XML standards for exchange of AIDX data. If certificate or encryption of data has to take
place, this will also be part of the bilateral agreement between sender and receiver.
 13

6. Bilateral Interface Agreement

Before implementation of a AIDX link, the sender and receiver should create a Bilateral Interface
Agreement which records various technical and commercial factors which are necessary for the
satisfactory implementation. The parties should agree on at least the following:

What optional fields will be included in their specific interface. This will define the
maximum subset of the flight message schema which the sender is capable of sending

Network communications, transport protocols and related factors.

How to resolve differences in data received from other parties.

Agreement of any features defined as optional in this RP

The maximum subset of the flight message schema which the sender is capable of
sending.

The use of the optional data request message from the data recipient.

The use of optional message application acknowledgement and/or error detection feature
from the data recipient including any timeout parameters

Any other information which needs to be agreed for the unambiguous implementation
and operation of the sender to receiver interface

NOTE a interface agreement template will be attached

NOTE a SLA template will be attached

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

 15

7. References

7.1. Standards

The AIDX Interface Standard references and acknowledges the standards shown below.

Table 7.1: IATA and ACC Recommended Practices

IATA ACC Title
RP-1785 Public Information Systems and Standards
ACC ITS 0010 ACC Airports IT & Systems Guidelines
RP-1797 CUPPS Technical Standard

7.2. Definitions

For the purposes of this Recommended Practice, the following definitions will apply:
Certification.
The process by which an application or platform is validated to ensure proper operation against
the defined specifications. There is no certification of the AIDX interface deployment other than
the agreements between the parties to utilize the IATA PADIS XML standards for exchange of
AIDX data.
CUPPS.
Common Use Passenger Processing Systems.
Data Sender.
The entity that creates the AIDX data to be distributed to others.
Data Receiver.
The entity that receives the AIDX data for use within that entitys systems and organization.
AIDX.
Aviation Information Data Exchange intended to provide flight data to various systems.
Intermediate Receiver.

AIDX-RP-V01.00-I01.00.0000.DOC *** DRAFT ***

16 Chapter 7: References

The entity that receives the AIDX data from the Data Sender on behalf of another Receiver.
Interface System.
Comprises the network, server, software and data storage components required to receive and
utilize the AIDX data.
Leg-Based Flights.
An aircraft movement comprising the flight between a departure airport and the corresponding
arrival airport
Network.
The communications equipment, software, cabling (wire, fiber, wireless), protocols and rules that
securely delivers AIDX data between Data Sender and Data Receiver.
Node-Based Flights.
When a flight is considered from an airports point of view. It can be either an arrival out of a
particular airport or a departure out of a particular airport. Each leg would have two node based
flights: a departure flight at the legs origin and an arrival flight at the legs destination.
Operational Window
That period agreed between the relevant parties, in which updates to flights operating in the
window are required for distribution to interested parties. Note, the primary use of the AIDX
standard is during the operational window, but wider usage is not excluded.
PADIS
Passenger and Airport Data Interchange Standards.
Unique Flight Identifier
The data fields which together define a unique flight leg
XML
Extensible Markup Language, the open standard for data formatting used by the AIDX protocol.