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.

Truck Priority Traffic Signal Operation – a potential opportunity

This post is based on the reader understanding basic and advanced traffic signal controller overlap operations.  These are outlined at:

http://ntcip-unleashed.blogspot.com/2012/02/basic-overlap-information.html

and

http://ntcip-unleashed.blogspot.com/2012/02/advanced-overlap-applications.html

Trucks decelerate and accelerate slower than other vehicles.  The operation described here provides a method to allow the signal to operate such that when a truck approaches a signal at a point where the signal may normally gap out, or max out, the truck will have a better chance of getting through the signal on a green, reducing the frequency of truck stops.

 

In this example, the truck is approaching the traffic signal on a continuous 10% uphill grade.  The continuous 10% uphill grade breaks to relatively flat right at the signalized intersection.  Any large vehicle stopping would have increased difficulty in getting moving on a green indication due to the grade of the street.

 

This is not a sales document.  There are a variety of methods that can be used to determine the classification of the vehicle.  This method uses a Wavetronix HD Count station, located approximately 400 feet from the stopbar down the hill from the traffic signal.  The HD Count Station uses RS-485 communications from the count station to the traffic signal cabinet.  The processing is done within the traffic signal cabinet.

 

More information about the HD Count Station can be found here:

 

http://www.wavetronix.com/en/products/smartsensor/hd

 

In the cabinet, there is a Wavetronix backplane, which provides the power bus and the RS-485 com for the Click! Devices on the back plane.  This backplane also provides power and communications for the Wavetronix Matrix stopbar detection system.

 

One key componenet is the Wavetronix Click! 512 vehicle alert module.  This module was developed for overspeed conditions, not necessarily for truck priority.  The Click! 512 module allows the user to program 4 unique channels of output, where the combination of the HD Count Station and the 512 module will identify a large vehicle, and make different actions based on the speed of that large vehicle.

 

More information about the Click! 512 Vehicle Alert module can be found at:

 

http://www.wavetronix.com/en/support/product_lines/2/products/53

 

When a large vehicle is progressing towards the signal, and passes the HD Count Station, the Click! 512 module determines the speed of the large vehicle, and then places a contact closure output to a Wavetronix 114 detector card.  The relation of the speed range, and which input to the controller is shown on the table below.  These are starting points, based on the HD Count Station being 400 feet from the stopbar.
 

Controller Det Input	Speed Range	Lower Speed	Ph 12 Extension Timing
17	More than 40 mph	60 fps	7 seconds
18	30-40 mph	45 fps	9 seconds
19	20-29 mph	30 fps	13 seconds
20	15-19 mph	22 fps	18 seconds

The extension timing is the controller’s extension timing, such that the controller detection input will call and extend for the time listed, based on one or more truck priority calls.

 

The traffic signal controller operates in USER mode (a modification from the standard 8-phase dual quad operation).  The USER mode is configured such that phase 4 and 12 are sequential, running to overlap 12, through load switch 4.  Phases 4 and 8, and phases 8 and 12 will terminate simultaneously.  This means that when the signal is getting close to gapping out, or maxing out, and a truck approaches the count station, the signal will transition from phase 4 to phase 12, and hold the green for the approach with the truck, while also holding the green for the opposing thru movement. 

 

The phase sequence diagram looks as follows:

If additional trucks arrive while the signal is running in phase 8 and 12, the signal will continue to hold the green until either phase 12 gaps out, or the phase 12 max timer is met.

 

If there is no traffic in the opposing left turn, or on the side street, then the controller may cycle between 4 and 12, based on the actual traffic on the main street.  Even though the signal is cycling between phase 4 and 12, the drivers will not see a change in the state of the indications, since 4 and 12 are run on an overlap through the load switch for phase 4.

 

It is important to keep the min green time for phase 12 relatively short.  The detection inputs for phase 12 are set to call and extend.  If the signal is operating in phase 4 and 8, and ready to gap out, and a truck approaches the intersection via the count station, the count station system places a call to the controller on the specific detection channel associated with the approach speed.  The following will occur within the controller while displays attached to load switch 4 stays green.

 

• Phase 4 times the yellow interval (typically 3 to 4 seconds, depending on what the engineer sets it to)
• Phase 4 times the red interval (0 to 2 seconds, depending on what the engineer sets it to)
• Phase 12 times the min green interval
• The remainder of the phase 2 extension timing occurs

 

