using simulation early in the design of a fuel injector...

This article was downloaded by: [129.105.32.228] On: 06 August 2014, At: 15:02Publisher: Institute for Operations Research and the Management Sciences (INFORMS)INFORMS is located in Maryland, USA

Interfaces

Publication details, including instructions for authors and subscription information:http://pubsonline.informs.org

Using Simulation Early in the Design of a Fuel InjectorProduction LineMustafa H. Tongarlak, Bruce Ankenman, Barry L. Nelson, Laurent Borne, Kyle Wolfe,

To cite this article:Mustafa H. Tongarlak, Bruce Ankenman, Barry L. Nelson, Laurent Borne, Kyle Wolfe, (2010) Using Simulation Early in theDesign of a Fuel Injector Production Line. Interfaces 40(2):105-117. http://dx.doi.org/10.1287/inte.1090.0479

Full terms and conditions of use: http://pubsonline.informs.org/page/terms-and-conditions

This article may be used only for the purposes of research, teaching, and/or private study. Commercial useor systematic downloading (by robots or other automatic processes) is prohibited without explicit Publisherapproval, unless otherwise noted. For more information, contact [email protected].

The Publisher does not warrant or guarantee the article’s accuracy, completeness, merchantability, fitnessfor a particular purpose, or non-infringement. Descriptions of, or references to, products or publications, orinclusion of an advertisement in this article, neither constitutes nor implies a guarantee, endorsement, orsupport of claims made of that product, publication, or service.

Copyright © 2010, INFORMS

Please scroll down for article—it is on subsequent pages

INFORMS is the largest professional society in the world for professionals in the fields of operations research, managementscience, and analytics.For more information on INFORMS, its publications, membership, or meetings visit http://www.informs.org

http://pubsonline.informs.org

http://dx.doi.org/10.1287/inte.1090.0479

http://pubsonline.informs.org/page/terms-and-conditions

http://www.informs.org

Vol. 40, No. 2, March–April 2010, pp. 105–117issn 0092-2102 �eissn 1526-551X �10 �4002 �0105

informs ®

doi 10.1287/inte.1090.0479©2010 INFORMS

Using Simulation Early in the Design ofa Fuel Injector Production Line

Mustafa H. Tongarlak, Bruce Ankenman, Barry L. NelsonDepartment of Industrial Engineering and Management Sciences, Northwestern University, Evanston, Illinois 60208

{[email protected], [email protected], [email protected]}

Laurent BorneMcKinsey & Company, Chicago, Illinois 60603, [email protected]

Kyle WolfeDelphi Corporation, West Henrietta, New York 14586, [email protected]

In this paper, we describe how Delphi Corporation used simulation in the concept-development phase of a newmultimillion-dollar fuel injector production line. Delphi wanted to assess the financial viability of productiontargets and identify the critical features of the line on which it would focus its design-improvement efforts.

Key words : simulation: applications, design of experiments.History : This paper was refereed. Published online in Articles in Advance February 16, 2010.

Delphi Corporation is a major supplier of fuelinjectors to automobile manufacturers world-

wide. The company was considering a proposal for anew line that would produce the next generation offuel injectors. Its ambitious requirements on the line’sthroughput were essential for the project to be finan-cially viable; in addition, Delphi had to address con-straints on the space available for the line and on thecost to build it and staff it.

As envisioned, this production line will consist ofmultiple process segments, three of which will beplaced in a clean room (Figure 1).

Each process segment may contain as many as30 machines and robots that perform various tasks,along a series of conveyors that convey partially com-pleted fuel injectors from machine to machine in pal-lets. The conveyors will also act as buffers; they willaccumulate pallets in front of machines that are eitherdown or unable to keep up with the flow of pal-lets from upstream machines. Transfer of assembledfuel injectors between process segments will be donevia trays that are stacked in carts and moved man-ually by operators. Because contamination inside theclean room is a major concern, parts will be washedbefore they enter the clean room and operators willbe assigned tasks that do not require them to movebetween rooms.

Delphi commissioned a simulation model andstudy at a very early stage of designing the new line.The simulation model’s goal was to serve as a testbed for candidate production-line designs, includinginitial concept, fine-tuning, and examining process-improvement ideas after the line was operational.Simulating a line design must include fully specifyingwhich machines to use and in what order, conveyorlengths, machine process rates and variability, oper-ator responsibilities and priorities, failure and repairdistributions for each machine, and scrap and reworkrates on each machine. Such complete and detailedinformation is typically not available at the conceptstage of a line design; however, this is precisely whensimulation could be most valuable in helping Delphito assess the project’s financial viability and deter-mine where in the evolving line design to expendthe most effort. Using simulation at such an earlystage requires frequent and significant changes to thesimulation base model; these changes can be bothtime consuming and difficult to manage. However,the simulation recommendations are often inexpen-sive or free to implement because the equipment hasnot yet been built. After the equipment has been built,using simulation to analyze the process is less timeconsuming because the base model is no longer amoving target. The drawback is that much of the cost

105

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.

Tongarlak et al.: Using Simulation Early in the Design of a Fuel Injector Production Line106 Interfaces 40(2), pp. 105–117, © 2010 INFORMS

Cartridgeassembly

Injectorassembly

Calibrationand test

CLEAN ROOM

Subassemblies

