Simulation of an Electric Quarry with Automated Transporter Scheduling

IN

DEGREE PROJECT MATHEMATICS, SECOND CYCLE, 30 CREDITS

STOCKHOLM SWEDEN 2018 ,

Simulation of an Electric Quarry with Automated Transporter

Scheduling

BILIN CHEN IDA KARLSSON

KTH ROYAL INSTITUTE OF TECHNOLOGY

SCHOOL OF ENGINEERING SCIENCES

Simulation of an Electric Quarry with Automated Transporter

Scheduling

BILIN CHEN IDA KARLSSON

Degree Projects in Optimization and Systems Theory (30 ECTS credits) KTH Royal Institute of Technology year 2018

Supervisor at Syntell: , Lars-Olof Kihlström Supervisor at KTH: Per Enqvist

Examiner at KTH: Per Enqvist

TRITA-SCI-GRU 2018:372 MAT-E 2018:78

Royal Institute of Technology School of Engineering Sciences KTH SCI

SE-100 44 Stockholm, Sweden

URL: www.kth.se/sci

Abstract

An electric site project is being developed by Volvo Construction Equipment with the goal to transform the quarry and aggregate industry by reducing carbon emissions by up to 95 % and total ownership cost up to 25 %. The goal is achieved by using electrical autonomous vehicles as the work force.

In an effort to reduce lead times, from design to reality, the objective of this thesis was to develop a logical architecture of a quarry using the Systems Modelling Language. The logical model contains all the essential elements existent in a quarry and describes core behavior to reflect the requirements needed in an electric site.

The value of the logical model lies in its ability to aid the development process, complementing it with an executable simulation further show- cases that value. The simulation was used to analyze the performance of the electrical autonomous transporter HX02 that is instructed by an algorithm for optimal routing and scheduling.

The algorithm incorporates traffic to reduce congestion at vertices with high level of activity. Its robustness is evaluated by varying the number of transporters and the weight on the traffic cost in the cost function.

It was found that applying the traffic cost helped reduce the congestion

significantly and increased production, but at the cost of more battery

usage. The effect of incorporating traffic was most noticeable when there

were more than 10 transporters operational. But when the weight on the

traffic cost was too large, the production declined instead. The observed

time complexity of the algorithm was O(n ² ), which was feasible due to a

small input size n.

Simulering av ett elektriskt stenbrott med automatiserad dumper-schemal¨ aggning

Sammanfattning

Ett elektriskt stenbrottsprojekt drivs av Volvo Construction Equip- ment med m˚ alet att omvandla hela gruvindustrin. M˚ alet ¨ ar att minska kol- dioxidutsl¨ appen med upp till 95% och det totala ¨ agarskapskostnaden upp till 25%. F¨ or att uppn˚ a m˚ alet ska elektriska autonoma maskiner anv¨ andas i stenbrotten.

I syfte att minska ledtiden fr˚ an design till verklighet, var m˚ alet med denna avhandling att utveckla en logisk arkitektur av stenbrottet med Systems Modelling Language. Den logiska modellen inneh¨ oll v¨ asentliga element som ˚ aterfinns i ett stenbrott och beskriver k¨ arnbeteenden f¨ or att

˚ aterspegla de krav som uppst˚ ar i ett elektrisk stenbrott.

F¨ or att ytterligare p˚ avisa v¨ ardet som den logiska modellen besitter och framf¨ ora dess betydelse i rollen att st¨ odja utvecklingsprocessen, skapades en exekverbar simulering som ett komplement. Simuleringen anv¨ andes f¨ or att analysera prestandan hos den elektriska autonoma dumpern HX02 som fick instruktioner av en algoritm f¨ or optimal ruttplanering.

Algoritmen tog h¨ ansyn till trafiken p˚ a omr˚ adet f¨ or att minska trafik- stockning vid noder med h¨ og aktivitetsniv˚ a. Dess robusthet utv¨ arderades genom att variera p˚ a antalet dumprar och vikten p˚ a trafikkostnaden i kostnadsfunktionen.

Det visade sig att introducera trafik bidrog till avsev¨ art minskad traf- fiktr¨ angsel och ¨ okade produktionen, men p˚ a bekostnaden av en h¨ ogre bat- teri˚ atg˚ ang. Trafikkostnadens p˚ averkan var som tydligast n¨ ar antalet verk- samma dumprar var h¨ ogre ¨ an 10. Men n¨ ar trafikkostnaden viktades f¨ or h¨ ogt, minskade produktionen ist¨ allet. Tidskomplexiteten hos algoritmen

¨ ar O(n ² ) vilket ¨ ar acceptabelt d˚ a m¨ angden indata n ¨ ar liten.

Acknowledgements

We would like to express our deepest gratitude to Lars-Olof Kihlstr¨ om, our supervisor at Syntell AB, for providing us with this thesis and always being available and eager to help whenever we needed it.

Per Enqvist, our supervisor at KTH, who in spite of being extraordin- arily busy, taking the time to discuss strategies and calm us down when we wavered.

Lastly, a special thanks Fabrizio Pugnetti, Senior Expert at PTC, for

giving us great advice regarding the modelling program and providing us

with software updates.

CONTENTS

Contents

1 Introduction 1

1.1 Objective . . . . 1

1.2 The electric site project . . . . 2

1.3 Systems Modelling Language . . . . 3

2 Theory 5 2.1 Dijkstra’s graph search algorithm . . . . 5

2.2 Big-O notation . . . . 6

3 Method 8 3.1 Disclaimer: Model parameters . . . . 8

3.2 Modelling software . . . . 8

3.3 Creating the quarry geography . . . . 8

3.4 Routing algorithm design . . . . 11

3.4.1 Preparing the site configuration for computational use . . 11

3.4.2 Decision algorithm for Transporter requests . . . . 12

3.4.3 Incorporating traffic into Dijkstra’s routing . . . . 13

3.4.4 Expected traffic and the traffic penalty . . . . 15

4 The Simulation Model 17 4.1 Assumption and simplifications . . . . 17

4.2 The Site . . . . 19

4.3 Control Tower . . . . 20

4.4 Roads . . . . 22

4.5 Transporters . . . . 23

4.6 Source . . . . 30

4.7 Facility . . . . 30

4.8 Logistical Support . . . . 30

4.9 Crossings . . . . 31

4.10 Material Processor . . . . 32

4.11 Loader . . . . 32

4.12 Charging . . . . 33

4.13 Excavator . . . . 34

5 Results 35 6 Discussion 42 6.1 Time complexity of the routing algorithm . . . . 42

