This is Part Two in a series about Traffic Signal Controllers. Part One showed various types of controllers and cabinets, here we continue with a closer look at a 1980s-2000s vintage controller: the Eagle EPAC 300, a 16 phase NEMA (National Electrical Manufacturers Association) TS-1 controller.
There’s not much to it on the outside: a membrane keypad and LCD screen for the interface and the “ABC” cables at the bottom for the inputs and outputs. The “A” cable feeds AC power to the controller, DC 24 volts from the controller to run the load switches, and all the inputs and outputs for a simple 2 phase intersection. The “B” cable adds phases three and four, and the “C” cable add phase five through eight. Each wire has a single fuction; there is no serial communication with the cabinet.
To the lower right of the controller are serial connectors for communications equipment, generally to a master controller or a traffic control center. Most newer controllers it’s possible to hook up to a computer with serial connections, and even newer ones may have integrated USB and Ethernet ports, but this is generally only done for initial programming. EPAC stands for Eight Phase Actuated Controller, despite some early units available with only two or four phases, and newer units having 16.
NEMA, conceived in simpler times, only had physical inputs and outputs (I/O) for eight phases. To use more than these, it’s necessary to electronically remap some of the I/O used for other marginal to useless features. NEMA has many features that either were never or are no longer useful; the I/O can be remapped and reused for other things on newer controllers, for instance there is a provision to have a “yellow” light for pedestrian clearance phases. Since instead the “Don’t Walk” is flashed, and these are in the cabinet wired to a the spare center section of the pedestrian load switches, these are normally used to drive things like pre-emption lights and blankout signs. Some controllers also had a proprietary “D” connector for such things.
NEMA controllers can operate by themselves as free-running controllers, or as a master controller that coordinates many of them. The EPAC 300 series is more or less still in production as the M50 and M60, though the Eagle name has been removed and is still owned by Siemens after the Eagle signal head business was sold off to Brown Traffic.
Some of the Screens
Although there are many screens, these can be broken down into (1) “Status” screens, that show what the controller is doing or logs of what it’s done, and (2) “Programming” screens where you enter what you want it to do. I’m omitting anything having to do with: Density and Time of Day Programming (where cycles change based on traffic volume and time), Coordination, Logging, Communication, Start up Sequence, Preemption, and Flash Mode. These are probably of marginal interest to non-engineers, some of these I don’t understand myself, and skipping them eliminates probably 95% of the complexity. Also omitted is anything having to do with actuation. Although some collectors will add video detection and pedestrian push-buttons to their setup (and there’s an amazing variety of buttons to collect), I have chosen not to. I have four phases with two associated pedestrian phases that run in sequence without waiting for calls.
Here is the main screen:
Let’s see what it’s doing first: go to 1-ACTIVE STATUS and then 7-INTERSECTION. The second line shows the phases and then “V-SIG” says they’re all red except phase 4 is green, below that P-SIG pedestrian outputs are “D” for “Don’t Walk” except Phase 4, which “d” means it’s flashing the “Don’t Walk” for the clearance interval. All the phases with physical outputs (1-8) default to red and “Don’t Walk” all the time unless programmed otherwise. In this case 4-8 are not programmed. If there were any Calls, these would be indicated under V-CALL and/or P-CALL. The Overlaps, with letters instead of numbers are additional outputs for driving such things as a protected/permissive display where you have a green ball and green arrow in the same direction. Not all of the vehicle overlaps have designated physical outputs. There are also pedestrian overlaps on a different screen (where you might give a “Walk” signal on one side only if there’s a green arrow the same direction; none of these have physical outputs).
Now suppose we want to play with things and see where values can be entered and changed. Go back to the main screen, select 3-PHASE DATA, then 1-VEHICLE TIMES. The MIN GRN is the green time in seconds for each vehicle phase. Phases 5-8 (and 9-16 on the second screen if you page down) have default values except for the zeros for MIN GRN, which disable them. PASS/10, MAX # 1, and MAX # 2 would extend the green if needed vehicle detection was used, since they’re not here they have no effect and the controllers default values are left in place here. YEL/10 and RED/10 are the yellow and red times in tenths of seconds.
Going back a screen and then to 3-PEDEST. TIMES. Phases 2 and 4 have pedestrian signals hooked up, with WALK time at 30 seconds and PED CLR. at 20 (5-8 will not activate since there are no associated vehicle phases and the numbers you see are default values). The FL WK will flash the walk light, now a MUTCD no-no, but previously used in DC to indicate a crosswalk where there vehicles might attempt to turn across. EXT PCL will continue flashing the “Don’t Walk” through the red and yellow vehicle phases. ACT RIW will hold the phase at “Walk” until a conflicting call come in.
Going back a screen and selecting 5- V&P RECALLS, we see Recall is selected for all four vehicle phases and both associated pedestrian phases (indicated by a “2”) So it will go through the cycle and service all phases without any demand from pedestrian push-buttons or pedestrian sensors. Entering a “1” will generate a call to test the controller in case physical test buttons aren’t provided in the cabinet. DELAY allows you to set a time before Recall is activated.
Why Can’t Signals Do What We Want?
Quite often the question gets asked “why can’t a traffic signal do this, or why doesn’t it do that”. Now with a bit of understanding of controllers and cabinets, lets go over a couple of broad reasons why things are or are not done a certain way.
1) It’s required or banned. The Minnesota Manual on Uniform Traffic Control Devices (MUTCD) based on the federal one with some very minor changes, has options , strong suggestions, and absolute requirements. Engineers are not likely to deviate from suggestions, and may not deviate from requirements. Banning creativity might preclude the best response to a specific situation, but on the flip side road users can expect uniformity nationwide. When traveling, they’re not going to encounter a flashing purple arrow in Peoria or a pink strobe-light in Paducah and then have to try to figure out what those mean. If a city really wants to try something new out, say a red arrow on top of a standard three light signal to emphasize no turns on red (not currently a legal configuration), they can apply for permission to experiment, do a study, and then either remove it if a study shows no benefit, or it may be adopted into the MUTCD if it does.
2) It’s often a zero or negative sum game with intersection capacity a fixed resource, since pedestrians and motorists compete for the same resource, and the needs are completely opposite. Right on red or longer overall cycle times: pro-motorist, anti-pedestrian. Exclusive walk phase or leading pedestrian intervals: anti-motorist, pro pedestrian. Other people may not see it this way, and are surprised when I describe “pedestrian improvements” as “anti-motorist”, but ultimately that’s the effect even though there may have been intent to harm vehicle operations (although sometimes there is). Additionally since pedestrians move a lot slower, sometimes a very modest benefit for pedestrians can produce an extremely severe impact for motorists, like ped recall across a wide suburban-style road. More details on some of these scenarios will be in the next part.
3) A lot of equipment on the field is very old. Even computerized controllers tend to use 1980s vintage microprocessors like the Motorola 86040, and the need for standardization dampens innovation. This is more true in the cities were demand for pedestrian amenities is greater. Until very recently Minneapolis even had electro-mechanical controllers. Old controllers may not have the capabilities that people want. But it still works and cities are not made of money. In some cases even what seems like a minor change could require a complete cabinet replacement, or even a bigger cabinet requiring a bigger concrete pad and redoing a lot of the wiring, and the cities are not likely to do that just because someone wants a leading pedestrian interval or something.
Although we’ve come a long ways from a free-running E/M controller in every light, even the newest controllers are nowhere near as powerful as a PC. (You may have noticed the line “16 MHz CPU” and a 2000 firmware date on the main screen of mine.) Even if they were, in most situations the input and output are still limited, with the only input available being vehicle sensors and pedestrian buttons and only output being lights. They can’t look at a a bunch of cameras focused on the intersection and down the block and make decisions based on it, or sound a fog horn if they see a motorist inching into the crosswalk. Things are getting better with multiple vehicle sensors that can thus measure vehicle speed (one controller even has a “feature” that will turn the light red if an approaching motorist is speeding) and the new Linux based controllers that are more flexible in certain ways.
Sometime upgrading the firmware on existing equipment is possible, but besides the expense and need to go out and swap out chips or update the flash memory, engineers like to have known, stable, and consistent firmware. At least once Mn/DOT has had to back out and revert to an earlier firmware version because of bugs. Mine is running 2000 firmware and would require an upgrade to do leading pedestrian intervals.
There is also the “SMART” Signal system, which tries to harvest and aggregate data gathered by standard controllers together using industrial PCs and use it to dynamically optimize timing in a way that’s not possible with traditional manual coordination. The controller is an Econolite ASC series, the Mn/DOT standard and most widely used in Minnesota.
4) Old-Fashioned engineers. To end with the elephant in the room, sometimes it really is engineers that are just set in their ways and not taking the needs of pedestrians seriously or being open to modern ways of doing things. And it’s not just signals; they admitted the trails associated with the St. Croix Crossing are only worked on “as we have time”. And closed down the sidewalk on the Hastings Bridge for the entire duration of the project even when there was no work being done anywhere close to it. However the point I’m trying to make is there usually more too it than some “dumb engineer sitting in a chair in Medina” not wanting to put down his donut in order to click an icon on the computer in front of him.
Overall, the idea isn’t to pass value judgments or state my opinions on what is or is not a worthwhile change, even though perhaps the fact that 95% of the time I’m a motorist shows through. Rather, what I’m trying to do is lay out the reason things are the way they are. Part Three will go into specific scenarios about why things are (or aren’t) done so I would suggest holding off specific questions on “why can’t/don’t signals do this” until then.
Streets.mn is a non-profit and is volunteer run. We rely on your support to keep the servers running. If you value what you read, please consider becoming a member.