Content uploaded by Lorenzo Tiacci

Author content

All content in this area was uploaded by Lorenzo Tiacci on Oct 25, 2017

Content may be subject to copyright.

1

Event and object oriented simulation to fast evaluate operational

objectives of mixed model assembly lines problems

Lorenzo Tiacci*

Università degli Studi di Perugia - Dipartimento di Ingegneria Industriale, Via Duranti, 67 – 06125 – Perugia, Italy

Abstract

In this paper an event and object oriented simulator for assembly lines is presented. The tool, developed in Java,

is capable to simulate mixed model assembly lines, with stochastic task times, parallel stations, fixed scheduling

sequences, and buffers within workstations. The simulator is a flexible supporting tool in finding solution of the

mixed model assembly line balancing problem (and the optimal sequencing and buffer allocation problems

associated to it). It is capable to immediately calculate the throughput of a complex line, by simply receiving as

inputs three arrays representing: the task times durations, the line configuration (number of workcentres, of buffers

within them, of parallel workstations in each workcentre, of tasks assigned to each workcentre), and the sequence of

models entering the line. Its fastness and flexibility allow its utilization in those algorithms and procedures where the

evaluation of a fitness function (which includes the throughput as performance indicator) has to be performed several

times. It allows overcoming the limit of using others measures of throughput, presented in literature, that are poorly

correlated to its real value when the complexity of the line increases. The simulator is an expandable tool; in its

current version provides the possibility to simulate both straight and U-shaped lines, and to generate both random

and fixed sequences of models entering the line.

Keywords: Event-oriented simulation; object-oriented simulation; line balancing; mixed model; sequencing; buffer allocation; U-

shaped lines.

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

* Corresponding Author: Tel.: +39-075-5853741; fax +39-075-5853736.

E-mail address: lorenzo.tiacci@unipg.it (L.Tiacci).

2

equally equipped with respect to machines and workers. For an overview of exact methods and heuristics

developed to solve the SALBP see Scholl and Backer (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) 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 said, 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 this work is to show how to overcome the limit of using performance measures instead of

simulated throughput, by the use of 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 is presented. The tool is capable to

immediately model a complex line and to calculate its throughput (and others performances indicators) by

3

simply receiving as inputs three arrays representing: the task times durations, the line configuration

(number of workstations, of buffers within them, of parallel stations in each workstations, of tasks

assigned to each workstations), and the sequence of models entering the line.

In the following, a literary review on features and operational objectives considered for the MALBP is

reported. Then, modeling features, inputs required and outputs provided by the simulator are described.

Section 3 summarily describes the event-oriented approach utilized and the simulator structure.

Implementation issues are discussed in Section 4. In Section 5 the simulator performances are tested, and

execution times are compared both with a process-oriented implementation of the same tool, and with

Arena.

2. Operational objectives and their measures

In recent years many heuristic and meta-heuristic methods have been proposed in literature to find

solution to the MALBP. Studies published in the last ten years utilize different approaches, such as:

Simulated Annealing (McMullen and Frazier, 1998; Vilarinho and Simaria, 2002), Ant techniques

(McMullen and Tarasewich, 2003), Genetic Algorithms (Simaria and Vilarinho, 2004; Tiacci et al., 2006;

Noorul Haq et al., 2006) and other heuristics (McMullen and Frazier, 1997; Askin and Zhou, 1998;

Merengo et al., 1999, Jin and Wu, 2002; Bukchin et al., 2002; Karabati and Sayin, 2003).

In order to compare design alternatives, some ‘metric’ have to be established. As in many industrial

problems, in the MALBP a trade-off exists between costs (associated to labour and equipments) and

performances. For this reason, objective functions of algorithms that find solution to MALBP usually

includes both these objectives. But while to calculate costs associated to a determined line configuration is

relatively easy (assuming that labour and equipments costs are known), to evaluate the performances of a

mixed model assembly line may be, as already mentioned, complicated. Thus, most of the above

mentioned studies uses some ‘measure’ to estimate the throughput (taken as the main performance

objective), but do not address the problem to verify the validity of such measures. Only two studies on

MALBP directly address this problem, namely Buckhin (1998) and Venkatesh and Dabade (2008).

The work of Buckhin (1998) is based on a comparison between 5 performance measures for throughput

with simulation results. Three of them had already been proposed by other authors, namely the ‘Smoothed

Station’ measure (Thomopoulos, 1979), the ‘Minimum Idle Time’ measure (Macaskill, 1972) and the

‘Station Coefficient of Variation’ (Fremerey, 1991), while the other two have been introduced by the

author: the ‘Model Variability’ and the ‘Bottleneck’. The latest one is obtained by estimating the expected

value of the assembly time at the bottleneck station. Model Variability and Bottleneck have been found to

outperform the other measures in showing a better correlation with the simulated throughput. On the basis

of these results, Buckhin et al. (2002) incorporated the Bottleneck into a balancing heuristic algorithm in

order to compare the quality of solution for a MALBP, while Tiacci et al. (2006) used a modified version

of Model Variability in the fitness function of a Genetic algorithm for balancing mixed model lines with

parallel workstations and stochastic task times.

Venkatesh and Dabade (2008) proposed other two measures, namely the Squared Based Model