6.2 Limitations of the routing algorithm . . . . 43

6.3 Simulation results . . . . 43

6.4 Model reliability . . . . 45

7 Conclusion 46 7.1 Future work . . . . 46

8 References 48

Appendices 49

CONTENTS

A Routing Function 49

B Drive Function 54

C Traffic Intensity graphs 56

1 INTRODUCTION 1

1 Introduction

The operating vehicles used in modern quarries are manually controlled ma- chines powered by fossil fuels. Routine routes being driven daily, with standard tasks such as loading and unloading of material performed diligently without much variance in the work duties [1]. Thus, making it an opportune scenario for a shift to an automated control. At the same time, the carbon footprint of the quarry can be reduced by building the new operation upon a foundation which utilizes clean electricity as its main power source. Some essential machines that will be transformed are for example the excavator, material processor, wheel loader and transporter. However, this report will only focus extensively on the transporters.

To operate quarry transporters the driver must have gone through training and obtain a license. Great knowledge about the vehicle is needed to operate these machines to their utmost efficiency, altogether this becomes a large cost for a company. On top of this, the drivers will most likely not drive in ways that will prolong the lifespan of their vehicle, causing faster deterioration.

By using automated transporters, this can be completely avoided. With a high level of autonomy the transporters would therefore only behave as it has been told, in the utmost optimal way. There is extensive research being conduc- ted in the field of autonomous vehicles for almost all industries. The benefits are many, some already mentioned. However, by transforming into an autonom- ous site comes with many challenges. The obstacle this project will tackle, is the design of a routing scheduling system for the automated transporters in a quarry environment based on logical architecture.

1.1 Objective

The objective of this thesis is divided into two parts. The first part is to improve an extensive logical architecture of a special quarry site and prepare the model for simulation and analysis. The quarry being special in that the operated vehicles will be fully automated and electric.

The second part is to create the actual simulation. The simulation is in- tended to reflect the capabilities of the electric site. It will contain a routing algorithm to guide the autonomous vehicles based on a given input. The ob- jective function is to maximize the production per time unit while minimizing the traffic congestion.

It will also be possible to induce vehicle errors in the simulation to examine the robustness of the system. This will help the decision makers to catch the problem early and draft preventative protocol for critical scenarios. Which can in the future lead to a foundation for best practice in certain scenarios.

The simulation results will later be used to evaluate the efficiency and feas-

ibility of using the new prototypes in a quarry site. Since it is based of a logical

architecture, it can help spot deficiencies in the design at an early stage to

avoid costly mistakes down the line. This shortens the development phase of

prototyping a quarry and result in greatly reduced lead time.

1 INTRODUCTION 2

1.2 The electric site project

With the rise of fuel prices the incentive to electrify the quarries is more inter- esting than ever. The other incentive is to reduce the carbon footprint of such sites. As of today, construction vehicles are not regulated by the same emis- sion standards that commercial vehicles have to abide to. Electrifying a large quarry will be a paradigm shift where the current infrastructure will experience a major overhaul as many pivotal components are in the center of change. The transformation is estimated to reduce the carbon emission of parts of the quarry by up to 95% and the operating cost by 25% [1].

Converting the current machinery set to perform with an alternate power source will present its own challenges. Firstly, stationary units will require protracted cables connected to an electric grid. An example of how the cables are intended to be connected to the electrical grid can be seen in Figure 1.1.

The material processor is a machine where the cables need a transformer which converts the 10 kV available in the grid to the 400 V needed by the processor.

The stationary unit must however also be somewhat mobile and move along the crush site as the quarry is gradually reduced [1]. Another stationary unit is the hybrid excavator EX1. This is a modified unit based on the old EC750 also connected to the outer electric grid.

Figure 1.1: Electric site envisioned by Volvo CE, from [2].

The mobile units will consist of the hybrid wheel loader LX1 with a 3,6 litre diesel engine and the HX2 load carrier in Figure 1.2.

The HX2 is the transporter and will be traversing all over the work site,

moving from the material processor to the facility storage area. It is fully

autonomous with the driver’s compartment completely removed and is also fully

electrically driven with a 18 kWh lithium-ion battery [3]. The design of the

load carrying transporter, see Figure 1.2, allows them to form a continuous line

beneath the processor for loading. Thus eliminating the need for an additional

loader next to the processor.

1 INTRODUCTION 3

Figure 1.2: Fully autonomous load carrier designed by Volvo CE, from [2].

A never-before-seen construct on quarry sites is the need of a charging station for the HX2 transporters. Since the battery capacity equipped is relatively small, the transporters will continuously visit the charging station every time it leaves the crusher for a fast charge using a pantograph [1]. The intent is to keep the battery level high at all times even though the battery is far from being depleted after only one lap. However, in the simulation of the model in this project another approach was used. In this approach, the transporter routing follow a decision logic based on the transporters current location and battery level. By using this decision logic, it is believed that a more optimal route planning and production could be achieved.

Since the new transporters have lower load capacity than the fossil fueled haulers, there will have to be a fleet of these transporters in order to meet the same demand in production. This will strain the road capacity and run the risk of overcrowding bottle necks of the area, such as the charging-, loading- and unloading stations. The model must therefore be able to accommodate the new design parameters in order to achieve a sustainable and high performing site.

1.3 Systems Modelling Language

The logical model of the electric site, from which this project is derived from, was grounded in the Systems Modelling Language (SysML). It is an extension of Unified Modeling Language (UML) which was a standard mainly for the software engineering domain, whereas SysML was developed specifically for the systems engineering domain [4].

Furthermore, the model that has been simulated has made use of an archi- tecture framework derived from SysML. The framework is UAF: Unified Archi- tecture Framework that has been defined by the Object Management Group as a means of expressing concepts within an enterprise and therefore covers stra- tegic and operational considerations, services, resources, personnel, projects, requirements, security as well as standards use.

In the same fashion as SysML is based on UML concepts by means of ste-

reotypes, and a few additions, UAF is based completely on SysML by extending

1 INTRODUCTION 4

its elements. The framework is the result of several years of work by various agencies such as the US DoD and its framework DoDAF, the UK MOD and its framework MODAF as well as NATO and its framework NAF to name a few [5].

The model that has been simulated is based on concepts from UAF solely from the Operational area.

SysML is used for model based systems engineering in order to support large systems development whether it may be aerospace application or down-to-earth industries [4]. It is a richly expressive graphical modeling language with its own modelling standard to be followed, it is also able to clearly communicate a systems design structure, behaviour and all its requirements. Therefore, it is a great medium to describe large systems of systems to anyone who understands the modelling language, but also for collaboration purposes due to the model elements unambiguous interpretation [4].

