Search Results

A framework is defined that includes requirements for cybersecurity processes and a common language for communicating and managing cybersecurity risk. ...This document specifies engineering requirements for cybersecurity risk management regarding concept, product development, production, operation, maintenance and decommissioning of electrical and electronic (E/E) systems in road vehicles, including their components and interfaces. ...This document does not prescribe specific technology or solutions related to cybersecurity.

A framework is defined that includes requirements for cybersecurity processes and a common language for communicating and managing cybersecurity risk. ...This document specifies requirements for cybersecurity risk management regarding engineering for concept, development, production, operation, maintenance, and decommissioning for road vehicle electrical and electronic (E/E) systems, including their components and interfaces. ...This document does not prescribe specific technology or solutions related to cybersecurity.

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.

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

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 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 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, …).

The basic requirements of AS9100A apply with the following clarifications. This document supplements the requirements of AS9100A for deliverable software. This supplement contains Quality System requirements for suppliers of products that contain deliverable embedded or loadable airborne, spaceborne or ground support software components that are part of an aircraft Type Design, weapon system, missile or spacecraft operational software and/or support software that is used in the development and maintenance of deliverable software. This includes the host operating system software including assemblers, compilers, linkers, loaders, editors, code generators, analyzers, ground simulators and trainers, flight test data reduction, etc., that directly support creation, test and maintenance of the deliverable software.

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.