Access the full text.
Sign up today, get DeepDyve free for 14 days.
L. Robertson (1990)
Introduction to operating systems
P. Janson (1985)
Operating Systems: Structures and Mechanisms
E. Coffman, M. Elphick, A. Shoshani (1971)
System DeadlocksACM Comput. Surv., 3
AS Tanenbaum (2002)
Moderne Betriebssysteme
Stephan Mayer (2011)
Development of a completely decentralized control system for modular continuous conveyors
Edward Coffman, Peter Denning (1973)
Operating Systems Theory
Abraham Silberschatz, Peter Galvin, Greg Gagne (1983)
Operating System Concepts
Y Rekhter, T Li, S Hares (2006)
A broader gateway protocol 4
박재현 (2003)
Open Shortest Path First Protocol을 위한 대수적 형식 명세 및 분석
C. Hedrick (1988)
Routing Information ProtocolRFC, 1058
(2002)
A broader gateway protocol 4. The Internet Society
(2002)
Moderne Betriebssysteme. Pearson Studium
(2000)
Netzwerkprotokolle in Cisco Netzwerken
Logist. Res. (2010) 2:147–158 DOI 10.1007/s12159-010-0035-4 OR IGINAL PAPER Deadlock prevention in a completely decentralized controlled materials flow systems Stephan Mayer Kai Furmans Received: 15 September 2010 / Accepted: 15 September 2010 / Published online: 22 October 2010 Springer-Verlag 2010 Abstract In this paper, we develop policies to prevent Even where the initial investment is not prohibitive, the deadlocks in a decentralized modular materials flow. The option of conventional fixed installations of continuous system consists of locally controlled conveyor units conveyor systems and the related necessity of a centrally, (modules) that can be plugged together in order to flexibly individually programmed control are not cost effective in interconnect materials flows within a given production many cases, because increasingly shorter product life area. The controller of each module is a local agent that cycles in industry cause frequent changes in material flow follows its own specific control rules. The behavior of the patterns and volumes which, in turn, cause high change- overall system is generated as the result of the interaction over cost and are time-consuming. The alternative use of of the modules. The findings in this paper are based on the driverless transport systems as an automated solution fea- dissertation research by Dr. Stephan Mayer (Development tures higher flexibility, but typically features significantly of a completely decentralized control system for modular lower throughput and relatively high investment and continuous conveyors. Dissertation, Universita ¨tsverlag operating costs. Karlsruhe, 2009), which provides a comprehensive des- Even though manufacturers of continuous conveyors cription of the development of decentralized control poli- offer systems that are modularly constructed and easily cies for in-plant continuous materials flow systems. connectable, the expenditures for changing their configu- ration are still high, when conventional systems of central control are being applied. Reconfigurations and customiz- 1 The limits of centrally controlled materials flow ing of those systems require extensive rewiring or, at the systems least, rewriting the control programs. Each installation and putting into operation adds very high cost. The investment for the installation of conventional in-plant The example of modern IT networks shows that sig- conveyor technology is very high. Especially for smaller nificant cost savings can be realized with systems that are companies, it severely limits their ability to automate modular and self-controlled: A large number of indepen- materials flow processes. That is why the in-plant trans- dent nodes create a network that is capable of moving large portation of unit loads in industry still is carried out by amounts of data without the necessity of an expensive, discontinuous conveyors like fork lifts or manually oper- central computer. Individual computers independently find ated lift trucks. new connections after being linked. In very short time, they create their own map of the real topology in form of a routing table. When a message is received, the destination S. Mayer (&) is identified and forwarded to the next node on the route. Institute of Conveyor Technology and Logistics (IFL), University of Karlsruhe (TH), Karlsruhe, Germany Mechanisms are applied here that ensure that collisions and e-mail: mayer.stephan@gmx.de time losses are avoided. The following discussion shows how the idea of a K. Furmans decentralized control concept in IT networks can be Head of the Institute of Conveyor Technology and Logistics transferred to the design of innovative materials flow (IFL), University of Karlsruhe (TH), Karlsruhe, Germany 123 148 Logist. Res. (2010) 2:147–158 controls, even though there are substantial differences 3.1 Decentral control logic in four steps between realms of data flows and of the flows of physical objects. Initially, when the system is first constructed, the modules do not yet know their position in the system or their neighbors. Therefore, as the first step, each module must 2 Basic requirements for the modules and the overall gather information about the topology of the conveyor system. This information is saved in routing tables, which system are updated on a regular basis, in order to react to changes in the system. Such changes could be the failure of another For the development of a completely decentralized control system, several requirements must be met. At the core is module or the expansion of the system by adding more the design of a control algorithm that is implemented in modules. each module. The representation in Fig. 1 depicts the The arrival of a CU at a port of the module is recognized modules as square shapes (righthand side). An illustrative by sensors. Immediately, the module starts to move the CU arrangement of modules is shown on the lefthand side of toward the reading area of the identification system in the Fig. 1. center of the module in order to read the CU ID and Destination ID. On positive identification, the routing is Each module is able to receive conveyor units (CU) arriving at any of its edges and move the CU on to the edge started. Should this process take longer, the CU is stopped in the middle of the module. of any adjoining module via a driver system. The principal characteristics of the system, hence, are During the routing process, the best available path for summarized as follows: the move of the CU to its destination is calculated. This is the biggest challenge for the programming of the module as – The system consists of many modules, which due to not only the shortest route has to be identified but also other their arrangement form the system layout CUs that are already in the system have to be considered. – Each module has its own unique address (see MAC The shortest route, for example, could already be trans- address in IT) by which they can be distinguished porting a CU in the opposite direction. In such a case, the – The modules have defined interfaces (ports) through CU either has to wait or a new alternate, possibly longer which they are connected to their neighbors for route has to be calculated. The decision has a big impact on communication and also for the physical handover of the potential throughput of the system and strongly CUs depends on the layout. – Every module is equipped with the same control After successful routing, the CU is handed over to the algorithm next module on the path. The next module, however, must – A module cannot act as input and output at the same be ready to accept the CU. Furthermore, the transmitting time module needs to be ready again after the transmission to – Within the module boundaries, only one CU can be accept another CU. Prior to the transport, it must be processed at any one time checked if the forwarding of the CU could cause a dead- – Input and output modules are connected to the system lock. This is especially necessary in systems with a high only via one neighboring module filling rate or circular paths. 3.2 Decentralized generation of topological 3 The basic control concept information The control logic of the modules follows a process of four The generation of topological information comprises the steps (see Fig. 2). gathering of information about the physical location of the modules in relation to other modules in the form of a graph. This information is necessary for the routing of the CUs and is captured in routing tables that include the shortest possible path for each transportation direction. The process to gather that information follows the rules of Distance Vector Routing as used with IT networks [5, 10]. Link State Routing would also be an alterative for the gathering of routing information (OSPF) [1, 7] but needs more computing time, and the broadcasting of information in decentralized systems with huge amounts of agents could Fig. 1 Graphical illustration of the modular materials flow system 123 Logist. Res. (2010) 2:147–158 149 Fig. 2 Process overview of the control logic of a module be difficult. As the process of the creation of routing tables are traveling on opposite routes. CUs crossing the conveyor is equal to the processes in IT networks, no more expla- section or travel in the same direction are not affected. nation is given in this paper. When a CU is entered into the system, the input module sends out a reservation token in the direction with the lowest 3.3 Identification of the CU costs selected from the routing table. This reservation token contains the module ID of the output module (Destination In a decentralized system, every module can recognize a ID), the CU ID, and the module ID of the input module. newly arriving CU and forward it in the direction of the When a neighbor module receives this reservation token, it destination module, without endangering the system sta- checks whether the Destination ID corresponds with its own bility. It can be assumed that a CU always enters a module module ID. If this is not the case, the request is saved in a through one of its ports and that no other CU is located reservation table and the reservation token is forwarded in within these module boundaries at the same time. In this the shortest direction toward the output module. This port is paper, it is assumed that the module has sensors at each of then blocked for incoming reservation tokens so that no its ports that report the arrival of a CU. As soon as this reservations can be made in the opposite direction. The message has been received, the module is switched on to reservation token runs along this route through the conveyor forward the CU in the direction of the decision point. At system until it arrives at the output module. On arrival, the the same time, the identification system is activated, which module compares, like all other modules before, the Des- reads the CU ID and Destination ID as soon as the CU tination ID of the reservation token with its own module ID. enters into the reading area. The module records this first Because the two IDs correspond with each other, the contact and blocks itself for the clearance for other CUs. module swaps the module ID of the input module with the This assures that two CUs never arrive at the same module Destination ID of the reservation token, attaches clearance simultaneously. information, and sends it back to the input module. The route is only blocked for requests in the opposing direction; 3.4 Routing and route reservation CUs running in the same direction can still be reserved and forwarded (see Fig. 3). Being a fully decentralized system, no higher-level infra- Furthermore, similar to the topology generation, the structure is available that supplies the modules with reservation token also contains the module IDs of the information about the location of CUs in the system. To modules already passed in order to prevent the reservation avoid collisions, it has to be ensured that two CUs on token from running in circles. When the reservation token opposing routes will not meet at any time. Therefore, it is has arrived back at the input module, the route has been necessary to reserve a section prior to sending the CU so fully reserved and the CU can be sent. Prior to the physical that during this time no CU is traveling in the opposite transport, two further characteristics have to be checked to direction. Although physical collisions are no longer pos- prevent a collision: sible, deadlock situations can still occur at nodes at which First, the next module in line has to be asked whether it two opposing CUs cannot pass each other and therefore is available to receive and forward a CU, and secondly, it block the node. The danger of a deadlock can be minimized has to be ensured that the forwarding of a CU does not lead in the developed routing algorithm by reserving the entire to a deadlock of the whole system. These two character- conveyor route from the input module to the output mod- istics will be discussed in the following sections. ule, before sending the CU. However, the reservation only In the case that another CU enters the system whose affects the blocking of conveyor section of those CUs that route partially runs in opposite direction (see CU no. 9, 123 150 Logist. Res. (2010) 2:147–158 Fig. 3 Sending of tokens for CU reservation Fig. 4 Route blockage in case of danger of collision Fig. 4), a reservation token will be sent from the input waiting for the clearance of the blocked conveyor section. module as before. This possible solution is very complex from a decentralized The reservation token initially runs smoothly through point of view because the current position of the opposing module 4 because the blocked port does not correspond CU would need to be calculated in addition to the section with the entry port of the reservation token. However, this reservation. The reservation request will not run in circles is the case in module 3. Because the blocked port is being on the alternative route because the module ID of all passed addressed, module 3 deletes the reservation token and modules is attached to the reservation token. If a module sends back a message that this route is barred (x-token). receives a reservation token twice, the route will also be When module 4 receives the x-token, it searches for blocked and an x-token will be sent back. This prevents alternative routes in its routing table. If it cannot find an reservation tokens or CUs from running in circles. Figure 6 alternative route, module 4 also deletes the reservation and shows such a scenario. sends the x-token to the previous module. If the x-token At module 13, the conveyor section is blocked for the arrives back at the input module, it waits a short while (e.g., CU (no. 2) by the opposed CU (no. 1). Module 5, how- 2 s) and tries again. Furthermore, module 4 remembers the ever, determines alternative routes and sends the token request from the input module and sends a clearance token toward module 4. This module determines the shortest once the first CU has exited module 4. alternative route via port A, which causes the reservation If on the way back from a failed reservation a new token to run in a circle and to arrive back at module 5. alternative route is found in the routing table (see Fig. 5), a This alternative route is blocked as well. The reservation new reservation token is sent on the alternative route prior token is sent back to module 4 and finally arrives at the to further sending back the x-token. output module via a third alternative route (port B and module 3). Consequently, CU no. 2 will travel via module If the reservation token eventually arrives at the output module, the CU is sent on this alternative route instead. 5, 4, 3, and so on. However, it is not checked how much longer the alternative By using the above-described reservation, direct colli- route is in comparison with the initial route or if it is worth sions of CUs can be avoided. Unfortunately, only to 123 Logist. Res. (2010) 2:147–158 151 Fig. 5 Search for an alternative route deadlock. This depends on the system’s workload and how many alternative routes exist. Prior to sending a CU to the neighbor module, several situations have to be checked in order to maintain the efficiency and functionality of the system. Despite having reserved the route, blockages and deadlocks may occur due to the interaction of several CUs in the system. To avoid such situations, two requests are made prior to sending the CU: – Is the neighbor module ready to take a CU? – Is there a risk of a deadlock situation? While this section discusses the first request, the fol- lowing two chapters will discuss the other request. Fig. 6 Avoidance of a circle on alternative routes 3.5.1 Clearance for the transport of CUs reserve a route before sending out a CU does not prevent Prior to forwarding a CU to a neighbor module, it needs to against deadlocks, which will be shown in the next section. be checked if this module is ready to take the CU. This is However, the reservation of the path is essential to ensure a confirmed with a clearance token that is sent back to the smooth material flow in a decentralized system where the individual modules do not know the whole system state. requesting module if the requested module is ready. The CU will only be forwarded if the clearance token is 3.5 Transportation of conveyor units received. If not, the module will wait a predefined period of time and try again. An occupied module saves the Shortly after the input module has reserved the route for a received request and sends clearance to adjacent request- ing modules directly after having forwarded its own CU. CU, the transport along the route begins. During the res- These direct clearance approvals interrupt the waiting time ervation process, all modules along the route have saved until the next request. By alternating the sequence of the CU ID together with the entry and exit ports. Hence, no cleared ports, it can be guaranteed that all neighbor further routing processes have to be run. The modules forward the CU to the saved port after identification. This modules are equitably cleared to forward their CUs to the now available module. At this stage, a prioritization of process saves time and unnecessary data transfer. In case of a technical failure of a module, all reservations are deleted CUs could be possible if the clearance token contains an appropriate message and if the prioritized CU receives the and renewed, so that the CU can use an alternative route as early as possible. However, a failure can bear the risk that clearance message from the next available module before any other CU. no alternative routes are available, which can result in a 123 152 Logist. Res. (2010) 2:147–158 Thus, to avoid deadlocks, the focus is to ensure that the fourth condition (circular waiting) will never occur. Although it is easy to avoid circular waiting among the modules waiting for their neighbor, a good deadlock avoidance algorithm should allow the maximum use of resources to optimize the throughput of the material flow system. For example, the easiest way to prevent the circular Fig. 7 Example of a deadlock of two processes waiting condition is to allow only one CU in the system at a time. Such a trivial policy is, however, overly conser- 4 Deadlock avoidance vative. The algorithm presented in this dissertation will allow a maximum possible load of CUs within the system Tanenbaum [11] describes the existence of a deadlock in without risking a deadlock. information technology as follows: 4.1 Analysis of critical module states ‘‘A set of processes is deadlocked when every process in the set is waiting for a resource that must be Figure 8 shows the different states of a module from the released by another process in the set’’ appearance of a new CU up to the transfer to the next A deadlocked system must have at least two processes. module on a predetermined (reserved) route to the Figure 7 shows such an example. Process 1 occupies the destination. It shows that the following four critical states can occur: screen while it is waiting for the printer. At the same time, process 2 occupies the printer while it is waiting for the 1. CU cannot be identified screen. 2. No route to the destination is available in routing table A more common example is found in road traffic when 3. Never receives a successful reservation four cars arrive at an intersection at the same time with no 4. Never receives a clearance token rule for the right of way. In the case of ‘‘right before left’’, all cars are waiting for the right car to go first and nobody The first two states can occur due to a technical failure, will move [9]. misuse, or insufficient mechanical design of the modules. The phenomenon of deadlock has been studied exten- They are not described further in this paper as they are not connected to any deadlock situation. sively in the context of computer operating systems [4, 8]. It is well known that the following four conditions are The third state can easily occur during a high utilization of the CS, if a conveyor section is the only connection necessary for a deadlock to occur among concurrent pro- cesses [2, 3]: between several sources and outputs and is to be used in both directions (see Fig. 9). To ensure a maximum 1. Mutual exclusion: processes require the exclusive use acceptable waiting time for the CU, the layout must be of resources changed or additional prioritization algorithms must be 2. Hold while waiting: processes hold onto resources implemented (subject of ongoing investigations at the IFL). while waiting for additional required resources to As the blockages dissolve autonomously by reducing the become available utilization, the fourth condition of ‘‘circular waiting’’ is not 3. No pre-emption: processes holding resources deter- fulfilled and a deadlock is not identified. mine when they are released The last critical state turns into a deadlock if the wait for 4. Circular waiting: closed chain of processes in which clearance from the next module turns into a circular each process is waiting for a resource held by the next waiting, because both modules are part of a circular chain process in the chain in which all modules are occupied with a CU and unable to To avoid deadlocks, it is sufficient to assure that at least give clearance. To avoid such a situation, the following one of these four necessary conditions is not fulfilled. For model is created, which is supported by axioms: the modules of the decentralized material flow system (MFS) considered in this paper, the first three conditions 4.2 Basic model for the avoidance of a deadlock are always present: resources (modules) can handle only The distributed system consists of a finite set of modules. one CU at a time, modules hold onto CUs while waiting for the next module specified in the transportation route, and a A module (M) is in one of the three general states: active, module occupied with one CU cannot be pre-empted by requested, or blocked, and has a finite number of four ports another module. (P) that are able to receive CUs and requests (rq). 123 Logist. Res. (2010) 2:147–158 153 Fig. 8 State diagram of a module which carries a CU With the description of several module process axioms, the basic logic for M is described to ensure a deadlock-free material flow system: 4.2.2 Initial module process axioms A1 When M wants to move CU to M , it sends rq to M i i j i j A2 If M is blocked, it ignores the request Fig. 9 Example for condition three, module 8 gets no valid A3 If M is not blocked, it sends a so-called deadlock reservation due to a high utilization of the CS token(dl )toM , which is the next module on i,j k the predetermined route of CU and remembers the port number (P ) of the incoming request rq i i 4.2.1 Description of module states (Fig. 10) S1 M is active, if it carries no CU and was not requested The behavior of a network of modules in terms of the three (rq) to receive one yet different states is described as follows: S2 M is requested, if it has received a rq but has not sent 4.2.3 Module process axioms out clearance (cl) for the handover yet S3 M is blocked, if it has sent out clearance cl to receive A4 If M receives dl and is active, it sends dl back to a CU or if it already carries a CU as shown in the state k i,j i,j diagram 8 M including a ‘‘Deadlock-Clearance’’ (dlcl ) j i,j 123 154 Logist. Res. (2010) 2:147–158 case if the requesting module M is part of the circle itself ([A5]). Although a clearance cl from M to M will block j i M ([S3]), the process will re-activate module M , which is j i part of the circle, after a certain time ([A9]) and the last condition (circular waiting) is not fulfilled. A simulation of the system performance (Fig. 12)ina circle (like Fig. 13a) shows the impact of a deadlock request. The throughput per minute was evaluated with a gradual increase in the input. It shows clearly that without a deadlock request, a deadlock situation occurs once a cer- Fig. 10 Deadlock avoidance process tain injection rate is reached and the material flow ceases. With a deadlock request, however, the throughput decrea- ses when a certain injection rate is reached, but a blockage A5 If M receives dl and is blocked or requested, it k i,j will never occur. sends dl to the next module M on the i,j k?1 Examining different topologies further in regard to determined route of its own CU deadlocks, three different topology types unfold which are A6 If M receives dl from a port other than P , j i,j i differentiated as follows: deadlock danger is recognized and no clearance is sent to M – Most common are module layouts with individual circles that are completely independent from each other A7 If M receives dl from port P , it sends out j i,j i clearance to M and becomes blocked (Fig. 13a) – Secondly, circles can be connected through several A8 If M receives dlcl , it sends out clearance to M j i,j i modules (Fig. 13b) A9 If M receives cl , it moves CU to M and returns to i i i j – Finally, there are layouts in which several circles join an active state after a certain time (after CU has in one module. In this case, the module is the only entirely left M ) connection between the circles (Fig. 13c) A10 If M (Destination Module) receives dl , it sends output i,j out dlcl to M i,j j From these three main types, all deadlock-endangered layouts can be designed and described. These axioms are sufficient to explain the whole process for deadlock avoidance. 4.4 Analysis of different layout types 4.3 Proof of correctness 4.4.1 Independent circle If a system consists of a finite set of modules, of which some are arranged in a circle, there is danger of a deadlock. For the independent circle, deadlocks can be avoided by applying the above-discussed axioms. Thereby it does not As long as there is at least one module in an active state, the last condition (circular waiting) is not fulfilled (see matter how many modules M are in the circle or how high the throughput is. [A4] and [A8]), and movement is possible (Fig. 11). A module can only turn into a blocked state if another Deadlocks can be avoided even if several CUs want to snap up the last remaining free spaces within a circle. In module in the circle is active ([A4] and [A8]) or if it this case, the modules of the circle switch to the status receives its transmitted deadlock token dl from the same i,j requested immediately after the request (rq) has been port from which rq was received ([A7]). This is only the Fig. 11 Identification of circle member by comparison of receiving ports 123 Logist. Res. (2010) 2:147–158 155 Fig. 12 CS throughput; left without deadlock check, right with deadlock check Fig. 13 Circle topologies: a independent circle; b circles overlap in several modules; c circles overlap in one module received ([S2]) and the deadlock tokens are forwarded clearance and the CU of the other circle would be allowed within the circle ([A5]). to move. If two CUs put in their requests to enter the circle at the Hence, when both modules with CU 3 and CU 6 send same time, neither of the two receive the clearance; the request token rq to module 4, for each CU a deadlock therefore, the system would remain fully functional even token will be released. The process of a deadlock request with only two non-blocked modules. depends on the next module on the route of CU 10, because deadlock tokens are always forwarded in the same direc- 4.4.2 Circles that overlap over several modules tion as its own CU ([A5]). This CU also decides which circle is going to be closed, because both circles cannot be In this case, the deadlock problem is resolved with the closed at the same time. As the module carrying CU 10 same algorithm as in the independent circle. The trans- forwards the deadlock token to the upper circle, CU 3 gets mission of the deadlock token prevents a closed circle of clearance, whereas CU 6 has to wait (see Fig. 14b). CUs from developing, which blocks itself. Although the lower circle is working to full capacity, If two circles overlap over several modules (see CU 10 will leave the circle upwards as soon as the empty Fig. 13b), this section is being used in the same direction in gap of module 2 has arrived at CU 10 after CU 9. Although both circles. Because in a closed circle, it can never happen this process has finished that all places are taken at the same time due to the when CU 3 has been transported to its right, the same deadlock request, and a minimum of one place is always process begins all over again with CU 2 and CU 6 free. A worst-case scenario would be if this free place were (see Fig. 14 c). This time it depends on the ongoing route in the first module connecting the two circles, because of CU 3. when a CU makes its next move, one of the two circles would be closed (see Fig. 14a). However, a deadlock sit- 4.4.3 Circles that overlap in one module uation only occurs if the last joint module (modules with CU 10) of the circles carries a CU that is going to be The avoidance of a deadlock as described in the general transported in the same circle. This is prevented by the definition is also assured in this scenario. If one or both of deadlock request, because then the CU would not receive the circles are almost fully blocked with CUs, the above- 123 156 Logist. Res. (2010) 2:147–158 Fig. 14 Process of deadlock prevention in overlapping circles mentioned algorithm will not allow the last module to resource of the other process by handing over a CU. At receive another CU. Consequently, the last condition the same time, each sub-system is not able to take another ‘‘circular waiting’’ will never be fulfilled. CU as only one free space in the circle is left. This can Unfortunately, in high utilization, the described dead- only occur when the sub-systems are connected over one lock algorithm could lead to a new type of system halt, single module because if the sub-systems are connected which will be called cross deadlock. over several modules, the last connecting module cannot A cross deadlock can occur when all modules in the two act for both sub-systems as it carries a CU that is dedi- circles are completely blocked except the module were the cated to one of the two sub-systems. This means, that at two circles overlap (see Fig. 15). least one of the two sub-systems is not waiting for the In this case, if in each circle the CU (5 and 8) in front of other, as described in Fig. 13b, ‘‘circles overlap in several the overlapping module (9) is on the way to enter the modules’’. opposite circle, the system breaks down. This is because However, if only one module connects two sub-systems when the overlapping module (9) sends out a deadlock and each sub-system is waiting for the other, a cross token around the opposite circle, for both CUs, it will deadlock has occured, which can be avoided as follows: recognize the danger of a deadlock. Consequently, both For modules, which have a maximum of four neighbors, requests will be ignored and the conveyor system will the condition that two CUs are waiting to enter an opposite, come to a halt. almost-blocked circle can occur in two different ways, which are shown in Fig. 16. 4.5 Cross deadlocks prevention Modules can prevent against cross deadlocks during the process of route reservation before CUs are injected into To find a prevention against cross deadlocks, the condi- the system at the input module. When the reservation token tion of ‘‘circular waiting’’ must be prevented not only is sent out from the input module to the output, each within single modules but also within the next level of module on the route that fulfills the necessary conditions to aggregation which are interacting sub-systems as, for cause a cross deadlock (being the only connecting module example, two circular layouts connected over one module. of two circular sub-systems) must check if the requested In the example of Fig. 13c, each circle can be seen as reservation is secure. If not, the reservation is rejected with such a sub-system that interacts with the other over the an x-token (see chapter 4.2.3) and handled as if it were a connecting module (module 7). Referring to the original blocked route. example for deadlocks in case of a deadlock, each sub- Necessary module condition to be able to cause a cross system can be seen as a process that needs to use a deadlock: Fig. 15 Cross deadlock, if two circles overlap in one module 123 Logist. Res. (2010) 2:147–158 157 Fig. 16 System states for cross deadlock; left 180 request, right 90 – Each port of the module is connected to another module (4 neighbors) Fig. 17 Self-diagnostics to prevent a deadlock with topology check – Both pairs of ports of the module form (together with other modules) a circle previously mentioned conditions (both pairs of ports of the module form a circle). 4.5.1 Cross deadlock check for a 180 request To check this, all modules occasionally carry out a self- diagnostic. This is done by a ‘‘diagnostic token’’ that is sent If the outgoing port of a requested route is on the opposite to one of the four connected ports. When such a diagnostic token is received, the module checks its routing table for an side of the port from which the request was received, it is called a 180 request. alternative route to the transmitting module. In this case, the message will be forwarded in this direction. If it is a If such a request is received, the module checks whether it has already reserved another CU perpendicular to it. If circle situation, the message will come back to the sending this is the case, the request is rejected and an x-token is sent module. If it receives back the diagnostics token, it sends out another diagnostics token to one of the remaining to the requesting module (see Fig. 16, left). neighbors. The module repeats this process with all four ports. If it received back the diagnostic token each time 4.5.2 Cross deadlock check for a 90 request from a different port, it recognizes that it has been posi- tioned as the only link between two circles and carries out If the outgoing port of a requested route is on the left or right side of the port from which the request was received, the cross deadlock check every time it receives a request (Fig. 17). it is called a 90 request. In this case, the module checks whether there is already another reservation that came from the opposite port and which follows a route to the opposite output port of the 5 Summary current reservation. Again, if this is the case, the request is Decentralized controls for continuous conveyor systems rejected and an x-token is sent to the requesting module (see Fig. 16, right). have the potential to significantly improve the performance over conventional, centralized controlled systems. On the 4.5.3 Self-detection for cross deadlock danger way to develop a satisfactory control logic to prevent against deadlocks within such systems is essential. The Although the above-described process prevents cross paper presented here shows a way how to prevent dead- locks in a completely decentralized system for modular deadlocks, there is a disadvantage that should be men- tioned. If a conveyor system is running with high utiliza- continuous conveyors. At the Institute of Conveying Technology and Logistics, University of Karlsruhe based tion, there is a high probability that a once-rejected request on the presented logic, a conveyor system with 9 identical will be rejected for a long time, because the relevant module has a long list of blocking reservations, which modules was built, including all necessary technical fea- tures to prove the possibility to transport several conveyor continue to exist because of CUs being continuously injected into the system. It might happen that the request- units completely decentralized controlled. The modules contain an RFID-reader, sensors, drives, and a controller ing module will never succeed, as in the case of the third state in the state diagram (see Fig. 8). To minimize the that contained the algorithm. If we consider a decentralized controlled material flow waiting time, only modules that are really in danger of a cross deadlock should reject unsecure requests. This is only system to replace existing systems as, for example, bag- gage transportation in airports or distribution centers, a the case for modules that mainly fulfill the second of the 123 158 Logist. Res. (2010) 2:147–158 4. Deitel HM (1983) An introduction to operating systems. Addi- major focus is on service level, meaning a defined maxi- sion-Wesley, Reading, Mass mum time for all conveyor units to run through the system. 5. Hedrick C (1988) Routing information protocol. The Internet This can still be a disadvantage in decentralized systems, as Society, New Jersey, USA the modules have no overall view and are not able to ensure 6. Mayer SH (2009) Development of a completely decentralized control system for modular continuous conveyors. Dissertation, a maximum given throughput. Here, further developments Universita ¨tsverlag Karlsruhe have to be made. 7. Moy J (1998) Open shortest path first protocol. The Internet Society, New Jersey, USA 8. Panson PA (1985) Operating systems: structures and mecha- nisms. Academic, New York 9. Peterson JL, Silberschatz A (1983) Operating system concepts. References Addison-Wesley Pub. Co, London 10. Rekhter Y, Li T, Hares S (2006) A broader gateway protocol 4. 1. Aurand D (2000) Netzwerkprotokolle in Cisco Netzwerken. The Internet Society, New Jersey, USA Addison Wesley Verlag, Verlag 11. Tanenbaum AS (2002) Moderne Betriebssysteme. Pearson Stu- 2. Coffman EG, Denning PJ (1973) Operating systems theory. dium, Munich Prentice-Hall, London 3. Coffman EG, Elphick M, Shoshani A (1971) System deadlocks. Comput Surv 3(2)
Logistics Research – Springer Journals
Published: Oct 22, 2010
You can share this free article with as many people as you like with the url below! We hope you enjoy this feature!
Read and print from thousands of top scholarly journals.
Already have an account? Log in
Bookmark this article. You can see your Bookmarks on your DeepDyve Library.
To save an article, log in first, or sign up for a DeepDyve account if you don’t already have one.
Copy and paste the desired citation format or use the link below to download a file formatted for EndNote
Access the full text.
Sign up today, get DeepDyve free for 14 days.
All DeepDyve websites use cookies to improve your online experience. They were placed on your computer when you launched this website. You can change your cookie settings through your browser.