deadlock prediction and avoidance in an agv system - CiteSeerX

DEADLOCK PREDICTION AND AVOIDANCE IN AN AGV SYSTEM By

Krishna Moorthy Rajeeva Lochana Moorthy

Wee Hock Guan

B.E. Mechanical Engineering Sri Ramakrishna Engineering College, 1999.

B.Eng. Electrical Engineering National University of Singapore, 1999

SUBMITTED TO THE SMA OFFICE IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN HIGH PERFORMANCE COMPUTATION FOR ENGINEERED SYSTEMS AT THE SINGAPORE-MIT ALLIANCE JUNE 2000

Signature of Authors: Krishna Moorthy Rajeeva Lochana Moorthy __________________________________________

Wee Hock Guan ________________________________________________________________ High Performance Computation for Engineered Systems June 30, 2000

Certified by: ___________________________________________________________________ Asst. Prof. Teo Chung Piaw SMA HPCES Fellow Project Supervisor Accepted by: ___________________________________________________________________ Assoc. Prof. Khoo Boo Cheong Programme Co-Chair HPCES Programme Accepted by: ___________________________________________________________________ Prof. Anthony Patera Programme Co-Chair HPCES Programme

DEADLOCK PREDICTION AND AVOIDANCE IN AN AGV SYSTEM By

Krishna Moorthy Rajeeva Lochana Moorthy

Wee Hock Guan

B.E. Mechanical Engineering Sri Ramakrishna Engineering College, 1999.

B.Eng. Electrical Engineering National University of Singapore, 1999

SUBMITTED TO THE SMA OFFICE IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE IN HIGH PERFORMANCE COMPUTATION FOR ENGINEERED SYSTEMS AT THE SINGAPORE-MIT ALLIANCE JUNE 2000

ABSTRACT Automated Guided Vehicle Systems (AGVS) form a very important part of automated material handling and its performance affects the efficiency of the entire system. Deadlock formation is a serious problem as it stalls the AGVS. The objective of this project is to develop an efficient deadlock prediction and avoidance algorithm.

Deadlock in a broad sense is a situation in which at least a part of the system stalls. There are a lot of situations in which the system may stall and most of these situations can be avoided by designing a good control and navigation system. The project concentrates on developing an algorithm to predict the occurrence of cyclic deadlock and the other kinds of deadlocks are avoided by using control logic.

A variety of deadlock-detecting algorithms are available but, the AGVS under study is huge and complex and none of the existing methods can be used. This is because, it is the first time that such a complex port AGVS layout has been taken for study and all the existing methods are for simpler and smaller layouts. A semi-dynamic routing system is

proposed which employs a prediction phase and an avoidance phase. The routes for the vehicles are obtained by using a shortest path algorithm, which takes congestion effects into consideration. Leighton, Maggs and Richa [11] have earlier shown that there exists a routing schedule in O(c+d) if the congestion effects are taken into account. A computationally efficient method for updating the network with the congestion effects is also suggested.

The proposed solution is implemented in a simulation software, AutoMod, and the performance of the technique is analyzed. A detailed description of the algorithm and specific details of implementation in AutoMod and C are provided.

The algorithm is implemented first on a small-scale model and then on the actual model. In the actual model, realistic loads are simulated so that the algorithm can be evaluated with as much real data as possible. Simulation shows that all the potential deadlock situations are detected and avoided. Also, the proposed strategy is computationally efficient and is able to provide the movement decision to the vehicles within the 1.5-sec sampling time.

The simulations show that the deadlocks formation is inherent in the layout and they cannot be avoided by simply reducing the number of vehicles in the system. This suggests that the prediction-avoidance strategy has to be a vital ingredient of the AGVS routing system.

ACKNOWLEDGEMENTS We thank our advisor Dr. Teo Chung Piaw whose expert advice has helped us a lot in completing the project successfully. His guidance and comments has aided us in looking into the finer aspects of the simulation and in obtaining meaningful results.

We thank Dr. Jonathan Ng, Manager, Operations Planning Department, PSA Corp., for providing us the opportunity to work on this problem. We are grateful to PSA Corp for providing the resources to do the simulation work.

Our special thanks to Mr. Yow Liang Keon, Senior Operations Research Officer, PSA Corp., for helping us a lot in understanding AutoMod and providing us implementation specific details. His experience with AutoMod has helped us in reducing the debugging time to a great extent.

We also wish to thank SMA for supporting us in doing this project.

Last but not the least we thank all the SMA faculty and students with whom we have had many a discussions.

Authors 30 June 2000

Deadlock prediction and avoidance in an AGV System

TABLE 1

OF

CONTENTS

INTRODUCTION .....................................................................................................9 1.1

AUTOMATED GUIDED VEHICLES ..........................................................................9

1.2

PSA PORT AUTOMATION PROJECT (PPAP)........................................................10

1.2.1

Description of Layout ................................................................................12

1.3

UNIQUENESS OF PPAP .......................................................................................13

1.4

PROBLEM STATEMENT ........................................................................................14

1.5

PROJECT CONTRIBUTION .....................................................................................15

1.6

OUTLINE OF THE THESIS .....................................................................................15

2

LITERATURE REVIEW .......................................................................................17

3

DEADLOCK PREDICTION ALGORITHM.......................................................20

4

3.1

THE CONDITIONS LEADING TO A DEADLOCK .......................................................20

3.2

TYPES OF DEADLOCKS IN THE AGVS .................................................................21

3.2.1

Cross lane deadlock ..................................................................................22

3.2.2

Shop deadlock............................................................................................22

3.2.3

Cyclic Deadlock.........................................................................................24

3.2.3.1

Methods in predicting or detecting cyclic deadlock..............................24

3.2.3.2

Deadlock prediction algorithm ..............................................................25

DEADLOCK AVOIDANCE ..................................................................................29 4.1

5

DYNAMIC ROUTING STRATEGY ..........................................................................30

4.1.1

Calculation of Shortest path ......................................................................31

4.1.2

Storage of Routes.......................................................................................32

4.1.3

Updating the Arc Weights .........................................................................33

4.1.4

Improvements in Computation speed ........................................................38

IMPLEMENTATION .............................................................................................40 5.1

AUTOMOD SIMULATION SOFTWARE ...................................................................40

5.1.1

Items required building a model in AutoMod............................................40

5.1.2

Vehicle procedures and functions .............................................................42

5.1.3

Specification of the workload in PSA ........................................................43


5.1.4

Implementation of the one-zone step deadlock prediction and avoidance

algorithm in AutoMod ...............................................................................................44 5.1.5 5.1.5.1

Idling vehicles at destination control points..........................................47

5.1.5.2

Multi-cycle deadlock .............................................................................49

5.1.5.3

Deadlock detection and resolution ........................................................51

5.2

6

Difficulties faced during the implementation in AutoMod ........................47

C - CODES AND INTERFACING .............................................................................53

5.2.1

Data structure............................................................................................53

5.2.2

Implementation of Dijkstra’s algorithm ....................................................54

RESULTS AND DISCUSSION..............................................................................55 6.1

EFFECTIVENESS OF THE ALGORITHM ON THE SMALL-SCALE MODEL ...................55

6.2

EFFECTIVENESS OF THE ALGORITHM ON THE ACTUAL MODEL.............................55

7

REFERENCES ........................................................................................................59

8

APPENDIX A...........................................................................................................61 8.1

HOW VEHICLES USE LIST TO MOVE AND PICK UP LOADS ......................................61

8.2

HOW VEHICLES BEHAVE AS SCHEDULERS USING VEHICLE PROCEDURES .............62

8.3

HOW VEHICLES BEHAVE AS MOVERS USING VEHICLE PROCEDURES AND

FUNCTIONS. ....................................................................................................................63

9

APPENDIX B...........................................................................................................64 9.1

VEHICLE PROCEDURES ........................................................................................64

9.1.1

Move to deliver procedure.........................................................................64

9.1.2

Move to retrieve procedure .......................................................................64

9.1.3

Leaving station procedure .........................................................................64

9.2

10

VEHICLE FUNCTIONS ..........................................................................................65

9.2.1

Vehicle initialization function....................................................................65

9.2.2

Decelerate ok function...............................................................................65

9.2.3

Location selection function........................................................................66

9.2.4

Park ok function ........................................................................................66

9.2.5

Passing station function ............................................................................67

APPENDIX C...........................................................................................................68


LIST

OF

FIGURES

Figure 1.1.1: Illustration of zone controlled AGVS ..........................................................10 Figure 1.1.2: Simple solution to reduce waiting time........................................................10 Figure 1.2.1: Increase in volume of transaction in ports operated by PSA.......................11 Figure 1.2.2: Bridge Cranes in operation ..........................................................................11 Figure 1.2.3: Part of the PSA’s AGVS layout showing one berth. ...................................12 Figure 1.2.1.1 Storage yard. .............................................................................................13 Figure 1.2.1.2 Traveling and working lanes......................................................................13 Figure 1.3.1: Physical constraints in AGVS leading to deadlock. ....................................14 Figure 3.0.1: A cyclic deadlock form by the vehicles.......................................................20 Figure 3.2.1.1: Illustration of a deadlock when two vehicles are crossing into each other’s lanes ...........................................................................................................................22 Figure 3.2.2.1: A Shop deadlock .......................................................................................23 Figure 3.2.2.2: Avoiding the Shop deadlock. ....................................................................23 Figure 3.2.3.2.1: Flowchart of the algorithm used to predict the deadlock (one zone step). ...................................................................................................................................26 Figure 3.2.3.2.2: Illustration of one zone step deadlock prediction. .................................26 Figure 4.1.1: Figure representing an example for a vehicle to be delayed in its travel.....31 Figure 4.1.2.1: AGV predicts a deadlock and changes its route .......................................33 Figure 4.1.3.1 Illustration for updating Arc Weights ........................................................35 Figure 4.1.3.2: Formula for updating arc weights.............................................................36 Figure 4.1.3.3: Arc weight updating with varying weights...............................................37 Figure 5.1.1.1: An example of AGV path layout. The crosses shown here are the control points by which the vehicle will stop at if necessary. ...............................................41 Figure 5.1.2.1: An illustration of an impending one-zone step deadlock situation. The small cubes represent the AGV while the bigger one represents that the AGV is carrying a load. ..........................................................................................................46 Figure 5.1.5.2.1: An illustration of the multi-cycle deadlock situation.............................49 Figure 5.1.5.2.2: Resolution of Multi-Cycle Deadlock .....................................................50 Figure 5.1.5.3.1: An illustration of the problem encountered. ..........................................52 Figure 5.2.1.1 Data structure used to represent the Network ............................................53


Figure 5.2.1.2: Data file format. ........................................................................................53 Figure 5.2.1.3: Structure of the Queue Item ......................................................................54 Figure 6.2.1: Layout of the Actual model .........................................................................55 Figure 6.2.2: Cyclic deadlock in the Actual model ...........................................................56 Figure 6.2.3: Impending deadlock detected by the Algorithm ..........................................56 Figure 6.2.4: Deadlocks predicted in a 7-day period.........................................................57 Figure 10.0.1: Flowchart for the proposed two-zone step deadlock prediction algorithm. See below for the definition of the numbers..............................................................68

LIST

OF

TABLES

