Skip to main content

UC 28: iTLC: Time-to-green information advice - active road user (ARU)

Operation use case​

The iTLCs transmit phase information in the form of SPaT messages. We use this information to inform users how long they have to wait for the green light if the current status is red (time-to-green). This information is displayed in the app in a clear way and/or if possible with an audible signal when a headset is active.

Based on the ARU logic, 0, 1 or more possible connections across the intersection will be detected, which in turn can refer to 0, 1 or more different signal groups. We apply the following logic:

  • 0 possible connections: no information
  • 1 possible connection: TTG is shown of the connected signal group
  • 2 or more possible connections: if there is a connected signal group that is red, it will be displayed. We assume that this is the most relevant for the ARU road user who is more likely to continue driving at a green light than paying attention to the TTG of another signal group. If both signal groups are green or red, information is given on the smartphone.

If there is an exceptional reason for waiting time and this information is transmitted from the iTLC (e.g. priority for ambulance, closed railway crossing), this will be included as an additional element in the interface if the HMI offers space for it (possibly only visible on the smartphone).

Road user's point of view

  • the road user A is not at the intersection topology:
    • road user A does not receive a notification
  • The user is at the crossroads topology:
    • road user B is approaching a green light: the service provider app shows a traffic light shows no information
    • road user C is approaching a red light: the service provider app shows a traffic light that is red, with an indication of the time to green.

Data sources​

Road users affiliated with Service Providers

This use case applies to:

  • Any user who participates in traffic with the ARU app and is near an iTLC
  • Any active iTLC registered in TLEX whose MAP topology and SPAT messages are sent over the MI
  • Timings when the iTLC is in red phase
  • Historical profiling of the movements of the ARU users across the intersection (most used connection per arm per intersection)

Every position of a connected road user will be monitored and checked whether it is on the ingress of an active iTLC. If it is located on this and the current phase is red, the service provider will pass on the estimated time to green phase to the end users.

Crossroads topology

The iTLCs that are connected to the TLEX platform and are currently active must provide the intersection topology in the form of MAP messages. The minimum frequency at which this happens is defined in the IDD UDAP-FI specification v1.0.0. This topology should be a true representation of the topology on the street and should be updated as soon as the topology of the intersection changes and comply with the MAP specification 3.0.0.

Timing information from the iTLCs

The iTLCs that are connected to the TLEX platform and are currently active must provide the real-time timing information on the MI in the form of SPAT messages. These messages must be completed in accordance with the SPAT v2.3.0 specifications, as laid down in the Talking Traffic program. The frequency at which these are sent must also comply with the UDAP-FI v1.0.0 specifications as laid down in the Talking Traffic program.

By default, we use the 'likely time' from the SPaT message, which is optional in the spec. If this is not present, nothing will be communicated to the user.

If the iTLC provides the likely time, it must continue to do so, except in exceptional circumstances. In this way, we avoid undesirable behaviour being caused by switching between the likely time and the minEndTime.

Minimum Requirements

  • topology in TLEX that gives a true picture of reality
  • iTLC with "likely time" in the SPaT message

Data Processing (PIP)​

The SPaT data from the traffic lights is placed on the MI without any additional processing.

RUF​

No RUF applies.

MI & Historical Archive​

All SPaT and MAP messages will be available on the MI.

All SPaT and MAP are archived in the historical archive.

Service Provider Implementation​

The SP processes the MAP messages and takes into account the different types of road users that belong to the signal group. The SP should determine the most relevant signal group(s) on the basis of the EAP and end-user data. If the SPAT message contains a reason for the waiting time, it must also be filtered in terms of relevant signal group (reason waiting time only relevant for the signal groups that are red) and then whether or not it is forwarded to the end user.

Tags:
Last updated on by Wiggertsm