Rhythm Engineering Blog

What SB 743 Meant for the Traffic Industry

By Justin P. Schlaefli, PE TE PTOE 

On September 27, 2013, the way we look at transportation in California changed. On that date, Governor Jerry Brown signed SB 743 into law, sending shockwaves through the transportation industry — which will be felt for years to come.

SB 743 involves a major change to the CEQA Guidelines requiring the use of Vehicle Miles Traveled (VMT) metrics rather than level of service based metrics for measuring vehicle impacts on transportation facilities. The intent of this change is to reduce reliance on the automobile by encouraging development in “Transit Priority Areas” as well as remove disincentives to infill development and reduce greenhouse gas emissions. While indeed serving critical goals, this change has secondary effects which influence the viability of many roadway improvement projects as well as impacting infrastructure funding mechanisms that California has relied on for decades.

While the Governor’s Office of Planning and Research (OPR) has been engaged in drafting and re-drafting CEQA Guidelines for the past several years, the transportation industry is still catching up. Current versions of the draft guidelines include the following key points:

  • Development within one-half mile of an existing major transit stops may be presumed to have a less than significant transportation impact. This mean development of this type may not be required to fund transportation infrastructure improvements.
  • Transit, bike and pedestrian projects may be presumed to have a less than significant transportation impact making them easier to construct.
  • Induced travel effects of major roadway capacity expansion projects are required to be analyzed meaning that road extensions and widenings may no longer be an infrastructure “improvement” but may have an “impact” under CEQA. This could impact the funding and viability of many infrastructure projects.
  • Safety impacts of road widening projects may be considered significant

As a result of many of these changes, funding and planning for transportation and infrastructure projects must be revised to comply with the new rules and priorities. The transportation industry is already headed in this direction, but important questions remain. Fundamentally, the challenge of the future transportation professional will be how to do more with less. It is unfortunate that the characteristics that often occur in the highest congestion locations also occur in areas which are most impacted by the changes of SB 743.

For example, major transit lines often occur in areas with significant density and congestion. Additionally, infill development typically occurs in areas which are already built-out and often experience congestion. A large part of the funding for local transportation projects has historically come from impact fees driven by the rules of CEQA. With those rules changing, large projects in congested areas could avoid paying these fees or avoid constructing roadway infrastructure. Alternatively, proposed roadway infrastructure could be considered to cause a CEQA impact and therefore be rendered infeasible or have a significantly increased cost.

This leads to the conclusion that we must increase the effectiveness of the existing road system. This must be done in a way that is sensitive to all roadway users. This must also be done in a way that avoids costly projects which lack funding or which induce VMT or cause safety concerns for other modes of transportation.

We must do more with less.

A solution which enhances safety, considers the needs of all roadway users, is cost effective and which avoids major induced VMT is ideal. This means that the transportation professional must be willing to go beyond the “traditional” road improvement projects of the past several decades and must add more tools in the tool box. The successful transportation professional of the future will recognize that creative solutions and funding options will keep residents and stakeholders happy. The shelf life of our existing playbook is about to expire … time for a new set of plays!

 

About the author:

Justin P. Schlaefli, PE TE PTOE is President of Urban Systems Associates, Inc. based in Southern California. He has over 16 years of experience in the transportation industry working for both public and private clients. Questions about SB 743 or transportation solutions which might be the most effective under likely future guidelines, please contact Justin@urbansystems.net

Rhythm EngineeringWhat SB 743 Meant for the Traffic Industry
READ MORE

A Quick Look at Traffic Sensors

By Wayne Simmons

As traffic signals needed to become more efficient and allow more traffic though an intersection, the industry realized that pre-set timed lights alone would never be good enough, even with different timings per day. The only way to streamline the process was to know which vehicle movement would best serve the current demand.

Because putting a traffic engineer on every corner wasn’t a possibility, controllers needed to have more smarts to make the best decisions. To make smarter decisions about how to run the lights in the intersection, controllers needed to know about the vehicles at the intersection. To solve this, in the early ‘60s, induction loops were deployed as detectors.

Induction loops use a simple interaction of metal, magnetism and electricity to detect large metal objects. They have many advantages: they are simple, cheap and reliable. However, they have some serious drawbacks.

Sometimes, loops can miss smaller vehicles, like motorcycles or bicycles. In addition, as modern cars get smaller and consist of more plastic than metal, they become harder to detect. Finally, loops are expensive to install (or reinstall), because they are embedded in the road. This leaves them vulnerable to unrelated road work, which can damage them or leave them inoperable.

Enter the Age of Video Cameras.

While research using video detection cameras was done as early as the ‘70s, use of video detection systems was not widely spread until cheap, reliable cameras became available in the ‘90s and 2000s.

Video cameras solve many problems that loop detectors face. Because video detection is not based on the presence of metal mass, smaller vehicles can be detected. Cameras are also easier and less expensive to install and maintain, because they attach to mast arms, poles or nearby street lights.

Video detection systems provide an extra added benefit: they give operators the ability to see what is really going on at the intersection in real time. However, they brought along new classes of problems too like sun glare, fog and other weather conditions that can make vehicles detection difficult.

