Standards List

Not available yet

The purpose of this document is to provide guidance for developers of visual external communication systems for automated vehicles (AV), particularly Automated Driving System – Dedicated Vehicles (ADS-DV), as defined by SAE J3016.
The main objective of this document is to propose how ADS-DVs could communicate with other road users via an external communication system. It discusses the interaction between humans and ADS-DVs within roadway environments. Recommendations for the type of external visual communication messaging are presented along with the supporting methodological rationale.
This document does not address functionality elements of the ADS-DV external visual communication system itself. Rather, it serves to propose how the system communicates to human users such that it can be learned and understood by society at large.

This document encompasses design parameters of external signaling systems used by Automated Driving System-Dedicated Vehicles (ADS-DVs), as defined by SAE J3016.

This document defines the concepts and the terms related to extended vehicles.
It presents general information regarding these vehicles, specifies the dedicated terminology and describes the interrelation with other standards related to extended vehicles.
It concerns:
— road vehicles with four or more wheels designed and constructed primarily for the carriage of persons that are defined as Category 1 vehicles in the United Nations Special Resolution No.1 in TRANS/WP.29/1045, as last amended on 19 June 2012;
— road vehicles with four or more wheels designed and constructed primarily for the carriage of goods that are defined as Category 2 vehicles in the United Nations Special Resolution No.1 in TRANS/WP.29/1045, as last amended on 19 June 2012,
where these road vehicles are still in accordance with the specifications of the vehicle manufacturer.
While this document mentions already standardized interfaces and devices (e.g. external test equipment) connected to these interfaces, the specification of these interfaces and devices is not within the scope of this document.

This document specifies general rules and basic principles the manufacturer of the extended vehicle (ExVe) considers when elaborating its own design method. It does not specify the manner in which these design methods are drafted and implemented.
It specifies by means of a template the necessary information that is communicated to the ExVe manufacturer for requesting the design of a new ExVe functionality. It also specifies, by means of a template, the information the ExVe manufacturer provides for responding to that request. It does not specify the process leading to the elaboration of the request information nor the process associated to communication of the response information.
It concerns the design of the extended vehicles mentioned in the scope of ISO 20077-1, regardless of the type of communication interface which is used between the ExVe and external systems or parties. It does not concern the internal communication of the ExVe. It does not standardize the implementation of software or hardware nor preclude any technical solution the ExVe manufacturer might select when designing a new ExVe functionality.
It relates to the design and production phases of a vehicle, where these phases include the subsequent design upgrades by the ExVe manufacturer of vehicle models, variants, or types still in production.

This document defines the classification methodology of time-constrained situations and their requirements, that are to be addressed by the “ExVe time critical interfaces' described in ISO 20077-1. Time-constrained situations include safety-critical situations.
It is important for the design of the vehicle to have priority management of 'ExVe time critical interface' resources in order to comply with time constrained situations requirements.
The methodology provides a classification, which determines application priorities for optimal vehicle resource allocation.

This document states the minimum requirements, recommendations, permissions and possibilities for ensuring interoperable web services from an accessing party’s perspective. The document:
— states requirements on the structure and format of resources;
— defines the concept of resource identifiers (direct and correlated);
— provides different resource categories (e.g. anonymous, pseudonymized, technical, and personal resources);
— provides different approaches on how to bundle shareable resources (e.g. resource group or container);
— contains guidelines on how to define the unique resources of an individual application;
— defines the entities and roles, necessary for granting an accessing party access to resource owner’s resources;
— states requirements on how an accessing party accesses resources, including requirements on how to use the defined and referenced technologies,

This document defines how to access resources on a web-services interface of an offering party using the Hypertext Transfer Protocol Secure (HTTPS). Resources can be accessed through request/reply and/or requested to be pushed.
The Representational State Transfer (REST) architectural pattern is chosen as a common way to format resource paths both for request/reply and push. Some specific extensions to this pattern are defined to allow for asynchronous resource requests, such as, for example, forcing readouts of data from a connected vehicle.

This document describes the processes of an offering party’s implementation to provide (ISO 20078-2) access-controlled (ISO 20078-3) resources (ISO 20078-1) to accessing parties. The processes are summarized as: registration of different stakeholder as well as granting, denying and revoking of access to resources. Those processes are held as examples of combining ISO 20078-1, ISO 20078-2 and ISO 20078-3 and can vary depending on the actual implementation of the offering party.

This document defines how to authenticate users and accessing parties on a web-services interface. It also defines how a resource owner can delegate access to its resources to an accessing party. Within this context, this document also defines the necessary roles and required separation of duties between these in order to fulfil requirements stated on security, data privacy and data protection.
All conditions and dependencies of the roles are defined towards a reference implementation using OAuth 2.0[1] compatible framework and OpenID Connect 1.0[2] compatible framework.