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.

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.

Pedestrian Detection Diagnostics

One really nice feature of the new generation of controllers is the ability to assign pedestrian diagnostics.

One traditional problem with traffic signals is that a pedestrian pushbutton will become stuck, causing the signal to constantly cycle pedestrian WALK and FDW, without any pedestrians.

This is not to be confused with actuated rest in walk, or pedestrian recall.  In some cases, traffic signals are purposely set up to always bring up a WALK.  This can be very helpful in a downtown central business environment, or where there are no pedestrian pushbuttons, or where the pedestrian movements are typically heavy enough to justify constantly bringing up pedestrian movements.

At other traffic signals, like near schools, it is normal to have the traffic signal go into pedestrian recall automatically by the time of day programming during the times when pedestrians are likely to be crossing - such as during the half hour before, and half hour after the school is in operation.

Why Pedestrian Detection Diagnostics Are Important

Traffic signal controllers have specific needs in the coordination operations to make sure that under normal circumstances, the sum of the WALK, FDW, Yellow plus All Red equals the split division for that vehicle phase.  This means that under normal operations, the cycle lengths can become really long to accommodate all of the normal pedestrian timing needs.  This is getting even more problematic with the adoption of the 2009 MUTCD, and the recommended slower pedestrian speeds for the FDW timing.

Generally the corridor's timing needs are set by the largest intersection on the corridor.  All other signals have to be timed to have the same cycle length as the largest intersection, so the corridor may normally only work with a very long cycle length because of the needs of the largest intersections on the corridor.  While a huge intersection may need a 150 second cycle length to work within all of the timing parameters in the corridor,  other intersections may better work at a 90 or 100 second cycle length for most of the day.

For many years, controller manufacturers have put in "cheats" or "special features" to allow the signal to be tricked into allowing split divisions that are shorter than the sum of WALK, FDW, Yellow and All Red.  The Traconex 390 would allow these short split divisions, and give a special controller error, that allowed the controller to fail the edit checks for the split divisions, but stay in coordination.  Naztec has a "Stop In Walk" feature, that when enabled, times the split division normally until the split division timing equals 0, then the controller places a modified stop time into the program, and finishes timing the FDW, Yellow, and All-Red, then transitions to a special, aggressive, offset seeking mode to get back in coordination within a single cycle.  Other controllers have similar features, with different naming.

The special feature allows the controller to have the normal timing parameters running, but may allow a signal that wants to run on a 140 or 150 second cycle length to run at 90 second cycle length or shorter.  This will be true only if there are relatively low volumes of pedestrians.

This whole system falls apart if the signal has a stuck pedestrian pushbutton.  If the traffic signal needs 45 seconds for the sum of WALK, FDW, Yellow and All-Red, the split division is 25 seconds long for that movement and the signal is running on a short cycle length (90 seconds) then the signal will always be out of step, and in offset seeking mode.

The pedestrian diagnostics allow the signal to generate an alarm.  In the case of the signals I operate, the alarm is important enough, that the central system is constantly looking for these alarms, and when they occur, the central system automatically forwards an email to my work email to inform me that there is a problem with a stuck ped pushbutton.

Pedestrian Diagnostics by NTCIP

The NTCIP standards allow for special diagnostics to be run in the controller, similar to the vehicle detection diagnostics.  These are covered under NTCIP 1202 Section 2.3.7.3 Pedestrian Detector No Activity Parameter, Section 2.3.7.4 Pedestrian Detector Maximum Presence Parameter and Section 2.3.7.5 Pedestrian Detector Erratic Counts Parameter.  The reporting is covered under Section 2.3.7.6 Pedestrian Detector Alarms.

The three types of pedestrian detection parameters are defined as follows:

• "Pedestrian Detector No Activity diagnostic Parameter in minutes (0–255 min.) . If an active detector does not exhibit an actuation in the specified period, it is considered a fault by the diagnostics and the detector is classified as Failed. A value of 0 for this object shall disable this diagnostic for this detector."
• "Pedestrian Detector Maximum Presence diagnostic Parameter in minutes (0-255 min.). If an active detector exhibits continuous detection for too long a period, it is considered a fault by the diagnostics and the detector is classified as Failed. A value of 0 for this object shall disable this diagnostic for this detector."
• "Pedestrian Detector Erratic Counts diagnostic Parameter in counts/minute (0-255 cpm). If an active detector exhibits excessive actuations, it is considered a fault by the diagnostics and the detector is classified as Failed. A value of 0 for this object shall disable this diagnostic for this detector."

Recommended Settings

An important thing to understand about the pedestrian diagnostic parameters is that if you set any values, and the thresholds are met, the controller will place the signal in pedestrian recall until the problem goes away.

The Pedestrian Detector No Activity diagnostic Parameter is one that I generally don't touch.  After I explained the operation of pedestrian diagnostics to a friend who worked for an agency in Alaska, he put them into the signal.  Then all of the signals went into pedestrian recall late at night.  The problem solution was really tricky to figure out... Another person got the call out in the middle of the night, knew nothing about the special controller settings, and was completely baffled about why all of the signals were in pedestrian recall until a pedestrian pushbutton was pushed, then it went away...  They went to the next signal, pushed the buttons, and the problem went away.  Went to the third signal, pushed the buttons and the problem went away, but by that time, the detection error had reset itself (no other pedestrian buttons pushed at the first signal because it was in the middle of the night), so the first signal went back into pedestrian recall.

