Received 21 January 2011Received in revised form 20 January 2012Accepted 23 January 2012Available online 3 March 2012

tool, developed in Java, is capable to simulate mixed model assembly lines, with stochastic

generalized assembly line balancing problem (GALBP). For example, in todays time of ever more personalized products, assem-bly lines assembling just one product are extremely rare. On the contrary, several products (models) are often manufacturedon the same line. The mixed-model assembly line balancing problem (MALBP) is a GALBP that address this issue, in which

1569-190X/$ - see front matter 2012 Elsevier B.V. All rights reserved.

Tel.: +39 075 5853741.E-mail address: lorenzo.tiacci@unipg.it

Simulation Modelling Practice and Theory 24 (2012) 3548

Contents lists available at SciVerse ScienceDirect

Simulation Modelling Practice and Theory

journal homepage: www.elsevier .com/ locate/s impatdoi:10.1016/j.simpat.2012.01.004The assembly line balancing problem (ALBP) has been one of the most studied problems in the literature related to indus-trial engineering. It consists in assigning tasks to workstations, while optimizing one or more objectives without violatingany restriction imposed on the line (e.g. precedence constraints among tasks). The basic version of the general problem isthe so-called simple assembly line balancing problem (SALBP). Its main characteristics are: serial line lay out with a certainnumber of stations, paced line with xed cycle time, only one product is assembled, task times are deterministic and all sta-tions are equally equipped with respect to machines and workers. For an overview of exact methods and heuristics devel-oped to solve the SALBP see [26].

The assumptions of SALBP are very restricting with respect to real-world assembly line systems. Therefore, researchershave recently intensied their efforts to identify, formulate and solve more realistic problems, that are embraced by the termKeywords:Event-oriented simulationObject-oriented simulationLine balancingMixed modelSequencingBuffer allocationU-shaped lines

1. Introductiontask times, parallel stations, xed scheduling sequences, and buffers within workstations.The simulator is a exible supporting tool in nding solution of the mixed model assemblyline balancing problem (and the optimal sequencing and buffer allocation problems asso-ciated to it). It is capable to immediately calculate the throughput of a complex line, bysimply receiving as inputs three arrays representing: the task times durations, the line con-guration (number of workcentres, of buffers within them, of parallel workstations in eachworkcentre, of tasks assigned to each workcentre), and the sequence of models enteringthe line. Its fastness and exibility allow its utilization in those algorithms and procedureswhere the evaluation of a tness function (which includes the throughput as performanceindicator) has to be performed several times. It allows overcoming the limit of using othersmeasures of throughput, presented in literature, that are poorly correlated to its real valuewhen the complexity of the line increases. The simulator is an expandable tool; in its cur-rent version provides the possibility to simulate both straight and U-shaped lines, and togenerate both random and xed sequences of models entering the line.

2012 Elsevier B.V. All rights reserved.Event and object oriented simulation to fast evaluate operationalobjectives of mixed model assembly lines problems

Lorenzo Tiacci Dipartimento di Ingegneria Industriale, Universit degli Studi di Perugia, Via Duranti 67, 06125 Perugia, Italy

a r t i c l e i n f o

Article history:

a b s t r a c t

In this paper an event and object oriented simulator for assembly lines is presented. The

relation of these (and any other) performance measures with the objective in question (i.e. the throughput) has to be ver-