If the min green time is excessive, the signal will hold for a longer time than necessary.  For example, if the truck is going 40 mph uphill, the call and extend time on phase 12 is 7 seconds.  This should get the truck to the stopbar at 40 mph.  If the signal is ready to end phases 4 and 8 and move on to 2 and 6, the controller will stay green for load switches 4 and 8, while the call / extension for phase 12 causes the signal to hold that green through the timing of phase 4 yellow and red plus the phase 12 min green time.  If phase 4 yellow is 3.2 seconds, and phase 4 all-red time is 1.8 seconds and the phase 12 min green time is 5 seconds (10 seconds total), the signal will hold green 3 seconds longer than necessary for the truck.  However, if the truck is traveling at 20 mph with the same settings, the extension timing will hold the green for 8 seconds longer than the sum of phase 4 yellow and all-red plus phase 12 min green.

 

There needs to be a balance of the timing that will need to be set by field calibration.

 

If the signal is to be in coordination, Phase 12 will need to be given adequate time in the split divisions to function within the coord plan. 

 

A couple more thoughts about detection diagnostics

This is a continuation of the earlier post on detection diagnostics, at:

http://ntcip-unleashed.blogspot.com/2012/02/controller-detection-diagnostics.html

The detector settings need to be reviewed to make sure that the global settings are not creating undue consequences.

In one recent example, a left turn pocket had moderately high traffic volumes, and the stopbar detector was a 60-ft long quadrapole.  The length of the quadrapole created a situation where there was never a gap in the traffic, so the standard stopbar (standing queue expected) timing of 5 minutes max time / 10 seconds detector fail time, created a situation where the timer for the left turn signal gapped out cycle after cycle.

This was not a new signal, but one where the operation had been changed from one brand of signal to another brand of signal as a part of a systemwide upgrade.  The settings were consistent with the previous brand's operation, but some changes were made in the conversion.

In looking at the new operation, it appeared that the signal was gapping out consistently, but there was a static queue forming.  The signal was gapping out because the detector fail mode was only placing a call for 10 seconds, and if the traffic was over the advanced detector, then the siganl would extend for time beyond the 10 seconds.

After observing the operation for a short while, it was apparent that the signal was not getting enough time for the movement.  Determing the reason for this operation was complicated by the fact that the 60-ft quadrapole also had NTCIP Queue mode turned on.

The detector diagnostics operate on the raw feed of the detector into the controller, not on the processed controller operations of the detector.

After observing the left turn pocket's operation via video feed, some modifications were made to the detector diagnostics from 5 minutes max time / 10 seconds detector fail time, to 15 minutes max time / 20 seconds fail time.

Once the timing changes were made, the left turn pocket cleared out in a few cycles, and began operating as expected.

The moral of the story is that the signal operation needs to be monitored after changes are made.

Why Communicate To Your Signals.

This may seem obvious.  But what needs to be communicated with?  What is appropriate to spend the extra money to purchase the optional Ethernet port on?  When two products are available that meet the specification, and one has data logging capabilities (and costs more), is it worth getting the device with the data logging?

Controller Communications

This is the most obvious one to connect.  Connecting the controller allows for remote uploading and downloading of the controller database, plus monitoring of the controller’s current operation.  If the signal system includes a central system, then the signal can be configured to provide data on scheduled intervals back to the central system.

The data fed to the central system can include alarms, traffic counts, current status of the controller (what phases are green, yellow, red etc.) and other information.  In some cases, the central system can be set up to log this data.  The central system that I use logs a great deal of information.  

One key piece of information that is logged, is the time served for each split division.  This is done whether the signal is in coordination, or free.  This is logged as historical information, so it is easy to run a report to look at what was happening recently for the amount of time served for any or all movements at the signal.  This can be helpful to determine what a reasonable cycle time may be for a signal.  It can also be helpful in determining if there is a problem with a signal.  Citizens will call and make statements about long waits for a green, or that a green was never served for a side street.  I have had phone calls where a citizen stated that they waited 25 minutes for a green.  There may be some truth to that statement, but having the ability to look back on the split division logs allows me to confirm that there was, or was not a problem at the specific time that the citizen stated that they had the undue wait.

