Content uploaded by Lorenzo Tiacci

Author content

All content in this area was uploaded by Lorenzo Tiacci on Sep 15, 2014

Content may be subject to copyright.

The Assembly Line Simulator Project: modeling U-shaped,

un-paced, mixed model assembly lines

Lorenzo Tiacci*

*Department of Engineering, University of Perugia, via Duranti 93, 06125, Perugia – Italy

(lorenzo.tiacci@unipg.it)

Abstract: To evaluate performances of U-shaped un-paced mixed model assembly line may be complicated. This

complication is a result of blockage and starvation caused by the arrival of different models to the line, having

different assembly time requirements at each station. Considering the throughput as the main operational design

objective, the effects of these phenomena on line throughput are very difficult to evaluate. Unfortunately, its

evaluation is fundamental in almost all procedures and algorithms developed to solve U-MALBP (U-shaped Mixed-

model Assembly Line Balancing Problem), since the estimation of objective functions that includes performance

indicators is often required. The only practical method to accurately evaluate throughput is a simulation study, which

is very time consuming and hard to perform. For this reason, instead, various performance measures, not simulation

based, have been presented in literature in order to evaluate and compare design alternatives. Unfortunately, these

performance measures are often poorly correlated to the real value of the throughput when the complexity of the

line increases. The aim of the Assembly Line Simulator Project is to overcome the limit of using performance

measures instead of simulated throughput, by developing a parametric simulator for mixed model lines that can

quickly simulate different line configurations and can be used iteratively in algorithms and procedures. In the paper,

the last version of the simulator, designed for U-shaped lines, is presented and tested.

Keywords: asynchronous lines, un-paced lines, discrete event simulation, object oriented simulation.

1 Introduction

The Assembly Line Balancing Problem (ALBP) has been

one of the most studied problems in the literature related

to industrial engineering. It consists in assigning tasks to

workstations, while optimising one or more objectives

without violating any restriction imposed on the line (e.g.

precedence constraints among tasks). The basic version of

the general problem is the so-called Simple Assembly Line

Balancing Problem (SALBP). Its main characteristics are:

serial line lay out with a certain number of stations, paced

line with fixed cycle time, only one product is assembled,

task times are deterministic and all stations are equally

equipped with respect to machines and workers. For an

overview of exact methods and heuristics developed to

solve the SALBP see (Scholl and Becker, 2006).

The assumptions of SALBP are very restricting with

respect to real-world assembly line systems. Therefore,

researchers have recently intensified their efforts to

identify, formulate and solve more realistic problems, that

are embraced by the term generalized assembly line

balancing problem (GALBP). For example, in today’s

time of ever more personalized products, assembly lines

assembling just one product are extremely rare. On the

contrary, several products (models) are often

manufactured on the same line. The mixed-model

assembly line balancing problem (MALBP) is a GALBP

that address this issue, in which units of different models

can be produced in an arbitrarily intermixed sequence. For

a comprehensive classification of other different possible

features of the GALBP see (Becker and Scholl, 2006).

As the number of features that try to capture the

complexity of real cases increases (e.g. mixed models,

sequencing policies, parallel workstations, buffers,

stochastic task times, U-shaped lines) evaluating the

performance of an assembly line become more

complicated. Exact analytical methods for evaluating

system throughput are not available. Thus, algorithms that

have been developed to solve the problem, and that need

to evaluate line performances in order to compare design

alternatives, use some ‘measures’ of the throughput,

represented by parameters that are easily calculable (once

the line configuration and the tasks assignments are given)

and that should be correlated to the real line throughput.

The delicacy of this issue has been properly outlined by

(Bukchin, 1998). He argued that the only practical method

to accurately evaluate throughput is a simulation study,

which is very time consuming and hard to perform, and

that for this reason, instead, various performance

measures are usually used in order to evaluate and

compare design alternatives. To find measures that can be

correlated with the throughput, he observes for example

that the allocation of assembly times to stations is

characterized by two types of variability: a ‘Model

Variability’ (variability of assembly times of a certain

model assigned to different stations) and a ‘Station

Variability’ (variability of assembly times of different

models assigned to a specific workstations). These two

types of variability are often considered correlated to

blockage and starvation, and, as a consequence, to high

idle times within stations and, eventually, to low

throughput. However, the correlation of these (and any

other) performance measures with the objective in

question (i.e. the throughput) has to be verified through a

simulation study.

Unfortunately, results presented in literature show that the