36 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548ied 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, thediscrepancy between measure and throughput is in general expected to increase with the complexity of the line (e.g. parallelstations, 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 eld is to assist to the continuous development of sophisticatedalgorithms that try to take into consideration several aspects of real problems, but that point toward a wrong objective, be-cause 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 per-form some simulation runs. This approach is very time consuming because includes the time needed for building the modelfor each (different) line conguration, and to execute simulation run(s). Thus, it is usually adopted only to analyze the nalsolution obtained by an algorithm, but cannot be utilized in the very process of nding solutions, when many evaluations ofdifferent lines congurations have to be done (consider for example how many times a tness function has to be evaluatedby a genetic algorithm).

The aim of this work is to show how to overcome the limit of using performance measures instead of simulated through-put, by the use of a parametric simulator for mixed model lines, able to model and simulate different solutions in such aquickly way that it can be used iteratively in algorithms and procedures. At this scope, a Java based event oriented simulatoris presented. The tool is capable to immediately model a complex line and to calculate its throughput (and others perfor-mances indicators) by simply receiving as inputs three arrays representing: the task times durations, the line conguration(number of workstations, of buffers within them, of parallel stations in each workstations, of tasks assigned to each work-stations), 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 describesthe event-oriented approach utilized and the simulator structure. Implementation issues are discussed in Section 4. In Sec-tion 5 the simulator performances are tested, and execution times are compared both with a process-oriented implementa-tion 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 nd solution to the MAL-BP. Studies published in the last 10 years utilize different approaches, such as: Simulated Annealing [21,31], Ant techniques[22], Genetic Algorithms [27,29,25] and other heuristics [20,3,19,11,7,12].

In order to compare design alternatives, some metric have to be established. As in many industrial problems, in the MAL-BP a trade-off exists between costs (associated to labor and equipments) and performances. For this reason, objective func-tions of algorithms that nd solution to MALBP usually includes both these objectives. But while to calculate costs associatedto a determined line conguration is relatively easy (assuming that labor and equipments costs are known), to evaluate theperformances of a mixed model assembly line may be, as already mentioned, complicated. Thus, most of the above men-tioned studies uses some measure to estimate the throughput (taken as the main performance objective), but do not ad-dress the problem to verify the validity of such measures. Only two studies on MALBP directly address this problem,namely Bukchin [6] and Venkatesh and Dabade [34].

The work of Bukchin [6] is based on a comparison between ve performance measures for throughput with simulationresults. Three of them had already been proposed by other authors, namely the Smoothed Station measure [28], the Min-imum Idle Time measure [17] and the Station Coefcient of Variation [9], while the other two have been introduced by theunits of different models can be produced in an arbitrarily intermixed sequence. For a comprehensive classication of otherdifferent possible features of the GALBP see Becker and Scholl [5].

As the number of features that try to capture the complexity of real cases increases (e.g. mixed models, sequencing pol-icies, parallel workstations, buffers, stochastic task times) evaluating the performance of an assembly line become morecomplicated. Exact analytical methods for evaluating system throughput are not available. Thus, algorithms that have beendeveloped to solve the problem, and that need to evaluate line performances in order to compare design alternatives, usesome measures of the throughput, represented by parameters that are easily calculable (once the line conguration andthe 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 [6]. He argued that the only practical method to accu-rately evaluate throughput is a simulation study, which is very time consuming and hard to perform, and that for thisreason, instead, various performance measures are usually used in order to evaluate and compare design alternatives.To nd measures that can be correlated with the throughput, he observes for example that the allocation of assemblytimes to stations is characterized by two types of variability: a Model Variability (variability of assembly times of a cer-tain model assigned to different stations) and a Station Variability (variability of assembly times of different models as-signed to a specic workstations). These two types of variability are often considered correlated to blockage andstarvation, and, as a consequence, to high idle times within stations and, eventually, to low throughput. However, the cor-

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

L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548 37measures with the realized throughput, with best results obtained by the SI. Contrary to what found by Bukchin, the Bottle-neck showed a very low correlation with throughput. Authors selected other two operational objectives, besides thethroughput, to which compare their measures: the Model Variability, and the Station Variability. At this purpose, a consid-eration has to be done. Model Variability and Station Variability should not be considered operational objectives, but mea-sures correlated to an operational objective (the throughput). For example, the fact that assembly times of different modelsare similar in each station (i.e. Station Variability is low), it is not an objective in itself, but a (supposed) mean to achieve ahigh and stable throughput. Furthermore, while the throughput is difcult to estimate, the Model Variability and the StationVariability, for givens tasks assignments, can be calculated straightforwardly and do not need to be evaluated through ameasure.

More in general, methods that are developed to seek station assignments that lead to more balanced workloads acrossstations and across products are motivated to limit the effect, on the realized cycle time, of the sequencing of different mod-els on the assembly line. However, as outlined by Karabati and Sayin [12], these methods remain to be approximate ap-proaches, for the very reason that the effects of the sequencing decision on the line throughput are not incorporatedexplicitly. Due to the computational complexities involved, the assembly line balancing problem and sequencing problemsare 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 litera-ture on BAP mostly refer to ow-lines production systems, consisting in a linear sequence of several machines. The decisionto be taken is the amount of buffer space (used to avoid blockage and starvation to obtain high throughput) to install be-tween successive stages; production rates in each stage are assumed to be known. The same problem can be transposedto assembly lines, with the difference that production rates in each station depend on which tasks are assigned to it, thatis, on the result of the balancing procedure. Again, to obtain optimal results, buffer allocation and line balancing shouldbe performed together. Literature about MALBP does not address the possibility to install buffers within stations. This is per-haps due to the additional difculty 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 [6,34] on the correlation between performance measures and realized through-put are not consistent each other, sign that it is difcult to nd a throughput measure of general validity for all the pos-sible issues of the problem;

both studies consider deterministic task times and a relatively simple mixed model line conguration; a loss of correla-tion of the same performances measures with the simulated throughput is expected if task times are stochastic, and, ingeneral, 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 theMALBP 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 onthe line throughput has to be calculable.

3. The Assembling Line Simulator (ALS)

The aim of this work is to put at the scientic community and practitioners disposal an efcient, exible and expandabletool, named Assembly Line Simulator (ASL), able to quickly model and simulate complex assembling lines. Its main charac-teristics are the ability to quickly build the model of a line conguration and to fast execute the simulation run. These twocharacteristics allow it to be easily embedded in algorithms and procedures that nd solutions to MALBP, overcoming theabove 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 required by thesimulator. In Section 3.2 the object-oriented structure and the event-oriented logic through which the simulator has beenimplemented are described.author: the Model Variability and the Bottleneck. The latest one is obtained by estimating the expected value of the assem-bly time at the bottleneck station. Model Variability and Bottleneck have been found to outperform the other measures inshowing a better correlation with the simulated throughput. On the basis of these results, Bukchin et al. [7] incorporated theBottleneck into a balancing heuristic algorithm in order to compare the quality of solution for a MALBP, while Tiacci et al.[29] used a modied version of Model Variability in the tness function of a Genetic algorithm for balancing mixed modellines with parallel workstations and stochastic task times.

Venkatesh and Dabade [34] proposed other two measures, namely the Squared Based Model Deviation (SBDM), and theBMI, 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 tness function for a Genetic Algorithm to obtain solutions of a total of 3000MALBP instances. Then, a statistical analysis was conducted on these solutions to compare the performance measures with

3.1. Description of the model

In the line, each operator has a workstation (WS) where he performs one or more tasks. Each workcentre (WC) consists ofeither one workstation, for the case of non-paralleling, or multiple parallel workstations (see Fig. 1). Paralleling means thatwhen aWC consists of two or more workstations, all the tasks assigned to theWC are not shared among theWS, but eachWSperforms 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 timelarger than the desired cycle time. However, also if any given task time does not exceed cycle time, the possibility to replicateworkstations may be desirable, because it enlarges the space of feasible solutions of the balancing problem, including manyfeasible and potentially better balanced congurations (Vilarinho, 2002; [29]).

The line is asynchronous, that is as well as blockage and starvation are possible. One WC with multiple WSs is consideredbusy if every WS inside is busy. If a WS nishes its work on a workpiece while the subsequent WC is still busy (or the sub-sequent buffer is full), the workpiece can not move on, and remains in the current WS keeping it busy (blocking after pro-

3.1.2. Task times of completion

we are dealing with mixedmodel lines, the number of models (types of product) to be assembled can be higher than one, andit nre s

mgeneral, time units). It is noteworthy that if the completion of a model does not require the execution of a certain task, this

38 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548would result in a 0 in the corresponding matrix element.

3.1.3. Representation of a line congurationA line conguration represents a specic 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).

operatorworkstationwork centre

buffers

Fig. 1. An assembly line with parallel workstations and buffers.odel requires 7 tasks to be completed. For example the average task time of task #4 of model #0 is equal to 5 min (or, in

The 2 7 matrix depicted in Fig. 2 represents the case in which 2 types of products (models) have to be assembled; each

pre ent the average completion time of task i on model type j.

is i dicated by m (numbered with j = 0, . . . ,m 1). Input data are thus represented by an n m matrix tij whose elementsA set of n tasks (numbered with i = 0, . . . ,n 1) has to be performed in the line in order to complete each product. Becausecessing policy); the WS will be released (i.e. will be able to process another workpiece) only when the workpiece leaves theWS.

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 rst WC is never starved (there is always raw material for the rst WC) and the last station is never blocked (there isalways storage space for the nished product).