SysML models has long been used for its great communication proficiency as a logical architecture blueprint. However, these models are often rigid and hard to extract any kinds of analytical data since the intent of the model design work was not to create an interactive user model. A large part of the focus for this project has henceforth surrounded the development of an executable SysML model a simulation environment and analyze the capabilities of such models for future potential. The software used to create the model will be mentioned in

§3.2.

2 THEORY 5

2 Theory

The geographical quarry location that has been modelled in this project is not based on an actual site. It is rather based on aerial images taken of many different quarry sites. Depicted in Figure 2.1 is the generalized visualization of a quarry site created in Matlab.

The simulation model has been designed with the intent to be flexible and able to be molded after any type of quarry location, as the data configuration are loaded from an external file.

Figure 2.1: Map of a generic Quarry site. Roads {A-L}, narrow roads {N1-N11}

and junctions {1-9}.

2.1 Dijkstra’s graph search algorithm

Dijkstra’s algorithm is a greedy algorithm which finds the shortest paths between

all pairs of vertices in a network. This means the algorithm lacks a direction in

its exploratory search for the final destination by comparing the distance to all

possible vertices until it reaches the source [6]. There are more direct algorithms

with a targeted approach, such as the A* algorithm which is an extension of

Dijkstra’s, which are able to find the same shortest path in a complex network

in less time. The difference between them being that the A* algorithm tracks

the length of the tree of paths the algorithm has visited, and uses a heuristic to

guide the search toward the target and terminates when an extension branches

to the destination vertex. Clearly an advantage in motion planning for autonom-

2 THEORY 6

ous vehicles. But due to Dijkstra’s simplistic nature and the small input size needed for the problem at hand, it becomes an ideal algorithm to implement in our modelling software, PTC Integrity Modeler.

Algorithm 2.1: Pseudocode for Dijkstra’s algorithm [7]

1 Function dijkstras()

2 dist[s] ← 0

3 forall v ∈ V − {s} do

4 dist[v] ← ∞

5 S ← ∅

6 Q ← V

7 while Q 6= ∅ do

8 u ← mindist(Q,dist)

9 S ← S ∪ {u}

10 forall v ∈ neighbor[u] do

11 if dist[v] > dist[u] + w(u, v) then

12 d[v] ← d[u] + w(u, v)

13 return dist

The algorithm 2.1 is initiated by defining undirected vertices and edges with nonnegative weights. The distance to the source vertex is set to zero and all others to infinity. The visited set of vertices S is initially empty and the set containing all the vertices of the network V is stored in Q, the set of vertices that are to be visited.

Then the algorithm will check for the vertex with the least distance u and add it to the visited set. If the total distance of the shortest path v found is greater than the newly found shortest path, then v will be set as the new path.

2.2 Big-O notation

The Big-O notation, or O-notation, is used to provide an asymptotic upper bound of a function f (n) and also reflect its growth rate. The O-notation of a function f (n), or by denoting O(f (n)) is then

O(f (n)) = {g(n) : there exist positive constants c and n 0 such that 0 ≤ f (n) ≤ cg(n), ∀n ≥ n 0 }

where the upper limit of the O-notation for a given function is up to a certain

constant c for large values of n. An example of this asymptotic upper bound

can be seen in Figure 2.2.

2 THEORY 7

Figure 2.2: For large values of n, the given function f will have a upper asymp- totic bound cg(n) for a positive constant c. [8]

The more formal definition can be formulated as: Let f and g be real valued functions defined on a unbounded subset in R ⁺ where g is strictly positive and n large, then

f (n) = O(g(n)), when n → ∞

Using the O-notation for algorithm analysis, by estimating the upper bound

for the worst-case situation one has also estimated a bound for the running time

of the algorithm. This gives intuitive information regarding the performance of

the algorithm when the input n starts to grow.

3 METHOD 8

3 Method

Various software and mathematical optimization methods was employed through- out the project. Here we will present our own implementation of these.

3.1 Disclaimer: Model parameters

Before introducing the modeling software and how the model was built, a dis- claimer regarding the model and electric site parameters has to be made. Most of the parameters were based on carefully crafted engineering guesses due to the confidentiality surrounding the Electric Site Project. However, the consequen- tial effect on the model reliability in this thesis is not of significance. This model was created with the intention to be flexible, therefore the parameters was meant to be exchangeable from the beginning.

3.2 Modelling software

The software used to model the electrical quarry site and the logical behaviour of all its elements was PTC Integrity Modeler. It is a graphical systems modelling software used in the design process of complex systems as a communication tool for representing the stakeholders requests and ideas and also as an effort to speed up the development process. The standard used in the model is UAF, an extension of the Systems Modelling Language. The software was provided for us by Syntell AB and PTC.

3.3 Creating the quarry geography

The first step in creating an extensive map of the site was to discretize the area topography using 3d points in Matlab. This became the plane of which the transporters would travel on and can be seen in Figure 3.1.

0 0.2 0.4 0.6 0.8

0 1 1.2 1.4 1.6

2 1.8

4

10 6

8

8 6

4

10 2

0

Figure 3.1: Fitted polynomial surface

3 METHOD 9

Then, by discretizing the x- and y-coordinates of the roads, and using the surface polynomial of the plane as the z-coordinate, a coherent discrete road system was complete, as seen in Figure 3.2.

1 2 3 4 5 6 7 8 9 10 11

1 2 3 4 5 6 7 8 9 10 11

S

F

CH P CT

Figure 3.2: The coherent site map of the discretized road data, seen from the simulation plane.

Combining Figure 3.1 and Figure 3.2 was then the final product seen in

Figure 3.3 where the roads have been made continuous by adapting polynomial

functions to fit the discrete roads. Figure 3.3 is the representation of what

the control tower would see on their control panel interface. A more in-depth

description of its functionality is detailed in §4.3.

3 METHOD 10

Source

Facility

Charging Parking Control Tower

1 2 3 4 5 6 7 8 9 10 11

1 2 3 4 5 6 7 8 9 10 11

Figure 3.3: The final site map with continuous roads, topography and names of the points of interest, seen from the simulation plane.

In order to have a reference in the simulation for how far along a road a specific transporter has travelled, a local parameter s j was introduced for each road segment. Each road segment j has its own maximum s _max,j and the parameter is also used for safe distance keeping between transporters.

