Assembly Line Simulator

0 downloads 0 Views 1MB Size Report
Nov 2, 2015 - 2.6 Simulation length and warm-up period. 7 ... The possibility to indicate different coefficients of variation for each ... assigned to the WC are not shared among the WS, but each WS .... and model #1 have the same probability to enter the line, while a ..... the tasks assigned to the WC (separated by spaces).
L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

ALS Assembly Line Simulator v. 2.2 – November 2015

By Lorenzo Tiacci*

*Prof. Lorenzo Tiacci, Phd Università degli Studi di Perugia Dipartimento di Ingegneria Via Duranti, 93 – 06125 Perugia - Italy Tel: +39-0755853741 e-mail: [email protected] web: http://impianti.dii.unipg.it/tiacci

1

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

Index 1

Introduction 1.1

2

3

new features

Straight Lines - The conceptual model

3 3 4

2.1

Notation

4

2.2

Task times of completion

5

2.3

Representation of a line configuration

5

2.4

Model sequencing

6

2.5

Stochastic task times

7

2.6

Simulation length and warm-up period

7

U-Shaped Lines - The conceptual model 3.1

Representation of a line configuration

3.2

Other features

8 8 10

4

Downloading and installing

11

5

Using ALS as a library

12

5.1

13

5.1.1

Constructor

13

5.1.2

Attributes

14

5.1.3

Example

14

5.2

6

Straight lines – the package ‘lineSimulator’

U-Shaped lines – the package ‘lineSimulatorU’

16

5.2.1

Constructor

16

5.2.2

Attributes

17

5.2.3

Example

17

Using ALS as an application

19

6.1

Inputs

19

6.2

Outputs

21

7

Source code

22

8

Licence

22

2

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

1

Introduction

ALS (Assembly Line Simulator) is a Java based simulator for mixed model assembly lines. ALS is the result of the ALS Research Project (http://impianti.dii.unipg.it/tiacci/English/research/ALS.html), and has been developed with the scope to be usable by researchers and practitioners. The simulator is divided in two packages, lineSimulator and lineSimulatorU, each corresponding to two different conceptual models of assembly lines: straight lines (package lineSimulator) and U-shaped lines (package lineSimulatorU). In Sections 2 and 3 the conceptual models related to straight lines and U-shaped lines are defined.

1.1 New features The basic features of ALS are:

-

version 1.0 simulation of mixed model, unpaced straight lines Buffers between work centres parallel workstations in each workcentre task times: deterministic, normally or exponentially distributed Outputs: throughput, cycle time, flow time, WIP, number of loads completed deterministic input sequence of models

In the following the new features introduced are listed:

-

-

-

-

version 1.1 Inputs related to simulation length: now it is possible to indicate or the length in time units, or the number of loads that have to be completed; Outputs related to buffers utilization statistics (time persistent average value; maximum value) version 1.2 The possibility to define a warm-up period, during which statistics are not collected. The warm-up period can be indicated both in time units and in a number of loads that have to be completed. version 2.0: The possibility to model U-shaped lines, in which stations may work at two segments of the line facing each other simultaneously version 2.1: The possibility to generate a random input sequence of models, respecting a specified demand proportion of models. version 2.2: Bug correction for random sequence of models entering U-shaped lines The possibility to indicate different coefficients of variation for each task (library version) Javadoc documentation (library version) available The possibility to copy and paste from/to task times and line configuration tables from/to Excel spreadsheets (application version)

3

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

2

Straight Lines - The conceptual model

In the line, each worker 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.

buffers

worker workstation work centre

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 load while the subsequent WC is still busy (or the subsequent buffer is full), the load cannot 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 load) only when the load 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)

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

4

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

2.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. Model# tij={{ 10, 8 }, { 3, 9 }, { 8, 8 }, { 7, 8 }, { 5, 9 }, { 6, 10}, { 13, 2 }}

a.

Task#

0

1

0

10

8

1 2

3 8

9 8

3 4

7 5

8 9

5 6

6 13

10 2

b.

Figure 2

a. The tij array representation. b. Tabular representation of input task times.

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

5

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

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

WC#

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

0 1 2

WSs assigned 2 1 1

a.

Buffer size 0 0 1

Tasks assigned 1, 3, 6 2, 0 5, 4

b.

1, 3, 6 2, 0

5, 4

c.

Figure 3

a. The lckz two dimensional array. b. Tabular representation. c. Graphical representation.