3.1.1. Notation

i task index (i = 0, . . . ,n 1)j model index (j = 0, . . . ,m 1)k workcentre index (k = 0, . . . ,p 1)tij time required by model j in workcentre i

The line conguration 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 rst element is the number of WSs assigned tothe WC: a number higher than 1 means parallel WSs. The second element represents the size of the buffer placed before the

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

a bFig. 2. (a) The tij array representation. (b) Tabular representation of input task times.

L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548 39WC: 0 means no buffer. The subsequent elements represent the tasks assigned to the WC. Note that rows do not necessarilycontain the same number of elements. For example, Fig. 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 becausethere are always raw materials for the rst WC, the buffer before WC#0 is useless, having no impact on the line throughput,and its size should be set to 0.

3.1.4. Model sequencingThe 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 numbersin the array (whose length can be arbitrarily chosen) is taken as reference for the generation of different model types enter-ing the line.

3.1.5. Stochastic task timesIn 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 [32]. In this rst version of ALS, task times duration can

WC# WSs assigned

Buffer size

Tasks assigned lckz = { { 2, 0, 1, 3, 6 }, 0 2 0 1, 3, 6 1 1 0 2, 0 2 1 1 5, 4

{ 1, 0, 2, 0 }, { 1, 1, 5, 4 } }

1, 3, 6

2, 0 5, 4

a b

cFig. 3. (a) The lckz two dimensional array. (b) Tabular representation. (c) Graphical representation.

40 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548be modeled, through the denition of the string distType, in three ways: deterministic (distType = DET), normally distrib-uted (distType = NORM), and exponentially distributed (distType = EXP). Deterministic task times are exactly dened bythe matrix tij. If task times are normally distributed, the standard deviation rij of the completion time of task i for model j istaken equal to its mean value (tij) multiplied by a coefcient of variation cv (rij = cv tij). If task times are exponentially dis-tributed, the density function of completion time is characterized by the single parameter tij (equal to the mean value and thestandard deviation).