The Cartesian coordinates were then created as functions of this local para- meter as x(s), y(s) and z(s). But the z-coordinates are less relevant, in the simulation it is instead the grade of the road that is of interest, referring to the change in z(s) which is ^dz(s) _ds .

Using the grade of each road segment, it was then possible to account for the changes in energy consumption when travelling up- or downhill. Using Equation 3.1 the battery level was updated constantly for each simulation time step with the consumption rate directly linked to the speed of the transporter.

BatteryLevel = BatteryLevel − (1 + grade · Heading) · CurrentSpeed (3.1) Moreover, depending on the Heading ∈ {−1, 1}, the grade of the road will either result in additional consumption or regenerative breaking yielding an increase in the battery. A drawback of Equation 3.1 is when a transporter is in standstill the battery consumption is zero. In addition, the speed of a transporter is also affected by the road grade. This relation is given by

CurrentSpeed = CurrentSpeed · (1 − grade · Heading) (3.2) where the transporter will travel faster downhill and slower uphill.

Both Equation 3.1 and Equation 3.2 are approximations of the battery con-

sumption and speed as the real dynamics and parameters have not been avail-

able.

3 METHOD 11

3.4 Routing algorithm design

An integral part of the simulated model is the routing design for the transport- ers. To maximize production, reduce queue size and avoid congestion at vertices etc., the automated transporters will need some form of optimized routing dir- ective.

In Figure 3.4 the overall structure of the routing algorithm for the trans- porters can be seen. Later on, in §3.4.1-§3.4.4 a comprehensive description of the important blocks are presented.

The algorithm is initiated by inputting the site configuration to produce a vertex network, consisting of intersections and points of interest in the site.

Each edge will be assigned an edge cost based on the length of the edge, s _max , not the euclidean distance between the vertices.

The vertex network and the corresponding edge cost are then submitted into the Modified Dijkstra’s block to calculate the cheapest path, including the arrival time and weighted traffic, upon receiving the parameter input from the Transporter Requests block.

Figure 3.4: Algorithm structure

After a route has been produced, the vertices of the planned path will be given a traffic cost at the corresponding arrival time in the expected traffic matrix, E T . This will represent the transporters planned presence at the vertex, thus representing the expected traffic at that vertex at the specified time. This behavior is described in more detail in §3.4.4. When routing the upcoming transporters, this added traffic cost must therefore be accounted for.

3.4.1 Preparing the site configuration for computational use

Since the actual quarry site configuration data was not available, the fictitious site was purely graphically created seen previously in Figure 3.3. As such, a graph search algorithm was favorable. With the low amounts of intersections present in the quarry site, a straight forward road network could be constructed.

Intersections and points of interest being vertices and the road lengths as the

edge cost, with the edge cost also taking into account the inclination of the area

3 METHOD 12

in the sense that up and downhill are treated the same; as a longer distance needed to travel.

In Figure 3.5 a simplified version of the map, used for the visual represent- ation of the optimal paths calculated, can be seen.

In this case, road obstacles will only occur due to a malfunctioning trans- porter with a major error, thereby blocking of an entire edge. The blocked edge is then removed from the vertex network while the remaining transporters are rerouted without using the blocked road.

0 1 2 3 4 5 6 7 8 9 10

0 1 2 3 4 5 6 7 8 9 10

1

2

3

4 5

6

7

8 9

10 12 11

13 14

Figure 3.5: Vertex Grid

When the Major error has been repaired the road is no longer blocked and is thus added to the vertex network again. This allows the routing to utilize the road segment for future scheduling.

3.4.2 Decision algorithm for Transporter requests

The real Electrical site intends to fast charge the transporter after each time they have dumped material at the Facility. In this thesis the transporters will be routed to the different locations according to a decision algorithm that takes the battery level into account.

The transporters are routed from one point of interest, for example Source or Facility to another. When the Transporter has arrived and finished its task, a new path will be requested based on the current location, state of the transporter and battery level of the fleet.

The decision logic is visualized in Figure 3.6. The set K contains the 40%

of the transporters with the lowest battery level. By comparing the battery

3 METHOD 13

level with the rest of the fleet, the transporter can be routed to charging before it personally requires more battery. This allows the fleet to maintain a higher average battery level while distributing the arrivals to the charging area more evenly.

Figure 3.6: Algorithm structure

The Transporter Request block is activated only if the status of the trans- porter is ”Operational”. If a minor error has occurred the transporter is routed straight to the logistics team located at Control Tower by a greedy Dijkstra’s function not considering the current traffic. At site shutdown the transporters are routed to the parking area using the same function. In both cases a loaded transporter will first be routed to the facility for unloading before being routed to the final destination. The transporters will also be routed trough Charging if the battery level is below a specified value at site shutdown.

Once the destination and status of the transporter has been determined the simulation sends the transporter request to the modified Dijkstra’s algorithm.

3.4.3 Incorporating traffic into Dijkstra’s routing

In order to avoid overloading certain road segments and points of interests, a [m × n] expected traffic matrix, E _T , was created where n are the vertices of the network and m the time span for which the simulation is to be run. Whenever a transporter has been routed past a vertex, a traffic cost would be added to that vertex and distributed around the time of arrival. The modified Dijkstra’s Algorithm 3.1 must then take this updated expected traffic matrix into account when calculating the routing for the next transporter in line.

If multiple transporters visit the same vertex around the same time, the

corresponding cost will significantly increase. Given a high enough weight on

the traffic cost, the transporters will be routed in a scattered manner in order

to avoid the most trafficked time intervals. This will result in a more evenly

3 METHOD 14

distributed flow of transporters on the site with minimal forming of queues. The matrices and vectors needed in Algorithm 3.1 are the following:

• Q is the set containing the unvisited vertices

• jT and iT , the previous and current traffic cost vector

• jA and iA, the previous and current arrival time vector

• C, the edge cost matrix converted to time based on the expected speed

• jCost and iCost, the previous and current modified output cost vector

• E T , the expected traffic matrix

• w, the weight in the cost function weighing traffic against arrival time Algorithm 3.1: Pseudocode for modified Dijkstra’s

1 Function mod dijkstra’s()

2 n := init

3 jT (init) := 0

4 jA(init) := Initial Time

5 jCost(init) := 0

6 while Q 6= ∅ do

7 min := ∞

8 Q \ n

9 for i = 1 To M do

10 if V(n, i) = 1 then

11 iA(i) = jA(n) + C(n, i)

12 iT (i) = jT (n) + E T (n, jA(n))

13 iCost(i) = iA(i) + w · iT (i)

