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 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.

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.

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.

Solutions

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.

Overbooking

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.

Delegation

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.

Takeover

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.