Search Results

The purpose of this SAE Aerospace Information Report (AIR) is to provide guidance for aircraft engine and propeller systems (hereafter referred to as propulsion systems) certification for cybersecurity. Compliance for cybersecurity requires that the engine control, propeller control, monitoring system, and all auxiliary equipment systems and networks associated with the propulsion system (such as nacelle systems, overspeed governors, and thrust reversers) be protected from intentional unauthorized electronic interactions (IUEI) that may result in an adverse effect on the safety of the propulsion system or the airplane.

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.

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.

Connected vehicles can provide data from multiple sensors that monitor both the vehicle and the environment through which the vehicle is passing. The data, when shared, can be used to enhance and optimize transportation operations and management—specifically, traffic flow and infrastructure maintenance. This document describes an interface between vehicle and infrastructure for collecting vehicle/probe data. That data may represent a single point in time or may be accumulated over defined periods of time or distance, or may be triggered based on circumstance. The purpose of this document is to define an interoperable means of collecting the vehicle/probe data in support of the use cases defined herein. There are many additional use cases that may be realized based on the interface defined in this document. Note that vehicle diagnostics are not included within the scope of this document, but diagnostics-related features may be added to probe data in a future supplemental document.

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.

Automated driving system (ADS) manufacturers, developers, and operators need to provide clear information on their safety approach to relevant stakeholders. Explainability to diverse audiences helps build trust in statements from these organizations towards the shared value of safety. A defined list of core safety topics can help set expectations when communicating deployment and use-case-specific automated vehicle (AV) safety information. The topics listed in this best practice are implementation-agnostic and broadly applicable. This best practice describes how safety is continuous and connected throughout lifecycle stages and highlights considerations when including safety metrics as part of the communicated information. It lists topics that are considered core, provides a rationale, illustrative examples where applicable, suggestions of content that could be included for the example, and lists references and industry examples for further information.

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

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

An ADS-operated vehicle’s operational design domain (ODD) is defined by the manufacturer based on numerous factors. Research is underway at other organizations to define and organize ODD elements into taxonomies and other relational constructs. In order to enhance collaboration and communication between manufacturers and developers and transportation authorities, common terms and consistent frameworks are needed. The conceptual framework presented by Automated Vehicle Safety Consortium establishes a lexicon that can be used consistently by ADS developers and manufacturers responsible for defining their ADS ODD. A common framework and lexicon will reduce confusion, align expectations, and therefore build public trust, acceptance, and confidence.

SMSOLUTIONS0123 represents the work of a team of policy and technical leaders from over a dozen forward-leaning organizations in the ground vehicle industry and government. When asked where Sustainable Mobility Solutions could best apply the capabilities SAE has developed over a century, the SMS group responded without hesitation: address EV charging system failure. The group determined to aggregate charging session data with the view to create a consistent data dictionary and analysis practice. Adopting agile work practices, it studied these data, vetting and iterating its solution with the objective of producing a technical report in approximately half the time required in normal standardization. The resulting document, EV Charging Infrastructure: Charging System Performance Reporting, is informing work by the U.S. Department of Energy and Departments of Energy and Transportation Joint Office, as well as OEMs and suppliers.