RAIL ASSEMBLY

Injector

WHITE ROOM

Figure 1: The three process segments inside the clean room are complex,highly automated, and costly.

has already been sunk and the study’s recommenda-tions may be more difficult to cost justify. This wasour challenge.

Trying to optimize the design over the literallyhundreds of changeable features early on is sense-less because too little information is available andtoo much is in flux. Therefore, we used simulation toanswer high-level questions about the line configura-tion, with the understanding that the model wouldlater evolve into a representation capable of evaluat-ing very specific questions. That is, the simulation’sobjective was first to guide the development of newdesigns by distinguishing critical features and factorsfrom less-critical ones; later it would be updated asnew designs emerged. Thus, the simulation wouldprovide a perpetual road map for the next stepsin the design process. This paper describes the firstphase (about six months) of this iterative design pro-cess, a period in which answering high-level ques-tions about line configuration, conveyor layout, andoperator assignments was of primary concern. In theremainder of this paper, we will illustrate how sim-ulation can have a profound impact at the conceptstage of a complex project.

System Description and Data SourcesClearly, machines (including robots) and conveyorsmust be included in the simulation model. Mostmachines will keep running until a failure occurs aslong as they are not starved (because of a lack of

material) or blocked. Because conveyors can handlethe subassemblies within process segments, opera-tors are needed only for transferring assembled fuelinjectors between process segments, filling raw mate-rial buffers, repairing machines, and periodically per-forming other tasks, such as quality checks, rejectedfuel injector handling, and preventative maintenance.Although the system is semiautomated and opera-tors are only lightly involved with actual operations,their supporting role in the system is critical becausemachine failures will occur, and input buffers willbe consumed, leading to lost production if operatorsare unable to fulfill their required tasks. Therefore,in addition to machines and conveyors, the modelincluded operators, injector trays, and material carts.

Delphi represented line designs as AutoCAD draw-ings (that eventually became backgrounds for the sim-ulation animation). More importantly, the companyalso maintained a single Excel spreadsheet with manyworksheets, the manufacturing system design (MSD),which always contained the current state of knowl-edge about the line design. This included processinformation of all types from raw material buffer sizesand operator task assignments to anticipated machinereliability, processing time, and processing-time vari-ability. Because this information ranged from firmvalues and commitments to educated guesses, andwould evolve and expand throughout the project, weestablished a link between the MSD and the sim-ulation model to ensure that the simulation wouldalways be run using the most current data.

However, the MSD was more than just a datasource; we also used it to balance the line to producek fuel injectors each minute (k is a number that Delphiset and that we cannot reveal). In this semiautomatedsystem, which comprises a series of connected pro-cesses, “balancing” simply means that if a particularoperation is not able to produce the target k parts perminute, then Delphi adds enough parallel capacityto keep up with the production requirement. Becausethe line will operate for 24 hours per day, its pro-duction capacity would be 1,440k parts per day if wedid not have to deal with machine downtime, scrap,or process variability, and if material buffers wouldnever go empty. However, to be more realistic, theMSD also incorporated discount factors for the per-centage of scrap and downtime by machine, leading

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.

Tongarlak et al.: Using Simulation Early in the Design of a Fuel Injector Production LineInterfaces 40(2), pp. 105–117, © 2010 INFORMS 107

to a still optimistic throughput target of 1,225k fuelinjectors per day—approximately 22 percent less thanthe theoretical maximum. Achieving this target is nec-essary for the new fuel injector project to be finan-cially viable.

The target 1,225k fuel injectors per day may beoptimistic because a static analysis such as the MSDprovides cannot account for the impact of processvariability, starvation because of lack of material orblocking, operator response time to failures, conveyorcongestion, etc. More-accurate analysis of the pro-posed system requires the fidelity of a detailed sim-ulation model that considers the interactions amongall parts of the system and the randomness inherentto the system. The critical question that the simula-tion had to help us answer at the concept stage waswhether 1,225k fuel injectors per day was actually fea-sible and what Delphi would have to do to achieve it.

In the following subsections, we list some key sys-tem elements that were part of our analysis and men-tion any approximations we made.

ResourcesEach machine is prone to failure. Mean time beforefailure (MTBF) represents the average time a machineruns until a failure occurs. When a machine fails,it cannot produce parts until an appropriate opera-tor has arrived and fixed it, a period called down-time. The average repair time is denoted by meantime to repair (MTTR). The MTBF and MTTR are val-ues derived from information in the MSD. We mod-eled the distributions of the time to failure and repairas exponential; we chose the exponential distributionbecause, in the absence of real data, it can be specifiedby a single parameter and reflects the high variabilitythat Delphi observed in existing lines.

OperatorsThree types of tasks need operators: machine-attention (MA), periodic (P), and material-handling(MH) tasks. Each requires a different set of operatorskills. MA tasks have the highest variability and MHtasks are the most regular. Therefore, operators willnot be assigned both MA and MH tasks. However,all operators will have some P tasks that they mustperform, such as quality checks, reject handling, andmaintenance.

