SMART-Signal Live



My colleague Henry Liu has been working with MnDOT the past several years on deploying the SMART-Signal system. It is live on Mn trunk highway 13, and the real-time intersection level of service, queueing, and speed data coming from the system are available online here. As the website says:

"Although measuring and archiving freeway traffic performance using commonly available loop detector data has become a norm for many transportation agencies, similar approaches for urban arterials do not exist. In practice, operational data from traffic signal systems are neither stored nor analyzed, which prevents proactive management of arterial streets. The development of the SMART-Signal (Systematic Monitoring of Arterial Road Traffic Signals) system fills in this gap. The SMART-Signal system simultaneously collects event-based high-resolution traffic data from multiple intersections and generates real-time arterial performance measures including intersection queue length and arterial travel time. The development of the system has laid the groundwork for better traffic models and control strategies and opens up entirely new opportunities for managing traffic on congested roads.

In the SMART-Signal system, a complete history of traffic signal control, including all vehicle actuation events and signal phase change events, are archived and stored. At each intersection, an industrial PC with a data acquisition card is installed inside the controller cabinet, and event data collected at each intersection are transmitted to the data server in real-time using an Ethernet connection. Using the event-based data, a set of arterial performance measures, especially intersection queue length and arterial travel time, can be estimated. SMART-Signal uses a newly developed algorithmic approach to queue length estimation based on traffic shockwave theory. Cyclic traffic shockwaves at an intersection can be reconstructed using event-based data, allowing for queue length estimation even when the queue of cars extends beyond the upstream vehicle detector. To measure travel time, SMART-Signal simulates the movements of a virtual “probe vehicle” along the arterial road. As the virtual probe moves, it can modify its own state in response to the state of traffic around it by accelerating, decelerating, or maintaining a constant speed at each time step as it encounters queues, traffic signals, and changes in traffic density. SMART-Signal can also optimize traffic signal parameters using the collected high-resolution data. Instead of relying on traditional offset optimization approaches, which are based on manually collected volume data on a typical day, SMART-Signal can account for traffic flow variations by using archived traffic signal data and the derived performance measures.

The SMART-Signal system has been field-tested on three major arterial corridors in Minnesota including six intersections on Trunk Highway 55 in Golden Valley, eleven intersections on France Avenue in Bloomington, and three intersections on Prairie Center Drive in Eden Prairie. A demonstration project is also being carried out on Orange Grove Boulevard in Pasadena, California. A large-scale implementation project currently under discussion with the Minnesota Department of Transportation will monitor 100 intersections in the Twin Cities area using the SMART-Signal system. "


This is very interesting. The high resolution data are collected in real time and sent to a central server for the processing. The computation and visualization part are no-brainer in terms of implementation, but for the data collection and communication part, I am very curious based on my experience with NYC's Midtown-In-Motion project where we used real time ET-Pass readers and RTMS wireless sensors to collect real data for adaptive control (nog so "event-based" and the granular of vehicle detection is aggregated very 30 seconds while travel time is individual trip based. This simpler (as compared to this SMART-Signal project) database setting would result our real time database server have 7 million records of travel time, and 30 million records of traffic detection data added monthly.

Since the data are "event-based" I guess the communication and archiving overload is pretty high. How frequent is the data transmission? What is the back-end database server used? Is the computation fully centralized or some part of the computation is delegated and distributed at the local intersection level? When large amount of data accumulated over the years data warehouse and management would become a real technical if not a scientific issue, I guess.

Thanks, Wuping. The frequency of data transmission is a variable that users can set. Right now we package and send for every 30 events at each intersection. But you can send in 20, 10, or even every single event (Chen-Fu has a blind pedestrian project which uses the SMART Signal device and he sends every single event). Since each event contains only a few bytes of data, the communication load is very light. Each intersection sends a few mbytes of data every day.

Our current database software is SQL Server. Currently all performance computation is done at the server side. Each month we have roughly 1G of data for the 13 intersections we have on TH13.

David Levinson

Network Reliability in Practice

Evolving Transportation Networks

Place and Plexus

The Transportation Experience

Access to Destinations

Assessing the Benefits and Costs of Intelligent Transportation Systems

Financing Transportation Networks

View David Levinson's profile on LinkedIn

Subscribe to RSS headline updates from:

About this Entry

This page contains a single entry by David Levinson published on May 4, 2012 4:51 PM.

Linklist: May 4, 2012 was the previous entry in this blog.

The Missing Link | is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


Monthly Archives


Powered by Movable Type 4.31-en