Standards List

This document addresses a conceptual framework and lexicon manufacturers and developers can use in describing the ODD for their ADS-operated vehicles and communicating this with users and the public. To that end, this document also provides an initial detailed list of potential variables with definitions that manufacturers and developers can use in describing the ODDs of their ADS-operated vehicles. The objective is to provide common terms across the industry. This lexicon is expected to grow as needed to accommodate changes in technology and the legitimate needs of stakeholders.

Driving safely is a complex task. It involves a broad range of skills invoked in a vast number of potential scenarios. Assessing a set of behavioral competencies offers a valuable directional indication of automated driving system-dedicated vehicle (ADS-DV) safety performance. Behavioral competencies provide a starting point for additional assessment and contribute to a manufacturer’s case for safety.
This best practice provides an approach to specify testable ADS behavior by:
- Clarifying a lexicon surrounding ADS behaviors
- Enumerating an elemental set of behaviors
- Demonstrating how to derive metrics to evaluate behavioral competence
To evaluate as many dynamic driving task (DDT) subtasks as possible, ADS developers decompose the DDT into a generalized set of behaviors. Subsequently, developers use system engineering techniques to ensure that this decomposition maps to an elemental set of behavioral competencies. In other words, the ADS may not always invoke a single behavior, but a set of behaviors covering a predictable part of the driving task. Although real-world conditions involve complex interactions among numerous systems in various situations, competency across a broad set of behaviors provides evidence of, and increases confidence in, baseline safety performance. Similarly, well-established system engineering techniques inform the validation of the driving capabilities by prescribing test criteria and integrating the results with developmental testing and overall safety case evaluation.
Providing a framework for manufacturers to link behavioral competencies to key scenarios in a given ODD provides evidence for ADS safety performance that manufacturers can use to build their case for safety. It should help to make individual test cases more extensible and therefore increase confidence in ADS safety performance.

This document addresses the qualifications and training for on-board human oversight of testing for automated driving system (ADS)-operated vehicles. It provides an outline with criteria commonly agreed to by members of the AVSC, which includes:
Driver selection
Basic Driver training
ADS-operation training
Initial driving on public roads
Periodic re-evaluation and training
The Best Practice applies to humans within the vehicle responsible for the safe oversight of development and testing SAE Level 4 and Level 5 automated driving systems on public roads.

AVSC Best Practice for Interactions Between ADS-DVs and Vulnerable Road Users (VRUs) AVSC00009202208 establishes common terminology and a baseline understanding of the challenges posed, and framework to evaluate automated driving system-dedicated vehicle (ADS-DV) interactions with VRUs. This best practice can facilitate communication among the industry and public, help calibrate expectations of all traffic participants, and improve broader acceptance of SAE level 4 and level 5 ADS-equipped vehicles.

This AVSC Best Practice for Metrics and Methods for Assessing Safety Performance of Automated Driving Systems (ADS) (AVSC00006202103) recommends a set of metrics that may be used to assess ADS safety performance of the dynamic driving task (DDT). These metrics and methods are principally designed to provide evidence of safety performance for a manufacturer’s decision to deploy (and monitor) fleet-operated/managed SAE level 4 and 5 ADS-dedicated vehicles (ride-hailing or product delivery).
This document lays out a performance-based, technology-neutral approach for measuring and analyzing safety performance. It supports long-term, socially-important safety goals (like reducing crashes). ADS safety performance metrics in this document support system-level analyses, i.e. they are practical to implement for any system regardless of architecture. The best practice provides:
- Metrics to Support ADS Safety
- Recommended Safety Outcomes
- Recommended Predictive Safety Metrics
- Methods for Assessing DDT Performance Metrics
The metrics and methods provided in this document are intended for use by the technical community (developers, manufacturers, testers, etc.) to aid in the safe development and deployment of ADS. They may also be useful to stakeholders who have interest in better understanding the safety posture of ADS deployments.

As passengers take rides in fleet-managed automated driving system-dedicated vehicles (ADS-DVs), they may feel the need to interrupt the trip due to a perceived emergency. There is currently no industry consensus on the proper balance between ADS passenger agency and the potential for introducing unexpected outcomes in dynamic traffic environments. In order to build public trust in automated vehicles, passengers should be given an option to exercise some type of control (agency) to intervene during situations they perceive as emergencies. Passenger-initiated emergency trip interruption features — however they manifest in a given vehicle - can help establish this confidence in ADS technologies.
AVSC Best Practice for Passenger-Initiated Emergency Trip Interruption recommends processes surrounding aspects of passenger-initiated features in SAE level 4 and 5 fleet-managed ADS-DVs. It recommends criteria and processes for passenger initiation of these features from inside the vehicle; communication with passengers and fleet operations; enhanced diagnoses of the situation, interaction outside the vehicle with other road users, and general post-stop actions. Also, precautions against some types of foreseeable misuse are addressed. These recommendations apply to commercially available, deployed ADS-DV’s providing trips to people.
The AVSC recommends that every fleet-managed SAE level 4 and 5 ADS-DV be equipped with a (PES) or (PEC) or both.

