Controller Detection Diagnostics

Improving your controller operations

A traditional problem with vehicle detection is when vehicle detection fails, causing constant calls into the traffic signal controller, causing the signal to hold for long periods of time for phases without any actual vehicles on the detection for those phases.

One underused feature that can reduce the effect of, and provide automatic reporting of these problems on many traffic signal controllers are vehicle and pedestrian detection diagnostics. Various versions of detection diagnostics have been on traffic signal controllers for many years.  Detection diagnostics are now defined as a standard requirement under NTCIP section 1202.

Essentially, there are several diagnostic parameters that can be assigned to each detection input, and each pedestrian input to the controller. Depending on the function of those parameters the controller can modify the operation of the detection input automatically, and forward alarms to a central system when the problem occurs.

So why do this?

Stuff happens.  Simple as that.

Detectors fail.  Utilities cut loops.  People park inside detection zones.  Sometimes other things happen that can not be engineered around.  In the attached video, a spider has build a web in front of the video detection camera.

Some agencies now use IMSA 51-3 or 51-7 loop wire.  Many agencies use single jacketed loop wire.  Why is this important?  Pavement is flexible.  It may not seem so, but as vehicle drive over the pavement, the weight of the wheels pushes the pavement around.  This minor nudging happens hundreds of thousands of times per year, and the loop may be in the pavement for several decades.  A single jacketed wire will directly put the pavement stress onto the loop wire.  Eventually, the loop wire's jacketing will crack, and allow water to migrate into the crack, onto the copper wire.  The copper wire will ultimately corrode, but in the near term, the water will short out the loop causing intermittent problems that occur only after rain - until the wire is corroded to the point where it will no longer conduct the electricity needed for the loop amplifier to function.

Using the IMSA 51-3 or 51-7 wire improves the loop life.  These wire types are double jacketed, with the inner jacket being cross linked polyethelene (XLPE).  The wire manufacturer shoots X-rays at the polyethelene jacket as it it comes out of the extruder.  The XLPE is exceptionally tough.  IMSA 51-3 wire has a second jacket, with no air core.  IMSA 51-7 has a second jacket with an air core.  We use 51-7 to further reduce the stress on the wire.

Additionally, the loop wire is spliced to home run cable in a junction box.  The junction box may be dry, it may be completely submerged.  The splice is a physical connection of two different wires within an enclosure.  Water migrates into the splices, causing corrosion and failure.

Other types of detection have problems too.  Video fails.    In the video to the right, snow is causing a failure of the video detection system.


Radar fails.  

The traffic signal controller is designed to act a specific way when it sees a problem with the vehicle detection.  When the detector has a problem, the signal will automatically call the specific vehicle movement that the detector was assigned to, and hold that call for a maximum amount of time.  That is why sometimes, you drive up on a signal on the main street in the middle of the night, and the signal is holding for the side street for 40, 50, 60 seconds or longer.  It is likely that one of the vehicle detectors has failed on the side street, and the traffic signal is screaming for attention.

NTCIP Discussion

For vehicle detection, NTCIP defines three mandatory parameters which include No Activity, Maximum Presence and Erratic Counts. NTCIP also defines an “optional” detector fail time parameter. Since this feature is optional, your controller may, or may not include this. Specific controller manufacturer may have additional features. Specific controller manufacturers may also have expanded functionality on the basic NTCIP parameters that will help provide further improved operations.

• No Activity – This parameter allows the controller to monitor each detection input for lack of detection input, from 0 to 255 seconds. This parameter can be useful in finding if a specific detection input has a lack of any calls. This parameter can be tricky to use, as if the detection on an approach actually has no calls, using this feature may falsely report problems.
• Maximum Presence - This parameter allows the controller to monitor if a detector has been constantly active for between 0 and 255 seconds. This parameter is very useful in identifying vehicle detection that locks on, because of problematic video detection, or bad loops, or where you have cars that may park on detectors.
• Erratic Counts – This parameter allows the controller to monitor if the detector has been receiving excessive actuations, ranging from 0 to 255 counts per minute. This parameter allows the controller to monitor if a detector is chattering the call into the controller input. This parameter is very useful in finding where the vehicle detention is erratically chattering the input into the controller.
• Detector Fail Time – This parameter is an optional parameter, which allows the controller to modify the operation of the detector that has failed any of the three detector parameters. If any of the detector diagnostics failed, the controller will place a call on the assigned phase during all non-green intervals, and then hold that call for the user specified time under this entry, from 0 to 255 seconds.

In general, when I am setting up detection diagnostics in a traffic signal controller, I use the following general parameters as a starting point.

Parameter	Stopbar (no standing queue expected)	Stopbar (standing queue expected)	Advanced	System Detectors
No Activity	0 minutes	0 minutes	0 minutes	0 minutes
Maximum Presence	3 minutes	5 minutes	3 minutes	2 minutes
Erratic Counts	90 cpm	90 cpm	120 cpm	90 cpm
Detector Fail Time	10 seconds (side street) 15 seconds (main street)	10 seconds (side street) 20 seconds (main street)	10 seconds (side street) 20 seconds (main street)	0 seconds

The parameters above are monitored, and adjusted to fit the needs of the intersection.

Detection diagnostic parameters are most useful when each unique physical vehicle detector has a unique detection channel in the controller. There is also benefit where groups of physical vehicle detectors are ganged up in series / parallel to a vehicle detection input on the controller.

Some controllers allow different detector patterns by time of day.  Many of these controllers allow alternate detection diagnostics by time of day.  This may allow the signal to test for lack of calls on any vehicle detection during the busy times.  It would not make sense to have no calls on a main street detector during the peak hour, but it may make sense that at 2:00 AM, it may be 5 minutes or more between vehicle calls.

Central System Communications

This really only helps if you ask the controllers what they are doing.  If there is no communications to the controller, there is no way to know if the detection is failing or working properly, unless you drive out to the signal, and stand and watch the detectors and controller.

Wherever possible, the controller should be connected to communications (Ethernet (fiber optic, VDSL, radio, CDMA modem) or telephone dial up, to allow the signal to report back what is going right, and what is going wrong.  This also requires that the controller sends alarms to a central system.

If the system is reporting something wrong, crews can be dispatched to fix problems.