Search Results

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.

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 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 document provides background and detailed technical information on existing methods to secure loadable software parts.

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.

This document applies to the development of Plans for integrating and managing COTS assemblies in electronic equipment and Systems for the commercial, military, and space markets; as well as other ADHP markets that wish to use this document. For purposes of this document, COTS assemblies are viewed as electronic assemblies such as printed wiring assemblies, relays, disk drives, LCD matrices, VME circuit cards, servers, printers, laptop computers, etc. There are many ways to categorize COTS assemblies1, including the following spectrum: At one end of the spectrum are COTS assemblies whose design, internal parts2, materials, configuration control, traceability, reliability, and qualification methods are at least partially controlled, or influenced, by ADHP customers (either individually or collectively). An example at this end of the spectrum is a VME circuit card assembly.

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