Bachelor Degree Project
A comparison of simulation tools for supply chain management
Author: Shishengxiong Zhong and Jinzhe Zhao Supervisor: Sabri Pllana Semester: VT 2020 Subject: Computer Science Abstract
This report provides a comparison of discrete-event simulation tools for supply chain models. We use different simulation tools (Arena and AnyLogic) to analyze and inspect the C14 supply chain management benchmark, as well as, a real-world busi- ness supply chain model that is provided by Vantai company in China. In this study, we consider different aspects of these simulation tools (such as, the capability of discrete-event simulation, visualization, simulation efficiency and accuracy, and de- bugging) to explore their advantages and disadvantages. We hope that our simulation results will have a positive impact on the supply chain management of the companies that provided us with data for this study; furthermore, the comparison results may be useful to developers and researchers in future simulation studies. Keywords: Supply Chain Management; Discrete-Event Simulation; Arena Sim- ulation Software; AnyLogic Simulation Software; Comparison of simulation tools. Preface
We like to use this opportunity to thank our supervisor Sabri Pllana for the opportunity and the research topic along with the aid he provides for us to proceed and accomplish this research. We would also like to thank the China Vantai company for sharing their data and support us to build our supply chain model and the research. Both Sabri and Vantai company have been encouraging and helpful for us during past few months. We would not be able to finish our degree project without their help. Contents
List of Figures
List of Tables
1 Introduction 1 1.1 Background ...... 2 1.1.1 The Anylogic simulation software ...... 2 1.1.2 The Arena simulation software ...... 2 1.1.3 Discrete-event simulation ...... 3 1.1.4 C14 Supply Chain Management ...... 3 1.1.5 Vantai Supply Chain Model ...... 3 1.2 Related work ...... 4 1.2.1 C14 Supply Chain Management Benchmark ...... 4 1.2.2 C14 Supply Chain Management - AnyLogic 4.0 ...... 4 1.2.3 An Object-oriented Approach to ARGESIM Benchmark C14 ’Sup- ply Chain’ using MATLAB ...... 5 1.2.4 Comparison of discrete event simulation tools in an academic en- vironment ...... 5 1.3 Problem formulation ...... 6 1.4 Motivation ...... 6 1.5 Objectives ...... 7 1.6 Scope/Limitation ...... 7 1.7 Target group ...... 7 1.8 Outline ...... 8
2 Method 9 2.1 Controlled variables and experimental environment ...... 10 2.2 The first controlled experiment ...... 10 2.2.1 Objective: C14 supply chain management ...... 11 2.2.2 Dependent variables: Expected modelling results ...... 16 2.3 The second controlled experiment ...... 16 2.3.1 Objective: Vantai supply chain model ...... 16 2.3.2 Dependent variables: Expected modelling results ...... 23 2.4 Comparisons metrics ...... 24 2.5 Reliability and Validity ...... 26 2.6 Threat to validity ...... 27 2.7 Ethical considerations ...... 27 3 Implementation 28 3.1 Implementation of C14 supply chain management ...... 28 3.1.1 Simulation model built by Anylogic ...... 28 3.1.2 The simulation results outputted by Anylogic ...... 38 3.1.3 Simulation model built by Arena ...... 40 3.1.4 The simulation results outputted by Arena ...... 44 3.2 Implementation of Vantai supply chain model ...... 46 3.2.1 Simulation model built by Anylogic ...... 46 3.2.2 The simulation results outputted by Anylogic ...... 54 3.2.3 Simulation model built by Arena ...... 55 3.2.4 The simulation results outputted by Arena ...... 60
4 Comparison Results of Simulation Tools 61 4.1 Tool capabilities with respect to discrete-event simulation ...... 61 4.2 Visualization ...... 65 4.3 Simulation efficiency ...... 71 4.4 Simulation accuracy ...... 76 4.5 Debugging ...... 78
5 Analysis 79
6 Discussion 82
7 Conclusion 83 7.1 Future work ...... 84
References 85
A Appendix A List of Figures
2.1 Controlled experiments overview ...... 9 2.2 JRE version ...... 10 2.3 Computer configuration ...... 10 2.4 the relationship between factory, distributor and wholesaler in C14 .... 11 2.5 Vantai model relationthips ...... 17 3.6 Product Agent ...... 30 3.7 Factory Agent ...... 30 3.8 The produce function of factory ...... 31 3.9 Distributor Agent ...... 32 3.10 The function buy of distributor ...... 33 3.11 The function getStorage of distributor ...... 34 3.12 The function sell of distributor ...... 34 3.13 The function addStorageFee of distributor ...... 35 3.14 Wholesaler Agent ...... 35 3.15 The method that wholesalers order product ...... 36 3.16 Main Agent ...... 37 3.17 the Main model ...... 41 3.18 FactoryProduce sub-model ...... 42 3.19 DistributorBuy sub-model ...... 42 3.20 WholesalerBuy sub-model ...... 43 3.21 ClearStock sub-model ...... 43 3.22 TaskA ...... 44 3.23 TaskB ...... 44 3.24 TaskC ...... 45 3.25 Factory Agent ...... 46 3.26 The produce function of factory ...... 47 3.27 Distributor Agent ...... 48 3.28 The function buy of distributor ...... 50 3.29 The function getStorage of distributor ...... 51 3.30 The function sell of distributor ...... 51 3.31 The function addStorage of distributor ...... 52 3.32 The function record of distributor ...... 52 3.33 Wholesaler Agent ...... 52 3.34 The function buy of wholesaler ...... 53 3.35 The Vantai simulation results outputted by Anylogic ...... 54 3.36 Main model ...... 57 3.37 FactoryProduce sub-model ...... 58 3.38 FactoryDiscount sub-model ...... 58 3.39 DistributorBuy sub-model ...... 59 3.40 WholesalerBuy sub-model ...... 59 3.41 The Vantai simulation results outputted by Arena ...... 60 4.42 the event component of Anylogic ...... 62 4.43 the Create module of Arena ...... 62 4.44 simulate The orders from the distributors with Anylogic ...... 63 4.45 simulate The orders from distributors with Arena ...... 64 4.46 Anylogic UI overall ...... 65 4.47 Arena UI overall ...... 66 4.48 Factory attributes in Anylogic ...... 67 4.49 the variables list of Arena ...... 68 4.50 Anylogic Chart ...... 69 4.51 Arena Chart ...... 69 4.52 Automatically generated report by Arena ...... 70 4.53 The limitation of Arena free version(1) ...... 72 4.54 The limitation of Arena free version(2) ...... 72 4.55 AppTimer configuration for Anylogic ...... 73 4.56 AppTimer configuration for Arena ...... 74 4.57 Anylogic operating screen ...... 74 4.58 Arena operating screen ...... 75 4.59 The order comparison of C14 between Anylogic and Arena ...... 76 4.60 The order comparison of Vantai between Anylogic and Arena ...... 76 4.61 The result of random integer result by Anylogic ...... 77 4.62 The result of random integer by Arena ...... 77 4.63 Error report of Anylogic ...... 78 4.64 Error report of Arena ...... 78 1.65 Anylogic random test code ...... A 1.66 Arena random test code ...... A
List of Tables
1.1 Project objectives ...... 7 2.2 Factories production ...... 12 2.3 Supply lead time ...... 12 2.4 Vantai products ...... 17 2.5 Vantai factory agent level ...... 18 2.6 Vantai distributor exclusive ...... 18 2.7 Discount for distributors ...... 18 2.8 The supply lead time between distributor and factory ...... 19 2.9 The supply lead time between distributor and wholesaler ...... 19 3.10 AnyLogic simulation agents for C14...... 29 3.11 AnyLogic simulation results for C14...... 39 3.12 Arena simulation variables for C14...... 40 3.13 Arena simulation results for C14...... 45 3.14 Arena simulation variables for Vantai ...... 55 4.15 Anylogic opening time ...... 73 4.16 Arena opening time ...... 74 4.17 Anylogic running time ...... 75 4.18 Arena running time ...... 75 5.19 Feature summary of Arena and Anylogic...... 79 1 Introduction
For a mature modern business system, outstanding management on the supply chain can effectively reduce the cost and increase its profit margins, thence, the research on the supply chain has extraordinary important value. However, the more mature supply chain is, the more intricate it will be [1]. In this case, simulation is frequently regarded as the suitable method for supporting the management decision making or researching on supply chain [2]. Currently, there are diverse simulation tools in the technology market. These simulation tools are used in different fields, their simulation capabilities are various when targeting different types of models. In the face of such massive simulation software, it may become a new problem that how to compare and select the appropriate simulator to make the research against the supply chain management more efficient. Based on this above issue, we started this research. At the beginning of this study, we found a phenomenon: In many different types of simulation research [3, 4, 5], the researchers usually use the discrete-event simulation to express the changes or events movements of the modelling system based on system time. This simulation is to abstract each system events into discrete events which triggered by the system time. [6, 7] This advanced method fits the supply chain simulation very well, after referred to other simulations on the supply chain [3, 8], we selected two popular simulation tools that support discrete-event simulation: AnyLogic and Arena. Since AnyLogic is developed base on JAVA, it possesses an excellent object-oriented modeling capability; As an individual system, the features that Arena holds make its modeling focus more on the overall process of the model. Due to this difference in their characteristics, the obviousness of our comparison could be enhanced. Therefore, We regard these two simulation tools as the comparison objectives. In order to compare Anylogic and Arena, we prepared two different supply chain models as the simulation objectives: C14 supply chain management [9] and Vantai sup- ply chain model. We use both of the selected simulation tools to simulate each model. Since each model was simulated by both AnyLogic and Arena, we obtained two build- ing processes and two simulation results within one supply chain model. Based on these obtained building processes and the outputted simulation results, the two simulation tools were compared. For comparison, we first referred to other related works on the comparison of simu- lation tools [10, 11, 12], then defined the comparison metrics of our research. According to the comparison metrics, we compared Anylogic with Arena based on five aspects: the capability of discrete-event simulation; Visualization; simulation efficiency; simulation accuracy, and debugging. The calculations of these metrics were explained in the Com- parison Metrics at the Method Section.
1 1.1 Background
To fully understand the concepts of this research, it is essential to have basic knowl- edge regarding
• The Anylogic simulation software
• The Arena simulation software
• Discrete-event simulation
• C14 Supply Chain Management Benchmark
• Vantai Supply Chain Model
This chapter provides a basic overview of the compared simulation tools, two differ- ent model templates and simple inforduction of discrete-event simulation. We describe those detailed models and their discrete events in the method section.
1.1.1 The Anylogic simulation software
Since developed based on java, Anylogic is a professional object-oriented simula- tion software which supports to develop models using three modern simulation methods including discrete events, agent-based, system dynamics. Anylogic has been used to in- sights even optimizes complex systems and processes across a wide range of industries, such as manufacturing, medical, transportation even business processes, its clients include DHL, Airbus, TOYOTA and etc. These clients use AnyLogic to simulate and analyze their own business or manufacturing processes [13]. As one objective of this research, Any- logic was used to process the discrete-event simulation of two supply chain models, then we compared Anylogic with another simulation software.
1.1.2 The Arena simulation software
As a classical simulation tool, Arena is more based on process, due to its unique system, users can only express the flow of the system or event through the cooperation be- tween the various attached modules when using Arena for simulation, rather than specifi- cally modeling an object or event. Therefore, Arena mainly used to simulate the business process and discrete event by its modules [14]. In this research, Arena as another com- parison objective, we attempted to use it on the discrete-event simulation of supply chain models. According to the building process when simulating the supply chain models and outputted simulation results, Arena was compared with Anylogic.
2 1.1.3 Discrete-event simulation
In a system, we can always find a time point to label the changes in the system. These time points are discrete on the time axis rather than continuous, the state of the system is only changed at the time points. by abstracting these discrete times into system events, any changes in the system can only be achieved by processing the corresponding events. In simple words, discrete-event simulation is a method to predict system changes according to the events changing at discrete time points [6, 7]. For example, factory production is to make the material to product. Using discrete event simulation modeling, the production process from the material until a product is modeled with two events, namely a production-start event and a production-end event. The actual process of the production would be modeled as a time delay between the production-start to production- end events.
1.1.4 C14 Supply Chain Management
As a classic supply chain model, there have been many descriptions of the model such as SIMULATION NOTES EUROPE. In this research, We will consider the C14 Supply Chain Management as one model template, using Anglogic and Arena to simu- late this model especially inside discrete events, then compare the two simulation tools through their building processes and simulation results.
1.1.5 Vantai Supply Chain Model
Vantai Supply Chain Model as another model template in this research, it has more complicated relationships between the upstream and downstream. For example, the dis- tributors are ranked into different grades by the factories with corresponding price dis- counts, the high-ranking distributors are even provided with the unique product. Besides, Vantai supply chain model possesses numerous system events, such as the discount event for distributors or the refunds initiated wholesalers.Since most of the data in this model is provided by China Vantai company which as one of the distributors in the supply chain, it will focus more on profits and costs of the distributors.(detaied model was showed in Method Section) By using Anglogic and Arena to simulate this model to collect their output simulate processes and simulation results, then compare the Anylogic with Arena according to these building processes and simulation results.
3 1.2 Related work
This research is based on model-building to compare two different simulation tools. During this thesis, we refer to many relative works to select one of the supply chain models according to the related simulation projects published in the journal Simulation Notes Europe (SNE)1 and reference their simulation algorithms and results. We also develop our comparison metrics by considering these relative works [12].In what follows in this sub-section, we highlight the relative works that have a profound influence on our research.
1.2.1 C14 Supply Chain Management Benchmark
The definition of C14 Supply Chain Management is described in SNE [9]. Author Shabnam Michèle Tauböck describes in detail for the basic definition of C14 supply chain management. According to this classic model, we have fully referenced the model as one of our controlled experiments, using Anylogic and Arena those two different simulation tools to build C14 supply chain model separately, then making a comparison of the first controlled experiment based on the performance during these building processes and the obtained two simulation results. For our research, we prepare another simulation model additionally as the second controlled experiment —– the Vantai supply chain model, which is only provided by the China Vantai company. Therefore, there is no academic research on this supply chain model yet.
1.2.2 C14 Supply Chain Management - AnyLogic 4.0
Author Michael.G and Johannes.K used AnyLogic 4.0 version to simulate the C14 Supply Chain Management. They first described and analyzed the model, then demon- strated their modeling ideas and published a part of their simulation results [15]. In their research, Anylogic is used, which also is one of the selected simulation tools in our study. Furthermore, their supply chain model —- C14 supply chain management, is one of our model templates as well. Therefore, our algorithms are inspired by these two scholars when we use AnyLogic to simulate C14 supply chain management. For example, to simulate the purchase, they express this event by sending an order and use system time to control it. We have used this discrete-event simulation method in our research as well. During our research, in addition to simulating C14 supply chain management by AnyLogic, we use Arena to model this supply chain template as well. Moreover, we use
1Simulation Notes Europe (SNE), https://www.sne-journal.org/home
4 both AnyLogic and Arena to simulate another supply chain model, to compare AnyLogic with Arena by these building processes and simulation results.
1.2.3 An Object-oriented Approach to ARGESIM Benchmark C14 ’Supply Chain’ using MATLAB
In this research, Matthias.W and Stephen.R simulated the C14 supply chain man- agement by MatLab, sharing their algorithms and publishing the complete simulation result. [16] Because of the incomplete simulation result in the previous related work(C14 Supply Chain Management - AnyLogic 4.0), we have to find another research to analyze the correct simulation result of C14 Supply Chain Management. The authors Matthias.W and Stephen.R explain their detailed simulation results in their study. We consider these simulation results to draft our expectation on C14 supply chain management simulation. In this relative work, the authors build the model by MatLab. However, our research does not include this software, we refer to their results of C14 supply management only, to assure our expectations.
1.2.4 Comparison of discrete event simulation tools in an academic environment
Author Jadric, Mario and Cukusic, Maja and Bralic, Antonia used Arena and Ex- tendSim to simulate two research models in their study, evaluating the simulation software on three main categories of criteria: modeling and simulation capabilities of the explored tools, and tools’input/output analysis possibilities. Each main category with respective sub-criteria such as the procedure of model building; Simulation efficiency; Modeling as- sistance; Speed of executing the simulation; visual aspects; Performance display and the possibility to clearly understand reports. Although neither the compared simulation software nor the models in their study are different from ours, it still valuable to be considered. By referring to their comparison criteria and the methods for performing comparisons, we designed a part of our compar- ison metrics: the capability of discrete-event simulation, simulation efficiency, and the visualization. The comparison of the discrete-event simulation capability is about the re- lated features of discrete-event simulation. The simulation efficiency is to compare the modeling assistance, the speed of opening the software, and the time cost of executing the simulation. The visualization is about the style of the user interface, the pixels of images or animations, and whether the structure of the user interface is clear In our research, we also prepared two additional comparison metrics on our own: the accuracy and the debugging ability. The comparison of the accuracy is to analyze and compare the simulation results that output by both AnyLogic and Arena. The debugging
5 ability is about the efficiency when debugging. Our detailed calculation methods of each metrics were explained in the Method Section.
1.3 Problem formulation
The goal of this project is to focus on comparing the two different simulation tools —-Anylogic and Arena on supply chain simulation. Based on such purpose, we designed two sets of controlled experiments, considering the C14 supply chain management and the supply chain data provided by the China Vantai company as the modeling templates for these experiments, then using AnyLogic and Arena to simulate each supply chain model. According to both the building processes and outputted modeling results of each simulation tool, we compared Anylogic with Arena from the capability of discrete-event simulation; Visualization; simulation efficiency; simulation accuracy, and debugging.
1.4 Motivation
The supply chain is an indispensable role in business groups. Through the flow of the information, logistics and funding, the supply chain will connect suppliers, manufac- turers, distributors, retailers, and end-users into one functional network chain structure. Outstanding management of the supply chain can effectively achieve the satisfaction of different customers, reduce the costs and increase profits. In order to pursue a more complete supply chain structure and achieve advanced management methods, many com- panies depend on the simulation of the supply chain based on their internal data for an- alyzing and optimizing. There are many professional modelling simulation tools in the technology market nowadays. Therefore, the topic that "how to compare and select an appropriate simulator to make the research against the supply chain management more efficient" has deeply attracted us. However, it would be a difficult task to compare all these simulation tools. There- fore, we focus on two famous and representative professional simulation software after the preliminary screening. The first one is AnyLogic, which is an object-oriented simula- tion software and developed based on java. AnyLogic as a set of modeling development tools combining multiple simulation theories, it is widely used in many fields; The other simulator is Arena, which is an advanced simulation software emphasizing business mod- eling and orienting more on the process. Arena is also known as simulation software that supports the discrete-event simulation theory. Since both of the two simulation software support the discrete-event simulation, but they have different features, the comparison be- tween them could be interesting. We compared the capabilities of these two simulation tools for supply chain management. Furthermore, we also attempted to find a comparison method of other simulation software from this research.
6 1.5 Objectives
Table 1.1 lists objectives of our project.
O1 Simulate the C14 supply Chain management and Vantai supply chain model by both Anylogic and Arena to obtain their building processes and simulation results. O2 Compare Anylogic and Arena according to the obtained building processes and simulation results from each supply chain model.
Table 1.1: Project objectives
Expected results are:
• To obtain the building processes and simulation results by using both Anylogic and Arena to simulate each supply chain model.
• To compare Anylogic with Arena according to their building processes and simula- tion results. The comparison results include five aspects: the capability of discrete- event simulation; Visualization; simulation efficiency; simulation accuracy and de- bugging.
1.6 Scope/Limitation
In this project, we selected Anylogic and Arena these two simulation tools against to supply chain simulation in our experiments and compare the two simulators based on the building processes and the results obtained. In fact, there is plenty of software avail- able for simulation such as Enterprise Dynamics, ANSYS, MatLab even the compiled languages like Python. The simulation capabilities of different tools in various fields have colossal contrast. However, It will be a huge task to completely compare all these simu- lation tools. In the term of comparison, we only compared the selected simulation tools from the five aspects as: the capability against to discrete-event simulation, visualization, the simulation accuracy, modelling efficiency and debugging. In addition, the optimiza- tions for simulation tools are also beyond the capabilities of this project.
1.7 Target group
The target group for this study may be commercial companies which managing a similar supply chain model or some researchers and developers who may interested in the simulating processes to have their own comparisons even try to optimize these two simulation tools.
7 1.8 Outline
In order to achieve the purpose of comparing the two simulation tools, we designed two sets of controlled experiment, we expected to compare the two tools by the building process of each simulation and the outputted modeling results in the experiment. The spe- cific experimental methods and comparisons metrics were described in the next section, the reliability and validity discussion and ethical considerations were also included. In Implementation section, we show the detail processes of each our experiment —– simu- lation processes and simulation results. The results of the comparison were displaying in Section 4; In the section 5, the the two simulation tools were analysed based on the ob- tained compare results. In section 6, we discussed how the research results are helping to solve our target questions. In section 7, we provided our conclusion for this research and further research objectives. Last pages of this report contained reference and Appendix.
8 2 Method
The purpose of this project is to compare the two simulation tools —- Anylogic and Arena against the in supply chain models with discrete-event simulation. To realize this purpose, the controlled experiment was selected as our method. However, If only prepare for one controlled experiment, the comparison may be short of representativeness or accuracy. In order to avoid such problem, the second controlled experiment was set. For the first set of the controlled experiment, We referred C14 supply chain management as the objective, used these two simulation tools as the controlled variables; In the second set of the controlled experiment, the Vantai supply chain model was considered as the objective but the same controlled variables would have. The obtained simulation building processes and modelling results were observed as dependent variables of each experiment. Anglogic and Arena were compared according to the dependent variables in the same set of controlled experiment. Since the existence of the controlled experiment were two, Anylogic and Arena were actually compared twice. Combined the two comparisons, a comprehensive analysis was described in section 5. The entire overview was showed in the Figure 2.1.
Figure 2.1: Controlled experiments overview
In the following contents, we first defined the controlled variables and experimental environment in order to reduce the deviations of the experiments. Then giving a detailed description base on each set of controlled experiment including both the experimental objectives —- used supply chain models with their discrete events —- and the expected modelling results as the dependent variables. Further, we elaborated on specific compar-
9 ison metrics that combined both the simulation implement processes and the modelling results.
2.1 Controlled variables and experimental environment
Here we defined our controlled variables and experimental environment to reduce the deviations of the experiments. Obviously, in both two sets of controlled experiments, the controlled variables were the two compared simulation tools — Anylogic and Arena: Anylogic was determined to be 8.5.1 personal learning version. JAVA running environ- ment（JRE）must be installed since Anylogic is developed according to JAVA, the JRE that we used was the 10.0.2 version [Figure 2.2]; Arena 16.00.00002 free version was chosen as another controlled variable, the bundled report renderer was also installed. Be- sides, the device for running the simulations equaled to the experimental environment, therefore, our computer configuration had also been confirmed as shown Figure 2.3.
Figure 2.2: JRE version
Figure 2.3: Computer configuration
2.2 The first controlled experiment
In this controlled experiment, the experimental objective is C14 supply chain man- agement, we used Anylogic and Arena as the controlled variables to simulate C14 supply
10 chain management one by one. The processes and modelling results outputted by An- glogic and Arena should be seen as the dependent variables. In the following content, we described C14 supply chain management model in detail and highlight the system events inside and abstracted them into discrete-events, then discussed the modelling results we expected.
2.2.1 Objective: C14 supply chain management
As the objective of first set of controlled experiment, here we described the C14 supply chain management model with the abstracted discrete-events. [9]
Model description This model is a relatively simple supply chain with three different strategy task. First consisting of four factories, four distributors, and a group of wholesalers. Their supply relationships are shown in the Figure 2.4
Figure 2.4: the relationship between factory, distributor and wholesaler in C14
The factories produce 12 different products Pk (uniformly distributed) to supply the distributors. Each factory does not produce all types of products but only produces 6 different products. The interarrival time of products is distributed exponentially with parameter 600 seconds (independent of type of product). The products pk have no specific attributes such as weight or size.The products produced by each factory are shown in the Table 2.2.
11 F1 F2 F3 F4 P1 P7 P4 P10 P2 P8 P5 P11 P3 P9 P6 P12 P4 P10 P7 P1 P5 P11 P8 P2 P6 P12 P9 P3
Table 2.2: Factories production
All the factories with unlimited raw materials produce all the time around the day. For the first 7 days, they focus on expanding their own stock of products without any selling. Then the distributors start with their orders on the 8th day, 00.00( after 168 hours); at this time, each distributor orders 10 pieces per product to fill their storages. Further orders are placed once a day, at 00.00. If the product amount of an order cannot be fulfilled, it is postponed until the next day. Transport ordered products from factory cost distributor 10 per hour of delivery per order (independent of the number of products), the distributor’s storage costs are 1 per product per day, Observed stock essential is the number of stored products at next order time, independent from arrival or leaving time of an individual product. Furthermore, a supply lead time between distributor and factory (Table 2.3) must be taken into account.
F1 F2 F3 F4 D1 16 16 20 12 D2 15 16 13 19 D3 14 16.5 20 17 D4 22 13 16.5 18
Table 2.3: Supply lead time
A group of wholesalers orders stochastically products from the distributors (one product per order). Starting to place their orders to the distributors at 00.00 on the 9th day (after 192 hours). If the distributor who could not deliver products of an order to the wholesalers, this distributor will orders these products additionally from the factories at next order time (00.00, next day) The time in between orders is uniformly distributed over the interval [ 600,3600 ] seconds discretely.
TASK A: Simple Order Strategy Each distributor daily orders a constant amount of 2 pieces per product at the same
12 factory after they build their own stock of products(begin at 00.00 on the 9th day after 192 hours). Their supply relationships as shown in figure2.3, D1 and D2 order at F1 and F2, D3 and D4 at F3 and F4.
TASK A1: Simulate the system once for 30 days and show the stock of distributor D1 over time.
TASK A2: Perform 100 simulation runs, calculating maximum, minimum, mean and deviation of
• C = total cost of distributor D1
• N = number of products delivered by distributor D1
• R = relative costs of distributor D1, R = C/N
TASK B：On Demand Order Strategy Instead of ordering a constant number of products in Task A, now the distributor orders as much as needed to meet the demand of the downstream component: Each dis- tributor accumulates the orders (for each product) of the wholesalers –no matter fulfilled and not –over 24 hours (from 00.00 to 24.00 each day) and then orders that amount from the factories at the next order time (00.00, next day).
TASK B1: Simulate the system once for 30 days and show the stock of distributor D1 over time.
TASK B2: Perform 100 simulation runs, calculating maximum, minimum, mean and deviation of
• C = total cost of distributor D1
• N = number of products delivered by distributor D1
• R = relative costs of distributor D1, R = C/N
TASK C：Minimal Supply Time Strategy
13 In the previous tasks the distributors place their orders at fixed factories. Now each distributor faces to every factory and tries to order at a factory which has the minimal supply lead time. If the desired amount of products is not available, the factory next in ranking in regard to minimal supply lead time is chosen, and so on. If no factory can deliver, the order is postponed to the next day.
TASK C1: Perform 100 simulation runs, calculating maximum, minimum, mean and deviation of
• C = total cost of distributor D1
• N = number of products delivered by distributor D1
• R = relative costs of distributor D1, R = C/N
TASK C2: Compute a comparative table, showing mean and deviation of C, N and R for all three order strategies.
System events abstracted into discrete-events Here, we clarified the discrete events of C14 supply chain management in the fol- lowing contexts.
• Production of factory From the beginning of the simulation until the end, each factory has always main- taining producing. The production interval time between the two products is dis- tributed exponentially with parameter 600 seconds which means a factory produces a new product every 600 seconds, and every 3600 seconds each factory can com- plete a round of all the 6 types of products. At the beginning of the system, the 00.00 on the first day represents one product starting to produce, after 10 minutes till 00.10, this product is completed and the next product is starting to produce, and so on. In fact, a factory uses "every 10 minutes" to represent the process of produc- ing a product. Thus, from the beginning of the system, a timer every 10 minutes as a loop should be set to processing the production of a factory.
• The orders sent from distributor to factory At 00.00 on the 8th day( after 168 hours) of the system time, the first order of each distributor is sent to corresponding factories and distributors purchase each product
14 with the amount 10, regardless of the ordering strategy used. Further orders are placed according to different ordering strategies at 00.00 once a day. Therefore, at 168 hours of system time, the ordering movements of each distributor will be triggered; at 00.00 next day, the same trigger is called again, every 24 hours as a loop. Except for the first ordering movement, the specific implementation of the remaining ordering movements are changed according to the ordering strategy.
• The products arrive at distributor This discrete event is almost the same as the previous event. At 00.00 on the 8th day( after 168 hours) of the system time, the first order of each distributor is sent to corresponding factories, and the further orders are placed at 00.00 once a day. When a factory receives an order from the downstream, the ordered products will be sent immediately, after the corresponding supply lead time, these products are delivered at the distributor, this corresponding supply lead time can represent the delivery process from a factory to a distributor. Therefore, a timer should be acted when a factory receives an order, after a supply lead time, the timer is stopped since the ordered products have arrived at the distributor. This timer is also a 24-hour loop every day at 00.00 starting at 168 hours of the system time.
• The stock statistics of distributor This is an important discrete event since we have to observe the distributor’s stock in task a and b. The stock statistics essentially is the number of stored products at next order time, independent from arrival or leaving time of an individual product. Starting at 168 hours, a stock checking is called, the same movement acts again at the 00.00 next day. Actually, this is a similar timer as the one triggering the distributor’s ordering movements, starting at 168 hours and calculating the current stock of observed distributor every 24 hours. In this way, stock statistics can be obtained.
• The orders sent from the group of wholesalers to distributor Since the time in between orders is uniformly distributed over the interval [600,3600] seconds, the group of wholesalers will send one order to a random distributor, the interval time between two orders is minimum 10 minutes, 60 minutes maximum. At 192 hours of the system time, the first one order is sent from wholesalers to a random distributor. The next ordering movement will be triggered after a random integer time within the range of 10 to 60 minutes. In other words, when the previ- ous ordering movement is completed, a timer will be set after a 10-minute interval， when this timer is acted, the next ordering movement must be triggered within 50 minutes; when the next ordering movement is acting, a new timer will be set again
15 after the same interval time, and so on. The cased result is the total number of orders from wholesalers will be as a range of minimum 24 to maximum 144.
2.2.2 Dependent variables: Expected modelling results
For a fixed model, the obtained result by each simulation is not always at the same value, these results are different but they are at the same range. According to these re- searches we referenced and the analysis of each order strategy, the following simulation results was expected: The stock of distributors should be raised to 120 after the first order, the further stock should have different trends based on the used order strategy. On Simple Order Strategy, ordering a fixed number of products made the stock gradually rise, the total cost and the relative cost on this strategy should be the most expensive one; On De- mand Order Strategy, products were ordered on demand make the distributors offer less additional stock, the total cost and the relative costs were cheaper; The Minimal Supply Time Strategy based on the previous strategy, transportation costs reduced by choosing the shortest supply lead time, therefore, the cheapest total cost and the relative costs should be had and a similar stock tend with On Demand Order Strategy should be got. Moreover, the deliver amounts of these three strategies should be at a same range. Whether using Anylogic or Arena, the obtained results should be at the same range as long as the model was built correctly.
2.3 The second controlled experiment
As the second controlled experiment, the experimental objective should be Vantai supply chain model, we also used Anylogic and Arena as the controlled variables to sim- ulate Vantai supply chain model one by one. The processes and modelling results out- putted by Anglogic and Arena should be seen as the dependent variable in this controlled experiment as well. In the following content, we explained Vantai supply chain model in detail and highlight the system events inside and abstracted them into discrete-events, then discussed the modelling results we expected.
2.3.1 Objective: Vantai supply chain model
As another objective in the second set of controlled experiment, the included discrete events of Vantai supply chain model are more that C14 supply chain management. The detailed descriptions of the model and the inside discrete events as followed.
Model description
16 This model is based on the data information provided by China Vantai company. First consisting of three factories, three distributors, and a group of wholesalers. Their supply relationships are shown in Figure 2.5.
Figure 2.5: Vantai model relationthips
The investigations consider a time horizon of 120 days, beginning at 00.00 at the 1st day and ending at 24.00 at the 120th day, totally 2880 hours. For the three factories, they produce 9 different products Pk (uniformly distributed)in total and to supply the distributors. Each factory only produces 3 types of different prod- ucts. The interarrival time of each product is distributed exponentially with parameter 20 minutes (independent of type of product) in the first 3 days, and then the interarrival time turns to be 180 minutes. The products pk have no specific attributes such as weight or size. The products produced by each factory are shown in Table 2.4.
Factory 1 Factory 2 Factory 3 Product 1 Product 4 Product 7 Product 2 Product 5 Product 8 Product 3 Product 6 Product 9
Table 2.4: Vantai products
All the factories are also supposed to be supplied with unlimited raw materials and keep produce 24 hours per day. For the first 3 days, the factories only producing without any sells in order to build their own stock of products. At 00.00 on the 4th day(after 72 hours), the factories begin to receive orders from downstream. At the same time, account from the 00.00 on the 4th day(after 72 hours), all these three factories will stop the production for one day off after working six days （after every 144hours, taking a 24-hour break) to ensure a quality performance and longer service-time of the production equipment. However, order receives and deliver products will be continued.
17 Moreover, in the model, the factories are ranking each distributor in three different levels in Table 2.5.
Factory 1 Factory 2 Factory 3 Distributor 1 Level A Level B Level C Distributor 2 Level B Level C Level A Distributor 3 Level C Level A Level B
Table 2.5: Vantai factory agent level
Each factory will consider their Level A distributor as the exclusive agent and give them the exclusive rights to sell one type of product, other distributors without the ex- clusive rights cannot order or sell this type. The exclusive rights of product for each distributor in the Table 2.6.
Name Exclusive rights of Product Distributor 1 Product 1 Distributor 2 Product 7 Distributor 3 Product 4
Table 2.6: Vantai distributor exclusive
The 4 Distributors Di supply a group of wholesalers and order from the factories. After the factories produce for 3 days to have a stock of products, Then the distributors start to purchase their regular orders after the 72 hours at 00.00 on 4th day. The regular order is a repeated order with a 30-day interval. When the distributors going to have the regular orders, the factories will give each of them a specific discount according to their rank. The higher rank distributor is, the greater discount will be. Except these regular order, the remaining orders have no discount. The discount of each level in the Table 2.7.
Level Discount A 55% B 65% C 75%
Table 2.7: Discount for distributors
Besides, The supply lead time between the factories and distributors must be consid- ered. The details is in the Table 2.8. In once regular order, each distributor will order 20 pieces per exclusive product and 10 for each normal product, the total amount that ordered should be 80 pieces. After the 72 hours(at 00.00 on 4th day), the first regular order is sent by a distributor to the factories in order to load their own stock. At 00.00 the next day —- after 96 hours on 5th day, the
18 F1 F2 F3 D1 14 16 18 D2 16 18 14 D3 17 15 17
Table 2.8: The supply lead time between distributor and factory group of wholesalers will start to orders stochastically products from the distributors(one product per order). The time in between these orders is uniformly distributed over the in- terval [ 50, 150 ] minutes discretely. If the ordered amount can be covered by the stock of distributors, then the distributors will deliver the product immediately. Otherwise, the dis- tributor accumulates the orders (for each product) of the wholesalers that not be fulfilled over 24 hours and then orders that amount from factories at the next order time(00.00) without discount. Further, The supply lead time in between of distributors and wholesalers also need to be calculated. The details is in the Table 2.9.
W D1 11 D2 12 D3 11.5
Table 2.9: The supply lead time between distributor and wholesaler
If set the cost of each production is unified as 1, the factories must ensure that the minimum profit of a single product is 17% to maintain healthy development. In this situation, after the most discount on A-level distributors, the profit of one single product for the factories must be still kept above 17%. To achieve this profit, the original price should be 2.127 per product; after discounts, the price for level A is 1.17 per product; for level B is 1.3845 per product and for level C is 1.5975 per product. For distributors, they must keep the profit of a single product at least 25% to ensure their costs can be full covered. Since the cost per product is considered as the original price from the factories, the final transacted price for the group of wholesaler is 2.658 per product. Furthermore, distributors have to spend on both the storage costs and the deliver fee that transport to the wholesalers. For their storage, the cost is 0.05 per product per day (essential is the number of stored products at next order time, where the storage costs are calculated as the formula (cost per day) * (number of stored products), independent from arrival or leaving time of an individual product).
19 The deliver fee costs 0.03 per hour of delivery per order (independent of number of products). After the basic flow of this supply chain model, there are two special event need to be discussed. The first event is acted by factories. All the three factories will carry out a discount event individually with a fixed probability of 20 % every 15 days. At 00.00 on the 15th day (after 336 hours), the factory is determining that if to hold a discount event or not. Only 20 % probability for each factory will agree to hold. If disagree, the same action will be achieved again with the same probability at 00.00 the next day after 24hours. Until the discount even is agreed, The second discount event will be after a 15-day interval. During the discount event, the distributors will purchase additional random amount of random product type but at less 3 of the exclusive product. The second event is realized on the wholesaler. If an order is still not delivered by upstream after 24 hours of sending it, this order will be considered as overdue order and may be cancelled with a starting probability of 0 %, every one hour more waiting, 0.1 % probability for undo is added. Since the sending order time is different, the wholesalers should check all the sending orders every minute starting at 00.00 6th day.
Observation Task Simulate the system once for 120 days and show the following contents:
• The stock of distributor D1 over time.
• The outcome of distributor D1 over time
• The income of distributor D1 over time.
• The profit of distributor D1 over time.
• The number of overdue orders by distributor D1.
• Total number of overdue order.
• Total discount event achieved.
System events abstracted into discrete-events Since there are a lot of discrete events in this model, Therefore, the detail of dis- crete events were explained as the movements of a system, in one movement, one or two discrete events may be included.
20 • Production of factory For the 3 days from the beginning of the simulation, the factories keep a fast pro- duction rate, the interarrival time of each product is distributed exponentially with parameter 20 minutes, At 00.00 4th day after 72 hours, the factories slow down their production rate as distributed exponentially with parameter 180 minutes and maintaining this producing rate until the end of system. For the system, there are three types of discrete events. Firstly, at the beginning of the system, the 00.00 on the first day represents one product starting to produce, after 20 minutes till 00.20, this product is completed and the next product is starting to produce, and so on. The factory use "every 20 minutes" to represent the process of producing a product of the first 3 days. At the 00.00 on 4th day, after 72 hours of system time, a timer is setted to trigger the slowdown of production. When the timer is triggered, the parameter of production is turn to 180 minutes which means the process of producing a product will be maintaining as "every 180 minutes".
• The one day off for factory The factories have not always maintaining producing. Account from the 00.00 on the 4th day(after 72 hours), all these three factories will stop the production for one day off after working six days （after every 144hours, taking a 24-hour break) to ensure a quality performance and longer service-time of the production equipment. For the system, the first timer should be triggered to represent the beginning of a six-day normal working period for the factories. After six days of this timer is called, another timer is setted to represent both the ending of the normal working period and the beginning of the one day off. After 24 hours, the first timer should be used again to represent the other beginning of the normal working period, so on as a loop.
• The orders sent from distributor to Factory At 00.00 on the 4th day( after 72 hours), the first regular order of each distributor will be sent to factories and purchase each product with a fixed amount. The regular order should be as a loop every 30 days. For the the system, at 00.00 on the 4th day( after 72 hours), the trigger is acted to represent the first-time regular order from distributors to factories. the same trigger should be used every 720 hour 30 days. Further orders are placed according to the extra requirement of distributors once a day at 00.00 ordering time. Therefore, also begin at 72 hours of system time, a timer should be achieved at 00.00 each day to represent the extra order from distributor. The order should be avoid if distributors has no extra requirement.
21 • The products arrive at distributor This discrete event is almost the same as the previous model. At 00.00 on the 4th day( after 72 hours) of the system time, the first order of each distributor will be sent to corresponding factories, the further extra orders are placed at 00.00 once a day. when a factory received an order from the downstream, the ordered products will be sent immediately, after the corresponding supply lead time, these products are delivered at the distributor, this corresponding supply lead time can represent the delivery process from a factory to a distributor. Therefore, a timer should be acted when a factory receives an order, after a supply lead time, the timer is stopped since the ordered products have arrived at the distributor. This timer is also a 24-hour loop every day at 00.00 starting at 72 hours of the system time. If there is no extra order, 0 products will be delivered.
• The stock statistics of distributor This is an important discrete event since we also have to observe the distributor’s stock. The stock statistics essentially is the number of stored products at next order time, independent from arrival or leaving time of an individual product. Starting at 72 hours, a stock checking will be called, the same movement will acting again at the 00.00 next day. Actually, this is a similar timer as the one triggering the distributor’s ordering movements, starting at 72 hours and calculating the current stock of observed distributor every 24 hours. In this way, stock statistics will be obtained.
• The orders sent from the group of wholesalers to distributor Since the time in between orders is uniformly distributed over the interval [50,150] minute, the group of wholesalers will send one order to a random distributor, the interval time between two orders is minimum 50 minutes, 150 minutes maximum. At 96 hours of the system time, the first one order for a product is sending from wholesalers to a random distributor. The next ordering movement will be triggered after a random integer time within the range of 50 to 150 minutes. In other words, when the previous ordering movement is completed, a timer will be set after a 50- minute interval，when this timer is acted, the next ordering movement must be triggered within 100 minutes; when the next ordering movement is acting, a new timer will be set again after the same interval time, and so on.
• The products arrive at wholesalers Same as the one The products arrive at distributor. At 00.00 on the 5th day( after 96 hours) of the system time, the first order of wholesalers will be sent to dis- tributors with a range interval as [50,150] minutes. when a distributors received
22 an order from the downstream, if their stock could fulfilled this order, the ordered products will be sent immediately, after the corresponding supply lead time, these products are delivered at the wholesalers; if not, after the distributor send the ex- tra order at00.00 next day and received the products after supply lead time with factories, then the ordered products will be sent. this corresponding supply lead time can represent the delivery process from a distributor to wholesalers a distrib- utor. Therefore, a timer should be acted when a distributor receives an order, after a supply lead time, the timer is stopped since the ordered products have arrived at the wholesalers. This timer is also a 24-hour loop every day at 00.00 starting at 72 hours of the system time. If there is no extra order, 0 products will be delivered.
• The discount events The first event is acted by each factory. All the three factories will carry out a discount event individually with a fixed probability of 20 % every 15 days. For the system, At 00.00 on the 15th day (after 336 hours), a trigger with a fixed probability of 20 % will be used to represent a discount event is happened. If the trigger is not be used, the same trigger with the probability of 20 % should be called again after 24 hours. Until the discount even is happened, The trigger represents to the discount event will be used after a 15-day interval as a loop.
• Cancel order by wholesalers This event is realized on the wholesaler. If an order is still not delivered b yupstream after 24 hours of sending it, this order will be considered as overdue order and may be cancelled with a starting probability of 0%, every one hour more waiting, 0.1 %probability for undo is added. Since the sending order time is different, the wholesalers should check all the sending orders every minute starting at 00.00, 6th day. For the system,
2.3.2 Dependent variables: Expected modelling results
For a fixed model, the obtained result by each simulation is not always at the same value, these results are different but they are at the same range. Due to lack of relevant research or report to refer on, we can only analysis the model to predict the expected modelling results: Since the price setting in this model is based on the lowest profit rate, the income should be just cover the expenditure for distributors. For distributors, If they want to keep break even, then before they purchase the reg- ular order every 30 days, they need to consume almost all of their storage first, otherwise, the increasing inventory costs will cased more and more expensive outcome. Therefore,
23 the products that purchased once at each regular order should be sold until they start to order the order the requirements of wholesalers which means the distributor is lacking of storage within 30 days. The basic storage changes should be as a periodic changes every 30 days as well. Besides, the total income and total outcome including inventory costs and delivery fee of observed distributor should be almost flat, the profit of this distributor should be slightly greater than 0. Furthermore, three of the distributors have the same order method and selling, plus the same costs and profits, the events happened on each distributor should be same as well.Thus, the number of return orders by the wholesalers from distributor 1 should be almost one-third of all returns.
2.4 Comparisons metrics
In our two sets of controlled experiments, the experimental objectives were the two supply chain models —– C14 supply chain management and Vantai supply chain model. By using Anylogic and Arena against to simulate each of the objectives, two sets of mod- elling results and simulating processes can be obtained. These modelling results and simulating processes of each set can be divided based on the used tool.In fact, four types of modelling results and simulating processes should be got through these two sets of con- trolled experiments. Since our target groups were not only included business companies with similar supply chain that focus on simulation results but also some developers or re- searchers who may be interested in the simulating processes for comparing or optimizing these simulation tools. In order to satisfy the needs of different readers, We combined both the building processes and simulation results to have a full comparison of Anylogic and Arena. After referred to the research of other scholars [10, 11, 12], we designed the comparison metrics as the following aspects:
• The capabilities against to discrete-event simulation In these two experimental supply chain models, there are many system events which triggered according to system time, to represent the movements or changes of model systems and push the evolution of the entire system forward. In order to simulate these system events, the discrete-event simulation is used. Therefore, the compari- son of the capabilities to discrete-event simulation must be considered. For a more obvious comparison on this metric, we first compare the features to set the triggers of each event. Then, we compare the features which used to build these event mod- els. This comparison metric is to evaluate the usability of related features, and the capability to build system events. The design and evaluation of this comparison metric is referred to another research [11]. We considered their criteria of simu- lation efficiency and used their evaluation into our comparison of the capability in
24 discrete-event simulation.
• Visualization Using a simulator which has visualization function to build a model can help the user clean the logic and relationships between different components of the model and improve modeling efficiency. If there is no visualization function or the visual- ization is not rich, it may be confusing when dealing with the logic or relationships, especially with some large complex models. To compare this metric, the overall visualization of the two simulation tools are compared. Besides, the comparisons for both the building process and the outputted simulation results are also displayed separately. We evaluate the visualization by considering the style of the user in- terface, the pixels of images and animations, and whether the structure of the user interface is clear. For this evaluation, we referred to the visual aspects from the study [11]. However, since the lack of a professional visual measure tool, our eval- uations of both the GUI style and the pixels are relatively general.
• Simulation efficiency For the comparison of simulation tools, simulation efficiency is one essential com- parison metric. We compare this metric from two aspects: building efficiency and running efficiency. The building efficiency is to compare the features that have been optimized to improves efficiency for the user to build models, further, the limitation of the used version was also included in this comparison. The running efficiency is the speed of opening the simulation software and the time cost of executing the simulation. For comparing the building efficiency, we evaluate the smoothness of dragging modules, the assistance when connecting modules, and also the limitation of the used version. For comparing the speed of opening the simulation software, we use a professional tool called "AppTimer" to measure the simulation software’s opening speed. We measure each simulation software by 10 times, record all the results, and calculate the average. However, AppTimer cannot be used to measure the time cost of executing a model, therefore, we select to use the timer on Win- dows 10 to measure the time. We use both AnyLogic and Arena to simulate each model by 10 times, measure the time cost of each executing, record the results, and calculate the average. After all the measures, we compare the running efficiency by evaluating these average results. For our comparison of building efficiency, we referred to the evaluation of the modeling assistance from another thesis [11]. Be- sides, for our method to evaluate running efficiency, we referred to the same thesis about the speed of executing the simulation [11].
25 • Result accuracy When simulate a fixed model by the different tools, as long as the building process is correct, the obtained result should be at the same range. Hence, the method to compare the accuracy is: Comparing the result of each model output by both AnyLogic and Arena, analyzing the difference between their results and explaining the reason. Then have a further comparison of the reason for this difference. To design the method of this accuracy comparison, we referred from other scholars [12] about their result comparison.
• Debugging In the process of building a model when using a simulation tool, debugging the simulation is an extremely important step. A perfect simulation is always based on multiple debugging, only few people can guarantee to successfully build a model within once attempt [17]. Therefore, to compare the debug abilities of AnyLogic and Arena is necessary. This comparison has combined the comprehensiveness of the error report with the user experience for debugging. For this metric, we first studied the importance of debugging from other researchers [17], and then we designed the evaluating method by referring to their descriptions of debugging ability.
2.5 Reliability and Validity
We performed two sets of controlled experiments. For the two sets of controlled experiments, we confirmed the objectives —- two supply chain models; the controlled variables —- two simulation tools; the experimental environment —- one computer for running simulations. Besides, we also defined the comparison metrics. In one controlled experiment, we simulated one supply chain model twice, use only one simulation tool each time, each simulation output one process and one simulation result by the one simulation tool, compared the one process and simulation result by one tool with another process and result by another tool. In another controlled experiment, simulated another supply chain model with the same method, compared by the same method as well. According to these two controlled experiments, we can compared Anglogic and Arena since they were the used simulation tools in our two controlled experiments
26 2.6 Threat to validity
In our methodology, we designed the experimental method to solve our target prob- lem. However, there are some threats to validity. In the comparison metrics of the simulation efficiency, we considered the limitation of the version to evaluate the building efficiency. However, if a user chose to use other versions of the simulation software, this kind of limitation may be changed or removed. In such cases, to evaluate this limitation is worthless. Except for the characteristic of sim- ulation software, some evaluations are also affected by the hardware device. For example, the speed of opening the software and the time cost of executing the model. This kind of effect reduces the accuracy of evaluation, it is a potential threat to evaluate the comparison metrics. To eliminate these threats, We first defined the version of the selected simulation software. Then we declared the configurations of our hardware device. Furthermore, since AnyLogic is developed based on JAVA, the JAVA running environment(JRE) is required when using AnyLogic. Hence, we declared the version of our JRE as well. According to these kinds of declaration, we ensure the validity of our methodology.
2.7 Ethical considerations
Because the goal of this experiment is to compare two simulation tools which have a certain competitive relationship, the results of the comparison may cause unnecessary conflicts between the owners of the two simulation tools. Moreover, since the data of the Vantai supply chain model is provided by a real business company, these data may be a secret(such as the minimal profit or discount proportion). We used these data in our model template and published it. This behavior may cause the dissatisfaction of other commercial groups.
27 3 Implementation
In the previous chapter, we described the controlled experiment design of this study: We set up two sets of controlled experiments, to compare and analyze the two simulation tools by two bases: the simulation process and modelling results outputted in the same set of experiment. In this chapter, we showed the specific simulation building process when we used the two simulation tools to simulate our experimental objectives in both two control experiments. When using Anylogic to simulate the supply chain models, we referred to the building processes in Operations and Supply Chain Simulation with AnyLogic [3]; for Arena, the reference was from Simulation in supply chains: An Arena basis [8]. Besides, since to simulate the model was not the final purpose of this project, the simulation results from each experiment were also one basis for the comparison, the related modelling results in each controlled experiment were also displayed in this section. The following contexts was divided as each set of controlled experiment.
3.1 Implementation of C14 supply chain management
Here we explained the simulation building processes by using Anylogic and Arena against to C14 supply chain and display each result outputted by both Anylogic and Arena.
3.1.1 Simulation model built by Anylogic
During the building process of this model by using Anylogic, we first to created the empty agents for each objectives in the model. Then, we added the attributes into each agent by using the package proved by Anylogic such as function, parameter, variable, product and collection. In those packages, we wrote the codes by JAVA for further setting. After we completed creating the agent filled with specific attributes, we linked each agent as the entire model system. In the following contexts, we proved an overview table for created agents. Then, the introduction for the detail construction of each agent was followed. In the end, we displayed our connection of the model system by each agent.
1. Table 3.10 is the overview for created agents against the Factory, Distributor, Whole- saler and Product.
28 Agent Type Name Used for Parameter name (String) Product name Product Variable stock (Integer) Product amount name (String) Factory name produceInterval (Integer) The interval time of production (minute) Parameter produceList (Integer[12]) available products Variable productIndex (Integer) Index of currently production Function produce () Produce method Product (name=Product1) Product (name=Product2) Product (name=Product3) Product (name=Product4) Product (name=Product5) Product (name=Product6) Product (name=Product7) Product (name=Product8) Product (name=Product9) Product (name=Product10) Product (name=Product11) Product Product (name=Product12) 12 different types of products Factory Collection ProductList (ArrayList
29 2. In order to build the model, we created 4 agents as:The specific construction of each agent is followed.
(a) Product Agent This is the agent to represent the product with two attributes as shown in the Figure 3.6
Figure 3.6: Product Agent
i. The parameter name is the name of one type of product, It is used to mark this product in order to simplify the process on this product. For exam- ple, adding this product when the storage of this product is increased, or reducing this product when the storage is decreased. ii. The variable stock means the storage number of the type of product in the Factory, distributor or wholesalers. (b) Factory Agent This is the agent to represent the factory, the attributes inside are in the Figure 3.7.
Figure 3.7: Factory Agent
i. The parameter name is the name of one factory, It is used to mark this factory in order to simplify the process on this factory.
30 ii. The parameter produceInterval is represent the production interval time of this factory which controlled the production rate. The unit of the pro- duction interval time is minute. For example, if it is set as 10, factory will produce 1 product every 10 minutes. iii. The parameter produceList is a list with the available production of fac- tory. Since one factory do not produce all types of product but only 6 of different products, the intArray was used. The products with 0 means unproduced, 1 means produced. iv. The variable productIndex represents an index value that the current pro- ducing in the factory since the products is produced one by one. v. The function produce is the used function when the factory is producing. In this function, When the interval time is 0, the factory will produce one available product. After this production, the next available product will be produced after the interval time. The construct this function is shown in the Figure 3.8.
Figure 3.8: The produce function of factory
31 (c) Distributor Agent Here is the agent for distributor, the attributes inside are in the Figure 3.9.
Figure 3.9: Distributor Agent
i. The parameter firstBuyCount is the amount of products for the first time ordering. ii. The parameter nextBuyCount is the amount of products for all the order- ing except the first time. the parameter is different in each task. iii. The parameter transferFee is the delivery fee from factory to Distributor, costs 10 per hour of delivery each order, independent of the number of products. iv. The parameter storageFee is the storage costs as 1 per product per day. v. The parameter transferTime is the supply lead time between the factory and distributor vi. The variable isFirstBuy is used to decide if it the first time to order. Since the number of products ordered by the distributor for the first time is different with the orders in all the next coming days, a variable is needed to distinguish vii. The variable lackProductList is a HashMap
32 x. The function buy is the function to be called when distributor order prod- ucts. At 00.00 on the 8th day, the distributor begins to order the products. As the first time to order products, 10 pieces of each product will be pur- chased by the distributor, and then the further order with the amount of 2 pieces for each product will be purchased once a day at 00.00 (only in Task A. In Task B and Task C, the distributor do not order a fixed amount but according to the orders from the wholesaler requirement). If the or- der cannot be fulfilled, store the information of these ordered products in the lackProductList, and re-order these products again at the next order time. If the purchase is successful, then the delivery fee is calculated. The detail construction is shown in the Figure 3.10.
Figure 3.10: The function buy of distributor
33 xi. The function getStorage is return the total amount of all products added by the distributor, used as the data to draw the picture of storage. Count- ing the total storage amount of distributor by using the for loop that shown in the Figure 3.11.
Figure 3.11: The function getStorage of distributor xii. The function sell is the function to be called when distributor sell the or- dered products to wholesalers. If the ordered products that need to be sold is greater than the storage, then distributor stops this selling and record these out-of-stock products with type and amount, adding these into the order at next order time to the factory; if the storage of distributor can fulfill the ordered products, then delivery them directly. The construction is shown in the Figure 3.12.
Figure 3.12: The function sell of distributor
34 xiii. The function addStorageFee is the function to increase the storage cost of distributor every day. Seen in the Figure 3.13.
Figure 3.13: The function addStorageFee of distributor
(d) Wholesaler Agent Here is the agent for the group of wholesalers, their attributes are in the Figure 3.14.
Figure 3.14: Wholesaler Agent
i. The variable lastBuyTime is the variable to record the time of the last order time since the wholesalers send an order every 10-60 minutes. ii. The variable buyCount The number of products ordered by the whole- saler at one time. iii. The variable buyIntervalRange is the range of interval time when the wholesaler send the orders. Using String to code in JAVA in order to set this range of interval time. iv. The variable buyInterval is the random order interval of wholesalers. By Split the Srting, the intArray we got is to represent the specific interval time between two orders. v. The function buy is the method that wholesalers use to send order and purchase. The following construction shows the entire process when the wholesalers order the products. From the 9th day, wholesalers began
35 to order. The selected distributors, ordered products and order time are all random, by using the Math.random () method provided by JAVA to obtain random numbers. The number of distributors is 4, and of products is 12, so the numbers are randomly generated from 0-3 and 0-11. Since they are integers, the random numbers generated are finite and conform as the discrete distribution. The order time stipulated that it is randomly generated for 10-60 minutes, and also belongs to a discrete distribution. After the three random numbers are generated, order the products from the distributor. The detail of the function is in the Figure 3.15.
Figure 3.15: The method that wholesalers order product
36 3. Add and connect these agents into Main Agent in the Figure 3.16.
Figure 3.16: Main Agent
37 3.1.2 The simulation results outputted by Anylogic
Here we display the outputted results by Anylogic of each task in C14supply chain management and discussed these results we got if is satisfy our expected modelling re- sults.
1. Task A As we can see, at 8th day, the distributor 1 starting to order and have the storage with the amount of 120. Further, the storage is keep rising till the end. The related obtained results were also in the Figure 17(a) and Figure 17(b).
(a) The storage of distributor 1 in Task A1 (b) The related obtained results in Task A2
2. Task B For the storage of distributor 1 in this task, the amount of is floating in a gentle range since distributor 1 not to order a fixed product number anymore, But according to the requirements of the wholesalers. The related obtained results are were in the Figure 17(c) and Figure 17(d).
(c) The storage of distributor 1 in Task B1 (d) The related obtained results in Task B2
3. Task C Since distributor 1 also order products from factory according to the requirements of the wholesalers, the storage amount of distributor 1 in this task should be similar
38 as the previous Task. However, the minimal supply lead time will reduce the deliver fee, the cheapest total cost will be in this task. Both the storage amount and related obtained results were also in the Figure 17(e) and Figure 17(f).
(e) The storage of distributor 1 in Task C1 (f) The related obtained results in Task C2
4. Conclusion of modelling results Here, we computed a comparative table to show the minimal, maximum and aver- age of each C, N and R from the results of all three Tasks. Table ?? summarizes C14 simulation results of AnyLogic. We may observe that the delivered amount in this three Tasks are almost same with an acceptable difference range; the total cost in Task A is the most expensive one, in Task B is relative cheaper, Task C has the most cheapest total costs. Since their delivered amount is about the same, only the total costs cause changes in the relative costs which are also placed in the same sequence as the total costs. For the storage, Task A gets a continued increasing storage, both Task B and Task C has a similar storage. All these results in the Table 3.11 meet our expectations.
Task A TaskB TaskC Min C 14628 10884 5840 Max C 15057 10897 6160 Average C 14842.5 10890 5930 Min N 202 195 184 Max N 222 227 214 Average N 212 213,33 153.75 Min R 65.89 47.96 36.88 Max R 74.53 55.88 41.7 Average R 70.21 51.25 38.67
Table 3.11: AnyLogic simulation results for C14.
39 3.1.3 Simulation model built by Arena
Very different from anylogic, the building process of Arena focuses more on pro- cesses than objects. The building steps were divided into 3 as: created the route; created the Tank, built the model, including the main model and 4 different sub-model. In ad- dition, since the variable settings were universal without specific object, we defined the variable settings at the beginning.
1. The following variable in the Table 3.12 must be added.
Name Type Used for Day Real count the number of days (more than 30 days will be cleared and restarted) Round Real count rounds (some tasks have to run 100 times) FactoryProduceIndex Real the index of current producing in the factory DistributorBuyCount Real the number of products that the distributor ordered each time. DistributorBuyIndex Real index of current ordering product of the distributor WholesalerProductInedx Real index of current ordering product of the wholesaler ClearStockIndex Real the index of each product storage at distributor when the round number is cleared ResultN Real [] statistics the results of the total delivered product by the distributor ResultC Real [] statistics the results of the total costs by the distributor ResultNNow Real statistics the delivered product within current round ResultCNow Real statistics the total costs within current round IsDistributorBuy Real If the distributor order product at the current day
Table 3.12: Arena simulation variables for C14.
2. Created 4 routes, respectively as Main route; Factory route; Distributor route and Wholesaler route:
(a) The Main route creates an Entity every 1 day, which is represented for calcu- lating the number of days and the round number reset. (b) The Factory route creates an entity every 10 minutes to represent the produc- tion of factory. (c) Distributor route creates an Entity once with one day interval, used to repre- sent the orders, deliveries and cost calculation. (d) The entity of wholesaler is created by using the UNIF function. The entity is created at discrete and random intervals of 10 minutes to 60 minutes, represent for the order of Wholesaler.
These four routes are destroyed in the Dispose module at the end of day
3. Created 4 Factory Tanks, 4 Distributor Tanks, and one Wholesaler Tank; Further, inside each Tanks, the regulator was added to represent the increase, decrease and flow of products:
40 (a) Each factory Tank: 6 Regulators are added (b) Each distributor Tank: 12 Regulators are added (c) Each Wholesaler Tank: 12 Regulators are added as well
4. Using Assign, Decide, Seize, Release and other modules to processed the logic relationship in between, built the Main model and 4 of the sub-models as: Facto- ryProduce; DistributorBuy; WholesalerBuy and ClearStock. The following context described each model.
(a) Main model (Figure 3.17): it controls the flow of overall time.
Figure 3.17: the Main model
i. When the time was 0, clear all variables first. ii. Then let the factory starts production, the interval between each product is a discrete random number of 10-60 minutes. iii. On the 8th day, the distributor started to order products. iv. On the 9th day, the wholesaler began to order products, the interval time of order was calculated using the owned method of Arena as UNIF (10, 60).
41 (b) FactoryProduce (Figure 3.18): to represent the production of factory
Figure 3.18: FactoryProduce sub-model
(c) DistributorBuy (Figure 3.19): to represent the orders of distributor send to factory
Figure 3.19: DistributorBuy sub-model
42 (d) WholesalerBuy (Figure 3.20): to represent the orders of wholesaler send to distributor
Figure 3.20: WholesalerBuy sub-model
(e) ClearStock (Figure 3.21): when this round (30 days) was completed, clear all the storage and start a new round.
Figure 3.21: ClearStock sub-model
43 3.1.4 The simulation results outputted by Arena
Here we displayed the outputted results by Arena of each task in C14supply chain management and discussed these results we got if is satisfy our expected modelling re- sults.
1. Task A As same as the previous result by Anylogic, this results also showed the increasing storage of the distributor 1 with the most expensive costs. The Figure 3.22 is the results.
Figure 3.22: TaskA
2. Task B For this task, the amount of the storage of distributor 1 was also floating in a gentle range. The costs of distributor 1 is relative cheaper that the one in Task A. The Figure 3.23 is the results.
Figure 3.23: TaskB
3. Task C Since distributor 1 also order products from factory according to the requirements of the wholesalers, the storage amount of distributor 1 in this task is similar as the one in previous Task B. The cheapest costs is also got. Both the storage amount and related obtained results are also as follow. The Figure 3.24 is the results.
44 Figure 3.24: TaskC
4. Conclusion of modelling results According to the three figures that showed above, the changes in storage and total cost, transportation amount, and related costs have all achieved our expected results. In this C14 supply chain management simulation, the results obtained by Arena were similar to Anylogic, which proved that the accuracy of the two simulation tools are guaranteed when simulating C14 supply chain management. The Table 3.13 shown below the results of Arena.
Task A TaskB TaskC Min C 13130 10644 8444 Max C 14918 11493 9116 Average C 14024 11184.33 8780 Min N 234 220 234 Max N 243 243 243 Average N 232.335 213,33 238.5 Min R 65.89 47.96 36.88 Max R 74.53 55.88 41.7 Average R 70.21 51.25 38.67
Table 3.13: Arena simulation results for C14.
45 3.2 Implementation of Vantai supply chain model
Here we explained the simulation building processes by using Anylogic and Arena against to Vantai supply chain model and displayed each result outputted by both Anylogic and Arena.
3.2.1 Simulation model built by Anylogic
The same steps as used when simulating C14 supply chain management. During the building process of this model by using Anylogic. we first to created the empty agents for each objectives in the model. Then, we added the attributes into each agent by using the package proved by Anylogic such as function, parameter, variable, product and collection. In those packages, we wrote the codes by JAVA for further setting. After we completed creating the agent filled with specific attributes, we linked each agent as the entire model system. In the following contexts, since the agents have the similar attributes with the previ- ous when we simulated C14 supply chain management, we would not prove an overview table for created agents again. But, the introduction for the detail building process of each agent and the connection of the model system by each agent are also included.
1. In order to build the model, we created 4 agents as: The specific building of each agent was followed. This step was basically similar to C14 supply chain manage- ment simulation. Except that the number of factories and distributors had changed from 4 to 3, the product types had changed from 12 to 9. The attributes and methods of Factory, Distributor and Wholesaler had been partially adjusted.
(a) Factory Agent Here is the agent for the factory, their attributes are in the Figure 3.25.
Figure 3.25: Factory Agent
46 i. The parameter name is the name of one factory, It is used to mark this- factory in order to simplify the process on this factory. ii. The parameter produceInterval is represent the production interval timeof this factory which controlled the production rate. The unit of the produc- tion interval time is minute. For example, if it is set as 10, factory will produce 1 product every 10 minutes. iii. he parameter discount is the discount for the distributors in different level, which is a double array iv. The parameter distributorLevel is the level of the corresponding distrib- utors v. The parameter productPriceis the basic selling price of the product. vi. The variable discountCount is the number of discount events vii. The variable isDiscountDay is is if the discount event happened in the current day. viii. The variable discountDay is the interval time betwwen each discount event(unit as day). ix. The variable productIndex represents an index value that the current pro- ducing in the factory since the products is produced one by one. x. The function produce is the used function when the factory is producing. The factory will produce only one product at once. at the first 3 days, every 20 minutes produce one product. Then, one product every 180 minutes will be the production rate begins at 00.00 on the 4th day. At the same time, begin at 00.00 on the 4th day, the factory will have one day off after every 6 days of production. The construct this function is shown in the Figure 3.26.
Figure 3.26: The produce function of factory
47 (b) Distributor Agent Here is the agent for the distributor, their attributes are in the Figure 3.27.
Figure 3.27: Distributor Agent
i. The parameter id is a unique remark of each distributor which is conve- nient for us to operate the distributor accurately. ii. The parameter speedToWholesaler is the supply lead time for distributors to supply wholesalers. iii. The parameter speedToFactory is the supply lead time for distributors to be supplied by factories . iv. The parameter normalBuyCount is the number of normal products that the distributor ordered each time. v. The parameter uniqueBuyCount is the number of exclusive products that the distributor ordered each time. vi. The parameter transferFee is the delivery fee from factory to Distribu- tor,costs 0.05 per hour of delivery each order, independent of the number of products. vii. The parameter storageFee is the storage costs as 0.05 per product per day. viii. The parameter productPrice is the price of the product when the distrib- utor sells it to the wholesaler. ix. The variableoverdueCount is the number of orders that refunded by whole- saler due to overdue within one running period. x. The variable lackProductList is a HashMap
48 xi. The variable outcome records the total costs of the distributor, including product purchase cost, transportation fee and storage cost. xii. The variable income records the total income of the distributor selling products. xiii. The variable storageOutcome records the total storage cost of the distrib- utor. xiv. The variable transferOutcomerecords the total transportation fee of the distributor. xv. The ArrayList orderList is a list of orders sent by the wholesaler to the distributor, which records the product type, purchased amount and trans- action hour. This list is used as the basis for the wholesaler to return the goods, making the operation convenient xvi. The function buy it is the method that used when the distributor purchases products by order. Called the sell function to process the order from the wholesaler before purchasing from the factory. Afterwards, according to different factories, the discount price and the date of discount events are obtained. The regular order is purchased every 30 days, the distributor purchases of 20 exclusive product and 10 for every normal product in each regular order. Except for the regular orders, the distributor only order the required products of the wholesaler at the next an order time. If the required product is out of stock, record it and additionally ordered at the next purchase. If the required product can be fulfilled, the distributor delivers the product immediately. The detail construction is shown in the Figure 3.28.
49 Figure 3.28: The function buy of distributor
50 xvii. The function getStorage is return the total amount of all products added by the distributor, used as the data to draw the picture of storage. Count- ing the total storage amount of distributor by using the for loop that shown in the Figure 3.29.
Figure 3.29: The function getStorage of distributor xviii. The functionsell is the method called when the distributor to sell the prod- uct to the wholesaler. If the amount of products that need to be sold is greater than the storage, the distributor stops this selling and record the type and amount of these out-of-stock products, order these products at the order time next day. During this process, both the supply lead time from the factory to the distributor and the other supply lead time from the distributor to the wholesaler must be counted. If the storage can fulfil the ordered product, the product is delivered directly, and only the sup- ply lead time from the distributor to the wholesaler is calculated. The construction is shown in the Figure 3.30.
Figure 3.30: The function sell of distributor
xix. The function addStorageFee is the function to increase the storage cost of distributor every day. Seen in the Figure 3.31 as below:
51 Figure 3.31: The function addStorage of distributor
xx. The function recordWhen the wholesaler sending an order to a distribu- tor, the distributor records this order with type and numer in the orderList. Seen in the Figure 3.32 as below:
Figure 3.32: The function record of distributor
(c) Wholesaler Agent Here is the agent for the Wholesaler, their attributes are in the Figure 3.33 as followed:
Figure 3.33: Wholesaler Agent
i. In this simulation, this wholesalers agent included the similar attributes and methods with C14 supply chain management. The only difference is the functionWholesaler.buy. Processing the previous order first, if the distributor is out of stock, the wholesaler will wait for the delivery from the distributor. During this waiting, if the product is received, then the storage of distributor reduced and of the wholesaler increased; If the or- der is overdue, one more waiting hour, the return rate increase of 0.1%.
52 After processing the previous order, the wholesaler randomly selects one product types of a random distributor, after a random interval time within a range as 50-150 minute, the wholesaler sends order again for purchase. The construction is in the Figure 3.34 shown below:
Figure 3.34: The function buy of wholesaler
53 3.2.2 The simulation results outputted by Anylogic
Here we displayed the outputted results by Anylogic of Vantai supply chain model and discussed these results we got if is satisfy our expected modelling results.
1. Observation Task From this 120-day simulation, the total outcome of distributor 1 was about 963.56, the income of this distributor was about 1001.25, the profit was about 37.7, the refunded order of this distributor was 143, total refunded was 483, the total discount events of all factory was 17. The storage changes of distributor 1 in the first line chart was presenting periodic changes. The results are shown in the Figure 3.35.
Figure 3.35: The Vantai simulation results outputted by Anylogic
2. Conclusion of modelling results Compared with our expected results, the total outcome was just covered by the total income, the profit was in balanced even has a tiny increase. The storage of observed distributor periodic changed with 30 days as a round. When the time was closed to regular order, the storage decreasing becomes slower than before, which was a symbol that this distributor was starting to order from the factory and trying to send them to downstream, the storage was hardly decreased as before, even some times was increased by order refunded. Further, the refunded order of distributor 1 was 143, which was about 29% of the total number of refunded, about to equal the 1/3. These three kind of results were meet our expected results. Besides, after each regular order, the storage of distributor had a slight increase, the reason to cased this phenomenon was because the two special events: the discount events and order refunded, both of these two events were act on the distributor’s storage and cased a rising. Such simulation results were consistent with the design of this model.
54 3.2.3 Simulation model built by Arena
As similar with the building process by Arena during the previous simulation with C14 supply chain management, the building process of Arena in this model is still focus- ing more on processes than objects. The building steps was divided into 3 as: created the route; created the Tank, built the models including the main model and 4 sub-model. Although the steps were same, the detail methods were not all the same. In addition, since the much more variables needed to be set were universal without specific object, we defined the variables settings at the beginning.
1. The following variables in the Table 3.14 must be added in Arena.
Name Type Ues for Day Real count the number of days (more than 30 days will be cleared and restarted) FactoryProduceIndex Real the index of current producing in the factory DistributorBuyCount Real the number of products that the distributor ordered each time. DistributorBuyIndex Real index of current ordering product of the distributor WholesalerProductInedx Real index of current ordering product of the wholesaler Outcome Real [] Statistics of the distributor’s outcomes Income Real [] Statistics of the distributor’s incomes Distributor1Lack Real[] list of lacking product for distributor 1 Distributor2Lack Real[] list of lacking product for distributor 2 Distributor3Lack Real[] list of lacking product for distributor 3 DistributorFirstBuy Real If the distributor ordering for the first time DistributorAgentLevel Real[][] The level of distributor Distributor1Discount Real[] The discount for distributor 1 DistributorPrice Real the price that distributor sell FactoryPrice Real the price that factory sell FactoryTransferTime Real[][] The supply lead time of factory to distributor Distributor1OrderTime Real The delivery time of distributor 1 to wholesaler, could be one supply lead time or two. Distributor2OrderTime Real The delivery time of distributor 2 to wholesaler, could be one supply lead time or two. Distributor3OrderTime Real The delivery time of distributor 3 to wholesaler, could be one supply lead time or two. FantoryDiscountIndex Real Index of the factory that currently holding discount FactoryDiscountTime Real[] The next discount time Distributor1TransferTime Real[] The suppl lead time of each product than distributor 1 has Distributor2TransferTime Real[] The suppl lead time of each product than distributor 2 has Distributor3TransferTime Real[] The suppl lead time of each product than distributor 3 has Factory1IsDiscount Real If factory 1 holding discount TotalSell Real statistics of the total sold product by the distributor 1 TotalDiscount Real statistics of the discount events happended on distributor 1 TotalOverdue Real statistics of the refunded order on distributor 1
Table 3.14: Arena simulation variables for Vantai
2. Created 4 routes, respectively as Main route; Factory route; Distributor route and Wholesaler route:
55 (a) The Main route creates an Entity every 1 day, which is represented for calcu- lating the number of days and the round number reset. (b) The Factory route creates an entity every 10 minutes to represent the produc- tion of factory and the judgment of discount event every 15 days Factory (c) Distributor route creates an Entity once with one day interval, used to repre- sent the orders, deliveries and various cost calculation. (d) The entity of wholesaler was created by using the UNIF function. The entity was created at discrete and random intervals of 50 minutes to 150 minutes, represent for the order of Wholesaler.
These four routes are destroyed in the Dispose module at the end of day
3. Create 3 Factory Tanks, 3 Distributor Tanks, and one Wholesaler Tank; Further, inside of each Tank, the regulator was added to represent the increase, decrease and flow of one products:
(a) Each factory Tank: 3 Regulators are added (b) Each distributor Tank: 7 Regulators are added (c) Each Wholesaler Tank: 7 Regulators are added as well
4. Built 4 of the sub-models as: FactoryProduce; FactoryDiscount; DistributorBuy and WholesalerBuy.
(a) FactoryProduce: to represent the production of factory (b) FactoryDiscount: (c) DistributorBuy: to represent the orders of distributor send to factory (d) WholesalerBuy: to represent the orders of wholesaler send to distributor
5. Used Assign, Decide, Seize, Release and other modules to process the logic rela- tionship in between, constructing the Main model and 4 of the sub-models as: Fac- toryProduce; FactoryDiscount; DistributorBuy and WholesalerBuy. The following context described each model.
56 (a) The Main model (Figure 3.36): it controls the flow of overall time.
Figure 3.36: Main model
i. When the time is 0, clear all variables and reset. ii. hen let the factory starts production, also, the factory has a probability of starting a discount event with an interval time every 15 days. iii. On the 4th day, the distributor begins to order products. iv. On the 5th day, the wholesaler begins to order products, the interval time of order is calculated by using the owned method of Arena as UNIF (50,150), generate a discrete random number of the range as 50-150 min- utes. v. According to the storage of the distributor, the storage cost increased every day.
57 (b) The FactoryProduce Sub-model is shown in the Figure 3.37.
Figure 3.37: FactoryProduce sub-model
(c) The FactoryDiscount Sub-model is shown in the Figure 3.38.
Figure 3.38: FactoryDiscount sub-model
i. using FactoryDiscountIndex as the index of processed factory. ii. Decided the discount event of each factory with an interval time of 15 days, using the UNIF function that arena onwed, UNIF(1, 100) will gen- erate a random discrete number, compare this number with 20, If it is greater than 20, the discount will be. By this function, the probability is 20%. (d) DistributorBuy sub-model is shown in the Figure 3.39. i. First of all, the number of ordered products will be considered. Once regular order after every 30 days, 20 exclusive products and 10 of normal products will be ordered, the total number of ordered products is 80. If it is an extra order, the ordered products will be based on the requirement of the wholesaler on the previous day ii. Seize the processed resource first, then move the resource, which means order products that move the products from the storage of factory to the storage of distributor. after the process, release the resource.
58 Figure 3.39: DistributorBuy sub-model
iii. counting for the outcome of the distributor. The discount price only used during the regular order and discount event, Otherwise, the order will be the original price. (e) WholesalerBuy sub-model is shown in the Figure 3.40.
Figure 3.40: WholesalerBuy sub-model
i. using UNIF to generate a random discrete index of product. ii. using the N-way by Chance in Decide Module, randomly decides which distributor to order product, the probability is 33.33%. iii. identify the storage of distributor. If the ordered product is not enough, then the order is counting the supply lead time from factory to distributor until wholesaler. If the storage can cover the ordered number, only the supply lead time between the distributor and wholesaler. iv. If an order is overdue more that 24 hour(counting number), then use the UNIF(1,1000)to generate a random discrete number which used to de- cided the refund with the probability 0.1%. v. If an order is delivered successfully, then to add the income, delivery fee and update the total number of distributor sold
59 3.2.4 The simulation results outputted by Arena
Here we displayed the outputted results by Arena of each task in C14 supply chain management and discussed these results we got if is satisfy our expected modelling re- sults. The results are shown in the Table 3.41.
1. Observation Task
Figure 3.41: The Vantai simulation results outputted by Arena
2. Conclusion of modelling results The simulation results outputted by Arena were also met our expectations: the total outcome was also covered by the total income, the profit had a tiny increase as well. The storage of observed distributor periodic changed with 30 days as a round. When the time was closed to regular order, the storage decreasing also becomes slower than before, which was the same symbol that this distributor was starting to order from the factory and trying to send them to downstream, the storage was hardly decreased as before, even some times was increased by order refunded. Besides, after each regular order, the storage of distributor also had a slight increase, the reason to cased this phenomenon was because the two special events as well: the discount events and order refunded, both of these two events were act on the distributor’s storage and cased a rising. Such simulation results were consistent with the design of this model.
60 4 Comparison Results of Simulation Tools
Since the ultimate purpose of this research was to compare the two simulation tools: Anylogic and Arena. We described the comparison results of these two tools in this section. According to the Comparisons metrics explained in the Method Section, these comparison results were divided into five aspects based on the comparison metrics [10, 11, 12]: The capabilities against to discrete-event simulation; Visualization; Simulation efficiency; Result accuracy and Debugging. The following content combined the building processes of the controlled experiments and their simulation results(which were showed in Section 3), to display the comparison of these two simulation tools within these five aspects.
4.1 Tool capabilities with respect to discrete-event simulation
In a supply chain system, a system event represents the change and the forward evolution of the system. These system events can be processed according to the system time. Therefore, the ability to discrete-event simulation when modelling supply chain models is important. Here, we compared Anylogic with Arena according to the discrete- event simulation when modelling the supply chain in the two controlled experiments.
1. The comparison of triggers setting The first thing to simulate the discrete events in the supply chain models was to set the triggers for each discrete event. This comparison was based on the trigger setting when using Anylogic and Arena.
(a) In Anylogic, a trigger of a system event is set by the Event Component. In the Event Component, there are two types of event trigger: One is the model time which activates an event by using system time, and another is calendar date which activates an event by using real time. If the event is triggered in a circular period, the recurrence time can be set as an attribute of this event, to be the interval time between two triggering of this event. Besides, in Any- logic we can also set first occurrence time in Event Component which controls when the event is first triggered. Both the first occurrence time and recur- rence time of one event are not only can be set as numbers but also called by codes in JAVA. For example, to achieve a periodic random interval time, the Math.random() is used in the recurrence time setting. In the following Figure 4.42, the trigger setting of distributor order event is shown.
61 Figure 4.42: the event component of Anylogic
(b) When using Arena, the events only triggered by the Entity which is produced by the Create module. In the Create module, we can set different kinds of method to generate Entities. These generating methods contain Constant, Schedule, Random and Expression. During the two controlled experiments, the Constant is used to simulate an event with periodic change. The random event is simulated through the random integer generated by the UNIF func- tion which is called by Expression. Besides, the Schedule method is like the calendar dates in Anylogic, which can produce Entities by using real time. In Arena, there is only interval time setting, but there is no first occurence time setting. In the following Figure 4.43 the Create setting with the Constant type for distributor order event is shown.
Figure 4.43: the Create module of Arena
2. The comparison of building discrete events After the setting of each trigger, the next step to simulate the discrete events is to build them. Since these discrete events may have complex logic relationships and
62 functions, many statements and conditions should be used. Here the comparison is according to the specific building processes of these statements and conditions within triggered discrete events.
(a) Since Anylogic is developed on JAVA, the functions with complex logic can be constructed directly by coding in JAVA. Such as the production of each fac- tory (Produce function of factory), the order strategy of the distributor (Buy and Sell function of distributor) and the order from the wholesalers (Buy func- tion of wholesaler), they are all implemented by JAVA coding. To implement these events by coding can improve the re-usability and facilitate the mainte- nance work. However, for the user who does not understand JAVA program- ming, it may increase the learning costs before simulation. The Figure 4.44 below represents the discrete events of distributor ordering by Anglogic.
Figure 4.44: simulate The orders from the distributors with Anylogic
63 (b) Arena is a process-oriented simulation tool, the construction of some logical relationships or conditions can only rely on the usage of Assign, Decide and other modules rather than coding. For a simple if statement by coding in Anylogic, the same effect in Arena must be constructed by using the Decide module to push the Entity into different Assign modules. The frequency usage of the Decide and Assign modules for complex logic will make the model appearance very messy and not conducive to maintenance. Furthermore, the version of Arena also limit the capability of building a discrete event: once the number of used modules are more than limitation, then Arena will stop simulating. The user has to simplify the model system to avoid triggering the limitations. (We explained the details of this limitation in 4.2 simulation efficiency) Therefore, Arena is more suitable to simulate the model with a medium-small size or fewer logical relationships. However, Arena is easy to learn, it is more friendly for the user who have no programming experience. The Figure 4.45 below represents the discrete events of distributor ordering by Arena.
Figure 4.45: simulate The orders from distributors with Arena
64 4.2 Visualization
According to the building processes of these two controlled experiments, and the experimental results outputted by Anylogic and Arena, here the overall Visualization of each simulation tool were compared. Besides, we also displayed the pictures of building processes and simulation results to have a further comparison on both building process visualization and results visualization. We evaluate the visualization by considering the style of the GUI, the pixels of images and animations, and whether the structure of the user interface is clear.
1. Comparison of overall visualization Both of these two simulation tools can drag various modules, as well as set anima- tions and pictures. In general, each of the simulation tools is with a high degree of visualization.
(a) In AnyLogic, there are many kinds of fancy pictures, the animations are more vivid. The pixels of both images and animations are relatively higher. Besides, the GUI in AnyLogic is modern. The frame of GUI is designed in a flat graphic style. For the buttons and other components, they are designed as a gradient style. The following Figure 4.46 is the Anglogic user interface.
Figure 4.46: Anylogic UI overall
(b) In Arena, it only provides a few kinds of pictures, both the pictures and the animations are displayed with a bit lower pixels. The GUI style of Arena belongs to the old version of Windows. All the frames, buttons, and other
65 components are designed in an old flat graphic style. The user interface of Arena as shown in the Figure 4.47 below.
Figure 4.47: Arena UI overall
66 2. Comparison of the visualization within building processes During the building processes, an excellent visual design can greatly improve the efficiency of implementation or debugging, the following content showed the com- parison between AnyLogic and Arena that whether the structure of the user inter- face is clear.
(a) AnyLogic is an object-oriented simulation software, all the models or com- ponents can be packaged as independent objects. During the model building, user can set the parameters, variables or functions for each different object. After clicking to open the object, the user can see every detail inside with a clear structure, the parameter, variable, and function own their unique symbol to display. The following Figure 4.48 shows the opened factory model as an object in Anylogic, all the attributes of Factory can be clearly seen.
Figure 4.48: Factory attributes in Anylogic
67 (b) Arena is a process-oriented simulation software without the concept of object, therefore, all the variables must be set in a unified Variables list without any special mark. If the number of variables is huge, the usage of each variable could be ambiguous without a classification, it is unfriendly for maintaining or debugging. The Figure 4.49 below is the setting of used variables when building the Vantai supply chain model by Arena.
Figure 4.49: the variables list of Arena
3. Comparison of results visualization For the output results, both these simulation tools have some modules to guarantee a better display. The comparison of the results visualization was divided by each simulation tool in the following content.
(a) The Label is used to display text by Anylogic, the Bar chart, Pie chart, Stack chart, Plot, Histogram and other statistical charts are also included in Any- logic to display data. The pixels of both images and animations are relatively high, the structure of the displayed result is clear and easy to read. As shown in the Figure 4.50.
68 Figure 4.50: Anylogic Chart
(b) Arena is using the Label and Scoreboard to display text, the Plot and His- togram statistics to display data. Although the pixels of both images and animations are a bit lower, the structure of the displayed result is still clear and easy to read. In addition, Arena outputs an independent system report, even do not to add any statistical component to the modelling project, Arena will still generate this report automatically. The content of the report is to count the generation and destruction of the Entity, the status of queues and resources are also included in this report. The structure of this report is also clear. The following Figure 4.51 and Figure 4.52 are the statistical chart and the automatically generated report by Arena.
Figure 4.51: Arena Chart
69 Figure 4.52: Automatically generated report by Arena
70 4.3 Simulation efficiency
As the explained comparison metric, this comparison of simulation efficiency was also divided into two aspects. the first One is the building efficiency which considered by the optimized features to improves the efficiency for users during their building processes such the smoothness of dragging modules and the assistance when connecting modules. Besides, the limitation of the used version was also included in this comparison. For another aspect, the running efficiency of each simulation tool was compared, including the speed of opening the simulation software and the time cost of executing the simulation. To compare the running efficiency, we used the timer to measure 10 times for both the opening speed and the time cost of executing, record the data, and calculate the average.
1. Building efficiency According to the experiments, here compared the building efficiency of the two simulators, which evaluated by the smoothness of dragging modules and the as- sistance when connecting modules. The limitation of the used version was also included in this comparison.
(a) For AnyLogic, to drag a component is not smooth. Since AnyLogic requires extra resources to call the JRE, it makes a low smoothness and a sense of de- lay for the user when dragging a component. For assistance when connecting components, AnyLogic does not support any assistance function for connec- tion, the components must be connected manually with the low smoothness. When simulating a model with a large number of components, These kinds of building process may cost extra time. For used AnyLogic version, the Per- sonal Learning Edition 8.5.1 as a free version which limitation is few. During the process of building each model by this AnyLogic version, there is no error caused by incomplete function. (b) Since Arena is an individual software, it dose not requires any extra resources. Therefore, the component dragging by Arena is smooth. For assistance when connecting components, Arena supports an intelligent assistance function, these features enhance the efficiency and user experience during this build- ing process. For used Arena version, it is 16.00.00002 Training Evaluation Mode, available as a free version as well. However, this free version of Arena has a functional limitation which affects the number of Entity and other mod- ules. In a complex model with many conditional statements, each statement requires the combination of multiple modules, once the number of used mod- ules have exceeded the limitation, then Arena will stop simulating. To avoid triggering the limitation, the user has to re-select a method to implement this
71 conditional statement with fewer modules or simplify the simulation. This limitation is resulting in many unnecessary modifications. The version and specific limitation of Arena are in the Figure 4.53 and Figure 4.54.
Figure 4.53: The limitation of Arena free version(1)
Figure 4.54: The limitation of Arena free version(2)
72 2. Running efficiency Here, we compared the running efficiency of these two simulation tools. We used AppTimer to count the speed to open the two simulation tools. By using AppTimer to measure each software 10 times, recorded each opening time, and calculated the average value. Besides, we also compared the time cost of executing the model by using the timer in Windows 10 to measure it. We measured each model by 10 times, then recorded each time cost and calculated the average.
(a) The software size of Anylogic is 971MB. Since it is based on JAVA, the JRE must be loaded first, the opening speed is slow. As our record, to open Any- logic has cost 29.13695 seconds on average. The Figure 4.55 and the Table 4.15 are the configure and results of Anylogic opening time by AppTimer.
Figure 4.55: AppTimer configuration for Anylogic
1 2 3 4 5 6 7 8 9 10 Average Opening 29.4178 29.5298 29.7929 28.6597 28.8993 28.9353 29.0914 29.0185 28.8796 29.1452 29.13695
Table 4.15: Anylogic opening time
(b) The size for Arena is 863MB, since Arena is developed as an original software which is independent of any other program or environment, the speed to open the software is relatively faster. We also used AppTimer to open Arena 10 times (Figure 4.56), recorded the results and calculated the average. As the record shown in the Table 4.16, it only takes 1.54101 seconds on average.
73 Figure 4.56: AppTimer configuration for Arena
1 2 3 4 5 6 7 8 9 10 Average Opening 1.5087 1.3918 1.6520 1.5841 1.6301 1.4109 1.5659 1.5935 1.5624 1.5107 1.54101
Table 4.16: Arena opening time
(c) Anylogic has to open a new window first when executing a model, after this new window is opened, the user needs to manually click again to start running, besides, the JAVA-based compilation and initialization also require extra time. These factors lower the overall running efficiency. As our records by Windows timer, Anylogic spent 47.969 seconds to finish simulate C14 supply chain management; 72.066 seconds for Vantai supply chain model from click to begin simulation until when the simulation is over. The Figure 4.57 below is the Anylogic operating screen where to start running the models. The records of the running time on each supply chain models by Anylogic are also shown in the Table 4.17.
Figure 4.57: Anylogic operating screen
74 1 2 3 4 5 6 7 8 9 10 Average C14 48.73 47.28 47.32 47.91 49.42 48.23 48.01 46.89 47.02 48.88 47.969 Vantai 70.21 72.92 72.32 71.96 72.82 71.87 72.82 70.98 73.21 71.53 72.066
Table 4.17: Anylogic running time
(d) Arena is one-click running: click the start button then the model can be op- erated immediately. This running efficiency is relatively high. We used Win- dows timer to test its running time. It took 19.445 seconds to run C14 on average and 20.516 seconds for Vantai. The following figure 4.58 and table 4.18 showed the Arena operating screen and the time records for running these two models by Arena.
Figure 4.58: Arena operating screen
1 2 3 4 5 6 7 8 9 10 Average C14 19.82 19.52 19.98 19.55 19.27 18.89 19.42 19.72 19.33 18.95 19.445 Vantai 20.39 20.52 19.82 20.87 20.73 200.55 21.01 20.83 19.92 20.72 20.516
Table 4.18: Arena running time
75 4.4 Simulation accuracy
By the obtained simulation results in each controlled experiment that showed in Sec- tion 3, this comparison conclusion is obvious: for the same supply chain model, the sim- ulation results of Anylogic and Arena are similar, which shows that the overall simulation accuracy of the two simulation tools —- Anylogic and Arena —- are almost the same. However, by comparing the simulation results of each supply chain model, we found a difference: no matter which task it is, about the number of the product delivered by the distributor, Arena’s output result is always greater than AnyLogic’s. The Figure 4.59 and Figure 4.60 below show this difference between Anylogic and Arena.
Figure 4.59: The order comparison of C14 between Anylogic and Arena
Figure 4.60: The order comparison of Vantai between Anylogic and Arena
The reason for this difference is: In both two supply chain models, wholesalers’ order that sending to the distributor is with a random interval time. To simulate this, we used Math.random() in AnyLogic and UNIF() in Arena to generate the random intervals.
76 The principles to generate random integer numbers of these two simulation tools may be different, which may cause this difference. Therefore, we added an extra small test to have a further comparison of the accuracy of generating a random integer number by these two simulation tools.
1. This small test is simple: using Anylogic and Arena to generte a random integer number within a range from 1 to 150 and repeat 10000 times, then calculating the average.
(a) The method of Anylogic to generate a random integer number is based on JAVAmethod Math.random (), the specific implementation is (int) (Math.random () * 149) + 1. The average result is 74 shown in the Figure 4.61.
Figure 4.61: The result of random integer result by Anylogic
(b) Arena uses the UNIF owned by itself, to generate a random integer number from 1 to 150, implement as UNIT (1, 150). The average result is 75.43 shown in the Figure 4.62.
Figure 4.62: The result of random integer by Arena
77 4.5 Debugging
As one important comparison metric, here to compare the overall debug abilities of Anylogic and Arena according to their error reporting and debugging efficiency during the models building processes of the two controlled experiments.
1. If any error occurs during the simulation process of Anylogic, the system reports the detailed error information and locates to the specific error position, in order to help User quickly find the error and fix it. The following Figure 4.63 shows the error reporting by Anylogic during debugging.
Figure 4.63: Error report of Anylogic
2. If any error occurs when using Arena, the system can report a detailed error in- formation as well, but in most cases, the system cannot accurately locate the error position, user can only find the approximate position through the error report then conduct a manually further screening. If the simulation model is large or with com- plex logical conditions, debugging by Arena would be a pain. The following Figure 4.64 shows the error reporting by Arena.
Figure 4.64: Error report of Arena
78 5 Analysis
In this section, we combined all the comparison results from the previous section to conduct a comprehensive analysis of AnyLogic and Arena. Subsequently, according to the comparison metrics, each comparison aspect was analyzed and discussed shortly. Besides, a feature summary of Arena and Anylogic is provided in the Table 5.19.
Feature Arena AnyLogic discrete-event simulation average excellent visualization average excellent efficiency excellent average accuracy excellent excellent debugging poor excellent
Table 5.19: Feature summary of Arena and Anylogic.
Anylogic is an object-oriented simulation tool developed based on JAVA. In Any- logic, each agent is an independent object, the attributes such as Name or Variable(name, number, etc.) and the function (order, delivery, etc.) can be added into an agent, since the construction of these attributes and function inherits from JAVA syntax, the types of Variable are Integer, String, Boolean, Float, also consistent with JAVA. The evolution process of the system is based on the attributes and function of one agent or the mutual transfer between different agents. The data structure of Anylogic is also diverse, support- ing Array, ArrayList, HashMap, etc., it basically covering all the data structure of JAVA. Generally, this simulation software is friendly for the users who are proficient in JAVA, they can quickly start to build the models after short learning. Further, Anylogic owned many inbuilt modules with packaged attribute or function. During the building processes of these controlled experiments, the Flow module was used to represent the increase of inventory and the flow of products. For Arena, it is a unique simulation tool which is more process-oriented. The prin- ciple of Arena is that the Create module creates a new Entity first, this Entity reaches to another module according to the route and makes the function or attribute in this module takes effect, then this Entity goes to the next new module and so on. After this Entity went through all the modules, it is destroyed in the Dispose module in the end. Through this principle, the entire project system is operated. However, precisely due to this principle, one resource can only be operated by one Entities at once, the allocation of Multi-process resource is strictly limited. For example, in these supply chain models of two controlled experiments, when the upstream factory sent the ordered products to the downstream dis- tributor, these ordered products should with the multiple amounts and types. Using Arena for simulation, the Regulators are set within a Factory Tank module to represent the de-
79 crease and flowing of the factory’s products. Since one regulator can only be operated by one Entity at once, to simulate the multiple amounts and types of products were sent at one delivery, the Seize and Release must be used additionally: Before one Entity operates one resource such as a Regulator, this Entity must Seize this resource, the other Entities that also need to operate this resource have to wait, until the previous Entity finished its operation and release this resource, then the next Entity can Seize this resource again in order to operate, and so on. Therefore, the concepts of Seize and Release are important, but for a beginner, it may be difficult to understand these concepts. In term of the capabilities to discrete-event simulation, the event component of Any- logic can easily set the trigger for the discrete events, even set up some simple but nec- essary operations against the discrete events. To build the event, Anylogic can use JAVA codes to achieve more complex logical conditions of event, for the larger models with complex logic conditions, using Anylogic to build the simulation is easier by coding. But for Arena, the situation is different. In the usage of Arena, the trigger of any discrete event can only be expressed by the Create module to create an Entity according to the demand of the event, the specific action must achieved by the cooperation between different mod- ules. This feature is also reflected on the building of the discrete event, when processing the complex logical conditions in these events, Arena can only use the Entity to achieve the Assign, Decide and other object modules: By the Assign module to perform the sys- tem action such as the increase or decrease of variables, using the Decide module as a conditional decide, then the Entity effects on the object module. The entire processing flow can be seen as“what to do" with "which condition" on "which things". Compared with the codes in Anylogic, this process in Arena is meticulous and complicated. For the comparison of visualization, the overall visualization of both AnyLogic and Arena is relatively complete. For the displayed result, Anylogic has more statistical chart components such as Pie chart and Bar chart than Arena, Arena automatically generates a detailed report that Anylogic does not have. In the presentation of the results, these two simulation tools have their own advantages. However, in terms of GUI style, the GUI of Anylogic is modern. The frame of GUI is designed in a flat graphic style. For the buttons and other components, they are designed as a gradient style. and the components of image or animation in AnyLogic have higher pixels. The GUI style of Arena is like the old version of Windows. All the frames, buttons, and other components are designed in an old flat graphic style, and the image or animation components have lower pixels. Besides, in AnyLogic, The visualization structure of the object’s attributes is very clear. But for Arena, the unified Variables list is not friendly to read. For the Simulation efficiency, since the habits and preferences of each user are dif- ferent, it is difficult to compare the building efficiency uniformly. In general, Anylogic as one object-oriented simulation software, it has a good performance in the simulation of
80 the large models with a complex structure, and it is suitable for the users with program- ming experience; Arena is more convenient for a middle-small size simulation, it is also easier for the beginners who are not familiar with object-oriented. In the aspect of running efficiency, with the same device, Arena is always faster whether to open the software or run the model. The reason is that Anylogic is developed based on JAVA, the software is relatively larger, and it takes up more device resources to open itself. When running the simulation, Anylogic even needs to call the JRE and compile. However, Anylogic has an accelerating function for simulation, which can speed up to two times even three times faster if the device performance supports it. For the results of the two controlled experiments, these two simulation tools have almost the same high-quality simulation accuracy. After the small test, we found maybe Arena is more refined with only a tiny advantage. Although the simulation effect is the same even slightly advanced as Anylogic, the debugging of Arena is truly difficult. With- out a detailed error report, the user has to analyze the entire simulation process again and calculate the use of various resources during each debugging.
81 6 Discussion
In this section, we discuss the comparison results of the simulation tools, our re- search objectives, and how our results are related to results from other studies. As two professional simulation tools, both Anylogic and Arena have met the ba- sic simulation requirements when simulating the supply chain models: the ability to discrete-event simulation, good visualization and simulation efficiency, high-quality ac- curacy. However, the usability against discrete-event simulation and debugging of these two simulation tools have disparities because the simulation building processes of them are different, which caused by the characteristics of the two simulation tools. The first objective "Simulate the C14 supply Chain management and Vantai supply chain model by both Anylogic and Arena to obtain their building processes and simula- tion results" is answered by the building process of each simulation model and outputted simulation results from Implement Section. Although these processes and results are the answer of the first objective, they are also the basis for the simulation tools comparison, therefore, we described them in the Implement Section as the process to achieve the entire experiment, which is aimed at Comparison as the ultimate goal. The second objective is" Compare Anylogic and Arena according to the obtained building processes and simulation results from each supply chain model". As the final objective of this research, it answered by the comparison results in Result Section, these comparison results can be divided into 5 aspects by the comparison metrics as: the capa- bility of discrete-event simulation; Visualization; simulation efficiency; simulation accu- racy and debugging. Further, during the Analysis Section, we analysis not only for the difference between these two simulation tools overall but also according to each specific comparison metrics. Thus, the second objective is also answered. Before starting our research, we first have studied from other researchers [4, 18] for the applicability of discrete-event simulation tools to the solution of particular problems, then we have learned the possibility of the compared simulation tools to conduct discrete- event simulation [5, 19]. We are also inspired by other researches [10, 11, 12] when we designed our comparison metrics. In our first controlled experiment, we used the C14 supply chain management [9] as the model template and considered the simulation results from other researches [15, 16] as our expected simulation results. For the Vantai supply chain model in the second controlled experiment, Since the data of this model is provided by China Vantai Company, there is no relevant academic support temporarily. Further- more, during the building processes of these two supply chain models by both Anylogic and Arena, we also referred our building processes with the author Ivanov, Dmitry [3] and Bekker, James and Guittet-Remaud, Sylvain [8].
82 7 Conclusion
At present, there are diverse simulation tools in the technology market. These sim- ulation tools are used in different fields, their simulation capabilities are various when targeting different types of models. In this study, we select two simulation tools: Any- logic and Arena, which support discrete-event simulation, comparing their capabilities in simulating the supply chain models. In order to realize this purpose, We divided this entire study into two stages. The objective of the first stage is to simulate the two sup- ply chain model(C14 supply Chain management and Vantai supply chain model) by both Anylogic and Arena in order to obtain their building processes and simulation results. The objective of the second stage is to compare Anylogic and Arena, based on the obtained building processes and the outputted simulation results from each supply chain model, these simulation tools are compared.
1. With respect to Objective O1, we design two sets of controlled experiments, For the first controlled experiment, we consider C14 supply chain management as one experimental objective; the Vantai supply chain model as another experimental ob- jective for the second controlled experiment. Using Anylogic and Arena as the controlled variables to simulate each model in these controlled experiments. The obtained building processes and simulation results are observed as dependent vari- ables and to be compared during next stage.
2. Regarding Objective O2, we define the comparison metrics of this research as five aspects: the capabilities to discrete-event simulation; visualization; Simulation ef- ficiency; simulation accuracy and debugging. Then, we combine the building pro- cesses and simulation results in the controlled experiments to represent each simu- lation tool, comparing them within these five aspects.
As the final result of this research, we display the comparison results and analysis them: During the simulations of the two supply chain models, both Anylogic and Arena have met the basic simulation requirements within most of the aspects. However, the usability against discrete-event simulation and debugging of these two simulation tools have disparities. It is because the simulation building processes of them are different, which caused by the characteristics of the two simulation tools—- Anylogic is Object- oriented can support JAVA codes but Arena is process-oriented without any coding. Although we have tried the best to perfect this research, there are still some contents that can be optimized: Firstly, the Vantai supply chain model of the second controlled experiment could be more completed, we look forward to obtaining more business data to enrich this model. Besides, both the comparison of the capabilities to discrete-event
83 simulation and the display of this comparison results could have a comprehensive method. We shall keep studying for more advanced comparison and expression.
7.1 Future work
After this research, We find that this study area is still extensive. We look forward to orienting more different simulation tools and comparing their simulation capabilities in various fields. In addition, since this study is end at comparing these two selected simu- lation tools, we expect to be provided with ability and time for giving the corresponding optimizations based on these comparison results in the future.
84 References
[1] G. C. Stevens, “Integrating the supply chain,” international Journal of physical dis- tribution & Materials Management, 1989.
[2] D.-J. Van Der Zee and J. G. Van Der Vorst, “A modeling framework for supply chain simulation: opportunities for improved decision making,” Decision sciences, vol. 36, no. 1, pp. 65–95, 2005.
[3] D. Ivanov, “Operations and supply chain simulation with anylogic,” Berlin: Berlin School of Economics and Law, 2017.
[4] D. Perez, S. Memeti, and S. Pllana, “A simulation study of a smart living IoT so- lution for remote elderly care,” in 2018 Third International Conference on Fog and Mobile Edge Computing (FMEC), 2018, pp. 227–232.
[5] V. Mokshin, A. Kirpichnikov, and A. Soiko, “Simulation and optimization of the cargo terminal in the anylogic environment,” in Journal of Physics: Conference Series, vol. 1368, no. 4. IOP Publishing, 2019, p. 042082.
[6] J. Banks, J. Carson, B. L. Nelson, and D. Nicol, Discrete-Event System Simulation (4th Edition), 4th ed. Prentice Hall, Dec. 2004.
[7] N. Matloff, “Introduction to discrete-event simulation and the simpy language,” Davis, CA. Dept of Computer Science. University of California at Davis. Retrieved on August, vol. 2, no. 2009, p. 3, 2008.
[8] J. Bekker and S. Guittet-Remaud, “Simulation in supply chains: An arena basis,” South African Journal of Industrial Engineering, vol. 11, no. 1, pp. 1–15, 2000.
[9] S. M. Taubock, “C14 Supply Chain Management – Definition,” Simulation News Europe (SNE), no. 32/33, pp. 42–43, November 2001.
[10] F. Breitenecker, S. Wassertheurer, N. Popper, and G. Zauner, “Benchmarking of simulation systems–the argesim comparisons,” in First Asia International Confer- ence on Modelling Simulation (AMS’07), 2007, pp. 568–573.
[11] A. Nikakhtar, K. Y. Wong, M. H. Zarei, and A. Memari, “Comparison of two sim- ulation software for modeling a construction process,” in 2011 Third International Conference on Computational Intelligence, Modelling Simulation, 2011, pp. 200– 205.
85 [12] M. Jadric, M. Cukusic, and A. Bralic, “Comparison of discrete event simulation tools in an academic environment,” Croatian Operational Research Review, vol. 5, pp. 203–219, 12 2014.
[13] Discrete event modeling and multimethod simulation, The AnyLogic Company, https://www.anylogic.com/use-of-simulation/discrete-event-simulation/.
[14] Discrete Event Simulation Software, Arena Simulation Software, https://www.arenasimulation.com/what-is-simulation/discrete-event-simulation- software/.
[15] M. Gyimesi and J. Kropf, “C14 Supply Chain Management - AnyLogic 4.0,” Simu- lation News Europe (SNE), no. 35/36, p. 85, December 2002.
[16] M. Wastian and S. Reichl, “An Object-oriented Approach to ARGESIM Benchmark C14 ’Supply Chain’ using MATLAB,” Simulation News Europe (SNE), no. 1, pp. 35–38, March 2018.
[17] M. A. Müllerburg, “The role of debugging within software engineering environ- ments,” in Proceedings of the symposium on High-level debugging, 1983, pp. 81–90.
[18] T. Fahringer, S. Pllana, and J. Testori, “Teuta: Tool support for performance model- ing of distributed and parallel applications,” in Computational Science - ICCS 2004, M. Bubak, G. D. van Albada, P. M. A. Sloot, and J. Dongarra, Eds. Berlin, Heidel- berg: Springer Berlin Heidelberg, 2004, pp. 456–463.
[19] A. S. Hashemi and J. Sattarvand, “Application of arena simulation software for eval- uation of open pit mining transportation systems–a case study,” in Proceedings of the 12th International Symposium Continuous Surface Mining-Aachen 2014. Springer, 2015, pp. 213–224.
86 A Appendix
All our simulations progress have already been shown in the Implementation Section, so here we only displayed the small test of random integer numbers. This small test was used in the Result Section where to compare the simulation accuracy of Anylogic (Figure 1.65) and Arena (Figure 1.66).
Figure 1.65: Anylogic random test code
Figure 1.66: Arena random test code
A