Skip to main content
Jump to: navigation, search

BaSyx / Documentation / ControlComponent / Occupation

This information is work in progress as part of the BaSys 4.2 project. This section is preliminary and subject to change during the project.

This page summarises information about occupation mechanisms of Control Components.

Handover and Takeover

Handover or takeover are methods for the safe transfer of device control units. Here, the occupancy of one or several device control unit is ensured from one group control unit to another one. The necessity of such methods arises from the fact that a deadlock can occur when several processes are running in parallel.

Description of the Problem

In a process, several group control units are occupied one after the other. These in turn execute operation modes and for this purpose occupy different single control units. After completion of an operation mode, the single unit is usually released again by the its group control unit. If necessary, the single control unit just released is now occupied by the next group control unit. If only one process is running on the system, there are no problems. But, if there are several processes running at the same time, there is the possibility of a deadlock. A second parallel running process could take the single control unit away from the first process after they have been released for the first time. Now the group control unit from the first process can no longer occupy the single control unit it needs to run its operation mode and so it is possible that both processes block each other from further progress.


Next, possible solution strategies are briefly explained.


Each process can occupy a control unit before and after critical situations. This means that only one process is active in each section. Processes can therefore not hinder each other. An advantage would be the good overview. However, this is at the expense of a dynamic process flow.


The group control units can occupy the individual control units on behalf of their process. This way all control units would be occupied by their respective process. This allows control units to be released only when the process no longer needs them.

Product Managment

Each object receives its own control unit (pallet, sleeve, coil, ...). The control units have different processes with which they are controlled. Accordingly, they move themselves from control unit to control unit. This has the advantage that objects are always assigned to a control unit and therefore cannot run into each other. In addition, it can lead to a very dynamic behavior. However, the effort is enormous. For each object, control units must be created and possibly also deleted again.


In addition to the OCCUPY command, there is a parameter for passing a single control unit. Let's assume that a group control unit has control over a single control unit. This should now be safely transferred to the next group control unit. With an OCCUPY command including a key (e.g. the process name or the name of the control unit) the safe handover to the new group control unit is now authorized. After that the new group control unit takes the single control unit. The previous group control unit can now safely release itself and all other individual control units.

Possible Take Over Implementation

The example of the command "Overtake=NewGCU,SCUA(PortA),SCUB(PortB);" is used to explain the current implementation.

In the Overtake command the new group control unit is named first. This is followed by all the single control units which are to be taken over by it, separated by commas. The server port is given in brackets after each unit. In the current syntax, the number of single control units to be taken over is variable. However, there must be at least one.

The command then process as follows:

1. Checking the single control units

The first step is to check whether all the single cntrol units can be transferred. Accordingly, it is checked whether the control units are really occupied by the previous group control unit. If they are not all free or occupied by the previous group control unit, the command is aborted.

2. Checking the group control unit

Then it is checked whether the new group control unit is free and the previous one is occupied by the correct operator. If not the command will be aborted as well.

3. Takover of the single conrol units

Now the s continglerol units are manipulated. The Actimode is set to zero. First, a possible occupancy command is deleted. Then the single control unit occupation outer text is changed to new group control unit. In addition, the SenderID is also rewritten so that the new group control unit is seen as currend sender.

The single control units are not taken over directly by the new group control unit, but it appears so from the outside.

4. Occupying the new group control unit

With a normal OCCUPY command, an attempt is now made to address the new group control unit. The control unit checks whether all important single control units are available. Accordingly it will try to occupy them. If it can do this, the control unit is successfully occupied and with it all transferred individual control units. Otherwise, the process must be restarted.

5. Checking all involved control units

Subsequently, all control units involved must be checked. This results in whether the test was successful or not.

6. Resetting changed values

If the transfer was successful and the new group control unit has adopted every single control unit, then only the Actimode of the single control units is now switched on again.

Otherwise, all changed values are reset to the original value.

Description of the lockdown problem

Back to the top