Search Results

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.

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.

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

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.

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.

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

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.

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.

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 will provide recommendations to vehicle manufacturers and component suppliers in securing the SAE J1939 network from the cybersecurity risks. It is recognized that not every application of SAE J1939 networks requires the same level of cyber security measures.

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.

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

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.

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

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.