The statechart simulation supports the simulation of multiple statechart instances. Simply choose a statechart and choose Run As > Statechart Simulation from the menu.
If the statechart defines variables which refer to other statechart types then the simulation engine will care about setting up the simulation scenario which includes statechart instances of the involved statechart types.
When starting the simulation for the statechart TwoWayTrafficControl the simulation view will list TwoWayTrafficControl.sct as the current simulation session. Additionally, the statechart instances which were created for the simulation session are listed as children of the simulation session.
The first statechart simply has no specific name and is of type TwoWayTrafficControl . The second and third are instances of the statechart TrafficLight. Their name is the name of the variables which are defined by TwoWayTrafficControl as statechart references.
If you click on the statechart instances then a simulation viewer for the specific statechart instance will be opened.
In the detail view below also the variables that reference statecharts are visualized with a statechart icon. You can unfold the details of the referenced statechart by clicking on the grey triangle.
The simulation engine creates statechart instances according to the following strategy:
As described in the previous chapters - statechart instances never create other statechart instances. Statecharts are created by the simulation environment.
After all statechart instances were created and connected the simulation engine will activate the root statechart instance. All other instances are not activated. This implies that the root statechart must initiate the activation of the referenced machine instances. This can be done by
If this is the case then everything works out of the box. There are additional cases where controlling the referenced statechart’s life cycle is not desired, e.g. to have a system of loosely coupled instances. Such systems typically just send events to each other and are inherently asynchronous. If you run the simulation for one of the involved statecharts then all instances except for the simulation root will never be activated.
In these cases you should setup an additional statechart which controls the life cycles of the loosely coupled state machine instances. This statechart defines the system behavior and thus we call it system statechart.
This case can be illustrated using the traffic light control example. Here, all involved statecharts interact using events. An additional statechart StreetCrossingSystem.sct defines the system behavior. This includes the start up sequence of all involved statechart instances.
The system statechart defines a reference called controller to a TwoWayTrafficControl state machine type. It does not start up everything immediately – what would be possible – but defines a set of states which define different system scenarios. The initial state is Off. In this state no state machine is active. By raising the event startAll the system enters the state On which makes sure that all state machines are active. Mention that the system behavior can access the referenced statecharts of referenced statecharts.
The system behavior also defines an additional state for each TrafficLight state machine instance. Here, a temopary outage of a TrafficLight is simulated by deactivating the machines.
System statecharts can be used to fully control state machines. They can be used to set up complex system scenarios and finally may automate execution sequences to bring the system in a defined state which would require much click work for the user.