Search Results

This document describes Airborne Collision Avoidance System X (ACAS X) functionality and provides the necessary interface definitions and protocols to accommodate the requirements of RTCA DO-385: Minimum Operational Performance Standards for Airborne Collision Avoidance System X (ACAS X) ACAS Xa and ACAS Xo) (latest version applies) and the requirements of RTCA DO-386: Minimum Operational Performance Standards for Airborne Collision Avoidance System X (ACAS X) ACAS Xu (latest version applies). Additionally, this document describes interfaces and protocols necessary to accommodate Cockpit Display of Traffic Information (CDTI) based on the reception of Automatic Dependent Surveillance-Broadcast (ADS-B) data and Traffic Information Services–Broadcast (TIS-B) data. The equipment becomes ACAS X with ADS-B IN applications added, as defined by RTCA DO-317C: Minimum Operational Performance Standards for (MOPS) for Aircraft Surveillance Applications (ASA) Systems (latest version applies).

The purpose of ARNC 633 is to specify the format and exchange of Aeronautical Operational Control (AOC) communications. Examples of ARINC 633 AOC Structures/Messages include: Flight Plan, Load Planning (i.e., Weight and Balance and Cargo Planning Load Sheets), NOTAMs, Airport and Route Weather data, Minimum Equipment Lists (MEL) messages, etc. The standardization of AOC messages enable the development of applications shared by numerous airlines on different aircraft types. Benefits include improved dispatchability and reduce operator cost.

This document provides an overview of the entire set of documents collectively referred to as ARINC 653. As this set of documents evolves, Part 0 has been adjusted to reflect technical changes made in Supplements to Parts 1 through 5 in conjunction with the technical changes made in the evolution of ARINC 653. A summary of the ARINC 653 documents follows: Part 0 – Overview of ARINC 653 Part 1 – Required Services Part 2 – Extended Services Part 3A – Conformity Test Specification for ARINC 653 Required Services Part 3B – Conformity Test Specification for ARINC 653 Extended Services Part 4 – Subset Services Part 5 – Core Software Recommended Capabilities The term “this document” refers to Part 0 only, while the term “ARINC 653” or “the Specification” refers to the whole set of ARINC 653 documents, currently Parts 0 to 5.

ARINC Report 679 defines the functional characteristics of an airborne server that will support Electronic Flight Bags (EFBs) and similar peripherals used in the flight deck, cabin, and maintenance applications. The document defines how EFBs will efficiently, effectively, safely, and securely connect to the airborne server in a way that offer expanded capabilities to aircraft operators. The airborne server has two main functions, first to provide specific services to connected systems, and second to provide centralized security for the EFB and its data. This document is a functional airborne server definition. It does not define the physical characteristics of the server.

The purpose of this specification is to define the general Galley Insert (GAIN)standardization philosophy, provide comprehensive equipment interfaces, and disseminate the most current industry guidance. Part 1 covers the Controller Area Network (CAN) data interface attachments, envelopes, and data content to be considered between all galley equipment using a Galley Data Bus as described within this specification. This document is intended as the successor and replacement for ARINC Specification 812. This document contains significant improvements to CAN data interfaces.

This specification describes the general connectors, contacts, and backshells in their shape and characteristic for cabin systems for commercial aircrafts. ARINC 600, ARINC 404, and ARINC 801 connector specifications are published as independent standards.

The difficulty in locating crash sites has prompted international efforts for alternatives to quickly recover flight data. This document describes the technical requirements and architectural options for the Timely Recovery of Flight Data (TRFD) in commercial aircraft. ICAO and individual Civil Aviation Authorities (CAAs) levy these requirements. The ICAO Standards and Recommended Practices (SARPs) and CAA regulations cover both aircraft-level and on-ground systems. This report also documents additional system-level requirements derived from the evaluation of ICAO, CAA, and relevant industry documents and potential TRFD system architectures. It describes two TRFD architectures in the context of a common architectural framework and identifies requirements. This report also discusses implementation recommendations from an airplane-level perspective.