Other modern traffic detection options range from thermal cameras to radar, as well as other advanced sensors. All of these options provide a more accurate understanding of real-time traffic needs that help run an intersection more efficiently. Each category of detector has their own strengths and weaknesses. However, one deficiency has never been addressed by any of these detectors since loops were first deployed.

Loops can only detect presence or not, meaning they can only tell a controller if a vehicle is above them, or not. This is good information, but it isn’t enough information to run the intersection in the most efficient manner. To know how to serve the greatest number of vehicles, the controller needs to know how many vehicle requests are at each approach. Loops can answer: “Yes someone is waiting,” but they can’t easily tell how many. So how can a controller know which phase serves the longest queue of waiting vehicles?

Adaptive Traffic Control with Video Processing

In|Sync does special video processing, looking at the images of the cars waiting on each approach to calculate which movement best serves the waiting vehicles. It then places calls to the controller to serve those phases.

In|Sync continuously analyzes queue levels and wait times, placing calls to the controller for the appropriate phases. Using this method, In|Sync streamlines intersection operation, even with the same controller running the lights. In|Sync uses cameras, other modern detectors, historical data, as well as loops to detect, verify and serve actual traffic demand.

All detectors have weaknesses, but unless you can afford to place a professional traffic light operator at each busy intersection to assess traffic and run the signals, you will have to rely on automatic detectors of some kind.

Knowing this, why wouldn’t you prefer a more advanced system that can understand demand better and put it to use when trying to move traffic safely and efficiently though the intersection?

Finally, all of this focuses on a single intersection. For busy corridors, traffic engineers must consider coordinating signal timing between each intersection. That’s something In|Sync excels at as well but, that’s a topic for another time.

Rhythm EngineeringA Quick Look at Traffic Sensors
READ MORE

In|Sync’s Distributed Architecture

By Grant Niehus, Director of Operations

From the very start of In|Sync’s history, it was designed to be a robust and scalable, adaptive traffic control platform. We envisioned that the system would positively impact millions of drivers a day, bringing loved ones to their destination faster and safer.

But to accomplish that goal, we had come up with an architecture that could be deployed quickly and without limits. By designing a system that utilized a distributed architecture we could overcome two significant challenges that adaptive systems encountered at the time:

1. System degradation during communication breaks

2. Limits to the number of intersections that could be added

Traditional adaptive systems relied on a central server to send operational instructions on a per-cycle-basis or even worse once every 5-15 minutes. Not only was this way of doing things slow and inefficient — because the “adaptive” changes were always behind — but more importantly, if the communication from the central server to the intersection was broken, the intersection could no longer operate adaptively.

In|Sync took a different approach and placed the adaptive logic at the intersection level instead of at a Traffic Management Center (TMC). This allowed In|Sync and the adaptive system to continue to operate with 100% efficiency even when a communication outage occurred between the TMC and the field. Events such as internet service provider outages, fiber breaks and network routing issues are becoming every day occurrences and designing a system to mitigate these real possibilities has been something we have worked very hard on.

The other advantage to a distributed network design is that it puts the computational load on the individual equipment in the cabinet rather than on a single server in the TMC. This allows the system to scale to a theoretically unlimited amount of intersections. Each intersection uses its own local, real-time data to alter the signal state and does not rely on network access back to the TMC. From an intersection network of 100+ intersections to a corridor crossing multiple jurisdictions, In|Sync is a solution that can be deployed without limits.

Over the years, we have used our knowledge gained from our 2,500+ intersections deployed and put it into our newest software. I am pleased to share that our brand-new software platform, In|Traffic and InSync 1.6, continues the distributed architecture design that we believe is a pillar to In|Sync’s success and are excited to roll it out to all of our users.

Learn more about In|Sync here.

Rhythm EngineeringIn|Sync’s Distributed Architecture
READ MORE

Are You Ready for a Revolution? The History and Future of Traffic Lights

By Jesse Manning, Vice President of Business Development

The modern traffic signal is an ever-present fact of life for motorists, but controlling traffic flow through green and red indicators was an idea pioneered long before motor vehicles were the standard mode of ground transportation. In 1868, J.P. Knight — a British engineer and inventor — developed a traffic signal in order to reduce the number of accidents on busy London streets, where horse-drawn carriages and carts, along with pedestrians, ruled the roads. Knight’s invention used semaphores to signal which directions of traffic should stop and which should proceed through an intersection, and at night, the police-operated device used red- and green-colored gas lamps to indicate the same instructions.

Knight’s traffic signal was abandoned in 1869 after one of the gas lamps exploded, injuring the traffic control officer, and traffic signals wouldn’t appear in London again for 50 years. But by the early-1900s in the United States, the growing number of motor vehicles sharing streets with horse-drawn traffic and pedestrians forced other inventors into action. From Lester Wire’s first electric traffic signal in Salt Lake City in 1912 to Garrett Morgan’s famous patent in 1923, America led the way in the development of modern traffic control devices. We had no other choice. The rapid adoption of automobiles as a preferred method of travel spurred the innovation of control devices that were desperately needed by municipal and state governments adjusting to a new normal.