14 if iCost(i) < jCost(i) then

15 jT (i) = iT (i)

16 jCost(i) = iCost(i)

17 jA(i) = iA(i)

18 for i = 1 to M do

19 if i ∈ Q And jCost(i) < min then

20 min := jCost(i)

21 n := i

22 return ”New path”

23 for i = 1 to path.Length do

24 E T Add(path(i), jA(path(i)))

The modified algorithm 3.1 is based on the main algorithm 2.1. Although

algorithm 3.1 utilize a combined cost function jCost. jCost consist of the arrival

time and accumulated traffic to each node and will thus be dynamic. This since

the expected traffic matrix, E T , is updated after each routing in the function

E T ADD. More on this behavior is described in §3.4.4.

3 METHOD 15

• Firstly, the initial values for the traffic cost vector jT , the arrival time vector jA and the modified edge cost vector jCost are set to zero. For each vertex arrival, the current vertex n will be set as the initial position before the next departure.

• Then, for the M edges in the network and the connected vertices in the vertex matrix V, the arrival time to the current vertex iA, will be the sum of the previous arrival time jA and the edge cost C.

• The current traffic cost iT is calculated by adding the previous traffic cost jT with the expected traffic E T of the current vertex and its arrival time.

• The current modified output cost vector iCost becomes the sum of the current arrival time vector iA and the current weighted traffic cost vector iT . If the current edge cost vector iCost is less than the previous one, then all the new values will be stored and the algorithm will return the chosen path.

• Also, during this time if the unvisited vertices in Q has a lower cost jCost(i) then the current lowest vertex cost min, the lowest vertex cost min and the current vertex n will be updated accordingly before going to the top of the while loop again.

• Lastly, the expected traffic matrix, E T , will be updated when a optimal path has been derived.

3.4.4 Expected traffic and the traffic penalty

When a transporters schedule has been computed using the modified Dijkstra’s algorithm the presence of the transporter in the expected traffic matrix, E T , must be added. The expected traffic matrix serves as a prediction of the traffic at each time interval at each vertex. Thus allowing the next transporter scheduling to take the planned traffic into account.

The presence of the transporter is added around the expected arrival time at the vertex v, t ^v _a . As seen in Figure 3.7 a 25 seconds interval is added before the expected arrival as to allow some uncertainty of the arrival time. After departure there is a similar 25 second interval. They also serve as a means to include arriving and departing traffic in the path planning.

Figure 3.7: Algorithm structure

3 METHOD 16

The expected time at the vertex, E[T _v ], is approximated using the expected time needed for the task at the vertex, t _e , and the already expected traffic at the vertex. At a crossing t e is approximated to 2 seconds. Whilst at the facility t e is 30 seconds.

Algorithm 3.2: Approximation of Expected time at vertex

1 Function Expected Time Span()

2 if E T (v, t ^v _a ) > Servers(v) then

3 q = E T (v, t ^v _a ) − Servers(v) + Servers(v)/2

4 else

5 q = 0

6 E[T v ] = t e (1 + q/Servers(v))

Where q is the expected queue to the server and Servers(v) is the amount

of servers for the queueing system.

4 THE SIMULATION MODEL 17

4 The Simulation Model

As with any simulation model, accurate data is absolutely necessary if the end result is intended to reflect reality. But accurate data is not always attainable.

For some parts of this project, the model has been built upon data based on educated engineering estimates and rule-of-thumb methodology.

In Modeler, the essential components of the electric site are modelled as sep- arate blocks. These blocks then contain state machines, signals and operations to express systems information and its behavior.

The blocks are then added onto a main block, The Site, as block properties where the interactive behavior between blocks can be defined. The main block is then added on to a simulation platform.

The state machine, an unambiguous specification of behavior, is also what drives the simulation behavior in the background. It is a dynamic view of the internal system and focuses on how the states in an internal system changes in response to event occurrences. The simulation contains numerous state ma- chines, some quite simplistic while others can more complex. Therefore, in the upcoming chapters only the most essential state machines will be described in detail.

The PTC model is made executable by auto-generation into Visual Basic code with all the predefined model behavior. To visualize the desired informa- tion, Visual Basic Forms was created and linked with its intended block.

4.1 Assumption and simplifications

For the simulated model some assumptions had to be made. The core dynam-

ics of the system was preserved while some systems behaviour superfluous to

the thesis objective were disregarded. This way, the analysis on the model

performance is in a more distilled form. In Table 4.1 are the stated model

simplifications.

4 THE SIMULATION MODEL 18

Table 4.1: A summary of the model simplifications and assumptions Property Simplification/Assumption

Block dynamics - The material pile at the source area is assumed to be infinite

- The location for discarded material has been disregarded

- The electrical grid which the real site must be connected to has been disregarded

- The material processor and wheel loader need no charging

- The weather condition at the quarry is invariable

- The Transporters driving does not include acceleration or braking.

Parameters - Loading material at the material processor and wheel loader takes 60 s and 90 s respectively - Minor and major repairs takes 30 min and 120

min respectively

- Unloading at the facility area takes 30 s - Expected time needed for completing a

crossing is 2 seconds.

- Expected time needed for unloading is 30 seconds.

- Expected time needed for loading is 60 seconds.

- Expected time needed for charging is at least 80 seconds seconds.

- Carrying load reduces a transporters speed by 50% and increases battery drainage by 30%.

- A minor error reduces a transporters speed by 70 %.

- The transporters normal speed is 30 km/h.

- The charging rate is 0.3 %/second.

- The maximum grade of the roads is 0.46.

- For safe distance keeping the headway is 30 m.

- N umberOf Servers at the source was set to

1.2, at the facility as 1, at all crossings as 1

and at charging as 2.

4 THE SIMULATION MODEL 19

4.2 The Site

The Site is the proprietor of all the model components where the elements of the electric site has been added as block properties. A diagram of all the connected blocks can be seen in Figure 4.1. The signals flowing through the connectors act as triggers either for state machine events or to initiate operations.

The elements are further categorized into two subgroups, the Known Re- sources and the Operation Performers. The difference is that the Opera- tional Performers are entities with behavior and dynamics objected to outer influence. Both groups have their own associated blocks. Table 4.1 is the col- lection of blocks which builds The Site.

Table 4.2: A simplistic model tree and its comprised blocks

Element Block

Known Resources - Roads

- Crossings - Facility - Source Operational Performers - Charger

- Loader

- Logistics Support - Material Processor - Supervision and Control - Transporter

- Excavator ¹

