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. 

 

A couple more thoughts about detection diagnostics

This is a continuation of the earlier post on detection diagnostics, at:

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

The detector settings need to be reviewed to make sure that the global settings are not creating undue consequences.

In one recent example, a left turn pocket had moderately high traffic volumes, and the stopbar detector was a 60-ft long quadrapole.  The length of the quadrapole created a situation where there was never a gap in the traffic, so the standard stopbar (standing queue expected) timing of 5 minutes max time / 10 seconds detector fail time, created a situation where the timer for the left turn signal gapped out cycle after cycle.

This was not a new signal, but one where the operation had been changed from one brand of signal to another brand of signal as a part of a systemwide upgrade.  The settings were consistent with the previous brand's operation, but some changes were made in the conversion.

In looking at the new operation, it appeared that the signal was gapping out consistently, but there was a static queue forming.  The signal was gapping out because the detector fail mode was only placing a call for 10 seconds, and if the traffic was over the advanced detector, then the siganl would extend for time beyond the 10 seconds.

After observing the operation for a short while, it was apparent that the signal was not getting enough time for the movement.  Determing the reason for this operation was complicated by the fact that the 60-ft quadrapole also had NTCIP Queue mode turned on.

The detector diagnostics operate on the raw feed of the detector into the controller, not on the processed controller operations of the detector.

After observing the left turn pocket's operation via video feed, some modifications were made to the detector diagnostics from 5 minutes max time / 10 seconds detector fail time, to 15 minutes max time / 20 seconds fail time.

Once the timing changes were made, the left turn pocket cleared out in a few cycles, and began operating as expected.

The moral of the story is that the signal operation needs to be monitored after changes are made.

Pedestrian Detection Diagnostics

One really nice feature of the new generation of controllers is the ability to assign pedestrian diagnostics.

One traditional problem with traffic signals is that a pedestrian pushbutton will become stuck, causing the signal to constantly cycle pedestrian WALK and FDW, without any pedestrians.

This is not to be confused with actuated rest in walk, or pedestrian recall.  In some cases, traffic signals are purposely set up to always bring up a WALK.  This can be very helpful in a downtown central business environment, or where there are no pedestrian pushbuttons, or where the pedestrian movements are typically heavy enough to justify constantly bringing up pedestrian movements.

At other traffic signals, like near schools, it is normal to have the traffic signal go into pedestrian recall automatically by the time of day programming during the times when pedestrians are likely to be crossing - such as during the half hour before, and half hour after the school is in operation.

Why Pedestrian Detection Diagnostics Are Important

Traffic signal controllers have specific needs in the coordination operations to make sure that under normal circumstances, the sum of the WALK, FDW, Yellow plus All Red equals the split division for that vehicle phase.  This means that under normal operations, the cycle lengths can become really long to accommodate all of the normal pedestrian timing needs.  This is getting even more problematic with the adoption of the 2009 MUTCD, and the recommended slower pedestrian speeds for the FDW timing.

Generally the corridor's timing needs are set by the largest intersection on the corridor.  All other signals have to be timed to have the same cycle length as the largest intersection, so the corridor may normally only work with a very long cycle length because of the needs of the largest intersections on the corridor.  While a huge intersection may need a 150 second cycle length to work within all of the timing parameters in the corridor,  other intersections may better work at a 90 or 100 second cycle length for most of the day.

For many years, controller manufacturers have put in "cheats" or "special features" to allow the signal to be tricked into allowing split divisions that are shorter than the sum of WALK, FDW, Yellow and All Red.  The Traconex 390 would allow these short split divisions, and give a special controller error, that allowed the controller to fail the edit checks for the split divisions, but stay in coordination.  Naztec has a "Stop In Walk" feature, that when enabled, times the split division normally until the split division timing equals 0, then the controller places a modified stop time into the program, and finishes timing the FDW, Yellow, and All-Red, then transitions to a special, aggressive, offset seeking mode to get back in coordination within a single cycle.  Other controllers have similar features, with different naming.

The special feature allows the controller to have the normal timing parameters running, but may allow a signal that wants to run on a 140 or 150 second cycle length to run at 90 second cycle length or shorter.  This will be true only if there are relatively low volumes of pedestrians.