Historically, however, automobiles and infrastructure have operated independently of each other. The driver has interpreted the language of the infrastructure and — at risk to himself and others — may ignore the direction of traffic lights and posted directions, limits and warnings if he so chooses. Even vehicle detection systems, which can make our signals operate more responsively and effectively, simply interpret vehicle presence and behavior.

In 2017, 105 years after the first electric traffic signal was installed in Utah, we are again facing a revolution in traffic that presents both industry and government with challenges and opportunities. True autonomous, driverless vehicles are far from science fiction, and the first freight and transit applications are being piloted around the country. Infrastructure can no longer afford to be passive, and since innovation rarely waits for regulation, governments cannot afford to take a wait-and-see approach.

Fortunately, connected vehicles — those that feature advanced communication capabilities but rely on traditional driver operation — will serve as a bridge between the familiar past and a driverless future. Standards for transferring data to and from vehicles and infrastructure are being set, and traffic technology innovators are working with states and municipalities across the United States to provide better information to drivers from the infrastructure, and to the infrastructure from the cars on the road. While those parties are working to determine which data sets are of most use to both motorists and traffic control systems, there’s no doubt that the connected-vehicle revolution is upon us. Over the next decade, we’ll see exceptionally rapid development and deployment of connected technologies at rates not experienced by the traffic industry in 100 years.

For traffic professionals, it’s critical to begin considering the impact of connected vehicles and infrastructure into both short- and long-term management plans. The industry may still be developing solutions — answers to questions that seemed outlandish just a decade ago — but we should begin to prepare today by researching and investing in powerful, modular platforms that are specifically designed to bridge the gap between traditional solutions and cars of the future.

Because it won’t be long before the most common motorist complaint changes from, “I’m sitting on the side street and no one is on the main street,” to, “Why aren’t your signals providing my new car with real-time travel-time information and signal status?”

Rhythm EngineeringAre You Ready for a Revolution? The History and Future of Traffic Lights
READ MORE

Virginia Solved Their Traffic Congestion with Adaptive Traffic Control

The state of Virginia had a problem. Across multiple jurisdictions, traffic flow issues were rampant. Each corridor and signal was different, with unique structure, volume, speed limit and control need; but they needed a solution that would solve traffic congestion across the state. What could be done? The answer was simple: adaptive traffic control.

Between 2011 and 2013, Rhythm Engineering worked with the Virginia Department of Transportation (VDOT) and installed In|Sync adaptive traffic control at 111 intersections, comprising 13 corridors in 11 jurisdictions. The goal was for In|Sync to help reduce delay and improve overall traffic safety as compared to the existing static time of day plans that weren’t working for those backed-up intersections.

“We have a little over 3,000 traffic signals that we operate and maintain from VDOT,” said Michael Clements, PE, VDOT Traffic Signal and Arterial System Program Manager. “Most of our corridors in Virginia are running time-of-day plans, so they’re based off of historical traffic data.”

While historical data provides information about vehicles, often times traffic patterns change before time-of-day plans can be updated. In many jurisdictions, signal timing plans are only updated every five years, and traffic patterns can change a lot over that lengthy period of time. Instead of relying on outdated data, Virginia needed a system that could adapt to the changing traffic flows driving through their intersections. In|Sync was the answer.

As an adaptive traffic control system, In|Sync is programed to respond to the actual demand at the intersection. This means, the system will prioritize movements based on the volume of vehicles. It does this by detecting vehicle presence and making real-time adjustments to phase sequencing to more efficiently serve demand.

 

 

The Problems Virginia Needed Solved

Many cities in the state of Virginia were having issues with increased traffic demand and backed up intersections. Before technological advances, the only answer to an increase in vehicle volume was expanding streets in order to accommodate traffic demand.

“We don’t have the option of expanding at all, so getting those facilities in is difficult,” said Justin Hall, Traffic Manager of Winchester, VA.

Due to an increased number of commuters to Winchester or out of Winchester to Washington D.C., peak volume times and increases in summer time traffic patterns, Winchester had a traffic volume their roads couldn’t handle. Winchester is full of historical buildings and was already tightly packed, so expanding roadways wasn’t an option.

Widening the roadways also wasn’t a favorable option in the County of Albemarle. While they had the space to widen, the budget was was creating another problem.

“With a lot of lane widenings you have to buy right of way and they can get very expensive,” said Dennis Rooker, Albemarle County Board of Supervisors (2001-2013), County of Albemarle. “You can expect to pay $10 million a mile for adding one lane, at least. Now we’re looking at a widening project on route 29 North that I think is a couple of miles long, and it’s projected to cost $30 million.”

Rather than invest in a long-term construction project, Rooker found In|Sync adaptive traffic control system to be a better option.

“I’m very much in favor of looking at ways to improve traffic flow and deal with capacity issues that don’t involve laying new pavement,” said Rooker.