The purpose of this document is to provide guidelines for integrating previously standalone cabin systems such as cabin management systems, In-Flight Entertainment (IFE) systems, In-Flight Connectivity (IFC) systems, galley systems, surveillance systems, etc. Resource sharing between systems can reduce airline costs and/or increase functionality. But, as systems expose their internal resources to external systems, the risk of an intrusion that could degrade function and/or negatively expose the supplier’s or airline’s brand increases. This document provides a recommended IP networking design framework between aircraft systems to reduce the operational security threats while still supporting the necessary intersystem routing.

ARINC 858 Part 2 provides aviation ground system gateway considerations necessary to transition to the Internet Protocol Suite (IPS). ARINC 858 Part 2 describes the principles of operation for an IPS gateway that enables ACARS application messages to be exchanged between an IPS aircraft and a ground ACARS host. ARINC 858 Part 2 also describes the principles of operation for an IPS gateway that enables OSI-based application messages to be exchanged between an IPS host and an OSI end system. This product was developed in coordination with ICAO WG-I, RTCA SC-223, and EUROCAE WG-108.

ARINC 858 Part 1 defines the airborne data communication network infrastructure for aviation safety services using the Internet Protocol Suite (IPS). ARINC 858 builds upon ICAO Doc 9896, Manual on the Aeronautical Telecommunication Network (ATN) using Internet Protocol Suite (IPS) Standards and Protocol. IPS will extend the useful life of data comm services presently used by operators, e.g., VDL, Inmarsat SBB, Iridium NEXT, and others. It represents the evolutionary path from ACARS and ATN/OSI to the end state: ATN/IPS. ARINC 858 includes advanced capabilities such as aviation security and mobility. This product was developed in coordination with ICAO WG-I, RTCA SC-223, and EUROCAE WG-108.

ARINC Specification 620 defines the interfaces between the Datalink Service Provider (DSP) and the aircraft, other ground-based datalink services, and users. The datalink ground system standard definition supports traditional ACARS and AOA protocols, as well as Media Independent Aircraft Messaging (MIAM) as defined by ARINC Specification 841. MIAM messages can be much larger than ACARS messages (5 MB versus 3.3 kB per message). Supplement 10 improves Controller-Pilot Data Link Communications (CPDLC) by defining a “Deliver By (DB)” period that allows the DSP, that originated the message, to intercept and discard the message if it is not delivered by the specified time. Supplement 10 also adds a Media Advisory code for ACARS over IP (AoIP) indicating that an ACARS non Safety Services messages is being transferred over IP links. New Reason Codes are assigned for un-transmittable or undeliverable messages. ACARS Character set clarifications are also provided in Supplement 10.

This document defines an Aircraft Data Interface Function (ADIF) developed for aircraft installations that incorporate network components based on commercially available technologies. This document defines a set of protocols and services for the exchange of aircraft avionics data across aircraft networks. A common set of services that may be used to access specific avionics parameters are described. The ADIF may be implemented as a generic network service, or it may be implemented as a dedicated service within an ARINC 759 Aircraft Interface Devices (AID) such as those used with an Electronic Flight Bag (EFB). Supplement 8 includes improvements in the Aviation Data Broadcast Protocol (ADBP), adds support for the Media Independent Aircraft Messaging (MIAM) protocol, and contains data security enhancements. It also includes notification and deprecation of the Generic Aircraft Parameter Service (GAPS) protocol that will be deleted in a future supplement.

This document describes the functions to be performed by airborne and ground components of the VDLM2 to successfully transfer messages from VHF ground networks to avionics systems on aircraft and vice versa where the data are encoded in a code and byte independent format. The compatibility of VDLM2 with OSI is established by defining a set of services and protocols that are in accordance with the OSI basic reference model. The compatibility with the ATN protocols is achieved by defining a set of interfaces between the VDLM2 subnetwork protocol specification and the Mobile Subnetwork Dependent Convergence Function (MSNDCF). The SNDCF is defined in the ICAO ATN SARPs.