Deviation (SBDM), and the BMI, equal to the sum of the SBMD and the Smoothness Index (SI). The two

performance measures along with eight others (reported in literature earlier) have been used as fitness

function for a Genetic Algorithm to obtain solutions of a total of 3000 MALBP instances. Then, a

statistical analysis was conducted on these solutions to compare the performance measures with regard to

their ability to represent the operational objectives; the statistical analysis showed a low correlation of

almost all measures with the realized throughput, with best results obtained by the SI. Contrary to what

found by Buckhin, the Bottleneck showed a very low correlation with throughput. Authors selected other

two operational objectives, besides the throughput, to which compare their measures: the Model

Variability, and the Station Variability. At this purpose, a consideration has to be done. Model Variability

4

and Station Variability should not be considered ‘operational objectives’, but measures correlated to an

operational objective (the throughput). For example, the fact that assembly times of different models are

similar in each station (i.e. ‘Station Variability’ is low), it is not an objective in itself, but a (supposed)

mean to achieve a high and stable throughput. Furthermore, while the throughput is difficult to estimate,

the Model Variability and the Station Variability, for givens tasks assignments, can be calculated

straightforwardly and do not need to be ‘evaluated’ through a measure.

More in general, methods that are developed to seek station assignments that lead to more balanced

workloads across stations and across products are motivated to limit the effect, on the realized cycle time,

of the sequencing of different models on the assembly line. However, as outlined by Karabati and Sayin

(2003), these methods remain to be approximate approaches, for the very reason that the effects of the

sequencing decision on the line throughput are not incorporated explicitly. Due to the computational

complexities involved, the assembly line balancing problem and sequencing problems are usually

addressed in literature independently of each other, although they are closely interrelated.

Another problem that is strictly connected to the balancing one is the buffer allocation problem (BAP).

Studies in literature on BAP mostly refer to flow-lines production systems, consisting in a linear sequence

of several machines. The decision to be taken is the amount of buffer space (used to avoid blockage and

starvation to obtain high throughput) to install between successive stages; production rates in each stage

are assumed to be known. The same problem can be transposed to assembly lines, with the difference that

production rates in each station depend on which tasks are assigned to it, that is, on the result of the

balancing procedure. Again, to obtain optimal results, buffer allocation and line balancing should be

performed together. Literature about MALBP does not address the possibility to install buffers within

stations. This is perhaps due to the additional difficulty in estimating line throughput.

In summary, the motivations for the development of the simulator that will be presented in the next

sections are:

- results from the above mentioned studies (Buckhin, 1990; Venkatesh and Dabade, 2008) on the

correlation between performance measures and realized throughput are not consistent each other, sign

that it is difficult to find a throughput measure of general validity for all the possible issues of the

problem;

- both studies consider deterministic task times and a relatively simple mixed model line configuration; a

loss of correlation of the same performances measures with the simulated throughput is expected if task

times are stochastic, and, in general, if the complexity of the line increases (number of workstations,

buffers within workstations, parallel stations, etc.);

- the assembly sequence of the models is also important with respect to the realized cycle time, and this

implies that the MALBP is also connected to a sequencing problem, that should not be treated separately

from the balancing problem. Thus, the impact of models sequencing on cycle time should not be

neglected.

- buffer allocation and line balancing decisions should be performed simultaneously. To do this, the

impact of buffers on the line throughput has to be calculable.

3. The Assembling Line Simulator (ALS)

The aim of this work is to put at the scientific community and practitioners disposal an efficient,

flexible and expandable tool, named Assembly Line Simulator (ASL), able to quickly model and simulate

complex assembling lines. Its main characteristics are the ability to quickly build the model of a line

configuration and to fast execute the simulation run. These two characteristics allow it to be easily

‘embedded’ in algorithms and procedures that find solutions to MALBP, overcoming the above mentioned

limits imposed by the use of measures instead of the simulated throughput. In the following (Section 3.1),

the types of assembling lines that can be modeled are illustrated, together with the representation of inputs

5

required by the simulator. In Section 3.2 the object-oriented structure and the event-oriented logic through

which the simulator has been implemented are described.

3.1. Description of the model

In the line, each operator has a workstation (WS) where he performs one or more tasks. Each work

centre (WC) consists of either one workstation, for the case of non-paralleling, or multiple parallel

workstations (see Figure 1). ‘Paralleling’ means that when a WC consists of two or more workstations, all

the tasks assigned to the WC are not shared among the WS, but each WS performs all of them. Thus an

increment of production capacity of the WC is obtained through the addition of one (or more) WS which

performs the same set of tasks. The aim of using parallel stations is often to perform tasks with processing

time larger than the desired cycle time. However, also if any given task time does not exceed cycle time,

the possibility to replicate workstations may be desirable, because it enlarges the space of feasible

solutions of the balancing problem, including many feasible and potentially better balanced configurations

(Vilarinho, 2002; Tiacci et al. 2006).

Figure 1. An assembly line with parallel workstations and buffers.

The line is asynchronous, that is as well as blockage and starvation are possible. One WC with multiple

WSs is considered busy if every WS inside is busy. If a WS finishes its work on a workpiece while the

