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.

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.

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.

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.

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 document provides airlines, airframe manufacturers, aircraft equipment suppliers, and others with information that is specific to data, software, and ground tools used in aviation configuration and data management. As a starting point, this document provides guidance on: Which standard to use in specific situations The use of and how integrity checks should be applied Common terminology in airborne software management Since airplanes started using software controlled hardware, there has been a need to standardize processes and terminology. This document is the centroid to which other software standards are related.

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.

The purpose of this standard is to provide a method for packaging aircraft software parts for distribution using contemporary media or by electronic distribution. This project intends to standardize and provide guidance for the storage of floppy based software, currently packaged in media set parts. This standard format can be then stored or distributed on a single physical media member (CD-ROM), or by electronic crate. The obsolescence of floppy disks drive an urgent need for this guidance.

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.

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.

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.

ARINC Specification 848 is a functional standard based on a protocol specification profile for a secured network interface. The purpose is to define a common method of initiating a mutually authenticated tunnel between an aircraft service and its Enterprise service. ARINC Specification 848 defines a standard implementation for securing the communications between an onboard Local Area Network (LAN) and an Enterprise LAN on the ground. Various aircraft network architectures and various air to ground communication channels (aka media) are accommodated in this document. For example, L-band Satellite Communication (Satcom), Ku/Ka-band Satcom, Gatelink Cellular, and Gatelink are considered.

ARINC 818 defines the digital video interface standard intended for use in all types of flight deck displays. This document represents the aviation version of ANSI Fibre Channel Audio Video (FC-AV) defined by ANSI INCITS 356-2002. Supplement 3 Supports the latest digital video rates of 12 Gbps and higher using 64B/66B encoding and 28 Gbps using 256B/257B encoding.

This document provides an overview of the entire set of documents collectively referred to as ARINC 653. As this set of documents evolves, Supplements to Part 0 will be made more consistent with Parts 1 through 5 in conjunction with the technical changes expected to be 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 3 - Conformity Test Specification, Part 4 - Subset Services, and Part 5 - Core Software Required Capabilities. Supplement 1 reflects the introduction of multicore processor support in Parts 1 and 2.

This standard defines the air transport industry's standards for the transfer of digital data between avionics system elements. Part 2 provides the formats of data words with discrete bit encoding.

The purpose of this document is to provide an overview of data networking standards recommended for use in commercial aircraft installations. These standards provide a means to adapt commercially defined networking standards to an aircraft environment. It refers to devices such as bridges, switches, routers and hubs and their use in an aircraft environment. This equipment, when installed in a network topology, can optimize data transfer and overall avionics performance.