Traffic Light Logic - A Finite State Machine Example

A "finite state machine" (FSM) is a model of computing in which the program is conceived as a machine which can be in one of a finite number of states. The FSM model is proposed as having advantages for a variety of applications and the example of a traffic light is often given, so it seems worthwhile to see how the Blockly for Business Logic "flat functional specification" would look for a traffic light example. For comparison, a traffic light example implemented in the machina framework can be found here.

The example implements BBL for a traffic light having the following requirements:

• a north-south main street is green for 180 seconds, then yellow for 5 seconds
• an east-west secondary street is green for 20 seconds, then yellow for 3 seconds
• there is a 2 second delay after one street turns red before the other turns green
• the east-west walk signal (for crossing the north-south main street) has:
• a 5 second start-walking signal
• a 20 second continue-walking signal
• the north-south walk signal (for crossing the east-west secondary street) has:
• a 3 second start walking signal
• a 5 second continue-walking signal
• there is a walk-request button for the east-west walk signal

Top Level Specification

Here is the BBL "flat functional specification" that implements the requirements:

This top level specification contains five outputs:

• a possibly new color for the east/west light, or empty for no change
• a possibly new color for the north/south light, or empty for no change
• a new state for the east/west walk light (start walking, continue walking, or don't walk)
• a new state for the north/south walk light
• an output to reset the east/west walk request when it has been handled

East/West Light Change

The specification for the first output, possible east/west light change, begins as follows:

If the east/west light is green and has been for 20 seconds, turn it yellow. Otherwise, if it is yellow and has been for 3 seconds, turn it red. This is the rest of the specification:

If the light for the other direction, the north/south road, is red and has been for at least 2 seconds, then turn the east/west light green. If none of these conditions are met, return an empty result, which means to leave the light unchanged.

North/South Light Change

The specification for light changes for the north/south road is similar, except that the durations are different and there is logic for handling the east/west walk request.

The north/south light changes from green to yellow if it has been green for 180 seconds, or if an east/west walk request is being processed. The east/west walk request is handled if the north/south light has been green for at least 20 seconds and the north/south walk signal is at "don't walk", because obviously you don't want the light to change while the north/south walk signal is still at "walk" or "continue walking".

Walk Signals

Below is the first part of the specification for changing the east/west walk signal.

When the east/west light is green, the walk signal changes to "walk" until it's been green for 5 seconds. This is the continuation:

When it has been green for 5 seconds, it changes to "continue walking" until it has been green for 25 seconds, when it changes to "don't walk". The north/south walk signal is similar, but with different durations.

Resetting the Walk Request

There's a pedestrian button to request the light to change when crossing the main north/south street, which otherwise has a long, 180 second green light. The pending request is reset when the east/west light turns yellow.

Processing Loop

The code created from the flat, functional specification defined in BBL is called in an implied loop implemented outside of BBL. The BBL-generated code would be called at least every 1/2 second, passing the current state of the lights and the length of time they have been in that state, and receiving back the new state.

Generating Code

One of the most important benefits of the BBL model of active specification is that the specification can be translated directly to multiple target platforms. In this example, a simulator may be created for validation, and when validated, a translation to a completely different target language may be required if, as is likely, an embedded platform is targeted. Many cities now have centralized network control of traffic signals. With the logic specified in BBL independently of these implementation details, it becomes more efficient and more reliable to change the target platform. Once a new translator is implemented for the new target environment, migration should go much more quickly and smoothly.

Conclusion

There are quite a lot of different possible configurations for traffic lights. Some intersections have more than two roads intersecting. There may be left and/or right turn signals. Sometimes all the traffic lights are supposed to be red when pedestrians are crossing. Sometimes you don't get the walk signal at all unless you request it. The BBL model lets you get control of a wide range of logic like this, and analyze and validate it with a minimum of distracting and irrelevant verbiage, with the objective of achieving rapid and highly reliable development and maintenance.