Skip to main content

UC 3: Priority vehicle warning

Operation use case​

In this use case, we alert road users to a priority vehicle (PV) that has flashing lights on.

It involves the following vehicle types:

  • ambulance
  • fire department
  • police
  • customs
  • emergency service vehicles (DOVO, Fluxys,...) The following traffic situations may occur where we alert road users.

(1) Driving priority vehicle (PV): notification is sent upstream.​

Alt text

Alt text Multiple situations possible:

On road with two opposite lanes (first figure above):

  • Message when approaching PV in the same direction of travel (and no traffic jam)
  • Message: warning PV (expected behavior: adapted speed and correct position on the road)
  • Message at approaching PV in same direction of travel and traffic jam
  • Message: warning PV (expected behavior: rescue lane)
  • Message when approaching PV in the opposite direction of travel - Distinction between congestion or no congestion not important here Message: warning PV (expected behavior: adjusted speed and correct position on the road) - Physical separations on the road are not considered On crosssing road (second figure above):
  • Message when approaching the crossing road (V1) and in 300 meter distance from either an approaching PV (PV1) or PV (PV2) which has already passed the crossing - Message: warning PV (expected behavior: adapted speed and correct position on the road) In the figure, vehicle 1, 2 and 3 will receive a message.

For all situations:

  • Time when DENM message is sent out = when vehicle drives priority and chooses when notification is shown to road user.

(2) Stationary priority vehicle (PV): notification is sent upstream​

The following definition of a stationary vehicle is used: vehicle shares its own status (if available in the data feed) or vehicle speed is < 5 km/h for a period of 60 seconds. Message is created by SP.

Notice:

  • Duplicate notification: accident warning vs. warning PV:
  • SP must make its own choice between the different notifications (this includes prio or duplication inter-events, inter-usecases)
  • In this case, both notifications are sent out from PIP. So merging or linking both notifications in DENM is not provided by the PIP!

Possible situation:

  • Notification when approaching stationary PV in the same direction of travel without physical separation
  • Message: warning PV (expected behavior: appropriate speed and proper place on the road)
  • We do not consider physical separation on the road when it is not plotted in the digital map

Again: Time when DENM message is sent out = when priority vehicle is detected as stationary and SP chooses when message is shown to road user.

(3) Transition between situations:​

From moving to stationary: PV must report that the vehicle is stationary or must have >= 60 seconds a speed below 5 km/h (0 km/h undesirable due to GPS drift) and active intervention status.

From stationary to moving: PV must report that the vehicle is stationary or must have >= 20 seconds a speed higher than 5 km/h and active intervention status.

Data sources​

Priority Vehicle Data Priority vehicle location and status information is generated by app or OEM equipment in the vehicle itself and via a serviceprovider as information message delivered to the PIP or MI-bus if the service provider has the full capability to do so. Whereas each vehicle can communicate directly with the service provider, a construction with a central hub as informationprovider is possible as well.
The role as informationprovider (front-end) as well as serviceprovider (back-end) can be combined by one supplying party.

The information, needed to create a complete MI bus ready message is minimal:

  • Position every two seconds with highest possible accuracy (HDOP < 5)
  • Timestamp GNSS receiver
  • Type of vehicle (fire, ambulance, police, etc)
  • Unique ID per trip
  • Speed
  • Intervention status (either lich beam and/or siren or data from incident management system) If the dataset is not complete, there will be no message creation. The interval of sending the available message data is once per second if moving prioritized, if the vehicle is standing, once per ten seconds is allowed.

Sometimes multiple emergency services are on their way, PIP sends out multiple messages. SP must make its own choice regarding mutual priority. Route information from PV (known/not known) will have no impact on implementation. So we do not take route choice into account.

Data processing (PIP)​

Dataflow:

  • SP connects with emergency service vehicles
  • Service provider with connected emergency service zones and police zones receives info from PV
  • A DENM message is then created by the SP.
  • Through the Feedback Channel, DENM messages are published on the MI, which then enter the PIP.
  • PIP processes DENM messages and SP checks whether PV is stationary or not and applies the desired cause code.

Specific example:

  • Ambulance is driving with appropriate active location- and status-data generating equipment. Sending at least every second if prioritized.
  • SP receives positions in and priority status in its own format.
  • Then SP platform sends out a DENM message for each position: prio emergency vehicle approaching.
  • Then SP will follow up whether PV is stationary or not.
  • Once PV brakes and is stationary longer than 60 seconds, the DENM message changes and SP sends out DENM message for warning stationary PV with cause codes as described below.

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

  • All road types possible
  • Update frequency: condition: min. 1 position per second containing necessary info.

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

  • Are protocols respected? Incorrect messages are filtered out.
  • Is all necessary info present? Incomplete messages are filtered out.
  • Is the format correct? Messages in incorrect format are not used.
  • Is the message not too old? Messages that are too old (older than 2 seconds) are filtered out.

The following checks are not implemented:

  • additional content checks: data source is leading is considered the truth.
  • There is no RUF, so we cannot test the reports.

The DENM messages published on the MI are read by the SP by subscribing to the correct AMQP feed (see next paragraph).

