Search Results

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.

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.

- Research existing maturity models - Highlight categories applicable to automotive - Identify a mapping of existing maturity model activities to 21434 work products - Covers organization and product security - Define levels of maturity for the automotive industry - Provide technical information report

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.

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.

This document provides a list of tests, techniques, actions – i.e. methods – for confirming the cybersecurity of a vehicle, its subsystems, and/or its components. There is no guidance provided on how to select from the list of methods, nor how to plan execution of those selected.

The scope of this SAE Recommended Practice is to require the use of the same Security Services as defined by the International Standard ISO/CD 15764, modified by the Class of Security as determined by the resource provider and referenced in Table 1, Extended Data Link Security References.

The scope of this SAE Recommended Practice is to require the use of the same Security Services as defined by the International Standard ISO/CD 15764, modified by the Class of Security as determined by the resource provider and referenced in Table 1, Extended Data Link Security References.

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.

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 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 will define architecture, design, and implementation requirements for vehicle key management security. This would of course include KMS interfaces, but would also include the ecosystem constraints, e.g., recommendations for hardening the OEM and Tier-1 backend systems (using role-based separation modeled on Uptane) to avoid single points of failure in key generation and key storage systems.

Digitally enabled mobility vehicles and services, including dockless bikesharing and electric scooter sharing, are generating and collecting a growing amount of mobility data. Mobility data holds great potential to support transportation officials and their efforts to manage the public right-of-way, but the unlimited distribution of mobility data carries untested risks to privacy and public trust. The Mobility Data Collaborative™ has identified the need to improve and coordinate understanding among all parties around foundational policy and legal issues to support mobility data sharing, including privacy and contracting. The guidelines are geared towards supporting a scalable mobility data sharing framework that aligns the interests of the public and private sectors while addressing privacy, transparency, data ownership, and consumer trust.

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.