Table 4.1.3.1 Original Adjacency Matrix..........................................................................35 Table 4.1.3.2 Adjacency Matrix after rerouting one vehicle.............................................36 Table 4.1.3.3: Comparison of the different Arc weight updating strategies. ....................38 Table 4.1.4.1: Comparison of computation times for two different implementations of Dijkstra’s algorithm...................................................................................................39 Table 6.2.1: Deadlock formation with regard to the number of vehicles..........................57


Chapter 1

9

Introduction

1 INTRODUCTION Material handling in manufacturing firms has always been an important process and the advent of automation has increased the demand for efficient material handling systems. By far, automated material handling has been one of the most important features in a Flexible Manufacturing System (FMS).

Material handling includes a variety of operations including material storage, retrieval, transportation of the products between machines etc. Each operation requires different hardware resources like the fork lifts, robots and the Automated Guided Vehicles (AGV). Automated Guided Vehicle System (AGVS) has been one of the most important components of an Automated material handling system because it is the responsibility of the AGVS to efficiently transport goods from one part of the factory to the other. Any delay in the part of the AGVS affects the entire production facility and hence improving the efficiency of the AGVS is very important.

The success of the AGVS in production firms has motivated people to use this system in other areas where efficient material handling is needed. And now, AGV’s have become an important component of most material handling systems.

1.1

AUTOMATED GUIDED VEHICLES

AGV’s are automated vehicles whose movement are controlled by a central or distributed control system. Typically, an AGVS has lot of sensors that send the location data of the vehicles. The control system takes in this data and decides whether a vehicle needs to move or not. AGV’s have a predefined layout on which they run and to prevent collision, most AGVS are zone controlled. It means that the track on which the AGV’s travel is split into smaller zones and only one vehicle is allowed to be present in a zone at any


Chapter 1

Introduction

10

particular time. Hence, when the next zone of a vehicle is blocked, the AGV waits until the zone is cleared before it proceeds. This is illustrated in the figure 1.1.1.

AGV 1 is waiting for AGV2 to clear

AGV 2 is loading/unloading

Figure 1.1.1: Illustration of zone controlled AGVS

Most AGVS layouts are simple and usually they have a loop in which the AGV’s travel. To reduce waiting time, simple solutions as shown in figure 1.1.2 are developed. The figure shows that the layout is made in such a way that there is an alternate route at the working locations. But such a simple strategy works only if the layout is very simple. For complicated layouts, better routing is the best way to increase the efficiency of AGVS. Actual route

New route

AGV Loading

Figure 1.1.2: Simple solution to reduce waiting time.

The increasing demand for better material handling solutions and also the presence of other constraints like space availability makes the AGVS layout very complex and hence the performance of the AGVS is dictated by the routing strategies.

1.2

PSA PORT AUTOMATION PROJECT (PPAP)

PSA Corporation is one of the world’s leading port operators and in Singapore PSA handles more that 15 Million TEU of cargo each year. Figure 1.2.1 gives a feel of the growth of PSA in terms of the amount of cargo handled. PSA operates many ports outside Singapore and due to increasing demand and also to maintain and improve their quality of service, they resort to automation of the port activities. Currently, PSA employs fully automated cranes in their ports as part of their container storage-retrieval


Chapter 1

Introduction

11

system. It operates about 24 quay cranes, 44 bridge cranes and 15 gantry cranes at the Pasir - Panjang Terminal. Figure 1.2.2 shows the bridge cranes used at the terminal.

Figure 1.2.1: Increase in volume of transaction in ports operated by PSA

Figure 1.2.2: Bridge Cranes in operation


Chapter 1

Introduction

12

Yard Side lanes

Corridor

Berth Side lanes

Figure 1.2.3: Part of the PSA’s AGVS layout showing one berth.

To further improve the service rate, PSA had decided to make the port operations fully automated. As part of this automation process, PSA is introducing AGV’s for container transport within the port. A pilot project is being done at the Pasir-Panjang Terminal in Singapore. In Singapore, land is a very important resource and efficient usage of the available space is one of the prime objectives in any project. An important feature of the ports in Singapore is that most of the cargo (almost 80%) is for transshipment. Hence, enough space for the transshipment goods must be available close to the dock.

To maximize the usage of the land area close to the dock, a complex AGVS layout has been planned for PSA. A part of the layout drawn by PSA is shown in figure 1.2.3.

When the layout is complex, the control and navigation systems of the AGVS must be very efficient to prevent any major congestion in the AGV traffic. High rates of congestion results in longer service time and lesser throughput and the objective of PSA to reduce the service time will not be fulfilled.

1.2.1 Description of Layout This section gives a brief overview of the PSA’s AGVS layout.


Chapter 1

13

Introduction

The layout has the following components. •

Berth-side lanes

•

Corridors

•

Traveling lanes

•

Working lanes

Figure 1.2.3 shows the lanes in the berth-side, storage yard and the corridor. There are 8 lanes on the berth-side and 4 lanes on the yard-side. The Export/Import containers are stored in the storage yard and the vessels arrive at the berth. All the containers need to be transported to or from the vessel and hence there are more lanes in the berth-side. The transshipment containers are stored in the storage yard and figure 1.2.1.1 shows a storage yard with the adjoining working and traveling lanes and figure 1.2.1.2 shows the traveling lanes and the working lanes in detail. A berth is the area between the two corridors.

Container Storage Area

Figure 1.2.1.1 Storage yard. Traveling lane

Working lane 1

Working lane 2 Figure 1.2.1.2 Traveling and working lanes.

1.3

UNIQUENESS OF PPAP

The project undertaken by PSA has a lot of unique features. With regard to port automation, there are only a few ports in the world that are fully or partially automated. On top of being one of the few ports that are automated, PSA has a lot of other constraints to heed to. As mentioned in the previous section, space is a major constraint for PSA and an AGVS layout with such complex network is the first of its kind.


Chapter 1

14

Introduction

Problems in routing may lead to system stall and manual intervention would be needed to restart the operations. PSA seeks to minimize human intervention in the automated system, since any intervention reduces the efficiency of the operations. As part of the control and navigation systems, there are a lot of physical constraints to be taken care of. For example, as seen in figure 1.3.1, when an AGV takes a turn, if there is a vehicle within a certain distance, it may lead to collision. This is much different when compared to routing systems in communication networks where such physical constraints are nonexistent. Such cases are to be taken care of by the navigation system and there are a host of other conditions to be checked by a particular vehicle before it moves.

AGV1

AGV2

Frame a

Frame b

Figure 1.3.1: Physical constraints in AGVS leading to deadlock.

1.4

PROBLEM STATEMENT

To address the concerns mentioned in the previous sections, PSA expressed the need for improving their current routing strategy. Specifically, a solution to prevent the deadlock in the AGVS is to be developed as part of the project. Deadlock in a broad sense can be defined as a condition when the system is stalled i.e. the automated system is unable to continue operations.

As part of the project, a deadlock prediction and avoidance strategy should be developed and satisfactory performance of the system must be demonstrated. The new strategy should be implemented in AutoMod and performance must be compared with that of the existing strategy that does not include deadlock prediction.

The control system provides the actual vehicle location every 1.5 seconds and the deadlock prediction phase must take into consideration the latest information if possible.


Chapter 1

Introduction

15

Hence the strategy developed must be computationally very efficient. If a deadlock is predicted, then an efficient avoidance measure (i.e. wait or reroute) is to be recommended. The project should address these concerns and detailed descriptions of the algorithms developed must be included.

1.5

PROJECT CONTRIBUTION

The problem proposed has been studied in detail and the following chapters provide a detailed description of the problem and the solution proposed. The proposed solution shows very good performance both in terms of throughput and also in detection of the deadlocks. The highlights of the project are: •

Development of an efficient deadlock prediction algorithm.

•

Development of a deadlock avoidance strategy.

•

Implementation of the deadlock prediction and avoidance scheme in AutoMod.

•

Implementation of the routing algorithms in C and interfacing them with AutoMod.

•

Recommendations regarding the usage of the deadlock prediction-avoidance strategy.

1.6

OUTLINE OF THE THESIS

The remainder of the document is divided into the following chapters. •

Chapter 2 provides a detailed review of the existing literature on the following topics:

Existing deadlock detection and prediction methods and an overview of their performance.

Literature regarding routing and the shortest path problem. •

Chapter 3 discusses in detail the deadlock prediction method. Details regarding the exact working of the method and a detailed description of the algorithm are included in this chapter.

•

Details regarding the avoidance measures are included in chapter 4. A description of the proposed semi-dynamic routing strategy is provided. Also included are details regarding the shortest path problems and implementation specific details to improve the computation speed.


Chapter 1 •

Introduction

16

In Chapter 5, detailed description regarding the implementation of the entire strategy in AutoMod is provided. Description of important AutoMod functions used is provided in this chapter.

•

Chapter 6 provides results obtained in the project and a detailed discussion of the results is included. Recommendations are made in this chapter as to the usage of the deadlock prediction-avoidance strategy in PAPP.


Chapter 2

17

Literature Review

2 LITERATURE REVIEW Deadlock detection has been a very important research topic and there are quite a few papers written in this field. But most of these literatures are suitable for very simple or small AGVS layout.

In [7], Lee and Lin use the theory of petri-nets onto AGV systems. They extended the idea of using petri-nets on flexible manufacturing systems (FMS) proposed by Viswanadham, Narahari and Johnson [13] for deadlock prediction and avoidance. In this paper, there is no mention of actual implementation of the algorithm. The complexity of this method is O(nm2) where ‘n’ is the number of nodes and ‘m’ is the number of arcs.

In [6], Cho, Kumaran, Richard and Wysk’s approach for the deadlock detection and resolution is to classify the network layout as bounded circuits. The definition of bounded circuits is similar to that of cycles. Using results from graph theories, the method is able to detect an impending deadlock situation. The complexity of the algorithm is O(wn(n+m)2) where w is the number of cycles.

In [9], a conflict resolution route planning method was devised by Reveliotis using a modified version of the banker’s algorithm [2] proposed by Chang, Tanchoco and Koo. The method in brief comprises of incrementing the route of the vehicle one zone at a time. This is done by first testing whether the system is in a “safe” mode before deciding the vehicle’s next zone. The complexity of the algorithm was shown to be O(V2) where V is the number of vehicles.

Upon detection of an impending deadlock situation, we implement a shortest path algorithm to determine the routes. The shortest path problem has been studied extensively


Chapter 2

Literature Review

18

in the literature. In [8], Ahuja, Magnanti and Orlin provide a general description of the various shortest path algorithms available. Theoretical analysis along with the computational complexity is also provided.

Reference [4] is a survey of the famous shortest path algorithms and in that, Gallo and Pallottino also provides basic recommendations of the choice of the algorithm for a given network. Also, a study of the important data structures is done in this paper and the performance of the various methods is compared. It also provides pseudo code for all the algorithms recommended in the paper and the comparison based on the computational complexity is done.

In [1], Zhan compares the three fastest algorithms on real road networks. The authors have compared the performance of the methods and have recommended the best algorithms along with the data structures for large road networks.

Pallottino and Scutella, [10], provide a study of the SPT algorithm for transportation systems. A dynamic shortest path algorithm called the chrono-SPT is provided. It also provides information of finding shortest paths with a time window constraint.

