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.

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.

This document will provide recommendations to vehicle manufacturers and component suppliers in securing the SAE J1939-13 connector interface from the cybersecurity risks posed by the existence of this connector.

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.

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 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 SAE Information Report J2931/7 establishes the security requirements for digital communication between Plug-In Electric Vehicles (PEV), the Electric Vehicle Supply Equipment (EVSE) and the utility, ESI, Advanced Metering Infrastructure (AMI) and/or Home Area Network (HAN).

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.

This SAE Information Report J2836 establishes the instructions for the documents required for the variety of potential functions for PEV communications, energy transfer options, interoperability and security. This includes the history, current status and future plans for migrating through these documents created in the Hybrid Communication and Interoperability Task Force, based on functional objective (e.g., (1) if I want to do V2G with an off-board inverter, what documents and items within them do I need, (2) What do we intend for V3 of SAE J2953, …).

This SAE Recommended Practice defines the Expanded Diagnostic Protocol (EDP), the requirements for the SAE J1978 OBD II Scan Tool for supporting the EDP protocol, and associated requirements for diagnosis and service information to be provided by motor vehicle manufacturers. Appendix A includes worked examples of the use of the protocol.

This SAE Recommended Practice defines the Expanded Diagnostic Protocol (EDP), the requirements for the SAE J1978 OBD II Scan Tool for supporting the EDP protocol, and associated requirements for diagnosis and service information to be provided by motor vehicle manufacturers. Appendix A includes worked examples of the use of the protocol.

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 SAE Information Report J2931/7 establishes the security requirements for digital communication between Plug-In Electric Vehicles (PEV), the Electric Vehicle Supply Equipment (EVSE) and the utility, ESI, Advanced Metering Infrastructure (AMI) and/or Home Area Network (HAN).

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.

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.

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.