This whole system falls apart if the signal has a stuck pedestrian pushbutton.  If the traffic signal needs 45 seconds for the sum of WALK, FDW, Yellow and All-Red, the split division is 25 seconds long for that movement and the signal is running on a short cycle length (90 seconds) then the signal will always be out of step, and in offset seeking mode.

The pedestrian diagnostics allow the signal to generate an alarm.  In the case of the signals I operate, the alarm is important enough, that the central system is constantly looking for these alarms, and when they occur, the central system automatically forwards an email to my work email to inform me that there is a problem with a stuck ped pushbutton.

Pedestrian Diagnostics by NTCIP

The NTCIP standards allow for special diagnostics to be run in the controller, similar to the vehicle detection diagnostics.  These are covered under NTCIP 1202 Section 2.3.7.3 Pedestrian Detector No Activity Parameter, Section 2.3.7.4 Pedestrian Detector Maximum Presence Parameter and Section 2.3.7.5 Pedestrian Detector Erratic Counts Parameter.  The reporting is covered under Section 2.3.7.6 Pedestrian Detector Alarms.

The three types of pedestrian detection parameters are defined as follows:

• "Pedestrian Detector No Activity diagnostic Parameter in minutes (0–255 min.) . If an active detector does not exhibit an actuation in the specified period, it is considered a fault by the diagnostics and the detector is classified as Failed. A value of 0 for this object shall disable this diagnostic for this detector."
• "Pedestrian Detector Maximum Presence diagnostic Parameter in minutes (0-255 min.). If an active detector exhibits continuous detection for too long a period, it is considered a fault by the diagnostics and the detector is classified as Failed. A value of 0 for this object shall disable this diagnostic for this detector."
• "Pedestrian Detector Erratic Counts diagnostic Parameter in counts/minute (0-255 cpm). If an active detector exhibits excessive actuations, it is considered a fault by the diagnostics and the detector is classified as Failed. A value of 0 for this object shall disable this diagnostic for this detector."

Recommended Settings

An important thing to understand about the pedestrian diagnostic parameters is that if you set any values, and the thresholds are met, the controller will place the signal in pedestrian recall until the problem goes away.

The Pedestrian Detector No Activity diagnostic Parameter is one that I generally don't touch.  After I explained the operation of pedestrian diagnostics to a friend who worked for an agency in Alaska, he put them into the signal.  Then all of the signals went into pedestrian recall late at night.  The problem solution was really tricky to figure out... Another person got the call out in the middle of the night, knew nothing about the special controller settings, and was completely baffled about why all of the signals were in pedestrian recall until a pedestrian pushbutton was pushed, then it went away...  They went to the next signal, pushed the buttons, and the problem went away.  Went to the third signal, pushed the buttons and the problem went away, but by that time, the detection error had reset itself (no other pedestrian buttons pushed at the first signal because it was in the middle of the night), so the first signal went back into pedestrian recall.

You can imagine the conversation in the signal shop the next morning.  It probably started with "What the..." and went downhill from there.

In general, I only set the Pedestrian Detector Maximum Presence diagnostic Parameter.

Generally, I set the max presence to 3 minutes.

The thinking is that somebody may push in a button, but not likely for more than 3 minutes.

I generally don't set the erratic counts.  I need to see how that works, where you have a button where the pedestrian pushes the button over and over again.


Other Pedestrian Detector NTCIP Stuff

The error states of this are defined as follows:

     Bit      Definition
     0         No Activity Fault: This detector has been flagged as non-operational due to lower than expected activity by the CU detector diagnostic.
     1         Max Presence Fault: This detector has been flagged as non-operational due to a presence indicator that exceeded the maximum expected time by the
               CU detector diagnostic.
     2        Erratic Output Fault: This detector has been flagged as non-operational due to erratic outputs (excessive counts) by the CU detector diagnostic.
     3        Communications Fault: Communications to the device (if present) have failed.
     4        Configuration Fault: Detector is assigned but is not supported.
     5-6     Reserved.
     7        Other Fault: The detector has failed due to some other cause.
     Once set a bit shall maintain its state as long as the condition exists. The bit shall clear when the condition no longer exists."