Apart from the above-mentioned papers, there is a lot of literature regarding routing problems in communication networks. But the methods used in communication networks cannot be directly be employed in AGVS network. This is because in the communication network, the information packets can be destroyed and sent again which is not possible in the AGVS. Even though the references provide a theoretical understanding of the AGV routing and the deadlock detection problem, there is no actual implementation mentioned in them. Most of the literature available is useful only for simple AGVS layouts. The cases under study are mostly FMS layouts where the network is very simple and a simple strategy as mentioned in [6] would be efficient as there would be only a few bounded circuits.


Chapter 2

Literature Review

19

For the problem under consideration, the AGVS layout is massive and it the first time that such an AGVS layout is taken for study and the methods that have been proposed earlier fail because the computational effort and/or the memory requirement is very large. Hence, a computationally efficient strategy needs to be developed to tackle this problem for a huge and complex network.

There are special algorithms proposed for finding shortest path in large networks. But, these techniques are not used since it is seen that a simple implementation of the Dijkstra’s algorithm works very well for the network. The reason for this good performance may be attributed to the AGVS layout.


Chapter 3

20

Deadlock Prediction Algorithm

3 DEADLOCK PREDICTION ALGORITHM A system is said to be in a deadlock if a part or the whole of the system stalls. In the AGVS, resources (zones between control points) are shared among the whole population of vehicles. Each of the vehicles can only occupy one zone at a time. This kind of maintaining control over particular resources (zones) allocated to the vehicle may bring about deadlock (see Figure 3.0.1).

In this chapter, the necessary conditions leading to deadlock, the different types of deadlock that can be deduced from the routing policy of the AGVS and the deadlock prediction and avoidance measures taken will be touched on.

Zone 1

Zone 4

Zone 2

Zone 3

Figure 3.0.1: A cyclic deadlock form by the vehicles.

3.1

THE CONDITIONS LEADING TO A DEADLOCK

From the literature available, Coffman, Elphick and Shoshani [3] pointed out that in order for deadlock to occur all of the following four conditions must be satisfied. The four conditions are: Deadlock prediction and avoidance in an AGV System

Chapter 3


21

•

Mutual exclusion: Two or more processes cannot use a resource at a time.

•

No preemption: When a resource is being used, it is not released until the process using it finishes with it.

•

Hold and wait: A process that is holding at least one resource and is waiting to acquire additional resources that are currently being seized by other processes.

•

Circular wait: A closed chain of processes in which each process is waiting for a resource occupied by the next process in the chain.

Therefore if even one of the conditions does not hold then a deadlock will not occur. It will be seen in the following that only the last condition can be prevented for the AGVS, as the other three conditions are always true for this system.

The resources mentioned in the four conditions refer to the zones of the path and the processes are the AGV’s. Mutual exclusion is obvious, since a zone cannot have two vehicles in it at any given time. This is a condition required by the control system in order to prevent the AGV’s from colliding into each other. ‘No Preemption’ is also obvious because, the vehicle must be in any zone at a given time (it cannot disappear into thin air) and the movement of the vehicle into another zone satisfies the condition. As for ‘Hold and Wait’ condition, it is also satisfied in the case of the AGVS as each vehicle has to be a zone at any one time and is waiting to move into it’s designated next zone. Thus all of the first conditions are satisfied leaving only the ‘circular wait’ condition. This condition is not always true in the AGVS and this is where the deadlock prediction can be used to detect whether a deadlock is imminent. The method in which the deadlock prediction is done will be covered in the later sections. In the following section, the different types of deadlock that can happen in the AGVS will be presented.

3.2

TYPES OF DEADLOCKS IN THE AGVS

They’re several forms of deadlock that can be formed in an AGVS. Given the layout and the routes of the vehicles, there can be many forms of deadlocks depending on the control logic of the AGVS. In this section, the three most common kinds of deadlock will be


Chapter 3

22


discussed including the generic form of deadlock i.e. cyclic deadlock in which, the vehicles form a cycle of request for the zones.

3.2.1 Cross lane deadlock The first kind of deadlock would be when two of the vehicles wanted to switch lanes. An illustration of this is shown in Figure. 3.2.1.1. AGV 1

Traveling lane

AGV 2

Working lane

Figure 3.2.1.1: Illustration of a deadlock when two vehicles are crossing into each other’s lanes

For example, say AGV1 wants to go to the working lane and AGV2 wants to go to the traveling lane. A situation may occur such that AGV1 might not be able to turn to the working lane if AGV2 is too near to the intersection i.e. AGV1 might collide into AGV2 when it makes the turn into the working lane. The navigation system on the vehicle will tell the AGV1 to stop. This will be the same for AGV2, which results in two vehicles waiting for each other to move, but nobody can move.

This kind of deadlock would be resolved by having a smart navigation system i.e. decide where the vehicles should stop when they are waiting. Installing more sensors to tell the vehicle where to stop can do this.

3.2.2 Shop deadlock Another kind of deadlock termed shop deadlock [2] can occur when the vehicles are dispatched carelessly in an overloaded shop as illustrated in Figure 3.2.2.1. In the container yard, there is only finite amount of capacity in each storage area. If all the storage space is used up, a situation as shown in Figure 3.2.2.1 may occur. It shows a shop deadlock whereby AGV1 wants to unload its container but the storage space has reached the limit and AGV 2 is waiting to pick up the container resulting in both vehicles


Chapter 3


23

waiting. The crane is lifting a container and cannot be dispatched to lift the container from AGV1.

Crane

Input Buffer

AGV 2

Output Buffer

AGV 1 Figure 3.2.2.1: A Shop deadlock

To prevent the shop deadlock, three things can be implemented concurrently. The first is routing. In Figure 3.2.2.1 there is only one lane in which the vehicle can move. Hence additional lanes and cross over between the lanes can be provided as in figure 3.2.2.2. Crane

Input Buffer

AGV2

Output Buffer

AGV1

Figure 3.2.2.2: Avoiding the Shop deadlock.

These additional lanes together with a good method of distribution of the containers throughout the storage yard and Banker’s algorithm as explained by Chang, Tanchoco and Koo [2] could prevent the shop deadlock from happening. For the case of our current project, prediction of this form of deadlock was not implemented as PSA has it’s own distribution algorithm that assures that the space constraint will not be tight.


Chapter 3


24

3.2.3 Cyclic Deadlock The last deadlock, which is the most generic, is the cyclic deadlock shown in Figure 3.0.1. This form of deadlock occurs when there is a chain of vehicles requesting for the zones (resources) in such a way that these form a cyclic request of zones. This form of deadlock prediction was not available in the control systems of the vehicles. A prediction and avoidance algorithm is needed to tackle this situation. In the following sections, a feasibility study on the present methods from the literature is done and at the last section will discuss about the prediction algorithm used in our implementation. 3.2.3.1

Methods in predicting or detecting cyclic deadlock

In the literature available, [7,13,6,14] have discussed the methods of predicting and detecting cyclic deadlocks. The methods mentioned in the literature in predicting the deadlock are either complicated or computationally expensive. For our case, the computation time to predict such a deadlock must be small as every sample time for the control system is in the range of 1.5 to 2 seconds. In the following, a discussion on why the methods mentioned in the literature are not feasible for implementation is provided.

In [7,13], Lee, Lin and Viswanadham, Narahari and Johnson use the petri-net theory to predict and avoid cyclic deadlocks in the FMS and AGVS. The entire network must be represented in the form of a matrix. The AGVS layout in our implementation consists of 1370 nodes and several thousand arcs. The dimension of the matrix would be in the order of a few million elements, which takes up huge memory space. To detect a cyclic deadlock, matrix vector operation needs to be done. For our implementation, the matrix is too large and the computation per iteration is O(m n) where ‘n’ is the number of nodes and ‘m’ is the number of arcs of the network. Therefore it is not feasible to implement this method for this problem.

In [6], Hyuenbo, Cho, Kumaran and Wysk use graph theory to detect impending deadlock. In order to do that, bounded circuits defined in [6] have to be found. The number of bounded circuits for our network is very large since the network in too complex and hence this method is also dropped.


Chapter 3


25

In order not to have a cyclic deadlock occurring, one strategy is to limit the number of vehicles for the entire system to be smaller than the minimum number of nodes in the smallest possible cycle. With this ensured, a cyclic deadlock will not possibly occur as there will not be enough vehicles to form a cyclic request of resources i.e. zones. However, this is not desirable since the AGVS will not be gainfully utilized. 3.2.3.2

Deadlock prediction algorithm

Since there are suitable no methods in the literature that can predict deadlock very fast for our problem, a new approach is developed to satisfactorily solve this problem. First, algorithm used for predicting the deadlock for one zone step is presented and then later in the section the algorithm for two zones step is presented. The algorithm that is used for one zone step is as follows:

The following is the definition of the numbers in Figure 3.2.3.2.1. 1. Extract the location (Lp) (i.e. the control points) of its next zone of the selected vehicle (say Vi) that is about to enter a new zone. For every sampling time i.e. 1.5 sec to 2 sec, a check is done to see if a vehicle has moved to a new zone or not. If it has, the vehicle is selected so that a deadlock prediction for its next zone step is done. 2. Check whether this next zone (Lp) is occupied by another vehicle. 3. Extract the location (Lq) of Vi ‘s next 2 zone (i.e. the “next next” zone). 4. Check whether any other vehicle occupies Lq. 5. Extract next zone location (Lr) of the vehicle that is occupying Lq and update Lq to the location Lr. 6. Return “vehicle is blocked”. 7. Return “vehicle is safe to proceed, deadlock is not predicted”. 8. Check whether Lp is equal to Lq. 9. Return “vehicle is not safe to proceed, deadlock is predicted”.


Chapter 3

26


1

Occupied

2

6

Not

Not occupied

4

7

Occupied Not Equal

5

Equal

Figure 3.2.3.2.1: Flowchart of the algorithm used to predict the deadlock (one zone step).

Let’s look at an example: 1 2 AGV 1

AGV1’s ‘next next’ location 5

3

AGV 2

AGV 4 4 AGV 3 Figure 3.2.3.2.2: Illustration of one zone step deadlock prediction.

The example in figure 3.2.3.2.2 shows four vehicles AGV1 to AGV4 and the shaded nodes are the locations of the vehicles. The arcs in each of the node are pointing to the next location node of the vehicle’s route for e.g. AGV4’s next location will be node 2. Following the given algorithm for the one zone step deadlock prediction, say AGV1 is about to enter a new zone i.e. node 2. It checks whether node 2 is occupied (Here, the


Chapter 3


27

node is free). It then checks its ‘next next’ node, which is node 3. It finds that AGV2 is occupying the node and hence, AGV2’s next node is checked, which is node 4. AGV3 is found to be occupying node 4 and then it continues to check AGV3’s next node i.e. node 5 and finds that AGV4 is occupying it. Finally it checks that AGV4’s next node i.e. node 2 is the same node that AGV1 wants to enter to. If AGV1 is allowed to enter node 2, there will be a cyclic request of resources, which implies a cyclic deadlock. The algorithm will thus return a value saying that a deadlock is predicted at the next zone step. The avoidance measures will be discussed in the chapter 4. The computational complexity of the algorithm is in the worst case O(V2) where V is the number of vehicles in the entire AGV system. This is because the worst case will be when the entire fleet of vehicles forms a huge cyclic deadlock.

In a control system, it will be difficult to detect when an AGV exactly enters new zone i.e. just crosses the boundary line of the previous zone and the new zone. This is due to the sampling time, every 1.5-second data is sent to the central control system such that the detection of crossing a zone boundary exactly cannot be detected. In order to detect whether the vehicle has enter a new zone, a comparison of the previous sampled position and the newly sampled position of the vehicle is done. If there is a change in the zone, the vehicle has entered a new zone. Here, it is assumed that a vehicle cannot traverse an entire zone within 1.5 seconds.

