Standards List

This Abstract Syntax Notation (ASN.1) File is the precise source code used for SAE International Standard J2945/2. As part of an international treaty, all US ITS standards are expressed in 'ASN.1 syntax'. ASN.1 Syntax is used to define the messages or 'ASN specifications'. Using the ASN.1 specification, a compiler tool produces the ASN library which will then be used to produce encodings (The J2945/2 message set uses UPER encoding). The library is a set of many separate files that collectively implement the encoding and decoding of the standard. The library is then used by any application (along with the additional logic of that application) to manage the messages. The chosen ASN tool is used to produce a new copy of the library when changes are made, and it is then linked to the final application being developed. The ASN library manages many of the details associated with ASN syntax, allowing for subtle manipulation to make the best advantage of the encoding style.

The terms and definitions in this document describe the functions performed within an ADS, as defined in SAE J3016. Where possible we have attempted to capture the language that is already in use within the automated driving development community. Where needed, we have added new terms and definitions, including clarifying notes to avoid ambiguity. SAE J3131 deals primarily with Level 4 and Level 5 ADS features.

RTCM 10403.4 defines messages that are used improve the accuracy of location provided by Global Navigation Satellite Systems (GNSS) such as GPS, GLONASS, Galileo, QZSS, BeiDou (BDS), and NavIC. The method used is differential correction which involves the use of a reference station at a precisely known location, which communicates with 'rover' receivers to refine their position using the messages in this standard.
This standard (referred to as Version 3) was first published by RTCM Special Committee 104 in 2004 as a more efficient alternative to the standards entitled 'RTCM Recommended Standards for Differential Recommended Standards for Differential GNSS (Global Navigation Satellite Systems) Service, Version 2.x'. (Current version is 2.3, now designated as RTCM 10402.3.) Service providers and vendors represented on the SC104 Committee wanted a new standard that would be more efficient, easy to use, and more easily adaptable to new situations. The main complaint was that the Version 2.x parity scheme, which uses words with 24 bits of data followed by 6 bits of parity, was wasteful of bandwidth. Another complaint was that the parity was not independent from word to word. Still another was that even with so many bits devoted to parity, the actual integrity of the message was not as high as it should be. Plus, 30-bit words are awkward to handle. Version 3 is recognized as correcting these weaknesses.
The standard has been revised several times since its original publication. It is now at version 3.4, designated RTCM 10403.4.
The significant changes in Version 3.4 are:
Update of BeiDou ICD to 3.0.
Changing QZSS 'LEX' signal types to 'L6'.
Changes and additions related to clarifications of transformation messages.
Addition of normative references for the ICDs.
Addition of Coordinate Reference Systems (CRS)/Datums Service Messages.
Addition of BeiDou and Galileo Network RTK Residual Messages after successful interoperability testing.
Incorporation of Amendments 1 -3, adding NavIC/IRNSS, Beidou BDS3 New Signals, and Coordinate Transformation clarifications.
Grouping of ephemeris messages into one section.
Grouping of legacy observation messages into one section.

The present document provides a summary of each Feature or, whenever needed, of each significant Work Item, introduced in Release 14.
The information provided in the present document is limited to an overview of each feature, explaining, in about a page, its purpose and the main lines of its behaviour.
The next step to retrieve more information on a given feature is to consult the 3GPP Ultimate web site, as explained in Clause 4.
This document presents the 'initial state' of the Features introduced in Release 14, i.e. as they are by the time of publication of this document. It is however important to note that each Feature is subject to be later modified or enhanced, over several years, by the means of Change Requests (CRs) associated to the Feature or to 'TEI' (Technical Enhancements and Improvements). It is therefore recommended to retrieve all the CRs which relate to the given Feature, as explained in Clause 4, to further outline a feature at a given time.

This document establishes terminology for digital twin (DTw) and describes concepts in the field of digital twin, including the terms and definitions of digital twin, concepts of digital twin (e.g. digital twin system context, life cycle process for digital twin, types of digital twin), functional view of digital twin, and digital twin stakeholders. This document can be used in the development of other standards and in support of communications among diverse, interested parties or stakeholders. This document is applicable to all types of organizations (e.g. commercial enterprises, government agencies, not-for-profit organizations).

Not available yet

Not available yet

The Distributed Co-Simulation Protocol (DCP) was developed in scope of the ACOSAR (Advanced Co-Simulation Open Systems Architecture) project. The DCP specifies a data model, a finite state machine, a set of protocol data units and a communication protocol. It is intended for the integration of real-time and/or non-real-time systems. It features a master-slave principle. Furthermore, it is defined independently of the underlying transport protocol and distinguishes between native and non-native DCP specifications. With this approach, support for additional transport protocols may be added in the future. The DCP specification also includes a default integration methodology.
The DCP specification document at hand can lead to a modular, considerably more flexible, as well as shorter system development process. The DCP is suitable for application in numerous industrial domains. Furthermore, it has the potential to enable new business models.

This project will develop the International Standard to describe the general considerations and use cases of external visual systems, which include the system model of the eHMI(external Human-Machine Interfaces).

The present document provides all features in scope of a vehicle sub-system from C2C-CC point of view. This set of features is the consolidated and communicated understanding of the core vehicle system features in a vehicle C-ITS station. According to the C2C-CC contract, the present list focuses on specifying the vehicle C-ITS station transmitting side. Moreover, this set is oriented towards enabling the vehicle use cases as included in the current C2C-CC release. Details about the content of the release can be found in [C2CCC RelOv] and are listed in brief in the following:
• emergency vehicle warning
• dangerous situation
• stationary vehicle warning
• traffic condition ahead warning
• collision risk (exchange of IRCs)
• adverse weather conditions
The use cases as part of the current C2C-CC release do not constitute a mandatory set of applications to be implemented as part of a vehicle C-ITS station. Only a subset of them might be supported by a specific implementation of the vehicle C-ITS station.
In terms of C2C-CC a feature defines a service or a major part of the vehicle C-ITS station. They always detail an objective, but – like objectives – without any further specification about its details. As a result, features are not directly testable.
Features itself are detailed by one or more requirements. A feature can be assumed as tested, if all requirements, which detail this feature, are tested.