We've probably all seen a car in an intersection -- rear end over the crosswalk and front end partially blocking the outside cross traffic land -- and they just stay there, never getting a green light to go. Or perhaps they have stopped 30 feet behind the crosswalk and they're stuck (and you're stuck behind them). There really is no mystery -- they are beyond the range of the sensor in the road and the traffic light system doesn't know they exist.
Traffic light systems are ideal for computer programming assignments. The basic system is very simple but it can be increased in complexity to understand more and more possibilities of design. I have used such systems as examples in a couple of my books.
The simplest form of traffic light is a blinking four-way stop (red lights). Not much of an advantage over a four-way set of stop signs except more visible in the dark. The next version can make use of a simple mechanical timer and set of switches (rather like many mechanical pool pump timers). The timer can revolve at a fixed rate and close contacts with the appropriate lights in the traffic system. It probably proceeds like
Green Red
-t- Red
Yellow Red
Red Red
Red Green
Red -t-
Red Yellow
Red Red
and back to the beginning. The "-t-" indicates some type of delay -- the length of time that the green light stays on for that direction. Note the two times that both directions are Red. This is very important for safety reasons.
This simple mechanical system has a timer and a set of connections to lights. The timer is an input and the connections are outputs. Mechanical systems can be designed to allow for a beautifully complex set of conditions but the actual construction becomes more and more precise and difficult to mass manufacture. It is much cheaper, and easier, to start adding microprocessors and programs to handle more complex operations.
With programming, the inputs are often extended to a clock, a set of timers, and one or more sensors. These are all concerned with events that affect the output -- which may be extended to include walk lights in addition to traffic lights. The programming may start taking into account the day of the week, time of day, whether it is a holiday, how many cars are waiting in a lane, and many other options. Once again, it can get pretty complex -- but most of the complexity is hidden in the programming and, thus, mass manufacturing is still possible (even reduces the cost per unit when more are made).
So, the car is stuck because the sensor no longer can tell it's there and it cannot use that as an event to trigger a light change.
Why go into all this detail? Who cares? Well, I find it interesting in itself but it's also a good prelude to talking about embedded processors in cars and the relation between complexity, sufficient testing, and safety which is definitely in the news of late. See the next blog
