Transport Engineering and Logistics Report

Transcription

FACULTY MECHANICAL, MARITIME AND
MATERIALS ENGINEERING
Department Marine and Transport Technology
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
Date:
June 13, 2012
FACULTY MECHANICAL, MARITIME
AND MATERIALS ENGINEERING
Department Marine and Transport Technology
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 AGVsystem.
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.
More detailed information on the specific background of this assignment and the required content of the
work can be found in appendix B.
Studying relevant literature, developing and implementing a simulation model, verification and validation
of the model, experimenting with different scenario’s, presenting solid conclusions and recommendations
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,
Prof. dr. ir. G. Lodewijks
Preface
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 appendix B, 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 opportunity 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.
Koen Davina
i
An AGVS design tool
ii
K. Davina
2012.TEL.7687
Summary
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 additional 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 answered: 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 hospital? 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
iii
An AGVS design tool
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.
iv
K. Davina
2012.TEL.7687
An AGVS design tool
Implementing more than the standard dispatching algorithms as well as combining dispatching algorithms can give better results. Compared to a first in first out system, standard algorithms improve job pickup times by as much as 10% and combining these algorithms 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.
K. Davina
2012.TEL.7687
v
An AGVS design tool
vi
K. Davina
2012.TEL.7687
Samenvatting
Een van de ziekenhuis uitgaven die geen toegevoegde waarde creëert 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 ziekenhuis 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 simulatie om te ondersteunen bij het ontwerp en het beoordelen van dat ontwerp. Hierbij moet de
gebruiker verschillende besturingsstrategieën aangeboden krijgen. Om een goede methodologie
voor het beoordelen van zo’n systeem te creëren, zijn key performance indicators noodzakelijk. Daarnaast zijn, aangezien het systeem speciaal voor ziekenhuizen is, elementen nodig die
verschillen van de elementen in huidige industriële 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
besturingsstrategieën 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 betrekking tot het uiteindelijke ontwerp? Welke besturingsstrategieën 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 conceptueel model gemaakt van de logistieke omgeving van ziekenhuizen. Dit model geeft inzicht
vii
An AGVS design tool
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 terugverdientijd 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 besturingsstrategieën 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 gecreëerd dat klaar is om geprogrammeerd
te worden.
Tijdens het analyseren van het logistieke systeem werd duidelijk dat de verdeling van opdrachten gedurende een dag, met meerdere pieken en dalen, een verschillende besturingsmethodiek vereiste. Het samenvoegen van een toewijzingsalgoritme voor drukke perioden met een algoritme 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
besturingsstrategieën. 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 liftstrategieën 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
viii
K. Davina
2012.TEL.7687
An AGVS design tool
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 combineren 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.
K. Davina
2012.TEL.7687
ix
An AGVS design tool
x
K. Davina
2012.TEL.7687
Glossary
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 of Buffer positions. 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 remaining battery charge to do the job. xi
Loading and Unloading Station The place where jobs originate and end. A station has
multiple loading and unloading Docks. xi
Lowest remaining battery charge A WIDA that chooses the AGV with the lowest remaining
battery charge to do the job. xi
xi
An AGVS design tool
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 performing 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 performance 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 workstations calls AGVs to its location without consulting other workstations for optimization.
xi
xii
K. Davina
2012.TEL.7687
Acronyms
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
xiii
An AGVS design tool
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 indicator
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
xiv
K. Davina
2012.TEL.7687
Contents
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
Quantitative description of a hospital logistics process . . . . . . . . . . . . . . .
12
2.4
xv
An AGVS design tool
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
AGVS element IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.7.1
General elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
3.7.2
Infrastructure elements . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
3.7
4 System control and algorithm theory
4.1
4.2
43
Optimization problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.1
Dispatching problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
4.1.2
Routing and scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
4.1.3
Parking (and charging) problem . . . . . . . . . . . . . . . . . . . . . . .
49
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
5.1
xvi
55
Delphi/TOMAS programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
K. Davina
56
2012.TEL.7687
An AGVS design tool
5.2
5.3
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
Implemented Control Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.2.1
Routing algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.2.2
Dispatching Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.2.3
Parking (and charging) algorithms . . . . . . . . . . . . . . . . . . . . . .
86
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
6.4
Operational Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.1
Face validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.2
Parameter variability analysis . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3.3
Operational graphics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Data Validity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7 Test Case
7.1
The case: Medisch Centrum Alkmaar
7.1.1
7.2
121
. . . . . . . . . . . . . . . . . . . . . . . . 121
Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Expected logistic flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
K. Davina
2012.TEL.7687
xvii
An AGVS design tool
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
F Testcase data
xviii
169
K. Davina
2012.TEL.7687
List of Figures
2.1
The hospital system with the external and internal logistic flows . . . . . . . . .
2.2
Left an overview of a typical pneumatic system, right a typical transport carrier
for this system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
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.1
Process of determining the elevator waiting time . . . . . . . . . . . . . . . . . .
67
xix
An AGVS design tool
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4
93
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
delivered for two different dispatching /routing algorithms . . . . . . . . . . . . . 119
xx
K. Davina
2012.TEL.7687
An AGVS design tool
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
C.1 Total proper model of the conceptual model . . . . . . . . . . . . . . . . . . . . . 161
K. Davina
2012.TEL.7687
xxi
List of Tables
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 dispatching algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
xxii
An AGVS design tool
7.1
Assumptions for the elevators for the test case
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
. . . . . . . . . . . . . . . . . . . 123
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
K. Davina
2012.TEL.7687
xxiii
List of Listings
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
xxiv
An AGVS design tool
5.24 The MOD-FCFS/HRBC dispatching algorithm in pseudo-code . . . . . . . . . .
84
5.25 The STT/NV dispatching algorithm in pseudo-code . . . . . . . . . . . . . . . .
85
K. Davina
2012.TEL.7687
xxv
An AGVS design tool
xxvi
K. Davina
2012.TEL.7687
Chapter 1
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 opportunities 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 automated 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 chapter 2.
In designing and evaluating the feasibility of such a system the need arose at Deerns Consulting 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
1
An AGVS design tool
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 a Discrete Event Simulation Tool
(DEST).
The goal of this research is:
Develop a DEST that 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 environment 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 designed 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 the DEST to 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
2
K. Davina
2012.TEL.7687
An AGVS design tool
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 priority 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.
K. Davina
2012.TEL.7687
3
An AGVS design tool
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 chapter 4. After the theory
and the conceptual model are known, the description and implementation of the final model is
described in chapter 5. 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
chapter 6. 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.
4
K. Davina
2012.TEL.7687
Chapter 2
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, section 2.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.
5
An AGVS design tool
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 section 2.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.
6
K. Davina
2012.TEL.7687
An AGVS design tool
Hospital
External
service
providers
Goods
Logistics department
(Logistics / Waste / Maintenance / Cleaning / Mail)
Goods
Clients
Waste &
return flows
Apothecary
Labs
OR/ER
Daycare
Policlinics
Kitchen
Restaurant
Offices
People
People
Patients / Visitors / Staff
Information streams
System boundary
Tangible external flows
Tangible internal flows
Figure 2.1: The hospital system with the external and internal logistic flows
K. Davina
2012.TEL.7687
7
An AGVS design tool
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 subsection 2.3.1. The
different types of discrete system available for hospitals are described in subsection 2.3.2. The
types of continuous systems and the applicability of these systems for hospitals is described in
subsection 2.3.3. To see which of these systems can be used for which of the flows, a comparison
between these systems is made in subsection 2.3.4. Also the flows that the DEST should 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
8
K. Davina
2012.TEL.7687
An AGVS design tool
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 transports. In figure 2.2 a typical set-up of a tube system and a transport tube are shown. In table 2.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
Aerocom
Kelly
Swisslog
K. Davina
[Aer05]
[Kel03]
[Swi09a]
Speed
[m/s]
Transport volume
[dm3 ]
Transport weight
[kg]
6-8
7.6
7.6
20
9
5
28
na
5.5
2012.TEL.7687
9
An AGVS design tool
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 table 2.2. An example
of such a system can be found in figure 2.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 figure 2.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
Transport weight
Transport volume
[m/s]
[kg]
[dm3 ]
1
10
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 in 2.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 figure 2.4.
10
K. Davina
2012.TEL.7687
An AGVS design tool
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
Egemin
JBT
Swisslog
2.3.3
[Ege]
[JBT]
[Swi09b]
Speed
[m/s]
Transport weight
[kg]
2
1.6
1.5
1500
680
450
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.
K. Davina
2012.TEL.7687
11
An AGVS design tool
Table 2.4: Method of automation choice for all hospital transport flows
Process
PTS
Patients
Staff
Visitors
Beds
Food, beverages and service
Linen and uniforms
Waste
Hazardous materials
Patient dossiers and mail
Specimens
Drugs
Consumables
Medical equipment
Empty carts and bins
2.3.4
ETV
AGV
Empty
X
X
X
X
X
X
X
X
X
X
X
X
None
X
X
X
X
X
X
X
X
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
table 2.5 an overview can be found of the number of people the hospital serves to. The hospital
12
K. Davina
2012.TEL.7687
An AGVS design tool
Table 2.5: Quantitative description of the hospital logistics process: general numbers
Description
Value
Unit
Target population
Number of licensed beds
635,000
1120
people
beds
Polyclinical visits
Day treatment patients
Clinical treatments
Average clinical stay
550,000
66,000
35,500
5.5
per year
per year
per year
days
Personnel on payroll
Specialists
2800
213
FTE
FTE
Table 2.6: Quantitative description of the hospital logistics process: flows and distances
Type of load
Number of loads
Distance (Km)
Nutrition
Snacks & beverages
Linen
Waste
Drugs
Consumables
Hazardous waste
Non scheduled transports
150
45
81
52
32
60
4
23
35.0
10.5
12.5
7.2
3.0
8.7
0.55
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 table 2.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
K. Davina
2012.TEL.7687
13
An AGVS design tool
absenteeism and productivity degradation (30%, section 2.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 figure 2.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].
Number of transports per half hour
60
Number of transports
50
40
30
20
10
0
6
8
10
12
14
Time of day
16
18
20
22
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 elements
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)
14
K. Davina
2012.TEL.7687
An AGVS design tool
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. Properties of this system element are:
Storage Area Property-1: location: the location of the station in the hospital and its connection 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;
Storage Area Property-3: dwell time: the time a cart stays in this area without being used.
K. Davina
2012.TEL.7687
15
An AGVS design tool
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 situation 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, chapter 3, and these
are further detailed in section 3.1.
2.6
System boundary, assumptions
For automating the system, a choice has to be made which system parts can or may be automized. 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 for a hospital logistics position costs e40,000;
16
K. Davina
2012.TEL.7687
An AGVS design tool
• 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 uncontrolled 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 feasibility 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:
K. Davina
2012.TEL.7687
17
An AGVS design tool
• 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.
These types of flows should be usable as input for a simulation tool.
18
K. Davina
2012.TEL.7687
Chapter 3
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 current AGVS design method and the shortcomings of this method.
Given the requirements and the shortcomings a framework has to be chosen for the development
of the DEST, this is done in section 3.4. After this, in section 3.5, a hospital AGVS is 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
19
An AGVS design tool
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.
20
K. Davina
2012.TEL.7687
An AGVS design tool
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
K. Davina
2012.TEL.7687
21
An AGVS design tool
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 (section 3.6) and the building blocks for the simulation program (section 5.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, section 3.4.
22
K. Davina
2012.TEL.7687
An AGVS design tool
3.4
Choice of framework for building the DEST
Addressing the issues in the current simulation method can be done using discrete event simulation. 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 Embarcadero 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, section 3.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 figure 3.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 section 3.6. One can also clearly see the control system required, this is further
elaborated in chapter 4 (theory) and section 5.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
K. Davina
2012.TEL.7687
23
An AGVS design tool
Environment
Need
Performance
Control
Order
Requirements
Product
Handled
Order
Results
Transform
Resource
Delivered
Product
Used
Resource
Figure 3.1: The PROPER model as described by Veeke [Vee03]
Goods at origin
Goods at destination
Move Goods
Figure 3.2: The system as a black box
24
K. Davina
2012.TEL.7687
An AGVS design tool
Environment
Handle transport tasks without
the use of personnel
Make sure the system performs
according to plan: use performance
indicators
Control
Transport request
Requirements
Handled request
Results
Goods to be
transported
Transported
goods
Transform
Available resource
Used resource
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
appendix C.
From the detailing of the second loop, the AGV loop, extra system components can be found.
The AGV loop is further defined in figure 3.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 are Loading Station (LS), Unloading Station (US),
Elevators (EL) and System Controller (SC). The SC is the part that controls the overall process
and is depicted with the ’Control’ block in the PROPER model in figure 3.1. The process as
K. Davina
2012.TEL.7687
25
An AGVS design tool
Goods at
origin
Goods at
destination
Receive
Transfer
Transport
Transfer
Deliver
Figure 3.4: Further detailing of the goods flow.
Goods flow
Receive
Transfer
Transport
Transfer
Deliver
Assigned AGVs
Assigned docks
Available docks
Assigned docks
Available AGVs
Available docks
Resources flow
Figure 3.5: Combining the goods and resources flow
26
K. Davina
2012.TEL.7687
An AGVS design tool
described for the AGV assumes the AGV gets some job assigned by the system controller. This
would imply a central controlled algorithm. For a decentralized algorithm the process would be
slightly changed: the AGV still has to wait for jobs entering the system but after that it would
try to select a job which is still available. In this diagram charging an AGV is not depicted; in
this flowchart charging is an action performed by the AGV in the block ’wait for job’. If the
AGV is either idle or does not have enough battery capacity, it will go to a parking space (PS)
or charging station (CS). This process is further elaborated in section 5.1.
The transport block is further detailed and shows that the AGV can encounter an elevator or
an automatic door while driving. The elevator needs to be modeled in order to incorporate the
stochasticity of the system. The automatic doors can be included by defining an arc that has
a lower maximum speed, as to loose the amount of time normally lost waiting for these doors.
This implementation strategy is elaborated in section 5.1.
While driving the AGV will move along a path. In hospital layouts corridors are a combination of these paths. For a broad corridor, where two AGVs may pass each other, two paths are
created: one in one direction, one in the other direction. This will be referred to as a road. If a
corridor is small, two choices can be made: AGVs can move in both directions, but have to wait
for each other, or AGVs can only move in one direction. In this research the former is referred
to as a small road, the latter as a one-way road.
The two stations the AGV interacts with, the LS and US, can also be investigated by building
a process loop. For the LS this is displayed in figure 3.7 and for the US it is displayed in figure
3.8. Again interactions are shown with the SC and the AGV. In these processes one can also
clearly see the interaction with the users of the system. The performance of this system will thus
be influenced by how proper the system is used.
For all processes described the parts that need an active process can be determined as well as
the parts that can be called upon by another active process. For the loading station, two parts
were distinguished: ”Receive” and ”Transfer”. Goods that have to be received are created by
a generator in the simulation process, but as can be seen, the goods are only accepted by the
system when there is an empty slot. To make sure new goods are still generated a queue can be
K. Davina
2012.TEL.7687
27
An AGVS design tool
Drive
AGV
EL
EL
Wait for
Elevator
Ride on
Elevator
AGV
Drive
AGV
AGV
Wait for
Doors
AGV
Transport
LS
Pick from dock
AGV
US
Transport
Wait for US
AGV
AGV
US
Deliver
AGV
Transfer
LS
Wait for dock
AGV
SC
Drive
Get Route
AGV
AGV
Transfer
SC
Wait for Job
AGV
Assignment of AGVs
Figure 3.6: The AGV process
placed in between. The generator will create transport jobs, put them in the queue once they
are created and taken from the queue by the loading station when there is an empty slot. The
”Receive” part of the process can then be activated. The ”Transfer” part can be activated by
the AGV collecting the goods.
For the unloading station a similar conclusions can be made: the ”Transfer” portion can
again be initiated by the arriving AGV. The second part, ”Deliver”, or taking the goods from
the unloading station, is dependent on an external factor, which needs an active process to be
modeled. Since the LS and US are sometimes combined, a logical step would be to merge these
two into one loading and unloading station (LUS). This can be achieved quite easily because
of the necessity for only one active process. How these parts would be programmed is further
detailed in chapter 5.
The AGV process as depicted in figure 3.6 cannot be split up in the way done with the LUS.
The AGV process is one single process. Parts of the process can be programmed into separate
functions, but the process itself must stay intact. The process can either be started by the SC
assigning a job to the AGV and then activating it or be a continuous active process checking if
28
K. Davina
2012.TEL.7687
An AGVS design tool
Loading Station
Goods at
origin
User
Accept
SC
AGV
Register Job
LS
Put in empty slot
LS
LS
Transfer Job
LS
Transfer
Wait for
empty slot
LS
Wait for
goods
LS
Receive
Figure 3.7: The Loading Station process
Unloading Station
AGV
Accept
US
SC
User
Finish Job
Release
US
US
Goods at
destination
Deliver
Wait for
empty slot
US
Wait for AGV
US
Transfer
Figure 3.8: The Unloading Station process
K. Davina
2012.TEL.7687
29
An AGVS design tool
any assignment was given to it or seeking out new assignments on its own in a decentralized way.
Since the latter would give a more flexible system, allowing decentralized as well as centralized
control, an active process is preferred. The steps in this process are further elaborated in section
5.1.
Next to the AGV and the LUS the SC was mentioned. So far the SC is responsible for
dispatching jobs to AGVs, calculating AGV routes and registering all jobs entering and leaving
the system. The interactions found in the AGV and LUS elements with the SC are shown in the
process scheme of the SC in figure 3.9. Any other control system used to optimize the AGVS as
a whole can also be implemented into the SC, since the SC uses a centralized perspective. From
this centralized perspective a lot of information on the workings of the AGVS can be extracted.
These performance indicators are registered by the system controller and are further described
in subsection 3.6.
System Controller
Transport
request
SC
Track Job
SC
Register Job
LS
SC
SC
Dispatch Job
Calculate Route
SC
SC
Wait for Job
Get Route
AGV
AGV
SC
Register job
perfomance
Handled
request
SC
Finish Job
US
Figure 3.9: The System Controller process and its interactions with the other processes
Other elements needed to make the system behave in a more realistic way as stated in the
goals of the research can be added on the side of the described processes. These elements can be
included in an AGV as well as the system controller: it depends on the nature of the element.
A battery system for instance has to be implemented as a feature of an AGV, the decision to
start charging this specific battery can be made by the SC. Implementing it as a choice made by
the SC gives more flexibility, allowing the controller to choose which charging station and which
AGV to charge at which time.
Next to this the SC can also be extended with a function that induces breakdowns in the
system, the availability controller (AvC), to make the system more realistic. This can be a sep30
K. Davina
2012.TEL.7687
An AGVS design tool
arate process within the SC that does this at intervals chosen by the user of the software. This
is a function not introduced in this research, but can be incorporated in follow-up research.
The feedback these elements need to provide to aid in the design process is further defined by
choosing the appropriate performance indicators. This is elaborated in the next section, section
3.6.
3.6
Performance Indicators
All elements described so far provide data during runtime, but not all data is relevant to the
user. The data relevant to the user is displayed in a number of performance indicators. These
performance indicators should be chosen in such a way that the user gets a quick overview on
how well the simulated design works. Next to this it should also point out if the system can be
downsized whilst still meeting the customer demands in order to decrease costs. As a third point
the user has to assess the performance of the chosen dispatching, routing and parking algorithms,
this should also become clear from the performance indicators.
For every design the goal of the designer is to decrease the total costs of ownership (TCO)
of the total system. The TCO for an AGVS consist of:
• the price and number of AGVs;
• the kilometers made by the AGV, which dictates service costs;
• the level of maintenance; higher maintenance levels costs more money but decreases the
number of breakdowns;
• the service level and system boundaries the customer implies (maximum speeds, no driving
during certain hours);
• the number and size of stations and parking positions.
The influence of changed maintenance costs and the change in breakdowns is not incorporated
in this study. From consultation with experts, and given the assumptions made in section 2.6.1
the costs for the individual parts can be estimated as follows:
• AGV investment: e 120,000 ;
• AGV maintenance (standard maintenance): e 0.75 per km;
• Stations do not occupy extra space when compared to a non-automated environment;
K. Davina
2012.TEL.7687
31
An AGVS design tool
• Charging stations are assumed to occupy a space of 3 m2 , and thus amount to e 4,200;
• Parking spaces are assumed to occupy a space of 2 m2 , and thus amount to e 2,800;
• Assumed is that no extra costs are introduced for the infrastructure (roads, crossings, etc.).
Next to the investment in the system, the system should be assessed on its main purpose.
Because the main goal of a transport system is to transport jobs within a certain timeframe, the
DEST should provide the percentage of jobs in the system that did not reach their destination
in time. If the time it takes to transport a job is too long, insight should be gained on how
this time is built-up. The time can be too long because of the transport distance, in which case
the speed or routing of the AGVs is the only way to decrease the time, or it can be because of
waiting, in which case it can either be waiting onboard of an AGV for crossings and elevators or
at a LUS, or waiting for an AGV to arrive. Not being in time can also come from an unreliable
system breaking down too often. For all cases different types of performance indicators are to
be implemented.
These indicators can be displayed in a tree with the time a job is in the system as the top
level. This top level indicator is referred to as a key performance indicator (KPI). This tree is
displayed in figure 3.10.
Since the design of the system also incorporates the number and size of stations and the
number and characteristics of the AGVs, performance indicators should also be displayed for
these elements. The AGVs should be used as effective as possible, this can be displayed as a
utilization ratio for the AGVs. Next to this the distribution of the utilization of the different
AGVs can be displayed to see if the load is equally divided between the different AGVs. AGVs
should be utilized as equal as possible for maintainability. For this case utilization is defined
as the time the AGV is not parked or driving to a parking space versus the time since it was
activated.
The user should be able to analyze this number further; one should be able to see if the time
the vehicle is not utilized. This can be split up in the time the AGV took to drive towards a
parking location and the time the AGV was actually parked. The percentage of time driving
towards this location depends on the number of parking spots available throughout the system
as well as the algorithm chosen to find a parking location. The percentage of time that the AGV
is actually parked can be seen in an opportunity percentage; the percentage of time that the
32
K. Davina
2012.TEL.7687
An AGVS design tool
Jobs in time
Waiting Time
Station
waiting time
Driving Time
On-board
waiting time
Pick-up time
Elevator waiting
time
Drop-off time
Traffic waiting
time
Percentage detour
Travelled distance / Shortest path
Figure 3.10: Overview of performance indicators for system analysis for a transport job
K. Davina
2012.TEL.7687
33
An AGVS design tool
AGVs can be used for other purposes without adapting the AGVS.
Analysis of the utilization part should also be possible; first the time the AGV carries a
transport job, second the time it takes for an AGV to drive towards an assignment and third
the time the AGV takes to recharge. This last number can be split up again in driving towards
a charging point and the charging itself. This number aids in the design and positioning of the
charging stations as well as the chosen battery charging regime. The first two numbers can be
split up in actual driving time, waiting time for traffic, waiting time for elevators. These numbers
can be used to see where actual progress can be made when choosing a different algorithm.
One additional performance indicator is added; the minimum number of jobs transported by
any AGV. This is to check if any of the AGVs transported substantial less jobs because it was
in a deadlock position or not working for any other reason. It is thus to check if the program
works properly.
An overview of these performance indicators for the AGVs can be found in figure 3.11.
AGV utilization
Recharge
Charging time
Working
Not utilized
Number of jobs done
- minimum
Drive towards
charge point
Driving
towards
parking
Carrying
payload
Parked
Towards
payload
Figure 3.11: Overview of performance indicators for AGVs
Analysis of the LUSs should also be possible in the same way as it is done for the AGVs and
34
K. Davina
2012.TEL.7687
An AGVS design tool
the jobs. Again the performance indicators can be implemented in a tree like structure. The
most important indicator for a LUS is the average queue length. In a LUS there are more than
one queue and the performance indicator can just be viewed as the average number of jobs in
the LUS waiting for pick-up. Since AGVs can only pickup the first job in a lane, adding more
lanes would decrease the pick-up time and thus the average queue length; displaying the average
queue length would provide a good insight in the workings of the designed LUSs.
To analyze the LUSs further the following additional performance indicators can be added:
the starting position in a lane for jobs with different priorities, the maximum and average number of jobs in a lane, the number of jobs that could not be put into the LUS because it was full
and the number of times an AGV could not drop-off its load because all lanes were full. The
maximum number of jobs in a lane can be used for the design of the length of the lane. The
average number of jobs for each lane and the starting position for jobs with different priorities
can be used to evaluate the algorithm used to put jobs in the system. All these performance
indicators are summarized and displayed in figure 3.12.
LUS average number of
jobs waiting for pick-up
Average starting position
of a job for each priority
Number of jobs in each lane
ready for pick-up
No drop-off possible
No LUS input possible
percentage
- lost time
Figure 3.12: Overview of performance indicators for LUSs
If the AGVs are standing still they are either in a parking spot or a charging station. These
elements should also be assessable which can be done by displaying their utilization ratio. Next
K. Davina
2012.TEL.7687
35
An AGVS design tool
to this performance indicator no additional indicators for parking spots and charging stations
should be necessary.
The last performance indicators to assess the AGVS are for the road network (elevators are
assumed to be part of the road network). This is done with utilization rates for the road elements. These ratios can also be used for evaluation of the routing algorithm as congestion
should decrease when the algorithm becomes smarter. For an elevator this would be the time
the elevator is occupied or called upon over the total time. For crossings and roads it would be
the time any AGV is on the crossing or road over the total time.
3.6.1
System performance indicator
For each element in the system performance indicators were drawn up. To give the user a possibility to compare one system to another, performance indicators can be combined to create a
single system performance indicator (SPI) number. How this number is built up is explained here.
The number itself will be displayed as a KPI, meaning the closer the SPI gets to 1, the better
the system is with respect to the wishes of the customer. As explained before the TCO and with
that the payback time (PT) is one of the most important indicators in the system. The system
will have a technical lifetime (TLT) and the closer the PT will come to this TLT, the worse the
investment is. From the PT and TLT the part of system performance indicator with respect to
payback time is calculated:
SP IP T

PT

1 −
T
LT
=

0
if P T ≤ T LT
(3.1)
if P T > T LT.
The payback time is calculated as the number of whole years it takes before the cumulative
costs of an AGV system would be lower than the costs of a comparable system with electric
vehicles. The second important performance indicator is the service level (jobs delivered within
the set time window) reached by the system. The customer will provide a required service level
(RSL). The service level (SL) can be calculated as:
36
K. Davina
2012.TEL.7687
An AGVS design tool
SP ISL

SL − RSL


1 − RSL
=

0
if SL ≥ RSL
(3.2)
else.
With the two described parts before, the most important parts of the system with respect
to the customer are covered. To further see if one design surpasses another one more extra
performance indicator is required. If the traffic congestion is high, but jobs are still delivered
within the set service level times, the system might give the same SPI as a low congested system,
so this indicator should show the possibilities of the system in terms of extensibility and the
degree in which the system can cope with bigger transport flows. Next to that the performance
indicator also provides insight in whether the system can cope with high disturbances in its
infrastructure (blocking of roads for instance). Traffic congestion can be viewed as the transport
time (T T ) required to deliver a job j relative to the waiting time during transport (W Ttransport ).
In this performance indicator the time required to reach the origin of the job is not incorporated,
this depends on parking algorithms. The part of the SPI based only on traffic congestion (T C),
and with this the effectiveness of the traffic avoidance algorithms used in the routing algorithm,
can be calculated as:
SP IT C =
jX
max
j=1
TT
.
T T + W Ttransport
(3.3)
To calculated the system performance indicator, SPI, the three separate elements can be
combined. Summing the three elements, PT, SL and TC, gives a number in which all three
elements have an equal weight. To incorporate the importance of each individual performance
indicator, weights can be used. The SPI is then calculated as:

α ∗ SP IP T + β ∗ SP ISL + γ ∗ SP IT C



α+β+γ
SP I =


0
if SP IP T > 0 ∩ SP ISL > 0
(3.4)
else.
The importance of the different KPIs (and with that their weights) were obtained using a three
step process. First the expected bandwidth of the KPIs was estimated in order to incorporate
a scale in the weight factor equalling the contribution of the tree KPIs. Second, the importance
of the different KPIs was assessed by ranking the KPIs from 1 (least important) to 3 (most
K. Davina
2012.TEL.7687
37
An AGVS design tool
important). As a last step the total weights were fine-tuned based on experience. All these steps
were performed by an expert at Deerns Consulting Engineers.
The expected bandwidth and the corresponding scaling factor, together with the importance
ranking of the KPIs, are presented in table 3.1. After the last step, the fine-tuning, the total
weights are α = 6, β = 3 and γ = 1.
PT
SL
TC
Expected
lower bound
Expected
upper bound
Average
Scaling
factor
Importance
ranking
Subtotal
finetuning
Total
weight
0.3
0.25
0.75
0.7
0.75
0.95
0.5
0.5
0.85
2
2
1
3
2
1
6
4
1
+0
-1
+0
6
3
1
Table 3.1: Bandwidth, scaling, importance ranking, fine-tuning and total weights of the three
KPIs for the system performance indicator
This provides the final equation to calculate the SPI:

6 ∗ SP IP T + 3 ∗ SP ISL + 1 ∗ SP IT C


10
SP I =

0
if SP IP T > 0 ∩ SP ISL > 0
(3.5)
else.
From the formula for the SPI one can see that obtaining an SPI of 1 is only reachable when
no investment is done, a service level of 100% is reached and waiting times are not present in
the system. In practice service levels are always lower and transport times will go up mainly
due to elevator rides. A big supplier of AGVs, Swisslog, incorporates 120 seconds of transport
time for elevator rides. However, the elevator ride itself will take 30 to 45 seconds, resulting in
75 to 90 seconds of delay in the system. Dedicated elevators in abundant numbers can decrease
these delays to almost zero. A service level of almost 100% can be reached by putting low
requirements on the transport times, resulting in longer turn around times for the goods, which
in turn results in more buffers, stock and decentralized services throughout the hospital. A high
level of overcapacity in the system, together with the aforementioned measures, can make the
SL and TC performance indicators close to 1, resulting in an SPI of at least 0.4.
A system where no investment is to be done can be created, but only involving some lease
construction costing less than the current expenses for the logistics system. If no investment is
done the SPI will be at least 0.6. If one takes the average numbers expected for each KPI, the
SPI will be 0.54. This also means that a system that does not earn itself back very quick (for
38
K. Davina
2012.TEL.7687
An AGVS design tool
instance
⁄
= 0.8), the maximal SPI that can be obtained is 0.52, which is lower than the
TLT PT
average expected of 0.54. This emphasizes the importance of the payback time in this type of
system. It also means that a system earned back quickly (for instance in
T LT /P T
= 0.3) with
a service level KPI value of 0.25 (expected lower boundary) and a traffic congestion KPI value
of 0.75 (expected lower boundary), the SPI will be 0.57. This is slightly higher than the SPI
calculated with average values.
To calculate the different performance indicators and the SPI certain data is required. The
outputs of the system elements required to calculate all performance indicators are summed up
per system element in section 3.7.
3.7
AGVS element IO
In this section all elements required to build the AGV system are described with their respective
properties, inputs and outputs needed to make the program work for different AGVSs and
different hospitals. It is a simple sum-up and can be seen as a summary of the previously done
system analysis, required performance indicators, literature research [Dav11] and the original
assignment by Deerns Consulting Engineers [Wit11]. At this stage the process within a system
element was conceptually described by a flowchart in section 3.5 but not yet fully defined. To
define the full process the inputs and the outputs of the process first need to be defined in this
section. From the inputs, outputs and properties, together with the modeled process, the element
process can be defined, these element processes are elaborated in chapter 5.
3.7.1
General elements
Job
- Input: Origin;
- Input: Destination;
- Input: Priority;
- Input: Latest Arrival Time (LAT);
- Output: Start time, end time, time in system
- Output: Time driving, time waiting (during driving/waiting for pickup)
K. Davina
2012.TEL.7687
39
An AGVS design tool
- Output: Travelled distance
- Output: Waiting time at stations/elevators/due to traffic congestion
AGV
- Input: location;
- Input: speed;
- Input: battery capacity, battery charging and usage parameters;
- Input: time for loading and unloading jobs;
- Output: driving start and end times;
- Output: driving purpose (to charging point, with payload, towards payload, to parking);
- Output: standing still start and end times;
- Output: standing still purpose (for loading, unloading, charging, parking, waiting for elevator/
crossing/path);
- Output: jobs done.
System Controller
- Input: routing algorithm;
- Input: dispatching algorithm;
- Input: idle behavior (parking and charging algorithm);
- Input: hospital layout;
- Input: expected transports;
3.7.2
Infrastructure elements
Infrastructure element
- Input: location, orientation;
- Input: connecting element(s);
- Input: maximum driving speed;
40
K. Davina
2012.TEL.7687
An AGVS design tool
Node
- Output: utilization ratio, defined as the time the node is reserved by an AGV over the total
time it is in the system.
Path
- Output: utilization ratio, defined as the time the path is occupied by at least one AGV over
the total time it is in the system;
Loading & Unloading Station
- Input: number and type of jobs to be generated;
- Input: number and type of (loading or unloading) docking points;
- Input: type of docking points flexible? (yes/no);
- Input: number of buffer positions (number of positions behind one docking point);
- Input: time required to reach the right docking point;
- Output: number of jobs waiting for pickup (total/per dock);
- Output: percentage jobs not accepted by the system (LUS full);
- Output: percentage and time loss on no unload possibility for AGV;
- Output: starting position for a job (total/per priority);
Charging station
- Input: charging parameters
- Input: coupling/decoupling time;
- Output: utilization ratio, defined as the time the charging station is occupied by an AGV over
the total time it is in the system.
Parking space
- Input: time required to reach the right position;
- Output: utilization ratio, defined as the time the parking space is occupied by an AGV over
the total time it is in the system.
K. Davina
2012.TEL.7687
41
An AGVS design tool
Elevator
- Input: entrance and exit times, door closing and opening times;
- Input: speed;
- Input: distribution type and parameters for elevator waiting time;
- Output: utilization ratio, defined as the time the elevator is called upon and ridden by an AGV
over the total time it is in the system.
42
K. Davina
2012.TEL.7687
Chapter 4
System control and algorithm
theory
This chapter describes two things: the theory behind the three optimization problems in section
4.1 and traffic control theory in section 4.2. The implementation of the control algorithms and
the traffic control for this specific hospital application is elaborated in chapter 5.
4.1
Optimization problems
When designing an AGVS 3 optimization problems concerning the control of AGVs can be
distinguished ([Vis06]): the dispatching problem (section 4.1.1), the routing problem (section
4.1.2) and as a part of that the scheduling problem (section 4.1.2), and the parking problem
(section 4.1.3). For all these problems different solution algorithms exist which are described in
their corresponding sections.
4.1.1
Dispatching problem
In the dispatching problem a method, or algorithm, has to be designed to dispatch an AGV
to a transport request. These algorithms can be divided into two types: work-center initiated
dispatching algorithm (WIDA) and vehicle initiated dispatching algorithm (VIDA). A work center is a station that requires and provides goods to be transported. A WIDA is applied when
assignment of jobs is done by the work center; it chooses one AGV from one or more idle AGVs
43
An AGVS design tool
Table 4.1: Overview of standard vehicle initiated dispatching algorithms
Rule
Acronym
Description
First-Come-First-Served
FCFS
Maximum Demand
MD
Maximum Outgoing Queue Size
MOQS
Minimum Remaining Outgoing Queue Size
MROQS
Modified First-Come-First-Served
MFCFS
Modified First-Come-First-Served
Random Work center
MOD
FCFS
RW
Shortest Travel Distance
STD
Shortest Travel Time
STT
The job that entered the system first
will be picked up first.
First bring jobs to the station that expects the most deliveries.
The AGV is dispatched to the station with the largest number of pickups
waiting.
Pick up a job at a station were the outgoing queue is almost filled up.
FCFS with max one pickup job in the
system for each pickup point.
If job is delivered first look for a job at
the drop off point, otherwise FCFS.
The vehicle that becomes idle picks a
random job to pick up.
Pick the job that requires the least distance to drive to.
Pick the job that requires the least
amount of time to drive to.
for a single transportation job. A VIDA is applied when the AGV makes a decision; if multiple
jobs are available the AGV will make the choice which job to transport first. An overview of
standard algorithms for VIDAs and WIDAs can respectively be found in table 4.1 and 4.2. Next
to these algorithms a lot more can be found in literature having different definitions with respect
to utilization ratio and idle time.
Several studies were performed to test the effectiveness of the dispatching algorithms. According to [Che87] distance-based rules (STD & FAV) perform better than AGV-attribute based
rules (LIT & LIV). In [ET84] studies are performed combining VIDA and WIDA, the first being
used when only one AGV is available, the latter being used if only one job is available and
multiple AGVs. The main conclusions from their research are: choosing a WIDA does not effect
the throughput for the system that much, VIDAs are the big influence on the system looking
at throughput. Next to that it is shown that distance based rules perform competitively with
other rules looking at system throughput, but perform bad when focusing on queue length and
throughput per station; stations lying far outside of the rest of the system will less likely be picked
for transport and queue sizes can grow rapidly on these systems. This conclusion is shared by
[KK96]; distance based rules can be very competitive but are layout sensitive.
44
K. Davina
2012.TEL.7687
An AGVS design tool
Table 4.2: Overview of standard work center initiated dispatching algorithms
Rule
Acronym
Description
First Available Vehicle
FAV
Least Utilized Vehicle
LUV
Longest Idle Vehicle
LIV
Least Cumulative Idle Time
LIT
Nearest Vehicle
Random Vehicle
NV
RV
First vehicle that can come available
will pick up the job.
First use the AGV that is used the
least.
First use the AGV that has been idle
for the longest time.
Choose the vehicle that has the lowest
total idle time.
Choose the nearest available vehicle.
Choose a random vehicle to pick up the
transport job.
Next to these algorithms, some less standard algorithms may be defined that have produced
promising outcomes. These algorithms can be found in table 4.3. The research of [KK96]
focuses on multi-attribute algorithms (MAA); combining standard rules (in this case STT/STD,
MOQS and FCFS) in several ways to decide which job to pick up. Since decision making is
always a process involving multiple criteria or attributes, applying a MAA is a logical step.
According to this research MAAs perform significantly better than single-attribute algorithms,
which is confirmed by research done by [TTT00, NT05]. In MAA a combination of standard
algorithms is made, which provide a contribution to the total priority of a transport job. This
combination can be made by applying fuzzy techniques and applying weights. These weights
can be chosen arbitrarily or tuned using a genetic algorithm as done by [TTT00, NT05]. This
weight tuning using a genetic algorithm makes the algorithm perform better than using manually
chosen weights. Next to using these standard algorithms, one can also choose to include other
factors in a multi-attribute algorithm that might make it better usable in practical cases. One
example could be the remaining battery life of an AGV. How this can be implemented is further
elaborated in section 5.1.
Another way to use several algorithms in making a decision is to use a hierarchical level
algorithm (HLA). In this type of algorithm each algorithm level will decrease the number of
possible AGV - transport job combinations using one of the standard algorithms at each level
followed by a final choice after all levels have been passed. These HLAs can be viewed as a
subset of MAAs, but instead of weighing all criteria at once, criteria are applied level by level.
An application of this type of algorithm is described in [SH92]. The research concludes that
applying HLAs gives better performance than just one of the standard dispatching algorithms.
K. Davina
2012.TEL.7687
45
An AGVS design tool
The authors of [BY96] propose the bidding-based device-dispatching (B2 D2 ) and modified
shortest travel time (MSTT) algorithms. These algorithms differ from the rest of the algorithms
in that they provide a framework for take-over of jobs by other AGVs when one AGV is already
heading that way. The algorithms both work with a job assigned to a vehicle, this job is however
not committed to the vehicle as long as the vehicle did not pass the threshold value. Once it
did the vehicle is committed to the job and no other AGV may pick it up any more. In these
algorithms every time a new job enters the system all uncommitted jobs in the system are reevaluated and may be reassigned. The MSTT is a modification of the STT rule; the vehicle closest
to a new job will be the vehicle picking up the job. However, as long as the distance towards
the job did not pass the threshold value the vehicle may still be reassigned to a different job.
In B2 D2 all AGVs place a bid when a new job comes up in the system. In this algorithm an
AGV will place a bid sized by the time it will take to get to the pick-up station. This time may
incorporate another delivery that the AGV has to do first; this algorithm is thus not limited
to assignment of one job per AGV. Both the MSTT and the B2 D2 perform considerably better
than any standard rule according to the authors. They propose to further extend their research
by incorporating f.i. job priorities and downtimes of system component to get a more practical
result. [LKY+ 03] proposes another bidding-based dispatching method (BDM) in which vehicles
keep bidding to each other till one has the lowest bid that still compensates for its costs. In
this system multiple bidding rounds are performed and when a vehicle is done with a job it can
outbid another vehicle already on its way to a job. In the BDM algorithm the station wants to
minimize the costs of the transport whereas the AGV wants to maximize its profit. The outcome
of this research is that the BDM performs considerably better than a STT/STD based AGVS.
All algorithms presented are calculated in theory, but supposedly not implemented in operational systems. To implement these algorithms more work has to be done to make the algorithms
behave in a more realistic way. A lot of these algorithms outperform the standard dispatching
algorithms, but the improvements proposed were never combined into a new further improved
algorithm. For this study the implementation and combination of existing solutions is worked
out in section 5.2.
46
K. Davina
2012.TEL.7687
An AGVS design tool
Table 4.3: Overview of other well performing dispatching algorithms
Rule
Acronym
2
2
Bidding-based Device-dispatching Algorithm
[BY96]
Bidding-based
Dispatching
Method
[LKY+ 03]
Genetically Optimized Multi-criteria Algorithm
[NT05]
Hierarchical Level Algorithm
[SH92]
B D
Modified Shortest Travel Time Algorithm
[BY96]
Multi Aspect/Attribute Algorithm [KK96]
MSTT
4.1.2
BDM
GMCA
HLA
MAA
Description
AGVs bid on jobs, lowest bidder gets
the job
AGVs try to maximize their profit,
while stations try to minimize costs
MAA with genetically optimized
weights
Each level filters the set of transport
jobs further down till 1 job remains
STT with AGV reassigning to other
jobs and job takeover by another AGV
Combining multiple standard algorithms using predefined weights
Routing and scheduling
The routing problem is concerned with the route an AGV should drive to get from place A to
place B. The scheduling problem describes when AGVs should enter and leave different parts of
the route in order to avoid congestion, collisions and deadlocks.
An AGV route network consists of some basic elements: arcs, nodes and stations. Arcs are
paths an AGV can follow, these arcs can be mono-directional or bi-directional. Nodes emerge
where two or more arcs meet and can be viewed as a crossing. Stations are points were AGVs
interact with the system to load/unload, park or charge. There are three possible types of paths
between two nodes: one-way paths consisting of one directed arc, two-way paths consisting of
two directed arcs and bi-directional paths consisting of one bi-directional arc.
To simply calculate the shortest route between two stations Dijkstra’s algorithm can be used
[Wik11b]. This routing will give multiple AGVs the same nodes and arcs to cross; this is where
scheduling comes in. In order to avoid problems arcs and nodes can be reserved for a certain time
window for a given vehicle. When a new route for another vehicle is calculated all reserved time
windows are avoided; this concept is known as conflict-free routing. Conflict-free routing can be
done for two separate cases: static or dynamic job sets. The static job set case can be applied if
all jobs are known prior to the routing and scheduling calculation. The algorithms work in two
ways; one way tries to optimize for the whole system at once, the other way calculates the route
for one AGV and start adding AGVs in a conflict-free manner. This can be done multiple times
to see which AGV should be used to start the calculation. This is done for static job sets; for
K. Davina
2012.TEL.7687
47
An AGVS design tool
static job sets, the jobs requiring transport in the to-be-calculated time window are known in
advance. An overview of solutions to static job sets can be found in [GHS98, Vis06, LAdK06].
For a dynamic job set the calculation is as done as in the second way for the static job
set; each new route is dynamically inserted into the existing set of routes. Example algorithms
can be found in [HPK93, OBK99]. Most research in this area addresses problems concerned
with routing through bi-directional paths where deadlocks are more likely to occur. Two-way
paths will only cause conflicts at nodes and stations and thus requires less control of the AGVs
[QH01, KT93, KT91].
All these algorithms use Dijkstra’s algorithm to calculate a shortest path. Another way to
calculate the path is to use a heuristic algorithm, like A* (A-star [Wik11a]). In this method one
tries to calculate the shortest route by using an estimation of the distance to the destination in
order to discard a lot of route options to speed up the calculation. To check if other routes might
be quicker based on expected traffic density a tabu search can be performed, by for instance
swapping a crossing in the calculated route with a neighboring one [Nan00] to further decrease
the transit time of the AGV.
In calculating the route one can either choose to calculate the whole route at once, complete
route planning, or only parts of the route, incremental route planning [TDT95]. Since routes can
become invalid during transport due to breakdowns or blockages calculating the complete route
might result in numerous unnecessary calculations. However, in incremental route planning local
optima may be found for routing instead of an overall optimum, which results in slightly longer
transfer times [TDT95].
For the hospital system elevators are introduced into the system, which will be used by people
as well. This makes planning impossible when an AGV uses an elevator, because elevator waiting
times cannot be calculated, only estimated, in this case. Incremental route planning can be used
in this case to plan routes per floor. Another problem in hospitals, and researched with the
simulation, is the number of times blockages, or breakdowns, of paths and nodes occurs, which
makes the AGVs stop or force a re-route. It can simply be because a patient or visitor is standing
in front of an AGV, a patient being moved with bed because of an emergency or a cart of bed
positioned in the path of the AGV. This will again require a recalculation of all movements on
that floor. For factory floor use of AGVs this is less of a problem, because employees can be
48
K. Davina
2012.TEL.7687
An AGVS design tool
instructed to keep all AGV paths free and not obstruct the AGV in any way.
Another possibility is not to use scheduling; when AGVs arrive at a point in the system where
they encounter each other, traffic control can be used to give certain AGVs priority over others.
This is the same method as the way traffic is controlled on public roads. It provides a solution
less efficient than the one calculated for the whole system, but requires less calculation. The
system will also continue to work without recalculation when AGVs or other parts of the system
break down. How traffic can be controlled is further explained in section 4.2.
4.1.3
Parking (and charging) problem
If an AGV becomes idle it has to be positioned somewhere in the system. This can be done in
three distinct ways [Vis06]: by central positioning, circulatory loop positioning or point of release
positioning. With central positioning the AGVs parking areas are designated within the system.
For circulatory loop positioning loops are defined within the system and idle AGVs will travel
around these loops as long as no transport jobs are available. With point of release positioning
the AGV will stay at the location it made its last drop off.
In [OBK99] central and point of release positioning are compared. According to this study
the latter outperforms the first. In another study, [LV01], an algorithm for optimal dwell points
is proposed. According to the simulation studies performed by the authors dwell points that
minimize the mean response time significantly improve system performance.
Most systems in operation have one parking location for all vehicles, which is also the charging
location. This is because vehicles used in manufacturing facilities, the biggest market, are almost
always busy. These vehicles will thus only seek a parking position when they need to be recharged.
Parking when waiting for a job is thus not applicable.
When opportunity charging is allowed (charging at every possible moment) a trade-off can
be made for going to either a charging or parking location. A parking location can be closer to
expected jobs (optimal dwell points) while opportunity charging can make sure the AGV is not
required to charge, when its battery is empty, at an undesirable (busy) moment.
K. Davina
2012.TEL.7687
49
An AGVS design tool
4.2
Traffic control
Since AGVs will encounter each other in different parts of the system, a way of controlling the
system has to be drawn up. First the behavior of AGVs with respect to nodes is elaborated. After
this the control of bi-directional paths is discussed. Elevators are also considered bi-directional
paths for traffic control. Next traffic control around a LUS is elaborated. Traffic control for
the PS and CS is discussed in the last paragraph. The assumptions made for implementation
of traffic control can be found in chapter 5 as part of the implementation description of the
concerning element.
4.2.1
Traffic control around nodes
At a node multiple paths are connected. Some of these paths give incoming traffic, others
outgoing traffic. Nodes are like road crossings and traffic control can be done using a sort of traffic
light or semaphore. The node semaphore will decide how many AGVs can cross simultaneously.
When AGVs arrive at the node they will express their wish to cross the node and try to
reserve it for themselves. If one AGV is currently claiming the node, the semaphore will give
this AGV the go-ahead and the AGV will cross. If multiple AGVs want to claim the node, the
semaphore will make a decision which AGV can go first. This can be based on a first-in-firstout principle, on priority, or on whatever other decision principle required by the system. The
semaphore can also choose to let multiple AGVs cross at once if it decided these AGVs would
not interfere with each other.
4.2.2
Traffic control on one-directional paths
If paths are one-directional, AGVs can just access them without the possibility of deadlocks.
AGVs will have to check if they are not running into the back of another AGV, but this is safety
based and hardware related and not traffic control related. Traffic control is thus not necessary
on one-directional paths.
4.2.3
Traffic control for small roads and elevators
If paths are bi-directional but too small to allow AGVs to pass each other, traffic control has to
be done to avoid deadlocks in the system. In order to do this the AGV has to claim the small
road. A type of semaphore can be used to give this AGV the go-ahead or give priority to another
50
K. Davina
2012.TEL.7687
An AGVS design tool
AGV traveling in the opposite direction. The priorities used can be chosen at will and AGVs
can directly drive onto the path when given the go-ahead.
An elevator can also be viewed as a road with multiple entry and exit points, but with the
capacity of a single AGV. If an elevator is involved the AGVs will still try to claim this, but when
it is allowed for the AGV to continue, it still has to call the elevator, wait for it till it arrives and
then start driving again. The way the elevator is dispatched can be implemented in many ways,
with first-in-first-out being the simplest implementation where the elevator first serves the AGV
that first claimed the elevator.
4.2.4
Traffic control for a LUS
A LUS has a capacity depending on the number of drop-off and pick-up points. Since an AGV
requires not only a place to stand while loading and unloading, but also space for its job when
unloading or a job ready to be picked up when loading, two AGVs will never occupy the same
dock of a LUS: a dock has the capacity of a single AGV. The node coupling the docks together
also has a capacity of one, meaning only one AGV at a time can drive towards a dock in a single
station.
When AGVs arrive at a station, the dock at which they drop off their load is not yet known
and a way to guide the AGV to the correct dock for drop-off should be implemented as part of
the traffic control.
4.2.5
PS and CS traffic control
Parking spaces and charging stations can accommodate one AGV per piece and thus require an
AGV to claim it. This can be done using a semaphore construction. With most infrastructure
elements multiple AGVs can claim the element. Some of the AGVs will then have to wait for
the element to have enough capacity to accommodate them. For PSs and CSs AGVs better not
claim an already occupied element. The waiting can take a long time because these elements are
created in order for an AGV to stay a longer time at that location. AGVs should thus never try
to claim an already occupied PS or CS.
K. Davina
2012.TEL.7687
51
An AGVS design tool
4.2.6
Chains of traffic controlled elements
In essence, the number of claimable, and thus limited in capacity, elements connected to each
other should be minimal. The shorter the chain of elements, the easier it will be for AGVs to
pass the chain.
If an AGV arrives at a chain of claimable elements it cannot claim only the first element,
continue driving till the next element and claim that one. If an AGV that comes from the other
side of the chain does the same they will meet halfway and will not be able to continue, as shown
in figure 4.1. AGVs may thus enter the chain of claimable elements only if they can claim the
whole chain before entering, preventing others to cross or enter the same path, as shown in figure
4.2. If chains become very long an AGV will claim a long part of the route, resulting in time
losses for the AGVs crossing the chain. To prevent this chains should be kept as short as possible
in this type of traffic control.
Figure 4.1: Multiple AGVs on each others path creating a deadlock situation
To keep the system clear, elements are always connected using nodes. An elevator will thus
52
K. Davina
2012.TEL.7687
An AGVS design tool
Figure 4.2: An AGV reserves a path to make sure deadlocks will not occur
always be connected to at least two nodes, which creates a chain of at least three elements. Any
extra bi-directional paths, LUSs, PSs or CSs connected to those nodes will further increase this
chain. To make provide the best possible flow the system should be designed in such a way that
chains are minimized.
K. Davina
2012.TEL.7687
53
An AGVS design tool
54
K. Davina
2012.TEL.7687
Chapter 5
Description and implementation
of the model
Since the conceptual model and framework, as well as the required theory, to build a DEST for
a hospital logistics system is presented, these parts can now be combined into a useable tool.
From the conceptual representation of the system as presented in chapter 3 a description can be
created in the form of a pseudo code. In this step considerations are also made whether or not
to implement certain details. From this pseudo code the coding itself can be done. If a part can
be coded quite easily the step to a pseudo code is skipped and the model is coded right away.
This describing and coding is done in the first section of this chapter, section 5.1.
After this, in section 5.2, the control algorithms used in the DEST are described in pseudocode. These implemented control algorithms are a subset of the control algorithms presented in
4 as well as some algorithms that are an adaption of these algorithms to better suit the hospital
environment.
Finally the way the system handles data and how this data is saved and retrieved is elaborated
in section 5.3. This section also describes the way data flows through the system: when inputs
are expected from the user and how this is transferred to outputs.
55
An AGVS design tool
5.1
Delphi/TOMAS programming
In this section the elements as they are programmed as objects in delphi are described. First
all object classes are presented with some explanation on their procedures and variables. Some
parts of this description require Delphi/TOMAS knowledge to read. Second, the elements that
have a distinctive process will be elaborated on their process together with some Delphi/TOMAS
definitions required to understand these processes. This is a direct translation of the processes
described and depicted in section 3.5 displayed in a pseudo-code fashion. After that the limitations of the model emerging from these processes, the used programming language and those
built in as a simplification of the real process together with the assumptions made to code the
system are described. Finally, some general functions and procedures are further elaborated and
presented in Delphi/TOMAS code.
5.1.1
AGVS Delphi class definitions
For this program one object is created from which all objects descent: the TSimulationElement.
The definition of this class is as follows:
Listing 5.1 Class definition of TSimulationElement
TSimulationElement = c l a s s ( TomasShape )
public
B a s e C o o r d i n a t e : TCoordinate ;
BaseOrientation : TOrientation ;
published
5
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ) ;
end ;
This class inherits all properties from the TomasShape element from the TOMAS package
and it ensures the location of an element can always be accessed by other classes. From this
class three new classes descent: TWaypoint, TAGV and TJob. These three elements form the
basic elements of the AGV program. TWaypoint is the parent class for infrastructure elements
as was described in 3.7.2. The system controller is the last part necessary and is implemented
using the TGenerator, TDispatcher and public variables and functions. The class definitions of
all these elements are further elaborated in this subsection.
56
K. Davina
2012.TEL.7687
An AGVS design tool
TWaypoint class definition
The TWaypoint class is presented in listing 5.2. The TWaypoint class is the parent element
for all infrastructure elements. For each of these elements it creates a list with all connection
making it possible to enter this element, the TomasQueue ConnectionsIn, to exit the element,
the TomasQueue ConnectionsOut, a semaphore if the element is claimable (for instance nodes
and elevators) and a TomasQueue containing all flags for AGV actions as explained in section
5.1.2.
Listing 5.2 Class definition for the TWaypoint element
5
10
15
20
TWaypoint = c l a s s ( TSimulationElement )
C o n n e c t i o n s I n : TomasQueue ;
ConnectionsOut : TomasQueue ;
Semaphore : TomasSemaphore ;
FlagQueue : TomasQueue ;
private
ChangeClaimTime : Double ;
public
C l a i m a b l e : Boolean ;
F l o o r : TFloor ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; PFloor : I n t e g e r ) ;
p r o c e d u r e AddFlag ( Fl a g : TFlag ) ;
p r o c e d u r e CreateShape ; v i r t u a l ; a b s t r a c t ;
p r o c e d u r e ShowShape ; v i r t u a l ; a b s t r a c t ;
p r o c e d u r e MakeFlags ; v i r t u a l ; a b s t r a c t ;
p r o c e d u r e S e t C l a i m F l a g s ( F l a g : TFlag ) ;
p r o c e d u r e Claim (F : Double ) ;
p r o c e d u r e R e l e a s e (F : Double ) ;
end ;
In the listing three variables are mentioned: ChangeClaimTime, which holds the last time
the number of claimers was changed, which is used for occupation calculations, Claimable, which
tells if the element is claimable or not, and Floor, which holds the floor information the waypoint
element is on.
The class also provides a number of procedures. The AddFlag, MakeFlags and SetClaimFlags
procedures are for creating and adding flags to waypoints. Flags are signaling elements for the
AGV in that the AGV will perform the flag action if the flag is meant for the passing AGV. How
the flags are included in the AGV process is described in subsection 5.1.2. The flag element itself
is defined as follows:
K. Davina
2012.TEL.7687
57
An AGVS design tool
Listing 5.3 Class definition of TFlag
TFlag = c l a s s ( TomasElement )
public
PFlagType : TFlagType ;
PFlagAction : TFlagAction ;
PPos : d o u b l e ; // P o s i t i o n a s p e r c e n t a g e o f t o t a l a r c l e n g t h
5
PTomasElementPointer : P o i n t e r ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; FType : TFlagType ; FAction : TFlagAction ; Po :
P o i n t e r ; Pos : d o u b l e =0) ;
end ;
10
MakeFlags creates claim and release flags for the waypoint. It adds a release flag to all outgoing waypoints using the AddFlag procedure of those waypoints. It also invokes its SetClaimFlags
procedure using the created claim flag. This procedure will add the flag for the waypoint to all
incoming waypoints. It will also invoke the SetClaimFlags of all incoming connections that are
claimable using the claim flag already created. This will make sure an AGV notices that for instance the next twelve elements on its route are claimable, because of the flags it will encounter.
It will then have to claim all these elements and thus deadlocks will be prevented. MakeFlags
is a virtual abstract procedure meaning it has no actual coding in this class and all descending
classes must implement the procedure.
The Create procedure must be present to initialize the element and create the necessary
queues and semaphore if necessary. The create procedure will also call upon the CreateShape
procedure to create the shape of the waypoint. The ShowShape procedure is used to evaluate if
the shape should be showed given the current floor that is viewed by the user. If the waypoint is
on the same floor as the one viewed by the user it will be displayed. CreateShape and ShowShape
are virtual abstract procedures.
The procedures Claim and Release call the Claim and Release procedures of the elements
Semaphore. It is added to register claim and release times.
From the TWaypoint class all types of waypoints descent. The class definitions of these
elements, the TNode for crossings, TArc for paths and roads, TParking for a parking spot,
TCharging for a charging station and TElevator for an elevator. TStation and TBigStation
58
K. Davina
2012.TEL.7687
An AGVS design tool
are the objects that implement the LUS. The TStation object can be seen as a dock, it holds
the active process for removing jobs from the dock. The TBigStation object is a descendant
of TNode and couples each dock to this node using a small road. The TBigStation object also
handles the acceptance of jobs and assigning jobs and AGVs to docks.
TJob class definition
The class definition of the job element is presented in listing 5.4. It implements the procedures
Create, CreateShape and ShowShape in the same fashion as for the TWaypoint element. The
variables Origin, Destination, Priority, JobDistance and MaxDeliverTime are known when the
job is entered into the system by the job generator. Floor is the current floor of the Job, Assigned
AGV is the AGV that should pick up the job, CurrentAGV is the AGV that is currently carrying
the job and RegInfo holds information for data registration purposes.
A TJob will have a location in the system, but the orientation of the job is not implemented:
A job will be oriented automatically by the AGV carrying it.
Listing 5.4 Class definition for the TJob element
5
10
15
TJob = c l a s s ( TSimulationElement )
private
public
Floor : Integer ;
Origin : TBigStation ;
Destination : TBigStation ;
AssignedAGV : TomasShape ;
CurrentAGV : TomasShape ;
Priority : Integer ;
J o b D i s t a n c e : Double ;
RegInfo : TJobRegistrationInfo ;
MaxDeliverTime : d o u b l e ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; JOr , JDe : T B i g S t a t i o n ; Pr : i n t e g e r ) ;
p r o c e d u r e CreateShape ;
p r o c e d u r e ShowShape ;
end ;
TAGV class definition
The class definition of the AGV is presented in listing 5.5. The procedures and variables of this
class are described here:
Create, CreateShape, ShowShape
These procedures have the same function as for the other elements. It creates an instance
K. Davina
2012.TEL.7687
59
An AGVS design tool
of an object with the create procedure, creates necessary TomasQueues and assignes values
to variables. The CreateShape and ShowShape methods will create the shape displayed in
animation and will evaluate if the shape should be visible depending on the floor the user
is currently viewing;
Process
This holds the AGV process as described in listing 5.13. It is called upon by the Tomas
mechanism;
Claim, Release, PerformOtherFlagAction
These are the procedures the AGV will call when encountering a flag. Since a flag has a
action coupled to it, the AGV will run the procedure belonging to the flag action;
ToIdle, ToActive
This will put the AGV in an idle state, thus ready to receive a new assignment, or in an
active state, when the AGV got assigned a job;
MoveToAdapted
This is a custom implementation of the Tomas MoveTo command, taking into account the
floor the user is currently viewing. Moving is done without rotating the AGV: time lost
with turning is incorporated in the TurnLostTime variable that is called at every node;
SetBattery, SetEnergyConsumption
These procedures are used to set the corresponding variables;
Pickup, Dropoff, DropJob
These procedures are called when an AGV arrives at a pickup or a drop off. These also
couple or uncouple the job from the AGV shape for visualization. The DropJob procedure
is called when an AGV is assigned a job it cannot do because the job is unreachable. The
time and energy needed for performing these actions is also simulated when calling this
procedure.
PowerNeededForTask
This function calculates the power needed to perform a task. Since the AGV cannot know
on beforehand how long it will take after performing the task to reach a charging spot, some
assumptions are made in this calculation. It will calculate the minimum distance to reach
60
K. Davina
2012.TEL.7687
An AGVS design tool
the job and the minimum distance to deliver the job. The maximum of these distances will
be used as an estimate to reach a charging location. The whole power needed for driving,
pickup and drop off will be multiplied by a changeable safety factor to incorporate waiting
times and detours. Since the length of the detour depends on the algorithm used, the
position of charging stations and the nature of the jobs to be transported, it will be up to
the user to set this number.
Listing 5.5 Class definition for the TAGV element
5
10
15
20
25
30
35
40
45
TAGV = c l a s s ( TSimulationElement )
private
p r o c e d u r e Pickup ;
procedure Dropoff ;
p r o c e d u r e DropJob ;
public
Floor , AssignedElevatorNr : I n t e g e r ;
Speed : Double ;
PickupTime , DropoffTime , ElevatorEnterTime , E l e v a t o r E x i t T i m e ,
ParkingEnterTime , ParkingExitTime , ChargingEnterTime , ChargingExitTime ,
TurnDelayTime : d o u b l e ;
E l e v a t o r C a l l i n g A r r i v a l T i m e : Double ;
CurrentWaypoint : TWaypoint ;
Route , ClaimedElements : TomasQueue ;
D e s t i n a t i o n : TWaypoint ;
Load : TJob ; // Load c u r r e n t l y on−board
AssignedLoad : TJob ; // Load a s s i g n e d
RouteCalculation : RouteCalculationFunction ;
ParkCalculation : ParkCalculationFunction ;
ChargeCalculation : ChargeCalculationFunction ;
New : b o o l e a n ; // h e l p e r v a l u e f o r AGV t h a t has not y e t moved
MyBattery : TBattery ;
MyConsumption : TEnergyConsumption ;
NeedsCharging : Boolean ;
RouteToDock : Boolean ;
R e g I n f o : TAGVRegistrationInfo ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; S t a r t L o c S t r : S t r i n g ; Sp : S i n g l e ; RC:
R o u t e C a l c u l a t i o n F u n c t i o n ; CC: C h a r g e C a l c u l a t i o n F u n c t i o n ; PC :
P a r k C a l c u l a t i o n F u n c t i o n ; TiPickup , T i D r o p o f f , TiElEn , TiElEx , TiPaEn , TiPaEx ,
TiChEn , TiChEx , TiTuDe : d o u b l e ) ;
p r o c e d u r e CreateShape ;
p r o c e d u r e ShowShape ;
procedure Process ; override ;
p r o c e d u r e Claim ( F1 : TFlag ) ;
p r o c e d u r e R e l e a s e ( F1 : TFlag ) ;
p r o c e d u r e P e r f o r m O t h e r F l a g A c t i o n ( F1 : TFlag ) ;
procedure ToIdle ;
p r o c e d u r e ToActive ;
p r o c e d u r e MoveToAdapted (X, Y, Z , Step , Speed : Double ) ;
p r o c e d u r e S e t B a t t e r y ( Value : TBattery ) ;
p r o c e d u r e SetEnergyConsumption ( FDrivingEmpty , FDrivingLoaded , FParking ,
FWaiting , FPickup , FDropoff : S i n g l e ) ;
f u n c t i o n PowerNeededForTask : s i n g l e ;
end ;
K. Davina
2012.TEL.7687
61
An AGVS design tool
This class has a number of variables, most of the variables used are self-explanatory, but some
of them are highlighted here:
Speed
The maximum speed of the AGV. If the current route element the AGV is on has a lower
maximum speed, the AGV will lower its speed. Acceleration and deceleration are ignored
in this simulation, this is because the number of times and the accumulated time an AGV
has to accelerate or decelerate is small compared to the total driving time. This is mainly
because AGVs accelerate and decelerate fast and drive long stretches;
ElevatorCallingArrivalTime
This variable will be set when an AGV calls an elevator. This calling will be done at the
moment the elevator is able to claim the elevator for itself. After that the AGV might still
have to drive for quite a while, when it arrives at the elevator it will only have to wait the
remainder of the total waiting time;
Route
Contains TWaypoints, it is the route the AGV will have to travel in the order of the
TomasQueue;
ClaimedElements
A TomasQueue of all the elements the AGV currently has claimed. If the AGV passes a
flag referring to a waypoint it has previously claimed and is present in this queue it will
release it again;
Destination
Destination is set when an AGV has no route and goes to pick up a job or go to a parking
or charging station. When it finished its route Destination is nilled;
RouteCalculation, ParkCalculation, ChargeCalculation
Variables pointing to the function the AGV has to use to calculate which route it should
take or to which parking or charging station it should drive;
MyBattery
The battery the AGV is currently using. The battery class contains charge parameters
and functions to charge and de-charge the battery. The battery has user-definable values
62
K. Davina
2012.TEL.7687
An AGVS design tool
for capacity, charging speed for the fast and slow charging regions and charging turning
percentage. The charging turning percentage is the percentage at which the charging speed
has to switch from fast charging to slow charging (normally around 80%). Especially when
the AGV allows opportunity charging this option is important to incorporate;
MyConsumption
States how much the AGV consumes at different tasks. Values for pickup, drop-off, driving
loaded, driving empty, waiting during operation (for instance for crossings and in elevators)
and waiting while parking;
RouteToDock
Set to true when an AGV has a route to a specific dock at the LUS, when the AGV arrives
at a dock it will set this parameter to false again;
RegInfo
Parameters saved and used for registering the AGVs actions. The values in this array are
used to calculate the KPIs desired;
The parameters do not contain a value for the type of AGV (mono- or bi-directional). The
different time required for an AGV to turn because it is of a different type should be incorporated
in pickup and drop-off times if extra maneuvering is required. If turning is also required to enter
and exit an elevator, this delay can be incorporated in the parameters ElevatorEnterTime and
ElevatorExitTime.
TNode class definition
The class definition of the TNode element is presented in listing 5.6. It shows that all nodes are
created with a maximum capacity of one AGV at any moment by default. The user may define
a different maximum capacity, but for a node this seems illogical.
The variable Distance and the TomasQueue ShortRouteToNode can be used to save the
distance and the route to that node from the node the calculation is made from by the route
calculation function.
K. Davina
2012.TEL.7687
63
An AGVS design tool
Listing 5.6 Class definition for the TNode element
TNode = c l a s s ( TWaypoint )
ShortRouteToNode : TomasQueue ;
public
D i s t a n c e : S i n g l e ; // For u s e with C a l c u l a t e R o u t e
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; X,Y: S i n g l e ; PFloor : I n t e g e r ; Cap : I n t e g e r = 1 ) ;
p r o c e d u r e CreateShape ; o v e r r i d e ;
p r o c e d u r e ShowShape ; o v e r r i d e ;
p r o c e d u r e MakeFlags ; o v e r r i d e ;
end ;
5
10
TArc class definition
In listing 5.7 the class definition of the TArc element is presented. An arc has next to its base
coordinate a second coordinate where the arc ends. An arc is always a one way element starting at
the base coordinate and ending at the second coordinate. The length of the arc is also stored and
calculated when the arc is created. The arc is created by specifying the starting node and ending
node, it also retrieves its coordinates from these nodes. Functions for creating combinations of
arcs into roads are presented in subsection 5.1.4.
Listing 5.7 Class definition for the TArc element
TArc = c l a s s ( TWaypoint )
public
Length : Double ;
S e c o n d C o o r d i n a t e : TCoordinate ;
published
C o n s t r u c t o r C r e a t e ( ConnIn , ConnOut : S t r i n g ) ;
end ;
5
10
TParking class definition
The class definition for the TParking element is presented in listing 5.8. It implements the
required procedures CreateShape, ShowShape and MakeFlags. It also has a Create procedure
that initiates an instance and adds the created instance to a TomasQueue holding all the parking
spaces.
TCharging class definition
The TCharging class definition, in listing 5.9, is in essence the same as the TParking definition.
All the logic concerning charging is programmed into the battery class that is part of the AGV.
64
K. Davina
2012.TEL.7687
An AGVS design tool
Listing 5.8 Class definition for the TParking element
5
TParking = c l a s s ( TWaypoint )
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; X,Y: S i n g l e ; Conn : S t r i n g ; PFloor : i n t e g e r ) ;
end ;
When creating an instance that instance will be added to a TomasQueue holding all the charging
spaces.
Listing 5.9 Class definition for the TCharging element
5
TCharging = c l a s s ( TWaypoint )
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; X,Y: S i n g l e ; Conn : S t r i n g ; PFloor : i n t e g e r ) ;
end ;
TElevator class definition
The class definition for the TElevator element is presented in listing 5.10. For the elevator
element the following functions and procedures are used:
Create
With this procedure a number of items are set. First the number of elevators that are in
the group is set, next to the nodes the elevator is connected with. The elevator is created
at location X,Y and connected with small roads. If the boolean bufferroom is set to true,
it means that there is a buffer room in front of the elevator. This will create normal roads
between the elevator and the connecting node. If a value is set for the number of places in
the buffer room a road with a maximum capacity is created (see 5.1.4);
CreateShape, ShowShape, MakeFlags
These are the necessary procedures declared in the class TWaypoint;
CallElevator
function to calculate which elevator to use and how long it will take to get that elevator
at the right floor. The way this waiting time is calculated can be found in figure 5.1. It
depends on some random variables changeable by the user;
K. Davina
2012.TEL.7687
65
An AGVS design tool
RideToFloor
This function returns the elevator ride time taking into account the times for opening and
closing the elevator, the travel distance and the elevator speed;
RideMeToFloor
Moves the TSimulationElement with the elevator to the specified floor while taking the
amount of time required to move in between these floors;
GetElevatorNr
Returns the elevator number of the elevator that can be used by the AGV;
CalculateRideTime
Calculates the time the elevator takes to get from one floor to another where the floors are
designated by a number.
Listing 5.10 Class definition of the TElevator element
T E l e v a t o r = c l a s s ( TWaypoint )
public
Speed : S i n g l e ;
C u r r e n t F l o o r : Array o f I n t e g e r ;
TimeLastClaim : Array o f Double ;
E l e v a t o r O c c u p a t i o n : Array o f Boolean ;
RandWaitingTimeDist : T E x p o n e n t i a l D i s t r i b u t i o n ;
AverageWaitingTime : Double ;
RandFloor , RandOccupied : T U n i f o r m D i s t r i b u t i o n ;
OccupationChance : Double ;
DriveInTimeLoss , DriveOutTimeLoss : Double ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; X,Y: S i n g l e ; C o n n e c t i o n s : Array o f S t r i n g ;
E l s p e e d : S i n g l e ; PFloor , N r O f E l e v a t o r : I n t e g e r ; DITL ,DOTL: d o u b l e ;
OccChance , AvgWaitingTime : d o u b l e ;
BufferRoom : Boolean ; Buffe rRoomS ize : I n t e g e r =9999) ;
f u n c t i o n C a l l E l e v a t o r ( C a l l F l o o r , ElNr : i n t e g e r ) : Double ;
f u n c t i o n C a l c u l a t e R i d e T i m e ( Z1 , Z2 : S i n g l e ) : Double ;
f u n c t i o n GetElevatorNr : I n t e g e r ;
p r o c e d u r e RideMeToFloor ( PFloor , ElNr : i n t e g e r ; Sen de r : TSimulationElement ) ;
f u n c t i o n RideToFloor ( PFloor , ElNr : i n t e g e r ) : Double ; { Returns r i d e time }
end ;
5
10
15
20
25
Next to these functions and procedures the following variables, which are initiated by calling the
create statement, are implemented:
RandWaitingTimeDist, AverageWaitingTime, RandFloor, RandOccupied, OccupationChance
66
K. Davina
2012.TEL.7687
An AGVS design tool
Was the elevator just
released by another AGV?
Yes
Elevator start from floor
it was released from
Use RideToFloor function to
give elevator waiting time
No
Are all elevators occupied?
N rEl = Number of elevators not occupied by AGVs
No
P (AllElevatorsOccupied) = P (Occupied)N rEl
Assume elevator comes from
a random floor. Get floor from
RandFloor
Yes
Use RandWaitingTimeDist with an average of
AverageWaitingTime to give elevator waiting time
Figure 5.1: Process of determining the elevator waiting time
RandWaitingTimeDist is the exponential distribution with an average of AverageWaitingTime (set by the user) to calculate the waiting time when necessary (see figure 5.1).
RandFloor draws a random floor from the available floors when necessary. OccupationChance is used to calculate the chance that an elevator is available for the AGV and
RandOccupied is used to draw a value between 0 and 1 to simulate this chance;
CurrentFloor, TimeLastClaim, ElevatorOccupation
These variables hold the current floor, the time it was last claimed and if the elevator is
occupied, for all elevators separately;
Speed
The speed at which the elevators move. The time for acceleration and deceleration of the
elevator are omitted in this simulation and can be compensated by adjusting the DriveInTimeLoss and DriveOutTimeLoss parameters;
DriveInTimeLoss, DriveOutTimeLoss
These values hold the time losses associated with door opening and closing as well as sensor
delays. It can also be used to compensate for the losses when accelerating and decelerating
the elevator.
K. Davina
2012.TEL.7687
67
An AGVS design tool
For elevators the expected distribution of the elevator over the different floors is not incorporated. The simulation assumes that the chance of the elevator being at a certain floor is equal
for all floors.
TStation and TBigStation class definitions
The last elements described here are the elements that implement the LUS: the TStation and
TBigStation classes. TStation is an implementation of a dock. TBigStation couples all TStations
together to create the total implementation of the LUS.
The class definition of the TStation element can be found in listing 5.11. It implements the
standard procedures form its parent TWaypoint: Create, MakeFlags, CreateShape and ShowShape. The DeliverJob procedure is used by the AGV when it transfers the job to the TStation.
The Process procedure is the active procedure that removes jobs after a certain time. This time
is calculated using the DeliverJobRemovalTime exponential distribution with an average set by
the user.
All delivered jobs are in the JobsDeliveredQueue which are put there by the DeliverJob
procedure. All jobs waiting for pickup are in the JobsQueue, these jobs are put there by a
procedure belonging to the TBigStation class. The BelongsTo variable holds the TBigStation to
which the TStation belongs. Next to these variables the TStation class also has a Jobs variable,
for the number of jobs that passed this dock, and a MyQueueDisplay variable, which is used for
animation purposes, in this case displaying the size of the queue.
Listing 5.11 Class definition of the TStation element (implementation of a dock)
T S t a t i o n = c l a s s ( TWaypoint )
public
Jobs : i n t e g e r ;
JobsQueue : TomasQueue ;
J o b s D e l i v e r e d Q u e u e : TomasQueue ;
BelongsTo : T B i g S t a t i o n ;
DeliverJobRemovalTime : T E x p o n e n t i a l D i s t r i b u t i o n ;
MyQueueDisplay : TQueueDisplay ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; X,Y: S i n g l e ; Conn : S t r i n g ; Cap : I n t e g e r ;
PFloor : I n t e g e r ) ;
p r o c e d u r e D e l i v e r J o b ( FJob : P o i n t e r ) ;
procedure Process ; override ;
end ;
5
10
15
The class definition of the TBigStation element can be found in listing 5.12. The TBigStation
68
K. Davina
2012.TEL.7687
An AGVS design tool
class is not an extension of TWaypoint, but one of TNode. It thus behaves like a node (since it
couples all docks to the rest of the infrastructure), but implements some extra procedures and
functions.
Listing 5.12 Class definition of the TBigStation element (implementation of a station)
5
10
15
T B i g S t a t i o n = c l a s s ( TNode )
public
MyStations : TomasQueue ;
MyLoadStations : TomasQueue ;
MyUnloadStations : TomasQueue ;
DynamicLoadUnload : Boolean ;
published
C o n s t r u c t o r C r e a t e (Nm: S t r i n g ; X,Y: S i n g l e ; PFloor : I n t e g e r ;
P S t a t i o n s : a r r a y o f T S t a t i o n P a r a m e t e r s ; MinLoad , MinUnload : I n t e g e r ) ;
f u n c t i o n G e t U n l o a d S t a t i o n ( Value : P o i n t e r ) : P o i n t e r ; { AGV can a s k a t which
s t a t i o n t o un lo ad }
f u n c t i o n G e t L o a d S t a t i o n ( Value : P o i n t e r ) : P o i n t e r ;
f u n c t i o n AddJob ( Value : TJob ) : Boolean ; { Add a j o b t o one o f t h e s t a t i o n s }
end ;
All connected docks (TStation instances) are placed in one of three queues: MyLoadStations,
for docks that are for loading jobs onto AGVs, MyUnloadStations for docks for unloading jobs
from AGVs, and MyStations, for docks that can be used for both loading and unloading (dynamic
docks). DynamicLoadUnload is a boolean set to true when dynamic docks exist. The user can
define how many docks should be available for each of these functions.
The procedures CreateShape and ShowShape do not need to be defined here, the ones from
the TNode class are used. The procedure MakeFlags now also creates a flag that tells the
passing AGVs that if it has to pickup or deliver a job at this station it has to call the functions
GetLoadStation or GetUnloadStation to go to the right dock. At this moment the last part of
the route the AGV has to travel will be added to its Route TomasQueue.
The function AddJob is used to add a job to one of the docks. The station will then check
which docks are available for loading and return this dock. The process belonging to the TBigStation element will take jobs from the input queue put there by the job generator and add them
using the AddJob function.
5.1.2
Processes of the active elements
In this section the general structure of the active elements processes is described. These elements
are the AGV, the LUS, the job generator and the job distributor.
The AGV process was depicted in a flow chart in figure 3.6. In that flowchart no interaction
K. Davina
2012.TEL.7687
69
An AGVS design tool
between AGVs was present. Since the simulation requires AGVs to wait for each other, as was
explained in 4.2, some method has to be implemented to make sure the AGV claims certain
route points for itself before occupying them. This is implemented with flags along the paths
the AGV drives; the AGV will drive along a path till it reaches the next flag. At each flag it
asserts if some action has to be performed. This also creates the possibility to not only put flags
there for claiming limited resources, but also for releasing these resources and any other action
that the system controller wishes to invoke. These flags can also be put on other infrastructure
elements to invoke AGV actions before going on to the next element.
The AGV process is modeled so that it will perform the functions described in the original
flow model. The process is a loop and modeled according to the pseudo-code in 5.13. In the loop
the calls to the necessary algorithms are defined: the routing and parking algorithms. A parking
algorithm is required for both parking and for charging.
The AGV will go to a parking or charging depending on the battery charge as mentioned
in line 10 in listing 5.13. This decision is made based on two changeable simulation parameter:
the opportunity charging percentage, SPo cp, as well as the chosen parking algorithm. When the
AGV has no assigned job and its battery charge is lower than this percentage it will call the
charging algorithm, if not it will call the parking algorithm. Setting this number at 100% will
make sure AGVs will always call the charging algorithm if no job was assigned. If the AGV
should go charging and the charging algorithm does not return an available space, the AGV
will go to a parking space. This is also true the other way around. This means the number of
charging spaces and parking spaces combined should at least be equal to the number of AGVs
present in the simulation.
The procedure to check if the battery charge is sufficient is an estimation of the required
power. It calculates the power necessary to drive to the load in the shortest possible way, pick
up the load, drive to its destination in the shortest possible way, drop off the load and drive
to a charging location, all with the maximum speed of the AGV. The distance to a charging
location is estimated as the maximum of the distances for driving to the pick up and driving to
the destination. This total power consumption is multiplied by a factor for incorporating waiting
times on the route, detour length depending on the route calculator and the position of charging
70
K. Davina
2012.TEL.7687
An AGVS design tool
stations, SFreqpower , which is changeable by the user. If the current charge is not enough the
AGV will take itself out of operation and go to a CS.
When the AGV arrives at a CS it will charge at least to the minimum charging percentage,
which is a changeable simulation parameter. During the initial charge the AGV will not be
available for operation. After reaching the minimum charge it will be available for operation
again and it will keep charging in blocks of 30 seconds. This means a maximum delay of 30
seconds is introduced in responding to a job.
When an AGV is parked, it will remain at its position for blocks of 10 seconds introducing a
maximum equal delay in response time to an assigned job.
From the AGV process it becomes clear that the AGV will only move itself on an arc from
flag to flag, the only other possibility for an AGV to move is when it is in an elevator, but this
move is initiated by the elevator and not by the AGV. When on one of the other elements the
AGV will check the flags and perform the necessary actions. From the process it is also clear that
once an AGV has a route it will first complete the full route before returning to the beginning
of the process. If the system wishes to change the route or destination of an AGV it has to do
so using a flag.
The LUS also requires processes for job acceptance and delivery as described in the flowcharts
in figure 3.7 and 3.8. The delivery process is modeled according to the pseudo-code in listing
5.14. With this process the average queue length at a dock becomes visible. The average time it
takes to remove a job from a dock is a parameter that can be set for a total station. The time it
actually takes to remove the job is modeled with an exponential distribution, which is the most
probable description of the process within the in TOMAS available distributions.
The job acceptance process needs to work according to the pseudo-code in listing 5.15. If a
station has both dynamic docks and loading docks this will ensure that jobs will always be put
in a position as much to the front of the dock queue as possible and it will prefer putting jobs in
a loading dock when the start position is equal for both dynamic and loading docks.
This will also mean that for some configurations (when no specific loading docks are available
or when all docks are full) jobs might not have a location to be put in. The system will then
K. Davina
2012.TEL.7687
71
An AGVS design tool
Listing 5.13 The AGV process
5
10
15
20
25
30
AGV p r o c e s s
repeat
i f (AGV has no r o u t e )
i f (AGV has no a s s i g n e d l o a d )
i f (AGV i s a t p a r k i n g )
s t a y parked
i f (AGV i s a t c h a r g i n g )
stay charging
i f (AGV i s somewhere d i f f e r e n t )
d e p e n d i n g on b a t t e r y c h a r g e
algorithm ( f i n d parking or charging )
algorithm ( get route ) to parking or charging
i f (AGV has an a s s i g n e d l o a d )
i f l o a d i s not on board
i f p r o c e d u r e (AGV has enough b a t t e r y )
algorithm ( get route ) to pickup
else
g i v e j o b back t o c o n t r o l l e r
go c h a r g i n g
i f l o a d i s on board
a l g o r i t h m ( g e t r o u t e ) t o drop o f f
i f (AGV has a r o u t e )
w h i l e AGV has a r o u t e
e n t e r t h e f i r s t r o u t e e l e m e n t i n AGV r o u t e
i f t h e e l e m e n t i s an a r c
d r i v e from f l a g t o f l a g and p e r f o r m a c t i o n
i f t h e e l e m e n t i s not an a r c
perform a l l n e c e s s a r y f l a g a c t i o n
i f t h e e l e m e n t i s a LUS
l o a d o r un lo ad
i f un lo ad make AGV a v a i l a b l e f o r new j o b
i f t h e e l e m e n t i s an e l e v a t o r
go t o t h e r i g h t f l o o r
72
K. Davina
2012.TEL.7687
An AGVS design tool
wait and try again after some time. This time loss will then be registered.
Listing 5.14 The LUS job deliver process
5
LUS d e l i v e r p r o c e s s
repeat
w h i l e t h e number o f j o b s s t i l l s t a n d i n g a f t e r drop o f f = 0
wait
draw t h e time t h e j o b w i l l s t a n d t h e r e from e x p o n e n t i a l d i s t r i b u t i o n
w a i t drawn time
remove t h e j o b
Listing 5.15 The LUS job accept process
5
10
15
20
LUS a c c e p t p r o c e d u r e
i f t h e r e a r e empty l o a d i n g d o c k s
put t h e j o b i n t h a t dock
else
what i s t h e b e s t p o s i t i o n f o r a j o b i n a l o a d i n g dock ?
i f t h e j o b i s not i n a dock y e t
i f t h e r e a r e empty dynamic d o c k s
put t h e j o b i n t h a t dock
else
what i s t h e b e s t p o s i t i o n f o r a j o b i n a dynamic dock ?
i f b e s t p o s i t i o n f o r dynamic dock > b e s t p o s i t i o n f o r l o a d i n g dock
i f dynamic dock not f u l l
put i n dynamic dock
else
i f l o a d i n g dock not f u l l
put i n l o a d i n g dock
w a i t and t r y a g a i n
r e g i s t e r l o s t time
The process of the job generator is two-fold. One part is used to calculate the jobs before
the simulation. In this case there are a lot of job generators active. When all these jobs are
calculated another job generator is used to take all these jobs one by one and introduce them
to the AGV system. The former job generators are created for each pair of stations and each
distribution associated with those stations. The pseudo-code for this process can be found in
listing 5.16. This process is different for each type of distribution. The latter job generator,
listed in 5.17, is a single generator introducing all jobs into the AGV system.
The last active process required for the system is the job dispatcher. This element assigns
jobs to AGVs is one of the blocks in the system controller process in figure 3.9. This element
dispatches jobs to the AGVs according to one of the algorithms presented in 4.1.1. The general
process of this element can be found in listing 5.18. This is a general description of this process
which can be different for some algorithms. For algorithms that redirect an assigned AGV when
K. Davina
2012.TEL.7687
73
An AGVS design tool
Listing 5.16 The Job Generator process for creating jobs
5
Job G e n e r a t o r pre−p r o c e s s
w a i t t i l l s t a r t time
r e p e a t w h i l e time < end time
sample i n t e r −a r r i v a l time from d i s t r i b u t i o n o r f i x e d v a l u e
w a i t i n t e r −a r r i v a l time from d i s t r i b u t i o n o r f i x e d v a l u e
c r e a t e j o b f o r g i v e n s t a t i o n p a i r and g i v e n p r i o r i t y
s a v e j o b with c u r r e n t time
Listing 5.17 The Job Generator process for introducing jobs into the AGV system
5
Job G e n e r a t o r p r o c e s s
repeat
g e t f i r s t j o b s o r t e d on time from s a v e d j o b s
w a i t t i l l j o b time
put j o b i n o r i g i n a t i n g s t a t i o n queue
p r o c e d u r e put j o b i n dock
remove f i r s t j o b from s a v e d j o b s
a new job enters the system to a job closer to its current location line 5 and 6 of this process will
not be applicable in this fashion. How the algorithms are actually implemented can be found in
section 5.2.
Listing 5.18 The job dispatcher process
5
10
Job D i s p a t c h e r p r o c e s s
repeat
i f number o f u n a s s i g n e d j o b s = 0
wait
i f number o f a v a i l a b l e AGVs = 0
wait
c h o o s e an u n a s s i g n e d j o b based on a l g o r i t h m
c h o o s e an AGV based on a l g o r i t h m
a s s i g n t h e j o b t o t h e AGV
make t h e AGV u n a v a i l a b l e
make t h e j o b a s s i g n e d
5.1.3
Assumptions and limitations of the programmed model
Animation displays only one level. Elevators are always shown, and objects moving through an
elevator are also visible. The color of the arc represents the type of arc and if AGVs may drive in
both directions. The AGVs will however drive through each other during animation; the actual
driving next to each other was not modeled to ease programming. Next to that there is no real
added value except for making it look nicer. Green lines are for roads where AGVs can drive in
both directions. Grey lines are for one way roads, AGVs can only move in one direction. Dark
green lines are roads traversable in both directions, but not simultaneously.
74
K. Davina
2012.TEL.7687
An AGVS design tool
If a model is required where AGVs pass each other instead, two way roads may be modeled
as two separate tracks and crossings may be modeled using more than one node as depicted in
figure 5.2. This requires far more input from the user of the program but still gives the possibility
to model individual lanes.
Multiple elevators are modeled as one. If there is an elevator block of two elevators specified,
then one will see at maximum two AGVs simultaneously in one elevator. Elevator waiting times
are modeled using a exponential distribution, which, according to experts is the most appropriate
estimation method.
Figure 5.2: Two ways in which roads and crossing can be modeled. The top version is less work,
but AGVs will seem to go through each other, the bottom version will make the animation more
realistic. For the simulation output it will approximately yield the same results.
5.1.4
General procedures and functions
CreateRoad
This procedure can be used to create a road: it will create two TArc elements, one from the first
node to the second and one from the second to the first node. For this type of road no flags are
set for claiming or releasing the element.
K. Davina
2012.TEL.7687
75
An AGVS design tool
CreateRoadWithCapacity
This procedure creates a road with a capacity defined by the user. This capacity will be the
same for both directions. It will create two TArc elements with their own TomasSemaphores.
Flags for claiming and releasing will be set upon initiation of the simulation.
CreateOWArc
This procedure creates a small road: it will create two TArc instances and only one semaphore
with a capacity of one AGV. The two arcs will share this semaphore. Flags for claiming and
releasing will be set upon initiation of the simulation. Since this capacity is very limited, usage
of this element should be minimized if the layout allows it as depicted in figure 5.3.
1 AGV / 50 sec
10 m
unlimited capacity
unlimited capacity
1 AGV /
10 sec
1 m/s
Figure 5.3: Limit the use of one way arcs - example. The above version allows 72 AGVs per
hour, the bottom version 360 AGVs per hour. For color definitions see 5.1.3.
5.2
Implemented Control Algorithms
In this section the logic and/or code of the algorithms used are presented. First the routing
algorithms are elaborated. Secondly, the dispatching algorithms are presented. Finally the
parking algorithms are discussed.
76
K. Davina
2012.TEL.7687
An AGVS design tool
5.2.1
Routing algorithms
Dijkstra’s algorithm (DA)
Dijkstra’s algorithm is the simplest algorithm to calculate a route, in Dijkstra’s case the shortest
route. The working of Dijkstra’s algorithm is presented in listing 5.19. This algorithm is coded
and presented to the user as one of the choices for routing the AGV. This algorithm will always
be slower in computer calculation time than the A* algorithm for single floor AGV systems, this
changes because of the presence of elevators. Dijkstra’s algorithm is however a good algorithm
for verifying the system and is almost as fast in hospitals with a small number of nodes or possible
roads.
Listing 5.19 Dijkstra’s algorithm in pseudo-code
5
10
15
20
FUNCTION R o u t e C a l c u l a t o r ( S o u r c e node , T ar get node )
Make queue with a l l nodes
S e t d i s t a n c e t o i n f i n i t y f o r a l l nodes
S e t s h o r t e s t r o u t e t o node t o n u l l f o r a l l nodes
Set d i s t a n c e to zero f o r source
WHILE node queue i s not empty
Take node with s m a l l e s t d i s t a n c e from node queue
IF t h i s node i s t h e t a r g e t node
return route
IF t h i s node has d i s t a n c e i n f i n i t y
Ta rge t node i s not r e a c h a b l e
r e t u r n empty r o u t e
Remove node from node queue
C a l c u l a t e which nodes a r e c o n n e c t e d t o t h i s node
FOR EACH o f t h e s e nodes
C a l c u l a t e t h e d i s t a n c e t o t h a t node from c u r r e n t node
Add d i s t a n c e t o c u r r e n t node f o r t o t a l d i s t a n c e
IF t o t a l d i s t a n c e < s a v e d d i s t a n c e t o t h a t node
s a v e d i s t a n c e t o t h a t node d i s t a n c e
s a v e r o u t e t o t h a t node :
s h o r t e s t r o u t e t o c u r r e n t node +
r o u t e t o c o n n e c t e d node
A* algorithm (ASA)
The A* algorithm uses a cost function to calculate a route to the destination as explained in
4.1.2. The A* algorithm itself will produce the same result as Dijkstra’s algorithm, it just requires
less calculation time. To apply this algorithm an estimation is required for the distance to the
destination. One option is to use the direct distance to the destination. The problem is that an
AGV that has to change floors will first have to go to an elevator. Using this way of estimation
might send the AGV in the wrong direction.
Another option is to check if floors have to be changed and then simply go to the nearest
K. Davina
2012.TEL.7687
77
An AGVS design tool
elevator. From that elevator the AGV can drive to its destination using the ASA. The problem
with this way is that the found route is not necessarily the shortest route.
A third option is to calculate the straight distances from the endpoint to all elevators and do
the same for the to be calculated nodes. Then the best elevator (shortest distance to endpoint)
can be found and the function will help the AGV in the right direction without overestimating
the distance to the endpoint.
To further increase the calculation speed of this algorithm at the cost of some accuracy the
part of the cost function estimating the distance to the endpoint can be multiplied by a factor
. The found route will have a maximal error of − 1. The pseudo-code for this algorithm
can be found in listing 5.20. One can see that routes containing more than one elevator where
the different elevators will not go directly from the originating floor to the destination floor are
not evaluated for the estimation part of the costs. With this type of elevator configuration this
algorithm will not necessarily find the shortest route. If the only possibility to get to the endpoint
is using multiple elevators the estimation of the costs will be a big number until a node that
has a direct elevator connection to the endpoint is found. This first part is actually the same as
Dijkstra’s algorithm. After the node with a direct elevator connection to the end node is found
the A* algorithm is used.
Expected travel time algorithm (ETT)
With this algorithm the time to reach a destination instead of the distance to the destination
is used. It is an adaption of Dijkstra’s algorithm, but instead of using the distance it uses the
average travel time on each waypoint. This only works when all AGVs have the same speed.
This should make the AGV avoid congested areas. For the elevators the actual ride time is used
instead of the average time on the waypoint. Firstly because the time spend in the elevator depends on the number of floors to be crossed. Secondly because AGVs will never have additional
waiting time in elevators.
Since the waiting time in front of an elevator is incorporated when calculating the expected
travel time, this algorithm will still divide the AGVs over all elevators present in the system, if
the elevators have the same characteristics with respect to waiting time and AGVs have to wait
for each other at the elevators. If the system has such a big overcapacity with respect to elevators
78
K. Davina
2012.TEL.7687
An AGVS design tool
Listing 5.20 The A* algorithm as implemented in pseudo-code
e p s i l o n =1
5
10
15
20
25
30
FUNCTION R o u t e C a l c u l a t o r ( S o u r c e node , T ar get node )
Make queue with a l l nodes
S e t c o s t t o i n f i n i t y f o r a l l nodes
S e t s h o r t e s t r o u t e t o node t o n u l l f o r a l l nodes
Set c o s t to zero f o r source
While nodequeue i s not empty
Take node with l o w e s t c o s t
I f t h i s node i s t h e t a r g e t node
return route
I f t h i s node has c o s t i n f i n i t y
t a r g e t i s not r e a c h e a b l e
r e t u r n empty r o u t e
Remove node from queue
C a l c u l a t e which nodes a r e c o n n e c t e d t o t h i s node
For each o f t h e s e nodes
P a t h c o s t = t h e d i s t a n c e t o t h e node
// E s t i m a t e d i s t a n c e t o end
I f t h e node i s on t h e same f l o o r a s t h e Tar get node
E s t i m a t e c o s t = d i s t a n c e with p y t h a g o r a s
I f t h e node i s on a n o t h e r f l o o r than Ta rge t node
C a l c u l a t e d i s t a n c e from t h e node t o e l e v a t o r s with p y t h a g o r a s
C a l c u l a t e d i s t a n c e from e l e v a t o r s t o t a r g e t with p y t h a g o r a s
E s t i m a t e c o s t = Min ( t o t a l d i s t a n c e f o r each e l e v a t o r )
I f no d i r e c t e l e v a t o r c o n n e c t i o n E s t i m a t e c o s t = 1000000000
Totalcost = Pathcost + e p s i l o n ∗ Estimatecost
I f T o t a l c o s t < s a v e d t o t a l c o s t f o r t h e node
Save new t o t a l c o s t
Save new s h o r t e s t r o u t e t o t h e node
K. Davina
2012.TEL.7687
79
An AGVS design tool
that AGVs almost never have to wait for each other, AGV waiting times for the elevator are
dominated by the average elevator waiting time parameter, in which case the choice of route is
not dominated by the elevators. Some elevators might be more heavily used in this case than
others.
Distributed traffic pressure algorithm (DTP)
For this algorithm a formula is used to correct the distance from one node to another keeping
into account the traffic pressure on a route element. This will make sure AGVs choose routes
that evenly divide the traffic pressure. If, for instance, AGVs can pass a certain corridor without
waiting, but with a high number of AGVs passing per hour all personnel in that section will
experience a high nuisance with respect to AGVs. Using this algorithm will distribute AGVs
more evenly. The influence of the traffic pressure can be tuned with the parameter . The
function for calculating the corrected distance, Dcorrected , is:
Dcorrected = D˙T P ,
(5.1)
where D is the original distance from one node to another and T P is the traffic pressure in
passing AGVs per hour. By changing the influence of the traffic pressure on the correction can
be changed. This also depends on the overall traffic pressure; if a busy part in the infrastructure
handles 4 AGVs per hour should be different than for a busy part handling 25 AGVs per hour.
If = 1 the DTP will behave as Dijkstra’s algorithm. For any value > 1 the traffic pressure is
included in the calculation. Graphs for different values of T P and can be found in figure 5.4.
The algorithm is an adaption of Dijkstra’s algorithm: the calculation is performed according to
Dijkstra where distances are corrected using the presented function.
5.2.2
Dispatching Algorithms
Next to the algorithms used for routing, a number of dispatching algorithms are implemented.
The algorithms are chosen from the ones found in literature (section 4.1.1). Since dispatching
is done centrally, both types of algorithms can be used. If a WIDA is used always the first job
is taken from the queue and the algorithm is used to find a certain AGV. This means that the
choice of job is on a first come first served basis. If a VIDA is used always the first AGV that
came available is taken and the algorithm is used to find a certain job. The choice of AGV in
80
K. Davina
2012.TEL.7687
An AGVS design tool
25
=1
= 1.1
= 1.25
= 1.5
Correction ratio
20
15
10
5
0
0
1
2
3
4
5
6
Traffic pressure T P
7
8
9
10
Figure 5.4: Correction ratios for the distributed traffic pressure algorithm for different values of
K. Davina
2012.TEL.7687
81
An AGVS design tool
this case is on a first come first served basis.
If the load on a system is high and the AGVS forms the bottleneck, the choice of AGVs for a
certain job is always limited to one. This is because the AGVs will come available in the system
one at a time, which is the case for a standard production system. In this case a WIDA will pick
this AGV for certain, no matter which algorithm is used, thus rendering it useless. Therefore a
VIDA should be used.
If the load on the system is low and multiple AGVs are available for a pickup, the number
of jobs to choose from for the dispatcher will be one, because the dispatcher is triggered at the
instance a job is created. Using a VIDA algorithm will, in this case, always pick the single
available job, no matter the algorithm, thus rendering it useless. Therefore a WIDA should be
used.
A WIDA and VIDA can be combined where the one chosen at any time depends on the load
on the system. This should be done primarily because of the distribution of the load on the
system during the day as was depicted in figure 2.5. The combination can also be made in the
sense that the first algorithm ranks the stations, in case of a VIDA, or AGVs, in case of a WIDA,
and after that the other algorithm is initiated. For example, the minimum remaining outgoing
queue size (MROQS) algorithm (VIDA) can be used to rank stations, and when the station that
is most critical is found, use the nearest vehicle algorithm (NV) to find the nearest vehicle for
that station. These combinations were also made in literature ([ET84]) The impact of this choice
compared to standard algorithms is researched in chapters 6 and 8.
If a combination is made with the first come first serve algorithm (FCFS) or first available
vehicle algorithm (FAV) algorithm, it actually means that this part can be ignored to get the
traditional algorithm name. For instance, the FCFS/NV algorithm is the same as the in literature
described NV algorithm. If this is the case for a certain algorithm, it is stated with its description.
The algorithms implemented as well as their specific code is described here. The algorithm names
are in the form VIDA/WIDA. Algorithms that work de-central are not considered here, these
cannot be tested with this centrally controlled system.
FCFS/FAV
In this algorithm, a combination of FCFS and FAV, AGVs are added to an AGV queue upon
creation and when they become idle again. Next to that jobs entering the system are added to
82
K. Davina
2012.TEL.7687
An AGVS design tool
a job queue. In this algorithm the first AGV in the AGV queue is coupled to the first job in the
job queue. The pseudo-code for the algorithm can be found in listing 5.21. This algorithm is the
same as the FCFS and FAV algorithms used separately.
Listing 5.21 The FCFS/FAV dispatching algorithm in pseudo-code
5
PROCEDURE Dispatching FCFS FAV
repeat
f i n d t h e f i r s t j o b i n t h e u n a s s i g n e d j o b s queue
f i n d t h e f i r s t AGV from t h e a v a i l a b l e AGV queue
r e t u r n j o b and AGV t o t h e j o b d i s p a t c h e r
MOD-FCFS/FAV
This algorithm has one change with respect to the FCFS/FAV algorithm: it uses modified first
come first serve algorithm (MOD-FCFS). When an AGV becomes idle at a station it will first
take a job from that station before taking on a job originating at a different station. The pseudocode for this algorithm can be found in listing 5.22. This algorithm is the same as the standard
MOD-FCFS algorithm.
Listing 5.22 The MOD-FCFS/FAV dispatching algorithm in pseudo-code
5
PROCEDURE Dispatching MODFCFS FAV
repeat
f i n d t h e f i r s t AGV from t h e a v a i l a b l e AGV queue
l o o k f o r a j o b a t t h e s t a t i o n t h e AGV i s a t
i f there i s a job
take that job
e l s e f i n d t h e f i r s t j o b i n t h e u n a s s i g n e d j o b s queue
MOD-FCFS/NV
This is a combination of the MOD-FCFS and NV algorithms. This combination will take the
job that first entered the system and that job will get the nearest AGV available. If the system
is highly loaded, the influence of choosing this algorithm over the two previous ones should be
negligible, since AGVs will only become available one by one: only one AGV will be available
for handling the load. In that case the VIDA part of the algorithm will be used, which is the
MOD-FCFS algorithm. The pseudo-code for this algorithm is presented in listing 5.23.
K. Davina
2012.TEL.7687
83
An AGVS design tool
Listing 5.23 The MOD-FCFS/NV dispatching algorithm in pseudo-code
5
10
15
PROCEDURE Dispatching MODFCFS NV
repeat
f o r each a v a i l a b l e AGV
l o o k f o r a j o b a t t h e s t a t i o n t h e a v a i l a b l e AGV i s a t
i f there i s a job
take that job
i f there i s a job
i f t h e j o b and AGV a r e a t t h e same l e v e l
use pythagoras
i f t h e j o b and AGV a r e a t d i f f e r e n t l e v e l s
c a l c u l a t e t h e d i s t a n c e from t h e AGV t o a l l e l e v a t o r s
use pythagoras
c a l c u l a t e t h e d i s t a n c e from t h e Job t o a l l e l e v a t o r s
use pythagoras
take the e l e v a t o r g i v i n g s m a l l e s t d i s t a n c e
f i n d n e a r e s t AGV
MOD-FCFS/HRBC
This dispatching routine combines MOD-FCFS and a highest remaining battery charge (HRBC).
This algorithm will only show a difference with the FCFS/FAV and MOD-FCFS/NV algorithms
when the system is lowly loaded. This can be a good algorithm when all AGVs only charge in the
night and during the day the load should be divided among them to make sure all AGVs remain
available for delivering loads. The advantage of this is that when a peak starts, all AGVs can
still be available to handle this peak. In a system where battery capacity is not high enough to
make it through the day, this algorithm introduces a problem: all AGVs will have their battery
empty at approximately the same moment. All AGVs will go charging and the system will have
a capacity problem. For this case the MOD-FCFS/LRBC in subsection 5.2.2 might be a better
choice. The implementation of this algorithm can be found in listing 5.24.
Listing 5.24 The MOD-FCFS/HRBC dispatching algorithm in pseudo-code
5
10
PROCEDURE Dispatching MODFCFS HRBC
repeat
l o o k f o r a j o b a t t h e s t a t i o n t h e a v a i l a b l e AGV i s a t
i f there i s a job
take that job
i f there i s a job
check remaining bat te ry c a p a c i t y
f i n d AGV with h i g h e s t c a p a c i t y
84
K. Davina
2012.TEL.7687
An AGVS design tool
MOD-FCFS/LRBC
This dispatching method performs in a similar way as the MOD-FCFS/HRBC algorithm in
subsection 5.2.2 with the only difference that it picks the AGV with the lowest remaining battery
charge instead of the one with the highest charge. This will make sure AGVs will go charging
sooner in calm times and the number of AGVs charging simultaneously will keep low. The
downside of using this algorithm is that there are less moments in time when all AGVs are
available for work.
STT/NV
This algorithm produces a high system throughput but can ignore stations lying far outside the
rest of the system. It will calculate which job can be picked up the fastest given the AGV that
just came available. When multiple AGVs are available for one job it will pick the AGV closest
to the job. The implementation of this algorithm can be found in listing 5.25.
Listing 5.25 The STT/NV dispatching algorithm in pseudo-code
5
10
15
20
25
30
PROCEDURE Dispatching STT NV
i f number o f a v a i l a b l e AGVs > 1
// p o s s i b l e improvement i f m u l t i p l e j o b s become
// a t t h e same time : h u n g a r i a n method
// i f m u l t i p l e j o b s a r r i v e t o t h e system a t t h e
// i t p r o b a b l y o c c u r s a t a s i n g l e s t a t i o n
// t h u s u s e n e a r e s t v e h i c l e a l g o r i t h m
take the f i r s t job
s e t job
i f t h e j o b and AGV a r e a t t h e same l e v e l
use pythagoras
i f t h e j o b and AGV a r e a t d i f f e r e n t l e v e l s
c a l c u l a t e t h e d i s t a n c e from t h e AGV t o a l l
use pythagoras
c a l c u l a t e t h e d i s t a n c e from t h e Job t o a l l
use pythagoras
take the e l e v a t o r g i v i n g s m a l l e s t d i s t a n c e
f i n d n e a r e s t AGV
s e t AGV
e l s e ( 1 AGV a v a i l a b l e )
t a k e t h e a v a i l a b l e AGV
s e t AGV
l o o k f o r j o b s a t c u r r e n t AGV s t a t i o n
s e t job
i f no j o b
w h i l e not a l l s t a t i o n s c a l c u l a t e d and no j o b
c a l c u l a t e t r a v e l time t o c l o s e s t s t a t i o n
are there jobs a v a i l a b l e at t h i s s t a t i o n
s e t job
s e t s t a t i o n as c a l c u l a t e d
r e t u r n AGV and Job
K. Davina
2012.TEL.7687
available
same time ,
elevators
elevators
85
An AGVS design tool
5.2.3
Parking (and charging) algorithms
The algorithms in this section can be implemented for finding a parking spot or a charging
station. It depends on the AGV which of the two is used at a certain moment depending on
the user defined parameters for the AGV battery. The algorithm always returns a waypoint as
the destination, so even when the AGV asks for a parking place, the algorithm can still return a
charging station instead of a parking spot if this would optimize the situation. Once a parking
spot or charging station is returned it is directly claimed by the AGV, before it starts driving.
NPA
The nearest parking algorithm (NPA) uses Dijkstra’s algorithm to calculate the distance to
available parking places. The one nearest and available is returned by the algorithm. For
charging stations this works in exactly the same manner.
5.3
Program workflow and data handling
The program has to go through some steps before the user has the output. First the user should
be able to define the layout (nodes, roads, elevators, charging and parking locations and the
loading and unloading stations), the number and position of the AGVs and the jobs the system
should handle in the simulation.
Since the way jobs enter the system can be very different for each station and moment of the
day, the choice is made to first calculate all the jobs the system will have to handle, before doing
the simulation itself. This provides a job list from which the simulation is performed. This job
list can also be used to run several scenarios in which layouts are changed. Using the same job
list makes for easier comparison of these different scenarios.
After all jobs are calculated a simulation run can be initiated either with or without animation. When the simulation is finished the data is saved and can be interpreted. The data should
be displayed using the KPIs defined at an earlier stage.
86
K. Davina
2012.TEL.7687
An AGVS design tool
5.3.1
Data interaction and saving in the program
To ease reuse and support easy changing of existing layouts, the program should provide an
option for saving and loading of the scenarios with their respective outputs. Since the program
works in multiple steps the data also has to be saved in between these steps. To make sure all
data is correctly transferred between all these steps a consistent system to save and load data
should be chosen.
The simple choice is to save all data in text files. The negative site of this choice is the speed
at which programs seek data in text files. Next to this the data in such a file is also almost
unreadable for a user viewing the raw data.
Another possibility is to use a database. The Delphi program supports a number of database
types from which the user may choose. Since only one user at a time uses the same simulation, the
database can be a stand-alone database. For ease of use a database type is chosen that does not
require any extra installation on the systems used at Deerns: Microsoft Access. This database
type also provides an easy way to open the database files and create any report necessary.
Since this database type also provides good support, the choice is made to save all data in
Access databases. The user will be presented with an empty database on program startup, but
he can choose to open a previously saved database. All data will be in this single database, both
the input and output of the simulation.
5.3.2
Generating and interpreting program output
During the simulation run data is saved to the database. The way this data is saved is pre-defined
and elaborated here.
The data is stored in 4 tables: one for AGV data, one for job data, one for claim data and
one for queue data. All this data is saved with the following parameters: name (can be the
AGV name, the job name, the waypoint name or any other), time (the simulation time), regtype
(a designation explaining the type of registration) and a regvalue (the value that needs to be
registered). The regtype designations are summed up in appendix D. From this data in its raw
form simple queries can be used to extract the data needed for calculating the key performance
indicators (KPI).
K. Davina
2012.TEL.7687
87
An AGVS design tool
88
K. Davina
2012.TEL.7687
Chapter 6
Verification and Validation of the
model
To make sure the created program does what it intends to do and gives useable output, verification
and validation (V&V) has to be performed. According to [Sar05] the V&V steps displayed in
figure 6.1 have to be performed: conceptual model validation, computerized model verification,
operational validation and data validity. These four V&V steps are further elaborated in this
section. Next to that the actual techniques applied within these steps are chosen and justified
and the result obtained during the V&V process are presented.
6.1
Conceptual Model Validation
With this step the translation of the real system to the conceptual model is checked. The basic
steps and procedures that are present in the system as they were described in chapter 3 were
validated with face validation and traces, which are the preferred methods according to [Sar05] .
Face validation is done by system experts to check wether the logic of the system model is correct
and if the model is reasonable for its purpose. This is done by checking the system process flow
charts. Traces can also be done by experts and checks if entities move through the sub-models
and the total model with consistency and the necessary accuracy. The experts consulted are
listed in appendix E.
89
$*# /(4(3*,&"1# '&20
0*-)1'%#.3%2(-*2%,#&'#$%(#)*")(,$0.3#2*/(3#&2,3(2("$(/#
'%*+"#&"#J&10-(#Z7#
*"#.#)*2,0$(-7#8%(#)*")(,$0.3#2*/(3#&'#/(4(3*,(/#$%-*01%#
/(4(3*,&"1#'9'$(2#
."# "&",/4.4( "&2( -*2%,.&$( )5"4%># $%(# )*2,0$(-&N(/# 2*/(3#
3.$('#4(-&5&).$&*"#."
&'#/(4(3*,(/#$%-*01%#.#0*-)1'%#()#*$#"--.&$("&2(.-),%6
8%&'# ,.-./&12
-%&'"'.*&( )5"4%># ."/# &"5(-(")('# .F*0$# $%(# ,-*F3(2# ("$&$9#
An AGVS design tool
."/#.#@&203.$&*"#G
.-(# *F$.&"(/# F9# )*"/0)$&"1# )*2,0$(-# (;,(-&2("$'# *"# $%(#
8%(-(#(;&'$#'*2(#4/
)*2,0$(-&N(/#2*/(3#&"#$%(#%7)%#.-%&'"'.*&()5"4%7#
*5# +%&)%# ."# 0"/(-'
#
/(')-&F(# $%(# )%.-.)
#
"+,-./0*123435*
$&$9E#."/#,*''&F39#&$
#
6)573/08#
"&2( #%41,'4# .-(# *F$
#
)%#.-%&'.&$E#*"#$%(
#
9,2:/;3<=.#
D;/+=34,2=.#
####(,>/.#
F9# "+4'#"0'.&$# +%.
##?=.4>=34,2#
#?=.4>=34,2
#
."/#F9#5/)*'5%4.3.&
#
'&203.$&*"#2*/(3#(
#
##2=.5747#
1C;/+40/23=34,2#
*5# '9'$(2# $%(*-&('#
#####=2>##
#
##%=3=*
#
*(,>/.42B
."/# -('03$'7# @9'$(2
#
?=.4>435#
'5%*#/(9",.2"'.*&7#8
#
'*"#*5#'9'$(2#$%(*#
$%(#/*2.&"#$%(#$%(*
#
9,0;<3/+#"+,B+=0042B#
9,0;<3/+4@/>*
9,2:/;3<=.**
&'#.1-((2("$7##8%&'#
#
###=2>#&0;./0/23=34,2#
(,>/.#
(,>/.#
$*#F(#)*"/0)$(/#*"#
#
G(#"*+#/&')0'
#
'3&1%$39#2*-(#)*2,
#
9,0;<3/+4@/>#
$%(# *$%(-# ,.-./&12
#
######(,>/.#
/(4(3*,(/# 5*-# .# '($
#
#?/+4A4:=34,2#
0%)'1",(-*2%,#&'#$%
#
$.$&*"# A2&2&)E# *5# $%
J&10-(#KO#@&2,3&5&(/#P(-'&*"#*5#$%(#Q*/(3&"1#R-*)(''#
Figure 6.1: Verification and Validation processes in modeling
*5#.#,.-$&)03.-#'$0/9
#
.# +-&$$("# /($.&3(/# /
G(# "*+# -(3.$(# 2*/(3# 4.3&/.$&*"# ."/# 4(-&5&).$&*"# $*#
',()&5&).$&*"# 5*-#,$%&'# '&2,3&5&(/# 4(-'&*"#
*5#Verification
$%(# 2*/(3&"1# ,-*)(''7# A@((# J&16
6.2 Computerized
Model
)(,$0.3#2*/(3#*"#.
0-(# K7E# 8*&0%)'1",( -*2%,( 9",.2"'.*&# &'# /(5&"(/# .'# /($(-6
,"'.*&( -*2%,# &'# $%(
2&"&"1# $%.$# $%(# $%(*-&('# ."/# .''02,$&*"'# 0"/(-39&"1# $%(#
In this part the translation of the conceptual model to the programmed model has to be verified.
,0$(-# '9'$(2# '0)%#
)*")(,$0.3#2*/(3#.-(#)*--()$#."/#$%.$#$%(#2*/(3#-(,-('("6
This can be done
using*5#
multiple
techniques.("$&$9#
The techniques
used here are:
$%(# 2*/(37# 8%(# 4.$.$&*"#
$%(# ,-*F3(2#
&'# S-(.'*".F3(T#
5*-#animation,
$%(# &"6 comparison
/.$.#."/#-('03$'#5-*
$("/(/#,0-,*'(#*5#$%(#2*/(37#8*-)1'%#.3%2(-*2%,(9%#.:.0"6
with mathematical
models, degenerate tests, extreme condition tests, internal validity, parameter
.&$E#*"#$%(#'&203.$&
'.*&#&'#/(5&"(/#.'#.''0-&"1#$%.$#$%(#)*2,0$(-#,-*1-.22&"1#
variability analysis and traces.
6.2.1
Animation
132
The TOMAS package for Delphi provides animation in a basic 3D view. Each of the elements
has a simple representation which is used to create the animation. Studying this animation gives
insight in the correctness of the model.
After studying the animation for the different models created no inconsistencies were detected
and as far as animation goes the system performs according to the way it was supposed to be
programmed.
90
K. Davina
2012.TEL.7687
An AGVS design tool
6.2.2
Comparison with mathematical models
For some simple systems mathematical models exist that calculate the queue sizes and average
time in the system. This can be compared with the output of the simulation. For the system in
figure 6.2 the system can be described as a queueing system which can be described as (using
Kendall’s notation) an M/D/1 for the pickup of jobs and a D/M/1 system for drop-off of jobs.
The first queue server system is tested using case 1 where the time after pickup by the AGV is
known. For the second system the first part of the system is fixed and can be calculated, the
drop-off by the AGV is done at a fixed rate and the jobs leave the system at an exponential rate.
The values expected from these scenarios are as follows:
0m
P
average arrival rate:
case 1: 1 job / 60 sec (exponential)
case 2: 1 job / 50 sec (fixed)
1 m/s
A
B
25 m
average removal rate:
case 1: 0 sec / job
case 2: 1 job / 40 sec
(exponential)
0m
Figure 6.2: Simple model used for validation by comparison with mathematical models
Case 1 The driving time for a job should always be 25 seconds. The time it takes to remove
the job from the system after it was dropped off is 0 seconds. The average time for a job in the
queue in a M/D/1 system is given by the formula:
w=
ρ
2µ(1 − ρ)
(6.1)
where λ = 60 jobs per hour, µ = 72 jobs per hour and ρ = 60/72 = 5/6. This results in:
w=
5/6
= 5/144 = 0.035 hours = 125 seconds.
2 ∗ 72 ∗ 1/6
(6.2)
The average time a job is in the system should be 150 seconds. The average length of the
K. Davina
2012.TEL.7687
91
An AGVS design tool
pickup queue is given by the formula:
Q=
Case 2
ρ2
25/36
=
= 25/12 = 2.1 jobs.
2(1 − ρ)
2 ∗ (1 − 5/6)
(6.3)
The average time a job is waiting for pickup is 0 seconds. The driving time for a
job is 25 seconds. A job will arrive at the drop-off point every 50 seconds. The times between
removing a job from the system is distributed exponentially and the system is thus a D/M/1
system. The average waiting time can be found in tables from [Pag82] and are for this type of
system always a bit smaller than those of a M/D/1 system. From the tables the average waiting
time is estimated with ρ = 72/90 = 0.8 as 68 seconds. Adding the driving time of 25 seconds
the time in the system should be 93 seconds.
Results
As can be seen from the graph the average waiting times correspond with the numbers from
mathematical models. Next to this the driving time for a job was always 25 seconds and the
time it took to remove a job from the system was always 0 seconds.
92
K. Davina
2012.TEL.7687
An AGVS design tool
Average Waiting Time (s)
Mathematical model comparison: Average waiting time
180
180
160
160
140
140
120
120
100
100
80
80
60
60
40
40
Station A case 1
Station B case 2
Figure 6.3: The average waiting time as a result of the simulation. The simulation was run 10
times with TomasSeeds 1 to 10. The left box plot shows the average waiting time for Case 1,
which was algebraically calculated as 125 seconds. The right box plot shows the average waiting
time for Case 2, which was obtained from [Pag82] as 68 seconds.
K. Davina
2012.TEL.7687
93
An AGVS design tool
Mathematical model comparison: Average queue length
3
3
Average number in queue
2.5
2.5
2
2
1.5
1.5
1
1
0.5
0.5
Station A case 1
Station B case 2
Figure 6.4: The average queue length as a result of the simulation. The simulation was run 10
times with TomasSeeds 1 to 10. The left box plot shows the average queue length for Case 1,
which was algebraically calculated as 2.1. The right box plot shows the average queue length for
Case 2.
94
K. Davina
2012.TEL.7687
An AGVS design tool
6.2.3
Degenerate tests
According to [Sar05], in a degenerate test the degeneracy of the model’s behavior is tested. For
this test a simple mode is created with one AGV and two stations, each with one dock. The
AGV can continue its work indefinitely without service or charging. With the setup as displayed
in figure 6.5 this would result in a growing number of jobs waiting for pickup (on average 18
per hour are added to the queue) and a growing number of jobs waiting to be removed from the
system (on average 12 per hour are added to the queue).
P
1 m/s
average arrival rate:
1 job / 40 sec
(exponential)
A
B
25 m
average removal rate:
1 job / 60 sec
(exponential)
Figure 6.5: Simple model used for degenerate validation test
Results
As can be seen from figure 6.6 the outcomes of the simulation are conclusive with the on beforehand calculated values.
K. Davina
2012.TEL.7687
95
An AGVS design tool
Queue length
Degenerate test queue length results after 24 hours
550
550
500
500
450
450
400
400
350
350
300
300
250
250
200
200
Station A out queue
Station B in queue
Figure 6.6: Simulation results for degenerate testing. With the given arrival rate and removal rate
the number of items in the queue after running for 24 hours should be 432 and 288 respectively.
96
K. Davina
2012.TEL.7687
An AGVS design tool
6.2.4
Extreme condition tests
Case 1 Under extreme conditions the model should still produce plausible outputs. To test
this the system in figure 6.7 is tested. Since this system does not provide any elevators it should
only bring jobs to the station on the same floor as the originating station. Given that no route
is possible from the moment the AGV wants to pickup the job, it should deny the job and
only do the jobs that can be delivered. For the model displayed the number of jobs delivered
to station C should be zero, the number of jobs delivered to station B should be 30 jobs per hour.
C
1 job / min
1 m/s
B
A
30 meter
Figure 6.7: Simple model used for extreme condition tests. The second floor is unreachable, so
station C should receive nothing. Station B should receive half of the jobs, on average 1 job per
2 minutes.
Case 2 As a second test, displayed in figure 6.8, a system is created with an elevator, but the
occupancy of this elevator by other users is set to 100%, which should result in the AGV always
waiting for the elevator. The waiting time will on average be the time specified as AverageWaitingTime by the user. In this model the trip time for the AGV should be 30 seconds of driving
time with load and 30 seconds without load. It should be in the elevator for 2 times 5 seconds
and it should have average waiting times of 2 times 30 seconds for the elevator. This results in
a round trip time of 2 minutes and 10 seconds on average and an average job driving time of 1
minute and 5 seconds.
K. Davina
2012.TEL.7687
97
An AGVS design tool
Occupancy: 100%
Average waiting time: 30 sec
Speed: 1 meter / sec
P
5 meter
1 job / 3 min
B
1 m/s
A
30 meter
0 meter
Figure 6.8: Simple model used for extreme condition tests. The AGV will have to wait for the
elevator every run resulting in this case in a round trip time of 2 minutes and 10 seconds.
Case 3
In a third extreme situation, displayed in figure 6.9, multiple AGVs have to share a
single charging point. This should result in AGVs waiting for one another to charge and very
high waiting and in-system times. The AGVs will only use power for driving, resulting in a
power consumption of 60 units per job. Since 1 job per 30 seconds is created, 60 units of power
are required per 30 seconds, or 2 units per second. If this is equal to the amount supplied by the
charging point, given the stochastic nature of the process and the fact the AGVs have to wait for
each other to charge, waiting times for the jobs at station A will keep increasing. Therefore the
charging speed at the single charging station is set at 15 and 50 units per second respectively.
The simulation is also ran with 3 different seeds, but since the jobs arrive at a static interval and
no other processes behave exponentially, this should not change the outcomes. This should be
visible from the simulation.
98
K. Davina
2012.TEL.7687
An AGVS design tool
Charging:
2 units / sec
P
AGV:
Battery capacity: 150 units
Usage: 1 units / meter
0m
P
1 job / 30 sec
(fixed)
B
0m
A
1 m/s
C
P
P
30 meter
30 meter
Figure 6.9: Simple model used for extreme condition tests. The AGVs combined can handle the
job load easily if battery capacity would be infinite. The charging capacity in this system is the
same as the average usage. Given the stochastic nature of the system and the single charging
station shared by all four AGVs the waiting times at station A should continuously increase.
Results
Case 1
After running the simulation for 24 hours the amount of jobs delivered at station B is
719. One would expect 24 × 30 × 1 = 720 jobs. Since the first job is created at t = 1 minute, 719
jobs is the correct number. Station C received zero jobs.
Case 2 At 1 job per 3 minutes (on average) 480 jobs are created by the system. This can be
seen on the right side of figure 6.10. 480 jobs results in 480 ∗ 30 = 14400 driving meters with a
load. Given the AGV speed this results in 14400 driving seconds, which can be seen in the same
figure.
Since the average elevator waiting time is set at 30 seconds, this should also be reflected in
the simulation outcomes. Figure 6.11 clearly shows this. The job enroute time is somewhat lower
than the 65 seconds calculated. This is because of an improvement to the system; the AGV will
call the elevator directly when it has claimed it and will continue driving before actually stopping
and waiting for the elevator. This claiming trigger is at 3 meters before the actual elevator, so
it saves the job 3 seconds.
K. Davina
2012.TEL.7687
99
An AGVS design tool
Extreme condition test case 2: Total drive time and Jobs done
16,000
540
15,500
Total drive time (s)
15,000
500
14,500
480
14,000
460
13,500
Number of jobs transported
520
440
13,000
12,500
420
Drivetime w load
Jobs Done
Figure 6.10: Simulation results for extreme condition tests case 2. This simulation was run 5
times with TomasSeeds 1 to 5. The total time driven by the AGV with a load is on the left. The
number of jobs delivered by the AGV at the destination is on the right.
100
K. Davina
2012.TEL.7687
An AGVS design tool
Extreme condition test case 2:
Average elevator calling time and job enroute time
31.5
62.4
31
62.2
30.5
30
61.8
29.5
Time (s)
Time (s)
62
61.6
29
61.4
28.5
28
61.2
Avg Call Time Elevator
Job enroute time
Figure 6.11: Simulation results for extreme condition tests case 2. This simulation was run 5
times with TomasSeeds 1 to 5. The average elevator calling time is on the left. The job enroute
time is on the right.
K. Davina
2012.TEL.7687
101
An AGVS design tool
Table 6.1: Outcomes for extreme condition tests case 3
Total for 24 hours
seed
Charge speed: 15 units/s
1
2
3
Charge speed: 50 units/s
1
2
3
drivingdistance
jobdone
jobpickup
[m]
159951
1821
1822
159951
1821
1822
159951
1821
1822
171126
1902
1902
171126
1902
1902
171126
1902
1902
chargetime
parktime
drivingtime
drivingtimetocharging
drivingtimetoparking
drivingtimeunloaded
waitingtime
total time
number of AGVs
total time per AGV
[s]
[s]
[s]
[s]
[s]
[s]
[s]
[s]
10276
154698
54640
71620
15390
18300
20648
345573
4
86393
10276
154698
54640
71620
15390
18300
20648
345573
4
86393
10276
154698
54640
71620
15390
18300
20648
345573
4
86393
3159
145228
57060
75958
18988
19120
26082
345595
4
86399
3159
145228
57060
75958
18988
19120
26082
345595
4
86399
3159
145228
57060
75958
18988
19120
26082
345595
4
86399
[s]
Case 3 Running this case provides the results given in table 6.1. What can be seen is that the
figures do not change when changing the seed, as expected. Second, the total of registered AGV
times is only slightly smaller than the total simulation time (86400 seconds).
Since the AGV tries to charge when it is idle, it will drive to the charging station. Since it
can still accept a job, it will be provided a job only moments after it arrives, resulting in high
drivingtimetocharging values and a low actual chargetime value.
During the total simulation 86400/30 − 1 = 2879 jobs are created at station A. In this
simulation only 1822 jobs at a slower charging rate and 1902 jobs at a higher charging rate are
handled. The number of jobs waiting and the average waiting time at station A are thus very
high. This can be seen in figure 6.12. The amount of jobs in the queue at the end of the running
time is 977, which is exactly the number of jobs not handled by the AGV for the case where the
charging rate is 50 units/s. From this figure the non-stochastic nature of this particular case can
be seen: the lines are straight.
102
K. Davina
2012.TEL.7687
An AGVS design tool
Extreme condition
20,000
1,000
800
Average Waiting Time
Average Queue Length
Queue Length
600
Length
Waiting time [s]
15,000
10,000
400
5,000
200
0
0
0
10,000
20,000
30,000
40,000
50,000
60,000
70,000
80,000
90,000
Simulation time [s]
Figure 6.12: Simulation results for extreme conditions test case 3. This simulation was run with
a charging rate of 50 units/s.
K. Davina
2012.TEL.7687
103
An AGVS design tool
6.2.5
Internal validity
Case 1
The system in figure 6.13 is tested. The seeds for the different distributions are first
kept the same for the first two runs and then changed for the third and fourth run. The seeds used
are the first three seeds specified by the TOMAS seed package. The values should not change
when the seed is kept the same. When the seed is changed the outcomes should be approximately
the same. If multiple docks are available at a station, always one will be programmed for pick-up
and one for drop-off; the rest of the docks is dynamic.
Transit times for jobs can be calculated on basis of the distance to be covered by the AGV.
These times will be lower than the actual times, but just by a small margin because of the low
congestion density. The transit time for a job from A (Dock 1 or 3) to B is at least 124.1 seconds,
from A (Dock 1 or 3) to C (Dock 2) 224.1 seconds and from C (Dock 1) to B 324.1 seconds.
With the amount of jobs coming from each station the average job driving time should be 212
seconds. The average transit time should be a little bit higher because of AGVs waiting for one
another and roads that are diagonal and thus a bit longer.
10 meter
90 meter
10 meter
To B: 1 job / 10 min (exponential)
To C: 1 job / 10 min (exponential)
10 meter
C
10 meter
C
C
90 meter
Charging:
100 units / min
A1
A2
10 meter
100 meter
A3
1 m/s
AGV:
Driving usage:
1 unit / meter (unloaded)
2 units / meter (loaded)
Pickup & Drop-off: 100 units
Waiting: 1 unit / s
C1
C2
To B: 1 job / 15 min (fixed)
B
Job removal time for all stations: 5 minutes
Figure 6.13: Model for internal validity tests. The model is run 4 times: the first two times with
the same seed, the third time and fourth time with different seeds.
104
K. Davina
2012.TEL.7687
An AGVS design tool
Case 2 The system in figure 6.14 is tested to include the elevator influence. Average waiting
times for the elevator should be a combination of the utilization ratio, the average waiting time
and the congestion in the system. If the elevator is occupied (50% chance) the average waiting
time is 20 seconds. If the elevator is not occupied it will be on the required floor half of the time
resulting in no waiting time or on the other floor resulting in a waiting time of 8 seconds. So
if the claim is not a direct claim, as shown in 5.1, the average waiting time will be 14 seconds.
Since the three charging stations are next to each other and all AGVs will have to use the same
elevator, some congestion and consequently direct claims do take place. This is also because of
the lack of parking space that will make the AGVs go to a charging station instead of parking.
10 meter
100 meter
100 meter
50 meter
10 meter
To B: 1 job / 10 min (exponential)
To C: 1 job / 10 min (exponential)
A1
A2
10 meter
100 meter
A3
1 m/s
AGV:
Driving usage:
1 unit / meter (unloaded)
2 units / meter (loaded)
Pickup & Drop-off: 100 units
Waiting: 1 unit / s
C1
C2
To B: 1 job / 15 min (fixed)
Elevator speed: 0.5 m/s
Occupancy: 50%
Avg waiting time: 20 sec
B
Level 1: 0 m
50 meter
Job removal time for all stations:
5 minutes
Level 2: 4 m
10 meter
Charging:
100 units / min
C
C
C
Figure 6.14: This model is the same as the model displayed in figure 6.13 with the inclusion of
an elevator.
K. Davina
2012.TEL.7687
105
An AGVS design tool
Table 6.2: Internal validity case 1: enroute and driving times
[s]
[s]
seed
1
1
2
3
211
2.5
404
199778
83857
63507
52414
214
2.1
388
191989
81770
59370
50849
212
1.7
363
182517
76266
59287
46964
199778
191989
182517
enroutetime
enroutewaiting
jobsdone
drivingdistance
drivingtime
drivingtimeunloaded
[m]
[s]
[s]
[s]
211
2.5
404
199778
83857
63507
52414
driving time total
[s]
199778
Results
Case 1
As can be seen from table 6.2 the enroute time for jobs is consistent with the calculated
enroute time of 212 seconds. The average time a job spends waiting enroute (thus waiting for
other AGVs at crossings/stations) is also displayed. As was expected, the time per job is low.
A second thing that is checked with this table is the total driving time of the AGVs with the
driving distance. Since the AGVs drive at 1 m/s the driving time should be equal to the driving
distance. This is also confirmed by the simulation.
Case 2
The results from simulating case 2 are presented in table 6.3. Again the number of
jobs picked up and the number of jobs done are displayed. Since three AGVs are used in this
case, the maximum difference can be three, which is supported by the outcomes. The outcomes
also show that not changing the seed will result in exactly the same values. The second run with
the same seed was ran on a different computer.
The time an AGV has to wait for an elevator on average is between 10.17 and 12.30 seconds.
This is indeed somewhat lower than the predicted value of 14 seconds and is primarily caused
by the number of direct elevator claims. The number of times the waiting time for the elevator
was zero seconds is also displayed in the table.
The time an AGV spends in the elevator is also displayed and should always be 8 seconds in
this case. The simulation data also proved this: the standard deviation of this value is zero.
The number of times an AGV had to use power that was not available was counted as
batteryempty. These numbers do not mean the AGV had this number of unsuccessful runs, it
means it may have had a few rides that it would not have been able to do in real life. For the
case where batteryempty is 128 all traces were checked: the batteryempty state was registered
106
K. Davina
2012.TEL.7687
An AGVS design tool
Table 6.3: Internal validity case 2: jobs done, elevator waiting times and batteries empty
Seed
batteryempty
jobdone
jobpickup
waitforelevatorreal
waitforelevator is zero
callelevator
waitinelevator
Qty
Qty
Qty
[s]
Qty
Qty
[s]
1
1
2
3
9
312
313
10.17
168
604
8
9
312
313
10.17
168
604
8
128
328
328
12.30
142
551
8
46
311
313
11.07
177
605
8
at only 9 distinctive times in a time window of less than 100 seconds. It was thus probably
only 1 AGV journey that failed. This is however a point of improvement for the DEST. For
this simulation run the safety factor was set at 1, so no additional power was reserved for this
purpose of drained batteries.
6.2.6
Parameter variability analysis
In this section multiple systems are tested in different cases. In each of these cases some or all
parameters are scaled. This should give an approximation on beforehand of what changes to
expect given the knowledge of the code. These approximations should compare to the outcomes
of the simulation to validate the program.
Case 1 For the first case the previously used system in figure 6.8 is used. For this test the
speed of the AGV and elevator are changed. The system is also run for AGV and elevator speed
of 1.5m/s and 2m/s. This should result in enroute times of respectively 53.7 seconds and 47.5
seconds.
Case 2
For this case the inputs of the previously used system in figure 6.14 are changed. The
AGV battery capacity will be variated to 2500 units and 10,000 units combined with the original
charging speed and charging speeds of 150 units per minute and 50 units per minute. On average
the time for charging should be enough when charging at 100 units per minute, but combined
with a stochastic process and a smaller battery capacity waiting times will still increase. A larger
battery would mean a decrease in waiting times. To ensure no empty batteries the safety factor
for the required power calculation is set at 1.25.
K. Davina
2012.TEL.7687
107
An AGVS design tool
Case 3
This case displays the differences in route congestion when choosing a different routing
algorithm. The system used is the one in figure 6.15. For this layout, Dijkstra’s algorithm will
always choose the shortest path: it will skip road 3 and 4. The A* algorithm should ignore road
1 and 2, because of the cost estimation factor of 1.1. The distributed traffic pressure algorithm
(DTP) algorithm divides the load evenly amongst all roads. This should result in roads 1, 2, 3
and 4 to be used evenly.
100 m
100 m
Road 6
B
Road 3
Road 2
100 m
Road 1
0m
101 m
Road 5
100 m
Road 4
Dijkstra's algorithm
A* algorithm ( � = 1.1 )
0m
Distributed occupancy algorithm
A
Figure 6.15: Model for doing parameter variability analysis by changing routing algorithm. The
dashed lines indicate the routes expected to be taken by the AGV when the associated algorithm
is selected.
108
K. Davina
2012.TEL.7687
An AGVS design tool
Table 6.4: Parameter variability analysis case 1: enroute times for different elevator and AGV
speeds
AGV and elevator speed
1
1.5
2
enroute
early calling
[s]
[s]
61.4
3.0
50.7
2.0
45.3
1.5
total
predicted
[s]
[s]
64.4
65.0
52.7
53.7
46.8
47.5
Table 6.5: Parameter variability analysis case 3: average number of vehicles on each road per
direction
Road
Road
Road
Road
Road
Road
1
2
3
4
5
6
Dijkstra
A-Star
DTP
0.11
0.11
0
0
0.11
0.11
0
0
0.11
0.11
0.11
0.11
0.06
0.06
0.05
0.06
0.11
0.11
Results
Case 1
From table 6.4 one can see that changing the speed parameter still provides conclusive
numbers. The values from the simulation are close to the values from the prediction displaying
consistency when varying parameters.
Case 2
The outcomes of this case for the average waiting time and the number of jobs done
can be found in respectively figure 6.16 and figure 6.17. From these plots one can see the impact
the battery capacity has on the simulation outcome. Increasing the speed at which the battery
charges, does not help a lot. In this system the time necessary to get to the charging point
is dominant compared to the charging time itself. This explains why increasing the charging
speed only increases throughput and decreases waiting times just a bit. Increasing the capacity
of the battery does provide tremendous growth in throughput as well as a big decline in the
average waiting time before pickup. Incorporating battery capacity in the simulation is thus an
important improvement and grants the designer more insight in the designed AGVS.
Case 3 The average number of vehicles on each road is displayed in table 6.5. From these
numbers the correct working of the algorithms is seen: the AGV takes the path as predicted.
K. Davina
2012.TEL.7687
109
An AGVS design tool
Average waiting time for pickup
12,000
150 units/min
100 units/min
50 units/min
10,000
Time [s]
8,000
6,000
4,000
2,000
0
2,500
5,000
Battery capacity
10,000
Figure 6.16: Average waiting time for pickup for case 2 of parameter variability analysis
110
K. Davina
2012.TEL.7687
An AGVS design tool
Number of jobs done at different battery capacities
400
150 units/min
100 units/min
50 units/min
Number of jobs done
300
200
100
0
2,500
5,000
Battery capacity
10,000
Figure 6.17: Number of jobs done after 24 hours for case 2 of parameter variability analysis
K. Davina
2012.TEL.7687
111
An AGVS design tool
6.2.7
Traces
For this type of validation the text traces of the AGVs in the systems displayed in figures 6.15
and 6.14 are studied for inconsistencies and if they follow the logic as presented in listing 5.13.
The traces performed did not display any inconsistencies.
6.3
Operational Validation
In operational validation the outputs of the computer program are compared with the real world
outputs of such a system. The techniques used to perform this validation are: face validity,
operational graphics and parameter variability analysis.
6.3.1
Face validity
Face validation will be performed by some knowledgeable experts at Deerns Consulting Engineers.
They will try the testcase given in chapter 7.
Results
The behavior of the simulation outputs is according to the expectation of the experts. According
to them the data outputted by the program looks reliable and consistent with their knowledge
on these systems. The experts consulted are listed in appendix E.
6.3.2
Parameter variability analysis
To do this analysis parameters for different cases are changed. These parameters should not
be chosen in a way that makes it highly predictable what the outcome should be, as was used
with parameter variability analysis in computerized model verification, but in such a way that
the changes in the outputs of the system can be compared with system outputs as they would
logically change in real life given the same changes. This will be done for the following case.
Case 1 The system in figure 6.18 is used. Since parking places are distributed over the system
and AGVs can come from either of these places, changes in the dispatching algorithm were the
distance between the job and the AGV plays a role should improve one output parameter in
particular: the average time to pickup.
112
K. Davina
2012.TEL.7687
An AGVS design tool
C
C
C
C
R17
R16
R15
R14
Charging Stations:
2500 units / hour
AGVs:
Details in table
R1
R2
R13
R3
R4
R5
R6
R11
R10
B3
R24
R9
P
Floor 1:
height = 0 meter
Station B:
To C, D, E, F, G: 10 jobs per day
To F, G: 5 jobs between 14:00 and 17:00
To A: 20 jobs per day
R25
R8
R23
R18
R19 R20 R21
A1
A2
R12
B4
R7
Elevator(s):
Qty: 1
Speed: 0.5 m/s
Avg. wait. time: 90 sec
Occupancy: 40 %
Elevator:
Qty: 1
Speed: 1 m/s
Avg. wait. time: 150 sec
Occupancy: 75 %
P
B2
R22
A3
B1
Station A:
To C, D, E, F, G: 3 jobs at 7:00, 11:30 and 16:30
To B: 20 jobs per day
P
P
R111
R102
R106
R101
R104
R103
C
Floor 2:
height = 4 meter
R107
R108
Station C:
D
E
To A: 3 jobs at 8:30, 13:00 and 18:00
Station D:
To A: 3 jobs at 8:30, 13:00 and 18:00
P
Station E:
To A: 3 jobs at 8:30, 13:00 and 18:00
P
R202
R204
R209
R201
R110
R109
R105
R203
G2
R208
R210
G1
R205
Station G:
To A: 3 jobs at 8:30, 13:00 and 18:00
To B: 5 jobs between 7:00 and 10:00
R206 R207
Floor 3:
height = 7 meter
F1
F2
Station F:
To A: 3 jobs at 8:30, 13:00 and 18:00
To B: 5 jobs between 7:00 and 10:00
Figure 6.18: Model used for operational parameter variability analysis. AGV details in table 6.6
K. Davina
2012.TEL.7687
113
An AGVS design tool
Table 6.6: AGV parameters for model used for operational parameter variability analysis
Speed
Fast charging
Slow charging
Turning point
Charge to minimal %
Opportunity charging
Safety factor power calculation
Energy usage
Pickup
Dropoff
Driving empty
Driving loaded
Waiting
Parking
[m/s]
[Units/hour]
[Units/hour]
1
40000
10000
65%
30%
No
1.3
[Units]
[Units]
[Units/sec]
[Units/sec]
[Units/sec]
[Units/sec]
65
50
10
15
5
1
For this system the routing algorithm will also be changed. Since multiple routes are available
to the same destination other routes may be favorable because of congestion, anticipated waiting
times or the objective of distributing the traffic load evenly.
Results
The result of the test case can be found in table 6.7. From this table one can see that using
the combination algorithm STD/NV, a better result is obtained compared to the two partial
algorithms it was made of. It is especially visible in the time it takes for a job to be pickup up
(waitforloading): it outperforms its partial algorithms by 6% and 11%. Also, the AGV driving
distance goes down, which reduces maintenance costs.
If one looks at the dispatching algorithms that take into account the battery capacity, it is
obvious that these do not improve the system looking at pickup time compared tot the STD/NV
algorithm. They do have a lower utilization ratio. These algorithms thus might prove better in
a system that has to cope with more loads.
In the same table also a comparison is made with the same dispatching algorithm, but using
the expected travel time (ETT) algorithm. Again the time to pickup is lowered, but this time
at the cost of some extra kilometers made by the AGV as well as a higher utilization ratio. The
STD/NV was also ran with the A* algorithm, which performed exactly as Dijkstra’s algorithm
as expected.
If one looks at the total improvement when compared to the standard FCFS/FAV case us114
K. Davina
2012.TEL.7687
An AGVS design tool
Table 6.7: Parameter operational variability analysis case1: impact of changing the dispatching
algorithm
AGV drivingdistance
Job waitforloading
AGV parktime
Hours available
Utilization
FCFS/FAV
STD
NV
STD/NV
HRBC
LRBC
STD/NV (ETT)
90.2
10.3
41.1
96
57%
89.6
9.8
40.9
96
57%
89.9
9.3
36.7
96
62%
88.0
8.7
36.4
96
62%
90.4
9.9
42.5
96
56%
88.0
10.7
38.0
96
60%
89.4
8.1
35.2
96
63%
[km]
[min]
[hours]
ing Dijkstra’s algorithm, the total improvement is for the pickup time from 10.3 minutes to 8.1
minutes, an improvement of 21%.
The data for the two cases using the two battery capacity algorithms is quite different from
the others. Especially the case where the AGV with the lowest remaining capacity is used does
not perform good. The algorithm using the highest remaining capacity performs a lot better,
but is still not good compared to the other algorithms.
K. Davina
2012.TEL.7687
115
An AGVS design tool
6.3.3
Operational graphics
The way the system changes during a run gives a lot of insight into the validity of the model.
Operational graphics display the changes in time for all kinds of parameters during a run. Graphs
will be made for several AGVS elements for the following cases.
Case 1 The first case for which operational graphs are displayed is the model that was used
for testing different routing algorithms (figure 6.15). Especially for the distributed occupancy
algorithm the occupancy graphs over time of the route elements should converge, since that is
the purpose of the algorithm.
Case 2
The second case will display operational graphics of the system presented in figure 6.18
which is used for parameter variability analysis.
Results
Case 1
The graph belonging to road 2 of the system in figure 6.15 is presented in figure 6.19.
From this graph one can see the convergence of the average number of AGVs. Since the number
of jobs does not change over time the graphs also depict the AGV actually sparing the road when
choosing the DTP algorithm, as was expected.
Case 2 For this test two operational graphs are shown. One depicting the average time a job
has to wait to be picked up in figure 6.20. The other graph, figure 6.21, depicting a part of a
simulated day were the number of jobs created and the number of jobs delivered are displayed.
In the first graph, figure 6.20, shows the average time to pickup for two different runs using
different routing algorithms: one using Dijkstra’s algorithm, the other using the expected travel
time algorithm (ETT) algorithm. The ETT algorithm should give a better result, since routing
in this way avoids congested parts. For this case, however, the distance to most of the stations is
too big if the second elevator is used. So only after a while, when the average occupation goes up
a bit, the system starts using other routes than the shortest one. This can be seen in the graph.
The graph thus displays the situation as would be expected from a real system, validating this
simulated system.
In the second graph, figure 6.21, one can see that the jobs are created in both situations using
the same seed: they are created at equal times. On the other hand the number of jobs delivered
116
K. Davina
2012.TEL.7687
An AGVS design tool
Average number of AGVs present on road 3
0.12
0.1
average number of AGVs
0.08
0.06
DTP
Dijkstra
A-Star
0.04
0.02
83100
81200
77700
75800
72300
70400
67800
65900
62400
60500
57000
55100
51600
49700
46200
44300
40800
38900
35400
33500
30000
28100
24600
22700
19200
17300
13800
8400
11900
6500
3000
1100
0
Simulation Time
Figure 6.19: Chart displaying the average number of AGVs on road 2
K. Davina
2012.TEL.7687
117
An AGVS design tool
600
Average time to pickup
500
Time [s]
400
300
ETT
Dijkstra
200
100
0
0
10000
20000
30000
40000
50000
60000
70000
80000
90000
100000
Simulated time of day [s]
Figure 6.20: The average time a job has to wait to be picked up during the simulation run
118
K. Davina
2012.TEL.7687
An AGVS design tool
is ahead for the case were a better dispatching and a better routing algorithm are used. This is
exactly as one would expect from this situation.
Job numbers during a part of the day
130
Number of jobs created (FCFS_FAV Dijkstra)
Number of jobs delivered (FCFS_FAV Dijkstra)
125
Number of jobs created (STD_NV ETT)
Number of jobs delivered (STD_NV ETT)
Number of jobs
120
115
110
105
100
41000
41500
42000
42500
43000
43500
Simulated time of day [s]
Figure 6.21: A small part of the simulated day displaying the number of jobs created and delivered
for two different dispatching /routing algorithms
6.4
Data Validity
In the development of the model two types of data were used. First the data for the conceptual
model, which is the data used to schematically model the system and program the system. Most
of this data was collected by Deerns Consulting Engineers ([Dav11]).
The other data used in this research is from scientific publications. Since these publications
are all reviewed the data is assumed correct.
To ensure the user inputs the correct data into the program a GUI was created. The GUI
will check user input for inconsistencies and makes sure the user couples the right route elements
to each other.
K. Davina
2012.TEL.7687
119
An AGVS design tool
120
K. Davina
2012.TEL.7687
Chapter 7
Test Case
In this chapter a test case is used to demonstrate the workings of the created tool. This case is
also presented to the engineers that will use the tool in the future to assess it. First the case itself
is presented. Since the layout of the hospital itself is not yet totally defined, multiple options
for the layout are available. After that, the flows expected in this hospital is presented. Third,
a first estimation is made on how much AGVs are required. This is followed by multiple runs
of the simulation tool to further design this particular system and test the impact of choosing
a different layout design. This part covers just some tests to illustrate the usability of the tool:
it is not a conclusive research on how an AGV system should be implemented in this hospital.
After this, a preliminary advice on the different layouts is presented. The section is concluded
with a conclusion on the usefulness of the tool for this type of system. This conclusion is also
drawn by experts that will use the tool in the future.
7.1
The case: Medisch Centrum Alkmaar
The hospital used for this case is the new to-be-built Medical Center of Alkmaar (MCA). A top
view of the MCA can be found in figure 7.1. The center consists of a straight building and a
wave-form building.
In this building AGVs may only drive in the straight part of the building. For this building
two scenarios are available at this time. One in which a logistics corridor is present in the
basement of the building (figure 7.2), called Case 1, and one where this corridor is placed on the
fourth floor (figure 7.3), called Case 2. The logistics point where most of the goods are received
121
An AGVS design tool
Figure 7.1: Schematic top view of the to-be-built Medical Center of Alkmaar
is in the basement, as indicated in the figures. Another important location is the apothecary:
this is also a location that generates a lot of transport flows. The apothecary is located on the
ground floor all the way to the right, as indicated in the figures. To investigate the impact of
allowing transport on all floors, the case without a logistics corridor is also tested allowing AGVs
on these floors. This is called Case 3.
7.1.1
Assumptions
For these cases the number of elevators is set at 4, 4, and 2 for respectively elevator blocks 1,2
and 3. The occupancy chance of a single elevator is always 80%. For case 2 two extra elevators
are required for the extra transport activities bringing goods to the fourth floor. This is done
with 2 dedicated elevators for transportation with a occupation chance of 20%, indicated as
Case 2 D, or 2 extra elevators in elevator block 1, indicated as Case 2 E. A summation of the
elevator assumptions for the different cases is displayed in table 7.1. The rest of the assumptions
done for all parameters required in the simulation are summed up in table F.1. All these values
stay equal during the different cases. The energy usage data is from [McH95]. Values for the
elevators, stations and AGV delays are estimated with the help of experts from Deerns Consulting
Engineers.
122
K. Davina
2012.TEL.7687
An AGVS design tool
3m
3m
3m
3m
4m
Apothecary
Logistics
Point
3m
1
30 m
2
3
95 m
95 m
Figure 7.2: Overview of the hospital layout for case 1. The part where the AGV may drive is
indicated with the green line, in this case only in the basement and from the elevators to the
stations. The origin of transport jobs is always the logistics point or the apothecary and return
flows will end here as well.
Table 7.1: Assumptions for the elevators for the test case
Logistics corridor
Elevators:
- block 1
- dedicated elevators
- block 2
- block 3
occupancy per elevator
- dedicated elevators
K. Davina
Case 1
Case 2 D
Case 2 E
Case 3
Yes
No
No
No
4
0
4
2
80%
na
4
2
4
2
80%
20%
6
0
4
2
80%
na
6
0
4
2
80%
na
2012.TEL.7687
123
An AGVS design tool
3m
3m
3m
3m
1
4m
2
3
Logistics
Point
3m
30 m
95 m
95 m
Figure 7.3: Overview of the hospital layout for case 2. The part where the AGV may drive is
indicated with the green line, in this case only on the fourth floor and from the elevators to the
stations. The origin of transport jobs is always the logistics point or the apothecary and return
flows will end here as well.
124
K. Davina
2012.TEL.7687
An AGVS design tool
Table 7.2: The number of carts to be transported per day for the Medisch Centrum Alkmaar
can be found by scaling the known flows of the Jeroen Bosch Hospital.
Jeroen Bosch Hospital
Medisch Centrum Alkmaar
1120
690
32
20
150
45
81
52
60
23
4
92
28
50
32
37
14
2
Nr of beds
Apothecary
Logistics point:
Meals
Snack and beverages
Linen
Waste
Consumables
Unexpected transport
Specific hospital waste
For the cost and KPI calculations the following assumptions were made: a technical lifetime
of 12 years, an interest percentage of 5%, no increase in costs for personnel and maintenance.
The minimum service level required is 80%.
The personnel in the non-automated environment uses electric vehicles and will always move
2 carts at once (conservative assumption, because some flows only provide one cart at once), this
will cut the distance to be covered and the number of jobs in half. They are assumed to cover
as much distance without a load as with a load. They will loose 2 minutes per job on elevator
waiting and riding. This is kept the same for case 2, were actually more rides per job are required
as well as more time.
7.2
Expected logistic flows
Because this hospital is a combination of several old hospitals, exact logistics flows are not yet
available. To make a good estimation of the flows to be expected another hospital case from
which the flows are known is used: the Jeroen Bosch hospital. This hospital caters 1120 beds.
Since the hospital in this case caters 690 beds the numbers of the Jeroen Bosch Hospital can be
scaled. The size of the transport flows will than approximately be as stated in table 7.2.
These flows are distributed during the day as in the Jeroen Bosch Hospital. After applying
the scaling the total list of transports to be done can be found in table F.2 in appendix F. The
numbering of the stations in this list is first the floor number, starting from zero on the ground
floor, and second from right to left for all stations in figure 7.2.
K. Davina
2012.TEL.7687
125
An AGVS design tool
7.3
Base requirement number of AGVs
For the three provided cases the minimum transport distance of the job list can be calculated by
the software. This results in 94 kilometers for case 1 and 3 and 111 kilometers for case 2. The
number of jobs in the timetable is 548. Assuming the AGV drives twice as much as this distance
and given the 16 hour time window of the jobs, the AGVs have to travel 11.8 kilometers per
hour for case 1 and 3 and 13.9 kilometers per hour for case 2. Driving at 1 m/s this gives a time
requirement of 3.3 hours per hour for case 1 and 3 and 3.9 hours per hour for case 2.
Next to that the elevator time losses have to be incorporated. If 1 minute per elevator ride is
assumed, together with 2 rides per job, 1096 minutes per 16 hours are lost, or 68.5 minutes per
hour.
In total 4.4 hours per hour and 5.1 hours per hour are required for both cases as a minimum.
That is 5 AGVs for case 1 and 3 and 6 AGVs for case 2. Since the AGV system has to handle
peaks and also (depending on the choice of battery) needs charging during this time, one AGV
is added for both facts, giving a starting scenario with 7 AGVs for case 1 and 3 and 8 AGVs for
case 2.
7.4
Analysis using the DEST
From the starting number of AGVs calculated in the previous section simulation scenarios can
be drawn up. For each of the cases multiple scenarios are created in which the number of AGVs,
the used algorithms, the battery capacity and the number of parking and charging stations are
varied. These simulation scenarios are stated in table 7.3.
The charging stations for the AGVs are in this simulation always at the location of the
logistics point and the number of stations there is the number of AGVs in the system.
The impact of adding some parking or charging stations is investigated for case 2, where
additional stations are located on the fourth floor next to each elevator position. This would
mean if a job comes available at any station other than the logistics point, the AGV will reach it
faster when choosing an appropriate dispatching function. The impact of making it a charging
point instead of a parking space is also investigated.
In these scenarios, the impact of choosing a different dispatching algorithm is tested a number
of times for each case. The impact of choosing a different routing algorithm is only done for case
126
K. Davina
2012.TEL.7687
An AGVS design tool
Table 7.3: The different scenarios simulated for the testcase. In each of the cases the number of
AGVs and parking and charging spaces was changed, as well as the algorithms used for routing
and dispatching
Scenario
1
2
3
4
5
6
7
8
9
10
11
12
13
Case
1
1
1
2
2
2
2
3
2
3
2
3
2
2
3
3
3
AGV
CS
PS
Battery
capacity
[Units]
Dispatching
Algorithms
Routing
7
7
0
108,000 FCFS FAV
Dijkstra
7
7
0
144,000 FCFS FAV
Dijkstra
7
7
0
144,000 MODFCFS FAV Dijkstra
D
8
8
0
108,000 FCFS FAV
Dijkstra
D
8
8
0
D
8
8
0
D
8
8
3
144,000 MODFCFS NV
Dijkstra
parking stations at each elevator on level 4
D
8
8
3
144,000 STD
Dijkstra
parking stations at each elevator on level 4
D
8
11
0
144,000 STD
Dijkstra
extra charging stations at each elevator on level 4
E
8
8
0
180,000 STD
Dijkstra
E
9
9
0
180,000 STD
Dijkstra
8
8
0
7
10
0
144,000 STD
ETT
extra charging stations next to elevator block 2 on levels 1, 3 and
Park
Charge
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
NPA
5
3, since alternative routes do not exist for the layout in case 1 and 2. The parking and charging
algorithm are kept the same.
If the hospital sticks to not putting in a logistics corridor in the basement, scenario 13 investigates the impact of combining several improvement techniques: allowing driving on all floors,
choosing a more sophisticated dispatching and routing algorithm and adding extra charging
stations in the middle of the building on floors 1, 3 and 5.
As can be seen the NV algorithm is not used as a part of the dispatching algorithm that
much, only in scenario 7. This is because this part of the algorithm is only used when multiple
AGVs are available for a single job. Since AGVs are all idle in the same location for most cases
(the charging stations), all AGVs are as near the job. When adding additional parking spaces,
choosing a nearest vehicle can be useful, however, in this case the job schedule is very demanding
and this algorithm is nearly used. For a job schedule with more moments to choose from different
AGVs for a single job and more decentralized parking and charging stations, it may be a useful
algorithm to choose.
K. Davina
2012.TEL.7687
127
An AGVS design tool
Table 7.4: The SPI and KPIs for the different simulation scenarios for the testcase
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
Scenario
7.4.1
1
2
3
4
5
6
7
8
9
10
11
12
13
SPI
KPI
Payback
Payback
[Years]
KPI
SL
Service
Level
KPI
TC
0.00
0.00
0.60
0.00
0.44
0.59
0.40
0.45
0.63
0.64
0.67
0.68
0.71
0.58
0.58
0.58
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.50
0.58
5
5
5
6
6
6
6
6
6
6
6
6
5
0
0
0.57
0
0.22
0.72
0.08
0.25
0.84
0.90
1.00
1.00
0.95
54%
72%
91%
48%
84%
94%
82%
85%
97%
98%
100%
100%
99%
0.80
0.80
0.79
0.74
0.74
0.74
0.74
0.75
0.74
0.75
0.74
0.80
0.80
Results
All scenarios were simulated and an overview of the system performance indicator (SPI) and
KPI values is given in table 7.4. From this table one can see that in the set of scenarios tested,
scenario 13 is the best one according to its SPI. Scenario 9 performs better than scenario 8
because of the change of 3 parking spaces to charging spaces distributed over the fouth floor.
Scenario 10 performs well because of the increased battery capacity. Scenario 11 performs well
because of the additional AGV compared to scenario 10. Because the payback time of the system
still falls in the same year, it does not have to give in on that KPI. It off course does require a
bigger investment than the system used in scenario 10. If this investment would cost one extra
year, the SPI would drop 0.05, dropping the solution in the ranking. More detail on this KPI
might prove necessary. Scenario 13 combines all improvements of the other systems, resulting
in the best overall SPI. If the same algorithms and improvements are used on case 1, one could
expect an even higher SPI. This was not tested here.
If one looks at the separate improvements from one scenario to another one can clearly see the
impact of choosing a certain battery capacity on the performance of the system. For instance,
when comparing scenario 5 and 6. This behavior can be explained by looking at a graph showing
the number of unassigned jobs and the AGVs currently charging, which is shown during the
simulation run. The graph for scenario 6 can be found in figure 7.4. When the peaks in the
blue line (for charging AGVs) alternate with the peaks in the red line (for unassigned jobs) the
AGVs use spare time to charge. When the peaks collide it means AGVs have to charge because
128
K. Davina
2012.TEL.7687
An AGVS design tool
there batteries are running empty. Choosing a larger battery capacity might give the AGVs the
possibility to keep working during job peaks and charge during calm times. In this case it means
decreasing the average pickup time from 31 to 22 minutes. Another possibility is to spread out
the jobs more evenly over the day. Whether this is possible depends on the hospital. The choice
of battery capacity is closely related to the peaks in the schedule and the schedule should thus
be as accurate as possible for a good decision on this.
40
35
Number of AGVs charging
30
Number of unassigned jobs
25
20
15
10
5
0
5
7
9
11
13
15
17
19
21
Simulated time of day
Figure 7.4: The number of unassigned jobs in the system and the number of charging AGVs for
scenario 6
The impact of giving the AGVs the possibility to drive on all floors instead of only on the
fourth floor (case 2 versus case 3) can also clearly be seen: scenarios 5 and 12 compare this.
In scenario 12 the battery capacity goes down, but the SPI goes up. This is mainly because
of the improvement of the service level. In these systems the distance jobs cover is almost the
same, but when an AGV comes available at a certain station and has to pickup a job at another
station on the same floor, it takes a lot less time. This should be visible in the average time for
a pickup. The average pickup time for scenario 5 was 50 minutes, while the average pickup time
K. Davina
2012.TEL.7687
129
An AGVS design tool
for scenario 12 was 14 minutes. With this average pickup time the low number for the service
level KPI is logical.
Adding parking spaces on the fourth floor did not improve the system: if one compares
scenarios 5 and 7 the SPI goes down, only because the service level goes down. The AGVs will
be quicker picking up a job in a quiet period when they are parked, but the AGVs will not have
charged during the time they were parked. This results a big capacity loss when a peak of job
requests enters the system and the AGVs must charge during the peak.
If these extra parking spaces are converted to charging spaces, as is done when comparing
scenarios 8 and 9, the service level goes up again. The average pickup time also decreases, from
25 minutes in scenario 8 to 15 minutes in scenario 9. The overall improvement from adding
charging and parking stations is however not clear, in this case keeping all parking and charging
stations next to the logistics point is probably the best option if horizontal transport on all floors
is not allowed.
7.5
Advice following from the analysis
Creating a hospital with a logistics corridor on the fourth floor, not adjacent to the logistics
point, more travel as well as more elevator rides are necessary to deliver the jobs. One can see
from the calculations that 17 kilometers more have to be travelled per day as well as over 300
jobs that require an extra elevator ride. This results in 2 FTE personnel extra. When the AGVs
are concerned it leads to longer trip times and distances, resulting in more AGVs and higher
maintenance costs. If an appropriate number of AGVs is chosen, jobs can still be delivered within
a given time window. There is also the possibility to do transport to the fourth floor manually
and let the AGVs handle jobs from the fourth floor. The impact of such a solution should be
assessed in a follow-up research.
If the hospital still wishes to choose a design without a logistics corridor in the basement an
(almost) equivalent system can be formed by allowing AGVs to drive on all floors. This will
lower the travel time and distances and additionally gives the option for route optimization.
If the hospital has the option to install extra charging point distributed over different floors,
this will give a boost to the overall system performance, which can, in combination with an
improved battery capacity and smart algorithms, save an AGV.
For a more thorough analysis, a better input of the transport jobs is required. Especially
130
K. Davina
2012.TEL.7687
An AGVS design tool
peaks should be known in order to size all system components properly. From the preliminary
analysis payback times of 5 to 6 years are possible, which is well within the technical lifetime
of such a system. The hospital is thus able to cut its logistics expenses when choosing an AGV
system.
7.6
The usefulness of the DEST
As was demonstrated by this chapter, the DEST proves to be a good tool in aiding a user in
the design of an AGV system for a hospital. It gives the possibility to compare different systems
on the basis of an SPI and provides the possibility to research the impact of choosing different
battery capacities as well as different layouts of the system.
The logistic problem at hand was investigated and the impact of an alternative building layout
was researched. Only a few of the possible solutions for the problem were tested. As input an
estimation of the transport jobs was used. It thus does not provide a conclusive solution for the
problem at hand, but it does provide insight in the impact of making certain decisions during
the design process.
7.6.1
The usefulness as seen by experts
A few experts from the transport and logistics department of Deerns Consulting Engineers tested
the program. Their thought on the program are stated and signed in appendix E. The most
important conclusions are cited here:
1. ”The results and the effect of variation of input parameters by a sensitivity analysis, appear
reliable and are within range of existing systems.”
2. ”..., it should be possible to simulate with different lay-outs, numbers of stations, buffer
positions, charging and parking positions and numbers and characteristics of AGV’s. The
simulation model offers all these possibilities.”
3. ”Because of these extra contributions the tool became more flexible, giving us the option
to adopt future developments in the simulations.”
4. ”the outputs generated by the tool are in sync with the expectations.”
5. ”A short explanation was sufficient to be able to use the simulation tool.”
6. ”The GUI is constructed logically, but will require an elaborated tutorial to define the
K. Davina
2012.TEL.7687
131
An AGVS design tool
correct manner and nature of parameter input for creating system lay-outs.”
7. ”It however remains necessary to have a certain level of basic knowledge of AGV systems
and the associated logistic choices.”
132
K. Davina
2012.TEL.7687
Chapter 8
Conclusions
With the possibilities of AGV Systems (AGVS) as presented in this research, hospitals are
provided with opportunities to save on their logistics expenses and use the savings on operations
or investments that add value. The Discrete Event Simulation Tool (DEST) developed in this
research enables the user to substantiate the decision on whether to use AGVs for transports in
hospitals. It provides the expected costs for the designed system as well as the service level to
expect from this system. The research questions presented in the introduction will be answered
here.
Is it possible to develop a discrete event simulation tool to simulate the logistics
environment within a hospital with respect to transports to be carried out by AGVs?
Yes, it is. The created tool gives the user the possibility to test different scenarios en choose the
most suitable scenario from the outcomes. It also gives the ability to test the designed system
given the AGVS specifications of different AGV suppliers. With this, the user can make a better
decision on which of the prospected suppliers can deliver the demanded system or on how much
the system needs to be changed to be compatible with a suppliers catalogue. The DEST also
provides the possibility to check a supplier’s counteroffer for applicability and correctness when
the requested system is not available.
With the tool the user is also able to assess the impact of different hospital layouts on the
logistics system. A test case for the Medical Center of Alkmaar was simulated. In this simulation,
the effect on the logistics system of canceling a logistics corridor in the basement and moving it
to the fourth floor became visible. It means an increase of 2 AGVs on the 7 AGVs required with
133
An AGVS design tool
a basement and thus adds a lot of costs. This can be solved by giving AGVs the possibility to
drive on all floors. The impact of distributed charging stations throughout the hospital was also
researched and meant a reduction of 40% in average pickup times in a certain case.
In conclusion, the tool manages to simulate different hospital designs and with that, different
logistic flow inputs as found in hospital logistics timetables.
Which performance indicators are required to assess the feasibility and performance
of such a system?
To give the user the possibility to compare the different systems during
design a system performance indicator was developed to display the system performance in a
single number: the system performance indicator (SPI). This number is a combination of different
factors, or key performance indicators (KPI). There are three KPIs important for the designers
for this type of system: payback time, service level and traffic congestion.
The payback time KPI is calculated with respect to the technical lifetime of the system: the
closer the payback time comes to the technical lifetime, the worse the investment in a system is
considered. Any improvement to the system, including but not limited to more stations, roads
or AGVs, is reflected in a longer payback time and for that in this KPI. If the payback time
exceeds the technical lifetime of the system the SPI becomes zero.
The service level KPI is calculated with respect to the minimum required service level set by
the customer. The more the service level goes over the minimum, the higher this KPI becomes.
When the service level is lower than the minimum level the SPI becomes zero.
The third part of the SPI is the traffic congestion KPI. This number reflects the traffic pressure
in the system, thereby describing how well the system is able to handle upsizing of traffic flows
and the number of AGVs. This is calculated using the driving time and the waiting time during
transit required for a job.
Next to these three numbers, more KPIs are calculated by the system giving insight into the
traffic pressure on each infrastructure element, the length and average length of queues in the
system. There are also KPIs for evaluating the time spent in the system by jobs as well as the
usage of AGVs during the simulation.
How important are these performance indicators towards the assessment of the
total designed AGV system?
The importance of the three KPIs with respect to the SPI
was assessed by scaling and prioritizing. This was done by an AGVS expert. The conclusion was
134
K. Davina
2012.TEL.7687
An AGVS design tool
that the KPI describing the payback time should contribute for 60% to the SPI score, the KPI
describing the performance level should contribute for 30% and the KPI describing the traffic
congestion should contribute for the remaining 10%. These weights would, according to the
expert, give a correct ranking of systems given the current market conditions.
The SPI was calculated for thirteen scenarios for the Medical Center of Alkmaar. The order
in which the different scenarios were ranked based on this SPI. The SPI proves to be a good
indicator when ranking the different scenarios. One improvement can be made however: the
payback time is now calculated on a yearly basis, in some cases adding an AGV did not mean
the system needed an extra year for payback, but it does mean a larger investment. This part
of the SPI can be improved, providing a better ranking.
The bandwidths used to scale the different KPIs is roughly consistent with the outcomes from
the test case.
If a system is designed where different bandwidths are applicable and where the minimum
requirement for the service level is different another approach for the KPIs may be required. If
a minimum service level of 99% is required, for instance, the weight of the KPI may be different
as well as the way it is calculated. At the moment all KPIs behave linearly, in some cases a
different function may be better applicable.
Which control strategies are required to test such a system?
To make sure a system of
this kind works some standard algorithms are required. For routing, both Dijkstra’s algorithm
and the A* algorithm where programmed. These algorithms should and did give the same results:
the travelled distance of an AGV for both routing strategies was the same. For dispatching a
first in first out algorithm was programmed. This algorithm also proved the correct working of
the system. This was validated with system traces.
Which control strategies are required to use such a tool in the design process?
The implemented control strategies provide the user with a broad basis to perform different
simulations for different situations. This will enable the user of the DEST to make an informed
decision on which control strategy to use and communicate this with a prospected supplier of the
system. It also gives the user the ability to communicate to the costumer how much a different
algorithm can matter for the number of AGVs needed.
For routing of AGVs different control strategies are required for correct implementation in
K. Davina
2012.TEL.7687
135
An AGVS design tool
hospital facilities. If a hospital is supplied from a logistics corridor where AGVs take an elevator
and drop their load next to the elevator on a floor, the number of possible routes to a certain
location is very minimal and most of the time 1. This means that choosing a different algorithm
does not change anything. However, if a hospital provides the possibility to drive on all floors,
multiple roads become possible from one point to another. In this case a choice should be made
how the AGVs should be divided over the different floors. For this situation a routing algorithm
was programmed to distribute the traffic pressure over all infrastructure elements or just over
the elevators as well as an algorithm to take the route that gives the lowest expected travel time.
These algorithms give the user the possibility to implement more advanced routing in hospitals
where multiple routes to a destination are possible. This was also demonstrated for the Medical
Center of Alkmaar providing a solution with their current design problem by using an expected
travel time algorithm.
For dispatching in hospitals one needs to take into account the distribution of transport jobs
over the day. Especially food distribution has a big influence on this distribution, changing it
from low demand to high demand. Since dispatching algorithms are designed for processes other
than hospitals, a suggestion was made to combine different algorithms for this specific hospital
application. In times of low demand a work-center initiated dispatching algorithm (WIDA) is
used, whereas in times of high demand a vehicle initiated dispatching algorithm (VIDA) is used.
This combination resulted in a decrease of average pickup times as well as a higher throughput
rate during high demand times.
For hospitals, were charging of AGVs is required, charging stations are also needed throughout
the system. For the test case additional charging stations were distributed throughout the
hospital. This did not improve the performance of the system. Since almost half of the jobs
originate at the logistics point, letting the AGV idle at a different station almost always results
in large driving times before arriving at a job. This might be solved by implementing algorithms
that keep track of historical data in the system and not only position at the parking or charging
station closest by, but calculates the location which is best suited at that time. This would
require additional research with respect to parking algorithms and might improve pickup times
and the systemwide service level.
Which elements need to be included in the DEST to cover this specific application?
If a hospital layout is compared to an industrial system additional elements are required to
136
K. Davina
2012.TEL.7687
An AGVS design tool
simulate this specific environment. In this simulation the non-designated elevator element is
added. This elevator element is shared with patients, visitors and hospital personnel, which
makes calculation on beforehand of elevator availability times impossible. The elevator was
implemented in a way in which the user of the tool can choose the occupation ratio of the
elevator as well as the average waiting time for an elevator. This waiting time is exponentially
distributed.
Next to the elevator, AGV battery management is introduced. This gives the user the possibility to test systems with different battery capacities and charging speeds.
Does implementing battery management influence the simulation outcomes? Yes, it
does. Especially the possibility to change the capacity of the battery. Because of the stochastic
nature of the system, a battery with a bigger capacity may be big enough to handle peak periods
and charge in the off peak periods. An example system, a very simple system with 3 pickup and
drop-off points, was programmed to test the influence of battery capacity on the average waiting
time before pickup for a job. In the tested system, with battery capacities of 2500, 5000 and
10000 units, the average time to pickup went from 166 minutes to 150 minutes to 16 minutes.
Especially the last doubling in capacity reduced the average pickup time 9-fold.
For the test case, the Medical Center of Alkmaar, increasing the battery capacity by 20%
meant an increase of the service level from 84% to 94% and a decrease in average pickup times
of 29%.
Are additional control strategies required in order to implement battery management?
Control has to implemented to make sure the AGV has enough battery capacity to
perform a certain job. This part was implemented in this tool. Control strategies for routing,
parking and dispatching are not necessary. Implementing different control strategies for parking
and dispatching do provide additional possibilities for design. For dispatching two additional
strategies were implemented giving the possibility to pick an AGV based on its remaining battery charge (both highest remaining and lowest remaining charge). Highest remaining charge is
needed when the battery capacity is sufficient to work for a long time and charge for a designated
time. Lowest remaining charge is needed when charging during the work period is necessary and
a low availability during long lasting peaks needs to be avoided. The tests performed did not
provide conclusive evidence that using these control strategies improves the system. In other
K. Davina
2012.TEL.7687
137
An AGVS design tool
scenarios than the ones tested they might prove worthwhile.
Does implementing elevators influence the simulation outcomes? Yes, it does. First
of all, elevators create a part of the system that has a limited capacity. If multiple AGVs arrive
at an elevator at the same time, these elevators will have to wait for each other. Next to this,
the time it takes to have an elevator available behaves stochastically. The combination of these
two factors can induce long waiting times when taking an elevator is necessary and analysis of
results from a system with elevators provides good insight in the expected additional problems
when compared to a system based on an average travel time.
Are additional control strategies required in order to implement elevators? No,
not necessarily. The way of interaction with the elevator already makes it possible to test
additional delays because of sharing an elevator with other people in the hospital. Using the
extra implemented control algorithms for elevators does create additional opportunities with the
same system. Division of the traffic over the different available elevators results in lower elevator
usage by AGVs and thus less nuisance for people. This simulation makes it possible to proof to
a hospital what amount of nuisance can be expected, thus making it possible to take away doubt
when advising on such a system.
Correcting certain algorithms for implementation of elevators is necessary. The A* algorithm
was corrected in such a way that the heuristic part of the algorithm takes into account the presence of elevators. The same is true for dispatching function that calculate the nearest vehicle:
calculation of the distance towards such vehicles needs some different way of calculation, not
using direct distances.
Verification and validation of the model
To make the DEST usable in logistics consul-
tancy for the initiator of this research, Deerns Consulting Engineers, the DEST was verified and
validated using a number of techniques. For validation of the conceptual model, face validation
and entity traces were performed by experts. These experts did not find any inconsistencies in
the conceptual representation of the AGVS.
For verification of the computerized model seven different techniques were used: animation,
comparison with mathematical models, degenerate tests, extreme condition tests, internal valid138
K. Davina
2012.TEL.7687
An AGVS design tool
ity, parameter variability analysis and traces. The outcomes of these tests verified the correct
implementation of the conceptual model into the DEST.
Finally, operational validation was performed to check the consistency of the model when
comparing with the real-life situation. The techniques used to perform this check were: comparison to other validated models, face validity, operational graphics and parameter variability
analysis. The outcomes of these methods acknowledged the correct implementation of the reallife system into the DEST.
Adaptation of the system for future changes in AGV systems and hospital logistics
In order to give Deerns Consulting Engineers the possibility to change the program in the future,
the AGVS was designed and implemented in such a way that extending the program can easily
be done. Control algorithms can be added since the inputs and outputs of these algorithms are
consistent and AGVs can be triggered to do other tasks along their way with the positioning of
a new (trigger) flag along its route without changing the AGV process.
Possibility of extending the usability of the software The simulation data is saved in a
format which is easily accessible. The format, a Microsoft Access database, will also remain supported for the next couple of years. This provides the user with the option to change the graphical
user interface according to new demands and wishes or, if required, replace it with a different one.
Test case: Medical Center of Alkmaar
To demonstrate the working of the DEST, a design
was made for a test case. This study provided a good insight for the building designers: the
decision to make only certain parts of the hospital accessible for AGVs has a great impact on
the AGV system. This impact can now be quantified and aids in the decision making process
for designing the hospital. The 13 scenarios tested provide good insight in what can be expected
when certain decisions are made. For this hospital a payback time of 5 to 6 years can be reached,
well within the technical lifetime of such a system, making implementation of an AGV system a
solid cost saving opportunity.
K. Davina
2012.TEL.7687
139
An AGVS design tool
Recommendations
Conclusions with respect to the improvement found using certain algorithms are based on one or
a few examples. To check whether these algorithms are applicable to almost all hospital cases,
tests need to be performed using different layouts. Next to this the larger tests were ran with a
single seed value. In order to obtain better funded conclusions from these values more tests with
different seeds should be performed.
In order to further extend the program several steps have to be performed in the following
order:
1. Implement a signaling system/flag type that makes route recalculation possible;
2. Implement blocking of waypoints and recalculation of route if that happens;
3. Implement a process that checks after every assignment if a job should be given to a
different AGV or if the jobs of two AGVs should be switched;
4. Make it possible for AGVs to have two assigned jobs. This way an AGV may be assigned a
job at the destination of the first job. It also makes implementing more advanced methods
dispatching methods [BY96] possible;
5. Calculate a better idling position for the AGV based on historical data or advanced knowledge on future jobs.
Implementing these steps will create a program capable of simulating advanced systems.
Improvements to decrease the number of calculated average values needed for certain parameters,
these numbers can be implemented in the simulation:
1. Add job handling speed. For certain jobs a maximum speed might be required;
2. Add AGV speed characteristics (acceleration, deceleration, corner speed);
3. Turn radius and orientation. This might be combined with a check if AGVs can make the
turn suggested in the design;
4. Type of AGV (bidirectional or monodirectional).
As a follow-up research, the impact of battery capacity on the design of hospital AGV system
design should be investigated. The impact of adding more charging stations, better control
strategies with respect to idling behaviour in combination with battery capacity can result in a
different approach in design of such systems.
140
K. Davina
2012.TEL.7687
Bibliography
[Aer05]
Aerocom. Pneumatic tube systems in hospitals [online]. November 2005. URL: http:
//www.aerocom-usa.com/files/AC3000.pdf.
[ANP11] ANP. Minister: Geen vast budget meer voor ziekenhuizen. Trouw, March 2011. URL:
http://www.trouw.nl/tr/nl/4500/Politiek/article/detail/1860061/2011/03/
14/Minister-Geen-vast-budget-meer-voor-ziekenhuizen.dhtml.
[BY96]
Yavuz A. Bozer and Chih-kuan Yen.
material handling systems.
Intelligent dispatching rules for trip-based
Journal of Manufacturing Systems, 15(4):226–239,
1996. URL: http://dx.doi.org/10.1016/0278-6125(96)84549-3, doi:10.1016/
0278-6125(96)84549-3.
[Che87]
T C E Cheng. A simulation study of automated guided vehicle dispatching. Robotics
and Computer-Integrated Manufacturing, 3(3):335–338, 1987. URL: http://dx.doi.
org/10.1016/0736-5845(87)90041-X, doi:10.1016/0736-5845(87)90041-X.
[Dav11]
Koen Davina. Hospital Logistics. Technical report, 2011.TEL.7550, Transportation
Engineering and Logistics, Delft University of Technology, February 2011.
[DeT10] DeTelegraaf. Angst terugkeer wachtlijsten na afknijpen ziekenhuizen. De Financiele Telegraaf, December 2010. URL: http://www.zkn.nl/consumenten/nieuws/
angst-terugkeer-wachtlijsten-na-afknijpen-ziekenhuizen/.
[Ege]
Egemin. Egemin Fork Lift Vehicles [online]. URL: http://www.egemin.com/modules/
page.phtml?pageid=1476&linkreset=1.
141
An AGVS design tool
[ET84]
Pius J Egbelu and Jose M A Tanchoco. Characterization of automatic guided vehicle
dispatching rules. Int. J. of Prodn. Res., 22(3):359–374, 1984. URL: http://dx.doi.
org/10.1080/00207548408942459, doi:10.1080/00207548408942459.
[GHS98] Tharma Ganesharajah, Nicholas G Hall, and Chelliah Sriskandarajah. Design and operational issues in AGV-served manufacturing systems. Annals of Operations Research,
76(0):109–154, January 1998. URL: http://dx.doi.org/10.1023/A:1018936219150,
doi:10.1023/A:1018936219150.
[HPK93] J Huang, U S Palekar, and S G Kapoor. A Labeling Algorithm for the Navigation
of Automated Guided Vehicles. Journal of Engineering for Industry, 115(3):315–321,
1993. URL: http://link.aip.org/link/?MSE/115/315/1.
[JBT]
JBT.
line].
John
Bean
URL:
Technologies
Hospital
AGV’s
[on-
http://www.jbtc-agv.com/solutions/products/
special-application-automatic-guided-vehicles-agvs/
atlis-hospital-automatic-guided-vehicle.aspx.
[JJS+ 07] J B Jun, S H Jacobson, J R Swisher, J B Jun, S H Jacobson, and J R Swisher.
Application of Discrete-Event Simulation in Health Care Clinics: A Survey. Journal
of the Operational Research Society, 50(2):109–123, December 2007. URL: http://
www.jstor.org/stable/3010560.
[Kel03]
Kelly tube systems. KELLY SYSTEMS AUTOVAC PNEUMATIC TUBE SYSTEM
[online]. August 2003. URL: http://www.kellytubesystems.com/images/autovac.
pdf.
[KK96]
C M Klein and J Kim. AGV dispatching. International Journal of Production Research,
34(1):95–110, 1996. URL: http://dx.doi.org/10.1080/00207549608904893, doi:
10.1080/00207549608904893.
[KT91]
Chang W Kim and J M A Tanchoco. Conflict-free shortest-time bidirectional AGV
routeing. International Journal of Production Research, 29(12):2377–2391, 1991. URL:
http://www.informaworld.com/smpp/content~db=all~content=a777787393, doi:
10.1080/00207549108948090.
142
K. Davina
2012.TEL.7687
An AGVS design tool
[KT93]
Chang Wan Kim and J M A Tanchoco.
automated guided vehicle system.
31(9):2123–2138, 1993.
Operational control of a bidirectional
International Journal of Production Research,
URL: http://www.informaworld.com/smpp/content~db=
all~content=a778240894, doi:10.1080/00207549308956848.
[LAdK06] Tuan Le-Anh and M.B.M. de Koster. A review of design and control of automated
guided vehicle systems. European Journal of Operational Research, 171(1):1–23, May
2006. URL: http://dx.doi.org/10.1016/j.ejor.2005.01.036, doi:10.1016/j.
ejor.2005.01.036.
[LKY+ 03] Jae Kook Lim, Kap Hwan Kim, Kazuho Yoshimoto, Jun Ho Lee, and Teruo Takahashi. A dispatching method for automated guided vehicles by using a bidding concept. OR Spectrum, 25(1):25–44, February 2003. URL: http://dx.doi.org/10.1007/
s00291-002-0116-0, doi:10.1007/s00291-002-0116-0.
[LV01]
Chulung Lee and J A Ventura. Optimal dwell point location of automated guided
vehicles to minimize mean response time in a loop layout. International Journal of
Production Research, 39(17):4013–4031, 2001. URL: http://dx.doi.org/10.1080/
00207540110054605, doi:10.1080/00207540110054605.
[McH95] R McHaney.
Modelling battery constraints in discrete event automated guided
vehicle simulations.
International Journal of Production Research, 33(11):3023–
3040, November 1995.
URL: http://www.tandfonline.com/doi/abs/10.1080/
00207549508904859, doi:10.1080/00207549508904859.
[Muu08] Freek Muurling. Het ontwerpen van een simulatiemodel voor buispostinstallaties. Technical report, 2008.TL.7233, Transportation Engineering and Logistics, Delft University
of Technology, 2008.
[Nan00]
WP Nanry.
Solving the pickup and delivery problem with time windows using
reactive tabu search. Transportation Research Part B: Methodological, 34(2):107–
121, February 2000.
URL: http://linkinghub.elsevier.com/retrieve/pii/
S0191261599000168, doi:10.1016/S0191-2615(99)00016-8.
[NT05]
D Naso and B Turchiano. Multicriteria Meta-Heuristics for AGV Dispatching Control Based on Computational Intelligence.
K. Davina
2012.TEL.7687
Systems, Man, and Cybernetics, Part
143
An AGVS design tool
B: Cybernetics, IEEE Transactions on, 35(2):208–226, April 2005.
URL: http:
//dx.doi.org/10.1109/TSMCB.2004.842249, doi:10.1109/TSMCB.2004.842249.
[OBK99] Christopher Oboth, Rajan Batta, and Mark Karwan. Dynamic conflict-free routing of
automated guided vehicles. International Journal of Production Research, 37(9):2003–
2030, 1999. URL: http://dx.doi.org/10.1080/002075499190888, doi:10.1080/
002075499190888.
[Ozk09]
A.G. Ozkil. Service robots for hospitals: A case study of transportation tasks in a
hospital. In Automation and Logistics, 2009. ICAL ’09. IEEE International Conference
on, pages 289–294, 2009. URL: http://dx.doi.org/10.1109/ICAL.2009.5262912,
doi:10.1109/ICAL.2009.5262912.
[Pag82]
E Page. Tables of Waiting Times for M/M/n, M/D/n and D/M/n and Their Use
to Give Approximate Waiting Times in More General Queues. The Journal of the
Operational Research Society, 33(5):453–473, May 1982. URL: http://www.jstor.
org/stable/2581664.
[QH01]
Ling Qiu and Wen-Jing Hsu.
routing of AGVs.
A bi-directional path layout for conflict-free
International Journal of Production Research, 39(10):2177–
2195, 2001. URL: http://dx.doi.org/10.1080/00207540110038531, doi:10.1080/
00207540110038531.
[Sar05]
R.G Sargent. Verification and validation of simulation models. In Simulation Conference, 2005 Proceedings of the Winter, 2005. URL: http://dx.doi.org/10.1109/
WSC.2005.1574246, doi:10.1109/WSC.2005.1574246.
[SH92]
Ihsan Sabuncuoglu and Don L Hommertzheim. Dynamic dispatching algorithm for
scheduling machines and automated guided vehicles in a flexible manufacturing system.
International Journal of Production Research, 30(5):1059–1079, 1992. URL: http:
//dx.doi.org/10.1080/00207549208942943, doi:10.1080/00207549208942943.
[Swi05]
Swisslog AG. Memorial Hermann Southwest Hospital: Transcar AGV Robot System Automates Hospital Bulk Transport [online].
October 2005.
URL: http:
//www.swisslog.com/hcs-agv-memorialhermann.pdf.
144
K. Davina
2012.TEL.7687
An AGVS design tool
[Swi07]
Swisslog AG. Healthcare Solutions - AGV benefits [online]. December 2007. URL:
http://www.swisslog.com/hcs-agv-benefits.pdf.
[Swi08]
Swisslog AG. RAIL-BASED CONVEYOR SYSTEMS [online]. April 2008. URL:
http://www.swisslog.com/hcs-tvs-multicar-unicar-2.pdf.
[Swi09a] Swisslog AG. Pneumatic Tube Systems [online]. June 2009. URL: http://www.
swisslog.com/hcs-pts-translogic.pdf.
[Swi09b] Swisslog
AG.
SYSTEMS
TRANSCAR
[online].
June
AUTOMATIC
2009.
GUIDED
URL:
VEHICLE
(AGV)
http://www.swisslog.com/
hcs-agv-transcar-overview.pdf.
[TDT95] F Taghaboni-Dutta and J M A Tanchoco. Comparison of dynamic routeing techniques
for automated guided vehicle system. International Journal of Production Research,
33(10):2653–2669, 1995. URL: http://www.informaworld.com/smpp/content~db=
all~content=a779873002, doi:10.1080/00207549508945352.
[TTT00] K. K. Tan, K.C. Tan, and K. Z. Tang. Evolutionary tuning of a fuzzy dispatching system for automated guided vehicles. Systems, Man, and Cybernetics, Part
B: Cybernetics, IEEE Transactions on, 30(4):632–636, August 2000. URL: http:
//dx.doi.org/10.1109/3477.865187, doi:10.1109/3477.865187.
[Vee03]
HPM Veeke. Simulation integrated design for logistics. PhD thesis, Delft University of Technology, Delft, June 2003. URL: http://resolver.tudelft.nl/uuid:
22d9b8ce-e32d-40b6-8b84-4c08c16720ec.
[Vis06]
Iris F.A. Vis. Survey of research in the design and control of automated guided
vehicle systems. European Journal of Operational Research, 170(3):677–709, May
2006. URL: http://dx.doi.org/10.1016/j.ejor.2004.09.020, doi:10.1016/j.
ejor.2004.09.020.
[VO00]
Hans P M Veeke and Jaap A Ottjes. TOMAS: Tool for object-oriented modelling
and simulation. In Proceedings of the Business and Industry Simulation Symposium,
pages 1–6, Washington D.C., April 2000. Delft University of Technology. URL: http:
//citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.17.8158.
K. Davina
2012.TEL.7687
145
An AGVS design tool
[VOL08] HPM Veeke, JA Ottjes, and G Lodewijks. The Delft Systems Approach. Springer
London, London, 7 edition, 2008. URL: http://www.springerlink.com/index/10.
1007/978-1-84800-177-0_7, doi:10.1007/978-1-84800-177-0{\_}7.
[Wik11a] Wikipedia. A* search algorithm [online]. 2011. URL: http://en.wikipedia.org/
wiki/A*_search_algorithm.
[Wik11b] Wikipedia. Dijkstra’s algorithm [online]. 2011. URL: http://en.wikipedia.org/
wiki/Dijkstra%27s_algorithm.
[Wit11]
Jochem Wit. Afstudeeropdracht simulatiemodel AGV. Deerns Raadgevende Ingenieurs
BV, January 2011.
146
K. Davina
2012.TEL.7687
Appendix A
Scientific paper
147
An AGVS design tool
148
K. Davina
2012.TEL.7687
Battery management considerations for the design
of hospital based automated guided vehicle systems
K. Davina∗ , Ir. J. Wit† , Ir. M.B. Duinkerken‡ , Prof. dr. ir. G. Lodewijks‡
∗ Email:
research@koendavina.com
http://nl.linkedin.com/in/koendavina
† Deerns Consulting Engineers, Rijswijk, The Netherlands
Email: j.wit@deerns.nl
‡ Department of Marine and Transportation Technology (M&TT)
Mechanical, Maritime and Materials Engineering
Delft University of Technology, Delft, The Netherlands
Email: M.B.Duinkerken@tudelft.nl
Abstract—Developments in AGV systems makes applicability
of these systems easier for hospital environments. These systems
are different from production systems in the distribution of flows
to be handled during a day and the non-availability of battery
changing personnel: the AGVs will have to charge automatically.
The effect of the difference in workload during the day and the
necessity for charging makes battery management a crucial part
of designing such a system.
In this paper the effects of different design aspects of battery
management is researched using discrete event simulation and
a specific hospital test case. For that purpose, elevators and
batteries are added to the simulations. The hospital researched
has a very standard hospital layout and the outcomes are
thus applicable for a lot of hospitals. The different aspects
researched are the impact of battery capacity, the impact of
adding distributed parking and charging spaces and the impact
of choosing dispatching algorithms based on average pickup times
and the number of jobs handled during a peak.
Changing battery capacity can improve the average pickup
times, in this situation the pickup time was cut in half. If it is
a good solution for a certain scenario depends on the workload
distribution. Adding parking or charging stations is something
that should be done with care. In this situation the proposed
addition of parking and charging stations in some cases doubled
the average pickup time, depending on the dispatching algorithm.
Adding these locations for AGVs should be substantiated with
simulations to make it an improvement on the existing system.
Choosing a dispatching system based on the remaining battery
charge did not prove an improvement. Only in certain situations
this type of dispatching may prove valuable.
Concluding, adding battery management in simulations and
designing whilst keeping battery management, and control of
AGVs with this management implemented, in mind is important
for hospital applications. Failure to do so might result in
large pickup times not found in simulations ignoring battery
capacity and dispatching from locations resulting in illogical job
assignments.
I. I NTRODUCTION
Continuing improvements in the field of Automated Guided
Vehicle (AGV) systems ease its implementation in sectors
other than production environments. Recent developments in
the Netherlands call for their application in hospital environments for logistics purposes. The types of hospital logistics
flows suitable for AGV transport are numerous and include
meals and snacks, linen, consumables, waste and medicines,
which, on average, results in almost 150 transport meters per
bed per day [1]. This specific type of application brings with
special considerations with respect to battery management: a
hospital does not want battery replacement stations, nor does it
require 24 hour shifts. On the other hand, the varying demand
in such a system creates possibilities for opportunity charging
[2].
In order to choose the right battery and the right type of
management of this battery for a hospital environment a study
was performed to assess the impact of these choices. This type
of study was already suggested by [2] and the necessity was
again emphasized by [3]. In this paper the impact of battery
management considerations is researched using a specific case:
the Medical Center of Alkmaar, currently under development
in the Netherlands. This hospital has a very standard layout
for its logistics purposes and thus represents a big part of the
hospitals for the Netherlands.
First, this paper studies the influence of battery capacity on
the number of AGVs required to handle a certain demand.
Second, it studies the influence of distributed parking and
charging stations throughout a hospital complementary to a
central charging station were all AGVs can charge at once.
Third, it researches the impact of two dispatching rules based
on remaining battery capacity.
This paper does not research the influence of technical
limitations of a battery including, but not limited to, battery
degradation, a lower capacity limit that may not be exceeded
or requirements on the number and length of charging cycles.
II. S IMULATION T OOL
The impact of changing the before stated parameters is
researched with a simulation tool extending the TOMAS
framework with an AGV module for hospital systems. The
original TOMAS framework was programmed by [4], the
AGV module for hospital system by [1]. The AGV module
adds, next to paths and nodes standardly available in any
AGV software, batteries, charging stations and elevators to
the simulation. It also provides the possibility to create custom
Number of transports per half hour
Number of transports
40
30
20
Apothecary
10
Logistics
Point
0
6
8
10
12
14
16
18
20
22
Time of day
Fig. 1.
The number of transports per half hour for a day
dispatching rules. This tool was thoroughly tested, verified and
validated.
III. S IMULATION INPUT
For the simulation, input on AGV characteristics, system
layout and transport flows are required. The flows are modeled
by scaling the logistic flows table of another hospital. The
transport times are kept the same, the number of loads is
scaled. This gives the number of loads during the day per
half hour as shown in Fig. 1. This is representation of the
expected arrival times of jobs; the arrivals are modeled using
certain distributions. The total flow input can be found in [1].
The Medical Center of Alkmaar has a layout as presented
in Fig. 2. In its base form all charging stations are located
at the logistics point. Most of the logistics flows originates
at the logistics point, some originate at the apothecary. For
all flows a return flow is also present. The three elevator
blocks contain, from left to right, 4, 4 and 2 elevators at each
block. Each elevator has a chance of being occupied of 80%
with an exponentially distributed waiting time with a mean
of 60 seconds when the elevator is occupied. The AGVs are
assumed to loose 6 seconds entering the elevator, as well as 6
seconds leaving the elevator. The exact assumptions used for
the elevators can be found in [1].
The energy usage of the AGVs is as for light loaded AGVs
as presented in [2]. These figures are presented in Table I.
Draws are given in Ampere or mAh.
In this system an AGV will always move to the nearest
parking space when it becomes idle and no more jobs are
unassigned at that moment. If no parking space is available, it
will move to the nearest available charging station. Only when
the AGV reached that location, it can become available again
for other tasks. The full logic and working of the system is
described in [1].
Fig. 2. Overview of the hospital layout of the Medical Center of Alkmaar.
Yellow blocks are stations. Red blocks are elevators. The part where the AGV
may drive is indicated with the green dashed line, in this case only in the
basement and from the elevators to the stations. The origin of transport jobs
is always the logistics point or the apothecary and return flows will end here
as well.
TABLE I
E NERGY DRAWS OF A LIGHTLY LOADED AGV
Description
Pickup
Dropoff
Driving empty
Driving loaded
Waiting
Parking
Unit
[mAh]
[mAh]
[A]
[A]
[A]
[A]
Value
18
14
10
15
5
1
In the standard situation 8 AGVs are available with a battery
capacity of 30 Ah. These AGVs are dispatched using the
MOD-FCFS algorithm [5], meaning the first available AGV
(FAV) is coupled to the first job that came into the system.
AGVs will however first check if there is already a job at
the station where they are currently at. In the case where
additional parking or charging stations are added two extra
dispatching algorithms are added: the shortest travel distance
(STD) algorithm and the nearest vehicle (NV) algorithm. In
the STD algorithm, instead of the job making the choice, the
AGV that became idle the first will choose the job closest to
its location. For the NV algorithm the AGV closest to the job
longest in the system is chosen for that job. Only when there
is already a job at the station the AGV ended, it will first do
that job.
IV. M ETHOD
The influence of choosing a different type of battery management is measured by comparing the values for average time
to pickup a load and the number of jobs done at 20:00 hours
to measure the throughput capacity after a peak period when
the batteries of all AGVs are lower on power.
First the influence of changing the battery capacity is tested.
In this case the battery capacity is changed to 40 Ah and 50
TABLE II
I MPACT OF CHANGING BATTERY CAPACITY ON THE AVERAGE PICKUP
TABLE III
I MPACT OF ADDING PARKING AND CHARGING STATIONS WHEN USING THE
TIME AND THE NUMBER OF JOBS DONE AFTER THE PEAK
FIRST AVAILABLE VEHICLE
Capacity
[Ah]
30
40
50
Average pickup time
[s]
Index
826 100
572 69
388 47
Nr of jobs done at 20:00
[Qty]
Index
525 100
522 99
534 102
Ah keeping the rest of the parameters equal.
Second, the influence of distributed parking and charging
spaces is investigated. First, this is done by adding 3 parking
spaces on the third floor: one at every elevator. After that the
same test is done, but now with 3 charging stations instead of
parking stations.
Third, the base case and the case using the 50 Ah battery
are ran using different dispatching algorithms. One algorithm
used is the HRBC algorithm, always picking the AGV with
the highest remaining battery charge instead of picking the
first available vehicle (FAV). The other algorithm used is the
LRBC algorithm, always picking the AGV with the lowest
remaining battery charge instead of picking the first available
vehicle (FAV).
V. R ESULTS
The impact of changing the battery capacity of the AGV
on the average pickup time and the number of jobs done at
20:00 is displayed in Table II. Especially the impact on the
pickup time is significant. The fact that the AGV requires
recharging during a period of demand diminishes the capacity
of the system and an increase in battery capacity can help
the AGV get through these periods without recharging. It may
then recharge at a moment where the demand is lower. The
impact of changing the battery capacity on the number of jobs
done at 20:00 is not significant. The average pickup time is
thus not only lower because more jobs are handled in total,
it actually takes longer to get to a certain job and in the end
(approximately) the same number of jobs is handled.
In Table III the simulation outcomes of adding additional
charging and parking stations is displayed. Simply adding
these distributed parking places is bad for the overall system
performance in terms of the average pickup time. This is partly
because of the choice of algorithm in how it chooses the AGV.
In case of the standard algorithm used here it chooses the
AGV that came available first. This would mean one of the
AGVs parking or charging on one of the added positions is
required to pickup a load at the logistics point. At this place
a number of AGVs is already parked. The influence of this
algorithm on the poor performance of the distributed parking
and charging stations is further investigated by choosing a
different algorithm. Another explanation is the fact that almost
half of the jobs in the system start at the logistics station. The
chance that a job will start exactly at the station where the
AGV is parked, is very small. The AGV thus still have to
take an elevator to a job and although being very close to it,
looses a big amount of time because of this.
No additional spaces
3 additional parking spaces
3 additional charging spaces
Average pickup time
[s]
826
1644
1651
Nr of jobs done
[Qty]
525
512
518
If the STD algorithm is used, the AGV will pick a job
closest to the location it became available. This will make
sure AGVs pickup a job if they are near to it, not first driving
to the other side of the hospital to pickup a job. The impact
of choosing this algorithm over the first available vehicle
algorithm is displayed in Table IV. From this, one can see
the impact of this algorithm when no additional parking and
charging stations are implemented. It diminishes the average
pickup time by 35%.
Adding parking or charging stations, however, still creates
a slower responding system, compared to a system without
additional parking and charging stations. This stems from two
things.
First, the order in which AGVs choose where to go is in
the order in which they became idle. If the AGV that first
becomes idle is at one of the distributed parking or charging
spots, it has a big chance needing to go to the logistics station,
making it actually a bad choice for that AGV to pickup that
job when other idling AGVs might be near that station. If on
the other hand a peak in demand enters the system, the AGVs
can handle more transports, going rapidly from one drop-off
to the next pickup, which can be seen from the number of
jobs done in Table IV: for all situations the number of jobs
done at 20:00 (in the peak) goes up.
Second, and this is only applicable to charging stations, if
an AGV needs to charge because of battery depletion, it will
go to the nearest charging station. After charging, the closest
job is probably not at the station next to where the AGV is
charging and there is a big chance the AGV will need to take
the elevator before reaching the nearest job. If AGVs are all
charging at the logistics station, there is a big chance a job
will be available there when the AGV finished charging. In
conclusion, this generates much higher average waiting times
than without distributed parking and charging stations.
Alternatively, positioning vehicles at a better location depending on the jobs expected might prove useful, studies on
optimal vehicle dwelling locations do promise shorter response
times [6]. However, these studies ignore battery management
and elevators, as are required in hospitals, and thus are not
representative for this specific application. Further research
should be done, addressing this possible improvement.
Using the NV algorithm for choosing the AGV produces
the output as listed in Table V. If no additional spaces are
added this algorithm performs almost the same as for the
FAV algorithm. If additional parking and charging stations are
added, the average pickup times go up, however, not as much
as for the FAV algorithm.
TABLE IV
I MPACT OF ADDING PARKING AND CHARGING STATIONS WHEN AGV S
TABLE VI
I MPACT OF CHOOSING A BATTERY CAPACITY DRIVEN ALGORITHM ON THE
PICKUP THE JOB CLOSEST BY
AVERAGE PICKUP TIME
Average pickup time
[s]
536
1173
1116
Nr of jobs done
[Qty]
528
528
529
TABLE V
I MPACT OF ADDING PARKING AND CHARGING STATIONS WHEN USING THE
NEAREST VEHICLE FOR THE OLDEST JOB
Average pickup time
[s]
823
1481
1462
Nr of jobs done
[Qty]
523
520
520
Capacity
[Ah]
30
50
FAV
[s]
826
388
HRBC
[s]
841
396
LRBC
[s]
895
427
TABLE VII
I MPACT OF CHOOSING A BATTERY CAPACITY DRIVEN ALGORITHM ON THE
NUMBER OF JOBS DONE RIGHT AFTER THE PEAK
Capacity
[Ah]
30
50
FAV
[Qty]
525
534
HRBC
[Qty]
521
533
LRBC
[Qty]
521
530
is still able to handle previous peaks in slower times.
The conclusion for this algorithm is thus the same as for
the two previous ones, adding parking or charging stations
worsens the average pickup time and throughput. Again, the
system does remain stable, it can still handle the jobs as can
be seen from the number of jobs handled.
Another reason for the poor performance of distributed
parking and charging stations in this situation can be the fact
that AGVs may need to take two elevators to get at the closest
station, while driving to the logistics point might be faster. This
is not incorporated in the way the AGVs choose their idling
location, they only drive to the one closest by. The impact of
choosing a parking or charging location to which the travel
time is the lowest is something that should be addressed in a
follow-up research.
The impact of choosing a remaining battery capacity driven
algorithm is displayed for the HRBC algorithm in Table
VI. From these numbers no improvement is noticeable when
choosing such an algorithm.
If the HRBC algorithm is used for dispatching, improvement
can be made if the battery capacity of all AGVs combined
is enough to get through all peaks seperately, after which all
AGVs can charge again. To get to this point, more simulations
need to be done to determine this capacity. When AGVs are
required to charge during some of the bigger peaks, choosing
this algorithm will only take all AGVs out of service for
charging at the same time, resulting in poor performance for
the jobs then waiting to be picked up.
If the LRBC algorithm is used, small peaks cannot even
be handled and AGVs will be required to charge within these
peaks. If a more constant flow of jobs is expected choosing a
dispatching algorithm of this sort ensures that the maximum
number of AGVs out of service because of charging will stay
low, it is however a worse solution for this case compared to
other algorithms.
For the amount of jobs handled within the last peak the
numbers do not change a lot. A slightly lower number of jobs
is handled when choosing one of the battery capacity driven
algorithms. This means the jobs are still handled, and there is
no big lag in handling jobs. The system is thus still stable, it
VI. C ONCLUSION
The influence of battery capacity, extra charging and parking
spaces and battery capacity driven algorithms was tested on a
specific case.
Changing battery capacity has a very big influence on the
average pickup time of jobs during a day in an AGV system.
This is mainly triggered by the insufficient power in the battery
during a peak. When a battery has enough capacity to handle
peaks and charge during slow times large decreases of average
pickup time can be measured. Incorporating battery capacity
as a design parameter is thus essential in the design of an
AGV system.
Implementing extra charging of parking spaces should still
be an addition to the system, but only when appropriate dispatching functions are chosen and a location for these spaces is
chosen keeping in mind the expected starting location of jobs.
This was however not proven in this research. The impact of
adding these spaces to a system can decrease performance if
the impact of this algorithm or the position of these spaces
with respect to the demand is not substantiated. Next to that,
adding these additional stations is not as straightforward as
might be the case in production systems, the influence of
battery management, the distribution of jobs during a day
and the impact of elevators cannot be ignored. In conclusion,
the importance of battery management in simulations is again
emphasized, because adding or removing these extra stations
might give an undesirable effect when looking at the average
pickup time of jobs.
Battery capacity driven algorithms picking either the AGV
with the lowest remaining or highest remaining battery charge
did not improve the AGV system; it actually deteriorates the
performance. Only if a specific case is presented, for instance
when the battery capacity of all AGVs combined is enough to
handle a peak, choosing such an algorithm can be useful. In
order to test this, more research has to be performed testing
the impact of these algorithms on different job input scenarios
and different hospital layouts.
VII. R ECOMMENDATIONS
R EFERENCES
Given the outcomes of this research a number of followup researches should be done. First of all, research should be
done on where an AGV should park or charge in this type of
system, simply taking the space closest by has an undesirable
effect. Second, the impact of adding charging and parking
spaces as well as choosing an AGV based on remaining battery
charge should be performed using different battery capacities
to assess the impact of the chosen capacity on these outcomes.
Third, the impact should be studied for different workload
profiles, some having more peaks, some having a more evenly
distributed workload. Choosing a dispatching algorithm based
on battery capacity might prove useful in some of these
situations. Finally, a study has to be performed how all these
conclusions relate to different hospital layouts.
[1] K. Davina, “Development of a simulation-based tool for designing AGVsystems for hospital logistics,” 2012.TEL.7678, Transportation Engineering and Logistics, Delft University of Technology, Tech. Rep., Jun. 2012.
[2] R. McHaney, “Modelling battery constraints in discrete event automated
guided vehicle simulations,” International Journal of Production Research, vol. 33, no. 11, pp. 3023–3040, Nov. 1995.
[3] I. F. Vis, “Survey of research in the design and control of automated
guided vehicle systems,” European Journal of Operational Research, vol.
170, no. 3, pp. 677–709, May 2006.
[4] H. P. M. Veeke and J. A. Ottjes, “TOMAS: Tool for object-oriented
modelling and simulation,” in Proceedings of the Business and Industry
Simulation Symposium. Washington D.C.: Delft University of Technology, Apr. 2000, pp. 1–6.
[5] M. M. Srinivasan, Y. A. Bozer, and M. CHO, “TRIP-BASED MATERIAL
HANDLING SYSTEMS: THROUGHPUT CAPACITY ANALYSIS,” IIE
transactions, vol. 26, no. 1, pp. 70–89, 1994.
[6] C. Lee and J. A. Ventura, “Optimal dwell point location of automated
guided vehicles to minimize mean response time in a loop layout,”
International Journal of Production Research, vol. 39, no. 17, pp. 4013–
4031, 2001.
ACKNOWLEDGMENT
The authors would like to thank the experts at Deerns
Consulting Engineers for their technical support and helpful
insights.
Appendix B
The Assignment by Deerns
Consulting Engineers
Deze opdracht betreft modelvorming & simulatie. Deerns raadgevende ingenieurs bv heeft behoefte aan een simulatiemodel, waarin AGV systemen onder andere kunnen worden beoordeeld
op lay-out, capaciteit en wachten bestemmingstijden. De laatste jaren constateert Deerns
een sterke opkomst van dergelijke systemen in de gezondheidszorg, met name voor interne distributie van linnen, maaltijden, magazijngoederen, steriele goederen, post, afval et cetera. Deze
opkomst heeft onder andere te maken met de toegenomen omvang van interne distributie in
ziekenhuizen, de toegenomen kosten van personeel en de afgenomen beschikbaarheid van personeel. Ook speelt hierin een rol, dat moderne systemen geen voorzieningen in de vloer meer nodig
hebben, maar navigeren op basis van bouwkundige onderleggers en positiesensoren. Aangezien
Deerns betrokken is bij het ontwerp van veel grote ziekenhuizen, wil het voor zijn opdrachtgevers
de lay-out, omvang en uitvoering van dergelijke systemen van tevoren kunnen optimaliseren door
de prestaties op het gebied van capaciteit, bezetting en wachten bestemmingstijden te kunnen
berekenen.
Technisch inhoudelijk:
De opdracht omvat het ontwikkelen van een simulatiemodel in Delphi Enterprise Dynamics 8,
waarin grootschalige systemen met talloze laad-losposities, AGV-karren, oplaadpunten, paden
(gangen), knopen (kruisingen) op een snelle en gebruiksvriendelijke manier kunnen worden
155
An AGVS design tool
gemodelleerd. Aan dit model dient een willekeurig verkeersprofiel van zendingen te kunnen
worden aangeboden (bestemming, aankomsttijd, prioriteit et cetera), zowel door middel van een
centraal spoorboekje met alle dagelijkse transporten, als met lokaal verzend- en ontvangstpatroon per station. Beide op basis van random generator met exponentiele spreiding en als vaste
lijst met zendingen (spoorboekje).
Met het model moet kunnen worden geoptimaliseerd:
• Het aantal benodigde AGV’s;
• Het aantal (buffer) ontvangst- en verzendposities per station;
• Het aantal en de positie van oplaadpunten voor AGV’s;
• Optimalisatie van de af te leggen route door AGV’s op basis van analyse van het netwerk
en de te verwachten drukte op paden/knopen;
• Optimalisatie van de toewijzing van AGV’s aan aanvragen, waarbij minimaal kan worden gekozen tussen: volgorde van aanvraag (fifo), kortste wachttijden aanvragen, hoogste
bezetting AGV’s, kortste afgelegde afstand AGV’s, resterend bereik accu’s, maximaal percentage dubbelslagen (= een zending afleveren, waarbij een lege kar retour kan worden
meegenomen);
• Overname van een haalopdracht door een AGV die dichter bij vrijkomt (continue optimalisatie door tussentijdse bestemmingswijziging).
Het model dient minimaal de volgende functionaliteit te kennen:
• Analyse van de bezetting van AGV’s (rijden, wachten op pad, wachten op laad-lospositie,
laden/lossen, inactief, opladen accu), zowel getalsmatig (uitvoerfile) als in grafieken;
• Analyse van de bezetting van paden (gangen), zowel getalsmatig (uitvoerfile) als in grafieken;
• Analyse van de bezetting van ontvangst- en verzendposities per station, zowel getalsmatig
(uitvoerfile) als in grafieken;
• Analyse van de wachttijd, reistijd en bestemmingstijd per zending, per station en per
zendingtype (wel of geen prioriteit), zowel getalsmatig (uitvoerfile) als in grafieken;
156
K. Davina
2012.TEL.7687
An AGVS design tool
• De rijdsnelheid dient afhankelijk te zijn van het pad (c.q. de gangbreedte en publiek
gebied of niet), waarbij sommige paden onbeperkt tweerichtingsverkeer toelaten (brede
gang), sommige paden onbeperkt eenrichtingsverkeer (in een vaste richting) en sommige
paden beperkt eenrichtingsverkeer toelaten (in beide richtingen, waarbij het pad bezet kan
zijn als er al een AGV rijdt (bijvoorbeeld bocht met krappe bochtstraal, waar passeren
onmogelijk is). De snelheid wordt gereduceerd bij gevaar (obstakels), bij automatische
deuren en andere doorgangen en in bochten;
• AGV’s kunnen meerdere verdiepingen in het ziekenhuis bedienen door op afstand liften
op te roepen en te gebruiken. De liften dienen minimaal de volgende (beperkte) functionaliteit te kennen (wachttijd uit een verdeling, deuropentijd, inrijdtijd, deursluittijd, reistijd
afhankelijk van hoogte en hefsnelheid, uitrijdtijd). Liften kunnen maar een AGV tegelijk
vervoeren, dus de wachttijd voor een lift wordt geloot (als lift vrij is) of berekend (als de
lift al een AGV vervoert);
• Aan zendingen moet een prioriteit kunnen worden gegeven, bijvoorbeeld maaltijdtransporten met een maximale aflevertijd vanwege temperatuur;
• De lay-out van het netwerk dient te kunnen worden ingetekend op een voor de klant herkenbare onderlegger in PDF formaat en ACAD formaat. Hierbij dienen diverse verdiepingen
gelijktijdig zichtbaar te kunnen worden gemaakt;
• Animatie van het proces in 2D. Hierbij dient de status van AGV’s zendingen, paden en
stations door middel van kleuren herkenbaar te zijn. AGV’s hierbij tekenen in overeenstemming met rijdrichting en orientatie laad-/losstation en oplaadpunt;
• Instelbare parameters AGV: transportsnelheid AGV, versnelling/vertraging AGV, verliestijd knopen, verliestijd omkeren, verliestijd laden, verliestijd lossen;
• Instelbare parameters accu: bereik (in tijd en in afgelegde meters), laadtijd et cetera
afhankelijk van operationele eisen (hefcapaciteit, snelheid en actieradius);
• Analyse met beide hoofdsoorten AGV’s moet mogelijk zijn: universele onderladers (niet
richtingselectief), heftruck (richtingselectief, moet keren en draaien);
• Het moet gemakkelijk en niet te arbeidsintensief zijn om een netwerk lay-out te definieren
of te wijzigen. Het moet zowel in een notepad omgeving kunnen, als in aangeboden invulK. Davina
2012.TEL.7687
157
An AGVS design tool
velden. Indien een waarde in een invulveld gewijzigd moet worden, dient niet het gehele
model opnieuw hoeven te worden ingevoerd;
• Het moet mogelijk zijn om een dag, dagdeel (instelbare begin- en eindtijd) of run van
meerdere dagen (met verschillende startwaarden van de randomgeneratoren) te testen;
• De resultaten zowel getalsmatig (uitvoerfile) als in grafieken beschikbaar stellen, waarbij
ten minste gemiddelde waarde, minimale waarde, maximale waarde en standaarddeviatie
beschikbaar komen;
• Simulaties moeten reproduceerbaar zijn door identieke startwaarden van de randomgeneratoren toe te passen (ten behoeve van scenariostudie, bijvoorbeeld optimalisatiecriterium);
• Beschikbaarheid AGV’s, laadstations, knopen en paden moet instelbaar zijn in percentage
uptime en downtime en MTTR (mean time to repair).
Proces inhoudelijk:
• Naast de ontwikkeling van het hierboven omschreven simulatiemodel, omvat de opdracht
tevens de volgende onderdelen:
• Aantoonbare verificatie en validatie
• Gebruikersinstructie/presentatie (intern bij Deerns)
• Gebruikershandleiding
• Toepassing van het model voor de analyse van een bestaand of nog te bouwen ziekenhuis
• Eindrapportage
•
The supervisor,
Ir. Jochem Wit
158
K. Davina
2012.TEL.7687
Appendix C
PROPER model for the AGV
system
159
An AGVS design tool
160
K. Davina
2012.TEL.7687
An AGVS design tool
Handle transport tasks
without logistics personnel
Check key performance indicators
Control
SC
SC
Track Job
Dispatch Job
LS
Wait for dock
AGV
Jobs in
User
Accept
LS
Wait for
empty slot
LS
SC
Register Job
AGV
Put in empty slot
LS
LS
Transfer Job
LS
AGV
LS
Pick from dock
AGV
Calculate Route
SC
Drive
Get Route
AGV
US
Transport
AGV
SC
Register job
perfomance
SC
Wait for US
AGV
SC
Wait for Job
AGV
US
Deliver
AGV
AGV
Accept
US
SC
User
Finish Job
Release
US
US
Jobs out
Wait for
empty slot
Wait for
goods
US
LS
Wait for AGV
US
Transfer
Resources
used
Resources
available
Available docks
Available vehicles
LS
Transform
Figure C.1: Total proper model of the conceptual model
K. Davina
2012.TEL.7687
Available docks
AGV
161
US
An AGVS design tool
162
K. Davina
2012.TEL.7687
Appendix D
Database registration types
Table D.1: Job values registration types
Regtype
Info
drivingdistance
drivingtime
endtime
enroutetime
jobintime
starttime
waitforclaimelement
waitfordockenter
waitfordockexit
waitforloading
distance the job has travelled
time the job has travelled
the time the job is removed from the system
the time it took from pickup to drop-off
is 1 if the job is in time, 0 otherwise
the time the job is created in the system
the time a job has to wait for a claim element when enroute
the time it takes for the job to get a position in a dock
the time it takes for the job to exit the system after drop-off
the time the job has to wait from entering the dock to pickup
163
An AGVS design tool
Table D.2: Queue data registration types
Regtype
Info
length
meanwt
meanlength
Queue length at the moment
The mean waiting time in the queue
The mean length of the queue
Table D.3: Claim data registration types
Regtype
Info
claimchange
registration of a change in number of claimers
Table D.4: AGV values registration types
Regtype
Info
batteryempty
chargetime
drivingdistance
drivingtime
drivingtimetoparking
drivingtimeunloaded
jobassignment
jobdone
jobpickup
waitforclaimelement
waitforelevator#
Number of times the battery went empty
Time spend charging
Distance driven by AGV
Time driving with load
Time spend driving to charging
Time spend driving to parking
Time driving without load
position in the queue of the assigned job (start=0)
Number of jobs deliver
Number of jobs picked up
time spend waiting to claim
time spend waiting for an elevator, where #=
1 busy with jobs
2 enroute to parking space
3 enroute to charging station
The time it takes for the elevator to get at the correct floor
Time waiting for a dock to become available for a dropoff
Time waiting for the dock with the assigned job
time spend riding an elevator, where #=
1 busy with jobs
2 enroute to parking space
3 enroute to charging station
waitforelevatorreal
waitforroutetodockdropoff
waitforroutetodockpickup
waitinelevator#
164
K. Davina
2012.TEL.7687
Appendix E
Expert validations
The following experts from the transport and logistics department of Deerns Consulting Engineers validated parts of the work.
E.1
Conceptual Model Validation
Jos van Velzen
ir. Jochem Wit
Senior Specialist
Senior Expert
Deerns Consulting Engineers
165
An AGVS design tool
E.2
Operational Model Validation
ir. Jochem Wit
ir. Matthijs de Kleine
Senior Expert
Specialist
Jos van Velzen
Senior Specialist
166
K. Davina
2012.TEL.7687
An AGVS design tool
E.3
Expert feedback
“The simulation program offers a versatile range of possibilities for AGV system assessment.
In the hospital projects Deerns consults for, it should be possible to simulate with different layouts, numbers of stations, buffer positions, charging and parking positions and numbers and
characteristics of AGV’s. The simulation model offers all these possibilities. Additionally, it is
possible to study the effect of different dispatching and routing algorithms, and charging strategies
on the system performance. This offers the possibility to compare the systems and controls of
several suppliers.
The GUI is constructed logically, but will require an elaborated tutorial to define the correct
manner and nature of parameter input for creating system lay-outs. The output database is
extensive, which offers the possibility to perform several additional statistical operations with the
output data. The animation is basic and could have been more attractive for client presentation.
Finally, the results and the effect of variation of input parameters by a sensitivity analysis, appear
reliable and are within range of existing systems.”
ir. Jochem Wit
Senior Expert and Team Leader Transport and Logistics
”On tuesday the 29th of May 2012 I have tested the simulation suite, which is part of the
graduation assignment of Koen Davina. The suite has a logical structure which makes structured
working possible. The menu structure is clear and organized. Inputting the data or making
changes or additions to the input is made easy because of this. It however remains necessary to
have a certain level of basic knowledge of AGV systems and the associated logistic choices.
The tool addresses the parameters that we deemed necessary, but it also provides parameters
added by the developer. Because of these extra contributions the tool became more flexible, giving
us the option to adopt future developments in the simulations. This concerns, for example, the
parameters for to be applied batteries, as well as the time delay variable for nodes in the AGV
K. Davina
2012.TEL.7687
167
An AGVS design tool
route.
The results of the simulation are presented in a clear way. The output files are thus well
suited for usage in reports. The final result is considered a good result and we expect that it will
serve us for years.”
Jos van Velzen
Senior Specialist Transport and Logistics
”The simulation program offers the necessary flexibility to use project specific input. The
program gives enough output data for a thorough understanding of the problem at hand, without
cluttering the entirety. Therefore the program offers sufficient starting point for making its use
valuable.
The results the simulation tool produces, are logically interpretable. In addition, the outputs
generated by the tool are in sync with the expectations. This is also true for changes in output
data when changing the input.
A short explanation was sufficient to be able to use the simulation tool. The graphical user
interface is logical and gives a clear overview.”
ir. Matthijs de Kleine
Specialist Transport and Logistics
168
K. Davina
2012.TEL.7687
Appendix F
Testcase data
169
An AGVS design tool
Table F.1: Assumptions done for input values for the performed test case
Description
Unit
Elevators
Door delay on enter
Door delay on exit
Average waiting time
- for dedicated elevators
sec
sec
sec
sec
3
3
60
90
min
min
3
5
Stations
Job removal time:
- logistics point
- other stations
Total nr of docks per station:
(equal amount for loading and unloading)
- Logistics point
- At elevator block 2
- At elevator blocks 1 and 3
Dock buffer size
AGV
speed
Pickup time
Dropoff time
Elevator drive in time
Elevator drive out time
Charge enter time
Charge exit time
Park enter time
Park exit time
Node delay time
Energy usage
Pickup
Dropoff
Driving empty
Driving loaded
Waiting
Parking
170
6
4
2
unlimited
[m/s]
sec
sec
sec
sec
sec
sec
sec
sec
sec
Battery
Fast charging
Slow charging
Turning point
Charge to minimal %
Opportunity charging
Safety factor power calculation
[Units/hour]
[Units/hour]
[Units]
[Units]
[Units/sec]
[Units/sec]
[Units/sec]
[Units/sec]
K. Davina
Value
1
3
3
3
3
3
3
3
3
1
40000
10000
65%
30%
No
1.3
65
50
10
15
5
1
2012.TEL.7687
An AGVS design tool
Table F.2: All transport flows used for the test case
From
To
Type
Start time
End time
Nr of jobs
Priority
Maximum transit time
Apothecary
Station 1-3
Random
09:00
11:00
1
1
45
Apothecary
Station 1-2
Random
09:00
11:00
2
1
45
Apothecary
Station 1-1
Random
09:00
11:00
1
1
45
Apothecary
Station 2-3
Random
09:00
11:00
1
1
45
Apothecary
Station 2-2
Random
09:00
11:00
2
1
45
Apothecary
Station 2-1
Random
09:00
11:00
1
1
45
Apothecary
Station 3-3
Random
09:00
11:00
1
1
45
Apothecary
Station 3-2
Random
09:00
11:00
2
1
45
Apothecary
Station 3-1
Random
09:00
11:00
1
1
45
Apothecary
Station 4-3
Random
09:00
11:00
1
1
45
Apothecary
Station 4-2
Random
09:00
11:00
2
1
45
Apothecary
Station 4-1
Random
09:00
11:00
1
1
45
Apothecary
Station 5-3
Random
09:00
11:00
1
1
45
Apothecary
Station 5-2
Random
09:00
11:00
2
1
45
Station 1-3
Apothecary
Random
15:00
16:00
1
2
180
Station 1-2
Apothecary
Random
15:00
16:00
2
2
180
Station 1-1
Apothecary
Random
15:00
16:00
1
2
180
Station 2-3
Apothecary
Random
15:00
16:00
1
2
180
Station 2-2
Apothecary
Random
15:00
16:00
2
2
180
Station 2-1
Apothecary
Random
15:00
16:00
1
2
180
Station 3-3
Apothecary
Random
15:00
16:00
1
2
180
Station 3-2
Apothecary
Random
15:00
16:00
2
2
180
Station 3-1
Apothecary
Random
15:00
16:00
1
2
180
Station 4-3
Apothecary
Random
15:00
16:00
1
2
180
Station 4-2
Apothecary
Random
15:00
16:00
2
2
180
Station 4-1
Apothecary
Random
15:00
16:00
1
2
180
Station 5-3
Apothecary
Random
15:00
16:00
1
2
180
Station 5-2
Apothecary
Random
15:00
16:00
2
2
180
Logistics Point
Station 0-1
Single
06:00
1
1
45
Logistics Point
Station 1-2
Single
06:00
6
1
45
Logistics Point
Station 2-2
Single
06:00
6
1
45
Logistics Point
Station 2-1
Single
06:00
3
1
45
Logistics Point
Station 3-2
Single
06:30
6
1
45
Logistics Point
Station 4-2
Single
06:30
6
1
45
Logistics Point
Station 4-1
Single
06:30
3
1
45
Logistics Point
Station 0-1
Single
11:00
1
1
45
Logistics Point
Station 1-2
Single
11:00
6
1
45
Logistics Point
Station 2-2
Single
11:00
6
1
45
Logistics Point
Station 2-1
Single
11:00
3
1
45
Logistics Point
Station 3-2
Single
11:30
6
1
45
Logistics Point
Station 4-2
Single
11:30
6
1
45
Logistics Point
Station 4-1
Single
11:30
3
1
45
Logistics Point
Station 1-2
Single
16:00
6
1
45
Logistics Point
Station 2-2
Single
16:00
6
1
45
Logistics Point
Station 2-1
Single
16:00
3
1
45
Logistics Point
Station 3-2
Single
16:30
6
1
45
Logistics Point
Station 4-2
Single
16:30
6
1
45
Logistics Point
Station 4-1
Single
16:30
3
1
45
Station 0-1
Logistics Point
Single
07:00
1
2
90
Station 1-2
Logistics Point
Single
07:00
6
2
90
Station 2-2
Logistics Point
Single
07:00
6
2
90
Station 2-1
Logistics Point
Single
07:00
3
2
90
Station 3-2
Logistics Point
Single
07:30
6
2
90
Station 4-2
Logistics Point
Single
07:30
6
2
90
Station 4-1
Logistics Point
Single
07:30
3
2
90
Station 0-1
Logistics Point
Single
12:00
1
2
90
Station 1-2
Logistics Point
Single
12:00
6
2
90
Station 2-2
Logistics Point
Single
12:00
6
2
90
Continued on next page
K. Davina
2012.TEL.7687
171
An AGVS design tool
From
To
Type
Start time
Nr of jobs
Priority
Station 2-1
Logistics Point
Single
12:00
End time
3
2
90
Station 3-2
Logistics Point
Single
12:30
6
2
90
Station 4-2
Logistics Point
Single
12:30
6
2
90
Station 4-1
Logistics Point
Single
12:30
3
2
90
Station 1-2
Logistics Point
Single
17:00
6
2
90
Station 2-2
Logistics Point
Single
17:00
6
2
90
Station 2-1
Logistics Point
Single
17:00
3
2
90
Station 3-2
Logistics Point
Single
17:30
6
2
90
Station 4-2
Logistics Point
Single
17:30
6
2
90
Station 4-1
Logistics Point
Single
17:30
3
2
90
Logistics Point
Station 1-2
Single
10:00
2
1
45
Logistics Point
Station 2-2
Single
10:00
2
1
45
Logistics Point
Station 2-1
Single
10:00
1
1
45
Logistics Point
Station 3-2
Single
10:00
1
1
45
Logistics Point
Station 4-2
Single
10:00
2
1
45
Logistics Point
Station 4-1
Single
10:00
1
1
45
Logistics Point
Station 0-1
Single
14:00
1
1
45
Logistics Point
Station 1-2
Single
14:00
2
1
45
Logistics Point
Station 2-2
Single
14:00
2
1
45
Logistics Point
Station 2-1
Single
14:00
1
1
45
Logistics Point
Station 3-2
Single
14:00
2
1
45
Logistics Point
Station 4-2
Single
14:00
1
1
45
Logistics Point
Station 4-1
Single
14:00
1
1
45
Logistics Point
Station 0-1
Single
19:00
1
1
45
Logistics Point
Station 1-2
Single
19:00
1
1
45
Logistics Point
Station 2-2
Single
19:00
1
1
45
Logistics Point
Station 2-1
Single
19:00
1
1
45
Logistics Point
Station 3-2
Single
19:00
2
1
45
Logistics Point
Station 4-2
Single
19:00
2
1
45
Logistics Point
Station 4-1
Single
19:00
1
1
45
Station 1-2
Logistics Point
Single
10:30
2
2
45
Station 2-2
Logistics Point
Single
10:30
2
2
45
Station 2-1
Logistics Point
Single
10:30
1
2
45
Station 3-2
Logistics Point
Single
10:30
1
2
45
Station 4-2
Logistics Point
Single
10:30
2
2
45
Station 4-1
Logistics Point
Single
10:30
1
2
45
Station 0-1
Logistics Point
Single
14:30
1
2
45
Station 1-2
Logistics Point
Single
14:30
2
2
45
Station 2-2
Logistics Point
Single
14:30
2
2
45
Station 2-1
Logistics Point
Single
14:30
1
2
45
Station 3-2
Logistics Point
Single
14:30
2
2
45
Station 4-2
Logistics Point
Single
14:30
1
2
45
Station 4-1
Logistics Point
Single
14:30
1
2
45
Station 0-1
Logistics Point
Single
19:30
1
2
45
Station 1-2
Logistics Point
Single
19:30
1
2
45
Station 2-2
Logistics Point
Single
19:30
1
2
45
Station 2-1
Logistics Point
Single
19:30
1
2
45
Station 3-2
Logistics Point
Single
19:30
2
2
45
Station 4-2
Logistics Point
Single
19:30
2
2
45
Station 4-1
Logistics Point
Single
19:30
1
2
45
Logistics Point
Station 1-3
Random
08:00
10:00
3
1
60
Logistics Point
Station 1-2
Random
08:00
10:00
5
1
60
Logistics Point
Station 1-1
Random
08:00
10:00
2
1
60
Logistics Point
Station 2-3
Random
08:00
10:00
3
1
60
Logistics Point
Station 2-2
Random
08:00
10:00
5
1
60
Logistics Point
Station 2-1
Random
08:00
10:00
2
1
60
Logistics Point
Station 3-3
Random
08:00
10:00
3
1
60
Logistics Point
Station 3-2
Random
08:00
10:00
5
1
60
172
K. Davina
2012.TEL.7687
An AGVS design tool
From
To
Type
Start time
End time
Nr of jobs
Priority
Logistics Point
Station 3-1
Random
08:00
10:00
2
1
60
Logistics Point
Station 4-3
Random
08:00
10:00
2
1
60
Logistics Point
Station 4-2
Random
08:00
10:00
3
1
60
Logistics Point
Station 4-1
Random
08:00
10:00
2
1
60
Logistics Point
Station 5-3
Random
08:00
10:00
2
1
60
Logistics Point
Station 5-2
Random
08:00
10:00
2
1
60
Logistics Point
Station 5-1
Random
08:00
10:00
2
1
60
Logistics Point
Station 0-3
Random
19:00
20:00
1
1
60
Logistics Point
Station 0-2
Random
19:00
20:00
1
1
60
Logistics Point
Station 0-1
Random
19:00
20:00
1
1
60
Logistics Point
Station 5-3
Random
19:00
20:00
1
1
60
Logistics Point
Station 5-2
Random
19:00
20:00
2
1
60
Logistics Point
Station 5-1
Random
19:00
20:00
1
1
60
Station 1-3
Logistics Point
Random
08:00
10:00
3
1
60
Station 1-2
Logistics Point
Random
08:00
10:00
5
1
60
Station 1-1
Logistics Point
Random
08:00
10:00
2
1
60
Station 2-3
Logistics Point
Random
08:00
10:00
3
1
60
Station 2-2
Logistics Point
Random
08:00
10:00
5
1
60
Station 2-1
Logistics Point
Random
08:00
10:00
2
1
60
Station 3-3
Logistics Point
Random
08:00
10:00
3
1
60
Station 3-2
Logistics Point
Random
08:00
10:00
5
1
60
Station 3-1
Logistics Point
Random
08:00
10:00
2
1
60
Station 4-3
Logistics Point
Random
08:00
10:00
2
1
60
Station 4-2
Logistics Point
Random
08:00
10:00
3
1
60
Station 4-1
Logistics Point
Random
08:00
10:00
2
1
60
Station 5-3
Logistics Point
Random
08:00
10:00
2
1
60
Station 5-2
Logistics Point
Random
08:00
10:00
2
1
60
Station 5-1
Logistics Point
Random
08:00
10:00
2
1
60
Station 0-3
Logistics Point
Random
19:00
20:00
1
1
60
Station 0-2
Logistics Point
Random
19:00
20:00
1
1
60
Station 0-1
Logistics Point
Random
19:00
20:00
1
1
60
Station 5-3
Logistics Point
Random
19:00
20:00
1
1
60
Station 5-2
Logistics Point
Random
19:00
20:00
2
1
60
Station 5-1
Logistics Point
Random
19:00
20:00
1
1
60
Logistics Point
Station 0-3
Static
06:00
1
2
180
Logistics Point
Station 0-1
Static
06:10
1
2
180
Logistics Point
Station 1-3
Static
06:20
1
2
180
Logistics Point
Station 1-2
Static
06:30
1
2
180
Logistics Point
Station 1-1
Static
06:40
1
2
180
Logistics Point
Station 2-3
Static
06:50
1
2
180
Logistics Point
Station 2-2
Static
07:00
1
2
180
Logistics Point
Station 3-3
Static
07:10
1
2
180
Logistics Point
Station 3-1
Static
07:20
1
2
180
Logistics Point
Station 4-3
Static
07:30
1
2
180
Logistics Point
Station 5-3
Static
07:40
1
2
180
Logistics Point
Station 5-2
Static
07:50
1
2
180
Logistics Point
Station 0-2
Static
13:00
1
2
180
Logistics Point
Station 1-2
Static
13:15
1
2
180
Logistics Point
Station 2-2
Static
13:30
1
2
180
Logistics Point
Station 3-2
Static
13:45
2
2
180
Logistics Point
Station 4-2
Static
14:00
2
2
180
Logistics Point
Station 0-3
Static
17:30
1
2
180
Logistics Point
Station 0-2
Static
17:40
1
2
180
Logistics Point
Station 0-1
Static
17:50
1
2
180
Logistics Point
Station 1-3
Static
18:00
1
2
180
Logistics Point
Station 2-3
Static
18:10
1
2
180
Logistics Point
Station 2-1
Static
18:20
1
2
180
Logistics Point
Station 3-3
Static
18:30
1
2
180
K. Davina
2012.TEL.7687
173
An AGVS design tool
From
To
Type
Start time
Nr of jobs
Priority
Logistics Point
Station 3-1
Static
18:40
End time
1
2
180
Logistics Point
Station 4-1
Static
18:50
1
2
180
Logistics Point
Station 5-3
Static
19:00
1
2
180
Logistics Point
Station 5-2
Static
19:10
2
2
180
Logistics Point
Station 5-1
Static
19:20
1
2
180
Station 0-3
Logistics Point
Static
06:00
1
2
180
Station 0-1
Logistics Point
Static
06:10
1
2
180
Station 1-3
Logistics Point
Static
06:20
1
2
180
Station 1-2
Logistics Point
Static
06:30
1
2
180
Station 1-1
Logistics Point
Static
06:40
1
2
180
Station 2-3
Logistics Point
Static
06:50
1
2
180
Station 2-2
Logistics Point
Static
07:00
1
2
180
Station 3-3
Logistics Point
Static
07:10
1
2
180
Station 3-1
Logistics Point
Static
07:20
1
2
180
Station 4-3
Logistics Point
Static
07:30
1
2
180
Station 5-3
Logistics Point
Static
07:40
1
2
180
Station 5-2
Logistics Point
Static
07:50
1
2
180
Station 0-2
Logistics Point
Static
13:00
1
2
180
Station 1-2
Logistics Point
Static
13:15
1
2
180
Station 2-2
Logistics Point
Static
13:30
1
2
180
Station 3-2
Logistics Point
Static
13:45
2
2
180
Station 4-2
Logistics Point
Static
14:00
2
2
180
Station 0-3
Logistics Point
Static
17:30
1
2
180
Station 0-2
Logistics Point
Static
17:40
1
2
180
Station 0-1
Logistics Point
Static
17:50
1
2
180
Station 1-3
Logistics Point
Static
18:00
1
2
180
Station 2-3
Logistics Point
Static
18:10
1
2
180
Station 2-1
Logistics Point
Static
18:20
1
2
180
Station 3-3
Logistics Point
Static
18:30
1
2
180
Station 3-1
Logistics Point
Static
18:40
1
2
180
Station 4-1
Logistics Point
Static
18:50
1
2
180
Station 5-3
Logistics Point
Static
19:00
1
2
180
Station 5-2
Logistics Point
Static
19:10
2
2
180
Station 5-1
Logistics Point
Static
19:20
1
2
180
Logistics Point
Station 0-3
Exp. Distr.
07:30
20:30
1
1
60
Logistics Point
Station 0-2
Exp. Distr.
07:30
20:30
1
1
60
Logistics Point
Station 0-1
Exp. Distr.
07:30
20:30
1
1
60
Logistics Point
Station 1-3
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 1-2
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 1-1
Exp. Distr.
07:30
20:30
1
1
60
Logistics Point
Station 2-3
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 2-2
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 2-1
Exp. Distr.
07:30
20:30
1
1
60
Logistics Point
Station 3-3
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 3-2
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 3-1
Exp. Distr.
07:30
20:30
1
1
60
Logistics Point
Station 4-3
Exp. Distr.
07:30
20:30
2
1
60
Logistics Point
Station 4-2
Exp. Distr.
07:30
20:30
2
1
60
Logistics Point
Station 4-1
Exp. Distr.
07:30
20:30
2
1
60
Logistics Point
Station 5-3
Exp. Distr.
07:30
20:30
2
1
60
Logistics Point
Station 5-2
Exp. Distr.
07:30
20:30
3
1
60
Logistics Point
Station 5-1
Exp. Distr.
07:30
20:30
2
1
60
Station 0-3
Logistics Point
Exp. Distr.
07:30
20:30
1
2
180
Station 0-2
Logistics Point
Exp. Distr.
07:30
20:30
1
2
180
Station 0-1
Logistics Point
Exp. Distr.
07:30
20:30
1
2
180
Station 1-3
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 1-2
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 1-1
Logistics Point
Exp. Distr.
07:30
20:30
1
2
180
174
K. Davina
2012.TEL.7687
An AGVS design tool
From
To
Type
Start time
End time
Nr of jobs
Priority
Station 2-3
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 2-2
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 2-1
Logistics Point
Exp. Distr.
07:30
20:30
1
2
180
Station 3-3
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 3-2
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 3-1
Logistics Point
Exp. Distr.
07:30
20:30
1
2
180
Station 4-3
Logistics Point
Exp. Distr.
07:30
20:30
2
2
180
Station 4-2
Logistics Point
Exp. Distr.
07:30
20:30
2
2
180
Station 4-1
Logistics Point
Exp. Distr.
07:30
20:30
2
2
180
Station 5-3
Logistics Point
Exp. Distr.
07:30
20:30
2
2
180
Station 5-2
Logistics Point
Exp. Distr.
07:30
20:30
3
2
180
Station 5-1
Logistics Point
Exp. Distr.
07:30
20:30
2
2
180
Logistics Point
Station 0-2
Random
06:00
21:00
1
1
45
Logistics Point
Station 0-1
Random
06:00
21:00
1
1
45
Logistics Point
Station 1-3
Random
06:00
21:00
1
1
45
Logistics Point
Station 1-2
Random
06:00
21:00
1
1
45
Logistics Point
Station 1-1
Random
06:00
21:00
1
1
45
Logistics Point
Station 2-3
Random
06:00
21:00
1
1
45
Logistics Point
Station 2-2
Random
06:00
21:00
1
1
45
Logistics Point
Station 3-3
Random
06:00
21:00
1
1
45
Logistics Point
Station 3-2
Random
06:00
21:00
1
1
45
Logistics Point
Station 3-1
Random
06:00
21:00
1
1
45
Logistics Point
Station 4-3
Random
06:00
21:00
1
1
45
Logistics Point
Station 4-2
Random
06:00
21:00
1
1
45
Logistics Point
Station 5-3
Random
06:00
21:00
1
1
45
Logistics Point
Station 5-2
Random
06:00
21:00
1
1
45
Station 0-2
Logistics Point
Random
06:00
21:00
1
2
180
Station 0-1
Logistics Point
Random
06:00
21:00
1
2
180
Station 1-3
Logistics Point
Random
06:00
21:00
1
2
180
Station 1-2
Logistics Point
Random
06:00
21:00
1
2
180
Station 1-1
Logistics Point
Random
06:00
21:00
1
2
180
Station 2-3
Logistics Point
Random
06:00
21:00
1
2
180
Station 2-2
Logistics Point
Random
06:00
21:00
1
2
180
Station 3-3
Logistics Point
Random
06:00
21:00
1
2
180
Station 3-2
Logistics Point
Random
06:00
21:00
1
2
180
Station 3-1
Logistics Point
Random
06:00
21:00
1
2
180
Station 4-3
Logistics Point
Random
06:00
21:00
1
2
180
Station 4-2
Logistics Point
Random
06:00
21:00
1
2
180
Station 5-3
Logistics Point
Random
06:00
21:00
1
2
180
Station 5-2
Logistics Point
Random
06:00
21:00
1
2
180
Logistics Point
Station 3-2
Static
13:00
2
1
45
Station 3-2
Logistics Point
Static
17:00
2
1
180
K. Davina
2012.TEL.7687
175
An AGVS design tool
176
K. Davina
2012.TEL.7687

Transport Engineering and Logistics Report

Transcription

Similar documents

HEDIN AGV

Salahuddin Kasem Khan, President, Bangladesh Employers

WERC Warehouse Employee Survey

fashion logistics - Logwin Logistics

Phoenix Logistics Center

Welcome to Weiss-Röhlig - Austrian Business Council

success in furniture retail

the sense of logistics

Harmac - Presentation Folder Brochure.indd

Read here more about our excellent logistics services. - Weiss