P tasks must be performed regularly—every 2, 4,8, 24, or 120 hours. MH tasks—much like P tasks—are performed periodically but more frequently thanP tasks. When P tasks occur, they have priority overMH tasks. MA tasks are performed as needed; i.e.,an operator who is responsible for fixing a specificmachine must attend to this duty when that machinefails. This random nature of MA tasks makes allocat-ing jobs to operators challenging, and poor operatorassignments can hamper productivity. For example,suppose that a specific operator is responsible forrepairs on both machines A and B. If machine A fails,the operator will respond to that machine as soon aspossible. However, if machine B fails while machine Ais still being repaired, the actual downtime of machineB will include not only its own repair time but alsothe remainder of the time it takes the operator to com-plete the repair of machine A and any travel timebetween the two machines. In general, because opera-tors can be responsible for repairs on many machines,this effect can be multiplied many times and causesubstantial downtime. Thus, to whatever extent pos-sible, the MA and P tasks should be balanced amongthe qualified operators such that a single operator isnot responsible for repair of more machines than nec-essary. To define a base case for operator assignments,we assigned each MA and P task to only one opera-tor; we then grouped the tasks by their proximity toeach other and approximately balanced them consid-ering the relative reliability of each. We assigned eachMH task to an operator who handled no MA or Ptasks and developed an extensive point-to-point walkmatrix to accurately account for operator travel times.

Figure 2 shows the operator-activity logic we usedin the simulation model; it reflects Delphi’s operatorpolicies for its existing lines. Each operator is givenresponsibility for performing specific tasks; operatorswho complete a task seek another task unless theirshift is over or it is time for lunch or a break. Lunchesand breaks have priority over tasks. If a machine isdown, filling buffers or handling rejects instead of fix-ing the machine is considered an inefficient use ofoperator time; therefore, MA tasks have the highestpriority of the three task types. In addition, if twotasks of the same type become due or call for operatorattention, they must be completed based on a fixed

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


Yes

No

No

No

Yes

Time forbreak?

Any repairjobs waiting?

END ofshift?

Any periodictasks due?

Any MHtasks due?

Attend to a failed machine

Perform a periodic task

Perform an MH task

Take abreak

Operators arrive every 8 hours

Operatorsleave after

8 hours

Yes

Yes

Yes

No

No

Figure 2: This flowchart of operator tasks shows the operator-activity logic used in the simulation program.

priority order. For example, if operator 4 is responsi-ble for repairing resources 5 – 3 – 4 – 6 in that order,then 5 is repaired first if both 5 and 3 fail. Repairing afailed unique machine (i.e., the only machine that canhandle a specific task or set of tasks) is given priorityover repairing one of a group of parallel machines.Operator modeling, which we describe in more detailin Appendix A, was the most difficult aspect of build-ing the simulation.

Process VariationEach machine has an average processing time givenin its specifications. Because some level of variationexists in processing rates, producing k fuel injectorsevery minute, even when no scrap is produced and allmachines are operational, is not possible. Because pro-cess variation affects production, it must be embed-ded in the model.

With help from the Delphi production team, weclassified the process variation of each machine intoone of the following three categories based on itsknowledge of the process: high, medium, or low vari-ation. We assigned a coefficient of variation (CV),defined as the ratio of the standard deviation tothe mean, for each of these categories. Because themean process time was specified, we could then cal-culate the process standard deviations using these

CV values. Using this mean and standard deviation,we specified a normal distribution to generate ran-dom processing times for each part that machineprocessed.

Simulation ModelWe developed the simulation model using version12.00 of Rockwell Automation’s Arena simulationsoftware (Kelton et al. 2006). It was a good choice forthe project for the following reasons:

• Arena is well-suited to modeling conveyors,which are the major mode of material transfer inDelphi’s production lines.

• It provides a user-friendly interface that makesunderstanding and modifying the model easier forpeople other than the modeler. In addition, it givesthe user the ability to design templates that can beused to create similar code for the parts of the modelthat are likely to be repeated (although with differ-ent parameters). For example, we designed a templatethat handles the tasks performed when a part arrivesfor a machine; examples include picking the part fromthe conveyor, checking for raw material inventory,processing the part, and placing it back on the con-veyor. When the template is available, a modeler onlyneeds to define machine-specific parameters, such as

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


conveyor name, machine number, and buffer type;the template will automatically generate customizedcode.

• The model can be linked to a data source (e.g.,the MSD, which is an Excel spreadsheet) to allowfor making most minor updates (e.g., changing MTBFfor some machines) directly using Excel rather thanArena. This also preserves data integrity because allDelphi analyses use a common data source.

• Arena provides animation capability that canbe used for model validation and demonstrationpurposes.

• Arena collects and reports most of the necessarystatistics by default and lets the modeler add otherstatistics.

Simulation Experiments and ResultsThe main performance measure in our simula-tion study was long-run average daily fuel injectorthroughput, i.e., the long-run average number of fuelinjectors that can be produced in a 24-hour period.Therefore, we treated this as a steady-state simula-tion (Banks et al. 2005) requiring a “warm-up period”to get from the initial state (conveyors empty butall input buffers full and all machines operational),to long-run operating conditions. For the base case(described below), approximately one day’s produc-tion was adequate (see Appendix B). Therefore, wemade each replication 11 days long; we discarded theoutput data from the first day and retained the next10 days (two weeks) of data. We then made enoughreplications to estimate long-run average throughputto within a 5 percent relative error; this required20 replications. We empirically determined the num-ber of replications so that (halfwidth of confidenceinterval)/(sample mean) was less than 0.05 for theestimated throughput. Running the scenario requiredapproximately eight hours to obtain 20 replications of11 days on a relatively fast PC. This is a function ofboth the size and complexity of the system and thevery large number of fuel injector subassemblies inprocess at any one time. Because all the other scenar-ios are modifications of the base case, we used thesame experimental effort (20 replications of 11 days)in each scenario tested. Although throughput drove

