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.

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.

This document addresses the development of security material for application specifications in SAE V2X Technical Committees. The assumption in this document is that two groups with distinct missions contribute to the development of each standard: the “Application Specification Team is in charge of specifying the application functionality and the “Security Specification Team” is in charge of specifying the security. The two teams may, of course, have a significant overlap of members.

SAE is developing a number of standards, including the SAE J2945/x and SAE J3161/x series, that specify a set of applications using message sets from the SAE J2735 data dictionary. (“Application” is used here to mean “a collection of activities including interactions between different entities in the service of a collection of related goals and associated with a given IEEE Provider Service Identifier (PSID)”). Authenticity and integrity of the communications for these applications are ensured using digital signatures and IEEE 1609.2 digital certificates, which also indicate the permissions of the senders using Provider Service Identifiers (PSIDs) and Service Specific Permissions (SSPs). The PSID is a globally unique identifier associated with an application specification that unambiguously describes how to build interoperable instances of that application.

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.

Access mechanisms to system data and/or control is a primary use case of the hardware protected security environment (hardware protected security environment) during different uses and stages of the system. The hardware protected security environment acts as a gatekeeper for these use cases and not necessarily as the executor of the function. This section is a generalization of such use cases in an attempt to extract common requirements for the hardware protected security environment that enable it to be a gatekeeper. Examples are: Creating a new key fob Re-flashing ECU firmware Reading/exporting PII out of the ECU Using a subscription-based feature Performing some service on an ECU Transferring ownership of the vehicle Some of these examples are discussed later in this section and some have detailed sections of their own. This list is by no means comprehensive.

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 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 Technical Governance is part of the SAE UCS Architecture Library and is primarily concerned with the UCS Architecture Model (AS6518) starting at Revision A and its user extensions. Users of the Model may extend it in accordance with AS6513 to meet the needs of their UCS Products. UCS Products include software components, software configurations and systems that provide or consume UCS services. For further information, refer to AS6513 Revision A or later. Technical Governance is part of the UCS Architecture Framework. This framework governs the UCS views expressed as Packages and Diagrams in the UCS Architecture Model.

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.