Simulation phase

The best way to validate that the (merged) supervisor you synthesized during the supervisor synthesis phase is correct, is through simulation. Simulation allows you to try different traces though the state space, to observe what happens for different scenarios (use cases).

You’ll always want to perform simulations before moving on to the implementation phase. While simulation doesn’t verify the supervisor, but only validates it, it can give a high degree of confidence in your supervisor. Furthermore, through simulation you can find the most obvious problems (too much behavior allowed, not enough behavior present) with your supervisor, and potentially prevent physical damage to the actual machine. Finally, simulation is available even when the machine is not available, for instance because other people are using the machine, you are not physically near the machine, or the machine has not yet been built.

If you find that the supervised system exhibits incorrect behavior, you need to go back to your plants and requirements. If you are convinced that the system does not allow any undesired behavior, while it still allows all the desired behavior, you can continue with the implementation phase.

Simple simulation

The simplest way to simulate a supervisor, is to first merge it with the disabled events file generated during the event disabler phase, and then directly simulate the merged model with the simulator. The documentation of the merger and simulator tools provide more information, and explain how to manually invoke them.

The benefit of this ‘simple’ simulation, is that it does not require a simulation model. The downside is that you’ll have to choose traces by selecting transitions from a list of possible transitions at the console or from a GUI. This gives little insight into the state of the system, and quickly becomes cumbersome.

Interactive visualization-based simulation

An alternative to the ‘simple’ simulation, is to make use of the advanced features of the CIF 3 simulator. The simulator provides powerful visualization features, and even allows the simulation to be controlled/guided by the visualization, making the simulation interactive by clicking on certain elements of the visualization.

Using the simulator with a visualization not only requires an image to use for the visualization, it also requires a more detailed model of the plant. Such models are usually timed or hybrid models, unlike the untimed models used for supervisor synthesis. If you are developing a supervisor for your own system, rather than one of the four workstations used in the 4K420 course, you’ll need to create your own simulation model and visualization. For the four workstations, hybrid simulation models with detailed interactive visualization are provided as part of the course files. The #_sim.cif file (where # is to be replaced by the name of your system, as usual), contains the (hybrid) simulation model. It also contains the mappings that couple the image (#.svg file) to the simulation model.

To simulate, first you’ll need to merge the (merged) supervisor from the supervisor synthesis phase, the disabled events file generated during the event disabler phase, and the (hybrid) simulation model together into a single file. Then, you can use the simulator to simulate it.

Similar to the previous phases, a script is provided to automate these tools. The 2_simulate.tooldef2 script automatically performs all the necessary steps (synthesize, merge, disable, etc) to generate the file that can be used by the simulator. To execute the script, right click it and choose Execute ToolDef. The script is smart enough to prevent regeneration of files that are already up-to-date. Once the file is available, the script starts the simulator, using the appropriate settings. Once started, the option dialog appears. Click the OK button to start the actual simulation. To stop the simulation, you’ll need to terminate the simulator.

For further information on the use of the CIF 3 simulator, see its documentation. For further information on the simulation models and visualizations of the four workstations provided by the 4K420 course files, see their documentation. The latter also includes information on how to configure timer durations, and other configuration settings of the simulation models. These settings will also be used during the implementation phase.

Simulation and traces

Regardless of how you simulate (as described above), you should always be aware that a single simulation follows only a single trace (test case). That is, given two sensors that go on at the same time, the simulator processes the event of one of the sensors before the event of the other sensor. Similarly, if two actuators can be enabled or disabled at the same time, or if a sensor goes on or off at the same time as an actuator can be enabled or disabled, the simulator makes choices on what to do first. In general, no two events can happen at exactly the same moment.

When simulating interactively, you can manually choose each transition that is taken, and you decide the order, and thus the traces (test cases). When simulating automatically, the simulator chooses for you. When using the simulation scripts provided as part of the 4K420 course files, the simulator will always choose the first enabled event (where events are sorted alphabetically).

For well-designed supervisors, it shouldn’t matter which sensor signal the simulator processes first. Similarly, it shouldn’t matter which actuator is enabled first. After the first one, the second one should still be possible. However, it is possible to specify requirements that result in supervisors that don’t exhibit this behavior.

When validating your supervisor, simulating a single trace and making sure the supervisor behaves correctly for that single trace, is not enough. It doesn’t guarantee that your supervisor behaves correctly for all traces. As such, you should simulate multiple traces. You can’t test all traces, as there are usually infinitely many of them. You should come up with a finite number of traces (test cases) that cover enough of the behavior to be reasonably sure that you supervisor works in all cases.

As stated above, the simulation scripts provided as part of the 4K420 course files instruct the simulator to always automatically choose the first enabled event. By changing the -a first option in the 2_simulate.tooldef2 file to -a random, you can instruct the simulator to make random choices instead. This makes it possible to cover more different traces.

By changing the -i svg option in the 2_simulate.tooldef2 file to -i gui, you can perform interactive simulations, where you can manually choose what happens at what time, allowing full control over the traces you simulate.

By adding a "--complete=on", line (for instance after the "-a first", line) in the 2_simulate.tooldef2 file, you can enable the complete mode option. This will result in all possible transitions being printed. This may be useful in determining whether multiple controllable events are ever enabled at the same time, and whether that is a problem for your supervisor.

For more information on simulation of traces, see the Simulation of traces page of the simulator documentation. For more information on the different simulation modes (interactive, automatic, random, etc), see the Input modes page of the simulator documentation. For more information on complete mode, see the Complete mode page of the simulator documentation. For more information on output printed to the console, see the Normal console output page of the simulator documentation.

Ideally, you’d also perform verification, instead of just validation, but that is beyond the scope of the toolchain as it is explained here.