It is widely known that there are two main problems in Russia: fools and roads. If we try to reverse-approach them, we get smart traffic lights, which is one way of addressing these perennial dilemmas. Smart traffic lights is a very popular expression: only in 2017, it appeared in many an article heading, for example: ‘Smart Traffic Lights to Become a Bane of Russian Drivers’ Existence’, ‘A Smart Traffic Light Is Good but a Reliable Police Officer Is Better’, and ‘Russian Inventors Come Up with a Smart Traffic Light Controlled from iPhone’ to name but a few.
All these headings attest to quite a vague interpretation of the term. And that is often abused with the aim of attracting collective attention and promoting third-rate solutions. This, in its turn, leads to nothing more than engendering negative attitudes amongst the public, who starts to look down on ‘intelligent’ technologies like this one. In the meantime, the majority of journalists talk of smart traffic lights only in name and seem to not have a clue as to what the technology really is.
I myself am very wary of this term. ‘Smart’ is more of a quality that pertains to a living organism, not a machine. But because our company has long been working on traffic lights with complex ‘stuffing’, I’ve attempted to find an optimal definition of what makes a traffic light smart, and I’ll explain it on the example of our peripheral traffic light controller ‘SPEKTR-2’.
Active directional control in place of phases
What we are most accustomed to in Russia is a phase-based traffic light control model, which implies that there is a sequential flow of states (traffic light cycles), which alternate on loop. Each state is called a traffic signal control phase. The common practice is to link these phases with several movement maneuvers that are independent from one another and responsible for permitting or forbidding the traffic movement in a whole set of basic trajectories simultaneously. Before, when the controlling equipment could only boast very modest computational abilities, this simplification was justified. But such an artificial integration distracts us from addressing the real, physical aspects of managing road traffic processes. Whereas experience proves that this vision has serious implications for when we’re trying to develop serviceable control algorithms.
The inefficient nature of the phase-based system also manifests itself in causing traffic jams, in the situation where a detector attempts to analyze the flow of cars from several directions at once and decides to turn on the green light. What that often leads to in addition is the mutual blocking of movement flows.
What they do abroad, as demonstrated by the НСМ2000 (Highway Capacity Manual) approach universal in the US, is opting for multi-ring controllers with active adaptive control based on signals from transport detectors. This means that our international counterparts abandoned phase-based approach as we in Russia know it and started to consider each movement maneuver separately, controlling traffic movement in trajectories, rather than phases.
The main advantage of this system is that it allows for a much more effective use of a junction’s traffic capacity. While cars continue to drive on one of the movement maneuvers, they get the green light. If there are no cars wanting to turn to the left during the red-light halt, then why on earth do we need to activate the turning pointer? It’s better to just drop this trajectory out of this cycle altogether if there isn’t such demand both from vehicles and pedestrians, who can indicate it by pushing a button at the crossing.
Using InterGreen matrix to describe transition states
Russian and American controllers don’t even have this option. You need to consider two aspects when creating a signal post-regime. The first is safety parameters, also known as minimal time frames of when the signal lamps are lit up, and the periods between the green light phases for conflicting movement flows. The second aspect is the duration of the main cycles. This factor is calculated based on flows which need to be attended to. Safety parameters fall into the category of geometric characteristics: we take two conflicting movement maneuvers and identify an area of a potential clash. All possible maneuvers considered, we get a full conflict matrix. When there’s a conflict, we put in a value equal to the number of seconds before the potential clash. This is the time the controller will wait for before turning on the green light.
What this matrix describes isn’t some abstract interim cycle, but, rather, true-to-life physical parameters such as the length of a trajectory and the movement speed. The controller can then use the matrix-derived data for making on-the-go calculations.
You can say that our flexible control technology unites the best of both worlds, or the international traffic movement controllers: the laconic American approach to typified algorithm description with the comprehensive German approach to setting interim cycles. I haven’t been to the US yet, but people tell me that all their junctions are the same, which would be a far cry from the diversity of complex road intersections we have here on in Europe. That’s why in their pure form these models are pretty much useful in our country.
Expandable open infrastructure
Our system works on Linux and has an open infrastructure. It is thanks to this that we can connect road controllers to a virtual environment and create user stories. In case the algorithmic approach we developed isn’t enough to perform a task, we can always make this a reality via the hardware platform, drawing on the opportunity to write our own scenarios in the high-level JavaScript language.
Returning to the first point I made about the ‘intelligent’ traffic lights, it’s important to remember what the intellect means in this sense: it is first and foremost a traffic light’s ability to adapt to the ever-changing road traffic, independent of a controller. That’s when the open platform comes to play; not as a technology itself, but as a means for a developer to unleash their creative potential, to modify and perfect the basic algorithm as the time passes.
But as with everything, there’s a reverse side of the coin: this makes the system much more complex. Even our developers admit that they can’t always make heads or tails of such intricate configurations, not to mention the users. The more the controller is complex, the more difficult it is to develop and use: it’s much more likely that you’ll make a mistake in a couple of hundreds of parameters that comprise a composite algorithm than in a dozen parameters of traditional phase-based configurations.
Traffic lights and the virtual environment
But despite these difficulties, it’s interesting for us to put our complex inventions to practice. Working in virtual reality and using hardware-in-the-loop simulation have proven to be especially useful to us in this respect. These tools allow to introduce a replica of a road controller to a virtual environment, in such a way that the former doesn’t even understand that it’s not the real-world conditions it’s functioning under. We set a certain scenario and roll out virtual cars. These then start to interact with each other, as well as with pedestrians, signs, traffic lights and, last but not least, with road traffic detectors: the cars ran these over when moving. The detector reacts by delivering a signal into the connected road controller, which, in its turn, managers traffic lights.
What’s so great about virtual environments is that they also give us the opportunity to implement more sophisticated control systems should we want to, for example, for connecting our scenario to the system control center. We often use this option when adjusting the priority-pass system for public transport.
How does it work? With the help of SUMO, an innovative environment for the simulation of transport processes which was created by German developers. This environment is made unique by its openness: the authors distribute it with all of the original codes. We spent a lot of time masterminding different variations to make it more suitable for our own projects.
How do we use SUMO in real projects?
When we were developing the high-speed tram model ‘Chizhik’, we used SUMO to test our control algorithm concept before the new trams were introduced to the roads. We copied all 23 traffic light posts situated along the tram line to the virtual environment and ran tests featuring all the novel traffic control methods possible: trajectories instead of phases, conflict matrix, and new types of detectors. This virtual trial proved the efficacy of our solutions, and convinced the client in their viability, too.
What changes await us in the near future?
There’s a good chance that the classical traffic lights as we know them will become obsolete. They will be replaced by radio signals-receiving equipment that will be fitted into every vehicle. This system will act as a sort of individual traffic light for each car that will provide drivers with information to help them make decisions of whether they should proceed with the driving or let another car pass before them at the junction. Will this traffic light guide a human driver or an automatic one? We’ll see that very soon.
A similar technology is currently under development at Carnegie Mellon University in the US. The researchers want to control road traffic at junctions through radio, streamlining the cars’ movement with the help of message exchange. What is worth mentioning is that they, like us, also use SUMO in their planning.
Another interesting technology we’ll see in the near future is grouping cars based on a certain common feature like similar dynamic behavior: it’ll much easier to pre-plan signals and handle the traffic flow if the cars move in an organized, logical way.
So yes, ‘smart’ traffic lights do dream of self-driving cars. And these dreams are not that far-fetched.
But what do ‘stupid’ traffic lights dream of? That’s a big question.