our performance measurement, measures of opera-tor utilization, machine downtime, congestion on con-veyor segments, and raw material buffer states werealso examined.

We compared the results of all experiments withthe results of two benchmarks: the base case, whichis a simulation of Delphi’s line design as specified inthe MSD, and the target of 1,125k fuel injectors perday. If we had not found a gap between these twobenchmarks, then the proof-of-concept phase of theline design would have been completed. Instead, wefound a very substantial gap; therefore, our objectivebecame to find the key factors producing the gap sothat they could become the focus of future designefforts. Because we did not have any specific designalternatives for comparison, we developed the exper-imental approach described below. Although the crit-ical factors were unexpected, they were completelyunderstandable after the fact.

First-Phase ScenariosTo design our preliminary experiments, called “first-phase scenarios,” we listed all the factors that mightcontribute to the loss of production. Obviously, if nosuch factors existed, then we would be consistentlyproducing 1,125k fuel injectors per day. We listed pro-cess variability, scrap rates, and downtime related tooperator availability as potentially critical factors, andconveyor lengths and number of pallets on each con-veyor were listed as secondary factors. We focusedour initial experiments on the potentially critical fac-tors; we felt that conclusions about conveyors wouldbe premature at this early study stage because majorchanges to the line layout were very likely.

In the simulation, we could control downtime bymanipulating the machine repair time. Because ourstudy involved 25 machines, each with a specifiedscrap rate, process variability, and repair time, wecould analyze 75 factors using classical design-of-experiments methods. However, even if we priori-tized and selected only 30 of these 75 factors andexamined only the main effects, we would requireat least 32 runs. At eight hours per test plus the timenecessary to set up scenarios and analyze results, thisexperiment would take about two weeks. At the con-cept stage of the line design, investing two weeks oftime and computational effort to estimate the effects

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


of each individual factor is not a worthwhile use oftime; many details are still in flux and major changesto equipment and conveyor layouts are almost cer-tain. Therefore, we used a group screening approach,grouping the factors into functional categories. By cat-egorizing the impact or lack of impact of these func-tional groups, we could answer broad questions aboutwhich factors have the greatest impact using reason-able computing effort.

For example, instead of investigating each machine’sprocess variability individually, we investigated theeffect of eliminating all the process variability. Thisallowed us to quantify the maximum impact that pro-cess variability has on throughput and saves the effortrequired to assess the effect of process variability foreach of the 25 machines if we find that process vari-ability as a group is not very significant. We con-structed analogous scenarios to examine the groupeffects of scrap rates and repair times. Thus, the first-phase scenarios included the following:

• Scenario 1: The base case is the model represen-tation of the factory as reflected in the MSD file andthe AutoCAD drawing of the layout.

• Scenario 2: All process variation is removed fromthe base case.

• Scenario 3: Process variation and all scrap areeliminated from the base case.

• Scenario 4: Repair times are set to zero; i.e., assoon as an operator attends to a failed machine, itstarts running again and the operator can leave forthe next assignment.

Scenario 2, which eliminates the process variation,was especially critical because the variation input tothe model was based on expert opinion and estimatedCVs. Therefore, if eliminating all the variation doesnot achieve a significant production gain, then puttingeffort into creating better CV estimates for the pro-cessing time of each machine is not essential at theconceptual design stage. However, if it makes a sig-nificant difference, then we should not make radicaldesign changes before we carefully characterize thisvariation.

Scenario 3 eliminates both scrap and process varia-tion. This scenario was intended to inform us of thesensitivity of throughput to scrap rates and to deter-mine if improving the machine scrap-rate estimate

before proceeding is critical. The purpose of eliminat-ing both process variation and scrap rate together isto use this scenario as a “best-case scenario” for thisdesign candidate.

Scenario 4 takes a different approach than Scenar-ios 2 and 3. In this experiment, we set repair timesto zero but retained scrap and process variations. Ourgoal was to determine the potential of the produc-tion line when repairs are done infinitely fast andmachines are down only for the time required forthe designated operator to attend to the machine(i.e., response time, which is time to complete a taskin progress and walking travel time). When we setrepair times to zero, operators became more availableand response times to failures decreased. Althoughwe recognized that this level of service is impossi-ble to achieve, this scenario showed us the benefits ofimproving machine-attention activities.

First-Phase Results and AnalysisFor the base-case scenario, the average daily pro-duction value estimate was only 800k fuel injectorsper day or 71 percent of the target throughput forthe new line. This left a gap of nearly 30 percentbetween planned and realized production. The resultsof Scenarios 2–4 shed light on what caused this gapand what design changes would give the largestimprovement.

In Scenario 2, when process variation was removedfrom all the machines, daily production relative tothe goal increased to 75 percent. In Scenario 3, inwhich we eliminated both process variability andscrap, this percentage became 76 percent. Both ofthese drastic and unattainable changes to the sys-tem produced only slight increases in productivity.Therefore, we concluded that more-detailed analysisof machine process variation and scrap rates shouldbe left to later stages of our study after we made moreinfluential changes to the system.

