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.

Real Time Congestion Monitoring on Arterials

This article is on how to use your central system to provide real time congestion mapping, and incident notifications.  The example here is using Naztec's ATMS.now central system and Naztec controllers using Apogee Version 76.x firmware.  As I have said before, I am not a Naztec employee, or vendor.  I am a local agency traffic engineer who uses Naztec products.  I would assume that other brands of controllers and central systems can do similar operations.

In our case, each detection zone (each induction loop (or array of circle loops within a specific lane), video detection zone or radar detection zone is brought back into the controller using a unique channel.  The desire for detailed operational information drove the specific design of signal cabinets and detection systems.  We have a Caltrans 332 style cabinet which has a modified I and J file and wiring harnesses to take advantage of 46 unique detection inputs into the 2070 controller using the C1 and C11 harness.  The vast majority of our signal cabinets are NEMA TS2-1 where we have up to 48 or 64 channels of detection coming into the controller.  While this may seem excessive, the rich data we are provided through this expanded detection methodology provides us with a lot of tools to help our signals run better, and provide additional data for determining performance.

Each detection input is monitored in the controller for detection diagnostics along with logging volumes and occupancies on 5-minute intervals.  Almost all stopbar detection occupancies are tied to only log the occupancy when the signal is either green or yellow for the associated phase the detection channel drives in the controller.  In some cases, we choose to log green + yellow + red, or only yellow + red, but the vast majority of the stopbar detectors are logging occupancies only during green plus yellow.

In some cases, we do also mirror specific detectors to log green + yellow under one channel, but mirror the detection to log green + yellow + red, if we need additional information about how the lane is operating.

Why do we do this?

There are a lot of reasons.  One primary reason is that the central system is programmed to monitor each group of lanes for congestion.  The left turn lanes are separately monitored from the thru lanes.  When congestion occurs, the system logs the congestion levels, and specifically shows them on a map.  When specific thresholds are exceeded, the system also sends email notifications about a specific left turn or thru movement which has excessive congestion.

How do we do this?

As stated before, each controller's detection inputs are logging congestion data on 5-minute intervals.  That information is uploaded every 5 minutes to the central system via the Ethernet communications.  This is done mostly via fiber optic interconnect or Ethernet radios.  At some remote signals, the communications are accomplished via 3G cellular data modems.  We have had up to 4 signals reporting back continuously via cellular data modems without any problems.

ATMS.now – Congestion Monitoring Configuration

The basic congestion mapping for North, South, East and West is mapped on the scan screen, however functions within ATMS.now allow for additional information to be used for incident triggering.
Below is a picture of NE Hazel Dell at Ne 99th St, showing the detector layout and the basic N, S, E and W congestion mapping.

Screen shot of Naztec ATMS.now central system showing the detection, phasing, pedestrian
and other features.  The green lines with "Occupancy: #" show the percent occupancy during
the approach's phase green + yellow of the stopbar detection for the previous 5 minutes

Each detector used for this function needs to have occupancy, or volume checked in the controller (MM-5-2, Occup and Volum columns).  The reporting period of the detector data needs to be set to 5 minutes in the controller (MM-5-8-1).

Each of the directions need to be associated with the specific detection inputs for the congestion levels.  In addition to the north, south, east, and west congestion levels being defined, the other 4 are defined.

Screen shot of Naztec ATMS.now central system definition of congestion mapping for a
signalized intersection The user has the option of choosing congestion thresholds of
occupancy, volumes or speeds based on specific detection inputs.  The specific
threshold values for "Medium" and "High" correspond to the color of the lines
on the map for the congestion (low is green, medium is yellow and high is red).  The
specific medium and high thresholds also correspond to unique incident triggers
 that the central system can implement.

Under Definitions, Incident Triggers, create the incident triggers for the 8 locations.

Screen shot of Naztec AMS.now showing the incident triggers based on inputs

Note that there are 8 separate congestion alerts for each signal (1 for each left turn, and 1 for each thru movement).  This is true only where separate left turn lanes exist.  In the event that the left is permissive, this tracks the frequency that congestion on the permissive left turn lane exceeds the high threshold as set in the Congestion Level Definition.

One problem with this system is that when a loop fails, and constantly calls, this mapping will generate constant email messages.  If you look at the list above, under 3425, you will see that none of the day of the week boxes are checked (orange oval).  In this case, a contractor cut out the stopbar loops when they were not supposed to, and the controller is running in recall, with the loop amplifiers failing.  To keep the email messages from overwhelming the user, this approach’s two congestion incident triggers were turned off for weekdays.  This provides a good visual indication of where problems need to be fixed in the field.

Under Incident Trigger, create the congestion incident triggers similar to the following.  The text for the box “Description” is important, since this is the specific message provided in the email, and in reports run in ATMS.now.

Screen shot of Naztec ATMS.now incident trigger.  The specific time and dates when the incident
trigger is in place can be customized.  The incident triggers can also be set up based on
alarms or congestion to change the pattern, turn on a CMS sign with a message, turn on a video
camera which has been integrated into the central system software using the IV&C video relay
software, or send out an email notification

In general, the congestion incident triggers only run from 5 AM to 8:59 PM, Monday through Friday.

In the future, additional information will be included, such as camera triggers, to allow for future implementation of automatic PTZ camera viewing of congested areas.

The orientations on the incident trigger congestion and congestion level definition are as follows:

NB - North NBL – North West

SB – South SBL – South East

EB – East         EBL – North East

WB - West WBL – South West

The user distribution is set to Clark TMC Staff

Screen shot of Naztec ATMS.now central system showing how to set up the email alerts to a
specific group of users based on the incident trigger.

When the incident trigger criteria is met, ATMS.now will send an email to the people listed on the Clark TMC staff for the specific approach with the congestion alert.

The email sent will look similar to the following.  Note that the message in the text of the email is what was entered in the “Description” box of the incident trigger definition, plus the date and time.

If you do not populate the “Description” box with enough information, the emails will not have any specific meaning. 

Sample email from central system showing congestion incident

Specific reports can also be run within ATMS.now

Sample report from Naztec ATMS.now showing the reporting abilities

Like other reports in ATMS.now, the text of the report can be exported to Excel, PDF, Word documents and RTF formats, in addition to printing them out on a printer.

Additionally, specific reports can be run showing the relative congestion on specific approaches to the signalized intersections.

Sample of congestion reporting for sample intersection.  The different colored lines
correspond to the  specific occupancies of the stopbar detectors during
green plus + yellow of the signal for that approach's phase.

Conclusion

This is a lot of work to do.  There are dozens, if not hundreds of settings in each controller.  There are thousands of settings in the central system which must be made, and verified.  A detailed understanding of how each controller is connected to the unique detection system in the intersection is mandatory.  After the system is set up, all of the thresholds will need to be verified and adjusted to show what is truly special as opposed to regular congestion.

The net result is that this type of operation in a central system provides invaluable data for understanding where the problems exist regularly as opposed to occasionally.  Also, this type of approach to signal operations provides advance notice that something is happening in the field.  In many cases, the system has told me that something has occured (collision, failed detection etc) via this type of programming, and I am already working on the fix, or in many cases have already addressed the issue before the phone calls come in.

Truck Priority Traffic Signal Operation – a potential opportunity

This post is based on the reader understanding basic and advanced traffic signal controller overlap operations.  These are outlined at:

http://ntcip-unleashed.blogspot.com/2012/02/basic-overlap-information.html

and

http://ntcip-unleashed.blogspot.com/2012/02/advanced-overlap-applications.html

Trucks decelerate and accelerate slower than other vehicles.  The operation described here provides a method to allow the signal to operate such that when a truck approaches a signal at a point where the signal may normally gap out, or max out, the truck will have a better chance of getting through the signal on a green, reducing the frequency of truck stops.

 

In this example, the truck is approaching the traffic signal on a continuous 10% uphill grade.  The continuous 10% uphill grade breaks to relatively flat right at the signalized intersection.  Any large vehicle stopping would have increased difficulty in getting moving on a green indication due to the grade of the street.

 

This is not a sales document.  There are a variety of methods that can be used to determine the classification of the vehicle.  This method uses a Wavetronix HD Count station, located approximately 400 feet from the stopbar down the hill from the traffic signal.  The HD Count Station uses RS-485 communications from the count station to the traffic signal cabinet.  The processing is done within the traffic signal cabinet.

 

More information about the HD Count Station can be found here:

 

http://www.wavetronix.com/en/products/smartsensor/hd

 

In the cabinet, there is a Wavetronix backplane, which provides the power bus and the RS-485 com for the Click! Devices on the back plane.  This backplane also provides power and communications for the Wavetronix Matrix stopbar detection system.

 

One key componenet is the Wavetronix Click! 512 vehicle alert module.  This module was developed for overspeed conditions, not necessarily for truck priority.  The Click! 512 module allows the user to program 4 unique channels of output, where the combination of the HD Count Station and the 512 module will identify a large vehicle, and make different actions based on the speed of that large vehicle.

 

More information about the Click! 512 Vehicle Alert module can be found at:

 

http://www.wavetronix.com/en/support/product_lines/2/products/53

 

When a large vehicle is progressing towards the signal, and passes the HD Count Station, the Click! 512 module determines the speed of the large vehicle, and then places a contact closure output to a Wavetronix 114 detector card.  The relation of the speed range, and which input to the controller is shown on the table below.  These are starting points, based on the HD Count Station being 400 feet from the stopbar.
 

Controller Det Input	Speed Range	Lower Speed	Ph 12 Extension Timing
17	More than 40 mph	60 fps	7 seconds
18	30-40 mph	45 fps	9 seconds
19	20-29 mph	30 fps	13 seconds
20	15-19 mph	22 fps	18 seconds

The extension timing is the controller’s extension timing, such that the controller detection input will call and extend for the time listed, based on one or more truck priority calls.

 

The traffic signal controller operates in USER mode (a modification from the standard 8-phase dual quad operation).  The USER mode is configured such that phase 4 and 12 are sequential, running to overlap 12, through load switch 4.  Phases 4 and 8, and phases 8 and 12 will terminate simultaneously.  This means that when the signal is getting close to gapping out, or maxing out, and a truck approaches the count station, the signal will transition from phase 4 to phase 12, and hold the green for the approach with the truck, while also holding the green for the opposing thru movement. 

 

The phase sequence diagram looks as follows:

If additional trucks arrive while the signal is running in phase 8 and 12, the signal will continue to hold the green until either phase 12 gaps out, or the phase 12 max timer is met.

 

If there is no traffic in the opposing left turn, or on the side street, then the controller may cycle between 4 and 12, based on the actual traffic on the main street.  Even though the signal is cycling between phase 4 and 12, the drivers will not see a change in the state of the indications, since 4 and 12 are run on an overlap through the load switch for phase 4.

 

It is important to keep the min green time for phase 12 relatively short.  The detection inputs for phase 12 are set to call and extend.  If the signal is operating in phase 4 and 8, and ready to gap out, and a truck approaches the intersection via the count station, the count station system places a call to the controller on the specific detection channel associated with the approach speed.  The following will occur within the controller while displays attached to load switch 4 stays green.

 

• Phase 4 times the yellow interval (typically 3 to 4 seconds, depending on what the engineer sets it to)
• Phase 4 times the red interval (0 to 2 seconds, depending on what the engineer sets it to)
• Phase 12 times the min green interval
• The remainder of the phase 2 extension timing occurs

 

If the min green time is excessive, the signal will hold for a longer time than necessary.  For example, if the truck is going 40 mph uphill, the call and extend time on phase 12 is 7 seconds.  This should get the truck to the stopbar at 40 mph.  If the signal is ready to end phases 4 and 8 and move on to 2 and 6, the controller will stay green for load switches 4 and 8, while the call / extension for phase 12 causes the signal to hold that green through the timing of phase 4 yellow and red plus the phase 12 min green time.  If phase 4 yellow is 3.2 seconds, and phase 4 all-red time is 1.8 seconds and the phase 12 min green time is 5 seconds (10 seconds total), the signal will hold green 3 seconds longer than necessary for the truck.  However, if the truck is traveling at 20 mph with the same settings, the extension timing will hold the green for 8 seconds longer than the sum of phase 4 yellow and all-red plus phase 12 min green.

 

There needs to be a balance of the timing that will need to be set by field calibration.

 

If the signal is to be in coordination, Phase 12 will need to be given adequate time in the split divisions to function within the coord plan. 

 

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.