Skip to main content

UC 26: iTLC Prioritising convoy - active road user (ARU)

Operation use case​

The use case facilitates that a group of active road users (cyclists and pedestrians), an ARU convoy, can cycle or walk through green in 1 go. The formation of the convoy is intentional and is done on the basis of a pre-agreed (mandatory to enter) convoy ID. A random group of active road users who are guided through green together by an iTLC, without taking any action to do so, falls under use case .

This use case is based on the updated CROW functional standard ( pending at the CAB) which is deviated from, if necessary, in order for the use case to succeed for ARUs.

In the convoy, at least the first and last participant must identify themselves to the service provider on the basis of an identical convoy ID. Based on the route entered and the type of ARU user (pedestrian or cyclist), the service provider will request priority (SRM1 message) for each individual convoy participant on the relevant connection(s), the convoy ID will be added to this priority request. The type of ARU user is necessary to apply for priority on the correct connection: pedestrians ask for priority on pedestrian lights, cyclists ask for priority on bicycle traffic lights. If there are no traffic lights for cyclists, priority is requested at the 'normal' traffic lights on the road.

The iTLC can then answer the SRM1 requests of the convoy participants with granted, confirming that all active road users will be able to cycle or walk 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 ride or walk and must be reactivated at the start of each new ride or walk. The service provider is responsible for deactivating the convoy priority after a period of inactivity. The convoy ID should never be hardcoded and should be configurable by the end user, ideally a new convoy ID should be used for each trip.

Any active road user who wishes to request priority as a participant in a convoy (at least first and last participant of the convoy) must be individually equipped and authorised to do so (the conditions for this are determined in working group 4).

A pedestrian or cyclist may cross an intersection via multiple connections, as illustrated in the figure below. In that case, the service provider will send multiple priority requests (incl. convoy ID) for different connections of the same intersection, based on the planned route. It is then up to the iTLC to assess how the phase control can be optimized to guide the convoy safely over the various connections.

ARU viewpoint

Via the end-user application of a service provider, the authorized active road users of the convoy will have to set up a convoy ID of their choice and make their route and type of ARU known. If the convoy priority has been assigned by the iTLC, the ARU convoy participants will be able to cross the intersection together in 1 green phase, unless the convoy priority is interrupted by a vehicle with a higher priority (or other practical limitations 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 pedestrian or cyclist 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.

Data sources​

Track & Trace ARU convoy participants​

The following data from the ARU convoy participants 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 is uploaded as a GPX file with enough detail to match the right connections for the priority requests.
  • convoy ID (max 63 characters)
  • Type of ARU convoy: pedestrians or cyclists

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

Service Provider

  • connects, authenticates and authorizes priority ARU convoy participants

  • Creates priority request (SRM) and positional data (CAM) messages from all ARU convoy participants

    • Based on the route entered, the ETA to iTLCs is calculated in accordance with the regulations of CROW Dutch Profile

    • SRM1: 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)

    • The priority requests are regularly updated and resent to the interchange.
    • When the ARU convoy of participants 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)

RUF​

Not applicable.

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 ARU convoy participants

SPaT, MAP will be archived after conversion.

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

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