subsequent WC is still busy (or the subsequent buffer is full), the workpiece can not move on, and

remains in the current WS keeping it busy (‘blocking after processing’ policy); the WS will be released

(i.e. will be able to process another workpiece) only when the workpiece leaves the WS.

Pieces are retrieved from buffers following a First In First Out rule. If a buffer is placed before a WC

with parallel WSs, pieces are retrieved from the same buffer by all the WSs.

The first WC is never starved (there is always raw material for the first WC) and the last station is

never blocked (there is always storage space for the finished product)

3.1.1. Notation

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

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

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

tij time required by model j in work centre i.

operator

workstation

work centre

buffers

6

3.1.2. Task times of completion

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.

The 2 x 7 matrix depicted in Figure 2 represents the case in which 2 types of products (models) have to

be assembled; each model requires 7 tasks to be completed. For example the average task time of task #4

of model #0 is equal to 5 minutes (or, in general, 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.

a. b.

Fig. 2. a. The tij array representation.

b. Tabular representation of input task times.

3.1.3. Representation of a line configuration

A ‘line configuration’ represents a specific solution of the MALBP, and is characterized by the

following information:

- the total number of WC in the line;

- the number of WS in each WC;

- the presence and the size of buffers before each WC;

- how many and which tasks are assigned to each WC (and are all performed by each WS assigned to

the WC).

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 is the number of WSs assigned to the WC: a number higher than 1 means parallel WSs. The

second element represents the size of the buffer placed before the WC: 0 means no buffer. The subsequent

elements represent the tasks assigned to the WC. Note that rows do not necessarily contain the same

number of elements. For example, Figure 3 shows a solution that represents a line composed by 3 WC.

Tasks #1, #3 and #6 are assigned to WC#0, in which 2 WSs operate. Tasks #2 and #0 are assigned to

WC#1 (with 1 WS), and task #4 and #5 are assigned to WC #2 (with 1 WS). A buffer of unit size is placed

between WC#1 and WC#2. Note that because there are always raw materials for the first WC, the buffer

before WC#0 is useless, having no impact on the line throughput, and its size should be set to 0.

Model#

Task#

0

1

0

10

8

1

3

9

2

8

8

3

7

8

4

5

9

5

6

10

6

13

2

tij={{ 10, 8 },

{ 3, 9 },

{ 8, 8 },

{ 7, 8 },

{ 5, 9 },

{ 6, 10},

{ 13, 2 }}

7

Fig. 3. a. The lckz two dimensional array.

b. Tabular representation.

c. Graphical representation.

3.1.4. Model sequencing

The simulator allows also to specify the sequence of models assembled through the line: this sequence

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.

3.1.5 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 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.2. Implementation

ALS has been developed in Java, basically because the Java language is intrinsically clear and concise;

the application can be easily distributed (deployed) through a single file (.jar), it is multiplatform, and

there is no need of any legacy software to deal with. The simulator has been implemented using SSJ

(L’Ecuyer et al., 2002; L’Ecuyer and Buist, 2005), a package for discrete event simulation in Java. SSJ

WC#

WSs

assigned

Buffer

size

Tasks

assigned

0

2

0

1, 3, 6

1

1

0

2, 0

2

1

1

5, 4

lckz = { { 2, 0, 1, 3, 6 },

{ 1, 0, 2, 0 },

{ 1, 1, 5, 4 } }

1, 3, 6

2, 0

5, 4

a.

b.

c.

8

(which stands for Stochastic Simulation in Java) is an organized set of software tools offering general-

purpose facilities for stochastic simulation programming in Java. It supports the event view, process view,

continuous simulation, and arbitrary mixtures of these.

ALS is built using the object oriented-approach of Java and the event-oriented approach provided by SSJ.

The event-oriented simulation approach is also referred in literature as “event-driven” simulation or

“event-scheduling” approach. In this approach a system is modelled by identifying its characteristic events

and then writing a set of event routines that give a detailed description of the state changes taking place at

the time of each event. The simulation evolves over time by executing the events in increasing order of

their time of occurrence (Law and Kelton, 2000, Zeigler et al., 2000, Banks et al., 2004).

To implement the simulator 4 classes, representing the physical configuration, have been defined (see Fig.

4 for the simplified UML class diagram): Line, WorkCentre, Workstation and Load.

Fig. 4. A simplified UML class diagram of ALS.

*

*

9

The relations between these classes reproduce the relations between the corresponding entities in real

world: an assembly line is formed by a set of WCs (List workCentre); each WC has a number of WS,

some of which are available for loads processing (List freeWorkStation). Each WC has a virtual

queue represented by the list of the loads (i.e. workpieces) that are waiting to be processed on the WC

(List loadScheduled); a number of elements of this queue equal to the WC’s buffer size (int

bufferSize) is physically in the buffer of the WC, while the remaining elements are still waiting in the

preceding WC. Each time that a load starts being processed in the WC, one WS is removed from the

freeWorkStation List. If this list is empty the WC is considered busy, and cannot process any further load.

The package ‘SSJ’ provides the abstract class Event that offers facilities for creating and scheduling

events in the simulation. Each type of event must be defined by implementing an extension of this class.

ALS is built using two main types of events, namely FinishProcessingEvent and

