User Tools

Site Tools


supcon:toolchain

Supervisory Control Toolchain (event-based)

This page provides an overview of the event-based supervisory control tooling. It also provides an overview of the toolchain, which illustrates the full path to take from specifying plants and requirements, via simulation, to the control of the actual hardware.

:!: Note that in Linux all commands are case sensitive!

Overview

The following figure shows an overview of the entire toolchain:

Toolchain overview

Notes about the toolchain figure:

  • The toolchain is divided into several phases. Each of the phases is described below.
  • The parts of the toolchain that are automatically performed for you by the supervisor synthesis script are indicated with dashed arrows. All the other arrows are solid, as must be performed manually, either using the SCIDE application or by using command line applications.

General tooling information

  • Always look at the output of the commands you enter. Most commands to not generate output unless something is wrong. In particular:
    • Lines starting with INFO indicate useful information. Always read this information to see if the data provided matches what you would suspect.
    • Lines starting with WARNING indicate something may be wrong. You should check all warnings and try to get rid of them.
    • Lines starting with ERROR indicate that something is definitely wrong. You need to get of all errors.
    • All other lines should be read as well. They provide status/progress/debugging/etc information.
  • Most of the applications have a --help (or -h) option. Use it to find out what certain options do and what other options are available. The most useful options usually have a one-letter shortcut name, beside the longer name.

Simulator

In the toolchain, the simulator is used to verify the correctness of the supervisor, by performing simulation of the supervisor merged with the untimed and timed plants (Untimed simulation phase and Timed phase respectively). In such cases visualizations can be used. See the exercises of week 1 for more information. The simulator is also used to control the hardware. In such cases visualizations can be used, but this is generally not recommended.

Step-by-step descriptions

This section includes step-by-step descriptions of each of the phases of the toolchain. You should follow the phases in the order given below. The steps are:

Specification phase

The following is a step-by-step description of the specification of the (untimed) plants and requirements, as well as the supervisor synthesis specification:

  • Start SCIDE:
    • In a terminal, enter:
      • scide
    • Note that as long as SCIDE is running, you cannot not use this terminal to enter additional commands. If you want to enter commands, please open a new terminal.
  • Using the SCIDE application, create a SCIM diagram.
    • Give the files a meaningful name, usually the name of the hardware setup. The figure above uses X as name, which is definitely not a good name, but keeps the figure small.
    • Model the plants and requirements. The plants specify the physical behavior of the hardware setup. The requirements limit part of the behavior. Together the requirements make sure that only the required behavior is allowed.
    • Don't forget about the marker states. You need at least one in each automaton.
    • Add a supervisor synthesis specification.
      • Don't forget to set the 'File format' property of generated automata. You need at least 'CIF' for the supervisor, to perform simulations and to control the hardware. However, if you want to view the supervisor in the SCIDE application, you need 'SCIM' as well.
    • Don't forget to save.
    • You end up with two files: X.scim and X.scim_diagram. The X.scim file contains all the model data, while the X.scim_diagram file contains the graphical editor information (like the positions of the locations etc).

Some hints:

  • Start with just a small part of the system, no more than a few sensors and actuators. Make plants and requirements, and go through the entire toolchain. Once you are convinced that your synthesized supervisor is correct, you extend the model with additional parts of the system. You go through the toolchain again. This way you incrementally build up your model. 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 very hard to track down the cause.

Supervisor synthesis phase

The following is a step-by-step description of the supervisor synthesis, including several conversions to and from the file formats used by the supervisor synthesis tooling:

  • Convert the SCIM model to a Core CIF model, using the scim2cif application. Use the --gen-synth-script (or -g) option to also generate a supervisor synthesis script. As you can see in the toolchain figure, you should end up with the files X.core.cifx and X_synth_sup. Example:
    • scim2cif -g yes X.scim
  • Run the supervisor synthesis script (by entering ./X_synth_sup in a terminal). The script does the following for you:
    • The Core CIF model is converted to multiple CFG models (with a .cfg extension), one for each automaton.
    • To the CFG models, the supervisor synthesis specification is applied. This includes the make_product and make_supervisor commands (indicated in the toolchain figure by the tool with make_* as toolname). This results in a CFG model of the supervisor.
    • The filename of the supervisor is determined by the name of the final (generated) automaton in the supervisor synthesis specification. If it is named sup, we end up with a sup.cfg file. It may be a good idea to name it XSupervisor, where X is once again replaced by the name of the hardware setup. In the above figure, sup is used, because it is short.
    • The CFG model of the supervisor is converted to a Core CIF model (with a .core.cifx extension). In the toolchain figure, this file is called sup.core.cifx.
    • The Core CIF model is converted to a SCIM model (with a .scim extension). In the toolchain figure, this file is called sup.scim.