The logging of data also helps identify problems with the signal operation.  If a controller develops internal problems, that information may be part of the alarm stream that is reported back to the signal.  We recently had a controller develop a problem with the TS2 communications and the controller started showing thousands of SDLC detector failures an hour.  Since the detector failures are not a critical SDLC problem for the controller, the signal kept chugging along.  A quick review of the alarm logs showed that there was a problem with the signal.  The problem was manifesting itself by causing the signal to extend, and serve movements that had no cars.  Based on the field review of the equipment, it was determined that there was a problem with the controller, and the controller was swapped out.  The BIU’s were swapped out, and the problem continued.  The problem could have been the CPU or the SDLC communications on the 2070-2N connector.  Bench testing will help determine that.  But having the controller connected to the central system gave us the first piece of information that there was a problem.

Another key piece of information is when a signal goes into all-red flash.  When a signal goes into red flash, the central system knows this within a second or two, and within another few seconds the central system sends out an email to key personnel stating that the signal is in red flash.  In some cases, I have seen signals in red flash for several days before a citizen calls in the problem.

Monitor Communications

There is a new generation of monitors generally called smart monitors.  These include advanced features for data logging, communications ports, and special programming to accommodate things like flashing yellow arrow configurations.  Many agencies are still holding on to their old monitors.  The old monitors work, but may not provide the same level of information that the more modern monitors provide.

I have had citizen calls where the citizen states that they are waiting at an intersection, and they are never getting a green.  By checking on the central system, I can see what the system states the controller is telling the system.  By checking remotely on the monitor software, I can confirm that the field indications are consistent with the central system.  

The monitor software allows for remote viewing of the signal inputs and outputs, along with the line voltages.  The picture below shows the Reno AE software talking to a Reno 1600Ge MMU.  This is a static picture, so you can’t get a real feel for the information.  The line voltages are dynamically being updated.  The current greens, yellows and reds are showing up on the screen.

Reno A&E PC software view of monitor operation

Another feature of the monitor software is that when a signal goes into flash, the monitor software can provide very good information about why the signal is in flash.  Is the problem a controller issue, a cabinet issue – that requires somebody to replace a component in the signal cabinet, or a problem with an indication that requires a bucket truck?

Problem Controllers

In the example below, the prior faults log is shown for a Reno 1600Ge MMU.  In this example, the controller CPU was dying. 

Reno MMU reporting a Port 1 failure

A little explanation of the standards is probably in order here.  The NEMA TS2 standards require that if a controller exhibits a Port 1 failure 3 or more times in a 24-hour period, that the monitor latch the signal in all-red flash.  The Port 1 is the main port out of the controller that provides the SDLC communications.  The controller sends out command frames, and gets response frames from the peripheral devices.  This is a very important communications node.  A Port 1 fail would typically be a failure of specific command frames from the controller.  These frames are generally routed around the controller, Terminals and Facilities (T&F, also known as the load bay) BIU’s and the MMU.  When a Port 1 failure occurs, the monitor puts the signal in flash.  If the Port 1 failure clears, the monitor will allow the controller to automatically come out of flash.  If 3 port 1 failures occur in a 24-hour period (also called in some controllers as 3 critical SDLC failures in 24 hours), then the monitor will transition the signal into all-red flash and keep it there until a technician comes by and services the cabinet.

Because the TS2 standard requires that 3 3 port 1 failures in 24 hours occur before the monitor locks the system in all-red flash, you can have a situation where the signal will transition in, and out of flash on its own.  This is not like a CVM fault, or 24V fault, where you can put in jumpers on the MMU board to latch a CVM or 24V fault.  This is a programming issue in the monitor.  To deal with this, many controller software packages allow the user to modify this by having the controller internally latch the signal in red flash when 1, 2 or 3 (user specified) Port 1 failures occur in a 24 hour period.  This will allow the controller to keep track of its own problems, and upon seeing a Port 1 failure, keep the signal in red flash.  This should allow the controller to not bounce in and out of red flash multiple times before going into locked red flash.

In the example above, the controller’s CPU was not working properly.  The controller would lock up, and create a Port 1 fail which the monitor reacted to, then the controller CPU would restart itself, then lock up, creating another Port 1 fail, restart and create another Port 1 fail, at which time the MMU would latch the red flash.