In other areas of Virginia, sometimes the issue couldn’t possibly be solved with a widening project because it wasn’t the vehicles that were the problem.

“Our biggest challenges right now are with pedestrians,” said Gigi O’Donnell, Traffic Signal Supervisor in Charlottesville, VA. “Almost every single intersection has pedestrian signals.”

Cities Across Virginia Signed Up for In|Sync

VDOT approached several cities and asked them to join in on the In|Sync deployment, including Winchester, Albemarle County and Charlottesville, among many others. Each city did their own research and were all impressed with the results.

“I think I had a constituent send me some information on In|Sync,” Rooker added. “I looked at some of the third-party evaluations of the In|Sync system, and I became convinced that it would be something that would probably enhance the transportation here.”

“I looked into it and what attracted me most was that it was real-time coordination,” said O’Donnell of Charlottesville.

“We thought that we would partner with Virginia DOT and see if this system would work for us,” replied Don DeBerry, PE, a Transportation Engineer in Lynchburg, VA, whose community also deployed In|Sync with VDOT.

In|Sync Deployments Brought Immediate Results

Over the next three years, In|Sync adaptive traffic control system was deployed at all 111 intersections chosen by VDOT. During that time, extensive amounts of data were collected in order to judge how In|Sync had impacted the corridors it was deployed on. Michael Fontaine, PhD, PE, Associate Principal Research Scientist was one of the lead analysts from the Virginia Transportation Research Council who evaluated the impact of In|Sync adaptive traffic control.

“We definitely saw benefits on the corridors where we deployed, both in terms of moving people safer and faster,” said Fountaine.

All intersections were impacted by the installation and the results were noteworthy in terms of stops, average speed, travel time and accidents. Overall, there was up to a 67% decrease in stops, a 58% increase in average speed, a 36% decrease in travel time and a 17% decrease in total accidents collectively across Virginia. Compared to the previous time-of-day plans, In|Sync’s adaptive technology was positively impacting the state of Virginia.

“We certainly have enough experience to know that with the initial implementation and the corridors are operating much more efficiently than we could have timed them,” responded DeBerry of Lynchburg, VA.

The data clearly illustrated how drastic the improvements were once In|Sync was in place, but the comments from the community were even more telling.

“Citizens were very excited about it. I don’t think I had a single negative comment from a citizen,” noted Rooker of Albemarle County. “I had many people comment that they thought it was one of the better things we had tried to move forward in the county on the transportation side for years.”

The same went for Winchester: “Everything we’ve been hearing has been positive about In|Sync in the two corridors that we have,” said Hall.

Safety Improved Across the State

Beyond the improvements in traffic flow, the safety benefits of installing In|Sync were apparent across Virginia.

“On the safety side, we looked at 47 intersections around the state where we had at least one to two years of data after In|Sync was activated,” said Fountaine. “On average we saw a statistically significant reduction of about 17% in total crashes.”

Imagine what 17% fewer crashes looked like to every city involved in the Virginia deployment of In|Sync. That is countless lives saved and hundreds of thousands of dollars saved from the cost of car accidents.

“We’ve definitely seen an improvement in traffic flow, and it looks like we’re going to see a significant reduction in our crashes. So I’d say job well done, guys.” DeBerry of Lynchburg said.

Overall, the benefits of the system were numerous and better than VDOT could have expected. From constituents to traffic engineers and managers, the positive impacts successfully improved the traffic environment across Virginia.

“It’s just unbelievable,” said O’Donnell of Charlottesville about their In|Sync deployment. “I ride down that way every day now.”

After all the data was reviewed, the Virginia Transportation Research Council also determined the benefit/cost ratio of their entire In|Sync deployment. They found an average ratio of over 8 after just a year of deployment, meaning almost 8 times as many benefits were accrued on those corridors than the cost to install the system initially. That is in one year alone. Overall they found an annual benefit vs. cost of $34.6 million.

“We have quite positive results with the system,” said Clements of VDOT. “Positive enough that we continue to keep installing it.”

Rhythm EngineeringVirginia Solved Their Traffic Congestion with Adaptive Traffic Control
READ MORE

In|Traffic vs. Central|Sync

By Ryan Broomfield, Systems Architect

Imagine shipping a nice wooden coffee table from one part of the world to another. It seems easy enough and relatively trivial at the outset. The customer pays for it and you simply place a coffee table in a box, wrap it up nicely and put it on the next plane or shipping service and wait for it to get to the destination.

Now, imagine that when it gets halfway to its destination, one of the countries the table is passing through has a law that, for security reasons, the coffee table must be disassembled into each individual part, photographed and then put together again. This becomes a much more difficult problem. To overcome this hurdle, you now must prepare a set of instructions on how to safely take apart the coffee table and put it back together again. You can only hope that your instructions were perfect and that they were followed precisely, otherwise the coffee table won’t arrive in the condition that it left.

At the next country on its path, there is a ban on transport of wooden coffee tables, so now your coffee table must be taken apart into the individual parts and metal parts must be fabricated to precisely match the original dimensions. The original gets thrown away or recycled. It’s not the same coffee table, but it still is a coffee table.

