Search Results

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.

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.

As technology and functionality of vehicle systems change, so do data recording needs. In ADS-dedicated vehicles (DV), the ADS perceives the environment and handles vehicle motion control, i.e., the dynamic driving task (DDT), as described in SAE J3016. When an ADS takes the place of a human driver, its sensing, processing, and control systems necessitate new considerations for data recording. Data recording is important to crash reconstruction, system performance investigations, and event analysis. It enables industry-wide improvements in ADS safety. This best practice makes recommendations for the ADS-DV data needed to support: (1) information about what the ADS "saw" and "did" and (2) identify the technology-relevant factors that contributed to the event.

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.

AVSC Best Practice for Interactions Between ADS-DVs and Vulnerable Road Users (VRUs) AVSC00009202208 establishes common terminology and a baseline understanding of the challenges posed, and framework to evaluate automated driving system-dedicated vehicle (ADS-DV) interactions with VRUs. This best practice can facilitate communication among the industry and public, help calibrate expectations of all traffic participants, and improve broader acceptance of SAE level 4 and level 5 ADS-equipped vehicles.

AVSC Information Report for Change Risk Management AVSC00010202304 provides a process for change risk management for fleet-operated ADS-DVs using level 4 or 5 automation. The document addresses risks resulting from planned and unplanned changes in an ADS-DV design and/or operation. This information report is based on the concept of risk-informed decision-making. Making risk management decisions such as safety and change management, safety analysis, and safety assurance are especially applicable when moving from concept to production intent for the ADS-DV. Change Risk Management (CRM) does not replace best practices or other methods for managing safety anomalies or change management processes. It may instead be viewed as an additional resource that elaborates on how safety anomaly management and change management can be performed.

The flexible data rate capability in CAN (commonly called CAN FD) is implemented as a transport layer in order to allow for functional safety, cybersecurity, extended transport capability, and backward compatibility with SAE J1939DA.

The flexible data rate capability in CAN (commonly called CAN FD) is implemented as a transport layer in order to allow for functional safety, cybersecurity, extended transport capability, and backward compatibility with SAE J1939DA.

The flexible data rate capability in CAN (commonly called CAN FD) is implemented as a transport layer in order to allow for functional safety, cybersecurity, extended transport capability, and backward compatibility with SAE J1939DA.

The flexible data rate capability in CAN (commonly called CAN FD) is implemented as a transport layer in order to allow for functional safety, cybersecurity, extended transport capability, and backward compatibility with SAE J1939DA.

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.

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.

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.

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 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 describes some of the actions that should be taken to help ensure safe vehicle operation in the case that any such connected device (external test equipment, connected data collection device) has been compromised by a source external to the vehicle. In particular, this document describes those actions specifically related to SAE J1979, ISO 15765, and ISO 14229 standardized diagnostic services. Generally, the following forms of communication bus connection topologies are used in current vehicles: a Open access to communication buses b Communication buses isolated via a gateway c Hybrid combinations of a. and b.

This document describes a set of recommended actions to take to increase the likelihood of safe vehicle operation when a device (external test equipment, data collection device, etc.) whose normal operation has been compromised by a source external to the vehicle is connected to the vehicle’s diagnostic system. The term “diagnostic system” is intended to be a generic way to reference all the different ways that diagnostic commands might be injected into the system. The guidance in this document is intended to improve security without significantly impacting the ability for franchised dealer or independent aftermarket external test tools to perform legitimate diagnosis and maintenance functions. The goal is that intrusive services are only allowed to be performed when the vehicle is in a Safe State such that even if the intrusive service were to be initiated with adversarial intent the consequences of such a service would still be acceptable.

Thus, assessments of cybersecurity, maintenance, interactions with passengers, etc., while important, are out of scope for this document.

This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.

This SAE Recommended Practice establishes a uniform practice for protecting vehicle components from "unauthorized" access through a vehicle data link connector (DLC). The document defines a security system for motor vehicle and tool manufacturers. It will provide flexibility to tailor systems to the security needs of the vehicle manufacturer. The vehicle modules addressed are those that are capable of having solid state memory contents accessed or altered through the data link connector. Improper memory content alteration could potentially damage the electronics or other vehicle modules; risk the vehicle compliance to government legislated requirements; or risk the vehicle manufacturer's security interests. This document does not imply that other security measures are not required nor possible.