On Mon, Nov 21, 2011 at 11:16:14PM -0500, Jay Ashworth wrote:
>
> Precisely. THe case in point example these days is traffic light
> controllers.
>
> I know from traffic light controllers; when I was a kid, that was my dad's
> beat for the City of Boston. Being a geeky kid, I drilled the guys in the
> signal shop, the few times I got to go there (Saturdays, and such).
>
> The old design for traffic signal controllers was that the relays that drove
> each signal/group were electrically interlocked: the relay that made N/S able
> to engage it's greens *got its power from* the relay that made E/W red; if
> there
> wasn't a red there, you *couldn't* make the other direction green.
>
> These days, I'm not sure that's still true: I can *see* the signal
> change propagate across a row of 5 LED signals from one end to the
> other. Since I don't think the speed of electricity is slow enough
> to do that (it's probably on the order of 5ms light to light), I have
> to assume that it's processor delay as the processor runs a display
> list to turn on output transistors that drive the LED light heads.
>
> That implies to me that it is *physically* possible to get opposing greens
> (which we refer to, in technical terms as "traffic fatalities") out of the
> controller box... in exactly the same way that it didn't used to be.
>
> That's unsettling enough that I'm going to go hunt down a signal mechanic
> and ask.
The typical implementation in a modern controller is to have a separate
conflict monitor unit that will detect when conflicting greens (for
example) are displayed, and trigger a (also separate) flasher unit that
will cause the signal to display a flashing red in all directions
(sometimes flashing yellow for one higher volume route).
So the controller would output conflicting greens if it failed or was
misprogrammed, but the conflict monitor would detect that and restore
the signal to a safe (albeit flashing, rather than normal operation)
state.
-- Brett