In the attached example, you can see that the controller went into red flash 3 times 8:38 AM and 8:45 AM, then a technician cleared the controller failures, restarted the controller, and the signal worked normally until it went into 2 Port 1 failures (in and out of red flash 2 times) between 3:51 PM and 4:56 PM.  This looks odd, because it looks like it went into red flash twice before it locked this time.  The reality is that I had a replacement CPU in my hand, and had just opened up the cabinet door at 4:56 PM, and the signal went through its restart procedure.  I then placed the signal into cabinet red flash, replaced the CPU, and restarted the signal with the new CPU.

Determining Conflicts

Another example of how the monitor software can help determine what is going on is when a conflict occurs.  In the example below, phases 2 and 6 were green, and the monitor showed that phases 3 and 4 showed green and reds on simultaneously.  This may not be the best example to show, but this was a case where one of the field technicians was working inside a cabinet, and momentarily contacted the greens for phase 3 and 4 to ground, which caused the signal to go into flash.

Reno MMU reporting a conflict

 While this may not be the best example, it does show information.  I got the email from the central system that the signal was in flash, and then almost immediately out of flash.  I pulled up the monitor PC software, and looked at what the monitor said it was doing.  By the time I got the monitor PC software running, the signal was out of flash.  I called the signal tech and asked what was going on.  He was a little sheepish, but told me what had happened.  Nobody got hurt, and the tech got a good reminder that you need to be careful when working around the contacts in a cabinet.

Oddities

One thing that you may see occasionally is the signal going into all-red flash because of a short yellow.  This is rare.  Most traffic signal controllers do not want to have a yellow change interval less than 3.0 seconds.  Some controllers will allow yellow change interval settings at less than 3.0 seconds, but only if the controller is programmed in one place to allow less than 3.0 seconds, and in another place to specifically program a phase to have less than 3.0 seconds.  I have been a traffic engineer for a long time, and have found exactly zero signals where I would time the signal at less than 3.0 seconds of yellow change interval.

The MMU also monitors the yellow change interval.  In the event that the yellow change interval is less than 2.7 seconds, the monitor will place the signal into all-red flash.  This can also be overwritten in the monitor settings, but like the short yellow in the controller, I have found exactly zero signals where I would override this setting in the field.

Below is an example from a traffic signal controller in a cabinet that is in a test environment.  This was forced to a short yellow as a part of testing out some features in the controller and monitor. 

If for some reason the signal actually experienced a yellow of 2.7 seconds or shorter, the signal would automatically go into all-red flash.

Reno MMU reporting a short yellow fault

Having the communications in the field allows the technician to know what has happened to the signal before leaving the desk.  This helps the technician to determine what level of equipment and expertise will be able to fix the problem.

The last example for monitors shows a known problem with the TS2 specification.  This is a minor irritant from a maintenance standpoint, but it may be a bigger deal if you are a pedestrian.

Reno MMU reporting dual indication fault

The NEMA TS2 specification requires that the monitor look at the time that the Flashing Don’t Walk (FDW) is on, and off.  The specification essentially requires that the FDW be turned on for half a second, then turned off for half a second.  The monitors generally allow for some slop in the SDLC communications frames, by allowing extension either of the on or off to 6/10^th of a second.  This is because the controller is driving the outputs, and in the event that a frame is missed, the status of the indication won’t change.

Occasionally, the monitor will see the FDW on or off for 7/10^th of a second.  This is seen as a problem by the monitor, and the monitor transitions the signal into all-red flash immediately.  This extra 1/10^th of a second happens very rarely, but it happens.  In my experience, when a TS2-1 traffic signal is left in ped recall, this will occur about once a month, on one of the pedestrian movements that is in recall.

Video Detection Communications

Cameras fail.  Nature sometimes helps.  What appears to be a good viewing angle when you set it up may be very different at night, or in the rain.  

Cameras fail

The following three pictures show older generation cameras that have problems with the video feed images to the video processor.  When the cameras are not working properly, and feed bad information to the video processor, this defines the term “garbage in, garbage out”.

Problem camera.  Note that the picture is divided where the bottom of the screen shows the far advance, and the left side of the screen shows what should be on the right.  The video detection zones are correct, if the camera were working properly.

Problem camera.  Note how the picture is divided at the bottom of the screen.  The bottom of the screen shows what should be the far horizon of the camera.

Problem camera.  Note how the picture is divided about in the middle of the screen.  The bottom half of the picture should be above the top half.  The zones are correct, assuming that the camera is working properly