3.2. Implementation

ALS has been developed in Java, basically because the Java language is intrinsically clear and concise; the application canbe easily distributed (deployed) through a single le (.jar), it is multiplatform, and there is no need of any legacy software todeal with. The simulator has been implemented using SSJ [15,16], a package for discrete event simulation in Java. SSJ (whichstands for Stochastic Simulation in Java) is an organized set of software tools offering general-purpose facilities for stochasticsimulation programming in Java. It supports the event view, process view, continuous simulation, and arbitrary mixtures ofthese.

ALS is built using the object oriented-approach of Java and the event-oriented approach provided by SSJ. The event-ori-ented simulation approach is also referred in literature as event-driven simulation or event-scheduling approach. In thisapproach a system is modeled by identifying its characteristic events and then writing a set of event routines that give adetailed description of the state changes taking place at the time of each event. The simulation evolves over time by execut-ing the events in increasing order of their time of occurrence [14,33,4].

To implement the simulator 4 classes, representing the physical conguration, have been dened (see Fig. 4 for the sim-plied UML class diagram): Line, WorkCentre, Workstation and Load.

The relations between these classes reproduce the relations between the corresponding entities in real world: an assem-bly line is formed by a set of WCs (List workCentre); each WC has a number of WS, some of which are available for loadsprocessing (List freeWorkStation). Each WC has a virtual queue represented by the list of the loads (i.e. workpieces) thatare waiting to be processed on the WC (List loadScheduled); a number of elements of this queue equal to theWCs buffersize (int bufferSize) is physically in the buffer of the WC, while the remaining elements are still waiting in the precedingWC. Each time that a load starts being processed in the WC, one WS is removed from the freeWorkStation List. If this list isempty 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 simula-tion. Each type of event must be dened by implementing an extension of this class. ALS is built using two main types ofevents, namely FinishProcessingEvent and StartProcessingEvent, which are implemented through two classes thatextend the Event class. A FinishProcessingEvent is associated to each load (relation 1:1 in Fig. 4), and it happens whenever aload has nished to be processed in a WC. A StartProcessingEvent is associated to each WC (relation 1:1), and represents theevent of the WC that starts processing a load. Their method actions () describes the actions that are performed each timethe event, associated to the corresponding entity (load or WC), happens. In this way it is not necessary to create a new eventeach time that a WC starts processing a load, or each time a load nishes to be processed in a WC. Instead, the same eventassociated 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 rst event inthe event list, that is, to be executed at the current time (as the next event). The method schedule(double delay) sched-ules an event to happen in delay time units, i.e., at current time + delay, by inserting it in the event list.

Fig. 4 shows only the main relationships among classes. Some arrows and lines have been omitted in the UML diagram toallow an acceptable readability. The FinishProcessingEvent class has a relation with WorkCentre whose cardinality is 1:2. Infact, when a load nishes to be processed, it is linked to two WCs: the WC in which the load has just been processed (Work-Centre currWC) and the one subsequent to the current one (WorkCentre nextWC). In that moment each load can schedulethe StartProcessing event associated to this two WCs (see Fig. 5). Even the StartProcessingEvent class is related to Loadthrough a relationship whose cardinality is 1:2, because, as described in the next paragraph, when a StartProcessing eventhappens, actions on the load that is going to be processed (startWorkingLoad) and on the load that is entering the bufferfrom the preceeding WC (enteringBufferLoad) have to be performed.

Through this architecture, each load and workstation can schedule, through their StartProcessing and FinishProcessinginstances, events associated to other instances. In the following, the actions () methods of the two classes StartProcess-ingEvent and FinishProcessingEvent are described in detail. Fig. 5 summarizes the events that are scheduled when StartPro-cessing and FinishProcessing events happens.

3.2.1. Actions associated to StartProcessingEventActions 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 twoconditions are both veried:

(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);

L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548 41If both conditions a and b are veried, the WC is ready to work. The method readyToWork () check if this two conditionsare true.

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