NTCIP Detection Settings

NTCIP Standards

The 1202 NTCIP standards allow for additional information to be provided by the detectors to the controller.  This allows the controller to display detector errors in addition to logging failed detection.

Under the 1202 section 2.3.2.13 Vehicle Detector Reported Alarms, the following as a mandatory data type.

     "This object shall return detector device reported alarms (via some communications mechanism). Inductive Loop Detector Alarms are indicated as follows:
     Bit     Definition
     0       Other
     1       Watchdog Fault: This detector has been flagged as non-operational due to a watchdog error.
     2       Open Loop Fault: This detector has been flagged as non-operational due to an open loop (broken wire).
     3       Shorted Loop Fault: This detector has been flagged as non-operational due to a shorted loop wire.
     4       Excessive Change Fault: This detector has been flagged as non-operational due to an inductance change that exceeded expected values.
     5-7    Reserved
    Once set a bit shall maintain its state as long as the condition exists. The bit shall clear when the condition no longer exists."

This may be a mandatory data type, but it only works if the communications between the controller and the loop amplifier is a data stream, instead of a wire with an ON / OFF switch.

TS2'ish Standards Within the NTCIP Requirements

Under the 1202 section 2.3.5.4.2 Occupancy data standard,  the detector provides the following information to the controller.

     Range      Meaning
     0-200       Detector Occupancy in 0.5% Increments
     201-209   Reserved
     210           Max Presence Fault
     211           No Activity Fault
     212           Open loop Fault
     213           Shorted loop Fault
     214           Excessive Change Fault
     215           Reserved
     216          Watchdog Fault
     217          Erratic Output Fault
     218-255   Reserved

The table above is essentially an continuation of the TS2 standards. 

This really only works if the controller has the ability to transmit not only the fact that the detector channel is on, or off, but provides a bit stream of data to the controller.  This can be done with TS2 detection, but not with TS1 or standard CalTrans 332 data.

By using the TS1 or 332 standard for detection, the detector provides a contact closure on a wire to an input on the controller.  This is either on, or off, not a system of transmitting data.

TS2 Detection Provides Better Intelligence 

With the TS2 standard, the serial communications transmits data streams between the equipment, which allows for more than an on / off switch, like the TS1 or 332 data.  The TS2 data stream is more robust, allowing for one set of bits to say one of the following messages

• "I was off, and I am still off"
• "I was off, and I am now on"
• "I was on and I am not off"
• "I was on, and I am still on"

along with a lot of other information, including the bits to define the data range from 0 to 255.

This is helpful for a bunch of reasons.  When any controller is talking to a central system, the controller and central system can be set up to log the detector failure status - based on whatever detection diagnostic parameters are programmed into the controller.  The TS2 controller can not only provide the fact that the diagnostic has failed, but it can also tell you what failed (see codes 210 to 217 from the list above).

This means that with a TS2 controller that is reporting back to a central system, the signal can provide actionable information to the engineer and technician to determine what the problems are, in addition to the fact that there is a problem.

It is a straightforward prospect to determine what has gone wrong, and help the fixing of a problem...  Is it a cut wire, or is it a splice?  Knowing in advance what happened to the loop can be the difference between going out to fix the problem, and then going back to get the proper equipment, or knowing that you need to schedule a loop cutter.  Since this data can be recorded in the central system, the user can run reports and determine what should be done system wide, and most importantly, find a bunch of loops that need to be replaced quickly, and efficiently - but only if the controller gets the coded information.  This is why we are looking at putting TS2 detection into 332 cabinets.

Detector Reset

Another TS2 / NTCIP standard requires the remote resetting of detection amplifiers.  Some controllers do this.  Many don't, even when they say they are "NTCIP" or "TS2".  I asked one controller manufacturer (who will remain nameless) why their controller and central system did not allow for remote resetting of detection amplifiers, even though they stated that they were fully NTCIP and TS2 compliant.  The response was "Nobody ever asked us about that".

From NTCIP 1202 section 2.3.2.14, Vehicle Detector Reset, there is a mandatory requirement that the detectors can:

