Skip to main content

UC 6: Active service/safeguarding vehicle warning

Operation of the use case​

The messages made for this use case are for registered service/maintenance vehicles like gritter vehicles, which are driving without the protection of crash absorber(s). The service/maintenance vehicles will offer their position and status in a constant updated stream. Upstream vehicles will get warning messages ("active maintenance vehicle") for all present registered service/maintenance vehicles. Due to limited endangerment, there is no downstream warning. (In awareness traces)

The following subtypes are included in this use case:

  • Towing services
  • Roadside assistance
  • Highways inspectors
  • winter services
  • Collision Absorber / Arrow Truck / Site Security Vehicle
  • mower

If the vehicle does not fit within one of the subtypes, it is classified as 'other'. In that case, the designs will indicate 'maintenance vehicle'. Approaching road users will be warned about their presence on roads if they are active.

We make the difference between UC4 and UC6/7 in the alert that is sent out.

  • UC 4 = Slow Moving Vehicle Warning
  • UC 6/7 = Active Maintenance Vehicle Warning. With further subdivision into subtypes of service vehicles (collision absorber, roadside assistance, etc.)

Active service vehicle position: The registered service vehicle is tracked by its operational track & trace system. The centralized data will be anonimously sent to the Mobilidata API.

Viewpoint of approaching vehicles:
  • upstream

Road user B (passenger vehicle) is driving on the same road as the official vehicle A, upstream in relation to road user A. B is approaching A. Road user B will receive a warning in the application for the event. Road user B can adjust his/her driving behaviour to avoid accidents regardless of his current speed.

  • downstream

Road user C (passenger vehicle) is driving on the same road as road users A and B, downstream of the official vehicle A. Road user C has therefore already passed the active official vehicle and will not receive a warning.

Data sources​

There are two ways, servcie vehcles can connect to Mobilidata:

  • Via an information provider, which will connect to a service provider like Monotch-DVS (Gritter service)
  • Via a service provider, this is the most direct way in communication, but maybe not suitable for standard track & trace solutions

For both paths, the following data is minimal:

  • Timestamp
  • Vehicle ID
  • Vehicle
  • Latitude
  • Longitude
  • Speed
  • Signallinglights on
  • Intervention active
  • Crash cushion down (crash absorbers only)
  • Arrow right on (crash absorbers only)
  • Arrow left on (crash absorbers only)
  • Crosssignal on (crash absorbers only)

0. Information Provider: The infomation provider will take care of a timely transfer of the from a single vehicle received data in a format that the service provider can handle. It is assumed that vehicle ID's will vary between different interventions or service routes. Thisin order to achieve a maximum level of privacy protection.

1. Service Provider: The service provider receives data either froman information provider or directly from vehicles. This data is translated into a DENM information message. The DENM messages are published on the MI.

The service provider is a data source here, with the following input:

  • any infomation provider that supports this use case;
  • any road user connected to a service provider that supports this use case;
  • Vehicle status (not) active.

Types of service​

Winter services: Winter services are connected via an information provider connected to a Be Mobile service API

Characteristics:

  • Data is only sent when the spreader is active (no manual activation).
  • Frequency at which the data is available 0.1 Hz > low
  • There is no test environment available for this data source.

Collision absorbers T&T: Collision absorbers are connected via a range of information providers connected to a TLEX service API under AWV management.

Characteristics:

  • Data will be made available by AWV
  • Update frequency is minimal 1x/10sec
  • Fixed IDs per trip per vehicle
  • Sufficient accuracy of GPS positions (HDOP <= 5)

Data Processing (PIP)​

1. Create an event​

When activating an official vehicle, the service provider will translate the vehicle positions into DENM messages. These are then sent over the MI to the PIP with each position update.

At the same time, the PIP directly processes the positions of the collision absorbers and spreading services via a Backend-to-Backend connection. The PIP will then implement the same functional logic for these position flows as the service providers and verify that the positions meet the minimum requirements. If met, the PIP will convert the positions to DENM messages and publish them over the MI.

2. Follow-up and cancellation of the event​

The active service vehicle is continuously monitored and it is checked at each position whether the vehicle is still in service. As soon as this is no longer active, the DENM messages will time out and no more updates will be sent. If the vehicle is still in service, a DENM update message will be sent with the updated location, speed, heading and adjusted traces.

3. Quality Control​

The PIP will perform a quality check on the DENM messages, before publishing them on the MI, the following checks will be implemented:

  • Are the protocols respected?→ If not, they will be ignored
  • Is all the necessary information available? → Incomplete messages are filtered out.
  • Is the format correct? Messages in incorrect format will not be used.
  • Isn't the message too old? Messages that are too old (older than 2 seconds) are filtered out.

The result of this check and the number of rejected messages will also be available per CSP in the technical monitoring.

We rely on a reliable source and we consider the information collected to be truth, we do not foresee RUF.

RUF​

N/A.

MI & Historical Archive​

DENM information​

