Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "BaSyx / Documentation / ControlComponent / Occupation"
| Line 48: | Line 48: | ||
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. | 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. | ||
| + | |||
| Line 56: | Line 59: | ||
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. | 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. | ||
| + | |||
| Line 63: | Line 69: | ||
==== Takeover ==== | ==== Takeover ==== | ||
| − | In addition to the OCCUPY command, there is a parameter for | + | 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. |
| Line 71: | Line 77: | ||
====Possible Take Over Implementation==== | ====Possible Take Over Implementation==== | ||
| − | The | + | 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. |
| − | In the Overtake command the new group control unit is named first. This is followed by all the single control units which | + | 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: | The command then process as follows: | ||
| Line 79: | Line 92: | ||
'''1. Checking the single control units''' | '''1. Checking the single control units''' | ||
| − | The first step is to check whether all the single | + | 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''' | '''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. | + | 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''' | '''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. | The single control units are not taken over directly by the new group control unit, but it appears so from the outside. | ||
| Line 93: | Line 106: | ||
'''4. Occupying the new group control unit''' | '''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 | + | 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''' | '''5. Checking all involved control units''' | ||
| − | Subsequently, all control units involved must be checked. This results in whether the test was successful or not. | + | Subsequently, all control units involved must be checked. This results in whether the test was successful or not. |
'''6. Resetting changed values''' | '''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. | 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. | Otherwise, all changed values are reset to the original value. | ||
Revision as of 07:25, 17 May 2021
This page summarises information about occupation mechanisms of Control Components.
Contents
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 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.
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.
Takeover
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.
Possible Take Over Implementation
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.