You can imagine the conversation in the signal shop the next morning.  It probably started with "What the..." and went downhill from there.

In general, I only set the Pedestrian Detector Maximum Presence diagnostic Parameter.

Generally, I set the max presence to 3 minutes.

The thinking is that somebody may push in a button, but not likely for more than 3 minutes.

I generally don't set the erratic counts.  I need to see how that works, where you have a button where the pedestrian pushes the button over and over again.


Other Pedestrian Detector NTCIP Stuff

The error states of this are defined as follows:

     Bit      Definition
     0         No Activity Fault: This detector has been flagged as non-operational due to lower than expected activity by the CU detector diagnostic.
     1         Max Presence Fault: This detector has been flagged as non-operational due to a presence indicator that exceeded the maximum expected time by the
               CU detector diagnostic.
     2        Erratic Output Fault: This detector has been flagged as non-operational due to erratic outputs (excessive counts) by the CU detector diagnostic.
     3        Communications Fault: Communications to the device (if present) have failed.
     4        Configuration Fault: Detector is assigned but is not supported.
     5-6     Reserved.
     7        Other Fault: The detector has failed due to some other cause.
     Once set a bit shall maintain its state as long as the condition exists. The bit shall clear when the condition no longer exists."

NTCIP Detection Settings

NTCIP Standards

The 1202 NTCIP standards allow for additional information to be provided by the detectors to the controller.  This allows the controller to display detector errors in addition to logging failed detection.

Under the 1202 section 2.3.2.13 Vehicle Detector Reported Alarms, the following as a mandatory data type.

     "This object shall return detector device reported alarms (via some communications mechanism). Inductive Loop Detector Alarms are indicated as follows:
     Bit     Definition
     0       Other
     1       Watchdog Fault: This detector has been flagged as non-operational due to a watchdog error.
     2       Open Loop Fault: This detector has been flagged as non-operational due to an open loop (broken wire).
     3       Shorted Loop Fault: This detector has been flagged as non-operational due to a shorted loop wire.
     4       Excessive Change Fault: This detector has been flagged as non-operational due to an inductance change that exceeded expected values.
     5-7    Reserved
    Once set a bit shall maintain its state as long as the condition exists. The bit shall clear when the condition no longer exists."

This may be a mandatory data type, but it only works if the communications between the controller and the loop amplifier is a data stream, instead of a wire with an ON / OFF switch.

TS2'ish Standards Within the NTCIP Requirements

Under the 1202 section 2.3.5.4.2 Occupancy data standard,  the detector provides the following information to the controller.

     Range      Meaning
     0-200       Detector Occupancy in 0.5% Increments
     201-209   Reserved
     210           Max Presence Fault
     211           No Activity Fault
     212           Open loop Fault
     213           Shorted loop Fault
     214           Excessive Change Fault
     215           Reserved
     216          Watchdog Fault
     217          Erratic Output Fault
     218-255   Reserved

The table above is essentially an continuation of the TS2 standards. 

This really only works if the controller has the ability to transmit not only the fact that the detector channel is on, or off, but provides a bit stream of data to the controller.  This can be done with TS2 detection, but not with TS1 or standard CalTrans 332 data.

By using the TS1 or 332 standard for detection, the detector provides a contact closure on a wire to an input on the controller.  This is either on, or off, not a system of transmitting data.

TS2 Detection Provides Better Intelligence 

With the TS2 standard, the serial communications transmits data streams between the equipment, which allows for more than an on / off switch, like the TS1 or 332 data.  The TS2 data stream is more robust, allowing for one set of bits to say one of the following messages

• "I was off, and I am still off"
• "I was off, and I am now on"
• "I was on and I am not off"
• "I was on, and I am still on"

along with a lot of other information, including the bits to define the data range from 0 to 255.

This is helpful for a bunch of reasons.  When any controller is talking to a central system, the controller and central system can be set up to log the detector failure status - based on whatever detection diagnostic parameters are programmed into the controller.  The TS2 controller can not only provide the fact that the diagnostic has failed, but it can also tell you what failed (see codes 210 to 217 from the list above).

This means that with a TS2 controller that is reporting back to a central system, the signal can provide actionable information to the engineer and technician to determine what the problems are, in addition to the fact that there is a problem.

It is a straightforward prospect to determine what has gone wrong, and help the fixing of a problem...  Is it a cut wire, or is it a splice?  Knowing in advance what happened to the loop can be the difference between going out to fix the problem, and then going back to get the proper equipment, or knowing that you need to schedule a loop cutter.  Since this data can be recorded in the central system, the user can run reports and determine what should be done system wide, and most importantly, find a bunch of loops that need to be replaced quickly, and efficiently - but only if the controller gets the coded information.  This is why we are looking at putting TS2 detection into 332 cabinets.

Detector Reset

