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.