These cameras are being replaced.  The key here is, this signal was not connected to any system.  It was a lone signal, with no communications.  The only reason we knew about the problem is because a citizen got frustrated and called in that the signal wasn’t operating properly.  If this signal were connected to the system, we would have been able to look at the operation and see what was working properly and what wasn’t.

Once a week, or more frequently, I spend a chunk of time and pull up multiple signals and look at what they are doing.

In a past job, I found another unique type of problem.  The video detection was not working properly.  It didn’t take long to figure out what was causing the problem.  It probably would have taken a little less time, if I had already had my first cup of coffee before I started looking at the cameras.  In that situation, the video detection cameras were mounted on Astrobrac connections to the mastarms.  During the night, the Astrobrac straps slipped on the mastarm, and the camera swiveled from being on top of the mastarm to being on the bottom of the mastarm, hanging down instead of up.  This caused the camera to go from the normal looking at traffic approaching eastbound to the intersection, to upside down, looking at traffic departing the intersection westbound.  The stopbar detection that the camera was driving didn’t work so well.

Sometimes Nature Helps

Below is a video I took where we had a spider who created a web over the video detection camera lens.  You can see how the spider is causing false calls to the controller.

Below is a video of a poorly placed camera, but showing how the glare of headlights is causing false calls on the detectors.

The key here is to watch the detection zones for the cars traveling north (almost straight up) in the picture.  The glare from the southbound headlights does not cause false calls in the two northbound detection zones.

The two northbound detection zones are count stations.  I experimented with how to deal with the oblique angle, and headlight glare.  The remote video feed allowed me to modify the detectors and try things to see what happened in multiple weather and lighting scenarios.  

There are actually two detectors in each northbound lane of travel.  The large, visible, box is a directional detection zone.  This box is looking only for traffic heading northbound.  Any glare from a southbound vehicle’s headlights don’t cause a true condition in the Boolean logic in the detection scheme.  When a northbound vehicle causes a True condition in the box, and then the vehicle crosses an invisible line at the far north end of the box, then the detection system places a call.

Having remote communications to the video detection system allows me to test a variety of ideas in vehicle detection strategies, and observe them in various weather and lighting conditions.  Based on the glare on the wet pavement from the overhead luminaires I moved the detection zones around into the glare, out of the glare, and observed how the system operated.  Based on this, I was able to hone in on a detection strategy for this particular brand and model of video detection system that works for multiple situations.

Conclusions

These are just a few examples of how communicating to the field equipment can provide significant benefits.

The main benefit is being able to see what is going on from your desk.  In my case, I can VPN into the system and see what is going on.  Last year, I was visiting family in Idaho, and received a call that there was a problem with a signal that was under construction.  I pulled out my laptop, connected it to my MiFi card, and was on the system within 5 minutes – from Lewiston Idaho.  It took about another 3 minutes to figure out that the contractor had shifted traffic from the normal lanes to another area of the pavement that had no detection.  I modified the radar stopbar detection and in about 15 minutes total, I was back on the phone to the construction manager telling him what I had done.  He reported to me that the signal appeared to magically begin working properly.

Magically.  I like that.  Magic is how things are explained that happen mysteriously that we can not explain with other knowledge or understanding.

Easing the effects of phase rotation during coordination

In general, when a signal is coordinated, and you want to have the coord plan switch from leading to lagging protected lefts, the signal must go free for a cycle to enable the phase rotation, even though the cycle length and offset may be the same.

This is problematic since the controller will need to go into offset seeking mode for between 2 and 3 cycles to get back in step, when the signal transitions from one plan to another.  If the controller is running a 2 minute cycle that means that the signal is likely out of step to some extent for up to 6 minutes.  When you add needing to go free for a short while before changing your coord plan to allow the phase rotation to occur, this creates a rather long time to be out of sync with the other signals.

For example, given the phase sequence below, assume that phase 3 needs to be a leading protected left, some times of the day, and a lagging protected left during other times of the day.

Standard NEMA Phase Sequence Diagram

Every time the controller needs to shift from leading to lagging protected left, the time of day plan requires that the controller run in free operation for a short while followed by the specific action plan that allows the controller to shift the phase rotation.