This algorithm has been implemented in a small-scale model consisting of 8 vehicles and 14 nodes, and the simulations show that the system is deadlock free as far as cyclic deadlock is concerned. The avoidance measure used in this small model is the “wait and proceed” which is discussed in Chapter 4. The large-scale model was also implemented and it exhibits no form of cyclic deadlock. The results obtained for the large-scale model are presented in chapter 6.

It is possible to extend this idea to the two-zone step deadlock prediction. The purpose of this is basically to facilitate for a better performance of the system. If deadlock is


Chapter 3


28

predicted earlier, then a better avoidance measure can be taken. For example, when a vehicle’s destination is not in the predicted deadlock region, then the vehicle can be rerouted in order to avoid congestion in the potential deadlock region. A disadvantage of this form of prediction will be that mild approximations are done here. These kinds of approximations come into effect because the vehicles do not travel from one point to another in exactly the theoretical time required. This difference between the expected time and the actual time taken creates an error. This error of prediction gets larger as more zone steps are predicted in advance. The proposed two-zone step prediction algorithm is shown in appendix C.


Chapter 4

Deadlock Avoidance

29

4 DEADLOCK AVOIDANCE As we have seen earlier, there are to ways of solving the deadlock problem: detection– resolution and prediction–avoidance. AGV is an expensive resource and hence, the total downtime for the system must be minimized. Hence a prediction–avoidance strategy is better because the strategy makes sure that no deadlocks occur and hence it results in better operations and higher throughput.

In the earlier chapter we had discussed regarding the deadlock prediction. Now, we shall see how deadlock avoidance is done. There are two strategies used as an avoidance measure: ‘Wait and proceed’ and ‘Rerouting’. The following is a brief description of both the avoidance strategies. •

Wait and Proceed In this strategy, when a vehicle predicts a deadlock in its route, then the vehicle stops at the same location and waits until at least one vehicle gets cleared from the predicted deadlock region.

•

Rerouting Another way of avoiding deadlock is by using a dynamic routing system. The system proposed is not entirely dynamic due to the time constraints i.e. the decision of rerouting and the new routes are to be given back to the control system within 2 seconds. Hence, a semi-dynamic routing strategy that computes static routes taking into consideration the traffic congestion effects is proposed as a solution to the avoidance problem.

The following sections discuss in detail the Deadlock Avoidance strategy. Computational results along with the performance measures are included to compare the two proposed strategies.


Chapter 4

Deadlock Avoidance

30

The first strategy is fairly simple as it halts the vehicle until the deadlock is cleared and then allows it to follow the original route to the destination. Hence the rest of the sections are devoted to describing the method by which the routes are re-computed. Also the computational issues that have been taken into consideration for faster solutions are described.

4.1

DYNAMIC ROUTING STRATEGY

In the AGV system that is used at PSA, the routing system is as follows: 1. The ‘work’ is assigned to a particular vehicle and the origin and destination information is passed to the routing system. 2. The travel time on the lanes is updated based on the projected congestion. Here, projected congestion means that the traffic information is projected in time and the congestion in future is calculated assuming that the AGV’s proceeds according to expectation. 3. A shortest path is calculated with the projected congestion effects. 4. The vehicles move from the origin to the destination along the calculated route.

In the above system, even if the projections are made as accurate as possible, in real time, we cannot expect the vehicles to be at an expected location at exactly the same time. For example, as shown in figure 4.1.1, there may be a delay in loading of a vehicle and due to that the vehicle under consideration may get delayed.

Such a delay for one vehicle affects the entire traffic system and hence, we can almost always never assure that the actual vehicle distribution to be the expected distribution. Another reason for the difference in the expected and actual vehicle distributions is due to the acceleration and deceleration effects in the vehicle. The vehicle always tries to travel at top speed. But the vehicles must decelerate at turns and would have to stop when it is queuing up. These effects are very difficult to simulate before hand and this also causes a lot of problem in predicting the exact location of the vehicles.


Chapter 4

Deadlock Avoidance

31

Vehicles waiting to be served by the Crane.

Vehicle waiting to pass Figure 4.1.1: Figure representing an example for a vehicle to be delayed in its travel.

Due to the above-mentioned reasons and a host of other physical limitations, the static routing system is not the best routing policy that can be used for the AGV system. Hence a routing system that takes into consideration the real-time information would be a better solution to this problem.

The route is calculated using the Dijkstra’s algorithm to find the shortest path tree (SPT). As mentioned earlier, the proposed method is semi dynamic i.e. the arc weights are updated at regular intervals of time and during that period of time, the vehicles are expected to follow the routing plan. More specific details are available in the following sections.

4.1.1 Calculation of Shortest path The shortest path is calculated using Dijkstra’s algorithm. The general outline of the Dijkstra’s algorithm explained in detail by Ahuja, Magnanti and Orlin [8] is given below. Given a network G(V, E), where V

: The set of Nodes

E

: The set of edges.

dv

: The distance of node ‘v’ from the origin node.

S

: The set of Nodes in the SPT.

S’

: The set of Nodes not in the SPT.


Chapter 4

lij

Deadlock Avoidance

32

: Length of arc (i, j) ∈ E.

Pr (i) : The predecessor of node ‘i’ in the SPT.

1. Initially, S is an Empty set and in the first step, the source node is added to this set ds = 0 Pr( s ) = Null 2. The values dv is set to Infinity for all Nodes v ∉ S 3. Remove a node ‘i’ in S’ and add it to the set S. 4. For every node ‘j’ in the Forward star of ‘i’, do: If d i > d j + l ij Then d i = d j + l ij Pr( j ) = i 5. The above operations are carried out till the optimality conditions are reached i.e. d i + l ij ≥ d j

∀(i, j ) ∈ E

Implementation specific details are available in the references [8] and [4]. The performance of the shortest path algorithms is dependent on the network and there are a lot of variants of the shortest path algorithms specific to the underlying network. Also, it has been shown by Gallo and Pallottino [4] that the performance of the algorithm is very much dependent on the kind of data structure used for representing the sets S and S’.

Even though there are a variety of variants in the shortest path algorithms, most of them use the above-mentioned strategy for finding the shortest paths. In the current study, the Dijkstra’s algorithm has been implemented using the queue data structure.

4.1.2 Storage of Routes Since the strategy adopted is semi dynamic, we need to recalculate new routes only when one of the condition holds:


Chapter 4

Deadlock Avoidance

33

•

The AGV reaches the Destination and a new job is assigned to that particular vehicle.

•

The deadlock Prediction Algorithm predicts the formation of a deadlock and requests for a new route for the AGV.

Since the formation of deadlocks is not very frequent, we need not re-compute the shortest path every time an AGV enters a new zone. Hence, the routes are stored in a table and when an AGV requests for its next location, the next zone is returned for the particular vehicle. This also saves a lot of computational time.

When the AGV predicts a deadlock, it first calls the shortest path code. After the route is computed, it requests for the next node. Figure 4.1.2.1 illustrates an AGV that requests for re-routing and then moves in the new path.

In the figure 4.1.2.1, the new route is computed because the AGV predicts a deadlock to be formed. If the prediction algorithm finds its original route to be clear then the route need not be computed again. In such a case, the route is directly obtained from the stored information.

Cyclic Deadlock Predicted Destination Original Route New Route Figure 4.1.2.1: AGV predicts a deadlock and changes its route

4.1.3 Updating the Arc Weights Another important and computationally expensive step in our routing strategy is that before the shortest path is computed, the arc weights must be updated. The shortest path


Chapter 4

Deadlock Avoidance

34

is computed based on the arc weights and if they are not updated, the system will always return the same route.

The arc weight considered for the calculation of the shortest path is basically the traveling time on each arc. If there is no traffic, then the traveling time on any arc is approximately the same. It is approximate because of the effects of acceleration, slowing down at turns etc. Even though the travel time is affected by the above-mentioned factors, their effects are minimal. Severe delay is actually caused by the congestion due to the AGV traffic in particular paths.

Another major reason for considering the congestion effects is that it helps in creating good routing schedules. It has been shown by Leighton, Maggs and Rao [11] that a routing schedule in O(c + d) can be constructed for a given layout. Here, ‘c’ is the maximum congestion and ‘d’ is dilation i.e. the length of the longest path. Hence, reduction in the values of ‘c’ and ‘d’ has a direct impact on the schedule length.

They show that given the O-D pairs and their paths, a schedule of length O(c+d) can be constructed. Hence, while rerouting, we need to take care that we try not to increase the congestion and dilation. This can be achieved by updating the arc weights with the congestion factor and hence updating the weights becomes an important step. It should be noted that when we find shortest paths, then we try not to increase dilation. At the same time, if we update the arc weights with the congestion effects, we tend not to use the congested arcs. Hence we will obtain routes in which the values of ‘c’ and ‘d’ are maintained at a smaller value.

Even though the results were obtained for packet routing networks, the consideration of congestion and the dilation together would be crucial for obtaining good routing schedules even in the AGVS case. However, there are few differences in the case considered in [11] and the AGV routing problem. This is because in [11], the problem is of packet routing and the travel time for the packets along the arcs is very small. Also


Chapter 4

35

Deadlock Avoidance

along all arcs, the travel time can be considered equal for the data packets, which is not the case in the AGV routing problem.

There is not much literature available on dynamic updating of arc weights on large networks and hence, we have devised a computationally cheap method for doing the above operation. The figure 4.1.3.1 is a simple sketch of the method in which the arc weights are updated. The figure represents the path that a vehicle is originally assigned to and also due to prediction of deadlock, the route has been changed as shown. The Adjacency matrix entries are appropriately changed as seen in table 4.1.3.1 and table 4.1.3.2. 1

2

O

D

3

4

Original Route New Route Figure 4.1.3.1 Illustration for updating Arc Weights

Node O O 1 2 3 4

0

1

2

Lold o1 0

3

4

D

Lold o3 old L12

Lold 2D

0 0

Lold 34 0

Lold 4D

Table 4.1.3.1 Original Adjacency Matrix


Chapter 4

36

Deadlock Avoidance

Node O O 1

0

1

2

Lold o1 − k 0

3

4

Lold o3 + k old L12 −k

Lold 2D − k

0

2

0

3

D

Lold 34 + k 0

4

Lold 4D + k

Table 4.1.3.2 Adjacency Matrix after rerouting one vehicle

Lnew = Lold ij ij + k

(i, j ) ∈ NewRoute

Lnew = Lold ij ij − k

(i, j ) ∈ OldRoute

Lnew = Lold ij ij

Otherwise

Figure 4.1.3.2: Formula for updating arc weights

In the tables, the value ‘k’ is a positive constant. The magnitude of ‘k’ depends on the . Here, we simply use the use the formula base values of Lij i.e. we can consider k = Lbasic ij mentioned in figure 4.1.3.2.

The value of Lij changes dynamically with the number of vehicles using the arc (i, j). Each arc (i, j) has a basic weight associated with it, which is Lbasic . When there are no ij vehicles using the arc, then the arc weight is Lbasic . Hence, the arc weight will always be ij greater than or equal to the basic value i.e. Lbasic ≤ Lnew ij ij .

