Search Results

This documents defines the Installation Characteristics of an airborne radio transceiver capable of broadband wireless communication with an Airport Surface Network. The Aeronautical Mobile Airport Communications System (AeroMACS) Radio Unit (ARU) will operate in the aeronautical protected frequency of 5091 MHz to 5150 MHz, utilizing the IEEE 802.16e WiMAX protocol. It is intended to offload some of the congested narrowband VHF airport traffic used for ATS and AOC communications. ARU and Antenna Form, Fit, Function and Interfaces are described.

This document defines the characteristics necessary to standardize the airborne recorder download file format in order to facilitate data import, transcription, and exchange. A standardized data format will reduce the variety of readout equipment required for airborne recorder data transcription. This document defines the detailed architecture of the Recorder Standard Output (RSO) file. The architecture is a tagged file structure within which many different files and their formats can be supported. The structure is necessary to support newer recording requirements for flight data, data link, audio, and image recording. This structure is intended for use with all civil recorders and should support use with military recorders.

This specification provides the overview of aircraft data networks installed in air-transport aircraft, tutorial information for adaptation of commercial network standards to air-transport aircraft, and terminology used to describe aircraft data networks. This specification explains the dependency of Aircraft Data Network (ADN) standards on network standards developed by the Internet community, IEEE, and ISO. The classes, Compliant Networks and Profiled Networks, used to characterize aircraft networks are introduced.

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

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 Parts 1 through 5 will be made more consistent with Part 0 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.

The purpose of this standard is to provide a source of definitions of terms and acronyms commonly used in the air transport maintenance community for test and evaluation with an emphasis on terms applicable to BITE.

This document is the first of a multi-part specification that will provide a catalog of cabin connector and cables that may be used in ARINC Standard cabin systems, including In-Flight Entertainment. Part 1 describes connector and cable requirements and evaluation criteria for the interface components used in the integration of cabin systems. Future releases will define connectors, contacts, and termination methods in Part 2. Cables will be specified in Part 3.

This document provides guidance for the development and installation of a Cockpit Voice Recorders (CVR) with solid-state memory. Supplement 6 provides the following: " The optional interfaces to data link services and On-Board Maintenance System (OMS) were revised to clarify that if the optional interface is implemented, then it shall be implemented in a specific way. " The power input section was revised to clarity the need for the CVR to be designed to accept 115 Vac power and 28 Vdc power from the aircraft. " The time correlation requirement was revised to specify that the CVR should receive its time signal from the same source as the Flight Data Recorder (FDR). " The OMS interface was updated to describe the correct ARINC 429 Sign Status Matrix (SSM) encoding for new CVR designs.

This Characteristic provides guidance for the development and installation of a new generation of Cockpit Voice Recorders (CVRs) using solid-state memory. This document supersedes the earlier ARINC Characteristic 557. ARINC Characteristic 757A is intended to coexist with ARINC Characteristic 757 CVR. Supplement 1 provides the following: " The CVR unit description was updated to clarify the differences in the equipment designed to ARINC 757A versus that designed to ARINC 757, i.e., data link and OMS interfaces are required for ARINC 757A compliance. " Material was added to maintain document alignment with ARINC 757 which has FDR capability. ARINC 757A recorders are not required to have FDR capability. " The time correlation requirement was revised to specify that the CVR should receive its time signal from the same source as the Flight Data Recorder (FDR). " The OMS interface was updated to describe the correct ARINC 429 Sign Status Matrix (SSM) encoding for new CVR designs.

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.

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.

This product is a Zip file that contains a subset of material in ARINC Specification 429, Part 1. Specifically: Attachment 1-1, Label Codes, in an Excel file; Attachment 1-2, Equipment Codes, in a Word file; Attachment 2A, Data Standards - BCD Data, in a Word file; and Attachment 2B, Data Standards - BNR Data, in a Word file.

This standard includes specific requirements necessary to support flight data recording and other flight data acquisition needs. Design details necessary to ensure interchangeability of equipment in a standard aircraft installation is included.

This document defines an open encoding format for airport databases which are loaded in airborne systems. This format, when designed and implemented, will enable a quick, economic, and efficient use of AMDB. However, since industry does not require applications to be standardized, data interpretation is not addressed in this document.

This document defines an open encoding format for airport databases which are loaded in airborne systems. This format, when designed and implemented, will enable a quick, economic, and efficient use of AMDB. However, since industry does not require applications to be standardized, data interpretation is not addressed in this document.

This document defines an open encoding format for airport databases which are loaded in airborne systems. This format, when designed and implemented, will enable a quick, economic, and efficient use of AMDB. However, since industry does not require applications to be standardized, data interpretation is not addressed in this document.

This document defines an open encoding format for obstacle databases. This format, when designed and implemented, will enable a quick, economic, and efficient use of Obstacle Databases (ObsDBs). However, since industry does not require applications to be standardized, data interpretation is not addressed in this document.

This document defines an open encoding format for terrain databases. This format, when designed and implemented, will enable a quick, economic, and efficient use of Terrain Databases (TerrDBs). However, since industry does not require applications to be standardized, data interpretation is not addressed in this document.

This document is intended to provide design guidance for the development and installation of an Enhanced Airborne Flight Recorder (EAFR). The EAFR standard addresses combinations of any or all of the following in a single Line Replaceable Unit (LRU), a Digital Flight Data Recorder (DFDR) function, a Cockpit Voice Recorder (CVR) function, a data link recording function, and an image recording function. This document does not address the overall flight data recorder system requirements but considers interface and system standards. This document does not replace ARINC Characteristic 747 which defines DFDRs. This document addresses the details of the voice recording function but does not describe the audio distribution system. It does not replace ARINC Characteristic 757 which defines CVRs. The EAFR may be used in a single or dual-redundant installation as permitted by regulation. Both configurations are addressed in this Characteristic.