After the blocks have been added, the block properties can be set as user defined multiplicities (represented by the numbers in the upper left corner of the blocks in Figure 4.1) allowing them to be independently manipulatable.

There are multiple purposes with The Site. It handles the initialization by loading the site configuration data and defines all the parameters of the electric site quarry, but any configuration can be applied. The road network and all the intersections are created along with the map for the control panel.

The Site also creates the initial values needed for the routing which incor- porates the cost matrix, the node matrix and the road name of the connected vertices.

When all site configuration has been set, The Site sets all relevant block status to ”Active”. This leads to the activation of the corresponding state machine.

1 The desired behavior has not yet, and will not be implemented in this thesis. It is a

subject for future work.

4 THE SIMULATION MODEL 20

Figure 4.1: Diagram of the The Site in PTC integrity modeler showing the connections of all its associated blocks.

The error inducing operations are also behaviors handled by The Site. This is a user interactive functionality and will only trigger if the ”Major” or ”Minor”

buttons has been pressed on the control panel interface seen in Figure 4.2. If a major error has been induced a minor error can not be applied. Whilst a minor error can always be aggravated to a major error.

The Site also handles the simulation time. The simulation speed can be manipulated using a scroll bar in the user interface. When this is done the simulation factor used in scaling all time steps in the simulation is updated.

The last important behavior The Site handles is the site shutdown opera- tion. When this order is sent by clicking the button in Figure 4.2, all transporters will be rerouted to the parking area by the Control Tower. The exception is if the transporters are loaded with goods or have a low battery level. Then they will first unload the material at the facility or pass by the charging area respectively, before heading to the parking area.

4.3 Control Tower

The interface with the user contains a map of the site including roads, topo-

graphy and locations of interest such as; Facility, Parking, Charging Area and

a Control Tower with logistics and technicians. The interface also shows the

simulation local time and the production (material unloaded at the facility) in

a graph and seven segment display. To keep the user informed of the individual

transporters battery level, current action and status are list displays. For the

availability of the charging spots is a separate display called ”Chrgr ID”.

4 THE SIMULATION MODEL 21

The simulation speed can be manipulated using a numeric slider. Errors on individual transporters can be simulated using the Error Inducer menu. The er- rors are of type ”Major” or ”Minor”. A Major error implies that the transporter has shut down right were it is and needs to be attended to by a technician or be removed, and cannot be used until it has been repaired. A minor error implies a reduction in performance and speed, but the transporter can on its own drive to the technicians at a the logistic support center located on the same area as the Control Tower.

Figure 4.2: User interface in Visual Studio

The Control Tower computes an order list using a routing function. These orders are sent out to the dumpers when the distance to the end of the current location is less than a specified value. When the transporter receives the new order, it will request access to the next location and before entering, finish its current activity.

When a transporter has reached its assigned destination the Control Tower evaluates the battery level, load and location of the transporter as to assign a new destination and compute the corresponding order list. This is is described in more detail in §3.4.2-§3.4.3.

The positions of the dumpers are sent to a site map as to visualize the oper-

ation of the site. The Control Tower also handles re-routing when minor error

occurs, at site shut down or when roads have been blocked. When re-routing is

required, as in the case of minor error, site shut down or low battery level, the

Control Tower initiates a re-route operation which uses Dijkstra’s algorithm. In

this case the re-routing is done based on the individual transporters needs to

make it to the new destination as fast as possible, without consideration to the

remaining transporters operation on the site. The Control Tower also handles

access requests to itself and the parking area.

4 THE SIMULATION MODEL 22

4.4 Roads

A road segment handles access by communicating the request to the connec- ted crossing and forwarding the granted access to the transporter, along with required road data. The information the road send upon the granted access include the grade function, length of the road and the heading of the trans- porter. The heading is either negative or positive and affects the transporters positioning along the road.

When a transporter enters the road, it is registered on the respective road lane going in opposite directions. The registration on the road enters the trans- porters in a vector where the transporters are order based on the order they have on the road. That is, the first transporter on the road has the lowest index in the road vector. In Figure 4.3 can an example of a situation on a road be seen.

Figure 4.3: Example of registration on road The resulting road vectors from Figure 4.3 would become:

M achinesOnRoad _A − = [4, 6, 0, . . . , 0]

M achinesOnRoad _A + = [5, 7, 1, 0, . . . , 0]

This allows the road block to continually compute the distance to the preceding transporter, which in turn is used to regulate individual speed limits for safe distance keeping.

After a safe distance along the road, a signal is sent to the connected crossing that the transporter has completed the crossing, allowing the next transporter in line to precede.

Along the road the s-position of the transporter is continually updated and converted to x and y-coordinates that are sent to the Control Tower as to update the position of the transporter on the map.

If a transporter has a major error, the Road block instigates a blockage.

This behavior includes updating the Control Tower, that in turn removes the blocked road from future scheduling and redirects transporters with schedules containing the blocked road segment. It also includes turning around transport- ers already on the blocked. When the major error has been repaired the road segment will be operational again and the Control Tower will be notified.

When a transporter leaves the road, it sends a signal which activates the

action to remove it from the road lane.

4 THE SIMULATION MODEL 23

At the start of the project the intention was to include the property of narrow road which only allow traffic in one direction at a time. In the current model, this property has not been implemented and will be included in the chapter of future work.

4.5 Transporters

The Transporter block has the most complex state machine of all blocks in the model. A complete view of the Transporter state machine is shown in Figure 4.4.

The main state is the Active state which is responsible for handling the majority of signals sent to the Transporter block. Depending on the received signal, an operation in the Transporter state machine will be triggered accord- ingly, activating corresponding behaviors. These signals thus define the rule of engagement between the transporter and the possible scenarios it can come in contact with.

The sequential states that describes the at-an-area interactions all have a common property, which is the pass through operation. If for whatever reason a transporter only want to use that area as a junction and not access its inherent abilities, it will be allowed to pass through.

In the Active state the transporter will enter a sequential state representing

the next location through the atomic state Check Data update. After exiting the

sequential state by completing the corresponding task and receiving a granted

access to the next location, it will once again loop through the atomic state

Check Data update. This structure insures that the transporter has been given

access, has updated local information and has completed its previous task before

continuing to the next location.

4 THE SIMULATION MODEL 24

Figure 4.4: Transporter State Machine

4 THE SIMULATION MODEL 25

The OnTheRoad sequential state in Figure 4.5 simulates the behavior when the transporter is driving on a road. The most significant functions of this sequential state are the Drive function in Appendix B and the UpdateRoadPos- ition function which constantly updates the s-position.

