Delay Beginning of Flashing Yellow Arrow Due To Opposing Queue of Cars

This post is a continuation of a previous post showing a modified operation of Flashing Yellow Arrow as described in a previous post.  See:

http://ntcip-unleashed.blogspot.com/2013/01/flashing-yellow-arrow-operation.html

This post documents additional modifications to the Flashing Yellow Arrow operations, to delay the onset of the FYA if the signal would cycle from the side street back to the main street, but there is a queue of thru cars opposing the vehicles in the left turn pocket.  The assumption here is that the protected left turn portion of the FYA operation is a queue dependent lagging protected left turn.

The example in this blog post is running in a Trafficware / Naztec 2070 controller, running Apogee V.76.7d.  While I am not advocating the use of any specific controller brand or software version, the description here is based on what I am using in the field.

Traffic signal controller settings to modify the FYA operation.

Goals:

• Continue use of inhibiting FYA across pedestrian WALK and FDW
• Continue inherent controller delay of FYA by implementing FYA Delay Time under MM-1-5-2-(OL#)-3
• Continue phase sequence to lag the protected left on the FYA, based on standing queue in the left turn lane at the end of the main street green phase
• New operation in free and coordinated TOD plans.
• New operation to inhibit the FYA when a queue of cars is in the opposing lane
• New operation will not allow a ped call while inhibiting the FYA to start the WALK, rather it will hold the ped call until the next time the phase is served.
• For example:
• The signal ends phase 2, a queue exists on the SB thru lane (associated with phases 4 and 9).  
• The signal would  come up in phases 9 and 8 (the queue of SB cars calls phase 9 as opposed to the min green for phase 8).  
• The FYA head will display a steady red left turn arrow to the NBL traffic, while cycling phase 9, then when the SB traffic gaps out for phase 9, or maxes out for phase 9, the signal will transition from 9 to 4, and the NBL flashing yellow arrow head will transition from a steady red arrow to the FYA indication.
• A late ped call across the west leg (ped 9) while the signal is timing phase 9 may display a WALK and FDW for Phase 9, which could end up with the signal needing to go into offset seeing mode

The phase diagram for this controller is as follows:

Phase diagram for signal controller running a modified flashing yellow arrow operation.
The modified FYA will provide a red left turn arrow across a specific pedestrian in WALK or FDW
(for example, Phase 7 will display a red arrow while the ped associated with phase 11 is provided a
WALK or FDW).  When ped 11 is through with timing the WALK, FDW, yellow and all-red, then the
controller will transition to phase 8, but since phases 11 and 8 are run through overlap 11 on load switch
position 8, the signal indication remains green for the thru movement.  After the signal transitions to
phase 8, the phase 7 FYA will be displayed.

In this case, the southbound left turns, associated with phases 7 and 12 on overlap 12 can be individually
programmed to provide either leading or lagging protected left turns, based on the NTCIP Action plan.
Setting up the controller in this way allows the signal to switch the lead and lagging protected left turns by TOD
without needing to go into free to allow for a change of sequence in coordination.

Intersection Layout and Description

Screen shot of intersection phasing and detection

In this case, the signal does not have stopbar detection on the main street.  There is main street presence detection located at approximately 60-ft to 80-ft from the stopbar.  The left turn detection also does not include stopbar detection.  There is presence detection located at approximately 20-ft to 40-ft from the stopbar in the left turn lane.  Since the signal rests in green on the main street, the FYA will normally come up.  The presence detection in the left turn lane is queue dependent to drive a lagging protected left turn lane.

The signal rests in min green for phases 4 and 8.  The signal is split phase eastbound (phase 1) / westbound (phase 2).  There is no ped for phase 2.  The eastbound approach to the signal serves a center including a big box retail, movie theater and, a restaurant and several smaller strip mall facilities.  The east leg serves a single parking lot for a small office complex.

If you look at the left turn arrow icons for phases 3 and 7, you will see that they are black, while the icons for phases 10 and 12 are red.  At the time that this screen shot was taken, phases 3 and 7 were omitted by the coord plan, but phases 10 and 12 were included.  They are displaying red, however the display also includes orange icons for the FYA indications.  These are driven off the channel outputs for the ped yellows that the FYA is operating from.  When the signal is not displaying a FYA, the orange arrows go black, providing an excellent indication of whether the signal is in protected left, FYA left, or just steady red or steady yellow for the lefts.

Also, note that the main street peds are phases 9 and 11, not the normal 4 and 8.    The pedestrian indications include unique phasing as a part of the special operation to not allow the FYA across the ped WALK or FDW, as described in the previous post on FYA operations.

Controller Coordination Programming Parameters:

One thing that must be considers is how tight the coordination parameters restrict the phasing and timing.  In this case, in order to get the signal to operate with all of the extra phases for the special FYA operation, the timing must be very tightly controlled.

One key thing that must be controlled is how the signal goes into offset seeking mode.  There are valid reasons why a controller may exceed the cycle length in coordination by over 0.1 second.

If the controller is only allowed to longway transition, you may find that your controller will bounce once in a while, where the signal exceeds the cycle length by 1 second, so the signal then goes into longway offset seeking mode to transition back to coordination sync.  This means that if the signal exceeds the cycle by 1 second, it must longway transition (cycle length - 1).  This could be a very long crawl for a signal running at a 140 second cycle that must longway transition 139 seconds over 3 exceptionally long cycles since the longway transition was set at 33%...  That would mean that the signal would need almost 560 seconds, or 9 minutes 20 seconds to get back into step if it exceeds the cycle by 1 second, and only has longway transition activated.  The caveat to this may be if the specific brand and model of controller firmware includes a special operation for allowing the split divisions to be less than the sum of (WALK+FDW+Yellow+All-red)

The coordination parameters inside the Apogee firmware allows each Action Plan to include 4 specific phases to not to be transitioned via shortway transition.  This allows for shortway transition to be very effective where you need specific phases to never shorten in the transition.  Having this type of control can really provide a nice way to get back into step if your cycle gets slightly long.

Before you decide that your controller never exceeds the cycle length under normal operation, take a good look at the specific cycle by cycle operation.  You may be very interested in how closely the coord cycle length is actually operating vs. the slight variations that you were unaware of.

Late Pedestrian Actuations

One key thing that must be accounted for is how does the signal accommodate late pedestrian actuations while in coordination.  In some cases, if there is time in the split divisions, a pedestrian pushing the button on the main street shortly after the main street green is provided will allow the ped indication to transition to WALK.  In this case, because of the special operation at the signal with the FYA, this needs to be prohibited.  If the pushbutton is actuated after the phase next decision is made, the signal really needs to lock the ped call, then come back to it.

Admittedly, this does hinder the pedestrian crossing, but at the same time, it is providing improved safety for the pedestrian, to insure that vehicles are not turning left across the crosswalk while the WALK or FDW is timing.

The Apogee software allows by Action Plan, to determine if the peds will be inhibited or not.  In this case, for the times of day where the FYA is operating in coordination, the specific Action Plans have this feature turned on.

Detection Settings to Inhibit the FYA When There Is An Opposing Queue

The goal here is not to inhibit the FYA when the opposing queue appears.  Rather it is to inhibit the FYA when the signal cycles from the side street back to the main street - if there is a queue of cars in the oncoming thru lanes.

In the Apogee software, each detection input is allowed to specifically be mapped to one phase.  Getting one detection input to do two separate things is accomplished by using the "source" feature.  Essentially, you program an unused detector input to be sourced from another detector.

I have used several controllers which allow you to map a single detection input to any of the 16 phases in the NTCIP controller.  I have to admit at first I didn't like Apogee's sourcing method, since I was used to assigning a controller's detector input to 2 or 3 phases, depending on what I wanted to do with the detector.  However, once I started working with Apogee's Sourcing features, I figured out that it was an exceptionally powerful tool.  You can source the detectors such that you can monitor a wide variety of things, such as:

• The primary detector input logs occupancy during green + yellow
• The sourced detector logs occupancy during any combination of green / yellow / red for any phase
• The primary detector calls one phase as a standard call / extend detector
• The sourced detector can be an extend only for another phase
• The sourced detector can be a NTCIP queue detector for another phase
• The primary and sourced detectors can have completely different delay and extension factors for running different types of signal operations from the same detector

and so on.

Sometimes flexibility comes in many different methods.  Once I started playing with this, it became very obvious how powerful this specific method of sourcing could be.

In this case:

• Detectors 33 and 34 are sourced from detectors 9 and 10.  
• Detector inputs 9 and 10 are the true inputs driving phase 4, but in this modification, 33 and 34 will drive call and extension detection for phase 9.
• Detectors 35 and 36 are sourced from detectors 3 and 4.  
• Detector inputs 3 and 4 are the true inputs driving phase 8, but in this modification, 35 and 36 will drive call and extension detection for phase 11.

In short, this type of operation allows the signal to delay the onset of the FYA for a left turn, where because of traffic congestion, there would be no opportunity to turn permissively across the oncoming cars anyway.  Since this is detection driven, the delay of the onset of the FYA would only appear when there is an opposing queue of cars.

It can be a little challenging in lighter traffic volumes.  Since a "dummy" phase is being called to drive the red arrow across the oncoming traffic, the "dummy" phase must time the min green, plus any extensions, plus the yellow and all-red before providing the left turn with a Flashing Yellow Arrow indication.  It may be appropriate to rethink the min green timings for the "dummy" phase to a short value to reduce undue delays to the left turning traffic.

Why Communicate To Your Signals.

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

Controller Communications

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

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

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

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

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

Monitor Communications

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

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

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

Reno A&E PC software view of monitor operation

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

Problem Controllers

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

Reno MMU reporting a Port 1 failure

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

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

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

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

Determining Conflicts

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

Reno MMU reporting a conflict

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

Oddities

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

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

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

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

Reno MMU reporting a short yellow fault

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

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

Reno MMU reporting dual indication fault

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

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

Video Detection Communications

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

Cameras fail

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

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

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

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

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

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

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

Sometimes Nature Helps

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

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

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

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

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

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

Conclusions

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

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

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

Easing the effects of phase rotation during coordination

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

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

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

Standard NEMA Phase Sequence Diagram

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

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

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

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

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

The new phase diagram looks like:

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

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

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

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

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

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

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

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

Documentation

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

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

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

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

Conclusion

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