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

http://https://www.sne-journal.org/fileadmin/user_upload_sne/benchmarks/C14/C14-definition.pdf/

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




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




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



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



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 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













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













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


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


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


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



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.



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



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


sults. The results are shown in the Table 3.41.

1. Observation Task

Figure 3.41: The Vantai simulation results outputted by Arena


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

bachelor degree project a comparison of simulation tools for …1453069/fulltext01.pdf · 2020. 7....

Documents