The s-position is then used for the visualization of the transporter movement on the on the interface Figure 4.2, but it is also used for safe distance hand- ling. This includes the safety to the transporter in front and also to slow the transporter down when s → s max and access to the next location has not been granted. This scenario means an intersection is approaching and the transporter is not yet cleared to approach.

Figure 4.5: The sequential state OnTheRoad contains the transporter behavior

when it is driving on any road.

4 THE SIMULATION MODEL 26

AtChargingArea in Figure 4.6 simulates the behavior at the charging area.

A transporter in the simulation is generally considered to have arrived at an area whenever the distance left to s max is less than 1 meter.

There are a total of two charging spots, so when a transporter arrives the Charging block will move the transporter into the queue and if the queue is empty it will be moved straight to one of the free charging spots. The number of charging spots can be specified up to a maximum of 8.

There are two different charging strategies that can be incorporated by this sequential state. One is to charge a transporter until it has reached a specified % of battery level. The other is to only charge for a set time, not taking the current battery load into consideration. The current sequential state incorporates the merge of the two strategies where the transporter charge for at least 80 seconds but can increase this time as needed to reach a battery level of 80 %. Upon completion of charging, the sequential state simulates the process of driving out of the area.

Figure 4.6: The sequential state AtChargingArea details the behavior at the

charging area.

4 THE SIMULATION MODEL 27

AtSourceArea in Figure 4.7 handles the source area arrivals. Depending on the received signal from the Source block, a transporter can be either directed to the Material Processor or the additional Loader for loading. When load- ing is complete the state also accounts for the time it takes to drive from the material pickup to the exit.

After a transporter has been loaded, the speed will be adjusted due to its changed load status to 50% · orginal speed. This speed will remain unchanged until it visits the sequential state AtFacilityArea for unloading.

Figure 4.7: The sequential state AtSourceArea details the behavior at the source

area.

4 THE SIMULATION MODEL 28

The AtFacilityArea sequential state is very similar to the AtSourceArea se- quential state. It can be seen in Figure 4.7. Basically, the operations are identical but instead of loading material it will unload. After unloading is com- plete the speed will be reset to the original speed.

Figure 4.8: The sequential state AtFacilityArea details the behavior at the fa- cility area.

The AtLogistics is entered when the transporter has been routed to the

logistics for repair after a minor error has occurred. Upon arrival it will be

placed in a queue and await repair until assigned to a logistics team. Once

repaired the transporter will receive new orders and join the operational fleet

once more.

4 THE SIMULATION MODEL 29

Figure 4.9: The ”AtLogistics” sequential state.

The last sequential state is AtParkingArea in Figure 4.10. This state is mainly used for the site shut down operation where every transporter must return to the parking area. When a transporter has arrived it will be ordered to its designated parking spot.

The state machine has been designed as to allow the transporter to leave the parking area when receiving a new order. Although in the current model, such a scenario will not occur.

Figure 4.10: State ”AtParkingArea”

4 THE SIMULATION MODEL 30

4.6 Source

The access in to the area is handled by the block itself and the connected crossings. The block then distributes the arrivals based on the queue size at the Material Processor and Loader. Both units will send a signal to the Source block requesting transporters when the queue size is too small, but the distribution process is designed to always prioritize the Material Processor over the Loader.

In the simulation model, there is considered to be an unlimited amount of material in the source pile. When either the Material Processor och the Loader has completed a load the Source block will update the material pile.

4.7 Facility

The Facility block is similar to to the Source block. It handles the access in to its own area, cooperating with the connected crossings, and the queue to the unloading space.

Upon arrival to the facility area the Facility block will send the approx- imated distance to the exit of the area as to allow the transporter to simulate driving out of there after unloading.

A completion signal from the transporter currently unloading will make the Facility block increase the production by the predefined 15 tonnes. It will also allow the next transporter in line to unload.

4.8 Logistical Support

The Logistical Support is the local logistics teams and is summoned when a transporter error has occurred. The teams are physically located at the same area as the Control Tower and the number of teams is a configuration parameter.

In the event of a minor error, the faulty transporter will be rerouted by the Control Tower to itself. The Logistical Support is activated by the signal OpTrnsArrvlAtLogistics and initiates diagnostics and repair. After a set minor error repair time, it will be released back into the work force. If the number of faulty transporters are larger than the number of logistics team they will be put in a queue.

If it is instead a major error, then the implication is that the magnitude of the error is so large the transporter no longer can move by itself. It will remain in place until a logistics team can arrive and remove it from the site.

This is simulated by the passage of the specified major error repair time and

is activated by the signal OpSupervisionErrorMessage. In the meantime, the

occupied road will be classified as completely blocked off.

4 THE SIMULATION MODEL 31

Figure 4.11

The upper concurrent state machine Handle Incoming Errors handles the arrival queue and assigns the transporter first in line to an available team.

The lower state machine Fix errors simulates the time required to repair the transporter.

4.9 Crossings

The Crossings were added to the simulation as to ensure that no two machines occupy the same crossing at the same time. This evolved to entrance handling of both areas and road segments. Each road segment or area which receives an access request from a transporter will send a request to the connected crossing.

The Crossing will handle each incoming crossing request according to first

come first serve. When a crossing is completed, the corresponding area or road

segment notifies the Crossing which in turn gives access to the next in line.

4 THE SIMULATION MODEL 32

4.10 Material Processor

When a transporter arrives at the source area, it will first and foremost be direc- ted to the Material Processor. The Material Processor used on the actual site is a mobile jaw crusher with a production capacity of 1000 tonnes/hour [9].

There is therefore a priority requirement where at least 2/3 of the arrivals must come and load here.

The queue for the transporters distributed here is handled internally by the Material processor block. Whenever the queue becomes less than 3 units short it will send a signal to the Source requesting more units. This will stop the diverting of transporters to the additional Loader giving the Material Processor priority.

When arriving to the queue the Material Processor will give the trans- porter the approximate distance to the exit of the area. This as to allow the transporter to simulate the drive to the exit.

The Material Processor change its position and will update the Control Tower of this change.

4.11 Loader

The Loader is the secondary loading unit at the source. Whenever the queue to the Material Processor is long enough, the Loader will take on 1/3 of the excess arrivals. When the queue is shorter then 2 transporters, the Loader will request more transporters.

When arriving to the Loader the transporter will receive the approximate distance to the area exit as to be able to simulate the drive out from the area.

