3.5 TTIS-04 Road Weather Information

3.5.1 ITS service at a glance

3.5.2 Harmonization requirements and advice

3.5.2.1 Functional requirements and advice

3.5.2.1.1 Functional architecture

Figure 26 shows the typical functional and informational architecture of the “Road Weather Information Services” and gives a schematic overview of the typical system architecture required for both weather information and weather warnings.

3.5.2.1.2 Functional requirements and advice

Functional requirements:

• FR1: The Road Weather Information service should support road maintenance and infrastructure management (expert service) and should be able to collect process and disseminate weather information for travellers (end user service).
• FR2: The Road Weather Information should provide information in the native language(s) at the output location, and from a user selected choice of other appropriate foreign languages, when applicable.
• FR3: The Graphical User Interface (GUI) should provide information using graphical representation or text. Graphical form should include the use of maps as well as text.

Functional advice:

Note: Beside the provision of road weather information other services could benefit from weather information. This provision is not directly the scope of a Road weather information service and therefore the following list is to be seen as functional advice (not a requirement). However, a clear definition of interfaces is needed at a later stage in the development of any further specification: —  The provision of the Road Weather Information service may also assist other services in the planning of (Multimodal) routes/ finding of alternative routes and assist in any decision by the user to switch mode (weather information as e.g. input parameter for multimodal services)

• The Road Weather Information service may be able to recommend short term road maintenance activities, including winter maintenance, based on data collected from the road infrastructure possibly combined with the current and/or forecast weather conditions^[1].
• The Road Weather Information service may support time predictions for a particular trip (road weather information as inputs parameter for a travel time estimation given to users by info services).
• The Road Weather Information service should have a minimum impact on the driving task (distraction).
• The Road Weather Information service must not do anything to reduce the safety of either the travellers in the vehicle (e.g. distracting drivers by overloading them with too much simultaneous information), or the staff using to operational equipment, e.g. in toll booths.
• The Road Weather information services may be delivered in the following ways in any combination:
  • as an information service for non-recurring requests
  • as a subscription service for periodical requests with the same request parameters for a specific route or area and a defined time period
  • as a monitoring service to monitor a specific area or a requested route during a trip. In case of a monitoring service only relevant weather warnings (alerts) shall be provided to the user.

3.5.2.2 Interface requirements

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

• IFR1a: If a service forRoad Weather Information is implemented at interface 1 (Figure 27) and it provides data on one or more of the categories listed below,
  • (a) temporary slippery road
  • (e) reduced visibility
  • (h) exceptional weather conditions

the service must provide 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” including the following elements:

• location of the event or the condition
• the category of event or condition (short description of it)
• driving behaviour advice, where appropriate

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

• IFR1b: If a service for Road Weather Information is implemented at interface 1 (see Figure 27) and it provides data on (p) weather conditions affecting road surface and visibility, the service must provide coded information following the Delegated Regulation (EU) 2015/962 (RTTI) including the following elements:
  • location of the event or the condition
  • the category of event or condition (short description of it)
  • driving behaviour advice, where appropriate
• IFR2: If interface 2 is implemented, the Road Weather Information Service must provide at interface 2 (see Figure 27) Weather information coded in C-ITS messages including the following elements:
  • Location of the weather warning area
  • Location of slippery roads
  • Relevant road signs regarding the weather situation
• IFR3: When relevant, the Weather Information Service should collect at interface 3 (see Figure 26) C-ITS coded Probe Vehicle Data information (microscopic traffic situation such as travel speed, travel direction, steering position, current location of a vehicle, traction information) relevant to this ITS Core service. 

3.5.2.3 Organisational Requirements

Organisational Architecture / 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.4. More information on new models of cooperation between public and private partners can be found in chapter 4.1.4.2

Organisational advice:

• The recommended organizational characteristics for minimum LoS^[2] in the area of safety critical Operating Environments (C1, T2, T4, R2, R4, R6, R8), are as follows:
  • Organisation of the TIS: A.1, A.2, A.3 or A.4
  • Obligations for TIS provision: B.1
  • Data used in the TIS: C.1or C.2
  • Business model of the TIS: D.1

Organisational requirements:

• OR1: Public administrations must act according to the assigned scope of their activities, which is normally regulated by law or similar regulations. In the field of the road weather information service provision, it has therefore to be distinguished between mandatory services and nonmandatory (voluntary) ones according to national laws.
• OR2: If a guarantee is needed that a service is provided in a single country, a regulation must be issued.