For the 4K420 course, if synthesizing a supervisor takes a long time, follow the steps from the Availability of the tooling page to access the SE-RACK server systems using the ssh command. The SE-RACK systems are much faster than the lab PCs. Try to use an SE-RACK system with a low load (see http://se.wpa.wtb.tue.nl/status/). Please reserve serack-74 for real-time control and don't overload it with large synthesis calculations. After that, you can also try:

  • Make sure you only choose the output file formats that you are actually interested in. In the supervisor synthesis specification, select the file formats of the 'GenAutomaton' nodes. Usually, for products of plants and requirements you need nothing, and for the supervisor you need only 'CIF'. If you want to view the supervisor, you need 'SCIM', but for larger supervisors that is not feasible anyway.
  • Use pure restrictions if possible, as they only make the supervisor smaller. If you introduce memory (like counters), or other forms of sequencing (like order of controllables), that increases the size of the supervisor.
  • Try to separate your requirements as much as possible, to keep them simple. Also, leave out any events that are not relevant to a specific requirement.
  • You can try to restrict more of the system, to get a smaller supervisor.
  • Try to avoid duplicate requirements that enforce the same behavior in different ways.

You may get the “Supervisor is empty” error message, or a supervisor with only a few states (typically two or three, or only a few dozen, depending on the size of your system). In such cases, in which the supervisor was not synthesized successfully, you need to go back to the plants and requirements. Here are some hints on resolving this problem:

  • Make sure you have at least one marker state per automaton (plants as well as requirements).
  • Make sure your initial and marker states are consistent between all automata. For instance, in the example below, the plant can initially only do an action 'PushButton1On', and not a 'PushButton1Off'. The requirement is the other way around, it allows only 'PushButton1Off' in the initial state. The initial states (locations) are not consistent.

  • You can try the synthesis with a subset of the requirements, to find out which requirement (or combinations of requirements!) is causing the supervisor to become empty.
  • Make sure your requirements don't restrict the system too much. Requirements must never block uncontrollable actions. So, for all the uncontrollable actions in the synchronizing action set of a requirement automaton, you must make sure that the requirement does not block that uncontrollable action. You should look at the plants, to see when the uncontrollable actions 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 actions are possible. They should then also be possible in the requirement. There are two ways to solve the blocking of an uncontrollable action by a requirement:
    • The first solution, is to add a new plant automaton that models the relation between related actuators and sensors. By doing this, the uncontrollable actions are enabled in much less (combinations of) locations of the plants. This means that the requirements are much less likely to block uncontrollable actions. The relationship plant automata restrict the behavior of the plant model. However, the restriction is also present in the physical system. Without such relationship automata, the plant model has more behavior than the physical system. Once you have such relationship automata, you may assume this relationship in the requirements, meaning you may assume that certain uncontrollable actions can physically not occur in certain locations.
    • The second solution, is to add self loops in the requirement to allow the uncontrollable that was previously disabled (or blocked) by the requirement.
    • The first solution is recommended. However, it does not always apply. If it is not possible to use the first solution, you should use the second one.

Once you have successfully synthesized a supervisor, you can continue with the inspection of the supervisor.

Supervisor inspection phase

The following is a step-by-step description of the inspection of the synthesized supervisor:

  • Using the SCIDE application, initialize a SCIM diagram for the supervisor, using the SCIM model that was created by the supervisor synthesis script.
    • Before doing anything else, use the auto arrange functionality of the editor.
    • Optionally, manually improve the layout of the supervisor.
    • Inspect your supervisor and check that it contains only wanted behavior.
    • Save the supervisor SCIM diagram.

If you find out that the synthesized supervisor is not correct, you need to go back to your plants and requirements. If you think it is correct, you can continue with the untimed simulation.

Untimed simulation phase

The following is a step-by-step description of the untimed simulation. If you want to visualize the individual automata during simulation, you need a few additional steps. Below are two step-by-step descriptions, depending on whether you want to use visualization of the plants (1.), or not (2.).

1. Step-by-step description of simulation using the supervisor and the untimed plants, including some conversions required to make simulation possible:

  • Convert the SCIM model to a Core CIF model, using the scim2cif application. This time, use the --plants-only (or -p) option to only include the plants. You may also want to use the --output (or -o) option to make sure you don't overwrite the previous output of scim2cif (which included both plants and requirements). In the toolchain figure, this results in the XPlants.core.cifx file. Example:
    • scim2cif -p yes -o XPlants.core.cifx X.scim
  • Merge the Core CIF models of the supervisor and the untimed plants together into a single Core CIF model, using the merge-cif application. You can use the --output (or -o) option to specify the output filename. In the toolchain figure the resulting file is XPlantsSup.core.cifx. Example:
    • merge-cif -o XPlantsSup.core.cifx XPlants.core.cifx sup.core.cifx
  • Simulate the merged Core CIF model using the CIF simulator (the simcif application). Examples:
    • simcif XPlantsSup.core.cifx
    • simcif --visualize-automata=* XPlantsSup.core.cifx

2. Step-by-step description of simulation using just the supervisor:

  • Simulate the Core CIF model of the supervisor using the CIF simulator (the simcif application). Example:
    • simcif sup.core.cifx

Through simulation, verify that you only get the wanted behavior. Note that you cannot do this without trying different traces through the model! If you find that the system exhibits incorrect behavior, you need to go back to your plants and requirements. If you are convinced that the system only allows the wanted behavior, you can continue with the specification of the timed plants.

Timed phase

The following is a step-by-step description of the specification of the timed versions of the untimed plants you specified earlier:

  • Using the SCIDE application, create a CIFT diagram.
    • Give the files a meaningful name, usually the same name as the SCIM diagram.
    • Model the timed versions of the untimed plants you specified in the SCIM diagram.
      • The timed plants closely resemble the untimed plants. Often, they are exactly the same, except for the added clocks, guards and updates, which add the timed behavior (and thus make them timed plants).
      • Not all plants need the additional timing. However, you do need to specify all plants.
    • Don't forget to save.
    • You end up with two files: X.cift (model data) and X.cift_diagram (graphical editor information).

The following is a step-by-step description of the simulation using the supervisor and the timed plants, including some conversions required to make simulation possible:

  • Convert the CIFT model (of the timed plants) to a Core CIF model, using the cift2cif application. You may want to use the --output (or -o) option to specify the output file. In the toolchain figure, this results in the XTimedPlants.core.cifx file. Example:
    • cift2cif -o XTimedPlants.core.cifx X.cift
  • Merge the Core CIF models of the supervisor and the timed plants together into a single Core CIF model, using the merge-cif application. The options you used when merging the supervisor with the untimed plants, can be used here as well. In the toolchain figure the resulting file is XTimedPlantsSup.core.cifx. Example:
    • merge-cif -o XTimedPlantsSup.core.cifx XTimedPlants.core.cifx sup.core.cifx
  • Simulate the merged Core CIF model using the CIF simulator (the simcif application).
    • You can once again use visualizations if you like.

Through simulation, verify that your supervisor can handle the added timing. Note that you cannot do this without trying different traces through the model! If you find that the system does not exhibit the correct behavior, you need to go back to your (untimed and timed) plants and requirements. If you are convinced the system only allows the wanted behavior, you can continue with controlling the actual hardware.

Hardware control phase

Controlling hardware requires the hardware, the I/O system and specific software drivers that need to be in place before the supervisor can be used. This makes this part of the toolchain rather specific. It is written with the laboratory setup for the 4K420 course in mind: Festo Didactic workstations with EtherCAT I/O, connected to a Linux based PC with the CentOS 5.x operating system.

The following is a step-by-step description of the hardware control phase, including some conversions required to make controlling the hardware possible:

  • If you used one or more timer automata, which are not available as physical hardware, you need the timed plants for the real-time control of the actual hardware. If you didn't use such timer automata, you can skip this step.
    • Copy the .cift and the .cift diagram files to a new directory.
    • Open the diagram file in SCIDE and remove all automata that correspond to physical hardware (sensors and actuators), leaving the non-physical hard-ware, such as timers.
    • Convert the CIFT model to a Core CIF model, using the cift2cif application. You may want to use the --output (or -o) option to specify the output file. In the toolchain figure, this results in the XTimers.core.cifx file.
    • Example:
      • cift2cif -o XTimers.core.cifx X.cift
  • Obtain the hardware description file for your hardware setup. For the 4K420 course, see the workstations page for information on how to obtain them for the four workstations used in this course (you only need the hardware description file for your specific workstation).
  • Using the merge-hw application, merge the Core CIF model of the supervisor (--supervisor or -s option) and the hardware description file (--hardware-description or -w option), into a single Core CIF model. If you need timers etc, also provide the Core CIF model containing them (as last argument to the application). The merge-hw has an --output (or -o) option to specify the output file of the merged Core CIF model. In the toolchain figure, the resulting file is named XTimersHwSup.core.cifx. Example:
    • merge-hw -o XTimersHwSup.core.cifx -s sup.core.cifx -w Y.hw XTimers.core.cifx
  • On the lab computer, do the following:
    • In a terminal window, start the ECSIM application, as follows:
      • ecsim > /dev/null
    • You can ignore the following warning: WARNING: Could not set process priority: (13) Permission denied
    • The 'ecsim' application acts as an interface with the hardware (which is connected through EtherCAT technology) and the simulator. For more information on how we use EtherCAT in combination with the simulator, see the EtherCAT information pages elsewhere on this wiki.
    • Keep the ECSIM application running. Do not close the terminal window, as the ECSIM application must keep running for as long as we want to control the hardware.
    • Once you no longer need it, terminate the application by pressing <Ctrl> + <c>, and close the terminal window.
  • Make sure the system has power (two power sources) and pressurized air.
  • From a terminal on the serack-74 machine, do the following:
    • Follow the steps from the Availability of the tooling page to access the SE-RACK server systems using the ssh command.
    • Using the CIF simulator, control the hardware:
      • simcif -a inf -m 0 --ethercat=3 --realtime=3 --ethercat-host=se-WWW ZZZ.core.cifx
      • In the given command, replace se-WWW by the name of the lab computer. See also the workstations page.
      • In the given command, replace ZZZ.core.cifx by the filename of the merged Core CIF model (in the toolchain figure, this is the XTimersHwSup.core.cifx file).
    • Problem solving:
      • If you encounter problems with simulation speed (events are missed, possibly resulting in deadlocks), you can try --ethercat=1 --realtime=1 instead of --ethercat=3 --realtime=3.
      • If you get a deadlock during simulation, try the following:
        • If the deadlock happens during initialization (before event 'InitReady'), please scroll up in the terminal, to just above the print-out of the model. You can see the last action that was executed, something like this: 'Action: InitError_PushButton1'. This indicates that initialization failed, because sensor 'PushButton1' did not have the correct value. This kind of initialization errors may occur if you push the button during initialization, or if there is a product before one of the sensors, etc. Make sure the hardware setup is in the correct initial state and try again. Consult the workstations page for the initial state of the sensors and actuators of the four workstations.
        • Make sure the physical system does not allow for more behavior than your plant models.
        • If during real-time events occur too frequently, or too close together, the simulator might miss certain events from the system. This may cause it to miss updating it's state for instance for a sensor going on. When it then gets an event for that same sensor going off, this is not possible in the plant model, which causes a deadlock. Possible solutions are to use a faster system for simulation, to not push buttons for too short a time, or to use request/response semantics for sensors (see the workstations page}).

Verify that the supervisor correctly controls the hardware and only allows the wanted behavior. If not, go all the way back to your initial plants and requirements. If the hardware functions correctly with your supervisor, you've reached your goal.

NOTE: Testing correct behavior directly on the hardware may feel like a fast way to solve your control problem, but remember:

  • You need to have access to the hardware,
  • Each experiment needs you to reset the physical machine,
  • You cannot check all possible traces,
  • You may be tempted to 'do without thinking', especially when the system is 'almost working'.
supcon/toolchain.txt · Last modified: Monday, 29 October 2012 : 10:58:49 by dhendriks