ARINC 633-1

PDF ONLY

The scope of this specification covers all the provisionsnecessary to enable communication between airborne and groundapplications.

Various types of communication can take place between aircraftand ground:

1. ACARS system traditionally enables theexchange of messages. These messages can be exchangedasynchronously 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 ofcommunications (transactional communications, such as databaseaccess, web access….) that do not involve individual messagesexchanges.

This specification addresses the first 2 types ofcommunications. When the need for standardization arises, othertypes of exchanges than message exchanges will be added.

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

Note:

‘Asynchronous ‘ communications means that thereis no need for the end applications to be active and ready tocommunicate during the communication. Typically, an application cansend a message to a ground message server, and the receivingapplication can retrieve it when it gets activated.

‘Synchronous’ communications is used here todepict exchanges where both end applications are active andcommunicating, allowing real bidirectional exchanges.

Transport technologies (especially TCP/IP based networks) areevolving rapidly; therefore the present document segregatesapplication level functionalities from transportfunctionalities.

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

• Applicative communications (the communication part of theapplication)

o Message Structure, content and encoding (ACARS and/or XMLdepending on the application)

o Minimum requirements on message processing / Dynamicaspects

o The objective here is to define ONLY those features necessaryfor 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 thisspecification.

• Transport (over ACARS, IP and physical media)

o This specification defines how the messages are transferredusing ACARS, IP networks, and physical media, i.e. USB stick orCD/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.

1. Message Structure designates the way amessage is organized and what data it contains in an abstractlanguage (before encoding for transmission) – in thisspecification, the message structure and content definition is donedirectly through definition of message encoding.

2. Data Encoding designates the way the data are represented(ASCII, fixed, variable length…) – for example, there is aspecific 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 areseparated, and encoded, before transmission (ASCII, fixed, variablelength…) – for example, there is a specific encoding for a givenmessage in ACARS, and in XML.

4. Packaging designates the way the data (or files) areencapsulated 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 applicationsthat lead to these message formats is outside the scope of thisdocument. The messages are standardized, but not the functionalitythat necessitates them. This is not a functional spec. However,some guidelines about how the standardized AOC messages may be usedare provided. This is done in two ways:

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

Some definition tables contain a column called “Example” andsome paragraphs contain textual examples that give guidance as towhich values could appear under specific conditions in a message,element or parameter.

It should be noted that using messages compliant to thisspecification may not be sufficient to ensure that a complexair-/ground systems runs properly.

Purpose of Document

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

• The message is defined by an airframe manufacturer, EFB oravionics vender such that it is not modifiable by the airline anddoes 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 asingle airline, for example, messages shared by multiple partiessuch as de-icing services shared in common among a group ofairlines from a single supplier.

COMMENTARY

Airlines may choose to define AOC applications in thisspecification that have safety implications. In the USA, the FAAmay classify the results of the delivery of such a message asconstituting more than a “minor hazard” should certain datacontained in the message become corrupted. In this case, theprinciples specified in RTCA DO-296 need to be observed by theimplementer. During the development of this specification someassessment of the safety impact of specified applications wasperformed, However, the airlines choosing to implementcommunication services defined in this specification will need toconsult their local authorities and may have to perform a hazardanalysis for certification of such applications.

This specification provides guidance for the encoding of themessages to be transmitted over the traditional ACARS air-groundlinks (VHF, SATCOM, and HF). The communications network technologyonboard aircraft is evolving to include Ethernet and TCP/IP basednetworks. Air-ground links that support these commercial protocolshave been available for some time. The configuration and equipageof cockpits is expanding to accept data through these commercialmedia. It is the intent of this specification to support multiplemethods of transmission: e.g., traditional character-oriented ACARSair-ground links and commercial network based environments thatutilize IP routing protocol and typically UDP or TCP Transportprotocol.

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

COMMENTARY

Supplement 1 (ARINC 633-1) introduced a break incompatibility with the initial release schema of ARINC 633 (ARINC633-0), and thus initial ARINC 633-0 applications and data sets.The AOC Subcommittee responsible for developing this specificationelected this path in order to provide a better foundation forfuture updates that will ultimately improve support for airlineoperations. Their rationale was that an early break incompatibility would have less of an effect (with fewer fieldedsystems) as opposed to a future release. Support of ARINC 633-1schema rather than the ARINC 633-0 schema is thus the recommendedsolution.

However, airlines and suppliers need to keep in mindthat ground data providers will need to produce two unique sets ofdata (initial ARINC 633-0 – compliant, and ARINC 633-1 – compliant)until such time as the aircraft ARINC 633-0 installations arephased out.

Edition:

10

Published:

03/12/2010

Number of Pages:

469

File Size:

1 file , 2.7 MB