This document summarizes a distributed traffic control system model that uses messages to coordinate traffic light states between two 1-way roads. Each road is controlled by an identical traffic light controller subsystem that represents the various traffic signal states in a "Controller" statechart. Messages allow the subsystems to communicate requests, like pedestrian crossings, and queue them to be addressed later, modeling real-world traffic control.

1. %% Modeling a Distributed Traffic Control System Using Messages
%
% This example models an intersection of two 1-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.
% Copyright 2006-2015 The MathWorks, Inc.
%%
%
mdlName = 'sf_msg_traffic_light';
open_system(mdlName);
fig = figure(1);
set(fig, 'Visible', 'off');
%%
% A simple GUI to control the traffic signals has been created using
% MATLAB(R). 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.
%
subsysName = [mdlName '/Traffic Light 1'];
open_system(subsysName);
%%
% The main logic in each subsystem is represented by a "Controller" chart
% which describes the various states of the traffic signal.
open_system([subsysName '/Controller']);
%%
% 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 till 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 "PrepareToStop" state.
close_system(mdlName);
close_system([mdlName '_lib']);