correlation between measures proposed by researchers

and the real throughput is often poor, and rapidly

decreases when the number of stations in the line

increases. Furthermore, the discrepancy between measure

and throughput is in general expected to increase with the

complexity of the line (e.g. parallel stations, buffers within

workstations) and with the number of aspects of the real

world that are considered into the model (e.g. stochastic

tasks times). Thus, the risk in this research field is to assist

to the continuous development of sophisticated

algorithms that try to take into consideration several

aspects of real problems, but that point toward a wrong

objective, because they are ‘driven’ by measures not

correlated to the real objective.

The only way to properly evaluate the throughput would

be, as mentioned, to build a simulation model of the line,

and to perform some simulation runs. This approach is

very time consuming because includes the time needed for

building the model for each (different) line configuration,

and to execute simulation run(s). Thus, it is usually

adopted only to analyze the final solution obtained by an

algorithm, but cannot be utilized in the very process of

finding solutions, when many evaluations of different lines

configurations have to be done (consider for example how

many times a fitness function has to be evaluated by a

genetic algorithm).

The aim of the Assembly Line Simulator Project is to

show how to overcome the limit of using performance

measures instead of simulated throughput, by using a

parametric simulator for mixed model lines, able to model

and simulate different solutions in such a quickly way that

it can be used iteratively in algorithms and procedures. At

this scope, a Java based event oriented simulator, named

ALS (“Assembly line simulator”) has been developed.

The first version (v.1.0) of ALS has been presented in

Tiacci (2012), and provided the possibility to model only

straight lines. Relevant breakthrough have already been

obtained, with respect of traditional approaches, by using

ALS coupled to genetic algorithms to solve the MALBP

(see Tiacci (2014a)).

The encouraging results achieved for straight lines

suggested to extend the same approach to other shapes of

the line. In this paper a new version of ALS (v.2.1), which

provides the possibility to model U-Shaped mixed models

un-paced lines, is presented.

U-Shaped lines have been addressed for the first time in

literature by Miltenburg and Wijngaard (1994), that

defined the U-line balancing problem for a single model,

while Sparling and Miltenburg (1998) introduced the

Mixed-model U-shaped Assembly Line Balancing

Problem (U-MALBP). This type of line configuration had

been observed in Japanese manufacturing companies. The

important characteristic of those systems is that

multiskilled workers perform various tasks of different

stations along the production line. This feature allows

assigning tasks both from the beginning and the end of

the precedence diagram to the same stations. In terms of

the solution of the line-balancing problem, this implies

that the solution of the U-type configuration dominates

the solution of the traditional straight-line configuration,

due to the reduced precedence relations (Erel et al., 2001).

On the other hand, U-shape introduces an extra

complexity for which concerns the throughput evaluation

of an un-paced line. This is due to the fact that when an

operator works on one side of the line, cannot work

simultaneously on a load that is waiting on the other side.

This intrinsic feature represents an extra cause (together

with mixed model production and stochastic task times)

of blocking and starvation phenomena, which are very

difficult to predict and to quantify without performing a

simulation study. These considerations make relevant the

development of the U-shaped version of ALS, which is

presented in this paper.

The paper is organized as follows. In Section 2 the

conceptual model of unpaced U-shaped lines is described.

In Section 3 the features of the simulation model related

to ALS 2.1 are described. In Section 4 ALS performances

are evaluated on a test-bed instance, by comparing

execution times of ALS with those of a simulation model

for U-shaped lines built with Arena. In Section 5

conclusions are drawn.

2 Unpaced U-Shaped Lines - The conceptual model

Notation:

i task index (i = 0, ..., n-1)

j model index (j = 0, ..., m-1)

k work centre index (k = 0, ..., p-1)

A set of n tasks (numbered with i = 0,…, n-1) has to be

performed in the line in order to complete each product.

Because we are dealing with mixed model lines, the

number of models (types of product) to be assembled can

be higher than one, and it is indicated by m (numbered

with j = 0, …, m-1). Input data are thus represented by an

n x m matrix tij whose elements represent the average

completion time of task i on model type j.

In U-shaped assembly lines, stations can be arranged so

that two loads at different positions on the line can be

handled. As depicted in Figure 1c, a WorkCentre (WC)

may consist of one worker and two WorkStations (WSs),

each one at two segments of the line. In this type of WCs,

