UC 15: iTLC Priority emergency vehicle

Operation use case

The following blueprint has been developed to formulate a clear and human-readable description of the use case. In terms of operation, the applicable standard published on CROW is leading.

A service provider connects a fleet of emergency vehicles. Depending on their position, direction of travel and status (active intervention or not), these vehicles can request priority from the iTLCs connected to the Mobilidata Traffic Light Exchange. If priority is given, the iTLC will give a faster/longer green light for the emergency service vehicle so that the vehicle can pass as smoothly as possible.

Emergency vehicles that wish to request priority should ideally make their route known (not mandatory). Based on the route, the arrival of the emergency service vehicle can be reported to the iTLC sufficiently in advance and the chance that priority can be granted increases and/or less disruption is caused to non-crossing traffic.

Position of emergency services

• The emergency vehicle is connected to the service provider

  • Positions of the emergency vehicle are shared with the service provider
  • Optionally, the route of the emergency vehicle is shared with the service provider

• The Service Provider tracks the vehicle

  • When an emergency vehicle enters the MAP topology of the iTLC and no route is known, the service provider automatically starts sending priority requests .
  • If the route is known, the service provider calculates the ETA to each iTLC and priority requests can be made a little earlier. Currently, priority requests are sent if the ETA to iTLC falls below 2 minutes (configurable by service provider per region/tlc/intersection, max 5 min). In the case of complex iTLCs with partial intersections, priority is only requested for the 1st connection in the direction of travel of the emergency service vehicle.

• The iTLC evaluates the priority request

  • Based on the regulations, the application will be accepted or rejected. Upon acceptance, the iTLC regulation will be adjusted in favor of the emergency service vehicle, taking into account the preconditions imposed on the phase control of the iTLC.

• It is possible to link the priority status (acceptance or refusal) back to the driver of the emergency vehicle. The choice of whether or not to do this lies with the developer of the application or backend to backend system

• Once the emergency vehicle has crossed the stop line, the priority request is cancelled and the iTLC resumes its normal regime.

Other road users' point of view

If priority is given to an emergency vehicle, the service provider has the option to issue a warning to the conflicting traffic indicating the reason why the traffic light is red faster or longer.

Data sources

Track & trace system for emergency vehicles

When working with the track & trace system of the emergency services party, the following data elements must be supplied at a minimum:

• Position every second with the highest possible accuracy (HDOP < 5 or 95% position confidence ellipse in centimeters)
• Timestamp GNSS receiver
• Speed
• Type of vehicle (ambulance, fire brigade, etc.) that is later mapped to the correct role and subrole combination
• Priority status: priority trip or no priority trip
  • can be done on the basis of the status of the light bar and/or siren or other information or agreements from which it can be deduced whether the vehicle is making an intervention in which priority must be requested or not.
• Planned route as WGS84 linestring (optional)
• Unique ID per trip (preferred, not strictly necessary if the correct data processing agreements are made)

Priority Configuration

The Priority Configurator of the iTLCs on the route must have a valid priority configuration in order to be able to respond to priority requests.

Crossroads topology

There must be an intersection topology in ETSI MAP format in which the lanes and/or tracks are present. This is in accordance with the Dutch Profile 3.0.0.

Data processing

PIP

The PIP has no function in this priority use case.

iTLC package

• receives the priority requests (SRM) and positional data (CAM) of the emergency service vehicle (linked via service provider), via TLEX
• assesses the application and adjusts the traffic light scheme if necessary
• responds to the priority request with an SSM message that shows the status of the traffic light (adjusted or not) via TLEX to the emergency vehicles (linked via service provider)

TLEX

• is responsible for delivering and routing:
  • SRM and CAM messages from emergency vehicle (via MI) to the iTLC package
  • SSM messages from iTLC package to emergency service vehicle (via MI)

Service Provider

• Connects, authenticates and authorises priority vehicles
• Creates priority request (SRM) and positional data (CAM) messages from the emergency vehicle
  • If route is known, ETA to iTLCs will be calculated according to the regulations of CROW Dutch Profile
• checks the priority requests in the TrafficLightPriority Validator
• sends the validated priority requests to the Mobilidata Interchange (and thus to TLEX)
  • The priority requests are regularly updated and resent to the interchange.
  • When the priority vehicle is within the MAP area of the iTLC, the service provider sends CAM messages with a frequency of 1Hz.
• provides the status of the priority request (however, the choice to share this status with the end user or not always lies with the developer of the application or backend to backend system)

TrafficLightPriority Validator

