This example models an intersection of one-way roads controlled using a distributed control system. In order to coordinate the traffic light state between the two charts, the two charts communicate with each other via messages. The two charts can thus be completely identical.
A simple UI to control the traffic signals has been created by using MATLAB®. The user can press the pedestrian request button under the pedestrian light to request a pedestrian crossing.
The controller for each road is represented by a traffic light controller subsystem. In this example, these are represented using the Traffic Light 1 and Traffic Light 2 subsystems.
The main logic in each subsystem is represented by the Controller chart which describes the various states of the traffic signal.
Messages are a convenient way to model such systems because of various semantic features of messages:
Messages are not discarded if they are not acted upon immediately. This allows us to model things like a pedestrian request naturally where the request is queued up until the traffic light turns red.
You can set up message "loops" between different components without needing to worry about algebraic loops.
Normally, input messages are destroyed at the end of the time step in which they are evaluated. However, you can preserve these input messages for use at a later time by temporarily forwarding them to a "holding" queue. This is demonstrated in the controller chart. In the outer transition flowgraph of the
Go state, when you get a message from the other controller that a pedestrian request has been made on the other road, you temporarily store that request on a local queue
pedRequestLocal. You can then check for that message at a future point. In this case, you check for the presence of that message in the outer transition flowgraph of the