ARINC 633

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 allows exchange of messages. Thesemessages 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 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 arise, 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 there is no need forthe end applications to be active and ready to communicate duringthe communication. Typically, an application can send a message toa ground message server, and the receiving application can retrieveit when it gets activated.

‘Synchronous’ communications is used here to depict exchangeswhere both end applications are active and communicating, allowingreal 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.

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

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

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

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

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

Edition:

07

Published:

06/30/2007

Number of Pages:

152

File Size:

1 file , 2 MB