Skip to main content

UC 24: Priority vehicle warning - active road user (ARU)

Operation use case

The purpose of these use cases is to inform active road users in time of a nearby emergency vehicle that has flashing lights on. Because of the fact that it is not possible to reliably map match ARUs on the correct road section (next to the cars, elevated/separate bicycle and pedestrian path) because the information is missing in the digital map, we use a radius of 100 meters in which the ARU road users are warned. We report both for a stationary emergency vehicle and a moving emergency service vehicle with a speed > 5 km/h.

These are the following vehicle types:

  • ambulance
  • fire brigade
  • police
  • other emergency vehicles (DOVO, Fluxys,..)

The following traffic situations may occur, in which case we warn road users.

Vehicle Viewpoint

The vehicle shares its position information that warns ARU road users. For example, ARUs receive a notification when the vehicle is nearby. We refer to UC3 here for further explanation.

ARU viewpoints

Notifications received when an emergency vehicle comes within the radius of 100 meters .

Data sources

Priority Vehicle Data

At a minimum, we need:

  • Position every two seconds with the highest possible accuracy (HDOP < 5)
  • Timestamp GNSS receiver
  • Type of vehicle (fire brigade, ambulance, police, etc)
  • Unique ID per trip
  • Speed
  • Intervention status (either light bar and/or siren or data from incident management system)

Sometimes several emergency services are on the way, PIP sends out multiple notifications. SP has to make its own choice with regard to mutual priority.

Route information from PV (known/unknown) will have no impact on the implementation. So we don't take the route choice into account.

Data Processing (PIP)

1. Create an event

  • SP connects with emergency vehicles
  • Service provider with connected emergency zones and police zones receives information from emergency vehicle
  • Then a DENM message is created by the SP.
  • Through the Feedback Channel, DENM messages are published on the MI, which then end up in the PIP.
  • PIP processes DENM messages and SP checks whether PV is driving and applies the appropriate cause code.

2. Follow-up and cancellation of the event

  • Ambulance is running and the priority function is active.
  • SP gets positions and priority status in its own format.
  • After that, the SP platform sends out a DENM message for each position: prio emergency vehicle approaching.
  • Subsequently, SP will monitor whether or not PV is standing still.
  • As soon as PV reports that it is stationary or has been stationary for more than 60 seconds, the message is adjusted to the stationary variant.

Specific conditions under which DENM messages of priority vehicles can be published on the MI:

  • Update frequency: condition: min. 1 position per second that contains the necessary info.

When no more positions are received or the vehicle is stationary for 60 seconds, the message is stopped.

3. Quality Control

Quality control by PIP of DENM messages. The following checks are implemented:

  • Are the protocols respected? Incorrect messages are filtered out.
  • 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 following checks are not implemented:

  • Extra content checks: data source is leading and is seen as the truth.
  • There's no RUF, so we can't check the notifications.

The DENM messages published on the MI are read by the SP by subscribing to the correct AMQP feed.

RUF

No RUF applies due to the highly dynamic nature of the notification.

MI & Historical Archive

The following data streams run over the MI:

DENM messages per position and per priority vehicle:

  • DENM driving PV
    • We follow the DENM interpretation such as use-case HLN-EVA in C-ROADS 2.0
    • If we are unable to show sufficient granularity of the approaching emergency vehicle using subcause codes, an application property will be added to the Mobilidata Interface to support it
  • DENM Stationary PV
    • We follow the DENM interpretation such as the use case HLN-EVI in C-ROADS 2.0
    • If we are unable to show sufficient granularity of the approaching emergency vehicle using subcause codes, an application property will be added to the Mobilidata Interface to support it

MI Headers

Capability descriptor:

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

Historical archive

The priority vehicle DENM messages are not stored in the historical archive due to privacy rules.

Service Provider Implementation

SP connects with various emergency zones and police zones. SP can publish messages via the feedback channel on the MI DENM, which then end up with the PIP.
SPs receive information about PV via MI using DENM messages.
SP sends notification with warning of PV to road users.

Message example

UC 24 Message Example
{
"shardId": "1",
"latitude": "51.0679871",
"quadTree": ",120202123030001103,",
"causeCode": "15",
"longitude": "3.7106251",
"shardCount": "1",
"messageType": "DENM",
"publisherId": "BE00004",
"serviceType": ",HLN-EVI,",
"subCauseCode": "1",
"publicationId": "BE00004:DENM_EMERGENCY_SERVICES_ALERTING_02",
"baselineVersion": "2.1.0",
"protocolVersion": "DENM:1.3.1",
"originatingCountry": "BE",
"custom-mobilidata-useCase": ",3,7,24,",
"custom-mobilidata-timestamp": "1737131653528",
"custom-mobilidata-alertCCodes": "1706",
"custom-mobilidata-vehicleType": "fireBrigade",
"custom-mobilidata-publisherType": "PIP",
"custom-mobilidata-baselineVersion": "1.0.0",
"custom-mobilidata-dtapEnvironment": "production"
}