ARINC 633-2

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 the exchange of messages.These messages can be exchanged asynchronously or in a synchronousway (see note below)

2. Most EFB type applications also use messages to communicate(e.g., electronic Flight Folder (eFF), Weight and BalanceApplication (WBA))

3. EFB applications will need to be able to use other types ofcommunications (transactional communications, such as databaseaccess, web access, etc.) 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., Hypertext Transfer Protocol (HTTP)sover TCP/IP, or ACARS)

• Security services: Encryption and compaction provisions(provisions only at the time of this writing) Note: Somedefinitions to complement text above.

1. Message Structure designates the way a message is organizedand what data it contains in an abstract language (before encodingfor transmission) – in this specification, the message structureand content definition is done directly through definition ofmessage encoding.

2. Data Encoding designates the way the data are represented(ASCII, fixed, variable length, etc.) – e.g., there is a specificencoding 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, etc.) – e.g., 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 specification.However, some guidelines about how the standardized AOC messagesmay 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 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 Specification 620, their usage necessitates a singledefinition. Further, the messages have at least one of thefollowing characteristics:

• The message is typically defined by an airframe manufacturer,Electronic Flight Bag (EFB) or avionics suppliers such that it isnot modifiable by the airline and does not easily fit into anexisting ARINC Specification e.g., ARINC Specification 622 (FANS),ARINC Specification 623 (ATS) or ARINC Characteristic 702 (FMS)

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

Edition:

12

Published:

11/28/2012

Number of Pages:

653

File Size:

1 file , 6.7 MB