Since the controller seeks to change its operation at the local zero of the cycle length, not the top of any minute, the Time of Day Plan will likely need to have the length of the free time be the number of minutes of the current cycle time, rounded down, plus one minute.  This is to make sure that the coordinator does not skip the free cycle action plan because the local zero occurs after the Time of Day’s free action plan, and after the Time of Day’s new coord plan.  Alternately, if you are really into math, you could calculate if each specific free cycle in the action plan will need to be 1 minute, 2 minutes or 3 minutes long and not be walked over the new coordinated action plan in the scheduler.  Good luck with that on a system wide timing program.

Since the controller needs to waste time it could be in coordination to go free, then go into offset seeking mode to do a phase rotation, why not use the power of your NTCIP controller to let it just switch plans, and inhibit or enable specific phases by time of day in your coordination plan?

For this example, Phase 3 needs to be able to be lead, or lagged by time of day.  Preferably, the lagging left would be inhibited during non-coordinated hours of operation.

This is done via overlap programming.  Instead of having phase 3 routed to load switch 3, phase 3 and phase 11 (the lagging phase corresponding to phase 3) are enabled through overlap 11, to load switch 3.  Generally, when I do this type of operation, I do not use overlaps 1 through 4 (also known as overlaps A through D), as these are commonly used as right turn overlaps.  Generally, overlaps 5 through 16 are rarely used.  For convention, I use the secondary phase number as the parent phase plus 8, and the overlap number to equal the parent phase plus 8 (hence phase 11 and overlap 11).

The new phase diagram looks like:

Modified NEMA Phase Sequence Diagram for Lead / Lag Protected Left Operation - By Time of Day

 The controller needs to be programmed to enable phase 11.  Phase 11 also needs timing values.  Special care needs to be provided to make sure that the timing values for yellows and reds match between phase 11 and phase 3.   The specific overlaps, compatibility tables, phase sequence operations etc need to be programmed to allow phase 3 and phase 11 to both be independently operate.  Specific care also needs to be given to make sure that the controller will not try to override the yellow and red times for the phases with the programmable overlap yellow and red times.

The Time of Day plan will call specific Action Plans that will enable phase 3 and omit phase 11, or omit phase 3 and enable phase 3.  

What about Cycle Fault and Cycle Fail for the controller operation?

Cycle Fault and Cycle Fail are functions of the controller that monitor if specific vehicle phases have calls that have not been served for some period of time.  The controller can be programmed to either go into all-red flash, or free, based on the lack of service of calls.  Generally, Cycle Fault is for coordinated operation, Cycle Fail is for free operation.

The way to deal with this is to program the detector tables, and use alternate detector tables.  The Action Plan must call either the normal detector table, or the alternate detector tables.  The NTCIP standards allow for multiple detector tables, which can be called by the Action Plan.

For example, the normal detector plan may have the detection for phase 3 be detector inputs 18 and 19.  The normal detector plan would have detector inputs 18 and 19 programmed with the proper call and extend features for phase 3.  The alternate detector plan would have the detector inputs 18 and 19 programmed with the proper call and extend features for phase 11.

Since the normal plan only affects phase 3, and the alternate detector plan only affects phase 11, the controller won’t experience Cycle Fault or Cycle Failure, as long as the Action Plans and Coordination Plans are properly programmed.

Documentation

Another extremely important portion of this operation is that it must be very well documented, and the technicians who are performing the maintenance must be aware of the special operation.

For example, if the loops in the phase 3 / phase 11 are cut, and the signal techs decide to put phase 3 in recall and turn off the failing detectors, the signal will only call phase 3, not phase 11.

It is important to understand how your particular controller deals with global vs. Action Plan settings.  All controllers have the ability to be put in ped recall, or various types of vehicle recall.  In some cases, the Action Plan, or the Coordination parameters may override the global settings.  So you may put a controller in MAX recall for the phase 2 main street green, but if the coord plan has the phase 2 main street has MIN recall for several of the coord plans, your MAX recall may become MIN recall.

It is important to understand how this works within the coord plans of your controller.  For the example of the cut loop for phase 3, you may need to go into each specific Action Plan and Coord Plan and set each specific plan to the specific recall you need for that set of active phases.

Conclusion

This offers a method to operate the signals in what could be a more efficient operation, if you have traffic signals that are in coordination and need phase rotation.  There are lots of things to make sure are programmed correctly.  If they are not, you will get twice per cycle phase operation, or maybe no phase operation by certain times of the day.