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.

Flashing Yellow Arrow Operation

This is a complete revision of a previous post on the same topic.  Based on new information, many of the controller settings were modified as shown below:

The operation detailed in this post is not a recommended operation, it is provided to allow engineers who work on traffic signal controllers ideas as to how Flashing Yellow Arrow signals could be operated.

The operation in this post details controller operations where the signal will not provide a FYA indication across a pedestrian movement that has a WALK or FDW indication that is active.

Flashing Yellow Arrow Operation

The Naztec controller has some specific things that must be done in order, to enable FYA.  The manual has some of the information, but not all.
 

One key piece of information is that the manual (as of December 2012 V.76, and Technote 1105 on the Naztec Website specifically use Overlap 1 (OLA) as the example overlap detailing the controller settings.  According to the Naztec rep’s email on January 21, 2013, the overlaps with FYA operation need to be on even overlaps (OL2, OL4, OL6… OL16), not on odd overlaps (OL1, OL3, OL5… OL 15).

 

When the FYA overlaps are on odd overlaps, the FYA appears to work properly until a preempt call is served.  The preempt call causes the signal that is operating on FYA to present signal indications that the monitor will not accept.

This appears to occur very occasionally in signals that are running in STD mode, operating with FYA indications.  However, when the signal is operating as described below, for No FYA across Ped Movements, the preempt call regularly presents signal indications that the monitor will not accept.

When the overlaps are mapped to even overlap numbers, the normal termination of a FYA operation due to a side street call, the signal should transition something like:

The main street greens (phases 2 and 6) and the main street FYA indications (phases 1 and 5) should all go yellow simultaneously upon the call to the side street.

When the overlaps are mapped to odd overlap numbers, the normal termination of the main street to a vehicle or pedestrian call on the side street operates the same as the above diagram, at least in Apogee V.76.7D, Build 3195, however when an emergency vehicle preemption call is served, the following phase operation will occasionally occur when the controller is in STD mode, but predictably occur when the controller is in USER mode:

The monitor will not accept a steady yellow on load switches 1 and 5, while greens are on for load switches 2 and 6, causing the signal to go into red flash.
By programming the overlaps running the FYA as even numbered overlaps, the controller has internal logic on the even numbered overlaps that prevent this from occurring.

No FYA across Ped Movements

The operation described here includes specific modifications of the controller operation to have the signal stop presenting a FYA indication to the left turn, when the pedestrian immediately to the left of the driver in the left turn pocket could have a WALK or FDW during normal operation.

A standard operation would be to allow the pedestrian movement to go to WALK and FDW while the corresponding left was in FYA.  In other words, if the NBL signal was in FYA operation, the SB ped would be given the WALK and FDW.

At issue here is what level of safety needs to be provided to the pedestrian while the driver is looking at for gaps in the oncoming stream of vehicles.  It could be argued that the left turning driver should yield to pedestrians to their left, however, if the pedestrian is traveling thru the crosswalk, to the left of the driver, going the same direction as a driver, the left turning driver may never look behind them while attempting to turn left for a person walking, running, biking or using other mode of transport while crossing the crosswalk.

Another operation would be to allow the FYA to terminate, and go to a steady red arrow, when a pedestrian received a WALK / FDW for the crossing.  This would likely create a yellow trap for the driver at a 4-legged intersection.

This operation would receive the pedestrian call, and wait for the signal to gap out, or max out on the main street traffic, then quickly serve the side street, them come back to the main street with the Ped WALK, and the conflicting left turn having a red arrow.

This is done by modifying the signal operation from the standard 8 phase dual quad operation.

Modifying the Phase Sequence

The following example is for setting up FYA for an intersection with the following basic operation:

The flashing yellow arrow will be for the eastbound left movement (Overlap 12 corresponding to Phase 1), and for the westbound left movement (Overlap 14 corresponding to phase 5).

The actual phase diagram is as follows:

The modified ring and barrier structure is set up to allow the FYA to flash yellow with the thru movements (1 with 6), but not with the peds (1 with 10).

The correspondence of the overlaps, and outputs is as follows:

 

The FYA output to the field wires is set up to connect to the (typically) unused yellow indication on the pedestrian load switches.  In this case, LS 9 drives Ped 2, and LS 11 drives Ped 6

  

Setting the Ring and Barrier Operation on Apogee V.76

 

There are several areas that need to be set up to make the FYA work.

The signal must be set to User mode.  To do this, go to MM-1-7, and turn the Run-Enable Status from ON to OFF, press enter, and the signal will stop running.  Next, go to MM-1-2-1 (Unit Parameters) and change the Phase Mode from “STD8” to “USER”. 

Now the ring and barrier structure must be modified to include the extra phases.   This is done via the signal sequence (MM-1-2-4):

  
The example here shows only modifying Sequence 1, but the user may want to modify other sequences.  

In general, when I am programming a special sequence that I don’t want to have the ability to undermine with potentially calling a sequence that may violate antibackup, or other features, I copy the only sequence I want to use into all 16 sequence entries, which means that there should be no way to have a sequence that creates a problem for the signal operation.

Next, the phase concurrency table needs to be modified to reflect the modified phases.  At this time, the signal is also modified such that it starts up in 9 and 10 WALK.  Normally, I start up signals in main street WALK.

This is done under MM-1-1-4:

Now that the ring and barrier structure is set for the controller, the signal run timer can be turned back on, under MM-1-7

Enabling the Specific Vehicle and Pedestrian Movements

  

The specific phases need to be enabled under MM-1-1-2.  The normal phases are enabled for the ped movements, plus phases 9 and 11 need to be enabled, so that the peds will time.

Time needs to be added to phase 9 and 11 peds under MM-1-1-1.  Also, any time for WALK and FDW for phase 2 and 6 peds need to be zeroed out.  In the example below, the ped timing, yellows and reds are what are operating in the signal cabinet for the intersection.

Specific timing is added to phase 9 and 11 for the min green, yellow and red.  This time is added, since the signal will be operating in soft recall during certain hours of the day.  Without having the appropriate clearance times for the phase 9 and 11, and the signal in soft recall, a late night pedestrian service may terminate from the main street to the side street at the end of the FDW without the signal going through the appropriate clearance times for the main street traffic.

 

Now the ped timing for phase 2 and 6 peds needs to be zeroed out.  The Peds that are normally associated with phase 2 and 6 are now phase 9 and 10 peds respectively.

Setting The Load Switches for the Overlaps

Now the load switches must be assigned for the overlaps.  The Channel I/O needs to be modified as follows under MM-1-8-1:

If you scroll to the right of the last column on the first screen , you will see the second screen that covers load switches 9 through 16.

The assumption on this second screen is that the channels were already modified so that the pedestrian load switch and overlap load switch assignments were modified to reflect that the peds were on load switch positions 9-12 and the standard overlaps were on load switch positions 13-16.

In this case, the load switches for 13-16 were actually modified to an unused input (changed to OL 16).  This was done to make sure that there was no problem with the overlaps being assigned to load switches 1, 2, 5 and 6.  Each specific installation will need to assign overlaps to the unused load switches that will not conflict with the other inputs.  Alternately, the unused load switches could be programmed to channel 0, which will result in a dark output.  The monitor will need to be programmed to accept a dark red output if the unused load switches are programmed to channel 0.

Setting up the Overlaps

There are several overlaps to be programmed for this operation.

• Overlap 12 and 14 are for the flashing yellow arrow.
• Overlap 9 is for the westbound thru / right movement
• Overlap 10 is for the eastbound thru / right movement

Starting with Overlap 9, the following parameters need to be programmed under MM-1-5-2-(9-Enter)-1:

For Overlap 10, the following parameters need to be programmed under MM-1-5-2-(10-Enter)-1:

Setting up the Overlaps for FYA Operation

For overlap 12, several parameters need to be added, including the type of overlap.  This is programmed under MM-1-5-2-(12-Enter)-1

The minus ped overlap parameters should not need to be programmed, However, if it is desired to program the negative ped overlaps, then this done under MM-1-5-2-(12-Enter)-2

For overlap 14, similar programming needs to be entered into the controller.  This is programmed under MM-1-5-2-(14-Enter)-1

The minus ped overlap parameters should not need to be programmed, However, if it is desired to program the negative ped overlaps, then this done under MM-1-5-2-(14-Enter)-2

Setting The Ped Yellows on Load Switches for FYA

Under MM-1-8-1, some values need to be modified for the output drivers.  In this case, the normal vehicle head for phase 1 (Channel 1) will be changed to run from Overlap 12 and the normal vehicle head for phase 5 (channel 5) will be changed to run from Overlap 14.

Now the controller’s operation needs to be modified to allow the overlap setting work with the controller outputs.  This is done by modifying the Channel plus parameters, under MM-1-8-4.  Once you are at the screen, scroll to the right, to bring up the screen that shows channels 9 through 16.  Modify the settings as follows:

This screen allows the controller to override yellow indications on load switches 9 and 11 to flash yellow as a driven output.  Normally, the yellows on the pedestrian load switches are steady on during the FDW clearance phase.  The steady on is a NEMA TS2 output standard.  This screen is the final item in the controller that must be enabled to get the controller to flash the ped yellow outputs, to drive the flashing yellow circuit on the left turns.

Setting the Pedestrian Calls and Detection Diagnostics

  

Now the pedestrian need to be modified to allow for to allow the pedestrians for phases 9 and 11 be mapped to the phase 2 and 6 inputs.  This is done under MM-5-4

Note that the MaxPres column has values other than zero.  Setting a value to other than zero for the MaxPres allows the controller to look for malfunctioning pedestrian buttons – where they are locked on.  This is covered in more detail at: 

http://ntcip-unleashed.blogspot.com/2012/02/pedestrian-detection-diagnostics.html
 

Setting Antibackup Operation

  

Now the antibackup feature needs to be set up, so that a ped call on phase 9 does not back up with a FYA on phase 5, nor a ped call on phase 11 does not back up to a FYA on phase 1.

The antibackup coding done via MM-1-1-5

Essentially, all of the work in the controller allows for the FYA to not operate across the pedestrian yellow

Setting Logic Processor To Serve the Side Street Before Serving Peds

One last thing needs to be done to the controller to allow the signal to cycle back to the pedestrian.  This is especially important to enable since the side street may have no traffic.  This is done by creating two logic statements to cause the signal to call a (typically) unused detector, and the detector then looks for an opportunity to call the side street.

The logic statements are coded under MM-1-8-7

 A quick conversion, from Section 12.6 and 12.7 of the Naztec controller manual

• I 64         (detector 64)
• I 130       (Ped call 2)  - The ped call is actually ped phase 9, but the physical input is 2 
• I 134       (Ped call 6) –  The ped call is actually ped phase 10, but the physical input is 6
• I 240       (logic flag)
• I 241       (logic flag)
• O 90       (Phase 2 on)
• O 94       (Phase 6 on)

Keep in mind, if you are coding this in ATMS.now, the columns in the data input screen in ATMS.now do not coincide with the columns in the controller.

 

Something to keep in mind about the logic processor.  The controller processes the logic from top to bottom.  The logic flags are set up to allow the controller to allow either ped

Setting Logic Processor To Serve the Side Street Before Serving Peds

  

The last controller function to set is to create a dummy input for detection channel to call phase 4 (the side street phase).  In this case, I selected detector input 64.  This detector input is unlikely to be used in normal operation.  If the controller operations use input 64 for a specific detection input purpose, then another detector should be selected.

Set detector 64 to call phase 4 under MM-5-1

Set detector 64 to be a calling detector, and to be a locking detector for red and yellow operation under MM 5 2.

Something to keep in mind about the logic processor.  The controller processes the logic from top to bottom.  The logic flags are set up to allow the controller to allow either ped call to serve the locking call to the side street.  Another way to reduce the logic statements by 1 line would be to have two unused detector channels used to place the call to the side street.

The logic statements could also be coded under MM-1-8-7

In this case, both detector inputs 63 and 64 would be coded to place locking calls to phase 4.

Emergency Vehicle Preemption Operation

The EVP channels on the approaches with the FYA operation should be set under MM-3-(EVP channel <enter>)- 8 to turn on the All Red B4 Prmpt.  The factory configuration has this off.

 

If the all red before preempt is not turned on, then an EVP call on the approach will create a yellow trap for vehicles in the left turn pocket when the signal transitions to preemption.

 

As stated before, if the overlaps are on odd numbers and the controller is running in USER mode, it is quite likely that any EVP call will cause the controller to transition where the monitor sees steady greens on the main street thru phases, and steady yellows on the main street left turn phases – which is a conflict.  As of Apogee V.76.7D, it did not matter what particular EVP call, or if the all red before preempt was enabled, any EVP call would cause the signal to display the conflicting greens and yellows while the FYA overlaps are programmed to the odd phases.

 

The EVP channels need to be programmed for the appropriate phase and overlap operation.  

 

The overlap exit phases can be tricky.  Normally, the EVP channels are programmed to end the call on any approach with the main street green thru’s (in this case phase 2 and 6).

 

This creates a problem, when the signal controller is programmed for anti-backup on phases 2 and 6.  When the EVP call ends, and the signal transitions from any EVP to 2 and 6, it does just that, without reliably bringing up the FYA indications that correspond with the phase 2 and 6 operation.

 

In general, the EVP operation and end of phase is programmed for this signal as follows:

 

 

By exiting the side street EVP call to the same phase, the controller will come around to the next movement, which is likely 2 and 6 including the FYA for corresponding lefts.

 

By existing the main street EVP call to the main street lefts, the controller will quickly transition to the main street green with the FYA active.

Min or Soft Recall

Once the controller has the programming as shown above, one final step needs to be made.  Phase 2 and 6 need to be in either min or soft recall.  Otherwise, under low traffic volumes, the signal will rest in phases 9 and 10, and the FYA will not turn on to the drivers.

 

Now, the monitor operation must be modified to allow the FYA to operate.

 

Settings in the Reno 1600 MMU for FYA

 

The monitor needs to be set up for the FYA operation.  In this case, phases 3 and 7 are future phases.  There are multiple methods for setting up the monitor based on how the load bay is being used.  This method is consistent with the programming of the Reno MMU Application Note AN-005 Example 3. This technote is available at Reno A&E’s website at:

 

http://www.renoae.com/traffic/files/Monitors/AppNotes/AN-005%20Flashing%20Yellow%20Arrows%2010-02-09.pdf

 

The particular screens for the Reno monitor for this operation in the test cabinet is as follows:

 

A couple of things to note. 

 

Load switch 1 and 5 are the steady RYG arrows of the FYA head.  Load Switches 1 and 5 need to have field check / dual enables turned on in the monitor.  With this done, the monitor should internally compare the load switch outputs of the 3 arrows on the load switch, with the corresponding flashing yellow arrow on the same 4-section head.

 

A flash transfer relay can go bad, where the outputs of the FTR are always flashing.  In one specific case during testing, the bad FTR caused load switch 1 and 5 to flash red, while the signal was operating with the flashing yellow arrow flashing on the same 4-section head.  While the monitor was set up to not have load switch 1 and 5 enabled for field check / dual enables, the monitor found no problems with the dual flashing of the FYA and the errant red flashing due to the bad load switch.  Once the field check / dual enables were checked for load switch 1 and 5, the monitor found the problem and kicked the signal into red flash.

 

 

Additional Thoughts on Pedestrian Detection

This is a continuation of a previous post, found at:

 http://ntcip-unleashed.blogspot.com/2012/02/pedestrian-detection-diagnostics.html

Generally, there are two pedestrian pushbuttons for each pedestrian phase.  These two inputs are wired in parallel to a single input.  The two buttons for phase 2 are wired in series to the input for ped phase 2.  This means that with most signals, the 8 pedestrian inputs are wired in pairs, to inputs 2, 4, 6 and 8.

Modern traffic signal controllers are capable of at least 8 pedestrian inputs.  Many are capable of 16 pedestrian inputs.  Traffic signal cabinets can be configured to include at least 8 pedestrian inputs.  Modern traffic signal controllers allow for mapping of any ped wire input to any controller ped input.  This can be done in two different places, one is in the mapping of the specific pins / BIU designation in the controller, and another in a pedestrian detection input screen.

Since normally the two pedestrian pushbuttons for any specific phase are wired in parallel to a single input, any problem on the parallel circuit will register in the pedestrian detection diagnostics as a failure on the ped phase input.  The parallel circuits for the two buttons creates a situation where the technician needs to spend extra time and effort to isolate which particular button / wire combination in the parallel circuit is failing.

Since multiple inputs can be mapped, the signal can be rewired to have each specific button / field wire set come into a unique input.  This would mean that when a failure occurred, the technician would have immediate knowledge of which particular button circuit was problematic.

A standard approach would need to be figured out.  A potential standard for the wiring could be:

Detection            Mapped               Near/Far
Input                     Phase
1                                 2                           Near
2                                 2                           Far
3                                 4                           Near
4                                 4                           Far
5                                 6                           Near
6                                 6                            Far
7                                 8                           Near
8                                 8                           Far

Where “Near” is the button closest to the approaching traffic on that that phase’s approach, and "Far" is on the opposite corner for the same phase.

This type of wiring, along with pedestrian detection diagnostics would allow for the central system to report the specific button that was failing.

This is important, as when ped detectors become stuck on, this causes added delay to the drivers waiting for pedestrians that don’t exist. 

Special consideration will need to be provided where there are more than 4 phases with pedestrian movements.  While most modern signal controllers include 16 ped inputs, not all modern signal controllers actually include data entry screens to map ped inputs 9 through 16 to anything, nor data entry screens to apply detection diagnostics to the ped inputs 9 through 16.

This type of approach will need to be clearly documented, and most importantly agreed to by the field technicians who will be implementing and using this type of approach.

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