The Greenwave project is attempting to create an app which can indicate to drivers when the upcoming traffic lights will change. To do this requires innovation in four key areas, summarised below:
1) Intercepting and translating the detector/traffic lights (signal) conversation.
The SCOOT messages sent between the detector loops, in-station server and traffic lights (signals) are internally generated, and not designed to be understood in other ways. The innovation is to tap into these messages, understand what they mean, and represent the messages in other formats (in this case via an app for driver use).
Tapping into these messages could happen in two location, and we’ll explore both to see which works best:
- At the server/in-station
- At the roadside traffic signal controller
Translation/interpretation of internal SCOOT messages. Understanding the raw language the detectors, traffic lights and in-station use to talk to each other for SCOOT, and which bits are needed for the app to work.
Latency/delay. Tapping into this conversation at the server (in-station) provides data from all traffic signal controllers in one location. But, the time it takes for the data to be sent and received between the in-station, and the detector loops and traffic signals out on the street could mean the data isn’t accurate enough for drivers to take timely action.
Consistency/interoperability. Accessing the data directly from the traffic signal controller boxes out on street would overcome the delay issue, but requires a few other things to be solved:
- being able to get the same data from all different models/makes of traffic signal controller. All are designed to support SCOOT, but none are currently designed to enable tapping into source data directly.
This is important in scalability of this project as local authorities will have a mixture of models/makes of traffic signal controllers on their network.
2) Accommodating predictions and priority requests
As the detectors, traffic lights (signals) and in-station talk to each other, through SCOOT, they perform predictions about when traffic detected over the loop will reach the lights. These predictions report the live and variable traffic flows. They also need to accommodate specific ‘requests for priority’, built in to SCOOT as programmable options for:
- pedestrian crossings
- Bus priority
The app needs to be able to accommodate the live adjustments to signal timings in the information it gives drivers.
3) App to predict and report the vehicles’ position
The app needs to be able to chat with the in-station/server to report its location, and learn of the next upcoming set of traffic signals.
It needs to know its location in relation to the next set of traffic lights, it’s likely arrival time at the lights, and correlate that with the traffic signal phase and timing, which is constantly adapting to live traffic flow conditions and any priority requests…….
The idea is that the driver sees / hears an indication of when the upcoming set of lights are due to change.
Yeah, complicated 🙂
4) The app is able to send a priority request
Where the app, or vehicle it is in, is able to send a request for priority to the upcoming signals.
This is likely to be of most value at key locations on strategic routes.
Target audience is likely to be repeat/regular use of specific routes, such as daily deliveries to depots/manufacturers.