Search Results

This recommended practice provides guidance on vehicle Cybersecurity and was created based off of, and expanded on from, existing practices which are being implemented or reported in industry, government and conference papers. ...Other proprietary Cybersecurity development processes and standards may have been established to support a specific manufacturer’s development processes, and may not be comprehensively represented in this document, however, information contained in this document may help refine existing in-house processes, methods, etc. ...This recommended practice establishes a set of high-level guiding principles for Cybersecurity as it relates to cyber-physical vehicle systems. This includes: Defining a complete lifecycle process framework that can be tailored and utilized within each organization’s development processes to incorporate Cybersecurity into cyber-physical vehicle systems from concept phase through production, operation, service, and decommissioning.

This report sets forth guidance for IP-based onboard networks and systems residing in the Airline Information Services (AIS) and Passenger Information and Entertainment Services (PIES) Domains by establishing a common set of security related data elements and format(s) that are produced by aircraft systems, suitable for use by airline IT and/or avionic supplier analytical ground tools.

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.

The purpose of this document is to provide recommended guidance and provisions for ACARS Message Security (AMS) key management. The key management framework described herein is based on open international standards that are adapted to the ACARS datalink communications environment.

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 this document is to facilitate an understanding of aircraft information security and to develop aircraft information security operational concepts. This common understanding is important since a number of subcommittees and working groups within the aeronautical industry are considering aircraft information security. This document also provides an aircraft information security process framework relating to airline operational needs that, when implemented by an airline and its suppliers, will enable the safe and secure dispatch of the aircraft in a timely manner. This framework facilitates development of cost-effective aircraft information security and provides a common language for understanding security needs.

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.

This brief User Guide recaps the content of the AS6518B UCS Architectural Model. The purpose of the UCS Architecture Model is to provide the authoritative source for other models and products within the UCS Architecture as shown in the AS6512B UCS Architecture: Architecture Description.

This Recommended Practice defines the technical requirements for a terrestrial-based PNT system to improve vehicle (e.g., unmanned, aerial, ground, maritime) positioning/navigation solutions and ensure critical infrastructure security, complementing GNSS technologies.

This SAE Aerospace Recommended Practice (ARP) provides insights on how to perform a Cost Benefit Analysis (CBA) to determine the Return on Investment (ROI) that would result from implementing a blockchain solution to a new or an existing business process. The word “blockchain” refers to a method of documenting when data transactions occur using a distributed ledger with desired immutable qualities. The scope of the current document is on enterprise blockchain which gives the benefit of standardized cryptography, legal enforceability and regulatory compliance. The document analyzes the complexity involved with this technology, lists some of the different approaches that can be used for conducting a CBA, and differentiates its analysis depending on whether the application uses a public or a private distributed network.

This document applies to the development of Plans for integrating and managing COTS assemblies in electronic equipment and Systems for the commercial, military, and space markets; as well as other ADHP markets that wish to use this document. For purposes of this document, COTS assemblies are viewed as electronic assemblies such as printed wiring assemblies, relays, disk drives, LCD matrices, VME circuit cards, servers, printers, laptop computers, etc. There are many ways to categorize COTS assemblies1, including the following spectrum: At one end of the spectrum are COTS assemblies whose design, internal parts2, materials, configuration control, traceability, reliability, and qualification methods are at least partially controlled, or influenced, by ADHP customers (either individually or collectively). An example at this end of the spectrum is a VME circuit card assembly.

This document is the Architecture Description (AD) for the SAE Unmanned Systems (UxS) Control Segment (UCS) Architecture Library Revision A or, simply, the UCS Architecture. The architecture is expressed by a library of SAE publications as referenced herein. The other publications in the UCS Architecture Library Revision A are: AS6513A, AS6518A, AS6522A, and AS6969A.

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.

Development of a new Industry Standard related to GIDEP Reporting.

This document applies to the development of Plans for integrating and managing electronic components in equipment for the military and commercial aerospace markets; as well as other ADHP markets that wish to use this document. Examples of electronic components, as described in this document, include resistors, capacitors, diodes, integrated circuits, hybrids, application specific integrated circuits, wound components, and relays. It is critical for the Plan owner to review and understand the design, materials, configuration control, and qualification methods of all “as-received” electronic components, and their capabilities with respect to the application; identify risks, and where necessary, take additional action to mitigate the risks. The technical requirements are in Clause 3 of this standard, and the administrative requirements are in Clause 4.

This document applies to the development of Plans for integrating and managing COTS assemblies in electronic equipment and Systems for the commercial, military, and space markets; as well as other ADHP markets that wish to use this document.

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 a process for use by ADHP integrators of EEE parts and sub-assemblies (items) that have been targeted for other applications. This document does not describe specific tests to be conducted, sample sizes to be used, nor results to be obtained; instead, it describes a process to define and accomplish application-specific qualification; that provides confidence to both the ADHP integrators, and the integrators’ customers, that the item will performs its function(s) reliably in the ADHP application.

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