"This object when set to TRUE (non-zero) shall cause the CU to command the associated detector to reset. This object shall automatically return to FALSE (zero) after the CU has issued the reset command. NOTE: this may affect other detector (detector channels) that are physically attached to a common reset line."


Other Reasons Why Data Is Better Than On / Off Switches

There is another reason why the TS2 detection is helpful.  Most NTCIP based controllers keep a log of the failures, including the detection failures.  One of the things that happens quite often, is an engineer or technician opens the door up, and they want to clear a fault by pulling the detector card, and resetting it...  Hopefully, the fault goes away.  What if you want to know what the reason was for the fault, after you cleared the card?

Since this information is kept in the controller, in a log, the engineer or technician can navigate through the controller menu to get to the logs, and see what the problem was.  In my case, we use Naztec Apogee software, so the code is reported as a hexadecimal code, not an easy number.  That is why I have a cheat sheet with me...

Advanced Overlap Applications - A Primer

Overlaps are traditionally used as Parent / Child (right turn overlaps), or as independent overlaps (timed overlaps or double clearance overlaps).  See discussion in the Blog Post on basic overlaps.

This Post starts talking about special uses of overlaps to do more with your traffic signal controller.

Think of an overlap as a tool that can be used to add flexibility to the rigid structure that your controller is chained to.  In general, the controller must follow the ring and barrier structure.  There is some flexibility in assigning time of day commands to cause the signal to have phase rotation (lead a protected left sometimes, lag a protected left at other times).

What if you wanted to:

• Lead and lag the protected left?  
• Lead the protected left and include a queue dependent lagging protected left?
• Create a queue dependent early release on an offramp while in coordination?
• Create a queue dependent early release for a lagging protected left?
• Asymmetrically double cycle a minor intersection within a long parent cycle length?

 and so forth.

Overlaps are the way to do these types of operations.  In future blog posts I will explain how to do the bulleted signal operations.

Older generation hard wiring of phases to load switches

Older Generation TS1 Equipment

So what am I talking about?  A little more explanation about overlaps is needed.  In older generation equipment, each phase was tied to a specific load bay position.  This was more typical for NEMA TS1 equipment than 332 style equipment.

Generally, on the TS1 controllers running in TS1 cabinets, this was something that required significant rewiring of the cabinet to do differently.

In general, the controllers were set up to have phases 1 through 8 assigned to load switches 1 through 8, then the peds then the overlaps to the remaining 8 phases.  If the signal needed something fancy, like a fifth ped, this created some interesting challenges for the engineer and technician to work out to make the conflict monitor work with the controller settings, and the cabinet wiring.

In the 1990's. traffic signal controller manufacturers started selling equipment that incorporated many of the TS2 functions into the same controllers that could be put in a NEMA TS1 or TS2 cabinet.  An Econolite ASC/2 is an example of this.  Eagle, Naztec, Peek and others had controllers that could be placed in either environment.  This can create some confusion, where users get a lot of new features that they can use, while staying in a TS1 environment.

Newer generation allows software reprogramming to load switches

Newer Generation TS2 and NTCIP equipment

Many of the TS2 controllers and all of the NTCIP controllers can be set up to allow any phase, overlap or pedestrian movement to be assigned to any load switch.  While this is revolutionary within the NEMA world, it was not groundbreaking.  Many of the 170 controllers could do this a long time before the NEMA world envisioned this ability.  The 170 and NEMA TS2 controllers still generally had few overlaps available for use.

This can create a really interesting mess of programming for the signal techs to figure out, if this is not documented.  In general, if you don't document what you are doing as an engineer, the field techs will not support it.  In reality, even if you do document what you are doing as an engineer, the field techs may not support it, unless you make it really clear what you are trying to accomplish.

Using overlaps to keep things clear, and improve the operations

Sorting out the remapping using overlaps

So why bother using overlaps to complicate things.  Generally, traffic signals are very rigid in how they operate.  The tools that exist such as conditional service and phase rotation can help, within limits.  By using overlaps to run specific load switches - instead of the phase outputs - the traffic signal controller can be made more efficient and help with the processing of traffic.