At the next country, there is a ban on transport of metal coffee tables. Now, the process must be completed again with wooden parts fabricated to precisely match the original dimensions. Now the coffee table looks identical to the original, but you’ve thrown away your original coffee table, built and thrown away a metal coffee table, and built an entirely new coffee table to match the original.

The recipient opens a box weeks later and finds a simple wooden coffee table inside and a bill for a discarded identical coffee table, a metal coffee table and the labor to build two tables that were thrown away.

“What in the world happened?” the customer would ask.

Once you’ve sent one of these coffee tables, you’ll discover that shipping a coffee table may not be the best idea. It may be a better idea to send the plans to a coffee table builder at the destination so that the coffee table can be built at the destination and the whole process can be far cheaper and faster.

Coffee Table Problems in the Software World

In the software world, situations like the coffee table problem happen frequently when data is moved from one complex application to another. It can be very difficult to figure out which approach is best until many have been investigated, or in some cases, tried and failed.

With CentralSync — the configuration software for In|Sync used in previous versions — there were some technical stumbling blocks along the way. For example, CentralSync could configure tunnels and In|Sync parameters pretty well, but it was unable to combine those factors and determine whether or not the configuration would actually run as intended at the intersection. This required more guidance and training from experienced professionals at Rhythm Engineering to determine whether or not there would be any hidden side effects or unintended behaviors.

Just like the circumstance where metal or wood coffee tables are banned during shipping, having the intelligence from In|Sync help us validate the configuration wasn’t a feature that was possible without building an identical second copy of In|Sync into CentralSync because of a fundamental difference in programming language models. CentralSync was built in C++ with Windows Desktop Application technology and In|Sync was built in Microsoft’s .NET system. While the two systems can eventually be made to work together, it’s a very time consuming process to get right and prone to error. This was the technical equivalent of shipping coffee tables and building multiple copies of the tables in wood and metal to overcome the transit laws. This was seen as too much of a challenge to take on due to our upcoming investment into In|Traffic.

In|Traffic also has a different programming language than In|Sync because we’ve built a world-class server system utilizing Java technologies while the In|Sync intelligence at the cabinet takes advantage of Microsoft’s .NET system.

What Could We Do to Get These Two Systems to Communicate?

After extensive research, we found an open source technology that allows us to automatically convert In|Traffic code built in Java into code that works directly on the .NET platform with our In|Sync cabinet software. It’s the technical equivalent in our earlier story of simply sending our coffee table plans to our destination country and building the table for the customer on location rather than building and scrapping coffee tables by trying to ship them through countries that did not permit our tables to get through.