Service/maintenance vehicle subtypecauseCodedescriptionsubCauseCodedescriptionAMQP app headeradditional AMQP app header
General service vehicle (non specific)26slow vehicle1slow moving maintenance vehicle//
Tow service26slow vehicle1slow moving maintenance vehicle/vehicleType "towService"
Roadside assistance (pechverhelping)26slow vehicle1slow moving maintenance vehicle/vehicleType "roadsideAssistance"
Traffic guard (road inspector)26slow vehicle1slow moving maintenance vehicle/vehicleType "trafficGuard"
Gritter service26Slow vehicle8salting vehicleserviceType "RWW-WM"vehiceType "gritterService"
Impact attenuator (absorber/arrow)3road works3slow moving road maintenance vehicleserviceType "RWW-WM"vehicleType ïmpactAttenuator"
Mower3road works3slow moving road maintenance vehicleserviceType "RWW-WM"vehicleType "mower"

MI Headers​

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

Historical archive​

Archiving of above mentioned DENM messages and accompanying AMQP-headers is not allowed due to privacy legislation.

Service Provider Implementation​

The service provider (or via the direct link for e.g. winter service/collision absorber) marks a service vehicle that is active based on a signal from the driver, vehicle or back-end system.

The active service vehicle is continuously monitored by the Service Provider and it is checked at each position whether the vehicle is still carrying out work.

DENM Profile and used AMQP Application Headers​

The following table contains the used DENM profile for filling in the different service vehicle types and allowing application backends to distinguish between the different subtypes of service vehicles. The DENM profile is filled in using the TF2 documentation as a guideline. If C-ROADS does not describe a certain class of service vehicle, the 'best fitting' DENM profile and application header extension has been determined to keep compatibility with C-ROADS but also allow the additional functionalities that Mobilidata wants on top of the C-ROADS TF2 use-cases.

Sub Use CaseDENM
General service vehicle (non-specific)
  • Cause code: 26 (slow vehicle)
  • Sub cause code: 1 (slow moving maintenance vehicle)
  • StationType: "specialVehicles" (10)
  • InformationQuality: required, provided as specified in the BSP (RS_tcSpVe_145)
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
Tow service (takeldienst)
  • Cause code: 26 (slow vehicle)
  • Sub cause code: 1 (slow moving maintenance vehicle)
  • StationType: "specialVehicles" (10)
  • InformationQuality: required, provided as specified in the BSP (RS_tcSpVe_145)
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
  • Additional application header: custom-mobilidata-vehicleType: "towService"
Roadside assistance (pechverhelping)
  • Cause code: 26 (slow vehicle)
  • Sub cause code: 1 (slow moving maintenance vehicle)
  • StationType: "specialVehicles" (10)
  • InformationQuality: required, provided as specified in the BSP (RS_tcSpVe_145)
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
  • Additional application header: custom-mobilidata-vehicleType: "roadsideAssistance"
Traffic guard (weginspecteur)
  • Cause code: 26 (slow vehicle)
  • Sub cause code: 1 (slow moving maintenance vehicle)
  • StationType: "specialVehicles" (10)
  • InformationQuality: required, provided as specified in the BSP (RS_tcSpVe_145)
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
  • Additional application header: custom-mobilidata-vehicleType: "trafficGuard"
Gritter service (strooidienst)
  • Cause code: 26 (slow vehicle)
  • Sub cause code: 8 (salting vehicles)
  • StationType: "specialVehicles" (10)
  • InformationQuality: 6
  • EventPositionHeading: required
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
  • Additional application header: custom-mobilidata-vehicleType: "gritterService"
  • Application header serviceType: "RWW-WM"
Impact Attenuator (botsabsorbeerder / pijlwagen / locatiebeveiligingsvoertuig)
  • Cause code (TF2 doc): 3 (road works)
  • Sub cause code (TF2 doc): 3 (slow moving road maintenance vehicle)
  • StationType: "specialVehicles" (10)
  • InformationQuality: 6
  • EventPositionHeading: required
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
  • Additional application header: custom-mobilidata-vehicleType: "impactAttenuator"
  • Application header serviceType: "RWW-RM"
Mower (maaier)
  • Cause code (TF2 doc): 3 (road works)
  • Sub cause code (TF2 doc): 3 (slow moving road maintenance vehicle)
  • StationType: "specialVehicles" (10)
  • InformationQuality: 6
  • EventPositionHeading: required
  • RelevanceTrafficDirection: required
  • Traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4]
  • Additional application header: custom-mobilidata-vehicleType: "mower"
  • Application header serviceType: "RWW-RM"

Message Example​

UC 6 Message Example
{
    "shardId": "1",
    "latitude": "51.0726318",
    "quadTree": ",120202132003233122,1202021320032,",
    "causeCode": "3",
    "longitude": "4.3453512",
    "shardCount": "1",
    "messageType": "DENM",
    "publisherId": "BE00004",
    "serviceType": ",RWW-RM,",
    "subCauseCode": "3",
    "publicationId": "BE00004:DENM_ACTIVE_SERVICE_VEHICLE_02",
    "baselineVersion": "2.1.0",
    "protocolVersion": "DENM:1.3.1",
    "originatingCountry": "BE",
    "custom-mobilidata-useCase": ",6,",
    "custom-mobilidata-timestamp": "1737355796947",
    "custom-mobilidata-alertCCodes": "804",
    "custom-mobilidata-vehicleType": "impactAttenuator",
    "custom-mobilidata-publisherType": "PIP",
    "custom-mobilidata-baselineVersion": "1.0.0",
    "custom-mobilidata-dtapEnvironment": "production"
}
Tags:
Last updated on by Jasper De Keukelaere (imec)