The scope of this specification covers all the provisions necessary to enable communication between airborne and ground applications.

Various types of communication can take place between aircraft and ground:

1. ACARS system traditionally allows exchange of messages. These messages can be exchanged asynchronously or in a synchronous way (see note below).

2. Most EFB type applications also use messages to communicate (e.g. eFF, WBA).

3. EFB applications will need to be able to use other types of communications. (transactional communications, such as database access, web access....) that do not involve individual messages exchanges.

This specification addresses the first 2 types of communications. When the need for standardization arise, other types of exchanges than message exchanges will be added.

Depending on the type of exchanges, asynchronous or synchronous message exchanges are addressed in this document.

Note:

‘Asynchronous ‘ communications means that there is no need for the end applications to be active and ready to communicate during the communication. Typically, an application can send a message to a ground message server, and the receiving application can retrieve it when it gets activated.

‘Synchronous' communications is used here to depict exchanges where both end applications are active and communicating, allowing real bidirectional exchanges.

Transport technologies (especially TCP/IP based networks) are evolving rapidly; therefore the present document segregates application level functionalities from transport functionalities.

The document covers the air-ground communication function that can be functionally split into (see figure below):

• Applicative communications (the communication part of the application)

o Message Structure, content and encoding (ACARS and/or XML depending on the application).

o Minimum requirements on message processing / Dynamic aspects.

o The objective here is to define ONLY those features necessary for interoperability – the document focuses on data description (XML schemas), but also specifies minimum communication services. The way the data are processed / operated is not defined in this specification.

• Transport (over ACARS, IP and physical media)

o This specification defines how the messages are transferred using ACARS, IP networks, and physical media, i.e. USB stick or CD/DVD:

• Data packaging (e.g. ARINC 665 for IP/Physical media)

• Transport of data (e.g. HTTPs over TCP/IP, or ACARS)

• Security services: Encryption and compaction provisions (provisions only at the time of this writing)

Note: Some definitions to complement text above.

• Designates the way a message is organized and what data it contains in an abstract language (before encoding for transmission) – in this specification, the message structure and content definition is done directly through definition of message encoding.

• Data Encoding designates the way the data are represented (ASCII, fixed, variable length...) – for example, there is a specific encoding in ACARS, and in XML.

• Message encoding designates the way a message is represented (in terms of structure and data) and data inside these messages are separated, and encoded, before transmission (ASCII, fixed, variable length...) – for example, there is a specific encoding for a given message in ACARS, and in XML.

• Packaging designates the way the data (or files) are encapsulated and associated to other data for transport (e.g. Packaging a given file or message in an ARINC 633 signed load

Listing operational requirements or specifying the applications that lead to these message formats is outside the scope of this document. The messages are standardized, but not the functionality that necessitates them. This is not a functional spec. However, some guidelines about how the standardized AOC messages may be used are provided. This is done in two ways:

1. Some definition tables contain a column called "Meaning" or "Purpose" explaining the operational or functional context in which the message, element or parameter could generally be used.

2. Some definition tables contain a column called "Example" and some paragraphs contain textual examples that give guidance as to which values could appear under specific conditions in a message, element or parameter.

It should be noted that using messages compliant to this specification may not be sufficient to ensure that a complex air-/ground systems runs properly.

Purpose of Document

The purpose of this specification is to support the exchange of certain Aeronautical Operational Control (AOC) air-ground and ground-ground messages. These messages are defined in this specification, apart from those defined in ARINC Specification 620, because they have unique qualities. Like the messages defined in ARINC Specification 620, their usage necessitates a single definition. Further, the messages have at least one of the following characteristics:

• The message is defined by an airframe manufacturer, EFB or avionics vender such that it is not modifiable by the airline and does not fit into an existing ARINC Specification e.g., ARINC 622 (FANS), ARINC 623 (ATS) or ARINC 702 (FMS).

• The distribution of the message is outside the control of a single airline, for example, messages shared by multiple parties such as de-icing services shared in common among a group of airlines from a single supplier.