The project that created this technology is named IKVM (https://www.ikvm.net/). It’s a play on words by taking the term JVM, which is the acronym for Java Virtual Machine, and picking the two adjacent letters to J in the alphabet and creating IKVM. It has the capability of taking standard Java applications and converting them into native .NET software that also allows previously written .NET software to directly interface with the translated output. One of the most impressive demonstrations of this system is that it can flawlessly convert Minecraft, one of the world’s most popular Java-based games and a complex application, and convert it to .NET.

Ultimately, with IKVM in hand, we could write one single piece of software in Java that would work for us at the cabinet with the rest of our .NET technologies and in our Java-based configuration software. We are pleased that we could choose the right technologies for the cabinet and our configuration application and not have to compromise on the wrong technology for either solution or build two identical models. This ability to share code gives us the brand new ability to test and validate our tunnels and parameters inside our configuration software with the same exact scrutiny that would occur at the cabinet and do so in a language that every system understands.

We are very happy to utilize an open source project like IKVM to help our products and services be industry leaders today and in the future.

To learn more about In|Sync and In|Traffic, visit our solutions page.

Rhythm EngineeringIn|Traffic vs. Central|Sync
READ MORE

What Makes In|Sync Different?

We’ve been working vigorously at developing an advanced adaptive traffic control system since the beginning of Rhythm Engineering. When developing In|Sync in 2005, Rhythm Engineering used creative approaches and technologies new to the transportation engineering industry. Instead of developing incremental improvements to existing traffic control tools and methods, we imagined the best possible traffic control tool and went from there.

Our exploration led us to the human brain, or rather, the brain of a well-informed traffic engineer. Once we understood that no existing machine or method matches the analytical, reasoning and observational abilities of a traffic engineer, we set out to build one. We challenged ourselves by asking, “How would a traffic engineer control a signal if he/she were standing at each intersection?” We then built a solution that comes as close as possible to emulating that decision process and its benefits.

Emulating a well-informed traffic engineer at each intersection means In|Sync must detect demand in real-time, be able to make immediate adjustments in signalization, not be constrained by “mechanical” thinking and be aware of upstream and downstream traffic conditions. In other words, In|Sync at each signal must know the actual traffic conditions, have the power to make dynamic changes and appreciate what conditions will exist in the next few minutes.

This is a substantial departure from other traffic management systems. Nearly all traffic control systems today use digital hardware but remain constrained by analog thinking such as common cycle lengths, set sequences, fixed offsets and standardized allotment of green time, or splits. The In|Sync Processor is instead a modern state machine, meaning it can dynamically choose which phases to serve and instantly adjust and coordinate service and green time.

By adapting to actual traffic demand, In|Sync truly is superior to predetermined signal timing plans that, at best, estimate traffic demand based on a small historical sampling and generalize those results across years of traffic signalization. In|Sync’s ability to constantly see and flexibly serve actual demand in the best way possible is what enables it to produce such astounding before-and-after results. Regardless of your traffic flow, time of day or demand, In|Sync responds specifically to your intersection’s needs.

View In|Sync case studies and learn more about the advancements adaptive traffic control brings to intersections and communities by visiting our Case Studies page.

Rhythm EngineeringWhat Makes In|Sync Different?
READ MORE

In|Sync 1.6 and the Future of Adaptive Traffic

Based on user feedback, we’ve improved In|Sync into the most advanced version of our adaptive traffic control system yet.

Our team at Rhythm Engineering has reworked the In|Sync algorithm from the ground-up, making new improvements but also creating a program that can easily accommodate additional changes in the future.

Some of the specific improvements In|Sync 1.6 will bring to existing and future intersections include:

  • Improved support for cross coordination, advanced geometries and custom sequencing
  • Improved dynamic period algorithms
  • A redesigned notification system
  • Official support for TSP
  • And other features

See the improvements In|Sync 1.6 will bring to your intersection by watching this webinar, “What’s New in In|Sync 1.6.”

At the end of the webinar we cover how to upgrade your system to In|Sync 1.6. Fast forward to 24:22 if you are just looking for upgrading information.

 
Rhythm EngineeringIn|Sync 1.6 and the Future of Adaptive Traffic
READ MORE

What is Adaptive Traffic Control?

Adaptive traffic control systems help improve communities and intersections across the world. But what is an adaptive traffic control system? Today we hope to clear that up.

Adaptive traffic control systems aren’t as complex as they sound. At the very base, its technology that makes traffic signals change and adapt based on actual traffic demand. So rather than adhering to a fixed cycle — like the majority of traffic controllers and systems used — an adaptive system responds, in real-time, to the vehicles at the intersection.

This is done with a combination of advanced hardware and software. You need measuring systems to recognize the demand of traffic, that’s the hardware. At a rudimentary level this could be loops, but it could also be a camera or thermal camera. What these detection sources do is recognize vehicle presence and feed that information into the software.

For software, you need an advanced system and algorithm that can recognize vehicle counts and stays, analyze incoming data and push out responses regardless of intersection geometries or traffic demand. The software is what makes the traffic controller adaptive by responding to vehicle presence at any given time and appropriately prioritizing signal changes.

Advanced algorithms can be designed to respond with real-time optimization and coordinate traffic movements across corridors — meaning signals can be linked across a section of roadway, rather than at individual intersections. When signals are adaptive at a corridor-level, larger groupings of vehicles can be moved smoothly along stretches of road in a way that improves overall traffic flow.

For accuracy, adaptive traffic control algorithms are rigorously developed and tested to ensure accurate, responsive and advanced adaptive operations take place. At times, traffic is predictable, but that isn’t always the case. That’s why adaptive systems have to be prepared for anything.

That’s what an adaptive traffic control system is — a 21st century solution for optimizing traffic signals. Adaptive traffic controls respond directly to demand at every intersection, 24/7/365. And that’s what makes this solution different. Regardless of your traffic flow, time of day or demand, adaptive traffic control responds specifically to your intersection’s needs.

 

Learn more about Rhythm Engineering’s adaptive traffic control In|Sync.

 

*According to the Virginia Center for Transportation Innovation & Research, “Evaluation of the Virginia Department of Transportation Adaptive Signal Control Technology Pilot Project.”

Rhythm EngineeringWhat is Adaptive Traffic Control?
READ MORE

Traffic Signals: The Troubling Truth

As a typical motorist who hates sitting at long red lights, it is reassuring to know that there is so much that occurs behind the scenes to control traffic congestion.  As we learned in the first blog (7 Traffic Myths Debunked), there are a number of reasons we get into a jam!

Here’s a ‘crash course’ in traffic engineering which will illuminate the real reasons traffic signals seldom function as we want them to.

Essentially, traffic signals can be considered to have 3 major parts: 1.) Traffic signal heads, 2.) Vehicle sensors or detectors, and 3.) Traffic signal controllers and cabinets.  As with a police officer directing traffic in a busy intersection, these parts must work together to make the best decisions for optimal traffic flow. Thinking of the officer analogy, this makes sense: his brain would be the signal controller; his eyes the sensor; and his hands the signal head. He must effectively observe, make decisions regarding signals, and communicate them to motorists to ensure their safe and efficient travel; this is the same way traffic signals work.

1. Traffic Signal Heads