remove the rst load in the loadScheduled List (startWorkingLoad: the load starting being processed in one of the WSof 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 P than the buffer size (i.e. a load has already been processed in theprevious 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.

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

42 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 35483.2.2. Actions associated to FinishProcessingEventActions associated to the FinishProcessing event are performed when a load has just nished to be processed in a WC. The

point of view of a load passing through the assembly line (from oneWC to the subsequent one) is assumed, and the followingnotation is utilized: WorkCentre currWC indicates the WC the load is leaving from, that is the WC in which the load has justbeen 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 WSin currWC)

if there is space in the buffer of nextWC (number of loads in the loadScheduled List of nextWC < buffer size), then:

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

L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548 43 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 rst 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 scheduledto happen at the current time;

3.2.3. Loads creationIn order to start the simulation, a rst event, corresponding to the rst load entering the line, has to be scheduled to hap-

pen at time zero. This rst event corresponds to a FinishProcessing event of the load in a virtual WC numbered -1 (i.e. a vir-tual WC before the rst WC in the line). When this event happens, the rst load passes fromWC#-1 to WC#0, and, triggeringthe StartProcessing event related to WC#0, starts up the recursive event scheduling and re-scheduling that allow the sim-ulation to go on. When a load nishes to be processed in the rst WC (WC#0), it triggers the creation of a new load enteringthe line, by scheduling a FinishProcessing event of a new load in WC#-1.

3.2.4. Inputs requiredALS is contained in a package named lineSimulator, which provides the public class Simulation, whose constructor re-

quires 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 conguration, the array s (int [] s) that denes the sequence of models enteringthe line, the string distType representing the task times distribution (String distType), the coefcient of variation cv (dou-ble cv) which is inuent only if distType = NORM, the simulation length (double simLength).

3.2.5. Outputs providedWhen 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 ofclass Tally collect data that comes as a sequence of real-valued observations. It can compute sample averages, sample stan-dard deviations and condence intervals on the mean based on the normality assumption. Class Tally is included in the pack-age 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 theline. Line throughput and WIP are derived: average throughput is calculated as the average cycle time inverse. AverageWIP is calculated, using the Little law, as the product between average values of throughput and ow time.

3.2.6. Graphical user interface (GUI)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 (Fig. 6). It allows to manually insert all the inputs required, included task times and lineconguration information (that can also be loaded from and saved to text les), and to display outputs and execution time ofthe simulation run.

3.2.7. Event and process oriented versionsThe nal version of ALS is built using the event oriented approach, as described above. However, ALS has also been real-

ized in other two versions, using two different process-oriented approaches, named process oriented and 2p implemen-tation (for details, see [30]). These two versions have been implemented using both the already mentioned package SSJ, andanother package for process-based discrete event simulation, named JavaSimulation [10]. A process is a time-ordered se-quence of interrelated events separated by intervals of time, which describes the entire experience of an entity as it owsthrough a system. The process-oriented paradigm is a natural way of describing complex systems [14] and often leads tomore compact code than the event-oriented view. Unfortunately many simulation environments, including the Java pack-ages JavaSimulation and SSJ, implement processes through threads. This adds signicant overhead, prevents the use of a verylarge number of processes in the simulation and slows the simulation execution [16], as the experiments described in thenext section conrmed.

3.3. Validation

We validated our model through two widely adopted techniques (see [14]. The rst 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 compar-ison. The second one, that is an extension of the rst one, is to run the model under simplifying assumptions for which itstrue characteristics are known and, again, can easily be computed.

Using the rst approach it is possible, on the basis of queuing theory, to exactly calculate the throughput of a single prod-uct assembly line with exponentially distributed task times, both for the case of two stations with a buffer of size N betweenthem, and in the case of three stations without buffers (see [1]. The capability to appropriately model lines in which multiplemodel are assembled and stations can be duplicated (paralleling) has been validated through the second approach. In this

44 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548case using deterministic task times it is possible to easily calculate ow time and throughput or different simple linecongurations.Fig. 6. The graphical user interface of ALS.4. ALS Performances

ALS have to be evaluated on the basis of its fastness in providing the simulated throughput of a line conguration, giventhat 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 Fig. 2, the lineconguration reported in Fig. 3, the sequence array s = {0,0,1,1}, normal task times distribution with coefcient of variationequal to 0.2. Problem 2 is taken from a real case, presented in Mendes et al. [18], concerning a company that is a major man-ufacturer of consumer electronic goods; the system analyzed is the PC camera assembly line, in which three different ver-sions of a PC camera with some dissimilar technical specications are assembled. Task times and line conguration arereported in Tables 1 and 2. The sequence array is s = {0,1,2}, task times are normally distributed with coefcient of variationequal to 0.1.

Tables 3 and 4 shows ALS execution times and outputs (for Problem 1 and 2 respectively), varying the package used (Java-Sim and SSJ), the implementation (process oriented, 2p, and event) and the simulation length. Problem 1 and 2 have alsobeen modeled in Arena 11.0 [13], and execution times in batch mode (no animation) have been recorded. The aim is to

Table 1Problem 2: task times (in time units).

Task# Model# Task# Model# Task# Model# Task# Model# Task# Model#

0 1 2 0 1 2 0 1 2 0 1 2 0 1 2

0 2 2 2 8 2 2 2 16 6 6 6 24 4 4 4 32 4 4 41 2 2 2 9 10 10 10 17 7 7 7 25 6 6 6 33 2 2 22 2 2 2 10 3 0 0 18 3 3 3 26 5 5 5 34 2 2 23 2 2 2 11 11 11 11 19 28 37 33 27 0 0 2 35 1 1 14 2 2 2 12 4 4 4 20 3 3 3 28 1 1 1 36 1 1 15 0 11 11 13 0 4 4 21 8 8 8 29 3 3 3 37 1 1 16 0 0 16 14 9 9 0 22 5 5 5 30 3 3 3 38 1 1 17 21 39 37 15 13 13 12 23 7 7 9 31 0 0 3

L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548 45Table 2Problem 2: line conguration.

WC# WS assigned Buffer size Tasks assigned

0 1 0 0, 1, 2, 3, 5, 6, 10, 141 2 0 4, 7, 8, 9, 12, 13, 18, 222 1 0 11, 15, 163 1 0 17, 204 2 0 19, 215 1 0 23, 24, 25, 26, 27, 28, 29, 30, 33, 366 1 0 31, 32, 34, 35, 37, 38

Table 3Execution times (sec) and outputs of Problem 1.

Sim. length (time units) ALS Arena

Process oriented 2p implementation Event (SSJ)

JavaSim SSJ JavaSim SSJ

100,000 1.26 1.12 0.73 0.501 0.025 0.265400,000 4.65 4.07 2.57 1.98 0.109 0.777700,000 8.12 7.04 4.36 3.46 0.187 1.2811000,000 11.30 10.04 6.26 4.84 0.266 1.77710,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.compare ALS performances with one of the most widely used software in the industrial eld for the simulation of manufac-turing and material handling systems [2], which also provides one of the most efcient simulation engine among many com-mercial simulation software [8]. All simulations have been performed on a computer with an AMD Athlon X2 Dual CoreProcessor 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 packageSSJ over JavaSimulation, and an appreciable superiority of the 2p implementation over the process orented version. Somedata, corresponding to simulation length equal to 10,000,000 time units, is not available (na), due to thread synchronizationerrors that arise when processes, like in this two versions, are implemented as threads. For other considerations about rela-tions between execution times, throughput and WIP for these two versions, see Tiacci and Saetta [30].

Execution times are drastically reduced using the event oriented version of ALS, which abundantly outperforms also Are-na (proving to be about from 10 to 5 times faster). Furthermore, Arenas execution times only include the simulation runtime, excluding the time needed to develop the model for the specied line congurations, that are, on the contrary, intrin-sically 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, thathave to evaluate different line congurations several times, becomes possible. For example, solving Problem 2 through thegenetic algorithm approach proposed in Tiacci et al. [29] would require to perform a total of 50,000 tness evaluations (i.e.throughput estimations). Considering a simulation lengths of 100,000 time units, using ALS to obtain the simulated through-put would require an extra CPU-time equal to (50,000 0.047) = 2350 s, that is little more than 39 min. This amount of time isquite 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, forProblem 2, very high. To approximately quantify this accuracy, 40 replications of 100,000 time units length have been per-formed, and average (l = 34.453) and standard deviation (r = 0.0432) of the simulated mean cycle times have been calcu-lated. The interval corresponding to an amplitude of 3r is equal to 0.1296, that is just 0.37% of the average value.Confounding the unbiased estimators l and r with the true values and assuming a normal distribution, the approximate

Table 4Execution times (sec) and outputs of Problem 2.

Sim. length (time units) ALS Arena

Process oriented 2p Implementation Event (SSJ)

JavaSim SSJ JavaSim SSJ

100,000 1.93 1.89 0.72 0.65 0.047 0.359400,000 7.11 6.86 2.66 2.25 0.181 0.984700,000 12.49 11.87 4.4 3.76 0.32 1.5741000,000 18.00 16.90 6.42 5.44 0.456 2.18310,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.

the

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

46 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548(or higher than) the number of tasks assigned to the WC, all tasks will be performed in the rst 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 thelckz array (i.e. the rst two columns) are ignored.A warm-up period w (double w) has been introduced, during which statistics are not collected. The total duration of thesimulation 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 propor-tion 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 species the demand proportion of model j with respect to total demand, so that each time a new load iscreated, the probability that its model type is j is equal to:

Pj demPropjPjdemPropj

This kind of random generation is performed when the value of the boolean input randomSeq (boolean randomSeq) istrue. Otherwise, the sequence of models assembled through the line is dened by the array s, as described in Section 3.1.4.

the possibility to model U-shaped lines [23], in which stations may work at two segments of the line facing each othersimultaneously;

In U-shaped assembly lines, stations can be arranged so that two loads at different positions on the line can be handled. Asdepicted in Fig. 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 differ-ence 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 nished until the product returns to station k for the second time (cf. [24]. It isnoteworthy that every solution feasible for straight lines is feasible for an U-line, because an U-line does not need to includecrossover WC. However, U-shaped lines provides much more possibilities of combining tasks to WCs, and this impliesincreasing possibilities to nd 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 deni-tion of an array uk (int [] u) is required in order to dene the number of tasks of a WC k that are performed in the rst sideof 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 rst two tasks (1,3) are done in the rst side, while the remaining tasks (12,13)possibility to dene a warm-up period;probability that the cycle time, provided by a single simulation run, falls between 0.37% of the real value would be equal tothe 99.7%. This accuracy is presumably much higher than any other measure, not simulation-based, might provide. If a loweraccuracy is acceptable, the simulation length can be shortened, allowing to further limit the extra CPU-time required by ALS.

5. Improvements

ALS is an expandable tool, and can benet from several libraries available for Java. Once the core of the simulator, con-sisting in the object structure (Fig. 4) and the logic of actions methods (Sections 3.2.1 and 3.2.2), has been dened manyimprovements 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 com-pletion time described by a specic statistical distribution.

The implementation of this feature has been done using the package randvar of SSJ, that provides a collection of classesfor non-uniform random variate generation. Inputs related to task times described in Section 3.2.4 (i.e. tij, distType, cv), hasbeen replaced with three arrays, namely: distTypeij = distribution of completion time of task i on model type j (String [][]distType), pij = rst parameter of the distribution distTypeij (double [][] p), p2ij = second parameter of the distributiondistTypeij (double [][] p2). In this way the following single and double parameter distributions have been modeled:DET = deterministic, GEO = geometric, LOG = logarithmic, POIS = Poisson, EXP = exponential, CHI = chi;NORM = normal, UNIF = uniform, GAM = gamma, ERL = Erlang, BIN = binomial. If the distribution distTypeij requiresonly one parameter, the corresponding p2ij values are ignored. If the distribution requires an integer parameter instead of adouble one (e.g. chi and Erlang distributions), double values are casted to integer.

L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548 47a b

cFig. 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 nextimprovements 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 consid-ering highly skilled workers, capable of performing a wide range of activities (for details see [7]);

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 ow lines, with unreliable machines and stochastic failure and repair times.

6. Summary

The simulator presented herein, named Assembly Line Simulator (ALS), can be used as supporting tool in nding solutionof 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 parallelstations, buffers within workstations, in which a variety of models have to be assembled in a mixed way, following adetermined input sequence, with stochastic task times of completion;

it is modular, because it is object-oriented: different lines congurations (with different number of workstations, tasksassignments, number of buffers, etc.) can be created by the mean of very simple array representations, so that timerequired for building the model is zeroed;

it is very fast, because it is event-oriented: the simulation run is performed only by events scheduling, re-scheduling, can-celling etc.; by avoiding the use of processes, execution times are kept very low (in some cases less than a tenth of sec-ond), arriving to outperform Arena.

These characteristics allows it to be effectively coupled to those algorithms and procedures where numerous variants ofline congurations have to be simulated, and the evaluation of a tness function (which includes some line performancesindicator, 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 arepoorly correlated to its real value. This lack of correlation increases with the complexity of the line, and this is one of thereasons 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 traditionalapproaches.

ALS has been developed with the scope to be usable by researchers and practitioners. For this reason it has been devel-oped in Java, a language that guarantees the compatibility with multiple platforms. ALS package is available as a freewaresoftware from the authors web page [35] and from the Homepage for assembly line optimization research [36].

48 L. Tiacci / Simulation Modelling Practice and Theory 24 (2012) 3548References

[1] Tayfur Altiok, Performances Analysis of Manufacturing Systems, Springer, 1997.[2] A. Anglani, A. Grieco, M. Pacella, T. Tolio, Object-oriented modeling and simulation of exible manufacturing systems: a rule-based procedure,

Simulation Modelling Practice and Theory 10 (2002) 209234.[3] R.G. Askin, M. Zhou, A parallel station heuristic for the mixed-model production line balancing problem, International Journal of Production Research

35 (11) (1997) 30953105.[4] J. Banks, J. Carson, B. Nelson, D. Nicol, Discrete-event system simulation, Fourth ed., Prentice Hall, 2004.[5] C. Becker, A. Scholl, A survey on problems and methods in generalized assembly line balancing, European Journal of Operational Research 168 (2006)

694715.[6] J. Bukchin, A comparative study of performance measures for throughput of a mixed model assembly line in a JIT environment, International Journal of

Production Research 36 (1998) 26692685.[7] J. Bukchin, E.M. Dar-El, J. Rubinovitz, Mixed model assembly line design in a make-to-order environment, Computers and Industrial Engineering 41

(2002) 405421.[8] A. Cimino, F. Longo, G. Mirabelli, A general simulation framework for supply chain modeling: state of the art and case study, International Journal of

Computer Science Issues 7 (2) (2010). No 3.[9] F. Fremerey, Model-mix balancing: more exibility to improve the general results, in: M. Pridham, C. OBrien (Eds.), Production Research: Approaching

the 21st Century, Taylor & Francis, London, 1991, pp. 312314.[10] K. Helsgaun, Discrete Event Simulation in Java, Department of Computer Science, Roskilde University, Denmark, 2004. .[11] M. Jin, S.D. Wu, A new heuristic method for mixed model assembly line balancing problem, Computers and Industrial Engineering 44 (2002) 159169.[12] S. Karabati, S. Sayin, Assembly line balancing in a mixed-model sequencing environment with synchronous transfers, European Journal of Operational

Research 149 (2003) 417429.[13] W.D. Kelton, R.P. Sadowski, D.T. Sturrock, Simulation with Arena, McGraw-Hill, New York, 2004.[14] A.M. Law, W.D. Kelton, Simulation Modeling and Analysis, Third ed., McGraw-Hill, New York, 2000.[15] P. LEcuyer, L. Meliani, J. Vaucher, SSJ: a framework for stochastic simulation in Java, in: Proceedings of the 2002 Winter Simulation Conference, IEEE

Press, 2002, pp. 234242.[16] P. LEcuyer, E. Buist, Simulation in Java with SSJ, in: Proceedings of the 2005 Winter Simulation Conference, IEEE Press, 2005, pp. 611620.[17] J.L.C. Macaskill, Production-line balances for mixed-model lines, Management Science 19 (1972) 423434.[18] A.R. Mendes, A.L. Ramos, A.S. Simaria, P.M. Vilarinho, Combining heuristic and simulation models for balancing a PC camera assembly line, Computers

and Industrial Engineering 49 (2005) 413431.[19] C. Merengo, F. Nava, A. Pozetti, Balancing and sequencing manual mixed-model assembly lines, International Journal of Production Research 37 (1999)

28352860.[20] P.R. McMullen, G.V. Frazier, A heuristic for solving mixed-model line balancing problems with stochastic task durations and parallel stations,

International Journal of Production Economics 51 (1997) 177190.[21] P.R. McMullen, G.V. Frazier, Using simulated annealing to solve a multiobjective assembly line balancing problem with parallel workstations,

International Journal of Production Research 36 (10) (1998) 27172741.[22] P.R. McMullen, P. Tarasewich, Using ant techniques to solve the assembly line balancing problem, IIE Transactions 35 (2003) 605617.[23] J. Miltenburg, J. Wijngaard, The U-line line balancing problem, Management Science 40 (1994) 13781388.[24] Y. Monden, Toyota production systemAn integrated approach to just-in-time, third ed., Kluwer, Dordrecht, 1998.[25] A. Noorul Haq, J. Jayaprakash, K. Rengarajan, A hybrid genetic algorithm approach to mixed-model assembly line balancing, International Journal of

Advanced Manufacturing Technologies 28 (2006) 337341.[26] A. Scholl, C. Becker, State-of-the-art exact and heuristic solution procedures for simple assembly line balancing, European Journal of Operational

Research 168 (2006) 666693.[27] A.S. Simaria, P.M. Vilarinho, A genetic algorithm based approach to the mixed-model assembly line balancing problem of type II, Computers and

Industrial Engineering 47 (2004) 391407.[28] N.T. Thomopoulos, Mixed model line balancing with smoothed station assignments, Management Science 16 (1970) 593603.[29] L. Tiacci, S. Saetta, A. Martini, Balancing mixed-model assembly lines with parallel workstations through a genetic algorithm approach, International

Journal of Industrial Engineering, Theory, Applications and Practice 13 (2006) 402411.[30] L. Tiacci, S. Saetta, Process-oriented simulation for mixed-model assembly lines, in: Proceedings of the 2007 Summer Computer Simulation Conference,

SCSI, San Diego, 2007, pp. 12501257.[31] P.M. Vilarinho, A.S. Simaria, A two-stage heuristic method for balancing mixed-model assembly lines with parallel workstations, International Journal

of Production Research 40 (6) (2002) 14051420.[32] WE. Wilhelm, On the normality of operation times in small-lot assembly systems: a technical note, International Journal of Production Research 25 (1)

(1987) 145154.[33] B.P. Zeigler, H. Praehofer, T.G. Kim, Theory of modeling and simulation: Integrating discrete event and continuous complex dynamic systems, second

ed., Academic Press, Berlin, 2000.[34] J.V.L. Venkatesh, B.M. Dabade, Evaluation of performance measures for representing operational objectives of a mixed model assembly line balancing

problem, International Journal of Production Research 46 (22) (2008) 63676388.[35] L. Tiacci, Department of Industrial Engineering, University of Perugia, Italy, 2012. Available from: .[35] A. Scholl, Homepage for Assembly Line Optimization Research. Available from: .

Event and object oriented simulation to fast evaluate operational objectives of mixed model assembly lines problems1 Introduction2 Operational objectives and their measures3 The Assembling Line Simulator (ALS)3.1 Description of the model3.1.1 Notation3.1.2 Task times of completion3.1.3 Representation of a line configuration3.1.4 Model sequencing3.1.5 Stochastic task times

3.2 Implementation3.2.1 Actions associated to StartProcessingEvent3.2.2 Actions associated to FinishProcessingEvent3.2.3 Loads creation3.2.4 Inputs required3.2.5 Outputs provided3.2.6 Graphical user interface (GUI)3.2.7 Event and process oriented versions

3.3 Validation

4 ALS Performances5 Improvements6 SummaryReferences