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.

Concurrency Control

Asynchronus control unit managment include 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 group control unit. If necessary, the single control unit which was just released is now occupied by the next group control unit. If only one process is running on the system, there are no problems at all. 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.

Occupancy hierarchy collision.png

Another related problem lies in the affiliation of control units to physical objects. An object, such as a coil, is protected from collisions with other coils and unauthorized access by occupying the respective control unit (e.g. a roller table on which a coil is located). For this example, we imagine a roller conveyor. Each roller table is represented by a control unit. In the end of the roller conveyor, each Coil is transported away by a coil cart. Two different running processes control one coil each over the roller tables to the end. In this example, there is now a coil on the last roller table, ready for the coil cart. Behind it follows the coil from the other, parallel running process, which tries to occupy the next roller table contrul unit. In the first process, the control unit of the roller table must be released so that the coil cartcan occupy the roller table and transport the coil it away. But while releasing the roller table, the second process can occupy it and continue its own procedure. The roller table can now push the coil onto the first roller table without knowing that the coil from the first process is already waiting there. This results in a collision of the two coils.

Takeover Collision example 1.png

Several processes should run in parallel and adapt dynamically and individually to the external situation. For this, however, it is necessary to solve the handover problem. Processes must not hinder each other or trigger dangerous situations. Furthermore, there shall be no central control. The control units should be able to solve their problems themselves.


The transfer of a control unit must be ensured (e.g. The transfer of an individual control unit from one group control unit to the next group control unit). There are at least two conditions for a possible solution:

  • Collisions of physical objects must be excluded.
  • Deadlocks and unauthorized influence of processes on each other must not happen.

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.

To illustrate, let's imagine a roller conveyor again. Several pallets of aluminum coils are transported on the roller tables and then lift by a coil cart. The coil cart then transports the coil to a coating station, afterwards the coil is cut in another station. The two stations pose a variety of risks. Theoretically, coating and trimming could be performed in parallel, by different coils and different coil carts. To minimize confusion and ensure the necessary safety (deadlock etc.), overbooking can now be used. The first coil that enters the station blocks the entrance. This is done in the knowledge that the stations are a bottleneck and thus dangers and possible problems are avoided by only one coil passing through them at a time. The group control units can now release their single control units in this protected area and then reassign them without other processes interfering. The single control unit, which acts as "entrance" to such bottle necks (here e.g. the single control unit for the roller table in front of the stations) must be occupied at the beginning by the first group control unit and is released at the end by the last group control unit of this procedure. In order for the group control units to still function in other plants and under other conditions without major changes, input ports could be created. The start and end control units can now be entered here dynamically. Nothing happens with an empty value. Otherwise these control units are occupied at the beginning and left free later. With this method, safety takes precedence over dynamic behavior.

Overbooking pro cons.png


The group control units can occupy the single control units on behalf of their process. This way all control units (group and single control units) would be occupied by their respective process. In a process, a group control unit no longer has to release a single control unit so that another group control unit can take it.

Currently, in a procedure, each group control unit occupies its single control units and then releases them again after the operation is done. This is followed by the next group control unit. To prevent other processes from interfering, the release of individual control units must be handled differently. One possibility would be that the process occupies (this could be also done by the group contrul unit) and releases the single control units. The group control units would then simply use the single control units that were occupied by the process. When occupying group control units, it would therefore have to be queried whether the single control units it requires were occupied by the same process that also occupied the group control unit. The group control unit can occupy the single control units, but either not release them (this could be done by the process), or only on request from the process or an operator. As a result, the single control units would be continuously occupied. Only the process can release them or initiate this. So there would be no gaps between release and occupancy in which other processes could interfere.

Delegation with Assignment

The assignment remains as it is. This means in the normal case: The measure (e.g. by Camunda) occupies the group control units and these occupy the single control units. But in addition to this, an output port is set up on each control unit, which indicates the occupancy of the control unit by a process. This means that each control unit can be occupied simultaneously by a process (i.e. a measure) and another control unit. The group control unit could now take over a single control unit from the same process. This is similar to handover or takeover. But it simplifies the authorization.

Here, however, the focus is on the possibility of encapsulating processes. The fact that control units are additionally occupied by a measure means that they are protected by the occupancy of other measures. This ensures that processes do not interfere with each other. A single control unit must be released not only by a group control unit, but also by the measure. If a single control unit has been released by a group control unit, other group control units of the same process have a priotization in the occupancy. Only if also the process releases the single control unit, then the contol unit can be occupied by a group control unit of another process.

