Standards List

Not yet available

This document provides background about existing methods to assess the robustness of neural networks.

This document provides methodology for the use of formal methods to assess robustness properties of neural networks. The document focuses on how to select, apply and manage formal methods to prove robustness properties.

This PAS specifies requirements for safety cases for automated vehicle trials and development testing in the UK to demonstrate that trialling and testing activities can be undertaken safely and securely. It covers the development of an operational safety case to demonstrate that the risks to all affected parties throughout automated vehicle trials and testing are reduced as low as reasonably practicable (ALARP). This includes operational risk assessments, safety testing, training, safety monitoring, compliance and permissions granted. It is applicable to all real-world testing environments, including test tracks and public domains and to all levels of driving automation systems. However, a safety case developed for test tracks might not need to include all elements detailed in this PAS.
This PAS does not cover the system safety of the vehicle (e.g. functional safety, safety of the intended functionality (SOTIF) and cybersecurity assessments) but does rely on their outputs. This PAS does not include the safety case requirements for the testing of a connected vehicle that is not also automated.
This PAS is intended for use by trialling organizations, including private developers and original equipment manufacturers (OEMs), developing safety cases for automated vehicle trials and testing. Compliance with this PAS does not guarantee acceptance of the safety case by relevant organizations.
This PAS might be of interest to organizations requiring assurance that a safety case has been developed in line with good practice, for example, highway authorities, road operators, landowners, leaseholders and insurers.

This SAE Recommended Practice provides guidelines for the use, performance, installation, activation, and switching of marking lamps on ADS-equipped vehicles.

This SAE Recommended Practice provides common data output formats and definitions for a variety of data elements that may be useful for analyzing the performance of automated driving system (ADS) during an event that meets the trigger threshold criteria specified in this document. The document is intended to govern data element definitions, to provide a minimum data element set, and to specify a common ADS data logger record format as applicable for motor vehicle applications.
Automated driving systems (ADSs) perform the complete dynamic driving task (DDT) while engaged. In the absence of a human 'driver,' the ADS itself could be the only witness of a collision event. As such, a definition of the ADS data recording is necessary in order to standardize information available to the accident reconstructionist. For this purpose, the data elements defined herein supplement the SAE J1698-1 defined EDR in order to facilitate the determination of the background and events leading up to a collision in an ADS-operated vehicle.
The data elements defined in this document are unique to Level 3, 4, or 5 ADS features, as defined by SAE J3016, and provide additional background of the events leading up to a crash or crash-like event. The data from sensors such as camera(s), LiDAR(s) etc. will provide information in the absence of a human driver. The data included in the ADS data logger is expected to be used in conjunction with the SAE J1698 event data recorder (EDR) record and traditional accident reconstruction analysis. The EDR and ADS data logger will capture information leading up to the triggered event, at a minimum. There are no facts to support that recording data for greater than 5 seconds pre-event would change the outcome of any crash analysis. Thus, the recommended recording duration for a data logger is 5 seconds pre-event, same as an EDR. Due to the potential for sensor and/or communication failure during a crash event, the recommendation is that data should be collected post-crash for impact and rollover sensors for up to 250 ms.
ADS technology is still being developed and is not yet commercially deployed. Therefore, this SAE Recommended Practice is intended as a guide toward standard practice and is subject to change to keep pace with experience and technical advances.

Safety practices at traditional proving grounds and test sites is well established. The development of Automated Driving Systems (ADS) and related technologies have highlighted the need for unique tests and testing environments. To ensure test facility safety, different requirements, approaches and considerations are necessary.

This project explored shared road users’ potential needs for information about Automated Driving Systems’ (ADS) intent and developed preliminary laboratory testing procedures for assessing external human-machine interface (eHMI) designs for communicating the intent of ADS-equipped vehicles. In Study 1, researchers interviewed driving instructors to determine the most important visual and auditory cues predicting driver actions in specific traffic scenarios. In Study 2, drivers, pedestrians, and bicyclists participated in field studies on public roadways while verbally commenting about the actions and anticipated actions of nearby vehicles. Study 3 introduced a preliminary laboratory method to assess prototype eHMI designs. All trials used a single unsignalized crosswalk, only one approaching vehicle, and no other pedestrians present. Results show that participants generally recognized that an eHMI indicated the vehicle was self-driving, and if the vehicle yielded, participants indicated that they perceived the vehicle had recognized their presence, even before the meanings of the interfaces had been explained to them. Results showed that the preliminary lab method showed promise in potentially differentiating between different eHMIs for the single specific scenario involving a relatively simple crosswalk case; however, the generalizability of findings is not claimed.

The AUTOSAR Adaptive Platform implements the AUTOSAR Runtime for Adaptive Applications (ARA). Two types of interfaces are available, services and APIs. The platform consists of functional clusters which are grouped in services and the Adaptive AUTOSAR Basis.  
Functional clusters...
- assemble functionalities of the Adaptive Platform
- define clustering of requirements specification
- describe behavior of software platform from application and network perspective
but, do not constrain the final SW design of the architecture implementing the Adaptive Platform.
Functional clusters in AUTOSAR Adaptive Platform Basis have to have at least one instance per (virtual) machine while services may be distributed in the in-car network.
In comparison to the AUTOSAR Classic Platform the AUTOSAR Runtime Environment for the Adaptive Platform dynamically links services and clients during runtime.

The AUTOSAR Classic Platform architecture distinguishes on the highest abstraction level between three software layers which run on a microcontroller: application, runtime environment (RTE) and basic software (BSW).
The application software layer is mostly hardware independent.
Communication between software components and access to BSW via RTE.
The RTE represents the full interface for applications.
The BSW is divided in three major layers and complex drivers:
Services, ECU (Electronic Control Unit) abstraction and microcontroller abstraction.
Services are divided furthermore into functional groups representing the infrastructure for system, memory and communication services.