named ‘crossover’ WCs (WC#0 and WC#2 if Fig.4c),

loads can be processed alternatively into one of the two

WSs (WS#0 and WS#5 in WC#0, and WS#2 and WS#4

in WC#2). So the difference to the straight line is that a

WCk can contain not only tasks whose predecessors are

assigned to one of the WC# 0, . . . ,k, but also tasks

whose predecessors will be finished until the product

returns to station k for the second time.

It is noteworthy that every solution feasible for straight

lines is feasible for an U-line, because an U-line does not

need to include crossover WC. However, U-shaped lines

provides much more possibilities of combining tasks to

WCs, and this implies increasing possibilities to find better

solutions with respect to straight lines.

In the current implementation, no buffers are assumed

between WCs, and no form of paralleling is considered.

WSs are ordered following the visiting order of a load

(WS#0 … WS#N). In Figure 1c loads enter in WS#0 and

exit from WS#5.

The line is asynchronous, that is as well as blockage and

starvation are possible. Two types of resources are used in

this conceptual model: WS and worker. A WS is busy

when a load physically occupies the WS, while when it is

free it is able to receive another load from the preceding

WS. A worker is busy when is performing the tasks on a

load in a WS.

Each time a worker finishes its work on a load, he is

released, and tries to pass the load to the next WS. If there

is place in the next WS, the current WS is released; the

load passes to the next WS, and will be served as soon as

the worker of the next WC is not busy.

Each time a WS is released (i.e. a load move to the next

WS), if there is a load in the preceding WS that is waiting

to pass to the next WS (because it has already been

worked in the preceding WS), the load passes to the

current WS: the preceding WS is released, and the current

WS is seized.

If a worker finishes its work on a load while the

subsequent WS is still occupied by another load, the load

cannot move on, and remains in the current WS, keeping

it busy. The WS will be released (i.e. will be able to receive

another load) only when the load leaves the WS, i.e. when

the next WS is released. Even if the load cannot move on,

the worker is released, being able to work on a load in the

WS at the other side of the line (in case of a cross-over

WC).

It is possible that when a worker is released in a crossover

WC, two loads are claiming at the same time the worker,

waiting to be worked in the two opposite WSs. In this

case the worker will give the precedence to the load that

had earlier finished to be processed in the preceding WS.

Models enters the line with a fixed sequence, able to

comply with the demand proportion for each model. Set-

up times between models are considered negligible.

3 The Assembling Line Simulator (ALS)

ALS is a parametric event-oriented simulator, developed

in Java, capable to immediately calculate the average cycle

time of a U-shaped line by simply receiving as inputs the

task times durations, the line configuration (number of

WCs, of tasks assigned to each WC side), and the

sequence of models entering the line. Thanks to its object-

oriented architecture, different lines configurations can be

created by the mean of very simple array representations,

so that the time required for building the model is zeroed.

ALS has been developed following an event oriented

paradigm: the simulation run is performed only by events

scheduling, rescheduling, cancelling etc.; by avoiding the

use of ‘processes’, execution times are kept very low with

respect to the analogous process-oriented version (Tiacci

and Saetta, 2007), arriving to outperform Arena, as it will

be shown in Section 5.

In the following, the description of how it is possible to

model and simulate an un-paced U-Shaped mixed model

line through ALS is given.

3.1 Task times

The matrix tij of completion times of task i for model j is

represented by an array of real numbers double[][]

tTimes. The 2 x 13 matrix depicted in Table 1 represents

the case in which 2 types of products (models) have to be

assembled; each model requires 13 tasks to be completed.

For example the average task time of task #4 of model #0

is equal to 5 time units. It is noteworthy that if the

completion of a model does not require the execution of a

certain task, this would result in a 0 in the corresponding

matrix element.

t#i

m#0

m#1

0

6.0

4.0

1

6.0

7.0

2

8.0

4.0

3

7.0

5.0

4

5.0

6.0

5

10.0

12.0

6

15.0

5.0

7

13.0

7.0

8

8.0

12.0

9

9.0

12.0

10

8.0

10.0

11

8.0

12.0

12

7.0

12.0

Table 1. Task times (time units)

tij

3.2 Representation of a line configuration

A ‘line configuration’ represents a specific solution of the

U-MALBP, and is characterized by the following

information:

• the total number of WC in the line;

• the number of WS in each WC;

• how many and which tasks are assigned to each WC

• which tasks in a WC are performed in its front and its

return side

The line configuration can be represented by a two-

dimensional array lckz (k = 0, …, p-1), where p (the

number of rows) represents the total number of WC in

the line. Each row represents a WC.

The first element of each row, named uk, is the number of

tasks that will be performed on the front side of WC#k.

The second element represents the size of the buffer

placed before the WC. In the current implementation of

ALS no buffers are allowed, so this value is always

considered equal to 0. The subsequent elements represent

the tasks assigned to the WC. Note that rows do not

necessarily contain the same number of elements.

In Figure 1 it is shown an example of a line configuration

in its tabular form (a), array form (b) and graphical form

(c). Tasks assigned to WC#0 are {0, 2, 11, 12}, and u0 = 2

means that the first two tasks (0, 2) are done in the front

side (WS#0) of the WC, while the remaining tasks (11, 12)

are done in the return side (WS#5). Note that if uk = 0, all

the assigned tasks will be performed in the return side. If

uk is equal to (or higher than) the number of tasks

assigned to the WC, all tasks will be performed in the

front side.

WC#k

u

k

Buffer size

(ignored)

Tasks

assigned

0

2

0

0, 2, 11, 12

1

3

0

1, 3, 4

2

1

0

5, 9, 10

3

3

0

6, 7, 8

a. tabular representation of a line configuration

lc = { { 2, 0, 0, 2, 11, 12 },

{ 3, 0, 1, 3, 4 },

{ 1, 0, 7, 9, 10 }

{ 3, 0, 6, 7, 8 } }

b. array representation of a line configuration

0, 2

work centre

workstation

operator

6, 7, 8

11, 12

1, 3, 4

5

9, 10

WC#0

WC#1

WC#2

WC#3

WS#0

WS#1

WS#2

WS#3

WS#4

WS#5

Tasks assigned

c. graphical representation of a line configuration

Figure 1: Line configuration representations

3.3 Model sequencing

The simulator allows two ways to define the model

sequencing, depending on the value assumed by the

boolean variabale named randomSeq.

If randomSeq is false, the input sequence of models is

deterministic, and it is represented by an array of integers

s. For example, in case of two models (#0 and #1) the

array s = {0,0,1,1} means that after two model#0, two

model#1 will be assembled, and so on. s = {0,1,0,1}

means that the two models are alternated. The sequence

of numbers in the array (whose length can be arbitrarily

chosen) is taken as reference for the generation of

different model types entering the line.

If randomSeq is true, the sequence of models entering the

line is random, but respects a determined demand

proportion among different model types (to simulate a JIT

environment). In this case the array s has to contain a

number of elements equal to the number of models. Each

sj value specifies the demand proportion of model j with

respect to total demand, so that each time a new load is

created, the probability that its model type is j is equal to:

j

jj

j

s

P= s

∑

3.4 Stochastic task times

In order to take into account another important feature of

real assembly lines, stochastic task times have to be

considered. The literature on stochastic ALBP is ample,

and most authors assume the task times to be

independent normal variates, which is considered to be

realistic in most cases of human work (Whilhem, 1987). In

this first version of ALS, task times duration can be

modelled, through the definition of the string distType,

in three ways: deterministic (distType=”DET”), normally

distributed (distType=”NORM”), and exponentially

distributed (distType=”EXP”). Deterministic task times

are exactly defined by the matrix tij. If task times are

normally distributed, the standard deviation σij of the

completion time of task i for model j is taken equal to its

mean value (tij) multiplied by a coefficient of variation

double cv (σij = cv . tij). If task times are exponentially

distributed, the density function of completion time is

characterized by the single parameter tij (equal to the mean

value and the standard deviation).

3.5 Simulation length and warm-up period

The simulation length (simLength) can be indicated or in

time units (the same as tij) or in a number of loads that

have to be completed. This depends on the value of the

binary variable simType; if simType = 0, the simulation

length is expressed in time units, if simType = 1 is

expressed in number of loads that have to be completed.

In both case the value indicated in simLength does not

include the warm-up period (warmUpPeriod), that is

expressed in the same unit as simLength (i.e. time units or

number of loads). During the warm-up period statistics

are not collected.

3.6 Graphical user interface

Although the primary utilization of ASL is expected to be

as embedded in the code of algorithms and procedures, a

very simple GUI has been implemented (Figure 2). The

application is started, and the GUI is visualized, just by

double clicking the ALS.jar file. It allows to manually

insert all the inputs required, included task times and line

configuration information (that can also be loaded from

and saved to text files), and to display outputs and

execution time of the simulation run.

3.7 Using ALS as a library

ALS for the simulation of U-shaped lines is contained in a

package named lineSimulatorU, which provides the

public class Simulation, whose constructor and attributes

are reported in the following. The Simulation class does

not provide any method. When a Simulation object is

created the model of the assembly line is created, the

simulation is performed and outputs are stored in the

objects attributes. In Appendix A an example about using

the Simulation class is described

public class Simulation

Constructor

public Simulation (String distType, double cv,

int simulationLength, int warmUpPeriod, int

lengthType, int[] s, double[][]taskTimes,

int[][]lc)

Attributes

public double cycleTimeAverage;

public double cycleTimeSD;

public double flowTimeAverage;

public double flowTimeSD;

public int loadsCompleted;

public double tp;

public double workInProgress;

public double executionTime;

Figure 2. ALS Graphic User Interface.

4 ALS performances

ALS has to be evaluated on the basis of its fastness in

providing the simulated throughput of a line

configuration, given that all required inputs are known.

This time corresponds to the creation time of a Simulation

object, and its value (expressed in seconds) is stored in the

attribute executionTime. The line configuration depicted

in Figure 1 has been used as test-bed. The task times for

each model are reported in Table 1. Other inputs are: the

sequence array s = {0,0,1,1}, deterministic times

distribution, and simulation length in time units varying

from 100,000 to 10,000,000.

Tables 3 shows ALS execution times. The problem has

also been modelled in Arena version 11.0 (Kelton et al.,

2004), and execution times in batch mode (no animation)

have been recorded. The aim is to compare ALS

performances with one of the most widely used software

in the industrial field for the simulation of manufacturing

and material handling systems (Anglani et al., 2002), which

also provides one of the most efficient simulation engine

among many commercial simulation software (Cimino et

al., 2010). All simulations have been performed on a

computer with an Intel® Core™ i5-2400 CPU at

3100GHz, with Java version 7 update 67, running under

Windows 7 Professional Edition (64 bit version).

Sim. Length

(time units)

ALS

Arena

100,000

0.003

0.1757

400,000

0.014

0.4140

700,000

0.023

0.6484

1,000,000

0.033

0.9114

10,000,000

0.327

7.8320

Table 2. Execution times (sec)

Execution times are very small using ALS, which

abundantly outperforms Arena, proving to be more than

20 times faster. Furthermore, Arena’s execution times

only include the simulation run time, excluding the time

needed to develop the model for the specified line

configurations that are, on the contrary, intrinsically

considered in execution times provided by ALS. The time

needed by ALS to obtain the line throughput is so much

short that its usage in algorithms and procedures, that

have to evaluate different line configurations several

times, becomes possible.

5 Conclusions

The simulator presented herein, named Assembly Line

Simulator (ALS), can be used as supporting tool in finding

solution of the U-Shaped Mixed Model Assembly Line

Balancing Problem with stochastic task times. Its main

features are the following:

- it is realistic: it is able to calculate the throughput (and

other performance indicators) of an U-shaped unpaced

assembling line, in which a variety of models have to be

assembled in a mixed way, following a determined input

sequence or , with stochastic task times of completion;

- it is modular, because it is object-oriented: different

lines configurations (with different number of

workstations, tasks assignments, etc.) can be created by

the mean of very simple array representations, so that time

required for building the model is zeroed;

- it is very fast, because it is event-oriented: the

simulation run is performed only by events scheduling,

rescheduling, cancelling etc.; by avoiding the use of

‘processes’, execution times are kept very low

These characteristics allow it to be effectively coupled to

those algorithms and procedures where numerous variants

of line configurations have to be simulated, and the

evaluation of a fitness function (which includes some line

performances indicator, such as the cycle time in our case)

has to be performed several times. ALS allows to

overcome the limit of using traditional measures (not

simulation-based) of the performance parameter (the line

throughput or, equivalently the effective cycle time) that

are poorly correlated to its real value ALS allows to

overcome the limit of using traditional measures (not

simulation-based) of the line throughput that are poorly

correlated to its real value.

ALS has been developed with the scope to be usable by

researchers and practitioners. For this reason it has been

developed in Java, a language that guarantees the

compatibility with multiple platforms. ALS package is

available as a freeware software from the author’s web

page (Tiacci, 2014b, c).

6 References

Anglani, A., Grieco, A., Pacella, M., Tolio, T. (2002).

Object-oriented modeling and simulation of flexible

manufacturing systems: a rule-based procedure. Simulation

Modelling Practice and Theory, 10, 209-234.

Becker, C., Scholl, A. (2006). A survey on problems and

methods in generalized assembly line balancing. European

Journal of Operational Research, 168, 694-715.

Bukchin, J. (1998). A comparative study of performance

measures for throughput of a mixed model assembly line

in a JIT environment. International Journal of Production

Research, 36, 2669-2685.

Erel, E., Sabuncuoglu, I., Aksu, B.A. (2001). Balancing of

U-type assembly systems using simulated annealing.

International Journal of Production Research, 39, 3003-3015.

Kelton, W.D., Sadowski, R.P., Sadowski, D.A. (2004).

Simulation with ARENA. McGraw-Hill New York.

Miltenburg, G.J., Wijngaard, J. (1994). The U-Line Line

Balancing Problem. Management Science, 40, 1378-1388.

Scholl, A., Becker, C. (2006). State-of-the-art exact and

heuristic solution procedures for simple assembly line

balancing. European Journal of Operational Research, 168, 666-

693.

Sparling, D., Miltenburg, J. (1998). The mixed-model U-

line balancing problem. International Journal of Production

Research, 36, 485-501.

Tiacci, L. (2012). Event and object oriented simulation to

fast evaluate operational objectives of mixed model

assembly lines problems. Simulation Modelling Practice and

Theory, 24, 35-48.

Tiacci, L. (2014a). Coupling a genetic algorithm approach

and a discrete event simulator to design mixed-model un-

paced assembly lines with parallel workstations and

stochastic task times. International Journal of Production

Economics, , in press, doi:10.1016/j.ijpe.2014.1005.1005.

Tiacci, L. (2014b). Lorenzo Tiacci's institutional

homepage. www.impianti.dii.unipg.it/tiacci.

Tiacci, L. (2014c). Lorenzo Tiacci's reserach gate

homepage. www.researchgate.net/profile/Lorenzo_Tiacci.

Tiacci, L., Saetta, S. (2007). Process-oriented simulation

for mixed-model assembly lines, Proceedings of the 2007

Summer Computer Simulation Conference. Society for

Computer Simulation International, San Diego, USA, pp.

1250-1257.

Appendix A. EXAMPLE

By linking the ALS.jar file as a library, it is possible to

import the package lineSimulatorU, which provides the

public class Simulation, whose constructor arguments

represent the inputs needed to start the simulation. When

a Simulation object is created, the simulation model of the

assembly line is created, the simulation is performed and

outputs (f.e. average cycle time, average flow time, average

WIP) are stored in the object attributes.In the following

an example of using ALS as a library is shown. The

required inputs are defined by code and correspond to the

test-bed instance used in Section 5. The simulation length

corresponds to the completion of 5000 loads, with a

warm-up period of 500 loads.

package example;

import linesimulatorU.Simulation;

public class Example {

public static void main(String[] args) {

String distributionType = "DET";

double cv = 0.0;

int s [] = {1,1,0,0};

boolean randomSeq = false;

int simLength = 5000;

int warmUpPeriod = 500;

int lengthType = 1;

double [][] tTimes = { {6, 4},

{6, 7},

{8, 4},

{7, 5},

{5, 6},

{10, 12},

{15, 5},

{13, 7},

{8, 12},

{9, 12},

{8, 10},

{8, 12},

{7, 12}};

int lc [][] = { {2, 0, 0, 2, 11, 12},

{3, 0, 1, 3, 4},

{1, 0, 5, 9, 10},

{3, 0, 6, 7, 8}};

Simulation sim = new Simulation (distributionType,

cv,simLength,warmUpPeriod,

lengthType,s,randomSeq,

tTimes,lc);

System.out.println("cycleTimeAverage:\t"+

sim.cycleTimeAverage+

"\ncycleTimeSD:\t"+sim.cycleTimeSD+

"\nflowTimeAverage:\t"+sim.flowTimeAverage+

"\nflowTimeSD:\t"+sim.flowTimeSD

"\nloadsCompleted:\t"+sim.loadsCompleted

"\nworkInProgress:\t"+sim.workInProgress

"\ntp:\t"+sim.tp

"\nexecutionTime:\t"+sim.executionTime);

}

Compiling and running the code will provide the

following output:

cycleTimeAverage: 33.25000000000005

cycleTimeSD: 5.761435483259838

flowTimeAverage: 166.25000000000009

flowTimeSD: 5.761435483259843

loadsCompleted: 5000

workInProgress: 5

tp: 0.03007518796992477

executionTime: 0.152