A first look at this algorithm gives a feel that the operation count is O(n2). But, the updating procedure is made simple because at the time of calculation of the routes, we know both the new route and the old route. Hence, we can just follow the arcs in the routes and now update procedure takes at most O(2n) which is an impossible worst case. But, in any route, we will not be traveling through all the nodes and hence, the number of operations for this procedure is much lesser: typically O(1).


Chapter 4

37

Deadlock Avoidance

If we update the weights as shown above, then we penalize all the arcs in a route equally. This is not a good strategy because an arc that is reached by an AGV1 at a much later time can be used now by another vehicle. Hence in the implementation, the weights are updated in such a way that the additional weight is inversely proportional to the distance of the arc from the current location. An example of such an updating procedure is given in figure 4.1.3.3. This would be a more appropriate updating procedure since unlike the data packets considered in [11], in the AGVS, the time taken for a vehicle to reach an arc plays an important role in determining the queue for using that arc.

K

K

K

K

K+ξ

K+αξ

K + α2 ξ

K + α3 ξ

K: Actual arc weight 0 < α < 1.0 ξ: Additional Arc weight Figure 4.1.3.3: Arc weight updating with varying weights

Typical value of α used is 0.9 and ξ is the actual arc weight. The Table 4.1.3.3 compares the performance of the ‘rerouting’ strategy with constant and varying arc-weight updating. Each trial in the table is an experiment with 500 O-D pairs. The routes are computed and the deadlock prediction strategy is simulated. The table shows the average route length and the maximum route length.

It should be noted that in all the cases, the average route length is lesser when the varying arc weight updating strategy is used. Also, it can be noticed that the maximum route length in the varying arc weight updating case is less than or equal to the value constant weight updating case. This means that in the AGVS case, if the arc weights are updated with varying weights as explained, then the dilation will be lesser than the constant weight case. The value of ‘c’ the congestion was same for all the cases showing that the varying arc weight is a better updating strategy. The best values are highlighted in the table.


Chapter 4

Trial

38

Deadlock Avoidance

Constant Arc-weight updating

Varying Arc-weight updating

Average route length

Maximum route length

Average route length

Maximum route length

1

330.55

760

328.7

735

2

302.85

690

300.68

690

3

305.67

695

303.5

695

4

316.47

735

314.12

735

5

297.88

750

296.2

750

Table 4.1.3.3: Comparison of the different Arc weight updating strategies.

4.1.4 Improvements in Computation speed The Shortest path code is one of the main ingredients of the solution proposed in this project. The code is run many times and hence any minor improvements in the performance of the algorithm will result in drastic improvements of the performance of the entire routing system.

The Dijkstra’s algorithm is used to find the SPT and the algorithm terminates only when all the nodes are permanently labeled. But, in case of our rerouting problem, we need to find the shortest path between the source and the destination only. If we are able to stop the Dijkstra’s algorithm immediately after the required path is found then we can expect a definite improvement in the running time of the algorithm.

With this motivation, we can take a second look at the Dijkstra’s Algorithm. We note that a node is permanently labeled only when the distance between the origin and that particular node is the minimum possible distance. This implies that when the destination node is permanently labeled, then we have already obtained the shortest path between the origin and the destination. Hence, we can stop the operation of the algorithm once the destination node is permanently labeled. In the implementation, when all the arcs (i, d) ∈ E are scanned, then the destination node will be permanently labeled and we can stop the algorithm. Theoretically, there is no improvement in the operation count for the algorithm. But experiments show that in most Deadlock prediction and avoidance in an AGV System

Chapter 4

39

Deadlock Avoidance

cases, this enhancement provides considerable improvement in the computational speed of the algorithm. Table 4.1.4.1 shows the comparison between the computation times taken for calculating shortest paths between 25 O-D pairs using this strategy as apposed to finding the entire SPT using Dijkstra’s algorithm. The time mentioned in the table is the system time as returned by the command ‘timex’ in SGI-UNIX system.

1

Time taken for finding SPT (Sec) 0.12

Time taken for finding Shortest path between 25 OD pair (Sec) 0.09

2

0.08

0.06

3

0.22

0.19

4

0.19

0.19

5

0.06

0.05

6

0.10

0.06

Trail

Table 4.1.4.1: Comparison of computation times for two different implementations of Dijkstra’s algorithm.

We note from the table that the performance of the partial implementation of the Dijkstra’s algorithm is usually better than the full implementation. Even though the improvement is not drastic in certain cases, it is to be noted that the shortest path needs to be called very frequently and even small improvements in speed of computation is important. We also note that the performance of the Dijkstra’s algorithm is very good for the network. There may be many reasons for this exceptionally good performance. One of them might be that the AGVS layout is unlike any regular road network and also it is very sparse.


Chapter 5

40

Implementation

5 IMPLEMENTATION In the following sections, a brief description of the simulation software, AutoMod, and the implementation details of the one-zone step deadlock prediction in AutoMod language is provided.

5.1

AUTOMOD SIMULATION SOFTWARE

AutoMod is a simulation software that consists of modules for the Automated Guided Vehicle Systems. Basically, a layout of the entire network and tasks has to be set up. The task consists of vehicles picking up the load, which is a container in our case, and delivering the container to its desired destination. The destination can be either a storage yard or a ship. To create the model, certain systems (AGVS, Process) have to be created.

5.1.1 Items required building a model in AutoMod In AutoMod, it is necessary to first create a movement system. In our case it is the AGVS. Figure 5.1.1.1 is an example for the AGVS layout. The layout consists of control points marked in the figure as ‘X’. Each control point has a unique label. Loads or containers in this case enter and exit the movement system through the control points. When the load enters the movement system, a vehicle will be assigned to carry it to its required destination. The paths, which are the lines, represent the way a vehicle can move. A path can be one directional or bi-directional. More information can be found in the paper by Reveliotis [9].

With the movement system created, the next step is to create a process system. A process system simply governs the relationship between loads, resources, and movement systems. In the process system, loads, resources, and queues are defined. In addition to these physical model entities, process procedures are created. Process procedures are like “to do” lists for loads. Deadlock prediction and avoidance in an AGV System

Chapter 5

Implementation

41

Figure 5.1.1.1: An example of AGV path layout. The crosses shown here are the control points by which the vehicle will stop at if necessary.

In a process procedure, instructions are written for the load to follow, telling it what to do next. The process procedure is written in AutoMod language. For our case, the loads would be containers from the ship and they will be transported either to another ship or container storage yard. The AGV’s are their modes of transport. Later in this chapter, a description will be done on how the workflow of the PSA port is simulated using a simplified model.

In order to tell how the AGV to go about their routes, vehicle scheduling in AutoMod is needed. Vehicle scheduling is the process of directing vehicles to retrieve and deliver loads, or travel to a parking location. There are three ways to schedule vehicles in a movement system: •

Creating scheduling lists.

•

Creating and controlling scheduled jobs.

•

Defining vehicle procedures and functions.

Scheduling lists are lists of locations that allow the user control where vehicles look for work, the order in which they pick up loads, and where they park. These are in the form of work list, park list, load activation list, vehicle activation list and load search list. Among these, only the work list and park list are used. A work list is a list of locations where work can be found. All vehicles search this list when they finish their current job and look for a new one. If no new job is found, the park list gives a list of locations where


Chapter 5

Implementation

42

the vehicle can “sleep”. To determine whether it is fine to park at that location, a function called ‘park ok’ function is used. This function can be used to evaluate some conditions and decides whether it can “sleep” at that location. The flowchart of how the vehicles use lists to move and pick up loads is shown in Appendix A section 8.1.

Scheduling jobs are tasks that are waiting to be completed by a vehicle. Scheduled jobs are created automatically as a result of vehicles finding work or a parking location on a scheduling list. However, they can also be created using actions in a procedure or function. Controlling scheduled jobs allows the user to change a vehicle’s current task, as well as view and cancel the waiting tasks that a vehicle has not yet completed. The flowchart of how the vehicles behave as schedulers using vehicle procedures is shown in Appendix A section 8.2.

Vehicle procedures and functions allow the user to perform custom processing as a vehicle travels through a movement system. Using vehicle procedures and functions the user can control scheduled jobs, accept or reject work and parking locations found on a scheduling list, define an alternate route to a vehicle’s destination, and more.

The details of the scheduling lists and jobs are not discussed here. In order to implement our one-zone step algorithm mentioned in Chapter 3, the vehicle procedure and functions are used. The vehicle procedure and functions are discussed in detail in the next section. The flowchart of how vehicles behave as movers using vehicle procedures and functions is shown in Appendix A section 8.3.

5.1.2 Vehicle procedures and functions Vehicle procedures and vehicle functions operate like process procedures and functions; the vehicle performs the actions that are defined for it. Vehicle procedures and functions allow the user to have direct control over vehicles.

Vehicle scheduling is comprised of two parts, the mover and the scheduler. The vehicle can be thought of as a taxi: the load is the passenger, the mover is the driver, and the


Chapter 5

Implementation

43

scheduler is the dispatcher. When the taxi has a passenger (a load), the vehicle goes where the passenger wants to go. As soon as the taxi is empty, the scheduler/dispatcher tells the mover/driver where to take the vehicle, and whether to find work, to park, or to do something else. Once the vehicle has received the scheduler/dispatcher’s instructions, the mover/driver takes responsibility for delivering the vehicle to the correct location quickly and safely. This is where the vehicle procedures and functions are used to implement the one-zone step prediction and avoidance measures for a cyclic deadlock. A description of the syntax of defining a process, procedure and function is included in the next section.

5.1.3 Specification of the workload in PSA In this project, a simplified specification of how the workload is modeled to suit the actual workload is used. Before doing this, the definition of important terms is provided. •

Yard cranes are cranes that carry containers from the vehicles to the storage yard or vice versa.

•

Bridge cranes are yard cranes that run on concrete platform. A bridge crane is shown in figure 1.2.2.

•

Quay cranes are cranes that carry containers from the vehicles to the ship or vice versa.

•

A discharging process is the discharging of containers from the ship to the container storage yards.

•

A loading process is the loading of containers from the container storage yard to the ship.

The specifications are as follows: •

A berth is randomly assigned to an arriving ship.

•

The arrival of the ship is assumed to be every ½ hr interval.

•

Each container storage yard is made of 9 clusters.

•

Each cluster is made up of 3 control points.


Chapter 5 •

Implementation

44

At any one time, a single cluster can only be used by a quay crane for either discharging or loading purposes. It is possible to move the quay cranes but this movement is not simulated here.

•

Four quay cranes are assigned per vessel.

•

Percentage of container handled by each quay crane:

1 2 3 4

st

quay crane: 18%

nd

quay crane: 25%

rd

quay crane: 27%

th

quay crane: 30%

•

Percentage of discharge containers follows a triangular distribution of (0,50,100)

•

Amount of loading containers is the number of discharge containers.

•

Each batch (number of containers) per cluster that is handled follows a triangular distribution of (1,12,24).

•

The time taken for a quay crane to load and unload a container follows a triangular distribution (1.25, 1.63, 2.00) minutes.

•

The time taken for a bridge crane to load and unload a container follows a triangular distribution (2.00, 2.50, 3.00) minutes.

With this, the next section will touch on the implementation of the one-zone step deadlock prediction and avoidance (wait and proceed) algorithm.

