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:
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."
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."
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."
Has anyone gotten these to work properly with ASC/2? I seem too have a bug that ignores the scaling factor. This limit the "No Activity" alarm to between 1 and 255 minutes, which is pretty much useless.
ReplyDeleteHi Bruce.
ReplyDeleteEconolite used the scaling factor for a lot of diagnostics in the ASC series. I found the scaling factors cumbersome. Scaling factors may have been a way to get the bits of data to be more efficient in the data transfer.
We have / had about 40 Econolite controllers at one time, these included the 8000's, ASC2/, ASC/2s and ASC/3. None of these were on a central system. We had one corridor that had a dial up modem with an on-street master that talked to about 18 ASC controllers. At the end of this year, we will be down to one 8000 in the street.
Using the ped diagnostics really only makes sense if there is a central system actively monitoring the controllers. I use it as an advanced alarm system - when it is not working, let me know right away. Essentially, if the ped diagnostics fail, the signal goes into ped recall. This is unlike the vehicle detection diagnostics where if it fails, the controller can slip into an alternate form of detection.