3.2 TTIS-01 Forecast and Real-time Event Information

3.2.1 ITS service at a glance

Service definition

“Forecast and Real-time Event Information Services” are defined as the provision of information about both expected and unexpected events to road users on identified segments of the road network and interfaces. This predictive or real-time information could be provided on-trip and pre-trip using different information channels, accessible by the road user via different end-user devices. The service may comprise common information as well as individual (personalised, ondemand) information.

“Events” are defined as – expected or unexpected – abnormal situations, which may lead to adverse effects on the road regarding to traffic safety, efficiency and environmental effects.

The main objective of providing forecast and real-time event information and warnings to the road user is improving the safety and the efficiency of the network. 

Service objective

Expected and unexpected events can develop into a traffic bottleneck, due to abrupt reactions of uninformed drivers. However, if those drivers know the upcoming traffic situation in advance they would be prepared and could pro-actively adapt their speed and following distance, thus preserving smooth, stable and safe traffic flow. 

Forecast and Real-time Event Information services allow traffic information to be factored into both pre- and on-trip journey planning. This can alter the departure times, assist the driver to take more effective routing decisions, where appropriate, search information for another means of transport or even alter the decision to travel. 

The provision of information to drivers enhances the travelling experience even if the information does not directly have an impact on network efficiency or safety. Better-informed drivers tend to be calmer and hence more concentrated. Other impacts can be the increased mode share of public transport, when drivers decided to select another mode of transport for their trip and reduced air pollution.

Service benefit radar

ITS service key words:

  • Real-time Event Information,
  • incident,
  • accident

3.2.2 Harmonization requirements and advice

3.2.2.1 Functional requirements and advice

3.2.2.1.1 Functional architecture

The function of the service is to provide forecast and real-time event information to road users either pre-trip or on-trip. This may be demand-responsive or initiated by the information providers.

In Europe, both private and public information providers are involved in this information provision (see organisational requirements). More information on the cooperation between public and private partners is provided in chapter 4.1.4.2.

Based on the TISA/CEDR value chain, Figure 21 shows the typical functional architecture of a “Forecast and Real-time Event Information service”, consisting of four subfunctions:

Figure 21: Functional architecture of the Forecast and Real-time Event service

3.2.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 cases that the service is carried out by more than one organisation 

Subfunction 1 “Detection and content collection”

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

Note: “Detection and content collection” is not only done by automatic data collection systems. “Events” are also announced/signalled by so-called ‘non-technical sources’ such as police, fire brigades, local authorities, road users as well as ’generated’ by actions of the road operator.

Functional requirement:

  • FR2: Beneath real-time data also historic data should be used to generate event predictions.

Sub-function 2 “Content pre-procession”

Note: Content pre-procession includes data validation and certification.

Within Europe different methodologies exist to aggregate collected data and other input information for forecast and real-time event 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: 

  • FR3: 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.
  • FR4: The quality of the data should be in line with the Quality Package defined in EU-EIP Activity 4.1

Sub-function 3 “Info-service 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. When providing customer-oriented Forecast and Real-time Event Information services, the users’ benefit can be increased by providing event information in combination with general traffic information (i.e. see “TTIS-02 – Traffic Condition and Travel Time Information”, “TTIS-03 – Speed Limit Information” and “TTIS-04 – Road Weather information”).

Sub-function 4 “Info-servicepresentation”

Functional requirement:

  • FR5: Beneath the means of 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.2.2.2 Interface requirements

Interface requirements a): Safety Related Events as listed in Delegated Regulation (EU) 886/2013 (SRTI)

  • IFR1a: If the Forecast and Real-time Event Information service provides data of one or more of the categories listed below, it must provide interface 1 (see Figure 21) coded information following the Delegated Regulation (EU) 886/2013 (SRTI) and as specified in the Document “Safety related message sets – Selection of DATEX II Codes, DENM Event Types, TPEG2-TEC Causes and TMC Events for EC high level Categories”.
    • (a) temporary slippery road
    • (b) animal, people, obstacles, debris on the road
    • (c) unprotected accident area
    • (d) short-term road works
    • (e) reduced visibility
    • (f) wrong-way driver
    • (g) unmanaged blockage of a road
    • (h) exceptional weather conditions.
  • IFR2a: If interface 2 is implemented, theForecast and Real-time Event Information service must provide at interface 2 (see Figure 21) C-ITS coded real-time information on the event categories required in Delegated Regulation 886/2013 (SRTI), including the location of the following elements:
    • temporarily slippery road
    • animal, people, obstacles, debris on the road
    • unprotected accident area
    • road works
    • wrong-way driver
    • unmanaged blockage of a road
    • reduced visibility
    • exceptional weather conditions
  • IFR3a: When relevant, the Forecast and Real-time Event Information service should collect at interface 3 (see Figure 21) C-ITS coded Information from C-ITS equipped end user devices/ vehicles relevant to this ITS Core service such as travel speed, direction, current location of a vehicle.

