3.3 TTIS-02 Traffic Condition and Travel Time Information

3.3.1 ITS service at a glance

Service definition

“Traffic Condition and Travel Time Information service” means the provision of information on the traffic conditions (LoS) and travel times on identified road segments of the network.
Traffic Condition / Level of service (LoS) is a qualitative measure used to relate the quality of traffic service. LoS is used to analyse road networks by categorising traffic flow and assigning quality levels of traffic based on performance measure shuck as speed, volume, delay etc. This is typically based on the continuity of flow.
Travel time is the total elapsed time necessary for a vehicle to travel from one point to another over a specified route under existing traffic conditions.
As the volume of traffic approaching a point exceeds capacity, LoS falls, and traffic is characterised by stop-and-go waves, poor travel times, low driver comfort, and increased accident exposure.
This predictive or real-time information can be provided both on-trip and pre-trip using different information channels.

Service objective

A road user provided with high quality traffic condition and travel time information will react to the information and adapt their travelling and driving behaviour; this could mean changing routes or trip scheduling; as well as reducing speed in congestion.
Thus, the road network is used in a more efficient and safe way, with significant contributions to improving environmental performance, energy efficiency and security of road transport.

Service benefit radar

ITS service key words

  • Travel time
  • Traffic condition
  • Level of Service (LoS)
  • traffic flow
  • traffic speed
  • volume
  • delay
  • congestion

3.2.2 Harmonization requirements and advice

3.2.2.1 Functional requirements and advice

3.2.2.1.1 Functional architecture

The following figure shows the typical functional architecture of a “Traffic Condition and Travel Time Information service”.

Figure 23: Functional architecture of the Traffic Condition and Travel Time service

3.3.2.1.2 Functional requirements and advice

Functional requirement:

  • FR1: Functional decomposition into sub-functions with the provision of interfaces must be carried out to enable interoperability in those cases that the service is provided by more than one organisation

Functional advice:

  • Functional decomposition is recommended in any case to be prepared to involve yet further parties as may be the case in the future.

Sub-function 1 “Data collection”

Tools, devices and methodologies for traffic data collection are not covered by this service description. They depend amongst other things upon the particular used data collection system and are left to the operator to select.

Functional requirements:

  • FR2: All collected and provided data elements must contain:
    • where applicable, location code(s)
    • a time stamp

The geographical basis of the location code should be left to the road operator to define, anyway the model of information provision to other organisations must respect DATEX II location reference and time stamp model.

  • FR3: Besides real-time data also historic data should be used to generate traffic condition and real-time predictions.

Sub-function 2 “Data fusion and processing”

Note: “Data fusion and processing” includes “data validation and certification”. Within Europe different methodologies exist to aggregate the real-time and predictive traffic condition and travel time information. These methodologies are not covered by this service description and are left to the operator to select. They depend amongst others on the particularly used data fusion and processing system and particular traffic model applied.

Functional requirements:

  • FR4: Source, scope and quality of data provided by content owners to content providers must be defined by the partners and must be part of data interface description.
  • FR5: The quality of the data should be defined and the travel time information quality should be in line with the relevant quality model.

Sub-function 3 “Information provision”

Different service providers in accordance with specific business models carry out information provision. The information provision to the road user on end-user devices has to be done using various information channels.

Functional requirements:

  • FR6: All stakeholders and partners involved in the value chain of a Traffic Condition and Travel Time Information service should formally agree and accept under which conditions information can be disseminated to the end user, for example:
    • without any restrictions
    • tied to the conditions of an appropriate partnership agreement
  • FR7: Underlying the information provision (information channels and end user devices), where applicable, the area (territory) and locations of information dissemination should be defined in relation to the media used

3.3.2.2 Interface requirements

Interface requirements:

  • IFR1: If the Traffic Condition and Travel Time service provides data of one or more of the categories listed below at interface 1 (see Figure 23), it must provide coded information including the following elements:
    • Location for the traffic conditions and/or travel times
    • Traffic status (Level of Service), and if applicable relevant types of vehicles
    • Current travel times, if applicable also for free flow, and if applicable relevant types of vehicles
    • Relevant Point of time
  • IFR2: If interface 2 is implemented, the Traffic Condition and Travel Time Information Service must provide at interface 2 (see  Figure 23) C-ITS coded information on the Traffic Condition and Travel Time including the following elements:
    • the setting of a road sign (what is shown in the sign)
    • the location/relevant area of the sign
  • IFR3: When relevant, the Traffic Condition and Travel Time Information Service should collect at interface 3 (see Figure 23) C-ITS coded information on Probe Vehicle Data (microscopic traffic situation) relevant to this ITS Core service, such as travel speed, direction, current location of a vehicle.

Note: The required/provided information content depends on availability and the levels of quality criteria table agreed among the partners involved

Interface advice:

  • In order to provide efficient and adapted information when needed and also to prevent from disseminating counterproductive information additional event-based information and official traffic management plans should be provided, which are covered by other ITS Core services (see TTIS-01 Forecast and Real Time Event Information and TMS-07 Traffic Management for Corridors and Networks)

