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...

Advanced Overlap Applications - A Primer

Overlaps are traditionally used as Parent / Child (right turn overlaps), or as independent overlaps (timed overlaps or double clearance overlaps).  See discussion in the Blog Post on basic overlaps.

This Post starts talking about special uses of overlaps to do more with your traffic signal controller.

Think of an overlap as a tool that can be used to add flexibility to the rigid structure that your controller is chained to.  In general, the controller must follow the ring and barrier structure.  There is some flexibility in assigning time of day commands to cause the signal to have phase rotation (lead a protected left sometimes, lag a protected left at other times).

What if you wanted to:

• Lead and lag the protected left?  
• Lead the protected left and include a queue dependent lagging protected left?
• Create a queue dependent early release on an offramp while in coordination?
• Create a queue dependent early release for a lagging protected left?
• Asymmetrically double cycle a minor intersection within a long parent cycle length?

 and so forth.

Overlaps are the way to do these types of operations.  In future blog posts I will explain how to do the bulleted signal operations.

Older generation hard wiring of phases to load switches

Older Generation TS1 Equipment

So what am I talking about?  A little more explanation about overlaps is needed.  In older generation equipment, each phase was tied to a specific load bay position.  This was more typical for NEMA TS1 equipment than 332 style equipment.

Generally, on the TS1 controllers running in TS1 cabinets, this was something that required significant rewiring of the cabinet to do differently.

In general, the controllers were set up to have phases 1 through 8 assigned to load switches 1 through 8, then the peds then the overlaps to the remaining 8 phases.  If the signal needed something fancy, like a fifth ped, this created some interesting challenges for the engineer and technician to work out to make the conflict monitor work with the controller settings, and the cabinet wiring.

In the 1990's. traffic signal controller manufacturers started selling equipment that incorporated many of the TS2 functions into the same controllers that could be put in a NEMA TS1 or TS2 cabinet.  An Econolite ASC/2 is an example of this.  Eagle, Naztec, Peek and others had controllers that could be placed in either environment.  This can create some confusion, where users get a lot of new features that they can use, while staying in a TS1 environment.

Newer generation allows software reprogramming to load switches

Newer Generation TS2 and NTCIP equipment

Many of the TS2 controllers and all of the NTCIP controllers can be set up to allow any phase, overlap or pedestrian movement to be assigned to any load switch.  While this is revolutionary within the NEMA world, it was not groundbreaking.  Many of the 170 controllers could do this a long time before the NEMA world envisioned this ability.  The 170 and NEMA TS2 controllers still generally had few overlaps available for use.

This can create a really interesting mess of programming for the signal techs to figure out, if this is not documented.  In general, if you don't document what you are doing as an engineer, the field techs will not support it.  In reality, even if you do document what you are doing as an engineer, the field techs may not support it, unless you make it really clear what you are trying to accomplish.

Using overlaps to keep things clear, and improve the operations

Sorting out the remapping using overlaps

So why bother using overlaps to complicate things.  Generally, traffic signals are very rigid in how they operate.  The tools that exist such as conditional service and phase rotation can help, within limits.  By using overlaps to run specific load switches - instead of the phase outputs - the traffic signal controller can be made more efficient and help with the processing of traffic.

In the example to the right, phase 1 and 9 are connected to overlap 1, which goes to load switch 1.  This means that the controller can have phase 9 enabled, and added to the ring and barrier structure, which will allow the signal to do special things with phase 9.

One key to understanding this is that the pairs, or trios (in some cases) of phases that are routed through the overlaps to the load switches, are routed through an overlap with the same load switch the normal phase the phase would be routed through, allowing the monitor to be blind to this type of controller operations.

In other words, if you had three phases operating 7, 8 and 16 that are to be routed the normal operation of phase 8, these phases are routed to an overlap that is output to load switch 8.

IF you were to route 7, 8 and 16 to overlap 8, to load switch 6, you might have some problems.