As pedestrians and motorists, we’re all extremely aware of signal heads; they are generally mounted on mast-arms or hung on wires spanning the intersection (aptly called “span wires”) and have three color-coded indications. As many of us have known since playing rousing games of “Red Light Green Light” as youngsters, these lights let us know when to stop and go, respectively. The middle, amber—or more commonly “yellow”—light alerts us to prepare to stop.

Most of us only think of this traffic signal component when expressing our frustration with red lights. When we must abruptly stop at yet another intersection, we’re more likely to shake our fists at that stubborn red light than any other part of the traffic signal system. In addition, these are often the most updated component of the three-part system.  In fact, most signal heads now use Light Emitting Diode (LED) lights in order to conserve energy. While signal heads may have the greatest presence in the public view of traffic signals, they are not as critical in signal optimization as the other two components.

(image source)

2. Vehicle Sensors

The next most infamous component is the subject of many of the myths described in the first blog: the vehicle sensor. The vehicle sensor detects the presence of vehicles at the stop bar of each lane, though it is neither a laser curtain nor a buried scale. The information collected by the sensor is binary, reading either “yes, at least one vehicle is present” or “no, not even one vehicle is present.”

Depending on the technology utilized, a sensor may or may not recognize the presence of more than one car. Once collected, this information is sent to the traffic signal controller for processing. The sensor is usually an inductive loop located beneath the pavement, though newer video technologies are growing in popularity. Two other less popular methods of detection include radar-based detection and detection using wireless magnetometers. Regardless of its form, the role of the vehicle sensor is always to detect cars and communicate that information to the signal controller.

…role of the vehicle sensor is always to detect cars and communicate that information to the signal controller.

Most intersections currently employ inductive loop sensors. Electromagnetic induction-based detectors use coils of wire under each lane. These coils are commonly referred to as “inductive loop detectors” or “loops.” This method works based on the laws of electromagnetic induction; when a mass of metal is moved inside a coil of wire, electricity or an electric pulse is generated. With these sensors, the vehicle is the mass of metal that moves inside the coil of wire buried under the lane. The detector constantly monitors the electric pulse in the loop and informs the traffic signal controller about the presence or absence of a car. Since induction-based detection relies directly on the laws of physics, if configured properly, it offers the most reliability.

While inductive loop sensors provide reliable feedback, installation and maintenance are costly and time consuming. To install loops, the pavement on each lane is cut with a saw in the shape of the loop. Loop wires are then installed into the saw cut and sealed. Over time, pavement moves and as a result, loop wires are broken. Regular pavement maintenance projects also destroy loops, necessitating premature reinstallation.

Furthermore, this methodology is limited: it does not know whether there is one vehicle or a string of vehicles waiting. Loop sensors can only detect the presence of cars idling at the stop bar. As a consequence, loop sensors do not allow for more complex traffic mitigation, which could give preference to busier streets in order to relieve traffic congestion. If you have seen a solitary car on the side street given priority (and green indication) over a long line of cars approaching on the main street, this limitation is likely the reason.

Another detection method is based on video image processing. This method has gained popularity because its installation is less intrusive and its maintenance is easier. In video based detection, cameras are mounted on mast arms from which vantage point they record approaching traffic. 

These (video) sensors are the little white, tubular objects sticking up from the signal mast-arm and staring at you. Fear not, these sensors aren’t recording your speed or your steering wheel drum solo!

The cameras send real-time images to an image processor. When pixels in the image don’t change over time, the processor saves them as a “learned” background image. The processor compares the real-time image with the learned image by literally subtracting the real-time image from the learned background image. If objects are left over from this subtraction process, the processor reports that a new car is present in its detection zone.

Installing cameras on mast arms is the only invasive step for deploying video image processing detection. If a camera fails, unlike replacing the loop, where the pavement has to be saw cut again, it is relatively easy to replace the failed part. However, video detection is susceptible to camera issues such as being blinded by the sun, fog, and snow. Additionally, shadows of moving objects and reflected light from wet pavements can generate false detection triggers. These false detection triggers bring up green lights even when there are no cars waiting to be served. Fortunately, software exists to readily compensate for these issues, thereby eliminating these issues and optimizing video detection sensors.

3. Traffic Signal Controller/Cabinet

If you’ve ever wondered about the purpose of the metal box at the corner of every major intersection, aside from being a public bulletin board or convenient place to unload an unwanted wad of gum, it is actually the traffic signal cabinet. The cabinet houses the signal controller and other hardware required to run the traffic signal. Based on input from the sensors set up at every intersection and the programming done by a traffic engineer, the signal controller determines the amount of green or “go” time given to each movement of cars. As such, it functions as the brains of the operation—aside from the traffic engineer, of course.

While they may look similar from the outside (i.e., big, metal boxes, possibly covered with graffiti), not all traffic signal controllers run in the same fashion. In fact, there are three modes of signal operations in the popular analog traffic signal controller. Most traffic signals operate using one of the following modes: pre-timed, actuated or synchronized.