5.1.4 Implementation of the one-zone step deadlock prediction and avoidance algorithm in AutoMod To implement the above algorithm, the use of vehicle procedures and function is needed for the “wait and proceed” avoidance algorithm. The prediction algorithm is defined as a function predict deadlock function which will the following values: •

0: indicates no deadlock predicted or vehicle blocking its path on the next node.

•

1: indicates that there is a vehicle blocking its path on the next node.

•

2: indicates that there is a deadlock predicted if it moves into its next node.

Using the above vehicle procedures and functions (see Appendix B for the definitions), the avoidance measure is implemented in the following manner:


Chapter 5

Implementation

45

1. The route of each vehicle is passed to variable list say R using the move to deliver and move to retrieve procedure. These procedures are executed only when there is a new task that needs to be done. Thus it has the current point as the starting point and a destination point with a task (e.g. delivering a container to some storage yard). A new route from the starting point to the destination point has to be obtained. The route is obtained from the built in shortest path algorithm in AutoMod or from the rerouting function. At each point in time, the routes of all the vehicles are known except when the vehicle is loading or unloading the container and the next job is still unknown. This creates a problem for the deadlock prediction algorithm as the algorithm depends on the assumption that all the vehicle’s routes are known. This point will be addressed in the later section.

2. Using the vehicle route list, R, the location selection function is used to force the vehicle to move according to R. The original path of the vehicle is the shortest path from AutoMod. The reason for using location selection function is the ability to implement a new routing strategy and asking the vehicle to follow the route given by this new strategy.

3. At each intermediate control point besides the start and destination control point along the vehicle’s route, the vehicle will call the deceleration ok function which in turn calls the predict_deadlock function to check whether it will have to signal the vehicle to stop at the approaching control point. If a deadlock is predicted, the vehicle will stop and wait at the control point until the deadlock clears. To check whether a deadlock has been cleared, the vehicle will have to invoke the leaving station procedure. This is discussed next.

4. Whenever a vehicle stops at a control point, the systems will check whether there is a process that needs to be executed first. If there are none, the leaving station procedure will be called. In the leaving station procedure, the predict_deadlock function will be called in discrete time steps of 0.2 seconds until the function returns that it is okay to


Chapter 5

Implementation

46

move into the next control point (node). This is the ‘wait and proceed’ avoidance measure that is mentioned in the previous chapter.

The detailed explanation of how the vehicle uses its vehicle procedures and functions is shown in Appendix A section 8.3.

An example is given in the following (see Figure 5.1.2.1), suppose that AGV1 wants to move into its next control point and is currently stopping at its current control point. When AGV1 is about to move into its next control point, it calls the leaving station procedure and this in turn calls the deadlock prediction algorithm. In this example, the deadlock prediction algorithm will return that a cyclic deadlock is predicted if AGV1 moves into its next control point. At this point in time, the leaving station procedure for AGV1 will repeatedly call the deadlock prediction algorithm in discrete time steps of 0.2 seconds (you can always change the time step) until no deadlock is predicted or no vehicle is blocking its next control point. Meanwhile, the rest of the vehicles are going about their assigned task.

Figure 5.1.2.1: An illustration of an impending one-zone step deadlock situation. The small cubes represent the AGV while the bigger one represents that the AGV is carrying a load.


Chapter 5

Implementation

47

The same thing applies even if AGV1 is approaching the current control point (the control point shown in the figure 5.1.2.1). The only difference is that the ‘decelerate ok’ function will be called by AGV1. When it detects that a deadlock is predicted using the predict_deadlock function, the ‘decelerate ok’ function instructs the vehicle to stop. When the vehicle stops at the current control point as shown in the figure 5.1.2.1, the next thing it looks for is whether a process is associated with it. In this example, there are no processes associated with this control point and the leaving station procedure is called, as the vehicle is about to leave its current control point. After this, it does the same thing as described previously.

5.1.5 Difficulties faced during the implementation in AutoMod In this section, a discussion of some of the difficulties encountered and how to resolve them during the implementation of the deadlock prediction-avoidance algorithm is described. 5.1.5.1

Idling vehicles at destination control points

A problem encountered during the testing of the simulation is that if no work is assigned to the vehicle after it has delivered its container either to the storage yard or ship, it will “sleep” or “park” at that location. This results in a form of “deadlock” where the vehicle will not move off until a new job is assigned to it. Thus if there is another vehicle which its destination point is the point that the “sleeping” vehicle is, it will have to wait until the “sleeping” vehicle is assigned a new job and move away from the destination point. This results in wastage of time. To resolve this situation, an algorithm is presented that performs a “bumping” action. This “bumping action” is done when a vehicle wants to move into the location where the “sleeping” vehicle is positioned. The “bumping” vehicle will signal the “sleeping” vehicle to wake up and either “sleep” elsewhere or find a job to do.

Each vehicle in the model has the same attributes as those declared for the loads. In this implementation, a load attribute called LABumpFlag is created. The vehicle uses this to determine if another vehicle has bumped it. By looking at this attribute, the bumped


Chapter 5

Implementation

48

vehicle knows whether it can park at that location or not. If it cannot park at that location, it will search for a next location in the park list provided by the user to park.

If a vehicle is sleeping at a destination location (point A) of another vehicle, the second vehicle will not be able to move to that location. In most cases, the second vehicle comes no closer than the control point (point B) immediately upstream from the destination point. In this implementation, the sleeping vehicle will be bumped from that upstream control point i.e. point B.

In order to perform this “bumping” action, the passing station function is used to test if a vehicle is at point B, and to test if there is a sleeping vehicle at point A. If there is a sleeping vehicle at point A, the “bumping” vehicle must change the attribute of the “bumped “ vehicle such that the attribute will wake the vehicle up by calling another function called “bumpavehic”. This function in turns calls a C-function called “wakeavehic”, which is available in AutoMod C-library, to wake up the “bumped” vehicle.

In short, this is how it works: 1. Whenever a vehicle passes a control point (passing station function), it checks whether it is upstream of any of the destination (point A). If it is, the bumpavehic function is called and this function checks whether there is a vehicle “sleeping” in that location. 2. If there is a “sleeping” vehicle at the destination control point, the function wakeavehic will be called. This function performs the task of “waking” up the vehicle. 3. This “woken up” vehicle then searches its work list for work and if there isn’t any, it then proceeds to check its park list of a list of locations to park. The destination control point will be exempted from the park list by the attribute LABumpFlag. 4. In any circumstances, the “sleeping” vehicle wakes up and leaves the destination control point and the “bumping” vehicle can thus move into that point.


Chapter 5

49

Implementation

The details of how to create the attributes, work list, park list and AutoMod user defined functions, vehicle functions and procedures and internal function are found in [9]. 5.1.5.2

Multi-cycle deadlock

Another deadlock situation might occur due to the ‘one-zone step’ deadlock prediction and the ‘wait and proceed’ avoidance algorithm. This form of deadlock is formed because of multiple loops sharing only one unoccupied node. An illustration is given in figure 5.1.5.2.1.

AGV2 Cycle 1

‘Next next’ node of AGV1 and AGV3

AGV1 AGV3 ‘Next node’ of AGV1, AGV2 and AGV3

Cycle 2

‘Next next’ node of AGV2 Figure 5.1.5.2.1: An illustration of the multi-cycle deadlock situation.

In the figure 5.1.5.2.1, we see that the AGV1 wants to enter the empty node. It’s ‘next next’ node the same as that of the ‘next next’ node of AGV3. Now, AGV1 runs the deadlock prediction algorithm and finds an impending deadlock. According to ‘wait and proceed’, AGV1 waits for the deadlock to clear. This is the same for the AGV2 and AGV3 and their respective ‘next next’ position is as shown. AGV2 and AGV3 will thus wait for the deadlock to clear before proceeding. Here, the cyclic deadlock is avoided by the ‘wait and proceed’ measure but it in turn creates another deadlock, which is not cyclic, but has many cycles share a single empty resource.

For this kind of a deadlock to occur, the following must be true: •

There must be more than one “cycle”.

•

There must be a common empty node shared by the cycles. Deadlock prediction and avoidance in an AGV System

Chapter 5 •

50

Implementation

The cycles must be unique i.e. different start node and end node (excluding the empty node).

•

The ‘next next’ position of the vehicle at the end of each cycle must be the start of another cycle.

Simulations show that this kind of deadlock typically arises due to many vehicles entering an area in the berth. The avoidance measure for this deadlock is primarily one of the following: •

To have a routing schedule to take into account congestion i.e. the rerouting strategy described in chapter 4.

•

Limit the number of vehicles entering an area on the berth at any time.

•

Detection and resolution: To resolve the deadlock, we might want to check along the cycle and move the AGV’s to into the working lanes to disperse the cycle and clear the deadlock situation.

In the current implementation, the deadlock is resolved in the following way.

AGV2 Cycle 1

‘Next next’ node of AGV1 and AGV3

AGV1 AGV3 ‘Next node’ of AGV1, AGV2 and AGV3

Node that does not cause a deadlock

Cycle 2

‘Next next’ node of AGV2 Figure 5.1.5.2.2: Resolution of Multi-Cycle Deadlock

•

Take one of the AGV at the end of each cycle involved in this deadlock for e.g. AGV2.

•

Check the forward stars of the common node.


Chapter 5

•

Implementation

51

For each forward stars, check whether AGV2 will enter a cyclic deadlock if it enters the common node.

•

If no impending deadlock is detected, then reroute it through this forward star.

•

Otherwise, check other forward stars.

The method to resolve this is not a complete resolution of this multiple cycle deadlocks, it fails when all the forward stars of the common node is an impending cyclic deadlock. For our case, this form of deadlock occurs in the ship loading/unloading area where there are plenty of forward stars (i.e. each node can go to a lot of other nodes). Thus, the probability of entering a situation of all the forward stars having a impending cyclic deadlock is almost zero, provided that the number of vehicles in the berth area is kept at a reasonable value. This method was implemented and simulations have shown that this multiple cyclic deadlock is resolved. 5.1.5.3

Deadlock detection and resolution

The earlier part of the document described deadlock prediction. Even though the prediction phase is theoretically fool proof, a deadlock may occur due to the uncertainty of the vehicle route during the loading and unloading process mentioned in section 3.2.3. Take for example, a vehicle carrying a container reaches its destination and the unloading process (crane lifting the container) begins. During this period, the next job of the vehicle is still unknown. As it was not known how long the unloading process would take. Without a next job, there would be no start and destination points and thus no route for the vehicle. The simulation environment requires that all vehicles should have a starting and destination point for proper working of the algorithm.

In order to resolve this kind of situation, a virtual “next control point” will have to be created for the vehicle during its loading and unloading process. With this virtual point, it is sure that if the actual route of the vehicle’s next job is through this virtual point, a deadlock would not occur. If the actual route of the vehicle’s next point is not through this virtual point, a deadlock might occur. If a deadlock is detected, a new route will be scheduled that consist of the virtual control point. Take for example, see figure 5.1.5.3.1.


Chapter 5

Implementation

52

Let us assume that AGV1 is unloading its container at the present control point shown above. It does not have a new job and therefore has no associated route. A virtual control point is referenced for AGV1 at that position when other vehicles are running their deadlock prediction algorithm. Thus if AGV1 is to actually move to the virtual control point when it receive its new route, a deadlock will not occur. This is because that every move is expected since each vehicle runs its deadlock prediction function. If AGV1 does not move to the virtual control point and instead the next control point is the position of AGV2, then a deadlock occurs if there is a cyclic request of their next control points shown in the above figure. The cyclic request occurs between AGV 1, 2, 3, and 4. Thus in this case, AGV1 detects a deadlock and it will then re-route through the virtual control point. This will ensure that no deadlock will occur.

