Monday, August 20, 2012

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.

Friday, August 10, 2012

Why Communicate To Your Signals.


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

Controller Communications

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

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

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

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

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

Monitor Communications

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

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

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

Reno A&E PC software view of monitor operation

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

Problem Controllers

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


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

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

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

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

Determining Conflicts

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

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

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

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

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

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

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

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


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

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

Video Detection Communications

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

Cameras fail

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

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

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

Problem camera.  Note how the picture is divided about in the middle of the screen.  The bottom half of the picture should be above the top half.  The zones are correct, assuming that the camera is working properly
These cameras are being replaced.  The key here is, this signal was not connected to any system.  It was a lone signal, with no communications.  The only reason we knew about the problem is because a citizen got frustrated and called in that the signal wasn’t operating properly.  If this signal were connected to the system, we would have been able to look at the operation and see what was working properly and what wasn’t.
Once a week, or more frequently, I spend a chunk of time and pull up multiple signals and look at what they are doing.

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

Sometimes Nature Helps

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




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




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

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

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

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

Conclusions

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

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

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

Friday, August 3, 2012

Loops vs. Radar and Video Detection

Most of the sales reps in my area have figured out that I like technology.  I am willing to put technology in place in intersections.  One of the new buzzwords in traffic signals is radar detection.  Even better, the neat new technology is combining radar and video detection in one device.  There have been multiple generations of radar and video detection.  Some have worked really well.  Some, not so much.
This post is not attempting to sell a product, rather a general discussion of what why some technologies work well beyond the technical specifications. 
I currently deploy video detection and radar detection for count stations, stopbar detection and advanced detection.  It is true that nonintrusive detection (radar, video detection etc) cost more to implement than traditional loops.  There are several advantages to nonintrusive detection.  These include, but are not limited to increased flexibility, immediate gratification, long term cost savings, ease of repair and other factors.
Flexibility
The easiest way to envision flexibility is that someone always has the idea that they should restripe the road.  Move the lanes around to create a bike lane, squeeze in a turn pocket, repurpose an approach to create dual lefts, or some other operational modification.  The non-intrusive detection allows for a decreased cost for reallocating the detection to the new lane configurations.  If the vehicle detection is all induction loops embedded in the pavement, then someone has to pay for the traffic control and labor to cut in the new induction loops in the new locations. 
One particularly troublesome intersection that vexes me has no detection at all for a left turn pocket with a protected left turn (it was cut out a long while ago and never replaced),  and another approach where the lane lines were restriped that ended up with the old left turn lane loop detection still being used, but it was on the lane line separating the left and thru lane.  If this had been video or radar detection, these zones could easily be reprogrammed in the detection units.
For some reason, engineers have designed lots of bike lanes, and in many cases, have no detection in the bike lanes.  Worse yet, in too many cases, the bike lane detectors are configured badly, where you have a small (I have seen 2-ft wide by 10-ft long quadrapoles as bike detection) loops in the bike lane at the stopbar.
Several states now require that traffic signals detect all legal vehicles.  A well designed bike loop can detect a steel bike (through the ferrous metal affecting the inductance field) or an aluminum bike (where the aluminum causes an eddy current in the loop that causes a change in the inductance field), well designed loops have problems at best sensing a carbon fiber bike.  By extending the radar stopbar or video detection zones into the bike lane, the bike is sensed by the signal.
Immediate Gratification
There appear to be a dearth of loop cutting contractors.  Regularly, traffic signal turn ons occur where the signal is ready to be turned on today, but the loop cutters have not been scheduled yet.  It is not unusual for a signal to be turned on, and operated in pretimed mode for an extended period of time before the loops get cut in and terminated.  In many cases for developments, the requirement is for the signal to be fully functional, but the political decision is made that getting the signal turned on, going green, yellow and red is good enough.  The opening of the development can occur even though the signal is not fully functional.  Once the developer has the occupancy permit, the traffic engineer has no hammer to get the loops cut in.  The developer is usually capable of making the straight faced argument to the elected officials that the loop cutter is just a short time away, so, please let the business open.  I understand the argument by the developer.  They have a significant capital investment in the property.  The business has a significant capital investment in getting to the point where they are ready to open.  The loops can’t be cut in until the asphalt is placed…  The asphalt is placed two days before opening, then comes striping… It was wet over the weekend, so the asphalt is late, the striping is late…  loops get the short shrift.
I have had traffic signals that have operated in pretimed mode for 3 months or more, between when the signal was turned on, and when the loops were finally installed and terminated.
By going to video or radar detection, all of the vehicle detection installation can take place when the poles are erected, weeks to months before the opening day.  We work with the contractor to aim the cameras and radar detection panels early.  In many cases, we go out with a generator and set up the video or radar detection systems after the cabinet is installed and wiring is pulled and terminated, but before the electrical service is connected to the transformer.  That means on the day of turn on, all we are doing is refining the detection zones.
Another form of immediate gratification is where utility work cuts through loops, or loop lead ins.  We had an intersection where a water line blew out immediately below the southbound stopbar loops for a major intersection.  In order to repair the water line, the stopbar loops for all 4 lanes of the southbound approach had to be cut.  Between the immediate utility work, patching, then removal of patching, and replacement of the pavement, the loops were reinstalled about 2 months after the water line blew out.  During that entire 2-month period the signal was in recall for the left and thru lanes, 24 hours a day.  It is pretty straightforward to take a coordinated traffic signal, and put the main street coord phase into recall.  During the hours of the day that coordination is in effect, the drivers will most likely not see any difference in the signal operation for that particular movement.  During the non-coordinated hours of operation, this will make the signal very sluggish.
The left turn lane is a different thing.  Putting a left turn lane into recall for 2 months is painful, especially when the opposing thru is very heavy.
We have Ethernet communications to all of our signals that have video and radar detection.  Where we have had utility work at signals with radar and video detection, we are able to quickly modify the detection zones, and observe that the changes are working well. 
Long Term Cost Savings
Video and radar detection systems likely cost more than initial installations of induction loops.  However, over the long term, the nonintrusive vehicle detection systems will pay for themselves.
Grind and Overlay
There are several methods to maintain the pavement surface.  When the decision to grind and overlay the existing asphalt this can be accomplished several ways.  One way is to grind out the entire pavement surface, the other is to retain as much of the pavement surface as possible, but to grind out a wedge of asphalt approximately 2-inches deep at the curbline, and taper to no grinding at 10 to 12-ft from the curb.  This second method is quite common where the pavement is in relatively good shape, but the desire is to keep the top of the curb at 6-inches above the gutter elevation.  It is not uncommon for a paving project to include significant patching, where small to large sections of the pavement are completely cut out to below the subgrade, and replaced full depth.
The specifics of the pavement replacement method is not really important to the loops.  What is important to understand is that even if the standard plan shows that the loop wires be at 3-inches below existing surface of the pavement, when the top 2 inches of asphalt are ground out, the grinding will most likely pull up the sealant, which is bonded to the loop wires running from the loop to the junction box.  When the sealant, which is bonded to the loop wires is pulled up, the pavement grinder will shred the loop wires, typically between 4 and 1 feet from the gutter line – where the grinding includes a wedge of asphalt removal.
As an aside, it is important to understand that if loops are replaced above the existing loops, the old loops will create false calls if the old loops are not dealt with properly.  If the old loop is not fully cut in multiple locations, then the shredded loop wires near the gutter line will allow the old loop to couple and decouple below the new loops, which will cause false calls on the new loop.  This will occur most frequently when the pavement gets wet.
On one grind and overlay project I worked on, the grinding took out the main street loops on a 5-lane Principal Arterial at 6 traffic signals.  Replacing the loops at these 6 traffic signals cost over $100,000.  All of the existing loops worked properly on that corridor, but when the asphalt wedge was ground out, the grinding shredded every loop wire at or near the gutter line.  The loops themselves were not affected, just the wires between the loops and the splices in the junction boxes.
Four years after the loops were installed due to the grind and overlay, the same road is going to have a sanitary sewer trunk line installed, which will require replacement of most of the loops… again.  If the vehicle detection systems had been video, or radar, instead of loops, the initial grind and overlay, and then the upcoming sewer work would have not required the replacement of all those loops, and the cost associated with replacing the loops. 
Underground Utility Work
Recently, I was approached by the local sewer utility, where they had four locations where minor sewer work needed to be accomplished.  Each of the four locations had 200-ft or less of sanitary sewer to be installed.  The problem was, that in each of the four locations, the sanitary sewer work was going right through a bunch of stopbar loops.  Each location was going to require between $4,000 and $6,000 worth of loop replacement.  In each case, the cost of the loop replacement will need to be passed on to the sewer rate payers.
Once again, if the vehicle detection systems were radar or video, instead of loops, the cost of replacing the vehicle detection would not be borne by the citizens.
Ease of Repair
When a loop shows problems, it could be any number of issues.  The problem could be any combination of one or more of the following:  the loop itself has gone bad, the splice between the loop and loop lead in wires is bad, the loop lead in wire is bad, the field wires are not firmly connected to the terminal screws in the cabinet, the loop amplifier has gone bad…
There is a similar laundry list of things that can go bad for video or radar detection.
The ease of repair comes from replacing an induction loop that has gone bad in the street, compared to replacing a camera or radar panel.  To replace a camera or radar panel, the detector needs to be replaced in the same location, usually with a bucket truck.  This likely requires that one lane be coned off for a relatively short period of time to replace the bad detector with a new detector.
When a loop, or series of loops goes bad, there needs to be multiple vehicles, equipment, and personnel out in the street for extended periods of time.  This causes one or more lanes of traffic to be routed around.  The wire from the loop to the junction box needs to be cut and laid across multiple lanes of traffic, which requires multiple sets and resets of traffic control.  Work needs to be done at the curb, for where the loop’s sawcut goes into the conduit that leads to the junction box.  There is a great deal of risk associated with all of this activity in the street.
Going from an in-pavement detection system to an out of pavement detection system reduces the risk associated with traffic maintenance operations.
Conclusion:
Induction loops can be more accurate than video or radar detection.  There are short term and long term benefits to seeking other methods of vehicle detection than induction loops.
In a later post I will discuss the benefits of different types of radar detection that far exceed the ability of induction loops.

Monday, July 30, 2012

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.

Saturday, February 18, 2012

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.