Routing the phases to specific movements allows the signal to be modified without affecting how the MMU or CMU sees the inputs.

Following are examples of applications of how overlaps can be used to improve the signal operations.  More detail will be provided in specific blog posts about how this works...  

Example 1.  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.

By using an overlap to cover the protected left turn, while working through the detection parameters through alt tables, the signal can efficiently transition from lead to lag protected left turn without needing to go free, followed by offset seeking mode for several cycles.  This means that your transition from lead to lag will be seamless... A big help if you this is being driven by a traffic responsive system.

Example 2.  Special phasing coming out of railroad or emergency vehicle preemption

By using the overlaps and doubling up on the signal phasing on the overlaps, the signal can be forced to come out of preemption to specific phasing when the preemption phasing ends.

For example, if your preemption needs to force a call to a lagging left turn, but the lagging left turn is only to come up after preemption, Phase 1 can be assigned to the leading left turn with vehicle detection, and the normal timing parameters.  Phase 9 can have no vehicle detection, and be in the ring and barrier structure as a lagging protected left, with special timing parameters (a special min green etc).  The controller can be programmed to exit preempt to Phase 6 and 9, and phase 9 may be timed for a 20 second min green time.  This would force the traffic signal to come out of preempt, flush a specific movement, then go back to normal operation.

This type of operation would allow the signal to serve a specific set of movements, then go on to the opposing movements, rather than go 1 and 6, then 2 and 6, then 3 and 8.  The signal would go 6 and 9, then 3 and 8 for example.

Since phase 9 has no detection, the signal would never serve the movement, unless the signal was coming out of preempt.

Example 3.  Cheap and dirty transit signal priority

For example, you wanted to allow a low priority preempt call to extend a green for a thru movement, but only when the bus was coming with the EVP low priority active, phase 2 and 10 could be programmed in the controller to overlap 2, which is programmed to load switch 2.  Phase 10 may have 10 seconds of green time.

When the traffic signal receives a low priority preempt, the traffic signal controller has a logic statement that ties the low priority preempt to calling (and possibly extending) phase 10.  Phase 10 would only come up after phase 2, if there was a bus with priority on.

The coord plans can be set up to accommodate the timing on phase 10, for the potential of a bus needing just a little more time to get through the intersection, but when no extra time is needed, the coord plan will move from 2 and 6 to the next phases across the barrier.  With the use of fixed force offs, this bonus time could be provided to the side street if necessary.

Example 4. Cheap and dirty truck priority

If specific movement that had a lot of trucks, the phases could be assigned a special operation based on the presence of a truck.

For instance, for an intersection with a steep uphill grade, and heavy truck movements, a pair of phases can be assigned to the approach with the trucks.  For this example, the uphill movement with the trucks is phase 4.  Phase 4 is paired with phase 12, on overlap 4, to load switch 4.

With specific truck detection (pairs of loops with logic in the controller, video, radar etc) the traffic signal will detect large vehicles coming up the hill.  The truck detection is assigned to extend phase 4, and call and extend phase 12.

In the applications we are putting in place, we are using a dopplar radar detection system (I am not advertising the product, but it is a Wavetronix HD detection system).  The radar system will sense the vehicle, plus the speed of the vehicle.  Depending on what the radar system sees - large vehicle 15 mph, vs. large vehicle at 25 mph etc - the radar system chooses to place a call on any one of the 4 contact closures on the detection card.  The extension placed by the card for phase 4 and 12 will be longer if the truck is going slower, shorter if the truck is going faster.

This is not a foolproof method of truck detection, but it does allow for the signal to dynamically change its operation due to the presence of trucks - and decrease the possibility that a truck will need to stop on the hill.

Example 5.  Queue dependent early release

In this form of operation, the traffic signal has advanced detection at an intersection, such as an offramp.

