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

This standard sets forth the desired characteristics of a second-generation aviation Ku-band and Ka-band satellite communication (satcom) system intended for installation in all types of aircraft.

This document describes effective methods to manage and distribute operation flight software programs, aeronautical data bases and other forms of software used within an airline organization. Topics include software acquisition, software receiving, software distribution and necessary documentation. The FLS management process described in ARINC 667 is compatible with published FAA/EASA guidance on this subject. Software suppliers, airline users and regulators will find this document to be a practical and effective guide.

Mark 4 Air Traffic Control Transponder (ATCRBS/MODE S) describes an Air Traffic Control Radar Beacon System/Mode Select (ATCRBS/Mode S) airborne transponder with Extended Interface Functions (EIF). The ATC surveillance system is made up of airborne transponders and ground interrogator-receivers, processing equipment, and antenna systems. Mode S is a cooperative surveillance system for air traffic control with ancillary communications capabilities. ARINC 718A supports elementary surveillance. Provisional enhanced surveillance functionality is also defined as a customer option. The Mark 4 transponder, like its predecessor, will support Collision Avoidance System which includes TCAS and ACAS X functions.

This standard provides a data base comprising standards used for the preparation of a navigation system data base. This data may be used with the operational flight software in a wide range of navigational equipment.

The purpose of this document is to provide operational guidance for key life-cycle management, which refers to the phases through which digital certificates and associated cryptographic keys progress, from creation through usage to retirement. Additionally, this document provides implementation guidance for online certificate provisioning of aircraft systems. The scope includes both the onboard part (aircraft system) as well as the ground part (PKI provider and Ground Infrastructure). Consideration of both onboard and ground provides the benefit of security considerations being included in the process flow and chain of custody. Specifically, the management to and from the aircraft is defined within a workflow.

ARINC 653, Part 3A is the Compliance Test Specification for ARINC 653 Required Services presently defined in ARINC 653 Part 1. The document specifies a set of stimuli and the expected responses. Future work on the ARINC 653 document set includes an effort to define Operating System services for multi-core processor environments. The Compliance Test Specification is expected to be updated in step with ARINC 653, Part 1.

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.

ARINC 810 defines galley equipment physical attachments, envelopes, connections, and qualification guidelines for interchangeable galley equipment. Supplement 6 defines the new Extended Size 2, intended for oven installation and other equipment suited to this type of installation.

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.

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.

This document defines a standard implementation for strong client authentication and encryption of Wi-Fi-based client connections to onboard Wireless LAN (WLAN) networks. WLAN networks may consist of multi-purpose inflight entertainment system networks operating in the Passenger Information and Entertainment System (PIES) domain, dedicated aircraft cabin wireless networks or localized Aircraft Integrated Data (AID) devices operating in the Aircraft Information Services (AIS) domain. The purpose of this document is to focus on the client devices requiring connections to these networks such as electronic flight bags, flight attendant mobile devices, onboard Internet of Things (IoT) devices, AID devices (acting as clients) and mobile maintenance devices. Passenger devices are not within the focus of this document.

ARINC 661 defines logical interfaces to Cockpit Display Systems (CDS) used in all types of aircraft installations. The CDS provides graphical and interactive services to user applications within the flight deck environment. When combined with data from user applications, it displays graphical images to the flight deck crew. The document emphasizes the need for independence between aircraft systems and the CDS. This document defines the interface between the avionics equipment and display system graphics generators. This document does not specify the "look and feel" of any graphical information, and as such does not address human factors issues. These are defined by the airline flight operations community. Supplement 8 adds numerous changes and additions. Eleven new widgets are added, all related to 3D Maps. Seven new widget extensions. Metadata definitions (XML) for all widgets, extensions, events, symbols, and associated data types.

This document defines the User Interface Markup Language (UIML) which allows developers to specify the interface, look, and behavior of any Graphical User Interface (GUI). The GUI consists of several components, from the simplest, called primitive components (such as rectangle, text, image, group), to more complex components built by the aggregation of several primitive components and by providing relational specific logic. Also defined is the execution model, which provides the rules to interpret the language so that the graphical user interface has a standardized and consistent behavior defined for any platform.

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.

ARINC Specification 628, Cabin Equipment Interfaces (CEI) Part 5 Parts Selection, Wire Design and Installation Guidelines, provides design and mounting guidelines for electrical installations, mainly for supplier of cabin furnishing equipment. Part 5 addresses several aspects of installation and is divided into five sections: Introduction, Parts Selection, Electrical Wire Design Guidelines, Wire Installation Guidelines, and Documentation Guidelines. Guidelines regarding design, safety, and other subjects relevant to acceptance of the end item are addressed. Notes explaining the reason for setting a guideline or suggesting methods for performing the task are provided in commentary. The content of the document is designed to make it usable for reference by industry, particularly manufacturers of seats and equipment.

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.

ARINC Specification 485, Part 2 specifies the ARINC 485-control protocol used by the LRUs described in ARINC Specification 628 Part 2. This document defines a multi-drop bus. The point-to-point configuration is also supported. The point-to-point bus is treated simply as a multi-drop bus with only one drop. There is one master LRU and one or more slave LRUs present on the bus. However; multiple buses may be connected in parallel, where each parallel bus operates independently from each other.

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.