In Scenario 4, in which we reduced repair times tozero, we achieved our goal of 1,125k fuel injectors perminute; the average daily production for this scenariowas 102 percent of the target. This significant jumpfrom the base case was a good indication that machinedowntime is a primary cause of the low productionin the base case. However, before we jumped to aconclusion too quickly, we returned to the base-case

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


scenario and looked at statistics that we had collectedto discover other reasons for lost production. We wereinterested in four types of analysis: operator avail-ability, pallet congestion, inventory levels, and failureanalysis.

Operator utilizations in the base case showed thatall operators were heavily utilized. Some operatorswere so very heavily utilized that they often did notcomplete their periodic tasks, such as quality checksduring their shift; thus, they pushed these tasks tothe following shift. For specific tasks, the operatorsin subsequent shifts were also too busy to completethese tasks; therefore, these jobs would queue up andnever be completed. An even more significant con-sequence of having heavily utilized operators wasthat many machine failures did not get immediateattention from operators; therefore, operator responsetime to machine failure began to overwhelm repairtime as the primary cause of machine downtime. Thisraised the machine downtime for most machines farabove the expected downtime and caused dramaticproduction losses.

Congestion on conveyors is also a system measure.A very straightforward way of determining whichconveyor segments experience higher congestion isto look at which segments are heavily utilized for along time. Before running any scenario, we createdfour utilization states: fully, highly, moderately, andlightly utilized. Throughout the 10 days of each repli-cation, we monitored the time that each conveyorsegment spent in each utilization state. Conveyor seg-ments that spent a high percentage of time in fully orhighly utilized states were marked and compared tothe machine downtimes in the vicinity of these con-veyors. We concluded that for the base case a verystrong relationship existed between operator inabil-ity to respond quickly to machine failures and heavyutilization of the conveyor segments just upstream ofthose machines.

Raw material buffer inventory is also relevant. Welooked at whether any machines went idle because oflack of material. All our scenarios included one opera-tor who was dedicated to raw material handling withno machine-repair responsibilities. Thus, this functionwas not affected by the excessive machine downtime.From analyzing inventory buffers, we concluded that

the material-handling assignments for the base casewere good and needed only minor adjustments.

Finally, we performed some detailed failure anal-ysis because overutilized operators and highly con-gested conveyor segments might be symptoms ofanother problem: frequently failed machines. As withthe conveyors, we collected statistics on percentagesof the time when each machine was idle, busy, orfailed. For each machine in the system, we comparedresulting downtime percentages with the expecteddowntime from the MSD model. For the majority ofmachines in the base case, the downtime percent-ages were two to three times higher than expected(Figure 3). Thus, we concluded that excessive machinedowntime was the primary cause of the 30 percentgap between the target and the base-case scenarios.

The three direct contributors to the averagemachine downtime are MTBF, MTTR, and mean oper-ator response time (MORT). We can calculate percent-age downtime (PD) as

PD = 100�MORT+MTTR�

/�MTBF+MORT+MTTR�� (1)

We estimated machine PD for the MSD modelby observing current machines that are similar tothose planned for the new production line. Because itdirectly affects the production, PD for each machine isoften recorded. MTBF for the MSD model is also eas-ily collected because machines often include run-timemonitors. However, separating the operator responsetime from the repair time is not typically done; doingso would be very difficult unless we do a lengthy

0

5

10

15

Input

Per

cent

age

dow

ntim

e

Base-case output

Figure 3: The graph shows a comparison of input and output downtimepercentages for a typical machine in the base case.

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


time study on each machine. Although we can eas-ily estimate the sum of MORT and MTTR, we can-not estimate either value individually. When settingup the base-case scenario, we discovered this problembecause each machine must have a distribution spec-ified for both time before failure and time to repair.To simplify the problem, we assumed that if oper-ator assignments were designed well MORT wouldbe substantially less than MTTR and thus negligible.Therefore, solving Equation (1) for MTTR, we get

M̂TTR ≈ P̂D× M̂TBF/�100− P̂D�� (2)

where P̂D and M̂TBF are the estimates of machinePD and MTBF from the MSD. Given the results ofScenario 4, our assumption that MORT is negligiblewas incorrect for the base case and the approximationof MTTR in Equation (2) is poor.

Our first response to this information was that weshould make all reasonable efforts to determine agood estimate of MTTR for each machine to sim-ulate the base case correctly. However, this wouldhave required substantial time to collect data at a cur-rent production facility with similar machines—if wecould find such a facility. Another option, more in thespirit of using simulation early in the design process,was to redesign the base case to reduce the operatorload and thus reduce the impact of MORT. We devel-oped additional scenarios to help us to understandthe problem of operator loading on the base case andpotentially suggest new design directions.

Second-Phase ScenariosIn light of the results of the first-phase scenarios, thesecond-phase experiments focused on operator avail-ability for machine failures. The operator assignmentsfor the base-case scenario involved some criticalassumptions, some of which might have a substantialimpact on daily production numbers. For example,in the base-case design, we assigned each task (qual-ity check, machine repair, or material-handling job)to a specific operator; no other operator on that shiftcould respond to that task. As a result, when a par-ticular operator was heavily utilized, failed machineswould often wait for long periods of time before theassigned operator would arrive to start repairs. Sim-ilarly, when an operator was at lunch or on a break,