Another TS2 / NTCIP standard requires the remote resetting of detection amplifiers.  Some controllers do this.  Many don't, even when they say they are "NTCIP" or "TS2".  I asked one controller manufacturer (who will remain nameless) why their controller and central system did not allow for remote resetting of detection amplifiers, even though they stated that they were fully NTCIP and TS2 compliant.  The response was "Nobody ever asked us about that".

From NTCIP 1202 section 2.3.2.14, Vehicle Detector Reset, there is a mandatory requirement that the detectors can:

"This object when set to TRUE (non-zero) shall cause the CU to command the associated detector to reset. This object shall automatically return to FALSE (zero) after the CU has issued the reset command. NOTE: this may affect other detector (detector channels) that are physically attached to a common reset line."


Other Reasons Why Data Is Better Than On / Off Switches

There is another reason why the TS2 detection is helpful.  Most NTCIP based controllers keep a log of the failures, including the detection failures.  One of the things that happens quite often, is an engineer or technician opens the door up, and they want to clear a fault by pulling the detector card, and resetting it...  Hopefully, the fault goes away.  What if you want to know what the reason was for the fault, after you cleared the card?

Since this information is kept in the controller, in a log, the engineer or technician can navigate through the controller menu to get to the logs, and see what the problem was.  In my case, we use Naztec Apogee software, so the code is reported as a hexadecimal code, not an easy number.  That is why I have a cheat sheet with me...

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.

Basic Overlap Information

What is a vehicle overlap?

A vehicle overlap is a specific operation of a traffic signal controller where a signal indication can be provided a continuous green through multiple timed phases.  These phases may be sequential, but they don't have to be.

Generally, overlaps fall into one of several categories.  Each manufacturer has a myriad of specialized operations.  The general uses of overlaps include:

• Parent / Child Overlap (also called a right turn overlap)
• Independent Overlap
• Negative Overlap
• Flashing Yellow Arrow Overlap

There are other uses for overlaps that I will describe in later blog posts.  

Generally, the overlap provides a way to get better operations out of your traffic signal.

Original Implementation

In the original NEMA TS1 standard, the basic controller operation did not include overlaps.  The overlap was accomplished by a module that could be added to a TS1 controller.  In this case, there are only 4 overlaps available (typically called Overlap A, Overlap B... Overlap D).  In some cases, agencies created their own modules by using external logic packages using AND and OR gates to create situations where overlaps could be hardwired to specific controller outputs, then to the load bay.

New Implementation

The NTCIP standards allow for 16 overlaps.  This may seem excessive, but there are good reasons to have more than 4.  In future posts, I will explain how the additionally overlaps can be used to greatly increase the efficiency of the traffic signal.

In the NTCIP language, the overlaps are numbered, not lettered.  They are Overlap 1, Overlap 2, ... Overlap 16).  Many controller manufacturers call them both Overlap A and Overlap 1, just to keep the signal engineers and technicians in language they are used to using.

Parent / Child Overlap (AKA right turn overlap)

This is a very standard overlap use.  In this type of case, there is dedicated right turn lane, that you want to signalize with a right turn arrow - AND the cross street has a corresponding protected left turn.  The Parent / Child overlap allows the right turn traffic to continue flowing, when the adjacent thru traffic is going, and to continue when the signal stops the adjacent thru traffic to serve the side street left turn traffic.  Care needs to be taken to make sure that the protected right turn arrow overlap does not create a problem for pedestrians.  See Negative Pedestrian Overlaps, below.

There is a similar looking operation, but different, where some agencies install a 5-section protected / permissive indication, where the top three circular indications (red, yellow, green) are wired to the thru movement wiring, and the bottom two arrow indications (yellow, green) are wired to the corresponding cross street left turn indication wiring.  This will not allow the signal to provide the simultaneous green ball and green arrow for the right turn movements.

The use of an overlap can help the overall traffic progression through the intersection (emphasis on "can").

So why not do this everywhere?

In order to implement this type of overlap, you need to have some specific things in place.

You need a signalized intersection, that has an dedicated right turn lane, plus the side street traffic must have a corresponding protected left turn lane. Protected left turn signal operations can be less efficient than protected / permissive, or straight permissive operations. Extra right turn lanes take extra land, which costs more to purchase, costs more asphalt (which costs more to construct and more to mitigate stormwater for), requires bigger traffic signal poles and mastarms (more $$ again) and almost always increases the size of the intersection - which directly affects the signal timing parameters.

Like anything, it has pros and cons. Where applicable, the right turn overlap may be a really good idea, if (a) you can afford it, (b) you can make the lane long enough to extend beyond the back of the queue of thru vehicles, and (c) it makes sense from a pedestrian and vehicle perspective. 

Independent Overlaps

Independent overlaps are also known as "Timed Overlaps" or "Double Clearance Overlaps".  They are used where you have one traffic signal controller that is operating two sets of lights for the same vehicle movement, and one set of vehicle indications goes yellow and red before the other set of vehicle indications.