The traditional way of dealing with offramp queues is to place a queue sensor at the offramp, at a point that the offramp would get close to backing up onto the high speed facility.  In the event that the queue of vehicles had backed up to the queue detector, the detector would place a call to the emergency vehicle preemption system, causing the ramp to dump onto the arterial street.  This is not very elegant, because if the arterial street is busy, there may be nowhere for the traffic to go to.

The other ways that traffic signals are programmed to deal with the potential of a long queue on an offramp backing up onto the higher speed facility is to give very generous time to the offramp.  So if the signal is running on a 120 second cycle length, the offramp may be given 50 seconds, just in case the offramp needs the time.  This creates a problem, where the offramp provides random arrival traffic to the traffic signal, where the arterial street is more likely part of a coordinated system which has platoons arriving.

The long offramp split division timing creates a situation where the offramp may only need 20 seconds to flush the static queue of cars, but then the offramp is held for another 15 to 25 seconds by single cars exiting the ramp extending the signal while the arterial waits.

Queue Sensitive Early Release

Queue Sensitive Early Release Phase Diagram Example

It would be far more efficient to develop a queue of cars on the offramp, then serve the queue, and go back to the main street.  The queue dependent early release timing parameters allows the signal to serve a normal timing to the for shorter queues, and when necessary, serve longer times for the offramp.



In general, this involves having stopbar detection, and advanced queueing detection, plus extension detection.  Most of which probably already exists.

For example, this is being done at a T intersection where there is a lot of traffic coming off the T onto a major arterial.  In this example, both phases 7 and 8 are tied to overlap 8, to load switch 8.  The pedestrian call is tied to phase 7.

When a short queue of cars exists, only phase 8 is called and served at the normal time in the coord cycle.  The radar detection provides extension to both phases 7 and 8.

When a queue of cars is on the detectors for phase 7, the signal ends the 2 and 6 coord phases early, and times phase 7, transitions to phase 8, then goes back to 2 and 6.  Phase 7 may have 10, 15, or 20 seconds depending on what is programmed in the coord timing parameters.

If a ped call is placed, the ped comes up with phase 7.

For an offramp application, the stopbar detection would call phase 8.  The early release queueing detection would be 250 to 300 feet from the stopbar detection, and call phase 7.  All of the advanced detection would extend both phases 7 and 8.  The queue detection for phase 7 would also extend both 7 and 8.  Ideally, the queue detection for 7, and the stopbar detection for phase 8 would have NTCIP Queue detection enabled.

The split divisions would be set up for the timing needed to serve the short queue (phase 8) and the longer queue (phase 7).  So for a 120 second cycle length, phase 8 would have maybe 25 seconds, and phase 7 would have 20 seconds of split division time.  If a short queue exists, the traffic signal would serve the amount of time for the short queue, and give all of the bonus time to the arterial.  If a long queue exists, the signal would terminate the arterial street 20 seconds early, and serve both 7 and 8.

Since this is a T offramp, there are no vehicles continuing straight off the offramp, all vehicle are turning right or left, the potential of needing extra extension for dealing with high speed vehicles is negated, and normal yellow and red timing can provide a safe and efficient transition from the offramp to the arterial.

Even better, using an advanced technology, like Wavetronix Advance detection (I am not advertising, but they have some great features) to have active dilemma zone monitoring will further improve the safety.

Example 6.  Dynamic lagging protected left timing

This operation is very similar to the queue dependent early release, but it is used to solve another problem.

Sometimes a coord pattern really needs some signals to operate with leading protected left turns and other signals to operate with lagging protected left turns.  The problem with lagging protected left turns is that a single car in the left turn pocket will cause the signal to start the green for the lagging left turn, and then hold it until the signal is ready to move to the other side of the barrier.  This means that a single car, or a short queue of cars in the left turn pocket with the lagging protected left may hold the signal  up for 30 or more seconds.  This can cause frustration with the drivers as they wait without any reason to do so.