repair of any failed machine assigned to that oper-ator would have to wait until that operator’s lunchor break was over. In this highly connected produc-tion system, any deviation of a machine from its pro-duction target is enough to slow down finished fuelinjector throughput.

Another base-case assumption was that operatorsleave for lunch or a break on schedule as soon as theyhave completed the task at hand, potentially leavingone or more machines failed through an entire lunchor break period. It also assumes that all operators goto lunch or break at the same time, thus complicatingthe downtime problem. Clearly, the throughput gapmight be reduced by redesigning the lunch and breaktimes of operators, possibly cross-training some oper-ators to provide backup for others, or by resetting thepriorities for lunches, breaks, or specific machines.

To quantify the operator-redesign potential, Sce-nario 5 used the base case but eliminated lunchesand breaks from operator schedules. We designedthis experiment to determine an upper bound on theproduction gain that could be achieved by optimiz-ing the rules on operator lunches and breaks; thebase case had implemented a worst-case scenario inwhich lunch and breaks have priority and all occurat the same time. Of course, requiring operators towork without any breaks is unrealistic, as is schedul-ing all operators to take lunch at the same time.However, the objective of our experiments was toguide the design effort—not to make a final sugges-tion for implementation. Furthermore, practical wayscould be implemented for lunch and break coverage,such as adding support operators to relieve operatorswhen they leave for breaks, thus ensuring continuouscoverage for all tasks.

The selection of Scenario 6 was intended to deter-mine how much the approximation of MTTR in Equa-tion (2) affected the daily production rate in thebase case. Recall that MTTR for each machine is adirect input to the simulation model. More specifi-cally, each time machine j failed, a random repairtime was drawn from an exponential distribution withmean M̂TTRj, which was calculated from Equation (2)using estimates of the downtime and MTBF for thatmachine or comparable machines from current pro-duction lines. Conversely, operator response time is arandom output of the simulation model that depends

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


on the random machine failures and the operatorutilization levels. The approximation in Equation (2)used for the base case assumes that all downtimeis repair time, an assumption that we found to beinaccurate. Scenario 4 went to the other extreme andassumed that all downtime was operator responsetime, an assumption that we also knew was untruebecause repairs take time. Scenario 6 attempts to com-promise between these two scenarios; it assumes thatthe repair will account for about half of the down-time and operator response time will be the other half.Thus, in Scenario 6, we halved the MTTR for eachmachine. Therefore, we ran the following two scenar-ios as second-phase scenarios:

• Scenario 5: Lunches and breaks are fully staffedwith no reduced efficiency.

• Scenario 6: MTTR is halved. This scenario antic-ipates that about half of the machine downtime isoperator response time.

In both scenarios, the base-case assumptions arekept the same except for the changes mentioned.Thus, they include scrap and process variability ratesat the same levels as in the base case.

Second-Phase ResultsIn Scenario 5, where lunches and breaks were fullycovered by relief operators, the expected daily pro-duction value relative to the production target was85 percent. Despite substantial improvement, thisshowed that even if we redesigned the base case toprovide full operator coverage during lunches andbreaks, a gap between the achieved production andthe target of 1,125k fuel injectors per day would stillexist. However, this scenario still used the assumptionthat operator response time is negligible and inves-tigation of the downtime for this scenario still didnot match the expected downtime from current pro-duction lines. However, in Scenario 6, which includesoperator lunches and breaks but cuts MTTR in half,the throughput is 92 percent of the target. This indi-cates that if the MTTR rates were indeed half ofthe originally proposed MTTR rates, then productionrates would almost meet expectations (Figure 4).

Interpreting Scenario 6 requires some caution. Theoperator response time in the simulation model isbased on the operator staffing level and assignments.Recall that the downtime estimates from current pro-duction machines are also based on some level of

0

5

10

15

Input MTTR/2 output

Per

cent

age

dow

ntim

e

Base-case output

Figure 4: The graph illustrates downtime percentages in the base caseand in the MTTR/2 scenario compared to input value.

Daily productionScenario (relative to target) (%)

1: Base case 712: No process variability 753: No process variation and no scrap 764: No repair time 1025: Full relief during lunch and break 856: MTTR/2 92

Table 1: The data show a comparison of daily production values.

operator staffing and an unrecorded system of taskassignments (that are not necessarily relevant to thenew production line). Thus, the conclusion of this sec-ond phase is that it is vitally important to determinean estimate of the MTTR for each machine that isaccurate and independent of the operator responsetime. We can only trust estimates of the daily through-put if we have accurate estimates of the MTTR. Onceaccurate estimates of the MTTR for each machine arecollected, new design candidates can be accuratelytested. In particular, Scenario 5 indicated that sub-stantial increases in daily throughput could be gainedby setting up an operator schedule that providestask coverage for operators when they take lunchor breaks. Table 1 summarizes the results of all sixscenarios.

ConclusionsMany real-world projects provide moving targetsas the business climate, physical and financial con-straints, and product concepts evolve. This might

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