StartProcessingEvent, which are implemented through two classes that extend the Event class. A

FinishProcessingEvent is associated to each load (relation 1:1 in Figure 4), and it happens whenever a load

has finished to be processed in a WC. A StartProcessingEvent is associated to each WC (relation 1:1), and

represents the event of the WC that starts processing a load. Their method actions() describes the

actions that are performed each time the event, associated to the corresponding entity (load or WC),

happens. In this way it is not necessary to create a new event each time that a WC starts processing a load,

or each time a load finishes to be processed in a WC. Instead, the same event associated to each Load or

WC will be scheduled and re-scheduled.

In fact, events happen because they are scheduled. The method scheduleNext()schedules an event

as the first event in the event list, that is, to be executed at the current time (as the next event). The method

schedule(double delay) schedules an event to happen in delay time units, i.e., at current time +

delay, by inserting it in the event list.

Figure 4 shows only the main relationships among classes. Some arrows and lines have been omitted in

the UML diagram to allow an acceptable readability. The FinishProcessingEvent class has a relation with

WorkCentre whose cardinality is 1:2. In fact, when a load finishes to be processed, it is linked to two

WCs: the WC in which the load has just been processed (WorkCentre currWC) and the one subsequent

to the current one (WorkCentre nextWC). In that moment each load can schedule the StartProcessing

event associated to this two WCs (see Figure 5). Even the StartProcessingEvent class is related to Load

through a relationship whose cardinality is 1:2, because, as described in the next paragraph, when a

StartProcessing event happens, actions on the load that is going to be processed (startWorkingLoad)

and on the load that is entering the buffer from the preceeding WC (enteringBufferLoad) have to be

performed.

Through this architecture, each Load and Workstation can schedule, through their StartProcessing and

FinishProcessing instances, events associated to other instances. In the following, the actions()

methods of the two classes StartProcessingEvent and FinishProcessingEvent are described in detail.

Figure 5 summarizes the events that are scheduled when StartProcessing and FinishProcessing events

happens.

3.2.1. Actions associated to StartProcessingEvent

Actions associated to the StartProcessing event are performed when a load starts being processed in the

WC, coming from the buffer or directly from the previous WC (if the buffer size is zero). The WC

StartProcessing event can happen only if two conditions are both verified:

a) its loadScheduled List is not empty (there is at least one load waiting to be processed);

b) its freeWorkStation List is not empty (there is at least one WS available for process a load);

If both conditions a and b are verified, the WC is ready to work. The method readyToWork() check

if this two conditions are true.

10

Actions performed in the StartProcessingEvent actions() method can be summarized as follows:

- remove the first load in the loadScheduled List (startWorkingLoad: the load starting being

processed in one of the WS of the WC)

- remove one WS (startWorkingWS) from the set of available ones (freeWorkStation);

- startWorkingWS calculates the processing time (calculateHoldTime()) on startWorkingLoad;

- the FinishProcessing event associated to startWorkingLoad is scheduled to happen in a time equal

to the processing time;

- if the number of loads in the loadScheduled List is than the buffer size (i.e. a load has already

been processed in the previous WC and is waiting to enter the buffer) then :

a load (enteringBufferLoad) enters the buffer of the WC;

one WS (currWS of enteringBufferLoad) is released in the previousWC;

if the previous WC (WorkCentre previousWC) is ready to work (conditions a and b are

true), the StartProcessing event associated to previousWC is scheduled to happen at the

current time.

3.2.2. Actions associated to FinishProcessingEvent

Actions associated to the FinishProcessing event are performed when a load has just finished to be

processed in a WC. The point of view of a load passing through the assembly line (from one WC to the

subsequent one) is assumed, and the following notation is utilised: WorkCentre currWC indicates the

WC the load is leaving from, that is the WC in which the load has just been processed; WorkCentre

nextWC indicates the WC the load is arriving in, which is subsequent to currWC.

These actions are described in the FinishProcessingEvent actions() method and can be summarized as

follows:

- the load claims to be processed in nextWC (the load enters the loadScheduled List of nextWC, but

does not release the WS in currWC)

- if there is space in the buffer of nextWC (number of loads in the loadScheduled List of nextWC <

buffer size), then:

the load enters the buffer of nextWC, and one WS is released in currWC (a WS is added

to the set of available ones);

if the load is leaving the first WC in the line, then a new load is created.

if currWC is ready to work (conditions a and b are true), then the event StartProcessing

event associated to currWC is scheduled to happen at the current time;

- if nextWC is ready to work (conditions a and b are true), then the StartProcessing event associated

to nextWC is scheduled to happen at the current time;

3.2.3. Loads creation

In order to start the simulation, a first event, corresponding to the first load entering the line, has to be

scheduled to happen at time zero. This first event corresponds to a FinishProcessing event of the load in a

virtual WC numbered -1 (i.e. a virtual WC before the first WC in the line). When this event happens, the

first load passes from WC#-1 to WC#0, and, triggering the StartProcessing event related to WC#0, starts

up the recursive event scheduling and re-scheduling that allow the simulation to go on. When a load