In the example to the right, phase 1 and 9 are connected to overlap 1, which goes to load switch 1.  This means that the controller can have phase 9 enabled, and added to the ring and barrier structure, which will allow the signal to do special things with phase 9.

One key to understanding this is that the pairs, or trios (in some cases) of phases that are routed through the overlaps to the load switches, are routed through an overlap with the same load switch the normal phase the phase would be routed through, allowing the monitor to be blind to this type of controller operations.

In other words, if you had three phases operating 7, 8 and 16 that are to be routed the normal operation of phase 8, these phases are routed to an overlap that is output to load switch 8.

IF you were to route 7, 8 and 16 to overlap 8, to load switch 6, you might have some problems.

Routing the phases to specific movements allows the signal to be modified without affecting how the MMU or CMU sees the inputs.

Following are examples of applications of how overlaps can be used to improve the signal operations.  More detail will be provided in specific blog posts about how this works...  

Example 1.  Easing the effects of phase rotation during coordination

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

By using an overlap to cover the protected left turn, while working through the detection parameters through alt tables, the signal can efficiently transition from lead to lag protected left turn without needing to go free, followed by offset seeking mode for several cycles.  This means that your transition from lead to lag will be seamless... A big help if you this is being driven by a traffic responsive system.

Example 2.  Special phasing coming out of railroad or emergency vehicle preemption

By using the overlaps and doubling up on the signal phasing on the overlaps, the signal can be forced to come out of preemption to specific phasing when the preemption phasing ends.

For example, if your preemption needs to force a call to a lagging left turn, but the lagging left turn is only to come up after preemption, Phase 1 can be assigned to the leading left turn with vehicle detection, and the normal timing parameters.  Phase 9 can have no vehicle detection, and be in the ring and barrier structure as a lagging protected left, with special timing parameters (a special min green etc).  The controller can be programmed to exit preempt to Phase 6 and 9, and phase 9 may be timed for a 20 second min green time.  This would force the traffic signal to come out of preempt, flush a specific movement, then go back to normal operation.

This type of operation would allow the signal to serve a specific set of movements, then go on to the opposing movements, rather than go 1 and 6, then 2 and 6, then 3 and 8.  The signal would go 6 and 9, then 3 and 8 for example.

Since phase 9 has no detection, the signal would never serve the movement, unless the signal was coming out of preempt.

Example 3.  Cheap and dirty transit signal priority

For example, you wanted to allow a low priority preempt call to extend a green for a thru movement, but only when the bus was coming with the EVP low priority active, phase 2 and 10 could be programmed in the controller to overlap 2, which is programmed to load switch 2.  Phase 10 may have 10 seconds of green time.

When the traffic signal receives a low priority preempt, the traffic signal controller has a logic statement that ties the low priority preempt to calling (and possibly extending) phase 10.  Phase 10 would only come up after phase 2, if there was a bus with priority on.

The coord plans can be set up to accommodate the timing on phase 10, for the potential of a bus needing just a little more time to get through the intersection, but when no extra time is needed, the coord plan will move from 2 and 6 to the next phases across the barrier.  With the use of fixed force offs, this bonus time could be provided to the side street if necessary.

Example 4. Cheap and dirty truck priority

If specific movement that had a lot of trucks, the phases could be assigned a special operation based on the presence of a truck.

For instance, for an intersection with a steep uphill grade, and heavy truck movements, a pair of phases can be assigned to the approach with the trucks.  For this example, the uphill movement with the trucks is phase 4.  Phase 4 is paired with phase 12, on overlap 4, to load switch 4.

With specific truck detection (pairs of loops with logic in the controller, video, radar etc) the traffic signal will detect large vehicles coming up the hill.  The truck detection is assigned to extend phase 4, and call and extend phase 12.

In the applications we are putting in place, we are using a dopplar radar detection system (I am not advertising the product, but it is a Wavetronix HD detection system).  The radar system will sense the vehicle, plus the speed of the vehicle.  Depending on what the radar system sees - large vehicle 15 mph, vs. large vehicle at 25 mph etc - the radar system chooses to place a call on any one of the 4 contact closures on the detection card.  The extension placed by the card for phase 4 and 12 will be longer if the truck is going slower, shorter if the truck is going faster.