Figure 5.1.5.3.1: An illustration of the problem encountered.

The source code for the above mentioned functions i.e. the one-zone step deadlock prediction and the vehicle procedures and functions in 3.1.1 needed to call upon this function to simulate the actual movement of the vehicles, the bumping algorithm and the deadlock detection and resolve are shown in Appendix D. The source code is written in AutoMod language [15].


Chapter 5

5.2

Implementation

53

C - CODES AND INTERFACING

This part of the report serves as a documentation for the software codes written for the project. The previous section described the Implementation details of the Deadlock prediction algorithm in AutoMod. This section describes the data structures used for implementing the deadlock-avoidance algorithm and also the implementation specific details of the algorithm.

5.2.1 Data structure The Network is very sparse and hence using an adjacency matrix to store the network information is prohibitively expensive. Also, the computational complexity of the shortest path algorithm becomes O(n2) when an adjacency matrix is used which is much higher than O(m.n). Here, ‘n’ is the number of nodes and ‘m’ is the number of arcs.

Hence to reduce the storage space and to improve the computational complexity, a data structure as shown in figure 5.2.1.1 is used. AdjMatrix [n] Node Number Node Name Forward star [k] Forward star distance [k] Figure 5.2.1.1 Data structure used to represent the Network

The ‘node name’ field has been included for interfacing the C program with AutoMod. Instead of using an Array for the ‘forward star’ and the ‘distance’ fields, a linked list can be used. An array is used to prevent memory management problems in AutoMod. The value of ‘k’ is the size of the largest forward star.

The Network is read from a data file that has the format as shown in figure 5.2.1.2. The Network generator generates this data file.

Node Number Node Name FS [1] Distance [1] … FS [k] Distance [k] Figure 5.2.1.2: Data file format.


Chapter 5

Implementation

54

In the implementation of the Dijkstra’s algorithm, a queue data structure is used and the queue is implemented as an array. A linked list is the best way to implement the queue but since AutoMod does memory management, an array is used to avoid memory related conflicts. The structure of the queue item is shown in figure 5.2.1.3. The information regarding the previous and next node is held so as to allow two-way searching along the queue.

The computed routes are stored in table and when there is a request for the next node, this table is looked up and the next node is returned. When there is a request for reroute, the new route is computed and this table is updated. Q_Item Node Number Distance from Origin Previous Node Next Node Figure 5.2.1.3: Structure of the Queue Item

The arc weight updating is done every time there is a request for reroute. The arc weights are updated based on route table and then the shortest path is computed. After the computation is done, the arc weights are reset back to the original values. This is an improvement over the classical Dijkstra’s algorithm as a dynamic component is added.

5.2.2 Implementation of Dijkstra’s algorithm As mentioned in the previous section, the Dijkstra’s algorithm is implemented with queue as the data structure. An important variation from the standard SPT algorithm is that in this implementation, the algorithm is stopped when the destination node is scanned i.e. permanently labeled. The Queue is first in – first out (FIFO) and hence, we can easily find out when the destination node is scanned. For example, we can have a flag on the queue location where the destination node enters and when that node is popped out, we know that it is permanently labeled.

The overall implementation also includes a network generator that creates the AGVS layout and writes the information into the data file.


Chapter 6

Results and Discussion

55

6 RESULTS AND DISCUSSION The one-zone step deadlock prediction and avoidance algorithm was implemented first in a small-scale model for testing and later scaled to the actual model. The actual model layout consists of four berths and 80 AGV’s. The workload generated follows the simplified version of the load distribution mentioned in section 5.1.3. The effectiveness of the algorithm on the small-scale algorithm is discussed first followed by the actual model.

6.1

EFFECTIVENESS OF THE ALGORITHM ON THE SMALL-SCALE MODEL

The testing of the algorithm was done in a path layout shown in Figure 5.1.1.1 with 8 vehicles. The workload distribution is random. The avoidance measure used in the model was the ‘wait and proceed’ method. The model was simulated for 52 weeks and no incident of a cyclic deadlock occurred. If the deadlock prediction and avoidance algorithm was not imposed, the model runs into deadlock in 20 minutes. The AutoMod export file for the entire small-scale model is attached with the report. The small-scale model can be implemented in the student version of AutoMod itself.

6.2

EFFECTIVENESS OF THE ALGORITHM ON THE ACTUAL MODEL

The layout for the actual model used in the simulation is shown in Figure 6.2.1. There are 80 AGV’s in the actual model. The workload distribution was simulated according to the information given in section 5.1.3.

Figure 6.2.1: Layout of the Actual model


Chapter 6


56

Without imposing the prediction algorithm, the simulation runs into a cyclic deadlock situation in 40 minutes and a typical deadlock is shown in Figure 6.2.2.

Figure 6.2.2: Cyclic deadlock in the Actual model

The simulation model was tested with the prediction algorithm and an impending deadlock situation is shown Figure 6.2.3. In the figure, the cycle is not complete and no more AGV’s are allowed to enter the cycle until the vehicles in the cycle move away.

Unoccupied control point

Figure 6.2.3: Impending deadlock detected by the Algorithm

The algorithm has been tested for various cases and the table 6.2.1 shows the number of deadlocks predicted in a period of 1 week. The simulation was run with 20, 40 and 80 vehicles and the avoidance measure used is ‘wait and proceed'. In the table, we can observe the relation between the number of deadlocks formed due to the number of vehicles and also due to the traffic effects. It is noted that the number of deadlocks formed varies approximately linearly with the number of vehicles in the network. This shows that for this AGVS layout, the cause of deadlock is not entirely because of the presence of more vehicles. Also, it is to be noted that the number of ships served reduces as the AGV’s are reduced. This shows that any attempt to prevent deadlock formation by


Chapter 6

57


reducing the number of vehicles will not be worthwhile. Hence to improve service rate, more vehicles have to be used. Number of vehicles

Number of deadlocks predicted

Number of ships served

Deadlock formation rate

20

42

46

0.91

40

137

77

1.779

80

204

108

1.88

Table 6.2.1: Deadlock formation with regard to the number of vehicles

The table 6.2.1 also shows the deadlock formation rate, which is the ratio of the number of deadlocks predicted to the number of ships served. This is a measure of the deadlock formation due to the traffic effects. As the number of vehicles is increased, the network becomes more congested and more deadlocks tend to be formed. But it is to be noted that the deadlock formation rate when 80 vehicles are used is only slightly higher than when 40 vehicles are used. This indicates that most of the deadlocks are formed of smaller cycles. 25 Number of Deadlocks Number of Ships

Number of deadlocks / Ships

20

15

10

5

0

0

1

2

3

4 Days

5

6

7

8

Figure 6.2.4: Deadlocks predicted in a 7-day period

Figure 6.2.4 is a bar chart showing the number of deadlocks formed in a 7-day period. The result is obtained by running the simulation with 80 vehicles. We note that this result corroborates the earlier result that the deadlock formation rate is 1.9. When 80 vehicles


Chapter 6


58

are used, the number of ships served in a day is 10 and the average number of deadlocks predicted in a day is 19.

The routing used in the simulation is obtained form AutoMod. AutoMod has a static routing policy and does not take congestion effects into consideration. If a routing policy as indicated in chapter 4 were used, the performance may be better. It can also be expected that when dynamic routing is used, the probability of the multi-cycle deadlock situation arising will be minimal as we restrict the congestion.

With the above results, we can claim: •

For a complicated network, deadlocks are formed irrespective of the number of vehicles used. Deadlock will not be formed if the number of vehicles is very less (say 2 or 3) but the throughput is affected when too few vehicles are used.

•

The number of deadlocks formed varies in direct proportion with the number of vehicles (when reasonable number of vehicles is considered). But, the rate of deadlock formation does not increase when more vehicles are added because most of the deadlocks are formed as small cycles.

•

To increase throughput, more vehicles need to be used but more vehicles means excessive congestion.

•

Deadlock formation depends on the amount of work and distribution of the workload. More vehicles imply more ships being served and hence more frequent deadlocks.

Hence, we can say that to improve the service rate and to prevent system stall, the deadlock prediction and avoidance strategy described in the report should definitely be part of the AGV routing system. Since PSA’s objective is to improve the service rate, it is recommended that more vehicles be used. But as seen, more vehicles mean more deadlock formation and hence, the deadlock prediction-avoidance strategy becomes an essential part of the AGVS.


Chapter 7

59

References

7 REFERENCES 1. Benjamin Zhan F. (1996). Three Fastest Shortest Path Algorithms on Real Road Networks: Data Structures and Procedures. Journal of Geographic Information and Decision Analysis, vol.1, no.1, pp. 69-82. 2. Chang, W.K., Tanchoco, J.M.A., and Koo, P.H. (1997). Deadlock Prevention in Manufacturing Systems with AGV Systems: Banker’s Algorithm Approach. Journal of Manufacturing Science and Engineering, v119, 849-854. 3. Coffman, E.G., Elphick, M.J., and Shoshani, A. (1971). System deadlocks. ACM Computing Surveys, 3(2), 67-78. 4. Goirgio Gallo, Stefano Pallottino (1988). Shortest Path Algorithms. Annals of Operations Research. J.C. Baltzer Scientific Publishing Company. 5. Gold, E. Mark. (1978). Deadlock Prediction: Easy and Difficult Cases. SIAM J. on Computing, v7, n3, 320-336. 6. Hyuenbo, Cho, Kumaran, T.K., and Richard, A.Wysk. (1995). Graph Theoretic Deadlock Detection and Resolution for Flexible Manufacturing Systems. IEEE Transactions on Robotics and Automation, v11, n3, 413-421. 7. Lee, C.C., Lin, J.T. (1995). Deadlock Prediction and Avoidance based on Petri nets for zone control automated guided vehicle systems. INT.J.PROD.RES., v33, n12, 2349-3265. 8. Ravindra K. Ahuja, Thomas L. Magnanti, James B. Orlin (1993). Network Flows: Theory, Algorithms and Applications. Prentice Hall. 9. Spyros A. Reveliotis. Conflict Resolution in AGV Systems. School of Industrial & Systems Engineering, Georgia Institute of Technology. 10. Stefano Pallottino, Maria Grazia Scutella (1998). Shortest path algorithms in transportation models: Classical and innovative aspects. University of Pisa. 11. Tom Leighton, Bruce Maggs, Satish Rao (1988). Universal packet Routing Algorithms. IEEE transactions. 12. Tom Leighton, Bruce Maggs, Andrea W. Richa (1999). Fast Algorithms for finding O(c+d) packet routing schedules. Combinatorica 19, Springer-Verlag. 13. Viswanadham N., Narahari Y., and Johnson, T.L. (1990). Deadlock prevention and deadlock avoidance in flexible manufacturing systems using Petri net models. IEEE Transactions on Robotics and Automation, 6(6), 713-723.


Chapter 7

References

60

14. Yeh, M.S., and Yeh, W.C. (1998). Deadlock Prediction and avoidance for zonecontrol AGVS. INT.J.PROD.RES, v36, n10, 2879-2889. 15. AutoMod V 9.0 Reference Manual.


Chapter 8

Appendix A

61

8 APPENDIX A 8.1

