Refine Your Search

Search Results

Viewing 1 to 8 of 8
Standard

Cybersecurity for Propulsion Systems

2023-09-05
CURRENT
AIR7368
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.
Standard

CAN FD Data Link Layer

2022-09-08
CURRENT
J1939-22_202209
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.
Standard

CAN FD Data Link Layer

2021-07-16
HISTORICAL
J1939-22_202107
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.
Standard

CAN FD Data Link Layer

2021-03-22
HISTORICAL
J1939-22_202103
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.
Standard

Hardware Protected Security for Ground Vehicles

2020-02-10
CURRENT
J3101_202002
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.
Standard

Diagnostic Link Connector Security

2022-10-04
CURRENT
J3138_202210
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.
Standard

Diagnostic Link Connector Security

2018-06-02
HISTORICAL
J3138_201806
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.
Best Practice

AVSC Information Report for Change Risk Management

2023-04-12
CURRENT
AVSC00010202304
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.
X