3.3.2.3 Organisational requirements and advice

OrganisationalArchitecture/BusinessModel

A general overarching description of the key actors, their roles in the value chain and the related conditions for TTI service provision are outlined in Chapter 3.1. More information on new models of cooperation between public and private partners can be found in chapter 4.1.4.2

Organisational advice

  • Where different autonomous parties are involved, clear definitions of organisational aspects are a crucial precondition for a successful implementation. These definitions should be documented in the form of . “Common partner arrangement” or a “Memorandum of understanding” (MoU), which establishes the roles and responsibilities of the respective parties in any cooperation and is then agreed upon by all parties/partners involved.

Organisational requirements:

  • OR1: The organisational and operational structure of the service, as well as the role of each organisation/body and its exact roles and tasks in the value chain must be compliant with the National Access Points across Europe, within the scope of the implementation of the delegated acts adopted under Directive 2010/40/EU
  • OR2: All necessary organisational aspects must be documented and agreed by all involved parties/partners to ensure cooperation.
  • OR3: All necessary collaboration processes/workflows and interfaces must be described and documented

3.3.2.4 Common Look & Feel requirements and advice

Common Look & Feel advice:

  • The core message of information provided for the end user should always be consistent, whatever media or end user device is used for distribution.

Specifically, for traffic condition information

Common Look & Feel requirement:

  • CL&FR1: The display of signs/pictograms on VMS or other end-user devices should be in accordance with prevailing national road codes and:
    • Member States which ratified the Vienna Convention MUST respect the Vienna Convention and the European agreement supplementing the convention (1st May 1971) and SHOULD consider the Consolidated Resolution on Road Signs and Signals (R.E.2).
    • Member States which did not ratify the Vienna Convention SHOULD follow the Vienna Convention and also consider the R.E.2.

It is up to the deploying road operator to ensure that physical road signs are well and widely understood by the road users.

Specifically, for travel time information

Common Look & Feel requirements:

  • CL&FR3: The display of travel times and delay times on VMS or other end-user devices (websites, navigation systems…) should respect the following format: <XX> min.
  • CL&FR4 : Concerning VMS, the travel time may be complementary with “(+ YY)” to denote the delay in addition to normal travel time. The YY should represent the additional time due to perturbation, included in the <XX> part.
  • CL&FR5: It should always be indicated for which location (intersection, exit, city …) the travel time displayed is valid.

Common Look & Feel advice:

  • Every VMS or other end-user devices providing information about abnormal travel time should also inform as well on the traffic situation.

3.3.2.5 ICT Infrastructure requirements and advice

No specific requirements or advice.

3.3.2.6 Required standards and specifications

Information provision standards:

  • IPS1: If the Traffic Condition and Travel Time service provides Traffic Condition and Travel Time information (see IFR1), it must be profiled based on CEN/TS 16157-5:2020 using the DATEX II Recommended Service Profile for Traffic Condition and Travel Time. The use of the PredefinedLocationsPublication is recommended. For calculated travel time information, the ElaboratedDataPublication is recommended to be used, otherwise the MeasurementSiteTablePublication.  
  • IPS2: If interface 2 is implemented, Traffic Condition and Travel Time information (see IFR2) must be profiled in an IVIM (Infrastructure to Vehicle Information Message) based on ISO 19321 using the C-ROADS C-ITS Message Profiles for the IVS-TS use case.
  • IPS3: When relevant, the Probe Vehicle Data (microscopic traffic situation) information (see IFR3) should be collected, which is profiled based on ETSI EN 302 637-2 using the CAR2CAR Communication Consortium Basic System Profile.

3.3.2.7 Level of Quality and Service definition

3.3.2.7.1 Level of Quality criteria

The “Levels of Quality table” for the definition of quality criteria for RTTI and SRTI services, which differentiates data quality into “basic”, “enhanced” and “advanced” (for detailed information see Quality of S Real-Time Services – Quality package) reflects the requirements for the data quality which are needed for Traffic Condition and Travel Time Information services. This table is not enduser oriented as Table 17.

Level of Quality advice:

  • It is recommended that Traffic Condition and Travel Time Information services fulfil the “Basic quality level” as a minimum.
3.3.2.7.2 Level of Service criteria

Table 17 gives the Level of Service recommendations for a Traffic Condition and Travel Time Information service. The background of this concept is descripted in chapter 2.6.

Table 18: Level of Service to Operating Environment mapping table (see also chapter  2.5.3 and ANNEX

3.3.2.7.3 Level of Service criteria related to Operating Environment

Level of service requirement:

  • LoSR1: In the case that pre-deployment surveys / evaluations provide the necessary evidence to proceed with the deployment of the ITS-service “Traffic Condition and Travel Time Information”, the minimum and optimum LoS should respect the following Level of Service to Operating Environment mapping table.

Note: Level of services concerning the core criteria“User interface” has only to be considered for traffic condition information (not relevant for traveltimes).

Table 18: Level of Service to Operating Environment mapping table (see also chapter  2.5.3 and ANNEX

C)