Supervisor synthesis phase

The second phase is the supervisor synthesis phase, which directly follows the specification phase. During this phase, the event-based supervisor synthesis tool and/or the data-based supervisor synthesis tool are used to synthesize a supervisory controller from the plants and requirements specified during the previous phase.

As can be seen in the toolchain overview figure, for each plants/requirements file, a separate supervisor is synthesized, using a supervisor synthesis tool. Then, if multiple supervisors were synthesized, the supervisors are merged together, to get one supervisor, in a single file.

If multiple supervisors are used, they need to be checked for conflicts, using the nonconflicting check tool. However, this tool is only available for event-based synthesis. If data-based synthesis with multiple supervisors is used, or a mix of event-based and data-based supervisors is used, the nonconflicting check can not be performed.

Manual vs scripted execution

There are two ways to start the synthesis tools, manually and automatically. Both are explained below, but the automatic approach is by far the easiest and less cumbersome, if it needs to be repeatedly applied.

Manual execution

To manually synthesize a supervisor for a plants/requirements file, use the event-based supervisor synthesis tool or the data-based supervisor synthesis tool. To merge multiple supervisors together, use the CIF merger tool. To check multiple merged event-based supervisors for conflicts, use the nonconflicting check tool. The documentation of those tools explains how to manually invoke them.

Scripted execution

The 4K420 course files contain scripts that can be used to automatically execute tools. For the four workstations provided with the course files, these scripts are provided. If you are working on a controller for your own system, you can use them as well, by copying them to your own project.

For each plants/requirements file (up to five such files), a script is available to synthesize the corresponding supervisor. The scripts are named 1a_synthesize1.tooldef2, 1b_synthesize2.tooldef2, etc. To execute such a script, right click it and choose Execute ToolDef.

The scripts generate the supervisors in a sub-directory named generated_files, which is automatically created if it does not yet exist. The supervisor files are named #_sup1.eventbased.cif or #_sup1.databased.cif, #_sup2.eventbased.cif or #_sup2.databased.cif, etc, where once again # should be replaced by the name of your system. If you are working on a controller for your own system instead of one of the four workstations from the course, you need to change the value assigned to the name variable, in the script itself.

The script automatically detect the plants/requirements files, and whether you want to apply event-based or data-based synthesis on them, based on their filenames, per the naming convention. They also automatically detect missing plants/requirements files, and skip the synthesis in such cases. Furthermore, they automatically remove generated event-based supervisors, if you switch to data-based synthesis, and vice versa. Finally, they automatically detect whether the plants/requirements have changed, and only re-synthesize if necessary.

The 1f_synthesize_merge.tooldef2 script can be used to merge the synthesized supervisors together to a single CIF file. As with the other scripts, the name variable may need to be assigned a different value, if you are working on your own system rather than one of the four workstations used for the course. This script automatically detects the existing synthesized supervisors, and (re)synthesizes them if needed. The resulting merged supervisor is written to a file named #_sup.cif. If multiple supervisors are used, the merged supervisor is also automatically checked for conflicts, if only event-based supervisors are present. If only data-based supervisors are present, or a mix of event-based and data-based supervisors is used, a warning is printed to the console indicating that the nonconflicting check can not be performed. The results of the check can be found in the #_conflicts.txt file, which is generated by the event-based nonconflicting check tool.

Empty supervisor

One of the most common problems that can occur during supervisor synthesis is the ‘empty supervisor’ error, or synthesis that results in a supervisor with only a few locations (typically two or three, or only a few dozen, depending on the size of your system). In such cases, where the resulting supervisor is not what you expect, you need to go back to the plants and requirements. Here are some hints on resolving this problem:

  • Try to use an incremental development approach. This ensures that if the supervisor is empty, you can be reasonably sure the problem is in the part you added since the last working version. If on the other hand you put the entire system in your model at once, and you get an empty supervisor, it is much more difficult to track down the cause.

  • Make sure you have at least one marked location per automaton (plants as well as requirements). Usually, marking the initial location is sufficient. For further details, see the section on Marking.

  • Make sure your initial and marker states are consistent between all automata. For instance, if in a plant you can initially only push a button, and then release it, but if in a requirement you must first release it before it can be pushed, you are likely to get an empty supervisor.

  • Make sure your requirements don’t restrict the system too much. Requirements must never block uncontrollable events. So, for all the uncontrollable events in the alphabet of a requirement automaton, you must make sure that the requirement does not block those uncontrollable events. You should look at the plants, to see when the uncontrollable events are possible. Then you should ask yourself, for each location of the requirement, in which locations of the plant you can be at the same time. For such plant locations, you should check which uncontrollable events are possible. They should then also be possible in the requirement. There are two ways to solve the blocking of an uncontrollable event by a requirement:

    • The first solution, is to correctly model the relations between the plants. For further details, see the section on Modeling the plants.
    • The second solution, is to add self loops in the requirement to allow the uncontrollable event that was previously disabled by the requirement.

    The first solution is recommended, but it does not always apply. If it is not possible to use the first solution, or if you already applied the first solution and still have the problem, you should use the second solution. However, never blindly add self loops. Always verify that this gives you the desired behavior!

  • You can try the synthesis with a subset of the requirements, to find out which requirement (or combination of requirements!) is causing the supervisor to become empty.

Conflicting supervisors

If the event-based nonconflicting check tool reports that the supervisors are conflicting, you need to go back to your plants and requirements. Either change your plants and requirements, or change the division of the system into parts, to resolve the problem. The report file generated by the tool may give you a rough indication of the problem(s). See the Using multiple plants/requirements files section of the specification phase for more information.