Mekelweg 2 2628 CD Delft The Netherlands Phone +31 (0)15-2782889 Fax +31 (0)15-2781397 www.mtt.tudelft.nl
Specialization: Transport Engineering and Logistics Report Number: 2012.TEL.7687
Title: Development of a simulation-based tool for designing AGV-systems for hospital logistics
Author: K. Davina
Title (in Dutch): Ontwikkeling van een simulatie gebaseerd hulpmiddel voor het ontwerp van AGV systemen voor ziekenhuis logistiek
Assignment: Master Thesis
Confidential: Yes (until sept. 2012)
Initiator (university): Prof. dr. ir. Gabriel Lodewijks
Initiator (company): Ir. Jochem Wit (Deerns Raadgevende Ingenieurs B.V.) Supervisor: Ir. M.B. Duinkerken
Mekelweg 2 2628 CD Delft The Netherlands Phone +31 (0)15-2782889 Fax +31 (0)15-2781397 www.mtt.tudelft.nl
Student: K. Davina Assignment type: Thesis
Supervisor (TUD): M.B. Duinkerken Creditpoints: 36 ECTS
Supervisor (Company): J. Wit Specialization: TEL
Report Number: 2012.TEL.7687 Confidential: Yes (until 2014)
Subject: Development of a simulation-based tool for designing AGV-systems for hospital logistics
Most hospitals have a large internal transport system that is used for f.i. meals, linen, mail, waste etcetera. The use of Automated Guided Vehicles (AGVs) for this transport has been subject of study for several years. Deerns raadgevende ingenieurs bv. feels the need for a methodology that supports the design of such an AGV-system.
Your assignment is to develop a simulation-based tool that would enable the comparison of AGV systems based on number and characteristics of vehicles, lay-out and control rules. A generic model must allow the user to test different configurations and control strategies. Definition of appropriate performance indicators is required.
and reporting the research work are all part of this assignment.
The report should comply with the guidelines of the section. Details can be found on the website.
The professor,
This report is the concluding work of my studies in Transport Engineering and Logistics at the TU Delft. It is the outcome of a Master of Science thesis, which concludes the two year master curriculum. The research subject of this thesis was formulated by ir. Jochem Wit of Deerns Consulting Engineers, which can be found in appendixB, and was assigned to me in August of 2010. After a rough start in January 2011 the project rapidly took shape but took a standstill July. Followed by three months of health issues I was able to pick up the project again in the end of October and a couple of months later the project was finally finished. The result is here in front of you as the keystone of my graduation.
In reaching this goal I would like to first and foremost thank my parents for supporting me during my studies at the TU Delft. Second, I would like to thank all colleagues at Deerns for the oppor-tunity and support during my graduation project, especially Jochem Wit for his supervision and continuous dedication towards my work. Third, I would like to thank my TU Delft supervisor, Mark Duinkerken, for his time and effort. Finally, I would like to thank all my friends and family for their support during my study time.
I look towards the future with a strong believe that my studies in Delft will help me in building a good career and a fulfilling life, for which I will be ever grateful towards the TU Delft and all other people I have met whilst studying there.
One of the expenses of a hospital that does not provide added value are its logistics costs. Given the development in AGV systems the last couple of years, implementing this type of system to pick up a part of the logistics demand can result in savings. At Deerns Consulting Engineers logistics studies are performed for customers in this hospital industry. To be able to design and assess such an AGV system, the need arose to develop a tool making this possible.
The goal of this research is to develop a tool based on discrete event simulation that aids in the design and assessment of designs. In this design different control strategies must be available to the user. To ensure a good methodology for assessing such systems, key performance indicators are required. Since this type of system is specifically for hospitals some elements need to be introduced that are different from those present in existing industrial applications of AGVs. In this study battery management and elevators are the main added elements to be studied.
Adding these elements rises the following questions: does adding these elements require addi-tional or adapted control strategies? Does implementing these elements influence the simulation outcomes? Next to the questions belonging to these elements other questions need to be an-swered: which key performance indicators are important and how important are these towards the final design? Which control strategies are needed to cope with the logistics flows in a hospi-tal? These questions were used to reach the goal of this research.
In answering these questions the following steps are performed: first a conceptual model of the hospital logistics environment is created. This conceptual model provides insight in the different elements required and the outputs collected from the system. These outputs are combined into three key performance indicators: the payback time of the system in relation to its technical
lifetime, the performance of the system with respect to its minimum required performance and a performance indicator displaying the traffic congestion within the system, indirectly displaying extension possibilities of the system as well as how well the system handles peaks.
In this conceptual model the actual control is not yet specified. To gain insight in the different methods of AGV system control, the general methods are elaborated upon. With this knowledge the conceptual model is detailed into a model ready for programming.
In analyzing the logistics system, the distribution of logistics tasks during the day, having multiple peaks and low periods, calls for a different methodology with respect to dispatching. Combining a dispatching method suited for busy periods with one suited for slow periods seems logical when looking at this type of system.
Next to that implementation of the elevator and the battery as an element in the simulation were done. After this, verification and validation tests are performed to check the correctness of the different models. Finally, a test case was used to demonstrate the usefulness of the tool in the design of hospital AGV system.
The programmed tool was validated and verified and behaves as expected. It provides the user with the ability to test a range of designs with different control strategies. After analysis the user is able to pick the most suitable option from these tested designs.
Implementing the elevators is important to take average elevator times, as was used before, out of the design. Implementing these elevators enables analyzing the stochastic effect of this element on the design. For implementing the elevator some routing and dispatching algorithms need to be adapted. Next to this a claim system is implemented to avoid deadlocks. Special algorithms made specifically for usage of elevators are not necessary. Researching the effect of different elevator designs on the AGV system also needed to be done in the test case performed. Incorporating batteries in the design proved important. Especially battery capacity can have a great influence on the simulation outcomes. In a case where on average the AGV would have enough time to load the capacity was varied. In simulations average time to pick up a job decreased 9-fold, making battery management an important addition to the simulation. In the test case performed, choosing a larger battery capacity meant meeting the minimum service level, without having to use more vehicles.
Implementing more than the standard dispatching algorithms as well as combining dispatch-ing algorithms can give better results. Compared to a first in first out system, standard algo-rithms improve job pickup times by as much as 10% and combining these algoalgo-rithms improves it by 15%. Combinations made on the basis of the traffic pressure are thus desirable for this type of application.
If alternate routing algorithms are used another 7% (in the case of using an expected travel time algorithm instead of Dijkstra’s algorithm) can be won proving implementation of different control strategies is a valuable addition. This is not possible for every type of layout, as was demonstrated in the test case.
Een van de ziekenhuis uitgaven die geen toegevoegde waarde cre¨eert zijn de logistieke kosten. Gegeven de vooruitgang in AGV systemen in de laatste jaren kan de implementatie van een dergelijk systeem, om een deel van de logistiek over te nemen, resulteren in een kosten besparing. Bij Deerns Raadgevende Ingenieurs worden logistieke studies gedaan voor klanten in deze zieken-huis industrie. Om ontwerp en beoordeling van een ontwerp van een AGV systeem mogelijk te maken ontstond de noodzaak om een tool te ontwikkelen voor dit doel.
Het doel van dit onderzoek is het ontwikkelen van een tool gebaseerd op discrete event sim-ulatie om te ondersteunen bij het ontwerp en het beoordelen van dat ontwerp. Hierbij moet de gebruiker verschillende besturingsstrategie¨en aangeboden krijgen. Om een goede methodologie voor het beoordelen van zo’n systeem te cre¨eren, zijn key performance indicators noodzake-lijk. Daarnaast zijn, aangezien het systeem speciaal voor ziekenhuizen is, elementen nodig die verschillen van de elementen in huidige industri¨ele toepassingen van AGV systemen. In deze studie zullen batterij management en liften de belangrijkste toegevoegde elementen zijn om te bestuderen.
Het toevoegen van deze elementen roept de volgende vragen op: zijn additionele of gewijzigde besturingsstrategie¨en nodig bij het toevoegen van deze elementen? Veranderen de uitkomsten van de simulatie door het toevoegen van deze elementen? Daarnaast worden de volgende vragen beantwoord: welke key performance indicators zijn belangrijk en hoe belangrijk zijn ze met be-trekking tot het uiteindelijke ontwerp? Welke besturingsstrategie¨en zijn nodig voor ziekenhuis logistiek. Deze vragen zijn als leidraad gebruikt in het bereiken van het onderzoeksdoel.
Om deze vragen te kunnen beantwoorden zijn de volgende stappen gezet: eerst is er een con-ceptueel model gemaakt van de logistieke omgeving van ziekenhuizen. Dit model geeft inzicht
in welke elementen er in het AGV model moeten zitten en welke uitkomsten verzameld kunnen worden. Deze uitkomsten worden gecombineerd in drie key performance indicators: de terugver-dientijd ten opzichte van de technische levensduur, het behaalde serviceniveau ten opzichte van het minimum vereiste serviceniveau en een performance indicator over de verkeersdrukte in het systeem, waarmee iets gezegd kan worden over de uitbreidingsmogelijkheden van het systeem alsmede de verwachtte problemen tijdens piekvorming.
In dit conceptuele model zijn de daadwerkelijke besturingsstrategie¨en nog niet gespecificeerd. Om inzicht te krijgen in de verschillende besturingsmethodieken is dit deel verder uitgediept. Met de opgedane kennis is daarna een gedetailleerd model gecre¨eerd dat klaar is om geprogrammeerd te worden.
Tijdens het analyseren van het logistieke systeem werd duidelijk dat de verdeling van op-drachten gedurende een dag, met meerdere pieken en dalen, een verschillende besturingsmethod-iek vereiste. Het samenvoegen van een toewijzingsalgoritme voor drukke perioden met een algo-ritme voor rustige perioden lijkt logisch met betrekking tot dit soort systeem.
Naast het implementeren van deze algoritmes zijn de lift en batterij elementen toegevoegd aan de simulatie. Daarnaast zijn verificatie en validatie tests uitgevoerd om de correctheid van het gemaakte model te waarborgen. Ten slotte is er een test casus gebruikt om de bruikbaarheid van de tool aan te tonen bij het ontwerpen van een ziekenhuis AGV systeem.
De gemaakte tool is geverifieerd en gevalideerd en gedraagt zich zoals verwacht. De tool geeft de gebruiker de mogelijkheid een verscheidenheid aan ontwerpen te testen met verschillende besturingsstrategie¨en. Na analyse kan de gebruiker de meest geschikte optie kiezen uit deze geteste ontwerpen.
Het implementeren van het lift element is belangrijk om gemiddelde waarden, zoals eerder gebruikt, te elimineren uit het ontwerp. Het toevoegen van liften geeft de mogelijkheid het stochastische effect van dit element op het ontwerp te onderzoeken. Voor het implementeren van liften moeten sommige besturingsalgoritmes aangepast worden. Daarnaast is er een claim systeem ge¨ımplementeerd om patstellingen tussen AGVs te voorkomen. Algoritmes speciaal voor de liften zijn niet nodig. Verschillende liftstrategie¨en zijn meegenomen in de test casus.
Het toevoegen van het batterij element is belangrijk gebleken. Voornamelijk de capaciteit van de batterij kan een grote invloed hebben op de uitkomsten van een simulatie. In een casus waar
de AGV gebaseerd op gemiddelden genoeg tijd had om te laden werd de capaciteit gevarieerd. Simulaties wezen uit dat de ophaaltijd van een opdracht een factor negen konden verschillen, wat nogmaals het belang van batterij management in dit soort simulaties benadrukt. In de test casus leverde het kiezen van een andere batterij capaciteit een systeem dat wel aan het gevraagde serviceniveau kon voldoen, zonder extra AGVs in te zetten.
Het implementeren van andere algoritmes dan het meest standaard algoritme en het com-bineren van algoritmes geeft verbetering in de resultaten. In vergelijking met een algoritme op basis van aankomsttijd, zorgen andere algoritmes voor een verbetering van de ophaaltijd tot 10%, waarbij een combinatie van algoritmes een verbetering tot 15% op kan leveren. Het combineren van algoritmes die afhangen van de drukte is dus een goede keuze voor deze toepassing van AGVs.
Als het routeringsalgoritme aangepast wordt, kan er tot 7% bespaard worden op de ophaaltijd bij het gebruik van een algoritme gebaseerd op verwachtte drukte in plaats van een algoritme gebaseerd op de kortste route. Dit toont aan de implementatie van andere routeringsalgoritmes een waardevolle toevoeging is. Dit is echter niet mogelijk bij elke ziekenhuisindeling, zoals ook te zien was in de test casus.
Buffer The number of positions within a dock, multiple jobs can be positioned here, but only the first can be reached by an AGV.xi
Charging Station The place where an AGV can replenish its batteries. xi
Distributed traffic pressure algorithm Divides the number of AGVs passing per hour on waypoints over the waypoints according a formula. xi
Dock A lane within a station from which an AGV can pickup goods or where goods can be dropped off. It has a number ofBufferpositions. xi
Expected travel time algorithm Chooses a route to travel based on historical data how long it takes to travel across waypoints. xi
First available vehicle algorithm A WIDA that picks the vehicle that first became available to transport a job. xi
first come first serve algorithm A VIDA that picks the job that first requested an AGV as its job. xi
Highest remaining battery charge A WIDA that chooses the AGV with the highest remain-ing battery charge to do the job. xi
Loading and Unloading Station The place where jobs originate and end. A station has multiple loading and unloadingDocks. xi
Lowest remaining battery charge A WIDA that chooses the AGV with the lowest remaining battery charge to do the job. xi
Modified first come first serve algorithm A VIDA makes the vehicle first look for a job at the location it became available, if no job is available it performs as FCFS.xi
Nearest parking algorithm Algorithm positions the AGV at the nearest parking or charging position. xi
Nearest vehicle algorithm A WIDA that picks the vehicle nearest to its location for perform-ing a job. xi
one-way road a road that is traversable in one direction. xi,27
Parking Space The place where an AGV can park and wait while idle. xi
small road a road that is traversable in both directions, but with a maximum capacity of one AGV.xi,27,59
System Controller The system element that oversees the system, distributes jobs, holds the layout and registers performance. xi
System performance indicator A number that combines several KPIs to measure the per-formance of a design in a single number. xi
Vehicle initiated dispatching algorithm A dispatching algorithm were the vehicle makes a choice on what job to pick-up without consulting other AGVs for optimization. xi
Work-center initiated dispatching algorithm A dispatching algorithm were the worksta-tions calls AGVs to its location without consulting other workstaworksta-tions for optimization. xi
AGV Automated Guided Vehicle. xi,1
AGVS Automated Guided Vehicle System. xi,1,4,19,133,138,139
CS Charging Station. xi,27, Glossary: Charging Station
DEST Discrete Event Simulation Tool. xi,2,8,19,55,107,131,133,135,136,138,139 DTP distributed traffic pressure algorithm. xi, 108, Glossary: Distributed traffic pressure
algorithm
EL Elevator. xi,25
ETT expected travel time algorithm. xi,116, Glossary: Expected travel time algorithm
FAV first available vehicle algorithm. xi,82–84, Glossary: First available vehicle algorithm FCFS first come first serve algorithm. xi,82–84, Glossary: first come first serve algorithm
HRBC highest remaining battery charge. xi, 84, Glossary: Highest remaining battery charge
KPI key performance indicator. xi,87,125,128,134,135
LRBC lowest remaining battery charge. xi, Glossary: Lowest remaining battery charge LS Loading Station. xi,25
LUS Loading and Unloading Station. xi, Glossary: Loading and Unloading Station LUV least utilized vehicle algorithm. xi
MOD-FCFS modified first come first serve algorithm. xi,83,84, Glossary: Modified first come first serve algorithm
MROQS minimum remaining outgoing queue size. xi,82
NPA nearest parking algorithm. xi,86, Glossary: Nearest parking algorithm NV nearest vehicle algorithm. xi,82–84,127, Glossary: Nearest vehicle algorithm
PS Parking Space. xi,27, Glossary: Parking Space
SC System Controller. xi,25, Glossary: System Controller
SPI system performance indicator. xi,128–131, 134, 135, Glossary: System performance indi-cator
US Unloading Station. xi,25
V&V verification and validation. xi,89
VIDA vehicle initiated dispatching algorithm. xi,43,80,82,83,136, Glossary: Vehicle initiated dispatching algorithm
WIDA Work-center initiated dispatching algorithm. xi,43,80,82,136, Glossary: Work-center initiated dispatching algorithm
Preface i
Summary iii
Summary (Dutch) vii
Glossary xi
Acronyms xiii
List of Figures xix
List of Tables xxii
List of Listings xxiv
1 Introduction 1
2 System analysis 5
2.1 Description of the different logistic flows . . . 5
2.2 Description of the logistics process . . . 6
2.3 Methods of transport within a hospital . . . 8
2.3.1 Manual systems. . . 8
2.3.2 Discrete transport systems . . . 9
2.3.3 Continuous transport systems. . . 11
2.3.4 Design and applicability of the various systems . . . 12
2.5 Description of manual hospital logistics system elements . . . 14
2.6 System boundary, assumptions . . . 16
2.6.1 Economic feasibility . . . 16
2.6.2 Information flow into the system . . . 17
2.6.3 Interpretation of the hospital logistics timetable. . . 17
3 Conceptual model and design of the AGV system 19 3.1 AGVS elements . . . 19
3.2 Strategic versus Operational design. . . 21
3.3 Current AGV system design method . . . 22
3.4 Choice of framework for building the DEST . . . 23
3.5 System modeling . . . 23
3.6 Performance Indicators. . . 31
3.6.1 System performance indicator . . . 36
3.7 AGVS element IO . . . 39
3.7.1 General elements . . . 39
3.7.2 Infrastructure elements . . . 40
4 System control and algorithm theory 43 4.1 Optimization problems . . . 43
4.1.1 Dispatching problem . . . 43
4.1.2 Routing and scheduling . . . 47
4.1.3 Parking (and charging) problem . . . 49
4.2 Traffic control . . . 50
4.2.1 Traffic control around nodes. . . 50
4.2.2 Traffic control on one-directional paths. . . 50
4.2.3 Traffic control for small roads and elevators . . . 50
4.2.4 Traffic control for a LUS . . . 51
4.2.5 PS and CS traffic control . . . 51
4.2.6 Chains of traffic controlled elements . . . 52
5 Description and implementation of the model 55 5.1 Delphi/TOMAS programming. . . 56
5.1.1 AGVS Delphi class definitions. . . 56
5.1.2 Processes of the active elements. . . 69
5.1.3 Assumptions and limitations of the programmed model . . . 74
5.1.4 General procedures and functions. . . 75
5.2 Implemented Control Algorithms . . . 76
5.2.1 Routing algorithms. . . 77
5.2.2 Dispatching Algorithms . . . 80
5.2.3 Parking (and charging) algorithms . . . 86
5.3 Program workflow and data handling. . . 86
5.3.1 Data interaction and saving in the program . . . 87
5.3.2 Generating and interpreting program output . . . 87
6 Verification and Validation of the model 89 6.1 Conceptual Model Validation . . . 89
6.2 Computerized Model Verification . . . 90
6.2.1 Animation. . . 90
6.2.2 Comparison with mathematical models . . . 91
6.2.3 Degenerate tests . . . 95
6.2.4 Extreme condition tests . . . 97
6.2.5 Internal validity . . . 104
6.2.6 Parameter variability analysis . . . 107
6.2.7 Traces . . . 112
6.3 Operational Validation . . . 112
6.3.1 Face validity . . . 112
6.3.2 Parameter variability analysis . . . 112
6.3.3 Operational graphics . . . 116
6.4 Data Validity . . . 119
7 Test Case 121 7.1 The case: Medisch Centrum Alkmaar . . . 121
7.1.1 Assumptions . . . 122
7.3 Base requirement number of AGVs . . . 126 7.4 Analysis using the DEST . . . 126 7.4.1 Results . . . 128 7.5 Advice following from the analysis . . . 130 7.6 The usefulness of the DEST . . . 131 7.6.1 The usefulness as seen by experts . . . 131
8 Conclusions and recommendations 133
Bibliography 141
A Scientific paper 147
B The Assignment by Deerns Consulting Engineers 155
C PROPER model for the AGV system 159
D Database registration types 163
E Expert validations 165
E.1 Conceptual Model Validation . . . 165 E.2 Operational Model Validation . . . 166 E.3 Expert feedback . . . 167
2.1 The hospital system with the external and internal logistic flows . . . 7 2.2 Left an overview of a typical pneumatic system, right a typical transport carrier
for this system . . . 9 2.3 Left a typical electric track vehicle, right an application of this system in a hospital 10 2.4 Two types of AGV’s; left a bi-directional AGV, right a single direction AGV . . 11 2.5 The distribution of transports during the day in a hospital. . . 14
3.1 The PROPER model as described by Veeke . . . 24 3.2 The system as a black box. . . 24 3.3 The system defined using a PROPER model. . . 25 3.4 Further detailing of the goods flow. . . 26 3.5 Combining the goods and resources flow . . . 26 3.6 The AGV process. . . 28 3.7 The Loading Station process . . . 29 3.8 The Unloading Station process . . . 29 3.9 The System Controller process and its interactions with the other processes . . . 30 3.10 Overview of performance indicators for system analysis for a transport job. . . . 33 3.11 Overview of performance indicators for AGVs . . . 34 3.12 Overview of performance indicators for LUSs . . . 35
4.1 Multiple AGVs on each others path creating a deadlock situation . . . 52 4.2 An AGV reserves a path to make sure deadlocks will not occur . . . 53
5.2 Two ways in which roads and crossing can be modeled . . . 75 5.3 Limit the use of one way arcs - example . . . 76 5.4 Correction ratios for the distributed traffic pressure algorithm for different values
of . . . 81
6.1 Verification and Validation processes in modeling . . . 90 6.2 Simple model used for validation by comparison with mathematical models . . . 91 6.3 The average waiting time as a result of the comparison with mathematical models
simulation . . . 93 6.4 The average queue length as a result of the comparison with mathematical models
simulation . . . 94 6.5 Simple model used for degenerate validation test . . . 95 6.6 Simulation results for degenerate testing . . . 96 6.7 First model used for extreme condition tests. . . 97 6.8 Second model used for extreme condition tests . . . 98 6.9 Third model used for extreme condition tests . . . 99 6.10 Simulation results for extreme condition tests case 2: AGV drive time and the
number of jobs done . . . 100 6.11 Simulation results for extreme condition tests case 2: Elevator calling time and
the job enroute time . . . 101 6.12 Simulation results for extreme conditions test case 3 . . . 103 6.13 First model for internal validity tests . . . 104 6.14 Second model for internal validity tests. . . 105 6.15 Model for doing parameter variability analysis by changing routing algorithm . . 108 6.16 Average waiting time for pickup for case 2 of parameter variability analysis . . . 110 6.17 Number of jobs done after 24 hours for case 2 of parameter variability analysis . 111 6.18 Model used for operational parameter variability analysis . . . 113 6.19 Chart displaying the average number of AGVs on road 2 . . . 117 6.20 The average time a job has to wait to be picked up during the simulation run . . 118 6.21 A small part of the simulated day displaying the number of jobs created and
7.1 Schematic top view of the to-be-built Medical Center of Alkmaar . . . 122 7.2 Overview of the hospital layout for case 1 . . . 123 7.3 Overview of the hospital layout for case 2 . . . 124 7.4 The number of unassigned jobs in the system and the number of charging AGVs
for scenario 6 . . . 129
2.1 Overview of different pneumatic tube systems and their characteristics . . . 9 2.2 Electric track vehicle characteristics . . . 10 2.3 AGV characteristics . . . 11 2.4 Method of automation choice for all hospital transport flows. . . 12 2.5 Quantitative description of the hospital logistics process: general numbers . . . . 13 2.6 Quantitative description of the hospital logistics process: flows and distances . . 13
3.1 Bandwidth, scaling, importance ranking, fine-tuning and total weights of the three KPIs for the system performance indicator. . . 38
4.1 Overview of standard vehicle initiated dispatching algorithms . . . 44 4.2 Overview of standard work center initiated dispatching algorithms . . . 45 4.3 Overview of other well performing dispatching algorithms . . . 47
6.1 Outcomes for extreme condition tests case 3 . . . 102 6.2 Internal validity case 1: enroute and driving times . . . 106 6.3 Internal validity case 2: jobs done, elevator waiting times and batteries empty. . 107 6.4 Parameter variability analysis case 1: enroute times for different elevator and AGV
speeds . . . 109 6.5 Parameter variability analysis case 3: average number of vehicles on each road per
direction . . . 109 6.6 AGV parameters for model used for operational parameter variability analysis. . 114 6.7 Parameter operational variability analysis case1: impact of changing the
7.1 Assumptions for the elevators for the test case . . . 123 7.2 The number of carts to be transported per day for the test case . . . 125 7.3 The different scenarios simulated for the testcase . . . 127 7.4 The SPI and KPIs for the different simulation scenarios for the testcase . . . 128
D.1 Job values registration types . . . 163 D.2 Queue data registration types . . . 164 D.3 Claim data registration types . . . 164 D.4 AGV values registration types. . . 164
F.1 Assumptions done for input values for the performed test case. . . 170 F.2 All transport flows used for the test case. . . 171 F.2 All transport flows used for the test case. . . 172 F.2 All transport flows used for the test case. . . 173 F.2 All transport flows used for the test case. . . 174 F.2 All transport flows used for the test case. . . 175
5.1 Class definition of TSimulationElement . . . 56 5.2 Class definition for the TWaypoint element . . . 57 5.3 Class definition of TFlag. . . 58 5.4 Class definition for the TJob element. . . 59 5.5 Class definition for the TAGV element . . . 61 5.6 Class definition for the TNode element . . . 64 5.7 Class definition for the TArc element . . . 64 5.8 Class definition for the TParking element . . . 65 5.9 Class definition for the TCharging element. . . 65 5.10 Class definition of the TElevator element . . . 66 5.11 Class definition of the TStation element (implementation of a dock) . . . 68 5.12 Class definition of the TBigStation element (implementation of a station) . . . . 69 5.13 The AGV process. . . 72 5.14 The LUS job deliver process . . . 73 5.15 The LUS job accept process . . . 73 5.16 The Job Generator process for creating jobs . . . 74 5.17 The Job Generator process for introducing jobs into the AGV system . . . 74 5.18 The job dispatcher process. . . 74 5.19 Dijkstra’s algorithm in pseudo-code. . . 77 5.20 The A* algorithm as implemented in pseudo-code. . . 79 5.21 The FCFS/FAV dispatching algorithm in pseudo-code . . . 83 5.22 The MOD-FCFS/FAV dispatching algorithm in pseudo-code. . . 83 5.23 The MOD-FCFS/NV dispatching algorithm in pseudo-code . . . 84
5.24 The MOD-FCFS/HRBC dispatching algorithm in pseudo-code . . . 84 5.25 The STT/NV dispatching algorithm in pseudo-code . . . 85
Introduction
Hospitals in the Netherlands have been struggling with budget cuts that started a couple of years ago[ANP11, DeT10], which requires them to search for new savings opportunities. One of the hospital expenses that is required for operation, but does not produce any added value, is its logistics expenses. For a big hospital (500k hospital visits or more) the number of movements performed by logistics personnel with goods to transport are around 2000 per day on a busy day [Dav11]. This process requires personnel and brings subsequent (non value adding) costs. Previous research and projects performed by Deerns Consulting Engineers showed saving oppor-tunities in this part of hospital expenses, from which this research was initiated. One possible way of cutting costs is to replace the logistics personnel by an automated system. Different auto-mated systems are used for logistics purposes, which all have their specific advantages in different applications. The advances made in Automated Guided Vehicle (AGV) technology in the last couple of years creates opportunities for applying such an AGV System (AGVS) in a hospital [Ozk09]. The payback time of this type of system is reported to be as low as 2.64 years [Swi05], but depends heavily on the hospital it is applied to and not all logistic flows in hospitals can be automated using an AGVS [Dav11]. The applicability of such a specific system on hospital logistics is researched in chapter2.
In designing and evaluating the feasibility of such a system the need arose at Deerns Con-sulting Engineers to develop a tool/methodology for modeling an AGVS independent of the (future) system supplier [Wit11] to examine the behavior and efficiency, and assist in its sizing
and cost estimates. Due to the combination of stochastic and planned transports in hospitals, together with the stochastic behavior of personnel and patients, exact methods are impractical and discrete event simulation is necessary [JJS+07].
The objective of this type of study is to minimize the size of the AGV fleet, while satisfying certain service levels for the system (for instance, delivering all jobs within the given time frame). This is important because the size of the AGV fleet is a good indicator of the overall system costs. The minimum bound of the fleet size can be approached analytically, but the final fleet size has to be determined using simulation [GHS98], in our case, using aDiscrete Event Simulation Tool
(DEST).
The goal of this research is:
Develop aDESTthat would enable a by-user comparison of automated guided vehicle systems for hospital logistics purposes on different configurations and control strategies to substantiate decisions during the design process. To that end, definition of appropriate performance indicators
is required. From this goal the main research questions can be defined:
1. Is it possible to develop a discrete event simulation tool to simulate the logistics environ-ment within a hospital with respect to transports to be carried out by AGVs?
2. Which performance indicators are required to assess the feasibility and performance of such a system?
3. How important are these performance indicators towards the assessment of the total de-signed AGV system?
4. Which control strategies are required to test such a system?
5. Which control strategies are required to use such a tool in the design process? 6. Which elements need to be included in theDESTto cover this specific application?
The necessity for the ability to compare different configurations stems from two things. First, the diversity in systems sold by manufacturers; different manufacturers will provide AGVs with, for instance, different speeds and battery capacities. Second, the possibility for strategic design; how many AGVs are required, where to put charging stations, how large a buffer should be at a
drop-off point, where to create parking spaces, etc.
Next to the strategic design, operational design must be done: different control strategies should be comparable. In AGVSs 3 optimization problems related to control of AGVs can be identified: the dispatching problem, the routing problem (and as an extension to this problem, the scheduling problem) and the parking problem [Vis06]. The dispatching problem is concerned with which AGV to assign to which transport. The routing problem is concerned with the route the AGV should travel to get from one point to another. The scheduling problem is an extension to the routing problem in that it is concerned with the precise times the AGVs should drive on a certain part of its route to avoid congestion and deadlocks. The parking problem is concerned with where to park an AGV when there are no more transports available.
The way scheduling is used in current (industrial) AGV systems is however not applicable in hospital based systems. For scheduling one needs to know where an AGV is expected at which moment in time. Because of the presence of elevators in a hospital that are shared with patients, visitors and staff, the position of AGVs cannot be calculated beforehand.
In literature a large number of algorithms are described which were developed to solve the 3 optimization problems. These algorithms provide solutions for (mainly) fictitious cases in which equipment failures, temporarily blocked paths, battery management and transportation job pri-ority are (almost) always ignored [Vis06,LAdK06]. Because of this, the algorithms provided in literature perform very good, but lack practical application for hospital purposes.
To test the applicability of these algorithms on a more realistic system, battery management and elevators are included in the simulation. The influence of these inclusions raise the following additional research questions:
7. Does implementing battery management influence the simulation outcomes?
8. Are additional control strategies required in order to implement battery management? 9. Does implementing elevators influence the simulation outcomes?
10. Are additional control strategies required in order to implement elevators?
Finding the answers to these research questions will give the correct framework for reaching the specified research goal and proving the reliability and usability of the tool to be created.
This report is built-up in the following way: first, the hospital logistics process is described in chapter 2. From this analysis a conceptual model is created for the AGVS in chapter 3. Before this conceptual model can be worked out into a computerized model, the theory behind the control algoritms required for an AGVS is elaborated upon in chapter4. After the theory and the conceptual model are known, the description and implementation of the final model is described in chapter5. To make sure this model is implemented correctly and the choices made for different algorithms can be substantiated, verification and validation tests are performed in chapter6. In chapter 7 a test case is included to show the working of the created tool. In the last chapter, chapter 8, a reflection is made on the research questions stated: it provides the conclusions and recommendations of this study.
System analysis
As a first step in this research the hospital logistics process as it is present in hospitals is analyzed. This is first done by describing the different types of flows present in a hospital in section 2.1. After this, the process needed to transport these flows in section 2.2. In section 2.3 the methods of transport used to move the different items trough a hospital are described. To give an estimation of the size of the flows in a hospital and the distribution of these flows during the day, a quantitative estimation is made in section 2.4. The logistics process as it is present in most hospitals is further analyzed in section 2.5, where the specific elements needed in the process are described. In the final section, section2.6, the boundary of the system is defined as well as the assumptions made to be able to automate this system.
2.1
Description of the different logistic flows
The DEST is built for implementing an AGVS in a hospital logistics process. To ensure the DEST matches with this process the workings and characteristics of the hospital process must be analyzed. A lot of these characteristics can be found in [Dav11]. The hospital logistics process can be summarized as depicted in figure 2.1. In this figure the system boundary is indicated with the red border; everything inside the boundary is the part of the logistics process that can be handled with AGVs. All green arrows indicate input and output of tangible goods, the blue arrows indicate non-tangible (information) streams.
The big logistic flows present in a hospital are [Dav11]: • Food, beverages and service
• Linen and uniforms • Beds
• Waste
• Patient dossiers and mail • Specimens
• Drugs and medication
• Consumables and sterile goods
All these flows also include return flows of empty carts, which is normally as big as the flows themselves. Next to these some smaller flows and non-automatable (by AGVs) flows are present: hazardous materials, medical equipment and people flows (patients, staff, visitors). Most of the big flows are regulated in a hospital by a schedule; for each flow, each movement is scheduled for transport for a specific time of the day. Some of the transports are done on call. All scheduled transports are summarized in tables and display the type of flow, number of carts, time of departure or latest arrival, origin and destination. This is further elaborated in section2.5.
2.2
Description of the logistics process
The different jobs that have to be transported in a hospital can be divided according to different principles; goods that are transported according to a schedule and goods that are transported on-call, goods that have a short time-limit as opposed to a longer time horizon. The easiest division for explanation of the system is to start with the scheduled versus the non-scheduled transports.
An example of scheduled transport in a hospital are meals that have to be transported to the different departments every day at a set time, the logistics department knows this from schedule and has personnel on stand-by to provide this service. If meals are a little earlier or later a call is placed from the kitchen to the logistics department to make sure personnel is ready at the right moment. Next to these jobs scheduled jobs with a lesser constraint are present; waste might have to be collected every morning between 10 and 12. The logistics department has some wiggling room in this case to fit these jobs within the rest of their schedule.
Hospital
Logistics department
(Logistics / Waste / Maintenance / Cleaning / Mail)
OR/ER
Labs
Daycare
Kitchen
Patients / Visitors / Staff Policlinics Restaurant Apothecary Goods Goods People People External service providers Clients Offices Information streams System boundary Tangible external flows Tangible internal flows Waste &
return flows
In parallel with these jobs are the non-scheduled jobs: departments place a call to deliver or pick-up some goods. The logistics department will fit these jobs in their schedule depending on the priority and time constraint of the job. If all personnel is busy or unable to answer the call other (nursing) personnel might do the work themselves.
The transports in a hospital go from roughly four places to all departments: a logistics point, the kitchen, the apothecary and a laboratory. The logistics point is where goods from outside the hospital are received, goods are stored and return flows (dirty linen, waste, some empty carts) are collected. The kitchen dispatches the food for the patients and receives its raw materials from the logistics point. The apothecary dispatches medicines and the laboratory does analysis of, e.g., blood samples. These four points may be combined or split up into more locations, but this depends on available space, location with respect to patients, and more factors.
2.3
Methods of transport within a hospital
For the transportation of goods different systems can be used in a hospital: a manual system, a discrete system or a continuous system. The manual system is described in subsection2.3.1. The different types of discrete system available for hospitals are described in subsection2.3.2. The types of continuous systems and the applicability of these systems for hospitals is described in subsection2.3.3. To see which of these systems can be used for which of the flows, a comparison between these systems is made in subsection2.3.4. Also the flows that theDESTshould be able to model are presented.
2.3.1
Manual systems
This is the method of transport used in hospitals that do not use automation for the distribution of goods. People push carts and containers around, which can be done in a highly flexible way; people can adapt to the situation at hand and are able to speed up when some transport requires this. Hospitals also make use of electric carts which are driven by a person to transport multiple containers at once (on average 2 containers, 3 containers is the maximum allowed length). People can also handle different transports in a different way depending on the type of cargo. Disadvantages of doing manual transport include sickness and less reliability; people might take
longer breaks or break with hospital policies which may result in delayed deliveries. Personnel going around the hospital also lose a lot of time socializing while doing their job, running into different people all day long. These factors combined decrease their efficiency by about 30%. Because manual work includes errors, damage is done by logistics personnel; this accumulates up to 2% on top of logistics personnel costs.
2.3.2
Discrete transport systems
Pneumatic tube system (PTS)
Pneumatic tube systems can be used for quick transport across hospitals for low weight trans-ports. In figure2.2a typical set-up of a tube system and a transport tube are shown. In table2.1 some key characteristics for different tube systems can be found. According to the manufacturers the systems are primarily suited for transport of small items, like blood samples and dossiers ([Aer05], [Swi09a]).
Figure 2.2: Left an overview of a typical pneumatic system, right a typical transport carrier for this system [Aer05]
Table 2.1: Overview of different pneumatic tube systems and their characteristics Supplier Speed Transport volume Transport weight
[m/s] [dm3] [kg]
Aerocom [Aer05] 6-8 20 28
Kelly [Kel03] 7.6 9 na
Electric track vehicles (ETV)
Electric track vehicles are small vehicles attached to a live rail that are able to transport a small bin. They are suited for transport of items with a bigger volume than those transported with a pneumatic tube system. Typical system characteristics can be found in table2.2. An example of such a system can be found in figure2.3. ETV systems provide more flexibility in the type of bin placed on the cart when compared to pneumatic tube systems. They can also function upside down as shown in figure2.3, which is an advantage over AGV’s.
Figure 2.3: Left a typical electric track vehicle, right an application of this system in a hospital [Swi08]
Table 2.2: Electric track vehicle characteristics Electric track vehicle
Speed [m/s] 1
Transport weight [kg] 10
Transport volume [dm3] 45
Automated guided vehicles (AGV)
Automated guided vehicles can drive around in all walking areas as long as the floor is leveled. The AGV’s can take a large payload in comparison with the other systems. The disadvantage is the speed of the vehicles and the amount of space they take up. They also cannot be separated from people without giving up a huge area. Typical characteristics for hospital AGV’s can be found in2.3. The volume that can be transported depends on the dimensions of the infrastructure present and not on the system itself. Pictures of two types of AGV’s can be found in figure2.4.
Figure 2.4: Two types of AGV’s; left a bi-directional AGV [Swi07], right a single direction AGV [JBT]
Table 2.3: AGV characteristics
Supplier Speed Transport weight
[m/s] [kg]
Egemin [Ege] 2 1500
JBT [JBT] 1.6 680
Swisslog [Swi09b] 1.5 450
2.3.3
Continuous transport systems
Another possibility to move goods from one place to another is to make use of a continuous transport system, like belt conveyors or chain conveyors. In these systems the belt or chain continuously moves in a specified direction and goods can be put on the belt or chain to move in this direction. This type of transport system gives a very high throughput rate compared to discrete transport systems, but also requires a big investment. The systems also use up a lot of space or require a lot of changes to the infrastructure of the building.
Looking at the diversity of the transports, especially when concerned the spread in origin and destination of the different goods, installing a continuous transport system is not a feasible idea; the transport flows from one origin to one destination are not continuous, goods go in and out at discrete intervals making this type of system capacity wise over-dimensioned for hospital purposes.
Table 2.4: Method of automation choice for all hospital transport flows
Process PTS ETV AGV None
Patients X
Staff X
Visitors X
Beds Empty X
Food, beverages and service X
Linen and uniforms X
Waste X
Hazardous materials X
Patient dossiers and mail X X
Specimens X X
Drugs X X X
Consumables X X
Medical equipment X
Empty carts and bins X X
2.3.4
Design and applicability of the various systems
From the three types of systems described above, the manual system as used nowadays in most hospitals as well as the discrete system are the two most suited for hospital flows. This is primarily because of the discrete behavior of the flows [Dav11]. To get a better overview of which discrete transport system is best used for which hospital flow a summary is made in table 2.4. From the table one can see all automatable flows can be handled using a combination of a pneumatic tube system and an AGV system. Software to aid in the design of a PTS was created by Freek Muurling [Muu08]. For an ETV system a big space has to be reserved in a hospital; the system has a cross section close to 1 square meter for a single direction. This type of system might prove useful to move certain goods too big for a PTS and too small to fully use the AGV system. The AGV system can be used for a lot of transport flows and supplements the PTS in a good way. For the design of this system a tool is created which is further elaborated in the following chapters.
2.4
Quantitative description of a hospital logistics process
To further clarify the transport processes within a hospital, transport volumes and distances collected by Deerns Consulting Engineers for a hospital with an AGV system are presented in this section. The numbers shown here represent the number of carts/loads an AGV would pick up; this is also the type of load an employee would be able to transport on his own manually. In table2.5an overview can be found of the number of people the hospital serves to. The hospitalTable 2.5: Quantitative description of the hospital logistics process: general numbers
Description Value Unit
Target population 635,000 people
Number of licensed beds 1120 beds
Polyclinical visits 550,000 per year
Day treatment patients 66,000 per year
Clinical treatments 35,500 per year
Average clinical stay 5.5 days
Personnel on payroll 2800 FTE
Specialists 213 FTE
Table 2.6: Quantitative description of the hospital logistics process: flows and distances
Type of load Number of loads Distance (Km)
Nutrition 150 35.0
Snacks & beverages 45 10.5
Linen 81 12.5
Waste 52 7.2
Drugs 32 3.0
Consumables 60 8.7
Hazardous waste 4 0.55
Non scheduled transports 23 3.4
Total 447 80 .85
concerned uses three types of transport systems: a PTS, an ETV system and an AGV system. The origins for the loads for the AGVs in this hospital are the kitchen for nutrition, snacks and beverages, the apothecary for drugs and the logistics point for the other goods. The number of loads transported and the single distance covered by these loads are summarized in table2.6.
If one assumes the AGV to deliver a load, drive back empty, drive towards the load again at a later point to pick it up and deliver it back to its starting point, the AGV would cover four times the distance mentioned here. This would result in a travelled distance of 80.85 ∗ 4 = 323.4 kilometer per day. If a logistics schedule would be made allowing no travel without load, still a distance of 80.85 ∗ 2 = 161.7 kilometers should be covered every day. So if transport is done manually without help of any electro vehicles or by AGV this type of hospital would require between 162 and 323 kilometers of transport every day. If electro vehicles are used by personnel with an average transport capacity of two loads, this will drop to 81 to 162 kilometers per day. In this hospital, which makes use of electro vehicles, this results in a workload of 14 FTE if average
absenteeism and productivity degradation (30%, section2.3.1) are included.
For the same hospital also an analysis was made of the distribution of the transport jobs over the day, which can be found in figure2.5. This is a transport schedule that was leveled as much as possible to even the load on the AGV system. After leveling there are still a number of very clear peaks during the day as well as some moments where not all AGVs are required to transport all jobs. For a hospital using a manual way of transportation the change during the day will be even heavier [Dav11].
6 8 10 12 14 16 18 20 22 0 10 20 30 40 50 60 Time of day Num b er of transp orts
Number of transports per half hour
Figure 2.5: The distribution of transports during the day in the Jeroen Bosch Hospital. The data is from a previous study performed by Deerns Consulting Engineers
2.5
Description of manual hospital logistics system
ele-ments
In the current system some essential elements are present in the system. These elements exist in a similar fashion for the automated system. The elements described here are the (transport)
job, logistic staff and (temporary) storage areas. All these elements are briefly described in this section.
Job
A job, or transport job, is an assignment to move a certain cart or bin from one location to another. This job has a time constraint that can vary from a few dozen minutes, for meals for instance, up to days, for certain consumables, trash bins, etcetera. All job properties available in a non-automized system are:
Job Property-1: origin; Job Property-2: destination; Job Property-3: time constraint;
Job Property-4: job priority: if two jobs can both make it easily within the time window, someone from the logistics department will make a choice which job should be given priority, which is normally done unconsciously;
Job Property-5: job handling: a job might has to be handled carefully, depending on the contents or the way it is packed.
Job volumes are estimated for most hospitals as the number of jobs expected per hour of the day. Some jobs are fully defined on beforehand.
Storage Areas
These areas make it possible for the logistics and hospital staff to temporarily store carts. Prop-erties of this system element are:
Storage Area Property-1: location: the location of the station in the hospital and its con-nection to the infrastructure;
Storage Area Property-2: size: the number of carts that can be stored. It doesn’t matter in which order these are stored since staff can rearrange them and pick up the right cart;
Logistics Staff
This is the element in a non automated system that will be replaced by an AGV in an automated system. Properties of the logistics staff are:
Logistics Staff Property-1: number of FTE’s available; Logistics Staff Property-2: work hours;
Logistics Staff Property-3: costs per FTE, which is needed for comparison with an AGVS; Logistics Staff Property-4: logistics staff can make choices depending on the current
situa-tion and can solve problems: flexible.
If the system is automated, these elements might be replaced by automated elements. Which system elements are needed is researched in the conceptual modeling phase, chapter3, and these are further detailed in section3.1.
2.6
System boundary, assumptions
For automating the system, a choice has to be made which system parts can or may be au-tomized. In this system, goods to be transported are assumed to be placed in a designated area and retrieved from a designated area at their destination. The transport between those two areas is now done manually and automatization is in this research limited to the processes involved getting a transport load from a designated origin area to a designated destination area.
First the assumptions done to do an economic feasibility study for a system are presented. Second, assumptions concerning the way information is introduced into the system are illustrated. The last section describes the way the hospital logistics timetable is interpreted for calculations.
2.6.1
Economic feasibility
In order to assess the feasibility of automating a logistics environment, assumptions have to be made concerning the present system costs. This concerns the price of personnel, the number of personnel required and the price of investing. The following assumptions are done in this research for calculations done concerning economic feasibility:
• one FTE amounts to 7.5 ∗ 5 = 37.5 working hours per week;
• 30% of the working hours cannot be used because of absenteeism, socializing and other efficiency decreasing factors;
• personnel walks at 5km/h;
• if electro vehicles are used, one employee can move 2 containers at once; • electro vehicles move at 5km/h;
• 2% should be added to the logistics personnel costs for repairing damages caused by un-controlled movement of carts with electro vehicles;
• electro vehicles cost e10,000 a piece;
• the costs of maintenance on vehicles is 4% of the investment; • the interest rate is 5%;
• the vehicles are depreciated in 5 years; • one square meter hospital costs e1400.
These numbers will be compared with the price of an automated system to assess the feasi-bility of such a system.
2.6.2
Information flow into the system
When a cart is at its designated origin area, it will be entered into the system either manually or through an RFID tag/barcode attached to the load. This information entering is assumed to be perfect: all carts have the right destination. Research concerning wrongly entered loads is not done.
The hospital has a timetable which can be used to anticipate on future jobs to be done. The times in this timetable are always an indication and do not mean that a transport job will be at the location at the time stated in the timetable. How times in the timetable are interpreted is further elaborated in the next section,2.6.3.
2.6.3
Interpretation of the hospital logistics timetable
If one looks at the hospital logistics timetable it has fixed times for certain flows. In practice this will never be the case, a load will not be put at the designated area at exactly that time. Next to that schedules have entries stating averages like 10 transports between ten and eleven in the morning. The interpretation of these timetable entries is as follows:
• Exact times in the schedule are interpreted as an average value for the arrival time of the load which is assumed normally distributed with an nσ interval ranging from −x . . . x minutes;
• If stated that n transports take place during m hour(s), the transports are distributed over the hour on an average basis or using an exponential distribution. If the distribution is used, n + 2 samples will be drawn. The two extra samples are to model the time before the first load and after the last load. The time sum of these samples is scaled to m hour(s); The different types of arrival times for flows stated in a timetable are assumed to be in the following set. For all these arrivals the number of jobs that arrive at the stated time can be anything.
Single
A precisely stated single arrival time; Normal
A single arrival time normally distributed; Static Interval
A number of arrival times with a static interval between them. A start and end time are provided;
Exponential
A single arrival time exponentially distributed; Random
A single arrival time randomly distributed in a specified time window; N jobs in M hours static
A number of N jobs that have to enter the system with a static interval to fit the jobs in a given time window;
N jobs in M hours exponential
A number of N jobs that have to enter the system with a exponential interval to fit the jobs in the given time window.
Conceptual model and design of
the AGV system
In this chapter a conceptual model of a hospital-based AGVS is created. In section 3.1 the elements in an AGVS are presented. After this, in section 3.2, the two levels of design found in these types of systems, strategic and operational design, are explained. This is followed by section 3.3 explaining the currentAGVS design method and the shortcomings of this method. Given the requirements and the shortcomings a framework has to be chosen for the development of theDEST, this is done in section3.4. After this, in section3.5, a hospital AGVSis modeled extensively to find all required steps in the logistics process. When this modeling is completed, performance indicators can be drawn up to view the performance of the different elements and element processes. This is done in section 3.6. Finally, in section 3.7, a comprehensive list is provided with all the required element input and outputs. This list is a summary of all properties and outputs that will provide the required performance indicators as well as a possibility to create a computerized model similar to the conceptual model.
3.1
AGVS elements
Introducing an AGV system requires introduction of elements that are not present in the system as currently exists. The new elements required are summed up in this section along with their advantages and disadvantages compared to a manual system. It also states whether they replace
a comparable part of the manual system or were non-existent in the manual system.
AGV (AGV)
The AGV is the system element that replaces the people in the logistics department that walk from A to B. AGVs work more hours during a day and work more efficient. An AGV can also be used to move dangerous goods around safely. Once bought they only cost maintenance and power. The disadvantages of the AGV include investment costs and a less flexible approach to changing situations.
Loading and Unloading station (LUS)
A place where AGVs put and pick-up a load. In the manual system this was designated as a storage area. This area might also include mechanical and electrical systems not found in the manual system to support the AGV system. Compared to manual systems these stations might, depending on the amount of mechanical and electrical systems installed, have a higher failure rate and require more investment. A station will have docks for loading jobs onto an AGV, for unloading jobs from an AGV and for doing one of both, so-called dynamic docks, depending on the demand.
Elevator (EL)
So far the elevator was not really mentioned as an integral part of the system. It is an element required in both manual and automated systems to transport goods and people from one floor to another. In the manual case the elevator is called upon when necessary and detached from the system. In the automated case, the AGV system has an integral connection with the elevator system to call upon the elevator when needed.
System Controller (SC)
The computer type of system, keeps track of all jobs and assigns AGVs to jobs. This element might be a person in the old system, or a notification board or spreadsheet. It depends on the way the current processes are designed.
Charging station (CS)
Needed for the AGVs for recharging its batteries. In the manual system this type of element does not exist. Compared to the manual system it requires more space and an investment in a recharging system.
Parking space (PS)
If an AGV is not required, it has to park somewhere. This might be in the middle of a corridor or at a CS or LUS, but it might also have a dedicated parking space. Parking spaces cost extra room and thus extra investment. This is a system element not present in a manual system.
Path (P)
Needed as a guide for the AGV, the AGV can drive along a path in one direction. The corridors also existed in the old system, but can be used in a flexible way by the logistics personnel. If a corridor can be used in two directions, this will be modeled by two paths to ensure a consistent modeling approach. Physically nothing changes, this element is just used for modeling.
Node (N)
Needed to start and end paths and connect other elements like a PS, can be viewed as crossings in the old system. Again, if used for modeling, rigor is required for correct modeling. In component terms nothing changes compared to the old system, this element is just used for modeling.
The element Job is still present in the automated system as it is in the manual system.
3.2
Strategic versus Operational design
When design of an AGVS is concerned two aggregation levels can be distinguished: strategic design and operational design. Strategic design is the higher aggregation level; it concerns the number of AGVs required, the number and size of loading and unloading stations, the number of charging points and parking locations, the number of elevators. One can choose enough of these for a given system to make the AGVS work. A first estimation of these numbers can be done with the current design system used and these numbers can be improved using a simulation based on simplified rules. These numbers can then be used to make a rough estimate on the return on investment of an AGVS.
To further improve the system operational design has to be performed wherein more in-depth questions can be answered: where should parking and charging stations be located, what is the
best time to charge, which AGV should pick up which job (dispatching), which alternative routes can an AGV take to avoid congestion, how many docks should loading and unloading stations have and what buffer capacity should these have, etcetera. Answering these questions with simulation can further improve the system, reduce costs, improve service level and/or increase redundancy. The difference between the two aggregation levels is also present in the performance indicators used (section3.6) and the building blocks for the simulation program (section5.1).
3.3
Current AGV system design method
At Deerns Consulting Engineers the current method of AGVS design is using a spreadsheet. The following steps are followed in this process:
1: collect all expected jobs for a day separated per hour; 2: calculate driving distance for all station combinations;
3: assume driving distance towards a job is equal to the job driving distance; 4: assume a percentage of jobs that do not require driving towards them; 5: calculate distance/time to drive for each hour of the day;
6: calculate the charging time required to perform these jobs in an hour; 7: calculate how many AGVs are needed to cope with the required time.
In this approach the following influences are not considered:
• the stochastic behavior of the process; • the position of charging and parking stations; • influence of elevator availability;
• breakdowns in the system;
• level of sophistication of the routing and dispatching system.
To make sure a better calculation is done when implementing an AGV system, the influences ignored should be addressed. This cannot be done in a spreadsheet, therefore another tool is required. This tool is further elaborated in the next section, section3.4.
3.4
Choice of framework for building the DEST
Addressing the issues in the current simulation method can be done using discrete event simula-tion. All the ignored influences can be researched if a simulation is created within the TOMAS environment. TOMAS is an object-oriented discrete event simulation package for the Embar-cadero Delphi programming language. Since the hospital logistics system can be well described in a object-oriented manner, TOMAS is a good choice for this type of simulation [VO00]. Next to that TOMAS is an open framework, tested, verified and validated by H.P.M. Veeke Phd. [Vee03]. Before this type of system can be programmed in TOMAS it has to be analyzed to get a better overview of the system, this will be done in the next section, section3.5.
3.5
System modeling
In order to create the right simulation, first the system has to be modeled in the right way. For this purpose the method of [Vee03], the PROPER model (PROcess PERformance model) for a logistic system, is used. This model ensures a good conceptual and structured design of the system, but describes it in an informal way. The PROPER model also provides a way to get a fast and good insight into the system and better communication means during the development of the program. The PROPER model is closely related to the ’Delft Systems Approach’ of In ’t Veld [VOL08], which can be used as a good start for the modeling of the system. The PROPER model describes the system using the schematic shown in figure3.1.
To model the system one should start at the highest abstraction level using a black box approach. The system modeled as a black box can be found in figure 3.2. One can model this using the PROPER model as displayed in figure 3.3 to gain some more insight into the system. One can see a clear need from the environment, the hospital in this case, to have goods transported from one location to another. To make sure this happens according to plan the performance of the system is measured using performance indicators. Which indicators to use is described in section3.6. One can also clearly see the control system required, this is further elaborated in chapter4(theory) and section5.2(implementation).
From the PROPER model of the system one can see the flows and boxes can still be further defined. Using a functional approach the flow of ’goods to be transported’ to ’transported goods’ can be further described. This is depicted in figure 3.4. It still shows an abstract version of
Environment
Need Performance Order Handled Order Product Delivered Product Resource Used Resource Requirements ResultsControl
Transform
Figure 3.1: The PROPER model as described by Veeke [Vee03]
Move Goods
Goods at origin Goods at destination
Environment
Requirements ResultsControl
Transform
Transport request Handled request
Goods to be transported
Transported goods
Available resource Used resource
Handle transport tasks without the use of personnel
Make sure the system performs according to plan: use performance
indicators
Figure 3.3: The system defined using a PROPER model
a part of the system, but it does provide insight into the different transfer points required in the system. Adding the resources flow to the same model results in figure 3.5. Three distinct loops, color marked, can be seen for the interaction between the resources and the goods. These loops should be further defined as they provide insight into the working of the system. The first (red) loop depicts the process at the station were the goods enter the system. This station then interacts with an AGV to transfer the goods. The second (purple) loop shows the process an assigned AGV follows when picking up goods and delivering them to the end station. The third (blue) loop shows the process of the end station, which interacts with the AGV as it drops of its load. A full version of the system as a PROPER model with all functional flows can be found in appendixC.
From the detailing of the second loop, the AGV loop, extra system components can be found. The AGV loop is further defined in figure3.6. In this figure the block in the bottom-right corner shows the process the function belongs to. The block in the upper-right corner shows the process this function has to interact with: here these areLoading Station (LS),Unloading Station (US),
Elevators (EL)andSystem Controller (SC). TheSCis the part that controls the overall process
Deliver Goods at
origin
Goods at destination Receive Transfer Transport Transfer
Figure 3.4: Further detailing of the goods flow.
Deliver
Receive Transfer Transport Transfer
Assigned AGVs
Assigned docks Assigned docks
Available docks Available AGVs Available docks
Goods flow
Resources flow