3.5.2.4 Common Look & Feel requirements

Common Look & Feel requirements:

• CL&FR1: Three or four levels should be indicated based on seriousness/ probability of the event when providing a web-based information service. It is recommended that the levels are defined based on local circumstances. However, the message for the drivers should be clearly communicated and be the same across Europe
  • Level 0 (normal conditions) – message for drivers: be prepared
  • Level 1 (moderate conditions) – message for drivers: drive carefully^[3]
  • Level 2 (strong conditions)- message for drivers: special attention needed^[4]
  • Level 3 (extreme conditions) – message for drivers: take action (in accordance with regulations from each Member State, regarding the type of extreme condition of weather and what means ”extreme weather” in that country)
• CL&FR2: A graphical representation should use a pictogram + a coloured bar to indicate the level of seriousness/ probability when providing a web-based information service.
  • Level 0 (normal conditions) – green
  • Level 1 (moderate conditions) – yellow^[5]
  • Level 2 (strong conditions)- orange^[6]
  • Level 3 (extreme conditions) – red
• CL&FR3: As content for pictograms the defined set of content for pictograms should be used when providing a web-based information service will be aligned with the pictograms regarding weather information from Vienna Convention. It is recommended that the limits are defined based on local circumstances.
  • rain: 3 rain drops
  • thunderstorm, lightning
  • snow / ice: snow flake
  • fog: fog
  • slippery road surface: slippery road (according Vienna convention)
  • wind: wind cone
  • flood: house on the waves
  • avalanche: lumps falling from the mountain
  • forest fires: fir in flames
  • coastal events: two waves

To support the above-mentioned CL&FR3, the EGs take into consideration that the same symbols will be used as in the European weather warning system Meteoalarm, provided by Eumetnet, which is a network of public European weather services. With these symbols and warning levels mentioned above the warnings would already be coherent among most of the European weather services. The following pictograms are taken from the Austrian web-based service SWIS as one deployment in compliance with this service description:

Table 21: Recommendations for common Look & Feel: Weather warnings, exemplary  icons

3.5.2.5 ICT Infrastructure requirements

No specific requirement or advice

3.5.2.6 Required standards and specifications

Information provision standards:

• IPS1: If the Road Weather Information service provides Road Weather Information at interface 1 (see IFR1), it must be profiled based on EN 16157-5:2020 using the DATEX II Recommended Service Profile for Road Weather information.
• IPS2: If interface 2 is implemented, Weather information regarding the in-vehicle signage of road signs (see IFR2) should be profiled in an IVIM (Infrastructure to Vehicle Information Message) based on ISO 19321 using the C-ROADS C-ITS Message Profiles for the In-Vehicle Signage service. Additionally, all other Weather information (see IFR2) should be profiled in a DENM (Decentralized Environmental Notification Message) based on ETSI EN 302 637-2 using the C-ROADS C-ITS Message Profiles for the Hazardous Location Notification service and the Use-Cases Weather Condition Warning (WCW) and Temporarily Slippery Road (TSR), as defined in the C-ROADS Common C-ITS Service and Use Case Definitions.
• 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.5.2.7 Level of Quality and Service Definition

3.5.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 Road Weather Information services. This table is not end-user oriented as Table 22.

Level of Quality advice:

• It is recommended that Road Weather Information services fulfil the “Basic quality level” as a minimum.

3.5.2.7.2 Level of Service Criteria

Table 22 gives the Level of Service recommendations for a Road Weather Information service. The background of this concept is descripted in chapter 2.6.

Table 22: Level of Service recommendations for Road Weather Information

3.5.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 “Road Weather Information”, the minimum and optimum LoS should respect the following Level of Service to Operating Environment mapping table.

Note: The Level of Service to Operating Environment mapping table is not an outcome of a specific scientific analysis but an expert view output.

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

---

[1] So there is no ambiguity in the decision making process a balance needs to be struck between what the system can recommend in terms of short term road maintenance activities and the contractual responsibilities of the Maintenance Providers.

[2] In 3.5.2.8 the optimum and minimum Level of Service for EU EIP operating environments are defined

[3] Level 1 could be merged with Level 2 to communicate only three levels towards the end users

[4] Level 1 could be merged with Level 2 to communicate only three levels towards the end users

[5] Level 1 could be merged with Level 2 to communicate only three levels towards the end users

[6] Level 1 could be merged with Level 2 to communicate only three levels towards the end users