Real Time Congestion Monitoring on Arterials

This article is on how to use your central system to provide real time congestion mapping, and incident notifications.  The example here is using Naztec's ATMS.now central system and Naztec controllers using Apogee Version 76.x firmware.  As I have said before, I am not a Naztec employee, or vendor.  I am a local agency traffic engineer who uses Naztec products.  I would assume that other brands of controllers and central systems can do similar operations.

In our case, each detection zone (each induction loop (or array of circle loops within a specific lane), video detection zone or radar detection zone is brought back into the controller using a unique channel.  The desire for detailed operational information drove the specific design of signal cabinets and detection systems.  We have a Caltrans 332 style cabinet which has a modified I and J file and wiring harnesses to take advantage of 46 unique detection inputs into the 2070 controller using the C1 and C11 harness.  The vast majority of our signal cabinets are NEMA TS2-1 where we have up to 48 or 64 channels of detection coming into the controller.  While this may seem excessive, the rich data we are provided through this expanded detection methodology provides us with a lot of tools to help our signals run better, and provide additional data for determining performance.

Each detection input is monitored in the controller for detection diagnostics along with logging volumes and occupancies on 5-minute intervals.  Almost all stopbar detection occupancies are tied to only log the occupancy when the signal is either green or yellow for the associated phase the detection channel drives in the controller.  In some cases, we choose to log green + yellow + red, or only yellow + red, but the vast majority of the stopbar detectors are logging occupancies only during green plus yellow.

In some cases, we do also mirror specific detectors to log green + yellow under one channel, but mirror the detection to log green + yellow + red, if we need additional information about how the lane is operating.

Why do we do this?

There are a lot of reasons.  One primary reason is that the central system is programmed to monitor each group of lanes for congestion.  The left turn lanes are separately monitored from the thru lanes.  When congestion occurs, the system logs the congestion levels, and specifically shows them on a map.  When specific thresholds are exceeded, the system also sends email notifications about a specific left turn or thru movement which has excessive congestion.

How do we do this?

As stated before, each controller's detection inputs are logging congestion data on 5-minute intervals.  That information is uploaded every 5 minutes to the central system via the Ethernet communications.  This is done mostly via fiber optic interconnect or Ethernet radios.  At some remote signals, the communications are accomplished via 3G cellular data modems.  We have had up to 4 signals reporting back continuously via cellular data modems without any problems.

ATMS.now – Congestion Monitoring Configuration

The basic congestion mapping for North, South, East and West is mapped on the scan screen, however functions within ATMS.now allow for additional information to be used for incident triggering.
Below is a picture of NE Hazel Dell at Ne 99th St, showing the detector layout and the basic N, S, E and W congestion mapping.

Screen shot of Naztec ATMS.now central system showing the detection, phasing, pedestrian
and other features.  The green lines with "Occupancy: #" show the percent occupancy during
the approach's phase green + yellow of the stopbar detection for the previous 5 minutes

Each detector used for this function needs to have occupancy, or volume checked in the controller (MM-5-2, Occup and Volum columns).  The reporting period of the detector data needs to be set to 5 minutes in the controller (MM-5-8-1).

Each of the directions need to be associated with the specific detection inputs for the congestion levels.  In addition to the north, south, east, and west congestion levels being defined, the other 4 are defined.

Screen shot of Naztec ATMS.now central system definition of congestion mapping for a
signalized intersection The user has the option of choosing congestion thresholds of
occupancy, volumes or speeds based on specific detection inputs.  The specific
threshold values for "Medium" and "High" correspond to the color of the lines
on the map for the congestion (low is green, medium is yellow and high is red).  The
specific medium and high thresholds also correspond to unique incident triggers
 that the central system can implement.

Under Definitions, Incident Triggers, create the incident triggers for the 8 locations.

Screen shot of Naztec AMS.now showing the incident triggers based on inputs

Note that there are 8 separate congestion alerts for each signal (1 for each left turn, and 1 for each thru movement).  This is true only where separate left turn lanes exist.  In the event that the left is permissive, this tracks the frequency that congestion on the permissive left turn lane exceeds the high threshold as set in the Congestion Level Definition.

One problem with this system is that when a loop fails, and constantly calls, this mapping will generate constant email messages.  If you look at the list above, under 3425, you will see that none of the day of the week boxes are checked (orange oval).  In this case, a contractor cut out the stopbar loops when they were not supposed to, and the controller is running in recall, with the loop amplifiers failing.  To keep the email messages from overwhelming the user, this approach’s two congestion incident triggers were turned off for weekdays.  This provides a good visual indication of where problems need to be fixed in the field.

Under Incident Trigger, create the congestion incident triggers similar to the following.  The text for the box “Description” is important, since this is the specific message provided in the email, and in reports run in ATMS.now.

Screen shot of Naztec ATMS.now incident trigger.  The specific time and dates when the incident
trigger is in place can be customized.  The incident triggers can also be set up based on
alarms or congestion to change the pattern, turn on a CMS sign with a message, turn on a video
camera which has been integrated into the central system software using the IV&C video relay
software, or send out an email notification

In general, the congestion incident triggers only run from 5 AM to 8:59 PM, Monday through Friday.

In the future, additional information will be included, such as camera triggers, to allow for future implementation of automatic PTZ camera viewing of congested areas.

The orientations on the incident trigger congestion and congestion level definition are as follows:

NB - North NBL – North West

SB – South SBL – South East

EB – East         EBL – North East

WB - West WBL – South West

The user distribution is set to Clark TMC Staff

Screen shot of Naztec ATMS.now central system showing how to set up the email alerts to a
specific group of users based on the incident trigger.

When the incident trigger criteria is met, ATMS.now will send an email to the people listed on the Clark TMC staff for the specific approach with the congestion alert.

The email sent will look similar to the following.  Note that the message in the text of the email is what was entered in the “Description” box of the incident trigger definition, plus the date and time.

If you do not populate the “Description” box with enough information, the emails will not have any specific meaning. 

Sample email from central system showing congestion incident

Specific reports can also be run within ATMS.now

Sample report from Naztec ATMS.now showing the reporting abilities

Like other reports in ATMS.now, the text of the report can be exported to Excel, PDF, Word documents and RTF formats, in addition to printing them out on a printer.

Additionally, specific reports can be run showing the relative congestion on specific approaches to the signalized intersections.

Sample of congestion reporting for sample intersection.  The different colored lines
correspond to the  specific occupancies of the stopbar detectors during
green plus + yellow of the signal for that approach's phase.

Conclusion

This is a lot of work to do.  There are dozens, if not hundreds of settings in each controller.  There are thousands of settings in the central system which must be made, and verified.  A detailed understanding of how each controller is connected to the unique detection system in the intersection is mandatory.  After the system is set up, all of the thresholds will need to be verified and adjusted to show what is truly special as opposed to regular congestion.

The net result is that this type of operation in a central system provides invaluable data for understanding where the problems exist regularly as opposed to occasionally.  Also, this type of approach to signal operations provides advance notice that something is happening in the field.  In many cases, the system has told me that something has occured (collision, failed detection etc) via this type of programming, and I am already working on the fix, or in many cases have already addressed the issue before the phone calls come in.