Skip to main content

UC 17: iTLC Prioritising vehicle convoy

Operation use case​

The use case facilitates that a group of vehicles, a convoy, can drive through the green in 1 go. The formation of the convoy is done intentionally by activating the convoy mode, for a specific convoy a pre-arranged convoy ID can optionally be set. A random group of vehicles that are guided through the green light together by an iTLC, without taking any action to do so, falls under use case optimization.

The updated CROW functional standard is leading in the elaboration of this use case.

In the convoy, at least the first and last participant must make themselves known to the service provider. Based on the route entered, the service provider will request priority (SRM message) for each individual vehicle on the relevant connection, the optional convoy ID will be added to the priority request.

The iTLC can then answer the SRM requests of the convoy participants with granted, confirming that all vehicles will be able to drive through the green (regardless of whether the current position of the relevant signal group is already green or red). After granted, the green phase for the convoy can only be interrupted when a conflicting priority request with a higher class is handled (or other practical limitations within the iTLC regulation e.g. maxPresence, maxLength, convoy lock timeout, bridge open, tunnel closed, railway crossing, etc.). In this case, the iTLC will reject every SRM request.

The convoy priority is active for one trip and must be reactivated at the start of each new trip. The service provider is responsible for deactivating the convoy priority after a period of inactivity (e.g. using a timer). The convoy mode (and convoy ID) should never be hardcoded, but should be configurable by the end user. Ideally, a new convoy ID will be used for each trip.

Any active road user who wishes to request priority as a participant in a convoy must be individually equipped and authorised to do so (the conditions for this are determined in Working Group 4)

Vehicle Viewpoint

Via the end-user application of a service provider, the authorized convoy participants will activate the convoy mode and set a convoy ID of their choice, the convoy participants must also indicate their route.

If the convoy is given priority by the iTLC, the participants of the convoy will all be able to drive past the intersection in 1 green phase, unless the convoy priority is interrupted by a vehicle with a higher priority (or other practical restrictions within the iTLC regulation e.g. maxPresence, maxLength, convoy lock timeout, bridge open, tunnel closed, railway crossing, etc.)

If desired, the service provider can provide feedback on the status of the priority request to each participant in the convoy.

Other road users' point of view

If a convoy priority is active at the intersection, the iTLC will provide a reason for (extra) waiting time in the SPaT messages. This reason can be mentioned in end-user applications if desired.

The figure below outlines the operation of the convoy use case. In the example, trucks are used, but the convoy usecase modality is independent.

Data sources​

Track & Trace convoy participants​

The following data from the convoy vehicles is at least necessary for a qualitative implementation of this use case:

  • Position
    • minimum 1 position/sec
    • highest possible accuracy: HDOP < 5 or 95% position confidence ellipse in centimeters
  • Timestamp GNSS receiver
  • Speed
  • Planned route as WGS84 linestring, to be able to make priority request at the correct connection.
  • convoy ID (max 63 characters)

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 convoy use case

Service Provider​

  • Connects, authenticates and authorizes priority convoy vehicles
  • Creates priority request (SRM) and positional data (CAM) messages from all convoy vehicles
    • Based on the route entered, the ETA to iTLCs is calculated in accordance with the regulations of CROW Dutch Profile
    • SRM: subRole = requestSubRole11(platoon)
    • SRM: routeName = convoy ID (max 63 characters)
  • checks the priority requests in the TrafficLightPriority Validator
  • sends the validated priority requests to the Mobilidata Interchange (and thus to TLEX)
    • When a convoy vehicle is within the MAP area of the iTLC, the service provider sends CAM messages with a frequency of 1Hz.
    • When the ETA (optimal travel time) from the convoy vehicle to the intersection drops below 90sec, priority requests (SRM) are regularly updated and resent to the interchange.
  • 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)

RUF​

Not applicable to this use case.

MI & Historical Archive​

The following data streams run over the MI:​

  • Validated SRM messages by the Service Provider
  • SSM messages from the iTLC and Priority Agent
  • MAP and SPaT messages from the iTLC
  • CAM messages from convoy participants

SPaT, MAP will be archived after conversion.

SRM, CAM and SSM messages contain location data of convoy vehicles that can be linked to individuals. 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 convoy use case according to CROW spec in approval process.

Tags:
Last updated on by Wiggertsm