One example of where this is use is at some freeway interchanges (typically Single Point Urban Interchanges, or SPUI's) they can be used to help clear the huge intersections more efficiently. In some SPUI's, there are two sets of signal heads for several vehicle movements. The leading signal heads are driven by the overlaps, the signal heads inside the intersection are driven by the phase movements. When used with Optically Programmed Signal heads, the use of overlaps allow the approaching driver to be shown that the signal is transitioning from green to yellow, while the driver within the intersection would be shown a different length of yellow and all-red. Subtle, but sometimes important.  This is typically done so that the drivers approaching the stop line can be told that the signal is turning yellow, but the vehicles inside the intersection are still provided a green by the second set of intersections within the interchange.  This operation does not decrease the efficiency of the signal, but do help with driver information, to reduce the potential that a driver is surprised by a yellow while they are in the large intersections

For Tight Diamond Interchanges (TDI), sometimes a single traffic signal controller controls both traffic signals at the intersection. The use of overlaps allows the signal to provide a red to the first signal you approach, while continuing to flush the next signal with a green. Once again, subtle, but rather important to keep the intersection from going to gridlock.

Overlaps also allow for some pretty complex operations at traffic signals.

One case that I recently designed and turned on, we had a "T" intersection with a slip lane on one approach. We wanted to keep the traffic moving on the slip lane, and be able to allow the signal to select the other movements as necessary. The extensive use of overlaps in the signal operation allows the signal to maintain the slip lane, and choose alternating lefts and rights while keeping the signal in the NEMA Dual 8-phase quad operation, which is the only way that this particular controller likes to operate in coordination.  This was especially important because the traffic signal controller was an older generation NEMA TS1 controller, and there were few tools within the controller to help with the signal's operation.  Also, this particular brand and model of controller would only operate in coordination if it was running in dual quad operation.

In another case, I designed a signal where there was one controller / cabinet operating two closely spaced intersections.  By using overlaps, I was able to get each of the signal indications for the nearside intersection's thru movement to go yellow by a user specified amount of time prior to the far side signal going yellow.  This created a situation where cars were not stranded in between the signalized intersections.  Likewise, when the signals went green, the far intersection's signal went green prior to the near intersection's green to get the traffic moving more efficiently.

Negative Overlaps

There are several reasons why overlaps need to be given rules.  Negative overlaps allow the controller to have rules to increase the flexibility, and efficiency, while not allowing some things to occur that may be undesirable.

It is important to consider how the overlap will operate when there is a pedestrian movement adjacent. For instance, if the right turn overlap is to operate with the northbound thru movement, and the westbound left turn movement, the overlap needs to not conflict with a pedestrian movement operating at the same time as the northbound thru movement. You don't want the right turn green arrow to operate across a pedestrian walk / don't walk as this would be a conflicting movement.

Some traffic signal equipment is capable of operating a "negative pedestrian overlap", or a "minus pedestrian overlap", which allows the traffic signal equipment to process the presence of a conflicting pedestrian movement, and provide different vehicle indications based on what is going on with the pedestrian indications.

Several traffic signal controllers currently being sold now don't have the ability to operate in a minus ped overlap operation. Several manufacturers have traffic signals that state that they do, but in actuality, there are some quirky things in the operation.  To get around this, some agencies implement a quasi overlap type of operation, by directly connecting the right turn green and yellow arrow electrical wires to the side street left turn protected movement, and providing a green ball to the right turn movement when the signal provides a green ball to the adjacent thru movements. This can be a little herky-jerky, as the traffic in the right turn lane can observe their green ball indication go from green ball, to yellow ball, to red ball (same as the thru movement), then after the end of the all-red clearance interval, the right turn indication would then turn to a right turn green arrow when the side street left was provided a left turn green arrow.

Some controller manufacturers can have unexpected, problematic issues with minus ped right turn overlaps.  Testing of the current version of controller firmware is essential.  Also, it is essential that the conflict monitor / malfunction monitor unit in the cabinet must monitor for the vehicle yellows against the pedestrian WALK / flashing DONT WALK.   Some controllers are loose when they apply the pedestrian call, causing problems.

Generally, controllers decide what phase to operate next immediately prior to the beginning of the yellow for the current phase.  Some controllers will allow for a late pedestrian call to be registered which can cause a conflict.  One controller with an official firmware version offered by the (un-named) manufacturer that I use actually will accept a pedestrian call after the phase next has been selected.  This means that if the pedestrian call is placed in the last second or two of the all-red phase of the thru movement, the controller will serve the pedestrian movement with the onset of the associated green phase, while simultaneously timing down the yellow for the adjacent overlap.  Essentially, this is a technical way of saying that the controller software allows for the controller to create a conflict that is only evident if you are paying attention, while simultaneously displaying a pedestrian WALK plus a conflicting right turn yellow arrow.  This is a conflict.  We caught it because our monitors are all set to monitor the presence and absence of all green, yellow, red, WALK flashing DONT WALK and steady DONT WALK indications.  We turned on four signals in four days, with the official software, and found that we had signals going into all-red flash every couple of hours. 

Other Uses For Overlaps

In future posts, I will describe how overlaps can be used for very specific operations, to allow coordinated operations with queue sensitive early release, asymmetric double cycle, queue sensitive dynamic lagging protected lefts, lead plus lag protected left turns and other operations.

We have one signal that will be modified this year where we are relaying the presence of queued vehicles at one intersection, to cause an early release at an upstream intersection, all based on overlaps.

Stay tuned.  That is where it gets really cool

Traffic Signal Operation - Signal Phases

What is a traffic signal phase?

A phase is a specific movement that has a unique signal indication.

If you have a four legged intersection, with protected left turns in all directions, the signal would be called an "8-phase intersection".

If the intersection has four legs, with protected left turns on the main street, but permissive left turns on the side street, the signal would be called a "6-phase intersection".

IF the intersection has four legs, with permissive left turns on all approaches, the signal may either be called a "4-phase intersection", or possibly a "2-phase intersection". In most cases, calling this type of intersection a 2-phase intersection is an oversimplification of how the signal actually operates.

What does this mean?

The traffic signal controller processes the request for green in a very specified, logical, manner. The logic is not always apparent, especially when you want to go, and you keep getting a red light.

Modern traffic signal controllers are relatively powerful control devices, but they are... computerized control devices, and they are specifically designed to operate as safely as possible in a very ordered fashion.

The traffic signal controller doesn't know if you are in a hurry, or if you are busy changing a CD in your car's radio, or for that matter, both at the same time. The signal processes the input information and makes decisions on a industry standardized method of decision making.

The following diagram shows the basic phase sequence diagram for a specific signal.

Straigh forward phase sequence diagram

A little explanation is in order.

Most modern traffic signals operate with what is sometimes termed a 2-ring, 8-phase dual quad operation.

In essence, phases (the funny looking o with the slash in the middle) 1, 2, 3, and 4 are in ring 1. Phases 5, 6, 7 and 8 are in ring 2. The traffic signal can present a green to only specific movements at the same time.

Say what?

The traffic signal is capable of showing any combination green indication to any single movement in ring 1, and any single phase in ring 2 at the same time. The traffic signal is prohibited from showing more than one phase a green indication in the same ring at a time.

Between phases 2 and 3 (and 6 and 7), there is a barrier. The barrier is a programmed requirement. The traffic signal must terminate the phases in ring 1 and ring 2 on one side of the barrier before continuing to the next side of the barrier. Likewise, there is a barrier on the right side of phases 4 and 8.of green indications to the following at the same time:

• Phases 1 and 5 (usually opposing left turns)
• Phases 1 and 6 (usually one left turn, and the adjacent thru movement)
• Phases 2 and 5 (one left turn and one adjacent thru movement)
• Phases 2 and 6 (two opposing thru movements)

Both the phases on the left side of the barrier in Ring 1 and Ring 2 must transition through the barrier simultaneously to continue

• Phases 3 and 7 (usually opposing left turns)
• Phases 3 and 8 (usually one left turn, and the adjacent thru movement)
• Phases 4 and 7 (one left turn and one adjacent thru movement)
• Phases 4 and 8 (two opposing thru movements)

Both the phases on the right side of the barrier in Ring 1 and Ring 2 must transition through the barrier simultaneously to continue with phases 1, 2, 5 and 6 again.

Obviously, phases 1 and 2 could not operate simultaneously, as this would be a conflicting set of movements (a left turn plus an opposing thru movement simultaneously would be bad).

In most cases, traffic signals want to go from the left side of the diagram to the right side of the diagram. In most cases, traffic signals don't want to back up.



This particular intersection has the main street movements on phases 2 and 6. Phases 1 and 5 are the main street left turns. The side street movements are phases 4 and 8, with the left turns being permissive (That's why phases 3 and 7 say "Future".

The large single headed arrows denote the vehicle movements. The smaller double arrow heads with the slashes in the middle show the pedestrian movements.

This is a relatively common type of intersection, you probably have a lot of intersections just like this in your town.

The following intersection has what is called split phase. Phases 7 and 8 operate sequentially.

NEMA phase sequence diagram - split phase 7 and 8

The phasing can be simple to complex.

Types of Traffic Signal Cabinets

Many people don't see the large boxes near the intersection that hold the signal equipment. There are several different flavors of signal control equipment. These are NEMA TS-1, NEMA TS-2 and the CalTrans TEES style control environments.

Eagle EF-20 electromechanical controller

Originally, the cabinets had electro mechanical switches and a rotary drum. They worked by having the rum rotate, and cams would engage and disengage mechanical points that would lead to circuits running the greens, yellows, and reds. Many agencies still use these types of controller assemblies. If you are standing next to a controller cabinet, and you hear it whirring, and when the lights change, you hear a clunk sound from the box, the controller may well be one of these old electro mechanical systems.

In the early 1960's, the first electronic controllers started being fielded. Everyone seemed to be doing their own thing without respect to a standard. Control equipment was produced by Singer (the same Singer as sewing machines), and at times, major companies like IBM, Raytheon and others were trying to figure out how to make better machines.

In the 1970's, two basic standards were developed. The California Department of Transportation developed a stander with a bunch of other states, and produced the Traffic Engineering Electrical Specification (TEES). About the same time, the National Electric Manufacturers Association (NEMA) produced the TS-1 specification. In the 1980's, NEMA published the TS-2 specification. Each of these specifications has matured over time, with new, updated specifications for the equipment.

In the late 1990's, several different organizations updated a standard specification for electronic communications and controller operation that is known as the National Transportation Communications Infrastructure Protocol (NTCIP). This is supposed to provide a national standard for how all of the parts and pieces within a traffic signal and ITS system.


NEMA TS-1

IDC NEMA TS1 Traffic Signal Cabinet

NEMA TS-1 is one of the older forms of control environments. Essentially, everything is communicating via a series of large wire harnesses within the cabinet. The controller has multiple milspec cannon plugs on the front and it talks with the equipment via a dedicated pinout / wire combination to the specific equipment. This is a reliable form of signal system, with some caveats. First is that the controller tells the equipment what to do, but never gets a check back from the equipment. This means that the signal controller assumes that the signal is doing what it has been told to do. There is a conflict monitor that makes sure that the signal does not malfunction.



Another issue with this type of controller is that while there are three of the cannon plugs defined by the NEMA TS-1 standard, any additional connectors are not defined. This is important, since the fourth connector plug includes how extra detection inputs are mapped, how the emergency vehicle preemption inputs are mapped, and other factors.

The basic NEMA TS-1 spec has 16 defined detection inputs. Depending on the generation of the equipment, there may only be between two and twelve phases available, and as few as 8 detection inputs. Some of the more modern NEMA TS-1 controllers can handle up to 64 detection inputs, but only 24 are really available.

The reason why this is important, is that if a cabinet is configured for one particular brand of controller, and the engineer wants to change the controller to a different brand of controller, some care needs to be given as to how the controller cabinet needs to be rewired to accommodate the new controller's inputs and outputs. This is especially true if the controller's manufacturer has a really unique hardwire mapping in the controller. For example, the Traconex CJ-32 controller is a modified NEMA TS-1 controller that has 32 unique detection inputs, however, 16 of these detection inputs are remapped to the phase hold and phase omit input pins. As long as you trade one Traconex CJ-32 for another CJ-32, it is ok, but change out the CJ-32 for a straight CJ, or and Econolite ASC/2, then you have your detection inputs causing the signal to omit and hold vehicle movements. That may not be what you are intending.

There are modern NTCIP controllers that are configured to fit in a NEMA TS-1 cabinet environment, and allow the pin inputs to be reassigned by the programming.

NEMA TS-2

Econolite TS2-1 traffic signal cabinet

NEMA TS-2 cabinets essentially refer to a controller that has a serial communications system referred to as "SDLC". This is a fancy term for a RS-485 communications system that connects the controller, Malfunction Management Unit (a fancy conflict monitor), the detection inputs, and the load bay.



There are other devices that can be added to the SDLC communications, including a frame grabber. The frame grabber is a product produced and sold by ATSI, that monitors all of the serial communications inside the system, and when an error occurs, the frame grabber will allow the engineer or technician to diagnose what was going on in a relatively simple manner.

The SDLC communications allow all of the equipment to talk back and forth, ten times per second, to send an command, and get a response that the command was executed.

Econolite Pole Mount TS2-1traffic signal cabinet

The back and forth communications allow the controller to make sure that the signal is working properly. The downside is that once in a while the SDLC communications skips a beat or two. Depending on what type of communications parameter was skipped by the communications system, this can either be logged, or actually send the signal into flash.

The Malfunction Management Unit for the NEMA TS-2 environment also monitors pedestrian WALK / Flashing DONT WALK, which the Conflict Monitor for the NEMA TS-1 environment does not.

The NEMA TS2 cabinet is usually capable of 64 unique detection inputs. The specification allows for up to 128, but I do not know of any manufacturer who has allowed for all 128 yet. 64 may sound like a lot of detection inputs, but when you start mixing and matching video, radar and loop inputs, you can eat up 64 detection inputs really fast.

Econolite NEMA TS2-1 Traffic Signal Cabinet

One of the primary considerations that the traffic engineer needs to understand with the NEMA TS2-1 is that the detection comes in groups of 16 on a Bus Interface Unit (BIU). This means that if you are going to need 17 detection inputs for a TS2 video detection system, you need to reserve all 32 detection inputs on 2 BIU's, which reduces the number of loop channels available. Alternately, the engineer could use a TS1 video detection card, and then each camera would have 4 unique detection inputs.

In the picture above, the controller is a 2070 controller, configured to operate in a NEMA TS2-1 environment.

One of the primary advantages of the NEMA TS-2 cabinet is that the internal communications are pretty standard. This allows for a very easy swap out of one brand / make / model of a controller for another. There should be very limited wiring differences between manufacturers. One of the few that may need to be addressed is if the signal is operating with FSK communications, the connector for the inter-cabinet communication may need to be modified. Where with the TS-1 cabinet, there are approximately 65 wires that have to be modified on the D connector, and if the controller uses another connector, maybe another 35 or so on the fifth connector.

Since the TS-2 cabinet talks via the serial RS-485 communications bus, it is very easy to swap out equipment.

One of my criticisms of the NEMA TS2 standard is that it was intended to provide a lower cost cabinet than a TS1 cabinet.  This was because the TS2 standard was supposed to have a lot less work in the manufacturing process.  Instead of having technicians wiring harnesses with 50 to 70 wires in each of 4 or 5 bundles, there would be a simple serial connection connecting the equipment.  The reality is, the TS2 spec has a relatively expensive component to talk between the equipment, the BIU.  Any savings in less cost due to simplicity of manufacture is added back in when you have to purchase 4 to 8 BIU cards, at $250 to $300 each, depending on manufacturer.  

Safetran TS2 Rackmount Cabinet

Safetran has a modified TS2 cabinet that is on a 19-in rack, designed to fit into a standard 332 shell.  The picture on the side shows a double wide version we had custom built for us.

The custom version included a double wide cabinet, including racks for 64 detection channels.  IT also modified the Econolite cabinet standard to replace the special MMU and TS2 5 Amp power supply with cables on the front, so we could use a normal MMU and power supply.

This custom TS2 rackmount cabinet also included switches for pedestrian calls, stop time etc.

The cabinet picture shows the signal in shop testing.  This picture was documenting that we could take the 2070 controller running Naztec Apogee software and quickly install an Econolite ASC/2 by simply hooking up the power, switching the SDLC cable to the ASC/2, and making minor programming modifications in the ASC/2 to run the signal.

This showed us that the TS2-1 operation was truly flexible, allowing us to easily change the controller without worrying about all of the special wiring in a TS1 cabinet.

Hybrid NEMA TS2-2

There is a hybrid NEMA TS2 cabinet where the load bay runs off cannon plugs and the detection inputs run off the SDLC communications. This can be handy if you have an older cabinet, and just want to add a video detection system without messing around with the cabinet wiring.

Some agencies also use this type of configuration because they want hardwired outputs from the controller but want the flexibility of the SDLC detection.

We are building a couple of these, taking TS1 cabinets out of service and modifying them.  This summer, we will have 4 in the field. Pictures, comments and other banter to come!

332 (CalTrans TEES)

The CalTrans TEES cabinet is a family of cabinets that are sometimes erroneously referred to as "332" cabinets. A 332 cabinet is one of the CalTrans style of cabinets. There are a bunch of different types of cabinets, within the family.

Safetran 332 (modified) traffic signal cabinet

In general, most 332 style cabinets are specifically wired to allow 26 detection inputs, with up to 46 detention inputs. This is done via a standard wiring harness and bridging of the detection inputs so that the there is a very standard pattern of where the detection comes in, and what the controller sees.

This type of standard wiring can be modified, and has in some cases, to allow each detection channel on the input files to have a unique detection channel on the controller. This can allow 46 unique vehicle detection channels, 4 emergency vehicle preemption channels, 4 pedestrian isolator switches and 2 channels of railroad preemption just by reassigning the wires on the existing C1 plug, assigning new inputs to the C11 plug, removing the bridging of the detection channels, and using a 2070 controller with an NTCIP style controller..

The advantage to the 332 style cabinet is that they are simple, robust, and cheap. They are essentially clones. The engineer is held by the rigid control of the 19 inch rack mount structure, and the limited choices that system holds. If anyone wants to argue, please try putting a fiber distribution unit, a couple of fiber switches, a video detection system, a video encoder and some DIN rail mounted radar units into a standard single wide cabinet. It gets really tight.

Double Wide 332 (modified) cabinet

The CalTrans Tees type of cabinets can be configures as a double wide cabinet, which does provide a very nice solution for having the traffic signal equipment on one side, and the Intelligent Transportation Systems gear on the other.

Blah, blah, blah. What does that mean? Essentially, the 332 style of cabinet can be a very powerful device.

There are some unique aspects to running a 332 cabinet that the engineer and tech need to know about.

The cabinet will run normally with the monitor removed and the door open. The NEMA TS-1 and NEMA TS-2 cabinets should drop to all-red flash if the monitor is removed. This can be a problem on the 332 style cabinets, if you remove the monitor, and don't secure the door open. If the door is unsecured with the monitor out, and opens and shuts, the drivers will see the signal go from normal operation to all-red flash, back to normal operation and flash every time the door closes and opens.

Putting the cabinet into all-red flash does not apply stop time to the controller. This means that if the cabinet is put into flash, then out of flash, the controller has continued to cycle away. If the cabinet is put into all-red flash, then taken out a few seconds later, the signal may have very different indications lit than what was operating when it went into flash.

Many 332 style cabinets to not have a hardwired stop time switch. Some controllers have the ability to assign the AUX switch on the front of the controller as a stop time switch.

The cabinet may be wired with a detection display panel. Many agencies have the display panel configured such that there are a bunch of detection switches, and if the switch is broken, or is not flipped to the correct position, the detection amplifier will place calls, but the switch will prevent the call from going into the controller.

If you have the cabinet set to normal operation (not switched into all-red flash), and you turn off the controller power, or remove the controller, all of the signal indications will go dark. To remedy this, manually set the cabinet into into FLASH and it should begin all-red flash.

Hybrid 332 (Part CalTrans TEES - Part TS2)

One of the interesting possibilities is that some traffic signal controllers are capable of being set up in a 332 cabinet (C1 FIO), while simultaneously running TS2 detection.  The Naztec 2070 controller running Apogee is one that can do this.  The NW Signal Voyage software had a software release in February 2012 that also allowed this.  I have heard that the Econolite ASC/3 and Siemens software can do this also, but have not seen this.

If this seems wacky, consider this.  If you have a 332 cabinet, with a normal wiring, you have 26 detection inputs.  This hybrid application allows you to either connect to the serial connection on the 2070-2B card, or install a 2070-7B card (depending on the software), and add new detection.  For instance, you can keep all of your I and J input files, and add 32 channels of video detection.  This requires that you have a video detection system that allows for BIU emulation (Econolite, Peek and Iteris have this, there may be others).

In other words, if you have a signal that is going to have major construction going on, and after the construction is over, the loops are going right back where they were, you can add the cameras to the mastarms, wire them in to the video detection system, and connect the SDLC communications to the controller, turn on the BIU's 3 and 4, turn off the loop detection channels, and whammo, you have new detection without turning your controller upside down.

We have ordered the parts from Safetran to replace the I and J files with the 19-in rackmount TS2 detection racks.  We will be experimenting with having a 332 cabinet running solely with TS2 detection.  More to follow on that in another post. 

ATC

Another standard of traffic signal cabinet is the new ATC standard.  This is serialized cabinet that looks similar to the CalTrans TEES (332) style cabinet, but instead of a large bundle of parallel wires connecting equipment, there is a serial interface, similar to the TS2 operation, but on a completely different standard.  These have a bit of a bad reputation in some circles, because the first ones sold were exceptionally expensive.  They provide some nice features, such as being able to support many more load switches than a NEMA or 332 cabinet.

There are some things I like about this cabinet, including the ability to have more load switches than other cabinets, and for the record, I have designed signals where I wanted 20 load switches, instead of the 18 I could use on a fully loaded 332.

The things I don't like about this cabinet is the monitor is a multi-module device, where instead of having a physical board (either diode card for a 332, or a permissive card for the NEMA cabinets), there is a hardware key that is programmed.  It most likely works just fine, I just can't make the jump from a physical contact I can measure and verify to a software / hardware only.

Another thing that concerns me is that the only pluggables I have seen for the cabinet (SIU's, monitors etc) are made by EDI.  I have no problems with EDI equipment, they make very good equipment, and I have a lot of it in the street.  This is not a comment about their products, however I am concerned about going to any device that has only one manufacturer.  For the NEMA and 332 cabinet environments, there are multiple manufacturers of all of the pluggables, so I don't worry about any of the companies going out of business, the competition driving pricing, or the decision by one company to no longer produce a product.  When there is one company, even a very good company, it makes me nervous.

Another concern with this design is that there isn't a lot of room in that big cabinet for other things, FDU's, Ethernet switches, etc.  

Basic traffic signal operation Pretimed Operation

Pretimed operation is the most basic type of operation. In this mode of operation, the signal will alternate the green, yellow and all-red time without regard to the traffic flow.

A signal may have one, some, or all phases on pre timed mode. For many downtown grids, most of the signals are on pre timed mode, and in many cases, the signals are in pedestrian recall.

Some signals are temporarily essentially set to pre timed mode if the vehicle detection fails.

The amount of time for each movement may be programmed to change by time of day.

The minimum amount of time for each phase should equal the sum of WALK, Flashing DONT WALK, Yellow and Al-Red. In some cases, some agencies allow the flashing DONT WALK to extend through the Yellow time. This can shave a few seconds of time off the cycle length of the signal.


Pretimed operation with the signals in pedestrian recall can be a very effective way of dealing with a grid network of signals. Many agencies don't put pedestrian pushbuttons in downtown grid signal networks, as the typical pedestrian volumes would have the signals constantly serving pedestrians anyway.

A pretimed signal operates on a user specified amount of time for each specific movement. For instance, if the signal is a 2-phase signal (2 specific signalized movements), like at the intersection of two one-way streets, and is operating in pretimed mode, the signal will serve one movement for a specified amount of time, followed by the second movement.

In this example, the first movement may be programmed for 20 seconds of green, followed by 3 seconds of yellow, followed by 3 seconds of all-red. The second movement would then commence, programmed for 30 seconds of green, then 3 seconds of yellow and 3 seconds of all-red. The total cycle time would be 62 seconds (20+3+3+30+3+3=62).

There are advantages, and disadvantages to this type of operation. The advantage is, it is pretty straightforward to set up, and the specific amount of green assigned to each phase (unique signalized movement) can be varied by time of day.

The variation by time of day allows for the cycle length to be adjusted to lengthen when necessary, and shorten when necessary.

The downside to this type of operation is that the signal is essentially a dumb box, without any way for it to modify operations by what is actually happening with the traffic. If the second movement has no cars, why serve it? If the 2nd movement has only 1 car waiting, why serve it for the entire time?

The fact of the matter is that with some situations, pretimed works pretty well, like in a downtown central business district grid. It also is a lot cheaper than installing vehicle or pedestrian detection systems in the intersection. It is also a pretty good way to deal with failed detection, as a temporary measure until the detection can be fixed.

It is possible that specific movements are timed, and other movements have vehicle detection, which would make that type of a signal semi-actuated.