This document describes best practices for developing and validating simulations in support of ADS for on-road motor vehicles, as well as validation of ADS models. However, this document will not address the various approaches and considerations for developing an ADS model as this topic is addressed primarily in SAE J2998. Similarly, this document will not specify types of simulations needed for a given system as this is dependent on the system developer as well as simulations where the ADS model (or parts thereof) can be utilized but are not the system under test. Conversely, this Information Report describes best practices related to taxonomies of ADS simulations (e.g., driver-in-the-loop, vehicle-in-the-loop, hardware-in-the-loop, etc.). In addition, ADS simulations referenced within this document can be utilized during different phases of a systems engineering lifecycle or product development lifecycle (e.g., design, development, testing, production, operations, maintenance). Some best practices may be specific to a specific type of simulation (e.g., hardware-in-the-loop, driver-in-the-loop, etc.) or a specific SAE J3016 level of automation or range of levels of automation (e.g., 3-5, 4, etc.) and such best practices will be designated accordingly. Furthermore, there are numerous assets utilized in ADS simulation and this document will discuss how these assets should be applied when conducting ADS simulation but not how to develop the assets themselves.

This document is one of the deliverables of Taskforce 5 of Working Group 2 of the C-Roads Platform and contributes to stage 5 in the C-Roads workflow. The stage 5 deliverables provide the basis to validate the interoperability of a C-ITS implementation and guide through all aspects of interoperability testing for ITS-G5 systems, IP-Based communication and security elements, as specified by Working Group 2 of the C-Roads Platform by the different other Task Forces, namely TF1, TF2, TF3 and TF4.
This document contains two procedures for generating and naming data packets (PCAP files) for a cross border exchange between C-Roads project partners. These procedures enable some type of interoperability testing by using various equipment before road tests. The first procedure, specified in the second chapter as “Non synchronized PCAP Files Exchanging”, must be used as an optional prerequisite for Cross-Border Physical Testing Sessions (PTS). It is mainly based on event-based recording. The objective of this procedure is to avoid the major interoperability issues before testing physically. However, due to the COVID-19 sanitary situation, all the scheduled PTS during 2020 and 2021 were canceled. All these PTS were switched to Virtual Testing Sessions (VTS). The procedure to store PCAP files for these VTS is specified in the chapter 3. The objective of VTS is to replace PTS, therefore the recording procedure was defined as drive based.

This document defines the C-ITS Infrastructure Mobile ITS-G5 station profile as part of the C-Roads Project. This profile defines the requirement related to the features of a mobile C-ITS station belonging to a special organisation. This includes all ITS-G5 stations that can potentially be used as mobile stations (e.g. trailers, (aftermarket) vehicle stations).
This document describes the common requirements of all infrastructure mobile C-ITS stations to realize interoperability with other C-ITS sub-systems as defined in EN 302 665 [12]. The functional requirements of mobile ITS stations are out of the scope of this document.
For a better readability, the terms “mobile ITS station” is used to describe an “C-ITS Infrastructure mobile ITS station”.
The scope of this document excludes the potential interaction between the infrastructure mobile ITS station and the infrastructure, other than the ITS-G5 exchanges with R-ITS-S. This concerns for instance a cellular connection that may link the mobile ITS station directly to the TCC.
This profile does not include the usage of C-ITS messages by trailers. The subject is still pending and might impact the present document.

This document provides a description of the functionality and interface profiles which are needed to provide interconnection of backend systems to allow sharing of C-ITS information.
This document specifies the following:
Basic Interface - IP based interface for backend communication:
- Functional requirements
- Basic Interface protocol specification
- Filtering mechanism
- Configuration parameters
- Location specification
- Application requirements
Improved Interface - IP based interface for backend communication:
- Functional requirements
- Improved Interface protocol specification
Transport layer security
- Transport Layer Security profile
- Transport Layer Security Certificates
This document does not cover the payload content, i.e. the C-ITS message contents.