ARINC 633

Description / Abstract: 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 typically defined by an airframe manufacturer, Electronic Flight Bag (EFB) or avionics suppliers such that it is not modifiable by the airline and does not easily fit into an existing ARINC Standard, e.g., ARINC Specification 622 (FANS), ARINC Specification 623 (ATS), or ARINC Characteristic 702A (FMS).

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

COMMENTARY

Airlines may choose to define AOC applications in this specification that have safety implications. In the USA, the FAA may classify the results of the delivery of such a message as constituting more than a “minor hazard” should certain data contained in the message become corrupted. In this case, the principles specified in RTCA DO-296: Safety Requirements Standard for Aeronautical Operational Control (AOC) Datalink Messages, need to be observed by the implementer. Airlines choosing to implement communication services defined in this specification will need to consult their local authorities and may have to perform a hazard analysis for certification of such applications.

This specification provides guidance for the encoding of the messages to be transmitted over the traditional Aircraft Communications Addressing and Reporting System (ACARS) air-ground links (i.e., Very High Frequency (VHF), Satellite Communication (Satcom), and High Frequency (HF)). The communications network technology onboard aircraft is evolving to include Ethernet and Transmission Control Protocol/Internet Protocol (TCP/IP) based networks. Air-ground links that support these commercial protocols have been available for some time. The configuration and equipage of cockpits is expanding to accept data through these commercial media. It is the intent of this specification to support multiple methods of transmission (e.g., traditional character-oriented ACARS air-ground links and commercial network based environments that utilize IP routing protocol and typically User Datagram Protocol (UDP) or TCP Transport protocol).

When using TCP/IP based ground-ground and air-ground links, this specification encourages the use of Extensible Markup Language (XML) for message coding. Therefore, for most applications, ACARS and XML message definitions (Schemas) have been designed.

Supplement 1 (ARINC 633-1) introduced a break in compatibility with the initial release schema of ARINC 633, and thus initial ARINC 633 applications and data sets. The AOC Subcommittee responsible for developing this specification elected this path in order to provide a better foundation for future updates that will ultimately improve support for airline operations. Their rationale was that an early break in compatibility would have less of an effect (with fewer fielded systems) as opposed to a future release. Support of the latest ARINC 633 schema rather than previous ARINC 633 schemas is thus the recommended solution.

However, airlines and suppliers need to keep in mind that ground data providers may need to produce various unique sets of data (ARINC 633-1, ARINC 633-2, and ARINC 633-3 compliant) until such time that previous aircraft ARINC 633 installations are phased out.

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 enables the 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., electronic Flight Folder (eFF), Weight and Balance Application (WBA))

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

This specification addresses the first two types of communications. When the need for standardization arises, 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 1.2-1):

• 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., Hypertext Transfer Protocol (HTTP)s 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:

1. Message Structure 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.

2. Data Encoding designates the way the data are represented (ASCII, fixed, variable length, etc.) – e.g., there is a specific encoding in ACARS, and in XML.

3. 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, etc.) – e.g., there is a specific encoding for a given message in ACARS, and in XML.

4. 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 specification. However, some guidelines about how the standardized AOC messages may be used are provided. This is done in two ways:

• 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.

• 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.