5. Simulation Approach
5.2. Simulation Tool
15 ⁞ calculate fA, hA, oA and αt ≻Now check whether to change the ratio of the available fleet capacity, 16 ⁞ if αt > p7then with Equation (4.5), Equation (4.6), Equation (4.7), Equation (4.8) 17 ⁞ ⁞ ChangeRatio = true
18 ⁞ ⁞ ifoA > fAthen ≻Determine order type for which we require more capacity
19 ⁞ ⁞ ⁞ ReqOrderType = A 20 ⁞ ⁞ else ReqOrderType = B 21 ⁞ ⁞ end if
22 ⁞ else if IncreaseCapacity orDecreaseCapacitythen
23 ⁞ ⁞ ReqOrderType = order type with largest total order quantity ≻Based on customers served so far
24 ⁞ end if
25 ⁞ if IncreaseCapacity orDecreaseCapacityor ChangeRatiothen 26 ⁞ ⁞ ChangeComposition = true
27 ⁞ ⁞ RC.clear ≻Reset the list with rejected customers
28 ⁞ end if 29 end if
30 if ChangeCompositionthen ≻Now try changing the fleet composition
31 ⁞ define new composition based on IncreaseCapacity, DecreaseCapacity, ChangeRatio ≻Use Table 4.2
32 ⁞ if enough capacity available for unplanned orders then ≻Prevent high response time when we know
33 ⁞ ⁞ send JSON request to CVRS to solve VRP for new composition that new composition is not feasible 34 ⁞ ⁞ if no unplanned orders in response then
35 ⁞ ⁞ ⁞ convert CVRS response into current schedule ≻Accept changed fleet composition
36 ⁞ ⁞ ⁞ send JSON request to OTS with current schedule ≻Keep OTS up-to-date
37 ⁞ ⁞ end if 38 ⁞ end if 39 end if
40 set RejectCustomer = false ≻Finally, consider if customer should be rejected
41 set u = unattractiveness score for customer c ≻Further explanation of calculation in Section 5.3
42 if fleet capacity cannot be increased anymore and ≻Perform checks as described in Chapter 4
43 current average utilization > p and
44 Ft + p < current average utilization andu > p10then 45 ⁞ RejectCustomer = true
46 end if
47 if notRejectCustomerthen ≻If customer is accepted, offer available time windows
48 ⁞ send JSON request for available time windows to OTS ≻OTS runs cheapest insertion algorithm
49 ⁞ setAT = list of available time windows ≻Retrieved from OTS response
50 ⁞ set PL = sorted preference list of customer c 51 ⁞ if AT.count > 0 then
52 ⁞ ⁞ ifPL contains any time windows from ATthen ≻If not, customer did not select time
53 ⁞ ⁞ ⁞ customer c selects highest ranked time window from PL window, order is not confirmed
54 ⁞ ⁞ ⁞ insert customer c in cheapest way into schedule ≻Determined by OTS (cheapest insertion)
55 ⁞ ⁞ end if
56 ⁞ else reject customer c 57 ⁞ end if
58 else reject customer c 59 end if
All these algorithms together make sure that all inputs are converted to outputs, which we use to investigate whether the hypotheses as defined in Chapter 3 can be confirmed for our input scenarios.
5.2.
Simulation Tool
In this section we describe the simulation tool we developed in C# to run our simulation experiments. C# is an object-oriented programming language that fits all the needs for running the algorithms we presented in Section 5.1. We present the way in which our simulation tool communicates with ORTEC’s
software solutions in Section 5.2.1. Subsequently, we briefly describe the different application modes that we developed in the tool in Section 5.2.2.
5.2.1.Communication with OTS and CVRS
As we already mentioned in the algorithms in Section 5.1, the communication with the cloud interfaces ORTEC uses for OTS and CVRS goes by means of JSON requests. JSON is frequently used in cloud applications to exchange data between two interfaces. It is a lightweight format and therefore suitable for applications where response time is an issue. ORTEC has specified a standard format for communication with its cloud services, that contain all the entities that are required to be able to respond the cloud request. We implemented these formats in our simulation tool to automate the communication with OTS and CVRS. So, our tool converts all entities (customer, driver, vehicle, depot) to entities that are defined in OTS and CVRS. After obtaining a response from OTS or CVRS the tool converts this response to the corresponding entities in our simulation tool.
5.2.2.Application Modes
Figure 5.1 shows the start screen of the application we developed to run our simulations and introduces the four application modes: a scenario generator mode, a demo mode, a simulation mode and a solution visualizer mode. These application modes can be used for different purposes, as we explain for each application mode in the remainder of this section.
Figure 5.1. Screenshot of the start screen of the simulation tool
Figure 5.2 presents a visualization of the scenario generator mode of our simulation tool. This application mode can be used to construct input files for a scenario. We distinguish between two separate functions for this application mode: one to retrieve the coordinates for a set of given addresses and one to consolidate all inputs for a scenario from an Excel file into a JSON file that can be read by our simulation tool. To retrieve the coordinates linked to an address, the tool makes use of ORTEC’s Maps Service. Whenever an address is not recognized, our tool gives the user the option to manually provide the coordinates. When constructing an input file for a scenario, the application also uses ORTEC’s Maps Service, to retrieve the distance and driving time matrices. In case we already have the distance and driving time matrices
5.2. Simulation Tool
available as a JSON file, the tool offers the option to import this JSON file. This can save much time, because for some scenarios we may have millions of entries for the distance and driving time matrices.
Figure 5.2. Screenshot of the scenario generator mode
Map rights: ©2019 Microsoft Corporation, ©2019 NAVTEQ, ©2019 Image courtesy of NASA, plugin by GMap.NET Figure 5.3 shows a screenshot of the demo mode of our simulation tool. This mode, as the name indicates, is meant for demonstration purposes of the tool. The user can generate a basic random scenario for Use Case 2. Several parameters can be modified, which serve as input for the random distributions that the application uses to generate the input for the demo scenario. Another possibility is to import an earlier generated scenario. After either importing or generating a scenario, the user can perform a demo simulation run to show how the tool works. Instead of running a whole simulation, the user can also just display the scenario on a map, to give an idea of how the scenario looks like.
Figure 5.4 visualizes the most important application mode of our simulation tool, the simulation mode. This application mode can be used to run multiple replications of different scenarios. In the section for scenario selection, under inactive scenarios, all available scenarios in the base application folder (a designated folder for the application located in the user’s documents) are displayed. By selecting one or multiple inactive scenarios and then pressing the button with the arrow to the right, the user can activate the selected scenarios. When the user starts the simulation (by pressing the button that displays “Running…” in Figure 5.4, but before the start of the simulation displays “Start simulation”), these activated scenarios will be simulated. The bottom progress bar indicates how many customers have already arrived in the simulation of the current booking period. The middle progress bar indicates how many replications have been performed already. The top progress bar indicates the overall progress for all activated scenarios. Whenever all replications for a scenario have been performed, the scenario is moved to the section with finished scenarios. During the simulation the current scenario and replication is displayed on a map. A green marker indicates a confirmed customer order, a red marker a customer order that could not be served. The orange marker with the ORTEC plus symbol indicates the location of the central depot. The section with simulation output gives the user information about what happens in the simulation run and serves for instance for verification purposes. During a replication all algorithms as described in Section 5.1 are run and at the end of each replication the results are exported, so the user can analyze the results afterwards.
Figure 5.4. Screenshot of the simulation mode
Map rights: ©2019 Microsoft Corporation, ©2019 NAVTEQ, ©2019 Image courtesy of NASA, plugin by GMap.NET Figure 5.5 displays the last mode, the solution visualizer. For each replication our simulation tool exports a JSON file that contains all information that is required to display the solution found for that replication on a map. We export for instance all the customers, with for each customer whether they are served or not and many other output metrics that were discussed in Section 5.1. We also export the final delivery routes that are formed, as well as other solution metrics. The solution visualizer mode enables us to import any solution file generated by our simulation tool and visualize the final routing plan that is formed. This application mode is quite useful, especially for verification purposes and gaining credibility for our simulation model.