Skip to main content

UC 19: iTLC Traffic signal optimization

Operation use case​

Purpose

The purpose of this use case is to optimize traffic flow at a light-controlled intersection. The goal is to maximize traffic flow and minimize unnecessary waiting, queue length, etc., using an optimization algorithm that takes into account the real-time traffic intensities at the intersection to optimize the phase control of the iTLC.

The implementation of the optimisation algorithm is the responsibility of the ITS application that controls the control within the iTLC package. The algorithm will use vehicle locations and expected routes provided by service providers connected to the Mobilidata ecosystem. The rules that iTLC follows when optimising the phase control are determined by the algorithm of the iTLC supplier and the priority level that the road authority assigns to the various road users.

Road user's point of view

  • An individual road user is connected to the service provider
    • Positions of the vehicle are shared with the service provider
    • Optionally, the route of the vehicle is shared with the service provider
  • The Service Provider tracks the vehicle
    • When a vehicle enters the MAP topology of the iTLC, the service provider will transmit the exact location of the vehicle (CAM, every second) to the relevant iTLC.
    • If the route is known, the service provider calculates the ETA to each iTLC and CAM messages and an SRM-0 message can be sent to the iTLC a little earlier. Messages are sent from the ETA until iTLC falls below 2 minutes (configurable by the service provider per region/tlc/intersection, max 5min).
  • The iTLC processes the location data and priority requests. Based on the rules in the algorithm, the phase control may or may not be adjusted/optimized.
  • The road user himself will not be informed of any optimisations of the iTLC, but (if it works properly) will on average get green faster/longer and will have to wait less time at red lights.

Data sources​

Road users connected to service providers

  • Location data of the road user with
    • 1Hz frequency
    • time GNSS receiver
    • highest possible accuracy: HDOP < 5 or 95% position confidence ellipse in centimeters
  • Speed
  • Heading
  • Planned route as WGS84 linestring (optional)

Crossroads topology

An intersection topology must be present in ETSI MAP format of each active iTLC. The MAP contains a true representation of the lanes and/or tracks of the intersection. This is in accordance with the Dutch Profile 3.0.0.

Data Processing (PIP)​

No intervention of the PIP for this use case.

RUF​

Not applicable for this use case.

MI & Historical Archive​

The following data streams run over the MI:

  • CAM (Cooperative Awareness Message)
    • in accordance with the Dutch Profile CAM specifications D3046-5 / Version 3.0.0, available on crow.
  • SRM-0
  • FOLDER

CAM and SRM-0 messages contain location data that can be linked to individuals. These messages are not (for the time being) stored in the historical archive. MAP messages do not contain any personal information and can be stored in the historical archive.

MI header​

{
  "messageType": "CAM",
  "originatingCountry": "BE",
  "protocolVersion": "CAM:1.4.1",
  "publisherId": "BE00005",
  "publicationId": "BE00005:CAM_02",
  "custom-mobilidata-dtapEnvironment": "production",
  "quadTree": [
  ]
}

Service Provider Implementation​

No specific presentation is required. The proces is runnig in the background.

Tags:
Last updated on by Wiggertsm