Interface requirements b): Real-time Related Events as listed in Delegated Regulation (EU) 2015/962 (RTTI)

  • IFR1b: If the Forecast and Real-time Event Information service provides data of one or more of the categories listed below, it must provide at interface 1 (see Figure 21) coded information following the Delegated Regulation (EU) 2015/962 (RTTI).
    • (a) road closures
    • (b) lane closures
    • (c) bridge closures
    • (e) roadworks
    • (f) accidents and incidents
    • (i) poor road conditions
    • (p) weather conditions affecting road surface and visibility
  • IFR2b: If interface 2 is implemented , theForecast and Real-time Event Information service should provide at interface 2 (see Figure 21) C-ITS coded real-time information on the event categories required in Delegated Regulation 2015/962 (RRTI) and listed below, in detail specified ….
    • road closures
    • lane closures
    • roadworks
    • accidents and incidents
    • weather conditions affecting road surface and visibility
  • IFR3b: When relevant, the Forecast and Real-time Event Information service should collect at interface 3 (see Figure 21) C-ITS coded real-time information from C-ITS equipped end user devices/vehicles relevant to this ITS Core service such as travel speed, direction, current location of a vehicle.

3.2.2.3 Organisational requirements and advice

Organisational Architecture/Business Model:

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

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 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 “Forecast and Real-time Event Information Service” must be documented and agreed by all involved parties/ partners to secure 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.

3.2.2.4 Common look & feel requirements and advice

Common Look & Feel requirements:

  • CL&FR1: Information for the end user should always be consistent whatever media or end user device is used.
  • CL&FR2: 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 signs are well and widely understood by the road users, even if some local variations to the Vienna Convention should be adopted in some countries.

Figure 22: Vienna convention – Consolidated Resolution on Road Signs and Signals (R.E.2) – Event information signs

3.2.2.5 ICT Infrastructure requirements and advice

No specific requirements or advice.

3.2.2.6 Required standards and specifications

Information provision standards a): Safety Related Events as listed in Delegated Regulation (EU) 886/2013 (SRTI)

  • IPS1a: If a service for Forecast and Real-time Event Information is implemented at interface 1, Safety Related Traffic Information (see IFR1a) must be profiled based on EN 16157-3:2019 using the DATEX II Recommended Service Profile for Safety Related Traffic Information.
  • IPS2a: If interface 2 is implemented, Safety Related Traffic Information (see IFR2a) should be provided based on ETSI EN 302 637-2 using the C-ROADS C-ITS Message Profiles for the Hazardous Location Notification and Road Works Warning services and the use cases TSR, APR, OR, AZ, SV, WCW, AWWD, UBR as defined in the “C-ROADS Common C-ITS Service and Use Case Definitions”.
  • IPS3a: When relevant, the Safety Related Traffic Information (see IFR3a) should be collected from C-ITS equipped vehicles based on ETSI EN 302 637-2 using the CAR 2 CAR Communication Consortium Basic System Profile.
  • Information provision standards b): Real-time Related Events as listed in Delegated Regulation (EU)
  • 2015/962 (RTTI)
  • IPS1b: Ifa service forForecast and Real-time Event Information is implemented at interface 1,
  • Real-time Traffic Information (see IFR1b) must be profiled based on EN 16153 using the DATEX II Recommended Service Profiles for Real-time Traffic Information or any international machinereadable format fully compatible and interoperable with DATEX II.
  • IPS2b: If interface 2 is implemented, Real-time Related Traffic Information (see IFR2b) must be provided based on ETSI EN 302 637-2 using the C-ROADS C-ITS Message Profiles for the Hazardous Location Notification and Road Works Warning services and the use cases AZ, UBR, WCW as defined in the C-ROADS Common C-ITS Service and Use Case Definitions.
  • IPS3b: When relevant, the Probe Vehicle Data (microscopic traffic situation) information (see IFR3) such as travel speed, direction, current location of a vehicle should be collected, which is profiled based on ETSI EN 302 637-2 using the CAR2CAR Communication Consortium Basic System Profile.

3.2.2.7 Level of Quality and Service definition

3.2.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 Forecast and Real-time Event Information services. This table is not end-user oriented as Table 16.

Level of Quality advice:

  • It is recommended that Forecast and Real-time Event services fulfil the “Basic quality level” as a minimum.

3.2.2.7.2 Level of Service criteria

Table 15 gives the Level of Service recommendations for a Forecast and Real-time Event Information service. The background of this concept is descripted in chapter 2.6.

Table 15:  Level of Service recommendations for Forecast and Real-time Event

Legend:

  • *UserInterface: This criterion relates to the interface between information and the user. Information should be capable of being displayed through pictograms (language independent) as an optimum, in an official language or an official language plus a shared language (English) as an intermediate level
  • **NeighbouringProvision: Addresses the issue of information exchange and availability between Operators managing neighbouring network. Service providers dealing with several different sources
  • ***LocalandsecondaryNetworkInformation (see LoQ for more details): Deals with provision of information relevant for non-TEN-T routes, provided on TEN-T routes.

3.2.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 “Forecast and Real-time Event Information”, the minimum and optimum LoS should respect the following Level of Service to Operating Environment mapping table.

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

[1] Definition and description of the key actors: see 3.1.4