This is not a foolproof method of truck detection, but it does allow for the signal to dynamically change its operation due to the presence of trucks - and decrease the possibility that a truck will need to stop on the hill.

Example 5.  Queue dependent early release

In this form of operation, the traffic signal has advanced detection at an intersection, such as an offramp.

The traditional way of dealing with offramp queues is to place a queue sensor at the offramp, at a point that the offramp would get close to backing up onto the high speed facility.  In the event that the queue of vehicles had backed up to the queue detector, the detector would place a call to the emergency vehicle preemption system, causing the ramp to dump onto the arterial street.  This is not very elegant, because if the arterial street is busy, there may be nowhere for the traffic to go to.

The other ways that traffic signals are programmed to deal with the potential of a long queue on an offramp backing up onto the higher speed facility is to give very generous time to the offramp.  So if the signal is running on a 120 second cycle length, the offramp may be given 50 seconds, just in case the offramp needs the time.  This creates a problem, where the offramp provides random arrival traffic to the traffic signal, where the arterial street is more likely part of a coordinated system which has platoons arriving.

The long offramp split division timing creates a situation where the offramp may only need 20 seconds to flush the static queue of cars, but then the offramp is held for another 15 to 25 seconds by single cars exiting the ramp extending the signal while the arterial waits.

Queue Sensitive Early Release

Queue Sensitive Early Release Phase Diagram Example

It would be far more efficient to develop a queue of cars on the offramp, then serve the queue, and go back to the main street.  The queue dependent early release timing parameters allows the signal to serve a normal timing to the for shorter queues, and when necessary, serve longer times for the offramp.



In general, this involves having stopbar detection, and advanced queueing detection, plus extension detection.  Most of which probably already exists.

For example, this is being done at a T intersection where there is a lot of traffic coming off the T onto a major arterial.  In this example, both phases 7 and 8 are tied to overlap 8, to load switch 8.  The pedestrian call is tied to phase 7.

When a short queue of cars exists, only phase 8 is called and served at the normal time in the coord cycle.  The radar detection provides extension to both phases 7 and 8.

When a queue of cars is on the detectors for phase 7, the signal ends the 2 and 6 coord phases early, and times phase 7, transitions to phase 8, then goes back to 2 and 6.  Phase 7 may have 10, 15, or 20 seconds depending on what is programmed in the coord timing parameters.

If a ped call is placed, the ped comes up with phase 7.

For an offramp application, the stopbar detection would call phase 8.  The early release queueing detection would be 250 to 300 feet from the stopbar detection, and call phase 7.  All of the advanced detection would extend both phases 7 and 8.  The queue detection for phase 7 would also extend both 7 and 8.  Ideally, the queue detection for 7, and the stopbar detection for phase 8 would have NTCIP Queue detection enabled.

The split divisions would be set up for the timing needed to serve the short queue (phase 8) and the longer queue (phase 7).  So for a 120 second cycle length, phase 8 would have maybe 25 seconds, and phase 7 would have 20 seconds of split division time.  If a short queue exists, the traffic signal would serve the amount of time for the short queue, and give all of the bonus time to the arterial.  If a long queue exists, the signal would terminate the arterial street 20 seconds early, and serve both 7 and 8.

Since this is a T offramp, there are no vehicles continuing straight off the offramp, all vehicle are turning right or left, the potential of needing extra extension for dealing with high speed vehicles is negated, and normal yellow and red timing can provide a safe and efficient transition from the offramp to the arterial.

Even better, using an advanced technology, like Wavetronix Advance detection (I am not advertising, but they have some great features) to have active dilemma zone monitoring will further improve the safety.

Example 6.  Dynamic lagging protected left timing

This operation is very similar to the queue dependent early release, but it is used to solve another problem.

Sometimes a coord pattern really needs some signals to operate with leading protected left turns and other signals to operate with lagging protected left turns.  The problem with lagging protected left turns is that a single car in the left turn pocket will cause the signal to start the green for the lagging left turn, and then hold it until the signal is ready to move to the other side of the barrier.  This means that a single car, or a short queue of cars in the left turn pocket with the lagging protected left may hold the signal  up for 30 or more seconds.  This can cause frustration with the drivers as they wait without any reason to do so.

