Skip to main content

UC 8: Slippery road warning

Operation use case​

Definition​

SLIPPERY ROAD:

Road location or area where the road surface has little adhesion, potentially causing slipping of vehicles passing by, especially when executing braking or steering manoeuvres in that area. The cause of the slipperiness can be weather related like snow, ice, heavy rainfall,.. or chemical due to spills or loss of load of slippery-making substances.

Precise information on the zones of slipperiness are most times difficult to obtain. Most of the issued notifications are point informations where slipperiness is often spread over larger zones, especially in weather related slipperiness, but also chemical slipperiness cases like fuel spills that can be spread over multiple miles of road area. The minimal goal is to raise the attention of the driver on a single (start) point. If the trace of the slippery surface is known, it will be added to the message. Otherwise, common sense takes over and awareness of further possible slipperiness is based on the own observations on type and nature of the slipperiness.

SMOG/SMOKE/REDUCED Visibility:

As a sub-use case of adverse weather the case of reduced visibility is also made part of this use case. The general alert of reduced visibility is added to the DENM Causecode list. However, at this time, it remains a more theoretical possibility since there are no (automatic or Crowd sourced) data sources available to trigger these notifications.

Opposite direction for event: If there is no hard deviation between the opposite lanes, the event is always duplicated (in PIP) for the opposite direction. This guarantes that all possible involved road users will get the warning message. On roads with separate tracks, there is no duplication. Except for weather oriented messages. If there is a road separation is based on the road geometry in OSM.

Operational Road Environment​

  • Territory: Flanders
  • Border passing cases: All of Flanders roads. The quality of coverage of the government information sources is best on highest levels road classes. Border passing cases: N/A
  • Road class: none
  • Time restrictions: none
  • Weather restrictions: none
  • Special restrictions: N/A

MI and Historical archive​

DENM message, main characteristics​

Cause and sub cause codes are:

CausecodeDescriptionSubcausecodeDescription
6Adverse weather condition – adhesion0unavailable
1Heavy frost (hoarfrost patches on the road)
2Fuel on Road
3Mud on Road
4Snow on road
5Ice on Road
6Black Ice on roade
7Oil on Road
8Loose chippings
9Instant Black ice - coming from undercooled freezing rain
10Road salted – surface may still be slippery
17Adverse weather condition – extreme weather condition0unavailable
1Strong Winds
2Damaging Hail
3Hurricane
4thunderstorm
5Tornado
6Blizard
18Adverse weather condition – visibility0unavailable
1Fog
2Smoke
3Heave Snowfall
4Heavy Rain
5Heavy Hail
6Low Sun Glare
7Sandstorm
8Swarms Of Insects
19Adverse weather condition – Precipitation0unavailable
1Heavy rain
2Heavy snowfall
  • Default time to live 600 seconds -10 minutes. However – Mobilidata will recreate new DENM’s to cover a time period up to 1 hour after initial notification of a spilled load based on road user feedback based alerts. Also: this 1-hour timer is reset after receiving an ‘upvote’ on an existing Mobilidata DENM via RUF. Spilled load notifications coming from the Flanders Traffic center are kept alive as long as the traffic center keeps them alive.
  • Lat/Long position of original situation detection

MI Headers​

{
  "messageType": "DENM",
  "originatingCountry": "BE",
  "protocolVersion": "DENM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:DENM_SLIPPERY_ROAD_01",
  "custom-mobilidata-publisherType": "PIP",
  "custom-mobilidata-dtapEnvironment": "production",
  "custom-mobilidata-useCase": [8],
  "quadTree": [
  ]
}

Historical archive​

The DENM messages are transformed to NGSI-LD class model and stored on historical archive together with AMQP header parameters.

Data processing​

The following steps are executed within the PIP:

  • Event creation The information from the sources as mentioned in the deignated paragraph is collected and validated in the PIP. After this there is the check if the message must be duplicated, depending on road type. Depending the source, events arecreated as DENM message. The government owned weatherstations are via an API read by the PIP, with two different types:
    • Weatherstationsequiped with an embedded roadsensor
    • Weatherstations with only basic characteristics as temperature, moisture, wateronroadsurface, etc. Only the first type is used to generate messages, without extrapolation to larger areas.
  • Event follow-up and ending The PIP will hold a timed set of validated messages for handling. The event is ended when:
    • the source is ending the event
    • via RUF
    • after the time to live: 1 hour after last RUFupvote ( just for RUF initiated events)
  • Merge and decide Check on existence of similar event in the PIP within acceptable limited distance. If present, the events will be joined and the original DENM is updated. Else, a new DENM messageisgenerated. See [Merge & Decide]

Data sources​

  1. Flanders traffic center notifications: own and trusted 3rd party observations and manually generated alerts DATEX point notification of location of observation (any position on highway/and larger secondary roads). Important sidenote: The Flemish network of weather stations (78 alongside Regionally managed roads) is not used to generate slippery road messages due to lack of a model that efficiently links these ‘point’ informations to a relevance area. E.g. current network generates mostly point alerts on the service roads accessing the weather station and not the intended mayor road network.
  2. RUF (road user feedback/new notifications) coming from Mobilidata connected Road users*. Under unspecified validation processes before transmission towards Mobilidata (e.g., required trust level user? number of notifications required? location bundling process?) The user trust system of these C-ITS service providers are not questioned by Mobilidata.

*: for this specific use case a known service provider does not foresee the possibility to generate feedback – it is judged more important to keep focus on the road.

Risk and remarks​

None

Alert cancelling​

None

Message example​

UC 8 Message Example
{
  "shardId": "1",
  "latitude": "51.034515",
  "quadTree": ",120202123130301332,1202021231303,",
  "causeCode": "6",
  "longitude": "4.107428",
  "shardCount": "1",
  "messageType": "DENM",
  "publisherId": "BE00004",
  "serviceType": ",HLN-TSR,",
  "subCauseCode": "0",
  "publicationId": "BE00004:DENM_SLIPPERY_ROAD_02",
  "baselineVersion": "2.1.0",
  "protocolVersion": "DENM:1.3.1",
  "originatingCountry": "BE",
  "custom-mobilidata-useCase": ",8,",
  "custom-mobilidata-timestamp": "1737358178449",
  "custom-mobilidata-alertCCodes": "1003",
  "custom-mobilidata-publisherType": "PIP",
  "custom-mobilidata-baselineVersion": "1.0.0",
  "custom-mobilidata-dtapEnvironment": "production"
}
Tags:
Last updated on by taeyma41