The State machine for the Loader contains two primary concurrent states, see figure 4.12. The first one, Handle Queue, handles the queue and assigns the first in line to the loading position when no one is currently loading. The second, Handle Loading, handles the loading. In Loading, the loading behavior is simulated.

Two scoops are simulated using scaled time steps. One scoop contains 7

tonnes of material, since the transporter can carry 15 tonnes, two scoops were

deemed as an acceptable simplification.

4 THE SIMULATION MODEL 33

. Figure 4.12

4.12 Charging

The Charging block handles both access requests to the area, the queuing system to the charging stations and the assigning of charging station to the transporter first in line.

When the transporter sends the signal of arrival to the charging area the Charging block signals the connected crossing that the corresponding crossing is complete.

The transporter will charge until the battery level is at least 80 % and a minimum of 80 seconds before sending the charger the signal of completion.

This activates the action to assign the corresponding charging station to the next transporter waiting.

At arrival to the queue the Charging block will send the transporter the

distance to the exit of the area so the transporter can simulate driving out of

4 THE SIMULATION MODEL 34

the area.

4.13 Excavator

The excavators mission is to move material from the source pile and feed it to

the Material Processor. It is assumed that the Excavator can reach the Ma-

terial Processor by rotation without having to move its position. The approx-

imated rate the Excavator can feed the Material Processor is higher than

the rate the Material Processor can handle the incoming material. Therefor

the Excavator has not been modeled for this thesis as there was unexpected

delays in the modeling process.

5 RESULTS 35

5 Results

This electric site model has been created with the intent to be reusable. Nearly all parameters are interchangeable with configuration data of any ambiguous quarry location. On an automated site it is important to have an even allocation of transporters to avoid overloading certain vertices and minimize the downtime at the Material Processor. Especially at the three vertices Source, Facility and Charging since the tasks required to be performed there take a relatively long time and the servers are limited, which could result in long queues forming.

The routing algorithm takes this into account as will be seen in the following section results. The simulation time was 50-55 min and there were mainly two parameters being varied in the simulation:

1. The number of transporters T, to operate on the site 2. The weight w, on the traffic cost for arrivals on a vertex

In Figure 5.1 the expected traffic versus the actual traffic is plotted, for a scenario of 15 transporters and a traffic weight of 50. The blue line, representing the expected traffic predicts the red line almost perfectly for the facility area.

At the facility, the service rate and number of servers are constant. This leads to an accurate prediction. Whilst at the source area, the number of servers and service rate varies. This since the arriving transporters are distributed between the material processor and the loader depending on the number of transporters at the area. Thus an average number of servers of 1.2 was used giving an acceptable result.

At the charging area, there is a similar problematic behavior. The time

spent at the charging station is a function of the amount of battery left. This

results in a difficulty deriving the expected waiting time at arrival. The charging

times can in some cases be double that of the shortest, making it difficult to

approximate expected time at charging.

5 RESULTS 36

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 2 4

0 500 1000 1500 2000 2500 3000

0 5 10

Figure 5.1: Expected vs Actual Traffic

To improve the approximation of the time a transporter has to spend at the charging area, the average expected charging time needed for all transporters currently heading towards the charging station was used. This gave a better approximation then a set time value.

The routing was tested by routing the transporters according to an egotistic scheduling, that only takes into account the individual transporters need for charging, location and load. The egotistic scheduling has a 0 weight on the traffic cost, meaning it ignores the current and future traffic situation. It also does not check if it is part of the set K in Figure 3.6 when deciding on a destination.

In Figure 5.2 it is clearly visible that even at a low traffic weight, the traffic at the charging and source is more evenly distributed. While at the facility there is no obvious change. In Figure 5.4 it can be observed that the routing algorithm, used on 20 transporters, gives a distinct increase in production.

When increasing the weight of the traffic it can be observed that the traffic

peeks at the source and charging area are reduced but at a cost of decreased

production, see Figure 5.4, and a slight increase in traffic peeks at the facility.

5 RESULTS 37

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 5 10

0 500 1000 1500 2000 2500 3000

0 5 10

0 500 1000 1500 2000 2500 3000

0 5 10

0 500 1000 1500 2000 2500 3000

0 5

0 500 1000 1500 2000 2500 3000

0 5

0 500 1000 1500 2000 2500 3000

0 5

Figure 5.2: Traffic intensity for simulations using a weight of 0, 25 and 125 for

20 transporters.

5 RESULTS 38

When making the same analysis on simulations run using the same setup but with 5 transporters, seen in Figure 5.3, similar behaviors can be observed.

The traffic peeks are slightly lowered at the source and at the charging area.

Although in this case, so are the peeks at the facility. It is an overall small

improvement of the traffic intensity and when looking at the production in

Figure 5.4 there is a slight increase. When increasing the weight, the production

level remains largely unaffected.

5 RESULTS 39

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 10 20

0 500 1000 1500 2000 2500 3000

0 5 10

0 500 1000 1500 2000 2500 3000

0 5 10

0 500 1000 1500 2000 2500 3000

0 5 10

0 500 1000 1500 2000 2500 3000

0 5

0 500 1000 1500 2000 2500 3000

0 5

0 500 1000 1500 2000 2500 3000

0 5

Figure 5.3: Traffic intensity for simulations using a weight of 0, 25 and 125 for

5 transporters.

5 RESULTS 40

The final production level as a function of the traffic weight for a 50 minutes simulation can be seen in Figure 5.4. The weights on the traffic cost used in the simulation was w = {0, 25, 50, 75, 100, 125}. A higher weight means there is a prioritization to reduce the traffic congestion on the nodes. We can see that the results of a reduced congestion is the most distinct when there are at least 15 transporters operating. When a lower amount of transporters are operating the production is more or less the same.

0 20 40 60 80 100 120

200 300 400 500 600 700 800 900 1000 1100

Figure 5.4: The final production level in tonnes for T _i transporters as a function of the traffic weight where i ∈ [5, 10, 15, 20]

When comparing the production level between the different number of trans-

porters it is clearly visible that the increase in production decreases as the num-

ber of transporters increase. Meaning that that the production is not a linear

function of the number of transporters. This phenomena can be observed in

Figure 5.5. The observed trend is that as the number of transporters increases,

the (total amount of produced material)/(transporters) decreases. For a large

weight w = 125, the advantage of using the routing algorithm is completely

neglected with >10 transporters.

5 RESULTS 41

5 10 15 20

40 45 50 55 60 65 70

Figure 5.5: The production per transporter using a traffic weight of 0, 25 and

125. As the number of operating transporter increases, the total produced

material per transporter decreases.