Standards List

The scope of the provisions in this Part are intended for consideration of traffic control devices that are specifically being designed to accommodate automated vehicles capable of performing partial or full realtime operational functions in general traffic on a sustained basis. This Part does not require agencies to use these provisions in their accommodation of automated vehicles on their roadways. Rather, the purpose of these provisions is to provide agencies with general considerations and guidance for traffic control devices that can be more helpful in the accommodation of such vehicles, while at the same time being more beneficial to road users.
It is important for early implementers of automated vehicles to understand the ramifications of traffic control devices in a mixed fleet environment and to consider the needs of both human and machine-led road users. Partial automation technologies are already commercially available in the vehicle fleet and are operating under current infrastructure conditions. The overall effectiveness of the automation is impacted by the uniformity and consistent application of the highway infrastructure, including traffic control devices.
This Chapter provides an overview of foundational driving automation system (see definition in Section 5A.03) technology terminology, key principles, considerations for traffic control device selection, and topics for agencies to consider. The MUTCD does not address standardization of digital infrastructure, geometric road design, traffic control device maintenance levels, minimum pavement conditions, or other items that might be important for safe and effective operation of driving automation system technologies.

MDF (Measurement Data Format) is a binary file format to store recorded or calculated data for post-measurement processing, off-line evaluation or long-term storage. The format has become a de-facto standard for measurement & calibration systems (MC-systems), but is also used in many other application areas.
As a compact binary format, ASAM MDF offers efficient and high performance storage of huge amounts of measurement data. MDF is organized in loosely coupled binary blocks for flexible and high performance writing and reading. Fast index-based access to each sample can be achieved by loss-free re-organization (i.e. sorting) of the data. Distributed data blocks even make it possible to directly write sorted MDF files. The file format allows storage of raw measurement values and corresponding conversion formulas; therefore raw data can still be interpreted correctly and evaluated by post-processing tools.

This Recommendation provides system requirements, technical and operational characteristics of millimetre wave radiocommunication systems for intelligent transport system applications to be used for system design objectives. The Recommendation covers vehicular collision avoidance radar operating in the 76-77 GHz and 77-81 GHz bands, as well as integrated millimetre wave radiocommunication systems for ITS applications in the 57-66 GHz range for vehicle-to-vehicle radiocommunications and radiocommunications between the vehicle and roadside infrastructure.

The present document focuses on the MEC Location Service. It describes the related application policy information including authorization and access control, information flows, required information and service aggregation patterns. The present document specifies the necessary API with the data model and data format.

The present document focuses on a MEC V2X Information Services (VIS), in order to facilitate V2X interoperability in a multi-vendor, multi-network and multi-access environment, considering the relevant work of other industry bodies relating to V2X communication (e.g. ETSI ITS, 5GAA). It describes the V2X-related information flows, required information and operations. The present document also specifies the necessary API with the data model and data format.

This document describes a systematic and rigorous process to: (1) identify and evaluate standard names and definitions for driving automation system features, and (2) identify a “user vocabulary” of terms and descriptions that [human] drivers use to describe driving automation system features.
The process described in this document includes selection criteria and trade-offs that can be used to select an approach to testing that matches the constraints and objective of a particular evaluation. The data from this process are analyzed to determine users’ name preferences for driving automation system features and what they would expect a specific feature to do, based on the name given to the features. The data generated by this naming methodology can provide guidance regarding the names that may support accurate understanding of the feature’s capabilities and limitations. Although the process described in this document emphasizes the use of large-scale electronic surveys for data collection, an in-person approach to administer the test (either paper-and-pencil or electronic) could be used instead.
NOTE: The development of this SAE Recommended Practice for developing standard names for driving automation system features was greatly aided by a large-scale pilot test that was used to assess and refine the individual test procedures described below. A summary of this pilot test is provided in Appendix A.

This document contains the specification of Navigation Data Standard (NDS), a standardized physical storage format for navigation systems. The format has been developed by the NDS e.V., a registered society of manufacturers, system suppliers and map suppliers. This document describes the general concepts and structure of the database format.
Examples used in the NDS Specification documents are intended to make the topics easy to understand. They are not binding.

This document contains the update concepts specified for Navigation Data Standard (NDS), a standardized physical storage format for navigation systems. The format has been developed by NDS e.V., a registered society of car manufacturers, navigation system suppliers, and map suppliers.
The standardized binary format for navigation data as specified in the NDS – Format Specification also offers new possibilities for updating navigation databases. This document, the NDS – Update Specification, describes a harmonized and flexible concept for content updates for NDS databases, including incremental and partial updates. This concept also allows using update processes for enhancing the content of navigation databases, for example, by adding countries or building blocks without changing the basic database structure. The NDS update concept ensures that the navigation database is still consistent after an update.

The present document provides objectives regarding C-ITS from C2C-CC point of view. They focus on vehicles but can be applied to other traffic participants too.
In terms of C2C-CC an objective is defined as an abstract requirement without any further specification about its details. An objective itself is always further detailed by at least one of two ways:
• by a feature, which describes a desired ability in scope of vehicles. The feature again is detailed by one or more requirements, which contains the implementation details.
• by a feature request, which describes an expected ability for every other entity outside vehicle scope (e.g. other traffic participants). The feature request again is detailed by one or more requirement requests, if necessary.
Thus, an objective can be considered as the most abstract requirement. This implies that an objective itself is not directly testable. An objective can be assumed as ‘tested’, if all of its detailing features or feature requests are assumed as ‘tested’. An exemplary structure of this relation between the mentioned requirement layers is in shown in Figure 1.
Note: The objectives describe a specification status, which shall be reached in a major release starting from a specific minor release of that major release, from which on the major release is considered complete. That means the specification set is not necessarily feature complete from the first minor release(s) of that major release.

The present document provides objectives regarding C-ITS from C2C-CC point of view. They focus on vehicles but can be applied to other traffic participants too.
In terms of C2C-CC an objective is defined as an abstract requirement without any further specification about its details. An objective itself is always further detailed by at least one of two ways:
• by a feature, which describes a desired ability in scope of vehicles. The feature again is detailed by one or more pure requirements, which contains the implementation details.
• by a feature request, which describes an expected ability for every other entity outside vehicle scope (e.g. other traffic participants). The feature request again is detailed by one or more requirement requests, if necessary.
Thus, an objective can be considered as the most abstract requirement. This implies that an objective itself is not directly testable. An objective can be assumed as ‘tested’, if all of its detailing features or feature requests are assumed as ‘tested’.