suggest that simulation, which is a detail-orientedmethodology, is not suitable for system design untilquite late in the development of a manufacturing sys-tem. However, Delphi’s ongoing use of simulationto design and evaluate its next-generation fuel injec-tor production line illustrates the value of simula-tion, even very early in the design process. The key isusing simulation to answer questions at the right level,including questions about project viability and appro-priate concentration of effort during system design.A simulation can address these needs before detailedspecifications are available. Furthermore, if the simu-lation is constructed in a way that makes it reasonableto update and refine, then it can continue to contributethroughout the project life cycle.

We learned the following lessons about using sim-ulation early in a system-design project:

• The simulation model should be constructed sothat it can be easily changed. Ideally, it should belinked to the same data sources that are being usedfor the overall project planning.

• Use group screening to assess which design fea-tures or data sources, taken together, impact perfor-mance; thus, as the project evolves, scarce engineeringeffort can be concentrated where it is most useful.

• Avoid the temptation to create or define detailedproduction-control plans; instead, use easy-to-define,extreme scenarios that bound potential improvementsor effectiveness.

• Focus not only on the output performance mea-sures of most interest (e.g., throughput) but alsorecord measures that provide insight into where prob-lems might be occurring.

EpilogueUpon completing the first six months of the concept-development phase, we presented our results andconclusions to Delphi engineers and managers,including a visiting European manager. This was thefirst major manufacturing simulation project for theDelphi Powertrain division in 10 years. Our pre-sentation generated a lot of feedback and sparkedinterest in carrying forward the simulation studyfor another three months. Taking the feedback intoaccount, we designed the next phase as a refinementof the concept-development phase.

Our first task was to carefully calibrate down-times to set MTTRs, paying particular attention tomachines with the largest downtimes. Then we exper-imented with three alternative coverage options foroperators: (1) full relief (operators continuously workwithout any breaks), (2) no relief (operators take peri-odic breaks during which their responsibilities awaittheir arrival), and (3) staggered breaks with coverage(operators working in the same area never overlaptheir breaks to allow them to cover for each other).Only option 1 adds employees to cover for breaks.Options 2 and 3 require no additional resources, andour results favored option 3 as the base case movingforward.

After setting the base case, we then moved on toimproving conveyor layouts. Based on a congestionanalysis of conveyors, we listed segments that werehighly congested and could benefit from lengthening.We added to this list those segments that are verylong and might add unnecessary travel time and takeup space. We defined three levels (long, medium, andshort length) for all the segments in the list and rana fractional factorial design to find the optimal levelfor each segment. This analysis showed which seg-ments could significantly enhance throughput by beinglengthened or shortened, and it identified segments forwhich throughput was insensitive to their lengths.

We constructed new conveyor layouts based on thesuggested sizing of the conveyor segments. One con-veyor layout resulted in a 7 percent improvement inthroughput compared with the current layout anda 10 percent reduction in required floor space forno additional investment. The Delphi team embracedthis layout as a viable alternative to its original pro-posal. Finally, a pallet study showed that throughputwas insensitive to the number of pallets within a verywide range.

Insights gained by this simulation study convincedDelphi to continue to update the model as its equip-ment design evolved. Its management was impressedby the positive results of this project and plans to usesimulation on future programs.

Appendix A. Modeling Operator“Bus Routes”Within Delphi, operator work assignments (Figure 2)are referred to as “bus routes.” The name was derived

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


from the observation that operators have sequences ofrepetitive tasks that they perform on specific cycles.However, unlike the typical city bus route, deviationsfrom the fixed route occur because of, for example,machine failures that demand immediate attentionbefore the route can resume. This appendix describeshow we used specific Arena features to simulate thecomplex work assignments of operators and, in par-ticular, their interactions with failed machines.

In a typical Arena simulation, operators andmachines are represented by Arena resources. AnArena resource is, effectively, a variable that keepstrack of the status of the operator or the machine thatoperator represents. When represented as a resource,a machine becomes unavailable when it is processinga job or has failed; similarly, an operator who is per-forming a task or is on a break is considered unavail-able. This logic for resources is usually sufficient formodeling machines with dedicated repair staff mem-bers who are ready to start fixing problems as soon asthey occur, or for modeling a pool of operators whoseonly responsibility is to respond to failures of a groupof machines. Often the machine and operator resourcecorrespond one to one.

However, this approach is inadequate for model-ing the more complex scenario we faced in whichoperators must perform a variety of duties andmachines that have failed must stay unavailable asthey wait for operator attention. The machines wemodeled are semiautomatic; therefore, they do nothave dedicated operator support. The operators inthe system have duties of various types, rangingfrom machine-attention tasks to material handlingand quality checks that make representing these tasksusing the standard Arena resources inappropriate.Therefore, we used Arena’s flexibility to implement acustom approach.

Delay for t1 secondsuntil failure

t1~ expon(MTBF)

Machine stopsworking

(FAILED)

Signal for attentionand wait t2a seconds

until repairmanarrives

Delay for t2b secondsduring repair

t2b~ expon(MTTR)

Machine startsworking again(AVAILABLE)

Failure entities arrive

Figure A.1: The flowchart illustrates failure modeling in the Delphi simulation.

To represent the operators in the model, we createdan Arena entity for each operator at the beginning ofeach shift and disposed of it at the end of the shift. AsFigure 2 shows, operator entities follow a routine inwhich they perform specific tasks in the priority orderassigned to them. As opposed to the passive involve-ment of operators as resources that are used by enti-ties, operators are actively involved in choosing theirnext task as soon as they become available. Repairjobs, periodic tasks, and material-handling tasks arecreated in other parts of the model, and operatorsrespond to them at their earliest opportunity accord-ing to the task priorities.