RUF and sourcing​

Not applicable.

MI & Historical archive​

DENM information​

The resulting DENM messages contain no 'eventHistory' or relevance traces, because of the unknown direction of the emergency vehicle. The LocationContainer will however as much as possible awareness traces, whereas all up- and downstream roads (with a maximum of 7) within reach of 300 meters are defined. Be aware, that a trace for a side road is starting at the reference point (vehicle) as well. There is no distinguish in direction of the reference, traces are taken as bi-directional with no-respect to drawing direction. In the example given below, the blue lines represent the awareness zones. If a notifiable vehicle is within the wareness zone, it shall receive the appointed message.

Alt text

Cause and sub cause codes are:

CausecodeDescriptionSubcausecodeDescription
15rescueAndRecoveryWorkInProgress0unavailable
1emergencyVehicles
3policeActivityOngoing
4medicalEmergencyOngoing
95emergencyVehicleApproaching0unavailable
1emergency vehicle approaching
2prioritized vehicle approaching

DENM messages by position and priority vehicle:

  • DENM driving PV
  • We follow the DENM interpretation as use case HLN-EVA in C-ROADS 2.0
  • If we cannot represent 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
  • Here we follow the DENM interpretation as use case HLN-EVI in C-ROADS 2.0
  • If we cannot represent 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​

A service provider will show this (emergency) type of messages with the highest priority to the end-user. In the case of multiple events, posted on the MI-bus at the same location, this will be shown on top. How the mesage is presented to the end-user, is the responsibility of the serviceprovider. Other priority in events or use-cases is free to determine by the serviceprovider.

SP connects with various emergency response zones and police zones. They can publish DENM messages through the Feedback Channel on MI, which then reach the PIP.

SPs receive information about PV through MI using DENM messages.

SP sends notification with warning of PV to road users.

DENM Profile and used AMQP Application Headers​

The following table contains the used DENM profile for filling in the different emergency vehicle types and allowing application backends to distinguish between the different subtypes of emergency 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 moving emergency vehicle (non-specific)
  • cause code: 95
  • sub cause code: 0 or 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • additional application header: custom-mobilidata-vehicleType => not included for this sub use-case
  • application header serviceType: "HLN-EVA"
Moving ambulance
  • cause code: 95
  • sub cause code: 0 or 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP (RS_tcSpVe_145)
  • relevanceTrafficDirection: required
  • additional application header: custom-mobilidata-vehicleType: "ambulance"
  • application header serviceType: "HLN-EVA"
Moving fire brigade
  • cause code: 95
  • sub cause code: 0 or 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • additional application header: custom-mobilidata-vehicleType: "fireBrigade"
  • application header serviceType: "HLN-EVA"
Moving police
  • cause code: 95
  • sub cause code: 0 or 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • additional application header: custom-mobilidata-vehicleType: "police"
  • application header serviceType: "HLN-EVA"
Moving customs (douane)
  • cause code: 95
  • sub cause code: 0 or 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • additional application header: custom-mobilidata-vehicleType: "customs"
  • application header serviceType: "HLN-EVA"
General stationary emergency vehicle (non-specific)
  • cause code: 15
  • sub cause code: 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4].
  • additional application header: custom-mobilidata-vehicleType: not included for this sub use-case
  • application header serviceType: "HLN-EVI"
Stationary ambulance
  • cause code: 15
  • sub cause code: 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4].
  • additional application header: custom-mobilidata-vehicleType: "ambulance"
  • application header serviceType: "HLN-EVI"
Stationary fire brigade
  • cause code: 15
  • sub cause code: 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4].
  • additional application header: custom-mobilidata-vehicleType: "fireBrigade"
  • application header serviceType: "HLN-EVI"
Stationary police
  • cause code: 15
  • sub cause code: 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4].
  • additional application header: custom-mobilidata-vehicleType: "police"
  • application header serviceType: "HLN-EVI"
Stationary customs (douane)
  • cause code: 15
  • sub cause code: 1
  • stationType: "specialVehicles" (10)
  • informationQuality: required, provided as specified in the BSP
  • relevanceTrafficDirection: required
  • traces: shall be provided as specified in C-Roads, C-ITS Message Profiles [4].
  • additional application header: custom-mobilidata-vehicleType: "customs"
  • application header serviceType: "HLN-EVI"

Message example​

UC 3 Message Example
{
    "shardId": "1",
    "latitude": "51.068151",
    "quadTree": ",120202123030001103,1202021230300,",
    "causeCode": "95",
    "longitude": "3.7100258",
    "shardCount": "1",
    "messageType": "DENM",
    "publisherId": "BE00004",
    "serviceType": ",HLN-EVA,",
    "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": "1737355771578",
    "custom-mobilidata-alertCCodes": "1707",
    "custom-mobilidata-vehicleType": "ambulance",
    "custom-mobilidata-publisherType": "PIP",
    "custom-mobilidata-baselineVersion": "1.0.0",
    "custom-mobilidata-dtapEnvironment": "production"
}
Tags:
Last updated on by Jasper De Keukelaere (imec)