In this example, the phasing of the signal would have phase 7 be the protected left turn with a short queue, and phase 15 precedes phase 7 in the ring and barrier structure - where 15 and 7 were tied to overlap 7, to load switch 7.  Phase 7 has the short queue detection, and phase 15 has the long queue detection.  The split divisions would be set up with 20 seconds on the split division for phase 7, and 10 seconds for phase 15, the total split division for 15 then 7 would be 30 seconds.

In the event that a short queue was present at the time in the cycle to begin the phase 7 left turn, only 20 seconds of split division would be served.  In the event that a longer queue was present for the phase 7 left turn, the traffic would start with 10 seconds of phase 15, followed by 20 seconds of phase 7.  The drivers would see the signal go green at the start of phase 15, the signal would stay green while Phase 15 times yellow and red, then transitions into phase 7 green.
 

Example 7.  Lead plus lag protected left turns

More detail will be provided for this type of operation, but essentially, the signal can be set up to provide a lead, and a lag protected left turn.

Queue sensitive protected lagging left turn - changed sensitivity by time of day

This can be very powerful, especially if the signal is set up to terminate phase 2 as efficiently as possible, leaving the bonus time to phase 9.  This can be done by making phase 6 the coord phase, and putting the signal into floating force offs.  The sensitivity of the operation can be changed by the time of day plan, by calling different alt tables for detection parameters.

If the signal has very heavy northbound thru (phase 6) and very heavy northbound lefts (phases 1 and 9), the signal can provide the timing necessary for the southbound movement (phase 2), and give a great deal of time to the northbound left.

Example 8.  Queue flushing through multiple signals with detection relay

This is a similar operation to the dynamic protected left turn operation.  The twist is that the signals are hardwired so that queued vehicles on one upstream intersection is hardwired to a downstream intersection.

In this case, we are relaying the vehicle detection call in a 332 cabinet by hardwiring the outputs of the specific detector to a 242 card in an unused detection slot.  The 242 card is hardwired to a 4cc/s cable that connects to a 242 card in another signal, and the outputs of that 242 card are wired to the input file of the second signal.

We have one of these going out to construction in the March of 2012...  more to follow.

There are opportunities for this type of application in a TS2 cabinet using an EDI SSM662 card to provide the contact closure input to the TS2 cabinet.


Example 9.  Active gridlock avoidance with double service

Active Gridlock Avoidance with Double Service

This is being implemented with the lead plus lag protected left turns.

In many cases, poor designs of parking lots affect the operations of the traffic signals.  In the example below, there is a very short stacking distance into the parking lot, and many times, the inbound traffic has nowhere to go, because of the yellow cars stacking into the first drive aisle.

In this case, there is a radar detector looking at the cars leaving the intersection, into the parking lot.  The radar is capable of not only seeing a queue of slow cars, but knowing exactly where they are, and how many there are.  When the radar detector sees a queue of slow moving cars on the inbound lanes of the entrance, the radar detector places a call to a normal detection channel.

The vehicle call does not extend the movement. Rather, the vehicle call is tied to a logic statement in the traffic signal controller, that translates the detection input to a force off for the specific ring that is feeding the entrance.

This is being implemented with the lead plus lag protected left turns, so that when this is enacted, the signal will come back and serve the movement a second time. 


Example 10.  Asymmetric Double Cycle

This takes a lot more explanation... 

Asymmetric double cycle is being implemented at a few intersections today by me.  It really works well.  This is not adaptive.  This is also not $50,000 to $70,000 per intersection

As a primer, look at the video.  This is a T intersection running an Asymmetric double cycle on a 150 second cycle length, with 600 vehicle an hour coming off the side street.

On the upper side of the picture is a roundabout.  There is only about 250 feet of storage before the signal backs up into the roundabout.  At the upper right of the picture is a 600 spot park and ride, which pulses out 20 to 30 cars after each bus arrives at the park and ride.

Watch the video, and decide for your self if it looks like this signal is running on a 150 second cycle length.

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.