In this example, the phasing of the signal would have phase 7 be the protected left turn with a short queue, and phase 15 precedes phase 7 in the ring and barrier structure - where 15 and 7 were tied to overlap 7, to load switch 7.  Phase 7 has the short queue detection, and phase 15 has the long queue detection.  The split divisions would be set up with 20 seconds on the split division for phase 7, and 10 seconds for phase 15, the total split division for 15 then 7 would be 30 seconds.

In the event that a short queue was present at the time in the cycle to begin the phase 7 left turn, only 20 seconds of split division would be served.  In the event that a longer queue was present for the phase 7 left turn, the traffic would start with 10 seconds of phase 15, followed by 20 seconds of phase 7.  The drivers would see the signal go green at the start of phase 15, the signal would stay green while Phase 15 times yellow and red, then transitions into phase 7 green.
 

Example 7.  Lead plus lag protected left turns

More detail will be provided for this type of operation, but essentially, the signal can be set up to provide a lead, and a lag protected left turn.

Queue sensitive protected lagging left turn - changed sensitivity by time of day

This can be very powerful, especially if the signal is set up to terminate phase 2 as efficiently as possible, leaving the bonus time to phase 9.  This can be done by making phase 6 the coord phase, and putting the signal into floating force offs.  The sensitivity of the operation can be changed by the time of day plan, by calling different alt tables for detection parameters.

If the signal has very heavy northbound thru (phase 6) and very heavy northbound lefts (phases 1 and 9), the signal can provide the timing necessary for the southbound movement (phase 2), and give a great deal of time to the northbound left.

Example 8.  Queue flushing through multiple signals with detection relay

This is a similar operation to the dynamic protected left turn operation.  The twist is that the signals are hardwired so that queued vehicles on one upstream intersection is hardwired to a downstream intersection.

In this case, we are relaying the vehicle detection call in a 332 cabinet by hardwiring the outputs of the specific detector to a 242 card in an unused detection slot.  The 242 card is hardwired to a 4cc/s cable that connects to a 242 card in another signal, and the outputs of that 242 card are wired to the input file of the second signal.

We have one of these going out to construction in the March of 2012...  more to follow.

There are opportunities for this type of application in a TS2 cabinet using an EDI SSM662 card to provide the contact closure input to the TS2 cabinet.


Example 9.  Active gridlock avoidance with double service

Active Gridlock Avoidance with Double Service

This is being implemented with the lead plus lag protected left turns.

In many cases, poor designs of parking lots affect the operations of the traffic signals.  In the example below, there is a very short stacking distance into the parking lot, and many times, the inbound traffic has nowhere to go, because of the yellow cars stacking into the first drive aisle.

In this case, there is a radar detector looking at the cars leaving the intersection, into the parking lot.  The radar is capable of not only seeing a queue of slow cars, but knowing exactly where they are, and how many there are.  When the radar detector sees a queue of slow moving cars on the inbound lanes of the entrance, the radar detector places a call to a normal detection channel.

The vehicle call does not extend the movement. Rather, the vehicle call is tied to a logic statement in the traffic signal controller, that translates the detection input to a force off for the specific ring that is feeding the entrance.

This is being implemented with the lead plus lag protected left turns, so that when this is enacted, the signal will come back and serve the movement a second time. 


Example 10.  Asymmetric Double Cycle

This takes a lot more explanation... 

Asymmetric double cycle is being implemented at a few intersections today by me.  It really works well.  This is not adaptive.  This is also not $50,000 to $70,000 per intersection

As a primer, look at the video.  This is a T intersection running an Asymmetric double cycle on a 150 second cycle length, with 600 vehicle an hour coming off the side street.

On the upper side of the picture is a roundabout.  There is only about 250 feet of storage before the signal backs up into the roundabout.  At the upper right of the picture is a 600 spot park and ride, which pulses out 20 to 30 cars after each bus arrives at the park and ride.

Watch the video, and decide for your self if it looks like this signal is running on a 150 second cycle length.