This standard defines the electrical characteristics, protocol and data content for a modified version of the EIA RS-485 data bus adapted for use with cabin electronics equipment. Specific cabin equipment interfaces are defined by ARINC 628.

This standard defines a new cabin network bus. While ARINC Specification 485: Cabin Equipment Interfaces, Part 2, Physical Layer – In-seat Protocol defined a low-speed serial communications interface between electronic equipment in the passenger seat, it is design-focused on obtaining status from in-seat electronic equipment. ARINC Specification 854 is a messaging protocol but does not preclude using the bus for video streaming or multicast. Cabin Equipment has evolved from the very simple to quite sophisticated systems. The resulting communications needs have surpassed the ability of ARINC 485 to provide the necessary data capacity and response times. The basic requirements for low latency, full duplex, elimination of ARINC 485 Master/Slave polling and lower weight drives the selection of 100BASE-T1 (per IEEE 802.3) as the preferred bus format.

This ARINC Standard defines the installation characteristics of first generation L-band satellite communication systems. It provides the traditional form, fit, function, and interfaces for the installation of satcom equipment for use in all types of aircraft. Description of avionics equipment (e.g., Satellite Data Unit (SDU), Antennas, etc.) are included. Supplement 15 adds references to new Diplexer/Low Noise Amplifiers (DLNAs) defined in Supplement 8 to ARINC Characteristic 781: Mark 3 Aviation Satellite Communication Systems. The five new DLNAs are intended to protect Inmarsat Classic Aero and SwiftBroadband (SBB) satcom equipment from ground-based cellular sources, such as cellular Long Term Evolution (LTE) and Ancillary Terrestrial Component (ATCt). The DLNAs are categorized by desired features and service (e.g., new DLNA versus drop-in replacement, LTE and/or ATCt protection, Classic Aero and/or SBB service).

This ARINC Standard defines the installation characteristics of second generation L-band satellite communication systems. It provides the traditional form, fit, function, and interfaces for the installation of satcom equipment for use in all types of aircraft. Description of avionics equipment (e.g., Satellite Data Unit (SDU), Antennas, etc.) are included. Supplement 6 adds references to new Diplexer/Low Noise Amplifiers (DLNAs) defined in Supplement 8 to ARINC Characteristic 781: Mark 3 Aviation Satellite Communication Systems. The five new DLNAs are intended to protect Inmarsat Classic Aero and SwiftBroadband (SBB) satcom equipment from ground-based cellular sources, such as cellular Long Term Evolution (LTE) and Ancillary Terrestrial Component (ATCt). The DLNAs are categorized by desired features and service (e.g., new DLNA versus drop-in replacement, LTE and/or ATCt protection, Classic Aero and/or SBB service).

As avionics software continues to evolve, so does ARINC Specification 653. ARINC 653 Part 2 specifies extensions (i.e., optional services) to the required Application Program Interfaces (APIs) described in ARINC 653 Part 1. Supplement 4 adds optional multicore services capabilities.

This standard defines a general-purpose Application/Executive (APEX) software interface between the Operating System of an avionics computer and the application software. The interface requirements between the application software and operating system services are defined in a manner that enables the application software to control the scheduling, communication, and status of internal processing elements. Supplement 5 adds multicore processor service capabilities.

This standard sets forth the desired characteristics of Aviation Ku-band Satellite Communication (Satcom) and Ka-band Satcom Systems intended for installation in all types of commercial air transport aircraft. The intent of this characteristic is to provide guidance on the interfaces, form, fit, and function of the systems. This document also describes the desired operational capability of the equipment needed to provide a broadband transport link that can be used for data, video, and voice communications typically used for passenger communications and/or entertainment. The systems described in this characteristic are not qualified, at this writing, for aviation safety functions.