The simplest of the three modes is the pre-timed mode. In the pre-timed mode, each vehicle movement is given a predetermined amount of time regardless of vehicle demand. Vehicle sensors are not required at these intersections because the system runs on a set timer rather than responding to the presence or absence of cars at the stop bar. Synchronization between signals is possible with the pre-timed mode; however, this method is very inefficient in terms of mitigating traffic or serving the needs of commuters and is not recommended.

Coming in as the polar opposite of the pre-timed mode is the actuated mode. In the actuated or “free” mode, there are no timing plans or synchronization between lights.

Each signal gets input from its own sensors and changes signal indication (i.e., the color of the light on the signal head) in a sequential fashion, regardless of what other signals on this main route are doing.

That is, with actuated signals, each intersection is something of a “first come, first served” affair: green lights and red lights are distributed according to the presence or absence of cars detected by the sensors at each individual intersection.

The advantage of the second mode, actuated mode, is that delay—that pesky wait time—on the side street is minimal during periods when traffic flow is light. The disadvantage is that delay experienced at the intersection as a whole will increase as motorists on the main street will need to stop while vehicles on the side street are being served. Also, there will not be any synchronization between signals. This lack of coordination will cause a substantial increase in stops, vehicle emission, delay, and fuel consumption. Thus, while isolated signals may effectively operate in actuated mode, it is not efficient to operate a string of signals in actuated mode.

The final and most efficient option is the synchronized mode. In this mode, the signal rests in green for the main street unless vehicles are present in the side street. This design takes into account the greater volume of traffic travelling through main streets and distributes more “go” time to that thoroughfare. Often, agencies may not install sensors on the main street because the signal will always revert to the default of giving green time to vehicles travelling on that street. The assumption is that more vehicles will always be present on the busier corridor.

Additionally, it is possible to synchronize multiple signals in an arterial in this mode, thereby allowing even greater customization for the needs of commuters along that route.

The Holy Grail every traffic engineer seeks is an efficiently installed and maintained system that allows for flexibility depending on changes in traffic patterns; thus, the synchronized traffic signal is the preferred option for effectively mitigating traffic congestion in city driving conditions.

Synchronizing semi-actuated signals allows whole movements of vehicles along a specific route to travel in what are called “green tunnels.” A green tunnel is a passageway of green lights enabling a group, or “platoon,” of vehicles to travel uninterrupted by congestion-causing red lights. Moreover, all signals that are synchronized must have the same cycle length. The cycle length is defined as the time it takes the timer within the controller to turn 360 degrees. In terms of what you see as a motorist, a cycle length is the time it takes to move from the beginning of green light to the end of a red light for your main street. Within that duration, the controller is required to sequentially serve all movements that have a demand. While this information may seem technical, we’ve all seen it in action. In reality, where an intersection fails to serve all movements sequentially—that is, give each direction of traffic its share of green lights—the resulting chorus of car horns would alert you of the lapse.

The cycle is further divided into “splits,” where splits are the percentage of a cycle allocated to a particular vehicle movement. Think of it this way: at an intersection of a main thoroughfare and a smaller side street, the main road is going to get the larger “split” of the cycle or the larger cut of green time. There is also one fixed point in the cycle that can be considered as a baseline and referenced. Offsetting this fixed point from one intersection to another synchronizes signals. If you’ve ever sung a tune like “Row, Row, Row Your Boat” in rounds, you can imagine the first singer as establishing the baseline upon which the other singers find their rhythm and melody. Much like when singing in rounds, synchronizing traffic signals in this fashion allows for a more complex, harmonious flow of traffic.

How Signals Communicate

To delve even deeper, traffic signals should be interconnected to form a network to ensure optimal performance.  Since roadways already function as a network, it makes sense for the technology responsible for directing traffic on these roads to communicate the same way.  Traffic issues don’t occur in isolation; if they did, we wouldn’t need to listen to the traffic reports during our morning or evening commutes.

Read an Engineer’s Perspective on the Signal Communication Problems

Traffic runs best when signals are interconnected and work together in a synchronized manner. Common media used for interconnection include wireless, fiber-optic cable, and twisted pair copper conductors. Often, this communication network covers the entire city and terminates at the office of the traffic engineer. Interconnection provides the engineer with remote access to the signal but synchronization is not perfect. Nevertheless, the overall effect of networking signals maximizes the efficiency of signal performance.

Summary

We hope you’ve begun to understand some of the technical reasons behind the difficulty of optimizing traffic signals.  The foundational equation behind most of the software models is flawed, and furthermore, the process of synchronizing the signals based upon those flawed equations is itself a time consuming and expensive endeavor. 

Since synchronizing traffic signals in this traditional manner is so inefficient, between 70 and 90 percent of traffic signals in the United States are not synchronized.  In fact, the National Transportation Operation Coalition grades U.S. traffic signal operation a grade D. 

However, it’s not the engineering limitations alone that earn us such a dismal grade.  Rather, a number of social and political factors prevent traffic engineers and city planners from making significant and technologically feasible improvements to traffic signal operation.  I will explore these limitations in greater detail in later blogs. For now, read more on the latest technology used for traffic control at www.rhythmtraffic.com.

Bo LaisTraffic Signals: The Troubling Truth
READ MORE