Although we did represent machines as resources,we chose not to use the built-in failure logic of theArena resources because it does not allow the time amachine spends waiting for an operator to depend onthe current state of that operator. Instead, we estab-lished three states for each resource—busy, idle, andfailed; idle is the only state in which the machineis able to serve a new part. In the busy state, theresource is processing a part; when it completes itsprocessing, it becomes idle and ready to receive thenext part waiting to be processed. The failed stateis active when the machine is down and unavailableuntil an operator attends to it. To model this, we cre-ated a special failure entity for each resource. Thisentity takes hold of the resource when it is time for theresource to go down because of a failure. The failureentities have priority over entities representing partswaiting to be processed; they can seize and thereforefail the machine as soon as they appear. Figure A.1displays the logic of this simple approach in a styl-ized way.

1. First, a failure entity is created for each resource;that entity starts in the leftmost block, where it isdelayed for t1 seconds before moving to the second

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


0

0.25

0.50

0.75

1.00

0 6 12 18 24 30 36 42 48 54 60

Hour

Sta

ndar

dize

d th

roug

hput

Figure B.1: The graph shows average hourly throughput for the first 60 hours of the simulation.

block; t1 represents the time before the next failureand is drawn from an exponential distribution with aparameter of MTBF.

2. In the second block, the failure entity occupiesthe resource and puts it into the failed state.

3. In the next block, the failure signal is turnedon for the resource just failed. The time that passesbetween the failure signal and the operator responseis represented in Figure A.1 as t2a seconds. However,t2a is not drawn from any distribution because it is alogical delay that depends on the state of the wholesystem at that moment. If the operator responsible forrepairing the machine that just failed is busy repairinganother machine and other machines are waiting tobe repaired by the same operator, then this time mightbe quite long. For t2a seconds, the machine stays in thefailed state because repair has not started. The failureentity that controls this routine’s logic stays in thisblock during this time.

4. When the operator arrives, repair starts and thefailure entity passes to the next block, in which it isdelayed for t2b seconds until the repair is completed.

5. After completion of the repair, the failure entitymoves to the final block in the series; this puts themachine into the idle state. Finally, the entity goesback to the beginning of the routine to wait anothert1 seconds before failing the resource again.

Appendix B. Warm-Up AnalysisA practical and widely used method for finding agood warm-up period is mean plot analysis (Bankset al. 2005). The idea is simple: estimate the transientmean of the process by averaging across a number of

replications; then choose as the deletion point a timeafter which the plot varies consistently around a fixedvalue. We explain how we used this method in ourfuel injector simulation below.

First, we ran 20 replications of our base-casemodel, each replication of 10 simulated days, andrecorded the number of fuel injectors produced ineach one-hour interval for each replication. This gaveus production numbers for 240 time intervals perreplication. Then, we averaged the 20 values fromeach time interval separately and plotted them asa function of time interval. We choose as the dele-tion point the interval at which this plot no longerhas a trend. There is only a weak upward trendbetween 3 to 9 hours, so deleting 24 hours is morethan adequate.

Figure B.1 shows the first 60 hours of this plot (withthe throughput normalized to an arbitrary constantunrelated to the actual value). Because we preloadeach process segment with injectors and all machinesare up and raw material buffers full, the throughputquickly reaches steady state; thus, a 24-hour warm-upperiod is certainly sufficient.

AcknowledgmentsThis paper was adapted from Tongarlak et al. (2008). Wethank the editors and referees for their helpful guidance.

ReferencesBanks, J., J. S. Carson, B. L. Nelson, D. Nicol. 2005. Discrete-

Event System Simulation, 4th ed. Prentice Hall, Upper SaddleRiver, NJ.

Kelton, W. D., R. P. Sadowski, D. T. Sturrock. 2006. Simulation withArena, 4th ed. McGraw-Hill, New York.

Tongarlak, M. H., B. Ankenman, B. Nelson, L. Borne, K. Wolfe.2008. Using simulation early in the design of a fuel

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.


injector production line. S. J. Mason, R. R. Hill, L. Moench,O. Rose, eds. Proc. 2008 Winter Simulation Conf., Miami,471–478.

John Wray, Delphi Communications, 3000 Univer-sity Drive, Auburn Hills, MI 48326, writes: “On behalfof Delphi Corporation I am pleased to verify our useof the simulation analysis presented in ‘Using Simula-tion Early in the Design of a Fuel Injector Production

Line’ by Tongarlak, Ankenman, Nelson, Borne, andWolfe.

“The project described in the paper is an ongoingeffort to design a production line for a new productat Delphi. The simulation analysis has provided andcontinues to provide valuable guidance for the lay-out, loading and staffing of this line, and in particularhas allowed us to assess design concepts early in thedesign process.”

Dow

nloa

ded

from

info

rms.

org

by [

129.

105.

32.2

28]

on 0

6 A

ugus

t 201

4, a

t 15:

02 .

For

pers

onal

use

onl

y, a

ll ri

ghts

res

erve

d.

using simulation early in the design of a fuel injector...

Documents