Bachelor Degree Project A comparison of simulation tools for …1453069/FULLTEXT01.pdf · 2020. 7....
Transcript of Bachelor Degree Project A comparison of simulation tools for …1453069/FULLTEXT01.pdf · 2020. 7....
Author: Shishengxiong Zhong and
Jinzhe Zhao
Supervisor: Sabri Pllana
Semester: VT 2020
Subject: Computer Science
Bachelor Degree Project
A comparison of simulation tools
for supply chain management
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 11.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 92.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 283.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 614.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 837.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 descriptionThis 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 F4P1 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 F4D1 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-eventsHere, 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-eventsSince 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<Product>) the set of 12 products
firstBuyCount (Integer) Number of products purchased for the first time
nextBuyCount (Integer) The number of products purchased after
transferFee (Double) Delivery costs (EUR / order)
storageFee (Double) storage costs(EUR / order)
Parameter transferTime (Double []) Transport time with each factory (minutes)
isFirstBuy (Boolean) if is the first purchase
lackProductList (HashMap<String, Integer>) lack of stock list (product name: the amount that lacked )
totalFee (Double) Total cost (Euro, delivery cost + storage costs)
Variable totalSell (Integer) Total sale
buy () Place an order to the factory
sell (int key, int buyCount, Wholesaler wholesaler) Place an order to the distributor
getStorage () Calculate total storage
Function addStorageFee () Increase storage costs
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
ProductList (ArrayList<Product>) the set of 12 products
Distributor Collection factoryList (ArrayList<Factory>) list of available factories
lastBuyTime (Integer) last order timebuyCount (Integer) amount of order
buyIntervalRange (String) interval range of order
Variable buyInterval (Integer) order interval
Function buy () order from distributor
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
Wholesaler Collection ProductList (ArrayList<Product>) the set of 12 products
Table 3.10: AnyLogic simulation agents for C14.
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<String, Integer>, when the
order from the wholesalers can not be fulfilled, distributor records the
number and type of ordered(lack) product.
viii. The variable totalFee is accounting all the delivery fee and storage cost.
ix. The variable totalSell is counting total amount of products that sell by
distributor.
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<String, Integer>, when the
order from the wholesalers can not be fulfilled, distributor records the
number and type of ordered(lack) product.
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 AverageOpening 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 AverageOpening 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 AverageC14 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 AverageC14 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
JAVA method 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 AnyLogicdiscrete-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