HOW VEHICLES USE LIST TO MOVE AND PICK UP LOADS

Vehicles use three lists to make decisions every time they perform a new task: work, park and vehicle. This flowchart shows where each of the three vehicle-activation list are used. The work list is searched only by a vehicle with available capacity; the park list is searched after the work list; and the vehicle list is searched each time a vehicle moves.


Chapter 8

8.2

Appendix A

62

HOW VEHICLES BEHAVE AS SCHEDULERS USING VEHICLE PROCEDURES

This flowchart shows the general flow of decisions made by a vehicle as a scheduler. This chart should give a general idea of the coordination between scheduling lists and vehicle procedures.


Chapter 8

8.3

Appendix A

63

HOW VEHICLES BEHAVE AS MOVERS USING VEHICLE PROCEDURES AND FUNCTIONS.

The following flowcharts depict the general flow of decisions made by vehicles as movers. These flowcharts represent the boxes on the scheduler flowchart that fall between the letters C and D. The boxes are labeled “Move to dest of closest load”, “Move to location of load”, and “Move to parking location”. The following flowcharts describe how the various types of vehicles accomplish those three tasks.


Chapter 9

64

Appendix B

9 APPENDIX B The following is a list of the Vehicle procedures and functions that are used in developing the simulation model.

9.1

VEHICLE PROCEDURES

In this implementation, the vehicle procedures are described:

9.1.1 Move to deliver procedure A vehicle executes a move to deliver procedure (scheduler) when: •

The vehicle has no remaining capacity or the closest onboard load’s destination is closer than any available work • The vehicle is ready to move to the destination of the closest onboard load and before: • The vehicle begins to move Immediately after completing the move to deliver procedure, the vehicle moves to the destination of the closest onboard load. Even if the vehicle is already at the destination of the next load, the move to deliver procedure is still called.

9.1.2 Move to retrieve procedure A vehicle executes a move to retrieve procedure (scheduler) when: • The vehicle claims a load to pick up next • The vehicle is ready to move to the pickup location of the new load and before: • The vehicle begins to move Immediately after completing the move to retrieve procedure, the vehicle moves to the location of the claimed load. Even if the vehicle is already at the location of the load to be retrieved, the move to retrieve procedure is called.

9.1.3 Leaving station procedure A path mover vehicle executes a leaving station procedure (mover) when: • It is ready to leave any location • It has done everything else it needs to do and before: • It begins to move


Chapter 9

Appendix B

65

The arriving at station procedure and leaving station procedure apply only to path mover systems, because only path mover vehicles can stop at unscheduled control points that are not defined as the vehicle’s destination. To make the vehicle stop at an unscheduled control point, use the ‘decelerate ok’ function. Note: The leaving station procedure is executed anytime a vehicle stops at a control point and begins moving again; if the vehicle does not stop at a control point, then the leaving station procedure is not executed for that control point. Important: You cannot use the travel action in this procedure.

9.2

VEHICLE FUNCTIONS

In this implementation, the vehicle functions used are described as follows:

9.2.1 Vehicle initialization function The vehicle initialization function (neither mover nor scheduler) is only called once by each vehicle when the vehicle is about to be initialized. The vehicle initialization function is an opportunity for the user to execute any actions that are legal in a function at the moment of initialization. The following parameter is provided in the vehicle initialization function: • theVehicle (type VehiclePtr) - points to the vehicle calling the function The return value of the vehicle initialization function is not used.

9.2.2 Decelerate ok function The decelerate ok function (mover) allows a path mover vehicle to decelerate and stop at unscheduled control points in the path to its destination. The function is called by a path mover vehicle each time it nears an intermediate control point en route to its destination; the function is called while the vehicle is still traveling, at the point at which the vehicle must begin to decelerate in order to stop at the next control point. The decelerate ok function is called only by path mover vehicles. Note: If you define the function by location, the path mover vehicle calls the function defined for the unscheduled control point at which it is considering stopping. The following parameters are provided in the decelerate ok function: • •

theVehicle (type VehiclePtr) - points to the path mover vehicle calling the function. stopLoc (type LocationPtr) - points to the unscheduled control point at which the vehicle is considering stopping.

This function only causes the vehicle to decelerate and stop at a control point other than its destination; the vehicle does not execute the vehicle decelerate ok function prior to arriving at a point where it must stop (for example, if the vehicle is arriving at a parking


Chapter 9

Appendix B

66

or delivery location, or if the vehicle must stop because it is unable to claim the next control point in its path). Return true to cause the vehicle to decelerate to a stop at the next control point, or return false to cause the vehicle to pass the next control point without stopping. If you want the vehicle to behave as it would without the function, return false. Important: If this function always returns true, the vehicle stops at each location in the path to its destination.

9.2.3 Location selection function The location selection function (mover) is called by a path mover vehicle when there is more than one control point that the vehicle can claim on the way to its destination (for example, when the vehicle arrives at a branch in a path). By default, vehicles take the shortest route to their destination; using the location selection function, you can force a vehicle to take an alternate route. The function selects from a list of subsequent control points and returns the control point to which the vehicle travels next. The location selection function is called only by path mover vehicles. Important: The location selection function is called each time a vehicle can choose between multiple control points in its route, even if one of the points is the vehicle's destination control point. Be careful not to return a different location when the vehicle is attempting to claim its final control point, or the vehicle may never reach its destination. The following parameters are provided in the location selection function: • theVehicle (type VehiclePtr) - points to the path mover vehicle that is being routed. • theLocList (type LocationList) - a list of control points subsequent to the most recently claimed location. The first control point in the list is the closest (default) control point in the shortest route to the vehicle’s destination; the rest of the list is not sorted. • curLoc (type LocationPtr) - points to the vehicle’s most recently claimed control point. • destLoc (type LocationPtr) - points to the vehicle’s destination control point. The return value of the location selection function is one of the control points in theLocList, which is the next location to which the vehicle travels on the way to its destination. Return null if you want the vehicle to take the default (shortest) route to its destination.

9.2.4 Park ok function The park ok function (scheduler) is called by a vehicle each time it finds a potential parking location in a park list; the function is used to accept or reject the parking location that is found. The following parameters are provided in the park ok function:


Chapter 9 • •

Appendix B

67

theVehicle (type VehiclePtr) - points to the vehicle calling the function parkLoc (type LocationPtr) - points to the parking location

Return true to accept the parking location that is found, or return false to skip to the next location in the park list. If you want the vehicle to behave as it would without the function, return true. Important: If this function always returns false, vehicles never park in the system. In implementing the one-zone step deadlock prediction algorithm, the vehicle’s procedures and functions defined in AutoMod software are used.

9.2.5 Passing station function The passing station function (mover) is called by a path mover vehicle each time it reaches a control point; the function is called whether or not the vehicle stops at that control point. The passing station function is called only by path mover vehicles. The passing station function provides an opportunity to execute actions that are legal in a function. The following parameters are provided in the passing station function: • theVehicle (type VehiclePtr) - points to the vehicle calling the function. • stopLoc (type LocationPtr) - points to the current control point. The return value of the passing station function is not used. In the following, the implementation of simulating a simplified version of the workload in the port and the one-zone step deadlock prediction and avoidance (proceed and wait) algorithm is explained. The simulation of the workload is done using the process system mentioned earlier. The one-zone step deadlock prediction and avoidance algorithm is implemented using vehicle scheduling i.e. vehicle procedures and function.


Chapter 10

68

Appendix C

10 APPENDIX C 1

#1

3

2 #2 4

#1

5 #2 #1

6

10

9

#2 #4

10

11

Deadlock predicted or blocked by a vehicle at the next node Deadlock not predicted or blocked by a vehicle at the next node

#3

Vi not equal to Vj

#4

Vi equal to Vj

#3 7

8 Figure 10.0.1: Flowchart for the proposed two-zone step deadlock prediction algorithm. See below for the definition of the numbers.

A proposed algorithm for the two-zone step prediction is shown in figure 10.0.1. Let S be the location of all the vehicles and W be an ordered list according to ascending time taken to reach the next zone. Let T be a waiting list that consists of all the vehicles waiting for an event to happen. The definition of the numbers in figure 10.0.1 is as follows:


Chapter 10

Appendix C

69

1. Extract the next location node of the selected vehicle (say Vi). The vehicle is selected based on the fact that the vehicle has entered into a new zone and a prediction must be done on its next node and next 2 nodes. 2. Check whether the vehicle is in a deadlock or is blocked by a vehicle at its next node location. This is done using the one zone step deadlock prediction algorithm given previously. 3. Return that there is either a deadlock prediction in the next zone step or a vehicle is blocking its next zone location. 4. Order all the vehicles in terms of ascending time needed to transverse to the next zone. This list is placed in W. 5. Extract the first vehicle in W say Vj. 6. Using the previous deadlock prediction algorithm and the current positions of each vehicle i.e. S, test whether Vj’s next location in its route is going to have a impending deadlock or is blocked by another vehicle. 7. The vehicle’s (Vj) position will be updated in S to the next zone location of the vehicle’s routing. 8. The waiting list T is evaluated for any another available movement of the waiting vehicles. 9. Vj is added to a waiting list T. 10. Check whether Vi=Vj. 11. Return that the selected vehicle (Vi) will be in a deadlock or no deadlock in two zone steps. This algorithm is not implemented in our solution, as the computational requirement is too large to satisfy the 1.5 seconds sampling rate. The implementation of the one-zone step algorithm is discussed in detail in Chapter 5. It is done in AutoMod simulation software, taking into account the avoidance measures and a simplified model of the workload in PSA.


deadlock prediction and avoidance in an agv system - CiteSeerX

deadlock prediction and avoidance in an agv system - CiteSeerX

Suggest Documents

Deadlock prevention and deadlock avoidance in ... - ePrints@IISc

Banker's Deadlock Avoidance Algorithm for

Deadlock Avoidance Control Synthesis in ... - Eecs.umich.edu

Deadlock Avoidance in Sequential Resource Allocation Systems ...

deadlock avoidance for distributed real-time and ... - CiteSeerX

Detection, Prediction, and Avoidance of Dynamic ... - CiteSeerX

Deadlock-Avoidance Control of Multithreaded Software: An Efficient ...

Bus Deadlock Avoidance Using Reconfigurable Arbiter

Gadara: Dynamic Deadlock Avoidance for Multithreaded Programs ...

Hardware/Software Deadlock Avoidance for ... - SMARTech

Deadlock Avoidance for Streaming Computations ... - Semantic Scholar

Deadlock Avoidance Algorithm for Flexible ... - Semantic Scholar

Maximally Permissive Deadlock Avoidance for Multithreaded Computer ...

Deadlock in Operating System

Deadlock Avoidance for Sequential Resource ... - Semantic Scholar

Deadlock Detection & Deadlock Prevention of Distributed System

Obstacle Avoidance Wheelchair System - CiteSeerX

Obstacle Avoidance Wheelchair System - CiteSeerX

Gradient Field-Based Task Assignment in an AGV ... - CiteSeerX

Gradient Field-Based Task Assignment in an AGV ... - CiteSeerX

Deadlock Avoidance in Petri Nets with Uncontrollable ...

Deadlock Avoidance Policy in Mobile Wireless Sensor ... - IntechOpen

Deadlock-Avoidance in a Page-Parallel Batch Rasterizer

Dynamic Deadlock Avoidance in Systems Code Using Statically ...