2.5  How ITS Core services share information

2.5.1 Interface implementation model

All ITS applications process digital data, some of them process data that is input from other systems and some produce data that needs to be sent out to other systems. This introduction describes the data sharing context of the ITS services in a technology agnostic way. These requirements reflect the regulatory context as well as the technical conditions at the time when this text was written.

In subsequent chapters, the current technical implementation options for the interfaces are described, based on mature technologies available for operational roll-out and also based on current relevant regulation.

Note: Other technical options are currently considered in the context of R&I projects, but these have not reached a level of maturity yet for everyday operation.

The structure for describing the data sharing context of the ITS Core services described in this Reference Handbook is depicted in Figure 9.

Figure 9: Data sharing architecture (Road operator view)

The centre of the diagram represents the road operator domain with the ITS service and its system boundary. The value chain overview – depicted in the background – is used as a symbol for the road operator processes. On the service boundary – depicted by a grey dotted line – we see three interfaces, which are served with two types of communication (network based communication, direct communication).

  • Interface 1 realises a backbone interface that allows the service to communicate via NAPs with other third party backbone systems (depicted in grey). Other backbone systems may be those of other road operators, service providers for vehicle fleets or end-user applications operated inside the vehicle, or other systems (see below and section 1.2.4 for the NAP roles).
  • Interfaces 2 and 3 describe direct communication links (i.e. via RSUs) between the road operator and individual vehicles (i.e. via OBUs) or other devices used inside the vehicle e.g. smartphones
    • Interface 2 is the interface to convey information from the service into the vehicles or the user device
    • Interface 3 is the interface for in-vehicle data being transmitted from the vehicle/user device to the service as a source data.

As stated above, the description so far was technology agnostic. In order to do actual implementations of the service, concrete technologies have to be selected to implement these interfaces. The requirements presented in this document will provide the required choices regarding technologies and data profiles. The requirements regarding Interface 1 are mainly governed by the Delegated Regulations published by the European Commission in the scope of the ITS Directive. These stipulate the use of National Access Points and the application of DATEX II standard (CEN 16157 series) for most data encoding. A building block of such profiles are the Recommended Service Profiles (RSP).

Communication with connected vehicles based on cellular radio technology to convey backbone data exchanged via Interface 1 into vehicles is mature and well established. Mature technologies for implementing Interface 2 and Interface 3 are currently limited to C-ITS based on ITS G5 (see comments in chapter 1.2.6). The requirements stated will directly refer to the two guiding specifications for infrastructure to vehicle (I2V) and vehicle to infrastructure (V2I) communication. These are the C-Roads “harmonised communication profile” (for I2V on Interface 2) and the “Basic System Profile” published by the CAR2CAR Communication Consortium (for V2I on Interface 3). A second indirect channel to exchange information with the end user/vehicle (see Figure 9) is currently also under specification (specification for interoperability of back-end hybrid C-ITS communication) in the C-ROADS project.

A second indirect channel to exchange information with the end user/vehicle (see Figure 9) is currently also under specification (C-ITS IP Based Interface Profile) in the C-ROADS project.

Subsequent sections will provide general introductions into the underlying technologies, and will specify for each ITS service the functional, technology agnostic requirements for data sharing as well as the required requirements for concrete standards and specifications for the currently available technologies. It should be noted that the development of connectivity technology for ITS is currently progressing fast and these requirements will require periodic update to keep pace with the evolving technology options. It is also challenging for users of the different types of interfaces to ensure consistency between the information provided via these disparate channels. Note that there is an increasing effort to support consistency with guiding documentation. In particular for safety related information, a cooperation of various actors has produced a document to relate the different implementation technologies to the concepts of the respective Delegated Regulation (EU) 886/2013. This document can be found at: Safety related message sets – Selection of DATEX II Situations, DENM and TPEG2-TEC Causes and TMC Events for EC high level categories.

2.5.2 Required interface standards and specifications DATEX II

For most of the IF1 interfaces, DATEX II, the European standard for the exchange of traffic information and traffic data must be used. It is standardised in the CEN/TS 16157 and EN 16157 series. The most relevant part of this series for the IF1 interfaces is Part 3, “Situation Publication”, which offers the data model for traffic related messages (for example safety related or real-time event information, incidents, …) and operator actions (for example most of the traffic management services). DATEX II covers a wide spectrum of Location Reference standards that can be used to describe the location of the given event or measure.

To use the wide spectrum of the DATEX data model, it is recommended to use so called DATEX II Profiles, which are tailored sets of elements that are relevant for the specific use case or information need. Thus, a profile is always a subset of the overall DATEX II model (“Level A”), because single elements or even complete branches of the model can be deselected. It is also possible to sharpen multiplicity restrictions, i.e. for example to make optional DATEX II elements mandatory in the profile.

A building block of such profiles are the Recommended Service Profiles (RSP) mentioned in this handbook and created by the DATEX II PSA organization. An RSP contains basic elements that a specific profile must contain, i.e. a RSP forms the base on which upon a specific profile will be created. It is possible (but not recommended) to remove elements from the RSP for the specific profile. On the other hand, it is recommended to add further elements to enrich the profile for the data elements available from a specific data supplier. A number of different RSPs are declared in this document to be used for the different services. It is important to stress, that not only the RSP itself can be used, but also a specific profile created out of this RSP. To find the RSPs and to create a profile, the DATEX II Schema generation tool should be used. This tool can be found at https:// webtool.datex2.eu/. C-ITS

For the interfaces 2 and 3, C-ITS based on ITS-G5 is to be used. Note that meanwhile a comparable access technology has been developed in the scope of the set of standards for cellular radio networks, called C-V2X. Since this is not readily available on the market for every-day operation yet, it is currently not yet referred to in this handbook, which may change in the future and would lead specifications which are an alternative to ITS-G.

For interface 2, the most relevant documents are the “C-ROADS C-ITS Message Profiles” and the “C-ROADS Common C-ITS Service and Use Case Definitions”, which describe the C-ITS services and use cases and the messages sent out by the infrastructure. For interface 3, the CAR 2 CAR Communication Consortium “Basic System Profile” defines the services and messages, which are sent out by vehicles.

The I2V communication in this reference handbook is mainly done via Infrastructure to Vehicle Information Messages (IVIM) and Decentralized Environmental Notification Messages (DENM), which are standardized in the ISO/TS 19321 and ETSI EN 302 627-3. However, the usage of the services is defined in the “C-ROADS Common C-ITS Service and Use Case Definitions”.

In the Service Definitions, each service (for example In-Vehicle Signage) is described according to the following scheme: at first, the service in general is defined using the keywords Summary, Background, Objective, Expected Benefits and Use Cases. After that, each use case is introduced using similar keywords. Subsequently follows a use case description regarding Situation, Logic of transmission, Actors and relations, Use case scenario(s), Display / Alert principle, Functional constraints / dependencies and Relation to C-Roads C-ITS Message Profiles. 

The V2I communication is mainly done via DENM and Cooperative Awareness Messages (CAM), which are standardized in the ETSI EN 302 627-3 and ETSI EN 302 537-2. The usage of these messages and the according services is also defined in the CAR 2 CAR Communication Consortium “Basic System Profile”, especially in the “Triggering Conditions” documents. The CAR 2 CAR Communication Consortium documents define the requirements for sending out messages and the contents of the messages.

The usage of the C-ITS services and use cases is dependent on the infrastructure available. In this document, a number of C-ITS use cases are declared to be used for the different services.