Service Definition

„Traffic condition and travel time information service” means, both pre-trip and on-trip, the provision of traffic condition (LoS) and travel time information on identified road segments of the network and interfaces, thus enabling road users to optimize and better anticipate their journey ahead. This predictive or real-time information will use different information channels, accessible by the road user via different end-user devices. The service may comprise common as well as individual (personalised, on-demand) information.

Functional Requirements

Functional architecture

The function of the service is to provide Traffic condition and travel time information to road users either pre-trip or on-trip. This may be demand responsive or led by the information providers. In Europe, both private and public information providers are involved in this information provision (see organisational requirements).

The following figure shows the typical functional architecture of a “Traffic condition and travel time information service”. The vertical lines drawn between sub-function 1, 2 and 3 show, where it is appropriate to segment the whole functionality of the service into at most three sub-functions:

 

Functional requirement:

• FR1: Functional decomposition into sub-functions with the provision of interfaces must be carried out to enable interoperability in cases that the service is carried out 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

Functional decomposition[1] and interfaces

[1] The ITS service is „distributed“ over more than one administration (cross-border, cross-regional) for operation, i.e. different road operators and other parties are involved, providing „logical sub-functions“. Between the distributed functions interoperability must be guaranteed by properly specified interfaces.

Sub-function 1 “Data collection”

Devices, tools and methodologies for traffic data collection are not covered by this deployment guideline. They depend amongst other things on the particular data collection system used and are left to the operator to select.

Functional requirements:

• FR2: All data and information collected/signalled/generated by both automatic and non-technical sources/road operator actions must contain:
  • where applicable, a location code and
  • 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 must respect DATEX II location reference and time stamp models.

• FR3: Beneath real time data also historic data should be used to generate Safety-Related & Real-Time Traffic Information.

Sub-function 2 “Data fusion and processing”

Note: „Data fusion and procession“ includes “data validation and certification”.

Within Europe different methodologies exist to aggregate collected data and other input information for Safety-Related & Real-Time Traffic Information. These methodologies are not covered by the present guideline and are left to the operator to select. They depend amongst others on the particular data fusion and processing system used and particular traffic model applied.

Functional requirements:

• FR4: Source, scope and quality (based on a quality model to be defined) of data provided by content owners[1] to content providers must be defined by the partners and must be part of data interface description.
• FR5: The quality of the data should not only be defined but should also be in line with the EU-EIP Quality Package

Sub-function 3 “Information provision”

Information provision is carried out by different service providers in accordance with specific business models. The information provision to the road user on end-user devices has to be done using various information channels. When providing customer-oriented Safety-Related & Real-Time Traffic Information services, the users‘ benefit can be increased by providing information in combination with additional traffic information (i.e. see TMS-DG07 – Traffic Management for corridors and networks)

Functional requirements:

• FR6: All stakeholders and partners involved in the value chain of Safety-Related & Real-Time Traffic Information service should formally agree and accept under which conditions information can be disseminated to the end user, for example:
  • without any restrictions whatsoever
  • 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

Interface Requirements

Note: If the Traffic condition and travel time information service „distributed“ over more than one administration (cross-border, cross-regional) for operation, i.e. different road operators and other parties are involved, providing „logical sub-functions“, interoperability between the distributed functions must be guaranteed by properly specified interfaces.

Interface requirement interface 1:

• FR8: To enable interoperability between all involved parties the sub-functions „data collection and „data fusion and processing“ and must – depending on the used data type for the automatic event detection require/provide an interface 1 with at least one or several of the following information structures:
  • traffic volume and speed, occupation rate (e. g. collected by loops, radar, video…)
  • trajectories (travel time per itinerary e. g. collected by APNR – automatic number plate recognition, video…)
  • travel time (e. g. collected by FCD, Navigation Systems, Phone Data, …)

Interface requirement interface 2:

• FR9: To enable interoperability between all involved parties the sub-functions „data fusion and processing“ and „information provision“ must require/provide an interface 2 with the following event information structure (if no information is available for an element, value can be left void):
  • Level of Service
  • Traffic states
  • Travel times

Interface advice interface 2:

• In order to provide efficient and adapted information when needed and also to prevent from disseminating counterproductive information additionally event-based information and official traffic management plans should be provided, which are covered by other Deployment Guidelines TMS-DG07 „Traffic management for corridors and networks“)

Organisational Requirements

Organisational Architecture/Business Model

A general overarching description of the key actors, their roles in the value chain and the related conditions for TIS-service provision is outlined in the SRTI & RTTI – Key actors in the information value chain.

Harmonisation focus of the chapter: “Interoperability on the organisational level”. The chapter should comprise at least on illustration of the organisational architecture/structure of the service (block-diagram style) in a way that the typical main organisational roles (of the service value chain) are depicted and identifiable.

Note: Even though partners involved in the service can be either public or private road organisations as well as public or private service providers, who are legally autonomous in varying degrees and in the international context sometimes even work on different national laws, it is not required to define organisational aspects on a legal and binding basis.

Organisational advice:

• Where different autonomous parties are involved, clear definitions of organisational aspects are a crucial precondition for a successful implementation of a „Forecast and real-time event information service“. These definitions are documented in the form of e.g. a “Common partner arrangement” or a “MoU – Memorandum of understanding” which establish the roles and responsibilities of the respective parties to any co-operation and be agreed by all parties/partners involved.

Organisational requirements:

• OR1: The organisational and operational structure of the service as well as the role of each public organisation/body and its exact responsibility and task in the 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 for successful implementation of a „SRTI & RTTI Service“ must be documented and agreed by all involved parties/partners to fix the cooperation.
• OR3: All necessary collaboration processes/workflows and interfaces must be described.
• OR4: The information provision should be in accordance with any management plans (TMP, see TMSDG07) which are in operation of the road authorities or traffic management centres.