finishes to be processed in the first WC (WC#0), it triggers the creation of a new load entering the line, by

scheduling a FinishProcessing event of a new load in WC#-1.

3.2.4. Inputs required

ALS is contained in a package named lineSimulator, which provides the public class Simulation,

whose constructor requires all the inputs described in Section 3.1: the array tij of tasks times completion

(double[][]t), the array lckz (int[][]lc) that describes the line configuration, the array s (int[]s)

11

that defines the sequence of models entering the line, the string distType representing the task times

distribution (String distType), the coefficient of variation cv (double cv) which is influent only if

distType = “NORM”, the simulation length (double simLength).

Fig. 5. Events scheduled when StartProcessing and FinishProcessing events happens.

3.2.5. Outputs provided

When an object Simulation is created, the model of the assembly line is created, the simulation is

performed and outputs are obtainable by accessing the following public attributes of the object: Tally

cycleTime; Tally flowTime. Objects of class Tally collect data that comes as a sequence of real-

valued observations. It can compute sample averages, sample standard deviations and confidence intervals

FinishProcessing event

A load FinishProcessing event happens at current time

(because it had been previously scheduled to happen at

this particular time). This means that the load has just

finished to be processed in currWC

time

Events that are scheduled when

a load FinishProcessing event

happens

if there is space in the

buffer of nextWC and

currWC is ready to work

the StartProcessing event

of currWC is scheduled to

happen at current time

If the next WC is ready to

work, the StartProcessing

event of nextWC is

scheduled to happen at

current time

current time

StartProcessing event

A workcentre (currWC) StartProcessing

event happens at current time (because it had

been previously scheduled to happen at this

particular time)

time

Events that are scheduled when

currWC StartProcessing event

happens

if the previousWC was

blocked and now it is

ready to work,

the StartProcessing event

of previousWC is

scheduled to happen at

current time

the FinishProcessing event of

startWorkingLoad is

scheduled to happen at

current time + processing

time

current time

processing time

12

on the mean based on the normality assumption. Class Tally is included in the package ‘stat’ of SSJ. Cycle

time is measured as the time that passes between two consecutive loads coming out from the line. Flow

Time is measured as the difference between the time of a load coming out from the line and its time of

entering the line. Line throughput and WIP are derived: average throughput is calculated as the average

cycle time inverse. Average WIP is calculated, using the Little law, as the product between average values

of throughput and flow time.

3.2.6. Graphical user interface (GUI)

Although the primary utilisation of ASL is expected to be as embedded in the code of algorithms and

procedures, a very simple GUI has been implemented (Figure 6). 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.

Fig. 6. The graphical user interface of ALS.

3.2.7. Event and process oriented versions

The final version of ALS is built using the event oriented approach, as described above. However, ALS

has also been realized in other two versions, using two different ‘process-oriented’ approaches, named

‘process oriented’ and ‘2p implementation’ (for details, see Tiacci and Saetta, 2007). These two versions

have been implemented using both the already mentioned package SSJ, and another package for process-

based discrete event simulation, named JavaSimulation (Helsgaun, 2004). A ‘process’ is a time-ordered

sequence of interrelated events separated by intervals of time, which describes the entire experience of an

“entity” as it flows through a “system”. The process-oriented paradigm is a natural way of describing

complex systems (Law and Kelton, 2000) and often leads to more compact code than the event-oriented

view. Unfortunately many simulation environments, including the Java packages JavaSimulation and SSJ,

implement processes through threads. This adds significant overhead, prevents the use of a very large

13

number of processes in the simulation and slows the simulation execution (L’Ecuyer and Buist, 2005), as

the experiments described in the next section confirmed.

3.3 Validation

We validated our model through two widely adopted techniques (see Law and Kelton, 2000). The first

one consists in computing exactly, when it is possible and for some combination of the input parameters,

some measures of outputs, and using it for comparison. The second one, that is an extension of the first

one, is to run the model under simplifying assumptions for which its true characteristics are known and,

again, can easily be computed.

Using the first approach it is possible, on the basis of queuing theory, to exactly calculate the

throughput of a single product assembly line with exponentially distributed task times, both for the case of

two stations with a buffer of size N between them, and in the case of three stations without buffers (see

Altiok, 1997). The capability to appropriately model lines in which multiple model are assembled and

stations can be duplicated (paralleling) has been validated through the second approach. In this case using

deterministic task times it is possible to easily calculate flow time and throughput or different simple line

configurations.

4. ALS Performances

ALS have 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 (see Section 3.2.4). This time corresponds to the

time of creation of an object Simulation; its value (expressed in seconds) is stored in the attribute

executionTime.

Two assembly problems have been used as testbeds. Problem 1 inputs are: the task times array reported

in Figure 2, the line configuration reported in Figure 3, the sequence array s = {0,0,1,1}, normal task times

distribution with coefficient of variation equal to 0.2. Problem 2 is taken from a real case, presented in

Mendes et al. (2005), concerning a company that is a major manufacturer of consumer electronic goods;

the system analyzed is the PC camera assembly line, in which three different versions of a PC camera with

some dissimilar technical specifications are assembled. Task times and line configuration are reported in

Tables 1 and 2. The sequence array is s = {0,1,2}, task times are normally distributed with coefficient of

variation equal to 0.1.

Tables 3 and 4 shows ALS execution times and outputs (for Problem 1 and 2 respectively), varying the

package used (JavaSim and SSJ), the implementation (process oriented, 2p, and event) and the simulation

length. Problem 1 and 2 have also been modelled in Arena 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 AMD Athlon X2 Dual Core Processor 4200+ (2.2 GHz), with JavaRuntime

Environment (JRE) 1.6 running under Windows Vista Home Premium Edition.

As far as ‘process oriented’ and ‘2p implementation’ versions are concerned, results show a slight

superiority of package SSJ over JavaSimulation, and an appreciable superiority of the ‘2p implementation’

over the ‘process orented’ version. Some data, corresponding to simulation length equal to 10,000,000

time units, is not available (na), due to ‘thread synchronization errors’ that arise when processes, like in

this two versions, are implemented as threads. For other considerations about relations between execution

times, throughput and WIP for these two versions, see Tiacci and Saetta (2007).

Execution times are drastically reduced using the event oriented version of ALS, which abundantly

outperforms also Arena (proving to be about from 10 to 5 times faster). Furthermore, Arena’s execution

14

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.

Table 1

Problem 2: task times (in time units)

Model#

Model#

Model#

Model#

Model#

Task#

0

1

2

Task#

0

1

2

Task#

0

1

2

Task#

0

1

2

Task#

0

1

2

0

2

2

2

8

2

2

2

16

6

6

6

24

4

4

4

32

4

4

4

1

2

2

2

9

10

10

10

17

7

7

7

25

6

6

6

33

2

2

2

2

2

2

2

10

3

0

0

18

3

3

3

26

5

5

5

34

2

2

2

3

2

2

2

11

11

11

11

19

28

37

33

27

0

0

2

35

1

1

1

4

2

2

2

12

4

4

4

20

3

3

3

28

1

1

1

36

1

1

1

5

0

11

11

13

0

4

4

21

8

8

8

29

3

3

3

37

1

1

1

6

0

0

16

14

9

9

0

22

5

5

5

30

3

3

3

38

1

1

1

7

21

39

37

15

13

13

12

23

7

7

9

31

0

0

3

Table 2

Problem 2: line configuration

WC#

WS assigned

Buffer size

tasks assigned

0

1

0

0, 1, 2, 3, 5, 6, 10, 14

1

2

0

4, 7, 8, 9, 12, 13, 18, 22

2

1

0

11, 15, 16

3

1

0

17, 20

4

2

0

19, 21

5

1

0

23, 24, 25, 26, 27, 28, 29, 30, 33, 36

6

1

0

31, 32, 34, 35, 37, 38

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

example, solving Problem 2 through the genetic algorithm approach proposed in Tiacci et al. (2006)

would require to perform a total of 50,000 fitness evaluations (i.e. throughput estimations). Considering a

simulation lengths of 100,000 time units, using ALS to obtain the simulated throughput would require an

extra CPU-time equal to (50,000 0.047 ) = 2,350 sec, that is little more than 39 minutes. This amount of

time is quite acceptable for this type of problems, considering also that the experiment has been conducted

on a standard PC.

It is noteworthy that the throughput estimation accuracy provided by a simulation run that lasts 100,000

time units is, for Problem 2, very high. To approximately quantify this accuracy, 40 replications of

100,000 time units length have been performed, and average (

= 34.453) and standard deviation (

=

0.0432) of the simulated mean cycle times have been calculated. The interval corresponding to an

amplitude of 3

is equal to 0.1296, that is just 0.37% of the average value. Confounding the unbiased

estimators

and

with the true values and assuming a normal distribution, the approximate probability

that the cycle time, provided by a single simulation run, falls between 0.37% of the real value would be

equal to the 99.7%. This accuracy is presumably much higher than any other measure, not simulation-

15

based, might provide. If a lower accuracy is acceptable, the simulation length can be shortened, allowing

to further limit the extra CPU-time required by ALS.

Table 3

Execution times (sec) and outputs of Problem 1.

ALS

Arena

Sim. length

(time units)

Process oriented

2p implementation

Event (SSJ)

JavaSim

SSJ

JavaSim

SSJ

100,000

1.26

1.12

0.73

0.501

0.025

0.265

400,000

4.65

4.07

2.57

1.98

0.109

0.777

700,000

8.12

7.04

4.36

3.46

0.187

1.281

1,000,000

11.30

10.04

6.26

4.84

0.266

1.777

10,000,000

na

na

62.65

49.29

2.65

16.51

Outputs (mean values expressed in time units): Cycle time: 17.00; Flow time: 68.7; WIP: 4.04.

Table 4

Execution times (sec) and outputs of Problem 2.

ALS

Arena

Sim. length

(time units)

Process oriented

2p implementation

Event (SSJ)

JavaSim

SSJ

JavaSim

SSJ

100,000

1.93

1.89

0.72

0.65

0.047

0.359

400,000

7.11

6.86

2.66

2.25

0.181

0.984

700,000

12.49

11.87

4.4

3.76

0.32

1.574

1,000,000

18.00

16.90

6.42

5.44

0.456

2.183

10,000,000

na

na

na

54.8

4.47

20.71

Outputs (mean values expressed in time units): Cycle time: 34.45; Flow time: 237.25; WIP: 6.80.

5. Improvements

ALS is an expandable tool, and can benefit from several libraries available for Java. Once the core of

the simulator, consisting in the object structure (Fig. 4) and the logic of actions methods (Sections 3.2.1

and 3.2.2), has been defined many improvements can be easily implemented. Among theses, the latest

version of ALS already includes:

- more statistical distributions for representing stochastic task times; the possibility that each individual

task has a completion time described by a specific statistical distribution.

The implementation of this feature has been done using the package randvar of SSJ, that provides a

collection of classes for non-uniform random variate generation. Inputs related to task times described in

section 3.2.4 (i.e. tij, distType, cv), has been replaced with three arrays, namely: distTypeij = distribution of

completion time of task i on model type j (String[][]distType), pij = first parameter of the

distribution distTypeij (double[][]p), p2ij = second parameter of the distribution distTypeij

(double[][]p2). In this way the following single and double parameter distributions have been

modelled: “DET” = deterministic, “GEO” = geometric, “LOG” = logarithmic, “POIS” = Poisson, “EXP”

= exponential, “CHI” = chi; “NORM” = normal, “UNIF” = uniform, “GAM” = gamma, “ERL” = Erlang,

16

“BIN” = binomial. If the distribution distTypeij requires only one parameter, the corresponding p2ij values

are ignored. If the distribution requires an integer parameter instead of a double one (e.g. chi and Erlang

distributions), double values are casted to integer.

- the possibility to define a warm-up period;

A warm-up period w (double w) has been introduced, during which statistics are not collected. The total

duration of the simulation run will be equal to the sum of the w and the simLength variables.

- the possibility that the sequence of models entering the line is random, while respecting a determined

demand proportion among different model types (to simulate a JIT environment);

The implementation of this feature has required adding a new input, consisting in an array named

demPropj (double [] demProp) that 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

demProp

P= demProp

This kind of random generation is performed when the value of the boolean input randomSeq (boolean

randomSeq) is true. Otherwise, the sequence of models assembled through the line is defined by the array

s, as described in section 3.1.4.

- the possibility to model U-shaped lines (Miltenburg and Wijngaard, 1994), in which stations may

work at two segments of the line facing each other simultaneously;

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 7, a WC may consist of one operator and two WSs, each one at two

segments of the line. In this type of WCs, named ‘crossover’ WCs (WC#0 and WC#2 if Fig.7), loads can

be processed alternatively into one of the WSs. So the difference to the straight line is that a WC k 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 (cf. Monden, 1998).

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.

U-shaped lines can be simulated through ALS setting the boolean input uShaped (boolean uShaped) to

true. The definition of an array uk (int [] u) is required in order to define the number of tasks of a WC k

that are performed in the first side of the U (the remaining tasks will be performed in the return side). For

example (see Fig. 7) tasks assigned to WC#0 are {1, 3, 12, 13}, and u0 = 2 means that the first two tasks

(1, 3) are done in the first side, while the remaining tasks (12, 13) are done in the return side. 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 first side.

In the current implementation loads can enter a WC one at a time, no buffers are assumed between

workcentres, and no form of paralleling is considered. So if uShaped is ‘true’ inputs data related to buffers

size and number of workstations in the lckz array (i.e. the first two columns) are ignored.

17

Fig. 7. a. Precedence diagram.

b. Tabular representation.

c. Graphical representation.

With the aim to cover the widest range of issues proposed in literature and that may be found in real cases,

the next improvements of ALS include the development of the following features:

- the possibility that same task can be assigned to different WCs for different models: this relaxation is

acceptable considering highly skilled workers, capable of performing a wide range of activities (for

details see Bukchin et al., 2002)

- the possibility to consider buffers between WCs in U-shaped lines;

- dynamic variation of task times due to learning effects of operators;

- a version more oriented toward flow lines, with unreliable machines and stochastic failure and repair

times.

WC#

Tasks

assigned

uk

0

1, 3, 12, 13

2

1

2, 4, 5

3

2

6, 10, 11

1

3

7, 8, 9

3

1, 3

work centre

workstation

operator

7, 8, 9

12, 13

2, 4, 5

6

10, 11

1

2

3

4

6

5

8

11

7

13

10

12

9

a.

b.

c.

WC#0

WC#1

WC#2

WC#3

18

6. Summary

The simulator presented herein, named Assembly Line Simulator (ALS), can be used as supporting tool

in finding solution of the assembly line balancing problem. Its main features are the following:

- it is realistic: it is able to calculate the throughput (and other performance indicators) of an assembling

line, with parallel stations, buffers within workstations, in which a variety of models have to be

assembled in a mixed way, following a determined input sequence, with stochastic task times of

completion;

- it is modular, because it is object-oriented: different lines configurations (with different number of

workstations, tasks assignments, number of buffers, 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 (in

some cases less than a tenth of second), arriving to outperform Arena.

These characteristics allows 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 throughput) has to be performed several

times.

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. This lack of correlation increases with the

complexity of the line, and this is one of the reasons why problems, that should be approached

simultaneously (line balancing, buffer allocation, model sequencing), have often been treated sequentially

or separately in literature. ALS represents an effective mean to go over these traditional approaches.

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 (available after paper acceptance

decision).

References

Altiok Tayfur, (1997). Performances Analysis of Manufacturing Systems, Springer.

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.

Askin, R.G., & Zhou, M. (1997). A parallel station heuristic for the mixed-model production line balancing problem.

International Journal of Production Research, 35 (11), 3095-3105.

Banks, J., Carson, J., Nelson, B. &Nicol, D., (2004). Discrete-event system simulation. Fourth edition. Prentice Hall.

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.

Bukchin, J., Dar-El, E.M., & Rubinovitz, J. (2002). Mixed model assembly line design in a make-to-order

environment. Computers & Industrial Engineering, 41, 405-421.

Cimino, A., Longo, F., & Mirabelli, G. (2010). A General Simulation Framework for Supply Chain Modeling: State

of the Art and Case Study, International Journal of Computer Science Issues, 7(2), No 3.

Fremerey, F. (1991). Model-mix balancing: more flexibility to improve the general results. In: M. Pridham, & C.

O’Brien, Production Research: Approaching the 21st Century, pp. 314-312, London: Taylor & Francis.

Helsgaun, K. (2004). Discrete Event Simulation in Java, Department of Computer Science, Roskilde University,

Denmark. Available at http://www.akira.ruc.dk/~keld/research/JAVASIMULATION/.

19

Jin, M., & Wu, S.D. (2002). A new heuristic method for mixed model assembly line balancing problem. Computers

& Industrial Engineering, 44, 159-169.

Karabati, S., & Sayin, S. (2003). Assembly line balancing in a mixed-model sequencing environment with

synchronous transfers. European Journal of Operational Research, 149, 417-429.

Kelton,W.D., Sadowski, R.P., & Sturrock, D.T. (2004). Simulation with Arena. New York: McGraw-Hill.

Law, A. M., & Kelton, W. D. (2000) Simulation Modeling and Analysis. Third edition. New York: McGraw-Hill.

L’Ecuyer, P., Meliani, L., & Vaucher, J. (2002). SSJ: a framework for stochastic simulation in Java. In: Proceedings

of the 2002 Winter Simulation Conference (pp. 234-242). IEEE Press.

L’Ecuyer, P., & Buist, E. (2005), Simulation in Java with SSJ. In: Proceedings of the 2005 Winter Simulation

Conference (pp. 611-620). IEEE Press.

Macaskill, J.L.C. (1972). Production-line balances for mixed-model lines. Management Science, 19, 423-434.

Mendes, A.R., Ramos, A.L., Simaria, A.S., & Vilarinho, P.M. (2005). Combining heuristic and simulation models

for balancing a PC camera assembly line. Computers & Industrial Engineering, 49, 413-431.

Merengo, C., Nava, F., & Pozetti, A. (1999). Balancing and sequencing manual mixed-model assembly lines.

International Journal of Production Research, 37, 2835-2860.

McMullen, P.R., & Frazier, G.V. (1997). A heuristic for solving mixed-model line balancing problems with

stochastic task durations and parallel stations. International Journal of Production Economics, 51, 177-190.

McMullen, P.R., & Frazier, G.V. (1998). Using simulated annealing to solve a multiobjective assembly line

balancing problem with parallel workstations. International Journal of Production Research, 36 (10), 2717-

2741.

McMullen, P.R., & Tarasewich, P. (2003). Using ant techniques to solve the assembly line balancing problem. IIE

Transactions, 35, 605-617.

Miltenburg, J., & Wijngaard, J. (1994). The U-line line balancing problem. Management Science, 40, 1378–1388.

Monden, Y., 1998. Toyota production system––An integrated approach to just-in-time, 3rd. Dordrecht: Kluwer.

Noorul Haq, A., Jayaprakash, J., & Rengarajan, K. (2006). A hybrid genetic algorithm approach to mixed-model

assembly line balancing. International Journal of Advanced Manufacturing Technologies, 28, 337-341.

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.

Simaria, A.S., & Vilarinho, P.M. (2004). A genetic algorithm based approach to the mixed-model assembly line

balancing problem of type II. Computers & Industrial Engineering, 47, 391-407.

Thomopoulos, N. T. (1967). Line balancing-sequencing for mixed-model assembly. Management Science, 14, 59-75.

Tiacci, L., Saetta, S., & Martini, A. (2006). Balancing Mixed-Model Assembly Lines with Parallel Workstations

through a Genetic Algorithm Approach. International Journal of Industrial Engineering, Theory, Applications

and Practice, 13, 402-411.

Tiacci, L., & Saetta, S. (2007). Process-oriented simulation for mixed-model assembly lines. In: Proceedings of the

2007 Summer Computer Simulation Conference (pp. 1250-1257). San Diego: SCSI.

Vilarinho, P. M., & Simaria, A. S. (2002). A two-stage heuristic method for balancing mixed-model assembly lines

with parallel workstations. International Journal of Production Research, 40 (6), 1405-1420.

Wilhelm, WE. (1987). On the normality of operation times in small-lot assembly systems: a technical note.

International Journal of Production Research, 25(1), 145-154.

Zeigler B. P., Praehofer, H., & Kim T.G (2000). Theory of modeling and simulation: Integrating discrete event and

continuous complex dynamic systems, second edition, Academic Press.