2.4 Model sequencing The simulator allows two way of define the model sequencing, depending on the value assumed by the boolean variabale named randomSeq. If randomSeq is false, the input sequence of models is deterministic, and it is represented by an array of integers s. For example, in case of two models (#0 and #1) the array s = {0,0,1,1} means that after two model#0, two model#1 will be assembled, and so on. s = {0,1,0,1} means that the two models are alternated. The sequence of numbers in the array (whose length can be arbitrarily chosen) is taken as reference for the generation of different model types entering the line. If randomSeq is true, the sequence of models entering the line is random, but respects a determined demand proportion among different model types (to simulate a JIT environment). In this case the array s has to contain a number of elements equal to the number of models. Each sj value specifies the demand proportion of model j with respect to total demand, so that each time a new load is created, the probability that its model type is j is equal to:

6

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

Pj =

sj

sj j

For example, in case of two models, a vector s = {50,50} means that when a new load is created, model #0 and model #1 have the same probability to enter the line, while a vector s = {70,30} means that with a probability of 70% a new model #0 will enter the line, against a probability of 30% for model #1.

2.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 the coefficient of variation cvi (ij = cvi . 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).

2.6 Simulation length and warm-up period The simulation length (simLength) can be indicated or in time units (the same as tij) or in a number of loads that have to be completed. This depends on the value of the binary variable simType; if simType = 0, the simulation length is expressed in time units, if simType = 1 is expressed in number of loads that have to be completed. In both cases the value indicated in simLength does not include the warm-up period (warmUpPeriod), that is expressed in the same unit as simLength (i.e. time units or number of loads). During the warm-up period statistics are not collected.

7

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

3

U-Shaped Lines - The conceptual model

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 4c, a WC may consist of one worker 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.4c), loads can be processed alternatively into one of the WSs (WS#0 and WS#5 in WC#0, and WS#2 and WS#4 in WC#2). So the difference to the straight line is that a WCk can contain not only tasks whose predecessors are assigned to one of the WC 0, . . . ,k, but also tasks whose predecessors will be finished until the product returns to station k for the second time. It is noteworthy that every solution feasible for straight lines is feasible for an U-line, because an U-line does not need to include crossover WC. However, U-shaped lines provides much more possibilities of combining tasks to WCs, and this implies increasing possibilities to find better solutions with respect to straight lines. In the current implementation, no buffers are assumed between WCs, and no other form of paralleling is considered. WSs are ordered following the visiting order of a load (WS#0 … WS#N). In figure 7 loads enter in WS#0 and exit from WS#5. The line is asynchronous, that is as well as blockage and starvation are possible. Two types of resources are used in this conceptual model: WS and worker. A WS is busy when a load physically occupies the WS, while when it is free it is able to receive another load from the preceding WS. A worker is busy when is performing the tasks on a load in a WS. Each time a worker finishes its work on a load, he is released, and tries to pass the load to the next WS. If there is place in the next WS, the current WS is released; the load passes to the next WS, and will be served as soon as the worker of the next WC is not busy. Each time a WS is released (i.e. a load move to the next WS), if there is a load in the preceding WS that is waiting to pass to the next WS (because it has already been worked in the preceding WS), the load passes to the current WS: the preceding WS is released, and the current WS is seized. If a worker finishes its work on a load while the subsequent WS is still occupied by another load, the load cannot move on, and remains in the current WS, keeping it busy. The WS will be released (i.e. will be able to receive another load) only when the load leaves the WS, i.e. when the next WS is released. Even if the load cannot move on, the worker is released, being able to work on a load in the WS at the other side of the line (in case of a cross-over WC). It is possible that when a worker is released in a crossover WC, two loads are claiming at the same time the worker, waiting to be worked in the two opposite WSs of a crossover WC. In this case the worker will give the precedence to the loads that had earlier finished to be processed in the preceding WS

3.1 Representation of a line configuration U-shaped lines can be simulated through ALS using the package linesimulatorU. With respect to straight lines, 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

8

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

example (see Figure 4) 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 (WS#0) of the WC, while the remaining tasks (12, 13) are done in the return side (WS#5). Note that if uk = 0, all the assigned tasks will be performed in the return side. If uk is equal to (or higher than) the number of tasks assigned to the WC, all tasks will be performed in the first side.

0

5

1

3

2

4

7

10

8 6

12

9

11

a.

lckz =

{ { 2, 0, 0, 2, 11, 12 }, { 3, 0, 1, 3, 4 }, { 1, 0, 5, 9, 10 } { 3, 0, 6, 7, 8 } }

WC#

uk

0 1 2 3

2 3 1 3

Tasks assigned 0, 2, 11, 12 1, 3, 4 5, 9, 10 6, 7, 8

c.

b.

Tasks assigned

Buffer size (ignored) 0 0 0 0

0, 2 WS#0

5

1, 3, 4 WS#1

WS#2

operator workstation work centre

WS#3 WS#5

WS#4

11, 12

9, 10

WC#0

WC#1

WC#2

6, 7, 8

WC#3

d. Figure 4

a. Precedence diagram. b. The lckz two dimensional array. b. Tabular representation. c. Graphical representation.

9

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

The line configuration can be thus represented also in this case by a two-dimensional array lckz (k = 0, …, p1), where p (the number of rows) represents the total number of WC in the line. Each row represents a WC. The first element is now the value of uk related to the WC. The second element represents the size of the buffer placed before the WC: 0 means no buffer. Because in the current implementation no buffers are assumed between WCs, this value is ignored (the input data has been kept for future implementation). The subsequent elements, as in the straight line case, represent the tasks assigned to the WC.

3.2 Other features Features related to model sequencing, stochastic task times, simulation length and warm-up period are the same as the straight line version of ALS, as described in sections 2.4, 2.5, 2.6.

10

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

4

Downloading and installing

The zipped ALS_x.zip file contains all the necessary files that allow ALS to be run in a computer, in which the Java Virtual Machine has been installed. It is recommended to download and install the last version of the JVM for your platform. Once the file has been unzipped, the following items are contained in the ALS folder:   





ALS_x.jar Readme.txt A “lib” folder containing the third parties libraries (jar files) utilized by ALS, that is: colt.jar, Helsgaun.jar, ssj.jar. The “lib” folder has to remain in this position during ALS_2 execution, i.e. in the same folder of ALS_x.jar file, both using ALS as a library and as an application. A “problems” folder, containing three folders named “problem1”, “problem2” and “problem U”. Each of them contains task times and line configuration files that can be loaded when using ALS as an application (see Section 6). Problems 1 and 2 are related to straight lines, while ‘problem U’ refers to U shaped lines. Other folders containing task times and line configuration related to published instances are present. A “javadoc” folder, containing the Javadoc documentation

11

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

5

Using ALS as a library

ALS has been designed 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. Using ALS with as a library simply requires the setup of the build path in order to tell the compiler (eg. NetBeans) where the classes can be found. A one-time setup is needed to link NetBeans with the classes, and a project-specific part adds ALS to a project's build path A project can be created using the New Project command in the File menu. The user then selects Java application in the dialog box that appears, and follows the instructions. After a project is created, it can be set up to use ALS as follows. In the Project tab of NetBeans, the user right-clicks on the name of the project that should use ALS, and selects Properties in the context menu that comes up. The user then selects the Libraries item in the left part of the dialog box that comes up. This results in a window similar to the next figure.

The user then clicks on the Add JAR/Folder button, and selects the ALS_1.jar file (or the name related to the current version of ALS) through the dialog box.

12

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

In order to use ALS as a library, the library has then to be imported (as any Java library, see the Example in Sections 5.1.3 and 5.2.3). In case of straight lines, the package linesimulator has to be imported; in case of U-shaped lines, the package linesimulatorU has to be imported.

5.1 Straight lines – the package ‘lineSimulator’ ALS for the simulation of straight lines is contained in a package named lineSimulator, which provides the public class Simulation, whose constructor and attributes are described in the following. The Simulation class does not provide any method. When a Simulation object is created the model of the assembly line is created, the simulation is performed and outputs are stored in the attributes described in Section 5.1.2. package lineSimulator public class Simulation Constructor public Simulation (String distType, double[] cv, int simulationLength, lengthType, int[] s, Boolean RandomSeq, double[][] taskTimes, int[][] lc)

int

warmUpPeriod,

int

Attributes public double cycleTimeAverage; public double cycleTimeSD; public double flowTimeAverage; public double flowTimeSD; public int loadsCompleted; public double tp; public double workInProgress; public double [] maxBufferLevel; public double [] avgBufferLevel; public double executionTime;

5.1.1 Constructor The public class Simulation constructor requires all the inputs described in Section 2:  

  



the string distType representing the task times distribution (String distType);”NORM” = normal distribution; “EXP” = exponential distribution; “DET” = deterministic. the array cv (double[]cv), representing the coefficient of variation of tasks 0,...,n-1. Note that a common coefficient of variation is assumed for different models. This parameter is influent only if distType = “NORM”; the simulation length (int simulationLength), expressed in time units or number of loads, depending on the value of lengthType. The warm-up period length, expressed in time units or number of loads, depending on the value of lengthType. the type of length indicated for the simulation and the warm-up period (int lengthType) =0 if the simulation length is expressed in time units; =1 if the simulation length is expressed as the maximum number of loads that have to be completed; the array s (int[]s) that defines the sequence of models entering the line, or the demand proportion for each model if the variable randomSeq is true (se Section 2.4);

13

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

  

the boolean variable randomSeq (boolean randomSeq), which determines the type of the input sequence of models in the line (se Section 2.4); the array tij of tasks times completion (double[][]t); the array lckz (int[][]lc) that describes the line configuration (see Section 2.3);

This is the complete version of the constructors, with all possible parameters. Other constructors, with a lower number of input parameters, are available. For details see the complete Javadoc documentation. 5.1.2 Attributes (Fields) 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:   

   

 



double cycleTimeAverage: the average vlue of cycle time during the simulation. Cycle time is

measured as the time that passes between two consecutive loads coming out from the line; double cycleTimeSD: the cycle time standard deviation; double flowTimeAverage: the average value of flow time during the simulation; 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; double flowTimeSD: the flow time standard deviation; int loadsCompleted: the number of loads that have been completed during the simulation; double tp: the average throughput, calculated as cycleTimeAverage inverse. double workInProgress: the average number of loads in the line; it is calculated (using the Little law) as the product between tp and flowTimeAverage (average values of throughput and flow time). double [] maxBufferLevel: the array containing the maximum buffers utilization during the simulation run. The arrays’ indexes correspond to the analogous WC#. double [] avgBufferLevel: the array containing the average (time persistent) buffers utilization during the simulation run. The arrays’ indexes correspond to the analogous WC#. double executionTime: the simulation execution time expressed in seconds. This includes the time needed to perform the warm-up period.

5.1.3 Example In the following an example of using ALS as a library is shown. In this example the required inputs are defined by code and correspond to a problem in which 3 models are assembled, and a line configuration with 7 workcentres is defined. The model sequence is deterministic. package example; import linesimulator.Simulation; public class Example { public static void main(String[] args) { String distributionType = "NORM"; int s [] = {0,1,2}; boolean randomSeq = false; int simLength = 100000; int warmUpPeriod = 100000; int lengthType = 1; double [][] tTimes = {{0, 0, 0},{2, 2, 2},{2, 2, 2},{2, 2, 2},{2, 2, 2},{2, 2, 2},

14

L. Tiacci / ALS – Assembly Line Simulator – V. 2.2

{0, {3, {6, {5, {1, {2, int lc [][] =

11, 11},{0, 0, 16},{21, 39, 37},{2, 2, 2},{10, 10, 10}, 0, 0},{11, 11, 11},{4, 4, 4},{0, 4, 4},{9, 9, 0},{13, 13, 12}, 6, 6},{7, 7, 7},{3, 3, 3},{28, 37, 33},{3, 3, 3},{8, 8, 8}, 5, 5},{7, 7, 9},{4, 4, 4},{6, 6, 6},{5, 5, 5},{0, 0, 2}, 1, 1},{3, 3, 3},{3, 3, 3},{0, 0, 3},{4, 4, 4},{2, 2, 2}, 2, 2},{1, 1, 1},{1, 1, 1},{1, 1, 1},{1, 1, 1}};

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

double cv [] = new double [tTimes.length]; Arrays.fill(cv, 0.1); Simulation sim = new Simulation(distributionType, cv, simLength, warmUpPeriod, lengthType, s, randomSeq, tTimes, lc);

System.out.println("cycleTimeAverage:\t"+sim.cycleTimeAverage); System.out.println("cycleTimeSD:\t"+sim.cycleTimeSD); System.out.println("flowTimeAverage:\t"+sim.flowTimeAverage); System.out.println("flowTimeSD:\t"+sim.flowTimeSD); System.out.println("loadsCompleted:\t"+sim.loadsCompleted); System.out.println("workInProgress:\t"+sim.workInProgress); System.out.println("tp:\t"+sim.tp); System.out.println("executionTime:\t"+sim.executionTime); System.out.println("WC#"+"\tavgBuff\tmaxBuff"); for (int k=0; k

Suggest Documents