The priority validator (managed by the service provider) retrieves all priority rules set by the road authority. These contain a set of parameters that must be met in order to be allowed to request priority, including the priority level at which a particular vehicle can request priority. When approaching an iTLC and starting a priority flow, the priority validator will check the current characteristics of the vehicle (e.g. id, approach, connection, vehicle type, etc.) and determine at what level the vehicle may request priority. If no rule is sufficient, the service provider will fall back on an SRM-0 message without priority. If a certain rule is met, the corresponding priority level will be entered in the priority requests (SRM) that have been sent. These are then put on the MI and forwarded to the priority agent.

TrafficLightPriority Agent

The Traffic Light Priority Agent acts as a gateway in the Mobilidata ecosystem. This component receives the SRM requests from all service providers in the ecosystem and will check them for correctness. To do this, the agent will evaluate the set priority rules against the information available in the SRM. If the agent notices that the priority level entered by the service provider does not comply with the rules, the priority agent will create an SSM message with status rejected and publish it on the interchange, so that the service provider immediately notices that its request has been rejected. The agent also keeps a log of the number of incorrect requests per service provider in the ecosystem in order to detect underperforming service providers. In addition, the agent will also do a technical validation of the incoming SRM messages (correct protocol version, mandatory fields filled in, etc.)

TrafficLightPriority Configurator

The Traffic Light Priority Configurator consists of two components: the input tool for road authorities to define priority rules at his or her intersections which is an integral part of the Traffic Light Exchange platform https://priority-portal.interchange.mobilidata.vlaanderen.be, as well as an API on which these configured rules are made available to all service providers and the priority agent. The road authority can use this component to set which parameters must be met in order to be able to request priority with a certain level. The set of parameters that can be set as a road authority are fixed in the official priority broker configurator specifications which are laid down in the Mobilidata/Talking Traffic program.

MI & Historical Archive

High level architecture

The following flows run through the MI:

• Validated SRM messages by the Service Provider
• SSM messages from the iTLC and Priority Agent
• MAP messages from the iTLC
• CAM messages from the emergency vehicle

SRM, CAM and SSM messages contain location data of priority vehicles that can be linked to people. These messages are not (for the time being) stored in the historical archive.

MI headers

SREM

{
  "messageType": "SREM",
  "originatingCountry": "BE",
  "protocolVersion": "SREM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:SREM_PV_02",
  "publisherType": "Priority Validator",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

SSEM

{
  "messageType": "SSEM",
  "originatingCountry": "BE",
  "protocolVersion": "SSEM:1.3.1",
  "publisherId": "BE00004",
  "publicationId": "BE00004:SSEM_PV_02",
  "publisherType": "Priority Validator",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

Service Provider Implementation

The Service Provider is responsible for executing the priority use case in accordance with the technical standard described in the Dutch Profiles version 3.0.0 (post-consolidation). We refer to the following page: CROW. TLEX, iTLC package and the priority configurator must also comply with this standard.

We briefly review the most important elements in the step-by-step plan below.

1. If route known: Calculate ETA. For each new position it obtains from the priority vehicle, SP calculates the ETA (Estimated Time of Arrival) to the iTLCs on the route of the emergency service vehicle. For any iTLC whose ETA of the emergency vehicle is less than 2 minutes (configurable, max 5min), a priority request will be initiated.
   If no route is known: SP tracks the truck. When the truck is within the MAP topology of an iTLC, a priority request is initiated.

2. Priority request checking. In a second step, the Priority Validator checks the priority rules for the intersection and signal group where priority is requested. This takes into account all vehicle characteristics that are also used in the priority rules. How the Priority Validator works and how it uses the Priority Configurator. If the vehicle complies with the rules, step 3 will be taken. If this is not the case, no priority will be requested. The road user will not be informed of this.

3. Start of the priority request. The priority request is then initiated by creating and sending an initial SRM message via the mobilidata interchange and priority agent to TLEX, fully according to the specifications. The TLC from the iTLC package checks the request and returns a response via an SSM message. The different possible answers are listed in the SSM standard.

   1. Update of the priority request. If the route is known, the SP regularly calculates a new ETA and sends it in an SRM message to the TLC, to which the TLC replies again with an SSM message.

   2. increased frequency and CAM messages in the MAP area. When the priority vehicle has reached the MAP area of the iTLC, we create CAM messages that are sent to the iTLC at a frequency of 1Hz via TLEX.

4. Canceling a priority request. If the emergency vehicle has crossed the stop line or deviates from its route at the traffic light, the CSP creates a cancellation SRM. This is a special type of SRM, whichxs informs the iTLC that the priority request has been aborted.