Skip to main content

UC 18: iTLC Prioritising truck

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 trucks. Depending on their position, direction and type of freight, these trucks can request priority from the iTLCs connected to the Mobilidata Traffic Light Exchange. If priority is granted, the iTLC will give the relevant signal group for the truck a faster/longer green light so that the truck will pass the intersection more smoothly. The rules that iTLC follows to decide whether or not to adjust the phase control are determined by the algorithm of the iTLC supplier and the priority level that the road authority assigns to the truck.

Trucks that want to request priority must indicate their route so that priority for the correct connection can be requested automatically.

Truck's point of view

  • The truck is connected to the service provider (via a backend to backend connection or via app)
    • Positions and the route of the truck are shared with the service provider
  • The Service Provider tracks the truck, calculates the ETA to each iTLC based on the route entered
    • When the ETA of the truck to the iTLC falls below 2 minutes (configurable by the service provider per region/tlc/intersection, max 5min), the service provider will automatically send priority requests to the iTLC, for the phase group that the truck will use according to the specified route. In the case of complex iTLCs with partial intersections, priority is only requested for the 1st connection in the direction of travel of the vehicle.
  • The iTLC evaluates the priority request:
    • Based on the regulations in force, 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 truck. The choice of whether or not to do this lies with the developer of the application or backend to backend system
  • Once the truck has crossed the stop line, the priority request is cancelled and the iTLC returns to its normal regime.

Other road users' point of view

If a truck is given priority, the service provider has the option to give the conflicting traffic a warning that indicates 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 for trucks, 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 truck (regular truck, special transport, dangerous goods, overweight) which is later mapped to the correct role and subrole combination
  • Planned route as WGS84 linestring, to be able to make priority request to the correct signal group.
  • 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)​

PIP​

The PIP has no function in this priority use case

iTLC package​

  • receives the priority requests (SRM) and positional data (CAM) of the truck (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 trucks (linked via service provider)

TLEX​

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

Service Provider​

  • Connects, authenticates and authorises priority vehicles
  • Creates priority request (SRM) and positional data (CAM) messages from the truck
    • Based on the route entered, the ETA to iTLCs is calculated in accordance with 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, 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.

RUF​

Not applicable

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 truck

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 & 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. 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 truck's route. For any iTLC whose ETA of the truck is less than 2 minutes (configurable, max 5min), 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 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. The SP regularly calculates a new ETA and sends it in an SRM message to the TLC, to which the TLC replies with an SSM message.

  4. 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.

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

Tags:
Last updated on by Wiggertsm