This consideration leads us to the following points:

  • Each control unit receives a new additonal occupancy automat and an additional occupancy output (assignment).
  • A new occupy (assign) and release (unassign) command controls this automat and the related output (assignment).
  • The measure can assign control units to make sure they are blocked for themself. The assign and unassign commands can be used by the measure or operator. But it is also included in the occupy command.
  • The Assignment is included in the occupy process. Before being occupied, the control unit checks if the assignment is correct.
  • Control units must be assigned before they are occupied. They can just be occupied when the assignment output is empty or assigned by the operator. Group control units use their own assignment as operator for the single control units - the assignment will be passed down.
  • Just the measure (or an operator) can unassign control units - it is not included in the free command.
  • An additional command (freeOccupancy) just sets the Control unit free not the assignment. The normal free command sets the assignment and the occupany free. Thus operators can use the control unit just using free and occupy. Measures, that use a more complex behavoir in general, can use the new assignment to avoid lockdowns.

Delegation pro con.png

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.

As an example, here would be an aluminum coil in a rolling mill. A group control unit must be created for the pallet with an aluminum coil. The pallet is thus represented by the control unit. The process specifies what should happen to the pallet. For example, a command could be that the pallet moves along a roller table. The group control unit of the pallet would address the single control units of the roller table and virtually move itself to the destination. However, the group control unit of the object must also have all commands for all possible operations and it must be able to address all single control units that it requires. Now objects can be created and destroyed in different processes. For example, when the coil is separated from the pallet. In this case, a new group control unit with the current position would have to be created for the new object, i.e. the coil. The creation and destruction of control units involves a special effort and could lead to further problems. During destruction, the group control unit releases its position (i.e. the current single control unit on which it is located). During creation, the individual control unit would first be occupied so that an object (or its control unit) can be located on it.

Product maganment pro con.png

Takeover and Handover

In addition to the 'OCCUPY' command, there is a parameter for occupyieng 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 without releasing it. With an 'OCCUPY' command including a key (e.g. the process name or the name of the control unit) a 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 single control units. It must be noted, however, that a takeover can only be executed after the previous group control unit has done its work, or that it knows about it. Otherwise, the previous group unit, from which the single control unit is taken over, could itself get stuck in its process.

Handover means the transfer of a control unit from one group control unit to the next one. This has the advantage that the group control unit knows when the process is ready and when the handover is safe. But the disadvantage is that the next group control unit remains passive.

Takeover pro con.png

Possible Take Over Implementation with the Help of Camunda

The transfer is currently not yet integrated in the group control units, but is executed by the process. The process sequence is executed by a task in Camunda.

The example of the command "Overtake=NewGCU,SCUA(PortA),SCUB(PortB),...;" is used to explain the current implementation. The execution of this command was programmed in Java and can be used within the process sequence by a task in Camunda.

In the Overtake command the new group control unit is named first. This is followed by all the single control units which should be taken over, 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. In Camunda, a command is executed in an action on behalf of the current group control unit. So the name of this control unit does not have to be passed in the command anymore.

To illustrate, let's take the following example: In a measure, a pallet is to be transferred from a roller table to a coil cart. There is a group control unit "PAX" and a single control unit for the roller tables. The movement on the coil cart is controlled by the group control unit "CX" and uses the single control unit for the coil cart "KE13". The roller table on which the transfer to the cart takes place is represented by the single control unit "PE024". When changing between the group control unit "PAX" and "CX", the single control unit for the roller table "PE024", on which the pallet is located, must be transferred without relasing it.

So the command in the Camunda process environment looks like this: "Overtake=CX,PE024". Without server (-ports) the control units are searched on fixed defined server (-ports). If not all control units are found, the command is aborted.

The command then process as follows:

1. Checking the single control units

The first step is to check whether all the single control units (in this example it is just the single control unit "PPE024") can be transferred. Accordingly, it is checked whether the control units are really occupied by the previous group control unit (here "PAX"). If they are not all free or occupied by the previous group control unit, the command is aborted, because the transfer would be illegal.

2. Checking the group control unit

Then it is checked whether the new group control unit (here "CX") 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

It was checked if the command would be legal, so now the single control 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 group control unit checks whether all single control units are available and if they can be occupied.With the help of the last step, it looks to the group control unit as if the transferred single control units are already occupied by it. Accordingly it will try to occupy them. If it can do this, the control unit is successfully occupied and with it all transferred single 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.

Possible Take Over Implementation on the control unit layer

To perform an overtake at the control unit level, all group control and single control units would receive a modified occupying sequence. With a normal "OCCUPY" command of the operator nothing would change. The group control unit could not take over the already occupied single control units. For the overtake, the group control unit needs at least the name of the single control unit that is to be taken over, maybe in additon a confirmation code that proves that the takeover is legitimate. In addition confirmation could consist of the name of the operator for the current and the previous group control unit within the overtake process. This would have to be passed on from the group control unit to the individual control units (a new port on each control unit) during normal occupying so that it can be checked within this process. The OCCUPY command with overtake parameter could therefore look like this: "OCCUPY;PE024;", where "PE024" represents the single control unit to be taken over. The occupancy automat of the group control unit goes through all single control units in the parameter list of the OCCUPY command. If the current group control unit and the group control unit of the single control unit to be taken over are occupied by the same operator (as an example of a leggtimation check), then the singlecontrol unit is taken over. After the single control units have been taken over, the occupancy automat can be continued normally.

Back to the top