Handbuch Factory Explorer FX210

User Manual
User's Guide Reference Topics
Factory Explorer
Version 2.10
Wright Williams & Kelly, Inc.
Acknowledgments
The following people provided valuable comments and suggestions during the development of Factory Explorer: Steven Brown, Al Bruska, Stuart Carr, Alison Cohen, Daren Dance, Jrg Domaschke, Volker Drrsam, Gerry Feigin, John Fowler, Dan Friedman, Kai Furmans, Ottmar Gihr, Navdeep Grewal, Semerjit Gupta, Sarah Hood, Tom Jefferson, David Jimenez, Dave Kohr, Alan Levine, Mark Metzger, Eileen Neacy, David Nehme, Robin Roundy, David Ruppert, Paul Schneider, Lee Schruben, Lance Solomon, Joel Trinidad, Hank Zuretti, Bob Kotcher, and Jennifer Hiner. The Factory Explorer development team included Frank Chance, Albina Datsukova, Jennifer Robinson, Scott Mason, Oliver Rose, Jani Jasadiredja, Craig Volonoski, and Jim Jameson. Prior to September 1st, 1995, the capacity analysis and simulation engines of Factory Explorer were known as Delphi. Some of the features supported in Delphi were inspired by the semiconductor manufacturing simulator described in Hood et al. (1989). Research pertaining to Delphi was supported by the Advanced Research Projects Agency and Sematech. The Delphi simulation engine was originally prototyped using the Sigma (Schruben 1991) graphical modeling system.
System Requirements
Operating System Windows XP Excel Version Excel 97/2000/XP Recommended Memory >2 Gigabytes
Other Windows operating systems may work but are not guaranteed.
Technical Support
Please refer all technical support questions to: Wright Williams & Kelly, Inc. 6200 Stoneridge Mall Road, 3rd Floor Pleasanton, CA 94588 USA Response time is typically one business day. Phone: (925) 399-6246 Fax: (925) 396-6174 Web: http://www.wwk.com Email: support@wwk.com
Exclusive Distribution Rights

Worldwide distribution rights to Factory Explorer are the exclusive property of Wright Williams & Kelly, Inc., 6200 Stoneridge Mall Road, 3rd Floor, Pleasanton, CA 94588.
Copyright WWK 1995-2009
Factory Explorer i
Legal Notices
Duplication or transmission of this document in any form or by any means without the express written permission of Wright Williams & Kelly, Inc. is prohibited by federal law. Copyright 1995-2009 Wright Williams & Kelly, Inc. All Rights Reserved. Factory Explorer is a registered trademark of Wright Williams & Kelly, Inc. Microsoft, MS-DOS, and Windows are registered trademarks of Microsoft Corporation. Windows NT is a trademark of Microsoft Corporation. Macintosh is a registered trademark of Apple Computer, Inc.. ManSim is a trademark of TYECIN Systems, Inc. PKZIP is a registered trademark of PKWARE, Inc. WorkStream is a registered trademark of Consilium, Inc. FabTime is a registered trademark of FabTime, Incorporated. Factory Explorer is not public domain or shareware software. Use of Factory Explorer without a license is prohibited.
Software License Agreement

Wright Williams & Kelly, Inc. ("Company") is willing to license the enclosed Software (the "Software") only upon the condition that you accept all of the terms of this agreement. Please read these terms carefully before downloading any installation packages, as doing so will indicate your agreement to these terms. If you do not agree to these terms, then Company is unwilling to license the Software to you, in which event you must return the Software within 14 calendar days to the place from which it was acquired, and your money will be refunded. No refunds will be provided for any other reason except as listed below. License You may use the Software for a single specified user on a single computer (or the number specified in your purchase agreement). You may copy the Software only for backup purposes, provided that you reproduce all copyright and other proprietary notices that are on the original copy of the Software provided to you. You may transfer the Software and all rights under this agreement to another party together with a copy of this agreement if the other party agrees to accept the terms of this agreement and you receive authorization in writing directly from Wright Williams & Kelly, Inc. prior to any such transfer. If you transfer the Software, you must at the same time either transfer all copies whether in printed or machine-readable form to the same party or destroy any copies not transferred. Restrictions You may not use, copy, modify, or transfer the Software, or any copy, in whole or in part, except as expressly provided for in this agreement. You may not disassemble or decompile the Software. Any attempt to transfer any of the rights, duties, or obligations hereunder except as expressly provided for in this agreement is void. You may not rent, lease, loan, resell for profit, distribute, or network the Software. Limited Warranty Company warrants for the period of ninety (90) days from the date of delivery of the Software to you as evidenced by a copy of your receipt that: 1) The Software, unless modified by you, will perform substantially in accordance with the user documentation provided by Company. Your sole remedy under this warranty
Factory Explorer ii
is that Company will either correct, within a reasonable period of time, any failure of the Software to perform substantially in accordance with the user documentation reported during the warranty period or, if Company is unable to correct any such issues, refund to you the money paid for the Software. Company does not warrant that the Software will meet your requirements, that operation of the Software will be uninterrupted or error-free, or that all Software errors will be corrected. 2) The medium on which the Software is furnished will be free from defects in materials and workmanship under normal use. Company will, at its option, replace or refund the purchase price of faulty medium at no charge to you, provided you return the faulty medium with proof of purchase to Company or an authorized dealer. Company will have no responsibility to replace or refund the purchase price of any medium damaged by accident, abuse, or misapplication. The above warranties are exclusive and in lieu of all other warranties, express or implied, and Company expressly disclaims all other warranties, including the implied warranties of merchantability, fitness for a particular purpose, and non-infringement. No oral or written information or advice given by Company, its employees, distributors, dealers, or agents shall increase the scope of the above warranties or create any new warranties. Some States do not allow the exclusion of implied warranties, so the above exclusion may not apply to you. In that event, any implied warranties are limited in duration to ninety (90) days from the date of delivery of the Software. This warranty gives you specific legal rights. You may have other rights, which vary from State to State. Limitations of Remedies Company's entire liability to you and your exclusive remedy shall be the correction of the Software or the replacement of the Software medium, or the refund of your purchase price, as set forth above. If Company is unable to deliver a replacement medium which is free of defects in materials and workmanship, you may terminate this agreement by returning the Software and your money will be refunded. Regardless of whether any remedy set forth herein fails of its essential purpose, in no event will Company be liable to you for any damages, including any lost profits, lost data, or other incidental or consequential damages, arising out of the use or inability to use the Software or any data supplied therewith, even if Company or an authorized dealer has been advised of the possibility of such damages, or for any claim by any other party. Some States do not allow the limitation or exclusion of liability for incidental or consequential damages so the above limitation or exclusion may not apply to you. Government Licensee If you are acquiring the Software on behalf of any unit or agency of the United States government, this provision applies. The government acknowledges Company's representation that the Software and its documentation were developed at private expense and no part of them is in the public domain. The government acknowledges Company's representation that the Software is "Restricted Computer Software" as that term is defined in clause 52.227-19 of the Federal Acquisition Regulations (FAR) and is "Commercial Computer Software" as that term is defined in subpart 227.401 of the Department of Defense Federal Acquisition Regulation Supplement (DFARS). The government agrees that: 1) If the Software is supplied to the Department of Defense (DOD), the Software is classified as "Commercial Computer Software" and the government is acquiring only Copyright WWK 1995-2009 Factory Explorer iii
"Restricted Rights" in the Software and its documentation as that term is defined in clause 252.227-7013(c)(1) of the DFARS, and 2) If the Software is supplied to any unit or agency of the United States government other than DOD, the government's rights in the Software and its documentation will be as defined in clause 52.227-19(c)(2) of the FAR. Restricted Rights Legend Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the rights in technical data and computer software clause at DFARS 252.227-7013 or subparagraphs (c)(1) and (2) of the commercial computer software -- restricted rights clause at 48 CFR 52.227-19, as applicable. Export Law Assurances You acknowledge and agree that the Software is subject to restrictions and controls imposed by the United States export administration act (the "Act") and the regulations thereunder. You agree and certify that neither the Software nor any direct product thereof is being or will be acquired, shipped, transferred, or reexported, directly or indirectly, into any country prohibited by the Act and the regulations thereunder or will be used for any purpose prohibited by the same. General This agreement will be governed by the laws of the State of California, except for that body of law dealing with conflicts of law. If any provision of this agreement is held to be unenforceable, that provision will be removed and the remaining provisions will remain in full force. This agreement is the complete and exclusive statement of the agreement between us which supersedes any proposal or prior agreement, oral or written, and any other communications between us in relation to the subject matter of this agreement. If you have any questions concerning this agreement, you may contact Company by writing to: Wright Williams & Kelly, Inc. 6200 Stoneridge Mall Road, 3rd Floor Pleasanton, CA 94588 You acknowledge that you have read this agreement, understand it, and agree to be bound by its terms. The Software and the accompanying user documentation are protected by United States copyright law and international treaty. Unauthorized reproduction or distribution is subject to civil and criminal penalties.
Factory Explorer iv
Contents
1. 1.1 1.2 1.3 1.4 1.5 2. 2.1 2.2 2.3 2.4 2.5 2.6 3. 3.1 3.2 3.3 3.4 3.5 4. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 5. 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 INTRODUCTION TO FACTORY EXPLORER ............................................................................. 1 OVERVIEW OF FACTORY EXPLORER ....................................................................................................... 1 ANALYTIC METHODS VS. SIMULATION METHODS .................................................................................. 3 BENEFITS OF INTEGRATED COST ANALYSIS ........................................................................................... 4 A QUICK TOUR OF FACTORY EXPLORER'S EXCEL INTERFACE ................................................................ 5 GETTING ANSWERS WITH FACTORY EXPLORER.................................................................................... 11 INTRODUCTION TO THE USER MANUAL ............................................................................... 19 INTRODUCTION ..................................................................................................................................... 19 IF YOU ARE NEW TO FACTORY EXPLORER ........................................................................................... 19 IF YOU ARE UPGRADING FROM A PRIOR RELEASE ............................................................................... 19 WHERE TO LOOK IF YOU HAVE A QUESTION ....................................................................................... 19 TERMINOLOGY...................................................................................................................................... 20 FORMATTING CONVENTIONS ................................................................................................................ 24 USER'S GUIDE: GETTING STARTED ......................................................................................... 27 HARDWARE SECURITY (HASP) KEYS .................................................................................................. 27 INSTALLATION ON WINDOWS PLATFORMS ........................................................................................... 27 INSTALLATION NOTES .......................................................................................................................... 28 TECHNICAL SUPPORT............................................................................................................................ 29 FACTORY EXPLORER VERSION NUMBERS............................................................................................. 30 USER'S GUIDE: BUILDING A BASIC MODEL .......................................................................... 31 INTRODUCTION ..................................................................................................................................... 31 STORING MODELS AS EXCEL WORKBOOKS .......................................................................................... 42 RULES FOR PRODUCT NAMES, TOOL GROUP NAMES, ETC. ................................................................... 66 PROCESS TIME PARAMETERS ................................................................................................................ 67 SPECIFYING DISTRIBUTIONS ................................................................................................................. 70 DISPATCH RULES .................................................................................................................................. 70 UNITS OF MEASURE .............................................................................................................................. 75 USER'S GUIDE: ENRICHING THE BASIC MODEL ................................................................. 79 INTRODUCTION ..................................................................................................................................... 79 EQUIPMENT FAILURES .......................................................................................................................... 79 SCRAP AND REWORK ............................................................................................................................ 80 OPERATORS .......................................................................................................................................... 85 MULTIPLE PRODUCTS ........................................................................................................................... 88 PRIORITY DISPATCH RULES AND DEFAULT PRIORITIES ........................................................................ 90 ADJUSTING LOT PRIORITIES ................................................................................................................. 92 SETUPS ................................................................................................................................................. 93
Factory Explorer v
6. 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7. 7.1 7.2 7.3 7.4 7.5 8. 8.1 8.2 8.3 8.4 8.5 8.6 9. 9.1 9.2 9.3 9.4 9.5 9.6 9.7 9.8 9.9 9.10 9.11 9.12 9.13 9.14 9.15 9.16 9.17 9.18 9.19 9.20 9.21 9.22 10. 10.1 10.2 10.3 10.4 10.5 10.6
USER'S GUIDE: RUNNING THE MODEL ................................................................................. 101 INTRODUCTION ................................................................................................................................... 101 BASIC INSTRUCTIONS ......................................................................................................................... 101 REQUIRED RUN-TIME INFORMATION .................................................................................................. 102 SPECIFYING FACTORY EXPLORER RUN-TIME OPTIONS ...................................................................... 103 MODEL VALIDATION .......................................................................................................................... 104 FACTORY EXPLORER OUTPUT CONSOLE ............................................................................................ 105 FACTORY EXPLORER EXIT CODE FILE ................................................................................................ 105 USER'S GUIDE: ANALYZING OUTPUT ................................................................................... 107 INTRODUCTION ................................................................................................................................... 107 OUTPUT WORKSHEETS ....................................................................................................................... 108 OUTPUT CHARTS ................................................................................................................................ 140 CUSTOM CHART WIZARD ................................................................................................................... 144 OUTPUT REPORTS ............................................................................................................................... 146 USER'S GUIDE: INCLUDING RAMP DATA IN A FACTORY EXPLORER MODEL ........ 149 INTRODUCTION ................................................................................................................................... 149 EXAMPLE: RAMPING PRODUCT DATA ................................................................................................ 150 EXAMPLE: RAMPING TOOL DATA ....................................................................................................... 151 EXAMPLE: RAMPING OPERATOR DATA .............................................................................................. 152 EXAMPLE: RAMPING PROCESS STEP DATA ......................................................................................... 153 RAMP DATA NOTES ............................................................................................................................ 154 USER'S GUIDE: ADDITIONAL MODELING CAPABILITIES .............................................. 159 INTRODUCTION ................................................................................................................................... 159 BATCH PROCESSING AND BATCH I.D.'S .............................................................................................. 160 EQUIPMENT DOWNTIME (FAILURES, PREVENTIVE MAINTENANCE, ENGINEERING, ETC.) ................... 177 SPLITTING UNITS AT PROCESS COMPLETION ...................................................................................... 183 BINNING UNITS AT PROCESS COMPLETION ......................................................................................... 184 ASSEMBLY .......................................................................................................................................... 185 ADJUSTABLE TRANSFORM AND ASSEMBLY PERCENTAGES ................................................................ 187 HOT LOTS ........................................................................................................................................... 188 FACTORY SCHEDULES ........................................................................................................................ 190 PROCESS STEP GOTO'S ................................................................................................................... 192 INDIVIDUAL LOTS .......................................................................................................................... 194 COST AND REVENUE ANALYSIS ..................................................................................................... 198 SPACE AND LAYOUT ANALYSIS ..................................................................................................... 207 ALTERNATIVE STEPS ..................................................................................................................... 209 HOLDING A TOOL ACROSS MULTIPLE PROCESS STEPS .................................................................. 211 SPLITTING AND RECOMBINING LOTS WITHIN A PROCESS FLOW .................................................... 216 CONTROLLING THE ORDER OF SIMULTANEOUS CHECK-REQUEST EVENTS .................................... 221 MODELING COMPLEX SETUPS ........................................................................................................ 224 CLUSTER TOOL MODELING ............................................................................................................ 226 TOOL GROUP BUFFERS .................................................................................................................. 232 ALTERNATE OPERATOR GROUPS AND WORK SCHEDULES ............................................................. 236 MERGE MODEL DATA .................................................................................................................... 243 USER'S GUIDE: MANAGING A SUCCESSFUL ANALYSIS PROJECT ............................... 249 INTRODUCTION .............................................................................................................................. 249 PROJECT LIFECYCLES..................................................................................................................... 249 MODEL DESIGN.............................................................................................................................. 250 MODEL DEVELOPMENT .................................................................................................................. 252 PROJECT DEPLOYMENT .................................................................................................................. 255 SUMMARY ...................................................................................................................................... 259
Factory Explorer vi
11. 11.1 11.2 11.3 11.4 11.5 11.6 11.7 11.8 11.9 11.10 11.11 11.12 11.13 11.14 11.15 12. 12.1 12.2 12.3 13. 13.1 13.2 14. 14.1 14.2 14.3 15. 15.1 15.2 15.3 16. 16.1 16.2 17. 17.1 17.2 17.3 18. 18.1 18.2 18.3 18.4 19. 19.1 19.2 19.3
REFERENCE TOPICS: WHAT'S NEW IN THIS RELEASE ................................................... 263 WHATS NEW IN VERSION 2.10 ...................................................................................................... 263 WHATS NEW IN VERSION 2.9 ........................................................................................................ 264 WHATS NEW IN VERSION 2.8 ........................................................................................................ 265 WHATS NEW IN VERSION 2.7 ........................................................................................................ 266 WHATS NEW IN VERSION 2.6 ........................................................................................................ 267 WHAT'S NEW IN VERSION 2.5 ........................................................................................................ 270 WHATS NEW IN VERSION 2.4........................................................................................................ 272 WHATS NEW IN VERSION 2.3A ..................................................................................................... 274 WHAT'S NEW IN VERSION 2.3 ........................................................................................................ 274 WHAT'S NEW IN VERSION 2.2A ...................................................................................................... 280 WHAT'S NEW IN VERSION 2.2 ........................................................................................................ 280 WHAT'S NEW IN VERSION 2.1 ........................................................................................................ 284 WHAT'S NEW IN VERSION 2.0A ...................................................................................................... 291 WHAT'S NEW IN VERSION 2.0 ........................................................................................................ 291 WHAT'S NEW IN VERSION 1.0 ........................................................................................................ 297 REFERENCE: TOPICS: TRANSLATING MODELS FROM PRIOR RELEASES................ 301 INTRODUCTION .............................................................................................................................. 301 TRANSLATING FACTORY EXPLORER VERSION 1 MODELS TO VERSION 2 ....................................... 301 TRANSLATING DELPHI VERSION 10 MODELS TO FACTORY EXPLORER VERSION 1 ........................ 303 REFERENCE TOPICS: RUN-TIME OPTIONS ......................................................................... 305 INTRODUCTION .............................................................................................................................. 305 COMPLETE LIST OF RUN-TIME OPTIONS ........................................................................................ 305 REFERENCE TOPICS: THE RESULTS DATA FILE ............................................................... 317 INTRODUCTION .............................................................................................................................. 317 GENERAL INFORMATION ................................................................................................................ 317 DOCUMENTATION FOR SPECIFIC RECORD TYPES ........................................................................... 318 REFERENCE TOPICS: UNDERSTANDING NON-INTUITIVE RESULTS .......................... 325 INTRODUCTION .............................................................................................................................. 325 OCCASIONAL EXTREME SPIKES IN CYCLE TIME ............................................................................ 325 UNSTABLE CYCLE TIME IN A SYSTEM WITH NO OVERLOADED TOOLS .......................................... 327 REFERENCE TOPICS: ASCII MODEL SYNTAX .................................................................... 331 INTRODUCTION .............................................................................................................................. 331 ASCII MODEL SYNTAX ................................................................................................................. 331 REFERENCE TOPICS: TRANSLATING MODELS BETWEEN FORMATS........................ 337 FACTORY EXPLORER EXCEL AND ASCII MODELS ......................................................................... 337 MANSIM(TM) MODELS ................................................................................................................. 337 TESTBED MODELS.......................................................................................................................... 341 REFERENCE TOPICS: CUSTOMIZING FACTORY EXPLORER ........................................ 345 INTRODUCTION .............................................................................................................................. 345 ROUTINES IN USER.DLL CALLED BY FACTORY EXPLORER ........................................................... 345 ROUTINES IN FACTORY EXPLORER CALLABLE FROM USER.DLL................................................... 347 CREATING YOUR OWN USER.DLL ................................................................................................ 350 REFERENCE TOPICS: ESTIMATING CYCLE-TIME CONSTRAINED CAPACITY ........ 351 INTRODUCTION .............................................................................................................................. 351 A BRUTE-FORCE METHOD ............................................................................................................. 353 A STOCHASTIC APPROXIMATION METHOD .................................................................................... 356
Factory Explorer vii
19.4 19.5 20.
A CURVE-FITTING METHOD .......................................................................................................... 356 THROUGHPUT RATE VS. INPUT RATE ............................................................................................. 357 REFERENCE TOPICS: CAPACITY ANALYSIS ....................................................................... 359
20.1 INTRODUCTION .............................................................................................................................. 359 20.2 ASSUMPTIONS ................................................................................................................................ 359 20.3 TRAFFIC ANALYSIS ........................................................................................................................ 359 20.4 NESTED REWORK FLOWS ............................................................................................................... 361 20.5 PROCESSING RATES ....................................................................................................................... 362 20.6 AVERAGE MAXIMUM BATCH SIZE ................................................................................................. 363 20.7 FACTORY NONSCHEDULED RATE................................................................................................... 363 20.8 OFFLINE RATES.............................................................................................................................. 363 20.9 REPAIR RATES ............................................................................................................................... 364 20.10 SETUP RATES AT TOOL GROUPS .................................................................................................... 364 20.11 SETUP RATES AT OPERATOR GROUPS ............................................................................................ 367 20.12 OCCUPIED% ................................................................................................................................... 368 20.13 CAPACITY LOADING% AND ACTUAL MAXIMUM PROCESSING RATE: RESOURCES THAT PERFORM PROCESSING ................................................................................................................................................. 368 20.14 CAPACITY LOADING%: RESOURCES THAT PERFORM ONLY REPAIR .............................................. 369 20.15 MAX GOING RATE (DAILY GOING RATE, OR DGR). ...................................................................... 369 20.16 SUGGESTED MAXIMUM CAPACITY LOADING ................................................................................. 371 20.17 SUGGESTED WHOLE TOOL AND OPERATOR COUNTS ..................................................................... 371 20.18 SUGGESTED EXACT TOOL AND OPERATOR COUNTS ...................................................................... 372 20.19 LEAD TIME..................................................................................................................................... 373 20.20 INTERARRIVAL AND PROCESS TIME COEFFICIENTS OF VARIATION ................................................ 373 20.21 QUEUE LENGTHS AND QUEUE DELAYS .......................................................................................... 374 20.22 MAXIMUM STABLE RELEASE RATES.............................................................................................. 375 20.23 THROUGHPUT AND YIELD .............................................................................................................. 375 20.24 RAW PROCESS TIME....................................................................................................................... 375 20.25 FUTURE WORK .............................................................................................................................. 376 21. 21.1 21.2 21.3 21.4 21.5 21.6 21.7 22. 22.1 22.2 22.3 22.4 22.5 23. 23.1 23.2 23.3 23.4 23.5 23.6 23.7 REFERENCE TOPICS: COST ANALYSIS ................................................................................. 377 INTRODUCTION .............................................................................................................................. 377 PRODUCT COST PER GOOD UNIT OUT ........................................................................................... 377 TOTAL FIXED COST........................................................................................................................ 380 TOTAL RECURRING COST............................................................................................................... 380 RAW UNIT COST ............................................................................................................................ 381 GROSS MARGIN ............................................................................................................................. 381 WIP VALUATION ........................................................................................................................... 383 REFERENCE TOPICS: SPACE AND LAYOUT ANALYSIS ................................................... 385 INTRODUCTION .............................................................................................................................. 385 TOTAL REQUIRED SPACE BY LAYOUT AREA.................................................................................. 385 TOTAL REQUIRED SPACE BY TYPE ................................................................................................. 386 TRAVEL MATRIX BY MOVE RATE .................................................................................................. 386 TRAVEL MATRIX BY DISTANCE RATE............................................................................................ 386 REFERENCE TOPICS: SIMULATION DETAILS .................................................................... 389 PSEUDO-RANDOM NUMBERS ......................................................................................................... 389 SIMULATION EVENT GRAPH........................................................................................................... 389 RANDOMIZED SEARCH TREES ........................................................................................................ 391 CALCULATING CONFIDENCE INTERVALS ....................................................................................... 391 TESTING FOR INITIALIZATION BIAS ................................................................................................ 393 ESTIMATED NUMBER OF VISITS ..................................................................................................... 394 OPERATOR DISPATCHING ............................................................................................................... 394
Factory Explorer viii
24. 24.1 24.2 24.3 24.4 24.5 24.6 24.7 24.8 25. 26.
REFERENCE TOPICS: VERIFICATION TESTS ...................................................................... 397 M/M/S QUEUE ............................................................................................................................... 397 M/G/1 QUEUE ................................................................................................................................ 398 M/M/1 QUEUES IN SERIES ............................................................................................................. 398 M/M/1 QUEUES IN SERIES WITH SCRAP ......................................................................................... 399 M/M/1 QUEUES IN SERIES WITH REWORK ..................................................................................... 399 M/M/1 QUEUE WITH TWO PRIORITY CLASSES ............................................................................... 400 M/M/1 QUEUE WITH LOADING AND UNLOADING .......................................................................... 400 VERIFICATION TEST SUITE ............................................................................................................. 401 BIBLIOGRAPHY ............................................................................................................................ 423 INDEX .............................................................................................................................................. 425
Factory Explorer ix
1. Introduction to Factory Explorer
1.1 Overview of Factory Explorer

Factory Explorer is an integrated capacity, cost, and cycle time analysis tool for manufacturing. Factory Explorer combines an Excel-based user interface with two performance analysis engines one containing analytic (static) methods and one containing simulation (dynamic) methods. The analytic engine uses a mathematical model to predict system capacity, minimum equipment and staffing requirements, resource usage, bottlenecks, factory gross margin, and product cost. The simulation analysis engine is a fast discrete-event simulator that provides estimates of cycle time, work-in-process levels, and inventory valuation. The Factory Explorer performance analysis engines run on Windows platforms. The Factory Explorer user interface is a Microsoft Excel visual basic application (compatible with Excel 97 or later), providing access to options, reports, and output charts in a familiar spreadsheet setting. Factory models can be stored as ASCII files or Microsoft Excel workbooks. A translator is also included for ManSim and Sematech Testbed models. Figure 1-1 diagrams the relationships among major system elements.
Excel Models ASCII Models Testbed Models ManSim Models User Selected Options Performance Analysis Engines Charts Reports Worksheets DOE Results Results Data
Figure 1-1: Factory Explorer System Diagram.
Factory Explorer 1
1. Introduction to Factory Explorer Figure 1-2 displays a more detailed input / output diagram of the Factory Explorer performance analysis engines.
User Selected Options Analytic Engine Predicts: Bottleneck Resources Tool Utilization Operator Utilization Space Requirements Capital Cost Gross Margin Product Cost Lot Move Rates Estimates: Cycle Time Work in Process Waiting Times Inventory Value
Input Model: Factory Data Product Data Lot Data Tool Data Operator Data Process Data
Simulation Engine
Figure 1-2: Input / Output Diagram: Factory Explorer performance analysis engines.
Factory Explorer modeling capabilities include support for machines, operators, multiple product types, scrap and rework, splitting, binning, and assembly. Splitting, binning, and assembly capabilities allow a single factory model to include several production stages, for example both front-end and back-end semiconductor manufacturing operations. Processing times can be specified as per-unit, per-lot, or perbatch (restricted batch formation via batch codes is supported). Machine and operator interruptions can be based on clock-time, busy-time, or units-of-work completed. Both sequence-dependent and sequence-independent setups are supported. Modeling of Kanban cells is supported. Factory Explorer currently does not support preemptive interruptions and dispatch rules, or limited buffers and blocking. Factory Explorer models can include seven different object types: factory, products, lots, processes, process steps, tool groups, and operator groups. Figure 1-3 displays an overview of the Factory Explorer object model. The maximum number of objects in a Factory Explorer model is limited on most platforms to around two billion, meaning that disk and memory space will more likely be constraining factors when building extremely large models.
2 Factory Explorer
1.2. Analytic Methods vs. Simulation Methods

Factory
Factory Produces...
Product1 Lot1
Product2 Lot2
...
Product / Lot Follows...
ProcessA
ProcessB
...
Process Consists of...
StepA1
StepA2
...
Step Requires Tool from...
Tool Group1
Tool Group2
...
Step Requires Operator from...
Op. Group1
Op. Group2
...
Figure 1-3: Overview of the Factory Explorer object model.
1.2 Analytic Methods vs. Simulation Methods

Effective modeling of discrete part manufacturing systems requires both analytical and simulation modeling capability. Buzacott & Shanthikumar, 1993. In Stochastic Models of Manufacturing Systems Factory Explorer uses both an analytic engine and a simulation engine when estimating factory performance measures. The main difference between analytic methods and simulation methods is the use of random numbers. Calculations performed by the analytic engine are the result of mathematical approximations and do not use random numbers. The simulation engine, on the other hand, uses random numbers to mimic (simulate) how the model would operate in the real world. Thus, the performance measures generated by the analytic engine (maximum throughput, etc.) will remain the same across multiple Factory Explorer runs. Performance measures generated by the simulation engine (cycle time, queue lengths, etc.) will generally vary across multiple runs, depending on the sequence of random numbers used. A second difference between analytic methods and simulation methods is the nature of the time horizon implicit in the analysis. The Factory Explorer analytic engine Copyright WWK 1995-2009 Factory Explorer 3
1. Introduction to Factory Explorer uses a steady-state framework. This framework assumes that performance measures such as throughput will, if the system is run long enough, eventually converge to one fixed value. Another assumption inherent in this framework is that these long-run performance measures are of interest to the experimenter. Either assumption may fail to hold. The first may fail due to the model being unstable, meaning that many performance measures will never converge to a fixed value, even if the model could be run forever. The latter assumption may fail if the real system under consideration has traits that mean finitehorizon performance, rather than steady-state, is of interest. For example, if a factory will only be in operation for a six-month period, then switched over to a completely different product, finite-horizon cycle time may be of more interest than steady-state tool throughput. Each framework has its place, however, in a complete system analysis, and both types of performance measures can lead to useful insights. Analytic methods and simulation methods each have their own strengths and weaknesses. Analytic methods are particularly useful for predicting maximum throughput, tool and operator usage, space requirements, capital cost, gross margin, and product cost. Analytic methods are generally quite fast, and the results are somewhat easier to interpret than simulation, since there is no randomness. However, methods for approximating some performance measures in complicated models still need work, and thus there is often a need to resort to simulation. Simulation methods are quite useful for cycle time and queue length estimation (two areas where analytic methods generally perform poorly), and can be used to estimate any steady-state or finite-horizon performance measure. Simulation estimates of steady-state performance are often biased, however, simply because it is not possible to simulate for an infinite amount of time. Also, depending on the simulation run length, it generally takes much longer to execute a simulation than to execute analytic methods. With the faster turn-around time of analytic methods, more iterations can be performed in the analysis process, generally leading to superior results. In summary, analytic methods and simulation methods are complementary analysis techniques. Each can provide part of the answer, but neither can currently provide the complete answer. That is why both are included in Factory Explorer.
1.3 Benefits of Integrated Cost Analysis

Cost analysis is often treated as a separate task from capacity and simulation modeling activities. Several important factory-level cost performance measures, however, rely on detailed capacity analysis calculations. In fact, much of the difficult groundwork for making these calculations has already been completed in Factory Explorer's capacity and simulation analysis engines. When combined with cost analysis, these activities fit quite naturally together, and give a more complete picture of factory performance than isolated analyses. Also, capacity and simulation analysis are increasingly used to support strategic and tactical business decisions. These decisions are most often framed in terms of their impact on the bottom line. Therefore, effective decision-support tools must speak not only in terms of capacity and cycle time, but also in terms of dollars.
4 Factory Explorer
1.4. A Quick Tour of Factory Explorer's Excel Interface
1.4 A Quick Tour of Factory Explorer's Excel Interface

Factory Explorer includes an easy to use Excel interface. In this environment, Factory Explorer models are stored as Excel workbooks. When Factory Explorer is loaded, all of its features are accessed via the FactoryX pull-down menu, shown in Figure 1-4. Sample model Aspen.xls (included with Factory Explorer) is in the background. From the FactoryX pull-down menu, one can create new Factory Explorer Excel models, run Factory Explorer, view models in Factory Explorer's ASCII (as opposed to Excel) format, perform batch execution of multiple model runs, perform output analysis, set system preferences, and view the table of contents for Factory Explorer's on-line help. This quick tour only covers the Run Factory Explorer and Analyze Output dialogs. For information on other dialogs, see the on-line help.
Figure 1-4: Products worksheet, Aspen model. Factory Explorer features are accessed via the FactoryX pull-down menu.
Factory Explorer 5
1. Introduction to Factory Explorer Factory Explorer Excel models are composed of a series of worksheets. Shown in the background of Figure 1-4 is the products worksheet. This worksheet contains product-level data, such as lot size, release information, cost / revenue data, etc. Other required worksheets are the factory worksheet, lots worksheet, tools worksheet, and operators worksheet. There is a separate worksheet for each process flow (multiple products may follow a single process flow). Factory Explorer uses keywords in the first row and column of a worksheet to determine what data is stored in each column, and to determine which rows contain data. Several features make Excel models particularly flexible. First, any cell in the model can be the result of an Excel formula. Second, additional columns or rows may be inserted into the model, and as long as the first cell is blank, Factory Explorer will ignore the entire column or row. These additional columns or rows can then be used to store input data for Excel formulas used in the model. For example, columns containing different types of tool recurring costs can be summed in a formula that calculates Factory Explorer's Annual Recurring Cost Per Tool column. Or, a column containing process step yield data can be used in a formula that calculates Factory Explorer's scrap-related columns. In general, this flexibility is useful for taking data in the form most familiar to users, and automatically translating it to the form required by Factory Explorer. Excel models may also contain worksheets beyond those required by Factory Explorer. For example, a model can include a change log worksheet that documents all model updates for future reference (in fact, Excel 97 can automatically track data changes in this fashion). Interesting output results can be stored in the same workbook as the model this makes distribution of the model and associated results via email particularly easy. Users with programming experience can write Excel Visual Basic for Applications (VBA) routines that automatically create or update model data using input from other systems this code can then be stored in a worksheet alongside the model. Taken together, these features make it much easier to incorporate data from a wide variety of sources into a Factory Explorer Excel model, and to maintain the model once it is created. Combined with the fact that many users are already familiar with Excel, this flexibility greatly reduces the amount of time required to build a model, allowing more time for model analysis. Model analysis is performed using the Run Factory Explorer dialog, the next topic of this quick tour.
6 Factory Explorer
1.4. A Quick Tour of Factory Explorer's Excel Interface The Run Factory Explorer dialog, shown in Figure 1-5, controls all run-time options. Factory Explorer automatically maintains a list of recently-analyzed models in the Model drop-down list. Users can select one of these models, or click on the Model button to display a model selection dialog. Primary run-time options are specified on the Run Factory Explorer dialog. Other run-time options are specified on the eight additional option dialogs, available from the bottom of the Run Factory Explorer dialog.
Figure 1-5: Run Factory Explorer dialog. Primary run-time options (model name, type of analysis, etc.) are specified here. Other run-time options are specified on the eight additional run-time option dialogs.
Once all run-time options have been specified, Factory Explorer is ready to perform the requested analysis. Factory Explorer displays the current run-time command to be executed at the bottom of the Run Factory Explorer dialog, as in Figure 1-5. In this case, Factory Explorer will perform capacity analysis, cost analysis, and simulation on model Aspen, which is stored in Excel format. The starting date for the analysis is January 1st, 2001, and the run length is four quarters. Factory Explorer will analyze capacity at the start of each quarter, and will simulate for the entire year. Outputs will be available on a quarterly basis.
Factory Explorer 7
1. Introduction to Factory Explorer The Factory Explorer analysis engines are written in portable ANSI C code. The analysis engines open an output console window, shown in Figure 1-6. Messages from the analysis engines (error messages, status updates, etc.) are displayed on this output console. At run completion, the output console waits for user confirmation before closing. The messages displayed on the output console are also written to a file that can be viewed from the Factory Explorer Analyze Output dialog.
Figure 1-6: Factory Explorer output console. Messages from the analysis engines are displayed on this console.
8 Factory Explorer
1.4. A Quick Tour of Factory Explorer's Excel Interface Factory Explorer's output analysis features are accessed via the Analyze Output option on the FactoryX pull-down menu. This dialog is shown in Figure 1-7. Factory Explorer generates output text reports, Excel charts, and Excel worksheets. Text reports primarily contain summaries of the input model data. Excel charts and worksheets contain all analysis outputs. Selecting one or more outputs and clicking on Create Selected Outputs causes Factory Explorer to build these output charts and worksheets. Not all charts and worksheets are available for every run, however, as some require specific run-time options. Output results charts and worksheets can be placed in any open workbook, or in a new workbook (as selected in Figure 1-7). A wide variety of custom charts may also be created using Factory Explorer's custom chart wizard.
Figure 1-7: Analyze Output dialog. Factory Explorer's output reports, charts, and worksheets are accessed from this dialog. For additional flexibility, Factory Explorer's custom chart wizard can be used to easily create a wide variety of output charts.
Factory Explorer 9
1. Introduction to Factory Explorer Factory Explorer output charts are regular Excel charts, so they may be edited, copied and pasted to other documents, etc., just like any other Excel chart. Figure 1-8 displays Factory Explorer's Cycle Time Contribution by ToolGroup Chart. This chart pinpoints the tools most responsible for product cycle time. Chart data is stored in the worksheet immediately to the left of the chart. Factory Explorer uses an Excel AutoFilter to select the top ten cycle time contributors. Changing this AutoFilter setting on the data worksheet (for example, to display the top five cycle time contributors) automatically updates the output chart. In general, data manipulation on the associated data worksheet makes chart customization much easier. For example, users can easily re-sort the underlying chart records, display a particular set of records, etc. Since users can customize existing charts rather than taking the time to build their own, more time is available for results analysis.
Figure 1-8: Cycle Time Contribution by ToolGroup Chart. Factory Explorer output charts are regular Excel charts, and as such may be manipulated, copied and pasted to other documents, etc. Chart data is stored in the worksheet immediately to the left of the chart.
10 Factory Explorer
1.5. Getting Answers with Factory Explorer This quick tour of Factory Explorer closes with a look at the on-line help's table of contents, shown in Figure 1-9. In addition to these general topics, detailed on-line help is available for each dialog simply select the dialog's Help button. If the on-line help doesn't answer your question, check the index at the back of the manual. Finally, don't hesitate to call upon technical support if you need assistance contact information is listed in the front of the manual.
Figure 1-9: Table of contents for Factory Explorer's on-line help.
1.5 Getting Answers with Factory Explorer

A successful model is one that can answer the questions posed of it. Many analysis questions can be answered with Factory Explorer's automated output charts. This section presents several such sample charts, and the questions they are designed to answer. Factory Explorer can also generate a complete set of detailed reports and worksheets that
Factory Explorer 11
1. Introduction to Factory Explorer support and expand on the data presented in output charts. For a full description of Factory Explorer's output reports, charts, and worksheets, see Chapter 7 of the manual. The model used here is Aspen.xls (included with Factory Explorer), run for 4 quarters starting on January 1st, 2001 unless otherwise noted. This model is a revised version of the Sematech Testbed dataset set4. See Section 17.3 of the manual for more information on the Testbed datasets. 1.5.1 What Is The Best Factory Size? When planning a new factory, it is obvious that product cost and total fixed cost depend on the factory's planned capacity. The larger the factory, the more economies of scale will lower product cost. However, large factories require more capital equipment. To quantify these effects, use Factory Explorer's Product Cost & Total Fixed Cost vs. Start Rate Chart, shown in Figure 1-10. For this analysis, a minimum toolset is generated for each start rate, based on a suggested capacity loading% of 85% (this figure can be controlled with run-time options). Economies of scale are much smaller above 2,000 unit starts per week, while a $40,000,000 factory can support approximately 1,500 unit starts per week. These results were generated using capacity analysis and cost analysis no simulation was required.
Product Cost & Total Fixed Cost vs Release Rate
$900.00 $60,000,000
$800.00 $50,000,000 $700.00
Cost Per Good Unit Out
$600.00
$40,000,000 Total Fixed Cost
$500.00 $30,000,000 $400.00
Cost Per Good Unit Out Total Fixed Cost
$300.00
$20,000,000
$200.00 $10,000,000 $100.00
$0.00 500.0 1000.0 1500.0 2000.0 2500.0 Release Rate (Units Per Week)
$0
Figure 1-10: Product Cost & Total Fixed Cost vs. Start Rate Chart, Aspen model. This chart quantifies the tradeoff between factory capacity, product cost, and total fixed cost. For this analysis, a minimum toolset is generated for each start rate, based on a suggested capacity loading% of 85% (this figure can be controlled with run-time options). Economies of scale are much smaller above 2,000 unit starts per week, while a $40,000,000 factory can support approximately 1,500 unit starts per week. These results were generated using capacity analysis and cost analysis no simulation was required.
12 Factory Explorer
1.5. Getting Answers with Factory Explorer Note: The run options to generate the chart in Figure 1-10 are: -DoCap DoCost StartDate 2001-01-01 RunLen 1 RunLenUM Quarters Reps 5 DelLots ReleaseRate 500 ReleaseRateUM UnitsPerWeek AddRate 500 AddRateUM UnitsPerWeek -UseSugg 1.5.2 How Much Slack Capacity Should Be Reserved? When planning the toolset for a new factory, the amount of slack capacity reserved across all tools is an important variable. For a given start rate, reserving a large amount of slack capacity usually produces a good cycle time, but forces additional capital equipment purchases. To quantify these tradeoffs, use Factory Explorer's Fixed Cost & Cycle Time vs. Suggested Capacity Loading% Chart, shown in Figure 1-11. For this analysis, the start rate is held constant, and a minimum toolset is generated for each suggested capacity loading%. Reserving a small amount of slack capacity (setting the suggested capacity loading% to a high number) ensures a lower product cost, but drives up cycle time. These results were generated using capacity analysis, cost analysis, and simulation analysis.
Fixed Cost & Cycle Time vs Suggested Capacity Loading%
$50,000,000 8.0
7.0 $40,000,000 6.0
Total Fixed Cost
$30,000,000
5.0
Cycle Time Over RPT
4.0
Total Fixed Cost Cycle Time Over RPT
$20,000,000
3.0
2.0 $10,000,000 1.0
$0 55.0% 65.0% 75.0% Sugg Capacity Loading 85.0% 95.0%
0.0
Figure 1-11: Fixed Cost & Cycle Time vs. Suggested Capacity Loading% Chart, Aspen model. For this analysis, the start rate is held constant, and a minimum toolset is generated for each suggested capacity loading%. Reserving a small amount of slack capacity (setting the suggested capacity loading% to a high number) ensures a lower product cost, but drives up cycle time. These results were generated using capacity analysis, cost analysis, and simulation analysis.
Note: The run options to generate the chart in Figure 1-11 are: -DoCap DoSim DoCost StartDate 2001-01-01 RunLen 1 RunLenUM Years Reps 5 DelLots ReleaseRate 1500 ReleaseRateUM UnitsPerWeek SuggLoading 55 AddSuggPct 10 -UseSugg
Factory Explorer 13
1.5.3 How Does Factory Loading Affect Product Cost and Cycle Time? Once a factory has been built, factory loading will affect both product cost and cycle time. The closer the factory as a whole runs to its capacity, the lower product costs will be. However, running close to capacity often drives cycle time higher. To examine the tradeoff between capacity loading, product cost, and cycle time, use Factory Explorer's Cycle Time Characteristic Curve Chart, shown in Figure 1-12. For this analysis, the toolset is held constant and the start rate is varied. Cycle time rises non-linearly with capacity loading, while product cost decreases linearly. These results were generated using capacity analysis, cost analysis, and simulation analysis.
Cycle Time Characteristic Curve
$1,000.00 6.0
$900.00 5.0 $800.00
$700.00 Cost Per Good Unit Out 4.0 $600.00 Cycle Time Over RPT
$500.00
3.0
Cost Per Good Unit Out Cycle Time Over RPT
$400.00 2.0 $300.00
$200.00 1.0 $100.00
$0.00 55.0% 65.0% 75.0% Factory Capacity Loading 85.0% 95.0%
0.0
Figure 1-12: Cycle Time Characteristic Curve Chart, Aspen model. This chart quantifies the tradeoff between factory capacity loading, product cost, and cycle time. For this analysis, the toolset is held constant and the start rate is varied. Cycle time rises quickly when the factory is loaded above 85%, while product cost decreases linearly as the loading increases. These results were generated using capacity analysis, cost analysis, and simulation analysis.
14 Factory Explorer
1.5. Getting Answers with Factory Explorer 1.5.4 What Are The Top Capacity Constraints (Bottlenecks)? For a given tool set, product mix, and start rate, one tool or operator group will constrain capacity (e.g. the bottleneck resource). However, even if this top capacity constraint is lifted by adding tools or operators, or making other improvements, there may be other capacity constraints lurking just behind. To see all capacity constraints at once, use Factory Explorer's Bottleneck Resource Chart, shown in Figure 1-13. For tool groups, the y-axis label includes the tool group name, the number of tools, and the fixed cost per tool. For operator groups, the y-axis label includes the operator group name and the number of operators. Tool group AME1 is the top capacity constraint, but the factory has a significant amount of spare capacity (about 10%). These results were generated using capacity analysis no simulation was required.
Top Bottleneck Resources
Percent Factory Non Sched Percent Offline 4 (Break) Percent Non Rework 0.0 AME1 1_Tools@$1.2M C1-9 1_Tools@$300.0K D1-9 1_Ops D1-9 2_Tools@$300.0K AME 1_Ops AME2 1_Tools@$1.2M DFC4 1_Tools@$500.0K PE1-5 2_Tools@$900.0K C1-9 1_Ops DFC4 1_Ops 0.0 20.0 39.6 35.1 32.2 29.0 40.0 60.0 80.0 100.0 120.0 46.8 58.8 57.7 55.4 54.7 Percent Offline 1 (Failure) Percent Setup Percent Free 20.0 40.0 Percent Offline 2 (PM) Percent Repair Capacity Loading (Boxed Number) 60.0 72.2 80.0 100.0 120.0 Percent Offline 3 (QualityCheck) Percent Rework
Figure 1-13: Bottleneck Resource Chart (bar-chart format), Aspen model. This chart displays top capacity constraint resources (tool groups or operator groups) and the time spent by each resource on various tasks. In this model, tool group AME1 is the top capacity constraint. For tool group, the label includes the tool group name, the number of tools, and the fixed cost per tool. For operator groups, the label includes the operator group name and the number of operators. These results were generated using capacity analysis no simulation was required.
Factory Explorer 15
1. Introduction to Factory Explorer 1.5.5 What Are The Top Cycle Time Contributors? In contrast to capacity improvements, which must first target bottleneck tools, cycle time improvements can be made at any tool within the factory. However, cycle time reduction opportunities are usually best focused on the tools that contribute most heavily to overall cycle time. To determine these tools, use Factory Explorer's Cycle Time Contribution by Tool Group Chart, shown in Figure 1-14. Although it is not heavily loaded, tool group QLESS is responsible for nearly 20% of total cycle time. Understanding and reducing this tool group's cycle time contribution could reap substantial benefits. These results were generated using simulation analysis.
Cycle Time Contribution by ToolGroup (Label shows ToolGroup, Capacity Loading%, Operator Delay%, #Tools@Price)
10 9 60% 8 Cycle Time Contribution (Days) 7 6 5 4 3 2 10% 1 0 QLESS 43% 10% 1@$250.0K ION1-3 48% 5% 1@$2.0M PE1-5 69% 2% 2@$900.0K ToolGroup Total Process Time Total Queue Time Cumulative Contribution % D1-9 75% 5% 3@$300.0K DFC4 80% 3% 1@$500.0K 0% 30% 50% 70%
40%
20%
Figure 1-14: Cycle Time Contribution by Tool Group Chart, Aspen model. This chart displays the tool groups that contribute most heavily to cycle time. Although it is not heavily loaded, tool group QLESS is responsible for nearly 20% of total cycle time. Understanding and reducing this tool group's cycle time contribution could reap substantial benefits. These results were generated using simulation analysis.
16 Factory Explorer
1.5. Getting Answers with Factory Explorer 1.5.6 What is the Trend in WIP and Cycle Time? In any complex factory, WIP and cycle time vary as time passes. Understanding and controlling these trends can significantly improve a factory's on-time delivery performance. To see how a factory's WIP and cycle time change over time, use Factory Explorer's WIP and Cycle Time by Period Chart, shown in Figure 1-15. The significant rise in WIP and cycle time in this factory makes it likely that the factory will soon have trouble meeting delivery dates. These results were generated using simulation no capacity analysis was required.
WIP & Cycle Time by Period

4000.0 60.0
3500.0 Average Cycle Time (Days), Max Cycle Time (Days) 50.0 3000.0 Average Unit WIP, Max Unit WIP 40.0 2500.0
Average Unit WIP Max Unit WIP Average Cycle Time (Days) Max Cycle Time (Days)
2000.0
30.0
1500.0 20.0 1000.0 10.0 500.0
0.0 2001-01-01 2001-04-01 2001-07-01 2001-10-01 Period Start Date
0.0
Figure 1-15: WIP and Cycle Time by Period Chart, Aspen model. The significant rise in WIP and cycle time in this factory makes it likely that the factory will soon have trouble meeting delivery dates. These results were generated using simulation no capacity analysis was required.
Factory Explorer 17
1.5.7 How Significant Are Cycle Time Outliers? Factory Explorer's Cycle Time by Lot Exit Time Chart shows how cycle time varies over time, and displays the existence, if any, of cycle time outliers. A cycle time histogram summarizes this same data to show the relative frequency of cycle time outliers. To see if cycle time outliers are significant, use Factory Explorer's Cycle Time Histogram Chart, shown in Figure 1-16. In this factory, the majority of lots have cycle times over 25 days. These results were generated using simulation no capacity analysis was required.
Cycle Time Histogram
9%
8%
7%
6% Percent Observed
5%
4%
3%
2%
1%
0% 0 10 20 30 Cycle Time (Days) 40 50 60
Figure 1-16: Cycle Time Histogram Chart, Aspen model. The majority of lots have cycle times between 20 and 30 days. However, a significant number of lots have cycle times exceeding 30 days. These results were generated using simulation no capacity analysis was required.
1.5.8 Summary Factory Explorer's automated output charts can help answer many common analysis questions. Not all charts have been presented in this section. In addition to charts, Factory Explorer provides a complete set of detailed output reports and worksheets. For a full list of Factory Explorer output reports, charts, and worksheets, see Chapter 7 of the manual. For those wishing to perform specialized output analysis not provided by Factory Explorer, many Factory Explorer output results are stored in ASCII text files. These output files can be read and analyzed independently. For documentation on output file formats, see Chapter 14 of the manual.
18 Factory Explorer
2. Introduction to the User Manual
2.1 Introduction
This user manual is organized into two parts. The user's guide is a narrative that describes how to use Factory Explorer to model many different kinds of factory activities. The reference topics detail the calculations performed by Factory Explorer. The purpose of this introductory chapter is to give you some tips on using the manual effectively, and to acquaint you with the terminology and formatting conventions used throughout this manual.
2.2 If You Are New to Factory Explorer

Begin by scanning Chapter 3 it contains software installation instructions and contact information for technical support. Next, read through Chapters 4, 5, and 6 they contain the basic information you need to build and analyze Factory Explorer models. For an overview of ramp data modeling, see Chapter 8. For more complex modeling tasks, see Chapter 9. Finally, project management skills are often just as important as technical skills when completing a modeling project see Chapter 10 for some tips on managing a successful analysis project.
2.3 If You Are Upgrading from a Prior Release

For information on changes in this release, see Chapter 11. For instructions on translating your Factory Explorer models to the current format, see Chapter 12.
2.4 Where to Look If You Have a Question

If you have a question that begins How do I model?, you should begin by looking in the user's guide. If your question is of the form How does Factory Explorer calculate?, the answer will probably lie in the reference topics. Don't forget to check out the online help and the index at the end of this manual -- they can also help you quickly track down the answer to your question. And, as always, feel free to contact technical support for additional help.
Factory Explorer 19
2. Introduction to the User Manual
2.5 Terminology
Factory Explorer is an integrated analysis and simulation tool tailored to manufacturing. Although Factory Explorer can model many non-manufacturing systems, this manual primarily uses manufacturing terminology. Table 2-1 presents a list of definitions and equivalent terms.
Table 2-1: Definitions and equivalencies.
Term Lot Unit Unit Type Process Step Process Flow Product
Definition Basic unit of work in the factory. Identical pieces that make up a lot. Classification of units (e.g. Wafers vs. Die, or Cells vs. Modules). Single operation performed on one or more lots. Sequence of process steps a lot must follow before exiting factory. Classification of lots. All lots that are the same product must follow the same process flow. Multiple products may follow the same process flow, however. Classification of products (e.g. Memory vs. ASIC, Regular vs. Engineering). A product that, upon reaching the end of its process flow, is assembled into another product. A product that, upon reaching the end of its process flow, is transformed into another product. A product that exits the factory when it reaches the end of its process flow, i.e. a product that is not a sub-assembly product or a sub-transform product. A product that is assembled from one or more sub-assembly products. A product that is transformed from a sub-transform product. A product that is released directly into the factory, i.e. a product that is not an assembly product or a transform product. Rate at which new lots or units enter the factory. Applicable only to release products. Rate at which lots or units finish a
Equivalent Terms Job Wafer, Display, Component
Routing Step Routing Sequence Job type, Customer Type
Product Type Sub-Assembly Product Sub-Transform Product End Product
Assembly Product Transform Product Release Product
Release Rate
Start Rate, Arrival Rate
Throughput Rate 20 Factory Explorer
2.5. Terminology Term Exit Rate Definition process flow. Rate at which lots or units exit the factory. Applicable only to endproducts. Collection of identical tools used to perform work required by a lot. Collection of operators with equivalent skills. A single tool or operator. Generic name for a tool or operator group. For a tool or operator group, max going rate represents the factory throughput rate (for products processed by this tool or operator group) that would cause the resource group to have a capacity loading of exactly 100%. For an individual tool or operator, max going rate is the tool or operator group max going rate divided by the number of tools or operators, respectively. Max going rate, expressed in terms of units per day. Common abbreviation for daily going rate. The DGR for a particular resource group. Adjusted DGR minus Group DGR. Similar to Group DGR, but adjusted DGR represents the factory throughput rate (for all products with unit type matching that of the resource group, not just those processed on the resource group) that would cause the resource group to have a capacity loading of exactly 100%. For a particular resource group, scheduled DGR is the sum of factory throughput rates for all products specifying a unit type that matches the resource group's unit type. Ratio of release rates in a multi-product model. A 2:1 mix for products A and B means A's release rate is twice B's. Factory Explorer 21 Equivalent Terms
Tool Group Operator Group Resource Resource Group Max Going Rate
Queue, Workcenter, Station, Workstation Operator Set, Operator Pool
Daily Going Rate DGR Group DGR Group DGR Adjustment Adjusted DGR
Scheduled DGR
Product Mix
2. Introduction to the User Manual Term Batch Tool Tool Lead Time Dispatch Rule Cycle Time Definition Tool that can process more than one lot in a single operation. The estimated time required to purchase, install, and qualify a particular tool. Method used when deciding which lot to process next (e.g. First-In-First-Out). Total time spent by a lot in the factory. Equivalent Terms
Service Discipline, Sequencing Rule Time in System, TurnAround Time, Flow Time
Product Lead Time
Critical Path
Time in Queue Interruption
Nonscheduled% Offline% Repair% Setup% Non Rework% Rework% Working%
Occupied%
Time elapsed from the release of the first product that feeds an end-product to the completion of the end-product, assuming no delay at transform or assembly points. Applicable only to endproducts. Of all possible sequences of products that feed an end-product, the sequence with the longest total cycle time. The total cycle time for the critical path is the product lead time for the end-product. Time a lot spends at a tool group waiting Waiting Time, Queue for service to begin. Delay Event that causes a resource to be unavailable for processing (offline) for some period of time. Interruptions are typically used to model failures, maintenance, engineering time, operator breaks, etc. Percent of time a resource is unavailable because it is not scheduled. Percent of time a resource is unavailable due to interruptions. Percent of time an operator group spends repairing tool groups. Percent of time a resource is unavailable due to setup. Percent of time a resource spends processing non-rework lots. Percent of time a resource spends processing rework lots. Percent of time a resource spends processing lots. Non Rework% + Rework%. Nonscheduled% + Offline% + Repair%
22 Factory Explorer
2.5. Terminology Term Free% Input Rate Theoretical Max Processing Rate Definition + Setup% + Working%. 100 Occupied%. Rate at which lots or units arrive to a factory, tool group, or operator group. Maximum rate at which a factory, tool group, or operator group could process lots or units if not affected by interruptions, setup, or repair. Assumes product mix held constant. Maximum rate at which a factory, tool group, or operator group can actually process lots or units (i.e. the Input Rate at which Free% is zero). Assumes product mix held constant. 100 * Input Rate / Actual Max Processing Rate. A process step that can be performed on more than one tool group, and thus must be listed more than once in the process flow. For an alternative step, the percent of lots arriving to the set of all possible alternatives for this step that are processed on this particular alternative. A tool held across multiple process steps. Set of steps across which a hold tool is held. The first step in a hold tool region. The last step in a hold tool region. A step within a process flow where a lot is split into smaller lots. The process step where split lots are recombined into the original lot. The inclusive set of process steps between the split step and unsplit step. The maximum size of a split lot, measured in units. A split where lot splitting occurs during processing, as an alternative to splitting at the end of the step. Input and output tool group buffers restrict the amount of WIP that can be stored before and after a tool group. Equivalent Terms
Actual Max Processing Rate
Capacity Loading% Alternative Step
Alternative%
Hold Tool Hold Tool Region Hold Step Free After Step Split Step Unsplit Step Split Lot Region Split Lot Size Mid-Process Split
Tool Group Buffer
Input Buffer, Output Buffer
Factory Explorer 23
2. Introduction to the User Manual Term Tool States Definition Specific states a tool may be in. Each tool state has differing processing rate impacts that characterize the condition of the tool. Equivalent Terms
2.6 Formatting Conventions

The following formatting conventions are used throughout this manual to identify different types of information. Format UPPERCASE type Type of Information A keyword in a Factory Explorer Excel model. For example, the TOOLGROUP keyword in a Factory Explorer Excel model identifies a column containing tool group names. 1) Text you type if instructed by the manual. 2) A statement in a Factory Explorer ASCII model. For example, the ToolGroup statement in a Factory Explorer ASCII model identifies the tool group name and number of tools. bold type A Factory Explorer run-time option. On platforms with Excel, options are specified in Factory Explorer user interface dialogs. On other platforms, options are specified on the command line. For example, the Unstable option is used to specify that it is OK to execute the simulation with unstable release rates. 1) Specialized terms. 2) Variables in a mathematical equation. 3) A model name or a name for an element in a model such as a tool group or processing step. 4) A file name. For example, the sample Factory Explorer model Aspen is stored in Excel format in the file Aspen.xls. The sample model is stored in ASCII format in the file Aspen.fx2. Underline type A placeholder for data you must supply. For example, the RunLen length run-time option specifies that the analysis run length is given by the value you enter in place of length. Similarly, the results data file for an analysis run is normally called modelname.rdf, so if your model is named factory, the results data file for your analysis run is factory.rdf.
Bold type
Italic type
24 Factory Explorer
Part I User's Guide
Factory Explorer 25
3. User's Guide: Getting Started
3.1 Hardware Security (HASP) Keys

You will receive a hardware security (HASP) key for use with each copy of Factory Explorer. This key must be attached to the parallel or USB ports before Factory Explorer will run on a machine. Factory Explorer checks for the presence of the key during the actual analysis run, so you can load Factory Explorer and look at sample models, but you cannot perform any analysis runs without the key. If you will be running Factory Explorer on more than one machine, install the security key drivers on each machine. Then when you wish to move between licensed machines, simply ensure that there is a hardware security key attached to the parallel or USB ports of the machine you are using.
3.2 Installation on Windows Platforms

Along with this manual, you should receive download instructions for the Factory Explorer software. Installation on Windows platforms requires you to be logged in as a user with administrator privileges. Run the setup program. Follow the instructions on screen for completing the installation. After the completion of setup, you will be prompted to install the hardware security (HASP) key drivers. These drivers must be installed in order to run Factory Explorer. Leave the checkbox selected and click Finish to install the drivers. The setup process should add an entry to your Windows Program menu titled Factory Explorer vX.X and a corresponding Shortcut on your Windows Desktop. Running Factory Explorer will start Excel (see the front of this manual for supported versions of Excel) and load the Factory Explorer user interface. In addition to the normal Excel menu system, Factory Explorer adds a drop-down menu titled FactoryX. From this menu, you access the features of Factory Explorer. 3.2.1 Network HASP License Manager Installation If you received a network (red) HASP key with Factory Explorer, you must setup the License Manager for HASP on the machine where the key will be installed. Run Copyright WWK 1995-2009 Factory Explorer 27
3. User's Guide: Getting Started lmsetup.exe available on the same download site. During this setup, you may choose to install the license manager as a program (i.e. you must manually start the license manager on the server each time you want users to be able to run Factory Explorer) or as a service (so that it is available any time the server is available). Note that each networked machine that will run Factory Explorer using this network HASP key must have the key drivers installed as described above in Installation on Windows Platforms.
3.3 Installation Notes

3.3.1 Windows Not Supported Factory Explorer cannot be executed on the Windows 98 or earlier operating systems. See the front of this manual for a list of supported platforms. 3.3.2 A1-style References Required Factory Explorer requires that Excel use A1-style references (columns labeled with letters, rows labeled with numbers). If your copy of Excel is using R1C1-style references (columns and rows both labeled with numbers), Factory Explorer will ask your permission to switch to A1-style references when it is first loaded. If you respond negatively, Factory Explorer will exit. If you respond affirmatively, Factory Explorer will instruct Excel to use A1-style references. The setting for this option can be accessed within Excel by selecting Tools | Options | General. 3.3.3 Automatic Excel Add-Ins The Factory Explorer Version 2 user interface add-in, fx.xla, cannot be installed as an automatic Excel Add-In using the Excel Tools | Add-Ins dialog. This limitation is due to a change that protects against decompilation. To start Factory Explorer when Excel is not currently running, use the Factory Explorer program icon to start Excel and load Factory Explorer. If you are already running Excel, use File | Open to load the user interface addin fx.xla. If the Version 1 user interface was installed as an automatic Add-In using the Excel Tools | Add-Ins dialog, you should remove it using this same dialog. If you do not remove the Version 1 user interface, both Version 1 and Version 2 will be loaded when you start Version 2. 3.3.4 Excel 97 or Later Required for Windows Platforms Factory Explorer v2.6 and subsequent releases require Excel 97 or later. Excel 5 and Excel 95 are no longer supported. 3.3.5 Strange Factory Explorer Start-Up Behavior in Windows NT 4.0 When starting Factory Explorer on a Windows NT 4.0 machine, the operating system may load Excel, then load Factory Explorer, and then attempt to load Factory Explorer a second time, triggering a warning message from Excel. This behavior does not appear to be specific to Factory Explorer, or to a particular version of Excel (it occurs for Excel
28 Factory Explorer
3.4. Technical Support 97). The behavior is not critical no matter what response is given to the warning message, Factory Explorer successfully loads and can be used without problems. If you wish to remove this behavior, take the following actions. First, log in as administrator. Second, double-click on the My Computer icon on the desktop. From the resulting window's menu bar, select View, then Options, then File Types. Scroll through the list of defined types until you find Microsoft Excel Add-In. Double-click on this item. In the list of actions that appears, double-click on the Open action. In the resulting dialog, un-check the Use DDE checkbox. Select OK, then close all open dialogs. Once you log out and log back in as a regular user, the double-loading behavior should no longer occur. 3.3.6 Error During First Load of Factory Explorer in Excel 97 During the first load of Factory Explorer on systems running Excel 97, Excel may sometimes halt with a Visual Basic error message. This behavior appears to be due to a bug in Excel 97. To work around this situation, simply exit from Excel and re-load Factory Explorer. The error should not occur on subsequent invocations of Factory Explorer. If the error persists, contact technical support. 3.3.7 Upgrading from a Prior Version of Factory Explorer If you are installing a full version upgrade (e.g. you are moving from Factory Explorer 1.0 to Factory Explorer 2.0), you should keep your prior version of Factory Explorer installed until you have translated all of your models to the current version's format. This translation process normally requires that you have both versions of the system installed. For instructions on translating your Factory Explorer models to the current version's format, see Chapter 12. If you are not installing a full version upgrade (e.g. you are moving from Factory Explorer 2.0 to Factory Explorer 2.1), no model translation is necessary. 3.3.8 Factory Commander software issue after Installation of Factory Explorer On Windows 2000 systems where Factory Commander is installed, Factory Commander may exhibit the following behavior after the installation of Factory Explorer. The first time Factory Commander is launched following the installation of Factory Explorer, you may be asked to insert your original Factory Commander installation CDRom. Place your Factory Commander CD in the drive and continue. This will only occur one time.
3.4 Technical Support

Please refer all technical support questions to: Wright Williams & Kelly, Inc. 6200 Stoneridge Mall Road, 3rd Floor Pleasanton, CA 94588 USA Phone: (925) 399-6246 Fax: (925) 396-6174 Web: http://www.wwk.com Email: support@wwk.com
Factory Explorer 29
3. User's Guide: Getting Started
3.5 Factory Explorer Version Numbers

The integral portion of the Factory Explorer version number is incremented only when the software can no longer read models formatted for earlier releases. That is, Factory Explorer 2.0 cannot directly read models formatted for Factory Explorer 1.0. The decimal portion of the Factory Explorer version number is incremented whenever a major modification is completed, but reverse-compatibility is being maintained. Thus, Factory Explorer 2.1 can directly read models formatted for Factory Explorer 2.0. Similarly, Factory Explorer 2.2 can directly read models formatted for either Factory Explorer 2.0 or 2.1. Minor bug fixes that do not include significant enhancements are denoted by a third character, e.g. Factory Explorer 2.8.1. See Chapter 12 for information on translating Factory Explorer models from earlier versions.
30 Factory Explorer
4. User's Guide: Building A Basic Model
4.1 Introduction
In this chapter, we illustrate the building blocks of Factory Explorer model construction with a basic model. In this example, we model the processing of a single product, 3-hole punched filler paper, through two operations, ruling, and punch. Paper arrives in 100sheet lots, is ruled, and then the holes are punched. We make the following assumptions, which we will gradually relax in later sections. First, there are no machine failures, reworking of product, or scrapping of product. Second, operators are always available to run the ruling and punch machines. Third, there is exactly one ruling machine and one punch machine. Finally, there are no lots present initially. We can tell Factory Explorer to start with a given configuration of lots at the start of simulated time, but for our example we will assume an empty system. The input variables for this example are the arrival rate of paper (in this case, specified in sheets of paper per day), and processing times on machines. All process times in Factory Explorer models are specified in hours. Based on prior experience, we estimate that twelve hundred sheets of paper (or twelve lots) arrive every day. For this model, we will assume each arrival consists of one lot, and that two hours passes between each lot arrival. We'll assume that process times have some variability, and range +/20% from the average. For the ruling machine, the average load time is fifteen minutes, the average per-sheet processing time is thirty seconds, and the average unload time is fifteen minutes. For the punch machine, the average load time is fifteen minutes, the average per-lot process time is five minutes, and the average unload time is three minutes. When entering these times into our model, we'll convert them to hours. Call this model paper. Factory Explorer models may be stored as ASCII text files or Excel workbooks. All of the sample models shown in this document are included in both formats with the Factory Explorer distribution. To follow along as the sample models are developed, you may either use Excel to open the workbook version of the model, or choose View ASCII Models from the FactoryX pull-down menu to open the ASCII version of the model.
Factory Explorer 31
4. User's Guide: Building A Basic Model Factory Explorer reads ASCII models directly -- all other types of models are converted automatically to ASCII format when Factory Explorer is executed. Factory Explorer will look in the file paper.fx2 for the description of products, release patterns, tools, operators, and process steps. We could generate this file by hand, but it is easier to enter the model first as an Excel workbook, then let Factory Explorer convert it to ASCII format automatically. The workbook paper.xls contains this model. Any Factory Explorer model stored as a workbook must contain the following worksheets: Factory: Detail for the factory factory fixed and recurring costs, space types, etc. Products: Detail for each product lot size, release patterns, etc. Lots: Detail for individual lots released into the factory at or after startup. Note that this data is optional - general release patterns can be specified on the Products worksheet. Tools: Detail for each tool group number of tools, interruptions, etc. Operators: Detail for each operator group number of operators, interruptions, etc. Process worksheets: Process steps, one worksheet per process flow (worksheet names selected by user). A portion of the Products worksheet for the paper model is shown in Figure 4-1. Not all columns are required; the columns are color-coded for easy identification (red for required, blue for optional). A complete list of columns is given in Section 4.2. For now, we will consider only the columns used in the paper model. The first column is reserved for DIST and DATA keywords. The DIST keyword identifies the row containing distribution templates; for a complete discussion of templates, see Section 4.2. Each row starting with the DATA keyword contains model information. Keywords in the first row of the worksheet (PRODUCT, PRIORITY, etc.) identify for Factory Explorer what type of information is stored in each column. Descriptions in the second row identify the column as required or optional, and additionally specify the type of data to be placed in the column (Date for a date, Text for user-specified text, Dist for a distribution, Num for a general number, Int for an integral number, and Pct for a percentage 0.0 to 100.0). Factory Explorer will skip rows (other than the first row), unless they contain a DIST or DATA keyword in the first column. Similarly, Factory Explorer will skip columns (other than the first column), unless they contain an entry in the first row. Thus, it is possible to insert extra rows or columns within a Factory Explorer Excel model, and use these rows to store data not contained within the model (raw data used to calculate model inputs, notes or comments, etc.).
32 Factory Explorer
4.1. Introduction
Figure 4-1: Products worksheet, paper model.
Columns used by the paper model include: PRODUCT: Product name. PRIORITY: Default priority for lots. The distribution template for this item is C(?) (constant with unknown value). Combined with the DATA row entry of 1, the template specifies that new lots of this product have a constant priority of 1. SIZE: Number of units in a lot when it is released into the factory. The distribution template for this item is C(?). When combined with the DATA row entry of 100, this means that new lots of this product will have a constant 100 units. PROCESS: Name of worksheet containing process steps for this product. STARTRATE / STARTUM: Arrival rate of paper. In this model, the arrival rate is 1200 units (sheets) per day.
Factory Explorer 33
4. User's Guide: Building A Basic Model The first several columns of the Tools worksheet for this model are shown in Figure 4-2. This model contains two tool groups, Ruling and Punch. The tool group names are listed in the TOOLGROUP column. The number of tools in each tool group is given in the NUMBER column.
Figure 4-2: Tools worksheet, paper model.
This model does not include operators or detailed lot information, so we will not display the Operators or Lots worksheets. Every Excel model must contain an Operators worksheet and a Lots worksheet, however, even if operators or detailed lots are not being modeled. If your model does not include operators, do not put any DATA rows in your Operators worksheet. Similarly, if your model does not include detailed lot data, do not put any DATA rows in your Lots worksheet.
34 Factory Explorer
4.1. Introduction The single process worksheet for this model is displayed in Figure 4-3.
Figure 4-3: Process worksheet, paper model. Columns F and G are hidden for clarity they are not used in this model.
Process worksheet columns used in the paper model include the following: STEP: The processing step name. Step names must be unique within each process worksheet. TOOLGROUP: The name of the tool group where processing for the step occurs. LOAD: The time required to load a lot onto the tool. The distribution template for this item is TP(?,20). When combined with the DATA row entry of 0.25 hours for the Rule-It step, this template indicates that the load time is triangular with an average of 0.25 hours (15 minutes), and a +/- range of 20%. PERUNIT: The time required to process a single unit (a sheet of paper in this model). PERLOT: The time required to process a lot (one hundred sheets of paper in this model). UNLOAD: The time required to unload a lot from the tool.
Factory Explorer 35
4. User's Guide: Building A Basic Model To perform a capacity analysis and simulation run of the model paper.xls, choose Run Factory Explorer from the FactoryX pull-down menu (see Figure 4-4 below).
Figure 4-4: Selecting Run Factory Explorer from the FactoryX menu.
On the dialog that appears, choose from the drop-down list of recently specified models, or click on the Model button to open the Select a Model dialog. By default, the Select a Model dialog first lists Excel workbooks (.xls extension). However, you may also select from a list of ASCII models (.fx2 extension), Testbed models (.vr extension), and ManSim models (.prd extension). To change the type of models listed, choose from the Files of Type drop-down list on the Select a Model dialog. After selecting a model name on the Select a Model dialog, choose OK or Open (the exact button label depends on the version of Excel in use). Factory Explorer automatically detects the model type based on the model name extension.
36 Factory Explorer
4.1. Introduction Once the model name has been entered, select Perform Capacity Analysis and Perform Simulation Analysis from the list box. The run-length unit of measure is displayed alongside the entry, and defaults at system installation to Quarters. Enter a simulation run length (say 6 months). The resulting dialog should look similar to Figure 4-5 below. Click Run to start the run.
Figure 4-5: The Run Factory Explorer dialog. The text box at the bottom of the dialog shows a summary of the current run-time command that will be passed to the Factory Explorer analysis engines.
Factory Explorer 37
4. User's Guide: Building A Basic Model Figure 4-6 below shows the Factory Explorer output console that appears. If Factory Explorer exits without a problem, the console should beep once. If there is an error, it should beep twice. Push OK to close the console.
Figure 4-6: Console output from a six month run of paper model. Every 10% of the run, Factory Explorer prints out an informational message telling how far along the simulation has progressed, and the current world (non-simulated) time.
38 Factory Explorer
4.1. Introduction Factory Explorer's analysis engines write the results of their analysis to a results data file (for this run, the results data file is paper.rdf). To analyze these outputs, choose Analyze Output from the FactoryX menu (see Figure 4-7 below).
Figure 4-7: Selecting Analyze Output from the FactoryX menu.
Factory Explorer 39
4. User's Guide: Building A Basic Model By default, Factory Explorer's Analyze Output dialog (see Figure 4-8 below) uses the results data file from the most recent analysis run. However, you can click on OutBase to select the results data file for a different run. You can place the results that you create (charts or worksheets) in any currently open workbook, in a new workbook, or in a workbook currently stored on disk (select from the drop-down list, or click on Put Results In to open a file selection dialog). To select a single output, simply double-click on the output name in the listbox. To select multiple outputs, hold down the CTRL key while selecting from the list, and then click Create Selected Items. Double-click on the Bottleneck Resource Chart (bars) to create this output.
Figure 4-8: Factory Explorer's Analyze Output dialog. To select a single output, simply double-click on the output name in the listbox.. To select multiple outputs, hold down the CTRL key while selecting from the list, and then click Crate Selected Outputs.
40 Factory Explorer
4.1. Introduction The bottleneck resource chart (bar format version) is shown in Figure 4-9 below. When creating a chart, Factory Explorer inserts a data worksheet and an Excel chart worksheet. At this point you can manipulate the data and the chart as you would any other Excel chart. From this chart, you can immediately see that the ruling machine is the factory bottleneck, although it is not loaded anywhere near its capacity (its capacity loading% is only 66.7%).
Figure 4-9: Bottleneck resource chart (bar format version) for the paper analysis run.
Running Factory Explorer on an Excel model automatically translates the Excel model to ASCII format. The translation creates the ASCII file paper.fx2. This file is shown in Figure 4-10. To view ASCII models on-screen, choose View ASCII Models / Files from the FactoryX pull-down menu. For a description of Factory Explorer's ASCII model syntax, see Chapter 16 of the manual.
{ File created by Factory Explorer Excel to ASCII conversion. Do not edit this file if you intend to reconvert the model at a later time. Instead, make changes to the Excel model. } Factory { Product <Name> (Default Lot priority) (#units) } Product Filler C(1) C(100) UseProcess Filler.Process UnitStartRate 1200
Factory Explorer 41

UnitStartRateUM UnitsPerDay { ToolGroup <Name> <Number of Tools> } ToolGroup Ruling 1 { ToolGroup <Name> <Number of Tools> } ToolGroup Punch 1 Process Filler.Process { Step <Name> <ToolGroup-name> } Step Rule-It Ruling Load TP(0.25,20) PerUnit TP(0.00833333,20) Unload TP(0.25,20) { Step <Name> <ToolGroup-name> } Step Punch-It Punch Load TP(0.25,20) PerLot TP(0.08333333,20) Unload TP(0.05,20)
Figure 4-10: Paper model in ASCII format.
4.2 Storing Models as Excel Workbooks

It is often easier to use a spreadsheet than a text editor when manipulating large models. For that reason, Factory Explorer models are normally stored as Microsoft Excel workbooks, then automatically translated to ASCII format when a model run is performed. This section outlines the form Excel models must take for the translation to work properly. When you build your own Excel models you should probably start with a copy of one of the sample models included with Factory Explorer, or use the New Excel Model option on the FactoryX pull-down menu to create a skeleton model. Starting with an existing model or a skeleton model is much easier than starting from a blank workbook, since these models include the necessary keywords and correct formatting. 4.2.1 Required Worksheets Every Excel model workbook must contain the following worksheets: Factory: This worksheet contains factory-level model information, including factory fixed and recurring costs, space type definitions, tool type definitions, layout area definitions, and travel matrix data. Products: This worksheet contains product-level model information, including product names, default lot priority and size, release rates, etc. In addition, each product entry defines the name of the worksheet containing process information for the product. Lots: This worksheet contains detailed individual lot information, including information about lots that are in the system upon startup (initial WIP), and lots that are to be released into the factory at particular times throughout the analysis.
42 Factory Explorer
4.2. Storing Models as Excel Workbooks Tools: This worksheet contains tool group-level model information, including number of tools in each tool group, setup and batch I.D. definitions, and interruption specifications (failures, preventive maintenance, engineering, etc.). OpSkill: This worksheet contains information to input the skill factor for a given operator group on a given toolgroup. The baseline skill factor for an operator group is 0. A 0 indicates that the operator group works at the mean productivity level for the toolgroup. OpSkill works intuitively based on a higher is better performance metric, and is expressed on a percentage basis. OpSchedule: This worksheet contains information for the work day and shift time of each operator group defined in the model. This allows differing numbers of operators to be working at any point in time and can provide for overlapping shifts where turnover communications are needed. Operators: This worksheet contains information for each operator group defined in the model, including number of operators, and interruption (breaks) specifications. Process worksheets: The names for these worksheets are defined by the user. In the products worksheet, there is a column containing the name of the worksheet holding the process flow data for each product. Multiple products can share a single process flow worksheet. Note that in order to maintain compatibility when migrating from earlier releases of Factory Explorer, Factory Explorer will execute models that do not contain Factory, Lots, OpSkill, and OpSchedule worksheets. 4.2.2 General Formatting Rules When converting an Excel model to ASCII, the conversion program uses keywords stored in the model to identify where different types of data are stored. A keyword is stored in the first cell of a row or column to identify the data stored in the row or column. We will often refer to a row/column headed by the XXXX keyword as the XXXX row/column'. The following formatting rules apply. Keywords can only appear in the first row or column of a worksheet. Keywords are not case-sensitive. Columns headed by keywords may not be reordered. Extra columns may be inserted between columns headed by keywords as long as the first cell in a column is blank, Factory Explorer will skip it when reading the model. Extra columns are useful for holding data or calculations used elsewhere in the model. The DATA keyword identifies a row containing model data. The DIST keyword identifies a row containing distribution templates. All worksheets except the Factory and Lots sheets must include a DIST row.
Factory Explorer 43
4. User's Guide: Building A Basic Model Certain groups of columns contain data that may be entered multiple times for a single product, tool group, operator group, or process step. In general, these column groups will be headed with the text Repeat to add... or Repeat for more..., and the column headings will be enclosed with a black border. For example, in the tools worksheet, there may be multiple types of clock-time based interruptions for a single tool group (failures, engineering time, preventive maintenance, etc.) To enter the first type of interruption, simply fill in the blanks on the DATA row for the tool group. To enter the second type of interruption, the easiest way is to simply insert an additional DATA row below the DATA row for the tool group. In this second DATA row, do not fill in the tool group name again -- that would create a duplicate tool group entry. Simply fill in the information for the second interruption type. Repeat this procedure to add more interruptions. Factory Explorer allows you to model information that changes over time for products, tool groups, operator groups, and process steps. To model these changes, you simply enter multiple definitions of an object (a product, say), and specify the date upon which the definition becomes effective. When entering multiple, ramped definitions for an object, all definitions must be listed sequentially in the input file. Every definition after the first must specify an effective date. Otherwise, Factory Explorer will flag the situation as an input model validation error. The first definition may or may not specify an effective date. If no effective date is specified for the first definition of an object, the definition is assumed to be effective from the start of the analysis run. Data from earlier definitions does not roll forward to later definitions if left unspecified. For example, suppose the first definition of product A (effective 2000-01-01) specifies a raw unit cost of $35, and a later definition (effective 2000-04-01) does not specify a raw unit cost. During the analysis, the raw unit cost will drop from $35 to zero on 2000-04-01. 4.2.3 Keyword/Column Definitions Keywords are used in Excel models to identify the contents of rows and columns. The following keywords have the same meaning across all worksheets: DATA: Identifies a row containing model data. DIST: Identifies a row containing distribution templates. In the following column descriptions, certain columns are identified as containing random variables. If a cell in such a column contains data, it must either include a complete distribution (e.g. e(5) for exponential with mean 5), or the DIST row for this column must contain a distribution template (e.g. the data cell contains the constant 5, and the DIST cell contains the template e(?)). See Section 4.2.4 of the manual for more information on distribution templates; see Section 4.5 of the manual for more information on distributions. Keywords/Columns in the Factory worksheet (all columns on the Factory worksheet are optional): FCNAME / FCAMOUNT / DEPLIFE: Specifies information for a factory fixed cost (e.g. buildings, land, etc.) Every factory fixed cost must specify at a minimum the
44 Factory Explorer
4.2. Storing Models as Excel Workbooks name (can be any text), and an amount. DEPLIFE specifies the fixed cost's depreciation life. Depreciation life is specified in years. Depreciation life is used when calculating gross margin depreciation amounts and product cost per good unit out. If depreciation life is zero or not specified, the fixed cost will not be included in gross margin calculations or product cost per good unit out. If the depreciation life is exceeded in the middle of a period, a full periods depreciation will be calculated. USELIFE specifies the useful life. Starting with Factory Explorer version 2.10 USELIFE is no longer used in product cost per good unit out calculations. If USELIFE is entered a warning message is generated and USELIFE is ignored. For product cost calculations, factory fixed costs are first allocated to tool groups on the basis of space usage, and then re-allocated to products on the basis of time-used. If a model does not include space requirements, factory fixed costs are not allocated to any product. If a tool has space requirements but is not used by any product, it will still be allocated a portion of the factory's fixed costs. These costs, however, will not be allocated to any product. To avoid this situation, remove space requirements for any unused tools, or remove the tools from the model. RCNAME / RCAMOUNT: Specifies information for a factory recurring cost (e.g. non-production salaries, building maintenance, taxes, etc.) Every factory recurring cost must specify both a name (can be any text) and an amount. Recurring costs are used in gross margin calculations and product cost calculations. For product cost calculations, factory recurring costs are first allocated to tool groups on the basis of space usage, and then re-allocated to products on the basis of time-used. If a model does not include space requirements, factory recurring costs are not allocated to any product. If a tool has space requirements but is not used by any product, it will still be allocated a portion of the factory's recurring costs. These costs, however, will not be allocated to any product. To avoid this situation, remove space requirements for any unused tools, or remove unused tools from the model. SCHED / NONSCHED / REPEATS: Specifies information for a factory schedule. Each combination of SCHED, NONSCHED, and REPEATS specifies one scheduling pattern. SCHED is the number of hours the factory is scheduled to be operating, NONSCHED is the number of hours the factory is scheduled to be shutdown, and REPEATS is the number of times to repeat this pattern before moving on to the next. If multiple scheduling patterns are specified, Factory Explorer moves through them in order. When the last scheduling pattern is exhausted, Factory Explorer returns to the first. Note: during factory nonscheduled time, release patterns are shut off, (e.g. they are delayed for the length of the shutdown). Releases generated from the Lots worksheet are not delayed, however. Clock-time interrupts are also not delayed. Events that are not delayed, and that occur during a shutdown, are queued and occur when the factory begins the next scheduled operation period. EXPITEM / EXPUOM / EXPCOST: Specifies information for factory expense items. Each combination of EXPITEM, EXPUOM, and EXPCOST specifies on expense Copyright WWK 1995-2009 Factory Explorer 45
4. User's Guide: Building A Basic Model item. EXPITEM is the expense item name. EXPUOM is the unit of measure. EXPCOST is the cost per unit of measure. PRODTYPE: Defines a factory product type (e.g. Memory, ASIC, etc.). At the product level, a model can identify each product with a particular product type. All product types must be defined at the factory level. UNITTYPE: Defines a factory unit type (e.g. Wafers, Die, etc.). At the product level, a model can identify each product with a particular unit type. At the tool and operator group levels, a model can identify each tool or operator group as processing a particular unit type. Unit types are used in Factory Explorers max going rate calculations, and are especially important when a single factory model includes multiple unit types (e.g. both wafer-level and die-level products). All unit types must be defined at the factory level. SPACETYPE: Defines a factory space type (e.g. class 10, class 1000, support, etc.). At the tool group level, a model can include multiple space requirements for different space types. All space types must be defined at the factory level. TOOLTYPE: Defines a factory tool type (e.g. furnace, photo, etch, etc.). At the tool group level, a model can identify each tool group with a particular tool type. All tool types must be defined at the factory level. STEPTYPE Defines a factory step type (e.g. front-end, back-end, assembly, etc.). At the process step level, a model can identify each process step with a particular step type. All step types must be defined at the factory level. LAREA: Defines a factory layout area (e.g. a bay, building, etc.) At the tool group level, a model can identify each tool group as belonging within a particular layout area. All layout areas must be defined at the factory level. FROM / TO / DISTANCE / CELL: Specifies information for a travel matrix record. Each travel matrix record must at a minimum contain an origin layout area name (FROM) and a destination layout area name (TO). DISTANCE specifies the distance between the two layout areas, and is used in calculations for travel distance intensity calculations. CELL identifies a particular route (or cell) within the travel matrix with a name, and is only used when Factory Explorer communicates with third-party software. Keywords/Columns in the Products worksheet (only the columns listed as required must be specified for every DATA row): DATE: The date upon which the definition specified for this product becomes effective. If not specified, the definition is effective from the start of the analysis run. On the effective date, this product definition supersedes all previous definitions. PRODUCT (required): Product name. 46 Factory Explorer Copyright WWK 1995-2009
4.2. Storing Models as Excel Workbooks PRIORITY (required): Default priority for lots (random variable). SIZE (required): Default number of units when lots of this product are released (random variable). Since the number of units must be an integer, any non-integral lot size is rounded up to the next integer. PROCESS (required): Name of worksheet that contains process steps for product. PRODTYPE: Specifies the product type. Product types are used for displaying product-related outputs. Product types must be defined on the Factory worksheet. UNITTYPE: Specifies the unit type. Unit types are used for max going rate (daily going rate) calculations. Unit types must be defined on the Factory worksheet. STARTRATE / STARTUM: Desired unit start rate for the product. Start rates can only be specified for release-products, e.g. products that are released into the factory. If a start rate is specified for a product with no release patterns, one release pattern will be created. If a start rate is specified for a product with one or more release patterns, the time between releases of each release pattern will be manipulated to achieve the specified overall start rate. Setting the start rate for a product to zero is allowed, and has the effect of eliminating all releases for the product. STARTUM specifies the unit of measure. Valid units of measure are UnitsPerHour, UnitsPerDay, UnitsPerWeek, UnitsPerMonth, UnitsPerQuarter, or UnitsPerYear. If a unit of measure is not specified, it defaults to UnitsPerHour. TPUTRATE / TPUTUM: Desired unit throughput rate for the product. Throughput rates can only be specified for end-products, e.g. products that are not transformed or assembled into other products. If a throughput rate is specified for an endproduct, Factory Explorer manipulates release rates for all release-products that feed the end-product, so as to obtain the desired throughput rate. If a releaseproduct that feeds the end-product does not specify any release patterns, one will be created. Since this release-rate manipulation process requires knowledge of line yields (a result of capacity analysis), simulation cannot be performed on a model containing throughput rates unless capacity analysis is also performed. Also, models containing throughput rates cannot have products with zero line yields. Setting the throughput rate for a product to zero is allowed, and has the effect of eliminating all throughput for the product. To ensure that a feasible set of release-rates can be calculated, end-products that specify a release rate (or products that feed this end-product) cannot be the result of transform or assembly where the percent reserved is less than 100%. TPUTUM specifies the unit of measure. Valid units of measure are UnitsPerHour, UnitsPerDay, UnitsPerWeek, UnitsPerMonth, UnitsPerQuarter, or UnitsPerYear. If a unit of measure is not specified, it defaults to UnitsPerHour. RELEASE / BETWEEN: Specifies a release pattern for the product. RELEASE gives the number of lots in each release (random variable), BETWEEN gives the time between lot releases (random variable). If only one release pattern is defined, it is repeated over and over. Multiple release patterns may be specified, however, and
Factory Explorer 47
4. User's Guide: Building A Basic Model Factory Explorer will cycle through them in order. Since the number of lots in a release must be an integer, any non-integral number of lots is rounded up to the next integer. Use of run-time options that manipulate release rates (e.g. ReleasePct or ReleaseRate) require that RELEASE be specified using only distributions that have the random variable's mean as one of the parameters. TIMETOFIRST: Time to first lot release (random variable). If not specified, first lot release occurs at simulated time zero. In models with ramped product data, TIMETOFIRST is only relevant for the first release during the simulation run. That is, Factory Explorer will use the TIMETOFIRST distribution, if any, specified for the product record that is active at the beginning of the simulation replication. Changes in the TIMETOFIRST distribution that are effective later in the simulation run will have no effect on the simulation. DUEDATE: Due-date offset for newly released lots (random variable). If specified, each new lot's due date is set to be the release time for the lot plus a random observation drawn from this distribution. LTF: Lead time factor for this product. Lead time factors are used in certain dispatch rule calculations (e.g. PRCRITICAL, PRWORKAPD). See Section 4.6 for more information on dispatch rules. CONWIP: Work-in-process target level for this product. The unit of measure is lots. Rework children are not counted for the purposes of CONWIP. If CONWIP is specified for a product, the normal release patterns are used until the number of non-rework lots in the system matches the target level. At that point, the normal release process is turned off, and new lots are released into the factory whenever a non-rework lot is completed or scrapped. COST: Specifies the per-unit raw material cost for released units (the cost of a unit when it is released into the factory). COST is used in Factory Explorer's cost analysis. COST cannot be specified for products that are the result of transform or assembly of other products. Factory Explorer automatically calculates the release cost for transformed (assembled) products from the cost per good unit out of the sub-transform (sub-assembly) products. Per-unit supplies and consumable costs, process overhead costs, and direct material costs, accumulated during production, can still be specified for transformed or assembled products using the COSTPERUNIT, OVHDPERUNIT and MATERPERUNIT process step attribute, respectively. REVENUE: Specifies the revenue associated with a single completed unit of this product. REVENUE is used in Factory Explorer's cost analysis. REVENUE cannot be specified for products that are assembled or transformed into other products. ADJPCTS: Flag to indicate that Factory Explorer should dynamically adjust transform or assembly percentages for this product to match the demand for
48 Factory Explorer
4.2. Storing Models as Excel Workbooks downstream products. ADJPCTS can only be marked for products that specify transform or assembly. ADJPCTS can only be marked for products that are demand-driven, i.e. products for which downstream products specify throughput rates. If specified, simulation can only be performed if capacity analysis is also enabled, as the percentages are adjusted by Factory Explorer's capacity analysis engine. When ADJPCTS is specified for a product, Factory Explorer examines downstream products (those that are transformed or assembled from this product) for unit throughput rates. Using these unit throughput rates, it back-calculates to determine the appropriate set of transform or assembly percentages for this product, so that throughput for this product exactly matches the demand specified by downstream products. If WriteExcel is enabled, the adjusted percentages will be written to the resulting Excel model. See Section 9.7 of the manual for a discussion of adjustable transform and assembly percentages. TRANPCT / TRANINTO / TRANMULT: Specifies that this product is transformed into another product at completion. TRANPCT gives the percentage of finished units that are transformed. TRANINTO gives the product name of the transformed units. TRANMULT gives the number of units of the TRANINTO product that are created from each unit of this product. Sum of TRANPCT for all release records for a product must be 100. See Sections 9.4 and 9.5 of the manual for sample models that include product transform. ASSMPCT / ASSMINTO / ASSMREQD: Specifies that this product is assembled into another product at completion. ASSMPCT gives the percent of finished units that are reserved for the ASSMINTO product. ASSMINTO gives the name of the assembled product. ASSMREQD gives the number of units of this product that are required in the assembly of a single unit of the ASSMINTO product. Sum of ASSMPCT for all assembly records for a product must be 100. See Section 9.6 of the user manual for a sample model that includes assembly. FLOWFACTOR: The FLOWFACTOR is specifically use with the ODD (Operation Due Date) dispatch rule and is defined as the target cycle time divided by the raw processing time (RPT). For instance, a FF of 2 says that a lot spends half of its cycle time in processing state and the other half in non-processing states like waiting. Thus, the due date of a lot is the time when it enters the fab plus FF * RPT. Keywords/Columns in the Lots worksheet (only the columns listed as required must be specified for every DATA row): LOT (required): Lot I.D. (number or name). PRODUCT (required): The product name for the lot. PROCESS (required): The process flow followed by the lot. The process flow must be specified in addition to the product name, as the process used by a product may
Factory Explorer 49
4. User's Guide: Building A Basic Model change throughout the analysis run. The process flow of an individual lot, however, never changes once it is released into the factory. STEP (required): For lots not yet released into the factory, the process step where they will be started. For initial WIP, the process step where the lot is located. Note that for initial WIP, the lot will always start in queue, waiting for processing. There is currently no way to specify that initial WIP is in process at a tool. UNITS (required): The current number of units in the lot. For rework parent lots, this quantity should not include any units currently contained within rework children lots. For split-lot parent lots, this quantity should not include any units currently contained within split-lot children lots. The rework and split-lot children are specified separately. PRIORITY: The current priority of the lot. START: The start date for the lot. When the simulation is started, Factory Explorer will initialize the system with lots that specify a) no start date, or b) a start date prior to the beginning of the analysis run. Lots that specify a start date falling after the start of the analysis run will be released into the simulation when the simulated start date is reached. Note that start dates can specify hours and minutes. DUE: The due date for the lot. Note that due dates can specify hours and minutes. RPARENT: Mark cell with a non-blank entry to indicate that lot is a rework parent. RCHILD: Mark cell with a non-blank entry to indicate that lot is a rework child. RPLOT: If lot is a rework child, the lot I.D. for the rework parent. RPLOT is required for all rework child lots. SPARENT: Mark cell with a non-blank entry to indicate that lot is a split-lot parent. STOTAL: If lot is a split-lot parent, the total number of split-lot children lots. STOTAL is required for all split-lot parent lots. SREMAIN: If lot is a split-lot parent, the remaining number of outstanding (not yet recombined) split-lot children lots. SREMAIN is required for all split-lot parent lots. SCHILD: Mark cell with a non-blank entry to indicate that lot is a split-lot child. SPLOT: If lot is a split-lot child, the lot I.D. for the split-lot parent. SPLOT is required for all split-lot child lots.
50 Factory Explorer
4.2. Storing Models as Excel Workbooks Keywords/Columns in the Tools worksheet (only the columns listed as required must be specified for every DATA row): DATE: The date upon which the definition specified for this tool group becomes effective. If not specified, the definition is effective from the start of the analysis run. On the effective date, this tool group definition supersedes all previous definitions. TOOLGROUP (required): ToolGroup name. NUMBER (required): Number of tools at this tool group. Specify inf for infinite (unlimited) tools. UNITTYPE: Specifies the unit type processed by the tool group. Unit types are used for max going rate (daily going rate) calculations. Unit types must be defined on the Factory worksheet. DISPATCHRULE: Dispatch rule for this tool group: FIFO, LSLACK, etc. If no dispatch rule is specified, the default is FIFO. See Section 4.6 for a list of dispatch rules. AVOIDSETUPS: Flag to indicate that a setup-avoidance strategy is used at this tool group. Put a non-blank entry in this column to enable setup-avoidance. If enabled, this strategy modifies the dispatch rule in force at the tool to include setup minimization as a primary goal behind priorities. Clear the entry in this column to disable setup-avoidance. IBUFFER: Specifies the size (in terms of # of Lots) of the input buffer for this tool group. A lot may not begin traveling to this tool group unless there is available input buffer space for the tool group. Lots occupy input buffer space until they can begin load. If WIP storage limitations do not apply in model, this value need not be specified. For more information on tool buffering, see section 9.20. OBUFFER: Specifies the size (in terms of # of Lots) of the output buffer for this tool group. A lot may not begin processing at a tool unless there is available output buffer space for the tool group. Lots occupy output buffer space until they can begin travel. If WIP storage limitations do not apply in model, this value need not be specified. For more information on tool buffering, see section 9.20. BSLOTS: Flag to indicate that minimum and maximum batch sizes are specified in terms of lots rather than units for this tool group. By default, Factory Explorer assumes that batch sizes are specified in terms of units. Put a non-blank entry in this column to enable lot batch sizes. Note that when a tool is changed from having batch sizes in terms of units to having batch sizes in terms of lots, the capacity loading on the tool may change even if the unit batch sizes were multiples of the nominal lot size. This change is due to the presence of rework and scrap in process flows.
Factory Explorer 51
4. User's Guide: Building A Basic Model BATCHID / MINBATCH / MAXBATCH: Specifies a batch I.D. for the tool group. BATCHID gives the I.D. name, MINBATCH and MAXBATCH specify the minimum and maximum batch sizes for the I.D. (in units). At the process step level, each step using this tool group must specify a valid batch I.D. Lots at steps with different batch I.D.'s may not be processed in the same batch at a tool. Multiple batch I.D.'s may be specified for a tool group. At least one batch I.D. must be specified for any batch tool group. Batch I.D. names may contain %Product, %Process, %Operation, and %Step wildcards. See Section 9.2 of the manual for more information on batch I.D. wildcards. If MINBATCH and MAXBATCH are specified in units, there are two restrictions on MINBATCH. These restrictions ensure that the simulation can always form a valid batch if there is a proper amount of work in queue. If the maximum lot size (across all products) is less than or equal to MAXBATCH, and this maximum lot size is strictly greater than 1, then (MAXBATCH MINBATCH) must be strictly less than maximum lot size minus 1. If the maximum lot size (across all products) is strictly greater than MAXBATCH, then MINBATCH must equal 1. SETUPPCT: Percent of setup time operator is required (default = 100). If operators are not used in model, this value need not be specified. LOAD: Percent of load time operator is required (default = 100). If operators are not used in model, this value need not be specified. PROC: Percent of processing time operator is required (default = 100). If operators are not used in model, this value need not be specified. UNLOAD: Percent of unload time operator is required (default = 100). If operators are not used in model, this value need not be specified. INTNAME / INTTYPE / TTF / TTR / FIRSTINT / STAGGERFIRST / E10STATE /NONSCHED /REPAIROP / REPAIRPCT: Specifies an interruption. INTNAME specifies the user-defined name for the interruption (e.g. Failure, Maintenance, Engineering, etc.). INTTYPE specifies the base for the interruption, and must be one of Between, Clock, Busy Units, or GroupClock. TTF gives the time-to or units-to interruption (random variable). For the Between INTTYPE TTF gives the time between interruptions (random variable). TTR gives the time off-line for the interruption (random variable). FIRSTINT specifies the time or units to the first interruption (random variable, optional). Marking STAGGERFIRST indicates that the first interruption at tool groups with multiple tools should be staggered among the tools. This option is most useful when modeling preventive maintenance as an interruption with constant time-to-interruption and time-offline. Marking STAGGERFIRST causes the first interruption to be staggered so that the tools are taken down in sequence, rather than all at once. REPAIROP specifies the operator group needed for repair (optional). If REPAIROP is specified, REPAIRPCT specifies the percent of repair time the operator is needed (default is 100%). E10STATE is the SEMI E-10 state for the offline type
52 Factory Explorer
4.2. Storing Models as Excel Workbooks (optional). Recognized E-10 states are NONSCHED, UNSCHEDDOWN, SCHEDDOWN, and ENGINEERING. SETUP / SETUPID / SETUPTIME / FROMID / MINTOOLS / MAXTOOLS / MINQUEUE / MINDELAY / MAXQUEUE / MAXDELAY: Specifies a setup group, I.D., and time for this tool group. SETUP gives the setup group name. SETUPID gives the I.D. name within the group. SETUPTIME gives the time required for the setup (random variable). If the setup time is sequence-dependent, FROMID specifies the setup I.D. from which this time is valid. If no FROMID is listed, the indicated SETUPTIME is taken to be the default time when switching to the I.D. Other SETUP / SETUPID / SETUPTIME / FROMID entries can give setup times when switching to SETUPID from specific I.D.'s. Note that there may be cases where no default time is specified for a setup group and I.D. If a setup occurs that does not have any time specified in the input file, and there is no default time specified, Factory Explorer will assume that the setup time is zero for this setup. Use the FlagNoSetup option to generate a warning every time this situation occurs. If AVOIDSETUPS is enabled for the tool group, MINTOOLS and MAXTOOLS may be used to specify the minimum and maximum number of tools to be setup for each I.D. Setup-avoidance is still the goal, but only lots that can be setup / run without violating a minimum or maximum tool limit are eligible for processing. In general, specifying MINTOOLS is a way of dedicating a minimum number of tools to a particular setup I.D., while specifying MAXTOOLS is a way to limit the number of tools that can be simultaneously setup for a particular setup I.D. Depending on the situation, specifying MINTOOLS or MAXTOOLS can result in either an increase or decrease in Setup%. One or both of MINTOOLS and MAXTOOLS may be specified for each setup I.D. If AVOIDSETUPS is enabled for the tool group, MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY may be used to specify trigger points for queue length and queue delay. When these trigger points are reached, the setupavoidance algorithm is modified slightly. Setup-avoidance is still the goal. Lots that have been waiting in queue less than MINDELAY hours, or lots that are waiting for a setup I.D. that has less than MINQUEUE units in queue, will not be eligible for processing if a non-zero setup time is required. Lots that have been waiting in queue for more than MAXDELAY hours, or lots that are waiting for a setup I.D. that has more than MAXQUEUE units in queue, are eligible for immediate processing, even if it creates an extra setup, and even if these lots do not satisfy MINQUEUE / MINDELAY requests. MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY are useful because sometimes setup-avoidance can lead to very long queues of particular setup I.D.'s. In general, specifying MINQUEUE, MINDELAY, MAXQUEUE or MAXDELAY will result in an increased Setup%, but may limit the maximum queue delay experienced by lots with particular setup I.D.'s. One or all of MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY may be specified for each setup I.D.
Factory Explorer 53
4. User's Guide: Building A Basic Model Most MINTOOLS, MAXTOOLS, MAXQUEUE, and MAXDELAY combinations are valid for each setup I.D. During model validation, Factory Explorer checks that MINTOOLS < MAXTOOLS, MINQUEUE < MAXQUEUE and MINDELAY < MAXDELAY. MAXDELAY must be specified if MINQUEUE is specified. None of these options, however, may be specified unless AVOIDSETUPS is also enabled for the tool group. Setup I.D. names may contain %Product, %Process, %Operation, and %Step wildcards. See Section 5.8 of the manual for more information on modeling setups. TLSTATE / TMSTATE: Specifies a tool state. TLSTATE specifies the user-defined name for the tool state. TMSTATE gives the time in hours the tool will spend in the given state before transitioning to another state (random variable). INSTATE: Specifies the initial tool state for tools in the tool group. FRSTATE / TOSTATE / TRANPCT: Specifies the transition percentage between tool states. FRSTATE specifies the tool state from which the tool is transitioning. TOSTATE specifies the tool state to which the tool may transition. TRANPCT specifies the percent to time the tool will transition to TOSTATE upon leaving FRSTATE. Note that the TRANPCTs for a given FRSTATE must sum to 100%. IMPACTST / IMPACTOP / IMPACT: Specifies the processing impact for a tool operating in a particular tool state. IMPACTST specifies the tool state for which there is a processing impact. IMPACTOP specifies the Operation ID (from OPERATION on Process worksheet) for which there is a processing impact. IMPACT specifies the process rate multiplier that applies when a tool is in IMPACTST and is performing IMPACTOP. This multiplier will be applied to the standard processing time to account for the tool state (e.g. IMPACT of 1.5 indicates that processing takes 50% longer, an IMPACT of 0.667 indicates that processing is 33% shorter). Note that an IMPACT of 0.0 indicates that the tool may not perform the specified IMPACTOP will in the given IMPACTST. If there are no processing impacts for a given tool state/operation ID combination, no entry is required (IMPACT is 1 by default). TOOLTYPE: Specifies the tool type. Tool types are used when aggregating fixed and recurring costs for gross margin calculations, and for product cost analysis. Tool types must be defined on the Factory worksheet. LAREA: Specifies the layout area where a tool is located. Layout areas are used for aggregating space requirements, and for calculating travel intensities. Layout areas must be defined on the Factory worksheet. SPACETYPE / SPACEAMT: Specifies a per-tool space requirement, both the type of the space, and the amount required. In tool groups with infinite servers, space requirements are counted once for the tool group. A tool group may have an
54 Factory Explorer
4.2. Storing Models as Excel Workbooks unlimited number of space requirements. Space types must be defined on the Factory worksheet. FIXEDCOST: Specifies fixed cost (purchase cost, installation cost, etc.) per tool. Tool fixed cost is used in Factory Explorer's cost analysis. DEPLIFE: Specifies the depreciation life, in years, for a tool in this tool group. Depreciation life is used in Factory Explorer's cost analysis. Depreciation life does not have to be an integer, e.g. it could be specified as 4.5. When computing depreciation expenses, Factory Explorer uses straight-line depreciation with zero salvage value. USELIFE: Specifies the useful life, in years, for a tool in this tool group. Starting with Factory Explorer version 2.10. Useful life is no longer used in Factory Explorer's cost analysis calculations. If USELIFE is entered a warning message is generated and USELIFE is ignored. RECCOST: Specifics the annual recurring cost for a tool in this tool group. Recurring cost is used in Factory Explorer's cost analysis. CBUFFER Specifies the capacity buffer used by Factory Explorer when calculating a suggested number of tools for this tool group. To calculate a suggested number of tools, Factory Explorer first subtracts CBUFFER from the suggested capacity loading as specified with SuggLoading (the default is 85% if SuggLoading is not enabled), to arrive at a maximum suggested capacity loading. Next, Factory Explorer finds the minimum tool quantity that results in a capacity loading less than or equal to the maximum suggested loading. This minimum tool quantity is reported as Factory Explorer's suggested number of tools. CBUFFER is useful because it allows you to vary the maximum suggested capacity loading by tool group. For example, you may wish to set CBUFFER to a small positive amount, say 15 or 25, for inspection equipment. This will cause Factory Explorer to suggest a larger number of inspection tools, which is reasonable since these tools are usually relatively inexpensive, and it does not make sense to load them very heavily. Alternatively, you can also set CBUFFER to a negative amount, say 10, if you want it to use a higher maximum suggested capacity loading for some very expensive pieces of equipment. Valid entries for CBUFFER are between -100 and the suggested capacity loading (as specified with SuggLoading, or 85% by default). Entries between -100 and -(100 SuggLoading) will lead to capacity loading values greater than 100%, however, and could to cause unstable simulation runs. For example, if SuggLoading is 85, setting CBUFFER equal to -100 will lead to a loading of (SuggLoading CBUFFER) = (85 - (-100)) = 185%. To keep the loading below 100% in this case, CBUFFER should be no less than -(100 - SuggLoading) = -15. CHECKPRI Specifies the priority of a check-request event for this tool group, in the event of simultaneous simulation events. In Factory Explorer's simulation engine, whenever a resource (tool or operator) is freed, or a lot enters a queue, a checkCopyright WWK 1995-2009 Factory Explorer 55
4. User's Guide: Building A Basic Model request event is scheduled. Upon execution, the check-request event checks to see if the resource is able, or is required, to start work somewhere in the factory. If multiple resources become free at exactly the same time, it is sometimes useful to control the order in which the check-request events for these resources are scheduled. By default, all resources have a check-request priority of zero, and the order cannot be determined in advance. Specifying CHECKPRI controls the priority, and hence the order, in which check-request events are executed. CHECKPRI must be between zero and 999. Zero is the best priority, and 999 is the worst priority. See Section 9.17 of the manual for a sample model that uses CHECKPRI. LEADTIME: Specifies tool purchase lead time, for a tool in this tool group. LEADTIME is used in Factory Explorer's capacity analysis. LEADTIMEUM: Specifies tool purchase lead time unit of measure, for a tool with LEADTIME in this tool group. By default is months. USESEXPITEM / CONSNON / CONSUNSCH / CONSSCHD / CONSENGR / CONSSTBY / CONSPROD / CONSUNIT: Specifies expense item consumption for each tool in this toolgroup. Each combination of USESEXPITEM, CONSNON, CONSUNSCH, CONSSCHD, CONSENGR, CONSSTBY, CONSPROD, CONSUNIT specifies one consumption pattern. USESEXPITEM specifies the expense item name. This name has to be defined on the Factory worksheet. CONSNON is the consumption per hour of non-scheduled time. CONSUNSCH is the consumption per hour of unscheduled downtime. CONSSCHD is the consumption per hour of scheduled downtime. CONSENGR is consumption per hour of engineering time. CONSSTBY is the consumption per hour of standby time. CONSPROD is the consumption per hour of productive time. CONSUNIT is the consumption per unit processed. Note that CONSUNIT consumption can be deleted via an expense item exclusion specified at the process step level. Keywords/Columns in the OpSkill worksheet (only the columns listed as required must be specified for every DATA row): DATE: The date upon which the definition specified for this operator skill becomes effective. If not specified, the definition is effective from the start of the analysis run. On the effective date, this operator skill definition supersedes all previous definitions. OPGROUP (required): Operator group name. TOOLGROUP (required): ToolGroup name. OPSKILLFACTOR (required): The OPSKILLFACTOR field allows for the input of a skill factor for a given operator group on a given toolgroup. The baseline skill factor for an operator group is 0. A 0 indicates that the operator group works at
56 Factory Explorer
4.2. Storing Models as Excel Workbooks the mean productivity level for the toolgroup. The OPSKILLFACTOR works intuitively based on a higher is better performance metric and is expressed on a percentage basis. For example, an OPSKILLFACTOR greater (less) than 0 indicates the operator group can perform tasks (e.g., load and unload) on the corresponding toolgroup at a rate higher (lower) than the average. Keywords/Columns in the OpSchedule worksheet (only the columns listed as required must be specified for every DATA row): SCHEDNAME (required): Schedule name. SCHEDPERIOD: This is optional text to more fully describe the schedule. SCHEDDAYSTART (required): The day of the week that starts the schedule entry. It is recommended that if a work schedule contains a Sunday, that Sunday be listed as the first day of the schedule. FX assumes that Sunday is the first day of the week and if it is not listed as such in the schedule, then the listed Sunday is for the following week. This can create situations were resources are not available on the first Sunday. SCHEDCLOCKSTART (required): The time of day that starts the schedule entry. Data should be entered in a 24 hour clock format (8:00 for 8am, 13:00 for 1pm). SCHEDDAYEND (required): The day of the week that ends the schedule entry. SCHEDCLOCKEND (required): The time of day that ends the schedule entry. Keywords/Columns in the Operators worksheet (only the columns listed as required must be specified for every DATA row): DATE: The date upon which the definition specified for this operator group becomes effective. If not specified, the definition is effective from the start of the analysis run. On the effective date, this operator group definition supersedes all previous definitions. OPGROUP (required): Operator group name. NUMBER (required): Number of operators in the group. Specify inf for infinite (unlimited) operators. Note that NUMBER represents snapshot staffing, or the number of operators on duty at any given time. For a factory that runs multiple shifts, NUMBER should generally not be the total number of operators that work in the factory. For example, if a factory runs twenty-four hours a day, five days a week, with no operation on weekends, the situation would typically be covered with three eight-hour shifts per day. If, on any given shift, ten operators are present in the factory, then ten should be entered in the NUMBER column. However, the total number of operators hired to work in the factory would probably be three times ten, or thirty.
Factory Explorer 57
4. User's Guide: Building A Basic Model SCHEDNAME: Operator work schedule name as specified on the OpSchedule worksheet. UNITTYPE: Specifies the unit type processed by the operator group. Unit types are used for max going rate (daily going rate) calculations. Unit types must be defined on the Factory worksheet. DISPATCHRULE: Dispatch rule for this operator group: FIFO, LSLACK, etc. If no dispatch rule is specified, the default is FIFO. See Section 4.6 for a list of dispatch rules. See Section 23.7 for details on operator dispatching. Operator dispatch rules only apply to process related tasks, e.g. load, process, and unload, but not repair requests. The reason for this is that most dispatch rules do not make sense when applied to repair requests. Therefore, repair requests are always processed by operators in FIFO order. INTNAME / INTTYPE / TTF / TTR / FIRSTINT / STAGGERFIRST / E10STATE: See documentation for Tools. Setting the E10STATE to NONSCHED for an interruption causes Factory Explorers cost analysis engine to not pay operator wages or accumulate operator overhead for the duration of the offline time. WAGERATE: Specifies the per-operator hourly wage rate (fully burdened) for this operator group. Operator wage rate is used in Factory Explorer's cost analysis. OVERHEAD: Specifies the per-operator hourly overhead rate (fully burdened) for this operator group. Operator overhead rate is used in Factory Explorers cost analysis. CBUFFER: Specifies the capacity buffer used by Factory Explorer when calculating a suggested number of operators for this operator group. See documentation for Tools. CHECKPRI: Specifies the priority of a check-request event for this tool group, in the event of simultaneous simulation events. See documentation for Tools. OTHORIZON: The OTHORIZON field specifies the number of days over which overtime accrual is assessed. This is meant to model a rolling set of time periods, not a set of overlapping periods. In other words, day one through 14 is the first period wherein overtime is assessed, and then day 15-28 is the subsequent period, rather than days one through 14, days two through 15, and so on. OTVALUE: The OTVALUE field specifies how many total hours an operator can work during the OTHORIZON before overtime is accrued. Finally, the OTFACTOR field specifies the wage rate multiple that is applied to the operator groups base hourly rate for overtime wages. For example, an OTFACTOR of 1.5 amounts to time and a half.
58 Factory Explorer
4.2. Storing Models as Excel Workbooks OTFACTOR: The OTFACTOR field specifies the wage rate multiple that is applied to the operator groups base hourly rate for overtime wages. For example, an OTFACTOR of 1.5 amounts to time and a half. Keywords/Columns in Process worksheets (only the columns listed as required must be specified for every DATA row): DATE: The date upon which the definition specified for this process step becomes effective. If not specified, the definition is effective from the start of the analysis run. On the effective date, this process step definition supersedes all previous definitions. STEP (required): Name of processing step. The process step name must be unique within a process flow unless alternative steps are included. Alternative steps are two or more steps that represent different ways of performing the same step. For example, it may be possible to perform a particular step on a new, fast machine, but as an alternative an older, slower, machine can still be used. For alternative steps, use the same process step name for each step. Alternative steps must be contiguous in the process flow, i.e. two or more steps in the process flow that are contiguous, and that have the same name, will be treated as alternative steps. Two or more steps in the process flow that are not contiguous, but that have the same name, will be flagged as a model validation error. For more information on alternative steps, see Section 9.14. Note also that multiple process steps with the same name may be defined for different effective dates. TOOLGROUP (required): Tool group used by processing step. OPGROUP: Operator group, if any, required for processing. Insert rows for additional operator groups that can be used at this process step. This is particularly useful when using the OpSchedule worksheet where differing operator groups are available at differing times of the day or days of the week or the OpSkill worksheet where there is cross-training between operator groups. FX will choose the available operator group with the highest skill set. ACTIVE Specifies the list of active products for this process step. If the ACTIVE column is empty, this process step applies to all products that use this process flow (as long as the INACTIVE column is also empty). If one or more ACTIVE products are specified, this process step applies only to these products for all other products it is as if this step didn't exist. Use the ACTIVE and INACTIVE columns when you wish to save data maintenance by combining process flows that are nearly the same, but which differ by a few steps for one or more products. INACTIVE Specifies the list of inactive products for this process step. If the INACTIVE column is empty, this process step applies to all products that use this process flow (as long as the ACTIVE column is also empty). If one or more INACTIVE products are specified, this process step applies to all but these products for these products it is as if this step didn't exist. Use the ACTIVE and
Factory Explorer 59
4. User's Guide: Building A Basic Model INACTIVE columns when you wish to save data maintenance by combining process flows that are nearly the same, but which differ by a few steps for one or more products. OPERATION: Operation number or I.D. for this step. This field is included primarily so that process steps can be more easily cross-referenced against existing manufacturing terminology or systems. For example, in manufacturing execution systems, sequential groups of related process steps are often labeled with a single operation number or I.D. When validating Factory Explorer models in cooperation with production personnel, it is often useful to have each process step labeled with its corresponding operation. Since production personnel will likely be familiar with operation numbers, this will make it easier for them to follow and double-check each process flow. If operation numbers were unique for all process steps, they could be used as the process step name. However, a single operation often includes multiple steps, so it is usually not possible to use the operation number as the step name. In addition, it is a good idea to make step names descriptive, rather than just a number, in order to make the process flow easier to understand. The Operation I.D. is also useful for modeling setups and batching via the %Operation wildcard. See Section 5.8 of the manual for more information on modeling setups. See Section 9.2 of the manual for more information on batch I.D. wildcards. The Operation ID is also used in modeling cluster tool state impacts. See Section 9.19 for more detail. STEPTYPE: Specifies the step type. Step types are display on the Process Step Detail Worksheet for easier grouping and sorting of output records. Step types must be defined on the Factory worksheet. LOAD: Time required to load a lot or batch onto a tool (random variable). PERUNIT: Processing time required for each unit (random variable). PERLOT: Processing time required for each lot (random variable). PERBATCH: Processing time required for each batch (random variable). USEBATCHID: Batch I.D. for this step. Steps using the same tool group and batch I.D. must have the same processing time (since the lots will be batched together). If different processing times are specified, Factory Explorer will flag it as an error. Batch I.D.'s are defined at the tool group level. Batch I.D. names may contain %Product, %Process, %Operation, and %Step wildcards. See Section 9.2 of the manual for more information on batch I.D. wildcards. UNLOAD: Time required to unload a lot or batch from a tool (random variable). DELAY: Extra delay time that a lot or batch experiences after it finishes processing at a tool (random variable). Tools and operators are not seized during this delay time. DELAY is useful for modeling conveyor-type tools, where the next lot can be started on the tool before the prior lot finishes processing. In this scenario, the 60 Factory Explorer Copyright WWK 1995-2009
4.2. Storing Models as Excel Workbooks time until the next lot can be started should be modeled as some combination of LOAD, PERUNIT, PERLOT, PERBATCH, and UNLOAD time. The remainder of a lot's cycle time should be modeled as DELAY time. STEPTRAVEL: Time it takes a lot or batch to get to the following processing step (random variable). TRAVELOP: Operator group, if any, required for travel. ALTPCT: Specifies the percentage of time that this alternative is chosen. ALTPCT may only be specified for alternative steps, and must be specified for every alternative process step. Currently, Factory Explorer's capacity analysis engine relies on ALTPCT to partition the flow of work among alternatives. The simulation engine, however, estimates this percentage independently. For comparison purposes, both percentages are displayed on the Alternative Steps Summary Worksheet. A version of the model that uses the alternative percentages estimated by the simulation can also be created by using the -WriteEstAlt runtime option. The sum of ALTPCT for a set of alternative steps must equal 100. For more information on alternative steps, see Section 9.14 of the manual. COSTPERUNIT: Specifies per-unit supplies & consumable cost for this process step. COSTPERUNIT is used in Factory Explorer's cost analysis. OVHDPERUNIT: Specifies per-unit overhead for this process step. OVHDPERUNIT is used in Factory Explorer's cost analysis. MATERPERUNIT: Specifies per-unit direct material cost for this process step. MATERPERUNIT is used in Factory Explorer's cost analysis. EXPXCP: Specifies expense-item exceptions for this process step. Note that only perunit expense item consumption can be eliminated via an exception. SETUPOP: Operator group, if any, required for setup. If unspecified, the process operator (if any) will be used for setup. USESETUP / SETUPID / FINISHID: Setup group name, I.D. name, and finish I.D. name for this step. Setup groups and I.D.'s are defined at the tool group level. Finish I.D.'s are rarely used unless setups are being used to model empty travel time for material handling systems. Setup I.D. and finish I.D. names may contain %Product, %Process, %Operation, and %Step wildcards. See Section 5.8 of the manual for more information on modeling setups. SCRAP / SCRAPLOT / SCRAPUNIT: Specifies scrap parameters for this step. After all processing is completed, a lot will be tested for scrap with probability SCRAP / 100. Of lots tested for scrap, each will be completely scrapped with probability SCRAPLOT / 100. Of lots tested for scrap that are not scrapped completely, each unit will be tested for scrap. Of units tested for scrap, each will be scrapped with probability SCRAPUNIT / 100. Copyright WWK 1995-2009 Factory Explorer 61
4. User's Guide: Building A Basic Model REWORKSKIP / REWORK / REWORKLOT / REWORKUNIT: Specifies rework parameters for this step. After all processing is completed, a lot will be tested for rework with probability REWORK / 100. Of lots tested for rework, each will be completely reworked with probability REWORKLOT / 100. Of lots tested for rework that are not reworked completely, each unit will be tested for rework. Of units tested for rework, each will be reworked with probability REWORKUNIT / 100. If no units of a lot are selected for rework, the lot proceeds to the step specified by REWORKSKIP. If any or all units in a lot are selected for rework, the lot is split into two pieces: the rework child (containing the units being reworked), and the rework parent (containing the good units). The rework parent waits at this step while the rework child continues to the next step in the process flow (the rework sequence). The rework sequence should end with a GOTO to some process step at or above the step where the rework originally occurred. Once the rework child finishes processing through all steps in the rework sequence and arrives back at the same step where its rework parent awaits it, it will once again be tested for rework. If no units of a rework child require rework at this second test, the child lot is reunited with its parent lot, and the parent proceeds to the step specified by REWORKSKIP. See Section 5.3 of the user manual for a sample model that includes rework. If REWORK is set to 100, REWORKLOT and REWORKUNIT must be strictly less than 100. This restriction is enforced to avoid infinite feedback loops in the process flow. FREESTEP/ HOLDTOOLPCT: Specifies the step after which the tool used for processing will be freed. Normally, Factory Explorer frees the tool used for this process step once processing for this step is completed. If FREESTEP is specified, however, Factory Explorer does not free the tool until after this later process step. HOLDTOOLPCT is optional. If HOLDTOOLPCT is not specified, then the tool will be freed upon completion of processing (load time plus process time plus unload time) at the FREESTEP. If HOLDTOOLPCT is specified, the tool will be freed after this percentage of processing at FREESTEP has been completed. This functionality is useful for modeling resources that are seized and held across multiple process steps, such as a mounting board that is only required for a portion of the process flow. FREESTEP is also useful for modeling Kanban cells. Several restrictions must be satisfied for FREESTEP to be specified, the primary one being that its use must not create a deadlock loop in the model. For more information and a complete list of restrictions, see Section 9.15 of the manual. SPLITSIZE / MIDPROCESSSPLIT / UNSPLIT Specifies the lot size and duration of lot splitting. At this process step, Factory Explorer splits the lot into one or more child lots each containing at most SPLITSIZE units. If the parent lot does not contain an even multiple of SPLITSIZE units, the last child lot will contain less than SPLITSIZE units. These child lots will proceed through subsequent process steps as normal lots. The MIDPROCESSSPLIT flag is optional. If it is not specified (default), the parent lot will be split after finishing this process step. If a
62 Factory Explorer
4.2. Storing Models as Excel Workbooks MIDPROCESSSPLIT is specified, child lots will be formed as soon as SPLITSIZE units have completed processing. The UNSPLIT step is optional. If an UNSPLIT step is specified, the child lots will accumulate at the UNSPLIT step. Once all of the child lots have finished processing at the UNSPLIT step, they are recombined into the parent lot, which then proceeds normally through the process flow. If no UNSPLIT step is specified, the child lots continue as normal lots through the remainder of the process flow. For more information on lot splitting, see Section 9.16 of the manual. PRADJUST: Value added to adjust a lot's priority after it finishes processing at this step. Use a positive value to worsen a lot's priority (i.e. moving it from priority 1 to priority 2). Use a negative value to improve a lot's priority. PRSET: Value used to set a lot's priority after it finishes processing at this step. PRDEFAULT: Flag indicating that a lot's priority should be reset to its default value after finishing processing at this step. NRGOTO: Flag indicating that any goto's specified for this step should be treated in a non-random fashion. This flag has no impact on capacity analysis calculations, only the simulation. See description for GOTOSTEP / GOTOPCT for simulation impact. GOTOSTEP / GOTOPCT: Specifies routing decision at step. GOTOSTEP gives the step where lots should be sent after finishing processing. The sum of all GOTOPCT entries for a step must not exceed 100. See Section 9.10 for details and a sample model. For capacity analysis, GOTOPCT specifies the percentage of product flow that is sent to GOTOSTEP. For simulation analysis, if NRGOTO is not specified, the probability each finished lot is sent to GOTOSTEP is given by GOTOPCT / 100, and the actual choice of GOTOSTEP is random. If NRGOTO is specified, the choice of GOTOSTEP is non-random. In this case, Factory Explorer keeps track of the total lots processed at the step, and the total lots previously sent to each GOTOSTEP. Each time a lot finishes processing, the simulation computes the percentage of lots sent to the first GOTOSTEP and compares this simulation estimate to that specified with GOTOPCT. If the simulation estimate is smaller than GOTOPCT, the lot is sent to the first GOTOSTEP. If the simulation estimate is larger than GOTOPCT, the calculation is repeated for the second GOTOSTEP, and so on. The net result is that if run for a long enough period, the percentage of lots sent to each GOTOSTEP will exactly match the step's GOTOPCT. Non-random goto's are most often used to model deterministic lot inspection selection rules. For example, if the inspection rule is that one out of every two lots must be inspected after processing at a step, non-random goto's can be used to ensure that in the simulation, every other lot processed is sent for inspection. If random goto's were used, the long-run percentage of lots inspected
Factory Explorer 63
4. User's Guide: Building A Basic Model would still be 50%, but in short periods of time the actual percentage of lots inspected could vary considerably from 50%. If GOTOSTEP is above this step in the process flow, and GOTOPCT is equal to 100, Factory Explorer checks to ensure that an infinite feedback loop is not being created. If this step is the end of a rework loop, then a 100% backward goto is allowed (assuming the rework loop is active for the same set of products for which this step is active). Also, if there is a goto above this step that points after this step, then a 100% backward goto is allowed (assuming the prior goto step is active for the same set of products for which this step is active). Otherwise, a 100% backward goto is a validation error. 4.2.4 Distribution Templates Many numeric values in Factory Explorer models are specified as random variables. For example, processing times, setup times, and time-to-failure are all specified as random variables. Specifying these values as random variables allows you to include variability and uncertainty in your model. A random variable is characterized by its distribution. Essentially, a random variable's distribution determines the frequency with which the variable takes on each possible value. From a variable's distribution, Factory Explorer can calculate its mean, minimum and maximum, and variance. The distribution also tells Factory Explorer how to generate individual observations of the random variable. See Section 4.5 of the manual for a complete list of distributions supported by Factory Explorer. Any cell in a Factory Explorer model that specifies a random variable requires you to enter the random variable's distribution. The distribution can be specified in two ways. You can enter the distribution directly into the cell (see Example 4 below), or you can use distribution templates. Distribution templates allow you to enter the type of distribution once at the top of a column (in the distribution template row, identified by the DIST keyword), and then enter actual distribution parameters below in the DATA rows. When a cell in a DATA row is converted to a distribution, the program first checks to see if a distribution has already been entered directly into the cell. If the cell data begins with an alphabetic character, the program assumes the entry completely specifies the distribution, and uses the contents of the cell without regard to the distribution template. Otherwise, the program substitutes the contents of the cell for the first question mark (?) in the distribution template. If there are subsequent question marks remaining in the distribution template, the program moves right one cell and substitutes the contents of that cell for the next question mark. This process is followed until there are no remaining question marks in the distribution template. If you specify a distribution template with multiple parameters (see Examples 3 and 4 below), you will need to add one or more additional columns to your worksheet to contain the extra parameters. It is ok to add these columns, and the additional columns do not need keywords in row 1. Example 1: Random variable is the constant 5: c(5). DIST DATA c(?) 5 Copyright WWK 1995-2009
64 Factory Explorer
4.2. Storing Models as Excel Workbooks Example 2: Random variable is triangular with mean 3 and range +/- 50%: tp(3,50). DIST DATA tp(?,50) 3
Example 3: Random variables are tp(3,25) and tp(5,75). DIST DATA DATA tp(?,?) 3 5 25 75
Example 4: Random variables are tp(3,25) and e(1). DIST DATA DATA tp(?,?) 3 e(1) 25
Using distribution templates to build your model will make certain types of model analysis much easier. For example, consider time-to-failure data, which is often modeled with exponential random variables. Specifying the template e(?) and then filling in the appropriate mean value for each DATA row is the recommended way of entering your data. To see why, suppose that you are not really sure that you should be modeling timeto-failure data with exponential random variables. For comparison purposes, you might wish to model time-to-failures as a triangular random variable with a range of +/- 50%. To see the effect of such a change, you can simply change the distribution template to tp(?,50) and make new model runs for comparison. If you had specified the time-tofailure data distributions directly in each model cell, e.g. e(1.5) in the first cell, e(2.7) in the second cell, etc., you would have been required to manually change each of these cells to read tp(1.5,50), tp(2.7,50), etc. 4.2.5 Excel's 1900 and 1904 Date Systems Microsoft Excel supports two systems for storing dates in workbooks. On Windows platforms, the most commonly used is the 1900 date system. In this system, dates are stored as the number of days (inclusive) since January 1st, 1900. For consistency, Factory Explorer Excel models must use the 1900 date system. Before performing analysis on an Excel model, Factory Explorer's Excel interface will check that the workbook holding the model uses the 1900 date system. To change the date system for an Excel workbook, select Tools | Options | Calculations. Use caution when changing the date system for a workbook, however. Switching the date system for a workbook will silently modify all existing dates in the workbook. Excel stores only the offset from either January 1st 1900 or January 1st 1904 in the workbook. When the date system is changed, the resulting dates are shifted by approximately four years. When Factory Explorer reads in an Excel model, it first converts it to ASCII format and then reads the ASCII model. When reading dates in an ASCII model, Factory
Factory Explorer 65
4. User's Guide: Building A Basic Model Explorer accepts dates in ISO format (YYYY-MM-DD) or in Excel's 1900 day number format. There is one slight quirk in this format, however. Excel's 1900 format assumes that 1900 was a leap year, even though it was not. As Microsoft's Knowledge Base Article Q106339 states: "When the date system in Microsoft Excel was originally created, it was designed to be fully compatible with date systems used by other spreadsheet programs. However, in this date system, the year 1900 is incorrectly interpreted as a leap year." So, Factory Explorer's internal date routines assume that dates specified in day number format use the Excel convention of 1900 as a leap year. This quirk will not affect most users, however, as it does not affect Excel models. Also, for ASCII models it is usually more convenient to enter dates in ISO format than in 1900 day number format. Factory Explorer will also accept dates that include hours and minutes. To use this functionality in Excel models, simply format cells with a date format that shows hours and minutes. Factory Explorer will automatically append the hours and minutes to the end of the ISO date format (e.g. YYYY-MM-DD_HH:MM) when converting the Excel file. To use this functionality in ASCII models, use the format YYYY-MMDD_HH:MM, where there is an underscore '_' between the date and hours/minutes. This method can also be used to specify a starting date other than midnight for the StartDate run-time option, use the format YYYY-MM-DD_HH:MM. To include hours and minutes in all Excel output worksheets and charts, go to the System Parameters dialog from the FactoryX pull-down menu. On the System Parameters dialog, check the option for Include Hours and Minutes in Date Outputs. Factory Explorer is year 2000 compliant, in that it a) can use dates beyond the year 2000; b) correctly identifies Jan 1, 2000 as a Saturday; and c) correctly identifies 2000 as a leap year. Excel 97 and Excel 2000 have also been tested to ensure that they can pass post2000 dates properly to Factory Explorer, and that they can correctly display post-2000 dates in Factory Explorer output.
4.3 Rules for Product Names, Tool Group Names, etc.

A Factory Explorer model includes textual names for various entities, including products, tool groups, operator groups, process steps, batch I.D.'s, setup groups, setup I.D.'s, etc. In the filler paper example the single product was filler, the tool group names were ruling and punch, and the process steps were rule-it and punch-it. This section describes the rules you must adhere to when naming these entities. Rules Applying to All Models 1) Names may be any combination of printable characters of any length. 2) Names are not case sensitive. Thus, ruling and Ruling both specify the same tool group.
66 Factory Explorer
4.4. Process Time Parameters 3) Names for the same type of entity must be unique. That is, you cannot have two products with the same name, two tool groups with the same name, etc. An exception to this rule is alternative process steps. Factory Explorer allows multiple process steps to have the same name, as long as these steps are contiguous within the process flow. Factory Explorer treats these steps as alternatives. For information on alternative steps, see Section 9.14 of the manual. Note 1: Excel Models Names in Excel models may contain leading, trailing, or intervening spaces. When Factory Explorer translates Excel models to ASCII format in preparation for a model run, it will automatically remove any leading and trailing spaces, and substitute underscores "_" for any intervening spaces. For example, the tool group name " M Prep 1 " will be translated as "M_Prep_1". You must be consistent when entering the name in different locations in the model, however. For example, if you enter the tool group name in one location as "M Prep 1", and in another location as "MPrep 1", the first reference will be translated as "M_Prep_1", but the second will be translated as "MPrep_1", leading to an error. Note 2: ASCII Models Names in ASCII models may not contain intervening spaces. Since spaces are used to separate keywords within ASCII models, the space would break the name into two pieces, and most likely cause an error when Factory Explorer attempts to read in the model. If you wish to use a tool group name such as "M Prep 1", simply enter it in the ASCII model as "M_Prep_1". If you are translating your model from Excel to ASCII format, the translation routine will automatically perform the substitution of underscores "_" for intervening spaces (see Note 1 above).
4.4 Process Time Parameters

In Factory Explorer, process time parameters specified at the process step level determine the process time calculation and tool type. The following formula is used to calculate processing time at the tool: Processing Time = Time per Batch * Number of Batches + Time per Lot + Time per Unit * Number of Units. If not specified for a processing step, Time per Batch, Time Per Lot, and Time per Unit default to zero. Time per Lot and Time per Unit may be used alone or with each other for a step. If Time per Batch is specified for a step, Time per Lot cannot also be specified. Time per Batch does not depend on the number of lots processed in a batch. For batch processing, the Number of Batches is always one unless a lot is processed that has more units than the maximum batch size. In that event, Factory Explorer sets Number of Batches = Ceiling(Number of Units in Lot / Maximum Batch Size), where the Ceiling function rounds up to the next higher integer. For example, if a lot contains twenty-five units, and the maximum batch size is twelve units, the lot will be processed as three batches (two full batches and one partial batch). Factory Explorer does not process additional lots as part of the final batch even if the final batch is only partially Copyright WWK 1995-2009 Factory Explorer 67
4. User's Guide: Building A Basic Model full. Note that this situation never arises if batch sizes are specified in terms of lots, as the smallest batch size (one lot) is large enough to process any incoming lot. Factory Explorer uses the following algorithm when attempting to form batches at batch tools. The algorithm starts with the first lot waiting in queue (sorted according to whatever dispatch rule is specified). From this first lot's process step it determines a tentative batch I.D. Factory Explorer then searches through the rest of the waiting line, looking for lots with the same batch I.D. As it finds lots with the same batch I.D., it adds them to the batch as long as the total batch size (in units or lots as specified by the batch I.D. definition) does not exceed the maximum batch size for the batch I.D. Factory Explorer does not add a lot to a batch unless the entire lot fits within the space remaining. The only time an individual lot is processed in more than one batch is when the batch size is specified in units, and the lot size exceeds the maximum batch size, making such splitting necessary. When the entire waiting line has been searched, Factory Explorer compares the batch size with the minimum batch size for the batch I.D. If the batch size meets or exceeds the minimum batch size, the batch is started. Otherwise, Factory Explorer adds the batch I.D. to an exclusion list. The search process is then restarted at the beginning of the waiting line, except that lots with batch I.D.'s found on the exclusion list are skipped (since it has already tried and failed to form a batch for any batch I.D. found on the list). At the algorithm's termination the exclusion list is cleared. When the dispatch rule at a batch tool is specified as PRFULLFIFO or PRFULLCR, Factory Explorer keeps track of the number of units waiting in queue by batch I.D. Whenever two lots are compared to see which lot should come first in line, Factory Explorer first compares the lots by priority. If both lots have the same priority, Factory Explorer checks to see if either lot has a batch I.D. for which enough units are waiting in line to form a nearly full batch (nearly full is defined to be a number of units greater than or equal to the maximum batch size minus the largest lot size defined in the model). If this check results in a tie, Factory Explorer compares the lots using the nominal method (FIFO or critical-ratio) for the dispatch rule specified. In addition to Processing Time defined above, the following additional process step parameters affect the timing of lot processing: Setup Time: Time spent setting up the tool to process a lot, if necessary. Load Time: Time spent loading a lot or batch onto the tool. Unload Time: Time spent unloading a lot or batch from the tool. Delay Time: Time when a lot or batch is not yet finished processing, but the tool used for processing is free to start loading another lot. Step Travel Time: Time spent transporting a lot or batch to the next process step. If operators are not required at a step, the following sequence occurs when lots are processed: 1. Seize tool. 2. Delay Setup Time, if any. 3. Delay Load Time + Processing Time + Unload Time.
68 Factory Explorer
4.4. Process Time Parameters 4. Release tool. 5. Delay Delay Time + Step Travel Time. 6. Lot enters next processing step. If operators are required at a step, the following sequence occurs when lots are processed: 1. 2. 3. 4. 5. 6. Seize tool and operator. Delay Setup Time (operator released before end of setup if Setup Percent < 100%). If Setup Percent < 100%, seize operator. Delay Load Time (operator released before end of load if Load Percent < 100%). If Load Percent < 100%, seize operator. Delay Processing Time (operator released before end of processing if Process Percent < 100%). 7. If Process Percent < 100%, seize operator. 8. Delay Unload Time (operator released before end of unload if Unload Percent < 100%). 9. Release tool (also release operator if Unload Percent = 100%). 10. Delay Delay Time. 11. Seize operator if required for travel to next step. 12. Delay Step Travel Time. 13. Release operator if seized for travel. The following common types of tools can be modeled by setting the corresponding parameters appropriately. All processing time parameters that are not specified default to zero. Batch Tools: Load Time, Unload Time, and Time per Batch (may also specify Time per Unit if appropriate). Single-Unit Tools: Load Time, Unload Time, and Time per Unit. Conveyer Tools: Load Time, Unload Time, Time per Unit, and Delay Time. Multisequence Tools: Load Time, Unload Time, Time per Batch, and Delay Time. Cluster Tools (model as batch tools): Load Time, Unload Time, and Time per Unit (may also specify Time per Batch if appropriate). See Section 9.19 for more detail on Factory Explorers cluster tool modeling capabilities. Single-Lot Tools: Load Time, Unload Time, and Time per Lot. Mixed Single-Unit / Singe-Lot Tools: Load Time, Unload Time, Time per Unit, and Time per Lot. And a final reminder: Time per Lot and Time per Unit may be used alone or with each other for a step that uses a non-batch tool. At steps that use a batch tool, Time per Batch and Time per Unit may be used alone or with each other, but Time per Lot cannot be specified. All process steps that use the same batch tool and that have the same batch I.D. must specify the same process time. For the method used by Factory Explorer to calculate a product's raw process time, see Section 20.24.
Factory Explorer 69
4.5 Specifying Distributions

To model uncertainty, many input variables are represented by random variables. To quantify the randomness in an input variable, you give its distribution. In ASCII models, a distribution is specified in the input file in the form dist(parms). In Excel models, a distribution may either be specified directly in the form dist(parms), or through the use of distribution templates. See Section 4.2.4 for information on distribution templates. The distributions supported in Factory Explorer appear in Table 4-1.
Table 4-1: Distributions supported in Factory Explorer.
Distribution c(value) e(mean) u(min,max) tp(mean,pct) up(mean,pct) tri(min,mode,max) beta(min,max,parm1,parm2) erlang(mean,m) hyper2(m1,p1,m2,p2) hyper3(m1,p1,m2,p2,m3,p3) ear(mean,corr) shift_e(min,mean) weibull(Alpha, Beta) gamma(Alpha, Beta) binom(N,p)
Description Constant. Exponential. Uniform between min and max. Triangular, mean +/- pct%. Uniform, mean +/- pct%. Triangular. Beta. Sum of m exponentials e(mean/m). Exponential e(m1) with probability p1, etc. Exponential e(m1) with probability p1, etc. Exponential autoregressive with lag-1 correlation corr. Shifted exponential: min+e(mean-min). Weibull Gamma Binomial -- sum ofN i.i.d. Bernoulli(p).
4.6 Dispatch Rules

Factory Explorer includes a variety of dispatch rules (service disciplines). If these rules are applied and a tie results, it is broken in favor of the lot with the lowest lot number. Lot numbers are assigned sequentially without regard for product type when lots are released into the factory. Lower priorities are favored (1 is better than 2). For references to articles on over one hundred dispatch rules, see Panwalker and Iskander (1977). Unless specified, the default dispatch rule used in Factory Explorer is FIFO (first-in-first-out). Dispatch rules may be specified for individual tool groups and operator groups in the DISPATCHRULE column (Excel models), with the DispatchRule statement (ASCII models) or globally for all tool groups and operator groups using DispatchRule. For rules that require due dates, due date offsets can be specified in the DUEDATE column (Excel models), with the DueDate statement (ASCII models), or globally for all products as a constant multiple of raw process time using SetDueXRPT. For rules that use leadtime factors, these factors can be specified in the LTF column (Excel models), with the LeadTimeFactor statement (ASCII models), or globally for all products using SetLTF. Factory Explorer includes both static and dynamic dispatch rules. Static rules are those where the information used to sort lots in the queue does not change with time. For example, if at time ten there are three lots in queue, and the current dispatch rule would 70 Factory Explorer Copyright WWK 1995-2009
4.6. Dispatch Rules service them in the order A, B, C, a static rule would never at some later time order the lots B, A, C. However, under a dynamic dispatch rule, the order of lots waiting in the queue can change over time. First-in-first-out is an example of a static rule; critical ratio is a dynamic rule. In models with operators, the interaction between operator dispatch rules and tool dispatch rules can be complex. See Section 23.7 for more details. Table 4-2 displays the dispatch rules supported in Factory Explorer. More detailed explanations follow this table.
Table 4-2: Factory Explorer Dispatch Rules
Rule ATCS CCOMPSTEP CCOMPRPT EDD FIFO LIFO LSLACK ODD PRCCOMPSTEP PRCRITICAL PRCRITICAL2 PREDD PRFIFO PRFULLCR: PRFULLFIFO: PRLIFO PRWORKAPD RANDOM SPT
Static or Dynamic Dynamic Static Static Static Static Static Static Dynamic Static Dynamic Dynamic Static Static Dynamic Dynamic Static Dynamic Dynamic Static
Description Apparent tardiness cost with setups Closest to completion by lot step Closest to completion by RPT Earliest due date First-in-first-out Last-in-first-out Least-slack Operation Due Date Priority-closest to completion by lot step Priority-critical ratio (original, version 1) Priority-critical-ratio (version 2) Priority-earliest due date Priority-FIFO Priority-full batch-critical ratio Priority-full batch-FIFO Priority-LIFO Priority-WorkStream AP/D Randomized Shortest mean processing time
ATCS: The Apparent Tardiness Cost with Setups dispatch rule is a composite rule which blends three different heuristics that are effective when used in singlemachine scheduling problems: weighted shortest processing time, least slack, and setup avoidance. These three heuristics are blended together to evaluate the tradeoffs that exist when trying to sequence jobs that have due dates and priorities on machines that require sequence-dependent setups. CCOMPSTEP: For each lot, the lot completion ratio (CompRatio) is computed, based on the current step number (Step), and the total number of processing steps in the lot's process flow (NStep), CompRatio = Step / NStep. The lot with the highest CompRatio is favored. Between lots with the same CompRatio, the rule is first-in-first-out.
Factory Explorer 71
4. User's Guide: Building A Basic Model CCOMPRPT: For each lot, the lot completion ratio (CompRatio) is computed, based on the current step's remaining raw process time (RemainingRPT), and the total raw process time for the lot's process flow (TotRPT), CompRatio = RemainingRPT / TotRPT. The lot with the highest CompRatio is favored. Between lots with the same CompRatio, the rule is first-in-first-out. Remaining raw process times are calculated from capacity analysis, so this rule cannot be used unless DoCap is enabled. EDD: The lot with the earliest due date is favored. When lots are released, Factory Explorer generates due dates by taking the current time and adding the due date offset, which can be a random variable. Due date offsets are specified at the product level with the DueDate statement (ASCII models) or in the DUEDATE column (Excel models). Products that are processed on tool groups using this dispatch rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). FIFO: The lot that entered queue first is favored. The default dispatch rule is FIFO. LIFO: The lot that entered queue last is favored LSLACK: The amount of slack (Slack) is computed for each lot based on the due date (Due), the remaining raw process time from the step (RemainingRPT), and current time (Now), Slack = Due - Now - RemainingRPT. Since Now is the same for all lots, the comparison is made on the basis of Slack* = Due RemainingRPT. The lot with the smallest Slack* is favored. Between lots with the same Slack*, the rule is first-in-first-out. Remaining raw process times are calculated from capacity analysis, so this rule cannot be used unless DoCap is enabled. When lots are released, Factory Explorer generates due dates by taking the current time and adding the due date offset, which can be a random variable. Due date offsets are specified at the product level with the DueDate statement (ASCII models) or in the DUEDATE column (Excel models). Products that are processed on tool groups using this dispatch rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). ODD: In general, the due date for a lot of a specific product is given in terms of a FLOWFACTOR (FF) that is defined as the target cycle time divided by the raw processing time (RPT). For instance, a FF of 2 says that a lot spends half of its cycle time in processing state and the other half in non-processing states like waiting. Thus, the due date of a lot is the time when it enters the fab plus FF * RPT. For ODD, we also need the raw processing time RPT(i) for a sequence of processing steps or operations from operation 1 to operation i (including operation i). The ODD of operation i is defined as the Release Time + RPT(i) * FF. For the final operation of a lot the ODD is equal to the classical due date as used in EDD or CR.
72 Factory Explorer
4.6. Dispatch Rules PRCCOMPSTEP: First, the lot with lowest priority is favored. In case of equal priorities, the lot with the lowest lot completion ratio is favored. For each lot, the lot completion ratio (CompRatio) is computed, based on the current step number (Step), and the total number of processing steps in the lot's process flow (NStep), CompRatio = Step / NStep. The lot with the highest CompRatio is favored. Between lots with the same CompRatio, the rule is first-in-first-out. PRCRITICAL: First, the lot with lowest priority is favored. In case of equal priorities, the critical ratio (Ratio) is computed for each lot, based on the total remaining process time (TotalRemain), the product lead time factor (LTF), the due date (Due), and the current time (Now). If Due > Now, Ratio is set to (1 + Due - Now) / (1 + LTF * TotalRemain), otherwise Ratio is calculated as 1 / ((1 + Now Due) * (1 + LTF * TotalRemain)). The lot with the lowest critical ratio is favored. When lots are released, Factory Explorer generates due dates by taking the current time and adding the due date offset, which can be a random variable. Due date offsets are specified at the product level with the DueDate statement (ASCII models) or in the DUEDATE column (Excel models). Products that are processed on tool groups using this dispatch rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). Lead time factors are specified at the product level with the LeadTimeFactor statement (ASCII models) or in the LTF column (Excel models). The default lead time factor is 1.0. PRCRITICAL2: First, the lot with lowest priority is favored. In case of equal priorities, the critical ratio (Ratio) is computed for each lot, based on the total remaining process time (TotalRemain), the product lead time factor (LTF), the due date (Due), and the current time (Now). Ratio is set to (Due - Now) / (Epsilon + LTF * TotalRemain). Epsilon is a very small number added to the denominator to avoid dividing by zero if the last few steps in a process flow have zero process times. The lot with the lowest critical ratio is favored. When lots are released, Factory Explorer generates due dates by taking the current time and adding the due date offset, which can be a random variable. Due date offsets are specified at the product level with the DueDate statement (ASCII models) or in the DUEDATE column (Excel models). Products that are processed on tool groups using this dispatch rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). Lead time factors are specified at the product level with the LeadTimeFactor statement (ASCII models) or in the LTF column (Excel models). The default lead time factor is 1.0. PREDD: First, the lot with lowest priority is favored. Within equal priorities, the lot with the earliest due date is favored. When lots are released, Factory Explorer generates due dates by taking the current time and adding the due date offset, which can be a random variable. Due date offsets are specified at the product level with the DueDate statement (ASCII models) or in the DUEDATE column (Excel models). Products that are processed on tool groups using this dispatch
Factory Explorer 73
4. User's Guide: Building A Basic Model rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). PRFIFO: First, the lot with lowest priority is favored. Within equal priorities, the lot that entered queue first is favored. PRFULLCR: First, the lot with lowest priority is favored. In case of equal priorities at a non-batch tool, the lot with the lowest critical ratio is favored. In case of equal priorities at a batch tool, the lot that can be part of a batch that is nearly full is favored. For this dispatch rule, nearly full means that the number of units in the batch is within the maximum lot size (for all products in the model) of the maximum batch size. If both lots make up nearly full batches, the lot with the lowest critical ratio is favored. Products that are processed on tool groups using this dispatch rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). PRFULLFIFO: First, the lot with lowest priority is favored. In case of equal priorities at a non-batch tool, the lot that entered queue first is favored. In case of equal priorities at a batch tool, the lot that can be part of a full batch is favored. If the batch size is specified in units, a full batch is defined as one where the number of units is within the nominal lot size (for the product) of the maximum batch size. If both lots are part of full batches, the lot that entered queue first is favored. Due to unit-level scrap, lots arriving at a batch tool may not always be full. The way that lots are collected to form a batch may lead to a batch that is partially full, but that cannot be completely filled since the remaining space in the batch is not large enough to accommodate any of the waiting lots that are eligible to fill it. (Factory Explorer does not process a lot as part of multiple batches unless the lot size exceeds the maximum batch size, making such splitting necessary). If the batch size is specified in lots, a full batch is defined as one where the number of lots equals the maximum batch size. PRLIFO: First, the lot with lowest priority is favored. Within equal priorities, the lot that entered queue last is favored. PRWORKAPD: First, the lot with lowest priority is favored. In case of equal priorities, the WorkStream priority function (WPF) is computed for each lot, based on the total remaining process time (TotalRemain), the product lead time factor (LTF), the due date (Due), and the current time (Now). First, define the number of days until the due date by D = (Due - Now) / 24, the remaining cycle time in days by C = LTF * TotalRemain / 24, and the expected days late by L = C - D. If L < 0, then WPF = -100 * L / (1 + D). If L >= 0 and D >= 0, then WPF = 10 * L / (1 + D). If D < 0, then WPF = -L * (10 - D). If WPF is larger than 99.9 or smaller than -99.9 it is truncated to 99.9 or -99.9, respectively. The lot with the lowest WPF is favored. When lots are released, Factory Explorer generates due dates by taking the current time and adding the due date offset, which can be a random variable. Due date offsets are specified at the product level with the
74 Factory Explorer
4.7. Units of Measure DueDate statement (ASCII models) or in the DUEDATE column (Excel models). Products that are processed on tool groups using this dispatch rule must specify due date offsets. If no due date offset is specified, FX sets the due date equal to the start date for each lot (or the split date for split lot children). Lead time factors are specified at the product level with the LeadTimeFactor statement (ASCII models) or in the LTF column (Excel models). The default lead time factor is 1.0. RANDOM: When a tool is ready to begin service, all lots that are ready to be served are assigned uniform (0,1) random numbers. The lot with the smallest random number is favored. SPT: The lot with the shortest raw process time (for the current step) is favored. Raw process times are calculated during capacity analysis, so this rule cannot be used unless DoCap is enabled. Raw process times are based on lots with an average number of units, unless OneUnitRPT is enabled, in which case they are based on lots with a single unit.
4.7 Units of Measure

Within its analysis engines, Factory Explorer normalizes all times and rates in terms of hours (e.g. lot cycle times are recorded internally in hours, and product start rates are stored internally in units per hour). For ease of use, however, Factory Explorer provides user-specified units of measure for several model inputs and run-time options. Run-time options also control Factory Explorer's display of performance measures on output reports, charts, and worksheets. This section presents methods for controlling unit of measure choices for model inputs, run-time options, and model outputs. 4.7.1 Time Units of Measure Table 4-3 defines the basic time units that Factory Explorer provides. Note that these times are defined in terms of calendar time, not factory scheduled hours. This distinction becomes important when modeling factory schedules. For example, suppose a factory is scheduled to operate only two shifts per day, seven days per week (for a total of 112 scheduled hours per week). If instructed to run a one-week simulation of this factory, Factory Explorer will execute the simulation for 168 calendar hours (thus simulating one week in real life), not 168 scheduled hours (which would simulate 1.5 weeks in real life).
Factory Explorer 75

Table 4-3: Time unit definitions.
Time Unit Hour Day Week Month
Definition ( StartDate not Specified) One calendar hour 24 calendar hours 168 calendar hours 730 calendar hours (8760 hours per year / 12 months per year) 2190 calendar hours (8760 hours per year / 4 quarters per year) 8760 calendar hours (365 days per year * 24 hours per day)
Quarter Year
Definition ( StartDate Specified) One calendar hour 24 calendar hours 168 calendar hours 1 calendar month (i.e. 31 days for January, 28 days for nonleap-year February, etc). 3 calendar months 1 calendar year
For start and throughput rates, Factory Explorer provides the following units of measure: UnitsPerHour, UnitsPerDay, UnitsPerWeek, UnitsPerMonth, UnitsPerQuarter, and UnitsPerYear. When converting between units of measure for rates, Factory Explorer first converts from the original unit of measure to UnitsPerHour, and then converts from UnitsPerHour to the desired unit of measure. For example, suppose an input model defines a start rate for a product of 1680 UnitsPerWeek. If directed to display start rates on output reports in UnitsPerYear, Factory Explorer first calculates that 1680 units per week is equivalent to 10 units per hour, then calculates that 10 units per hour is equivalent to 87,600 units per year. Note that the above definitions are particularly important when using start or throughput rates stated in terms of units per week or units per month. Using Factory Explorer's definitions, there are approximately 4.35 weeks per month (730 hours per month / 168 hours per week), and approximately 52.14 weeks per year (8760 hours per year / 168 hours per week). If input for a Factory Explorer model is based on numbers that do not match these conversion factors, confusion often results. In Factory Explorer models, only a limited number of input variables currently support user-specified units of measure. These variables are product start and throughput rates. Product start rates, specified in the STARTRATE column (Excel models) or via the UnitStartRate statement (ASCII models), default to UnitsPerHour. The unit of measure for start rates may, however, be specified in the STARTUM column (Excel models) or via the UnitStartRateUM statement (ASCII models). Similarly, product throughput rates, specified in the TPUTRATE column (Excel models) or via the UnitTputRate statement (ASCII models), default to UnitsPerHour. The unit of measure for throughput rates may be specified in the TPUTUM column (Excel models) or via the UnitTputRateUM statement (ASCII models). For more information on these input variables, see Section 4.2.3 of the manual. Factory Explorer run-time options that accept a time or rate have an accompanying option that controls the unit of measure. For example, RunLen time specifies the analysis run-length, while RunLenUM timeUM controls the unit of measure for time. If RunLenUM is not enabled, then Factory Explorer assumes that 76 Factory Explorer Copyright WWK 1995-2009
4.7. Units of Measure time is given in hours. The following run-time options have accompanying unit of measure run-time options: RunLen, ReleaseRate, and AddRate. The clear-statistics option ClearStats cleartime does not have an accompanying unit of measure run-time option. Factory Explorer assumes that cleartime is in the same unit of measure as the analysis run-length. For more information on these or other run-time options, see Section 13.2 of the manual. In the Factory Explorer Excel interface, RunLen and ClearStats are specified on the Run Factory Explorer dialog, while ReleaseRateUM and AddRateUM are specified on the Lot Release options dialog. Two Factory Explorer run-time options control the units of measure displayed on output reports, charts, and worksheets. Run-time option OutCTUM timeUM specifies the unit of measure for cycle times; option OutRateUM rateUM specifies the unit of measure for product start and throughput rates. In the Factory Explorer Excel interface, OutCTUM and OutRateUM are specified on the Output Data options dialog. For more information on these or other run-time options, see Section 13.2 of the manual. 4.7.2 Cost Units of Measure There is no specified cost unit of measure in Factory Explorer. Users must assume consistent cost units of measure throughout the model. If the cost unit of measure is US$, then all inputs have to be in US$. Users can insert blank columns to input different units of measure and to convert it into a consistent unit of measure. In charts, the displayed cost unit of measure is controlled by axis attributes set within the users Excel. Users must ensure that these axis attributes are also set consistently with the assumed cost units of measure.
Factory Explorer 77
5. User's Guide: Enriching The Basic Model
5.1 Introduction
In this chapter we return to the paper model discussed in Section 4.1. Starting with that basic model, we gradually enrich it to demonstrate many of the modeling capabilities supported by Factory Explorer, including equipment failures (Section 5.2), scrap and rework (Section 5.3), operators (Section 5.4), multiple products (Section 5.5), prioritybased dispatch rules (Section 5.6), lot priority adjustment (Section 5.7), and setup (Section 5.8).
5.2 Equipment Failures

In this section we relax the assumption that our machines are always available to process incoming lots. Consider the ruling machine, which places ruling lines on the filler paper. Over time, the printing mechanism gets dirty and clogged with ink, and eventually stops working. From past data, we know this happens about every 10,000 sheets processed, and takes about sixteen hours to fix. This is an example of a failure, or interruption, which is based on units-of-work completed, as opposed to busy-time, the time a machine has been busy processing lots, or clock-time, the elapsed simulated time. All three types of interruptions can be included in Factory Explorer models for more detailed instructions on modeling equipment downtime, see Section 9.3. Since we have little information about the actual distribution of units of work between failures, we can use a triangular distribution with mean 10000, and range +/- 25%. The time to repair we model as a constant sixteen hours. The modifications necessary to our earlier example are included in the Excel model paper2.xls. The only change occurs on the tools worksheet, with an entry for the failure process. Figure 5-1 displays the section of the tools worksheet where this information is entered.
Factory Explorer 79
Figure 5-1: Tools worksheet, paper2 model.
For more detailed information on modeling equipment downtime (failures, preventive maintenance, engineering time, etc.) with Factory Explorer interruptions, see Section 9.3.
5.3 Scrap and Rework

In this section we show how to model product scrap and rework in Factory Explorer. Expanding on our filler paper example, suppose we know that the punch machine ruins about 1% of the sheets that it processes (due to miss-alignment of the sheets, or tearing of the paper when it is drilled). Suppose also that the ruling machine jams about 5% of the time and only completes half of the current lot. Sorting out the unprinted sheets for rework takes about 15 minutes. Scrap and rework information is specified at the process step level. The Excel model for this example is paper3.xls. The first few columns of the new tools worksheet are displayed in Figure 5-2.
80 Factory Explorer
5.3. Scrap and Rework
Figure 5-2: Tools worksheet, paper3 model.
The paper3 tools worksheet is different from that of paper2.xls only in that it contains an additional tool group definition for the sorting table. This tool group is the one used when performing rework. The process sheet for paper3 has several new areas filled in to specify the scrap and rework parameters. First of all, the process flow has been expanded to include the process step for rework. The first section of the process worksheet is shown in Figure 5-3.
Factory Explorer 81
Figure 5-3: Process sheet, paper3 model. The process flow has been expanded to include the process step for rework.
Scrap is modeled in Factory Explorer by specifying the percentage of lots tested for scrap, the percentage of lots tested that are fully scrapped (the entire lot is scrapped), and the percentage of units scrapped in lots that are tested but not fully scrapped. Rework is modeled in Factory Explorer by specifying a skip-to step and three rework parameters. The skip-to step identifies the process step that a lot is transferred to if it does not require any rework (normally the skip-to step identifies the next non-rework step in the process flow). The three required rework parameters are the percentage of lots tested for the rework, the percentage of lots tested that are fully reworked (the entire lot is reworked), and the percentage of units reworked in lots that are tested but not fully reworked. Figure 5-4 displays the columns in the paper3 model that contain scrap and rework information.
82 Factory Explorer
5.3. Scrap and Rework
Figure 5-4: Process sheet, paper3 model. Scrap parameters have been filled in for the punch step, and rework parameters have been filled in for the ruling step.
All lots are tested for scrap following the Rule-It step. The percentage of time a full lot must be scrapped is so small that we do not include it in this model. Approximately 1% of all sheets are scrapped at this point. Approximately 5% of the time, the Ruling machine jams during processing. Lots involved in a jam must be examined to see if rework is required (i.e. the percentage of lots tested for rework is 5%). When jamming occurs, approximately 50% of the sheets normally require rework. If no sheets require rework, the lot continues to the Punch-It step. Otherwise, the lot is split into a rework parent lot containing the sheets that are not being reworked, and a rework child lot containing the sheets being reworked. The rework child lot proceeds to the next step in the process flow (the Sort-Sheets step). This step begins the rework loop, and could contain an arbitrary number of process steps. In this example, however, it contains only the single step required to sort the sheets back into a tidy package. The rework loop must end with a branch (a goto) to a process step at or before the process step where the rework occurred. In our example, the rework loop ends with a branch back to the Rule-It step, where the rework child lot undergoes ruling. The columns containing the goto information for the paper3 model are displayed in Figure 5-5.
Factory Explorer 83
Figure 5-5: Process sheet, paper3 model. A goto statement ends the rework loop, indicating that all rework child lots are to return to the ruling step after being reworked.
Once the rework child lot returns to and finishes processing at the rework step where it was separated from its parent (the Rule-It step), it is again tested for rework. If jamming again occurs, and the rework child itself requires more rework, a new rework child lot is created containing rework sheets from the child lot, and the process is repeated. When no sheets in a rework child lot require additional rework, the rework child lot is merged back into its parent. If the parent is itself a rework child lot, the merging process continues until the original parent lot is reached, at which point the original parent lot becomes a normal lot and continues to the Punch-It step. 5.3.1 Rules for Modeling Rework Introducing rework into a Factory Explorer adds a new level of complexity. To ensure that the model it is analyzing makes sense, Factory Explorer enforces a set of rules regarding rework modeling. In particular, these rules ensure that rework child lots are always (eventually) recombined with their parents, and that a lot in rework never exits the process flow. When performing model validation, Factory Explorer enforces the following rules. 1. In models with ramped data, a step cannot be both a rework step and not a rework step at different effective dates. 2. In models with ramped data, a rework step must specify the same skip-to-step for all effective dates. 84 Factory Explorer Copyright WWK 1995-2009
5.4. Operators 3. A rework step cannot also specify a goto. 4. The rework skip-to-step must point forward in the process flow (e.g. to a step after the rework step). 5. The rework skip-to-step cannot point to the next step in the process flow (which must by definition be inside the rework loop). 6. The last step in the rework loop (the step prior to the rework skip-to-step) must specify a 100% goto to a step at or above the rework step. 7. The last step in the rework loop (the step prior to the rework skip-to-step) must be active for all products for which the rework step is active. 5.3.2 Including Scrap Inside Rework Loops Factory Explorer's capacity analysis engine makes the assumption that scrap inside rework loops is negligible. If the rework rate and scrap rate are both high (say larger than 20%) this assumption will not be valid, thus biasing the results of capacity analysis. If you wish to model significant scrap inside rework loops, please contact technical support for assistance on how to work around this problem.
5.4 Operators
Up to this point, we have assumed that operators are always available to perform the steps in our models. Operators are modeled in Factory Explorer with operator groups. Operator group descriptions are much like tool group descriptions, in that you specify an operator group name, number of operators, and optionally list any applicable operator interruptions. There are tradeoffs involved in modeling operators. Explicit modeling of operators may increase the realism of the model, but it also increases the model complexity and the time required to simulate. Continuing the example of the previous section, suppose two operators are available to run both the ruling and punch machines. However, operators are not required to be present at the ruling machine while it is processing, other than to load and unload lots. The Excel model for this example is paper4.xls. This model is an extension of paper3.xls, with changes to the tools, operators, and process worksheets. The tools worksheet has been modified to include the percent of time that operators are required for load, processing, and unload for each tool group. These columns are shown in Figure 5-6. The operators worksheet contains the operator group definitions, and is shown in Figure 5-7. The process worksheet has been modified to specify that an operator is required for each processing step, and is shown in Figure 5-8.
Factory Explorer 85
Figure 5-6: Tools worksheet, paper4 model. This model includes operators, and the columns above contain the percent of time operators are needed to perform various tasks.
86 Factory Explorer
5.4. Operators
Figure 5-7: Operators worksheet, paper4 model. In this model, there is a single operator group that performs all operator tasks, and it contains 2 operators.
Factory Explorer 87
Figure 5-8: Process worksheet, paper4 model. An operator from the FillerOp operator group is required for each processing step.
5.5 Multiple Products

In this section we explore the modifications necessary to our paper4 model in order to include a second product. Recall that we had a single product: one hundred count filler paper. Suppose the second product is two hundred count filler paper. For clarity, we have renamed the first product to be 100count, and named the second product 200count. In this example, we have lengthened the process flow to include the step where the filler paper is shrink-wrapped. The process steps for both products are the nearly the same, except for minor differences at this shrink-wrap step. With the addition of the two hundred count product, the system is no longer stable. The queue at the ruling machine becomes larger and larger over time, and lots spend longer and longer in the system. To regain stability, we have added an additional ruling machine. In our paper4 model, we assumed that 100count lots arrived at the rate of twelve hundred sheets per day, or twelve lots per day. Suppose the 200-count lots arrive at a rate of eighteen hundred sheets per day, or nine lots per day. The Excel model for this example is paper5.xls. This model is an extension of paper4.xls, with changes to the products, tools, and operators worksheets. The products worksheet has been modified to include a second product. Since this additional product (200-count) has nearly the same process as the original product (100-count), the products worksheet can specify that the same process sheet is used for both products. The products 88 Factory Explorer Copyright WWK 1995-2009
5.5. Multiple Products worksheet is shown in Figure 5-9. The only change to the tools worksheet is that the quantity of ruling machines has been increased.
Figure 5-9: Products worksheet, paper5 model. A second product has been added to the model. Both products have nearly the same process, so they can each specify Filler.Process as the worksheet containing process steps.
The process flow worksheet is displayed in Figure 5-10. One hundred count filler paper takes less time to shrink-wrap than does two hundred count filler paper. To model this fact, the process flow includes two separate shrink-wrap steps. The first step, Wrapit.100, is active only for the one hundred count product. The second step, Wrap-it, is inactive only for the one hundred count product. This convention is used so that if more products are added to the model, they will by default use the Wrap-it step, and receive the longer processing time.
Factory Explorer 89
Figure 5-10 Process flow worksheet, paper5 model. The 100Count product requires less time to shrink-wrap than other products. That fact is modeled here using the ACTIVE and INACTIVE columns
5.6 Priority Dispatch Rules and Default Priorities

Up to this point, we have not explicitly specified the dispatch rule used when picking lots from the queue for processing. By default, a first-in-first-out rule (FIFO) is in force. This means that in most cases, lots that have been waiting the longest for service at a tool group are served first when a tool at that tool group becomes available. We say most cases because the mechanics of batch formation at batch tools can cause situations where a late-arriving lot can bypass earlier lots by becoming part of a batch. Also, in certain cases when operators are necessary for service at a tool, a lot that cannot be serviced because there is no appropriate operator will be bypassed in favor of a lot that can be processed immediately. Several priority-based dispatch rules are implemented in Factory Explorer. For example, under priority-FIFO, service at a tool is based first on a lot's priority. If two lots of equal priority are waiting for service, the first lot to arrive receives preference. Factory Explorer uses the convention that smaller numbers identify more urgent priorities. Thus, a lot having priority 1 is more urgent than a lot having priority 2, and the priority 1 lot will receive service first at tool groups using priority-based dispatch rules. For a complete list of dispatch rules, see Section 4.6.
90 Factory Explorer
5.6. Priority Dispatch Rules and Default Priorities Lot priorities can be specified in two ways. On the product specification line in the configuration file, a default priority is specified for all lots of that product. Also, after each process step a lot's priority can be adjusted up or down. See Section 5.7 for a description of priority adjustments at the process step level. We expand the example paper5 to include default priorities and to use the priority-FIFO dispatch rule. We'll call this new model paper6. The Excel model for this example is paper6.xls. Suppose that 100-count filler paper is stocked in much higher finished quantities than 200-count filler paper. In that case, we might wish to give priority to 200-count filler paper when it arrives, so as to expedite its completion date, and minimize stockouts or backorders. This model is an extension of paper5.xls, with changes to the products and tools worksheets. The products worksheet has been modified to change the default priority for 100-count filler to be worse than that for 200-count filler (10 is worse than 1), and is displayed in Figure 5-11. The tools worksheet has been modified to specify that the dispatch rule at each tool group is priority-FIFO, and is shown in Figure 5-12.
Figure 5-11: Products worksheet, paper6 model. The default priority for 100Count has been changed to be worse than that for 200Count.
Factory Explorer 91
Figure 5-12: Tools worksheet, paper6 model. The priority-FIFO dispatch rule has been specified for each tool group.
5.7 Adjusting Lot Priorities

In this section we describe how to adjust lot priorities dynamically. Recall that default priorities for all lots are specified with the product information. The statements we describe here are specified at the process step level, and take effect after individual lots have completed processing at a given step. The PrAdjust statement adjusts a lot's priority up or down, the PrSet statement sets a lot's priority to a specific value, and the PrDefault statement resets a lot's priority to its default value. For an example of the use of PrAdjust and PrDefault, consider the case of rework lots. Once rework occurs, the units that must be reworked (the rework children) are split off from the original lot (the parent lot), and follow the rework sequence. Only when the rework units complete the rework sequence and successfully pass the original step where rework occurred are they reunited with the parent lot. To speed this process, we use the PrAdjust option to adjust the rework children's priority so they are processed before other non-rework lots. Once the rework children are reunited with the parent lot, we use the PrDefault statement to reset priorities back to default levels. The Excel model for this example is paper7.xls. This model is an extension of paper6.xls, with changes to the process worksheet. The process worksheet has been modified to specify the priority changes described above, and the relevant columns are displayed in Figure 5-13.
92 Factory Explorer
5.8. Setups
Figure 5-13: Process sheet, paper7 model. Rework lots are given a boost in priority so that they will be processed before non-rework lots. Once rework children are reunited with their parents, their priority is returned to its default value.
Although we do not demonstrate its use in an example, use the PrSet statement to set a lot's priority to a specific value. The PrAdjust statement is more useful in this example because the two products have different default priorities. We can use PrAdjust to make any rework child's priority better while still maintaining the relative priority of 200-count filler paper.
5.8 Setups
5.8.1 Introduction Setups are used to model delays that do not occur for every lot. Typically, setups are required when different types of operations can be performed on a machine, but in order to change types the machine must be reconfigured in some fashion (set up to perform the new operation). Lots arriving for processing at a machine that is already set up for them do not incur setup delays, while those requiring a different type of processing must wait while the machine is reconfigured. Factory Explorer includes the capability to model sequence-dependent setups. Consider setups at a single tool group. To model setups, Factory Explorer needs to know about setup groups, I.D.'s, times, and operators. A setup group can be thought of as a control knob on a machine. At any given time, this knob can only be pointing to one Copyright WWK 1995-2009 Factory Explorer 93
5. User's Guide: Enriching The Basic Model particular position (e.g. A, B, or C). Setup I.D.'s represent the different positions on the knob. One type of processing may require the knob to be set to position A, while another type may require the knob to be set to position B. If the knob is set to the wrong position, it must be changed (the machine must be setup) before processing can take place. Multiple setup groups at a tool correspond to multiple knobs. Setup times correspond to the time it takes to change the setting of a particular knob. A setup can be sequenceindependent or sequence-dependent. A setup is sequence-dependent if the time it takes to switch to a new position on the knob depends on the old setting for the knob (for example, if it takes longer to switch the knob from position A to position C than to switch from B to C). Otherwise, the setup is sequence-independent. Factory Explorer can model either type of setup, along with any number of setup groups. The (optional) setup operator specifies a designated operator group that is required to perform the setup. 5.8.2 Setups and Dispatch Rules All of the dispatch rules described in Section 4.6 disregard setup times when figuring out the next lot to be served. In a factory with significant setup times, it often makes sense to use a dispatch rule that tries to avoid incurring setups. Factory Explorer provides one way to model this behavior with the AVOIDSETUPS column (Excel models) or the AvoidSetups statement (ASCII models). Setup-avoidance is specified at the tool group level. When enabled for a tool group, setup-avoidance modifies the way dispatching is performed. This modification works two different ways, depending on whether the dispatch rule specified for the tool group has as its primary rule a priority-based approach or not. For tool groups with a priority-based dispatch rule (e.g. priority-FIFO, or prioritycritical ratio), the dispatcher first finds the highest priority class of lots waiting for service among which there is at least one lot ready to run. Note that some classes of lots, even though they have high priority, may not contain any lots that are ready to run since the appropriate operator may not be available. Within this highest priority class with ready lots, the dispatcher chooses the lot that minimizes setup time. If more than one lot minimizes setup, the lots are ordered by the rest of their nominal dispatch rule (e.g. FIFO or critical ratio), and the first lot is selected. For batch tools, other lots are then chosen to fill the batch if possible. For tool groups with a non-priority-based dispatch rule, the dispatcher finds all lots that would provide the minimal setup time. Within this set of lots, the dispatcher orders the lots by the normal dispatch rule for the tool group, and picks the first one. At batch tools, other lots are again chosen to fill the batch if possible. Setup-avoidance behavior is modified with the MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY columns (Excel models) or the MinQueue, MinDelay, MaxQueue and MaxDelay statements (ASCII models). These attributes are specified at the tool group level for individual setup I.D.'s. MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY may be used to specify trigger points for queue length and queue delay, respectively. When these trigger points are reached, setup-avoidance is still the goal. Lots that have been waiting in queue less than MINDELAY hours, or lots that are waiting for a setup I.D. that has less than MINQUEUE units in queue, will not be
94 Factory Explorer
5.8. Setups eligible for processing if a non-zero setup time is required. Lots that have been waiting in queue for more than MAXDELAY hours, or lots that are waiting for a setup I.D. that has more than MAXQUEUE units in queue, are eligible for immediate processing, even if it creates an extra setup, and even if these lots do not satisfy MINQUEUE / MINDELAY constraints. MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY are useful because sometimes setup-avoidance can lead to very long queues of particular setup I.D.'s. In general, specifying MINQUEUE, MINDELAY, MAXQUEUE or MAXDELAY will result in an increased Setup%, but may limit the maximum queue delay experienced by lots with particular setup I.D.'s. One or all of MINQUEUE, MINDELAY, MAXQUEUE and MAXDELAY may be specified for each setup I.D. Finally, the lots available for processing when setup-avoidance is enabled may be restricted via the MINTOOLS and MAXTOOLS columns (Excel models) or the MinToolsSetup and MaxToolsSetup statements (ASCII models). These attributes are specified at the tool group level for individual setup I.D.'s, and determine the minimum and maximum number of tools to be setup for each I.D. Setup-avoidance is still the goal, but only lots that can be setup / run without violating a minimum or maximum tool limit are eligible for processing. In general, specifying MINTOOLS is a way of dedicating a minimum number of tools to a particular setup I.D., while specifying MAXTOOLS is a way to limit the number of tools that can be simultaneously setup for a particular setup I.D. Depending on the situation, specifying MINTOOLS or MAXTOOLS can result in either an increase or decrease in Setup%. One of both of MINTOOLS and MAXTOOLS may be specified for each setup I.D. Most MINTOOLS, MAXTOOLS, MAXQUEUE, and MAXDELAY combination are valid for each setup I.D. During model validation, Factory Explorer checks that MINTOOLS < MAXTOOLS, MINQUEUE < MAXQUEUE, MINDELAY < MAXDELAY. MAXDELAY must be specified if MINQUEUE is specified. None of these options, however, may be specified for a tool group unless AVOIDSETUPS is also enabled for the tool group. 5.8.3 Setup Example Returning to our paper model, suppose the punch machine has a valve that controls the pressure applied when punching holes in filler paper. The pressure required to punch 100count lots is much lower than that required to punch 200-count lots. If the operator wants to start a lot and the valve is not set to the correct pressure, they must first adjust the pressure before starting the lot. In this example, there would be a single setup group, which we will call Pressure. Within the setup group there are two possible setup I.D.'s, one corresponding to each product. We will assume that if the pressure is wrong, it takes approximately fifteen minutes to adjust it to the correct level. This is an example of a sequence-independent setup. If the time to change the pressure level depended on the current setting, that would be a sequence-dependent setup. Factory Explorer can model both sequence-independent and sequence-dependent setups. We assume that the operator will try to minimize setup time by scanning the list of waiting lots and picking out those that can be processed on the tool without incurring a setup. If no such lots exist, the operator will then set up the
Factory Explorer 95
5. User's Guide: Enriching The Basic Model machine for the type of lot that is waiting. In order for such setup-minimization to be effective, we must allow the operator to pick freely among the different products waiting in queue (i.e. the two products must have equal priority). The Excel model for this example is paper8.xls. This model is an extension of the paper7.xls model, with changes to the products, tools, and process sheets. First, the products sheet must be changed to indicate that both products have equal priority. Otherwise, setup minimization will not have a large effect, since a setup will be introduced every time a high priority product arrives to the punch machine. Second, the system with setups is now unstable due to lack of operators, so we have added a second filler group operator. These are both minor changes, so we will not show the revised worksheets here. Next, the tools worksheet must be modified to include the setup group, I.D., and time information. The AVOIDSETUPS column is also marked, indicating that a setupavoidance strategy is in place. The setup columns of the tools worksheet are shown in Figure 5-14. Since we are creating a single setup I.D. for each product, we can use the %Product wildcard. This wildcard tells Factory Explorer to scan the list of products using the punch tool and create a unique setup I.D. for each one. Then, at the process step level we can again specify the setup I.D. using a wildcard, and Factory Explorer will substitute the correct setup I.D. If we did not use setup I.D.'s, we would be forced to create separate process flows for each product, and then specify unique setup I.D.'s for the punch step in each process flow.
96 Factory Explorer
5.8. Setups
Figure 5-14: Tools worksheet, paper8 model. The punch machine now contains entries for a single setup group with one setup I.D. for each product.
Finally, the process sheet must specify the appropriate setup group and I.D. at the punch step. Relevant columns of the process sheet are shown in Figure 5-15.
Factory Explorer 97
Figure 5-15: Process worksheet, paper8 model. The Punch-It step has been modified to specify that a setup occurs if the setup group Pressure' is not currently set to the correct setup I.D. (the product's name is used as the setup I.D.).
5.8.4 Notes on Wildcards and Setup I.D. Names As shown in the previous example, including wildcards in setup I.D. names can greatly simplify a model. Using the %Product wildcard to model product-dependent setups allows a model to specify a single process flow for multiple products. Setup I.D. names can include any combination of %Product, %Process, %Operation, and %Step wildcards. In general, the use of wildcards does not increase the modeling capabilities of Factory Explorer. In other words, any model that can be built using wildcards can also be built without using wildcards. However, the use of wildcards can dramatically lower the amount of data that must be entered into a model. For example, suppose a particular tool is used in many different process steps. If each step requires a unique setup that has approximately the same length for all steps, use the %Step wildcard as a shorthand way of generating a unique setup I.D. for each process step using the tool. If a setup is required whenever the process changes, use the %Process wildcard. If a setup is required whenever the operation I.D. changes, use the %Operation wildcard. Wildcards may be combined with each other and with arbitrary text in a setup I.D. name. For example, suppose a setup is required whenever the process or process step changes at a tool, but there are two different lengths of setups, depending on the particular process step in question. In this case, define two setup I.D.'s such as 98 Factory Explorer Copyright WWK 1995-2009
5.8. Setups %Process%Step.type1 and %Process%Step.type2 at the tool level. Then, at the process step level enter the appropriate setup I.D.
Factory Explorer 99
6. User's Guide: Running the Model
6.1 Introduction
This chapter describes how to run Factory Explorer to analyze your model. Section 6.2 gives basic instructions for making a model run. Section 6.3 describes the information required for every model run. Section 6.4 describes the methods used to specify run-time options on different platforms. Section 6.5 describes Factory Explorer's model validation process. Section 6.6 describes Factory Explorer's output console. Section 6.7 describes Factory Explorer's exit code file. See Chapter 13 for a complete list of run-time options.
6.2 Basic Instructions

Suppose that we wish to make a six month run of the paper.xls model described earlier. The steps required to run a model vary depending on the platform. Running a Model To perform a capacity analysis and simulation run of the model paper.xls, choose Run Factory Explorer from the FactoryX pull-down menu. Choose from the drop-down list of recently specified models, or click on the Model button to open the Select a Model dialog. By default, the Select a Model dialog first lists Excel workbooks (.xls extension). However, you may also select from a list of ASCII models (.fx2 extension), Testbed models (.vr extension), and ManSim models (.prd extension). To change the type of models listed, choose from the Files of Type drop-down list on the Select a Model dialog. After selecting a model name on the Select a Model dialog, choose OK or Open (the exact button label depends on the version of Excel in use). Factory Explorer automatically detects the model type based on the model name extension. Once the model name has been entered, enable both capacity and simulation in the selection list. The run-length unit of measure is displayed alongside the entry, and defaults at system installation to Quarters. Enter a simulation run length (say 6 months), and click on the Run button. A Factory Explorer output console should appear. Diagnostic messages will appear on the output console as the run proceeds. If Factory Explorer exits without a problem, the console should beep once. If there is an error, it
Factory Explorer 101
6. User's Guide: Running the Model should beep twice. Output reports for the run are contained in the file paper.run. From the FactoryX pull-down menu, select the Analyze Output item. Options on the resulting dialog allow you to browse the output reports, as well as generate output charts and worksheets. Click on the Help button on the Analyze Output dialog for more detailed instructions. You may also use a text editor to directly view paper.run. If you have a large list of runs you wish to make, consider storing the Factory Explorer commands for these runs in a worksheet (from the Run Factory Explorer dialog, click on Store to store the command in a worksheet cell). Once you have a list of run-time commands, you can have Factory Explorer execute them as a batch. To do so, choose Batch Execution from the FactoryX pull-down menu. On the resulting dialog, highlight your list of run commands and choose Run. Factory Explorer will execute each run, one after another, until it reaches the end of the list or an error is encountered in one of the models. Note that if you are making multiple runs of the same model, you will probably want to use OutBase to specify different output files for each run. Otherwise, the output from later runs will overwrite that from earlier runs. If you forget to use OutBase, and Factory Explorer detects that later runs will overwrite the output from earlier runs, it will warn you of the situation. You can specify OutBase on the Run Factory Explorer dialog. On Windows platforms, you may also execute Factory Explorer directly from the command line (MS-DOS) interface, as described for platforms without Excel below. If you are running a model that is not stored in the directory where Factory Explorer is installed, you must include the installation directory in your path. Paths are normally set in your autoexec.bat file in the root directory of your C: drive.
6.3 Required Run-Time Information

Factory Explorer requires at a minimum the model name. In our example given above, the base model name is paper. No identifying extension is provided, so Factory Explorer assumes the model is in ASCII format, and reads model data from the file paper.fx2. If the model name includes an identifying extension, Factory Explorer attempts to automatically translate the model from the specified format to an ASCII model. Factory Explorer then reads the ASCII model and performs the analysis run. To perform capacity analysis on a model, enable DoCap. To perform cost analysis, enable DoCap and DoCost. To perform simulation analysis, enable DoSim. To perform scheduling analysis, enable DoSim and DoSched. For simulation analysis, the length of the analysis must be specified using RunLen time. If RunLenUM is not specified, time is in hours. In the Factory Explorer Excel interface, DoCap, DoCost, DoSim, RunLen, and RunLenUM are specified on the Run Factory Explorer dialog. To see if a model is formatted properly, you can run Factory Explorer without performing capacity analysis or simulation. In this case, Factory Explorer simply loads the model, performs sanity checks on the input (such as ensuring that tool groups and operator groups referred to by process steps are defined, etc.), and reports any errors. In addition, you can translate models from ASCII format to Excel format without performing capacity analysis or simulation. If you enable WriteExcel, the model will be written out in a form that the user interface can read and translate into an Excel model.
102 Factory Explorer
6.4. Specifying Factory Explorer Run-Time Options An analysis run may include multiple types of analysis: capacity analysis, cost analysis, simulation analysis, and scheduling analysis. Capacity analysis is a fast way to get rough-cut capacity answers without waiting for a detailed simulation. Simulation is useful when estimating dynamic performance measures such as cycle time and work-inprocess levels. Usually, capacity analysis takes such a small amount of time compared to simulation that it does not hurt to include capacity analysis when performing any simulation analysis. Also, many output reports and charts provide comparisons between capacity analysis and simulation results, so it is helpful if you are doing simulation to go ahead and run capacity analysis as well. That way, capacity analysis answers can serve as a validity check on your simulation results.
6.4 Specifying Factory Explorer Run-Time Options

In addition to the base model name, there are a number of Factory Explorer options that can be used to customize a model run. The method for specifying these options varies, however, depending on the platform. See Chapter 13 for a complete list of run-time options. Specifying Run-Time Options: Commonly used options can be specified directly from the Run Factory Explorer dialog box. Others are accessed via the various option buttons displayed across the bottom of the Run Factory Explorer dialog box. For example, to specify that the release rate be adjusted to 75% of system capacity, select the Lot Release button. From the Lot Release dialog, select the checkbox for option Set release rate as % of approximate max, and fill in the corresponding edit box with 75. Before each model run, Factory Explorer builds a complete options list and writes it to the options file fx.opt. This file is stored in the temporary directory specified on the System Parameters dialog, and is read by the analysis engines. You may also run Factory Explorer from the command line (MS-DOS) interface. In that case, you can specify options directly on the command line. Remember that if you are running a model that is not stored in the directory where Factory Explorer is installed, you must include the installation directory in your path. Options may be specified directly on the command line or read from an options file. For example, to make the model run described above, but to specify that the input rate be adjusted to 75% of system capacity, use the command fx paper DoCap DoSim RunLen 6 RunLenUM Months ReleasePct 75 If you are specifying an option argument that contains spaces, you can include the argument in single or double quotes. For example, to add a descriptive label to the output file, you can use the command: fx paper DoCap DoSim RunLen 6 RunLenUM Months ReleasePct 75 Label 'run at 75% of max' or the command
6. User's Guide: Running the Model fx paper DoCap DoSim RunLen 6 RunLenUM Months ReleasePct 75 Label "run at 75% of max" Specifying Run-Time Options in an Options File: Options may also be stored in an options file (a regular text file), which is specified on the command line. In our example, suppose the file options.txt contains the text paper DoCap DoSim RunLen 6 RunLenUM Months ReleasePct 75. The following command will run Factory Explorer and specify that it should read all options from the file options.txt: fx @options.txt An options file can have a free-flow format -- all white space between options is ignored by Factory Explorer, including the presence of carriage returns or linefeeds. As with options specified on the command line, use a pair of single or double quotes to enclose an argument that contains spaces (e.g. when you are using the Label option). An options file may contain commands for multiple runs -- simply separate the options for different runs with semicolons ;. An options file is useful for automating a long series of analysis runs, especially on platforms without Excel. Using a text editor's cut-and-paste facility, it is possible to quickly define a list of runs, and then have Factory Explorer execute these runs in sequence without human intervention.
6.5 Model Validation

After reading in a model, Factory Explorer performs extensive model validation checks. Some of these checks are very simple, such as checking to see that tool group names used in process flows are actually defined in the model. Other checks are more sophisticated, such as checking for deadlock loops in models with hold-tool regions. In all cases, whenever Factory Explorer finds an error, it generates an error message on the output console. These messages are as specific as possible, so as to ease the process of tracking down and fixing the problem. Model validation is particularly complex for models containing effective dates. Whenever Factory Explorer detects that a model contains effective dates, it performs a complete set of model validation checks for startup and for every discrete effective date found in the model. This means that Factory Explorer performs model validation not only during the period when analysis is performed (say from the date specified with StartDate to the end of the replication), but for all dates when the model changes, and for the model effective at startup. Whenever possible, when Factory Explorer detects an error in models with effective dates, it prints not only the error message but also the effective date at which the error occurs. It is important to understand how model validation works in models with effective dates, as the results can sometimes be confusing. For example, suppose the first definition of a particular tool group has an effective date. When this occurs, Factory Explorer creates an artificial input record for the tool group that is effective at model startup. Factory Explorer does not assume any information about this artificial tool group record.
6.6. Factory Explorer Output Console Suppose also that a process step is listed in the model that uses this tool group, that this process step specifies setup, and that this process step does not specify an effective date. To Factory Explorer, this situation is a model validation error the process step is effective at model startup, and Factory Explorer expects there to be a corresponding tool group effective at model startup with appropriate setup information defined at the tool group level.
6.6 Factory Explorer Output Console

During any model run or model conversion, Factory Explorer writes informational messages to the output console. The output console is a separate window created by Factory Explorer. Factory Explorer also echoes any output console messages to the output console file fx.con. This file is stored in the temporary directory specified on the System Parameters dialog, and may be viewed from the Analyze Output dialog. The output console file is useful for viewing diagnostic messages that otherwise might have scrolled off the screen. The console file can also come in handy when making a long sequence of runs (with the batch execution dialog in the user interface, or with an options file). After the runs have been completed, you can review the console output to determine how long each run took, without having to open individual output files.
6.7 Factory Explorer Exit Code File

When Factory Explorer exits, it writes a final numeric exit code to the file fx.xcd. This code is zero if no errors occurred. Otherwise, the code is nonzero. Exit codes and their meaning are listed in Table 6-1. The exit code file is stored in the temporary directory specified on the System Parameters dialog. This file is useful when other applications execute Factory Explorer synchronously and the calling application needs to know when Factory Explorer has finished and whether or not any errors occurred. Upon startup, Factory Explorer immediately deletes the exit code file, if it exists. Only when the run is finished does Factory Explorer recreate the file. Thus, if a calling application wishes to know when Factory Explorer has finished, it may itself delete the exit code file before calling Factory Explorer and then wait for the file's reappearance to signal Factory Explorer's exit. The only instance where this method will fail is if Factory Explorer experiences an abnormal exit (a true crash), which should be quite rare.
Table 6-1: Factory Explorer Exit Codes
Exit Code 0 -2200
-2210
Meaning No errors occurred. The model could not be simulated because one or more resources (tool groups or operator groups) were overloaded, and Unstable was not enabled. An error was returned from the operating system when Factory Explorer asked for memory. This error sometimes occurs when an unstable simulation run causes Factory Explorer to need ever-increasing amounts of memory. If this error occurs on a Windows platform, try increasing the
6. User's Guide: Running the Model amount of virtual memory. An error occurred when reading or validating the model. No HASP security key was found.
-2220 -2230
7. User's Guide: Analyzing Output
7.1 Introduction
At the completion of a model run, Factory Explorer can generate a variety of pre-defined outputs, including Excel worksheets, Excel charts, and text reports. In addition, Factory Explorer's custom chart wizard can create a variety of custom Excel charts with very little work. Depending on the options enabled for the run, not all types of output will be available. This chapter describes available outputs, along with any relevant options. For a model with base name modelname, Factory Explorer normally writes output data for charts and worksheets to the results data file modelname.rdf. Factory Explorer writes text reports to the file modelname.run. If the OutBase basename option is selected, Factory Explorer writes to basename.rdf and basename.run. Records in the results data file are in a comma-separated (CSV) format. The exact format is documented in Chapter 14. Factory Explorer normally generates output results at the end of each analysis period, at the end of each analysis replication, and at the end of each analysis run. If NoPeriodOutput is enabled, end-of-period output data is suppressed. If NoRepOutput is enabled, end-of-replication output data is suppressed. For output charts, Factory Explorer places the output data used in the chart in a data worksheet stored directly before the chart worksheet. Factory Explorer adds an Excel AutoFilter to this chart data. The AutoFilter is useful for manipulating the selection of data displayed in the chart. Search the Excel on-line help for more information on AutoFilters. Factory Explorer performs capacity analysis on a model if DoCap is enabled, cost analysis if DoCost is enabled, simulation analysis if DoSim is enabled, and scheduling analysis if DoSched is enabled. In general, if a particular type of analysis is not performed, outputs for that analysis will be listed as zero, or will not be produced. Data reported by analysis period is not affected by the setting of ClearStats. Unless otherwise specified, all end-of-replication outputs are based on data gathered after the ClearStats time. Copyright WWK 1995-2009 Factory Explorer 107
7. User's Guide: Analyzing Output Section 7.2 describes Factory Explorer's pre-defined output worksheets. Section 7.3 covers pre-defined output charts. Section 7.4 describes the custom chart wizard. Section 7.5 lists pre-defined output reports.
7.2 Output Worksheets

7.2.1 Introduction To access Factory Explorer's pre-defined output worksheets, select Analyze Output from the FactoryX pull-down menu. The resulting dialog displays a list of pre-defined output worksheet and charts. Select one or more outputs from this list and click on Create Selected Outputs. Factory Explorer beeps once when all selected outputs have been created. 7.2.2 Analysis Run Details Worksheet This worksheet displays miscellaneous run information such as memory usage, simulation speed, random number usage, memory usage, and the Factory Explorer runtime command. This worksheet is not available if NoPeriodOutput is enabled. Output Columns Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Time Completed: Wall-clock (real world) time when all analyses for the period were completed. Lot Moves Per Minute: If simulation enabled, the average number of lot moves per minute of wall-clock time. A lot move is registered whenever a lot finishes processing at a process step and moves to the next process step. Lot moves per minute is a measure of simulation engine speed. First Stream: First random number stream used during analysis. See Section 23.1 of the manual for more information. Last Stream: Last random number stream used during analysis. See Section 23.1 of the manual for more information. Random Numbers Used So Far: Total quantity of random numbers generated cumulatively during the entire analysis run. Max Memory (Kbytes): Peak memory usage so far during the entire analysis run. Current Memory (Kbytes): Current memory usage. Memory Allocs: Cumulative number of calls to operating system to obtain a block of memory.
7.2. Output Worksheets Memory ReAllocs: Cumulative number of calls to operating system to resize a previously obtained block of memory. Memory Frees: Cumulative number of calls to operating system to release a previously obtained block of memory. Run Command: The run-time command executed to start the analysis run. 7.2.3 Factory Summary Worksheet This worksheet summarizes factory and product-level performance measures. Simulation-based performance measures will be zero unless DoSim is enabled. Capacity-analysis-based performance measures will be zero unless DoCap is enabled. Cost-analysis-based performance measures will be zero unless DoCost is enabled. By default, this worksheet displays product summary data. Click on the "+" button to the left of a product summary row to view details for individual products. Or, click on the "1" or "2" buttons in the upper left-hand corner of the worksheet to display different levels of detail for the entire worksheet (click "1" for product summary data, "2" for individual product data). Notes For models with effective dates, even if the model does not change, some outputs may change from period to period simply due to differences in period length. For example, if the analysis period length is quarters, the number of days in each quarter will be slightly different. Thus, the factory gross margin, or other outputs, may vary from period to period due to varying period lengths, not due to changes in the model. Use OutRateUM to control the unit of measure shown on this worksheet for release, throughput, and exit rates. Use OutCTUM to control the unit of measure for cycle time estimates. Summary records across all periods in a replication are generated at the end of each replication. Summary records for the entire run are not generated unless multiple replications are enabled with Reps. These records are also not generated if AddPct, AddRate, or AddSuggPct are enabled, as the statistics would be meaningless. Records are summarized across periods in the manner that makes the most sense for that type of data. For example, the summary across all periods of Gross Margin is the total, while the summary for Average Cycle Time is a weighted average. More detail is given in the field descriptions below. Fields Rep: Replication number, or "Summary" for replication-summary rows. Pd: Analysis period, or "All" for period-summary rows. Period Start Date. Period End Date. Product: Product name, or "Summary" for product-summary rows.
7. User's Guide: Analyzing Output Gross Margin: Predicted factory revenue minus factory operating expenses. Only defined for product-summary rows. See Chapter 21 for the details of margin, revenue, expense, and cost calculations. Revenue: Predicted factory throughput multiplied by revenue per good unit out, summed across all products. Only defined for product-summary rows. Raw Unit Expense: Predicted release rate multiplied by cost per raw unit released, summed across all products. Only defined for product-summary rows. S C Expense: Predicted supplies and consumables expense, defined as predicted throughput rate for each process step, multiplied by process step per-unit supplies and consumables cost, summed across all process steps and products. Only defined for product-summary rows. Process Overhead Expense: Predicted process overhead expense, defined as predicted throughput rate for each process step, multiplied by process step per-unit overhead, summed across all process steps and products. Only defined for product-summary rows. Direct Material Expense: Predicted direct material expense, defined as predicted throughput rate for each process step, multiplied by process step per-unit direct material cost, summed across all process steps and products. Only defined for product-summary rows. Factory Dep. Expense: Predicted factory depreciation expense, summed across all factory fixed costs. Only defined for product-summary rows. Factory Rec. Expense: Predicted factory recurring expense, summed across all factory recurring costs. Only defined for product-summary rows. Tool Dep. Expense: Predicted tool depreciation expense, summed across all tool groups. Only defined for product-summary rows. Tool Rec. Expense: Predicted tool recurring expense, summed across all tool groups. Only defined for product-summary rows. Operator Wage Expense: Predicted operator wages, summed across all operator groups. Only defined for product-summary rows. Operator Overhead Expense: Predicted overhead, summed across all operator groups. Only defined for product-summary rows. Operating Expense: Sum of raw unit expense, supplies and consumable expense, process overhead expense, direct material expense, factory depreciation expense, factory recurring expense, tool depreciation expense, tool recurring expense, operator wage expense and operator overhead expense. Total Fixed Cost: Sum of total tool fixed cost plus total factory fixed cost. Where total tool fixed cost is the sum of tool fixed cost times number of tools for all tool groups and total factory fixed cost is the sum of all factory fixed cost. Sugg Capacity Loading: Factory suggested capacity loading, controlled by SuggLoading.
7.2. Output Worksheets Factory Capacity Loading: Predicted factory capacity loading, which is defined as the capacity loading of the bottleneck resource group (tool group or operator group). Capacity loading for a resource group is the resource group's total input rate divided by the resource group's current actual maximum processing rate. Cost Per Good Unit Out: Predicted cost per good unit out. For product-summary rows, cost per good unit out is a weighted average of product cost per good unit out by unit exit rate. For replication-summary rows, the individual product cost per good unit out is a weighted average across all periods by period length times throughput rate. For replication-summary / product-summary rows, cost per good unit out is a weighted average across all products by exit rate. See Section 21.2 of the manual for the details of product cost calculations. Release Rate: Predicted unit release rate. For product-summary rows, unit release rate is a sum across all products. Input Rate: Predicted unit input rate. For release products, input rate is equal to release rate. For transformed or assembled products, input rate is the start rate of transformed or assembled units. Line Yield: Predicted unit throughput rate divided by predicted unit input rate. Tput Rate: Predicted unit throughput rate. Required Tput Rate: Predicted required unit throughput rate, based on throughput requirements for downstream products. If product is not a sub-assembly or subtransform product, required throughput rate is zero. Throughput Rate Mismatch: Throughput rate minus required throughput rate. Exit Rate: Predicted unit exit rate. For sub-assembly and sub-transform products, units do not actually exit the factory, and so unit exit rate is zero. For all other products, unit exit rate is equal to throughput rate. Max Input Rate: Predicted maximum unit input rate. Equal to input rate divided by factory capacity loading (since input rate divided by max input rate is equal to factory capacity loading). Max Tput Rate: Predicted maximum unit throughput rate. Equal to throughput rate divided by factory capacity loading. Lots Started: Simulated lots started. For product-summary rows, lots started is a sum across all products. Lots started includes release lots, transform lots, assembly lots, and individual lots (but not individual lots that are rework or split-lot children). Units Started: Simulated units started. Defined identically to Lots Started. Lots Finished: Simulated lots finished (lots that successfully complete the process flow). For product-summary rows, lots finished is a sum across all products. Lots finished includes release lots, transform lots, assembly lots, and individual lots. Units Finished: Simulated units finished. Defined identically to Lots Finished.
7. User's Guide: Analyzing Output Avg CT Lower Bound: Lower bound of confidence interval for simulation average cycle time. Confidence interval precision is controlled with CILevel (the default is 95% confidence intervals). Remember that the confidence interval for mean cycle time states If all statistical assumptions have been met, and you make a large number of model runs using this same procedure, the true mean cycle time should fall within the confidence interval generated by about 95% of these runs. The mean cycle time confidence interval does not imply that 95% of actual cycle times will fall within the upper and lower bounds. Confidence intervals are only given for replication-level outputs. Cycle time confidence interval only defined for replication-summary rows for individual products. Avg CT Upper Bound: Upper bound of confidence interval for simulation average cycle time. Average Cycle Time: Simulation average cycle time for finished lots. For productsummary rows, average cycle time is a weighted average by number of lots finished across all products. Raw Process Time: Predicted raw process time. Raw process time is the time a lot would take to complete the process flow assuming no scrap, rework, downtime, setups. Does not include step-to-step travel time. Raw process time is based on a lot with an average number of units, unless OneUnitRPT is enabled, in which case it is based on a lot with a single unit. For product-summary rows, raw process time is a weighted average by unit throughput rate across all products. Cycle Time over RPT: Cycle time divided by raw process time. Tardy Lots: Simulated tardy lots. A tardy lot is one that finishes after its due date / time. Only lots with due dates can be tardy. If a lot has no due date, it is never counted as being tardy, no matter when it finishes. For product-summary rows, tardy lots is a sum across all products. Non Tardy Lots: Simulated non-tardy lots. Lots finished is equal to tardy lots plus non-tardy lots. For product-summary rows, non-tardy lots is a sum across all products. Pct Tardy Lots: Percent tardy lots, defined as tardy lots divided by lots finished, multiplied by 100%. Pct Non Tardy Lots: Percent non-tardy lots, defined as non-tardy lots divided by lots finished, multiplied by 100%. Avg Time Tardy for Tardy Lots: Average time tardy for tardy lots. For tardy lots, time tardy is the actual finish date / time minus the due date / time. For productsummary rows, average time tardy for tardy lots is a weighted average by number of tardy lots across all products. Avg CT Tardy Lots: Average cycle time for tardy lots. For product-summary rows, average cycle time for tardy lots is a weighted average by number of tardy lots across all products.
7.2. Output Worksheets Avg CT Non Tardy Lots: Average cycle time for non-tardy lots. For productsummary rows, average cycle time for non-tardy lots is a weighted average by number of non-tardy lots across all products. CT Var Lower Bound: Lower bound of confidence interval for simulation cycle time variance. Confidence interval precision is controlled with CILevel (the default is 95% confidence intervals). Variance confidence interval only defined for replication-summary rows for individual products. CT Var Upper Bound: Upper bound of confidence interval for simulation cycle time variance. Cycle Time Variance: Simulation cycle time variance for finished lots. For productsummary rows, cycle time variance is a weighted average by number of lots finished across all products. Cycle Time Upper Percentile: Simulation cycle time upper percentile. The upper percentile level for cycle times is controlled with Percentile (the default is 95th percentiles). This statistic reports the approximate value below which 95% of all cycle times fell. Max Cycle Time: Simulation maximum cycle time for finished lots. Average Unit WIP: Simulation average unit work-in-process. A unit is defined as being work-in-process from the time it starts its process flow to the time it finishes the process flow or is scrapped. Average WIP is a time-average, e.g. if WIP is 10 units for 1 hour, and 5 units for 3 hours, average WIP is (10*1+5*3)/4 = 6.25 units. For product-summary rows, average unit WIP is a time-average of all factory unit WIP, not a weighted average of unit WIP for individual products. Raw Unit Cost: Product raw unit cost. For release products, raw unit cost is defined in the input model. For transformed or assembled products, raw unit cost is calculated based on the cost per good unit out of sub-transform or sub-assembly products. For product-summary rows, raw unit cost is a weighted average by predicted unit throughput rate across all products. Average WIP Raw Cost Value: Simulated average work-in-process raw cost value, defined as average unit WIP multiplied by raw unit cost. Max Unit WIP: Maximum number of units in the system. Bias Test Statistic: Test statistic for initialization bias test. See Section 23.5 of the manual for more information on the initialization bias test. Bias tests are only performed for individual products, and only for replication-summary rows. Degrees of Freedom: Degrees of freedom for initialization bias test. Bias Test P Value: P-value for initialization bias test. P-values below 0.10 are evidence of statistically significant differences between batch cycle time means across the replication, i.e. initialization bias is likely. For the product summary level, the line yield, average cycle time, raw process time, cycle time over RPT, and max cycle time performance measures are weighted averages of the corresponding product values by throughput rate. Copyright WWK 1995-2009 Factory Explorer 113
7. User's Guide: Analyzing Output 7.2.4 Gross Margin Worksheet This worksheet displays predicted gross margin on a period-by-period basis. The predictions in this report are based upon capacity analysis, not simulation. Gross margin is predicted as revenue minus expenses, where expenses include raw materials, supplies & consumables, factory depreciation, factory recurring expenses, tool depreciation, tool recurring expenses, and operator wages. If one or more fixed costs do not specify a depreciation life, depreciation expenses for these fixed costs cannot be calculated or included in this worksheet. By default, this worksheet displays gross margin data for the first analysis period of the first replication. Use the AutoFilter to select a different analysis period or replication. For runs with multiple analysis periods, use the AutoFilter to select a particular revenue or expense category and display trends over time. This worksheet is not available if NoPeriodOutput is enabled, and is only available if the model contains cost data and DoCap, DoCost, StartDate, and RunLen are enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Item: Description of gross margin line item revenue items and expense items. Totals: Revenue or expense total for an individual gross margin line item. Contribution: Total revenue, expense, and gross margin amounts. 7.2.5 Product Cost Worksheet This worksheet lists the product cost per good unit out for each product, broken down into factory fixed and recurring costs, raw unit costs, supplies & consumable costs, process overhead costs, direct materials costs, tool fixed and recurring costs, and operator costs. The cost of assembled or transformed products is also included. Product cost outputs are generated for each analysis period. By default, this worksheet displays overall product summary data for the first replication. Use the AutoFilter to select a different replication. Click on the "+" button to the left of a product cost summary row to view broad product cost category totals (raw unit costs, operator wages, etc.). Click on the "+" button to the left of a category total to view detailed cost items (actual raw unit cost, scrapped raw unit cost, etc.). Or, click on the "1", "2", or "3" buttons in the upper lefthand corner of the worksheet to display different levels of detail for the entire worksheet (click "1" for product cost summary data, "2" for category totals, or "3" for detailed items). For runs with multiple analysis periods, use the AutoFilter to select a particular product and display trends over time. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap and DoCost are enabled and the model contains some type of cost data. Fields Rep: Replication number.
7.2. Output Worksheets Pd: Analysis period. Period Start Date. Period End Date. Product: Product name. Item: Description of product cost item. At the highest summary level, displays Total Product Cost. Within total product cost, displays product cost categories Factory Fixed Costs, Factory Recurring Costs, Raw Unit Costs, Supplies and Consumable Costs, Process Overhead Costs, Direct Material Costs, ToolType Costs (for each defined ToolType), Total Costs for All Tools, Operator Wage Costs, Operator Overhead Costs, Total Operator Cost for Working/Non-Working Time. Within each cost category, displays detailed cost items. Details: Shows product cost amount attributable to each detailed cost item. Cost Per Good Unit Out: Shows product cost amount attributable to each product cost category, and total product cost. 7.2.6 Expense Item Summary Worksheet This worksheet displays expense item consumption and cost information. This worksheet is only available if the input model contains expense item information, and if capacity and cost analysis are enabled with DoCap and DoCost. This worksheet is not available if NoPeriodOutput is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Expense Item. Total Cons: Total predicted consumption for this expense item for this period. UOM: The unit of measure for this expense item. Total Cost: Total predicted cost for this expense item for this period. 7.2.7 Scheduling Worksheet This worksheet displays detailed event-by-event scheduling information from the simulation. This worksheet is only available if scheduling analysis and simulation analysis are enabled with DoSched and DoSim. Fields Rep: Replication number. Pd: Analysis period.
7. User's Guide: Analyzing Output Date. Time. Activity: Description of the activity. The following activities are normally reported. Some activities are not reported if the elapsed time is zero. For example, if the load time for a process step is zero, then the Start Loading and Finish Loading activities are not reported. Release Lot(s): One or more lots are released into the factory. Release Indiv. Lot(s): One or more individual lots are released into the factory. Lot Enters Queue: A lot enters a queue for a particular tool group. Seize Resource(s): A tool and/or operator are seized for a factory activity. Start Loading: A lot or batch starts the load phase of processing. Finish Loading: A lot or batch finishes the load phase of processing. Start Processing: A lot or batch starts the process phase of processing. Finish Processing: A lot or batch finishes the process phase of processing. Start Unloading: A lot or batch starts the unload phase of processing. Finish Unloading: A lot or batch finishes the unload phase of processing. Start Delay: A lot or batch starts the extra-delay phase of processing. Finish Delay: A lot or batch finishes the extra-delay phase of processing. Start Travel: A lot or batch starts its step travel time. Finish Travel: A lot or batch finishes its step travel time. Free Resource: A tool or operator is freed. Lot Completes Flow: A lot completes its process flow. Scrap: A lot is scrapped. Assemble: An assembly lot is released into the factory. Interrupt: A tool or operator interruption occurs. Start Offline: A tool or operator starts an offline time. End Offline: A tool or operator ends an offline time. Clear Statistics: The clear-statistics time is reached in the analysis run. Call User Code: A call is made to user-defined code. Start Nonscheduled: A factory nonscheduled time is started. Finish Nonscheduled: A factory nonscheduled time is finished. The following activities are only reported if SchedShowAll is enabled: Start Run: The start of the analysis run.
7.2. Output Worksheets Batch Statistics: Internal simulation statistics are calculated. Show Pct Completed: A progress message is written to the output console. Check Resource Request: A tool or operator group is checking its request list. End of Period; The end of an analysis period. Ramp Model Variables: A model input is being ramped. Lot ID: The lot identification. For individual lots, the lot ID is specified in the input model. For other lots, Factory Explorer assign a unique lot ID to each new lot. Product. The product name. Process. The process name. Step: The process step name. Tool Type: If an activity is related to a tool group, the tool type for the tool group. Tool Group. The tool group name. Tool: If an activity is related to a particular tool, the tool number for this tool. Tool Offline Name: If an activity is related to a particular tool offline, the tool offline name. Total Tools: The total number of tools in the tool group. Idle Tools: The number of currently idle tools in the tool group. Lots in Queue: The number of lots waiting in queue for the tool group. For tool groups that serve alternative process steps, lots will be counting as waiting in queue for all tool groups listed as alternatives. Total Lot WIP: The number of lots waiting in queue for the tool group, plus any lots currently being processed by tools in the tool group. Oper Group: The operator group name. Oper: If an activity is related to a particular operator, the operator number for this operator. Oper Offline Name: If an activity is related to a particular operator offline, the operator offline name. Idle Opers: The number of currently idle operators in the operator group. Lot Size: The number of units in the lot. For rework parent lots, this number does not include units currently in rework child lots. Lot Priority. The current lot priority. 7.2.8 Bottleneck Capacity Resource Worksheet This worksheet displays the results of capacity analysis at the resource (tool and operator group) level in a combined format, sorted from highest to lowest capacity loading%. These results are generated by replication and by period. By default, this worksheet displays data for the first period of the first replication. Use the AutoFilter to select a Copyright WWK 1995-2009 Factory Explorer 117
7. User's Guide: Analyzing Output different replication or period. To view trends across analysis periods, use the AutoFilter to set the selected period to (All), to set the rank filter to (All), and to select a single resource. By default, this worksheet displays summary columns only. Click on the "+" button above the columns to view capacity details. Or, click on the "1" or "2" buttons in the upper left-hand corner of the worksheet (click "1" to hide detail columns, "2" to display detail columns). This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Rank: Numerical rank of the resource group by capacity loading. The resource ranked 1 has the highest capacity loading, and by definition is the factory bottleneck. Resource: Resource group name. Process Type: The resource type, defined as single if the resource is a tool group with only per-lot or per-unit processing times, batch if the resource is a tool group with batch I.D.'s defined (may have per-unit or batch processing times), opgroup if the resource is an operator group, or unused if the resource is a tool group or operator group not used by any process step. Total Input Rate: Predicted total unit input rate for the group. Total input rate is a sum across all process steps that use the group, and accounts for scrap, rework, multiple visits, and random routings within process flows. Theo Max Proc Rate: Predicted theoretical maximum unit processing rate. The maximum feasible rate at which the group could process units, assuming no nonscheduled time, no offline time, no setup, no repair, and full batches (for resources that perform batch processing). Percent NonSched: Predicted percent nonscheduled time. Note that this is a result of factory nonscheduled time, not nonscheduled downtime (which is usually modeled as a resource group interruption). Number of Offline Types: Number of distinct offline types defined in the model. An offline type is defined whenever an interruption is included in the model with a unique interruption name. Percent Offline n (Offline Type Name): Predicted percent offline time due to a particular offline type. Percent Offline (Total): Predicted percent offline time summed across all interruption types. Percent Setup: Predicted percent setup time.
7.2. Output Worksheets Percent Repair: Predicted percent repair time. Percent repair is defined only for operators, and will be zero for all tool groups. Percent Non Rework: Predicted percent time spent processing non-rework lots. Percent Rework: Predicted percent time spent processing rework lots. Percent Work (Total): Percent non-rework plus percent rework. Percent Free: 100% minus the sum of percent nonscheduled, percent offline (total), percent setup, percent repair, and percent work (total). Current Actual Max Proc Rate: Current actual maximum processing rate. The maximum feasible rate at which the resource group could process units, taking into account nonscheduled time, offline time, setup time, and repair time. Note that since setup time, offline time, and repair time can vary non-linearly with changes in input rate, Factory Explorer calculates actual maximum processing rate by dynamically varying the input rate until it finds the point at which percent free becomes zero. This point is the current actual maximum processing rate. Tool (or Operator) DGR (Unit of measure controlled by OutRateUM). Group DGR divided by current resource count. Group DGR (Unit of measure controlled by OutRateUM). Daily going rate for the resource group, calculated as the sum of throughput rates for products with the same unit type as this resource group that are also processed on this resource group, divided by the resource groups capacity loading. Current Resource Count: Current number of resources in the resource group. Note that the number of resources reported for each analysis period is a weighted average across the entire analysis period, and hence can be non-integral if the number of resources changes within the period. Current Capacity Loading: Total input rate divided by current actual maximum processing rate, multiplied by 100%. Sugg Max Loading: Suggested maximum loading. Suggested maximum loading is defined as the factory suggested loading, minus any capacity buffer defined for the resource group. Sugg Exact Resource Count: Suggested exact resource count, defined as the fractional quantity of resources required to obtain a capacity loading equal to the suggested maximum loading. Sugg Resource Change: Suggested resource change, defined as the change in resource count required to obtain the suggested whole resource count. Sugg Whole Resource Count: Suggested whole resource count, defined as the whole (integral) quantity of resources required to obtain a capacity loading equal to or less than the suggested maximum loading. New Capacity Loading: The capacity loading that would result if the current resource count were set to the suggested whole resource count. Resource Type: Resource type name. Opgroup or toolgroup.
7. User's Guide: Analyzing Output 7.2.9 Bottleneck Simulation Resource Worksheet This worksheet displays the results of simulation analysis at the resource (tool and operator group) level in a combined format, sorted from highest to lowest capacity loading%. These results are generated by replication and by period. By default, this worksheet displays data for the first period of the first replication. Use the AutoFilter to select a different replication or period. To view trends across analysis periods, use the AutoFilter to set the selected period to (All), to set the rank filter to (All), and to select a single resource. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoSim is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Rank: Numerical rank of the resource group by capacity loading. The resource ranked 1 has the highest capacity loading, and by definition is the factory bottleneck. Resource: Resource group name. Process Type: The resource type, defined as single if the resource is a tool group with only per-lot or per-unit processing times, batch if the resource is a tool group with batch I.D.'s defined (may have per-unit or batch processing times), opgroup if the resource is an operator group, or unused if the resource is a tool group or operator group not used by any process step. Resource Type: Resource type name. Opgroup or toolgroup Sim Percent Factory NonSched: Simulated percent nonscheduled time. Note that this is a result of factory nonscheduled time, not nonscheduled downtime (which is usually modeled as a resource group interruption). Number of Offline Types: Number of distinct offline types defined in the model. An offline type is defined whenever an interruption is included in the model with a unique interruption name. Sim Percent Offline n (Offline Type Name): Simulated percent offline time due to a particular offline type. Sim Percent Offline (Total): Simulated percent offline time summed across all interruption types. Sim Percent Setup: Simulated percent setup time. Sim Percent Repair: Simulated percent repair time. Percent repair is defined only for operators, and will be zero for all tool groups. Sim Lost Capacity (Total): Simulated Sim Percent Offline (Total), Sim Percent Setup and, Sim Percent Repair summed.
7.2. Output Worksheets Sim Percent Busy Working BatchWork: Simulated percent time spent busy processing at a tool group with batch I.D.'s defined (may have per-unit or batch processing times). Sim Percent Busy Working SingleWork: Simulated percent time spent busy processing at a tool group with only per-lot or per-unit processing times. Sim Percent Busy Working Rework: Simulated percent time spent busy processing rework lots. Sim Percent Busy Working Non Rework: Simulated percent time spent busy processing non-rework lots. Sim Percent Busy Working: Simulated Sim Percent Busy Working BatchWork and Sim Percent Busy Working SingleWork summed. Also Sim Percent Busy Working Rework and Sim Percent Busy Working Non Rework summed Sim Percent Busy No Oper: Simulated percent time waiting for an Operator at a tool group requiring an operator to begin setup or processing. Sim Percent Busy Held: Simulated percent time waiting for a resource group hold to be released. Sim Percent Work Pending (Total): Sim Percent Busy No Oper and Sim Percent Busy Held summed. Sim Percent Busy BatchWork: Simulated percent time spent busy (with either work pending or working) processing at a tool group with batch I.D.'s defined (may have per-unit or batch processing times). Sim Percent Busy SingleWork: Simulated percent time spent busy (with either work pending or working) processing at a tool group with only per-lot or per-unit processing times. Sim Percent Busy Rework: Simulated percent time spent busy (with either work pending or working) processing rework lots. Sim Percent Busy Non Rework: Simulated percent time spent busy (with either work pending or working) processing non-rework lots. Sim Percent Busy: Simulated Sim Percent Busy BatchWork and Sim Percent Busy SingleWork summed. Also Sim Percent Busy Rework and Sim Percent Busy Non Rework summed Sim Percent Free: 100% minus the sum of percent nonscheduled, percent offline (total), percent setup, percent repair, and percent work (total). 7.2.10 Resource Planning Worksheet This worksheet displays resource planning information in a compact format. Each row represents a single tool or operator group, and columns represent periods in the analysis run. By default, this worksheet displays tool group data for the first replication use the AutoFilter to select operator groups, or to select a different replication. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled.
7. User's Guide: Analyzing Output Fields Rep: Replication number. Resource Type: "ToolGroup" for tool group rows, "OpGroup" for operator group rows. Resource Group: The tool or operator group name. Sugg Max Loading: Suggested maximum capacity loading for the resource group, defined as the factory suggested maximum loading (as specified with SuggLoading) minus any capacity buffer (as specified at the resource group level). Item: Description of resource plan line item Current Count, Sugg Exact Count, Sugg Change, Sugg Whole Count, Lead Time, Purchase Date, Tool (or Operator) DGR, Group DGR, Group DGR Adjustment, Adjusted Group DGR, Scheduled Group DGR, Capacity Loading, Sim Busy (percentage). Period n: Results for an individual resource plan line item. Note: For Capacity Loading, on Excel 97 and higher, this row is conditionally formatted as follows: If the capacity loading lies between zero and Sugg Max Loading divided by 2, the cell is colored light blue. If the capacity loading lies between Sugg Max Loading divided by 2 and Sugg Max Loading, the cell is colored green. If the capacity loading lies between Sugg Max Loading and 100, the cell is colored yellow. If the capacity loading is greater than 100, the cell is colored red. 7.2.11 Tool Group Results Worksheet This worksheet displays Factory Explorer analysis results for tool groups. These results are generated by replication and by period. By default, this worksheet displays data for the first period of the first replication. Use the AutoFilter to select a different replication or period. To view trends across analysis periods, use the AutoFilter to set the period filter to (All) and to select a single tool group. This worksheet is not available if NoPeriodOutput is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Tool Group. Tool Type.
7.2. Output Worksheets Process Type: The tool group process type, defined as single if the tool group has only per-lot or per-unit processing times, batch if the tool group has batch I.D.'s defined (may have per-unit or batch processing times), or unused if the tool group is not used by any process step. Total Input Rate: Predicted total unit input rate for the group. Total input rate is a sum across all process steps that use the group, and accounts for scrap, rework, multiple visits, and random routings within process flows. Theo Max Proc Rate: Predicted theoretical maximum unit processing rate. The maximum feasible rate at which the group could process units, assuming no nonscheduled time, no offline time, no setup, no repair, and full batches (for groups that perform batch processing). Sim Percent NonSched: Simulation percent nonscheduled time. Note that this is a result of factory nonscheduled time, not nonscheduled downtime (which is usually modeled as a resource group interruption). Pre Percent NonSched: Predicted percent nonscheduled time. Number of Offline Types: Number of distinct offline types defined in the model. An offline type is defined whenever an interruption is included in the model with a unique interruption name. Sim Percent Offline n (Offline Type Name): Simulation percent offline time due to a particular offline type. Pre Percent Offline n (Offline Type Name): Predicted percent offline time due to a particular offline type. Sim Percent Offline (Total): Simulation percent offline time summed across all interruption types. Pre Percent Offline (Total): Predicted percent offline time summed across all interruption types. Avoid Setups: "Yes" if setup-avoidance is enabled for the group, otherwise "No". Sim Percent Setup: Simulation percent setup time. Pre Percent Setup: Predicted percent setup time. Sim Percent Busy Working: Simulation percent busy time when work is actually being performed. Sim Percent Busy No Oper: Simulation percent busy time when a tool is waiting for an operator to start processing, or to start unloading. Sim Percent Busy Held: Simulation percent busy time that occurs after processing has completed on the process step where the tool was originally seized, up to the time when the tool is actually freed. If the tool group is not listed on any hold-steps, then Sim Percent Busy Held will be zero. If the tool group is listed on hold-steps, Sim Percent Busy Held quantifies the amount of time the tool is busy while it is waiting for the lot that holds it to reach the free-after step.
7. User's Guide: Analyzing Output Sim Percent Busy: Sim Percent Busy Working plus Sim Percent Busy No Oper plus Sim Percent Busy Held. Sim Batch Util (Avg Over Max): Simulation batch utilization (average batch size over maximum batch size). For non-batch tools, this output is zero. Sim Percent Work: Simulation percent work time. For non-batch tools, simulation percent work time is equal to simulation percent busy. For batch tools, simulation percent work time is equal to simulation percent busy multiplied by simulation batch utilization. Pre Percent Non Rework: Predicted percent time spent processing non-rework lots. Pre Percent Rework: Predicted percent time spent processing rework lots. Pre Percent Work (Total): Percent non-rework plus percent rework. Sim Percent Free No Work: Simulation percent free, due to no lots waiting for processing. Sim Percent Free No Oper: Sim Percent Free No Oper: Simulation percent free, due to no operators available for processing (but lots waiting for processing). NOTE: The simulated percent free no operator will always be zero for tool groups that specify minimum or maximum queue delay or minimum or maximum queue length or minimum or maximum numbers of tools to be setup. For these tool groups, Factory Explorer is unable to distinguish between forced idle time due to setup restrictions and forced idle time due to lack of operators. Thus it is unable to separately quantify the amount of forced idle time due to lack of operators. Sim Percent Free: Simulation percent free, defined as simulation percent free no work plus simulation percent free no operator. Pre Percent Free: 100% minus the sum of predicted percent nonscheduled, predicted percent offline (total), predicted percent setup, predicted percent repair, and predicted percent work (total). Current Actual Max Proc Rate: Current actual maximum processing rate. The maximum feasible rate at which the group could process units, taking into account nonscheduled time, offline time, setup time, and repair time. Note that since setup time, offline time, and repair time can vary non-linearly with changes in input rate, Factory Explorer calculates actual maximum processing rate by dynamically varying the input rate until it finds the point at which percent free becomes zero. This point is the current actual maximum processing rate. Group DGR (Unit of measure controlled by OutRateUM). Daily going rate for the resource group, calculated as the sum of throughput rates for products with the same unit type as this resource group that are also processed on this resource group, divided by the resource groups capacity loading. Tool DGR (Unit of measure controlled by OutRateUM). Group DGR divided by Current Tool Count. Current Tool Count: Current number of tools in the tool group. Note that the number of tools reported for each analysis period is a weighted average across the entire 124 Factory Explorer Copyright WWK 1995-2009
7.2. Output Worksheets analysis period, and hence can be non-integral if the number of tools changes within the period. Total Fixed Cost: Current tool count multiplied by per-tool fixed cost. Current Capacity Loading: Total input rate divided by current actual maximum processing rate, multiplied by 100%. Rank: Numerical rank of the tool group by capacity loading. Sugg Max Loading: Suggested maximum loading. Suggested maximum loading is defined as the factory suggested loading, minus any capacity buffer defined for the group. Sugg Exact Tool Count: Suggested exact tool count, defined as the fractional quantity of tools required to obtain a capacity loading equal to the suggested maximum loading. Sugg Tool Change: Suggested tool change, defined as the change in tool count required to obtain the suggested whole tool count. Sugg Whole Tool Count: Suggested whole tool count, defined as the whole (integral) quantity of tools required to obtain a capacity loading equal to or less than the suggested maximum loading. New Total Fixed Cost: Sugg whole tool count multiplied by per-tool fixed cost. New Capacity Loading: The capacity loading that would result if the current tool count were set to the suggested whole tool count. Sim Avg Queue Delay: Simulation average queue delay. Pre Avg Queue Delay: Predicted average queue delay (based on queuing theory). Sim Max Queue Delay: Simulation maximum queue delay. Sim Avg Queue Length: Simulation average queue length. Pre Avg Queue Length: Predicted average queue length (based on queuing theory). Sim Max Queue Length: Simulation maximum queue length. Sim Avg Unit WIP: Simulation average unit work-in-process. Sim Max Unit WIP: Simulation maximum unit work-in-process. Sim Avg Lot WIP: Simulation average lot work-in-process. Sim Max Lot WIP: Simulation maximum lot work-in-process. Sim Avg Inter Arrival: Simulation average inter-arrival time, defined as the average time between lot arrivals to the tool group. For tool groups that appear on alternative steps, simulation and predicted interarrival time values are calculated for arrivals to the group of alternatives, not simply to the tool group that ultimately processes the arrival. For example, if tool group TG1 and tool group TG1 are 50-50 alternatives for step S1, and the arrival rate of lots to step S1 is one lot per hour, then the interarrival times for both TG1 and TG2 should be one hour, not two hours. Copyright WWK 1995-2009 Factory Explorer 125
7. User's Guide: Analyzing Output Pre Avg Inter Arrival: Predicted average inter-arrival time. Sim CV Inter Arrival: Simulation inter-arrival time coefficient of variation. Coefficient of variation is the square root of the variance divided by the mean. Pre CV Inter Arrival: Predicted inter-arrival time coefficient of variation. Pre Avg Process Time: Predicted average process time, weighted by process step unit throughput rate. Predicted average process time is a per-lot value, except for batch tools, where it is a per-batch value. Pre Var Process Time: Predicted process time variation. Predicted process time variation is a per-lot value, except for batch tools, where it is a per-batch value. Pre CV Process Time: Predicted process time coefficient of variation. Predicted process time coefficient of variation is a per-lot value, except for batch tools, where it is a per-batch value. 7.2.12 Tool Group Capacity by Product Worksheet This worksheet displays a breakdown of capacity usage and cost allocation by product for each tool group. The cost allocation for an individual product is based on the total time spent processing that product (in a week, say) divided by the total time spent processing all products. The Current Input Rate is the total rate at which units are arriving to the tool group. The Actual Max Input Rate is the rate at which the loading of the tool group would become 100%, assuming product mix is hold constant. Capacity loading is Current Input Rate divided by Actual Max Input Rate, and is the same for all products processed by a tool group. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Tool Group. Product. Product Type. Percent Work: Predicted percent of time the tool group spends working on this product. Cost Alloc Percent: Cost allocation percentage, defined as the percent work time for this product divided by total time the tool group spends working on all products. Current Input Rate: Total rate at which units of this product arrive to this tool group. Actual Max Input Rate: The maximum feasible rate at which the tool group could process units of this product, taking into account nonscheduled time, offline time, setup time, and repair time, and assuming mix is held constant.
7.2. Output Worksheets Capacity Loading: Current input rate divided by actual maximum input rate. 7.2.13 Tool Group Setups Worksheet This worksheet displays simulation-based statistics for individual setup I.D.'s. These statistics include the number of setups, the total time spent in setup, and the total setup time as a percent of the analysis period. This worksheet is available if DoSim is enabled, and is not available if NoPeriodOutput or DelSetups is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Tool Group. Setup Group. Setup ID. Sim Total Setups: Simulation total setups, defined as the total number of simulated setups for this particular setup I.D. during the analysis period. Sim Total Setup Time: Simulation total setup time, defined as the total time spent setting up for this setup I.D. during the analysis period. Reported in hours. Sim Setup Pct: Simulation setup percent, defined as Sim Total Setup Time divided by the product of analysis period length and tool group tool quantity. 7.2.14 Tool Group Expense Item Worksheet This worksheet displays expense item consumption and cost information for each tool group. This worksheet is only available if the input model contains expense item information, and if capacity and cost analysis are enabled with DoCap and DoCost. This worksheet is not available if NoPeriodOutput is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Tool Group. Expense Item. UOM: The unit of measure for this expense item.
7. User's Guide: Analyzing Output Non Sched Time Cons: Total predicted non-scheduled time expense item consumption for this tool group for this period. This field is initially hidden within a column group. Unsched Downtime Cons: Total predicted unscheduled downtime expense item consumption for this tool group for this period. This field is initially hidden within a column group. Sched Downtime Cons: Total predicted scheduled downtime expense item consumption for this tool group for this period. This field is initially hidden within a column group. Engr Time Cons: Total predicted engineering time expense item consumption for this tool group for this period. This field is initially hidden within a column group. Standby Time Cons: Total predicted standby (free) time expense item consumption for this tool group for this period. This field is initially hidden within a column group. Productive Time Cons: Total predicted productive (working) time expense item consumption for this tool group for this period. This field is initially hidden within a column group. Units Processed Cons: Total predicted units-processed expense item consumption for this tool group for this period. This field is initially hidden within a column group. Total Cons: Total predicted consumption for this expense item for this period. Total Cost: Total predicted cost for this expense item for this period. 7.2.15 Operator Group Results Worksheet This worksheet displays Factory Explorer analysis results for operator groups. These results are generated by replication and by period. By default, this worksheet displays data for the first period of the first replication. Use the AutoFilter to select a different replication or period. To view trends across analysis periods, use the AutoFilter to set the selected period to (All) and to select a single operator group. The number of operators reported for each analysis period is a weighted average across the entire analysis period, and hence can be non-integral if the number of operators changes within the period. The maximum capacity loading used to calculate suggested numbers of operators is controlled with SuggLoading. To vary the suggested capacity loading% for individual operator groups, use the CBUFFER column (Excel models) or the CapacityBuffer statement (ASCII models). The calculation of work% for operators that work at batch tools is based on full batches. This worksheet is not available if NoPeriodOutput is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date.
7.2. Output Worksheets Operator Group. Process Type: The operator group process type, defined as opgroup if the operator is used anywhere in the model, or unused if the operator group is not used by any process step. Total Input Rate: Predicted total unit input rate for the group. Total input rate is a sum across all process steps that use the group, and accounts for scrap, rework, multiple visits, and random routings within process flows. Theo Max Proc Rate: Predicted theoretical maximum unit processing rate. The maximum feasible rate at which the group could process units, assuming no nonscheduled time, no offline time, no setup, no repair, and full batches (for groups that perform batch processing). Sim Percent NonSched: Simulation percent nonscheduled time. Note that this is a result of factory nonscheduled time, not nonscheduled downtime (which is usually modeled as a resource group interruption). Pre Percent NonSched: Predicted percent nonscheduled time. Number of Offline Types: Number of distinct offline types defined in the model. An offline type is defined whenever an interruption is included in the model with a unique interruption name. Sim Percent Offline n (Offline Type Name): Simulation percent offline time due to a particular offline type. Pre Percent Offline n (Offline Type Name): Predicted percent offline time due to a particular offline type. Sim Percent Offline (Total): Simulation percent offline time summed across all interruption types. Pre Percent Offline (Total): Predicted percent offline time summed across all interruption types. Sim Percent Setup: Simulation percent setup time. Pre Percent Setup: Predicted percent setup time. Sim Percent Repair: Simulation percent repair time. Pre Percent Repair: Predicted percent repair time. Sim Percent Busy: Simulation percent busy time. Sim Batch Util (Avg Over Max): Simulation batch utilization (average batch size over maximum batch size). For operators that only work with non-batch tools, this output is zero. Sim Percent Work: Simulation percent work time. For operators that only work with non-batch tools, simulation percent work time is equal to simulation percent busy. For operators that work with at least one batch tool, simulation percent work time is equal to simulation percent busy multiplied by simulation batch utilization. Pre Percent Non Rework: Predicted percent time spent processing non-rework lots. Copyright WWK 1995-2009 Factory Explorer 129
7. User's Guide: Analyzing Output Pre Percent Rework: Predicted percent time spent processing rework lots. Pre Percent Work (Total): Percent non-rework plus percent rework. Sim Percent Free: Simulation percent free time. Pre Percent Free: 100% minus the sum of predicted percent nonscheduled, predicted percent offline (total), predicted percent setup, predicted percent repair, and predicted percent work (total). Current Actual Max Proc Rate: Current actual maximum processing rate. The maximum feasible rate at which the group could process units, taking into account nonscheduled time, offline time, setup time, and repair time. Note that since setup time, offline time, and repair time can vary non-linearly with changes in input rate, Factory Explorer calculates actual maximum processing rate by dynamically varying the input rate until it finds the point at which percent free becomes zero. This point is the current actual maximum processing rate. Group DGR (Unit of measure controlled by OutRateUM). Daily going rate for the resource group, calculated as the sum of throughput rates for products with the same unit type as this resource group that are also processed on this resource group, divided by the resource groups capacity loading. Operator DGR (Unit of measure controlled by OutRateUM). Group DGR divided by Current Ops Count. Current Ops Count: Current number of operators in the operator group. Note that the number of operators reported for each analysis period is a weighted average across the entire analysis period, and hence can be non-integral if the number of operators changes within the period. Current Capacity Loading: Total input rate divided by current actual maximum processing rate, multiplied by 100%. Rank: Numerical rank of the group by capacity loading. Sugg Max Loading: Suggested maximum loading. Suggested maximum loading is defined as the factory suggested loading, minus any capacity buffer defined for the group. Sugg Exact Ops Count: Suggested exact operator count, defined as the fractional quantity of operators required to obtain a capacity loading equal to the suggested maximum loading. Sugg Ops Change: Suggested operator change, defined as the change in operator count required to obtain the suggested whole operator count. Sugg Whole Ops Count: Suggested whole operator count, defined as the whole (integral) quantity of operators required to obtain a capacity loading equal to or less than the suggested maximum loading. New Capacity Loading: The capacity loading that would result if the current operator count were set to the suggested whole operator count.
7.2. Output Worksheets 7.2.16 Operator Group Capacity by Product Worksheet This worksheet displays a breakdown of capacity usage and cost allocation by product for each operator group. The cost allocation for an individual product is based on the total time spent processing that product (in a week, say) divided by the total time spent processing all products. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Operator Group. Product. Product Type. Percent Work: Predicted percent of time the operator group spends working on this product. Cost Alloc Percent: Cost allocation percentage, defined as the percent work time for this product divided by total time the operator group spends working on all products. Current Input Rate: Total rate at which units of this product arrive to this operator group. Actual Max Input Rate: The maximum feasible rate at which the operator group could process units of this product, taking into account nonscheduled time, offline time, setup time, and repair time, and assuming mix is held constant. Capacity Loading: Current input rate divided by actual maximum input rate. 7.2.17 Product Lead Time Worksheet This worksheet displays estimated average product lead time for each end-product. For each end-product this worksheet also displays a list of critical path products and their cycle times. The critical path traces the sequence of products that define the end-product's product lead time. This worksheet is not available if NoPeriodOutput is enabled, and is only generated if DoSim is enabled and the model includes assembled or transformed products (otherwise, all products are end-products, and the product lead time for each product is just its cycle time). Fields Rep: Replication number. Pd: Analysis period.
7. User's Guide: Analyzing Output Period Start Date. Period End Date. Product. The end-product name. Critical Product: Name of a product on the sequence of products that define the endproduct's lead time. Avg CT: Average Cycle Time. 7.2.18 WIP and Cycle Time by Operation Worksheet This worksheet displays simulation estimates for average queue length, queue delay, WIP, and cycle time. The data is estimated for individual process steps and operation. This process works as follows. First, only steps that are contiguous within the process flow and which all specify the same operation will be aggregated together. This means that if operation 100 is specified for two steps in the process flow, but an intervening step specifies a different operation, then operation 100 will be listed twice on this report. Second, steps that do not specify an operation are treated as if they had specified the operation "(Empty)". Finally, queue delay and cycle time are estimated directly via an average of actual lot queue delay and cycle times; and unit WIP (or queue length) is estimated indirectly via Little's law (average unit WIP = unit arrival rate * average cycle time or average queue length = unit arrival rate * average queue delay). By default, this worksheet displays data for the first product, period, and replication. To view data for a different product, period, or replication, use the AutoFilter. For the analysis run, enable DoSim and RunLen. This worksheet is not available if you enable NoPeriodOutput. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Product. Process. Operation. Sim Lot Arrivals to All Steps in Operation: Simulated number of lots arrivals to all steps in this operation. Number of Steps in Operation. Sim Avg Lot Arrivals to Operation: Sim Lot Arrivals to All Steps in Operation divided by Number of Steps in Operation. Sim Avg Queue Length: Simulation average queue length in units. Sim Avg Queue Delay: Simulation average queue delay. Sim Avg WIP: Simulation average WIP in units.
7.2. Output Worksheets Sim Avg Cycle Time: Simulation Average Cycle time. Cumul Cycle Time: Cumulative cycle time. 7.2.19 WIP Snapshot Worksheet This worksheet displays a snapshot of simulated WIP (work in process lots) in the system at the end of each analysis period. For each lot, the worksheet displays detailed information including the lot's product, process, current process step, current number of units, priority, start date, and due date. If a lot is a rework parent or child, or a split lot parent or child, this information is also displayed. This worksheet is formatted so as to make it easy to copy and paste data for lots onto the Lots worksheet in an Excel model. See Section 9.11 of the user manual for more information on the Lots worksheet. By default, this worksheet displays WIP for the end of the first period of the first replication. Use the AutoFilter to select a different replication or period. This worksheet is not available if NoPeriodOutput is enabled, and is only generated if DoSim and WriteDetail is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Lot ID. Product. The product name for the lot. Process. The process the lot is following. Step: The process step where the lot is located. Number of Units: Number of units in the lot. Priority: Current lot priority. Start Date: Date lot was started. For rework children: date the child lot was created. Due Date: Date lot is due. Rework Parent Flag: X if the lot is a rework parent. Rework Child Flag: X if the lot is a rework child. Rework Parent Lot ID: If the lot is a rework child, the lot I.D. of its rework parent. Split Lot Parent Flag: X if the lot is a split-lot parent. Total Split Lot Children: If the lot is a split-lot parent, the total number of split lot children. Remaining Split Lot Children: If the lot is a split-lot parent, the number of split lot children that have not yet been recombined with the parent lot. Split Lot Child Flag: X if the lot is a split-lot child. Copyright WWK 1995-2009 Factory Explorer 133
7. User's Guide: Analyzing Output Split Lot Parent ID: If the lot is a split-lot child, the lot I.D. of its split-lot parent. 7.2.20 Process Step Detail Worksheet This worksheet displays detailed process step information, including product cost breakdowns, raw process time, total lot arrivals, and average queue delay. By default, this worksheet displays data for the first product in the model for the first period of the first replication. Use the AutoFilter to select a different product, analysis period, or replication. Replication-level outputs are displayed if the number of analysis periods is greater than one. Run-level outputs are displayed if the number of replications is greater than one. To view steps with large queue delays, use the AutoFilter to select a particular analysis period (or all periods) and to select a particular product (or all products). Then use the AutoFilter to select only those steps with average queue delays greater than a given amount (e.g. select custom from the AutoFilter drop-down, select '<=' as the operator, and fill in a maximum queue delay, say 5 hours). Only the steps that are active for a product are listed for the product (i.e. steps within a products process flow that are not active for the product are not listed). Period-level outputs are not available if NoPeriodOutput is enabled. Replication-level outputs are not available if NoRepOutput is enabled. Run-level outputs are not available if NoRunOutput is enabled. This worksheet is only available if WriteDetail and DoCap or DoSim are enabled. Cost-analysis-based performance measures are only available if DoCost is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Product. Process. Step. Tool Group. Tool Type. Op Group: Operator Group. Operation. Step Type. Travel Op Group: Travel Operator Group. Non Rework Units Per Hour: The arrival rate of non-rework units to the step. Rework Units Per Hour: The arrival rate of rework units to the step.
7.2. Output Worksheets Total Input Units Per Hour: Non Rework Units Per Hour plus Rework Units Per Hour. Raw Unit Cost Per Good Unit: The calculated raw unit cost per good unit out. This cost is assigned to the first process step in the process flow, and is zero for all other steps. Transform Cost Per Good Unit: If the product is a result of transform, the calculated cost per good unit out of all sub-transform products. This cost is assigned to the first step in the flow, and is zero for all other steps. Assembly Cost Per Good Unit: If the product is a result of transform, the calculated cost per good unit out of all sub-assembly products. This cost is assigned to the first step in the flow, and is zero for all other steps. Supplies And Consumable Cost Per Good Unit: Supplies and consumable cost per good unit out. Process Overhead Cost Per Good Unit: Overhead per good unit out. Direct Material Cost Per Good Unit: Direct material cost per good unit out. Direct Cost Per Good Unit: Raw Unit Cost plus Transform Cost plus Assembly Cost plus Supplies and Consumable Cost plus Process Overhead Cost plus Direct Material Cost. Cumulative Direct Cost Per Good Unit. Tool Fixed Cost Per Good Unit: Allocation of tool group's fixed cost to this process step, based on time-used. Tool Recurring Cost Per Good Unit: Allocation of tool group's recurring cost to this process step, based on time-used. Total Tool Cost Per Good Unit: Tool Fixed Cost plus Tool Recurring Cost. Op Wages Working Time Per Good Unit: Allocation of operator group's working time wages (e.g. total wages multiplied by percent of time spent working) to this process step, based on time-used. Op Wages Non Working Time Per Good Unit: Allocation of operator group's non working time wages (e.g. total wages multiplied by percent of time not spent working) to this process step, based on time-used. Op Overhead Working Time Per Good Unit: Allocation of operator group's working time overhead (e.g. total overhead multiplied by percent of time spent working) to this process step, based on time-used. Op Overhead Non Working Time Per Good Unit: Allocation of operator group's non working time overhead (e.g. total overhead multiplied by percent of time not spent working) to this process step, based on time-used. Travel Op Wages Working Time Per Good Unit: Allocation of travel operator group's working time wages (e.g. total wages multiplied by percent of time spent working) to this process step, based on time-used.
7. User's Guide: Analyzing Output Travel Op Wages Non Working Time Per Good Unit: Allocation of travel operator group's non working time wages (e.g. total wages multiplied by percent of time not spent working) to this process step, based on time-used. Travel Op Overhead Working Time Per Good Unit: Allocation of travel operator group's working time overhead (e.g. total overhead multiplied by percent of time spent working) to this process step, based on time-used. Travel Op Overhead Non Working Time Per Good Unit: Allocation of travel operator group's non working time overhead (e.g. total overhead multiplied by percent of time not spent working) to this process step, based on time-used. Total Op Cost Working Time Per Good Unit: Op Wages Working Time plus Op Overhead Working Time plus Travel Op Wages Working Time plus Travel Op Overhead Working Time. Total Op Cost Non Working Time Per Good Unit: Op Wages Non Working Time plus Op Overhead Non Working Time plus Travel Op Wages Non Working Time plus Travel Op Overhead Non Working Time. Total Op Cost Per Good Unit: Total Op Cost Working Time plus Total Op Cost Non Working Time. Factory Fixed Cost Per Good Unit: Allocation of total factory fixed costs to this process step, based on a square-footage allocation to tool groups, and a reallocation based on time-used. Factory Recurring Cost Per Good Unit: Allocation of total factory recurring costs to this process step, based on a square-footage allocation to tool groups, and a reallocation based on time-used. Total Factory Cost Per Good Unit: Factory Fixed Cost plus Factory Recurring Cost. Total Step Cost Per Good Unit: Direct Cost plus Total Tool Cost plus Total Op Cost plus Total Factory Cost. Cumulative Total Cost Per Good Unit. RPT: Raw Process Time for this step. Remaining RPT: Remaining Raw Process Time, from this process step forward. Sim Non Rework Lot Arrivals: Total number of non-rework lot arrivals to this step in the simulation. Sim Rework Lot Arrivals: Total number of rework lot arrivals to this step in the simulation. Sim Total Lot Arrivals: Total lot arrivals (non-rework and rework lots) to this step in the simulation. Sim Average Queue Delay: Average queue delay for this step in the simulation. Sim Average Cycle Time: Average cycle time for this step in the simulation. Note that cycle time includes all time from when a lot arrives at a tool (begins queue delay), through processing, to the completion of travel, if any, for this step.
7.2. Output Worksheets Pre Average Lot Size: Predicted average lot size, in units, of lots arriving to this step. Note that since lots with zero units remaining are scrapped, the average lot size for steps after scrap may look usually large. For example, for a lot size of 2 units, after a 50% unit scrap step, the average lot size is 1.33 units, not 1 unit. This is because there is a 25% chance the entire lot is scrapped (and hence does not enter the following step). There is a 50% chance that exactly 1 unit will remain, and a 25% chance that 2 units will remain. Hence the average lot size for the following step is (.5 * 1 unit + .25 * 2 units)/(.5 + .25) = 1.33 units. 7.2.21 Alternative Steps Summary Worksheet This worksheet displays alternative process step summary statistics. For each group of alternative steps, this worksheet displays the alternative percentage defined in the input model, and compares it with the alternative percentage estimated via simulation (if DoSim is not enabled, the simulation estimates are zero). The worksheet contains one set of outputs for each analysis period, and one set for the entire analysis run. Enable WriteEstAlt in combination with WriteExcel to build a model that has the estimated percentages substituted for the input model percentages. This worksheet is not available if NoPeriodOutput is enabled. This worksheet is only available if the model contains alternative steps, and if DoCap and / or DoSim are enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Process. Step. Tool Group. Operator Group. Operation. Model AltPct: The alternative percentage specified in the input model for this step. Sim AltPct: The alternative percentage estimated from the simulation for this step, defined as the percentage of lots that chose this alternative out of total lot arrivals for the set of alternatives for this step. Total Lot Arrivals: The number of lots that arrived to the set of alternatives for this step. Number Times Chosen: The number of lots that chose this particular alternative.
7. User's Guide: Analyzing Output 7.2.22 Tool Space by Layout Area Worksheet If a model includes space and layout area data, this worksheet lists a breakdown of floor space requirements by layout area. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Layout Area. Total Tool Space: The sum of required tool space for all tools located in the layout area. This sum is calculated by taking the number of tools in each tool group, and multiplying by tool space requirements, then summing across all tool groups. 7.2.23 Tool Space by Type Worksheet If a model includes space data, this worksheet lists a breakdown of floor space requirements by space type. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. Space Type. Total Tool Space: The sum of required tool space for all tools that require space of this type. This sum is calculated by taking the number of tools in each tool group, and multiplying by tool space requirements for this space type (if any), then summing across all tool groups. 7.2.24 Travel Matrix by Move Rate Worksheet If a model includes layout area data, this worksheet lists a predicted move rate (lot moves per hour) between each pair of layout areas. Only pairs with non-zero move rates are displayed. Layout area pairs are sorted in descending order by move rate. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number.
7.2. Output Worksheets Pd: Analysis period. Period Start Date. Period End Date. From Layout Area. To Layout Area. Lot Move Rate: The predicted rate (in lots per hour) at which lots move from the From Layout Area to the To Layout Area. 7.2.25 Travel Matrix by Distance Rate Worksheet If a model includes layout area data, this worksheet lists a predicted distance rate (lots moves per hour * distance per move) between each pair of layout areas. Only pairs with non-zero distance rates are displayed. Layout area pairs are sorted in descending order by distance rate. This worksheet is not available if NoPeriodOutput is enabled, and is only available if DoCap is enabled. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Period End Date. From Layout Area. To Layout Area. Lot Distance Rate: The predicted rate (in lot-distance per hour) at which lot travel is generated from the From Layout Area to the To Layout Area. For example, if distances are input in feet, this output is measured in lot-feet per hour. This output is intended to give an idea of the required sizing for material handling systems that handle lot movement between layout areas. 7.2.26 Warnings Worksheet This worksheet displays warnings that Factory Explorer has generated during the analysis run. Whenever possible, Factory Explorer flags with a warning situations that, while not an outright error, could cause confusing or erroneous results. For example, a warning is generated giving the name of each unused tool or operator group. Note that any fixed or recurring costs associated with unused tools will not be allocated to any product. Similarly, wages for unused operators will not be allocated to any product. Fields Rep: Replication number. Pd: Analysis period. Period Start Date. Copyright WWK 1995-2009 Factory Explorer 139
7. User's Guide: Analyzing Output Period End Date. Warning: The text of the warning message.
7.3 Output Charts

General Comments: To access Factory Explorer's pre-defined output charts, select Analyze Output from the FactoryX pull-down menu. The resulting dialog displays a list of pre-defined output worksheets and charts. Select one or more outputs from this list and click on Create Selected Outputs. Factory Explorer beeps once when all selected outputs have been created. Individual Output Charts: Bottleneck Capacity Resource Chart (Bars or Columns): This bar-chart or column-chart displays Offline% (broken down by offline type), Setup%, Repair%, Rework%, Non Rework%, and Capacity Loading% data for the top bottleneck resources (tool groups and operator groups). Resource quantities (the number of tools in a tool group, or the number of operators in an operator group) are also displayed. Resources are ranked according to Capacity Loading%. By default, this chart displays data for the first analysis period of the first replication, and only displays the top loaded resources. The default number of resources displayed is specified on the System Parameters dialog. Use the AutoFilter to select a different analysis period or replication, or to display a different number of resources. To view trends across analysis periods, use the AutoFilter to set the selected period to (All), to set the rank filter to (All), and to select a single resource group. For the analysis run, enable DoCap. If the model contains a large number of offline types, this chart can become difficult to read. To make it easier to read, consolidate similar offline types under the same name. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by capacity analysis, and are not the result of simulation. Bottleneck Capacity Resource Chart with Product Capacity Data: This chart is similar to the Bottleneck Resource Chart (bar-chart format), except that it breaks down total working time by product. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, enable DoCap. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by capacity analysis, and are not the result of simulation. Bottleneck Simulation Resource Chart (Bars or Columns): This bar-chart or columnchart displays Sim Offline% (broken down by offline type), Sim Setup%, Sim Repair%, Sim Busy Working Rework%, Sim Busy Working Non Rework%, Sim Busy No Oper%, Sim Busy Held%, and Sim Lost Capacity (Total) data for the top bottleneck resources (tool groups and operator groups). Resource quantities (the number of tools in a tool group, or the number of operators in an operator 140 Factory Explorer Copyright WWK 1995-2009
7.3. Output Charts group) are also displayed. Resources are ranked according to Capacity Loading%. By default, this chart displays data for the first analysis period of the first replication, and only displays the top loaded resources. The default number of resources displayed is specified on the System Parameters dialog. Use the AutoFilter to select a different analysis period or replication, or to display a different number of resources. To view trends across analysis periods, use the AutoFilter to set the selected period to (All), to set the rank filter to (All), and to select a single resource group. For the analysis run, enable DoSim. If the model contains a large number of offline types, this chart can become difficult to read. To make it easier to read, consolidate similar offline types under the same name. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by simulation analysis, and are not the result of capacity. Tool Group Bottleneck Capacity Chart (Bars or Columns): This chart is similar to the Bottleneck Capacity Resource Chart, except that only tool group resources are displayed. Tool groups are ranked according to capacity loading%. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, enable DoCap. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by capacity analysis, and are not the result of simulation. Tool Group Bottleneck Capacity Chart (With Product Capacity Data): This chart is similar to the Bottleneck Capacity Resource Chart (With Product Capacity Data: bar-chart format), except that only tool group resources are displayed. Tool groups are ranked according to Capacity Loading%. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, enable DoCap. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by capacity analysis, and are not the result of simulation. Tool Group Bottleneck Simulation Chart (Bars or Columns): This chart is similar to the Bottleneck Simulation Resource Chart, except that only tool group resources from the simulation run results are displayed. Tool groups are ranked according to Capacity Loading%. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, enable DoSim. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by simulation analysis, and are not the result of capacity. Operator Group Bottleneck Capacity Chart (Bars or Columns): This chart is similar to the Bottleneck Capacity Resource Chart, except that only operator group resources from the simulation run results are displayed. Operator groups are ranked according to Capacity Loading%. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, Copyright WWK 1995-2009 Factory Explorer 141
7. User's Guide: Analyzing Output enable DoCap. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by capacity analysis, and are not the result of simulation. Operator Group Bottleneck Capacity Chart (With Product Capacity Data): This chart is similar to the Bottleneck Capacity Resource Chart (With Product Capacity Data: bar-chart format), except that only operator group resources are displayed. Operator groups are ranked according to Capacity Loading%. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, enable DoCap. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by capacity analysis, and are not the result of simulation. Operator Group Bottleneck Simulation Chart (Bars or Columns): This chart is similar to the Bottleneck Simulation Resource Chart, except that only operator group resources from the simulation run results are displayed. Operator groups are ranked according to Capacity Loading%. The default number of resources displayed is specified on the System Parameters dialog. To view data for a different period, or a different replication, use the AutoFilter. For the analysis run, enable DoSim. This chart is not available if NoPeriodOutput is enabled. All values on this chart are predicted by simulation analysis, and are not the result of capacity. WIP and Cycle Time by Period Chart: This chart displays average and maximum WIP / cycle time by analysis period. By default, this chart displays summary data for all products, for the first replication. To view data for a single product, or for a different replication, use the AutoFilter. For the analysis run, enable DoSim, RunLen, and StartDate (and DoCap if required). This chart will not be useful if you specify a single analysis period, or if you enable NoPeriodOutput. WIP and Cycle Time by Operation Chart: This chart displays simulation estimates for average unit WIP and cycle time by operation. The underlying data is estimated for individual process steps, and then aggregated for display by operation. This process works as follows. First, only steps that are contiguous within the process flow and which all specify the same operation will be aggregated together. This means that if operation 100 is specified for two steps in the process flow, but an intervening step specifies a different operation, then operation 100 will be listed twice on this report. Second, steps that do not specify an operation are treated as if they had specified the operation "(Empty)". Finally, cycle time is estimated directly via an average of actual lot cycle times; and unit WIP is estimated indirectly via Little's law (average unit WIP = unit arrival rate * average cycle time). By default, this chart displays data for the first product, period, and replication. To view data for a different product, period, or replication, use the
7.3. Output Charts AutoFilter. For the analysis run, enable DoSim and RunLen. This chart is not available if you enable NoPeriodOutput. Cycle Time by Lot Exit Time Chart: Factory Explorer splits the simulation run into one hundred equal time slices. For each time slice, it records the minimum, maximum, and average cycle time for lots that exit within that slice (scrapped lots are not included). This chart displays these results. By default, the chart displays data for the first replication and the first product in the model. To view an average across all replications, use the AutoFilter to set the replication to Summary. For the analysis run, enable DoSim and RunLen. Charts for individual replications are not available if NoRepOutput is enabled. Cycle Time Characteristic Curve Chart: This chart displays weighted average product cost and weighted average cycle time normalized by raw process time versus factory capacity loading%. Average product cycle times are weighted by unit throughput rate to produce a weighted average cycle time. Product raw process times are also weighted by unit throughput rate to produce a weighted average raw process time. The weighted average cycle time is divided by the weighted average raw process time to produce a normalized cycle time for the system. For the analysis run, enable Reps, DoCap, DoCost, DoSim, RunLen, ReleasePct, and AddPct. Or, you can enable ReleaseRate and AddRate in place of ReleasePct and AddPct. For models with individual lots, you must also enable DelLots to remove the individual lots. This chart will not be useful if you make a single replication, if you enable NoRepOutput, or if you enable UseSugg. Cycle Time Contribution by Tool Group Chart: For a selected product, this chart displays estimated cycle time contribution for each tool group. Tool groups are ranked from highest to lowest contribution. For each of these tool groups, the simulation estimates the number of times a typical lot would visit the tool group, then multiplies this estimate by the estimated tool group cycle time. This aggregate time gives a better picture of the overall product cycle time contributed by each tool group. For example, a tool group with a relatively high queue delay and service time (10 hours, say) may be visited only once during the process flow, while one with a much lower queue delay and service time (2 hours) is visited fifteen or even twenty times by a typical lot. In this case, the latter tool group ends up contributing more to the product's cycle time than the former tool group, and perhaps should be the first target for cycle time reduction efforts. By default, this chart displays data for the first replication, the first analysis period, the first product defined in the model, and the top ranked tool groups. The default number of tool groups displayed is specified on the System Parameters dialog. Use the AutoFilter to select a different replication, analysis period, product, or number of tool groups. To view trends across analysis periods, use the AutoFilter to set the period filter to (All), to set the rank filter to (All), and to select a single tool group. For the analysis run, enable DoSim and RunLen. This chart is not available if NoPeriodOutput is enabled. Copyright WWK 1995-2009 Factory Explorer 143
7. User's Guide: Analyzing Output Cycle Time Histogram: This chart displays a histogram for product cycle times. By default, this chart displays data for the first analysis period of the first replication, and for the first product defined in the model. Use the AutoFilter to select a different analysis period, replication, or product (select product All to display data aggregated for all products). For the analysis run, enable DoSim and RunLen. This chart is not available if NoRepOutput is enabled. Fixed Cost & Cycle Time vs. Suggested Capacity Loading% Chart: This chart displays total fixed cost (factory fixed costs plus all tool fixed costs) and cycle time versus suggested capacity loading%. This chart is meant to display the tradeoff between cycle time and fixed cost as the suggested capacity loading% is varied. For the analysis run, enable DoCap, DoCost, DoSim, RunLen, Reps, SuggLoading, AddSuggPct, and UseSugg. To vary the suggested capacity loading% for individual tool or operator groups, use the CBUFFER column (Excel models) or the CapacityBuffer statement (ASCII models). This chart will not be useful if you make a single replication, or if you enable NoRepOutput. Product Cost & Total Fixed Cost vs. Release Rate Chart: This chart displays product cost (a weighted average for all products by exit rate) and total fixed cost versus release rate, assuming a minimum cost toolset for each release rate. This chart is meant to display the tradeoff between total fixed cost and product cost as the release rate for the system is varied. For the analysis run, enable DoCap, DoCost, Reps, ReleaseRate, AddRate, and UseSugg. You must enable UseSugg so that Factory Explorer can select a minimum cost toolset for each start rate. Use SuggLoading to control the suggested capacity loading% Factory Explorer uses when selecting the minimum cost toolset. To vary the suggested capacity loading% for individual tool or operator groups, use the CBUFFER column (Excel models) or the CapacityBuffer statement (ASCII models). This chart will not be useful if you make a single replication, or if you enable NoRepOutput.
7.4 Custom Chart Wizard

General Comments: To access Factory Explorer's custom chart wizard, select Analyze Output from the FactoryX pull-down menu. On the resulting dialog, click on Custom Chart Wizard. Factory Explorer's custom chart wizard helps you quickly create a variety of output charts based on factory, product, tool, and operator outputs. In general, you choose the data type (product & summary data, tool group data, operator group data), x-axis variable and up to three variables for each of the left-hand and right-hand y-axes. Factory Explorer's custom chart engine does the rest. Since Factory Explorer generates several of its own charts using the custom chart engine, you can easily create customized versions of these charts using the chart wizard. This is also an easy way to learn about the custom chart wizard. Once you have gone through this customization process several times, you should be comfortable creating your own custom charts.
7.4. Custom Chart Wizard NOTE: When charting two or more variables against the same axis (left-axis or rightaxis), you are responsible for ensuring that it makes sense to plot the variables against a single axis. For example, it probably does not make sense to plot both WIP (measured in units, say), and cycle time (measured in days, say) against the same axis. Useful Custom Charts: Custom Cycle Time Characteristic Curve Chart: For the analysis run, enable Reps, DoCap, DoCost, DoSim, RunLen, ReleasePct, and AddPct. Or, you can enable ReleaseRate and AddRate in place of ReleasePct and AddPct. This chart will not be useful if you make a single replication, if you enable NoRepOutput, or if you enable UseSugg. To Create the Chart: On the custom chart dialog, set the data type to product & summary data, the x-axis variable to replication, and the additional x-axis attribute to factory capacity loading. Set the left-axis variable #1 to product cost, and the right-axis variable #1 to cycle time over raw process time. The resulting chart should look just like Factory Explorer's pre-defined chart (apart from the title that Factory Explorer adds to its pre-defined chart). Suggestions for Customization: Change the x-axis attribute to predicted release rate, or predicted throughput rate. Change the left-axis variable #1 to gross margin. Set the right-axis variable #2 to cycle time upper percentile, or to maximum cycle time. To look at a WIP characteristic curve, change the right-axis variable #1 to average unit WIP, and set the right-axis variable #2 to maximum unit WIP. Custom WIP and Cycle Time by Period Chart: For the analysis run, enable DoSim, RunLen, and StartDate (and DoCap if required). This chart will not be useful if you specify a single analysis period, or if you enable NoPeriodOutput. To Create the Chart: On the custom chart dialog, set the data type to product & summary data, the x-axis variable to analysis period, and the additional x-axis attribute to period start date. Set the left-axis variable #1 to average unit WIP, the left-axis variable #2 to maximum unit WIP, the right-axis variable #1 to average cycle time, and the right-axis variable #2 to maximum cycle time. The resulting chart should look just like Factory Explorer's pre-defined chart (apart from the title that Factory Explorer adds to its pre-defined chart). Suggestions for Customization: Change the x-axis attribute to factory capacity loading (if DoCap enabled). Change the right-axis variable #2 to cycle time upper percentile. Custom Fixed Cost & Cycle Time vs. Suggested Capacity Loading% Chart: For the analysis, enable DoCap, DoCost, DoSim, RunLen, Reps, SuggLoading, AddSuggPct, and UseSugg. This chart will not be useful if you make a single replication, or if you enable NoRepOutput. Copyright WWK 1995-2009 Factory Explorer 145
7. User's Guide: Analyzing Output To Create the Chart: On the custom chart dialog, set the data type to product & summary data, the x-axis variable to replication, and the additional x-axis attribute to suggested capacity loading. Set the left-axis variable #1 to total fixed cost, and the right-axis variable #1 to cycle time over raw process time. The resulting chart should look just like Factory Explorer's pre-defined chart (apart from the title that Factory Explorer adds to its pre-defined chart). Suggestions for Customization: Change the x-axis attribute to product cost. Change the left-hand axis variable #1 to gross margin. Change the right-hand axis variable #1 to average cycle time, or to cycle time upper percentile, or to maximum cycle time. Custom Product Cost & Total Fixed Cost vs. Release Rate Chart: For the analysis, enable DoCap, DoCost, Reps, ReleaseRate, AddRate, and UseSugg. This chart will not be useful if you make a single replication, or if you enable NoRepOutput. To Create the Chart: On the custom chart dialog, set the data type to product & summary data, the x-axis variable to replication, and the additional x-axis attribute to predicted release rate. Set the left-axis variable #1 to product cost, and the right-axis variable #1 to total fixed cost. The resulting chart should look just like Factory Explorer's pre-defined chart (apart from the title that Factory Explorer adds to its pre-defined chart). Suggestions for Customization: Change the x-axis attribute to predicted throughput rate. Change the left-hand axis variable #1 to gross margin.
7.5 Output Reports

General Comments: To access Factory Explorer's pre-defined output reports, select Analyze Output from the FactoryX pull-down menu. On the resulting dialog, click on Open Reports File. This action will open the default text editor to view the output reports file. Factory Explorer's text-based output reports contain only information about the input model. All capacity analysis and simulation results are contained in output worksheets and charts. Individual Output Reports: Factory Information Report: This report shows the aggregate time the factory is scheduled for operation. Product Information: Parts I, II, and III: For each product and effective date, these reports show the average lot size at release, average lot priority, setting of the constant-WIP flag, number of release patterns, release wrap policy, process name, due-date offset distribution, lead time factor, maximum nesting of rework levels, unit start rate (if specified directly in model), unit throughput rate (if specified
7.5. Output Reports directly in input model), and cost data. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Tool Group / Operator Group Cross-Reference Report: For each tool group, this report lists the operator group(s) that serve it. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Operator Group / Tool Group Cross-Reference Report: For each operator group, this report lists the tool group(s) it serves. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Tool Group Information: Parts I and II: For each tool group and effective date, these reports show the type (see the documentation for the Bottleneck Resource Report), interruption information, dispatch rule, avoid setups flag, load%, processing%, unload% values, layout area, and cost data. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Tool Group Batch Information Report. For each batch tool group, this report displays the tool's batch I.D.'s. This report displays batch I.D.'s before wildcards are expanded. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Tool Group Setup Information Report. For each tool group with setup, this report displays a list of setup groups and I.D.'s defined for the tool group along with the mean setup time. This report displays setup I.D.'s before wildcards are expanded. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Operator Group Information Report. For each operator group, this report shows dispatch, interruption and cost information. Information on this report comes directly from the model, and is not the result of capacity analysis or simulation. Process Information: For each process, this report shows the number of process steps and the name of all products that use the process. Dispatch Rules Information Report: This report lists information for dispatch rules, including rule status (active or inactive), whether or not the rule is used in the model, rule type (static or dynamic), whether or not the rule is priority-based, and rule description. As user-supplied dispatch rules may be customized by users between analysis runs, this report is useful for recording exactly which rules were in effect for a particular analysis. Yes/No Run-Time Options: This report lists default values and current settings for the Factory Explorer on / off run-time options. Copyright WWK 1995-2009 Factory Explorer 147
7. User's Guide: Analyzing Output Numeric Run-Time Options: This report lists default values and current settings for the Factory Explorer numeric run-time options. String Run-Time Options: This report lists default values and current settings for the Factory Explorer alphanumeric run-time options.
8. User's Guide: Including Ramp Data in a Factory Explorer Model
8.1 Introduction
The Factory Explorer models presented thus far are similar in the fact that data specified for the factory does not change during the analysis run. In many cases, however, this assumption of static input data is too restrictive. For example, consider the problem of toolset planning for a factory that is ramping up production. Over a period of several months, quarters, or years, the factory is going to be significantly changing the volume of production for one or more products. These changes in volume determine the minimum required toolset at different times. It is possible to build multiple Factory Explorer models, one for each period of interest, and perform separate analysis runs. But this approach requires that all portions of the model input data be duplicated. Then, if a change occurs to any part of the model data (e.g. a process flow change, or a tool availability assumption), all of the various input models must be updated. To avoid these problems, Factory Explorer allows you to model the complete factory ramp in a single model. This approach means fewer data maintenance hassles, and significant increases in analysis productivity. This chapter presents the methodology used when modeling ramp data with Factory Explorer. Sections 8.2, 8.3, 8.4, and 8.5 present ramp data examples for products, tools, operators, and process steps. These examples are drawn from the Aspen.xls model included with Factory Explorer. Section 8.6 covers common ramp data notes.
8.2 Example: Ramping Product Data

Factory Explorer's sample Aspen.xls model ramps several product attributes. For example, product Wafer1's start rate is ramped from 150 units per week at startup to 500 units per week on October 1st, 2002. Figure 8-1 displays relevant columns from the products worksheet. Notice that product attributes are specified for each definition of Wafer1, even if the attributes are not changing (e.g. product priority, number of units per lot, process flow). The entire object is duplicated for each effective date for which there is a change.
Figure 8-1: Products worksheet, Aspen model. The start rate for product Wafer1 is ramped from 150 units per week at startup to 500 units per week on October 1st, 2002. Throughout this sample model, data from different effective dates is colored for easier comprehension.
8.3. Example: Ramping Tool Data
8.3 Example: Ramping Tool Data

Factory Explorer's sample Aspen.xls model ramps tool quantities and downtime characteristics. For example, tool group C1-9 initially contains a single tool, but on July 1st, 2001, a second tool is added. Figure 8-2 displays relevant columns from the tools worksheet. If you analyze this model with Factory Explorer for the 2002 time frame, you will discover that many other tools need to be added for capacity purposes during 2002. Factory Explorer can tell you when additional tools will be needed for each tool group, for a specified capacity loading %. As with ramp data for products, notice that all tool group attributes are specified for each definition of tool group C1-9. Note, however, that only tool groups where something has changed need to be specified.
Figure 8-2: Tools worksheet, Aspen model. Tool group C1-9 initially contains a single tool, but on July 1st, 2001, a second tool is added
8.4 Example: Ramping Operator Data

Factory Explorer's sample Aspen.xls model ramps operator quantities and wage rate characteristics. For example, operator group D1-9 initially contains a single operator, but on July 1st, 2001, a second operator is added. Operator group C1-9 initially has a wage rate of $20/hour, but on July 1st, 2001 this wage rate is increased. Figure 8-3 displays some of the relevant columns from the operators worksheet. As with tool groups, if you analyze this model for 2002, you will discover that many additional operators are required for capacity.
Figure 8-3: Operators worksheet, Aspen model. Operator group D1-9 initially contains a single operator, but on July 1st, 2001, a second operator is added.
8.5. Example: Ramping Process Step Data
8.5 Example: Ramping Process Step Data

Factory Explorer's sample Aspen.xls model ramps process times and alternative step percentages. For example, step A05_26_Phosw_Align in process A initially specifies a per-unit time of one minute (0.016667 hours = 1 minute), but on July 1st, 2001, the time is lowered to 0.8 minutes (0.013333 hours). Figure 8-4 displays relevant columns from the process flow worksheet.
Figure 8-4: Process flow worksheet, Aspen model. Step A05_26_Phosw_Align initially specifies a per-unit time of one minute (0.0166667 hours), but on July 1st, 2001, the per-unit time is changed to 0.8 minutes (0.013333 hours).
8. User's Guide: Including Ramp Data in a Factory Explorer Model Ramping of alternative process step data can be tricky. There is a logical method to it, however. The idea is to keep all of the effective date entries for a particular alternative together. For each alternative process step, first specify the startup definition (if any) for the first alternative, and immediately follow that with any ramped definitions of the step. Once you have specified all of the ramped definitions of the first alternative step, specify the startup definition (if any) for the second alternative, and so forth. For example, step A09_26_Phosw_Bk_etch in process A initially specifies alternative step percentages of 75%, 15%, and 10% for the three alternatives, but on April 1st, 2001, the alternative step percentages change to 50%, 25%, and 25%.Therefore, the first alternative is listed with rows for 75% and 50%, followed by the second alternative with rows for 15% and 25%, etc. Figure 8-5 displays relevant columns from the process flow worksheet.
Figure 8-5: Process flow worksheet, Aspen model. Step A09_26_Phosw_Bk_etch initially specifies alternative step percentages of 75%, 15%, and 10% for the three alternatives, but on April 1st, 2001, the alternative step percentages change to 50%, 25%, and 25%.
8.6 Ramp Data Notes

This section presents general notes on Factory Explorer's ramp data functionality. The method used to ramp product, tool, operator, and process step data is the same. In particular, any of these Factory Explorer objects can be ramped. Ramping simply means that an object's attributes vary over time. Thus, a product can have one start
8.6. Ramp Data Notes rate when the analysis run starts, but a different start rate later in the analysis run. Or, the number of tools in a tool group can change as tools are added to or removed from the factory. To ramp an object, simply re-specify the entire object definition with a new effective date. For example, suppose the start rate for product P1 is initially 250 units per week, but on July 1st, 2001, the start rate will change to 500 units per week. To model this situation with Factory Explorer, include one definition for P1 that specifies a start rate of 250 units per week. Right below this first definition of P1, specify one more definition of P1 with a start rate of 500 units per week, but enter an effective date for the second definition of July 1st, 2001. Factory Explorer will keep track of which definition should be effective at any given time, and will automatically switch to the appropriate definition as required. If an object definition does not specify an effective date, Factory Explorer assumes that this definition is active at startup. The startup definition may not be active at the start of the analysis run, however, if a later definition specifies an effective date prior to the start of the analysis run. For example, if the first definition of product P1 does not specify an effective date, and the second definition specifies a July 1st, 2001, effective date, an analysis run with a start date of November 1st, 2001, will use the latter definition. An analysis run with a start date of January 1st, 2001 would use the startup definition. If the first definition of an object specifies an effective date, Factory Explorer assumes there is no startup definition for the object, and it creates an empty startup definition that is used as a placeholder (it includes the object name but no other object attributes). Each definition of an object must specify all appropriate attributes. That is, Factory Explorer does not automatically pull forward, or default, attributes from an earlier definition of an object to a later definition. If the first definition of product P1 specifies a raw material cost of $100 per unit, but the second definition (effective July 1st, 2001) does not specify any raw material cost, Factory Explorer will not assume that the $100 per unit raw material cost is still appropriate for the later definition. The raw material cost for P1 will, effective July 1st, 2001, drop to zero. Factory Explorer does not automatically pull data forward because that could easily lead to data maintenance and interpretation complexity if many object definitions exist (say one definition for each month in a year). It is a good idea to specify all definitions of an object sequentially, ordered by effective dates. In some instances Factory Explorer allows you to specify the definitions of an object non-sequentially, or with effective dates not in order, but the result is generally a model that is hard to maintain and hard to understand. Future releases of Factory Explorer may enforce this rule as a model validation check. It can be helpful to use color when building a complex Factory Explorer Excel model with many effective dates. For example, you can choose a particular color for each effective date (green for Q1/2001, blue for Q2/2001, etc). Consistently coding all object definitions that have similar effective dates with the same color makes the model easier to grasp visually. Factory Explorer does not use the color information, however.
8. User's Guide: Including Ramp Data in a Factory Explorer Model When ramping data in a Factory Explorer model, any object can be ramped on any date. However, you should probably select a sub-set of available dates, and only make changes on those dates. For example, you might only allow changes on the first of every month. There are two reasons for this recommendation. First, your model will be difficult to understand and maintain if you have many different objects changing at arbitrary dates. Second, Factory Explorer validates the entire model every time a data object changes. Although validation is quite fast, going through it hundreds of times for a run would likely slow down the run. In the majority of cases, all object attributes can be ramped. As much as possible, Factory Explorer allows objects to change without restriction. Several restrictions exist, however: A product must maintain the same basic type (release product, end product, assembled product, transformed product, etc.) at all effective dates. The number of resources in a resource group (a tool or operator group) cannot be specified as infinite at some effective dates, and finite at other effective dates. Hold tool regions and split lot regions are subject to several ramp data restrictions see Sections 9.15 and 9.16 of the manual for more information. Rework steps are subject to several ramp data restrictions see Section 5.3.1 of the manual for more information. Factory Explorer performs extensive model validation for model startup and for all effective dates specified in the model. Thus, Factory Explorer will detect model validation errors that occur outside the period of analysis. For example, if an analysis run has a start date of January 1st, 2001 and a run length of four quarters, Factory Explorer will still flag all validation errors, even those that occur before January 1st, 2001, or after December 31st, 2001. Analyzing models that contain ramp data can be very complicated, in part because changes in data can lead to ambiguous situations. In situations where the model data could be interpreted in multiple fashions, Factory Explorer attempts to operate in a way that is straight-forward and reasonably intuitive. For example: If the process flow for a product changes within a simulation run, this change only affects lots that are released after the effective date. Lots that were released prior to the effective date and that are still in the factory continue to follow the same process flow upon which they were released. If the time to interrupt or time offline distribution for a tool group or operator group changes within a simulation run, this change only affects interrupts that occur after the effective date. If a tool is up, the new time offline distribution will take effect upon the next interrupt, after which the new time to interrupt distribution will take effect. If a tool is offline for a clock-type interrupt, the new time to interrupt distribution will take effect when the current offline time ends, after which the new time offline distribution will take effect. If a tool is offline for a between-type interrupt, the new time to interrupt distribution and the new time offline distribution will only take effect upon the next interrupt.
8.6. Ramp Data Notes If a tool or operator group interruption is deleted within a simulation run, any offline time that is in progress at the effective date will continue to normal completion, but no more interrupts will occur after the effective date. If a tool or operator group interruption is added within a simulation run, the time to first interrupt attribute applies, and is calculated forward from the effective date rather than the start of the simulation. Factory Explorer uses interrupt names to determine if interrupts have been added or deleted, so changing the name (e.g. RandFailure to RandomFailure) will cause Factory Explorer to delete the RandFailure interrupt and add a new RandomFailure interrupt.
9. User's Guide: Additional Modeling Capabilities
9.1 Introduction
In this chapter, we consider a selection of modeling capabilities not discussed in detail in prior chapters. These capabilities include: batch processing (Section 9.2) equipment downtime (Section 9.3) splitting units at process completion (Section 9.4) binning units at process completion (Section 9.5) assembly (Section 9.6) adjustable transform and assembly percentages (Section 9.7) hot lots (Section 9.8) factory schedules (Section 9.9) process step goto's (Section 9.10) individual lots (Section 9.11) cost / revenue analysis (Section 9.12) space / layout analysis (Section 9.13) alternative steps (Section 9.14) holding tools across multiple process steps (Section 9.15) splitting and recombining lots within a process (Section 9.16) controlling the order of simultaneous check-request events (Section 9.17) modeling complex setups (Section 9.18) cluster tool modeling (Section 9.19) tool group buffers (Section 9.20) alternate operator groups and work schedules (Section 9.21) merging process flows from a SQL Server database (Section 9.22)
9.2 Batch Processing and Batch I.D.'s

9.2.1 Introduction A batch tool has the capacity to process units from more than one lot at a time. However, it is often the case that several processing steps use the same batch tool, but lots from these different processing steps cannot be processed together at the tool. This situation can arise when multiple passes through a furnace-type batch tool are necessary for a product, but different temperatures are required for different phases of production. It may also be necessary to restrict maximum batch sizes at different points in the process flow to ensure temperature uniformity or other processing characteristics. Both of these types of restrictions arise in semiconductor manufacturing. To model this situation, use batch I.D.'s. Each batch tool must have at least one batch I.D. defined at the tool group level; each batch I.D. specification gives a batch I.D. name and minimum and maximum batch sizes. Minimum and maximum batch sizes are given in terms of units or lots. Each processing step using a batch tool requires the specification of a batch I.D. At batch tools, Factory Explorer will not form batches containing lots waiting at steps with different batch I.D.'s. Since the minimum and maximum batch sizes are specified at the tool group level along with the batch I.D., this necessarily enforces that these parameters will be the same for all steps using a similar batch I.D. However, processing times and operator requirements specified at different steps with the same tool and batch I.D. must be consistent. Otherwise, Factory Explorer will flag the situation as an error. For details on the mechanics of batch formation and batch processing times, see Section 4.4. In a complicated process flow, a batch tool may occur in many process steps. If the operating rule for the tool is that lots can only be batched together if they belong to the same product, process, operation, or process step, then many different batch I.D.'s may be necessary. To automate this process, Factory Explorer allows batch I.D.'s to include wildcards. Wildcards can be embedded in batch I.D. names to ease the modeling of complicated batching rules. The following sections present a series of sample models that illustrate batch tool modeling in Factory Explorer. Section 9.2.2 presents a very simple model of batch processing. Section 9.2.3 presents a model that uses the %Product wildcard to restrict batch formation to a single product. Section 9.2.4 presents a model that uses the %Process wildcard to restrict batch formation to a single process. Section 9.2.5 presents a model that uses the %Operation wildcard to restrict batch formation to a single operation I.D. Section 9.2.6 presents a model that uses the %Process and %Step wildcards to restrict batch formation to a single product and process step. Section 9.2.7 presents a model that uses wildcards embedded within batch I.D.'s to vary the minimum and maximum batch sizes at different process steps, while still restricting batch formation to a single process and process step. 9.2.2 Example: Simple Batch Processing This section presents a simple model of batch processing. This model includes a single product, a single process flow (consisting of one process step), and a single tool group
9.2. Batch Processing and Batch I.D.'s containing one batch tool. Incoming lots, TWafers, follow the process flow WFlow-1. TWafers travel through the factory in 25 wafer lots. The number of wafers per lot only affects batching insofar as Factory Explorer does not normally process wafers from a single lot in more than one batch. For details on the batch formation process, see Section 4.4. The sole process step in this process flow, Bake22A, models the baking of wafers in a batch tool, Oven22. This oven can be loaded with up to 200 wafers for a single operation. Although there is no technology-imposed lower limit on the number of wafers that can be processed at one time, management has set an operational rule that a batch should not be started unless at least 50 wafers can be processed. The oven requires 8 hours to process a batch. The Excel model for this example is batchit1.xls. The products and operators worksheets do not contain details specific to batch processing, so we do not display them here. Figure 9-1 displays the tools worksheet; Figure 9-2 displays the process flow worksheet.
Figure 9-1: Tools worksheet, batchit1 model. A single batch I.D. has been defined for the tool group. This batch I.D. restricts batches to have a minimum of 50 units and a maximum of 200 units. Minimum and maximum batch sizes are assumed to be in terms of units, unless the BSLOTS column is marked.
At the tool group level, a single batch I.D., ID1, is defined for Oven22. This I.D. specifies that the minimum number of units (wafers) in a batch is 50, and the maximum number is 200. Whenever a process step specifies that it uses Oven22, it must also specify which batch I.D. is to be used. In this case there is only one choice.
Figure 9-2: Process flow worksheet, batchit1 model. The batch process step must specify both a process time and a batch I.D.
At the process step level, the Bake22A process step uses Oven22 for processing. Since Oven22 is a batch tool, the step must also specify a batch processing time (8 hours in this case), and a batch I.D. (ID1). From this information, Factory Explorer can then determine which lots can be batched together for processing at Oven22 (only those waiting at process steps having the same batch I.D.), how long the batch processing takes (8 hours), and the minimum and maximum allowable batch sizes (50 and 200 wafers, respectively). This method of batch I.D. definition works fine for small models, but quickly becomes difficult when creating much larger models. To handle these more complex scenarios, Factory Explorer allows batch I.D.'s to contain wildcards. Batch I.D. wildcards are the focus of the next several sample models. 9.2.3 Example: Restricting Batches to a Single Product with the %Product Wildcard Modeling batch processing quickly becomes tedious if a system includes many batch tools, or complicated batch formation logic. For example, many different products may use the same process flow, but lots from different product types cannot be batched together. Or, many different steps may use the same batch tool, but lots from different steps cannot be batched together. Using only simple batch I.D.'s, these situations require the creation and maintenance of many different batch I.D.'s. To simplify this modeling 162 Factory Explorer Copyright WWK 1995-2009
9.2. Batch Processing and Batch I.D.'s task, Factory Explorer allows batch I.D. names to include wildcards. Wildcards sharply reduce the need to create many different batch I.D.'s, making complex models easier to develop, debug, and maintain. Within a batch I.D., Factory Explorer allows the use of four wildcards: %Product, %Process, %Operation, and %Step. Wildcards are not case sensitive, and can appear anywhere in the I.D. Multiple wildcards can appear in a single I.D. This section presents a sample model that uses the %Product wildcard. Later sections present sample models that use the %Process, %Operation, and %Step wildcards. The sample for this section extends the batchit1 model described in the previous section. There are now two products, TWafers and SWafers. Both products use the same process flow, WFlow-1. A single tool group containing one batch tool performs all processing. The sole process step, Bake22A, models the baking of wafers at the tool, Oven22. This oven can be loaded with up to 200 wafers for a single operation. Management has set an operating rule that a batch should not be started unless at least 50 wafers can be processed. The oven requires 8 hours to process a batch. Due to technical constraints, wafers from the two different products cannot be batched together for processing. The Excel model for this example is batchit2.xls. The products and operators worksheets do not contain details specific to batch processing, so we do not display them here. Figure 9-3 displays the tools worksheet; Figure 9-4 displays the process flow worksheet.
Figure 9-3: Tools worksheet, batchit2 model. The %Product wildcard indicates that unique batch I.D.'s should be generated for each product using the tool group. These I.D.'s will simply be the individual product name.
At the tool group level, a single batch I.D. is defined for Oven22. This batch I.D., however, uses the %Product wildcard. When Factory Explorer reads in the model, it will do the work of generating a list of batch I.D.'s for this tool group, with one unique batch I.D. for each product that is processed on Oven22. Since the %Product wildcard appears alone, these unique batch I.D.'s will be created by simply taking each product's name and using it as a batch I.D.
9.2. Batch Processing and Batch I.D.'s
Figure 9-4: Process flow worksheet, batchit2 model. The %Product wildcard indicates that Factory Explorer should use the product name of a lot as its batch I.D. The result is that different products will not be batched together.
At the process step level, the %Product wildcard is used as the batch I.D. After the model has been read, Factory Explorer creates a list of batch I.D.'s by product and process step. Since the %Product wildcard appears alone as the batch I.D., Factory Explorer will simply use each product's name as the batch I.D. The end result is that different products, when processed at step Bake22A, have different batch I.D.'s, and thus will not be batched together. A similar method can be used when batches are restricted to a single process. The next section presents an example that uses the %Process wildcard to model restriction of batches to a single process. 9.2.4 Example: Restricting Batches to a Single Process with the %Process Wildcard When several different processes use the same batch tool, the operating rule may be that lots from different processes cannot be batched together. To quickly model this behavior, use the %Process batch I.D. wildcard. This section presents a sample model that uses this wildcard to restrict batch formation to a single process. The sample for this section extends the batchit2 model described in the previous section, by adding a third product, QWafers. This new product uses a separate process flow, WFlow-2. A single tool group containing one batch tool performs all processing. The sole process step in both process flows, Bake22A, models the baking of wafers at the
9. User's Guide: Additional Modeling Capabilities tool, Oven22. This oven can be loaded with up to 200 wafers for a single operation. Management has set an operating rule that a batch should not be started unless at least 50 wafers can be processed. The oven requires 8 hours to process a batch of TWafers or SWafers, but requires 12 hours to process a batch of QWafers (due to a higher temperature requirement). Due to technical constraints, TWafers and SWafers can be batched together, but neither can be batched with QWafers. In this case, only wafers that follow the same process flow can be batched together. The Excel model for this example is batchit3.xls. The products and operators worksheets do not contain details specific to batch processing, so we do not display them here. Figure 9-5 displays the tools worksheet; Figure 9-6 and Figure 9-7 display the process flow worksheets.
Figure 9-5: Tools worksheet, batchit3 model. The %Process wildcard indicates that unique batch I.D.'s should be generated for each process using the tool group. These I.D.'s will simply be the individual process names
At the tool group level, a single batch I.D. is defined for Oven22. This batch I.D. uses the %Process wildcard. When Factory Explorer reads in the model, it will generate a list of batch I.D.'s for this tool group, with one unique batch I.D. for each process that uses Oven22. Since the %Process wildcard appears alone, these unique batch I.D.'s will be created by simply taking each process name and using it as a batch I.D.
Figure 9-6: Process flow worksheet, batchit3 model, process WFlow-1. The %Process wildcard indicates that Factory Explorer should use the process flow name (WFlow-1) as the batch I.D. for lots at this step.
At the process step level for process flow WFlow-1, the %Process wildcard is used as the batch I.D. After the model has been read, Factory Explorer creates a list of batch I.D.'s by product and process step. Since the %Process wildcard appears alone as the batch I.D., Factory Explorer will simply use the process flow name as the batch I.D. All lots that use this process flow (TWafers and SWafers) will have the same batch I.D. (WFlow-1), and thus will be batched together.
Figure 9-7: Process flow worksheet, batchit3 model, process WFlow-2. Specifying the %Process wildcard as the batch I.D. for this step indicates that Factory Explorer should use the process flow name as the batch I.D.
For process flow WFlow-2, the %Process wildcard is also used as the batch I.D. Factory Explorer will use the process flow name as the batch I.D. All lots that use this process flow (QWafers) will have the same batch I.D. (WFlow-2), and thus will be batched together. Thus, by using the %Process wildcard as a batch I.D., it is possible to easily specify that only lots using the same process flow may be batched together. If batching must be restricted to steps within a process flow with the same operation I.D., the %Operation wildcard can be used. The next section presents an example that uses this wildcard to model restriction of batches to a single operation I.D. 9.2.5 Example: Restricting Batches to a Single Operation with the %Operation Wildcard Steps with similar processing requirements are often tagged with the same operation I.D. In this case, batching lots from different steps may only be allowed if the steps have the same operation I.D. To model this situation, use the %Operation batch I.D. wildcard. This section presents a sample model that uses the %Operation wildcard to restrict batching to steps having the same operation I.D. The sample model in this section extends the batchit1 model presented previously. A single product, TWafers, follows the process flow WFlow-1. During this process, the wafers are processed three separate times on the batch tool Oven22. The first
9.2. Batch Processing and Batch I.D.'s two visits are very similar operations, and are tagged with the same operation I.D., Op210. The third visit has a slightly different processing time, and is tagged with the operation I.D. Op310. Wafers waiting for Op210 can be batched together, as can wafers waiting for Op310, but wafers for different operations cannot be batched together. The Excel model for this example is batchit4.xls. The products and operators worksheets do not contain details specific to batch processing, so we do not display them here. Figure 9-8 displays the tools worksheet; Figure 9-9 displays the process flow worksheet.
Figure 9-8: Tools worksheet, batchit4 model. The %Operation wildcard indicates that a unique I.D. should be generated for each Operation I.D. processed on this tool.
At the tool group level, the model specifies a single batch I.D. This batch I.D. uses the %Operation wildcard. After the model is read, Factory Explorer will generate a unique list of batch I.D.'s for operation I.D. processed on this tool. For the batch I.D. name, Factory Explorer will use the Operation I.D.
Figure 9-9: Process flow worksheet, batchit4 model. Specifying the %Operation wildcard as the batch I.D. for these steps indicates that Factory Explorer should use the Operation I.D. as the batch I.D.
In this process flow, steps Bake22a and Bake22b specify the same operation, Op210. Since these steps use the %Operation wildcard as the batch I.D., these steps will have the same batch I.D., Op210, and hence can be batched together. Step Bake22c, however, specifies a different operation, Op310. Since this step uses the %Operation wildcard for the batch I.D., it has a different batch I.D. and cannot be batched with the first two steps. Thus, by using the %Operation wildcard, it is possible to easily specify that only lots waiting for steps with the same Operation I.D. may be batched together. Note, however, that Factory Explorer only processes lots together in a batch if they share the same batch processing time. If you assign the same Operation I.D. to steps that have different process time requirements, Factory Explorer will flag the situation as an error. In the examples shown thus far, a single wildcard has been used as the batch I.D. Factory Explorer also allows the use of combined wildcards, however. The next section presents a sample model that uses combined wildcards to restrict batching to a single product and process step. . 9.2.6 Example: Restricting Batches to a Single Product and Step with the %Product and %Step Wildcards When many different products and process steps use the same batch tool, technology considerations may require that only lots of the same product type and process step can be batched together. To model this behavior, Factory Explorer allows a multiple batch 170 Factory Explorer Copyright WWK 1995-2009
9.2. Batch Processing and Batch I.D.'s I.D. wildcards to be combined. This section presents a sample model that uses the %Product and %Step wildcards to restrict batch formation to a single product type and process step. The sample model for this section is a variation on the sample models from previous sections. Two products, TWafers and SWafers, are processed on a single process flow, WFlow-1. A single tool group containing one batch tool performs all processing. The process flow contains two process steps, Bake22A and Bake22B. Both of these process steps use the same batch tool, Oven22. In actual process flows, there would be other process steps between Bake22A and Bake22B, but for demonstration purposes we need only these two steps. The oven can be loaded with up to 200 wafers for a single operation. Management has set an operating rule that a batch should not be started unless at least 50 wafers can be processed. The oven requires 8 hours to process a batch at step Bake22A, and 10 hours to process a batch at step Bake22B. Due to technical constraints, TWafers and SWafers cannot be batched together, and lots at the two different bake steps cannot be batched together (the steps require different processing times). Thus, only lots having the same product type and process step can be batched together. The Excel model for this example is batchit5.xls. The products and operators worksheets do not contain details specific to batch processing, so we do not display them here. Figure 9-10 displays the tools worksheet; Figure 9-11 displays the process flow worksheet.
Figure 9-10: Tools worksheet, batchit5 model. The combination of the %Product and %Step wildcards indicates that a unique I.D. should be generated for each product / process step combination that uses this tool.
At the tool group level, the model specifies a single batch I.D. This batch I.D. is a combination of the %Product and %Step wildcards. After the model is read, Factory Explorer will generate a list of unique batch I.D.'s for each product / process step combination that uses the oven. The batch I.D.'s will be formed by concatenating the product name and the process step name.
Figure 9-11: Process flow worksheet, batchit5 model. Combining the %Product and %Step wildcards in the batch I.D. indicates that Factory Explorer should concatenate a lot's product name and its process step in order to form its batch I.D.
At the process step level, the batch I.D. for each step is simply specified as %Product%Step. The combination of these two wildcards tells Factory Explorer that batch I.D.'s for lots at these steps should be formed by concatenating the lot's product name with the process step name. In this way, a unique batch I.D. is generated for each product / process step combination. Since only lots with the same batch I.D. can be batched together, this model restricts batch formation to lots having the same product type and process step. One complication that could arise is that steps Bake22A and Bake22B do not have the same minimum or maximum batch size. For instance, if step Bake22B is a particularly sensitive process, it may not be possible to fully load the oven and still achieve acceptable production quality. The next section presents a sample model that uses embedded wildcards to handle this situation. 9.2.7 Example: Varying Batch Sizes at Process Steps with Embedded Wildcards In the sample models presented in prior sections, batch I.D. wildcards have always appeared alone in the batch I.D. specification. Wildcards do not have to appear alone, however. If necessary, wildcards can be embedded along with other text in the batch I.D. A situation where this technique is useful is the case where minimum or maximum batch
9. User's Guide: Additional Modeling Capabilities sizes vary across different process steps using the same batch tool. This section presents a sample model that uses embedded wildcards to model this behavior. The sample for this section is a slight modification of the batchit5 model in the previous section. Two products, TWafers and SWafers, are processed on a single process flow, WFlow-1. A single tool group containing one batch tool performs all processing. The process flow contains two process steps, Bake22A and Bake22B. Both of these process steps use the same batch tool, Oven22. The oven can be loaded with up to 200 wafers for the Bake22A operation, but only 175 wafers for the Bake22B operation (due to temperature sensitivities in the process used at this step). Management has set an operating rule that a batch should not be started unless at least 50 wafers can be processed. The oven requires 8 hours to process a batch at step Bake22A, and 10 hours to process a batch at step Bake22B. Due to technical constraints, TWafers and SWafers cannot be batched together, and lots at the two different bake steps cannot be batched together (the steps require different processing times). The Excel model for this example is batchit6.xls. The products and operators worksheets do not contain details specific to batch processing, so we do not display them here. Figure 9-12 displays the tools worksheet; Figure 9-13 displays the process flow worksheet.
Figure 9-12: Tools worksheet, batchit6 model. %Product and %Step wildcards have been embedded in the batch I.D.'s. For each product / process step that uses the oven, Factory Explorer will create a unique list of batch I.D.'s by substituting in the product name and process step name for the %Product and %Step wildcards.
9.2. Batch Processing and Batch I.D.'s At the tool group level, the model specifies two batch I.D.'s. Each of these batch I.D.'s include the %Product and %Step wildcards. However, each batch I.D. includes additional text after the wildcards (the .200 and the .175). After the input model is read, Factory Explorer examines every product / process step combination that uses the oven. For each step, it expands the batch I.D. specified at the process step level (by substituting in for any wildcards), and compares the results against similarly expanded batch I.D.'s specified at the tool group level. Whenever it finds a match, it records the uniquely expanded batch I.D. at the tool group level. In this model, four unique batch I.D.'s will be created for the oven: 1. 2. 3. 4. TWafersBake22A.200 TWafersBake22B.175 SWafersBake22A.200 SWafersBake22B.175
Batch I.D. wildcards can appear anywhere within the batch I.D. The additional text (the .200 and the .175) has no special meaning for Factory Explorer. Since a batch I.D. must specify a unique minimum and maximum batch size, each unique batch size that is possible (200 and 175 wafers) requires a separate batch I.D. In this case, it is useful to append the maximum batch size to the end of the batch I.D. so that it will be easy for you to recognize each step's maximum batch size when scanning through the process flow.
Figure 9-13: Process flow worksheet, batchit6 model. %Product and %Step wildcards are embedded within the batch I.D.'s. For each product / process step combination, Factory Explorer expands the batch I.D. by substituting in the product name and process step name for the wildcards.
At the process step level, step Bake22A specifies the batch I.D. %Product%Step.200, while step Bake22B specifies the batch I.D. %Product%Step.175. Factory Explorer expands these batch I.D.'s by substituting in for the wildcards. In this way, a unique batch I.D. is generated for each product / process step combination. Since only lots with the same batch I.D. can be batched together, this model restricts batch formation to lots having the same product type and process step. By embedding the wildcards in the batch I.D. along with extra text (the .200 and the .175), the model specifies that different batch I.D. definitions apply to the two separate process steps. Again, note that this extra text does not have any special meaning for Factory Explorer. In particular, it is not does not immediately specify the minimum or maximum batch size that information is specified in the batch I.D. definition at the tool group level. Since the %Product%Step.200 and %Product%Step.175 batch I.D.'s are defined to have maximum batch sizes of 200 and 175 wafers, respectively, lots processed at step Bake22A will have a maximum batch size of 200 wafers, while those processed at step Bake22B will have a maximum batch size of 175 wafers. Thus, by embedding wildcards within batch I.D.'s, it is possible to vary the minimum or maximum batch size across process steps that use the same tool, while still modeling sophisticated batch formation rules.
9.3. Equipment Downtime (Failures, Preventive Maintenance, Engineering, etc.)
9.3 Equipment Downtime (Failures, Preventive Maintenance, Engineering, etc.)

9.3.1 Introduction Equipment downtime is modeled in Factory Explorer with interruptions. Interruptions are events that occur at a tool that cause the tool to be unavailable for processing for a period of time. Section 9.3.2 presents a short background on Factory Explorer interruptions. Although interruptions can be used to model many different kinds of equipment downtime, three in particular are commonly included in factory models: failures (nonscheduled maintenance), preventive maintenance (scheduled maintenance), and engineering time (time when equipment is being used for engineering test, process development work, etc.) Section 9.3.3 presents a simple model that includes these three types of equipment downtime. 9.3.2 Background on Interruptions Interruptions are specified in Factory Explorer models at the tool group level, and can be one of five types: Between, Clock, Busy, Units, or GroupClock. These types vary in the method used to determine the time between interruptions, and the number of interrupt processes running at a tool group. An interrupt process is the mechanism inside Factory Explorer's simulation engine that is responsible for generating interruptions at a tool. If a separate interruption process is running for each tool in a tool group, it means that all tools will incur downtime at the frequency defined by the interruption. If a single interruption process is running for a tool group, the interruptions will be spread (in a random fashion) over all the tools in the group. The interruption types are defined as follows. 1. Between: The time between interruptions is based on the simulation clock. A separate interruption process runs for each tool in the tool group. In this interruption process, the countdown to the next interrupt starts immediately when an interrupt occurs. Between-time interruptions are useful for modeling downtime that occurs on a calendar basis, such as preventive maintenance as the simulation runs, the timing of interrupts will be very predictable. For example, if the time between interruptions is specified as a constant 24 hours, an interrupt will occur every 24 hours throughout the simulation run. Between-time interruptions can be used to model random failures, although this may not be realistic as it allows tool to fail while they are idle. Also, multiple failures can queue at a tool if a very short time-between interrupts is combined with a relatively long repair time. Due to the way failure data is collected, however, it is often in a form most readily used for between-time interruptions. 2. Clock: The time between interruptions is based on the simulation clock. A separate interruption process runs for each tool in the tool group. In this interruption process, the countdown to the next interrupt does not start until the previous downtime is completed. Clock-time interruptions are thus more appropriate than between-time interruptions for modeling random failures, as multiple failures can never queue at a tool. However, there is still the problem that tools can fail while they are idle. Clocktime interruptions are less appropriate than between-time interruptions for modeling regularly scheduled interruptions such as preventive maintenance. For example, if the
9. User's Guide: Additional Modeling Capabilities time to interruption is specified as a constant 22 hours, and the time offline as a constant 2 hours, the interruption will generally not occur every 24 hours in the simulation run. That's because if the tool is ever busy when an interruption occurs, the interruption is delayed until the tool completes its current activity. Then the interruption will occur (lasting 2 hours), and then the next interruption will be scheduled to occur 22 hours later. Thus the complete time between interruptions will always be greater than or equal to 24 hours. Over a long simulation run, this can cause the total percent time down for a toolgroup to be slightly less than expected. 3. Busy: The time between interruptions is based on the time a tool is busy. A separate interruption process runs for each tool in the tool group. Busy-time interruptions are useful for modeling downtime that is related to actual production time at the tool, such as preventive maintenance and failures. 4. Units: The time between interruptions is based on the number of units completed at a tool. A separate interruption process runs for each tool in the tool group. Units-ofwork completed interruptions are useful for modeling downtime that is related to actual production volume at the tool, such as preventive maintenance and failures. 5. GroupClock: The time between interruptions is based on the simulation clock. A single interruption process runs for the entire tool group. In this interruption process, the countdown to the next interrupt does not start until the previous downtime is completed. Group-clock interruptions are useful for modeling downtime that occurs on a calendar basis and that applies to a single tool no matter the number of tools in the tool group, such as engineering time. In Factory Explorer, all interruptions are non-preemptive. If an interruption occurs at a tool while the tool is busy processing, or while the tool is occupied by another interruption, the interruption is queued until the tool becomes free. Furthermore, an interruption that occurs while a tool is processing does not cause the work in process to be scrapped. An interruption may specify that an operator is required to assist in returning the tool to service. If an operator is required, an operator request is generated when the interruption occurs. See Section 23.7 for more information on operator dispatching. Once an operator is available, the interruption's repair time begins. Unless otherwise specified, operators are required for 100% of the repair time. If an operator is required for less than 100%, the operator's time falls at the beginning of the repair time. That is, if an operator is required for 50% of the repair time, that 50% always falls at the beginning, not the end, of the repair time. Although Factory Explorer can model an unlimited number of interruptions for each tool group in a model, there is generally a point of diminishing returns past which the work required to gather more data is not justified by material increases in model accuracy. Also, defining a large number of interruptions for numerous tool groups in a model can slow down the simulation, as it must perform record-keeping for each interruption process. 9.3.3 Example: Modeling Equipment Downtime This section presents a simple model that includes three types of equipment downtime failures, preventive maintenance, and engineering time. The model includes a single 178 Factory Explorer Copyright WWK 1995-2009
9.3. Equipment Downtime (Failures, Preventive Maintenance, Engineering, etc.) product, TWafers, processed on a single tool group, Implant. TWafers travel through the factory in lots containing 25 individual wafers, and the start rate is one lot per hour. Processing a wafer on an implant tool requires 3 minutes. The Implant tool group contains 3 implant tools. Implant tools are subject to failures, require occasional preventive maintenance, and are sometimes reserved for engineering tests. The Excel model for this example is downtime.xls. Figure 9-14 displays the tools worksheet. As only the tools worksheet contains details relevant to this discussion, the others are not displayed. The following sections describe how each type of equipment downtime can be modeled using interruptions. Also, each section details how the interruption is handled by Factory Explorer's capacity analysis and simulation engines.
Figure 9-14: Tools worksheet, downtime model. Equipment downtime for the implant tool group is modeled using five separate interruptions.
Modeling Failures with Units-of-Work Completed Interruptions Suppose historical data indicates that implant tools occasionally fail catastrophically, requiring many hours to repair. Furthermore, suppose these failures are related to the number of wafers processed on the tool, with a majority of failures occurring after approximately 2,000 wafers have been processed since the last catastrophic failure. Lacking more precise data, we assume that the number of units processed between catastrophic failures has a triangular distribution with mean 2,000 and +/- variation of 50% (ranges between 1,000 and 3,000 wafers). Since the repair time is highly variable,
9. User's Guide: Additional Modeling Capabilities we assume that it has an exponential distribution with the mean repair time set to 24 hours (the historical average). In Figure 9-14, the first interruption defined for the Implant tool group shows how to model this type of downtime with a units-of-work completed interruption. This interruption applies equally to all implant tools. During capacity analysis, Factory Explorer calculates the Offline% due to this interruption as follows. First, it knows that wafers arrive to the implant tool group at a rate of 25 wafers per hour. Thus, the average arrival rate of wafers to individual tools is 25/3 wafers per hour. Every 240 hours (2,000 wafers / (25/3 wafers per hour)), an implant tool can be expected to have processed 2,000 wafers, and on the average, experience one catastrophic failure. The mean repair time is 24 hours, so on the average, each tool is offline for 24 out of every 240 hours, resulting in an Offline% of 10%. For this interruption, Factory Explorer's simulation engine starts a units-of-work completed interruption process running for each implant tool. When started, each interruption process generates a random observation from the units-to distribution, and stores this countdown value for the tool. As wafers are processed at the tool, the countdown value is decremented by the number of wafers produced. When the countdown value reaches zero, the interruption process triggers an interruption at the tool. Since no operator is required for repair, the repair time starts immediately. Factory Explorer generates a random repair time from the repair time distribution. Once the repair time has elapsed, the interruption process generates a new countdown value from the units-to distribution and the procedure restarts. Modeling Failures with Clock-Time Interruptions Suppose that in addition to catastrophic tool failures, implanters also experience more frequent failures (occurring daily) that are less severe (requiring a mean repair time of approximately one hour). If these failures do not appear to depend on either the number of units produced or the tool's production time, it may be necessary to model them with clock-time interruptions. Since both the occurrence and repair time are highly variable, we assume both are exponentially distributed. After each repair, we assume the time to the next failure has an exponential distribution with mean 23 hours. For the repair time, we assume it has an exponential distribution with mean 1 hour. In Figure 9-14, the second interruption defined for the Implant tool group shows how to model this type of downtime with a clock-time interruption. This interruption applies equally to all implant tools. During capacity analysis, Factory Explorer calculates the Offline% due to this interruption as follows. In a period of 24 hours, each tool on the average experiences one failure (23 hours of uptime and 1 hour offline). Thus, each tool is offline for 1 hour out of every 24, resulting in an Offline% of 4.2%. For this interruption, Factory Explorer's simulation engine starts a clock-time interruption process running for each implant tool. When started, each interruption process generates a random observation from the time-to distribution, and schedules the first failure to occur at this time. When the simulation clock reaches the failure time, the interruption process triggers an interruption at the tool. Since no operator is required for repair, the repair time starts immediately. Factory Explorer generates a random repair
9.3. Equipment Downtime (Failures, Preventive Maintenance, Engineering, etc.) time from the repair time distribution. Once the repair time has elapsed, the interruption process generates a new time-to failure and the procedure restarts. Modeling Preventive Maintenance with Between-Time Interruptions Suppose that each implanter requires a daily preventive maintenance that takes two hours to complete. This downtime is best modeled with a between-time interruption. We assume that the scheduling and completion of preventive maintenance are highly regular, so we model the time-between and repair time for this interruption as constant. This regular behavior may not always be the case, however, so it may sometimes be necessary to model preventive maintenance with more variable distributions. We'll assume the time between maintenance interruptions is a constant 24 hours. For the preventive maintenance itself, we assume it takes a constant 2 hours. Furthermore, the tools are not all taken down at once for maintenance, so we assume the interruptions have a staggered first interrupt. In Figure 9-14, the third interruption defined for the Implant tool group shows how to model this type of downtime with a between-time interruption. This interruption applies equally to all implant tools. During capacity analysis, Factory Explorer calculates the Offline% due to this interruption as follows. In a period of 24 hours, each tool on the average experiences one maintenance (22 hours of uptime and 2 hours offline). Thus, each tool is offline for 2 hours out of every 24, resulting in an Offline% of 8.3%. For this interruption, Factory Explorer's simulation engine starts a between-time interruption process running for each implant tool. When started, the interruption process for the first implant tool schedules maintenance to occur after 24 hours have passed. Since the interruption specifies a staggered first interrupt, the interruption process for the second tool schedules maintenance to occur after 26 hours, and the interruption process for the third tool schedules maintenance to occur after 28 hours. When the simulation clock reaches the maintenance time for a tool, the tool's interruption process triggers an interruption at the tool, and the next interruption is scheduled to occur 24 hours later. Since an operator is required for the maintenance (from the MaintTech group), the maintenance time does not start until this operator is available. Unless otherwise specified, the operator is required for 100% of the maintenance time. Once a MaintTech operator is available, Factory Explorer schedules the end of maintenance to occur 2 hours later. With a between-time interruption, the interruptions will occur at precisely the same time each day during the simulation. Modeling Preventive Maintenance with Busy-Time Interruptions Suppose that in addition to daily preventive maintenance, implanters require a much more thorough maintenance that must be performed every 1,000 hours of production time. Assuming the maintenance is performed as required, we can model the time-to maintenance as a constant 1,000 hours of production time. If the maintenance time varies between 24 and 72 hours, with most taking around 48 hours, we can model it using a triangular distribution with mean 48 hours and +/- variation of 50%. In Figure 9-14, the fourth interruption defined for the Implant tool group shows how to model this type of downtime with a busy-time interruption. This interruption
9. User's Guide: Additional Modeling Capabilities applies equally to all implant tools. During capacity analysis, Factory Explorer calculates the Offline% due to this interruption as follows. Since wafers arrive to the implant tool group at a rate of 25 wafers per hour, each implanter sees an arrival rate of 25/3 wafers per hour. A wafer takes 3 minutes to process, so each tool accumulates 25 minutes of processing time per hour. Every 2,400 hours (1,000 production hours / (25/60 production hours per hour)), an implant tool will require this preventive maintenance. The mean maintenance time is 48 hours, so on the average, each tool is offline for 48 out of every 2,400 hours, resulting in an Offline% of 2%. For this interruption, Factory Explorer's simulation engine starts a busy-time interruption process running for each implant tool. When started, each interruption process stores the constant busy-time between interruptions (1,000 hours) in a countdown value for the tool. As wafers are processed at the tool, the countdown value is decremented by the production time. When the countdown value reaches zero, the interruption process triggers an interruption at the tool. Since an operator is required for the maintenance (from the MaintTech group), the maintenance time does not start until this operator is available. In this example, the operator is required for 25% of the maintenance time. Once a MaintTech operator is available, Factory Explorer generates a random maintenance time from the maintenance time distribution. The operator is freed after 25% of the maintenance time has elapsed. When the entire maintenance time has elapsed, the interruption process resets the countdown value and the procedure restarts. Modeling Engineering Time with Group-Clock Interruptions Suppose that time on an implant tool is regularly reserved for engineering tests and experiments. If the engineering time applies equally to all implant tools, it can be modeled using any of the other three interruption types (clock-time, busy-time, or unitsof-work completed). However, it is often the case that engineering time is allocated on a calendar basis, but only requires a single implanter. While this type of interruption could be modeled using the other three interruption types, it requires manipulating the time-to parameter based on the number of tools in the tool group. If the number of tools in the tool group were ever to change, the interruption definition would also need to be changed. For engineering time that requires only a single tool from a tool group, it is better to model it using a group-clock interruption. Suppose that engineering requires a single implanter for 8 hours of testing every 2 days. In Figure 9-14, the fifth interruption defined for the Implant tool group shows how to model this type of downtime with a group-clock interruption. This interruption applies solely to the implant tool group. During capacity analysis, Factory Explorer calculates the Offline% due to this interruption as follows. Every 48 hours, 8 hours must be reserved on a single implanter for engineering. On the average, then, each of the three implanters is used for engineering 8/3 hours out of every 48. Thus the Offline% due to engineering is 5.6%. For this interruption, Factory Explorer's simulation engine starts one clock-time interruption process running for the implant tool group. When started, the interruption process schedules engineering time to occur after 40 hours have passed. When the simulation clock reaches the engineering time, the interruption process first searches for an idle implanter. If one is found, it triggers an engineering time interruption at that tool. 182 Factory Explorer Copyright WWK 1995-2009
9.4. Splitting Units at Process Completion Otherwise, the interruption takes place at the first implanter to become free. Since an operator is required for the engineering (from the Engineer group), the maintenance time does not start until this operator is available. In this example, the operator is required for 100% of the engineering time. Once an Engineer operator is available, Factory Explorer schedules the end of engineering time to occur eight hours later. When the engineering time has elapsed, the operator is freed, the interruption process schedules the next engineering time, and the procedure restarts.
9.4 Splitting Units at Process Completion

This section describes how to model the splitting of units using Factory Explorer's transform mechanism. Transform is used to model both splitting and binning at process completion. Section 9.5 describes the use of transform to model binning. Splitting occurs, for example, in semiconductor manufacturing. When modeling front-end production facilities, silicon wafers (units) travel through the factory in lots of 25, 48, or more wafers. Each wafer, however, often contains many individual die (memory or logic chips). At a certain point, each wafer is cut up into its individual die, and these die are grouped into carriers for further (back-end or post-fab) processing. This splitting often occurs in a separate factory from where the wafers are processed. The entire production process, however, can be included in a single Factory Explorer model. One benefit of an integrated front-end / back-end model is that the impact of proposed front-end changes (start rate, toolset, etc.) can quickly be assessed for the back-end. In order to make capacity analysis calculations feasible, Factory Explorer enforces the rule that maximum lot sizes cannot change within a single process flow. Hence, when a unit is split, it becomes part of a new Factory Explorer process flow, and this splitting can only occur at the end of a process flow. For any process flow where splitting occurs, Factory Explorer needs to know a multiplication factor and recipient process flow. For example, suppose a factory produces wafers containing 150 individual die per wafer. After several process steps, each wafer is split into its constituent die and receives some further processing. A Factory Explorer model for this situation would require two process flows: one for the processing of wafers, and one for the processing of individual die. For this example, wafers travel in lots of 25, while die travel in lots of 10. The Excel model for this example is split.xls. The only worksheet containing details relevant to splitting is the products worksheet. The relevant columns of the products worksheet are shown in Figure 9-15.
Figure 9-15: Products worksheet, split model. No release patterns are specified for the Die product, since lots of this type are only started as a result of Wafer splitting. Each completed wafer is split into 150 individual die.
9.5 Binning Units at Process Completion

This section describes how to model the binning of units using the Factory Explorer's transform mechanism. Transform is used to model both splitting and binning. Section 9.4 describes the use of transform to model splitting. Binning occurs when units are scored according to some performance measure and then separated into distinct categories (bins) based upon their score. In semiconductor manufacturing, individual die are often scored and binned according to the highest speed at which they can operate. As with splitting, Factory Explorer only allows binning to take place at the end of process flow. Binned products are released as new lots of separate products. Continuing the splitting example of Section 9.4, suppose that individual die are scored according to speed and separated into two categories: slow die and fast die. Approximately 75% of die are rated as slow, while the remaining 25% are scored as fast. The Excel model for this example is bin.xls. This model is an extension of split.xls, with changes to the products worksheet. The products worksheet has been modified to include two additional products; and to include the binning parameters. The relevant columns of the products worksheet are displayed in Figure 9-16.
9.6. Assembly
Figure 9-16: Products worksheet, bin example. Two additional products (representing the binned die) have been added. Each completed wafer is split into 150 individual die. Each completed die has a 75% chance of being rated a Slow Die, and a 25% chance of being rated a Fast Die.
9.6 Assembly
This section describes how to model assembly with Factory Explorer. Assembly is the process by which one or more products are consumed by the production of a single (assembled) product. Factory Explorer models assembly in much the same fashion as splitting and binning, which are described in Sections 9.4 and 9.5. Each of the subassembly products must be modeled as a separate Factory Explorer product, as must the assembled product. Assembly is treated on a unit-level basis. Requirements for the number of sub-assemblies needed to produce a single assembled item are given in units. Likewise, the assembled item is assumed to be a single unit of the assembled product. For example, suppose we are modeling the production of tables. Each table consists of a top and four legs. In our example, table legs travel through the factory in lots of size four, tops travel in lots of size one, and completed tables are transported in lots of size one. Four table legs and one table top are required to assemble a table. The Excel model for this example is assembly.xls. The products worksheet is the only one containing details specific to assembly. Figure 9-17 displays the relevant columns of this worksheet.
Figure 9-17: Product worksheet, assembly model.
When Factory Explorer simulates this model, it keeps track of the number of completed table tops and legs. When there are enough completed sub-assembly units to assemble a full lot of the assembled product (tables), Factory Explorer starts a new lot of tables, and subtracts the number of units used (tops and legs) from the inventory of completed sub-assembly units. In general, a sub-assembly product can be used as part of more than one assembled product. For example, table legs might be combined with two different types of table tops (wood or metal, say) to produce two different completed tables. In that case the Assembly statement for table legs would be listed twice, once for wood tables, and once for metal tables. Each assembly statement would specify the percentage of table legs dedicated to production of the corresponding assembled product (wood tables or metal tables). However, it is not currently possible to model a combined inventory of completed sub-assembly units that are used for more than one assembled product. For example, suppose 25% of table legs are dedicated to wooden-top tables, and 75% to metal-top tables. As table legs are completed, they are separated into two different inventories -approximately 25% go into the inventory location reserved for wooden-top tables, and the remainder into the inventory location reserved for metal-top tables. If the inventory of legs reserved for wooden-top tables is empty, no wooden-top tables may be assembled, even if there is a wooden top available and there are table legs available in the inventory location reserved for metal-top tables.
9.7. Adjustable Transform and Assembly Percentages When simulating a model with assembly and ramped product data, care should be taken to understand Factory Explorer's treatment of as-yet unused sub-assembly inventory at ramp points. For example, suppose that a model initially specifies that ten Widgets are required for the assembly of one WidgetPack, but starting 2000-01-01, fifteen Widgets are required for one WidgetPack. Suppose that at the start of 2000-01-01, there are eight completed Widgets waiting for assembly, but assembly cannot begin because a WidgetPack requires ten completed Widgets. Upon reaching the ramp point (2000-01-01), Factory Explorer sets aside the completed Widgets, updates the assembly information for WidgetPacks, and then restores the completed Widgets as unused inventory waiting for assembly into WidgetPacks of fifteen. In this situation, the treatment of unused inventory is straightforward. However, suppose that starting 2000-01-01, WidgetPacks are being upgraded, and will no longer be assembled from Widgets, but from SuperWidgets. Suppose that at the start of 2000-01-01, there are eight completed Widgets waiting for assembly. Upon reaching the ramp point (2000-01-01), Factory Explorer sets aside the completed Widgets, updates the assembly information for WidgetPacks, but does not restore the completed Widgets as unused inventory waiting for assembly into WidgetPacks (since WidgetPacks no longer are assembled from Widgets, but from SuperWidgets). In this situation, Factory Explorer assumes that the unused Widgets are simply thrown away. Factory Explorer does not report these unused Widgets as scrap. If this type of behavior is being modeled (change of sub-assembly products at ramp points), Factory Explorer's treatment of unused inventory should be kept in mind.
9.7 Adjustable Transform and Assembly Percentages

Sections 9.4, 9.5, and 9.6 discussed Factory Explorer's transform and assembly mechanisms. With these mechanisms, it is possible to model the physical transformations (e.g. sawing of wafers into die, speed-binning of die) that products undergo upon completion of their process flows. In all cases it is possible to specify a percentage transformed or assembled. Only in the modeling of binning does this percentage really represent a physical reality (e.g. only 10% of die tested will fall into the fastest speed category). For all other cases this percentage usually represents the allocation of an upstream product to multiple downstream products (e.g. a fixed percentage of the upstream product's production is reserved for each of several downstream products). In some cases it is sufficient to enter these percentages into the Factory Explorer model. When demand is specified for multiple downstream products, however, it is much easier to have Factory Explorer simply compute the appropriate transform and assembly percentages so as to satisfy this demand. For example, consider solar module (solar panel) production. As cells are produced, they are tested for efficiency, and graded into a variety of bins. This testing process is very similar to the binning process of Section 9.5. That is, the percentage of cells that falls into each bin is a physical reality, and not something that Factory Explorer should be able to modify. If the model shows there is a shortage of high efficiency cells, only a process improvement can make up for this fact.
9. User's Guide: Additional Modeling Capabilities Continuing this example, each graded bin of solar cells can be used to make a variety of solar modules. These products may vary in size, mounting, or electrical attachments. But nonetheless, multiple end-products are supplied by the same graded bin. In this case, if the model specifies demand at the solar panel level, it is easy for Factory Explorer to correctly compute the percentage of binned cells required for each endproduct. In this example, one intermediate product (solar cells) is assembled into multiple end-products (solar panels). To notify Factory Explorer that it should ignore the assembly percentages specified in the model and compute its own, mark the ADJPCTS column on the products worksheet (Excel models), or specify the AdjustPcts keyword (ASCII models). Since the adjusted percentages are calculated as part of capacity analysis, models with adjustable transform or assembly percentages cannot be simulated unless capacity analysis is also enabled. For models that require it, the same mechanism is used to specify adjustable transform percentages. Combining fixed and adjustable assembly or transform percentages in a single model can make the results of the model hard to interpret. That is not to say, however, that these features should never co-exist in the same model. In the solar module example, a fixed transform percentage is used to model the efficiency testing of solar cells. Then an adjustable assembly percentage is used to model the assembly of a single type of cell into a variety of solar module types. The reason that the results can be hard to interpret is that the presence of fixed transform percentages can lead to mismatches between the production rate of cells in a particular efficiency bin, and the demand for cells from that efficiency bin. For example, suppose that cells are tested and graded into two efficiency bins A (25%) and B (75%). Furthermore, suppose that A cells can be assembled to produce panels PA1 (10 cells) and PA2 (20 cells), while B cells can be assembled to produce panels PB1 (50 cells). Suppose the demand for PA1 is 100 modules per week, for PA2 is 200 modules per week, and for PB1 is 100 modules for week. Factory Explorer will back-calculate the demand for A cells to be 5,000 cells per week, and the demand for B cells to be 10,000 cells per week. It will also calculate the correct assembly percentages for A cells to be 20% (1,000 cells per week) for PA1 and 80% (4,000 cells per week) for PA2. To produce 5,000 A cells requires a cell throughput of 20,000 cells (since only 25% of cells become A cells). At that level, 15,000 B cells will be produced per week, against a demand of 10,000 B cells per week. There will be a 5,000 cell mismatch, or excess production, of B cells every week. This mismatch is a result of the difference between the product mix demanded of the factory, and the product mix the factory is capable of efficiently producing. Factory Explorer cannot provide a solution, per se, to such mismatches. All it can do is to identify and report the mismatch, which it does on the Factory Summary Worksheet.
9.8 Hot Lots

It is sometimes desirable in a factory to expedite the processing of certain lots. For example, suppose an important customer order includes a lot that has been significantly delayed due to tool failures. If the order cannot be shipped until it is complete, the factory supervisor may decide to expedite the tardy lot through the remainder of its processing. Expedited lots are called hot lots. Hot lots are usually viewed as a necessary evil, since they are generally disruptive to the overall system. Often, the introduction of hot lots into
9.8. Hot Lots a system will increase both the mean and variability of cycle time for other lots. The effect of hot lots can be very large in a system with significant setups, as hot lots generally force an increased number of setups. For these reasons, you may wish to quantify the disruptions caused by hot lots. There are several ways to accomplish this task with Factory Explorer, depending on the level of detail you wish to include in your model. In this section, we will describe several methods of modeling hot lots with Factory Explorer, starting with the easiest method (the least amount of detail), and progressing to the most difficult method (the most amount of detail). Remember that hot lots will have no effect in your system unless you use prioritybased dispatch rules. Hot lots are modeled in all of the following methods by manipulating lot priorities. For non-priority-based dispatch rules, lot priorities are ignored when deciding which lot to process next. For priority-based dispatch rules, smaller priorities are favored. Priorities can be any real number, positive or negative. For example, priority 5.3 is better than priority 0, priority 0 is better than priority 1, and priority 1 is better than priority 3.7. Modeling Hot Lots as Separate Products If you wish to restrict hot lots to certain product types, or to assign different priorities to hot lots of different product types, you will need to model hot lots as separate products. For each product where there is the possibility of hot lots, create a second product with the same process flow but having better default priority and a modified release structure. This second product will be the hot lot version of the base product. To modify the default priority for the hot lot product, change the PRIORITY column in Excel models or the priority field on the product statement in ASCII models. To manipulate the release structure for the hot lot product, modify the RELEASE / BETWEEN columns in Excel models or the release statement in ASCII models. This method of modeling hot lots involves more work than using run-time options, but does ease some of the restrictions imposed by the run-time approach. In particular, this method allows hot lots to be restricted to certain products within a model, and it allows different shades of hot lots. If a product is especially important, its hot lot product can be assigned a priority better than all other hot lot products. However, this method still assumes that only lots entering the system are eligible for expediting. All lots that are released as hot lot products are expedited, while those that are released as regular products are never expedited. Remember that hot lots are only expedited at tool groups with priority-based dispatch rules. This method differs from the run-time approach regarding the number of hot lots in the system. Under this method, you directly specify the rate at which hot lots enter the system (by controlling the release structure for hot lot products). The actual number of hot lots in the system will fluctuate. With the run-time approach, you directly specify the number of hot lots in the system. Modeling Hot Lots as Priority Changes within a Process If you wish to expedite lots at some point other than lot release, you will need to model hot lots as priority changes within a process. For each product where there is a possibility of hot lots, and at each point in the process where lots can become hot, insert a dummy processing step that takes zero processing time but that sets lot priorities to the
9. User's Guide: Additional Modeling Capabilities hot lot priority. Denote the percent of lots expedited from this step forward by HotPct At the step prior to each dummy step, add a goto that skips over the dummy step. The goto percentage should be set to 100 - HotPct. To set lot priorities to the hot lot priority, use the PRSET column in Excel models or the prset statement in ASCII models. To add a goto, use the GOTOSTEP / GOTOPCT columns in an Excel model or the goto statement in ASCII models. If you wish to expedite lots over a limited section of the process flow, you can reset the priority of hot lots back to their default value after any process step using the PRDEFAULT column in Excel models or the prdefault statement in ASCII models. Depending on the number of steps where you choose to model expediting, this method can be the most time-consuming to implement. This method does not, however, require any duplication of process flows, and does allow a detailed treatment of hot lots. Hot lots can be restricted to certain products within a model, hot lots of different products can receive different hot lot priorities, and lots are eligible for expediting at any point in the process flow. Remember, however, that hot lots are only expedited at tool groups with priority-based dispatch rules. Similar to the method of modeling hot lots as separate products, this method differs from the run-time approach regarding the number of hot lots in the system. Under this method, you directly specify the percentage of hot lots created at a step. The actual number of hot lots in the system will fluctuate. With the run-time approach, you directly specify the number of hot lots in the system.
9.9 Factory Schedules

Unless otherwise specified, Factory Explorer assumes that any factory being modeled is run continuously, 24 hours a day, 365 days a year. If a model specifies a factory schedule, however, Factory Explorer takes this schedule into account during both capacity analysis and simulation. Factory schedules are specified using the SCHED / NONSCHED / REPEATS columns of the Factory worksheet (Excel models) or using the Schedule statement (ASCII models). This section describes the use of factory schedules to model non-continuous factory operation. A factory schedule consists of one or more schedule records. Each schedule record defines the quantity of factory scheduled time, the quantity of factory nonscheduled time, and the number of times of the record is repeated. All times are specified in hours. For example, to model a factory that runs two eight-hour shifts each day, with third shift left idle, the single schedule record shown in Table 9-1 is sufficient.
Table 9-1: Schedule for two daily shifts.
Scheduled Time 16
Nonscheduled Time 8
Repeats 1
If, however, the factory runs with two shifts during the week, and one shift one weekends, two schedule records are required. The first record is repeated five times, once
9.9. Factory Schedules for each weekday, and the second record is repeated twice, once for each weekend day. The resulting schedule is shown in Table 9-2.
Table 9-2: Schedule for two weekday shifts, one weekend shift.
Scheduled Time 16 8
Nonscheduled Time 8 16
Repeats 5 2
When modeling a factory schedule, Factory Explorer assumes that the schedule pattern specified in the first record is repeated the indicated number of times, then the schedule pattern specified in the second pattern is used, etc. When all schedule records have been exhausted, Factory Explorer returns to the first record. Schedules can be arbitrarily complex, and there is no limit to the number of schedule records that can be specified. For example, to model a factory that operates three weeks with two shifts on weekdays, one shift on weekend days, but on the fourth weekend does not operate at all due to equipment maintenance, one could use the schedule shown in Table 9-3.
Table 9-3: Schedule for two weekday shifts, one weekend shift, except for every fourth weekend when factory is down for equipment maintenance.
Scheduled Time 16 8 16 8 16 8 16 0
Nonscheduled Time 8 16 8 16 8 16 8 48
Repeats 5 2 5 2 5 2 5 1
This last example points out that the sum of factory scheduled time and factory nonscheduled time for any schedule record does not necessarily have to sum to twentyfour hours. In many cases it is most natural for this sum to equal twenty-four hours, but it is not necessary for Factory Explorer. When performing capacity analysis, Factory Explorer treats factory nonscheduled time as a capacity loss for all tool groups and operator groups. For more information on capacity analysis calculations concerning factory schedules, see Section 20.7 of the manual. During the simulation, Factory Explorer treats each simulation event in one of two ways. When the factory begins an factory nonscheduled period, an event pending on the simulation events list can either be delayed by the factory nonscheduled time, or it can be left to occur at its previously factory scheduled time. Table 9-4 lists events in the simulation, and describes how they are treated at the start of a factory nonscheduled period.

Table 9-4: Description of event treatment at start of factory nonscheduled period.
Event Release of a lot generated by a release pattern in the model Freeing of a tool or operator at the end of an offline period Freeing of an operator at the end of a repair task Freeing of an operator or tool at the end of a load, process, unload, or travel task Start of a clock-based interruption for a tool or operator Clearing of statistics Call to user-supplied scheduler interface Release of an individual lot
Treatment at start of factory nonscheduled period Delayed by factory nonscheduled time Delayed by factory nonscheduled time Delayed by factory nonscheduled time Delayed by factory nonscheduled time No delay No delay No delay No delay
9.10 Process Step Goto's

After each process step, a lot normally proceeds to the next step in the process flow. However, lots can be routed randomly or non-randomly to any particular process step using the GOTOSTEP / GOTOPCT columns (Excel models) or Goto statement (ASCII models). In manufacturing models, goto statements are primarily used for the following reasons: To model rework loops (see Section 5.3 for a sample model that contains a rework loop). To model inspection lot sampling strategies. To model dynamic manipulation of lot priorities within a process flow (see Section 9.8 for a discussion of hot lot modeling).
Each process step can list an unlimited number of goto choices. The sum of goto step percentages for a particular step cannot exceed 100. If the sum of goto step percentages is less than 100%, Factory Explorer assumes the remaining percentage of the flow is directed to the immediate next step in the process flow. A 100% backward goto triggers a validation error, unless the step is the end of a rework loop, or there is a prior step with a goto that points after the 100% backward goto step. Factory Explorer process step goto's can be random or non-random. This distinction does not affect capacity analysis results. For capacity analysis, Factory Explorer uses the goto percentage to approximate the long-run percentage of lots that flows to each goto choice. By default, Factory Explorer assumes random goto's. To specify non-random goto's for a process step, use the NRGOTO column (Excel models) or the NonRandomGoto statement (ASCII models).
9.10. Process Step Goto's 9.10.1 Simulation Behavior of Random Goto's For random goto's, the simulation uses the goto percentage as the probability (after dividing by 100) that a lot will goto a particular destination step. The actual choice of destination step is random, with these probabilities. 9.10.2 Simulation Behavior of Non-Random Goto's For non-random goto's, the simulation attempts to match, as closely as possible, the percentage of lots specified as going to each destination step. This algorithm works as follows. First, the simulation engine keeps track of the total lots processed at the step, and the total lots previously sent to each destination step. Each time a lot finishes processing, the simulation computes the percentage of lots sent to the first destination step and compares this simulation estimate to the goto percentage specified in the input model. If the simulation estimate is smaller than the input model goto percentage, the lot is sent to the first destination. If the simulation estimate is larger than the input model goto percentage, the calculation is repeated for the second destination step, and so on. The net result is that if run for a long enough period, the percentage of lots sent to each destination step will exactly match the goto percentage specified for that destination step in the input model. Here are two concrete examples: Step S1 specifies two goto's one to step S2 (50%), and one to step S3 (50%). In the simulation, the first lot to finish S1 will automatically goto S2, since the prior S2 goto percentage is still undefined. When the second lot finishes S1, the algorithm computes the prior S2 goto percentage (1 lot out of a total of 1 lot, or 100%), and finds that this is larger than the input model percentage (50%). The algorithm then moves on to S3 and computes the prior S3 goto percentage (0 lots out of a total of 1 lot, or 0%). Since this percentage is less than the input model (50%), the lot goes to S3. When the third lot finishes S1, the prior S2 goto percentage is 50% (1 lot out of a total of 2 lots). Since this percentage is less than or equal to the input model percentage (50%), the lot goes to S2. When the fourth lot finishes S1, the prior S2 goto percentage is 67% (2 lots out of a total of 3 lots), but the prior S3 goto percentage is 33% (1 lot out of a total of 3 lots), and so the lot goes to S3. This pattern is repeated a lot goes to S2, then a lot goes to S3, then a lot goes to S2, etc. Step S1 specifies two goto's one to step S2 (75%), and one to step S3 (25%). In the simulation, the first lot to finish S1 will automatically goto S2, since the prior S2 goto percentage is still undefined. When the second lot to finish S1, the prior S2 goto percentage is 100%, but the prior S3 goto percentage is 0%, so the lot goes to S3. When the third lot finishes S1, the prior S2 goto percentage is 50% (less than the input model percentage of 75%), and so the lot goes to S2. When the fourth lot finishes S1, the prior S2 goto percentage is 67% (two lots out of three, and still less than the input model percentage of 75%), and so the lot goes to S2. When the fifth lot finishes S1, the prior S2 goto percentage is 75% (three lots out of four, but still less than or equal to the input model percentage), and so the lot goes to S2. At this point the cycle restarts the sixth lot goes to S3, the seventh lot goes to S2, and the eighth lot goes to S2. At this point, the prior S2 goto percentage is again 75%, and the prior S3 goto percentage is 25%.
9. User's Guide: Additional Modeling Capabilities 9.10.3 Sample Model For an elementary example of process step goto's, consider a simple six step operation, where the second step is skipped for about one-third of all lots, and the fifth step is skipped by every other lot. The Excel model for this example is goto.xls. The process worksheet is the only sheet in this model with details specific to random routing. Figure 9-18 displays relevant columns from this worksheet.
Figure 9-18: Process worksheet, goto model. Products finishing the first processing step have a 33% chance of skipping over the second step and jumping directly to the third processing step. Every other lot, however, skips the fifth step.
9.11 Individual Lots

By default, Factory Explorer models do not require data for individual lots. The simulated factory starts with no initial WIP, and lots are released into the factory according to rates or patterns specified at the product level. For detailed factory modeling, however, it is often desirable to more completely specify initial factory WIP and the release time of individual lots. This level of control is available via the Lots worksheet (Excel models) or Lot-related statements (ASCII models). This section presents notes on the modeling of individual lots, and a sample model that specifies individual lots.
9.11. Individual Lots 9.11.1 Notes For each individual lot, the following information is mandatory: Lot I.D. Product Name Process Name Step Name Number of Units
For each individual lot, the following information is optional: Lot Priority Start Date Due Date Rework Information (Is the lot a rework parent? Is the lot a rework child? If a rework child, what is the parent lot I.D.?) Split-Lot Information (Is the lot a split-lot parent? If a split-lot parent, what is the total number of split-lot children, and the remaining number of split-lot children? Is the lot a split-lot child? If a split-lot child, what is the parent lot I.D.?)
1. The easiest way to generate a detailed list of initial WIP is to use the final WIP snapshot from a previous simulation run. To do so, enable DoSim and WriteDetail. When these options are enabled, Factory Explorer generates a WIP snapshot at the end of each analysis period. To view these WIP snapshots, create the WIP Snapshot Worksheet. This output worksheet is formatted to allow for easy copying and pasting of lot information onto the Lots worksheet of a Factory Explorer Excel model. 2. The WIP Snapshot Worksheet does not contain information about any units of subassembly products that have completed their sub-assembly process flow but have not yet started the assembled product's process flow. Similarly, it is not possible to initialize Factory Explorer with units in this waiting-for-assembly status. 3. Specifying individual lots affects both capacity analysis and simulation. However, several simplifying assumptions are made during capacity analysis. In particular, Factory Explorer approximates the effect of rework during capacity analysis by placing a lot with the combined units from the rework parent lot and rework child lot at the rework step. Factory Explorer also approximates the effect of splits lots during capacity analysis by placing a lot with the combined units from the split parent lot and all its split child lots at the split step. Finally, Factory Explorer's capacity analysis engine assumes that all individual lots released during an analysis period complete the flow during this same period. This is the same assumption it makes for processing regular release rates and patterns, but the effect can be more noticeable when modeling very short periods and many individual lots. For example, capacity analysis may show that a model with many individual lots is unstable if run for a one-week period, when the same model is stable if run for a one-year period. This is because the lots cannot all complete processing in one week. Over a whole year, however, their effect becomes much smaller, and the factory remains stable.
9. User's Guide: Additional Modeling Capabilities 4. Specifying individual lots does not affect release rates or patterns specified at the product level. If individual lots are specified in addition to release rates or patterns, then both methods of releasing lots into the factory will be active. To avoid confusion, it is often best to use one method or the other for each product. One exception is using individual lots to model WIP in the factory at the start of the analysis. In this case individual lots are all released into the factory at the beginning of the run, and then release rates or patterns control lot releases for the remainder of the run. 5. Individual lots may represent either initial factory WIP, or lots that are to be released during the analysis run. Factory Explorer compares each individual lot's start date with the analysis start date to decide between the two categories. If a lot specifies no start date, or specifies a start date before the analysis start date, Factory Explorer assumes the lot should be in the factory at startup. Otherwise, it waits until the specified start date to release the lot into the factory. If a lot's start date falls beyond the end of the analysis run, Factory Explorer will not release the lot into the factory. Note that if one or more individual lots specify start dates or due dates, then a start date for the analysis run must be specified with StartDate. 6. Only individual lots that represent initial factory WIP may be rework or split-lot parents or children. Individual lots that are rework parents must be positioned on a rework step. Each rework parent lot must have exactly one rework child lot (that is specified as an individual lot). 7. Each individual lot must specify a unique lot I.D. 8. All individual lots except rework children and split-lot children are counted in the Lots Started and Units Started columns on the Factory Summary Worksheet. 9. Individual lots can be removed from a model at runtime using the DelLots option. In some cases, this option is required. For example, ReleasePct and ReleaseRate manipulate the arrival rate of lots into the factory, and cannot function properly in a model with individual lots. To use these run-time options, you must remove individual lots, and thus these options require you to also enable DelLots. 10. If an individual lot specifies a process step that is not active for the lots specified product, then the lot will be treated during capacity analysis and during simulation analysis as if it had been released to the next step in the process flow that is active for this product. If there are no subsequent steps that are active for the product, the lot will be treated during capacity analysis and during simulation analysis as if it did not exist. E.g. it will not show up as being released, processed, or finished, since it effectively follows a process flow that has no active steps. 9.11.2 Sample Model The workbook IndivLts.xls contains a sample model of a small brick-making facility with one product (patio pavers), six tool groups, and a single process flow. The facility includes both rework and within-process lot splitting. The process flow starts with a baking operation, and then a test for rework. Rework units are cooled, and then sent back for additional baking. When a lot has successfully completed the baking operation, it is 196 Factory Explorer Copyright WWK 1995-2009
9.11. Individual Lots split into smaller lots for processing through parallel grinding tools. Upon completion of grinding, the lot is packaged and shipped. Figure 9-19 displays relevant columns from the process flow worksheet.
Figure 9-19: Process flow worksheet, IndivLts model. The process flow includes both rework and lot-splitting. Only columns that show the structure of the process are displayed.
Suppose that we wish to predict the behavior of this facility in detail over a period of just a few days. The Lots worksheet in this model contains a sample set of individual lots some initial WIP, and some to be released after the analysis starts. Figure 9-20 displays this worksheet.
Figure 9-20: Lots worksheet, IndivLts model. Assuming an analysis start date of 3/7/98, this worksheet specifies a mixture of initial WIP lots and lots to be released after the analysis starts.
If you simulate this model for a period of seven days starting March 3, 2000, you will see that much of the new work released into the system after the start date does not exit the facility (examine the Lots Started and Lots Finished columns of the Factory Summary Worksheet). In fact, the bake oven is busy 100% of the time (examine the Sim Percent Busy column of the Tool Group Results Worksheet). If you simulate this model for a longer time frame, say fourteen days, you will see that WIP does eventually clear out of the system, but it often takes a significant amount of time. Note that if you run multiple replications of this system you will generally get different results, due to the variability introduced by the presence of rework.
9.12 Cost and Revenue Analysis

Factory Explorer models can include a variety of cost and revenue data. Factory Explorer uses this data to calculate a facility's total fixed cost, gross margin, product cost, and average work-in-process value. For the details of these calculations, see Chapter 21 of the manual. In this section we present a sample model that includes cost and revenue data. Cost and revenue data are entered at several different locations in a Factory Explorer model, as listed below. 1. At the factory level: A model may specify any number of factory fixed costs, factory recurring costs, and expense items. Each factory fixed cost may specify a depreciation
9.12. Cost and Revenue Analysis life and a useful life. Each expense item must specify a unit of measure and a cost per single unit of measure. At the product level: For each product, a model may specify raw unit cost and finished unit revenue. At the tool group level: For each tool group, a model may specify per-tool fixed cost, tool depreciation life, tool useful life, per-tool annual recurring cost, and an unlimited list of expense item consumption rates. For each expense item, the data may include the consumption rate per hour of non-scheduled time, per hour of scheduled downtime, per hour of unscheduled downtime, per hour of engineering time, per hour of productive time, per hour of standby time, and per unit processed.. At the operator group level: For each operator group, a model may specify peroperator hourly wage rate and per-operator hourly overhead rate. At the process step level: For each process step, a model may specify a per-unit supplies & consumable cost, a per-unit overhead cost, a per-unit direct material cost, and a list of expense item exceptions (expense items defined at the tool group level that are not used for this particular process step). Step-level expense item exceptions may only apply to expense items for which there is per-unit-processed consumption specified at the tool group level.
2. 3.
4. 5.
The major outputs of Factory Explorer's cost and revenue analysis are product cost per good unit out, total fixed cost, gross margin, and work-in-process value. Enable DoCap and DoCost to generate most cost/revenue outputs. Some outputs also require DoSim. Not all cost and revenue data inputs are required for any one individual output. The data and type of analysis engine(s) used to generate each output are listed below. 1. Product cost per good unit out (predicted by analytic engine): Uses factory data (fixed costs, useful life, recurring costs, expense items, space types, and tool types), product data (raw unit cost), tool group data (fixed cost, useful life, recurring cost, expense item consumption, space requirements, tool type), operator group data (hourly wage rate and overhead rate), and process step data (per-unit supplies & consumable cost, overhead cost, direct material cost, and expense item exceptions). Tool group space requirements are used to allocate factory costs to individual tool groups, from which point these costs are re-allocated to individual products on the basis of time used. If a model does not include space requirements, factory costs are not allocated to products. Note that factory costs allocated to a tool that is unused will not be allocated to any product. Nor will any direct tool costs (fixed costs or recurring costs) for unused tools be allocated to any product. 2. Total fixed cost (predicted by analytic engine): Uses factory data (fixed costs) and tool group data (fixed cost). 3. Gross margin (predicted by analytic engine): Uses factory data (fixed costs, depreciation life, recurring costs, expense items, and factory schedule), product data (raw unit cost and finished unit revenue), tool group data (fixed cost, depreciation life, recurring cost, and expense item consumption), operator group data (hourly wage rate and overhead rate), and process step data (per-unit supplies & consumable cost, overhead cost, direct material cost, and expense item exceptions). 4. Work-in-process value (estimated by simulation engine, but also uses results from analytic engine): Uses product data (raw unit cost).
9. User's Guide: Additional Modeling Capabilities We illustrate cost and revenue modeling with a model of a facility that includes factory fixed and recurring costs, two products, one tool group, and one operator group. The workbook cost.xls contains this model. At the factory level, the model includes a fixed cost for buildings of $100,000 (depreciation life 15 years, useful life 20 years), an annual recurring cost for utilities of $10,000, and an annual recurring cost of $75,000 for management salaries. The factory worksheet also defines three expense items: ChemicalA ($1.5 per liter), ChemicalB ($1 per liter), and CleaningSoln ($3 per liter). Note that expense item units of measure are text inputs, and may be defined at the users discretion. This data is specified on the factory worksheet, shown in Figure 9-21.
Figure 9-21: Factory worksheet, cost model. Factory fixed and recurring costs have been entered, and expense items have been defined.
For product costing purposes, Factory Explorer allocates factory costs to individual tool groups on the basis of space requirements. Also for product costing purposes, tool groups may be grouped by tool type product cost analysis will then show the contribution of different tool types to overall product cost. Space types and tool types must be defined at the factory level. Figure 9-22 displays space type and tool type definitions for this model.
9.12. Cost and Revenue Analysis
Figure 9-22: Factory worksheet, cost model. Space types and tool types have been entered.
The first product, BigW, has a raw unit cost of $2 and a per-unit revenue of $10. The second product SmallW, has a raw unit cost of $1 and a per-unit revenue of $7. This data is specified on the products worksheet, shown in Figure 9-23.
Figure 9-23: Products worksheet, cost model. Per-unit cost and revenue data have been filled in for both products.
BigW and SmallW products are processed by Grinder and Polisher tools. Each Grinder requires 500 square feet of manufacturing space and 250 square feet of support space (for storage of supplies, access space, etc.). Each Polisher tool requires 250 square feet of manufacturing space and 150 square feet of support space. The purchase and installation cost for a Grinder tool is approximately $15,000, for a Polisher tool these costs are approximately $12,500. Both types of tools have depreciation lives of 5 years and useful lives estimated at 7 years. The annual recurring cost for each grinder tool is approximately $1,000 (this input includes the cost of maintenance contracts, repairs, etc.); for a polisher tool these costs are approximately $500 This data is specified on the tools worksheet, shown in Figure 9-24.
Figure 9-24: Tools worksheet, cost model. Tool type, space, and cost data have been entered.
Expense item consumption for tools is also specified on the tools worksheet. So that Factory Explorer can distinguish between non-scheduled time, unscheduled downtime, scheduled downtime, and engineering time, the E10-state of Engineering is specified in the interruption definition, shown in Figure 9-25.
Figure 9-25: Tools worksheet, cost model. The E-10 state for the EngrCheck interruption has been entered.
Expense item consumption rates are shown in Figure 9-26.
Figure 9-26: Tools worksheet, cost model. The expense item consumption rates have been entered for the polishing machine.
Processing is performed by operators from the GrinderOp and PolishOp operator groups. The fully-burdened wage rate for all operators is $17.50 per hour. This data is specified on the operators worksheet, shown in Figure 9-27.
Figure 9-27: Operators worksheet, cost model. Hourly wage rates have been entered.
Processing a SmallW unit on a Grinder tool requires approximately $0.75 in supplies & consumables. The Polisher tool specifies expense item consumption (on the tools worksheet), but SmallW processing does not require ChemicalB. This data is entered on the process worksheet for SmallW products, shown in Figure 9-28. The method of specifying data for BigW products is similar, so we will not show that worksheet here. For models with cost and revenue data, several output reports and charts are available. For more information, see the documentation in Chapter 7 for the Product Cost Worksheet, the Gross Margin Worksheet, the Cycle Time Characteristic Curve Chart, the Fixed Cost & Cycle Time vs. Suggested Capacity Loading% Chart, and the Product Cost & Total Fixed Cost vs. Start Rate Chart.
9.13. Space and Layout Analysis
Figure 9-28: Process worksheet, cost model, SmallW product. Per-unit supplies & consumable cost has been entered for the Grind step. An expense item exception has been entered for the Polish step.
9.13 Space and Layout Analysis

Factory Explorer models can include several types of space and layout data. Factory Explorer uses this data to calculate a facility's space requirement and lot travel rates between layout areas. For the details of these calculations, see Chapter 22 of the manual. This section presents a sample model that includes space and layout data. Space data is entered at the factory level and at the tool level. At the factory level, a list of space types must be defined. A space type is simply a text name defined by the user. For example, in semiconductor manufacturing typical space types might be Class10, Class1000, and NonClean. At the tool level, a tool group can specify an unlimited number of space requirements. A space requirement is specified by a space type and the number of square feet / square meters required of that space type for each tool. Layout data is also entered at the factory level and at the tool level. At the factory level, a list of layout areas must be defined. A layout area is a text name defined by the user, and represents a physical area of the factory. Layout areas must be non-overlapping. Layout areas can be as small as an individual tool group, or as large as desired (a layout area might consist of a building in some cases). Layout areas can be of varying sizes, depending on the goal of the analysis. Again drawing from semiconductor manufacturing, a typical set of layout areas names might be bay identifiers. Also at the
9. User's Guide: Additional Modeling Capabilities factory level, a travel matrix may be specified. For any two layout areas, the travel matrix specifies the number of feet / meters lots must travel when moving from the first layout area to the second. Specification of a travel matrix is optional, but some performance measures will only be generated if travel data is included (for example, the Travel Matrix by Distance Rate Report is only generated if a model includes travel matrix data). Note that Factory Explorer does not currently use the data within the travel matrix to estimate travel times between process steps. At the tool level, a tool group can specify the layout area that it is located within. We illustrate space and layout modeling with a model of a facility that includes this data. The workbook spclyt.xls contains this model. The model includes two space types (Class10 and NonClean), two layout areas (Bay#1 and Bay#2), and accompanying travel matrix data, shown on the factory worksheet in Figure 9-29. Note that travel matrix entries are for a single flow direction. In some cases (e.g. if the material handling system can only carry material in one direction) the travel distance may not be symmetric. Route names need not be entered, as they are only used when Factory Explorer communicates directly with third-party software.
Figure 9-29: Factory worksheet, spclyt model. Space, layout, and travel matrix data have been entered.
At the tool level, the model specifies a layout area for each tool group, and tool space requirements. Figure 9-30 displays the tools worksheet.
9.14. Alternative Steps For models with space and layout data, several output reports are available. For more information, see the documentation in Chapter 7 for the Tool Space by Layout Area Worksheet, the Travel Matrix by Move Rate Worksheet, the Travel Matrix by Distance Rate Worksheet, and the Tool Space by Type Worksheet.
Figure 9-30: Tools worksheet, spclyt model. Layout areas and space requirements have been entered for each tool group.
9.14 Alternative Steps

Models of existing factories, especially factories that have been operating for some time, often need to account for alternative process steps. This situation usually arises when new equipment is purchased that is functionally superior to existing pieces of equipment. For example, in semiconductor manufacturing, a wafer visits a tool called a stepper multiple times during the process. Each visit is for a particular layer on the wafer. Some of these layers are quite critical. Critical layers are usually performed on the newest steppers in the facility, since these steppers are most likely to maintain the tight tolerances necessary. Other layers are not so critical, and are usually performed on older steppers. However, the newer steppers are perfectly capable of serving as alternatives for non-critical layers. Modeling this situation requires the use of alternative steps. As another example, two pieces of equipment can be functionally equivalent (they can process exactly the same steps), but not operationally equivalent (one is a per-wafer tool, the other is a batch tool). In general, alternative steps provide a means of modeling multiple alternatives for a
9. User's Guide: Additional Modeling Capabilities single step. This section describes the rules for modeling alternative steps in Factory Explorer, and presents a sample model containing alternative steps. 9.14.1 Rules Factory Explorer identifies two or more process steps as alternatives whenever a) the process steps all have the same name, and b) the process steps are contiguous in the process flow. Thus, alternative steps are an exception to the rule that all process steps within a process flow must have unique names. Factory Explorer imposes several other restrictions on alternative steps. A complete list of restrictions is detailed below. 1. Two or more contiguous process steps with the same process step name are automatically identified as alternative steps (unless they have different effective dates). 2. Alternatives for the same step must be contiguous, i.e. it is an error for steps that are not contiguous to have the same name. 3. Alternative steps may not specify scrap. 4. Alternative steps may not specify rework. 5. Each alternative step must specify an alternative percentage in the ALTPCT column (Excel models), or using the Alt% statement (ASCII models). 6. The sum of alternative percentages for a step for a given effective date must be 100. 7. For models with active/inactive process steps, the sum of alternative percentages for each product that uses an alternative step must be 100. 8. For models with active/inactive process steps, alternatives for the same step must specify exactly the same list of active/inactive process steps. 9. Only alternative steps may specify an alternative percentage. 9.14.2 Sample Model This section presents a sample model containing alternative steps. In this model, two different tool groups, NewStepper and OldStepper, may be used for process step NonCritLayer. For capacity analysis, the entries in the ALTPCT column instruct Factory Explorer to split the flow into step A evenly between the two tool groups. The workbook altsteps.xls contains this model. The only model worksheet of interest here is the Process1 sheet that contains the process steps. Figure 9-31 displays relevant columns from this worksheet.
9.15. Holding a Tool Across Multiple Process Steps
Figure 9-31: Process flow worksheet, altsteps model. The non-critical step may be performed on either the new stepper or the old stepper. For capacity analysis, the model instructs Factory Explorer to divide the flow evenly between the two choices.
For capacity analysis, Factory Explorer uses the entries in the ALTPCT column to split the flow of work between the two tool groups. In the simulation, an incoming lot joins the queue for the new stepper and the queue for the old stepper. Upon reaching the front of a queue, the lot removes itself from both queues before beginning processing. For example, suppose the lot reaches the front of the new stepper queue first. At that point, the lot would remove itself from both queues, and would process on the new stepper. At the end of a simulation, Factory Explorer estimates the percent of time that each alternative was chosen. The Alternative Steps Summary Worksheet compares the alternative step percentages specified in the model with those estimated via simulation. Enable WriteEstAlt in combination with WriteExcel to build a model that has the estimated percentages substituted for the input model percentages.
9.15 Holding a Tool Across Multiple Process Steps

By default, Factory Explorer assumes that a tool used for a process step is freed after processing for the step is completed. In some instances, however, it is useful to model the situation where the tool is not freed until after some later process step is completed. This situation arises in some types of back-end semiconductor manufacturing. Normally, dies (the product) are physically located in a plastic carrier device (the lot). Before being placed in a burn-in furnace, however, the dies must be moved to special testing boards.
9. User's Guide: Additional Modeling Capabilities These boards carry the dies through several process steps, including the burn-in furnace. If too few testing boards are available, they can become the bottleneck for the burn-in area. Since testing boards often vary by product type and are relatively expensive, it may be desirable to have just enough, but not too many, on hand. In this case, it makes sense to explicitly model the demand for a resource (the testing board) that is held across multiple process steps. This modeling functionality (holding a tool across multiple process steps) can also be used to model Kanban cells. This section describes the rules enforced by Factory Explorer for this functionality, and presents two examples showing its use. 9.15.1 Rules Holding a tool across multiple process steps introduces a good deal of complexity into a model. In particular, it introduces the possibility of deadlock. To avoid simulation deadlock, during model load Factory Explorer scans the process flows for all products and automatically detects any situation where deadlock could arise. If a deadlock loop is located, Factory Explorer prints out the list of tools involved in the loop and exits with a model validation error. This check is performed before any capacity analysis or simulation takes place. For example, the model shown in Table 9-5 contains a deadlock loop. During model load, Factory Explorer would identify this deadlock loop and flag it as a model validation error.
Table 9-5: Process flow containing deadlock loop. Suppose TGA and TGB each contain one tool. Suppose lot #1 seizes TGA at Step1. Before completion of lot #1 processing, suppose lot #2 seizes TGB at Step3. Now, no matter what happens, the simulation will be deadlocked. Lot #1 will finish processing at Step1 but can never seize TGB for Step2 processing, since TGB is not yet released by lot #2. Similarly, lot #2 will finish processing at Step3 but can never seize TGA for Step4 processing, since TGA is not yet released by lot #1. Factory Explorer automatically detects deadlock loops and flags them as model validation errors.
Step Step1 Step2 Step3 Step4
Uses Tool Group TGA TGB TGB TGA
Free Tool Group After Step2 N/A Step4 N/A
Thus, the primary rule enforced by Factory Explorer is that the use of multi-step hold cannot create a deadlock situation. Other rules are listed below, and use the following terminology. A hold tool is a tool held across multiple process steps. A hold tool region is a set of process steps across which a hold tool is held. A hold step is the first step in a hold tool region, while a free after step is the last step in a hold tool region. 1. In models with ramped data, a step cannot be both a hold step and not a hold step at different effective dates. 2. In models with ramped data, a hold step must specify the same free after step for all effective dates. 3. In models with ramped data, a hold step must specify the same tool group for all effective dates. 4. Steps outside a hold tool region may not specify a goto into a hold tool region. 5. Steps within a hold tool region may not specify a goto to a step outside the region. 212 Factory Explorer Copyright WWK 1995-2009
9.15. Holding a Tool Across Multiple Process Steps 6. No split lot region can cross a hold tool region (split lot functionality is described in Section 9.16 of the manual). That is, a split lot region cannot start outside a hold tool region and end inside a hold tool region, nor may a split lot region start inside a hold tool region and end outside a hold tool region. But a split lot region may contain an entire hold tool region, and a hold tool region may contain an entire split lot region. 7. Nested hold tool regions cannot be specified for the same tool group. 8. The hold tool may not be used for any process step in a hold tool region other than the hold step. 9. The hold step cannot be an alternative process step. 10. The hold tool cannot be a batch tool. 11. The hold tool group cannot have infinite servers. 12. The free after step must be located after the hold step in the process flow. 13. The free after step must be active for all products for which the hold step is active. 9.15.2 Sample Model of a Burn-In Area This section presents a simplified model of a semiconductor manufacturing burn-in area. This model demonstrates how a tool can be held across multiple process steps within a Factory Explorer process flow. The workbook burnin1.xls contains this model. Section 9.16.2 of the manual presents a more realistic version of this model that also includes lotsplitting. This model includes a single product, P1Die, a single process, P1Flow, and three tool groups: TestBoards, LoadStation, and Furnace. Before processing in the furnace, die must be mounted on a testing board. After mounting, they are placed in the furnace for burn-in. When finished in the furnace, die are removed from the testing boards. In this simplified model, no other process steps take place while the die are mounted on testing boards, but a more realistic model could include other intervening steps. The only model worksheet of interest here is the P1Flow sheet that contains the process steps. Figure 9-32 displays relevant columns from this worksheet.
Figure 9-32: Process flow worksheet, burnin1 model. Each test board, once seized at step SeizeBoards, will be held until the completion of step UnloadBoards.
When a lot reaches step SeizeBoards, it seizes one testing board, if available. If no testing boards are available, the lot queues until one becomes available. Once seized, the testing board is held until the lot completes step UnloadBoards. If too few testing boards are included in the model, they will become the bottleneck for this area. In this sense, the testing boards act like Kanban cards in a simple, single-card Kanban cell the subject of the next sample model. 9.15.3 Sample Model of a Single-Card Kanban Cell This section presents a simplified model of a single-card Kanban cell. Kanban methodology has become popular as a method of controlling WIP and cycle time in manufacturing lines. For a general overview of Kanban methodology, see Schoenberger (1982). For a specific case study, see Schoenberger (1987). Many different types of Kanban systems have been proposed, but in general, Kanban methodology seeks to limit WIP within areas of the factory, or Kanban cells. Entry into a Kanban cell is controlled by Kanban cards. In a single-card system, a lot cannot enter the cell unless a Kanban card is available. If available, the card is physically attached to the lot and travels with it throughout the cell. Upon completion of processing within the cell, the Kanban card is detached from the lot and becomes available. When implementing a Kanban system, two immediate questions must be answered. First, the boundaries of each Kanban cell must be determined. Next, the 214 Factory Explorer Copyright WWK 1995-2009
9.15. Holding a Tool Across Multiple Process Steps number of Kanban cards dedicated to each cell must be specified. If the number of cards is too large, they do not effectively limit WIP and the Kanban methodology essentially has no effect on operations. If the number of cards is too small, cell throughput can be severely restricted. Factory Explorer is most useful in answering the second question. For possible hints on the first problem (determining cell boundaries), see the references noted above. Once Kanban cell boundaries have been determined, Factory Explorer's capacity analysis and simulation engines can be used to help determine an appropriate number of Kanban cards in each cell. Capacity analysis can be used to determine the minimum number of cards, while simulation can be used to fine-tune the choice. The workbook kanban1.xls contains the sample model presented here. In this model, a single Kanban cell consists of three operations coat, step, and develop. The only model worksheet of interest here is the process flow worksheet, WProcess. Figure 9-33 displays relevant columns from this worksheet.
Figure 9-33: Process flow worksheet, kanban1 model. A Lot cannot enter the cell unless a Kanban card is available. The lot then holds this cell card until completion of the develop step, when the card is released.
A lot entering the cell must first seize a Kanban card. If a Kanban card is not available, the lot must wait until one becomes available. Once a card is obtained, the lot proceeds through the cell's three operations. After completion of the develop step, the Kanban card is released for use by other lots.
9.16 Splitting and Recombining Lots Within a Process Flow

By default, Factory Explorer maintains lot integrity within a process flow. Lot integrity means that the units within a lot are never separated, and that a lot never moves to the next process step until all units within the lot have completed processing at the current step. Factory Explorer allows two exceptions to lot integrity rework and lot splitting. For rework, units requiring rework are placed in a new lot (the rework child lot). Units not requiring rework remain in the original lot (the rework parent lot). When finished with rework, the rework children lot is recombined with the rework parent lot. Lot splitting is similar to rework (see Section 5.3 of the manual for details on rework). At the split point, the original lot (the split parent lot) is split into a number of smaller lots (the split child lots), which then move forward in the process flow. The split child lots can be recombined at a later point in the process flow, or may flow through the rest of the process and never be recombined. Lot splitting is different from rework in that split child lots do not return to the split point to be recombined (if they are recombined at all). Also, in lot splitting, all units in the split parent lot are assigned to split child lots. In a sense, the split parent lot temporarily ceases to exist until all split child lots complete processing at the recombination step. At that point, units from all split child lots are returned to the split parent lot, and the split child lots cease to exist. Again, this recombination only occurs if specified in the model. Lot splitting is most useful in modeling manufacturing lines with large lot sizes. For example, in some semiconductor manufacturing assembly & test lines, the lot size can be hundreds or thousands of die. At machines where processing is required for each die, processing the entire lot on a single machine can take a very long time. If many parallel machines are available, the lot may be split into many smaller pieces and processed in parallel on many machines. After processing is completed the split lots are recombined into the original lot. In other cases, processing requirements may dictate that die be mounted on special boards before processing. In effect, mounting the die on multiple boards amounts to lot splitting, and can be modeled as such. Section 9.16.2 presents a sample model with this use of lot splitting. 9.16.1 Rules Factory Explorer enforces several rules when modeling lot splitting. These rules use the following terminology. The split step is the process step where lot splitting occurs. The unsplit step is the process step at which split child lots are recombined into the split parent lot. The split lot region is the (inclusive) set of process steps between the split step and the unsplit step, if an unsplit step is specified. If no unsplit step is specified, then there is no split lot region. The split lot size is the lot size for split child lots. The following rules, if broken, are flagged as model validation errors by Factory Explorer. 1. In models with ramped data, a step cannot be both a split step and not a split step at different effective dates. 2. In models with ramped data, a split step must specify the same unsplit step (or no unsplit step at all) for all effective dates.
9.16. Splitting and Recombining Lots Within a Process Flow 3. The split lot size must be strictly less than the maximum lot size of any product that uses the process flow. 4. The unsplit step, if specified, cannot be the last step in the process flow. 5. Split lot regions cannot cross a hold tool region (hold tool functionality is described in Section 9.15 of the manual). 6. Nested or overlapping split lot regions are not allowed. 7. Steps within a split lot region may not specify scrap. 8. Steps outside a split lot region may not specify a goto into a split lot region. 9. Steps within a split lot region may not specify a goto out of the split lot region. 10. The split step may not be an alternative process step. 11. The unsplit step may not be an alternative process step. 12. The split step may not specify goto's. 13. The unsplit step may not specify goto's. 14. The split step may not be a rework step. 15. The unsplit step may not be a rework step. 16. The unsplit step may not also be a split step. 17. The unsplit step must be located after the split step in the process flow. 18. The unsplit step must be active for all products for which the split step is active. 9.16.2 Sample Model of a Burn-In Area This section presents a sample model of a semiconductor manufacturing burn-in area. This model is an extension of the model presented in Section 9.15.2. To recap, die enter the burn-in area in lots. Each lot contains 5,000 die. To be processed in the burn-in furnace, the die must be mounted on special testing boards. In this model, test boards can hold 150 die. The workbook burnin2.xls contains this model. This model includes a single product, P1Die, a single process, P1Flow, and four tool groups: TestBoards, LoadStation, Furnace, and DummyTG (used as a placeholder in the process flow). Before processing in the furnace, die must be mounted on testing boards. This model mimics the testing boards by first splitting each lot into lots containing at most 150 die. Then, each of these split child lots seizes a single testing board and holds it across multiple process steps. The only relevant model worksheet is the P1Flow worksheet containing the process flow. Figure 9-34 displays relevant columns from this worksheet.
Figure 9-34: Process flow worksheet, burnin2 model. Lots are first split into child lots containing at most 150 die. Each split child lot then seizes a test board at step SeizeBoards. Test boards are released upon completion of step UnloadBoards, and the split child lots are recombined into the split parent lot. The Dummy Step is required by Factory Explorer, since the unsplit step can never be the last step in a process flow.
When a lot reaches the SplitLots step, it is split into child lots containing at most 150 die. Each child lot then attempts to seize a testing board at step SeizeBoards. Test boards are released when each child lot completes processing at step UnloadBoards. When all children have completed processing at step UnloadBoards, they are recombined into the parent lot. Factory Explorer requires that the unsplit step (UnloadBoards in this case) cannot be the last step in the process flow, so a dummy step is used in this model. Note that Factory Explorer's capacity analysis engine will consistently underestimate the load on the testing boards in this example. This situation arises because the effective service time for a testing board is the sum of queuing and processing times at steps SeizeBoards, LoadBoards, BurnIn, and UnloadBoards. Factory Explorer approximates this service time by adding up the processing times for these steps, but does not attempt to add in estimated queuing times. Therefore, if significant queuing exists for these steps, the simulation will give a more accurate estimate of load on the testing boards, since it captures this effect in its entirety. 9.16.3 Effect of Lot Splitting on Cycle Time Contribution Estimates Splitting and recombining lots within a process flow affects how Factory Explorer estimates values that appear on the Cycle Time Contribution by Tool Group Chart. In
9.16. Splitting and Recombining Lots Within a Process Flow some cases it may not be possible for Factory Explorer to calculate the exact cycle time contribution of a tool if it processes split lots. This section briefly describes the method Factory Explorer uses to estimate cycle time contribution for tools that process split lots. To demonstrate this method, consider a simple three step process. Lots arrive to step A containing fifty units. Processing for step A occurs on tool group A, and lasts for one hour. After completing step A, each lot is split into five child lots. Each child lot contains ten units. Child units are then processed for two hours each at step B on tool group B. After processing is completed at step B for all child lots, the children are recombined into the parent lot, which continues on to step C. At step C, the parent lot is processed for three hours on tool group C. Suppose tool groups A, B, and C each contain a single tool. In this case, the total cycle time for a lot (assuming no other lots in system) is composed of one hour processing at step A, ten hours processing at step B (two hours for each child lot), and three hours processing at step C, for a total of fourteen hours. Factory Explorer calculates the cycle time contribution of each tool group as follows. For tool group A, it knows that the number of visits is one, the raw process time is one hour, and the queuing delay is zero, so the total cycle time contribution is one hour. Similarly, for tool group C, it knows that the number of visits is one, the raw process time is three hours, and the queuing delay is zero, so the total cycle time contribution is three hours. For tool group B (the tool that processes split lots), Factory Explorer knows that the number of visits by each split lot child is one, the raw process time is two hours, and the average queuing delay for each split lot child is four hours (zero hours for the first child lot, two hours for the second, four hours for the third, six hours for the fourth, and eight hours for the fifth; the average across five lots is four hours queuing delay). What Factory Explorer does not know, however, is whether or not the child lots were competing for time on tool group B. It is possible that the child lots would have experienced very different paths through the split lot region (although not in this case because the process flow is so simple). Thus, Factory Explorer cannot assume that the cycle times and / or the queue delays for split lot children should be added together to form the cycle time contribution for the parent lot. What it does instead is to use an average across all child lots. As a result, Factory Explorer calculates the average number of visits to tool group B to be one, the average raw process time to be two hours, and the average queue delay to be four hours. The total cycle time contribution for tool group B is then calculated as 1 (visit) * 2 (hours raw process time) + 4 (hours queuing) = 6 hours. Thus, if the cycle time contribution for all three tool groups are added together, the result is ten hours, while the actual cycle time is fourteen hours. In this case, Factory Explorer's cycle time contribution calculation underestimates the true contribution of tool group B. However, in more complex process flows, or in the case where tool group B contains multiple tools, Factory Explorer's estimate will likely be close to the true value. Note that the above discussion only concerns the case when an unsplit step is specified. If no unsplit step is specified, at the split point the split parent (the original lot) ceases to exist. Any split child lots that are created inherit the parent lot's due date, release date, and tool group visits information.
9. User's Guide: Additional Modeling Capabilities 9.16.4 Mid-Process Lot Splitting By default, lot splitting in Factory Explorer occurs at the end of a particular process step. However, there is an option to form the child lots as soon as enough units have completed processing. This functionality could be used to model die-attach machines, where there are a large number of units per lot and units are separated during processing. Conceptually, this mid-process lot splitting occurs at the start of processing (after setup and load). At this point, the original parent lot is partitioned into the appropriate number of split lot children based on the specified split lot size (note that this occurs after a particular tool has been seized, so the split lot children are not placed in queue to contend with other lots for priority). The process time for the original parent lot is allocated to the split lot children based on the number of units in each child lot. Also, the split lot children are processed sequentially, on a single tool, rather than in parallel on multiple tools. The unload, delay, and travel times associated with the original lot are inherited by the split lot children, as are operator requirements (i.e. if the original lot required a travel operator, so will each split lot child). Upon creation, the split lot children then proceed independently through processing, unload, delay, travel, and the remaining process flow. Split lot children may be optionally recombined at a specified future process step. All of the lot splitting rules described above in Section 9.16.1 apply to midprocess lot splits. Additionally, a mid-process lot split may not be performed during a step that utilizes a batch tool. Mid-process lot splitting does not affect Factory Explorers steady-state capacity or cycle time calculations. The mid-process lot splitting functionality is activated by setting a flag on the process step, as shown in Figure 9-35.
9.17. Controlling the Order of Simultaneous Check-Request Events
Figure 9-35: Process flow worksheet, MidSplit model. In Step1, Lots are split during processing into child lots containing 1 unit each.
9.17 Controlling the Order of Simultaneous Check-Request Events

In Factory Explorer's simulation engine, whenever a resource (tool or operator) is freed, or a lot enters a queue, a check-request event is scheduled. Upon execution, the checkrequest event checks to see if the resource is able, or is required, to start work somewhere in the factory. If multiple resources become free at exactly the same time, it is sometimes useful to control the order in which the check-request events for these resources are scheduled. By default, all resources have a check-request priority of zero, and the order cannot be determined in advance. Specifying CHECKPRI (Excel models) or CheckPriority (ASCII models) controls the priority, and hence the order, in which check-request events are executed. 9.17.1 Rules Check-request events and priorities satisfy a few simple rules: 1. All check-request priorities are between zero and 999. 2. Zero is the best check-request priority, and 999 is the worst. 3. The default check-request priority (if none is specified) is zero.
9. User's Guide: Additional Modeling Capabilities 4. All check-request events for operators are executed before any check-request events for tools. This is due to the fact that operators can consider work waiting at more than one tool group, while tool groups only consider work waiting in their own queue. Thus specifying a check-request priority for a tool group only changes its priority vis-vis other tool groups. Similarly, a check-request priority for an operator group only changes its priority vis--vis other operator groups. 9.17.2 Sample Model of a Tester This section presents a simplified model of a semiconductor manufacturing tester. This model demonstrates how to control the order of simultaneous check-request events within Factory Explorer's simulation engine. The workbook tst1.xls contains this model. This model contains three products, P1, P2, and P3. To be tested, die must first be mounted on product-specific testing boards Board.P1, Board.P2, and Board.P3. The mounting time is negligible. The tester tool group has a product-specific setup of one hour, and setupavoidance is enabled. The actual testing requires 2.25 hours. Figure 9-36 displays relevant columns from the process flow worksheet for this model.
Figure 9-36: Process flow worksheet, tst1 model. Before testing, lots are mounted on product-specific test boards. A product-specific setup is required at the tester. Upon completion of testing, the test board and tester are freed at the same time. With check-request priorities, it is possible to ensure that if another lot of the same product is waiting for a test board, this lot will be mounted on the just-freed test board, and that test board will enter the queue for the tester, before the tester decides what lot to work on next.
The key in this model is what happens when testing is completed. In the Factory Explorer simulation, the product-specific test board and the tester are released at the same
9.17. Controlling the Order of Simultaneous Check-Request Events time, resulting in simultaneous check-request events. In reality, since setup-avoidance is enabled, the operator would probably look to see if another product of the same type is in the queue. If so, the operator would mount the matching product to the test board and test it, thus avoiding a setup. In the simulation, this sequence of events will only occur if the check-request event for the test board executes before the check-request event for the tester. If the check-request event for the test board occurs first, Factory Explorer will see that another lot of the same product is waiting to be mounted, will mount it, and will move the lot into queue in front of the tester. Thus when the tester's check-request event fires, it will find that it can do another lot with the same setup I.D., and hence avoid a setup. If the check-request event for the tester executes first, however, Factory Explorer will not see any more lots in front of the tester with the appropriate setup I.D., and it will incur a setup in order to process a lot from a different product type. In order to control the order of check-request events, this model uses the CHECKPRI column on the Tools worksheet. Figure 9-37 displays the relevant columns from this worksheet.
Figure 9-37: Tools worksheet, tst1 model. Entries in the CHECKPRI column tell Factory Explorer that check-request events for the test boards have a better priority than those for the tester, and hence should be executed first.
With check-request priorities entered, setup hovers around 16% for long simulation runs, and the system is quite stable. Without check-request priorities,
9. User's Guide: Additional Modeling Capabilities however, the extra setups cause setup to rise above 20%, and the system exhibits very unstable behavior.
9.18 Modeling Complex Setups

Within Factory Explorer, it is possible to model tools with complex setup rules. The workbook complex_setup1.xls contains an example illustrating a tool with multiple setup groups and multiple setup IDs. In this case, a track tool can be used as both a coater and a developer. There are two coat recipes requiring two different temperatures while there is only one develop recipe. When a coat lot is run, it has to wait only if its recipe calls for a different temperature from that of the previous coat batch. This may happen even though there may have been several develop lots in between. When a develop lot is run, the develop batch is never delayed. The products and operators worksheets do not contain details specific to setup models, so we do not display them here. At the tool group level, shown in Figure 9-38, there are two setup group names: Coat and Develop. In the Coat setup group, there are two setup IDs Coat1 and Coat2 -representing the two temperatures. For the Develop setup group, there is only one Setup ID. Notice also that the setup time fields are set. If necessary, the From Setup ID field can be specified for sequence independent setup.
Figure 9-38: Tools worksheet, complex_setup1 model. Multiple setup IDs are used for the Coat setup group.
9.18. Modeling Complex Setups At the process step level, this setup ID can be modeled using the wildcard. For specification of setup IDs, Factory Explorer allows the use of four wildcards: %Product, %Process, %Operation, and %Step. Wildcards are not case sensitive, and can appear anywhere in the ID. Multiple wildcards can appear in a single ID. This section presents a sample model that uses the %Step wildcard. In this case we are using the %Step wildcard as Coat1 and Coat2 in the Process1 and Process2 worksheets, respectively. This is shown in Figure 9-39 and Figure 9-40.
Figure 9-39: Process1 worksheet, complex_setup1 model. Note the use of wildcards to supply setup IDs within Cost and Dev setup groups.
Figure 9-40: Process2 worksheet, complex_setup1 model. Note the use of wildcards to supply setup IDs within Cost and Dev setup groups.
9.19 Cluster Tool Modeling

Factory Explorer models cluster tools as having a number of different tool states. The processing rate of each step performed on the cluster tool can be adjusted based on the active tool state. Throughout the run, cluster tools transition from state to state, adjusting their processing rates appropriately. The combination of the amount of time spent in each tool state and these processing rate impacts affect the overall capacity of the tool and the system. A cluster tool model requires the following information: Cluster tool state names Initial tool state State-specific processing rate multipliers for each process step utilizing the cluster tool Distribution for the amount of time in each tool state State-to-State transition percentages
9.19. Cluster Tool Modeling Modeling a cluster tool starts with the identification of the relevant tool states (i.e. the states that have significant processing impacts), as well as the initial state the cluster tool is in when the analysis begins. Then, the amount of time the cluster tool spends per visit to each state must be determined. A distribution template may be used to specify these values. State-to-state transition percentages describe the proportion of time the cluster tool moves into each tool state upon departing from a given state. Finally, the processing rate multipliers for each tool state and process step combination must be specified. This is done using the Operation ID from the process worksheet. Based on the distribution of time the tool operates in each tool state and the stateto-state transition percentages, the proportion of time the cluster tool spends in each state is calculated. Then, this information is applied to come up with an average processing rate for each process step that utilizes the cluster tool. These adjusted processing rates are incorporated in both Factory Explorers capacity analysis and simulation analysis. See Section 20.5 for more details. 9.19.1 Sample Model of a Simple Cluster Tool Factory Explorers sample Cluster_A3.xls model illustrates a simple cluster tool. Figure 9-41 displays the relevant columns from the tools worksheet for this model. In this simple case, the cluster tool has 3 identical chambers. This tool has 4 tool states, described by the number of chambers that are functioning. A single process operation is run on this tool. Table 9-6 contains the data for this cluster tool.
Table 9-6: Tool state descriptions and parameters for simple cluster tool in Cluster_A3 model.
State Description
A3 A2 A1 A0
All chambers up 2 chambers up 1 chamber up All chambers down
Init Process Rate Multiplier X 1.000 0.667 0.333 0.000
Time in State (Hours) 80 10 8 4
Initially, the tool begins fully functional (tool state: A3). The actual processing rate of this tool is directly proportional to the number of functioning chambers. Note that this value is used to scale the actual processing rates associated with the particular process step. Typically, the processing times on the process worksheet will be based on the tool being fully functional and the state-specific process rate multipliers will be used to scale down the process time for states where some chambers are down. In particular, a process rate multiplier of zero is used when a process step cannot be performed when the cluster tool is in a given tool state (as is the case here with tool state A0). Note that process rate multipliers of 1 are not required in the model data (since they will not impact the process rate), although they may be included for clarity. The final column in Table 9-6 contains the observed amount of time the tool spends in each tool state before transitioning to another tool state. In Cluster_A3.xls, this transition time is modeled using an exponential distribution template.
9. User's Guide: Additional Modeling Capabilities The final component of a cluster tool model are the state-to-state transition percentages that detail how the cluster tool moves between tool states. Table 9-7 contains the observed transition percentages for the cluster tool in model Cluster_A3.xls. For example, when the tool departs from tool state A1 (1 chamber up), 70% of the time it will enter tool state A2 (2 chambers up) and 30% of the time it will enter tool state A0 (all chambers down).
Table 9-7: State-to-state transition percentages for simple cluster tool in Cluster_A3 model.
From/To A3 A2 A1 A0
A3 70 0 10
A2 90 70 30
A1 0 20 60
A0 10 10 30 -
In this model, there is some chance of the entire tool failing from every tool state (all tool states have some transition to state A0). Similarly, the tool may go from all chambers down (A0) to any of the other tool states. Other than these, the only transitions allowed in this model are the addition or subtraction of a single chamber (transitions such as A3 A1 are uncommon and are ignored in the model). Note that transitions from a tool state to itself (e.g. transition from A3 A3) are not permitted. Also, the sum of the percentages from a given tool state must equal 100%. Note that zero state-to-state transition percentages (e.g. A3 A1) are assumed by default and are not required in the model data.
9.19. Cluster Tool Modeling
Figure 9-41: Tools worksheet, Cluster_A3 model. Tool states, time in each state, the initial tool state, state-to-state transition percentages, and state-specific operational impacts have been entered.
9.19.2 Sample Model of a Multi-Operation Cluster Tool Factory Explorers sample Cluster_SSG.xls model depicts a cluster tool where different operations are processed in different chambers. Figure 9-42 displays the relevant columns from the tools worksheet for this model. The cluster tool in this model contains 2 S chambers and 1 G chamber. This tool has 6 tool states, described by the number of functioning chambers of each type. This tool processes both S and G operations. Figure 9-43 displays the process flow worksheet from this model, which illustrates how the Operation ID is used to associate a process step with a tool state-specific process rate multiplier. Table 9-8 contains the data for this cluster tool.

Table 9-8: Tool state descriptions and parameters for Cluster_SSG model. Note the state-conditional process rate multipliers for Operation G and Operation S.
State
Init
S2G1 S2G0 S1G1 S1G0 S0G1 S0G0
Process Rate Process Rate Multiplier Multiplier Operation G Operation S 1.000 1.000 0.000 1.000 1.000 0.500 0.000 0.500 1.000 0.000 0.000 0.000
Time in State (Hours) 100 4 24 8 12 20
Initially, the tool begins fully functional (tool state: S2G1). For a given operation, the actual processing rate of this tool is directly proportional to the number of functioning chambers that are valid for that operation. For example, when the tool is in tool state S1G0, the processing of all S operations is only half as fast as when the tool is fully functional because 1 of the 2 S chambers is inoperable, and processing of any G operations is not permitted because the single G chamber is down. The final column in Table 9-8 contains the observed amount of time the tool spends in each tool state before transitioning to another tool state. In Cluster_SSG.xls, this transition time is modeled using an exponential distribution template. The final component of a cluster tool model are the state-to-state transition percentages that detail how the cluster tool moves between tool states. Table 9-9 contains the observed transition percentages for the cluster tool in model Cluster_SSG.xls.
Table 9-9: State-to-state transition percentages in multi-operation cluster tool in Cluster_SSG model.
From/To S2G1 S2G1 S2G0 30 S1G1 30 S1G0 0 S0G1 0 S0G0 30
S2G0 20 0 40 0 10
S1G1 70 0 40 70 0
S1G0 0 60 10 0 30
S0G1 0 0 40 0 30
S0G0 10 10 20 20 30 -
9.19. Cluster Tool Modeling
Figure 9-42: Tools worksheet, Cluster_SSG model. Tool states, time in each state, the initial tool state, state-to-state transition percentages, and state-specific operational impacts have been entered. Note that transition percentages of 0 and process rate multipliers of 1 are in effect by default and need not be specified.
Figure 9-43: Process flow worksheet, Cluster_SSG model, illustrating how the Operation ID of a process step is specified. This Operation ID is used on the tools worksheet to specify state-specific process rate multipliers..
9.20 Tool Group Buffers

Tool group buffers enable the (optional) modeling of limited WIP storage. Each tool group may have an input buffer and an output buffer, with specified capacities in terms of lots. Input buffers limit the number of lots waiting at the tool group for a tool to become available. Output buffers limit the number of processed lots waiting to travel from the tool group. By default, each tool group has infinite capacity input and output buffers. The use of input and output buffers is independent at each tool group, as well as between tool groups (i.e. each buffer is independent of all other buffers). A lot will only begin activity on a tool if there is availability in the output buffer for the tool group. Tool groups with output buffers will be blocked when the buffer is full. Upon seizing a tool from a tool group, the available capacity of the output buffer is decremented and the availability of the input buffer is incremented. Upon completing activity at a tool group, a lot will only begin travel to the next downstream tool group if there is input buffer availability to accommodate it. Otherwise, the lot will remain in the upstream output buffer until there is availability in the downstream input buffer. Whenever a lot leaves an input buffer, all upstream tool groups are notified of the availability and will attempt to initiate travel for any waiting lots (pulling a new lot into 232 Factory Explorer Copyright WWK 1995-2009
9.20. Tool Group Buffers the downstream input buffer). Upon initiation of travel, the available capacity of the downstream input buffer is decremented and the availability of the upstream output buffer is incremented. Whenever a lot leaves the output buffer, the tool group will attempt to begin processing a new lot. Figure 9-44 illustrates a simple assembly line with tool group buffers in place at upstream tool T1 and downstream tool T2. All input and output buffer in this example have a capacity of 1 lot. At this point in time, tool T1 is blocked from processing lot D since its output buffer is currently occupied by lot C. Lot C cannot travel to tool T2 because lot B is occupying the downstream input buffer. Lot B must wait to begin processing until tool T2 completes work on lot A.
Figure 9-44: Simple assembly line with single capacity buffers. In this figure, tool T1 is blocked from processing waiting lot D because there is no capacity available in its output buffer due to downstream congestion.
Figure 9-45 shows the above assembly line immediately after lot A finishes processing. At this point, tool T2 pulls lot B from its input buffer and begins processing. This frees space in the input buffer at tool T2, allowing lot C to travel from the output buffer at tool T1. The departure of lot C frees space in the output buffer at tool T1, which unblocks tool T1, allowing it to begin processing of lot D. Note that the system may only be constrained when an upstream output buffer is feeding a downstream input buffer effectively limiting the amount of WIP that can be physically stored between two tool groups.
Figure 9-45: Simple assembly line with single capacity buffers, immediately after lot A has completed processing at tool T2. Upon completion, lot A moved into the output buffer at tool T2, freeing capacity upstream, which resulted in a chain-reaction pulling lots downstream. In particular, tool T1 is unblocked and may begin processing lot D.
9.20.1 Tool Group Buffer Rules Factory Explorer enforces the following rules when modeling tool group buffers: 1. 2. 3. 4. 5. Buffer sizes must be greater than zero. The first step in a process may not use a tool group that has an input buffer. The last step in a process may not use a tool group that has an output buffer. Buffers may not be placed on a tool group that processes a split or unsplit step. Buffers may not be placed on a batch tool group.
Tool group buffers are not addressed by Factory Explorers capacity calculations.
9.20.2 Sample Model of Tool Group Buffers The tool group buffer sample model, TGBuffer.xls, contains two tool groups, Upstream and Downstream, each containing a single tool. There is a single product, Wafers, that arrives at a rate of 4 lots/hour. The processing time at the Upstream tool is a constant 15 minutes. The processing time at the Downstream tool is exponentially distributed with a mean of 12 minutes. The tool group buffer functionality is activated by setting optional buffer sizes on the tool group worksheet, as shown in Figure 9-46, where the Upstream output buffer and Downstream input buffer are each capped at a single lot.
9.20. Tool Group Buffers
Figure 9-46: Tools worksheet, TGBuffer model. The Upstream tool has an output buffer with a capacity of 1 and the Downstream tool has a capacity of 1. This will limit the amount of WIP storage between the two tools. Table 9-10: Scenario parameters, results and comments for various runs of TGBuffer model.
Run
A B C
Up Output Buffer N/A 1 N/A
Down Input Buffer N/A N/A 1
Up Util 100% 100% 100%
Down Throughput Comments Util 78.9% 8735 78.9% 8735 78.9% 8735 Unbuffered control case No constraint on WIP same results No constraint on WIP same results, Downstream queue lengths are capped Constrained lower utilization Less Constrained
D E
1 3
1 1
91.4% 72.1% 7987 97.2% 76.8% 8489
Table 9-10 contains the results when the TGBuffer.xls model is run with varying buffer sizes. Run A is the unbuffered, unconstrained scenario. Run B and Run C are practically unconstrained, since there is not both an upstream output buffer and a downstream input buffer to create a WIP storage limitation between the tool groups. Run D is tightly constrained with only room for 2 lots between the two tools, one lot in each Copyright WWK 1995-2009 Factory Explorer 235
9. User's Guide: Additional Modeling Capabilities buffer. This results in lower utilization at both tools the Upstream tool is occasionally blocked when both buffers are full and the Downstream tool is occasionally starved because WIP build-up is limited. Because of these impacts, throughput also declines relative to the unconstrained scenarios. Run E relaxes the storage limitations by increasing the capacity of the output buffer at the Upstream tool. This alleviates, but does not eliminate, the impact of the buffers - the Upstream tool can still be blocked and the Downstream tool can still be starved.
9.21 Alternate Operator Groups and Work Schedules

The traditional method for modeling operators in Factory Explorer is to specify a single operator group per process step for load, process, and unload. These so called super operators are defined on the Operator worksheet and are available whenever the factory is in operation. The basic assumption is that the number of operators specified is the average number of operators available at any time during the model run or between effective dates. Starting with FX v2.9, it is possible to model operators in a more realistic fashion that includes alternative operator groups at each step, work schedules for each operator group, differing skills for cross-trained operator groups, and overtime pay scales. Use of the run-time option DelOpGroups will ignore all operator groups regardless if they are super operators or use the schedule features. The UseSugg run-time option will ignore all schedules and report results as if all operator groups are super operators. Due to the potential complexity of these calculations, it is highly suggested that only simulation results be used to make decisions regarding alternate operator groups and work schedules. 9.21.1 Alternate Operator Groups Much like the use of tool groups at alternative steps, alternative operator groups allow more than one operator group to be used at a process step. However, unlike the alternative step which requires a new process step and a percentage split, the alternative operator group is simply entered as an extra row under the existing process step. FX will determine which resource is available based first on the highest skill (see Section 9.21.3), if entered, and then decending from the top of the list. This technique works for either the super operator construct or in conjunction with operator group schedules (see Section 9.21.2) where operator groups working the same tasks but on different shifts can be given unique names. The latter is the preferred naming convention if it is anticipated that one of the shifts will be a contraint. Alternative operator groups are only allowed to be entered for the load, process, and load functions. Where separate operator groups are used for setup and transportation, only one operator group may be specified for those functions. There are some rules regarding the use of alternate operator groups: 1) The same operator group cannot be listed twice for the same process step (ie an operator group cannot be an alternate group to itself). 2) Due to limitations on capacity analysis, when using alternate operator groups, the first named operator group in the list cannot be the first name
9.21. Alternate Operator Groups and Work Schedules in another list unless the list is identical to the first. This is applied across the model for all process worksheets.
Figure 9-47: ProcessA worksheet showing an alternate steps using the AME1 and AME2 toolgroups and the AME and GENERAL operator groups.
9.21.2 Operator Schedules The OpSchedule worksheet allows the user to breakdown the super operator construct into actual times when operators are available. The schedules can be overlapping to handle situations such as manufacturing turnover which aids in communications between shift workers. The schedules are assigned to the operator groups on the Operator worksheet. If schedules are used, FX requires that a start date be specified in the runtime options even if no Effective Date columns are used elsewhere in the model. Additionally, FX reads the schedules in the order in which they are entered. So, if the schedules start on a Monday and end on a Sunday, FX will interpret that the first listed Sunday is first available on the seventh work day. This is only an issue when the model start date selected is the day just prior to the first day listed in the schedule, Sunday in the above example. In this case, FX will interpret the schedule as no operators
9. User's Guide: Additional Modeling Capabilities are working on the first day of the model run. This will create unusual WIP situations at the start of the model.
Figure 9-48: The OpSchedule worksheet allows for the construction of complex work schedules To use the OpSchedule worksheet the model must specify a start date in the run-time options.
There are some rules regarding the use of schedules: 1) Schedule names may only be used once per operator group. In the following figure, the AME operator group lists shifts 1, 2, 3, and 4. It would not be valid to enter shifts 1, 2, 3 and then 1 again. 2) Within a model, an operator group can either use schedules or not as long as this is consistent during all effective dates. 3) If the INF function is to be used, it must only be entered for the number of operators for the first named shift. This is the equivalent of specifying an infinite number of super operators for that operator group (ie schedules for that group are ignored). If the INF function is used, it must be used across all effective dates for that operator group.
9.21. Alternate Operator Groups and Work Schedules 4) If a number of operators is specified, it can be different for each shift. The first shift must specify a number or INF. However, if the number of operators is left blank for any shift after the first, FX will assume that the number of operators available for the remaining shifts will be equal to the last entry above it. 5) If the schedule name is blank in the first row, then the number of operators listed for the first row will become the number of super operators in that operator group. All other schedules and number of operators for that group will be ignored. This can also be used to move back and forth between a shift based model into a traditional super operator model. If this function is used, it must be used across all effective dates for that operator group.
Figure 9-49: Work schedules are assigned to operator groups on the Operator worksheet. In this example, the AME operator group is not renamed for each shift even though there are different operators available per shift.
Figure 9-50: In this example, the AME operator group is renamed for each shift to allow results to be reported for each work shift. This is the recommended naming convention. Additionally, each AME group will need to be listed on the Process worksheet as an alternative operator group for the appropriate steps.
9.21.3 Operator Skills People are not homogenous. They differ in skills, motivation, and training. In order to model this reality, we introduce the concept of each operator group having some capability. Capability describes both 1) which toolgroups each operator group is trained to work on and 2) their respective degrees of skill/proficiency in working with each toolgroup. The OpSkill worksheet allows for the entry of this type of data. There are four input fields in the OpSkill worksheet, three of which are required. The DATE field is optional, as it is in the rest of FX, and will function in the same way as the other DATE fields. In this case, it could be used to allow users to schedule future operator capabilities changes, such as an increase in operator capability that results from the completion of a training course. The OPGROUP field contains the operator group names that correspond to the list found in the Operators worksheet. The TOOLGROUP field specifies which toolgroups the associated operator group is capable of working on. Operator groups may be capable of working on multiple toolgroups. The Process worksheet is the controlling entity for 240 Factory Explorer Copyright WWK 1995-2009
9.21. Alternate Operator Groups and Work Schedules which toolgroup/operator group pairings are valid. Any listings in the OpSkill worksheet that is not used in the Process worksheets are ignored. The OPSKILLFACTOR field allows FX users to input the skill factor for a given operator group on a given toolgroup. The baseline skill factor for an operator group is 0. A 0 indicates that the operator group works at the mean productivity level for the toolgroup, meaning FX uses the entered values for load and unload times. The OPSKILLFACTOR works intuitively based on a higher is better performance metric and is expressed on a decimal basis. For example, an OPSKILLFACTOR greater (less) than 0 indicates the operator group can perform tasks (e.g., load and unload) on the corresponding toolgroup faster (slower) than the entered values. The OPSKILLFACTOR provides a means of specifying an intuitive speed increase or decrease for the operator group. For example, if an OPSKILLFACTOR for a toolgroup is 0.10. This indicates that the operator group can operate the toolgroup 10% faster than the entered rate. Consider the calculation of required tool load time as captured in FXs LOAD field on process flow worksheets. The method for calculating required tool loading would now be given by: Actual Load Time = Base Load Time * (1 OPSKILLFACTOR) For example, if the base load time for a toolgroup is 3 minutes, then the operator group would be capable of loading a tool in the toolgroup in: Actual Load Time = 3 mins * (1 0.10) = 2.7 minutes Only enter those toolgroup/operator group combinations where the operator group has a non-zero OPSKILLFACTOR. This will provide the fastest execution speed for the model. An entry of 1 sets the load and unload times to zero. An entry of -1 sets the load and unload times to double the entered values. All entries must be between -1 and 1. 9.21.4 Operator Overtime The final update to the Operator worksheet is the ability to model overtime. This is done by adding three fields to the Operator worksheet, OTHORIZON, OTVALUE, and OTFACTOR. The OTHORIZON field specifies the number of days over which overtime is being accrued. This is meant to model a rolling set of time periods OTHORIZON in length, not a set of overlapping OTHORIZON periods. In an example where OTHORIZON equals 14, day one through 14 is the first period wherein overtime is assessed and then day 15-28 is the subsequent period, rather than days one through 14, days two through 15, and so on. The OTVALUE field specifies how many total hours worked that operators must exceed to receive overtime compensation. Finally, the OTFACTOR field specifies the wage rate multiple that is applied to the operator groups base hourly rate for overtime wages. For example, an OTFACTOR of 1.5 amounts to time and a half.
Figure 9-51: The OpSkill worksheet allows for alternate operator groups to have differing skill sets when operating the same toolgroup. The OPSKILLFACTOR is applied to the load and unload times.
The overtime logic specifies that every OTHORIZON days, if the operator groups total hours worked exceeds OTVALUE, then the hours worked in excess of OTVALUE will be compensated at a rate of OTFACTOR * the base wage rate.
9.22. Merge Model Data
Figure 9-52: The AME operator group has a maximum 80 hours worked in 14 days before being paid at 1.5 times their normal hourly wage.
9.22 Merge Model Data

Selecting Merge Model Data from the FactoryX menu will allow the merging of data from an SQL Server database, such as FabTime, into the FX input worksheets. The resulting dialog will connect to the SQL Server database containing the data to merge with the Factory Explorer model. Upon successful login, the Merge Model Select Data Dialog will display allowing you to select specific types of data to merge.
Figure 9-53: Selecting the FactoryX menu and Merge Model Data opens the following dialog box.
Figure 9-54: The Merge Model Data dialog box with the Server, User, Password, and Database inputs.
Server Specifies the server where the SQL Server database with product flow data to merge resides. User Specifies a user with access to the table in the SQL Server database with product flow data to merge.
9.22. Merge Model Data Password Specifies the password for the user specified in the user input field. Database Specifies the database where the SQL Server product flow data to merge resides. Login Connect to the SQL Server database containing the data to merge with the Factory Explorer model.
Figure 9-55: The Merge Model Data dialog box with factory select and merge choices.
The Select Data dialog will allow you to select specific types of data to merge with a Factory Explorer model. Factory Allows you to select a specific factory to merge with a Factory Explorer model. The SQL Server database may contain multiple factories. Selecting a specific factory will limit the data retrieved for the merge data types selected below to a specific factory Merge Flow Data If this checkbox checked, Factory Explorer will query the SQL Server database for the following flow fields:
Flow: The name of the product flow. Sequence: The sequence number of the product flow step from the SQL Server data. Step: The name of the step within the product flow (matched against a Step on a FX product flow worksheet.
A SQL statement must already exist in the SQL Server database referencing the table and column names where the product flow data to merge exists. The merge flow data process performs the following tasks: A. Determine if the SQL Server flow matches a FX product flow worksheet
Flow match criteria
1. If the SQL Server Flow is a valid Excel sheet name, the Flow match will be between the SQL Server Flow and the FX product flow worksheet name

2. If the SQL Server Flow is not a valid Excel sheet name, the Flow match will be between the SQL Server Flow and the value on the FX product flow worksheet Step column Row 3
Flow match
1. If requested, the original FX product flow sheet to merge is copied before any changes are made. 2. To rerun the merge program delete the modified merged sheet and rename the copy to the original name
No SQL Server flow - FX product flow worksheet match

1. Create a new FX product flow worksheet with all the SQL Server data copied over. 2. Add the new FX product flow worksheet name to the FX product worksheet a. If requested, the existing FX product worksheet will be copied before changes made. b. If no FX product worksheet exists a new one will be created.
Notes
Before any existing FX worksheet is copied (Product or Product flow), the user is prompted to determine if copying worksheets is required. If copying is not required, no FX worksheets will be copied for the length of the run.
B. Try to match a SQL Server step on a particular FX product flow worksheet The merged FX product flow worksheet contains the following columns added by the merge program:
Column 2 - InputStepNo - The merge program generated InputStep data step number Column 3 - InputStepSeq Column 4 - FXStepNo - The merge program generated FX flow data step number
Step match results.

1. The InputStepNo and InputStepSeq filled in and a blank FXStepNo indicates a SQL Server data record inserted because there was no FX product flow match 2. InputStepNo, InputStepSeq and FXStepNo filled in indicates a match between an SQL Server data step and an FX Flow step 3. The final result is in order by SQL Server Sequence 4. Only the SQL Server steps are included in the final result. Any data in the original FX product flow worksheet which was not matched to a SQL Server step is deleted
Merge Product Data If this checkbox checked, Factory Explorer will add a new data record to the Product worksheet. The Merge Flow checkbox must be selected for product data to be created. The product data added is from the already retrieved Merge Flow data. A. If the Product worksheet does not currently exist, one will be created. B. If the process already exists on the Product worksheet, it will not be added again. C. If the product flow worksheet exists at the start of the merge process, the product flow data will not be added to the product worksheet. Merge Lot Data If this checkbox checked, Factory Explorer will: A. If requested, the original FX Lot sheet is copied before any changes are made. B. Delete any existing Lot worksheet C. Create a new Lot worksheet D. Add new Lot information from the SQL Server database.
9.22. Merge Model Data A SQL statement must already exist in the SQL Server database referencing the table and column names where the lot data to add to Factory Explorer exists. Lot data will be limited to the specific factory selected above.
10. User's Guide: Managing a Successful Analysis Project1
10.1 Introduction
In this chapter, we identify and discuss the features we believe are key to the successful use of Factory Explorer as a manufacturing support tool. Drawing upon past experience, we discuss the ideal project lifecycle model design, development, and deployment. For model design, we emphasize the importance of a clear and consistent specification, articulated in a written document. This specification should identify project customers, goals, and deliverables. We next review a range of model development options, stressing the existence of many non-simulation alternatives. We also discuss methods for model verification and validation. Finally, we consider the difficulties of model deployment, including output analysis, data maintenance, and model integration. We close with several suggestions on how best to present analysis results to a management audience.
10.2 Project Lifecycles

Most factory analysis projects pose questions that can be answered a variety of ways. One such method is physical experimentation making changes in the real factory and analyzing the results. An example might be a new configuration of a workcell, which is tested out in a small area before being implemented in the whole factory. Physical experimentation is not always possible, however, especially when planning for a new factory. Even in an existing factory, it is often prohibitively expensive to experiment with the real facility. Increasing equipment quantities, for example, can require many months of product lead time, not to mention sizable capital investment. Therefore, it is usually necessary to build a model of the real factory, and perform experiments in this virtual environment. In an ideal world, modeling projects would progress in an orderly fashion through three distinct phases model design, development, and deployment. In reality, however, these phases often overlap, or are repeated as later phases shed light on errors or
1
Adapted from Chance, Robinson, & Fowler (1996).
10. User's Guide: Managing a Successful Analysis Project omissions in earlier work. Changes in project scope can also cause iterations through these phases. Often, the later work cannot even be clearly defined until the earlier phases are completed. Interaction is usually needed between the customer and the analyst to clear up details and discuss new possibilities. However, by following as closely as possible the model design, development, and deployment phases, we believe that it is possible to minimize false starts. In the remaining sections of this note, we outline some key features that we have found contribute to successful manufacturing analysis projects.
10.3 Model Design

Building and using a factory model can be a daunting task. The sheer size and complexity of most factories makes it difficult to completely view and understand all of the many elements found there. These elements include products, processes, tools, material handling systems, inventory, and operators. We believe that the goal of any modeling project is to develop a model that reflects enough, but not too much, of this complexity. Models with excessive detail take longer to build, debug, and understand, are harder to maintain, and have longer run times than less detailed models. The guiding light in determining how much complexity is necessary should be the questions posed of the model. Clarification and documentation of these questions, then, is of paramount importance, and is the primary goal of the design phase. 10.3.1 Identifying Project Customers The first step in the design phase is identifying who will use the results the project is meant to create. Potential customers might be from the shop floor, or from a corporate planning department. In many cases, a project will have several customers, each of whom has his or her own expectations. Prioritizing among the needs of these different customers may not be the analyst's responsibility. However, the analyst must sometimes consolidate various customer objectives, and identify which of these, if any, conflict. 10.3.2 Identifying Project Goals As indicated above, a project may have multiple customers, and / or multiple goals. Tradeoffs may be necessary. The goals ultimately selected help determine the planning horizon, and should be stated in terms of quantifiable performance measures. The specification of project goals should also include a project timeline with deliverables highlighted. 10.3.3 Identifying the Planning Horizon The planning horizon to which the model will be applied is important in determining the level of detail to include. A common classification of planning horizons is strategic, tactical, and operational. Although no formal definition of these horizons exists, strategic models are usually concerned with long-term questions like "should I build a new factory, and if so, what should I produce in it?" Tactical models address questions like "how many units should I start this quarter?" Operational models are concerned with production over the next day or week.
10.3. Model Design The way in which a model adds value is highly influenced by the project's planning horizon. For example, at the strategic level the analyst has the opportunity to make recommendations that save (or cost) the company millions of dollars in equipment purchases. In this case, there is a large value to answering these few key questions correctly. At the operational level, the analyst has the opportunity to set in place a system that will help with many day-to-day or hour-to-hour decisions ("what lot should I run next on this machine?" or "when should I promise this order will be shipped?"). Here, there is a large cumulative value to making these many small decisions correctly. 10.3.4 Identifying Performance Measures Performance measures are necessary to quantify project goals. Performance measures should be tracked in the real world, not just in models. In some cases, real world performance measures can be compared against those generated by the model during model validation. Most projects will deal with some performance measure stated in monetary terms, e.g. product cost, total fixed cost, etc. Other common performance measures are cycle time, WIP, and capacity (expressed in terms of maximum starts per week, say, or maximum units out per week). 10.3.5 Writing a Project Specification Ideally, every project should have a document that provides a black-and-white synopsis of project design. This document should identify the customer or customers, the planning horizon, the project goals (stated in terms of quantifiable performance measures), and the expected deliverables. Where possible, the expected deliverables should be expressed in the form of mock results charts. The analyst is then responsible for filling in the charts with actual model output. This helps to ensure that the results provided from the project are in the format that the customer needs. Figure 10-1 displays the table of contents for a sample project specification.
1. 2. 3. 4. 5. 6. 7. Executive Summary Issues 2.1. Unresolved 2.2. Resolved Action Items 3.1. In Progress 3.2. Completed Definitions Assumptions Project Goals Deliverables 7.1. Deliverable 1 7.1.1. Results Template 7.1.2. Description Of Analysis 7.1.3. Actual Results Miscellaneous Results Project Timetable Model Validation Model Development Plan
8. 9. 10. 11.
Figure 10-1: Sample Table of Contents for a Project Specification
Figure 10-2 displays a mock results chart for a sample project that is concerned with planning toolset and staffing levels under mix / volume uncertainty. This chart displays two performance measures, toolset cost and annual profit, for four candidate
10. User's Guide: Managing a Successful Analysis Project scenarios. Figure 10-3 displays a mock results chart for a second sample project concerned with cycle time optimization via capital purchases.
$2.5 $350 $300 Toolset Cost (Millions) $2.0 $250 $1.5 $200 $150 $100 $0.5 $50 $A B C Mix/Volume Scenario D $Annual Net Profit (Thousands)
$1.0
Toolset Cost (Left Scale)
Annual Net Profit (Right Scale)
Figure 10-2: Toolset Cost and Annual Net Profit for Four Mix/Volume Scenarios
5 4.5 Average Cycle Time (Days) 4 3.5 3 2.5 2 1.5 1 $0.0 $1.0 $2.0 $3.0 $4.0 Capital Expenditures (Millions) Beyond Minimum Cost Toolset
Figure 10-3: Average Cycle Time vs. Additional Capital Expenditures
In addition to summarizing what the analyst will deliver, the specification should also include customer responsibilities. In particular, the specification should document what data the customer will provide, and in what basic format (electronically, on paper, in spreadsheets, etc.). In our experience, misunderstandings about the quality of the data available, and who is responsible for improving it, can result in considerable project delays. The specification should be a living document. As the project scope or deliverables evolve, the specification should be updated to reflect these changes and their impacts. These changes, however, require that both the customer and the analyst are in agreement, and the specification often serves as a good negotiation tool. While the specification should not be changed radically in the midst of the project, adding specific details and refinements as they become apparent is beneficial.
10.4 Model Development

Once the project specification has been written, model development can begin. This requires selecting a methodology and tool, building the model, populating the model with
10.4. Model Development the necessary data, and verifying and validating both the model and the data. Decisions in this phase of the project depend in particular on whether the model is intended for single use or for on-going support. For the latter, the question of who will actually own and maintain the model is important. Also of obvious importance is the type of question being answered by the model. Certain modeling methodologies are more appropriate for certain types of questions. In some cases, what types of tools are available can drive the questions that are asked in model design. In other cases, the customer may specify the use of a particular tool or methodology. In general, we feel that the customer should identify questions to be answered, while the analyst should be primarily responsible for actual model selection and development. 10.4.1 Selecting a Methodology and Tool Many different methodologies and tools are available to support manufacturing projects, including spreadsheets, analytic models, data-driven simulation models, simulation languages, and general-purpose programming languages with simulation libraries. Some projects may require the use of more than one tool to answer different types of questions. Some strengths and weaknesses of these tools for different applications are discussed below. Spreadsheet models are appealing for projects where a large number of scenarios must be evaluated quickly. They are fast, easy to understand and use, and easy to modify. Managers are generally accustomed to reviewing results presented in spreadsheet-based formats. However, there are limits to the types of questions that can be addressed with spreadsheet models. Spreadsheet models are static, generally grouping time into large buckets. They are also usually deterministic. Though spreadsheets typically include the ability to sample from distributions, this capability is not usually exploited in manufacturing applications. Because of these limitations, spreadsheet models are often not capable of estimating cycle time or WIP. Analytic models include capacity analysis, queuing, linear programming, and other math programming models. For an example of the successful application of linear programming-based methods to manufacturing production planning, see Leachman et al. (1996). Like spreadsheet models, analytic models are useful for evaluating multiple scenarios, because they are typically very fast. Analytic models can also include detail beyond that of spreadsheets. For example, capacity analysis models can accurately capture complexity such as rework, batch processing, and re-entrant flows. Queuing models can improve upon spreadsheet models by including variability with arrival and service time distributions. Most of the results available in the area of queuing models, however, are only applicable to long-term, steady state behavior. Queuing models can thus be used to estimate long-run average cycle times and WIP, but not short-term behavior (although there is active research in this area, we have not seen any commercial applications of the methodology to date). The results from analytical models are relatively easy to interpret, because they consist of a single number for each performance measure. However, the simplifying assumptions necessary to get closed form results are not always appropriate, especially in
10. User's Guide: Managing a Successful Analysis Project queuing models. Analytic models are best suited to strategic and tactical questions, where the emphasis for dynamic behavior is on relative performance. Discrete event simulation can capture virtually any level of manufacturing detail, and is potentially very accurate. It captures both dynamic (time-dependent) and stochastic (random) behavior. Simulation is sometimes used in the early stages of a project to help understand how the system works. It has intuitive appeal for managers, especially when animation is used, because they can see' what is going on in the model. However, there are several disadvantages to using simulation models. They typically take much longer to run than analytic models, and the results from a simulation model can be difficult to interpret. Statistical analysis of the output is necessary, because each simulation run represents a single possible sample path. For these reasons, simulation can be an expensive option. When simulation is chosen for a project, it is also necessary to decide between data-driven simulation models (simulators), and user-developed models written in a simulation or general-purpose programming language. In our opinion, languages are more appropriate for building small, detailed models, while simulators tend to be more applicable for modeling large-scale manufacturing systems. The decision also depends on the modeler's proficiency with different tools, and on whether or not the model will be reused. Overall, tool choice for a project should be most heavily influenced by the needs of the customer, particularly if the model is to be used on an on-going basis after the project is complete. Attention must be paid to what the customer will be able to learn, use, and modify as needed. The planning horizon and the project goals will also influence which tool is appropriate. Clearly, if accurate cycle time estimation is critical, a spreadsheet model is probably not the best choice. If many different scenarios need to be evaluated quickly, with comparisons based on toolset capacity and cost rather than on cycle time, simulation may not be the best choice. We think that it is important to remember that simulation is not the only tool available. In many cases, simulation may not be required at all. The goal of the project is to answer the questions posed by the customer, using the simplest model. 10.4.2 Developing the Model and Collecting Information Once the tool and methodology have been selected, the basic structure of the model should be constructed. This requires gathering information about the real system, including things like the total number of products, the number of tools, the general sequence of steps followed by operators at the different machines, and the structure of the material handling system. The analyst should rely on the project specification to resolve disputes about what the model should be able to do and what it will not be expected to do. Tools or models that grow haphazardly over time, as different functionality is included in response to input from various sources, are extremely difficult to use. At this stage, it is important to keep in mind the overall goals of the model.
10.5. Project Deployment 10.4.3 Populating Model Data Perhaps the biggest roadblock to building models for real manufacturing applications lies in the difficulty of obtaining the proper data. In our experience, there are three classes of data: 1) the data you want; 2) the data you need; and 3) the data you get. These sets are typically decreasing in size, but are not necessarily overlapping. That is, data may be provided that is not needed for the model, even as data critical to building the model is unavailable. One suggestion is to find out what types of data will be available before spending much effort designing and developing the model. In many cases, the accuracy level of the data does not justify a complex model. If some data is simply not available, it may be possible to perform sensitivity analysis to see how important the missing data is. Only if the data will likely have a significant impact on the model are new data collection efforts necessary. Carrying this approach to its extreme, it is sometimes advantageous to build a model with a bare minimum of actual data. At that point, sensitivity analysis can be used to determine the priority areas for data collection. 10.4.4 Verifying and Validating the Model We distinguish between model verification and model validation as follows: verification is the process of ensuring that the model produces a correct output given a specified input, while validation is the process of ensuring the model accurately represents reality to the necessary degree (100% accurate representation is usually not required for a successful project). We recommend starting data verification and validation efforts as early as possible in the modeling process. An example of data verification might involve having end-users check data forms or data summary charts to see that data has been entered correctly. An example of validation would be reviewing outputs with end-users to ensure that results look reasonable. Often, it will take numerous passes before bugs in the data are completely worked out. For existing factories, another method of validation is a variant on the Turing test (see Schruben 1980). This involves taking model output data and transforming it into the same format as typical manufacturing reports. If manufacturing personnel cannot distinguish between the model output and actual factory output, then the model is probably a reasonable representation of reality. Tool utilization, cycle time, and production volumes are possible candidates for this method, as they are likely to be included on existing production reports. In some cases, there may be other models that can be used for validation (e.g. existing spreadsheet models used for capacity planning purposes).
10.5 Project Deployment

Frequently, model development and debugging consume the lion's share of the project schedule. This is in spite of the fact that the model itself is not the project's end goal. The goal is to use the model to answer the questions outlined in the project specification. For most simulation projects, this requires analyzing the simulation output, presenting the results to management, and setting up the model for on-going data collection and analysis (if needed). These topics are outlined below, followed by a brief discussion of common simulation project pitfalls.
10. User's Guide: Managing a Successful Analysis Project 10.5.1 Analyzing Steady-State Simulation Output Often, simulation projects do not require steady-state analysis. When required, however, steady-state analysis presents a variety of difficulties not found in finite-horizon analysis. Simulation texts usually treat this topic in depth (see, for example, Law and Kelton 1991). Nelson (1992) also provides a helpful overview of steady-state analysis. Two features often found in manufacturing simulations cause special difficulties highly correlated output data and initialization bias. Highly correlated data makes it difficult to produce within-run confidence intervals using traditional statistical methods. If the correlation is not taken into account, the width of confidence intervals is usually biased on the low side. This bias can cause modelers to predict significant differences between alternatives where none exist. It may be possible to batch the output data in such a way as to reduce the serial correlation to a negligible level. Otherwise, the best way to avoid the problem of correlated data is to make independent replications and use cross-replication results to generate confidence intervals. Using multiple replications, however, can aggravate initialization bias problems. Initialization bias is present in any simulation where the initial simulation state is not drawn randomly from its steady-state distribution. Since this steady-state distribution is never known exactly (otherwise, the problem would be trivial), and may not exist at all, initialization bias is present to some extent in nearly all steady-state manufacturing simulations. Since this bias usually dies away over time, one popular method is to run the simulation for a very long time and then truncate the first portion of the output. Another option is to initialize the factory with a certain amount of work-in-process inventory. With the former method, the difficulty lies in deciding how much to throw away; with the latter method, it lies in deciding initial WIP levels. Neither method is entirely satisfactory, but two qualitative observations are in order. First, the best way to determine if initialization bias is a problem is to look at time series output. For example, Figure 10-4 displays time series output for cycle time in a manufacturing simulation. From this chart, it appears there is negligible initialization bias. Figure 10-5, displays cycle time output that appears to contain significant initialization bias.
35 30 Cycle Time (Days) 25 20 15 10 5 0 0 50 100 150 200 250 300 350 400 Lot Exit Time (Days)
Figure 10-4: Cycle Time vs. Lot Exit Time for Run with Negligible Initialization Bias
10.5. Project Deployment
Figure 10-5: Cycle Time vs. Lot Exit Time for Run with Significant Initialization Bias
Our second qualitative observation is that the effect of initialization bias in manufacturing simulations generally increases as utilization rises. Thus, a truncation point that successfully eliminates most initialization bias for a highly loaded system will generally work quite well for more lightly loaded systems. In fact, the two series shown above are from simulations of the same model. Figure 10-4 displays output from a 65% utilization run, while Figure 10-5 displays output from a 95% utilization run. Not only does the second run have a higher cycle time, as we would expect, it also appears to have a longer transient effect. To set a truncation point, visually inspect output charts of data averaged across multiple replications. This averaging will smooth out random fluctuations and will make the trend easier to pick out. For example Figure 10-6 displays the cycle time output series for 95% utilization averaged across ten replications. From this chart, it appears that a truncation point of six months or more is required. At this point, we would recommend making multiple replications of somewhat longer runs to confirm that six months is in fact a reasonable truncation point.
Figure 10-6: Cycle Time vs. Lot Exit Time Averaged Across 10 Independent Replications
When it is not possible to visually examine all relevant output, one can employ a statistical test, such as the one described by Schruben, Singh, and Tierney (1983).
10. User's Guide: Managing a Successful Analysis Project 10.5.2 Presenting Simulation Results to Management When presenting results to management, there are several things to keep in mind that can increase the likelihood of model acceptance. First, display results graphically whenever possible. This makes it easier to understand tradeoffs in a short amount of time. The graphs should follow the formats identified in the project specification. Second, present only a few vital pieces of output. Do not waste managers' time by forcing them to wade through a myriad of details. In particular, make sure that the results presented answer the questions asked in the original project specification. Finally, whenever possible present results in terms of dollars. Managers have a ready grasp of the bottom line. And, ultimately, project success will be judged in terms of tangible financial results. 10.5.3 Maintaining an On-Going Model Considerably more work is required to build a model that will be used on an on-going basis. Such a model must be robust enough to be used by different people, and flexible enough to be changed over time. Systems that will be used on a daily basis will probably have to be integrated directly into existing systems. For example, a scheduling system, to be effective, must receive at least periodic updates from the shop floor control system. A strategic planning model, is more likely to exist as a stand-alone model. If the model is really only going to be used once, integrating it with existing systems is probably not worth the effort. However, models intended for a single use often end up being used on an on-going basis. This can lead to much more work than integrating the models in the first place, and can be the source of many data maintenance nightmares. 10.5.4 Common Factory Analysis Project Pitfalls Factory analysis projects can fail for a variety of reasons. Perhaps the most common problem is lack of a good project design. Models are built without regard to the questions that they will answer, and then they are not able to adequately provide the answers that are needed. Models built for single-use often end up being maintained and used over time. If they have not been designed to be used by someone other than the model developer, inaccurate results can be generated. Lack of a clear design can also result in insufficient buy-in and participation from the customer. Another common problem is data. Sometimes the necessary data does not exist, or is prohibitively expensive to obtain. Other times inaccurate data is used through oversight, or lack of clear lines of responsibility for collecting the data. A prevalent problem with factory models is that they are too detailed. As a result, they are not maintained, because data collection is such an effort, or they are not run at all because the runs take such a long time. A more subtle reason why projects sometimes fail is that the performance measures optimized in the model are different from the performance measures rewarded in real life. For example, few factory models will be able to motivate workers to reduce cycle time when pay standards are based upon throughput. In general, we believe that more of these problems stem from project management / environmental issues than from lack of technical expertise on the part of the analyst.
10.6. Summary
10.6 Summary
Despite the cautionary tone we have taken, we believe it is possible to successfully support manufacturing with analysis tools such as Factory Explorer. Based on our experience, however, doing so requires more than technical expertise. First and foremost, it requires that the analyst work with the customer to prepare a written project specification. This document should clearly spell out project customers, goals, and deliverables. Once goals are established (along with suitable performance measures), the analyst should consider the entire range of available analysis techniques. Depending on project goals, simulation may not be required. Even within the class of simulation techniques, there is usually a spectrum of choices ranging from data-driven simulators (such as Factory Explorer) to full-blown simulation languages. No matter the choice of tool, data-related problems should never be ignored or underestimated, as they often cause significant delays in model development. Model completion, however, does not guarantee project success. That comes only when the model is used to answer the questions it was built to satisfy. Then, and only then, will the model be viewed by management as an effective decision-support tool.
Part II Reference Topics
11. Reference Topics: What's New in this Release
11.1 Whats new in Version 2.10

This section describes whats new in Factory Explorer Version 2.10. The changes listed below are relative to Factory Explorer Version 2.9. Major Changes: 1. A new Merge Model Login screen was added to log into the SQL Server database containing the data to merge. This screen is separate from the old Merge Product flow data screen. After login, a new screen allows selection of a specific factory to merge and specific types of data to merge from the factory selected; Merge product data and merge lot data. 2. Added new user functions for tracking scheduled events; User_PrintEventDescriptions, User_ProcessTracedEvents, Event_GetDescriptions, Event_SetTraceOn, Event_GetName, Event_LookupName, and Misc_FXAboutShow. 3. Added the following output charts with their associated output data worksheets: a. Bottleneck Simulation Resource Chart (Columns and Bars) b. Tool Group Bottleneck Capacity Chart (Columns and Bars) c. Tool Group Bottleneck Capacity Chart w/ Product Capacity Data d. Tool Group Bottleneck Simulation Chart (Columns and Bars) e. Operator Group Bottleneck Capacity Chart (Columns and Bars). f. Operator Group Bottleneck Capacity Chart w/ Product Capacity Data g. Operator Group Bottleneck Simulation Chart (Columns and Bars) 4. Excel 2007 compatibility. Minor Changes: 1. RTO dispatch argument changed to indicate dispatch rule in use DispatchRule_SetUsedInModelFlag. 2. Scheduling Worksheet output now includes seconds.
11. Reference Topics: What's New in this Release 3. Scheduling Worksheet Product field has been increased to 20 characters from 10 characters. 4. Fixed the random number generation overflow error when input values exceed 32000. 5. Resource Type added to Bottleneck Worksheet output report. 6. Validations are added for individual lot, product, and process. 7. Added SIM Busy as percentage in Resource Planning Worksheet output. 8. Fixed depreciation calculation to become 0 after the depreciation life when a model is run longer than depreciation life. 9. Added Total Cost for All Tools to Product Cost Worksheet output.

This section describes whats new in Factory Explorer Version 2.9. The changes listed below are relative to Factory Explorer Version 2.8. Major Changes: 1. Added PRCCOMPSTEP dispatch rule. First, the lot with lowest priority is favored. In case of equal priorities, the lot with the lowest lot completion ratio is favored. For each lot, the lot completion ratio (CompRatio) is computed, based on the current step number (Step), and the total number of processing steps in the lot's process flow (NStep), CompRatio = Step / NStep. The lot with the highest CompRatio is favored. Between lots with the same CompRatio, the rule is first-in-first-out. 2. Added ODD dispatch rule. In general, the due date for a lot of a specific product is given in terms of a FLOWFACTOR (FF) that is defined as the target cycle time divided by the raw processing time (RPT). For instance, a FF of 2 says that a lot spends half of its cycle time in processing state and the other half in non-processing states like waiting. Thus, the due date of a lot is the time when it enters the fab plus FF * RPT. For ODD, we also need the raw processing time RPT(i) for a sequence of processing steps or operations from operation 1 to operation i (including operation i). The ODD of operation i is defined as the Release Time + RPT(i) * FF. For the final operation of a lot the ODD is equal to the classical due date as used in EDD or CR. 3. Changed the naming convention for split lots to "name_of_mother_lot_#1", "name_of_mother_lot_#2". This change only affects lots that are split into children with an unsplit step. Lots that are split and do not specify an unsplit step do not identify the children as split lot children and so this change won't work for that type of split. 4. Added detailed operator work schedules, operator skill differences, overtime pay, and the ability to have alternative operator groups at the process step. This allows modeling of operators in a more realistic fashion versus the super operator construct. 5. Added period average number of servers. Earlier versions of FX used the number of servers (tools and operators) available at the beginning of each period regardless of ramp points within the period. FX now calculates the average number of servers during a period based on ramp points and operator schedules for use with the capacity analysis engine.
11.3. Whats new in Version 2.8 6. Added Merge Product Flows to the FactoryX menu. This dialog will merge process flow data from an SQL Server database into the FX process flow worksheets. Factory Explorer will query the SQL Server database for the following flow fields: Flow (The name of the process flow matched against an FX process flow worksheet), Sequence (The sequence number of the process flow step from the SQL Server data), Step (The name of the step within the process flow matched against a step name on a FX process flow worksheet). For the merge process to work correctly the Flow/Step combination on a particular SQL Server database record must match a Process Flow worksheet name and Step name on a FX process flow worksheet. Minor Changes: 1. Bug Fix: correct an array out of bounds error in the ATCS dispatch rule. 2. Added Standby parameter to the FabTime_WriteToolStateRecord.. 3. Bug Fix: correct rounding error on Scheduling Worksheet when events start slightly before midnight but round up to midnight but the date was not incremented to the next day.. 4. When using the FirstStream option without an initial seed value, FX gives a Visual Basic Error 13 Type Mismatch. The default value is now set to 1 when users do not specify any value.

This section describes whats new in Factory Explorer Version 2.8. The changes listed below are relative to Factory Explorer Version 2.7. Major Changes: 1. Added capability to model tool states. This enhancement makes it possible to more accurately model cluster tools. See Section 9.19 for more details. 2. Added capability to split lots during processing (previously, lot splitting only occurred following a process step). This enhancement allows for more flexible and detailed modeling of the process flow. Lots undergoing a mid-process split independently complete unload, delay, and travel of the split step and the remaining process. See Section 9.16.4 for more details. 3. Added capability to model physical input and output inventory buffers at each tool group. This enhancement enables more accurate modeling of WIP storage constraints. In particular, upstream blocking occurs when there is no availability in downstream input buffers. See Section 9.20 for more details. 4. Added capability to designate a specific operator group to perform setup. Separate operator groups may now be specified for setup, processing (load, process, unload), and travel. Minor Changes: 1. The SetupIsLoad option is obsolete. 2. Bug Fix: Delimited text fields with double-quotes in schedule worksheet output so that names containing commas would load correctly into Excel. Copyright WWK 1995-2009 Factory Explorer 265
11. Reference Topics: What's New in this Release 3. Bug Fix: Modified simulation code to not break simulated %Free No Operator out of simulated %Free when a toolgroup specifies any of MinQueue, MaxQueue, MinDelay, or MaxDelay. Code was already not breaking out %Free No Operator when a toolgroup specified MinTools or MaxTools. 4. Changed input model validation for tool groups that specify min tools setup. Now, the code only checks that the sum of min tools within each setup group (rather than across all setup groups) is less than or equal to the current number of tools 5. Added Sim Percent Busy Held output to Tool Group Results Worksheet. This column quantifies, for tool groups listed on hold tool steps, the time that tools are held busy after processing has completed on the hold-step. 6. Bug Fix: If an individual lot specifies a step that is inactive for the individual lot's product, and all remaining steps in the process flow are also inactive for this product, would cause crash in capacity analysis and/or simulation. The new code treats a lot like this as not being released at all. 7. If an individual lot specifies a step that is inactive for the individual lot's product, causes a crash during capacity analysis. The new code treats the lot as being released on the next step that is active for the individual lot's product. 8. If an individual lot specifies a step that is inactive for the individual lot's product, simulation will release the lot onto that step but it will never get processed. The new code treats the lot as being released on the next step that is active for the individual lot's product. 9. Added input check: If product max lot size is greater than the max batch size for a tool group used in the process flow, and this tool group has units-based batch sizes, then the minimum batch must be set to one unit. 10. Included latest version of HASP security key drivers (4.02) earlier version did not work properly with Windows 2000.

This section describes whats new in Factory Explorer Version 2.7. The changes listed below are relative to Factory Explorer Version 2.6. Major Changes: 1. Added capability to model individual expense items, with cost definitions at the factory level, consumption rates at the tool group level, and exceptions at the process step level. 2. Added Expense Item Summary Worksheet showing expense item consumption and cost by period. 3. Added Tool Group Expense Item Worksheet showing expense item consumption and cost by period at the tool group level. 4. Alternative steps may now specify gotos. 5. Added Resource Group Capacity by Product Chart. Similar to the Bottleneck Resource Chart, this chart breaks capacity usage down by product, enabling detailed analysis of product-level usage at the resource group level. 6. Capacity analysis engine is now much faster and requires much less memory for large models with many product-specific process steps.
11.5. Whats new in Version 2.6 Minor Changes: 1. Added freeze panel for all worksheets for charts. 2. Bug Fix: TRANMULT & ASSMREQD have Opt-Int attribute, instead of Opt-Num. 3. Bug Fix: Modified period-level product summary line yield calculation (on Factory Summary Worksheet). Previously it was using a weighted average of the productlevel line yields, which could lead to rounding errors. New code uses a direct calculation (throughput rate divided by input rate). 4. Bug Fix: Simulation was not taking unit throughput rates into account when calculating start rates for replications after the first for models with no ramp data. 5. Bug Fix: Hangover from the implementation of goto's on alternative steps. 6. Conwip was counting identical twin lots created for alternative steps as part of overall WIP. 7. Bug Fix: Capacity analysis was not correctly predicting the split between rework% and non-rework% for tool groups used both inside and outside rework loops, and having per-unit process times. The total work% was correct, but the split was not. 8. Bug Fix: Model validation was not checking to ensure that individual lots initialized to steps within split-lot regions really were split-lots. For a model with this problem, running the simulation could cause Factory Explorer to crash. 9. Added WriteFabTime option to generate a FabTime-compatible movement transaction log during a simulation run. 10. Added DeadlockOK option to specify that it is ok to simulate a model even when Factory Explorer has detected potential deadlock conditions. 11. Added Gamma distribution. 12. Added Weibull distribution 13. Modified simulation code to explicitly prioritize product releases (in product order) when they occur at the same time in the simulation. This change makes it easier to compare simulation runs for models that are the same except for the inclusion of ramping data (in some cases the ramping data caused simultaneous random events to occur in the simulation in a different order, thus giving slightly different output results for the two models). 14. Bug Fix: Changed SchedLot to accept string argument, and compare this argument against the LotID displayed on the Scheduling Worksheet.

This section describes what's new in Factory Explorer Version 2.6. The changes listed below are relative to Factory Explorer Version 2.5. Major Changes:
11. Reference Topics: What's New in this Release 1. Factory Explorer tested with Excel 97 and Excel 2000. 2. Excel 5 and Excel 95 are no longer supported. 3. Modified capacity analysis calculations to automatically detect products with zero volume, and to skip over detailed calculations for these products. This change makes capacity analysis much faster for models that have zero-volume products. 4. Added bar-chart version of Bottleneck Resource Chart, to accompany the existing column-chart version. This bar-chart version displays and prints better when a model contains long tool group names. 5. Added new columns for lot arrivals and average queue length to WIP & Cycle Time by Operation Worksheet. The columns make it easier to compare simulation estimates against shop-floor estimates (which are often aggregated at the operation level). 6. Added ability to modify operation of setup-avoidance algorithm with MINQUEUE / MINDELAY columns (Excel models) and MinQueue / MinDelay statements (ASCII models). These new inputs allow modeling of setup-avoidance logic that forces a minimum queue length or queue delay time before allowing a setup. 7. Added the ability to free a hold tool after a percentage of the process time has passed at the free-after step. This change makes it possible to model operating logic at timeconstrained process steps, e.g. not releasing a lot into an upstream step until processing at a downstream step is partially completed, thus ensuring that the downstream tool will be available by the time the lot finishes the upstream step. 8. Added ability to specify tool lead times (on the Tools worksheet). Added new output rows Lead Time and Suggested Purchase Date to the Resource Planning Worksheet. Also added Current Count, Sugg Exact Count, Sugg Whole Count, and Capacity Loading rows to the Resource Plan Worksheet These change make it easier to see with a single glance at the Resource Planning Worksheet when tools should be ordered during a factory ramp. 9. Added Max Going Rate (e.g. Daily Going Rate, Weekly Going Rate, etc.) performance measures to the Bottleneck Resource Worksheet, Tool Group Results Worksheet, Operator Group Results Worksheet, and Resource Planning Worksheet. If the user requests throughput rates to be shown in units per day, these outputs become the popular DGR (Daily Going Rate) performance measure used in many factories. 10. Added replication-level outputs (simulation outputs only) for Process Step Detail Worksheet (if the number of analysis periods is greater than one). Also added runlevel outputs (simulation outputs only) for Process Step Detail Worksheet (if the number of replications is greater than one). These new outputs eliminate the tedious hand-calculations previously required to generate replication and run-level averages for simulation outputs on this worksheet. 11. Added product type definition at factory level, product type attribute at product level. Product type is now displayed on the Tool Group Capacity by Product Worksheet and the Operator Group Capacity by Product Worksheet. Showing the product type on these output worksheets makes it easier to analyze the relative usage of equipment and staffing by different product families. 12. Added unit type definition at factory level, unit type attribute at product level, unit type attribute at tool group level, and unit type attribute at operator group level. Unit type is used for max going rate (e.g. Daily Going Rate, or DGR) calculations, and is
11.5. Whats new in Version 2.6 especially important for factory models that include multiple unit types (e.g. both wafers and die). Minor Changes: 1. The Tool Group Capacity by Product Worksheet and the Operator Group Capacity by Product Worksheet are now generated whenever capacity analysis is performed WriteDetail is no longer required. As more people use these output worksheets for analysis, it is nice to have them generated all the time, and not require WriteDetail. 2. Added more detailed NetHASP error messages. 3. Added ability to create a worksheet / chart by double-clicking on the worksheet's / chart's name from the list on the Analyze Output Dialog. 4. Added simulation average cycle time statistics to Process Step Detail Worksheet. 5. Column Line Yield on the Analyze Summary Worksheet now includes more decimal digits. 6. Added Pre Average Lot Size column to the Process Step Detail Worksheet.. 7. Modified label for Bottleneck Resource Chart -- shows full resource group name now (used to be truncated at 10 characters). Also eliminated "ToolGroup" and "OpGroup" text -- indication of resource type now comes from resource quantity (e.g. x_Tools or y_Ops). 8. Added option on System Parameters Dialog in Excel user interface to specify the default number of items displayed on Pareto charts (bottleneck resource charts, cycle time contribution by tool group charts). Changed to use 10 as the default value for this setting (previously the default was 5, and it was not user-controllable). 9. Added simulation max queue delay to Tool Group Results Worksheet. Also changed calculation method for average queue delay shown on this worksheet - previously was estimated indirectly using Little's Law. Now it is estimated directly using lot queue delays (since lot queue delays had to be tracked to get the max queue delay). 10. Modified capacity loading calculation for operator groups that perform only repair (no processing). Previously, capacity loading was defined as infinite if the sum of capacity loss factors exceeded 1, zero otherwise. But this was confusing on outputs, so the new formalism is that capacity loading for operator groups that perform only repair is equal to the sum of all capacity loss factors (offline time, non-scheduled time, and repair time). Note that if an operator group does not perform processing, the setup time must by definition be zero, and hence is not included in this definition. 11. Modified actual maximum processing rate calculation slightly, to eliminate several numerical instabilities for certain situations. 12. Bug Fix: Maxtools setup restriction could fail to work properly for tool groups that defined multiple setup groups. 13. Added total non-rework lot arrivals (simulated) and total rework lot arrivals (simulated) to outputs on the Process Step Detail Worksheet. 14. Bug Fix: Modified capacity analysis calculations to eliminate numerical instabilities arising in some models when calculating capacity loading for tools with setupavoidance.
11. Reference Topics: What's New in this Release
11.6 What's New in Version 2.5

This section describes what's new in Factory Explorer Version 2.5. The changes listed below are relative to Factory Explorer Version 2.4. Major Changes: 1. Added DoCost run-time option to control generation of cost analysis results. 2. Added Lots worksheet (Excel models) and Lot statement (ASCII models) integrates functionality of state-space and release-list files. Allows model to included detailed definition of individual lots that are in the system when the analysis run starts (initial WIP), or that are to be released as the analysis proceeds. 3. All individual lots specified on the Lots worksheet (Excel models) or Lot statement (ASCII models) are now taken into account by Factory Explorer's capacity analysis engine. 4. Added WIP Snapshot Worksheet shows detailed list of WIP in the system at the end of each simulated period. 5. Eliminated ReadState option, as that functionality is replaced by new Lots worksheet (Excel models) or Lot statement (ASCII models). 6. Eliminated SaveState and SaveInt options. WIP results data file records now written out at the end of each period whenever simulation is executed, and WriteDetail is enabled. As part of same change, eliminated SAVE event from simulation engine. 7. Eliminated State Space options dialog from Excel interface no longer needed. 8. Added between-time interruptions. Makes it easier to model interruptions that occur on a regularly scheduled basis, e.g. preventive maintenance. 9. Added WIP & Cycle Time by Operation Chart. This chart shows simulation estimates for WIP and cycle time, broken down by operation, allowing quick identification of the areas within process flows that contribute most to WIP and cycle time. 10. Added Tool Group Setups Worksheet showing simulation-based statistics for individual setup I.D.'s. 11. Added ability to modify operation of setup-avoidance algorithm with MINTOOLS / MAXTOOLS columns (Excel models) and MinToolsSetup / MaxToolsSetup statements (ASCII models). These attributes can be used to specify the minimum and maximum number of tools allowed to be setup for each particular setup I.D. 12. Enhanced within-process lot splitting the unsplit step is now optional. Split lot children can now be recombined at a later point in the process flow, or left to flow through the remainder of the process flow. 13. Added scheduling worksheet showing detailed event-by-event listing of simulated factory activities. 14. Added new cost-related input parameters: operator overhead rate, process step overhead cost, and process step direct material cost. 15. Separated operator wage costs into working and non-working components for cost analysis outputs.
11.6. What's New in Version 2.5 Minor Changes: 1. Changed Run Factory Explorer dialog to dynamically display current run-time command. This change makes it easier to see all currently specified options, and also eliminates the need for a run-time command confirmation dialog. 2. Added numbers of tardy, numbers of not tardy, percent tardy, percent not tardy, average tardiness for tardy lots, average CT for tardy lots, average CT for non-tardy lots. All those columns are displayed on Factory Summary Worksheet. 3. Added check for over-capacity before allowing DoCost. 4. Added process step type (defined at factory level, specified at process step level). Process step type is displayed on the Process Step Detail Worksheet for easier grouping and sorting of output records. 5. Added ability to model non-random gotos using NRGOTO column (Excel models) and NonRandomGoto statement (ASCII models). See Section 9.10 for details and a sample model. 6. Added ability to control order in which simultaneous check-request events are executed in the simulation using CHECKPRI column (Excel models) and CheckPriority statement (ASCII models). 7. Added accelerator keys to primary options on Run Factory Explorer dialog. 8. Optimized capacity analysis execution speed for models with very large lot sizes (more then 10,000 units). 9. Changed Cycle Time Contribution by Tool Group Chart to use process time estimates from the simulation run, so that capacity analysis is no longer required for this chart only the simulation must be run. 10. Lots loaded into the system at startup can now be located in the midst of hold regions. 11. Bug Fix: Capacity analysis under-estimated true capacity of batch tools with lotbased minimum/maximum batch sizes that specified per-unit process times inside split-lot regions. 12. Added Input Check: Only products that are demand-driven (have downstream products that specify throughput rates) can specify adjustable transform or assembly percentages. 13. Bug Fix: In models with adjustable transform/assembly percentages, if the original model specified a transform or assembly percentage of zero, the capacity analysis engine would be unable to properly adjust the percentages to meet end-product demand. 14. Bug Fix: In models with adjustable transform/assembly percentages, specifying a zero unit throughput rate for downstream products could cause the capacity analysis calculations to halt with an internal error. 15. Bug Fix: In models with active/inactive steps that specified scrap, the calculation of raw process time was biased. 16. Added Input Check: It is now an error for a product to specify a set of release patterns that result in an overall release rate of zero. 17. Added current input rate, maximum input rate, and capacity loading columns to Tool Group Capacity by Product Worksheet and Operator Group Capacity by Product Worksheet. 18. Added operator group and operation I.D. columns to Alternative Steps Summary Worksheet. Copyright WWK 1995-2009 Factory Explorer 271
11. Reference Topics: What's New in this Release 19. Added operation I.D. column to Process Step Detail Worksheet. 20. Added Input Check: Sum of goto percentages for a step must not exceed 100%. 21. Added Input Check: Percent of lots reworked and percent of units reworked must be strictly less than 100%, if percent of lots tested for rework is 100%. Previously, entering 100% for percent of lots tested and percent of lots or units reworked would cause capacity analysis calculations to halt with an internal error, due to an infinite feedback loop. Note that the percent of lots tested for rework can equal 100%, but in this case the percent of lots and percent of units reworked must both be strictly less than 100%. 22. Added Input Check: A 100% backward goto triggers a validation error, unless the step is the end of a rework loop, or there is a prior step with a goto that points after the 100% backward goto step. This input check catches situations that previously caused capacity analysis calculations to halt with an internal error, due to an infinite feedback loop. 23. Added additional user-customization call-back routines, so that more sophisticated custom dispatch rules can be built. 24. Added Input Check: An unsplit step cannot also be a split step. 25. Renamed Material and consumable cost to Supplies and consumable cost to avoid confusion with new process step column Direct material cost. 26. Added User_CalcOnLotSelection routine to user code, so that custom code can perform actions every time a lot is chosen for processing. 27. Added process step type parameter to allow for categorization of process steps on Process Step Detail output worksheet. 28. Added DelLots option to remove individual lots from the model. 29. Added run-time restriction: ReleasePct and ReleaseRate cannot be enabled for a model with individual lots, unless DelLots is also enabled. 30. Changed Process Step Detail Worksheet to only display active steps within each products process flow.
11.7 Whats New in Version 2.4

This section describes whats new in Factory Explorer Version 2.4. The changes listed below are relative to Factory Explorer Version 2.3a. Major Changes: 1. Process flows can now include product-specific process steps. New ACTIVE and INACTIVE columns (Excel models) and ActiveProduct and InactiveProduct statements (ASCII models) allow users to collapse process flows that are similar except for a few steps into a single process flow that specifies a few product-specific steps. 2. Added ability to calculate suggested tool and operator quantities on the basis of a maximum suggested capacity loading that varies by tool and operator group. New CBUFFER column (Excel models) and CapacityBuffer statement (ASCII models) allow specification of a tool group specific or operator group specific capacity buffer that is subtracted from the overall suggested capacity loading (as specified with SuggLoading) before Factory Explorer calculates suggested quantities.
11.7. Whats New in Version 2.4 3. Added ability to model transform and assembly of products into multiple downstream products, when demand is specified for the downstream products. New ADJPCTS column (Excel models) and AdjustPcts statement (ASCII models) notify Factory Explorer that it should take over the work of calculating appropriate transform and assembly percentages so as to most closely satisfy demand for end-products. 4. Added Tool Quantity Chart. This chart visually represents the points in time when additional tools will be required. For a tool group, it shows (by analysis period) current tool count, suggested exact tool count, suggested whole tool count, current capacity loading, and capacity loading for the suggested whole tool count. The suggested exact tool count is a new output, and it represents the suggested number of tools required if one could purchase fractional tool quantities. 5. Added Operator Quantity Chart. Similar to Tool Quantity Chart, but shows operator quantities. 6. Chart wizard can now create custom charts from tool and operator group data (in addition to product & summary data), and allows up to three left-axis and three rightaxis variables on a single chart. 7. Bottleneck Resource Chart, Bottleneck Resource Worksheet, Tool Group Results Worksheet, and Operator Group Results Worksheet now display of a breakout of predicted work% into rework% and non-rework% (along with a total work%). 8. Bottleneck Resource Chart, Bottleneck Resource Worksheet, Tool Group Results Worksheet, and Operator Group Results Worksheet now display a breakout of predicted and simulated (where appropriate) offline% into offline% by offline type (along with a total offline%). For offline types, Factory Explorer builds a list of unique interruption names as specified in the input model, and then aggregates offline time from interruptions with the same name into one offline type. 9. Added ability to modify operation of setup-avoidance algorithm with MAXQUEUE / MAXDELAY columns (Excel models) and MaxQueue / MaxDelay statements (ASCII models). 10. Alternative steps now may specify the same tool group but different operator groups. This change enhances the ability to model detailed operator cross-training policies. Minor Changes: 1. Added Input Check: It is now a validation error for a process step to specify a batch time but not use a batch tool. Previously, this condition was only flagged as an error if the step also specified a batch I.D. 2. Bug Fix: The validation error message for a negative operator group wage rate did not correctly display the offending operator group's name. 3. Added Input Check: It is now a validation error for a product to be fed by multiple sub-transform products, if a downstream product specifies a unit throughput rate. 4. Added index entries to user manual for all Factory Explorer Excel model columns and all run-time options. 5. Bug Fix: In models with unit throughput rates specified for non release products, use of ReleasePct would not result in the desired capacity loading for the factory, as the throughput rate for non release products would not be adjusted properly.
11. Reference Topics: What's New in this Release 6. Bug Fix: In some cases, analysis engines could crash when converting Excel model to ASCII format if Excel model contained odd dates such as 1-Jun, instead of Excel's days-since-1900 date format. 7. Bug Fix: In some cases, conversion of an Excel model to ASCII format would not work if an active AutoFilter was set in the Excel model. 8. Added ASCII Model Input Check: It is now an input error to define a product after one or more processes have been defined. That is, all products must be defined before the first process is defined. 9. Bug Fix: When simulating models with ramp data and one or more infinite server resource groups, Factory Explorer would ask for much more memory than was really necessary, causing longer simulation run-times, and out-of-memory messages on some Windows 95 systems. 10. Changed Excel to ASCII conversion program so that cells with spaces are now treated as empty cells (previously, they could be treated as cells containing data, causing hard-to-diagnose problems with the ASCII input model). 11. Bug Fix: In models with many ramp points, simulation-based WIP estimates on Tool Group Results Worksheet could be biased low.
11.8 Whats New in Version 2.3a

This section describes whats new in Factory Explorer Version 2.3a. The changes listed below are relative to Factory Explorer Version 2.3. Minor Changes: 1. Added support for network HASP security keys. Now it is possible to run multiple workstations on a network using a single network HASP security key. 2. Bug Fix: For simulation runs with multiple replications, queue delay estimates shown on the Cycle Time Contribution by Tool Group Chart were biased high for replications after the first.

This section describes what's new in Factory Explorer Version 2.3. The changes listed below are relative to Factory Explorer Version 2.2a. Major Changes: 1. All product, tool, operator, and process step attributes may now be ramped within a single model. 2. Added custom chart wizard makes it easy to quickly create a large variety of customized output charts. 3. New %Operation wildcard makes it much easier to model complex batching and setup rules that depend on operation I.D.'s. 4. Replaced limited what's next scheduling interface with much more powerful usersupplied code interface. This new interface allows advanced users to customize Factory Explorer with their own code, including the capability to add custom, userdefined, dispatch rules. 5. Replaced all capacity analysis output reports with output worksheets. 6. Replaced all simulation output reports with output worksheets. 274 Factory Explorer Copyright WWK 1995-2009
11.9. What's New in Version 2.3 7. All output worksheets now display results by analysis period. 8. In Excel user interface, modified Analyze Output dialog so that multiple output charts and worksheets can be created simultaneously. 9. Enhanced modeling of Kanban systems hold tool regions can now include goto's, scrap, and rework. 10. New WriteEstAlt option can be used to quickly substitute simulated alternative step percentages in large models. Minor Changes: 1. Operator Group Capacity Report previously stated that rates listed in terms of hours that was an error. It now correctly states UnitsPerHour. 2. Bug Fix: Capacity analysis calculations were not predicting the correct start rate in models where product lot size was given as a distribution rather than a constant. This error also affected line yield calculations, causing them to exceed 100% in some cases. 3. Added Check: Rework loops must end with 100% goto. Previous code only checked that it was a single goto, and that it pointed backwards at or above the rework step. 4. Eliminated restriction that InputPct and InputRate could not be used when analyzing models with multiple release patterns for a single product. 5. Bug Fix: In models containing within-process lot splitting, could generate a file using SaveState that would not be readable with ReadState due to fractional tool group visits data. 6. Bug Fix: In models containing alternative process steps, SaveState would generate a file containing a record for each identical twin lot waiting for an alternative step. When this state space was read in using ReadState, each identical twin was treated as a real lot, causing too many lots to be created. 7. Bug Fix: Previously, if InputPct or InputRate were used on a model containing UnitStartRate or UnitTputRate, and the model was written out with WriteExcel, the release patterns would be adjusted to correct the new production volume, but the unit start rate and unit throughput rate inputs would not be adjusted. Now these inputs are also adjusted to show the effect of changes in input percentage or input rate. 8. Bug Fix: Using InputPct in models with transform or assembly resulted in incorrect start rates (new start rate was calculated based on total input release for all products, not just release products). 9. Added WIP and Cycle Time by Period Chart. 10. Added Dispatch Rules Information Report. As user-supplied rules may be modified between analysis runs, this report is useful for tracking exactly which rules were in effect (and used in the model) for a particular analysis. 11. Added NoPeriodOutput option to suppress end-of-period outputs. In Excel interface, this option is located on the Output Options dialog. 12. Renamed Tool Group Capacity Analysis Worksheet to Tool Group Results Worksheet. This worksheet now includes results from both capacity analysis and simulation. 13. Eliminated Timing Information Report it duplicated information usually available in console output. 14. Eliminated Recurring Cost Report it was used very infrequently.
11. Reference Topics: What's New in this Release 15. Eliminated Fixed Cost Report it was used very infrequently. 16. Added option RunLen to specify the analysis run-length applies to both capacity analysis and simulation analysis. With ramp analysis, the run-length is now relevant even for capacity analysis. 17. Changed DoSim run-time option to no longer require an argument the simulation run-length is now specified with RunLen. 18. Eliminated DoSimUM and ClearStatsUM run-time options -- RunLenUM now controls the unit of measure for both the analysis run length and the clear-statistics point. 19. Added option StartDate to specifying the starting date for analysis run. 20. Factory Explorer now checks before analyzing an Excel model that the workbook containing the model uses Excel's 1900 date system. As models can now contain ramp date including dates, Factory Explorer requires that all input models use the 1900 date system (as opposed to the 1904 date system) for consistency. 21. Eliminated Assumptions of Capacity Analysis Report. 22. Added Warnings Worksheet containing warnings for situations that could cause confusing or erroneous results. 23. Eliminated Unused Tool and Operator Groups Report, since that information is now contained in Warnings Worksheet. 24. Eliminated Tool Group Capacity Analysis Report, since all the information on that report (and more) is contained in the Tool Group Results Worksheet. Tool Group Results Worksheet also displays results by period for easy ramp analysis. 25. Eliminated Gross Margin Summary Report, since the information on that report is contained in the Gross Margin Worksheet. 26. Eliminated Product Capacity Report, since the information on that report is now contained in the Factory Summary Worksheet. 27. Eliminated Product Cost Per Good Unit Out Report, and replaced it with Product Cost Worksheet. 28. Eliminated Product Raw Unit Cost Report and Raw Unit Cost WIP Valuation Report, since the information on these reports is now contained in the Factory Summary Worksheet. 29. Eliminated Operator Group Capacity Analysis Report, and replaced it with Operator Group Results Worksheet. 30. Eliminated Bottleneck Resource Report, and replaced it with Bottleneck Resource Worksheet. 31. Eliminated Total Required Space by Layout Area Report, and replaced it with Tool Space by Layout Area Worksheet. 32. Eliminated Total Required Space by Type Report, and replaced it with Tool Space by Type Worksheet. 33. Eliminated Travel Matrix by Move Rate Report, and replaced it with Travel Matrix by Move Rate Worksheet. 34. Eliminated Travel Matrix by Distance Rate Report, and replaced it with Travel Matrix by Distance Rate Worksheet. 35. Eliminated Tool Group Capacity by Product Report, and replaced it with Tool Group Capacity by Product Worksheet.
11.9. What's New in Version 2.3 36. Eliminated Operator Group Capacity by Product Report, and replaced it with Operator Group Capacity by Product Worksheet. 37. Bug Fix: If an Excel model contained an inactive product row (no DATA keyword), and the process flow specified on the inactive row was specified again lower in the worksheet for an active product, the process flow was not being written out. 38. Eliminated Throughput Analysis Worksheet this capability was not used very often, and has been approximately replaced by the ability to directly specify throughput rates in the input model. 39. Removed output reports drop-down list from Analyze Output dialog in user interface, since most reports are now just input data feedback. Changed dialog to allow users to open output reports file (basename.run) with ASCII text editor. 40. Eliminated Initialization Bias Test Report, and placed that output on Factory Summary Worksheet. 41. Eliminated Product Cycle Time Report: Parts I and II, and placed that output on Factory Summary Worksheet. 42. Added option Percentile to specify the upper percentile reported for cycle times. Previously, this value was specified with CILevel. Since it is a percentile, not a confidence level, it is better to have a separate option. 43. Modified Cycle Time Histogram to generate data for analysis periods and for the entire replication. 44. Eliminated Product WIP Report, and placed that output on Factory Summary Worksheet. 45. Eliminated Model Run Information Report, and replaced it with Analysis Run Details Worksheet. 46. Eliminated Lot Moves and Starts Report, and placed that output on Factory Summary Worksheet (lot moves and starts) and Analysis Run Details Worksheet (lot moves per wall-clock minute). 47. Eliminated Number in Queue Chart and Queue Delay Chart they were not used very often, and this data can now be found on Tool Group Results Worksheet. 48. Eliminated Cycle Time Contribution Report. 49. Eliminated Tool Group WIP Report, Tool Group Number in Queue Report, and Tool Group Queue Delay Report data from these reports can now be found on Tool Group Results Worksheet. 50. Eliminated Tool Group Utilization Report, Operator Group Utilization Report, Tool Group Operator Delay Report, Arrival Process Report, and Setup Report data from these reports can now be found on Tool Group Results Worksheet and Operator Group Results Worksheet. 51. Eliminated Tool Group Service Time Report data from this report can now be found on Tool Group Results Worksheet. 52. Eliminated Product Cycle Time Report (End of Run) data from this report can now be found on Factory Summary Worksheet. 53. Eliminated Product Lead Time Report data from this report can now be found on Product Lead Time Worksheet. 54. Modified Alternative Steps Summary Worksheet to display data by period. 55. Modified Process Step Detail Worksheet to display data by period. 56. Eliminated YIELD results data file record it was used very infrequently.
11. Reference Topics: What's New in this Release 57. Eliminated BCT results data file record it was used very infrequently. 58. Added Quarters and UnitsPerQuarter time and rates if starting date is specified for analysis, quarter is interpreted as three calendar months. If no starting date is specified, quarter is interpreted as one fourth of a year (8,760 hours per year divided by four quarters per year = 2,190 hours per quarter). 59. On the Analyze Output Dialog, if the currently active workbook is a Factory Explorer Excel model, the output workbook defaults to the last specified output workbook, rather than to (new workbook). Before, it was very easy to create a string of many new output workbooks when doing repeated output analysis. 60. Modified input check: If batch size specified in units for a tool, and maximum batch size is greater than or equal to maximum lot size, and maximum lot size is greater than one, then maximum batch size minus minimum batch size must be greater than or equal to maximum lot size minus one. Before, code was not performing this test if maximum batch size equaled maximum lot size. 61. Modified input check: If sum of alternative step percentages for an alternative step is within a small tolerance (0.1) of 100, a model validation error is not generated. 62. Modified Tool Group Batch Information Report report now displays list of batch I.D.'s before wildcards are expanded. Since expansion can result in a different list after each ramp point, the report would be very large otherwise. Also, removed the mean service time output, as that could also change after every ramp point (not just after ramp points defined for the tool group). 63. Modified Tool Group Setup Information Report report now displays list of setup I.D.'s before wildcards are expanded. Since expansion can result in a different list after each ramp point, the report would be very large otherwise. 64. Added Input Check: Capacity analysis must be enabled to use the SPT (shortest processing time) dispatch rule. Since this dispatch rule requires raw processing times, and these are only calculated if capacity analysis is enabled, the rule does not function properly unless capacity analysis is enabled. 65. Added testbed dataset set1 to distribution, removed set4r (revised version of set4r is now included as Aspen model). 66. Bug Fix: Excel user interface was not saving choice of ASCII text editor (specified on System Parameters dialog). 67. Added PRCRITICAL2 dispatch rule (different version of critical ratio calculation). 68. Renamed options InputPct, InputRate, and InputRateUM to ReleasePct, ReleaseRate, and ReleaseRateUM to lessen confusion between input rate (applies to release products, assembly products, and transform products) and release rate (applies only to release products). 69. Rename Set Input Rate dialog to Lot Release dialog, to better reflect the options found there. 70. Added input check: SPT rule requires capacity analysis (to calculate raw process times). 71. Bug Fix: Raw process times were being overstated in models with HoldTool raw process time for hold tool region was counted both for hold tool, and for tools inside the region. 72. Added process name to WIP state data. Process data is required because now a product's process flow can change within the analysis run. But, lots that are already in
11.9. What's New in Version 2.3 the factory stay on the process flow upon which they were started. So, lots saved during an analysis run with SaveState must record the process they are using, so that they can be restarted on the correct process flow if the WIP state is read in using ReadState. 73. Added total lot arrival and average queue delay outputs to Process Step Detail Worksheet. 74. Bug Fix: In some cases, if a hold tool region contained alternative process steps, or if the free after step was an alternative process step, the hold tool would not be released when a lot exited the hold tool region. 75. Added Input Check: It's now a validation error to specify multiple operation I.D.'s for a process step. 76. Added Input Check: It's now a validation error to specify multiple batch I.D.'s for a process step. 77. Added Input Check: It's now a validation error to specify multiple rework definitions for a process step. 78. Added Input Check: It's now a validation error to specify multiple scrap definitions for a process step. 79. Added Input Check: It's now a validation error to specify multiple split lot definitions for a process step. 80. Changed Input Check: Invalid rework percentages are now treated as validation errors that do not halt model input. 81. Changed Input Check: Invalid scrap percentages are now treated as validation errors that do not halt model input. 82. Changed Input Check: Invalid goto percentages are now treated as validation errors that do not halt model input. 83. Added Input Check: It's now a validation error to specify multiple hold tool definitions for a process step. 84. Changed Input Check: Invalid operator group names on process steps are now treated as validation errors that do not halt model input. 85. Eliminated GOTO, SCRAP, and REWORK results data file output records were rarely used, and could use other means for verification purposes (predicted and simulated lot arrival rates, etc). 86. Changed Input Check: Invalid travel operator groups are now treated as validation errors that do not halt model input. 87. Added Input Check: It's now a validation error to specify batch size in lots flag multiple times for a tool group. 88. Eliminated WNACT results data file record cycle time characteristic curve chart now generated from SUMMARY records. 89. Eliminated FCOSTCT results data file record fixed cost & cycle time chart now generated from SUMMARY records. 90. Changed colors on Bottleneck Resource Chart to be more intuitive. 91. Modified calculation of simulation-based estimate of alternative step percentage shown on Alternative Steps Summary Worksheet. Now, the percentage is estimated by dividing the actual number of lots processed at a single alternative step by the total number of lots processed at all possible alternatives for the step. Before, the calculation was based on the number of lots processed at a single alternative step
11. Reference Topics: What's New in this Release divided by the total number of lot arrivals to all possible alternatives. If there were many lots in queue when the calculation was performed, it could result in a biased estimate. 92. In Excel user interface, date outputs in charts and worksheets can now be formatted to include hours and minutes (hh:mm). This setting is accessed via the System Parameters dialog. 93. Modified input check: If AddStream, FirstStream, or OneStream are enabled but DoSim is not enabled, that is no longer an error that stops the run Factory Explorer simply prints a warning message (that these options have no effect unless DoSim is enabled) and continues. 94. Added option DebugOG generates a detailed event trace for a particular operator group. 95. Modified calculation for mean interarrival time prediction for tools that appear on alternative steps, the calculation accounts for lots that arrive to all alternatives, not just for lots that are processed by tool group. With this change, the predicted value more closely matches the simulation estimate. 96. Bug Fix: A group clock interrupt that occurred in the middle of an nonscheduled period for a resource group with more than one free server could cause Factory Explorer to halt with an internal error. 97. Bug Fix: Outputs on Tool Group Capacity by Product Worksheet calculated incorrectly for hold tools. 98. Modified behavior of DelScrap it can now be used on models with transform and assembly. However, when scrap is deleted, throughput rates are only maintained for release products, not for transformed or assembled products. The throughput rates for transformed and assembled products are determined by the throughput rates of subtransform and sub-assembly products. 99. Bug Fix: A product name containing a comma "," would cause problems with the Cycle Time by Lot Exit Time Chart. 100.Removed testbed dataset set1 from Factory Explorer distribution to save space. To receive this dataset, contact technical support.
11.10 What's New in Version 2.2a

This section describes what's new in Factory Explorer Version 2.2a. The changes listed below are relative to Factory Explorer Version 2.1. Minor Changes: 1. Bug Fix: In models with alternative process steps, cycle time contribution estimates incorrect for all tools in model, not only those listed on alternative process steps. 2. Bug Fix: When using SaveState and ReadState, estimated number of visits would be slightly biased low.

This section describes what's new in Factory Explorer Version 2.2. The changes listed below are relative to Factory Explorer Version 2.1.
11.11. What's New in Version 2.2 Major Changes: 1. Excel 97 is fully supported. 2. Windows 3.1 is no longer supported. 3. Modified output reports, charts, and worksheets to display performance estimates in units of measure as specified by run-time options. 4. On Analyze Output dialog (renamed from Output Menu dialog) in user interface, users can now directly specify the workbook where output results are to be placed. 5. Added ability to model alternative process steps in both capacity analysis and simulation. For capacity analysis, Factory Explorer allocates flow on the basis of the ALTPCT column (Excel models) or the Alt% statement (ASCII models). 6. Added ability to split and recombine lots within a process flow using the SPLITSIZE and UNSPLIT columns (Excel models) or the SplitIntoLotSize statement (ASCII models). 7. Added ability to hold tools across multiple process steps using the FREESTEP column (Excel models) or the HoldTool statement (ASCII models). This capability can also be used to easily model single-card Kanban cells. 8. Added automatic detection of model type based on file name extensions. Specifying a model name with a .fx2 extension indicates an ASCII model (as does specifying a file with no extension); a .xls extension indicates an Excel model; a .vr extension indicates a Testbed model; a .prd extension indicates a ManSim model. Run-time options Excel, Testbed, and ManSim have been eliminated. 9. Added improved handling of units of measure, both for run-time options and for selected model inputs (product start and throughput rates). 10. Added New Excel Model option to FactoryX pull-down menu in Excel user interface. Automates the process of creating a new Excel model. 11. Added ability to directly specify unit start rates for products using the STARTRATE column (Excel models) or the UnitStartRate statement (ASCII models). 12. Added ability to directly specify units of measure for product start and throughput rates using the STARTUM and TPUTUM columns (Excel models) or the UnitStartRateUM and UnitTputRateUM statements (ASCII models). 13. Added ability to label each process step with its operation number or I.D. using the OPERATION column (Excel models) or the Operation statement (ASCII models). 14. Added Process Step Detail Worksheet showing detailed product cost breakdown by process step (generated if WriteDetail is enabled). 15. Added Tool Group Capacity Analysis Worksheet showing contents of Tool Group Capacity Analysis Report, but in Excel format for easier manipulation. Minor Changes: 1. Modified code to not generate a debug file (model.dbg) unless a debugging option is enabled. Additionally, the code deletes any existing debug file if debugging is not enabled, so as to eliminate any possible confusion with a file left over from a previous run. Similarly, the code no longer generates a DOE file (model.doe) unless a DOE option is enabled, and any existing DOE file from a previous run is erased. Finally, the code no longer generates an Oracle data file (model.odf) unless the Oracle data file option is enabled, and any existing Oracle data file from a previous run is erased. Taken together, these changes drastically reduce the number of output files that are Copyright WWK 1995-2009 Factory Explorer 281
11. Reference Topics: What's New in this Release created under normal circumstances, making it easier to manage models and output files. 2. Removed detail data file (model.ddf) and placed all those records in the results data file (model.rdf). Since the user interface no longer needs to load in the entire results data file before creating a chart or worksheet, it is no longer necessary to have two separate files to keep the results data file short. The WriteDetail option must still be enabled, however, for detail data records to be written. 3. Modified user interface code to automatically place the run-command, workbook and worksheet names, run-time, and Factory Explorer version number in the page headers and footers of all output reports, charts, and worksheets. This change helps document the exact model and run conditions that produced a particular result. 4. Modified Testbed import and export code to handle alternative percentage for alternative process steps. 5. Modified Product Cycle Time Report: Part I and Product Cycle Time Report: Part II to display cycle time means, variances, and percentiles as specified by OutCTUM. 6. Modified Bottleneck Resource Report, Tool Group Capacity Analysis Report, and Operator Group Capacity Analysis Report to display input and processing rates in units per hour (previously these figures were displayed in lots per hour). 7. Modified Product Capacity Report to display input and through rates as specified by OutRateUM, and to display raw process times as specified by OutCTUM. 8. Eliminated Welcome dialog in Excel user interface the reset functionality was no longer needed, and overall the dialog was not very useful. 9. Whenever the Run Factory Explorer dialog is displayed, if the active workbook looks like a Factory Explorer model (it contains worksheets titled Products, Tools, and Operators), Factory Explorer automatically adds the workbook name to the top of the model drop-down list. 10. Added Alternative Steps Summary Worksheet shows alternative percentages defined in the model, versus those estimated via simulation. 11. Renamed Summary Worksheet to Factory Summary Worksheet. 12. Added Production Information: Part III report showing unit start and throughput rates (if specified directly in model). Removed unit throughput rate from Product Information: Part I report. 13. Added section to manual and to on-line help documenting new units of measure functionality. 14. Removed shading from cells on Summary Worksheet if this worksheet was transmitted via fax machine, the faxed copy was illegible. 15. Replaced underscores in all results data file and detail data file field names with spaces (e.g. Cost_Per_Good_Unit_Out replaced by Cost Per Good Unit Out). 16. Eliminated Throughput by Lot Size Report, since it was used infrequently. This data is still available, however, via the TPUT detail data file record. 17. Added options OutCTUM and OutRateUM so that performance estimates for cycle times and start/throughput rates can be reported directly in terms of hours, weeks, months, or years. Removed unit of measure preferences from System Parameters dialog, since they are now specified using run-time options. 18. Bug Fix: Using AddRate without capacity analysis would cause a panic, even though it does not require capacity analysis.
11.11. What's New in Version 2.2 19. Moved simulation run length / clear-statistics unit of measure specification from System Parameters dialog to Run Factory Explorer dialog. 20. Added options DoSimUM and ClearStatsUM so that simulation run-length and clear-statistics time can be directly specified in hours, days, weeks, months, or years. 21. Moved input rate unit of measure specification from System Parameters dialog to Set Input Rate dialog. 22. Added options InputRateUM and AddRateUM so that input rate manipulations can be directly specified in units per hour, day, week, month, or year. 23. In user interface, changed run-time option confirmation from a message box to a regular dialog, so that very long run-time option lists are no longer truncated when displayed. 24. Cycle-time contribution by tool group records (CTCONT) now only generated for products with production volume after the clear-statistics point. 25. Maximum length for object names (product names, tool group names, etc.) increased from 30 characters to an unlimited number of characters. All object names are now stored internally in variable-length strings, resulting in decreased memory requirements of up to 10% for large models. 26. Modified ManSim conversion program to translate tools with loadsize_lots = 1 and loadsize_parts = 1 as serial, not batch, tools. 27. Modified ManSim conversion program to apply Load% = 100, Proc% = 0, Unload% = 100 for null_ToolGroup (the ToolGroup that is used for steps in ManSim model that do not specify a workstation). 28. Modified ManSim conversion program to translate operation codes. 29. Eliminated NoRunOutput option, since it was very rarely used. 30. Added FlagNoSetup option to Output Data dialog in Excel user interface. Previously, this run-time option was available only with command-line invocation of Factory Explorer. 31. Modified Excel to ASCII conversion code now it no longer requires column, DIST, or DATA keywords to be specified in upper case. 32. Bug Fix: In Excel user interface, accessing the System Parameters Dialog would always reset the current directory to be the temporary directory. Now the current directory is left unchanged when this dialog is accessed. 33. Added Check: It is now an error for a run-time option to be specified more than once on the command line. 34. Changed behavior of ForceFull for tools with batch sizes specified in units. Before, it would set the minimum batch size equal to the maximum batch size minus the largest nominal lot size processed by the batch I.D. Now it sets the minimum batch size equal to one plus the maximum batch size minus the largest nominal lot size processed by the batch I.D. 35. Bug Fix: In models where product names contained commas ,, certain columns on the Summary Worksheet would be out of line. 36. Added elements of operating expense (raw unit cost, operator wages, etc.) to Summary Worksheet as a set of grouped columns. 37. Bug Fix: In models with unit throughput rates directly specified (as opposed to release patterns) the capacity analysis predictions for interarrival time coefficients of variation as reported on the Arrival Process Report were incorrect.
11. Reference Topics: What's New in this Release 38. Bug Fix: Simulation estimates for interarrival time coefficient of variation as reported on the Arrival Process Report were slightly off for very short simulation runs. 39. Removed Help button from Throughput Analysis Worksheet moved description of capabilities into output worksheet documentation. 40. Added input check: It is now a model validation error for a model to specify a factory schedule that is composed entirely of factory nonscheduled time, i.e. the factory has no operating hours at all. 41. Changed Excel user interface so that it now stores the current drive and directory settings upon exit and automatically restores them upon startup. For first startup, automatically sets drive and directory to point to location where Factory Explorer is installed. 42. Improved capacity analysis predictions for batch tools where the maximum batch size is in units and is less than the product lot size. 43. Modified Excel to ASCII conversion code so that it now flags as an error data cells in columns requiring a distribution if there's no distribution specified in the cell, and there's no distribution template for the column. Previously, the code would go ahead and generate the ASCII file but would leave the distribution blank, resulting in an error that was often difficult to understand and track down. 44. Renamed PRODSTEP results data file record to PROCSTEP. 45. Fixed bug in Testbed import routine if toolset input file contained records of varying lengths, data could be carried forward from one tool group to the next. In particular, if a tool group record defined more downtimes than the subsequent tool group record, the downtimes from the former record could be incorrectly carried forward and defined for the latter record (in the resulting Factory Explorer model). This problem did not occur if all records in the Testbed input file were the same length, i.e. if empty fields were filled in with spaces. 46. Added Free% column to Bottleneck Resource Report, Tool Group Capacity Analysis Report, and Operator Group Capacity Analysis Report. 47. Improved setup rate approximation for batch tools where the maximum batch size is specified in units, and the incoming lot size exceeds the maximum batch size. In this case, the lot is processed as multiple batches, but there is no possibility for setup between batches, and hence the arrival rate of setup opportunities is really just the lot arrival rate, not the batch arrival rate. 48. Modified capacity analysis code in some cases where an unused tool had unitsbased interruptions defined, it would generate a nonsensical prediction for offline%.

This section describes what's new in Factory Explorer Version 2.1. The changes listed below are relative to Factory Explorer Version 2.0a. Major Changes: 1. Added Factory worksheet containing factory-level fixed costs, recurring costs, schedule, space, layout, and travel matrix information. 2. Added ability to directly specify unit throughput rates for products using the TPUTRATE column (Excel models) or the UnitTputRate statement (ASCII models).
11.12. What's New in Version 2.1 3. Added ability to specify batch sizes in terms of lots (default is in terms of units) using the BSLOTS column (Excel models) or the BatchSizeLots statement (ASCII models). 4. Added ability to specify dispatch rules for operator groups using the DISPATCHRULE column (Excel models) or the DispatchRule statement (ASCII models). 5. Added ability to specify the percent of offline time a repair operator is required using the REPAIRPCT column (Excel models) or the Repair% statement (ASCII models). 6. Replaced fixed cost per unit output on Fixed Cost vs. Start Rate chart with average product cost. Renamed chart to Product Cost & Total Fixed Cost vs. Start Rate. 7. Added cross-replication summary output (average across all replications) to Cycle Time by Lot Exit Time Chart. To display it, use the AutoFilter to set replication column to Summary. 8. Changed Product Capacity Report to be generated at the completion of capacity analysis. Removed estimated cycle time over RPT output from this report, and placed it on Product Cycle Time Report. 9. Added Factory Information Report showing factory-level details. 10. Added factory-level fixed costs to Fixed Cost Report. 11. Added breakout of tool group fixed costs by tool type to Fixed Cost Report. 12. Added Recurring Cost Report showing factory and tool-level recurring costs. 13. Added total factory depreciation cost and total factory recurring cost to Gross Margin Summary Report. 14. Added Product Lead Time Report showing product lead time estimates for endproducts. 15. Added Tool Group WIP Report showing average and maximum WIP levels (units and lots) for each tool group. 16. Added factory fixed and recurring costs to Product Cost Per Good Unit out Report. 17. Added breakout of tool group fixed and recurring costs by tool type to Product Cost Per Good Unit out Report. 18. Added Travel Matrix by Move Rate Report and Travel Matrix by Distance Rate Report showing sorted travel matrix results for models with layout area / distance information. 19. Eliminated Average Cycle Time by Lot Number Chart, since its cross-replication summary functionality is now present in Cycle Time by Lot Exit Time Chart. Eliminated CTBYLOT record from results data file, since it was no longer used to generate Average Cycle Time by Lot Number Chart. 20. Eliminated Number in System Profile Chart, since it is seldom used and its output data can be very large. Also eliminated ProductNIS option, and NS results data file record. 21. For operators, non-load requests now have first priority, and are treated in a FIFO fashion before any load requests. Non-load requests used to be interspersed with load requests in a FIFO fashion. 22. Bug Fix: In models with rework, rework parents' due dates were not being passed down to rework children, leading to incorrect results in models with due-date-based dispatch rules.
11. Reference Topics: What's New in this Release 23. Added Total Required Space by Layout Area Report and Total Required Space by Type Report showing aggregate floor space requirements by layout area and by space type. 24. Added Tool Group Capacity by Product and Operator Group Capacity by Product reports showing breakouts of tool and operator group capacity usage and cost allocation by product. 25. Added ability to write models into Sematech Testbed format using WriteTestbed. 26. Modified user interface so that output charts and worksheets can be generated even if the results data file exceeds 16,384 rows. Now, output charts and worksheets can be generated as long as the number of records in a particular chart or worksheet (rather than the entire file) does not exceed Excel's row limit (16,384 rows for Excel 5 and Excel 7, 65,536 rows for Excel 8). 27. Added Summary Worksheet showing summary results at the factory level with details for each product. 28. Added two new sections to introductory chapter of manual a section presenting a quick tour of Factory Explorer's Excel interface, and one section on getting answers with Factory Explorer. 29. Added a chapter to the user's guide on managing analysis projects. Minor Changes: 1. Bug Fix: In user interface, when Replication field on Run Factory Explorer dialog completely blanked out, would generate a Type Mismatch error when trying to make a run. 2. Eliminated NoSimOutput option, and replaced it with WriteDetail option. Since the only within-simulation output is cycle time, and that is written to the detail data file, it does not normally need to be enabled. Also, WriteDetail allows control over generation of all detail data file output. Detail data file output is only required for thirty-party analysis packages, so it is reasonable to generate it only if requested by the user. 3. Renamed Approximations of Capacity Analysis Report to Assumptions of Capacity Analysis Report. Removed assumption that repair load on operators is negligible, since the capacity engine does take operator repair into account when calculating load on operator groups. 4. Added single-line run-time options list to console output and Model Run Information Report. This change makes it easier to tell, either from the console or the output report, exactly what run-time options were enabled for a run. 5. Changed Batch ToolGroup Report to only print headings if the model contains at least one batch tool group. 6. Added factory name to Model Run Information Report. 7. Bug Fix: In user interface, build Excel model function would not work properly if the Treat consecutive delimiters as one setting was enabled on Excel's Text Import Wizard. Changed user interface code to explicitly specify this setting when reading in all text data files. This bug could also cause problems when reading in data for the Throughput Analysis Worksheet, or possibly other data files. 8. Added Nonscheduled% to Bottleneck Resource Report, ToolGroup Capacity Analysis Report, and Operator Group Capacity Analysis Report.
11.12. What's New in Version 2.1 9. Bug Fix: Could not previously use DebugEv option to trace ENDTIME and ASSEMBLE simulation events. 10. Added estimated and predicted Nonscheduled% to ToolGroup Utilization Report and Operator Group Utilization Report. 11. Replaced estimated and predicted Capacity Load% on ToolGroup Utilization Report and Operator Group Utilization Report with estimated and predicted Occupied%. This change was made because Setup%, Repair%, and even Offline% can depend in a non-linear fashion upon arrival rates, and since the simulation only runs at one arrival rate it cannot estimate these percentages for all arrival rates. Without these percentages, no simulation-based estimate of Capacity Load% that is accurate for all types of resources can be provided. Occupied%, however, can be accurately estimated using simulation results. 12. Added maximum WIP values to Product WIP Report. 13. Added definitions for Sub-Assembly Product, Sub-Transform Product, End-Product Throughput Rate, Exit Rate, Product Lead Time, and Critical Path in terminology section of manual. 14. Reformatted Product Cost Per Good Unit Out Report to make it more readable. 15. Added unit throughput rate to Product Information Report. 16. Bug Fix: Use of ForceFull in multi-product models would cause an application error in capacity analysis and simulation engine. 17. Bug Fix: In certain circumstances, time of last batch-statistics update would be calculated as falling just beyond the end of simulation, due to rounding errors. In very short runs, this could cause some statistics such as average batch size to be slightly wrong (usually on the high side). 18. Added predicted Work% field to Bottleneck Resource Report, Tool Group Capacity Analysis Report, and Operator Group Capacity Analysis Report. 19. Modified Tool Group Utilization Report and Operator Group Utilization Report removed average batch size and maximum batch size fields, and replaced them with average batch utilization%. This new field is average batch size divided by maximum batch size. Needed to do this because operators could serve both tools with unit batch sizes and lot batch sizes, and averages across these would not make sense. But an average batch utilization% does make sense. 20. Removed average lot size and lot service rate fields from Batch Tool Group Report. This report now no longer requires capacity analysis to be performed. 21. Renamed Batch Tool Group Report to Tool Group Batch Information Report. 22. Added Tool Group Setup Information Report, showing setup group and I.D. information. This report is useful when tracking down problems in models having setup I.D. wildcards. 23. Bug Fix: Comparison between batch I.D.'s specified at the tool group level and at the process step level was case-sensitive, when it should have been case-insensitive. 24. Removed estimated and predicted arrival rates from Cycle Time Contribution by Tool Group Report, and replaced with predicted process time per visit, estimated total process time seemed like more useful information. 25. Bug Fix: Changed code so that predicted process time per visit is calculated by product, and process time for batch tools is calculated based on average lot size, rather than maximum batch size.
11. Reference Topics: What's New in this Release 26. Added NoWait option to suppress normal wait prior to close of output console. This option is normally used only in command line environments, so it is not available within the Excel user interface. 27. Bug Fix: Corrected REVENUE column heading on Products worksheet (Excel models). 28. Changed user interface so that the current drive and directory are not affected by a model run. Previous behavior always left current drive and directory pointing to Factory Explorer temporary directory as specified on the System Parameters dialog. 29. Bug Fix: Changed code so that operator groups used solely for repair no longer show up on the Unused Tool Groups and Operator Groups Report. 30. Changed simulation engine so that when a tool and operator are freed at the same time, both resources are marked as free before either resource's request list is checked. Before, could get non-intuitive results because an operator would become free but before the tool could be freed the operator would check the request list and go to work at another tool, even if the oldest request was located at the tool that was just about to be freed. 31. Changed model validation to allow resource groups (tool groups and operator groups) with zero resources. This change is useful because it allows you to retain unused tool group and operator group definitions in a model but exclude their cost and space from all calculations. 32. Changed model validation to allow unused tool groups with batch I.D.'s. 33. Improved speed of simulation engine for batch tools with minimum batch sizes. This change, however, causes a smaller number of random numbers to be used during the simulation, which could cause slight changes in results for the same model when compared with prior releases of Factory Explorer. 34. Added input check: Process steps using the same tool group and batch I.D. must either all specify the same operator group for processing or all specify no operator group for processing. 35. Bug Fix: In models where the bottleneck tool had setups, and avoid-setups was enabled, was not correctly calculating new input rates when InputPct enabled. 36. Improved speed of capacity analysis setup-rate approximation. 37. Updated manual annual tool recurring cost not included in description of gross margin calculations. Also, corrected description of cost per good unit out line calculation for total supplies and consumable cost. These were changes to the manual only the code was not changed. 38. Added warning to Product Cost Per Good Unit Out Report if model includes factory fixed or recurring cost, and one or more tool groups that do not specify space requirements, these tool groups will not be allocated any of the factory-level costs. 39. Added warning to Product Cost Per Good Unit Out Report if model includes factory fixed or recurring cost, and no tool groups specify space requirements, these costs will not be allocated to any product. 40. Changed allocation of tool recurring cost in product cost per good unit out calculation allocation occurs even if useful life for tool group is zero or is not specified. 41. Added input check it's now an error for a tool group to specify multiple dispatch rules.
11.12. What's New in Version 2.1 42. Since operator groups can now have dispatch rules, changed operation of DispatchRule option to override dispatch rules for all tool groups and all operator groups. 43. Added dispatch rule column to Operator Group Information Report. 44. Added warning to Product Cost Per Good Unit Out Report if model includes tool or operator groups that are not used in any process step, costs from these resources will not be allocated to any product. 45. Added input check it's now an error to specify a dispatch rule with DispatchRule that requires due dates if due dates are not specified at product level. 46. Changed behavior of DelOpGroups now it eliminates all uses of operators in the model and sets the number of operators in each operator group to zero. Before, it only eliminated operator uses, but that meant that operator wages were still calculated as part of gross margin. Now, since the number of operators is also zeroed out, operator costs also are deleted. 47. Changed run behavior for unstable models. If Factory Explorer detects that a model is unstable, and Unstable is not specified, the simulation will simply be skipped. The previous behavior was to immediately exit after capacity analysis was completed. An error message will still be generated, but it will be after all end-of-run reports have been generated. 48. Added option DelSetups to remove setups from input model. 49. Added PRWORKAPD dispatch rule simulates WorkStream Activity Planner / Dispatch rule. 50. Added lead time factor to critical ratio and WorkStream AP/D dispatch rule calculations. Lead time factors are specified at the product level using the LTF column (Excel models) or the LeadTimeFactor statement (ASCII models). 51. Infinite server tool groups can now specify fixed and recurring costs they are treated as if the tool group had a single tool. 52. Infinite server operator groups can now specify wage rates they are treated as if the operator group had a single operator. 53. Changed behavior of UseSugg in models with unused infinite server resource groups. Previously, the capacity analysis engine did not calculate a suggested number of resources for infinite server resource groups, so UseSugg had no effect, even if an infinite server resource group was unused. Now, the capacity analysis engine will calculate that the number of suggested resources is zero, and if UseSugg is enabled, will change the number of resources to zero. Note that the behavior is unchanged for infinite server resource groups that are used in the model the code will always show no suggested change from the current number of resources (infinite). 54. Added product cost output to Cycle Time Characteristic Curve Chart. 55. Renamed DelDown option to DelInt (delete interruptions). 56. Added SetLTF option to override lead-time factors for all products. 57. Modified scale on right-hand y-axis of Cycle Time Contribution by Tool Group Chart to always start at zero. 58. Bug Fix: Previously, could not generate Cycle Time by Lot Exit Time Chart (even the cross-replication summary) if multiple replications performed and NoRepOutput enabled.
11. Reference Topics: What's New in this Release 59. Bug Fix: Previously, could not generate Summary Worksheet if multiple replications performed and NoRepOutput enabled. 60. Bug Fix: Model valuation code was not catching situations where maximum batch size exceeded minimum by less than lot size, leading to probable panic during simulation. 61. Added setups as a DOE factor. 62. Bug Fix: Files generated with SaveState could contain information for lots with zero units (rework children that were also rework parents, and thus contained no units), but ReadState could not be used to start a new simulation from this file. 63. Changed WIP state file to include more details, and to store in CSV format. Documented format of WIP state file in manual. 64. Enhanced suggested number of servers calculation in cases where sum of capacity loss factors (nonscheduled% + offline% + repair% + setup%) exceeds 100%. If increasing the number of servers by one does not significantly decrease the sum, the algorithm now immediately gives up and suggests an infinite increase in servers. If, however, increasing the number of servers by one does significantly decrease the sum, the algorithm continues until it finds the correct number of suggested servers. Previously, the algorithm would continue no matter what, sometimes causing long delays while it searched a very large number of servers. 65. Replaced fixed cost per unit axis on Fixed Cost & Cycle Time Chart by total fixed cost (factory fixed costs plus tool fixed costs). 66. Modified Testbed import code to not duplicate process flows when multiple products use the same process flow. 67. Modified Testbed import code to work properly for products with zero start rates. 68. Modified Excel to ASCII translator to unhide all hidden rows and columns, and remove any AutoFilters before writing out worksheets. 69. Added input check: The mean time or units to any interruption must be strictly positive. 70. Added more explicit error message pointing to a particular random variable when a run-time option requires manipulation of a random variable that does not have its mean as a parameter. 71. Added warning to Product Cost Per Good Unit Out Report if model includes tool groups with space requirements that do not perform any processing, factory-level costs will be allocated to these tool groups, but not re-allocated to any product. 72. Changed capacity loading% calculation for operator groups that only do repairs if sum of capacity loss factors (nonscheduled time, offline time, setup time) exceeds 100%, capacity loading% is infinite, otherwise it is zero. 73. Renamed run-time option to scale all tool group interruptions from DownMultSt to DownMultTG. 74. Made ManSim to Factory Explorer conversion routine much more robust (it could crash for some ManSim models). Conversion now handles multiple rework steps (conversion moves these steps into Factory Explorer rework loop). Conversion now also concatenates the ManSim step number with the ManSim step description to create the Factory Explorer process step name. 75. Added Testbed dataset set4r to distribution, removed set1 from distribution.
11.13. What's New in Version 2.0a 76. Bottleneck Resource Chart was displaying 32,000 for number of servers for infinite server resource groups. Changed it to display Inf for number of servers. 77. Changed definition of return codes written to exit code file fx.xcd. 78. Changed number of characters printed for batch I.D. names in Tool Group Batch Information Report to 20. 79. Changed number of characters printed for setup I.D. names in Tool Group Setup Information Report to 20. 80. Bug Fix: Capacity analysis not calculating throughput, line yield correctly if model contains process steps with scrap and a goto to immediate next process step. 81. Bug Fix: Capacity analysis would panic if model contained batch tool in an unused process flow. 82. Bug Fix: Capacity analysis would panic if -InputPct enabled for a model with infinite factory capacity loading. 83. Bug Fix: Could not read in models containing rework skip-to steps with names exceeding 30 characters. 84. Bug Fix: In user interface, batch execution performed for a selection composed entirely of blank cells would cause an error. 85. In user interface, if batch execution performed for a selection containing one or more cells with invalid commands, would give cryptic error message improved the error message, and made it only occur once for the entire selection. 86. Bug Fix: In Excel user interface, if last workbook opened before a model run was stored on a drive other than the drive where Factory explorer was installed, temporary files would get written to the current directory on this drive rather than to the temporary directory. This was only a serious problem under Windows 3.1, where these temporary files included the batch file fx.bat, which was required for model runs.
11.13 What's New in Version 2.0a

This section describes what's new in Factory Explorer Version 2.0a. The changes listed below are relative to Factory Explorer Version 2.0. Major Changes: 1. Bug Fix: If multiple replications performed with -AddPct, -AddRate, or AddSuggPct enabled, product cost analysis would not zero out total tool recurring cost and operator wages between replications, thus causing these figures to be overstated in replications other than the first. 2. Bug Fix: Operator wages in product cost and gross margin calculations overstated by a factor of 4.2 caused by unnecessary multiplication by number of operator shifts per week.

This section describes what's new in Factory Explorer Version 2.0. The changes listed below are relative to Factory Explorer Version 1.0.
11. Reference Topics: What's New in this Release Major Changes: 1. Added cost analysis capabilities, including gross margin prediction (from capacity analysis), product cost per good unit out (from capacity analysis), and WIP valuation (from simulation). 2. Eliminated separate model conversion dialogs from user interface. 3. Added ability to directly run/convert ManSim & Testbed models. 4. Separated user manual into 2 sections: user's guide and reference. 5. Modified capacity analysis to handle large lot size (> 1000 units). 6. Developed complete Macintosh port. 7. Changed default behavior to only perform model translation and load. 8. Can now run capacity analysis and/or simulation separately. 9. Eliminated -EndJob and -EndJobType options. 10. Added option -DoCap to indicate capacity analysis should be performed. 11. Renamed option -EndTime to -DoSim: indicates simulation should be performed. 12. New interrupt syntax -- allows unlimited interrupts, named interrupts. 13. Added ASCII->Excel model translation. 14. Renamed JobType statement to Product in ASCII models, all documentation. 15. Renamed Discipline to DispatchRule in ASCII models, all documentation. 16. Deleted NoRelease statement (products without releases are OK). 17. Eliminated Model worksheet in Excel models can store info elsewhere in Excel model. 18. Renamed charts output file (.ch) to results data file (.rdf), documented file format. 19. Added detail data file (.ddf) output for backup data not needed for charts or worksheets. 20. Added option -ReadRList: can now specify exact simulation release list at run-time. 21. Eliminated estimated completion times -- reading, estimating, and writing. 22. Unit multiplier parameter for transform is now a constant, not a random variable. 23. Units required parameter for assembly is now a constant, not a random variable. 24. Added histogram and percentile estimation for product cycle-times. 25. Batch I.D. wildcards sharply reduce the work required to model complex batch formation rules. 26. Added GroupClock interrupt type eases modeling of engineering time. 27. New terminology: Switched from Station to ToolGroup. 28. New terminology: Switched from Opset / Operator Set to OpGroup / Operator Group. 29. New terminology: Switched from Job to Lot. 30. New terminology: Switched from Component to Unit. 31. Eliminated FixedCost attribute for operators fixed cost not usually modeled for operators. 32. Renamed Stations worksheet in Excel models to Tools. 33. Added time unit-of-measure and rate unit-of-measure choices to system parameters dialog. These choices are used when specifying simulation run length, start rates, and when creating output charts / worksheets. 34. Enhanced flexibility when modeling batch tools batch processing steps now can have any combination of load, unload, per-unit, and per-batch processing times.
11.14. What's New in Version 2.0 35. Replaced Actual Cycle Time Chart with Cycle Time by Lot Exit Time Chart it summarizes minimum, maximum, and average cycle time for the entire simulation run, and greatly shortens the amount of data written to the results data file. 36. Added Product WIP Report. Minor Changes: 1. Beefed up manual index. 2. Modified hot lot modeling section of manual. 3. After reports loaded, formatted report titles for better visibility. 4. Removed button bitmaps from online help for Mac compatibility. 5. Added file name quoting in options list for Mac/Excel 95 compatibility. 6. Changed code to echo all console output to fx.con. 7. Added ability in user interface to view console output file fx.con. 8. When running DOE, FX now displays current DOE I.D. on console. 9. Added system parameters dialog to user interface. 10. Eliminated option -silent (specified at model level but used at run level). 11. Added beta numbering to reduce confusion between beta releases. 12. Added option -mansim to indicate input model is in ManSim format. 13. Added option -testbed to indicate input model is in Testbed format. 14. Created Execution Options dialog in user interface. 15. Eliminated Getting Started section from on-line help. 16. Charts are now full-screen: axis labeling works much better that way. 17. Added check for R1C1-style references at load time -- must use A1-style. 18. Directories now no longer need trailing separator in user interface. 19. Added Notes on Directory and Folder Names to on-line help. 20. Changed Edit ASCII Model option to View ASCII Models / Files. 21. Can access FactoryX menu from worksheets, charts, and with no open files. 22. Bug Fix: TimeToFirst entry in Excel models now converted as random variable. 23. Bug Fix: State-space-save file names now use base specified by -OutBase. 24. Bug Fix: Batch execution skips cells in range having error entries. 25. Reworded message that appears when run is unstable. 26. Factory Explorer exit message now includes instructions for Mac. 27. Bug Fix: Operator group utilization calculation now accounting for repair. 28. Bug Fix: Units-of-work completed rate prediction corrected. 29. Added legend to cycle time characteristic curve chart. 30. Excel->ASCII conversion now automatically de-spaces all product names, tool group names, etc, by converting spaces to underscores "_". 31. Bug Fix: Operator group repair prediction corrected. 32. Bug Fix: Operator group utilization now correct for repair-only operator groups. 33. Added notes on Mac installation to manual. 34. Bug Fix: Assembled/transformed products can now precede products they are assembled/transformed from. 35. Changed clear-stats event to execute after the last event occurring at the clear-stats time. 36. Eliminated Memory cleanup successful message -- only reports problem if it occurs. 37. Eliminated option -convertonly -- just don't specify -DoCap and -DoSim. 38. Renamed Miscellaneous Information Report to Model Run Information. Copyright WWK 1995-2009 Factory Explorer 293
11. Reference Topics: What's New in this Release 39. Eliminated relunif ASCII model statement. 40. Bug Fix: Simulation could crash when travel time random. 41. Renamed Lottype Statistics Report to Product Cycle Time Report. 42. Renamed Lot Type Information reports to Product Information. 43. Renamed Time in Queue Plus Service by Lot Report to Cycle Time Contribution by Tool Group report, and changed report to sort tool groups in order of highest to lowest contribution. 44. Bug Fix: Models with operator group repair and -debug caused memory bug. 45. Renamed Excel->ASCII intermediate file extensions to start with .y. 46. Changed Excel->ASCII intermediate file type to be CSV, not DIF. 47. Added new chart Cycle Time Contribution by Tool Group. 48. Renamed Lottype Capacity Report to Product Capacity Report. 49. Renamed option -Discipline to -DispatchRule. 50. Renamed option -JTNIS to -ProductNIS. 51. Renamed option -ShowDisc to -ShowDisp: Show dispatch rules. 52. Added What's New reference chapter to manual. 53. Added Translating from Prior Releases reference chapter to manual. 54. Added -WriteExcel option: generates files user interface reads to build Excel model. 55. Expanded manual's description of interruption modeling. 56. Eliminated options -ShowCfg and -ShowRt: ASCII models stored in a single file now. 57. Added option -ShowSyn to show ASCII model file syntax. 58. Renamed RTSHEET keyword in Excel model products sheets to PROCESS. 59. Renamed STATION keyword in Excel model routing sheets to TOOLGROUP. 60. Renamed OPSET keyword in Excel model routing sheets to OPGROUP. 61. Renamed BATCHID keyword in Excel model routing sheets to USEBATCHID. 62. Renamed SETUP keyword in Excel model routing sheets to USESETUP. 63. Eliminated Random Routing Report, put data in GOTO record in results data file instead. 64. Eliminated Scrap Report, put data in SCRAP record in results data file instead. 65. Eliminated Rework Report, put data in REWORK record in results data file instead. 66. Added worksheets to view data in SCRAP and REWORK results data file records. 67. Replaced # of steps in Product Information Report with process name used by product. 68. Added Process Information Report: shows # of steps and products that use process. 69. Added diagram of object model to introduction in manual. 70. Eliminated Input statement in routing files. 71. Changed LSLACK rule to be based on remaining raw process time, not completion time. 72. Renamed CCOMPTIME rule to CCOMRPT. 73. CCOMPRPT rule now based on remaining raw process time, not completion time. 74. Eliminated EstComp statement in ASCII models. 75. Eliminated ESTCOMP keyword in Excel models. 76. Eliminated options -ReadComp, -WriteComp, and -EstComp.
11.14. What's New in Version 2.0 77. Eliminated UseLast statement in ASCII models -- can use release list to provide transient portion of release schedule, then insert final release as a pattern in the model. 78. Eliminated USELAST keyword in Excel models. 79. Bug Fix: Model run from user interface when workbook is open but not active now works. 80. Added input check: Products cannot be the result of both transform and assembly. 81. Added Gross Margin Summary Report. 82. Added Raw Unit Cost WIP Valuation Report. 83. Added input check: Products that are the results of transform or assembly cannot have release patterns or release list entries. 84. Deleted cost columns from Throughput Analysis Worksheet they did not contain actual data, and a realistic treatment of throughput/cost relationship requires more complicated analysis. 85. Changed cost data on Fixed Cost & Cycle Time vs. Utilization chart from line format to column format. 86. Switched terminology from Utilization to Capacity Loading%. 87. Renamed Fixed Cost & Cycle Time vs. Utilization chart to Fixed Cost & Cycle Time vs. Capacity Loading%. 88. Renamed -SuggUtilPct option to -SuggLoading. 89. Switched terminology from %Down to %Offline. 90. Switched queue length and queue delay predictions to be based on Occupied% rather than Capacity Loading%, where Occupied% is calculated as Working% + Setup% + Offline% + Repair%. For tools with significant setup or interruptions, this improves the accuracy of the prediction. 91. Bug Fix: Fixed error in capacity analysis for models with process steps containing goto's to the immediate next process step. The input rate for the next process step would be calculated as twice its correct value. 92. Added input check: Process steps with rework cannot specify a goto. 93. Added Product Cycle Time Report: Part II showing percentile estimates. 94. Added Cycle Time Histogram chart showing histograms. 95. Changed user interface so that model name and directory on View ASCII dialog would be reset to match that entered on the Run Factory Explorer dialog each time the Run Factory Explorer dialog is accessed. 96. Changed batch execution dialog in user interface to check for multiple runs of the same model that do not specify -OutBase -- generates a warning if this occurs. 97. Eliminated -IgnoreErr option -- code now shows all errors automatically, then exits if any validation errors found. 98. Bug Fix: Working% calculation for bottleneck resource chart was using total process rate truncated to one decimal digit of precision. When both arrival rate and service rate were small, caused error in working% calculation. 99. Added warning dialog to user interface: if Excel 5.0 or 5.0a is run on a Windows platform, user interface generates a warning dialog at load time. Known bugs in these releases of Excel cause problems with some output charts. Excel 5.0c, which fixes these bugs, is available from Microsoft.
11. Reference Topics: What's New in this Release 100.Bug Fix: Added double-quotes around all object names used in results data file. Otherwise, if an object name (product name, tool group name, etc.) included a comma, Excel would read in the name as two fields, shifting all remaining fields one column to the right. This shifting caused errors in output charts and worksheets. 101.Bug Fix: Added double-quotes around all object names used in ASCII to Excel translator. If these names included a comma, Excel would read in the name as two fields. 102.Bug fix: In a model run with -ClearStats specified, and some tool groups with no visits by a particular product after clear statistics point, but same product still has lots in the system that exit after clear statistics, caused cycle time contribution by tool group calculations to generate a divide-by-zero. 103.Enhanced error messages displayed when there is a problem reading in a distribution added object name to make it easier to find the problem. 104.Changed Cycle Time Contribution by Tool Group chart to only print 1 decimal digit for tool costs. 105.Bug Fix: ASCII to Excel translation program now converts all odd characters in object names (forward slash "/", backslash "\", colon ":") to underscores "_". Otherwise, there is risk that Excel will not recognize the name properly and may try to treat it as a time, etc. Also changed Testbed to ASCII translator to use underscore instead of colon as a separator. 106.Modified output menu dialog in user interface. When executed, dialog initially disables Jump To / Report selection options unless active workbook name matches current reports output file. Options remain disabled until a reports output file is opened. 107.Added input check: Only clock-time failures can specify StaggerFirst. 108.Renamed -DelOpsets to -DelOpGroups. 109.Renamed -ZeroCompOk to -ZeroUnitOk. 110.Renamed -OneCompRPT to -OneUnitRPT. 111.Renamed -DebugLot to -DebugLot. 112.Renamed -DebugSt to -DebugTG. 113.Bug Fix: Fixed bug in user interface -- model run with blank clear stats value would cause an error. 114.Added current total fixed cost (fixed cost per tool times the current number of tools) and suggested total fixed cost (fixed cost per tool times the suggested number of tools) to ToolGroup Capacity Analysis Report. 115.Bug Fix: Throughput Analysis Worksheet data was being generated even when capacity analysis was not performed should only be generated if capacity analysis is performed. 116.Bug Fix: Cell names on Throughput Analysis Worksheet require that all bad characters (commas, colons, etc.) be removed from product names added code to perform this manipulation. 117.Bug Fix: Changed Throughput Rate by Lotsize Chart to only require capacity analysis it uses no data from simulation. 118.Eliminated time conversion dialog made obsolete by new time and rate choices on the system parameters dialog.
11.15. What's New in Version 1.0 119.Reduced simulation memory requirements by replacing arbitrary-length stack that recorded all process step visits by a lot with a fixed length array that records visits by tool group. 120.Added Product Cost Per Good Unit Out Report. 121.Bug Fix: Fixed bug in capacity analysis suggested number of operators not being calculated correctly for operator groups with Offline% + Setup% + Repair% exceeding 100%. 122.Deleted Cumulative Line Yield Chart was not very useful. 123.Moved Batch I.D. column next to Batch processing time in Excel models makes more sense to have these two columns together. 124.Modified user interface to work on Windows 3.1 systems with Win32S installed creates a special batch file in temporary, then calls that batch file instead of directly executing fx.exe. 125.Added input check: Rework skip-to step cannot point to a step before rework step in process flow. 126.Added input check: Rework skip-to step cannot point to immediate next step in process flow (that step is part of the rework loop). 127.Bug Fix: Operator groups used only for travel were being marked as Unused on output reports. 128.Bug Fix: Capacity analysis was not accounting for capacity load imposed on operator groups used for travel. 129.Added run-time option check: Cannot create cycle time characteristic curve if UseSugg enabled.

This section describes what's new in Factory Explorer Version 1.0. Changes listed below are relative to the final release of Delphi Version 10. Major Changes: 1. Fully-operational user interface functions as Excel add-in. 2. Output from Excel conversion program now formatted to be human-readable. 3. Online help available for Excel models. 4. Excel conversion program now written in C (much faster). 5. Eliminated -InputJT option. 6. Changed -InputRate to specify total unit release rate. 7. Added -AddRate so that -InputRate / -AddRate work together. 8. Added -AddSuggPct so that -SuggUtilPct / -AddSuggPct work together. 9. Eliminated individual -chartxxx entries. 10. DOE output now goes to a single file. 11. Eliminated model.p* output files. 12. Changed command line format -- first stream no longer a required option. 13. Added option -firststream to specify first random number stream. 14. Added option -excel to indicate model should be read from Excel DIF files. 15. Added option -convertonly to indicate run should stop after conversion. 16. User interface handles automatic conversion of Excel models before run. 17. Changed the way interruptions are specified in Excel models.
11. Reference Topics: What's New in this Release Minor Changes: 1. Added 'FixedCost' input for tool groups & operator groups. 2. Added fixed cost report. 3. Added total fixed cost & fixed cost per unit vs. start rate graph. 4. Added fixed cost per unit & cycle time vs. suggested util% graph. 5. Added model information sheet in Excel models. 6. Operator group sheet in Excel models now named 'operators'. 7. Excel conversion program now ok for models without operators. 8. 'Products' sheet on Excel models must now contain RTSHEET column. 9. Color coded required/optional columns in sample model 'xlmodel.xls' 10. ManSim conversion program now executes from pull-down menu. 11. Testbed conversion program now executes from pull-down menu. 12. Online help for ManSim conversion program. 13. Some support for operators in ManSim conversion program. 14. Added -DelOpsets option -- deletes all operator uses in model. 15. Changed -DelScrap to maintain throughput rates and mix. 16. Added '@optionsfile' -- reads command line from file. 17. Options file may specify options for multiple runs separated by ";" 18. Model run from user interface automatically closes .run/.ch/.dbg files. 19. Included Sematech Testbed dataset #1 as Excel model (set1.xls). 20. Added tool group / operator group cross-reference report. 21. Added operator group / tool group cross-reference report. 22. Eliminated option -noopen (not needed since .p* output files gone). 23. Eliminated option -repfiles (results output file includes replication #). 24. Eliminated option -msetrunc (did not seem useful). 25. Eliminated option -xtrace (cycle time data written to results file). 26. Eliminated option -xbtrace (batch cycle time data written to results file). 27. Eliminated option -nistrace (did not seem useful). 28. User interface checks model name and output base name for validity. 29. User interface automatically quotes run labels. 30. User interface sets saved flag for .run files so user can easily close. 31. Added single beep when exiting if no problems. 32. Added double beep when exiting if there is an error. 33. Added option -silent to suppress beeping at exit. 34. Added chart abbreviation to worksheet name when creating charts. 35. Added check for unstable input rates between replications. 36. Changed manual to reflect new source code option. 37. Changed paper model to use adjustable inter-release distribution. 38. Changed manual to specify why adjustable distributions are nice. 39. Added detailed chart / report descriptions to manual and online help. 40. Modified setup rate approximation to handle basic batch tool approximation. 41. User interface warns user if chart data exceeds Excel limit (16384 rows). 42. Changed fixed cost report to break out costs for tool groups, operators. 43. Added option -NoSimOutput: suppress within-simulation output. 44. Added option -NoRepOutput: suppress end-of-replication output. 45. Added option -NoRunOutput: suppress end-of-run output.
11.15. What's New in Version 1.0 46. Eliminated option -pointwait (did not seem useful). 47. Eliminated option -pointbias (c.t. by lot now generated automatically). 48. Eliminated option -tputreport (will turn into output chart). 49. Eliminated option -routeinfo (did not seem useful). 50. Eliminated option -ssyield (will turn into output chart). 51. Eliminated option -nonis (already have output chart). 52. Eliminated options -chartall/-chartend (replaced by no...output). 53. Eliminated option -norunlist (replaced by no...output). 54. Eliminated option -nohead (did not seem useful). 55. Eliminated option -verify (no longer needed for verify suite). 56. Replaced chart & report dialogs with single "select output" dialog. 57. Now keeping track of lot numbers within products. 58. Eliminated target cycle time code, options, & options dialog. 59. Eliminated number in system report -- available as output chart. 60. Eliminated steady-state yield report -- available as output chart. 61. Cycle time chart automatically selects a product for display. 62. Eliminated throughput by lot size report -- available as output chart. 63. Corrected average batch size calculation at batch tools with setup. 64. Added average cycle time by lot output chart. 65. Added bottleneck resource output chart. 66. Eliminated workstation utilization chart. 67. Fixed bug in -delscrap (incorrect for multi-unit lots). 68. Eliminated option -traffic (did not seem useful). 69. Moved -IgnoreErr option to the Run Factory Explorer Dialog. 70. Moved -NoRelease option to the Set Input Rate Dialog. 71. Completed documenting all options dialog boxes with online help. 72. User interface now an Excel Add-In. 73. User interface model run now saves all dialog box settings. 74. Default chart and DOE choices reset with first execution. 75. Chart and DOE choices now saved to initialization file. 76. Reordered reports to put capacity analysis reports first. 77. Changed to always print capacity analysis reports even if unstable. 78. Modified Testbed conversion to add 'AvoidSetups' at tools with setup. 79. Can click on cell where options list is to be stored. 80. Can select range for batch execution using mouse. 81. Fixed bug in generation of DOE screening design. 82. Changed bottleneck resource chart to include quantities, better labels. 83. Results workbook can be closed by user without Excel asking for save. 84. Only generates fixed cost by start rate, fixed cost by util%, and characteristic curve data if required options are enabled. 85. Renamed "Weighted Avg. cycle time / RPT" to "Cycle Time Characteristic Curve" 86. Added formatting conventions section to front of manual. 87. Number in queue chart sorts by estimated WIP and displays top 5. 88. Queue delay chart sorts by estimated delay and displays top 5. 89. Fixed bug in screening designs -- was using bad design matrix. 90. Manual now includes an index.
11. Reference Topics: What's New in this Release 91. Added section on hot lot modeling to manual. 92. Fixed bug in bottleneck chart -- didn't work for models w/single tool group. 93. Added quotes around file names for compatibility with Excel 95/Mac Excel. 94. Changed file name validity check to work with Excel 5 on NT.
12. Reference: Topics: Translating Models from Prior Releases
12.1 Introduction
Factory Explorer releases are identified by a version number. Version numbers are shown on the inside cover of the Factory Explorer manual, and on the FactoryX | About Factory Explorer dialog. If you are upgrading from a release of Factory Explorer that has the same integral version number as the current release, no model translation is necessary (e.g. no translation is required when upgrading from Factory Explorer 2.0 to 2.1, but translation is required when upgrading from Factory Explorer 1.0 to 2.0). The following sections contain instructions for model translation.
12.2 Translating Factory Explorer Version 1 Models to Version 2

12.2.1 ASCII Models This section contains instructions for translating Factory Explorer Version 1 ASCII models to Factory Explorer Version 2 format. To aid in this translation, the Perl script v1tov2.prl is included with the Factory Explorer distribution. Perl is a widely available scripting language that runs on many different platforms, including Windows. If you do not have access to a Perl interpreter for your platform, please contact technical support to obtain one. The script v1tov2.prl reads one or more ASCII model files, and translates to the new model format whenever possible. For example, in DOS, the following command line would translate the model factory to Version 2 format and place it in the file factory.fx2: perl v1tov2.prl factory.del The following command line would translate all model configuration files in the current directory to Version 2 format: perl v1tov2.prl *.del
12. Reference: Topics: Translating Models from Prior Releases v1tov2.prl will not completely translate all Version 1 models: 1. If a model contains the RelUnif statement, which has been removed in Version 2, this statement will need to be replaced manually with Release. 2. If a model contains a ClockFirst, BusyFirst, or WorkFirst statement that does not directly follow the corresponding ClockDown, BusyDown, or WorkDown statement, the translated file will contain a FirstInterrupt statement in the wrong location. Edit the translated file to move the FirstInterrupt statement to follow its corresponding interruption. 3. If a model contains a StaggerCDown statement that does not directly follow the corresponding ClockDown, the translated file will contain a StaggerFirst statement in the wrong location. Edit the translated file to move the StaggerFirst statement to follow its corresponding interruption. 4. If a model contains an EstComp statement specifying an estimated completion, the translated model will also contain this statement. Since this statement is no longer supported in Version 2, it must be manually removed. 5. If a model uses the CCOMPTIME dispatch rule, the translated file will also contain this rule. This dispatch rule has been modified to use raw process time, not estimated completion times, and has been renamed CCOMPRPT. The rule must be renamed manually in the translated model. 6. If a model contains the UseLast statement, the translated file will also contain this statement. Since this statement is no longer supported in Version 2, it must be manually removed. To mimic the effect of UseLast, take all but the last release pattern and write to a file in the form of a release list. Leave the final release pattern in the model, and it will be executed repeatedly once the release list is exhausted. 7. If a model contains the FixedCost statement for operators, the translated file will also contain this statement. Since this statement is no longer supported in Version 2 for operators, it must be manually removed. 8. If a model includes Transform or Assembly statements, the translated file will include the unit multiplier or units required parameters as random variables. In Version 2, these parameters must be specified as constants. These parameters must be manually changed to constants in the translated model. 12.2.2 Excel Models This section contains instructions for translating Factory Explorer Version 1 Excel models to Version 2 format. The recommended way to perform this translation for a model is via the following steps: 1. Using Factory Explorer Version 1, run the Version 1 Excel model. This step will create a copy of the model in Version 1 ASCII format. 2. Follow the instructions in Section 12.2.1 for converting the Version 1 ASCII model to Version 2 format.
12.3. Translating Delphi Version 10 Models to Factory Explorer Version 1 3. Using Factory Explorer Version 2, run the Version 2 ASCII model with the WriteExcel option enabled. From the Factory Explorer Version 2 output menu, select Build Excel Model from Final Model. The resulting model is in Version 2 Excel format.
12.3 Translating Delphi Version 10 Models to Factory Explorer Version 1

Factory Explorer Version 1 can read Delphi Version 10 ASCII models without translation.
13. Reference Topics: Run-Time Options
13.1 Introduction
This chapter contains a complete list of Factory Explorer run-time options. See Chapter 6 for detailed information on specifying run-time options.
13.2 Complete List of Run-Time Options

Let modelname be the model name prefix. Factory Explorer run-time options and arguments are not case sensitive. File names that appear as part of options, however, must be in the proper case for any operating system with case-sensitive file names. A complete list of options is given below. In the Factory Explorer Excel user interface, a few primary options are specified on the Run Factory Explorer dialog, others are specified on individual run-time option dialogs. AddPct value Specifies the value added to the system input rate between replications. Options ReleasePct and Reps must also be specified. Value is a flat percentage of system capacity. For example, if the input rate is set to 50% of capacity, and the increase is set to 5%, a three replication run of the model would have release rates of 50%, 55%, and 60% of capacity, respectively. In Excel interface, specified on Lot Release options dialog. AddRate value Specifies the value added to the system release rate between replications. Options ReleaseRate and Reps must also be specified. The unit of measure for value defaults to units per hour, but can be overridden with AddRateUM. In Excel interface, specified on Lot Release options dialog. AddRateUM rateUM Specifies the unit of measure for the AddRate run-time option. The argument rateUM must be one of UnitsPerHour, UnitsPerDay, UnitsPerWeek, UnitsPerMonth, UnitsPerQuarter, or UnitsPerYear. The default value is UnitsPerHour. For more information on units of measure, see Section 4.7 of the manual. In Excel interface, specified on Lot Release dialog. AddSuggPct value Specifies the value to add to the suggested capacity loading% between replications. In Excel interface, specified on Capacity Load% options dialog.
13. Reference Topics: Run-Time Options AddStream value Specifies the value that will be added to the initial random number stream between replications. This option has no effect unless DoSim is enabled. Unless this option is specified, random number streams are not reset between replications, and random numbers are generated from the place where the previous replication left off. When this option is specified, the initial random number stream has value added to it, and all random number streams within the simulation are re-assigned. Use of this option can increase the effectiveness of common random numbers as a variance reduction technique when comparing multiple replications, because it effectively re-synchronizes random number streams after each replication. In Excel interface, specified on Random #'s options dialog. CILevel level Specifies the percent level of the confidence intervals given in the output statistics. Default level is 95, for 95% confidence intervals. In Excel interface, specified on Output Data options dialog. ClearStats time This option only applies to replication-level output statistics. Since capacity analysis is only performed on period boundaries, ClearStats has no effect on capacity analysis based output statistics unless StartDate is also enabled (if StartDate is not enabled, the entire replication is one analysis period, and capacity analysis is only performed once at the beginning of the replication) If StartDate is enabled, then end-of-replication capacity analysis based output statistics are calculated from analysis periods after the clear statistics time. Endof-replication simulation based output statistics are always cleared when time is reached in the analysis run. The unit of measure for time is always the same as that specified with RunLenUM. If RunLenUM is not enabled, the unit of measure is hours. In Excel interface, specified on Run Factory Explorer dialog. CompareFlows filename This option is useful for comparing the process flows in a Factory Explorer model against process flows from a separate system or model. For example, most shop-floor control systems maintain process flow lists in a database. Since these flows are used for factory operation, it is useful to verify that the flows in the Factory Explorer model match those from the factory. If CompareFlows is enabled, Factory Explorer reads in a list of process flow / operation I.D. pairs from filename, and compares that list against the process flows in the model. Factory Explorer generates a warning for each discrepancy between the model and the comparison file. These warnings are available on the Warnings Worksheet. The comparison file filename should contain one record per line. Each record is composed of two fields: a process flow name and an operation I.D. The fields should be separated by one or more spaces. A sample compare flows file for the Aspen.xls model is included with Factory Explorer (Aspen.cfl). In Excel interface, specified on Output options dialog. DeadlockOK Specifies that Factory Explorer should go ahead and simulate a model, even when it has detected during model validation that deadlock is a possibility. Normally Factory Explorer would treat this condition as a model validation error. In some cases, however, models where deadlock is theoretically possible will run ok in practice. Beware that if you enable this option and deadlock does occur during the simulation run, the resulting situation may be very difficult to debug. In Excel interface, specified on Deadlock options dialog.
13.2. Complete List of Run-Time Options DelInt Ignores all tool group and operator interruptions. Useful for testing the effect of downtime on a model without manually removing downtime entries. In Excel interface, specified on Model Changes options dialog. DelLots Removes all individual lots from the model. This option must be enabled if ReleasePct or ReleaseRate is enabled for a model with individual lots. In Excel interface, specified on Model Changes options dialog. DelOpGroups Ignores all operator uses, and sets the number of operators in each group to zero. Operators are still reported as being present in the model, but all uses of operators for repair or processing or travel are deleted. Useful for testing the effect of operators on a model without manually removing all operator references. In Excel interface, specified on Model Changes options dialog. DelRework Leaves rework entries in process flows, but sets all rework probabilities to zero, so rework is effectively ignored. Useful for testing the effect of rework on a model without manually removing rework entries. In Excel interface, specified on Model Changes options dialog. DelScrap After reading in the model and performing capacity analysis, Factory Explorer will adjust the release rate for all products to match the throughput rate, then zero out all scrap probabilities. The effect of this option is to create a model where there is no scrap, but the throughput rate and mix is the same as the original model. Useful for testing the effect of scrap on a model without manually removing scrap entries. In some cases, Factory Explorer cannot maintain throughput rates for all products when removing scrap. In particular, if a model includes transform or assembly, and a transformed or assembled product specifies a process flow containing scrap, Factory Explorer will not be able to maintain the throughput rate for the transformed or assembled product. Instead, Factory Explorer will maintain the throughput rate for all release products, and the throughput rate for the transformed or assembled product will be implicitly determined from the throughput rate of the sub-transform and sub-assembly product(s). If this situation occurs, Factory Explorer generates a warning on the output console. In Excel interface, specified on Model Changes options dialog. DelSetups Removes all setups from the model. In Excel interface, specified on Model Changes options dialog. DispatchRule rule Overrides dispatch rule at all tool groups and operator groups. Use of this option only specifies that the given dispatch rule is used by all tool groups and operator groups; it does not modify the setting of AvoidSetups flags (if any) specified in the model. In Excel interface, specified on Model Changes options dialog. DoCap Specifies that capacity analysis should be performed. Capacity analysis of models containing ramp data also requires StartDate. The analysis run length is specified with RunLen. In Excel interface, specified on Run Factory Explorer dialog. DoCost Specifies that cost analysis should be performed. Cost analysis requires that DoCap also be enabled. The analysis run length is specified with RunLen. In Excel interface, specified on Run Factory Explorer dialog. DOE designpoint Specified by the user interface DOE module. Writes all defined DOE performance measures to modelname.doe at the end of each replication,
13. Reference Topics: Run-Time Options identified with the specified design point. For more information, see the user interface on-line help for Design of Experiments. Not available in Excel interface specified automatically by DOE module. In Excel interface, the DOE module is reached via the Sensitivity button on the Run Factory Explorer dialog. DOEAppend designpoint Specified by the user interface DOE module. Appends all defined DOE performance measures to modelname.doe at the end of each replication, identified with the specified design point. For more information, see the user interface on-line help for Design of Experiments. Not available in Excel interface specified automatically by DOE module. In Excel interface, the DOE module is reached via the Sensitivity button on the Run Factory Explorer dialog. DoSched Specifies that scheduling analysis should be performed. Scheduling analysis requires that DoSim also be enabled. The analysis run length is specified with RunLen. In Excel interface, specified on Run Factory Explorer dialog. WARNING: Running with schedule analysis enabled can generate a very large results data file. You should probably start with a very short run, e.g. just a few hours before making longer runs. DoSim Specifies that simulation analysis should be performed. Simulation analysis of models containing ramp data also requires StartDate. The analysis run length is specified with RunLen. In Excel interface, specified on Run Factory Explorer dialog. DownMultOp multiplier Multiplies all operator group interruption time-to or unitsto and time-offline mean values by multiplier. All operator interruption random variables must be specified with distributions where one of the parameters is the mean of the distribution. Note that when using this option, the percentage of time that operators are unavailable due to interruption does not change; only the frequency and severity of interruption is affected. In Excel interface, specified on Model Changes options dialog. DownMultTG multiplier Identical to DownMultOp, but applies only to tool groups. In Excel interface, specified on Model Changes options dialog. FirstStream number Specifies that the simulation should use number as the starting random number stream. This option has no effect unless DoSim is enabled. In order to make the variance reduction technique of common random numbers as applicable as possible, the simulation sequentially assigns random variables in the model to independent random number streams starting with stream number. If the first stream is specified as 5, say, then Factory Explorer will use stream 5 for interarrival times, and stream 6 for service times. Several additional streams are used internally by Factory Explorer for housekeeping purposes. Valid entries for number are 1 to 21474. If this option is not specified, the default is to assign streams starting from stream 1. In Excel interface, specified on Random #'s options dialog. FlagNoSetup When a tool is changing setup I.D.'s, and there is no specified default or sequence-dependent setup time that applies, write a warning message to the console. In Excel interface, specified on Output Data options dialog. ForceFull Forces nearly full batches. For tools with batch sizes specified in terms of lots, not units, enabling this option sets the minimum batch size for each batch I.D. equal to the maximum batch size. For tools with batch sizes specified in
13.2. Complete List of Run-Time Options terms of units, enabling this option sets the minimum batch size for each batch I.D. equal to one plus the maximum batch size minus the largest nominal lot size of any product processed with this I.D. If the resulting minimum batch size is less than one unit, it is set to one unit. In Excel interface, specified on Model Changes options dialog. Label text Adds text as a label in the output file. Can be used to comment the exact run conditions, for example the factor settings used in a particular run in a design of experiments. If you are specifying this option from the command line or in an options file (e.g. you are not using the Factory Explorer Excel interface), and text contains spaces, specify option as Label "text". In Excel interface, specified on Output Data options dialog. NBatch batches Specifies the number of batches to use when calculating batch means and confidence intervals for time in system. Unless specified, Factory Explorer uses a default of 20 batches. The number of batches used is displayed in the reports file. Note that this option has nothing to do with how processing is performed at batch tools in the model. In Excel interface, specified on Output Data options dialog. NoPeriodOutput Suppress end-of-period output (e.g. end-of-period reports, worksheets, and results data). Normally this output is written to the reports file and to the results data file. For runs with many periods, these files can grow to be quite large, so this option is provided to suppress the output if it is not needed. In Excel interface, specified on Output Data options dialog. NoRelease Suppress regular lot release mechanism. Lots will only be loaded into the system as specified on the Lots worksheet (Excel models) or as specified using the Lot statement (ASCII models). In Excel interface, specified on Lot Release options dialog. NoRepOutput Suppress end-of-replication output (e.g. end-of-replication reports, worksheets, and results data). Normally this output is written to the reports file and to the results data file. For runs with many replications, these files can grow to be quite large, so this option is provided to suppress the output if it is not needed. In Excel interface, specified on Output Data options dialog. NoWait Normally, when Factory Explorer completes a model run or series of model runs, it displays an exit message and waits for user input before closing the output console. If this option is specified for any model within a run, this wait is suppressed. This option is normally used only when Factory Explorer is executed in a command line environment such as MS-DOS, so NoWait is not available within the Excel user interface. OneStream Instead of generating random numbers from many different streams, Factory Explorer will generate from a single stream. This option has no effect unless DoSim is enabled. This option is included so it is possible to check the effect of generating from overlapping random number streams. If the use of this option does not give significantly different results, then it is probably safe to assume that overlapping streams are not causing a problem. Overlapping streams will occur in long simulations because each stream is simply a block of 100,000 random numbers from a much longer sequence. If more than 100,000 random numbers are generated from a single stream, these numbers will effectively be
13. Reference Topics: Run-Time Options from the following stream. It is possible, but unlikely, that this overlapping behavior could produce dependence within otherwise independent random variables in the model, thus biasing some simulation estimates. In Excel interface, specified on Random #'s options dialog. OneUnitRPT Instead of calculating raw process times on the basis of lots with an average number of starting units, Factory Explorer will calculate on the basis of single-unit lots. If any per-unit processing times are present in a model, this option will result in lower raw process times. Not currently available in Excel interface. OutBase basename Specifies a new base name for all output files instead of the normal base of modelname. Useful when you are making multiple runs of the same model, but you want to keep the output from each model run in a separate files. In Excel interface, specified on Run Factory Explorer dialog. OutCTUM timeUM Specifies the unit of measure for cycle time estimates found on output reports, charts, and worksheets. The argument timeUM must be one of Hours, Days, Weeks, Months, Quarters, or Years. The default value is Days. For more information on units of measure, see Section 4.7 of the manual. In Excel interface, specified on Output Data options dialog. OutRateUM rateUM Specifies the unit of measure for start and throughput rate estimates found on output reports, charts, and worksheets. The argument rateUM must be one of UnitsPerHour, UnitsPerDay, UnitsPerWeek, UnitsPerMonth, UnitsPerQuarter, or UnitsPerYear. The default value is UnitsPerWeek. For more information on units of measure, see Section 4.7 of the manual. In Excel interface, specified on Output Data options dialog. Percentile value Specifies the upper percentile reported for cycle times. Default value is 95, for 95th percentiles. In Excel interface, specified on Output Data options dialog. ReleasePct value Specifies that release rates be modified to achieve a system capacity loading% of value. Factory Explorer sets the release rate for the first product to value% of its maximum feasible value (assuming a constant mix). The argument value should be specified as a percentage (i.e. it should range from 0 to 100, not from 0 to 1). Release rates for all other products are adjusted to maintain the mix specified in the model. In models with release patterns, this release rate adjustment can only take place if all inter-release distributions include the mean inter-release time as a distribution parameter. For example, if the inter-release time is specified as u(a,b), this option cannot be used since the distribution does not have its mean as one of its parameters. Using this option will result in the bottleneck resource's capacity loading% being set to value. This option cannot be used for models with individual lots, unless DelLots is used to remove the individual lots. In Excel interface, specified on Lot Release options dialog. ReleaseRate rate Sets the total unit release rate for the system. Release rates for individual release products are adjusted up or down by an identical ratio to achieve this desired overall release rate. The unit of measure for rate defaults to units per hour, but can be overridden with ReleaseRateUM. This option cannot be used for models with individual lots, unless DelLots is used to remove the individual lots. In Excel interface, specified on Lot Release options dialog.
13.2. Complete List of Run-Time Options ReleaseRateUM rateUM Specifies the unit of measure for the ReleaseRate runtime option. The argument rateUM must be one of UnitsPerHour, UnitsPerDay, UnitsPerWeek, UnitsPerMonth, UnitsPerQuarter, or UnitsPerYear. The default value is UnitsPerHour. For more information on units of measure, see Section 4.7 of the manual. In Excel interface, specified on Lot Release dialog. Reps replications Analysis is replicated replications times. Output files contain data from all replications. In Excel interface, specified on Run Factory Explorer dialog. RunLen time Specifies the length of the analysis run. The unit of measure for time defaults to hours, but can be overridden with RunLenUM. The parameter time must be an integer. If StartDate is not enabled, each replication consists of one analysis period of length time. If StartDate is enabled, each replication consists of time analysis periods, and the length of each analysis period is determined by RunLenUM (each analysis period is one unit of measure long, e.g. one week, one month, etc.). In Excel interface, specified on Run Factory Explorer dialog. RunLenUM timeUM Specifies the unit of measure for the analysis run-length. If StartDate is enabled, then RunLenUM also specifies analysis period length. The argument timeUM must be one of Hours, Days, Weeks, Months, Quarters, or Years. The default value is Hours. For more information on units of measure, see Section 4.7 of the manual. In Excel interface, specified on Run Factory Explorer dialog. SchedEv event-name Turns on scheduling trace, but only for event event-name. May be used in conjunction with other scheduling options. See Table 23-1 for a complete list of events. In Excel interface, specified on Scheduling Output options dialog. SchedLot LotID Turns on scheduling trace, but only for the specified lot. May be used in conjunction with other scheduling options. In Excel interface, specified on Scheduling Output options dialog. SchedOG OperatorGroup-name Turns on scheduling trace, but only for specified Operator Group. May be used in conjunction with other scheduling options. In Excel interface, specified on Scheduling Output options dialog. SchedRep rep Turns on scheduling trace, but only once the simulation starts replication rep. May be used in conjunction with other scheduling options. In Excel interface, specified on Scheduling Output options dialog. SchedShowAll Turns on scheduling trace. May be used in conjunction with other scheduling options. In Excel interface, specified on Scheduling Output options dialog. SchedStart time Turns on scheduling trace, but only after simulation clock reaches time (specified in hours). May be used in conjunction with other scheduling options. In Excel interface, specified on Scheduling Output options dialog. SchedTG ToolGroup-name Turns on scheduling trace, but only for specified ToolGroup. May be used in conjunction with other scheduling options. In Excel interface, specified on Scheduling Output options dialog. SetDueXRPT multiple Overrides due-date offsets for all products with a constant multiple of each product's raw process time. In Excel interface, specified on Model Changes options dialog.
13. Reference Topics: Run-Time Options SetLTF value Overrides lead-time factor for all products with value. In Excel interface, specified on Model Changes options dialog. ShowAll Show all helpful information. This option is primarily used when running Factory Explorer on command line platforms where on-line help is not available. Not currently available in Excel interface. ShowDisp Show dispatch rules. This option is primarily used when running Factory Explorer on command line platforms where on-line help is not available. Not currently available in Excel interface. ShowDist Show distributions. This option is primarily used when running Factory Explorer on command line platforms where on-line help is not available. Not currently available in Excel interface. ShowGen Show general information. This option is primarily used when running Factory Explorer on command line platforms where on-line help is not available. Not currently available in Excel interface. ShowOpt Show all run-time options. This option is primarily used when running Factory Explorer on command line platforms where on-line help is not available. Not currently available in Excel interface. ShowSyn Show ASCII model file syntax. This option is primarily used when running Factory Explorer on command line platforms where on-line help is not available. Not currently available in Excel interface. StartDate date Specifies the starting date for an analysis run. When analyzing models containing ramp data, StartDate is required. When specified on the command line, date can be in ISO date format (yyyy-mm-dd) or Excel's 1900 date format (the day number starting with January 1st, 1900 see Section 4.2.5 of the manual for more information). Factory Explorer's Excel interface automatically converts most popular date formats to ISO format. In Excel interface, specified on Run Factory Explorer dialog. SuggLoading pct Specifies the capacity loading% used when calculating suggested resource levels in capacity analysis reports. The argument pct should be specified as a percentage (i.e. it should range from 0 to 100, not from 0 to 1). For each resource (tool group or operator group), Factory Explorer will approximate the minimum number of resources required to keep the resource's capacity loading% below pct. To vary the suggested capacity loading% for individual tool or operator groups, use the CBUFFER column (Excel models) or the CapacityBuffer statement (ASCII models). In Excel interface, specified on Capacity Load% options dialog. Unstable Specifies that Factory Explorer should allow simulation and/or cost analysis of a model that capacity analysis predicts will be unstable. When this occurs, the capacity analysis has detected that one or more tool groups or operator groups in the model are overloaded, and queue lengths / queue delays will grow without bound as the simulation is run. It is probably best to start by looking at capacity analysis results to better understand the problem. The simulation of an unstable system can be interesting when short-term results are desired. Beware that unstable simulation runs generally require ever-increasing amounts of memory as the run proceeds. If the amount of memory required for a simulation exceeds the amount of physical memory available, the operating system is forced
13.2. Complete List of Run-Time Options to use virtual memory or swap space (the operating system swaps information from physical memory out to disk, thus making space for your simulation). For small amounts of memory, this process is relatively efficient, but for large amounts of memory the operating system quickly reaches a point where it spends most of its time swapping information back and forth between physical memory and the disk. Since disk access is quite slow compared to physical memory access, your simulation will slow to a crawl if the operating system uses a large amount of virtual memory. In Excel interface, specified on Lot Release options dialog. UserInt time Interval between calls to user code during simulation (specified in hours). See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UserParm1 string Optional run-time parameter for user code. See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UserParm2 string Optional run-time parameter for user code. See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UserParm3 string Optional run-time parameter for user code. See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UserParm4 string Optional run-time parameter for user code. See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UserParm5 string Optional run-time parameter for user code. See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UserStart time Time of first call to user code during simulation (specified in hours). See Section 18 of the user manual for information on customizing Factory Explorer with user code. In Excel interface, specified on User Code options dialog. UseSugg Instructs Factory Explorer to make the model run using the suggested resource quantities calculated by capacity analysis. These suggested resource quantities are based on a suggested capacity loading% which can be controlled with SuggLoading. In models with ramp data, suggested tool and operator quantities are calculated at the beginning of each analysis period, based on the model that is effective at the period's start date. If tool or operator input records are specified in the middle of an analysis period, Factory Explorer will also override these intermediate records with the suggested quantities as calculated at the beginning of the analysis period. In Excel interface, specified on Capacity Load% options dialog. WriteDetail Enables the generation of detail data records. Normally, this output is suppressed, as it is not required for many of Factory Explorer's output reports or charts. However, these detail records are required for some outputs (e.g. the Process Step Detail Worksheet) and can be useful for post-analysis processing by
13. Reference Topics: Run-Time Options third-party software. Note that if this option is enabled for a run with multiple replications or multiple analysis periods, the results data file (modelname.rdf) can become quite large. This file will be large because it will contain one record for each product / process step pair for each analysis period. Because all of Factory Explorer's output charts and worksheets are extracted from the results data file, enabling this option can significantly increase the time required to create charts and worksheets. See Section 14 of the manual for information on detail data records. In Excel interface, specified on Output Data options dialog. WriteEstAlt If enabled in conjunction with DoSim and WriteExcel or WriteTestbed, specifies that the final model written out should use estimated alternative step percentages from the simulation rather than the alternative step percentages given in the input model. There is one exception, however. For alternative steps that are never visited by lots during the simulation run, Factory Explorer writes the alternative step percentages given in the input model, since there are no simulation estimates. The alternative step percentages written in the final model are estimated from all periods of all replications. To view all alternative step input percentages and estimated percentages in one location, generate the Alternative Steps Summary Worksheet. In Excel interface, specified on Output Data options dialog. WriteExcel Specifies that a copy of the final model should be written in a format that can be read by the user interface and converted to an Excel model. When this option is specified, Factory Explorer writes out the following files in commaseparated (CSV) format: modelname.ypr (product data), modelname.ytg (tool group data), modelname.yop (operator data). Factory Explorer writes process step data for the first process to modelname.y1, process step data for the second process to modelname.y2, etc. In Excel interface, specified on Output Data options dialog. WriteFabTime Specifies that Factory Explorer should write a FabTime-compatible movement transaction log during the simulation run. When this option is specified, Factory Explorer creates a comma-separated (CSV) format file named modelname.fab. This file may then be read into FabTime to mimic the data flow that FabTime expects from a factorys manufacturing execution system. In Excel interface, specified on Output Data options dialog. WriteTestbed Specifies that a copy of the final model should be written in Sematech Testbed format. If the model contains ramp data, the resulting testbed model will be a snapshot of model data as it stands upon completion of the analysis run (since the testbed format does not support ramp data). See Section 17.3 of the manual for more information on this format. Not all Factory Explorer model data can be translated to the Testbed format specific notes on the translation process are written to the output model's comments file model.cf. In Excel interface, specified on Output Data options dialog. ZeroUnitOk Suppress the normal warning that Factory Explorer generates when a lot release is skipped because the randomly generated lot size turns out to be zero. In cases where the lot size distribution includes a positive probability of generating zero units, the actual lot size distribution will not match the specified lot size distribution, because Factory Explorer does not allow lots to be released
13.2. Complete List of Run-Time Options into the system with zero units. Using such a distribution could result in subtle modeling errors, so Factory Explorer normally generates a warning when any zero-unit release is skipped. Not currently available in Excel interface.
14. Reference Topics: The Results Data File
14.1 Introduction
During each model run, Factory Explorer records output in the results data file. This chapter documents the format of this file. The purpose of the results data file is to store results from the model run in a format that can be easily read and used by Factory Explorer's user interface to create output charts and worksheets. In addition, other more detailed data can also be written to this file if requested by the user. Although the results data file is primarily used by Factory Explorer to generate output charts and worksheets, records contained within it may be read and analyzed by other third-party software.
14.2 General Information

A results data file is composed of a series of variable-length records. Within each record, fields are stored in a comma-separated, variable-length format (CSV format). The first record is composed of a single field containing the word Type. Following this first record is a set of header records. Data records follow the last header record. Generation of specific records depends on the information specified in the model and the options enabled at run-time. The first field in a header record specifies the record type. Record types are generated internally by Factory Explorer, and are upper-case alphabetic abbreviations for the information contained within the record. The remainder of the fields in a header record contain header names for each field to be found in data records of this type. Where appropriate, the unit of measure for a field is noted in parentheses (e.g. (Hours) or (UnitsPerWeek)) following the field name. The first field in a data record specifies the record type. The remainder of the fields in a data record contain the actual data for the record. In data records, all fields that specify object names (product names, tool group names, etc.) are double-quoted. The double-quotes ensure that names containing a comma are not broken into two fields when read into Excel. Results data file records are written to modelname.rdf, unless OutBase basename is specified, in which case the records are written to basename.rdf. Certain detail records are only written to the results data file if WriteDetail is enabled. Copyright WWK 1995-2009 Factory Explorer 317
14. Reference Topics: The Results Data File
14.3 Documentation for Specific Record Types

ALTSTEPS records contain alternative process step statistics. An ALTSTEPS record is generated at the end of each analysis period and at the end of the analysis run for each alternative process step. An ALTSTEPS record contains the data fields Rep, Period, Period Start Date, Period End Date, Process, Step, Tool Group, Operator Group, Operation, Model AltPct, Sim AltPct, Total Lot Arrivals, Number Times Chosen. ALTSTEPS records are only generated if the model includes alternative steps, and if DoCap and / or DoSim are enabled. End of period ALTSTEPS records are not generated if NoPeriodOutput is enabled. BNECK records contain capacity data for each tool group and operator group (resource), sorted by capacity loading%. A BNECK record is generated at the end of each replication for each resource. A BNECK record contains the data fields Rep, Pd, Period Start Date, Period End Date, Rank, Resource, Chart Label, Process Type, Total Input Rate, Theo Max Proc Rate, Percent NonSched, Number of Offline Types, Percent Offline n (n=1 to number of offline types), Percent Offline (Total), Percent Setup, Percent Repair, Percent Work, Percent Free, Current Actual Max Proc Rate, Group WGR (Unit of measure controlled by OutRateUM), Resource WGR (Unit of measure controlled by OutRateUM), Current Resource Count, Current Capacity Loading, Sugg Max Loading, Sugg Exact Resource Count, Sugg Resource Change, Sugg Whole Resource Count, New Capacity Loading, and Resource Type. BNECK records are not generated if NoRepOutput is enabled. BNECKPR records contain capacity data for each tool group and operator group (resource), sorted by capacity loading%. Each resource has total working time by product. A BNECKPR record is generated at the end of each replication for each resource. A BNECKPR record contains the data fields Rep, Pd, Period Start Date, Period End Date, Resource Type, Row, Resource Group, Chart Label, Number of Products, Pre Percent Factory Non Sched, Pre Percent Offline (Total), Pre Percent Setup, Pre Percent Repair, Pre Percent Work n (n=1 to number of products), Pre Percent Free, and Current Capacity Loading. BNECKPR records are not generated if NoRepOutput is enabled. BNECKSIM records contain simulation data for each tool group and operator group (resource), sorted by capacity loading%. A BNECKSIM record is generated at the end of each replication for each resource. A BNECKSIM record contains the data fields Rep, Pd, Period Start Date, Period End Date, Rank, Resource, Chart Label, Process Type, Resource Type, Sim Percent Factory Non Sched, Number of Offline Types, Sim Percent Offline n (n=1 to number of offline types), Sim Percent Offline (Total), Sim Percent Setup, Sim Percent Repair, Sim Lost Capacity (Total), Sim Precent Busy Working BatchWork, Sim Precent Busy Working SingleWork, Sim Precent Busy Working ReWork, Sim Precent Busy Working Non ReWork, Current Sim Precent Busy Working, Sim Precent Busy No Oper, Sim Precent Busy Held, Sim Percent Work Pending (Total), Sim Precent Busy BatchWork, Sim Precent Busy SingleWork, Sim Precent Busy ReWork, Sim Precent Busy Non Rework, Sim Precent Busy, and Sim Precent Free. BNECKSIM records are not generated if NoRepOutput is enabled. CT records contain cycle time and other data related to a specific lot. A CT record is generated whenever a lot successfully exits the factory. CT records contain the data
14.3. Documentation for Specific Record Types fields Rep, Product, Lot ID, Priority, Number of Units, Start Date, Due Date, Finish Date, and Cycle Time. Data on a CT record is collected when the lot exits the factory. CT records are only generated if WriteDetail and DoSim are enabled. CT records are not generated if NoRepOutput is enabled. CTBYTIME records contain cycle time data by lot exit time. Factory Explorer splits the simulation run length into one hundred equal time slices. For each time slice, it keeps track of the minimum, maximum, and average cycle time of jobs that exit within that slice. A CTBYTIME record is generated at the end of each replication for each product and time slice that contains data. CTBYTIME records contain the data fields Replication, Product, LowerLimit, MidPoint, UpperLimit, Max Cycle Time, Avg Cycle Time, Min Cycle Time, Count. CTBYTIME records are not generated if NoRepOutput is enabled. CTCONT records contain cycle time contribution data by tool group by product. A CTCONT record is generated at the end of each analysis period for each product and tool group, sorted by total contribution. CTCONT records are only generated for products with production volume during the analysis period. A CTCONT record contains the data fields Rep, Pd, Period Start Date, Period End Date, Product, Rank, Tool Group, Chart Label, Tools, Fixed Cost Per Tool, RPT Per Visit, Visits, Total RPT, Total Queue Delay, Cycle Time Contribution, Pct of Total, Cumulative Pct, Loading. CTCONT records are only generated if DoSim is enabled. CTCONT records are not generated if NoPeriodOutput is enabled. CTHIST records contain cycle time histogram data. While running a simulation, Factory Explorer records histogram data for each product and for all products aggregated. A CTHIST record is generated at the end of each analysis period and at the end of each replication for each histogram cell containing a non-zero count. A CTHIST record contains the data fields Rep, Pd, Period Start Date, Period End Date, Product, Lower Limit, Mid Point, Upper Limit, Count, Ratio Of Total. CTHIST records are only generated if DoSim is enabled. CTHIST records for individual periods are not generated if NoPeriodOutput is enabled. CTHIST records for replications are not generated if NoRepOutput is enabled. EITEM records contain expense item cost and consumption summary data. An EITEM record is generated at the end of each analysis period for each expense item. A totals record also printed for each analysis period. EITEM records contain the data fields Rep, Pd, Period Start Date, Period End Date, Expense Item, Total Cons, UOM, Total Cost. EITEM records are only generated if DoCap and DoCost are enabled. EITEM records are not generated if NoPeriodOutput is enabled. GRMR records contain gross margin predictions. A GRMR record is generated at the end of each analysis period for each gross margin line item. GRMR records contain the data fields Rep, Pd, Period Start Date, Period End Date, Item, Totals, Contribution. GRMR records are only generated if DoCap, StartDate, and RunLen are enabled. GRMR records are not generated if NoPeriodOutput is enabled. LASPC records contain required tool space by layout area data. A LASPC record is generated at the end of each analysis period for each layout area. LASPC records contain the data fields Rep, Pd, Period Start Date, Period End Date, Layout Area, Total Copyright WWK 1995-2009 Factory Explorer 319
14. Reference Topics: The Results Data File Tool Space. LASPC records are only generated if the model contains layout areas and DoCap is enabled. LASPC records are not generated if NoPeriodOutput is enabled. LDTM records contain estimated product lead time data. A LDTM record is generated at the end of each analysis period for each end-product / critical sub-product pair. LDTM records contain the data fields Rep, Pd, Period Start Date, Period End Date, Product, Critical Product, Avg CT. LDTM records are only generated if DoSim is enabled, and the model contains assembled or transformed products. LDTM records are not generated if NoPeriodOutput is enabled. OG records contain operator group results data. An OG record is generated at the end of each analysis period for each operator group in the model. OG records contain the data fields Rep, Pd, Period Start Date, Period End Date, Operator Group, Process Type, Total Input Rate, Theo Max Proc Rate, Sim Percent NonSched, Pre Percent NonSched, Number of Offline Types, Sim Percent Offline 1, Pre Percent Offline 1, , Sim Percent Offline, Pre Percent Offline, Sim Percent Setup, Pre Percent Setup, Sim Percent Repair, Pre Percent Repair, Sim Percent Busy, Sim Batch Util, Sim Percent Work, Pre Percent Work, Sim Percent Free, Pre Percent Free, Current Actual Max Proc Rate, Group DGR (Unit of measure controlled by OutRateUM), Op DGR (Unit of measure controlled by OutRateUM), Current Ops Count, Current Capacity Loading, Rank, Sugg Max Loading, Sugg Exact Ops Count, Sugg Ops Change, Sugg Whole Ops Count, New Capacity Loading. If DoCap is not enabled, capacity analysis results will be zero. If DoSim is not enabled, simulation results will be zero. OG records are not generated if NoPeriodOutput is enabled. OGPR records contain operator group capacity by product data. An OGPR record is generated at the end of each analysis period for each operator group / product pair where the product has a non-zero arrival rate for the operator group. A totals record is also printed for each operator group with a non-zero arrival rate. OGPR records contain the data fields Rep, Pd, Period Start Date, Period End Date, Operator Group, Product, Product Type, Percent Work, Cost Alloc Percent, Current Input Rate, Actual Max Input Rate, Capacity Loading. OGPR records are only generated if DoCap is enabled. OGPR records are not generated if NoPeriodOutput is enabled. OPN records contain WIP and cycle time estimates summarized across the process steps within an operation. An OPN record is generated at the end of each analysis period for each series of contiguous steps that can be grouped by operation I.D. OPN records contain the data fields Rep, Pd, Period Start Date, Period End Date, Product, Process, Operation, Sim Lot Arrivals to All Steps in Operation, Number of Steps in Operation, Sim Avg Lot Arrivals to Operation, Sim Avg Queue Length (Units), Sim Avg Queue Delay, Sim Avg WIP, Avg Cycle Time, Cumul Cycle Time. OPN records are only generated if DoSim is enabled. OPN records are not generated if NoPeriodOutput is enabled. OPTION records contain settings for all Factory Explorer run-time options. An OPTION record is generated at the end of the run for each run-time option. An OPTION record contains the data fields Name, Type, Enabled, Value. The Value data field is enclosed in double quotes. OPTION records are generated at the end of all model runs.
14.3. Documentation for Specific Record Types PCOST records contain predicted product cost data for each product. A PCOST record is generated at the end of each analysis period for each product cost item for each product. PCOST records contain the data fields Rep, Pd, Period Start Date, Period End Date, Product, Group Level, Item, Details, Cost Per Good Unit Out. PCOST records are only generated if DoCap is enabled and the model contains some type of cost data. PCOST records are not generated if NoPeriodOutput is enabled. PROCSTEP records contain results data for each product / process step pair. A PROCSTEP record is generated at the end of each analysis period, replication (if the number of analysis periods is greater than one), and run (if the number of replications is greater than one) for each process step within a product's process flow. PROCSTEP records contain the data fields Rep, Pd, Period Start Date, Period End Date, Product, Process, Step, Tool Group, Tool Type, Op Group, Operation, Step Type, Travel Op Group, Non Rework Units Per Hour, Rework Units Per Hour, Total Input Units Per Hour, Raw Unit Cost Per Good Unit, Transform Cost Per Good Unit, Assembly Cost Per Good Unit, M C Cost Per Good Unit, Direct Cost Per Good Unit, Cumulative Direct Cost Per Good Unit, Tool Fixed Cost Per Good Unit, Tool Recurring Cost Per Good Unit, Total Tool Cost Per Good Unit, Op Wages Per Good Unit, Travel Op Wages Per Good Unit, Total Op Wages Per Good Unit, Factory Fixed Cost Per Good Unit, Factory Recurring Cost Per Good Unit, Total Factory Cost Per Good Unit, Total Step Cost Per Good Unit, Cumulative Total Cost Per Good Unit, RPT, Remaining RPT, Sim Non Rework Lot Arrivals, Sim Rework Lot Arrivals, Sim Total Lot Arrivals, Sim Average Queue Delay, Sim Average Cycle Time, Pre Average Lot Size. PROCSTEP records are generated if WriteDetail and DoCap or DoSim are enabled. PROCSTEP records are not generated if NoPeriodOutput is enabled. QDCONT records contain queue delay contribution data by tool group by product. A QDCONT record is generated at the end of each replication for each product and tool group, sorted by total contribution. A QDCONT record contains the data fields Replication, Product, Rank, ToolGroup, Fixed Cost Per Tool, Total Queue Delay. QDCONT records are only generated if WriteDetail and DoSim are enabled. QDCONT records are not generated if NoRepOutput is enabled. RPLAN records contain resource planning information by resource group by item. A RPLAN record is generated for each item for each resource group for all periods. RPLAN records contain the data fields Rep, Total Periods, Resource Type, Resource Group, Sugg Max Loading, Item, Period n (n = 1 to number of periods). RPLAN records are not generated if NoPeriodOutput is enabled. RUNDETAIL records contain miscellaneous analysis run information such as memory usage and simulation speed. A RUNDETAIL record is generated at the end of each analysis period. RUNDETAIL records contain the data fields Rep, Pd, Period Start Date, Period End Date, Time Completed, Lot Moves Per Minute, First Stream, Last Stream, Random Numbers Used So Far, Max Memory, Current Memory, Memory Allocs, Memory ReAllocs, Memory Frees, Run Command. RUNDETAIL records are not generated if NoPeriodOutput is enabled.
14. Reference Topics: The Results Data File RUNINFO record contains overall run information such as run options, run date/time, and Factory Explorer release. A RUNDETAIL record is generated at the start of each run. RUNDETAIL records contain the data fields Run Command, Time Stamp, Release Nmae. A RUNDETAIL is always generated at the start of each run. SCHED records contain a chronological history of Factory Exploere events as they occur in the factory. A SCHED record may be generated each time a selected event occurs. Specific events for output can be specified in several ways. 1) DOSCHED is enabled with no scheduling options selected: A default set of events is shown. 2) SchedShowAll is enabled: Most events are shown (see exceptions below). 3) SchedEv, SchedLot, SchedOg, SchedTg one or all enabled: The option filter criteria specified is shown. 4) An event is triggered without an event number. 5) The user routine SetTraceOn(char *EventName) is called: TheEventName specified is shown( see section 18 for details). The Show Pct Completed and Change Tool State are never generated. SCHED records contain the data fields Rep, Pd, Date, Time, Activity, Lot ID, Product, Process, Step, Tool Type, Tool Group, Tool, Tool Offline Name, Total Tools, Idle Tools, Lots in Queue, Total Lot WIP, Oper Group, Oper, Oper Offline Name, Idle Opers, Lot Size, Lot Priority. SCHED records are only generated if DOSCHED and DoSim are enabled. SCHED records are not generated if NoPeriodOutput is enabled. SETUP records contain estimated setup statistics by setup I.D. A SETUP record is generated at the end of each analysis period for each setup I.D. defined for each tool group in the model. SETUP records contain the data fields Rep, Pd, Period Start Date, Period End Date, Tool Group, Setup Group, Setup ID, Sim Total Setups, Sim Total Setup Time, Sim Setup Pct. SETUP records are only generated if DoSim is enabled. SETUP records are not generated if NoPeriodOutput is enabled. SPC records contain required tool space by space type data. A SPC record is generated at the end of each analysis period for each space type. SPC records contain the data fields Rep, Pd, Period Start Date, Period End Date, Space Type, Total Tool Space. SPC records are only generated if the model contains layout areas and DoCap is enabled. SPC records are not generated if NoPeriodOutput is enabled. SUMMARY records contain factory and product summary outputs. A SUMMARY record is generated at the end of each period for each product in the model, along with one record for the factory. SUMMARY records contain the data fields Rep, Pd, Period Start Date, Period End Date, Product, Gross Margin, Revenue, Raw Unit Expense, S C Expense, Factory Dep. Expense, Factory Rec. Expense, Tool Dep. Expense, Tool Rec. Expense, Operator Wage Expense, Operating Expenses, Total Fixed Cost, Sugg Capacity Loading, Factory Capacity Loading, Cost Per Good Unit Out, Release Rate, Input Rate, Line Yield, Tput Rate, Required Tput Rate, Tput Rate Mismatch, Exit Rate, Max Input Rate, Max Tput Rate, Lots Started, Units Started, Lots Finished, Units Finished, Avg CT Lower Bound, Avg CT Upper Bound, Average Cycle Time, Raw Process Time, Cycle Time Over RPT, CT Var Lower Bound, CT Var Upper Bound, Cycle Time Variance, Cycle Time Upper Pctile, Max Cycle Time, Average Unit WIP, Raw Unit Cost, Average WIP Raw Cost Value, Max Unit WIP, Bias Test Statistic, Degrees of Freedom, Bias Test P Value. SUMMARY records are not generated at the end of an analysis period if NoPeriodOutput is enabled.
14.3. Documentation for Specific Record Types TG records contain tool group results data. A TG record is generated at the end of each analysis period for each tool group in the model. TG records contain the data fields Rep, Pd, Period Start Date, Period End Date, Tool Group, Tool Type, Process Type, Total Input Rate, Theo Max Proc Rate, Sim Percent NonSched, Pre Percent NonSched, Number of Offline Types, Sim Percent Offline 1, Pre Percent Offline 1, , Sim Percent Offline, Pre Percent Offline, Sim Percent Setup, Pre Percent Setup, Sim Percent Busy Working, Sim Percent Busy No Oper, Sim Percent Busy Held, Sim Percent Busy, Sim Batch Util, Sim Percent Work, Pre Percent Work, Sim Percent Free No Work, Sim Percent Free No Oper, Sim Percent Free, Pre Percent Free, Current Actual Max Proc Rate, Group DGR (Unit of measure controlled by OutRateUM), Tool DGR (Unit of measure controlled by OutRateUM), Current Tool Count, Total Fixed Cost, Current Capacity Loading, Rank, Sugg Max Loading, Sugg Exact Tool Count, Sugg Tool Change, Sugg Whole Tool Count, New Total Fixed Cost, New Capacity Loading, Sim Avg Queue Delay, Pre Avg Queue Delay, Sim Max Queue Delay, Sim Avg Queue Length, Pre Avg Queue Length, Sim Max Queue Length, Sim Avg Unit WIP, Sim Max Unit WIP, Sim Avg Lot WIP, Sim Max Lot WIP, Pre Avg Process Time, Pre Var Process Time, Pre CV Process Time. If DoCap is not enabled, capacity analysis results will be zero. If DoSim is not enabled, simulation results will be zero. TG records are not generated if NoPeriodOutput is enabled. TGEI records contain expense item cost and consumption data for each tool group. A TGEI record is generated at the end of each analysis period for each tool group / expense item pair where the expense item has non-zero consumption for the tool group. A totals record is printed for each tool group with non-zero consumption. A totals record is also printed for each analysis period. TGEI records contain the data fields Rep, Pd, Period Start Date, Period End Date, ToolGroup, Expense Item, UOM, Non Sched Time Cons, Unsched Downtime Cons, Sched Downtime Cons, Engr Time Cons, Standby Time Cons, Productive Time Cons, Units Processed Cons, Total Cons, Total Cost. TGEI records are only generated if DoCap and DoCost are enabled. TGEI records are not generated if NoPeriodOutput is enabled. TGPR records contain tool group capacity by product data. A TGPR record is generated at the end of each analysis period for each tool group / product pair where the product has a non-zero arrival rate for the tool group. A totals record is also printed for each tool group with a non-zero arrival rate. TGPR records contain the data fields Rep, Pd, Period Start Date, Period End Date, Tool Group, Product, Product Type, Percent Work, Cost Alloc Percent, Current Input Rate, Actual Max Input Rate, Capacity Loading. TGPR records are only generated if DoCap is enabled. TGPR records are not generated if NoPeriodOutput is enabled. TRDR records contain travel matrix data sorted by distance rate. A TRDR record is generated at the end of each analysis period for each from-to layout area combination that has a defined distance. TRDR records contain the data fields Rep, Pd, Period Start Date, Period End Date, Lot Distance Rate. TRDR records are only generated if the model contains layout areas and DoCap is enabled. TRDR records are not generated if NoPeriodOutput is enabled. TRMR records contain travel matrix data sorted by move rate. A TRMR record is generated at the end of each analysis period for each from-to layout area combination. Copyright WWK 1995-2009 Factory Explorer 323
14. Reference Topics: The Results Data File TRMR records contain the data fields Rep, Pd, Period Start Date, Period End Date, Lot Move Rate. TRMR records are only generated if the model contains layout areas and DoCap is enabled. TRMR records are not generated if NoPeriodOutput is enabled. USER1 records contain product level data requested by a Factory Explorer user who is researching factory optimization. A USER1 record is generated at the end of each analysis period for each product. A USER1 record contains the data fields Rep, Pd, Period Start Date, Period End Date, Product, Raw Unit Cost, Predicted Factory Unit WIP. USER1 records are only generated if WriteDetail and DoCap are enabled. USER1 records are not generated if NoPeriodOutput is enabled. WARNING records contain warnings generated by Factory Explorer during an analysis run. A WARNING record is generated whenever Factory Explorer wishes to alert you of a situation that could prove confusing or erroneous. WARNING records contain the data fields Rep, Pd, Period Start Date, Period End Date, Warning. WIP records contain lot-level data for lots in the system. A WIP record is generated at the end of each analysis period for each active lot in the system. A WIP record contains the data fields Rep, Pd, Period Start Date, Period End Date, Lot ID, Product, Process, Step, Number of Units, Priority, Start Date, Due Date, Rework Parent Flag, Rework Child Flag, Rework Parent Lot ID, Split Lot Parent Flag, Total Split Lot Children, Remaining Split Lot Children, Split Lot Child Flag, Split Lot Parent Lot ID. WIP records are only generated if WriteDetail and DoSim are enabled. USER1 records are not generated if NoPeriodOutput is enabled.
15. Reference Topics: Understanding NonIntuitive Results
15.1 Introduction
In some complex models, certain output results will appear so strange as to be assumed the result of a software or input data error. Upon closer examination, however, these results sometimes have extremely simple causes, and can be replicated in very small models. This chapter presents a few such non-intuitive results and the models where they arise. Although the models described here are quite simple, all of these results were first seen (and puzzled over) in large factory models.
15.2 Occasional Extreme Spikes in Cycle Time

Consider the cycle time chart shown in Figure 15-1. For most lots, cycle time is quite small. However, an occasional lot has an incredibly large cycle time. Something certainly appears to be wrong. The weird1 model included with Factory Explorer exhibits this behavior. As a test, see if you can figure out what is causing the cycle time spikes before continuing.
15. Reference Topics: Understanding Non-Intuitive Results
Cycle Time by Lot Exit Time

7
5 Cycle Time (Days)
Max_Cycle_Time Avg_Cycle_Time Min_Cycle_Time
0 0 5 10 15 20 25 30 35
Lot Exit Time (Days)
Figure 15-1: Cycle time by lot exit time chart, one month run of weird1 model.
One way to track down the cause of non-intuitive results is to progressively remove elements of the model until the behavior disappears. This method is not foolproof, but it does serve as a quick guide to point you in the right direction. For example, if a model includes setup, rework, and scrap, you can use run-time options to progressively remove these features from the model. In this particular case, try making a model run with DelRework enabled. The behavior shown above disappears. If you further examine the model, you will find that there is a low unit rework probability. The single step in the rework loop uses a batch tool with a large minimum batch size. Since there is a low probability of unit rework, any rework child lot arriving to this batch tool probably contains only a few units. Compounding the behavior is the fact that rework lots arrive infrequently. Thus it takes an incredibly long time to build up enough units to satisfy the minimum batch requirement. If the minimum batch size is set to one, the behavior disappears. Note that this behavior can arise in models where the batch tool in question performs other process steps, and there is a steady arrival of lots to the tool. In that case, the important factor is whether or not rework child lots can be batched with other nonrework lots. If not, then rework lots will still have to wait an incredibly long time to form a batch.
15.3. Unstable Cycle Time in a System with No Overloaded Tools
15.3 Unstable Cycle Time in a System with No Overloaded Tools

Normally, systems that capacity analysis predicts will be stable do not display the cycle time behavior shown in Figure 15-2. The weird2 model included with Factory Explorer exhibits this behavior, however, and the highest capacity loading% of any tool in the system is only 85%.
Cycle Time by Lot Exit Time
2.5
Cycle Time (Days)
1.5 Max_Cycle_Time Avg_Cycle_Time Min_Cycle_Time 1
0.5
0 0 5 10 15 20 25 30 35
Lot Exit Time (Days)
Figure 15-2: Cycle time by lot exit time chart, one month run of weird2 model.
To understand this model's behavior, the first thing to notice is that all the cycle time is coming from Tool1 (see the cycle time contribution chart in Figure 15-3). Tool1 is a batch tool, and it is visited twice during the process. Lots visits Tool1 at Step1, then visit Tool2 at Step2, then return to Tool1 at Step3 for final processing. Lots waiting for Tool1 at Step1 and Step3 cannot be batched together (the batch I.D. is set to the %Step wildcard, causing unique batch I.D.'s to be generated for each process step). In this case, varying the dispatch rule with DispatchRule to a rule like FIFO causes the behavior to disappear. Or, forcing a full batch policy with ForceFull also eliminates the behavior.
15. Reference Topics: Understanding Non-Intuitive Results
Cycle Time Contribution by ToolGroup (Label shows ToolGroup, Capacity Loading%, Operator Delay%, #Tools@Price)
1.2 100% 90% 1 80% Cycle Time Contribution (Days) 70% 0.8 60% 0.6 50% 40% 0.4 30% 20% 0.2 10% 0 Tool1, 85%, 0%, 1@$0 ToolGroup Total Process Time Total Queue Time Cumulative Contribution % Tool2, 64%, 0%, 1@$0 0%
Figure 15-3: Cycle time contribution chart, one month run of weird2 model.
The original dispatch rule in this model is CCOMPSTEP. The behavior seen in this model can arise with a variety of different dispatch rules, however. The key to understanding the behavior is to look at the batch utilization%, found on the ToolGroup Results Worksheet. This value indicates how full the batch tool is, on average, when it processes work. In the baseline model, this figure is approximately 80%. Switching to FIFO causes the value to rise to 85%. Of course, forcing a full batch policy increases the batch utilization% to 100%. In either case, the batch tool is now processing more units in the same amount of time. Evidently, a batch utilization of 80% lowers the processing rate of the tool enough for it to become unstable. The important question, then, is if the tool is unstable, a huge queue must be building up in front of it. Why, then, is it not always running with a full batch? The answer lies with the dispatch rule. CCOMPSTEP favors lots that are nearing the end of the process flow (several other dispatch rules such as PRCRITICAL and PRWORKAPD also exhibit this behavior under some circumstances). Thus, whenever a lot at arrives to Tool1 for Step3 processing, it is processed in the next batch no matter how many Step1 lots are in queue. The only delay the Step3 lot will incur is waiting for the current batch to finish processing. There is a high probability that a Step3 lot will be processed by itself, since the upstream tool processes lots one at a time. The net result is that a huge queue builds up in front of Tool1, but this queue is composed entirely of lots waiting for Step1 processing. If multiple Step3 lots ever queue in front of Tool1, they are run together during the next batch. Although capacity analysis predicts that this system will be stable, the interaction between dispatch rules and 328 Factory Explorer Copyright WWK 1995-2009
15.3. Unstable Cycle Time in a System with No Overloaded Tools batching policy can cause it to exhibit unstable behavior. Switching to a dispatch rule that does not consistently favor lots at one step over another causes the behavior to disappear, as does switching to a full batch policy.
16. Reference Topics: ASCII Model Syntax
16.1 Introduction
For any model, Factory Explorer reads an ASCII file that describes factory data, products, tool groups, operator groups, and process flows. When running non-ASCII models (e.g. Excel, ManSim, and Testbed models), Factory Explorer automatically translates the input model to ASCII format, and then loads the translated model. If the model is named mymodel, the ASCII input model is named mymodel.fx2. The syntax for ASCII models is displayed in Figure 16-1.
16.2 ASCII Model Syntax

Factory Explorer(R) Copyright (c) Wright Williams & Kelly 1995-2009. Duplication without express written permission of the author violates federal law. Unlicensed use is prohibited. For license information, contact Wright Williams & Kelly. Email: support@wwk.com, Web: http://www.wwk.com, Phone: (925) 399-6246, Fax: (925) 396-6174. Checking HASP key for installed modules. Option '-DoCap' enabled - module installed. Option '-DoCost' enabled - module installed. Option '-DoSim' enabled - module installed. Syntax for ASCII model file <model>.fx2. Constants denoted by <...>, distributions by (...). Enclose comments in {}'s: { for example, this is a comment }. For the Factory (Factory information optional): Factory [[FixedCost <Name> <Amount> [DepLifeYears <Depreciation life in years>] [UsefulLifeYears <Useful life in years>]] ...] [[RecurringCostPerYear <Name> <Amount>] ...] [[Schedule <ScheduledTimeHours> <UnScheduledTimeHours/NonScheduledTimeHours> <#Repeats>] ...] [[ProductType <Name>] ...] [[UnitType <Name>] ...] [[SpaceType <Name>] ...]

[[ToolType <Name>] ...] [[StepType <Name>] ...] [[LayoutArea <Name>] ...] [[ExpenseItem <Name> <UnitOfMeasure> <CostPerUnitOfMeasure>] ...] [[TravelMatrix <FromLayoutArea> <ToLayoutArea> [Distance <Distance between layout areas>] [CellName <Route or cell name>]] ...] For each Product: [EffectiveDate <Date>] Product <Name> (Default Lot priority) (#Units/Lot) [UseProcess <Process-Name>] {Defaults to Product Name.} [IsProductType <Name>] [IsUnitType <Name>] [UnitStartRate <Start rate> [UnitStartRateUM <Rate unit of measure>]] {Defaults to UnitsPerHour.} [UnitTputRate <Throughput rate> [UnitTputRateUM <Rate unit of measure>]] {Defaults to UnitsPerHour.} [[Release (#Lots) (Inter-release time) ] ...] [TimeToFirst (Time to first release)] [ConWip <# of Lots>] [DueDate (Due-date offset for arriving Lots)] [LeadTimeFactor <Multiplier for est. cycle time as function of RPT>] [AdjustPcts] {Adjust transform/assembly %'s to demand.} [[Transform <% Units> <Receiving product> <Multiplier>] ...] [[Assembly <% Units> <Assembly product> <Units Required>] ...] [PlateMatchChild <Unscaled cycle time> [CostPerRawUnit <Cost>] [RevenuePerFinishedUnit <Revenue>] For each Lot (Optional): Lot <Lot ID> IsProduct <Product Name> OnProcess <Process Name> AtStep <Step Name> HasUnits <Number of Units> [HasPriority <Priority>] [HasStartDate <Date>] [HasDueDate <Date>] [IsReworkParent] [IsReworkChild ReworkParentLot <Lot ID>] [IsSplitParent TotalSplitChildren <Number> RemainingSplitChildren <Number>] [IsSplitChild SplitParentLot <Lot ID>] For each ToolGroup: [EffectiveDate <Date>] ToolGroup <Name> <Number of Tools>|Inf [IsToolType <Name>
16.2. ASCII Model Syntax

[InLayoutArea <Name> [ProcessesUnitType <Name> [DispatchRule <Rule Name>] [[Interrupt <Name> Clock|Between|Busy|Units|GroupClock (Time/units to/between interrupts) (Time offline) [RepairOpGroup <Name of operator group needed for repair>] [Repair% <% of time operator needed for repair>] [FirstInterrupt (Time/units to first interrupt)] [StaggerFirst] [E10State NonSched|UnschedDown|SchedDown|Engineering]] ...] [Setup% <% of time operator needed for setup (default=100%)] [Load% <% of time operator needed for loading (default=100%)] [Proc% <% of time operator needed for processing (default=100%)] [Unload% <% of time operator needed for unloading (default=100%)] [AvoidSetups|StrictAvoid] [InputBufferSize <Lots>] [OutputBufferSize <Lots>] [[Setup <Group> <Setup I.D.> (Setup Time) [MinQueue <Units>] [MinDelay <Hours>] [MaxQueue <Units>] [MaxDelay <Hours>] [MinToolSetup <#Tools>] [MaxToolsSetup <#Tools>...] [[FromID <I.D.>] ...]] [BatchSizeLots {Default is units}] [[BatchID <I.D. name> <Min batch size> <Max batch size>] ...] [FixedCost <Fixed cost per tool>] [DepLifeYears <Depreciation life in years>] [UsefulLifeYears <Useful life in years>] [RecurringCostPerYear <Per-tool recurring cost per year>] [[ToolSpace <SpaceType> <RequiredPerTool>] ...] [CapacityBuffer <Buffer to subtract from sugg. loading for sugg. tools calc>] [CheckPriority <Priority in case of simultaneous check-request events.>] [LeadTime <Lead time> [LeadTimeUM <Rate unit of measure>]] {Defaults to Months.} [UsesExpenseItem <ExpenseItemName> [ConsPerHourNonSched <Rate>] [ConsPerHourUnschedDown <Rate>] [ConsPerHourSchedDown <Rate>] [ConsPerHourEngineering <Rate>] [ConsPerHourStandBy <Rate>] [ConsPerHourProductive <Rate>] [ConsPerUnitProcessed <Rate>]] [[ToolState <Name> (TimeInState)] ...] [InitialToolState <ToolState>] [[StateTransition <FromState> <ToState> <Weight>] ...] [[StateOpImpact <ToolState> <Operation> <Process Rate Multiplier>] ...] For each Operator Group (Optional): [EffectiveDate <Date>] OpGroup <Name> <Number of Operators> [ProcessesUnitType <Name> [DispatchRule <Rule Name>] [[Interrupt <Name> Clock|Between|Busy|Units|GroupClock (Time/units to/between interrupts) (Time offline)

[FirstInterrupt (Time/units to first interrupt)] [StaggerFirst] [E10State NonSched|UnschedDown|SchedDown|Engineering|Standby]] ...] [WageRatePerHour <Per-operator wage rate per hour>] [OverheadRatePerHour <Per-operator wage rate per hour>] [CapacityBuffer <Buffer to subtract from sugg. loading for sugg. ops calc>] [CheckPriority <Priority in case of simultaneous check-request events.>] For each Process (a set of process steps): Process <Name> [PlateMatchStep <StepName>] [EffectiveDate <Date>] Step <Name> <Name of ToolGroup needed for processing> [UseOpGroup <Name of operator group needed for processing>] [ActiveProduct <Product name> [ActiveProduct ...]] [InactiveProduct <Product name> [InactiveProduct...]] [Operation <Operation ID for step> [IsStepType <Step Type Name> [Load (Load time)] [PerUnit (Per-unit processing time)] [PerLot (Per-Lot processing time)] [PerBatch (Per-batch processing time)] [Unload (Unload time)] [Delay (Per-Lot extra delay time)] {Tool not seized during delay.} [StepTravel (Travel time to next step) [TravelOpGroup <Name of operator group needed for travel>]] [CostPerUnit <Supplies & consumable cost per unit processed>] [OverheadPerUnit <Overhead cost per unit processed>] [MaterialPerUnit <Material cost per unit processed>] [Alt% <If alternative step, % of flow served by step.>] [UseBatchID <I.D. name>] [Scrap <Scrap %> <Lot scrap %> <Unit scrap %>] [Rework <Skip to step> <Rework %> <Lot rework%> <Unit rework%>] [ParamScrap <Scrap %> <Lot scrap %> <Unit scrap %>] [SetupOpGroup <Operator group needed for setup>] [[UseSetup <Groupname> <Setup I.D.> [FinishID <Setup I.D.>] ...] [PrAdjust <Value to add to Lot's priority when finished>] [PrSet <New value for Lot's priority when finished>] [PrDefault] {Resets finished Lot's priority to default.} [NonRandomGoto] [Goto <Process-step-name> <% time chosen> [Goto ...]] [SplitIntoLotSize <New lot size> [MidProcessSplit] [UnsplitStep <Unsplit after step>]] [HoldTool <Free after step>] [HoldToolPct <Hold percent for tool>] [EffectiveDate <Date>] [Step <Name> <ToolGroup>]
16.2. ASCII Model Syntax

Note: Batch/Setup I.D.'s may include %Product, %Process, %Operation, and %Step wildcards. Note: Rate U/M's are 'UnitsPerX', where X = Hour, Day, Week, Month, Quarter, or Year.
Figure 16-1: Syntax for Factory Explorer ASCII models.
17. Reference Topics: Translating Models Between Formats
17.1 Factory Explorer Excel and ASCII Models

Factory Explorer automatically translates Factory Explorer Excel models to ASCII format before performing any analysis. This process assumes that the Excel model has already been stored in intermediate comma-separated-format (CSV) files. When an Excel model is run from the user interface, the user interface automatically generates these intermediate files. The following worksheets are written in CSV format: Factory to modelname.yfa, Products to modelname.ypr, Tools to modelname.ytg, and Operators to modelname.yop. The first process worksheet is written to modelname.y1, the second to modelname.y2, etc. Factory Explorer reads these CSV files (and a process flow list in modelname.ypl) and translates the model to ASCII format, writing out the file modelname.fx2. It then reads the ASCII model. No modeling assumptions are introduced during this translation.
17.2 ManSim(TM) Models

Factory Explorer includes a routine that imports ManSim models to Factory Explorer ASCII format. This routine has been tested for ManSim Version 3.8 models, although it should work for models generated by earlier version of ManSim. The import process does not create an exact 100% translation of the ManSim model, and the translated model will still need to be modified by hand. However, the import routine does speed the conversion process significantly by converting the basic product, tool, and process flow detail to Factory Explorer format. To import a model from ManSim format, choose Run Factory Explorer from the FactoryX pull-down menu. Click the Model button to open the Select a Model dialog. Change the file type to ManSim Models, choose a model, then click OK to return to the Run Factory Explorer dialog. If you wish to import the model without performing any capacity analysis or simulation on the resulting model, clear the Analyze Capacity and Simulate for checkboxes. To create an imported model in Excel format, select the Write final model in Excel format checkbox on the Output Data options dialog (after the run is
17. Reference Topics: Translating Models Between Formats completed, choose Analyze Output from the FactoryX pull-down menu and select Build Excel Model from Final Model). There is a sample ManSim model called msample included with the Factory Explorer distribution. When processing this sample model, the import routine will read the following input files: msample.as: Work Area Shifts msample.eq: Equipment msample.pm: Preventive Maintenance msample.prd: Products msample.rec: Recipes (Process Flows) msample.seq: Step Equipment Definitions msample.sts: Workstation Definitions msample.wst: Workstation Setup When importing a real ManSim model you will have to collect the model files into a single directory from the various subdirectories where they are stored. You will also have to rename the files to match the extensions listed above. The import routine makes the following assumptions: All times in resulting Factory Explorer model are given in hours. Inter-release times are modeled as constant. Tool group time-to-interruption and off-line times are modeled as exponential. First interruption times are modeled as constant. Operator time-to-interruption and off-line times are modeled as constant. Processing times are modeled as constant. Preventive maintenance times are modeled as constant. The first ManSim equipment record is used for Factory Explorer tool group information (all tools within a Factory Explorer tool group must have identical tool parameters). The first ManSim work area shift record is used for Factory Explorer operator group information. Information about operator breaks and product-dependent setups in ManSim model is not converted (although they may be added by hand after the conversion). Conversion program sets Factory Explorer Load% = 100, Process% = 0, Unload% = 100. ManSim has a single random failure type. The figures stored in ManSim input files are MTTF, not MTBF. ManSim MTTF and MTTR are stored in minutes.
17.2. ManSim(TM) Models Conversion program models ManSim yield loss with 'scrap 100 0 100<yield_percent> * 100'. Conversion program models ManSim rework with 'rework <skip-to-step> <rework_percent> * 100 <rework_parts_percent> * 100' At recipe step level, if any of process_time_low/mode/high are != 0, the tool is assumed to be a batch tool. If process_time_low > 0, process_time_high = 0, and process_time_mode = 0, conversion program assumes it's a constant value processing time, otherwise it uses a triangular distribution. At recipe step level, if the step uses a tool where equipment record gives nonzero loadsize-lots, the conversion program will multiply this number by the lot size of the *first* product using this process flow to get maximum batch size. At recipe step level, if the step uses a tool where the equipment record gives nonzero loadsize-parts, the conversion program will simply use this number as the Factory Explorer maximum batch size. PM's are either time-based or units based. If the interval field is non-zero, the conversion program assumes time-based, otherwise records as units-based using the usage field. The time unit for the process delay field given in tool groups file is minutes. If low > 0 and high == 0 and mode == 0, conversion program assumes process_delay = low. Otherwise, it sets process_delay = mode. If the step is perwafer, then it adds perlot with given process delay time. If step is perlot, it adds process delay time to perlot time. If step is perbatch, it adds process delay time to perbatch time. The conversion program ignores distribution information for process delays! Load & unload times are specified at the workstation level, but if they are > 0 for first equipment entry for workstation, they will be overridden by equipment-level values. For perbatch and perlot times, conversion program subtracts (load + unload) before splitting out Factory Explorer times. No equipment-specific setups are present in ManSim input file. The batch I.D. wildcard combination %Process%Step is used at all batch tools (lots cannot be batched together unless they are waiting for the same process step). ManSim subtracts off load & unload times from the total process time, even for perwafer tools. Since Factory Explorer adds load & unload times to the total perwafer time (per-wafer time * # of wafers), the conversion program will not include load & unload times for per-wafer tools. Most datasets will require additional modification. The following tips and suggestions were provided by Jennifer Robinson. Changes to ManSim Files: Clean up your .wset (Sequence dependent setups) file. Delete any redundant entries, and eliminate extra characters. Some ManSim files have extra characters in front of some setup I.D.'s. Factory Explorer does check for redundant setups, or setups
17. Reference Topics: Translating Models Between Formats specified with the from I.D. and to I.D.'s the same. However, it is easier to delete them here all at once. Make sure that all maximum batch sizes are specified in wafers, instead of lots (e.g. sinks might have a 2 lot load size, use 48 wafers). The conversion program sometimes does flaky things otherwise, and it's an easy enough fix. Changes to Factory Explorer Files: Either increase sink quantities by multiplying by the maximum number of loads allowed in each sink at one time, or break out the sink baths into separate steps. Add StaggerFirst statements (in the modelname.fx2 file) for all tools with constant downtime events (PMs). This makes Factory Explorer stagger the events, as ManSim does, rather than taking all the tools down at once. Check the dispatch rules on batch tools. The conversion program defaults to a FIFO rule for all tools, with a greedy policy on batch tools. Add the additional delay to multi-sequence tools (e.g. linked steppers). For example, to add a 10 minute delay, where times are expressed in hours, add a line saying Delay c(0.16667) at all steps using the tool. Also be sure the multi-sequence tools do not have a batch I.D. specified in the modelname.fx2 file (sometimes models get converted this way, and Factory Explorer gives an error). Check the throughput of tool groups that have different processing times for individual tools within the group. Factory Explorer uses the throughput of the first tool. It may be better to use the highest throughput tool, or an average. If using operators, you will need to manually put in the load and unload times for all steps with per unit times. They need to be subtracted from the total processing time at the step (which will vary according to the lot size, particularly where there is significant yield loss). If modeling operators, you will need to check that the number of operators generated by the conversion program is correct -- it is simply using the number from the first shift record for each operator group. You will also need to add any operator breaks, since the conversion program does not generate these. Add product setups if they are being used in model. Make a pair of ManSim and Factory Explorer runs at the same start rate, and carefully go through the results. In particular, check the number of visits to each workstation by each product. Engineering steps in the ManSim model, which have zero processing time, still show up in the Recipe file, and hence get translated to the Factory Explorer model. The Factory Explorer model has no way of knowing that the processing times should be zero, and will record a larger number of visits. When such steps are found, delete them from the Factory Explorer process flow.
17.3. Testbed Models
17.3 Testbed Models

17.3.1 Background There currently exist a wide variety of commercial, corporate, and university developed simulation and analytical tools for the analysis of semiconductor wafer fabs. There have also been a number of strategies and rules developed to control the flow of product in a wafer fab. However, it has been difficult for Sematech and its member companies, as well as for suppliers and researchers, to evaluate and compare these tools and strategies. One of the major problems in such comparisons has been the lack of representative data. The purpose of the semiconductor Testbed is to provide planners, researchers and software suppliers with actual data and models that can be used to benchmark their control strategies and software. The data set format was developed by Gerry Feigin (IBM), John Fowler (Arizona State University), and Robert Leachman (University of California, Berkeley). The factory datasets are available at: http://www.fulton.asu.edu/~ie/research/labs/masm/factory_datasets.php If you have trouble obtaining the datasets from this location, please contact technical support. The Testbed includes actual manufacturing data from several wafer fabrication facilities, organized into a standard format. The data sets do not include real product names, company names or other nomenclature that could serve to identify the source of the data. The data sets are as non-sensitive as possible, so that they may be widely circulated. The goal in development of the fab level data sets was to include the minimum information necessary to model a factory. In support of this goal, the data sets were kept as simple as possible, specifically by including data but not modeling assumptions. For example, mean times between failures are provided, but not their distributions. Process holds, engineering holds, and send aheads are also not included. The resulting data is given in six ASCII flat files, containing: product process steps and processing times; rework process steps; equipment availability; operator availability; product starts; and a comments file. A more detailed description of the fab level dataset structure is included with the datasets. Currently, the Testbed contains 8 factory-level datasets. Some general information about the datasets is listed in Table 17-1. More information is included in the comments file provided with each dataset. The comments files all have the ending .cf (e.g. set1.cf). The comments files each include a revision number for the dataset, and a list of changes made since the last revision was published.
17. Reference Topics: Translating Models Between Formats

Table 17-1: Information about the Semiconductor Testbed Datasets
Dataset Set1 Set2 Set3 Set4 Set5 Set6 Set7 MiniFab
Factory Type Non-volatile memory ASIC and Memory Memory, various types Microprocessors ASIC ASIC R-D Wafer Wafers
Products 2 7 11 7 177 9 1 3
Wafers Starts per Month 16,000 10,000 21,400 3,400 10,000 5,500 408 9,000
17.3.2 Questions on the Testbed Datasets For questions regarding the testbed datasets, contact John Fowler (john.fowler@asu.edu). It is requested that anyone who downloads the testbed datasets send an email to John Fowler with your name, address, and purpose for using the testbed. This will allow Dr. Fowler to notify you of any changes to the testbed (e.g. when new datasets are released). It will also be helpful, in general, for Dr. Fowler to know how many people are using the testbed and for what sorts of purposes. Also, if you have a data set that you would like to donate, please contact John Fowler.
17.3.3 Importing and Exporting Models Stored in Testbed Format Conversion routines are included with Factory Explorer to import from and export to the Testbed format. To import a model from the Testbed format, choose Run Factory Explorer from the FactoryX pull-down menu. Click the Model button to open the Select a Model dialog. Change the file type to Testbed Models, choose a model, then click OK to return to the Run Factory Explorer dialog. If you wish to import the model without performing any capacity analysis or simulation on the resulting model, clear the Analyze Capacity and Simulate for checkboxes. To create an imported model in Excel format, select the Write final model in Excel format checkbox on the Output Data options dialog (after the run is completed, choose Analyze Output from the FactoryX pull-down menu and select Build Excel Model from Final Model). Suppose the Testbed model you are converting is set3. The conversion routine will read the following Testbed files: set3.vr: Volume and Release set3.ts: Toolset set3.os: Operator Groups set3.pr: Product Routing set3.rw: Rework Routing The conversion routine makes the following assumptions: All times in the converted Factory Explorer model given in hours. Inter-release times modeled as constant.
17.3. Testbed Models Tool group time-to-interruption and off-line times modeled as exponential. Operator time-to-interruption and off-line times modeled as constant. Processing times modeled as constant. The conversion program automatically specifies the AvoidSetups statement for all tool groups with setup. Some datasets will require additional modification. For more information on the necessary modifications, see the comments file associated with each dataset (e.g. set1.cf). Testbed dataset 5 contains two separate volume / release files (set5.vr and set5a.vr). Set5.vr contains definitions for 177 products. Set5a.vr aggregates many similar products, producing a model with many fewer products. This simplified model has the same aggregate release rate, but is generally easier to work with due to the smaller number of products. If you are unable to obtain the Testbed datasets via ftp, contact technical support to receive copies. To export a Factory Explorer model to Testbed format, select the Write final model in Testbed format checkbox on the Output Data options dialog. Not all Factory Explorer model data can be written to the Testbed format check the comments file for detailed translation notes. Since the Testbed format is a description of fields rather than a set of data, it can be used for models other than the Sematech Testbed datasets. As the Testbed format contains a large subset of the data needed for a factory model, it provides a useful means of transferring models between different pieces of software.
18. Reference Topics: Customizing Factory Explorer
18.1 Introduction
In order to give advanced users the highest degree of flexibility possible, Factory Explorer supports customization via a set of user-supplied code and dispatch rules. Customization is only supported on Windows platforms. User code is stored in the dynamic link library (DLL) user.dll. The user.dll installed with Factory Explorer includes pre-compiled sample routines. Advanced users may customize the source code for user.dll (also included with Factory Explorer) to create their own user.dll file. This chapter describes the interface between Factory Explorer and user.dll and the mechanics of customization. Section 18.2 documents the routines in user.dll that Factory Explorer calls. By placing custom code inside these routines, users can modify the operation of Factory Explorer. Section 18.3 documents the routines in Factory Explorer that are callable from user.dll. With these routines, custom code can access built-in Factory Explorer data structures and procedures. Section 18.4 describes the process of building your own user.dll.
18.2 Routines in User.DLL Called by Factory Explorer

Factory Explorer requires that a number of pre-defined interface routines be included in user.dll. These routines are called by Factory Explorer and are used to communicate with user-supplied code. These interface routines are documented in Table 18-1.
Table 18-1: Routines in User.DLL Called by Factory Explorer
Routine void User_InitBeforeLoad(void) short User_GetRuleActiveFlag(int UserRuleNumber) char *User_GetRuleDescription(int
Called by Factory Explorer Before the model is loaded. Before the model is loaded, for each usersupplied dispatch rule. Before the model is loaded, for each user-
18. Reference Topics: Customizing Factory Explorer Routine UserRuleNumber) short User_GetRuleStaticFlag(int UserRuleNumber) short User_GetRulePriorityFlag(int UserRuleNumber) void User_InitAfterLoad(void) void User_InitBeforeRun(void) void User_InitBeforeRep(void) void User_InitBeforePeriod(void) double User_Rule1StaticCompare(int LotTagA, int LotTagB) Called by Factory Explorer supplied dispatch rule. Before the model is loaded, for each usersupplied dispatch rule. Before the model is loaded, for each usersupplied dispatch rule. After the model is loaded. Before the analysis run begins. Before each analysis replication. Before each analysis period. During the simulation, whenever two lots waiting in the same queue need to be statically compared on the basis of usersupplied dispatch rule #1. Similar routines are defined for rules #2, #3, #4, and #5. During the simulation, whenever two lots waiting in the same queue need to be dynamically compared on the basis of usersupplied dispatch rule #1. Similar routines are defined for rules #2, #3, #4, and #5. During the simulation, after choosing the lot(s) to be processed, when it is time to pick a tool. Similar routines are defined for rules #2, #3, #4, and #5. If UserInt interval is enabled, this routine is called every interval hours during the simulation, starting at time zero. If UserStart startingtime is enabled, the first call occurs at time startingtime (hours). Every time a lot arrives at a tool group. Every time a lot is selected for processing at a tool group. In simulation, at clear-statistics time. After each analysis period. After all object CalcAfterPeriod() routines completed. After each analysis replication. After all object CalcAfterRep() routines completed. After analysis run is completed. After all object CalcAfterRun() routines completed. After the entire run is completed. Accepts output from the Factory Explorer
double User_Rule1DynamicCompare(int LotTagA, int LotTagB)
int User_Rule1PickTool(int ToolGroup, int LotTag)
void User_CalcDuringSim(void)
void User_CalcOnLotArrival(int LotTag, int ToolGroup) void User_CalcOnLotSelection(int LotTag, int ToolGroup) void User_ClearStats(void) void User_CalcAfterPeriod(void) void User_GenPeriodOutputs(void) void User_CalcAfterRep(void) void User_GenRepOutputs(void) void User_CalcAfterRun(void) void User_GenRunOutputs(void) void User_Cleanup(void) void User_PrintEventDescriptions
18.3. Routines in Factory Explorer Callable from User.DLL Routine (char *EventName) voidUser_ProcessTracedEvents(int event_number,intToolGroup,int tool,int OpGroup,int oper,int LotTag,int product) Called by Factory Explorer routine Event_GetDescriptions After a traced event coours. Events must be turned on using the Factory Explorer routine Event_SetTraceOn(char *EventName)
18.3 Routines in Factory Explorer Callable from User.DLL

The user-supplied custom code in user.dll has access to a variety of Factory Explorer routines. These routines are documented in Table 18-2.
Table 18-2: Routines in Factory Explorer Callable from User.DLL.
Routine void myexit(int type)
void myprintf(char *fmt, )
double *makevector(int rows) void freevector(double *b, int rows) int *makeintvector(int rows) void freeintvector(int *b, int rows) double **makematrix(int rows, int cols)
void freematrix(double **A, int rows, int cols) short RunTimeOptions_GetUserParmEnabledFlag(i nt Parameter) Char *RunTimeOptions_GetUserParmString(int Parameter) Short DispatchRule_GetUserRuleInUseFlag(int UserRuleNumber)
Description Custom version of exit() that writes type to exit code file fx.xcd and displays closer message. Use myexit() to exit from Factory Explorer if an unrecoverable error exists. Custom version of printf() that sends output to Factory Explorer console and to console output file fx.con. Allocate memory for a double-precision vector, accessed using 1rows. Free memory previously allocated using makevector. Allocate memory for an integer vector, accessed using 1rows. Free memory previously allocated using makeintvector. Allocate memory for a double-precision matrix, accessed using 1 rows and 1 cols. Free memory previously allocated using makematrix. Returns TRUE if UserParmX is enabled, where X is identified by Parameter, FALSE otherwise. Returns the parameter string specified by UserParmX, where X is identified by Parameter. If UserParmX is not enabled, returns NULL. Returns TRUE if the user-supplied dispatch rule identified by UserRuleNumber is used in model.
18. Reference Topics: Customizing Factory Explorer Routine int Products_GetNumberOfProducts(void) char *Product_GetName(int Product) int Products_LookupName(char *ProductName) int Product_GetStepBatchID(int Product, int Step) Description Returns the number of products in the model. Returns the name of a product. Looks up a product by its name and returns product number. If product is not found, returns NA. Returns the batch I.D. for a particular step within a product's process flow. Due to wildcards, the batch I.D. of a step can vary depending on the product. Returns NA if step does not use a batch tool. Returns the number of setup records for a particular step within a product's process flow. Returns the setup group for a setup record for a particular step within a product's process flow. Returns the setup I.D. for a setup record for a particular step within a product's process flow. Returns the finish I.D. (or NA if no finish I.D. specified) for a setup record for a particular step within a product's process flow. Returns the number of process flows in the model. Returns the name of a process. Looks up a process flow by its name and returns process number. If process is not found, returns NA. Returns the tool group number used by a process step. Returns the tool group number used by a product / process step. Return the expected tool process time for a product at a particular process step. Returns the number of tool groups in the model. Returns the name of a tool group. Looks up a tool group by its name and returns tool group number. If tool group is not found, returns NA. Returns total number of tools in a tool
int Product_GetStepNumberOfSetupRecords(int Product, int Step) int Product_GetStepSetupGroup(int Product, int Step, int SetupRecord) int Product_GetStepSetupID(int Product, int Step, int SetupRecord) int Product_GetStepSetupFinishID(int Product, int Step, int SetupRecord)
int PFlows_GetNumberOfProcesses(void) char *PFlow_GetName(int Process) int PFlows_LookupProcessName(char *ProcessName) int PFlow_ProcessStepGetToolGroup(int Process, int Step) int PFlow_ProductStepGetToolGroup(int Product, int Step) double PFlow_ComputeStepTooltime(int product, int step, double size) int ToolGroups_GetNumberOfToolGroups(void) char *ToolGroup_GetName(int ToolGroup) int ToolGroups_LookupName(char *ToolGroupName) int ToolGroup_GetTotalTools(int ToolGroup)
18.3. Routines in Factory Explorer Callable from User.DLL Description group. If infinite server tool group, returns INF_SERVER constant defined in user.h. int ToolGroup_GetNumberOfSetupGroups(int Returns the current number of setup ToolGroup) groups defined for a tool group. void ToolGroup_GetToolStatusList(int Returns a list of tool status values (status ToolGroup, int *ToolStatusList, int values enumerated in user.h). Cannot be LastListRecord) used for infinite server tool groups. Status values returned in ToolStatusList[1], , ToolStatusList[TotalTools]. int ToolGroup_GetQueueLengthLots(int Returns the number of lots in queue. ToolGroup) void ToolGroup_GetQueueLotList(int Returns a list of lots in queue. ToolGroup, int *LotTagList, int LotTagList must be an array of size LastListRecord) LastListRecord, and LastListRecord must be greater than or equal to the number of lots in queue. Lot tags returned in LotTagList[1], , LotTagList[QueueLengthLots]. double Return total mean setup time required ToolGroup_CalcTotalMeanSetupTime(int for a lot with specified product and step Product, int Step, int Tool) at a given tool. double Return total mean setup time required to ToolGroup_CalcGroupMeanSetupTime(int change from a given product and step to ToolGroup, int SetupGroup, int FromID, int a different product and step. ToID) int ToolGroup_PickToolFromFree(int ToolGroup) int Lot_GetProduct(int LotTag) int Lot_GetProcess(int LotTag) int Lot_GetStep(int LotTag) double Lot_GetTimeEnteredToolGroup(int LotTag) double Lot_GetTimeDue(int LotTag) double Lot_GetCurrentPriority(int LotTag) void Lot_SetCurrentPriority(int LotTag, double NewPriority) int Lot_GetNumberWithinSystem(int LotTag) Return a tool at random from those that are free. Returns product number for a lot. Returns process number for a lot. Returns step number for a lot. Returns the time a lot entered the queue at its current tool group. Returns the time a lot is due to finish processing on current process flow. Returns a lot's current priority. Sets a lot's current priority. Returns a lot's unique, sequentially assigned index number. Normally used in dispatch code to break ties. Returns a lot's current size (number of units in the lot). Routine
int Lot_GetCurrentSize(int LotTag)
18. Reference Topics: Customizing Factory Explorer Routine int Lot_GetOriginalSize(int LotTag) Description Returns a lot's original size (number of units in the lot when the lot started the process flow). Pauses FX to allow modification of unser function input files Returns a list of user traceable events for output in user function User_PrintEventDescriptions Turns on a specific event for user tracing in user function User_ProcessTracedEvents Returns a user traceable event name Returns a user traceable event number
void Misc_FXAboutShow(void) void Event_GetDescriptions(void)
void Event_SetTraceOn(char *EventName)
char *Event_GetName(int event_number) int Event_LookupName(char *EventName)
18.4 Creating Your Own User.DLL

Before you begin, first make a backup copy of the existing user.dll file included with Factory Explorer. You may need to restore this file if the copy you create causes problems. Included with Factory Explorer is a starter source code file user.c. The file user.h contains definitions for Factory Explorer routines that may be called from user.c. The file userexp.h contains definitions for routines in user.c that are exported for access by Factory Explorer. The Microsoft Visual C/C++ (MSVC) 5.0 developer studio workspace and project files user.dsw and user.dsp are also included. To customize Factory Explorer, modify only the code in user.c. For information on adding custom dispatch rules, see the comments in user.c. For general information on dispatch rules, see Section 4.6 of the manual. You should not modify user.h or userexp.h. Only technical support can revise the information in these files. In MSVC, open the workspace file user.dsw and recompile. Note that this workspace refers to the library file fx.lib, which is also included with Factory Explorer. Copy the resulting user.dll file into the Factory Explorer installation directory. You should overwrite the user.dll file that comes with Factory Explorer with your new user.dll. When you next run Factory Explorer, your custom code will be in effect. To back out the changes you have made, simply copy the original user.dll included with Factory Explorer back into the Factory Explorer installation directory.
19. Reference Topics: Estimating Cycle-Time Constrained Capacity
19.1 Introduction
In this chapter we describe three possible methods for estimating cycle-time constrained capacity. Each of these methods were investigated by the author while participating in the Sematech Measurement and Improvement of Manufacturing Capacity (MIMAC) project. For more information on the results of the MIMAC project, cycle-time constrained capacity, and the use of design of experiments in wafer fab capacity planning, see Fowler and Robinson (1995), or Chance et al. (1996). Simply put, cycle time constrained capacity is the maximum rate at which a system can complete work under the constraint that average cycle time does not exceed a pre-specified target. For a precise definition, denote the throughput rate of a system by , and the expected cycle time resulting from this throughput rate by C(). It may seem odd to consider the throughput rate of a system as an independent variable (one that can be directly controlled). However, the throughput rate is directly related to the release rate via a multiplication by the line yield Y, = Y. Thus, either a release rate or a throughput rate may be specified. In any system with limited capacity to perform work, there will be some maximum system throughput rate the system can achieve. Systems with infinite throughput capacity do not often arise in practice, so we have limited ourselves to studying finite capacity systems. We have defined cycle time constrained capacity as the maximum throughput rate * that can be achieved while limiting the mean cycle time to fall below some target value C*, * = max{: C() C*}. In graphical terms, this is equivalent to plotting cycle time C() versus throughput , and drawing a horizontal line across the graph at height C*. At the point where this horizontal line intersects the curve C(), a vertical line is then dropped to the x-axis. The point on
19. Reference Topics: Estimating Cycle-Time Constrained Capacity the x-axis where this vertical line falls is the cycle time constrained capacity *. See Figure 19-1 for an example.
Figure 19-1: Graph of average cycle time (normalized by raw process time) versus input rate for the M/M/1 queue. This example shows that system capacity is reduced to 80% of maximum when cycle time is constrained to 5 times the raw process time. The solid horizontal line represents the cycle time constraint. The x-coordinate of the point where this constraint line intersects the cycle time curve is the cycle-time constrained capacity (shown graphically in this figure by the vertical line dropped from the intersection to the x-axis).
For systems with multiple products, the total system throughput can still be treated as an independent variable, as long as a constant product mix is maintained. Denote the number of product lines by n, the throughput of product j as j, the release rate of product j as j, and the line yield of product j as Yj. This leads to the relationship = j = jYj. In order to obtain meaningful results, it is necessary to hold either the input product mix or the output product mix constant. Although holding input mix constant is easier in practice, maintaining the output mix is probably more realistic. Under the constraint that the output product mix does not vary when changing throughput rate , it is possible to solve for the appropriate release rates j when given a throughput value . To see this fact, define the output product mix P as a vector, each entry in the vector pj being the ratio of the output rate for product j to the total output rate, pj = j / . Holding the output mix constant means the value pj does not change as the throughput rate is varied. The following discussion shows that specifying a throughput rate determines the value of j for all products. Suppose a new throughput rate ' is given. Since the output mixture is constant, it is possible to solve for the new throughput rates of individual products j' j' = pj '. Once ' is known, it is possible to solve for j', j' = j' / Yj. Thus in a system with multiple products and a fixed product mix, the total system throughput may be treated as an independent variable. It is often convenient to define 352 Factory Explorer Copyright WWK 1995-2009
19.2. A Brute-Force Method the overall cycle time C() as the average of all product cycle times, weighted by throughput, and normalized by the weighted average raw process time. For example, define Rj as the raw process time for product j, and defined the weighted average raw process time R = (j Rj) / j. Now define the weighted (and normalized) cycle time as follows: C() = j (Cycle time for product j) / R. When the cycle time has been normalized by the raw process time, it is often referred to in terms of (Cycle time) X RPT, or simply (Cycle time)X. For example, if the weighted, normalized cycle time turns out to be 4, the model is said to be running at 4 times RPT, or 4X. Constraining the weighted, normalized cycle time to fall below 4 is said to be a 4X constraint.
19.2 A Brute-Force Method

This method for estimating cycle time constrained capacities is based on two intuitions about manufacturing cycle times. The first is that for any manufacturing system that is not completely deterministic, cycle times will grow larger and larger as the system throughput approaches capacity. Expressed symbolically, C() as , where is the system throughput rate, and is the maximum system throughput. The second intuition is that small changes in throughput rate will usually result in small changes in cycle time C(), and that the function C() is relatively smooth. Suppose 0 and 1 are similar, i.e. the difference 1 - 0 is small. If our intuition is correct, it is probably not too great an error to approximate the true cycle time function C() for between 0 and 1 by a straight line connecting the points C(0) and C(1). Note that as the difference 1 - 0 decreases, the error in this linear approximation also decreases. Continuing, choose a third throughput rate 2, that exceeds 1 by a small amount, and approximate the true function C() for between 1 and 2 by a straight line connecting C(1) and C(2). Continuing this process, the result is a piece-wise linear approximation to the true function. Given a target cycle time C*, the cycle time constrained capacity * may be approximated by first searching for a pair of throughput rates j and j+1 with C(j) C* C(j+1). Then, assuming a straight line approximation, linear interpolation can be used to find *. If the points j are evenly spaced, there are several Factory Explorer options that ease the generation of simulation estimates C(j) for C(j). For example, the following command runs 10 replications of the mm1 model, each replication ending when 10,000 time units have passed.
% fx mm1 -DoCap -DoSim 10000 -Reps 10 -ReleasePct 50 -AddPct 5
The first replication is run at 50% of capacity, the second at 55%, etc., up to the final replication that is run at 95% of capacity. Weighted average cycle time across all products (only one in this case) is normalized by the weighted average raw process time and written to the results data file mm1.rdf in a format that can easily be imported into a Copyright WWK 1995-2009 Factory Explorer 353
19. Reference Topics: Estimating Cycle-Time Constrained Capacity spreadsheet and graphed. A sample graph is shown in Figure 19-1. In this example, the 5X cycle-time constrained capacity is approximately 80% of the maximum system capacity. Two complications can arise while using this method. First, suppose simulation estimates C(0), ..., C(n) are available, but C(n) < C*. Graphically, this corresponds to the upper right portion of the curve not reaching high enough to hit the cycle time constraint. Finding a pair of simulation estimates bounding C* will not be possible. In that case, we have found that it works well to approximate the right-hand tail of C() by the function T() = 0 + 1 ( - ) -1. Choose 0 and 1 so that T() matches the right end of the estimated cycle time function, and its first derivative T'() matches the slope of the right-most linear segment. T(n) = C(n), T'(n) = (C(n) - C(n-1)) / (n - n-1). Once the function T() has been derived, it can be used to solve for *, where * satisfies T(*) = C*. A second complication arises if the true cycle time function C() is not monotonic, i.e. it does not always increase as increases. This situation can occur if there are minimum batch sizes of greater than one unit specified in the system (see Figure 19-2 for an example of this behavior on one of the Sematech Testbed Datasets discussed in Section 17.3 of the user manual). In this case, there may be a region of relatively low throughput rates where the cycle time actually decreases as the throughput rate increases, since less time is spent waiting to form batches. If the capacity estimation code specifically searches for pairs of bounding points with C(j) C(j+1), and the throughput rates are listed in increasing order, 0 < ... < n , then there is no risk that the algorithm will find one of the artificially low capacities on the left-hand side of the U-shaped cycle time curve. Also, when a U-shaped cycle time curve occurs, it may happen that no pair of simulation estimates bound the target cycle time C* (C* may fall below the bottom of the curve). In that case, the algorithm should notify the user of the situation; when this happened on one of our experiments, we simply chose a different target cycle time that was feasible for all design points. Note that this complication is not specific to the bruteforce method it is a problem that will arise with all of the methods.
19.2. A Brute-Force Method
Sematech Testbed Data ASIC 1

5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 55% 55% 65% 60% 75% 65% 70% 75% 80% 85% 90% 105% 95% 100% % of Max. Input Rate 85% 95% Full Batches #REF! Full Batches Greedy Policy
Sematech Testbed Dataset ASIC1
% of Max. Input Rate
Figure 19-2: Example showing a non-monotonic cycle time function when a full-batches policy is enforced. Delaying batches until a full-load is ready results in significant delays at lightly loaded batch tools for low traffic intensities. The model in this is example is one of the Sematech Testbed datasets discussed in Section 17.3.
We believe that the benefits of this brute force method outweigh the errors caused by the piece-wise linear approximation. In particular, the method is easy to program, is easy to understand, and performs very reliably. In our experience, it works best to simulate between 7 and 10 different throughput rates j , with a concentration of points between 75% and 95% of capacity . At lower capacities the points do not need to be as close together, since the cycle time curve will probably be relatively flat. As part of its capacity analysis, Factory Explorer calculates an approximate value for . We chose to make runs at 35%, 45%, 55%, 65%, 75%, 80%, 85%, 90%, and 95% of capacity. Another advantage of the brute force method is that all of these simulation runs can be made in parallel when a network of machines is available. Finally, if, after the simulation estimates have been generated, one wishes to change the target cycle time C* and search for a new cycle-time constrained capacity *, it is not necessary to make any more simulation runs simply proceed with the search process outlined above, using the new C* . If the simulation estimates have a high variance, then the resulting estimated cycle time curve will not be a good approximation to the true curve. For our experiments, very long simulation runs were made in order to decrease the variance of the simulation estimates. To check the effect of variability, the entire experimental design was repeated with different random number seeds. The outputs of the analysis were quite similar, indicating that the effect of variability had been successfully minimized.
19. Reference Topics: Estimating Cycle-Time Constrained Capacity
19.3 A Stochastic Approximation Method

To examine the effectiveness of stochastic approximation when searching for cycle-time constrained capacity, we tested a variety of search algorithms. The best-performing such algorithm we tested was the following variant of one given in Chen and Schmeiser (1994): 1. Run the simulation for one replication with the current throughput rate . 2. Compute a confidence interval for the average cycle time. If the confidence interval includes the target cycle time, and has a small enough relative width, the algorithm terminates. If the interval contains the target, but is not small enough, the run length is multiplied by a user-specified factor, and the replication continues (when it finishes, the algorithm returns to this step). 3. Otherwise, the confidence interval just computed does not contain the target cycle time. If the average is less than the target, the throughput is increased. If the average is greater than the target, the throughput is decreased. 4. If the number of replications does not exceed a user-specified limit, the algorithm returns to the first step. Otherwise, the algorithm terminates unsuccessfully. There are several drawbacks associated with using a stochastic approximation technique to estimate cycle-time constrained capacity. First, it requires a large amount of simulation to arrive at a single cycle-time constrained capacity estimate. Part of this problem seems to be caused by initialization bias, which is an extra factor not present in the original problem considered by Chen and Schmeiser. Second, stochastic approximation is quite general; it does not require any prior knowledge concerning the shape of the cycle time curve. This generality means that the algorithm is working at a relative disadvantage when compared to the other methods, which use this prior information. Third, all of the simulation runs required by the stochastic approximation must be done in sequence; it is not possible to take advantage of networked machines to speed the computation. Finally, the result of the algorithm is an estimate for a single cycle-time constrained capacity. If the target cycle time C* is varied, the entire process must be repeated.
19.4 A Curve-Fitting Method

At first glance, it seems likely that some sort of smooth function, either a quadratic or low-order polynomial, could be fitted to the expected cycle time function C(). That is, we would run the simulation for several arrival rates 1, ..., n, then use linear regression to fit a simple model such as C() = 0 + 1 ( - )-p + 2 ( - )-q + 3 ( - )-r, where p, q, and r are chosen to give the right general shape for the curve. For our experiments, we used values of p = 1, q = 1.5, and q = 2. Regression analysis was used to find estimates of 0 through 3. Once these estimates were calculated, we used a simple root-finding approach to calculate *, since it satisfies the relation
19.5. Throughput Rate vs. Input Rate C(*) = C*. After much experimentation with the Sematech Testbed datasets (see Section 17.3), we found this technique to work reasonably well, but not well enough to be trusted. In many situations, the resulting curve would fit well at the simulated points, but would behave strangely at the endpoints. In particular, the regression estimate of 3 would often be negative, causing the fitted curve to become negative as , which does not match reality. When this situation occurred, it was usually possible to tweak the parameters p, q, and r slightly and remove the behavior. However, when running a large designed experiment with cycle-time constrained capacity as the performance measure, it was simply not possible to examine every design point to make sure that the algorithm was behaving as needed. For those interested in pursuing this curve-fitting approach further, there should be other (albeit more complicated) estimation techniques that would guarantee a positive sign for 3's estimate.
19.5 Throughput Rate vs. Input Rate

We have chosen in our experiments to concentrate on system throughput rates rather than release rates. This choice was made to avoid certain anti-intuitive situations that can arise when comparing different design points on the basis of maximum possible input rate. For example, it seems reasonable to state that a system with a higher maximum input rate is better than one with a lower maximum input rate. But by introducing scrap into a system we can actually increase the maximum input rate. In our judgment, the introduction of scrap should not result in a "better" system; comparison on the basis of maximum throughput avoids this anti-intuitive result. Caution is also in order when comparing design points with different scrap settings for a multi-product system. Generally, it is recommended that the output mixture should be held constant, not the input mixture. Eliminating scrap while holding the input mixture constant can decrease maximum throughput, a somewhat anti-intuitive result. In a real system, system throughput is probably chosen to meet external demand, so it seems reasonable to hold the output mixture constant when modifying the level of scrap.
20. Reference Topics: Capacity Analysis

All models are wrong, but some are useful -- George Box.
20.1 Introduction
Factory Explorer performs steady-state capacity analysis on a model if DoCap is enabled. From this analysis, it generates a variety of output reports. These reports may not all be applicable to your situation, especially if you are performing finite-horizon analysis. In this chapter we briefly outline the methods used in Factory Explorer's capacity analysis module. Several of these methods were implemented from the description in Connors, Feigin, and Yao (1994), although Factory Explorer uses a direct method to solve the traffic equations, where those authors use an iterative method to solve for lot size distributions at each step. For a path-breaking paper in this area, see Whitt (1983a, 1983b).
20.2 Assumptions
Factory Explorer makes several assumptions in performing steady-state analysis, the first of which is that steady-state analysis can provide meaningful performance measures. We will not argue the point here; for arguments for and against steady-state analysis, see a general text such as Bratley, Fox, and Schrage (1987). The second assumption is that scrap inside rework loops is negligible. To solve the traffic equations in a reasonable amount of time, it is very helpful to assume that the distribution of lot sizes entering a rework step is the same as that leaving, i.e. the number of units scrapped while rework children travel through rework loops is negligible.
20.3 Traffic Analysis

The first step in Factory Explorer's capacity analysis is the solution of the traffic equations. These equations describe the flow of lots between steps in the system. Factory Explorer performs the traffic analysis for each product separately, then merges the results to calculate the flow of lots into each tool group. For the following, assume a single product. Let J be the maximum number of units in a lot, and S the number of process steps. For each step s, and each lot size j, define Copyright WWK 1995-2009 Factory Explorer 359
20. Reference Topics: Capacity Analysis n(s,j) = Input rate of non-rework lots of size j into step s. r(s,j) = Input rate of rework lots of size j into step s. t(s,j) = n(s,j) + r(s,j). The variables n(s,j) and r(s,j) describe all flow circulating within the system. We need the following additional definition, (s,j) = Release rate of new lots of size j into step s. For models without individual lots, all (s,j) are zero except (1,J), which is set to the flow rate of new lots into the system. For models with individual lots, there may be other non-zero (s,j), to represent the flow of individual lots into the system at points other than the first process step. From our assumption that scrap inside rework loops is negligible, we can formulate two sets of traffic equations: one for non-rework lots, and one for rework lots. We will first discuss the non-rework problem. To formulate the traffic equations, we need to define the transition probabilities, pn(s',j',s,j) = Probability that a non-rework lot of size j' leaves step s' and becomes size j at step s. The traffic equation for each step s and lot size j states that the flow into the step and lot size is the result of any external release and flow from other steps: n(s,j) = (s,j) + n(s',j') pn(s',j',s,j). From the process flow information it is not too difficult to compute the various values of pn required for this system. However, for many semiconductor simulations, the number of process steps S and the lot size J can be quite large, say on the order of 500 and 25, so solving the traffic equations directly results in a linear system with 12,500 variables. After experimenting with the iterative methods described in Press et. al. (1992), we found these large linear systems not at all easy to solve. However, it is possible to decompose the problem into J sub-problems each having S variables, which is quite a bit faster. To do so, we make the observation that lots only become smaller due to scrap, and never become larger. Thus, we can solve the traffic equations for j = J, resulting in the traffic flows n(s,J). With this information, we can then solve the traffic equations for j = J-1, to find n(s,J-1), and so on down to j = 1. For each of these J sub-problems, after solving for the non-rework flows (s,j), we can then formulate and solve the corresponding problem for rework flows (defining and computing the transition probabilities pr in a corresponding fashion). However, in the case of nested rework flows, the method used is a bit more complicated, see Section 20.4 for the details. The method is also modified slightly for lot splitting within a process flow. As long as scrap is not allowed within a split lot region, however, the same rule applies lots can only get smaller, never larger. The flow arriving to a split step is treated as moving immediately to the step following the unsplit step. Special accommodations are then made for the flow within a split lot region. We have observed that for many systems the number of steps having scrap, rework, or random goto's is quite small, on the order of ten to twenty percent of S. Thus, for large sections of the process flow, the distribution of lot sizes does not change. Before starting any of the traffic analysis, we compress the process flow into a much smaller 360 Factory Explorer Copyright WWK 1995-2009
20.4. Nested Rework Flows number of steps S' << S. After solving the traffic equations, we map the compressed flows back into the original process flow. We end up sequentially solving 2J linear systems (rework and non-rework flows for each lot size), each containing S' variables. For S' on the order of fifty to one hundred, these calculations are quite fast, compared to the simulation of the system for most non-trivial time horizons. After solving the traffic equations for each product, Factory Explorer computes the input rate of lots for both tool groups and operator groups. For a tool group or operator group w, Factory Explorer sums the flows across all steps using w, and calculates n(w,j) = Input rate of non-rework lots of size j into w. r(w,j) = Input rate of rework lots of size j into w. t(w,j) = n(w,j) + r(w,j). tw = t(w,j).
20.4 Nested Rework Flows

Some manufacturing lines may contain nested rework flows. In that case, the solution of the traffic equations becomes more complicated, and must be decomposed into a different set of equations for each so-called nesting level. After reading in each process flow, Factory Explorer searches the process for the presence of nested rework flows. It tags each rework step with its nesting level, and displays the maximum rework nesting level in the product information section of the output statistics. As an example, suppose we have the system displayed in Figure 20-1.
Figure 20-1: System with nested rework loops.
Factory Explorer solves the traffic equations for this system in three steps (each of these steps is performed for each lot size from the largest down to a lot size of 1): 1. Cut both the rework transitions C B and D A so that no lots are reworked at any rework step. Insert the normal flow of non-rework lots. Solve the traffic equations for the flow of non-rework lots. 2. Cut the non-rework transition D E, and reattach the rework nesting level one transition D A. Insert the flow of normal lots that would be reworked along the Copyright WWK 1995-2009 Factory Explorer 361
20. Reference Topics: Capacity Analysis arc D A. Solve the traffic equations for the flow of nesting level one rework lots. 3. Cut the non-rework transition C D, and reattach the rework nesting level two transition C B. Insert the flow of normal lots and rework nesting level one lots that would be reworked along the arc C B. Solve the traffic equations for the flow of nesting level two rework lots. When all calculations are completed, the rework flows of various nesting levels are summed to arrive at the aggregate rework flow.
20.5 Processing Rates

In this section we describe the procedure used by Factory Explorer to approximate the lot processing rate w for each tool group or operator group w. Note that these figures are per-tool or per-server rates. To arrive at a per-tool group or per-set rate, you must multiply by the number of tools or servers. Each processing rate is merely the inverse of the corresponding mean process time, w = 1 / Mw. Denote the set of steps using w by Rw. The mean process time is a weighted sum of the mean process times of rework and non-rework lots, Mw = ( s Rw j t(s,j) Mw(s,j) ) / tw, where the first sum is over all the steps s in Rw, and the second sum is over all possible lot sizes j. If step s uses a non-batch tool, we define Mw(s,j) = Mean time to process j units at step s. If step s uses a batch tool, we define Mw(s,j) = (Mean time to process j units at step s) * j / max batch size. If step s is a hold step, then Mw(s,j) is defined to include the process time for all steps between s and the free after step, inclusive. See Section 9.15 of the manual for more information on holding a tool across multiple process steps. If step s is utilizes a cluster tool, then Mw(s,j) is adjusted to account for the state-specific operational impacts. See Section 9.19 of the manual for more information on cluster tool modeling. Denote the set of tool states at w by Sw. The mean process time adjustment is in the form of the following multiplier: = 1 MAX st Sw (PRMw(st, s)) - st Sw PRMw(st, s) SSw(st), where PRMw(st, s) is the operational impact of running step s on tool w while in tool state st and SSw (st) is the steady-state proportion of time that tool w is in tool state st. The steady-state proportions SSw(st) are determined by approximating the cluster tool state transitions as a continuous-time Markov chain.
20.6. Average Maximum Batch Size
20.6 Average Maximum Batch Size

For any tool group or operator group w that performs batch processing, Factory Explorer calculates a weighted average maximum batch size. This average maximum batch size is used in various output reports to predict the capacity loading% of batch tools. Factory Explorer calculates the weighted average across all steps that use w. Denote the maximum batch size at step s by Bs. Using definitions of Section 20.5, Factory Explorer computes the average maximum batch size as MAXBw = [s Rw j ((t(s,j) / Bs) Mw(s,j) Bs)] / [s Rw j ((t(s,j) / Bs) Mw(s,j) )]
20.7 Factory Nonscheduled Rate

When a model specifies a factory schedule, Factory Explorer needs to know the rate at which nonscheduled time occurs, or the factory nonscheduled rate w. Calculation of w is based upon the details of the factory schedule. First, denote the individual schedule data fields by STi = Factory Scheduled Time for schedule record i, NTi = Factory Nonscheduled Time for schedule record i, Ri = Number of repeats of schedule record i. Next, calculate the total schedule cycle length and the total factory nonscheduled time, CL = i (STi + NTi) Ri, TN = i NTi Ri. The factory nonscheduled rate is the total factory nonscheduled time divided by the total schedule cycle length, w = TN / CL. For models that do not specify a factory schedule, the factory nonscheduled rate is zero.
20.8 Offline Rates

For several calculations, Factory Explorer needs to know the approximate rate at which a tool group or operator w will be offline and thus unavailable to service lots due to interruptions, or the offline rate w. Note first that if w is being modeled as having an infinite number of servers, the offline rate is set to zero. For each interruption i that is modeled at w, let Tto be the mean time or units to the interruption, and Toff be the mean time offline when an interruption occurs. Denote the offline rate for interruption type i at w by w,i. Denote the number of tools or servers at w by Nw. The offline rate is calculated differently depending on the type of interruption, and may depend on the total unit input rate per tool or server Cw, Cw = ( j t(w,j)) / Nw. For between-time interruptions, w,i = Toff / Tto .
20. Reference Topics: Capacity Analysis For clock-time interruptions, w,i = Toff / (Tto + Toff). For busy-time interruptions, we need an estimate of wunit, the per-unit service rate at the tool group or operator group. Factory Explorer uses wunit = w * Average incoming lot size. Then, w,i = Toff / (Tto wunit / Cw + Toff}. For units-completed interruptions, w,i = Toff / (Tto / Cw + Toff). For group-clock interruptions, w,i = Toff / (Tto + Toff) / Nw. The overall offline rate w is the sum over all applicable interruption types, w = w,i.
20.9 Repair Rates

Within Factory Explorer, the repair (or maintenance) of a tool can require an operator from a specified operator group. In this case, repair becomes an additional interruption factor for the repairing operator group. Since tools are not used in the repair of other tools, repair is not an interruption factor for tool groups. Denote the repair rate of the tool group or operator group w by w. Thus for any tool group w, w = 0. For an operator group w that does repairs, let V denote the set of tools that require w for repair. For any tool group v in V, let Iv denote the set of interruption types at the tool group that require an operator from set w. Then we have w = v V i Iv v,i (mean time offline for interruption type i at tool group v).
20.10 Setup Rates at Tool Groups

In order to calculate traffic intensities, Factory Explorer needs to know the approximate rate at which tools will be experiencing setup, and thus unable to service lots. Denote the setup rate at tool group w by w. Factory Explorer currently uses one of two different approximations for w, depending on whether or not tool group w has setup-avoidance specified. These approximations were developed by Jennifer Robinson and John Fowler while at Sematech. Some modifications have been made to the setup-avoidance approximation by the author. Additional finish-rate related modifications have been made to both approximations by the author. Section 20.10.1 discusses the case where setup avoidance is not specified, Section 20.10.2 discusses the setup-avoidance approximation. Several definitions and concepts are common to both sections, however, so we will introduce them here.
20.10. Setup Rates at Tool Groups Within each setup group g defined at tool group w, Factory Explorer calculates an approximate value for the rate of setups due to group g, w(g). For the total setup rate at the tool group, Factory Explorer calculates w = w(g), where the sum is taken over all setup groups defined for the tool group. For a given setup group g, define t(g) = Total input rate of lots to tool group w for setup group g. For each setup I.D. j within setup group g at tool group w, define t(g,j) = Total input rate of lots to tool group w, setup group g, setup I.D. j, tf(g,j) = Total input rate of lots to tool group w, setup group g, that finish in I.D. j (unless specified otherwise using a finish I.D., a lot that requires setup I.D. j to start processing also finishes processing in I.D. j). Factory Explorer approximates the probability that a lot selected randomly from all setup I.D.'s will be of setup I.D. j with the following ratio: pj = t(g,j) / t(g). Factory Explorer approximates the probability that a given tool is setup for I.D. j at a random time with the following ratio: fj = tf(g,j) / t(g). Note that if a model does not include setup finish I.D.'s, fj will be identical to pj. Denote the mean setup time when switching from setup I.D. j to setup I.D. k by s(j,k). Suppose that a tool is currently setup for I.D. j. Denote by Sj the setup time that will occur due to servicing the next lot that specifies a setup I.D. for setup group g. Sj is a random variable, and can be zero if the next lot also has setup I.D. j. At batch tool groups, Factory Explorer expresses t(g) and t(g,j) in terms of full batches, not lots. If partial batches are processed, the setup rate will necessarily be in error to some degree, because more setups will take place than can be expected based on full-batch processing. 20.10.1 Setup Rate Approximation: No Setup Avoidance When AvoidSetups is not specified, Factory Explorer assumes that lots are served without regard for the magnitude of setup incurred. Factory Explorer computes the expected value for Sj as follows: E[Sj] = k E[Sj | next setup I.D. is k] P[next setup I.D. is k] = k s(j,k) pk. Now suppose that nothing is known about the current setup status of the tool group; denote by S the next setup time. Factory Explorer calculates the expected setup time as E[S] = j E[S | current setup I.D. is j] P[current setup I.D. is j] = j E[Sj] fj, and finally, the rate at which setups occur for setup group g, w(g) = t(g) E[S] / Nw, Copyright WWK 1995-2009 Factory Explorer 365
20. Reference Topics: Capacity Analysis where Nw is the number of tools at tool group w. 20.10.2 Setup Rate Approximation: Setup Avoidance When setup-avoidance is specified for a tool group, the approximation becomes significantly more complicated. Currently, Factory Explorer uses an approximation based on a strict-avoidance policy, when in fact the simulation uses a setup-minimization policy if setup-avoidance is specified (the StrictAvoid statement is also included in the simulation for solely research purposes). A strict-avoidance policy means that when a tool becomes free, the waiting list is searched for a lot that completely eliminates setup; if no such lot is found, the next lot in line is served. A setup-minimization policy searches for the lot in line that minimizes overall setup time. Based on current experiments, it does not appear that there is much error induced by this approximation. A setup-minimization approximation may be included in future releases. Factory Explorer's setup-avoidance approximation also does not take into account the effect of MINTOOLS, MAXTOOLS, MINQUEUE, MINDELAY, MAXQUEUE, and MAXDELAY. To understand the complication inherent in the setup-avoidance approximation, consider the following. The setup rate depends in part on the probability of finding a lot in queue with a setup I.D. matching the current setup status of the tool. This probability depends on the queue length, which is a function of the traffic intensity of the tool. However, the traffic intensity at the tool depends on the rate at which setups occur. As the traffic intensity increases, queue lengths become longer, leading to a higher probability that a matching lot will be found in queue, which in turn causes the setup rate to decrease at higher traffic intensities. To surmount these difficulties, Factory Explorer uses a bisection search approach. First it guesses a setup rate, and using this setup rate calculates the resulting traffic intensity. Based on this traffic intensity, it calculates an approximate setup rate and compares this rate with the original guess. If the guess was too low, Factory Explorer increases it and tries again; if the guess was too high, Factory Explorer decreases it and tries again. The procedure terminates when the guess and resulting setup rate fall within a small difference of each other. Recall that we have defined Sj to be setup time (a random variable) that next occurs, conditioned on the tool currently being set up for I.D. j. If there are no lots in queue, we assume the next lot to arrive (which will immediately be processed, and hence, force a setup) has setup I.D. k with probability pk. If there are lots in queue and at least one of those lots has setup I.D. j, that lot will be selected for service and there will be no setup. Otherwise, a setup will occur. Factory Explorer calculates the expected value of Sj as follows: E[Sj] = E[Sj | empty queue] P[empty queue] + E[Sj | no lots of setup I.D. j in queue] P[no lots of setup I.D. j in queue] Let n denote an approximation for the probability that exactly n lots are in queue when the next service time ends. Factory Explorer uses an M/M/s approximation when calculating n. Now we have P[empty queue] = 0, P[no lots of setup I.D. j in queue] = n n (1-pj)n. (Sum from 1 to ), 366 Factory Explorer Copyright WWK 1995-2009
20.11. Setup Rates at Operator Groups E[Sj|empty queue] = k E[Sj|next setup I.D. is k]P[next setup I.D. is k] = k s(j,k) pk, E[Sj | no lots of setup I.D. j in queue] = k E[Sj | no lots w/I.D. j, next I.D. is k]P[next I.D. is k|no lots w/I.D. j] = k s(j,k) qk, where qk = t(g,k) / (t(g) - t(g,j)). Once E[Sj] has been approximated, the method proceeds to find the expected setup rate for the tool group: E[S] = j E[S | current setup I.D. is j] P[current setup I.D. is j] = j E[Sj] fj, w(g) = t(g) E[S] / Nw, w = w(g). As discussed above, however, the procedure does not end here. Before starting the algorithm, Factory Explorer makes an initial guess at the setup rate, which is used in the M/M/s approximation to calculate n. Once w has been calculated, Factory Explorer compares it with the original setup rate guess. Using a bisection search, Factory Explorer searches for a setup rate guess that results in a matching output w. Once the guess and the output are within a small tolerance of each other, the algorithm terminates.
20.11 Setup Rates at Operator Groups

Approximating setup rates for operator groups is complicated by the fact that operators can serve several different tool groups. Some of these tool groups may have setup, while others do not. Among the tool groups with setup, some may have very long setup times, while others have very short setup times. For an operator group w, Factory Explorer approximates the setup rate of w by a weighted average of the setup rates for all tool groups served by w. Let V denote the set of all tool groups v served by w, Pv the percent of time an operator is required for setup at tool group v, Rv the set of all processing steps s that are served by tool group v and operator group w, Ss the total setup time at step s (a random variable), and t(s) the total input rate of lots into step s. Factory Explorer approximates the setup rate for operator group w by w = v V (Pv /100) [ ( s Rv E[Ss] t(s) v ) / (s R E[Ss] t(s)) ]. Potential problems with this approximation appear to be centered around calculation of the expected total setup time at a step, E[Ss]. At best, E[Ss] would reflect the expected total setup time of a lot randomly processed at the step. However, that calculation would depend on the setup configuration of the tool group prior to each lot's arrival, which Factory Explorer does not currently approximate. When there are no sequence-dependent setups, Factory Explorer uses a straight-forward calculation for E[Ss]. However, the presence of sequence-dependent setups causes some additional error, because Factory Explorer again does not know the prior setup configuration of the tool group. For each setup group specifying sequence-dependent setups, Factory Explorer uses the default setup time when calculating E[Ss]. Thus, the approximation will probably not perform well when sequence dependent setups are present in a model, but default Copyright WWK 1995-2009 Factory Explorer 367
20. Reference Topics: Capacity Analysis setup times are not specified for each setup group. This problem affects the setup rate approximation only for operator groups, not tool groups.
20.12 Occupied%
For each tool group or operator group w, Factory Explorer predicts an approximate occupied%. The occupied% represents the overall percent of time the resource is working, nonscheduled, offline, setting up, or repairing other resources (in the case of operator groups that perform repair). Factory Explorer approximates the occupied% at w by w = 100 [tw / (Nw w) + w + w + w + w ] %. For non-batch tools, occupied% should be roughly 100-free%. For batch tools, however, the working portion of occupied% represents the percent of time the tool would be busy working if all batches were completely filled. Thus for batch tools, occupied% will generally be somewhat smaller than 100-free%.
20.13 Capacity Loading% and Actual Maximum Processing Rate: Resources that Perform Processing
For each tool group or operator group w, Factory Explorer predicts an approximate capacity loading%, that represents the overall capacity used by work after capacity has been downgraded for nonscheduled time, interruptions, setups, and (in the case of operators) repairs. To compute capacity loading%, Factory Explorer first approximates the actual maximum processing rate for the resource group, tw,max. To find tw,max, Factory Explorer searches for the arrival rate that would exactly saturate the resource, i.e. leaving the resource with a free% of zero, or an occupied% of 100. In actuality, the occupied% w is a function of arrival rate, so Factory Explorer uses a binary search algorithm to find tw,max satisfying w(tw,max) = 100. The capacity loading% at w is approximated by w = 100 tw / tw,max %. Note that this value is usually not the same as occupied%. Batch tools with a large maximum batch size but small minimum batch size can lead to resources working a high percentage of the time but still processing at less than full capacity (most of the batches can be nearly empty). Even for non-batch processing, a capacity loading% of 75% does not necessarily mean the tool will be occupied 75%. For example, suppose the total arrival rate of lots to a tool group is tw = 6, the number of tools Nw = 1, the service rate w = 10, the offline rate w = 0.20, the nonscheduled rate w = 0, and the setup rate w = 0. Since we are considering a tool group, the repair rate w = 0. The occupied% becomes 100% at the actual maximum processing rate of tw,max = 8, w(8) = 100 [8 / (1 * 10) + 0.20 + 0.0 + 0.0 + 0.0 ] = 100%.
20.14. Capacity Loading%: Resources that Perform Only Repair Thus the capacity loading% is w = 100 * 6 / 8 %. = 75%. However, the occupied% is w = 100 [ 6 / (1 * 10) + 0.2] = 80%. These figures do not match because we are defining capacity loading% to be the ratio of the tool's arrival rate to its actual maximum processing rate, not the percent of time the tool is occupied (due to work, setups, or interruptions). If the capacity loading% is 75% and the current input rate of lots is 6 per hour, this means that the tool could handle an input rate of up to 8 lots per hour (6 / 8 = 75%).
20.14 Capacity Loading%: Resources that Perform Only Repair

For resource groups that perform only repair (e.g. operator groups), Factory Explorer cannot calculate capacity loading% in the above fashion, since the actual maximum processing rate is technically infinite. Instead, in these cases, Factory Explorer uses the formalism that capacity loading is equal to the sum of capacity loss factors (offline rate, non-scheduled rate, and repair rate). By definition, if the operator group performs no processing, its setup rate must be zero, so that is not included here. Thus, for an operator group w that performs only repair (no processing whatsoever), Factory Explorer defines capacity loading as w = 100 * (1.0 - w - . w - w).
20.15 Max Going Rate (Daily Going Rate, or DGR).

For each tool group or operator group w, Factory Explorer predicts an approximate max going rate for the group and per resource in the group. When expressed on a units per day basis, max going rate is referred to as the Daily Going Rate (DGR). Max Going Rate represents the factory throughput rate that would cause the resource group to be loaded exactly to 100%. Max Going Rate is calculated as follows: MaxGoingRatew = Throughput w /w, MaxGoingRatePerResource = MaxGoingRatew / (Current Resource Count), where w = Capacity Loading for resource group w (see section 20.13), Throughput w = Sum of product throughput rates for products that are processed by group w and that specify the same unit type as resource group w (or in the case that resource group w does not specify a unit type, the sum of product throughput rates for products that are processed by group w that do not specify a unit type). The restriction on the throughput sum to only products specifying the same unit type as the resource group is necessary for factories where multiple unit types are processed (e.g. both wafers and die). For multiple unit type factories, max going rate calculations produce nonsense numbers unless restricted in this fashion (i.e. it does not make sense to add throughput rates together for different unit types).
20. Reference Topics: Capacity Analysis For multi-product factories, it is often useful to compute an adjusted max going rate that is directly comparable to factory throughput numbers. For example, suppose a factory produces two products A and B, and that the start rate of A is one unit per hour, and the start rate of B is one unit every two hours. Suppose the factory contains two tool groups, TG1 and TG2 (each composed of a single tool), and that TG1 is required for production of both A and B, whereas TG2 is only required for production of A. Suppose that TG1 has a process times of 1/2 hour, no matter the product being processed, and that TG2 has a process time of 1 hour. In this case we have for TG1: tTG1 = arrival rate to TG1 = A's arrival rate + B's arrival rate = 1 + 0.5 = 1.5 units per hour, TG1 = service rate of TG1 = 1 / (process time) = 1/0.5 = 2 units per hour, NTG1 = number of TG1 tools = 1, TG1 = tTG1 / (TG1 NTG1) = 1.5 / 2 = 0.75, ThroughputTG1 = 1.5, MaxGoingRateTG1 = ThroughputTG1 / TG1 = 1.5 / 0.75 = 2 units per hour, DGRTG1 = 48 units per day. For TG2, we have: tTG2 = A's arrival rate = 1 unit per hour. TG2 = service rate of TG2 = 1 / (process time) = 1/1 = 1 unit per hour. NTG2 = number of TG2 tools = 1 TG2 = tTG2 / (TG2 NTG2) = 1.0 ThroughputTG2 = 1, MaxGoingRateTG2 = ThroughputTG2 / TG2 = 1 / 1 = 1 unit per hour, DGRTG1 = 24 units per day. In this example, the factory is producing 24 units per day of product A and 12 units per day of product B, and thus we say the scheduled factory DGR is 36 units per day. For TG1, which processes both product A and B, the DGR is 48 units per day. Comparing the TG1 DGR of 48 units per day to the scheduled factory DGR of 36 units per day, we say that the tool group has enough capacity. The problem comes when we compare the TG2 DGR of 24 units per day to the scheduled factory DGR of 36 unit per day. In this case, we would be tempted to say that TG2 does not have enough capacity, but that would be incorrect. The problem lies in the fact that TG2 does not process product B, and so it is wrong to compare a tool-level DGR (which does not account for product B) against the factory-level DGR (which does account for product B). That is why Factory Explorer also calculates an adjusted max going rate number for all resource groups. To do this calculation, we make a DGR adjustment to the group DGR to give credit for non-processed products. To do so, we calculate: AdjustedMaxGoingRatew = AdjustedThroughput w /w, where
20.16. Suggested Maximum Capacity Loading w = Capacity Loading for resource group w (as before), AdjustedThroughput w = Sum of product throughput rates for all products that specify the same unit type as resource group w, whether or not they are actually processed by resource group w (or in the case that resource group w does not specify a unit type, the sum of product throughput rates for all products that do not specify a unit type). Returning to our example, we have: AdjustedThroughput TG2 = 1.5 units per day, AdjustedMaxGoingRateTG2 = AdjustedThroughput TG2 /TG2 = 1.5 / 1 = 1.5 units per day, AdjustedDGRTG2 = 36 units per day. Now we can compare the adjusted DGR for TG2 (36 units per day) against the scheduled factory DGR (36 units per day), and see that TG2 has just enough capacity (if we assume that 100% capacity loading is ok) to satisfy capacity. In fact, the following is an alternative way of explaining the concept of capacity loading for a resource group: Capacity Loading = Scheduled Factory DGR / Adjusted Group DGR.
20.16 Suggested Maximum Capacity Loading

In addition to analyzing the input model specified by the user, Factory Explorer makes suggestions as to the appropriate quantity of tools and operators. To do so, it first calculates a suggested maximum capacity loading for each tool and operator group. For tool or operator group w, denote the suggested maximum capacity loading by w,max. Factory Explorer calculates w,max by taking the suggested maximum capacity loading specified by the SuggLoading option, modifying it as necessary by the contents of the AddSuggPct option, and then subtracting the tool or operator group specific capacity buffers specified in the CBUFFER column (Excel models) or with the CapacityBuffer statement (ASCII model). This calculation is performed as follows: w,max = (SuggLoading Parameter) + (AddSuggPct Parameter) * (Replication Number 1) (Capacity Buffer Model Input for Group w).
20.17 Suggested Whole Tool and Operator Counts

Factory Explorer calculates a suggested whole resource count for all tool and operator groups. This whole resource count will always be an integer, as it represents the minimum quantity of resources that would be required to meet the suggested maximum capacity loading for the resource group. For each tool or operator group w, denote the suggested whole resource count by Nw,whole. Factory Explorer calculates Nw,whole as follows: 1. Set Nw,whole = 0. 2. Calculate w,whole, the capacity loading% for group w with Nw,whole resources, . 3. If w,whole <= w,max, exit the routine.
20. Reference Topics: Capacity Analysis 4. Otherwise, increment Nw,whole and return to step (2). Several special cases exist. First, if the current number of resources Nw is infinite, the suggested number of resources is always infinite. Second, if at any point in the routine Nw,whole exceeds one and the resulting capacity loading% is infinite, that means the sum of the capacity loss factors for the resource group exceeds 100%. If this sum does not significantly decrease as Nw,whole is incremented, the routine is terminated and the suggested number of resources is reported as infinite. Finally, if the suggested number of resources is calculated as zero by the above routine for a resource that is used in the model (this is possible for resources that are only used at process steps with zero process times), the suggested number of resources is reported as one.
20.18 Suggested Exact Tool and Operator Counts

Factory Explorer calculates a suggested exact resource count for all tool and operator groups. This exact resource count will in general be a decimal (not integral) quantity, as it represents the quantity of resources that would be required to exactly meet the suggested maximum capacity loading for the resource group. For each tool or operator group w, denote the suggested exact resource count by Nw,exact. Factory Explorer calculates Nw,exact as follows: Nw,exact = Nw,whole * w,whole / w,max. Factory Explorer uses the results of the suggested whole resource count Nw,whole and w,whole, because that makes the exact resource count calculation more widely applicable. For example, if a tool group in the model specifies zero tools but really requires a nonzero quantity of tools, the suggested whole tool count will be set to non-zero quantity, and this calculation can then be used to generate the exact tool count. Several special cases exist. First, if the suggested whole number of servers Nw,whole is infinite, the above calculation cannot be used, and Nw,whole is set to infinite. Second, if the capacity loading w,whole equals zero, no servers are required and Nw,exact is set to zero. Third, if the capacity loading w,whole is infinite, then no amount of servers will bring the capacity loading below the suggested maximum, and Nw,exact is set to infinite. Finally, if the suggested whole number of servers Nw,whole is zero, the above calculation cannot be used, and Nw,exact is set to zero. Note that in some cases, the difference between Nw,exact and Nw,whole may be more than one resource. That is, Nw,whole is not just Nw,exact rounded up to the next larger integer. For operator groups that perform repair, or for tool groups with group-clockbased interruptions, these capacity loss factors are not constant as the number of resources is changed (e.g. as the number of operators is decreased, the resulting repair% must increase, as the same quantity of repairs are performed by fewer operators). Since the calculation of Nw,exact does not account for this effect, it is possible for Nw,exact to be more than one resource smaller than Nw,whole. For example, consider a one-step system with arrival rate tw = 2.456 units per hour, service rate w = 1.0 units per hour, and a hour engineering downtime (modeled as a group-clock interruption) with a time-to-interrupt of four hours. So no matter how
20.19. Lead Time many tools are installed, one tool is required every four hours for hour of engineering. In this system, If Nw,whole = 1, w,whole = 2.456 / [1.0 * 1 * (1 0.1111)] = 2.7630, If Nw,whole = 2, w,whole = 2.456 / [1.0 * 2 * (1 0.0556)] = 1.3000, If Nw,whole = 3, w,whole = 2.456 / [1.0 * 3 * (1 0.0370)] = 0.8502, If Nw,whole = 4, w,whole = 2.456 / [1.0 * 4 * (1 0.0278)] = 0.6315. Hence, Nw,whole = 4, and w,whole = 0.6315. But Nw,exact = Nw,whole * w,whole / w,max = 4 * 0.6315 / 0.85 = 2.97. This situation should occur infrequently, however, as conditions must be just right for the difference Nw,whole - Nw,exact to exceed one resource.
20.19 Lead Time

Factory Explorer represents tool purchase lead time and calculates a purchase date for all tool. Lead time value will represent for period with suggested whole resource count more that for previous period. Purchase date = PeriodStartDate - LeadTime
20.20 Interarrival and Process Time Coefficients of Variation

In order to approximate queue lengths and delays, Factory Explorer must approximate the coefficients of variation for interarrival and process times at a tool group. For tool group w, denote the coefficient of variation for interarrival times by ca(w), and for process times by cs(w). Interarrival Time Coefficient of Variation: Factor Explorer solves a system of linear equations as described in Whitt (1983a) to approximate the coefficient of variation for interarrival times. Process Time Coefficient of Variation: The coefficient of variation of a random variable is the ratio of its standard deviation to its mean, cs(w) = (Vw)1/2 / Mw, where Vw is the variance of the process time, and Mw is the mean process time. Calculations for the mean service time are covered in Section 20.5. If only a single step uses the tool group, the calculation of the variance Vw is straightforward: Vw = Var[step process time]. If, however, multiple steps use the tool group, the calculation becomes a bit more complicated, especially if the processing steps specify different processing times. For all steps that use a tool group w, define
20. Reference Topics: Capacity Analysis m(s,j) = Expected processing time of a lot with j units at step s. v(s,j) = Variance of processing time of a lot with j units at step s. t(s,j) = Total input rate of lots with j units to step s. t = Total input rate of lots to tool group w. Denote the process time at tool group w by S (a random variable). If we make the assumption that lots served by tool group w are chosen randomly from all possible step/size combinations, we can approximate the process time variance Vw = Var[S] using a conditional variance approach. Let C denote a step/size combination {s,j}. We will think of C as a random variable with the probability that it equals any particular step/size combination being equal to the ratio of lot input rate to that step/size combination divided by the total input rate to the tool group: p(s,j) = P[C = {s,j}] = t(s,j) / t. Using conditional expectation, Vw = Var[S] = Var[ E[S|C] ] + E[ Var[S|C] ] = Var[ E[S|C] ] + v(s,j)p(s,j) = E[ E[S|C]2 ] - E[E[S|C]]2 + v(s,j)p(s,j) = m(s,j)2p(s,j) - ( m(s,j)p(s,j) )2 + v(s,j)p(s,j) where each of the sums is taken over all possible step/size combinations {s,j}. If many different steps use a tool group, it is possible for numerical problems to cause the resulting variance to be a small negative number, when the actual variance should be zero. When Factory Explorer performs these calculations and arrives at a very small (but negative) variance, it silently coerces the result to zero. If the result is negative, but not very small, Factory Explorer will still coerce the result to zero but will also print a warning message. The presence of this warning message may indicate problems other than numerical accuracy, and should be investigated.
20.21 Queue Lengths and Queue Delays

Factory Explorer uses the approximation developed in Kraemer and Langenbach-Belz (1967) for mean steady-state queue lengths. Denote the steady-state queue length at tool group w by Lw. Two correcting factors GKLB and Pm are calculated as described in the KLB paper. The queue length is approximated by Lw = (w / (1 - w)) GKLB Pm (ca(w)2 + cs(w)2) / 2. At batch tools, Factory Explorer performs an additional correction to restate the queue length in terms of lots and to correct for the presence of minimum batch sizes. Once the queue length has been approximated, Factory Explorer uses Little's law (Lw = tw Qw) to approximate the mean steady-state queue delay Qw: Qw = Lw / tw.
20.22. Maximum Stable Release Rates
20.22 Maximum Stable Release Rates

In order to approximate the maximum stable factory release rate, Factory Explorer scans through each tool group and operator group w and finds the maximum capacity loading w. The tool or operator group with the maximum capacity loading (the bottleneck) determines the capacity for the factory. Call this maximum capacity loading wmax. If wmax is infinite, then the maximum stable release rate is zero. If wmax is zero, the maximum stable release rate is infinite. Otherwise, the maximum stable release rate is calculated by dividing the current release rate by wmax.
20.23 Throughput and Yield

Subject to the assumptions listed in Section 20.2, Factory Explorer can calculate exact throughput and line yield. Please note, however, that this throughput will not be attained if the system is operating with an unstable input rate (the specified input rate exceeds the maximum stable input rate). Let p denote the probability that units are scrapped after processing at step s. The non-rework unit throughput rate at step s is given by s = (1-p) j n(s,j). For each product, Factory Explorer approximates the throughput of the system as the unit output rate of the final process step, S. Cumulative line yield for a step s is approximated by the output rate at that step divided by the unit release rate, s / (1,J). The overall line yield reported in the output is the cumulative line yield for the final process step, S / (1,J).
20.24 Raw Process Time

For each product, Factory Explorer calculates and displays an estimate for the raw process time, or total time a lot would spend in the line under the best possible circumstances. There are many definitions for raw process time, but the one used by Factory Explorer is as follows. First, a special version of the traffic equations is constructed and solved, under the assumption that rework and scrap never occur. Next, the expected number of visits by a unit to each step in the process flow is computed. Let J be the expected number of units in lots when released into the line. Raw process time at a step is the expected number of visits times the mean Load Time plus Processing Time plus Unload Time plus Delay Time (as defined in Section 4.4) for a lot with J units. Note that Delay Time does not refer to queuing delay, only to one of the service time parameters. Raw process time for the line is the sum over all process steps of the step raw process times. Use the OneUnitRPT option to specify that Factory Explorer should calculate single-unit raw process times. The above calculations are used, except that J is set to one.
20. Reference Topics: Capacity Analysis
20.25 Future Work

There are several areas where the approximations currently implemented in Factory Explorer could be significantly improved. First and foremost, the method used to estimate the coefficient of variation of interarrival times needs to be updated to take into account the significant variability induced downstream of batch tools. Without such a correction, queue length and queue delay approximations will likely be consistently too low. Second, it appears from recent tests that just estimating the correct coefficient of variation for the arrival process downstream from batch tools will not be enough -- the overall traffic pattern will have to be analyzed. Third, the setup rate approximation for operator groups will likely perform poorly when a single operator group serves many different tool groups that have sequence-dependent setups. Finally, the queue length approximation code inside the setup-rate approximation uses an M/M/s formula, when in reality a G/G/s approximation is more appropriate.
21. Reference Topics: Cost Analysis
21.1 Introduction
In this Chapter, we detail the calculations that Factory Explorer performs during cost analysis. Cost analysis provides five primary performance measures: product cost per good unit out (Section 21.2), total fixed cost (Section 21.3), total recurring cost (Section 21.4) gross margin (Section 21.6), and WIP valuation (Section 21.7). Note that options such as UseSugg, ReleasePct, DelScrap, etc., modify the input model. Factory Explorer performs cost analysis on the modified model. Enable DoCap and DoCost to generate most cost analysis outputs. Some outputs also require DoSim.
21.2 Product Cost Per Good Unit Out

If a model includes any type of cost data, Factory Explorer computes the product cost per good unit out. For products p, tool groups w, operator groups v, and process steps s, define pout = Number of good units out per year for product p, pin = Number of entering units per year for product p, FFCf = Factory fixed cost f, FULf = Useful life of factory fixed cost f, FRCr = Factory annual recurring cost r, RUCp = Raw unit cost for product p (for a single unit), FCw = Per-tool fixed cost for tool group w, ULw = Useful life of a tool in tool group w, ARCw = Per-tool annual recurring cost for tool group w, EIe = Cost per unit of measure for expense item e, EICw,e,t = Consumption rate per hour, tool group w, expense item e, E-10 state t (t is one of non-scheduled time, scheduled downtime, unscheduled downtime, engineering time, productive time, standby time),
21. Reference Topics: Cost Analysis EICPw,e = Consumption per unit processed, tool group w, expense item e, E10Rw,t = Percent of time (expressed as decimal between 0 and 1) that a tool in tool group w spends in E-10 state t, Is,e = 1 if process step s specifies an exception (item not used) for expense item e, 0 otherwise, Nw = Number of tools in tool group w (if infinite, Nw is set to 1), PTw = Process time allocation ratio for tool group w, SRw = Per-tool total space requirement for tool group w, SRw,s = Per-tool total space requirement for tool group w, space type s. TS = Total space requirement for factory, SPCw = Space ratio for tool group w, HWRv = Per-operator hourly wage rate for operator group v, HORv = Per-operator hourly overhead rate for operator group v, WPv = Working percentage for operator group v. Nv = Number of operators in operator group v (if infinite, Nv is set to 1), PTv = Process time allocation ratio for operator group v, p,sr = Number of rework units per year of product p processed at step s. p,s = Number of units per year of product p processed at step s. SCp,s = Per-unit supplies & consumable cost for product p, step s, OCp,s = Per-unit overhead cost for product p, step s, MCp,s = Per-unit direct material cost for product p, step s, NVp,s = Number of visits to step s by a good unit of product p if it experiences no rework, Ip,s,w = 1 if process step s for product p uses tool group w, 0 otherwise, w(s) = Tool group w used by process step s, Ip,s,v = 1 if process step s for product p uses operator group v, 0 otherwise, MTTp,s = Mean tool time required for product p at step s, MOTp,s = Mean operator time required for product p at step s. For each product p, Factory Explorer generates product cost per good unit out data that is similar to the following. 1. 2. 3. 4. 5. 6. 7. 8. 9. Factory Fixed Cost f Total Factory Fixed Cost Factory Recurring Cost r Total Factory Recurring Cost Actual Raw Unit Cost Scrapped Raw Unit Cost Total Raw Unit Cost Baseline Supplies & Consumable Cost Rework Supplies & Consumable Cost $x $x $x $x $x $x $x $x $x Copyright WWK 1995-2009
21.2. Product Cost Per Good Unit Out 10. Scrapped Supplies & Consumable Cost 11. Total Supplies & Consumable Cost 12. Baseline Overhead Cost 13. Rework Overhead Cost 14. Scrapped Overhead Cost 15. Total Overhead Cost 16. Baseline Direct Material Cost 17. Rework Direct Material Cost 18. Scrapped Direct Material Cost 19. Total Direct Material Cost 20. Expense Item Cost e 21. Total Expense Item Cost 22. Tool Fixed Cost 23. Tool Recurring Cost 24. Total Tool Cost 25. Operator Wage/Working Time Cost 26. Operator Overhead/Working Time Cost 27. Total Operator/Working Time Cost 28. Operator Wage/Non-Working Time Cost 29. Operator Overhead/Non-Working Time Cost 30. Total Operator/Non-Working Time Cost 31. Total Operator Cost 32. Total Product Cost $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x $x
Calculations: 1. w FFCf SPCw PTw / [pout FULf] 2. f (1) 3. w FRCr SPCw PTw / pout 4. r (3) 5. RUCp 6. (7) - (5) 7. pin RUCp / pout 8. s SCp,s NVp,s 9. s SCp,s p,sr / pout 10. (11) - (8) - (9) 11. s SCp,s p,s / pout 12. s OCp,s NVp,s 13. s Cp,s p,sr / pout 14. (14) - (11) - (12) 15. s OCp,s p,s / pout 16. s MCp,s NVp,s 17. s MCp,s p,sr / pout 18. (17) - (14) - (15) 19. s MCp,s p,s / pout 20. (s EICPw(s),e (1 - Is,e) EIe p,s / pout) + (w e t EICw,e,t EIe E10Rw,t Nw PTw)
21. Reference Topics: Cost Analysis 21. e (20) 22. w FCw Nw PTw / [pout ULw] 23. w ARCw Nw PTw / pout 24. (20) + (21) 25. WPv v 8760 HWRv Nv PTv / pout 26. WPv v 8760 HORv Nv PTv / pout 27. (23) + (24) 28. (1 - WPv) v 8760 HWRv Nv PTv / pout 29. (1 - WPv) v 8760 HORv Nv PTv / pout 30. (26) + (27) 31. (25) + (28) 32. (2) + (4) + (7) + (11) + (15) +(19) + (21) + (24) + (31) where SRw = s SRw,s. PTw = [s Ip,s,w MTTp,s p,s] / [p s Ip,s,w MTTp,.s p,s], PTv = [s Ip,s,v MOTp,s p,s] / [p s Ip,s,v MOTp,.s p,s], TS = w Nw SRw, SPCw = (Nw SRw) / TS. When product p is the result of assembly or transform, the items relating to raw unit cost are deleted, and similar items are inserted for each product that feeds p either through assembly or transform. When a model include tool types, the fixed and recurring cost contribution of tool groups to product cost is summarized by tool type.
21.3 Total Fixed Cost

If a model includes fixed cost data at the factory level or for tool groups, Factory Explorer computes the system's total fixed cost. Denote by FFCf factory fixed cost f. For each tool group w, denote the fixed cost per tool by Fw, and the number of tools by Nw (if infinite, Nw is set to 1). Fw can include just the purchase price, or the purchase price plus installation costs. Using this data, Factory Explorer calculates the total fixed cost for the system, f FFCf + w Fw Nw. When a model includes tool types, tool-related fixed costs are also summarized by tool type.
21.4 Total Recurring Cost

If a model includes recurring cost data at the factory level or for tool groups, Factory Explorer computes the system's total annual recurring cost. Denote by FRCr factory recurring cost r. For each tool group w, denote the annual recurring cost per tool by ARCw, and the number of tools by Nw (if infinite, Nw is set to 1).
21.5. Raw Unit Cost Using this data, Factory Explorer calculates the total annual recurring cost for the system, r FRCr + w ARCw Nw. When a model includes tool types, tool-related annual recurring costs are also summarized by tool type.
21.5 Raw Unit Cost

For gross margin and inventory valuation, Factory Explorer needs to know the cost of raw units for each product. Factory Explorer defines the raw unit cost for a product to be the cost associated with releasing a single unit of the product into the factory. For each product p, define RUCp = Raw unit cost for product p (for a single unit). For products that are not the result of transform or assembly, the raw unit cost can be specified in the input model. In these cases, Factory Explorer simply uses the value of RUCp specified in the model. However, Factory Explorer calculates the raw unit cost for transformed or assembled products. Factory Explorer calculates the raw unit cost for transformed products by taking a weighted average of the raw unit cost for all input products. Suppose that products p1 through pn are transformed into product p. Denote the unit multiplier for the pj to p transform by Mj, the rate at which units of product pj are completed by j, and the percentage of product pj's throughput that is transformed into p by Pj. Factory Explorer calculates the raw unit cost of the transformed product as a weighted average, RUCp = [j (RUCpj / Mj) (j Pj/100)] / [j (j Pj/100)]. Factory Explorer calculates the raw unit cost for assembled products by summing up the raw unit costs for all sub-assembly products. Suppose that products p1 through pn are assembled into product p. Denote the units of product pj required for the assembly by Rj. Factory Explorer calculates the raw unit cost of the assembled product as a simple sum, RUCp = j RUCpj Rj.
21.6 Gross Margin

For models that include revenue or cost data, Factory Explorer uses capacity analysis results to predict gross margin (revenue - total cost). To document this calculation, we will need the following definitions. FFCf = Factory fixed cost f, FDLf = Depreciation life of factory fixed cost f, FRCr = Factory annual recurring cost r, EIe = Cost per unit of measure for expense item e,
21. Reference Topics: Cost Analysis EICw,e,t = Consumption rate per hour, tool group w, expense item e, E-10 state t (t is one of non-scheduled time, scheduled downtime, unscheduled downtime, engineering time, productive time, standby time), EICPw,e = Consumption per unit processed, tool group w, expense item e, E10Rw,t = Percent of time (expressed as decimal between 0 and 1) that a tool in tool group w spends in E-10 state t, Is,e = 1 if process step s specifies an exception (item not used) for expense item e, 0 otherwise, pout = Number of good units out per year for product p, REVp = Revenue per finished unit of product p, pin = Number of entering units per year for product p, RUCp = Raw unit cost for product p (for a single unit), FCw = Per-tool fixed cost for tool group w, DLw = Depreciation life of a tool in tool group w, ARCw = Per-tool annual recurring cost for tool group w, Nw = Number of tools in tool group w (if infinite, Nw is set to 1), HWRv = Per-operator hourly wage rate for operator group v, HORv = Per-operator hourly overhead rate for operator group v, Nv = Number of operators in operator group v (if infinite, Nv is set to 1), p,s = Number of units per year of product p processed at step s. SCp,s = Per-unit supplies & consumable cost for product p, step s. OCp,s = Per-unit overhead cost for product p, step s. MCp,s = Per-unit direct material cost for product p, step s. Factory Explorer calculates annual system revenue, p pout REVp, annual factory depreciation cost, f FFCf / FDLf, annual factory recurring cost, r FRCr, annual expense item cost, (e s EICPw(s),e (1 - Is,e) EIe p,s) + (w e t EICw,e,t EIe E10Rw,t Nw) annual raw unit cost, p pin RUCp, annual tool depreciation cost, w FCw Nw / DLw,
21.7. WIP Valuation annual tool recurring costs, w ARCw Nw, annual operator wages, 8760 v HWRv Nv annual operator overhead cost, 8760 v HORv Nv annual supplies & consumable cost, p [s p,s SCp,s]. annual process overhead cost, p [s p,s OCp,s]. and annual direct material cost, p [s p,s MCp,s]. Factory Explorer's gross margin prediction is system revenue minus factory depreciation cost minus factory recurring cost minus expense item cost minus raw unit cost minus tool depreciation cost minus tool recurring cost minus operator wages minus operator overhead cost minus supplies & consumable cost minus process overhead cost minus direct material cost.
21.7 WIP Valuation

For models that include raw unit cost data, Factory Explorer uses simulation results to estimate the average value of work-in-process (WIP). This valuation is based on raw unit cost only, and does not include production cost. For each product p, define RCCp = Raw unit cost of product p (for a single unit), WVp = WIP valuation for product p, based on raw material cost. During the simulation, Factory Explorer updates WVp at the following times: 1. When a unit of product p is released into the factory, WVp = WVp + RMCp. 2. When a unit of product p is scrapped, WVp = WVp - RMCp. 3. When a unit of product p is finished, WVp = WVp - RMCp. 4. When a unit of product p is transformed into M units of product q, WVp = WVp RMCp, WVq = WVq + (RMCq)(M). 5. When a unit of product p is finished and reserved for assembly into product q, WVp = WVp - RMCp, WVq = WVq + RMCp. For assembly, these updates take place when the product p unit finishes, even if it is not immediately assembled into product q (due to other required units in the assembly not being available). For each product p, Factory Explorer computes an estimate and confidence bounds for the WIP valuation WVp. Copyright WWK 1995-2009 Factory Explorer 383
22. Reference Topics: Space and Layout Analysis
22.1 Introduction
In this chapter, we detail the calculations that Factory Explorer performs during space and layout analysis. The primary space and layout analysis performance measures are total required space by layout area (Section 22.2), total required space by type (Section 22.3), travel matrix by move rate (Section 22.4), and travel matrix by distance rate (Section 22.5).
22.2 Total Required Space by Layout Area

When a model includes both space data and layout area data, Factory Explorer will roll up the space requirements by layout area. To document these calculations, we need the following definitions. TRSa = Total required space for layout area a, LAw = Layout area for tool group w, Nw = Number of tools in tool group w (if infinite, Nw is set to 1), SRw = Per-tool total space requirement for tool group w, SRw,s = Per-tool total space requirement for tool group w, space type s. Factory Explorer first calculates the per-tool total space requirement for each tool group w, SRw = s SRw,s. For each layout area, the total required space is calculated as TRSa = w Nw SRw I(LAw = a), where I() is the indicator function (equals 1 if condition inside is satisfied, equals 0 otherwise).
22. Reference Topics: Space and Layout Analysis
22.3 Total Required Space by Type

When a model includes space data, Factory Explorer calculates the total required space by space type. Assume the following definitions. TRSs = Total required space for space type s, Nw = Number of tools in tool group w (if infinite, Nw is set to 1), SRw,s = Per-tool total space requirement for tool group w, space type s. For each space type s, Factory Explorer calculates TRSs = w Nw SRw,s.
22.4 Travel Matrix by Move Rate

When a model includes layout areas, Factory Explorer calculates the total lot move rate between each pair of layout areas. This lot move rate captures moves that satisfy the following conditions. 1. Lot moves between two sequential steps, where both steps use a tool group with a defined layout area. 2. Lot moves between three sequential steps, where the first step and the third step use a tool group with a defined layout area, but the second step uses a tool group with no defined layout area (e.g. the middle step is a material handling step, and thus uses a tool group that does not belong to any single layout area). The two conditions above apply even if the origin layout area and the destination layout area are the same. That is, within-area lot move rates are calculated, as well as betweenarea lot move rates. For these calculations, assume the following definitions. LMRa1,a2 = Lot move rate from layout area a1 to layout area a2, LAw = Layout area for tool group w, w(s) = Tool group used by process step s, sout = Lot throughput rate for process step s, S = Set of all pairs of process steps (s1,s2) satisfying one of the above conditions (in the case of the second condition, s1 is the first process step, and s2 is the third process step). For each pair of layout areas a1 and a2, Factory Explorer calculates LMRa1,a2 = s1 s2 s1out I(LAw(s1) = a1) I(LAw(s2) = a2) I( (s1,s2) S).
22.5 Travel Matrix by Distance Rate

When a model includes layout areas and travel matrix data, Factory Explorer calculates the total lot distance rate between each pair of layout areas (where distance rate is defined as the lot move rate times the distance traveled). This calculation builds on the lot move rate calculation described in Section 22.4 of the manual. Assume the following definitions.
22.5. Travel Matrix by Distance Rate LDRa1,a2 = Lot distance rate from layout area a1 to layout area a2, LMRa1,a2 = Lot move rate from layout area a1 to layout area a2, Da1,a2 = Distance traveled by a lot moving from layout area a1 to layout area a2. For each pair of layout areas a1 and a2, Factory Explorer calculates LDRa1,a2 = LMRa1,a2 Da1,a2.
23. Reference Topics: Simulation Details
23.1 Pseudo-Random Numbers

Any one who considers arithmetica methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number -- there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method -- John von Neumann. The generation of random numbers is too important to be left to chance -anonymous (from A.Word.A.Day List). Random numbers in Factory Explorer are generated using the C version of a generator given in Chapter 7 of Law and Kelton (1991). Over 20,000 random number streams are provided, each of length 100,000. To enhance the applicability of common random numbers as a variance reduction technique (see Chapter 11 of Law and Kelton), separate streams are used wherever possible within Factory Explorer. The number of streams used during a particular run is listed in the output reports. Random number generation in Factory Explorer is affected by the FirstStream, OneStream, and AddStream options.
23.2 Simulation Event Graph

The Factory Explorer simulation module was originally modeled using the Sigma simulation prototyping system, and thus has an underlying event graph structure. The event graph for the simulation is shown in Figure 23-1. Nodes in the graph represent events, such as lot releases. Arcs are shown where the execution of an event may schedule one or more future events. Due to space constraints, scheduling conditions, time delays, and some secondary events are not shown in this figure. See the Sigma (Schruben 1991) manual for a more complete explanation of event graphs. Simulation events are listed in Table 23-1. The event name can be used with the SchedEv option to generate a schedule trace for a particular event.
23. Reference Topics: Simulation Details

Request Operator
Run
Release Enter
Seize
Load Down Indiv. Lots Factory NonSched Ramp End Load
Repair End NonSched Up Check Request
Process
End Travel
End Process
Travel Unload Exit Free Scrap End Unload
Assemble
End Delay
Delay
Figure 23-1: Factory Explorer event graph. Table 23-1: Factory Explorer simulation events.
Event Name Start Run Lot Enters Queue Lot Completes Flow Start Loading Finish Loading Start Processing Finish Processing Start Unloading Finish Unloading Interrupt Start Offline End Offline
Called When A simulation run is started. A lot enters the queue for a tool group. A lot successfully exits the system. A lot or batch starts load phase of processing. A lot or batch finishes the load phase of processing. A lot or batch starts service phase of processing. A lot or batch finishes the service phase of processing. A lot or batch starts unload phase of processing. A lot or batch finishes the unload phase of processing. A tool or operator interruption occurs. Starting a tool or operator offline time. Finishing a tool or operator offline time.
23.3. Randomized Search Trees Scrap Seize Resource(s) Release Lot(s) Release Indiv. Lot(s) Batch Statistics Clear Statistics Call User Code Show Pct Completed Free Resource Check Resource Requests Start Travel Finish Travel Start Delay Finish Delay End of Period Assemble Start NonScheduled Finish NonScheduled Ramp Model Variables A lot is scrapped. A tool is seized for processing. A lot is released into the system. An individual lot is released into the system. Statistics are batched. Statistics are cleared. User code is called. A progress message is printed to the console. A tool or operator is released. Checking requests for tools or operators. A lot or batch starts traveling to the next process step. A lot or batch finishes traveling to the next process step. A lot or batch starts the delay phase of processing. A lot or batch finishes the delay phase of processing. An analysis period is completed. An assembly lot is released into the system. Starting an factory nonscheduled period for system. Finishing an factory nonscheduled period for system. One or more model input variables are changed.
23.3 Randomized Search Trees

In numerous areas Factory Explorer must keep track of information in sorted lists. In particular, maintenance of the simulation's future-events list must be highly optimized. Factory Explorer uses a technique called randomized search trees to store sorted lists, which has proven to be highly effective. The Factory Explorer randomized search tree code was adapted from an implementation done by Dave Kohr. For more information on randomized search trees, see Aragon and Seidel (1989).
23.4 Calculating Confidence Intervals

Factory Explorer uses two different methods to calculate confidence intervals for time in system and time at individual queues. First, to calculate confidence intervals for time at a queue, Factory Explorer uses the queuing relation L = W, where L is the expected value of the limiting number at the queue, is the arrival rate into the queue, and W is the expected value of the limiting time in queue. If we let Q(t) be the number at the queue (waiting plus being served) at time t and the simulated clock runs from time 0 to time T, we can estimate L by L = T-1 Q(t) dt, where the integral goes from 0 to T. If we know , or can estimate it, we estimate W by W = L / ., Note that the exact effect of dividing by an estimate of rather than the true is unknown. To arrive at a confidence interval for our estimate of time at queue, we split time into a series of batches. Suppose the number of batches is B, and the ending time of batch b is Tb (let T0 = 0). Denote the bth batch estimate of L by
23. Reference Topics: Simulation Details Lb = (Tb - Tb-1)-1 Q(t) dt, where the integral goes from Tb-1 to Tb. Unless otherwise specified, Factory Explorer splits the output for each lot type into a default number of batches, and assumes the batch means are approximately independent, identically distributed normal random variables with unknown mean and variance. Under these assumptions, a t-confidence interval is placed about the average of the batch means. Let G be the grand batch mean G = B-1 Lb. Let s2G be the estimated variance of G, s2G = (B-1)-1 ( Lb - G)2. Then the approximate 95% confidence interval for the expected number in queue is G +/- tB-1(0.05) (s2G / B)1/2, where tN(c) is the (1-c)/2 quantile of the t-distribution with N degrees of freedom. Proceeding boldly, we use G / +/- tB-1(0.05) (s2G / B)1/2 / as our confidence interval for estimated time at queue. To estimate time in system, Factory Explorer uses transaction observations rather than the relation L = W. The reason for this choice is that scrapping is possible, and if we were to use L = W, we would be estimating the time in system for all lots, including those that are scrapped. Usually, we only wish to estimate time in system for those lots that exit normally. Time is batched as before. Denote by Wb an estimate of the mean time in system of lots exiting normally during the bth batch. Factory Explorer does not use the average of time in system observations for Wb. Instead, it uses the average of (waiting time + expected service time), since the expected service time for a lot can be calculated when it starts service, and this figure has a lower variance than the average of (waiting time + service time). Let G be the grand batch mean G = B-1 Wb. Let s2G be the estimated variance of G, s2G = (B-1)-1 (Wb-G)2. Then the approximate 95% confidence interval for the expected time in system is G +/- tB-1(0.05) (s2G / B)1/2. Confidence intervals for the variance of the time in system distribution are calculated in a similar fashion, using batch estimates of the variance. Using the simulation ending time endtime (specified using the RunLen endtime option), the batch size is calculated as Batch Size = endtime / Number of Batches, and the ending time of batch b is
23.5. Testing for Initialization Bias Tb = b * Batch Size. The default number of batches is small, on the conservative side, so the default batch length is large. It may be possible to increase the number of batches with the NBatch option, and hence lessen the width of the confidence interval, without lowering the probability that the confidence interval does cover the true expected value. The confidence level, unless specified with the CILevel option, defaults to 95%. That is, if all the assumptions about the independence and normality of the data were satisfied, the confidence intervals reported would cover the true values approximately 95% of the time. It is very important to note that this coverage level is appropriate only for examining confidence intervals one at a time. If multiple confidence intervals are examined, the probability that all hold simultaneously is at least 1 - (1 - (Confidence Interval Level)/100) * Number of Confidence Intervals. For example, if a model has five products, then the probability that all five time in system confidence intervals hold simultaneously is at least 1 - (1 - 0.95) * 5 = 0.75. Thus, even if all independence and normality assumptions are satisfied, multiple simultaneous confidence intervals can not be guaranteed to cover all the true values with a very high probability. Quantiles of the t-distribution are obtained from C versions of the routines VSTUD and VNORM given in Bratley, Fox and Schrage (1987).
23.5 Testing for Initialization Bias

When using Factory Explorer to estimate steady-state performance parameters of a system (long-run performance, independent of any set of initial conditions), it is necessary to consider the effects of initialization bias. That is, the distribution of the time in system for lots early on in the simulation run does not match those later in the run. For example, if the model is started with no lots present, early lots will see very little congestion, and hence will have lower mean time in system, compared to later lots. Plotting the time in system observations, and averaging across replications as described in Welch (1983), is often a good way to identify the effect of initial conditions on the output. Another way is to test the hypothesis that the time in system batch means are all statistically equal. One test of this hypothesis is detailed in Schruben et. al. (1983), and is implemented in Factory Explorer. Briefly, the test involves forming a test statistic that is sensitive to changes in the batch means, and which converges in distribution to a known form. Let Wb be the average time in system for lots in the bth batch, B the number of batches, s2G the estimated variance of the grand batch mean, and define Sk to be the cumulative sum of batch means, S k = Wb , where the summation runs from 1 to k. Let Yk the mean of the first k batches, Yk = Sk / k. The test statistic given in Schruben et. al. (1983) is
23. Reference Topics: Simulation Details T = (45)1/2 (B3/2 sG)-1 k (1 - k/B) k (YB-Yk). In this form, the calculation of T requires keeping all the batch means until the end of the run. However, with some algebraic manipulation, we can use the alternate form T = (45)1/2 (B3/2 sG)-1 ( YB (B+1)(B-1) / 6 - k Sk + B-1 k k Sk ), that can be calculated as the simulation runs. Since we perform a 2-sided test (to protect against both positive and negative initial bias), Factory Explorer uses the absolute value of this test statistic, |T|. To compute the p-value of the statistic, Factory Explorer calculates the area outside -|T| and |T| for the t distribution with B-1 degrees of freedom. Since the t distribution is symmetric, this amounts to calculating 2(1-Fb-1(|T|)), where Fb(x) is the distribution function for the t distribution with b degrees of freedom. The p-value of the statistic is the lowest significance level at which we would reject the hypothesis that the batch means are equal. The lower the p-value, the more evidence we have for the existence of statistically significant differences among the batch means. Since the formation of confidence intervals for the mean time in system depends on identically distributed batch means, the run length should be increased until the p-value for the initialization bias test falls consistently above a reasonable significance level, say 0.10, before other statistics given in the output file can be viewed with confidence.
23.6 Estimated Number of Visits

In its output report, Factory Explorer displays for each lot type the estimated number of times a lot visits each queue before exiting the system. These estimates are only for those lots that successfully exit the system, not for those that are scrapped along the way. This section of output statistics is included so that a more complete picture of queuing bottlenecks can be achieved. For instance, suppose we estimate the delay at queue one to be ten hours, while at queue two to be thirty hours. However, if each lot visits the first queue an average of ten times, while visiting the second tool only once, the total delay contributed by queue one is a much larger percentage of the overall time in system than that contributed by queue two. It might be more appropriate, then, to concentrate resources on lowering the delay at queue one.
23.7 Operator Dispatching

In models with operators, each operator group can specify a particular dispatch rule. If no rule is specified for an operator group, Factory Explorer uses FIFO. During the simulation, the operator's dispatch rule interacts with the dispatch rule(s) specified at tools served by the operator. This interaction can be quite complex, and is the focus of this section. First, it is important to understand the concept of operator requests. Operator requests are generated whenever an action is required by an operator. These requests are of six basic types: 1. Setup requests are generated when a lot arrives to a tool group that requires setups.
23.7. Operator Dispatching 2. Load requests are generated when a lot arrives to a tool that requires an operator for processing. 3. Process requests are generated when a lot finishes the load phase of service. 4. Unload requests are generated when a lot finishes the process phase of service. 5. Travel requests are generated when a lot finishes the unload phase of service, and an operator is required for travel to the next process step. 6. Repair requests are generated when a tool experiences an interruption that requires an operator for repair. Conceptually, one can think of operator requests as being stored in a big in-basket, with one in-basket for each operator group. When an operator becomes free, it searches through its in-basket and chooses a request to complete. When a request is completed, it is removed from the in-basket and discarded. The complexity arises in the area of request selection. In Factory Explorer, an operator follows these steps when selecting a request to complete: 1. Separate the in-basket of requests into two piles: setup requests, and all other requests (load, process, unload, travel, and repair). 2. Complete the oldest non-setup request, if any, then return to step 1. 3. Otherwise, separate the pile of setup requests into stacks by tool group. 4. For each tool group setup request stack, find the lot that should be served next, based on the tool group's dispatch rule. Pull each of these lot requests into a separate pile, and call this pile the candidate requests. Note that the tool group setup request stacks contain only setup requests that can be completed by this operator. 5. From the requests in the candidate request pile, find the lot that should be served next, based on the operator group's dispatch rule. Complete this request, then return to step 1. Non-setup requests are separated from load requests because it may not be possible to directly compare non-setup requests with setup requests on the basis of dispatch rules. For example, if the dispatch rule for an operator is earliest-due-date, it is difficult to use that rule to compare a repair request with a setup request (what is the duedate of a repair request?). Or, if the dispatch rule is priority-full batch-FIFO, it is difficult to use that rule to compare a process or an unload request with a setup request (what does full batch preference mean for a lot that is already being processed?). Non-setup requests are processed in FIFO order in advance of setup requests because that appears to be a reasonable approximation of common factory operating practice. Many times in the simulation, the physical request generation and selection process is skipped. For example, if an operator is required for 100% of load, Factory Explorer assumes that the operator performing the load phase of service will also perform the process phase. Thus, at the completion of the load phase, the same operator immediately begins the process phase. No operator request is generated, and the operator does not search through its list of requests. The same type of behavior can occur at the junction between the process phase and unload phase, and between the unload phase and travel.
24. Reference Topics: Verification Tests

Credibility is not a gift--it has to be earned. It is built up one step at a time and supported by facts, and by consistency. Even more, credibility is never owned; it is rented, because it can be taken away at any time -- Pedro Aspe, 1993. We detail in this section the list of tests in Factory Explorer's verification suite. Several of the tests use single stage queuing models. We reference these models using Kendall's A/B/s notation, where A is the distribution of inter-release times, B is the distribution of service times, and s is the number of servers. Common distributions are M (Markov, or exponential), G (general), and D (deterministic, or constant).
24.1 M/M/s Queue

The M/M/s queue has exponentially distributed interarrival and service times, and s servers. Let be the arrival rate, the service rate, and = /(s ) the traffic intensity. For either first-come-first-served (also known as first-in-first-out, abbreviated FIFO), or last-come-first-served (LIFO) dispatch rules, the mean of the limiting time in system distribution is given by us (s (1-)2 )-1 + -1, where us = (/)s (s!)-1 [ ( (/)i (i!)-1 ) + (/)s (s!(1-))-1 ]-1, where the summation runs from 0 to s-1. When the dispatch rule is first-come-firstserved, the variance of the limiting time in system distribution is given by us((s )2 (1-)4)-1 (2-2-us) + -2. When the rule is last-come-first-served, the variance is given by us((s )2 (1-)4)-1 (2-us) + -2. In each of these variance calculations, us is as given above. Means and variances are listed in Table 24-1 for several arrival and service rates, with varying number of servers
24. Reference Topics: Verification Tests and dispatch rule. In the Factory Explorer verification library, these exact calculations are compared with simulation estimates from very long runs.
Table 24-1: Verification table for M/M/s Queue
Number Mean of Servers Arrival s Rate 1 2 10 15 0.125 1.25 0.4 0.1
Mean Traffic Service Intensity Rate 0.5 1.53846 0.055 0.01 0.25 0.41 0.73 0.67
Limiting Limiting Time in Time in System FIFO System Mean Variance 2.667 0.778 20.49 102.04 7.111 0.547 351.07 10078
Limiting Time in LIFO System Variance 8.296 0.643 414.09 10241
24.2 M/G/1 Queue

The M/G/1 queue has exponentially distributed interarrival times, general service times, and a single server. The dispatch rule is first-come-first-served. Let be the arrival rate, the service rate, and = / the traffic intensity. From Equation 6.25 of Prabhu (1981), the mean of the limiting time in system distribution is given by E[S02] (2 (1-) )-1 + -1, or, if we substitute in the variance plus the squared mean for the second moment of the service time distribution, ( Var[S0] + -2) (2(1-))-1 + -1. This limiting value is calculated in Table 24-2 for several service time distributions and values of and .
Table 24-2: Verification table for M/G/1 Queue
Service Time Distribution u(2,4) u(5,10) c(3) c(7.5) up(3,33.3) tp(5,50)
Mean Arrival Rate 0.10 0.05 0.10 0.05 0.10 0.067
Mean Service Rate 1/3 1/7.5 1/3 1/7.5 1/3 1/5
Traffic Limiting Time in System Intensity 0.300 3.67 0.375 9.83 0.300 3.64 0.375 9.75 0.300 3.67 0.333 6.30
24.3 M/M/1 Queues in Series

Consider an assembly line of three machines, with each lot having to visit the machines along the line exactly once, in sequence. If the interarrival time to the first machine or queue is exponentially distributed, and service times at all machines are exponentially distributed, then according to Section III.4 of Asmussen (1987), the limiting input process to each queue is Poisson (interarrival times are exponentially distributed), and we may calculate limiting expected time in queue separately for each queue. Suppose the
24.4. M/M/1 Queues in Series with Scrap arrival rate to the system is = 1.0, and the service rates at the three queues are 1 = 2.5, 2 = 2.0, and 3 = 2.5. For simplicity, suppose each queue has exactly one server. Thus, the total limiting expected time in system should be (1 - )-1 + (2 - )-1 + (3 - )-1 = 0.67 + 1.0 + 0.67 = 2.33
24.4 M/M/1 Queues in Series with Scrap

We test whole-lot scrapping here only, so that we may compare with analytic results for M/M/1 queues in series. Suppose we have three machines in series, with some scrap occurring after steps one and two. If the interarrival times to the first machine are exponentially distributed, and all service times are exponentially distributed, then we can analyze the limiting expected time in queue separately for each queue, as before. The only modification is that the arrival rate to each queue changes, as some lots are removed due to scrapping. Let the arrival rate to machine one be 1 = 1.0. If approximately one out of every ten lots is scrapped during processing at machine one, then the arrival rate to machine two is 2 = 1 * 0.9 = 0.9. If approximately one out of every five lots is scrapped during processing at machine two, then the arrival rate to machine three is 3 = 2 * 0.8 = 0.72. Suppose as before that the three processing rates are 1 = 2.5, 2 = 2.0, and 3 = 2.5. Then, the total limiting expected time in system should be (1 - 1)-1 + (2 - 2)-1 + (3 - 3)-1 = 0.67 + 0.91 + 0.56 = 2.14.
24.5 M/M/1 Queues in Series with Rework

We test whole-lot rework here only, so that we may compare with analytic results for M/M/1 queues in series. Suppose we have two machines in series, with some possibility of rework at step one. By rework, we mean that there is a certain probability that for every lot leaving step one, it may have to visit a third machine for processing, then pass through step one again. Suppose all three machines have processing rate = 2.0. Let the arrival rate into the system be = 1.0. However, that is not the effective arrival rate that machine one sees, due to the possibility of rework. Let the probability of rework be p = 0.20, that is, approximately one out of every five lots will be reworked. Lots that are reworked visit a rework machine, then return to machine one. Lots that are not reworked visit machine three, then exit the system. To calculate the analytic limiting expected time in system, we need first to calculate the effective arrival rate to all three machines, given that rework can occur. First, the arrival rate to machine one is incoming lots at a rate of , plus reworked lots at a rate of p, plus those lots that are reworked twice at a rate of p2, etc. Thus, 2 = pn = (1-p)-1 = 1.25. The arrival rate to the rework machine is the probability of rework times the effective arrival rate into machine one, r = p1 = 0.25. The arrival rate to machine two is the exit rate of machine one (that must be its arrival rate 1) minus the rate of lots being reworked (r),
24. Reference Topics: Verification Tests 2 = 1 - r = 1.0. Finally, the expected time in system is the expected number of visits to each queue times the expected time at queue, added together, 1 ( (-1))-1 + r ( (-r))-1 + 2 ( (-2))-1 = 2.81.
24.6 M/M/1 Queue with Two Priority Classes

Consider a single server with two classes of lots, one receiving high priority, the other receiving low priority. The dispatch rule is head-of-the-line, in that high priority lots that arrive during the service of a low priority lot do not interrupt service. Rather, the high priority lot moves ahead of any low priority lots waiting for service. Within a priority class, service is first-come-first-served. Let H, L denote the arrival rates for the two classes. Let H, L denote the service rates for the two classes. Denote the traffic intensities by H = H/H, L = L/L, and assume H+L < 1. We obtain the limiting expected queuing delay from Table 4.4 of Prabhu (1981), and after adding the expected service time, we find the expected time in system for high priority lots to be (1-H)-1 + H-1, and for the low priority lots to be ((1-H)(1-H-L))-1 + L-1, where = L L-2 + H H-2. Suppose H = 0.25, L = 0.125, H = 2.0, L = 0.5. Then = 0.5625, and the expected time in system for high priority lots is 0.5625 / 0.875 + 1 / 2.0 1.14. For low priority lots, the expected time in system is 0.5625 ((0.875)(0.625))-1 + 1 / 0.5 3.03.
24.7 M/M/1 Queue with Loading and Unloading

Consider a single server and single lot class, but each service time consists of three parts: loading the lot, servicing the lot, and unloading the lot. The dispatch rule is first-in-firstout. We can use the formula given before for the M/G/1 queue to calculate the limiting expected time in system, where the service time has three parts, E[S02] (2 (1-) )-1 + -1, Suppose = 0.05, and the three parts of the service time are distributed exponentially with means 1/1 = 1.0, 1/2 = 4.0, and 1/3 = 2.0. Then -1 = 1 + 2 + 3 = 7.0. Now the second moment of the service time, E[S02] = Var[S0] + E[S0]2 = 1-2 + 2-2 + 3-2 + -2 = 70.0,
24.8. Verification Test Suite since the service time is the sum of three independent exponential random variables. The traffic intensity = 0.35. Hence the limiting expected time in system should be (0.05 * 70.0)(2*(1-0.35))-1 + 7.0 9.7.
24.8 Verification Test Suite

The following tests are contained in Factory Explorer's verification test suite. If a test refers to a specific Factory Explorer option, see Chapter 13 of the manual for more detailed option information. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. clstrtl1: Capacity calculations for tool groups with tool states (cluster tools). SSG-S: Capacity calculations for tool groups with tool states (cluster tools). SSG-G: Capacity calculations for tool groups with tool states (cluster tools). A3: Capacity calculations for tool groups with tool states (cluster tools). midsplt1: Simulation avg. cycle time results for mid-process split with subsequent recombine. midsplt2: Simulation avg. cycle time results for mid-process split. buffer1: Simulation results with tool group buffers. buffer2: Simulation avg. inter-arrival time with tool group buffers. buffer3: Simulation - tool group input buffers are not exceeded. setupop5: Simulation %Setup/Free/Work for tools with designated setup operators. setupop6: Simulation %Setup/Free/Work for tools with designated setup operators not required 100%. setupop4: Testing free and re-acquisition of setup operator when not required 100%, and operator busy. setupop3: Testing free and re-acquisition of setup operator when not required 100%, and operator offline. setupop2: Testing free and re-acquisition of setup operator when not required 100%. setupop1: Capacity calculations with many setup IDs. indiv10: Capacity analysis and simulation results for models where an individual lot specifies a step that is not active for its specified product, and no subsequent steps are active for this prduct. indiv9: Capacity analysis and simulation results for models where an individual lot specifies a step that is not active for its specified product. tardy3: Sim %Tardy statistics when ClearStats is enabled. toolst1: Tool-state outputs. minmax10: Mintools with two free tools being reserved. minmax9: Mintools with multiple setup groups. minmax8: Mintools with multiple setup groups. minmax7: Mintools with multiple setup groups, and not all groups specify mintools. setup22: Setup-avoidance with mintools and multiple setup groups. setup21: Setup-avoidance with mintools/maxtools and maxqueue. move7: Move-rate prediction for alternative steps to the following step. move6: Move-rate prediction for step to a following alternative step. Factory Explorer 401
17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
24. Reference Topics: Verification Tests 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. move5: Move-rate prediction for active/inactive steps. bsyhld5: Sim %Busy Held when model includes factory non-scheduled time. bsyhld4: Sim %Busy Held when HoldToolPct is used, and each toolgroup has multiple tools. bsyhld3: Sim %Busy Held when HoldToolPct is used. bsyhld2: Sim %Busy Held when lot is scrapped before reaching end of hold-tool region. bsyhld1: Sim %Busy Held for simple model. bneckpr1.fx2: Simple test of bottleneck resource chart with product capacity data. rework3.fx2: Predicted rework% and non-rework% when model includes tools that are used both inside and outside rework loops and have per-unit process times. eitem1.fx2: Units-processed expense item. eitem2.fx2: Non-scheduled time (factory) expense item. eitem3.fx2: Non-scheduled time (factory and tool group) expense item. eitem4.fx2: Multiple products, same process times. eitem5.fx2: Multiple products, different process times. eitem6.fx2: Unscheduled downtime expense item. eitem7.fx2: Scheduled downtime expense item. eitem8.fx2: Engineering time expense item. eitem9.fx2: Standby time expense item. eitem10.fx2: Engineering time (multiple tools) expense item. eitem11.fx2: Productive time expense item. eitem12.fx2: Multiple expense items, expense item exception. eitem13.fx2: Multiple expense items, no exceptions. prdst18.fx2: Verification of product-specific process steps. gamma5.fx2: Model is checking gamma distribution (10,10). gamma4.fx2: Model is checking gamma distribution (1,2). gamma3.fx2: Model is checking gamma distribution (1,.5). gamma2.fx2: Model is checking gamma distribution (.5,1). gamma1.fx2: Model is checking gamma distribution (1,1). atcs4.fx2: Verification of ATCS rule with due dates and 2products. atcs3.fx2: Verification of ATCS rule with due dates. atcs2.fx2: Verification of ATCS rule with priorities. atcs1.fx2: Verification of ATCS rule with no priorities. weibull5.fx2: Model is checking weibull distribution (10,10). weibull4.fx2: Model is checking weibull distribution (1,2). weibull3.fx2: Model is checking weibull distribution (1,.5). weibull2.fx2: Model is checking weibull distribution (.5,1). weibull1.fx2: Model is checking weibull distribution (1,1). delscr3.fx2: ltgt8.fx2: Model containing goto's on alternative steps and multiple productspecific alternative steps in a sequence. altgt7.fx2: Model containing goto's on alternative steps and product-specific steps and multiple products.
38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68.
24.8. Verification Test Suite 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. altgt6.fx2: Simple model containing goto's on alternative steps and productspecific steps. altgt5: Model with goto's on alternative steps, where the goto percentage is less than 100%. altgt4: Model with goto's on alternative steps, where the alternative step is a rework skip-to step. altgt3: Model with goto's on alternative steps, where the alternative step is also a goto destination. altgt2: Model with rework and goto's on alternative steps. altgt1: Basic model with goto's on alternative steps. setup20: Capacity loading calculations for resources with setup-avoidance enabled. rework2: Non-rework and rework lot arrival counts on process step detail worksheet. unitscrap: Input for init scrapped, lot scrapped, & Sim line yield columns in Factory Summary worksheet. unitar1: Check for unit arrivals with random lot size u(1,3). minmax6: Min tools setup when a tool group specifies multiple setup groups. minmax5: Max tools setup when a tool group specifies multiple setup groups. qd4: Tool group simulation average and max queue delay for multiple periods. qd3: Tool group simulation average and max queue delay when there is queuing. qd2: Tool group simulation average and max queue delay when there is no queuing. qd1: Tool group simulation average and max queue delay when there are no arrivals. dgr11: Check for Daily Going Rate for 2 products (one has 1 toolgroup, another has 2 tool's groups; both with capacity = 50%). tardy1: Tardy for 3 replication and clearstats after first. tardy2: Tardy for 3 replication and clearstats after first and 0 lot arrival on third. ltime8: Different type for lead time & different type for lead time um for every period. ltime7: Lead time as a float & with lead time um not by default. ltime6: Lead time with lead time um not by default. ltime5: Lead time as a float. ltime4: Lead time for third period, the same as for the first one. ltime3: Lead time for second and fourth periods. ltime2: Check lead time for all period, started from second. ltime1: Check lead time. dgr10: Check for Daily Going Rate for 3 period with different data. dgr9: Check for Daily Going Rate for 2 products (one has 1 toolgroup, another has 2 tool groups). dgr8: Check for Daily Going Rate for 2 tool groups (one has 2 interruptions (120% down)). dgr7: Check for Daily Going Rate for 2 tool groups (one has 0 number of tools). dgr6: Check for Daily Going Rate for 2 tool groups (one has inf number of tools). dgr5: Check for Daily Going Rate for 2 tool groups (one has capacity buffer).
24. Reference Topics: Verification Tests 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. dgr4: Check for Daily Going Rate for one tool & one operator groups with two operators. dgr3: Check for Daily Going Rate for one tool & one operator groups. dgr2: Check for Daily Going Rate for two tools. dgr1: Check for Daily Going Rate. holdtl13: Check for HoldToolPct statement with two tools. holdtl12: Check for HoldToolPct statement. minq5: Simulation results for MINQUEUE & MINDELAY in the same ID. minq4: Simulation results for MINQUEUE & MINDELAY in different IDs.. minq3: Simulation results for MINDELAY in different IDs. minq2: Simulation results for MINQUEUE & MAXDELAY in the same ID. minq1: Simulation results for MINQUEUE in different IDs. rplan1: Check resource plan worksheet. avlots4: Check average lot size for lot with scrap (two steps & two products). avlots3: Check average lot size for lot with scrap (two steps). avlots2: Check average lot size for lot with scrap (one step). avlots1: Check average lot size. cost12: Product cost calculations for overhead cost from Routing Worksheet. cost14: Overhead cost & material cost from Routing Worksheet with scrap in Step2. cost13: Overhead cost & material cost from Routing Worksheet with scrap in Step1. pcost39: Material & consumable costs with initial wip. indiv8: -ReleasePct for models with individual lots requiring DelLots. ltsplt20: Lot-splitting inside a rework loop. ltsplt19: Lot-splitting with scrap but no unsplit step. ltsplt18: Cycle-time contribution for lot-splitting with no unsplit step. ltsplt17: Lot-splitting for large lot size but no unsplit step. ltsplt16: Lot-splitting with rework but no unsplit step. ltsplt15: Lot-splitting with backward goto but no unsplit step. ltsplt14: Lot-splitting with forward goto but no unsplit step. ltsplt13: Capacity analysis for models with lot-splitting but no unsplit step. ltsplt12: Estimating WIP in model with lot-splitting but no unsplit step. ltsplt11: Simple lot-splitting with no unsplit step. pcost38: Overhead in one OpGroup. pcost37: Overhead in OPGroup and TravelOpGroup. pcost36: Overhead in two OpGroups. nsch3: Flag NonSched in OpGroup And TravelOpGroup. nsch2: Flag NonSched in OpGroup. nsch1: Flag NonSched in ToolGroup. goto1: Validation of 100% backward goto's. indiv7: Lot tardy statistics. indiv6: Lot tardy statistics. sttype1: Process step types. nrgoto3: Non-random goto's where sum of goto percentages is less than 100. nrgoto2: Non-random goto's with unequal goto percentages.
24.8. Verification Test Suite 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. nrgoto1: Non-random goto's with equal goto percentages. altst14: Operator group and operation I.D. fields on alternative steps summary worksheet. cap17: Input rates on tool group capacity by product worksheet, when model includes setup. cap16: Input rates on tool group and operator group capacity by product worksheets. minmax4: Min/max tools setup when a tool that's never been setup must be held idle to enforce maxtools rule. minmax3: Min/max tools setup when a tool that's never been setup must be held idle to enforce mintools rule. minmax2: Min/max tools setup when one I.D. specifies a minimum, and a different I.D. specifies a maximum. minmax1: Min tools setup when all I.D.'s specify a minimum. prdst17: Raw process time calculation for models with goto's specified for active/inactive steps. prdst16: Raw process time calculation for models with scrap specified for active/inactive steps. setup19: Calculations on tool group setups worksheet. indiv5: Capacity analysis for split-lots in models with individual lots. indiv4: Capacity analysis for rework in models with individual lots. indiv3: Capacity analysis for multi-step models with individual lots. indiv2: Capacity analysis for multi-product models with individual lots. indiv1: Capacity analysis for single-product models with individual lots. between4: Interruption between option for two tool groups. between3: Interruption between option with stagger. between2: Multiple interruption between option for one tool group. between1: Interruption between option for one tool group. rework1: Rework-related WIP record outputs. adjpct9: Adjusting transform and assembly percentages when the original percentages specify zero percent transformed/assembled for a downstream product. adjpct8: Adjusting transform and assembly percentages when down-stream products specify zero unit throughput rates. ltsplt10: Capacity analysis for batch tools inside split-lot regions. holdtl11: Individual lots that are placed in the middle of hold regions. schsht8: Schedule worksheet outputs. schsht7: Schedule worksheet outputs. schsht6: Schedule worksheet outputs. schsht5: Schedule worksheet outputs. schsht4: Schedule worksheet outputs. schsht3: Schedule worksheet outputs. schsht2: Schedule worksheet outputs. schsht1: Schedule worksheet outputs. opn8: Operation results for simple two step model when there is queuing and multi-unit lots.
167. 168. 169. 170. 171. 172. 173. 174. 175. 176. 177. 178.
24. Reference Topics: Verification Tests 179. 180. 181. 182. 183. 184. 185. 186. 187. 188. 189. 190. 191. 192. opn7: Operation results for simple two step model when there is queuing. opn6: Operation results for simple three step when model when first and last steps specify same operation, but middle step has no operation. opn5: Operation results for simple two step model with both steps having no operation. opn4: Operation results for simple two step, single operation model with first step having no operation. opn3: Operation results for simple two step, single operation model with last step having no operation. opn2: Operation results for simple two step, single operation model. opn1: Operation results for simple two step, two operation model. cprio4: Check-request priorities for alternative operator groups. cprio3: Check-request priorities for alternative tool groups. cprio2: Check-request priorities for hold tool and tool groups when later tool groups have priority. cprio1: Check-request priorities for hold tool and tool groups when earlier tool groups have priority. pramp24: Simulation-based WIP estimates when lots are in queue during a ramp point. altst13: Alternative steps when steps specify same tool group and same operator group but different process times. prdst15: Capacity analysis and simulation results for models with hold steps that specify active/inactive steps, and steps within the hold region specify active/inactive steps. prdst14: Capacity analysis and simulation results for models with hold tool regions that contain active/inactive steps. maxq5: Simulation results for a mixture of MAXDELAY and MAXQUEUE. maxq4: Simulation results for a mixture of MAXDELAY and MAXQUEUE. maxq3: Simulation results for MAXDELAY. maxq2: Simulation results for MAXDELAY. maxq1: Simulation results for MAXQUEUE. altst12: Alternative steps when steps specify same tool group but different operator group. prdst13: Capacity analysis and simulation results for models with active/inactive steps and nested rework loops. prdst12: Capacity analysis and simulation results for models with active/inactive steps and rework. prdst11: Capacity analysis and simulation results for models with active/inactive steps and alternative process steps. prdst10: Capacity analysis and simulation results when active/inactive steps specify lot-splitting. prdst9: Deadlock detection when model contains active/inactive steps. prdst8: Capacity analysis and simulation results when active/inactive steps specify goto's. prdst7: Validation of models where hold-steps specify active/inactive products. prdst6: Validation of models where some batch processing steps are inactive.
193. 194. 195. 196. 197. 198. 199. 200. 201. 202. 203. 204. 205. 206. 207.
24.8. Verification Test Suite 208. 209. 210. 211. 212. 213. 214. 215. 216. 217. 218. 219. 220. 221. 222. 223. 224. 225. 226. 227. 228. 229. worksep1: Capacity analysis calculations of rework%, non-rework%, and work%. prdst5: Capacity calculations when last step in process flow is inactive. sugg6: Suggested exact and whole operator counts, when operator is over capacity. sugg5: Suggested exact and whole operator counts, when operator is under capacity. sugg4: Suggested exact and whole tool counts, when initial quantity of tools is zero. sugg3: Suggested exact and whole tool counts, special cases (infinite servers, infinite loading, etc). sugg2: Suggested exact and whole tool counts, when tool is over capacity. sugg1: Suggested exact and whole tool counts, when tool is under capacity. unoff8: Unique offline types effective dates, two unique interruption names. unoff7: Unique offline types effective dates, two unique interruption names. unoff6: Unique offline types two unique interruption names, three interruptions. unoff5: Unique offline types operator group and tool group with different interruption names. unoff4: Unique offline types operator group and tool group with same name interruption. unoff3: Unique offline types one operator group interruption. unoff2: Unique offline types one tool group interruption. unoff1: Unique offline types no interruptions. prdst4: Goto's to an inactive step for product-specific process steps (inactive product specified). prdst3: Simple model with product-specific process steps (inactive product specified). prdst2: Goto's to an inactive step for product-specific process steps (active product specified). prdst1: Simple model with product-specific process steps (active product specified). adjpct7: Adjusting assembly percentages when products are transformed (fixed percentages) and then assembled to match demand. transf7: Throughput rate calculations when a product is transformed into multiple products, and these products specify unit throughput rates that don't match, and transform percentages are fixed. transf6: Throughput rate calculations when a product is transformed into multiple products, and one of these products specifies a unit throughput rate, and transform percentages are fixed. adjpct6: Adjusting transform percentages when resulting products are then assembled into different products. adjpct5: Adjusting transform percentages when resulting products are then assembled into one product. adjpct4: Adjusting assembly percentages with different assembly requirements. adjpct3: Adjusting assembly percentages in a simple model. adjpct2: Adjusting transform percentages with different transform multipliers. adjpct1: Adjusting transform percentages in a simple model.
230.
231. 232. 233. 234. 235. 236.
24. Reference Topics: Verification Tests 237. 238. 239. 240. 241. 242. 243. 244. 245. 246. 247. 248. 249. 250. 251. 252. 253. 254. 255. 256. 257. 258. 259. 260. 261. 262. 263. 264. 265. 266. ctcont4: Cycle time contribution queue delay estimates for multiple replications. cbuff2: Capacity buffer. cbuff1: Capacity buffer. sramp26: Ramping of step data changing tool group from batch to non-batch tool while lots are in queue. sramp25: Ramping of step data changing tool group from non-batch to batch tool while lots are in queue. sramp24: Ramping of step data changing operator group while lots are in queue. sramp23: Ramping of step data changing tool group while lots are in queue. rstats8: Line yield and throughput outputs on Factory Summary Worksheet. rstats7:Input rate and exit rate outputs on Factory Summary Worksheet. rstats6: Release rate output on Factory Summary Worksheet. rstats5: Cost per good unit output on Factory Summary Worksheet. rstats4: Capacity loading output on Factory Summary Worksheet. clrst2: Replication summary cycle time output in models with ClearStats but no StartDate. pcost35: Product cost with unit scrap and per-unit process times. pcost34: Summary product cost output. pramp23: Ramping of product data Use of -ReleasePct with multiple replications when the mix is changing during the model run. sramp22: Ramping of process step data changing the operator group required at a step while lots are in queue. delscr2: Use of -DelScrap in models with transform. tramp46: Ramping of tool group data clock-based interrupt that lasts across a period when the number of tools is reduced and then increased. tramp45: Ramping of tool group data adding a tool in the middle of an factory nonscheduled period. pramp22: Ramping of product data lowering the product lot size while some lots are in the middle of rework. holdtl10: Tool group capacity by product outputs for models with multiple products and hold tool regions. gclock4: Group clock interrupts that occur in the middle of factory nonscheduled periods. altst11: Use of -WriteEstAlt in models with alternative steps that are never visited. waitop2: Tool group %Busy waiting for operator statistic. waitop1: Tool group %Free waiting for operator statistic. tramp44: Ramping of tool group data nonscheduled% estimate when number of tools in a tool group is reduced during the run. tramp43: Ramping of tool group data changing load% when load time lasts across ramp point boundary. tramp42: Ramping of tool group data changing process% when process time lasts across ramp point boundary. tramp41: Ramping of tool group data clock downtimes across periods where the number of tools is temporarily changed to zero.
24.8. Verification Test Suite 267. 268. 269. 270. 271. 272. tramp40: Ramping of tool group data group clock downtimes across periods where the number of tools is changed and even goes to zero. tramp39: Ramping of tool group data starting and stopping of downtimes when number of tools is being ramped. cflows1: Testing -CompareFlows for extra operation I.D. in the middle of a process flow. cflows2: Testing -CompareFlows for missing operation I.D. in the middle of a process flow. cflows3: Testing -CompareFlows for same operation I.D. listed multiple times with blank operation I.D. in between within process flow. cflows4: Testing -CompareFlows for missing operation I.D. at beginning of comparison flow and model with blank operation I.D.'s at beginning of process flow. cflows5: Testing -CompareFlows for missing operation I.D. at end of comparison flow. cflows6: Testing -CompareFlows for missing several operation I.D.'s at the end of comparison flow. cflows7: Testing -CompareFlows for extra operation I.D.'s after the end of the process flow. cflows8: Testing -CompareFlows for extra operation I.D.'s after the end of the process flow and process flow ends with several blank I.D.'s. cflows9: Testing -CompareFlows for combination of missing and extra operation I.D.'s. cflows10: Testing -CompareFlows for first I.D. in the model not equal to any I.D. in the comparison flow, and first I.D. in comparison flow not equal to any I.D. in the model. cflows11: Same as cflows10, but for multiple I.D.'s. cflows13: Testing -CompareFlows for extra process at end of model. cflows14: Testing -CompareFlows for missing process at end of comparison flow. cflows15: Testing -CompareFlows for combination of missing processes at the end and extra processes at the beginning of flows. cflows16: Testing -CompareFlows for combination of extra processes at the middle and at the end of the model, plus some combination of extra I.D.'s inside one of the processes. cflows17: Testing -CompareFlows for missing and extra I.D.'s at the end and beginning of next to last process. cflows18: Same as cflows17, but missing last process. cflows19: Same as cflows17, but extra last process. pramp21: Use of -ReleasePct and -ReleaseRate in models with ramped product volume specifications (release lists, start rates, throughput rates). altst10: Estimated alternative step percentage based on simulation. rstats3: Replication outputs total fixed cost. rstats2: Replication outputs suggested capacity loading. rstats1: Replication outputs gross margin. oramp9: Use of -WriteExcel and -UseSugg for models with ramp data. tramp38: Use of -WriteExcel and -UseSugg for models with ramp data.
273. 274. 275. 276. 277. 278.
279. 280. 281. 282. 283.
284. 285. 286. 287. 288. 289. 290. 291. 292. 293.
24. Reference Topics: Verification Tests 294. 295. 296. 297. 298. 299. 300. 301. 302. 303. 304. 305. 306. 307. 308. 309. 310. 311. 312. 313. 314. 315. 316. 317. 318. 319. 320. 321. 322. 323. 324. 325. sramp21: Ramping of process step data hold tool. sramp20: Ramping of process step data within-process lot splitting. sramp19: Ramping of process step data alternative step percentages. sramp18: Ramping of process step data travel operator groups. sramp17: Ramping of process step data setups when number of setup groups changes during run. sramp16: Ramping of process step data setups. sramp15: Ramping of process step data rework percentages. sramp14: Ramping of process step data scrap percentages. sramp13: Ramping of process step data goto percentages. sramp12: Ramping of process step data change of operator group while lot is being processed. sramp11: Ramping of process step data operator groups. sramp10: Ramping of process step data setting lot priorities. sramp9: Ramping of process step data adjusting lot priorities. sramp8: Ramping of process step data setting lot priorities to default values. sramp7: Ramping of process step data operation I.D.s. tramp37: Ramping of tool group data stagger first interruption. tramp36: Ramping of tool group data repair operator group and repair%. holdtl9: Freeing of hold tool when free after step is an alternative process step. holdtl8: Freeing of hold tool when hold tool region contains alternative process steps. sramp6: Ramping of process step data extra delay times and step travel times. sramp5: Ramping of process step data load times, per-unit times, per-batch times, batch I.D.'s, and unload times. sramp4: Ramping of process step data load times, per-lot times, and unload times. pstep1:Total lot arrivals, average queue delay, and average cycle time outputs by product / process step. pramp20: Ramping of product data change of process flow while lot is being processed. sramp3: Ramping of process step data change of tool group while lot is being processed. sramp2: Ramping of process step data first record specifies an effective date. sramp1: Ramping of process step data tool groups. holdtl7: Cycle times and tool group busy% calculations for models with hold tool regions that contain scrap. holdtl6: Cycle times and tool group busy% calculations for models with hold tool regions that contain split lot regions. holdtl5: Product raw process times, cycle time contribution calculations, and tool group busy% calculations for models with hold tool regions that contain rework. holdtl4: Product raw process times, cycle time contribution calculations, and tool group busy% calculations for models with hold tool regions that contain goto's. holdtl3: Product raw process times and cycle time contribution calculations for models with hold tool regions.
24.8. Verification Test Suite 326. 327. 328. 329. 330. 331. 332. 333. 334. 335. 336. 337. 338. 339. 340. 341. 342. tramp35: Use of -UseSugg when number of tools is changed in the middle of an analysis period. disp3: PRCRITICAL2 dispatch rule both lots already missed due dates. disp2: PRCRITICAL2 dispatch rule impact of due date. disp1: PRCRITICAL2 dispatch rule impact of remaining cycle time. tramp34: Current, suggested, and new number of tools when actual number of tools is changed in the middle of an analysis period. oramp8: Suggested number of operators when -UseSugg is enabled and start rate is ramping. tramp33: Suggested number of tools when -UseSugg is enabled and start rate is ramping. tramp32: Ramping of tool group data removing interruptions when all interruptions have same name. tramp31: Ramping of tool group data adding interruptions when all interruptions have same name. tramp30: Ramping of tool group data removing interruptions. tramp29: Ramping of tool group data adding interruptions. tramp28: Ramping of tool group data dispatch rules when lots are waiting in queue at time of dispatch rule change. tramp27: Ramping of tool group data dispatch rules. tramp26: Ramping of tool group data existence of setups for a tool. tramp25: Ramping of tool group data setup times. tramp24: Ramping of tool group data number of tools increase when lots are waiting in queue, and new number of tools allows more lots to start immediately. tramp23: Ramping of tool group data minimum batch size decrease when lots are waiting in queue, and new minimum batch size allows batch to start immediately. tramp22: Ramping of tool group data batch size type (units or lots). tramp21: Ramping of tool group data maximum batch sizes. tramp20: Ramping of tool group data minimum batch sizes. tramp19: Ramping of tool group data avoid setups flag. tramp18: Ramping of tool group data unload%. tramp17: Ramping of tool group data proc%. tramp16: Ramping of tool group data load%. tramp15: Ramping of tool group data tool depreciation life. tramp14: Ramping of tool group data tool useful life. tramp13: Ramping of tool group data tool fixed costs. tramp12: Ramping of tool group data tool recurring costs. tramp11: Ramping of tool group data tool space requirements and space types. tramp10: Ramping of tool group data tool space requirements. tramp9: Ramping of tool group data tool space within one layout area. tramp8: Ramping of tool group data layout areas. tramp7: Ramping of tool group data tool types. oramp7: Ramping of operator group data hourly wage rates. oramp6: Ramping of operator group data no active record at start of analysis. tramp6: Ramping of tool group data no active record at start of analysis.
343. 344. 345. 346. 347. 348. 349. 350. 351. 352. 353. 354. 355. 356. 357. 358. 359. 360. 361.
24. Reference Topics: Verification Tests 362. 363. 364. 365. 366. 367. 368. 369. 370. 371. 372. 373. 374. 375. 376. 377. 378. 379. 380. 381. 382. 383. 384. 385. 386. 387. 388. 389. 390. 391. 392. 393. pramp19: Ramping of product data when some products are not active at beginning of run, but other products are active. pramp18: Ramping of product data when first record for a product contains an effective date. oramp5: Ramping of operator group data removing an operator in the middle of an analysis period at a time when operator is busy. oramp4: Ramping of operator group data removing an operator in the middle of an analysis period. oramp3: Ramping of operator group data adding an operator in the middle of an analysis period. oramp2: Ramping of operator group data number of operators when first effective record specifies zero operators. oramp1: Ramping of operator group data number of operators. tramp5: Ramping of tool group data removing a tool in the middle of an analysis period at a time when tool is busy. tramp4: Ramping of tool group data removing a tool in the middle of an analysis period. tramp3: Ramping of tool group data adding a tool in the middle of an analysis period. tramp2: Ramping of tool group data number of tools when first effective record specifies zero tools. tramp1: Ramping of tool group data number of tools. altstep9: Models where sum of alternative step percentages is close to, but not exactly equal to, 100. ctcont3: Cycle time contribution estimates when -ReadState and -SaveState are used. ctcont2: Cycle time contribution estimates for models with alternative process steps. transf5: Use of -ReleasePct for models with transform. pramp17: Ramping of product assembly data - retention of previously completed but as-yet unused sub-assembly units across ramp boundaries. pramp16: Ramping of product assembly data - receiving product. pramp15: Ramping of product transform data - receiving product. pramp14: Ramping of product assembly data - requirements. pramp13: Ramping of product transform data - multipliers. pramp12: Ramping of product CONWIP levels. pramp11: Ramping of product lead-time factors. pramp10: Ramping of product costs and revenues. pramp9: Ramping of product time-to-first release distributions. pramp8: Ramping of product priorities. pramp7: Ramping of product lot sizes. pramp6: Ramping of product due-date offsets. pramp5: Ramping of product tput rate unit of measures. pramp4: Ramping of product tput rates. pramp3: Ramping of product start rate unit of measures. period1: Calculation of period start dates for Tool Group Results Worksheet.
24.8. Verification Test Suite 394. 395. 396. 397. 398. 399. 400. 401. 402. 403. 404. 405. 406. 407. 408. 409. 410. 411. 412. 413. 414. 415. 416. 417. 418. 419. 420. 421. 422. 423. 424. 425. urule3: Default USER3 user-supplied dispatch rule. urule2: Default USER2 user-supplied dispatch rule. urule1: Default USER1 user-supplied dispatch rule. dtramp1: Date calculations for ramp analysis. cap15: Use of -ReleaseRate with -WriteExcel for models containing release patterns, unit start rates, and unit throughput rates. cap14: Use of -ReleasePct with -WriteExcel for models containing release patterns, unit start rates, and unit throughput rates. altstep8: Use of -ReadState and -SaveState with models containing alternative steps. altst8a: Alternative step related WIP record outputs. cap13: Use of -ReleasePct and -ReleaseRate for models with multiple release patterns. pramp2: Analysis of models with many products. pramp1: Ramping of product start rates. cap12: Capacity analysis calculations and simulation estimates for models with product lot size specified as a distribution. setup18: %Operation setup I.D. wildcard in model with sequence-dependent setups. setup17: %Operation setup I.D. wildcard in model with sequence-independent setups. btwild14: %Process and %Operation batch I.D. wildcards. btwild13: %Operation batch I.D. embedded wildcard. btwild12: %Operation batch I.D. wildcard. opcalc20: Capacity analysis calculations for operators in models with batch tools where the maximum batch size is less than the lot size. altstep7: Alternative process steps in models with operators. jtsetup4: Setup rate prediction in models with batch tools where the maximum batch size is specified in units, and the lot size exceeds the maximum batch size. lotsplt9: Lot splitting in models where lots arrive to the split step with fewer units than the split lot size. cap11: Capacity analysis for models with large lot sizes (3,500 units per lot) and rework. user1: Detail data record values. altstep6: Alternative process steps in models where one of the alternatives has zero tools. altstep5: Alternative process steps in models where one of the alternatives uses a batch tool. altstep4: Alternative process steps with different process times. altstep3: Raw process time and product cost calculations in models with alternative process steps. pcost33: Allocation of operator and travel operator wages to process steps. pcost32: Allocation of factory fixed and recurring costs to process steps. pcost31: Allocation of tool recurring cost to process steps. pcost30: Allocation of tool fixed cost to process steps. pcost29: Product cost analysis for models with operator-assisted travel.
24. Reference Topics: Verification Tests 426. 427. 428. 429. 430. transf4: Capacity analysis for models where a single product is transformed into multiple products, and the parent product has multiple units in a lot. transf3: Capacity analysis for models where a single product is transformed into multiple products, and the parent product has multiple units in a lot. lotsplt8: Cycle time contribution estimates for tools that process split lots. holdtl2: Capacity analysis and simulation results for models where hold tool region includes a batch tool. lotsplt7: Capacity analysis for models with lot splitting, very large product lot sizes (5,000 units), and a split lot size that is not an even divisor of the product lot size. lotsplt6: Capacity analysis for models with lot splitting and rework loops inside split lot regions. lotsplt5: Capacity analysis for models with lot splitting and backward-pointing goto's inside split lot regions. lotsplt4: Capacity analysis for models with lot splitting and forward-pointing goto's inside split lot regions. lotsplt3: Capacity analysis for models with lot splitting. lotsplt2: Simulation-based WIP estimates in models with lot splitting. lotsplt1: Support for lot splitting (SplitIntoLotSize statement) when using individual lots. ltsplt1a: Split-lot related WIP record outputs. batch15: Capacity analysis predictions for batch tools where batch size is specified in units and is less than the product lot size. cvest3: Estimation and prediction of interarrival time coefficient of variation in a completely deterministic serial system with UnitTputRate statement. cvest2: Estimation and prediction of interarrival time coefficient of variation in a completely deterministic serial system. um4: Capacity analysis and simulation for simple models with UnitStartRateUM and UnitTputRateUM statements. um3: Model input for simple models with UnitStartRateUM and UnitTputRateUM statements. um2: Operation of -ReleaseRateUM and -AddRateUM. um1: Operation of -RunLenUM and -ClearStats. oper1: Simple model with Operation statement. holdtl1: Simple model with HoldTool statement. psplit3: Model with SplitIntoLotSize statement and split lot size is larger than original lot size. psplit2: Model with SplitIntoLotSize statement and last split lot is not full. psplit1: Simple model with SplitIntoLotSize statement. ustart4: Interaction between unit start rate specification in model and -ReleasePct. ustart3: Interaction between unit start rate specification in model and ReleaseRate. ustart2: Specifying a unit start rate of zero. ustart1: Unit start rate specification in simple models. altstep2: Equal sharing of work among three alternative servers in simulation. altstep1: Equal sharing of work among two alternative servers in simulation.
431. 432. 433. 434. 435. 436. 437. 438. 439. 440. 441. 442. 443. 444. 445. 446. 447. 448. 449. 450. 451. 452. 453. 454. 455.
24.8. Verification Test Suite 456. 457. 458. 459. 460. 461. 462. cap10: Capacity analysis calculations in models with infinite factory capacity loading when -ReleasePct enabled. cap9: Capacity analysis calculations in models with batch tools used only in unused process flows. cap8: Throughput and line yield calculations for models with process steps having scrap and a goto to immediate next process step. cap7: Factory and operator group capacity loading% calculations when operator groups that only perform repair are overloaded. cap6: Input rate and factory capacity loading% calculations when -ReleasePct combined with -AddPct and -Reps. cap5: Calculations for Tool Group Capacity by Product and Operator Group Capacity by Product worksheets. cap4: Suggested number of servers calculation when sum of capacity loss factors exceeds 100%, but increasing the number of servers can bring sum below 100% (suggested number of servers is finite). cap3: Suggested number of servers calculation when sum of capacity loss factors exceeds 100%, and increasing the number of servers can never bring sum below 100% (suggested number of servers is infinite). lstate3: Loading detailed info from individual lots. lstate2: Loading individual lots that contain rework. setltf1: Use of -SetLTF in models with multiple products. pcost28: Product cost calculations in models specifying wage rates for infinite server operator groups. pcost27: Product cost calculations in models specifying fixed and recurring costs for infinite server tool groups. workapd1: PRWORKAPD dispatch rule. setup16: Use of -DelSetups in models with setups. delops2: Use of -DelOpGroups in models with operator cost data. cap2: Capacity load% calculation when capacity load is infinite. ccompstp: CCOMPSTEP dispatch rule. pcost26: Product cost calculations when useful life of factory resource of tool group is set to zero or not specified. setup15: Maximum input rate calculation in models with FinishID statement and setup-avoidance enabled. setup14: Use of -ReleasePct with models where the bottleneck tool has setup, and setup-avoidance is enabled. zerores1: Models with zero resources specified for a tool group or operator group. opcalc19: Simulation logic when tool and operator are freed simultaneously. opcalc18: Operator Repair% prediction and estimation in models with multiple ToolGroup interruptions for a single tool. opcalc17: Operator Repair% prediction and estimation in models with Repair% specified. opcalc16: Operator Repair% prediction and estimation in models with default Repair%.
463.
464. 465. 466. 467. 468. 469. 470. 471. 472. 473. 474. 475. 476. 477. 478. 479. 480. 481.
24. Reference Topics: Verification Tests 482. ctcont1: Calculations for predicted process time per visit, estimated visits, and estimated total process time contribution on Cycle Time Contribution by Tool Group Chart. setup13: Models with setup I.D.'s that only appear as FromID's in ToolGroup definition. plmt1: Plate matching scaled cycle time calculation and use in simulation. setup12: FIFO Setup rate approximation in models with FinishID statement and lot batch sizes. setup11: FIFO Setup rate approximation in models with FinishID statement. setup10: Estimated setup time in models specifying FinishID statement. move4: Sorting of entries on travel matrix outputs. move3: Travel matrix calculations for multi-product models. move2: Travel matrix calculations for moves across steps with no LayoutArea. move1: Travel matrix calculations for moves between steps with LayoutAreas. setup9: %Process setup I.D. wildcard in model with sequence-dependent setups. setup8: %Process setup I.D. wildcard in model with sequence-independent setups. setup7: %Product setup I.D. wildcard in model with sequence-dependent setups. setup6: %Product setup I.D. wildcard in model with sequence-independent setups. setup5: Embedded %Step setup I.D. wildcards. setup4: %Step setup I.D. wildcard in model with sequence-dependent setups. setup3: %Step setup I.D. wildcard in model with sequence-independent setups. batch14: Units-completed based downtime calculations for models with lot batch sizes. batch13: Operator Group predictions / estimates for models with lot batch sizes and shared operators. batch12: Tool Group and Operator Group predictions / estimates for models with lot batch sizes. batch11: Simulation estimates of batch utilization and Occupied% for models with lot batch sizes. odf2: Factory fixed and recurring cost allocation to tool group level for WriteODF. odf1: Operator cost allocation to tool group level for -WriteODF. ffull3: Use of -ForceFull option in models with multiple products and the %Product batch I.D. wildcard. ffull2: Use of -ForceFull option in models with multiple products and the %Product batch I.D. wildcard. ffull1: Use of -ForceFull option in simple models. utput10: Unit throughput calculations for models with assembly and no release patterns. utput9: Unit throughput calculations for models with transform and no release patterns. utput8: Unit throughput calculations for models with multiple products and no release patterns. utput7: Unit throughput calculations when throughput rate is set to zero in a simple model with no release patterns. utput6: Unit throughput calculations for a simple model with no release patterns.
483. 484. 485. 486. 487. 488. 489. 490. 491. 492. 493. 494. 495. 496. 497. 498. 499. 500. 501. 502. 503. 504. 505. 506. 507. 508. 509. 510. 511. 512.
24.8. Verification Test Suite 513. 514. 515. 516. 517. 518. 519. 520. 521. 522. 523. 524. 525. 526. 527. 528. 529. 530. 531. 532. 533. 534. 535. 536. 537. 538. 539. 540. 541. 542. 543. 544. 545. 546. 547. 548. 549. pcost25: Product cost calculations for models with multiple tool types. utput5: Unit throughput calculations for models with assembly. utput4: Unit throughput calculations for models with transform. utput3: Unit throughput calculations for models with multiple products. utput2: Unit throughput calculations when throughput rate is set to zero in a simple model. utput1: Unit throughput calculations for a simple model. pcost24: Product cost calculations for models with multiple factory fixed costs and multiple factory recurring costs. pcost23: Product cost calculations for models with a single factory fixed cost and a single factory recurring cost. leadtm5: Product lead time calculations for models with multiple end-products and different critical paths. leadtm4: Product lead time calculations for models with multiple end-products. leadtm3: Product lead time calculations for models with transform and assembly. leadtm2: Product lead time calculations for models with assembly. leadtm1: Product lead time calculations for models with transform. pcost22: Product cost and gross margin calculations for models with factory schedules. pcost21: Operator wage calculations for gross margin and product cost. cost18: Factory depreciation and recurring cost calculations for gross margin. sched12: Random combination parameters for models with factory schedules. sched11: Cycle time estimation for models with factory schedules. sched10: Use of -UseSugg, -AddSuggPct, and -SuggLoading with factory schedules. sched9: Use of -ReleaseRate and -AddRate with factory schedules. sched8: Use of -ReleasePct and -AddPct with factory schedules. sched7: Use of -ReleaseRate with factory schedules. sched6: Use of -ReleasePct with factory schedules. sched5: Adjusted release rate calculations for models with factory schedules and release patterns. sched4: Factory schedule calculations for models with multiple, repeated schedule records. sched3: Factory schedule calculations for models with repeated schedule record. sched2: Factory schedule calculations for models with single schedule record. sched1: Factory schedule calculations for models with no factory schedule. layout2: Total required space by layout area calculations when -UseSugg enabled. layout1: Total required space by layout area calculations. space2: Total required space by type calculations when -UseSugg enabled. space1: Total required space by type calculations. tslice2: Data reported on CTBYTIME results data record for run summary. pcost20: Product cost calculations when -UseSugg and -Reps are enabled. pcost19: Product cost calculations for models with assembly. pcost18: Product cost calculations for models with transform. travop1: Capacity analysis calculations for models with operators dedicated to travel.
24. Reference Topics: Verification Tests 550. 551. 552. 553. 554. 555. 556. 557. 558. 559. 560. 561. 562. 563. 564. 565. 566. 567. 568. 569. 570. 571. 572. 573. 574. 575. 576. 577. 578. 579. 580. 581. 582. 583. 584. 585. 586. 587. 588. 589. 590. unitbt1: Batch tool that has per-unit times. summ1: Multiple products. nis9: Product WIP outputs for models with lot rework and lot scrap. nis8: Product WIP and tool group WIP outputs for models with lot rework. nis7: Product WIP outputs for models with unit rework and unit scrap. nis6: Product and tool group WIP outputs for models with unit rework. tslice1: Cycle time data reported on CTBYTIME results data record. opcalc15: Operator groups with Offline% + Repair% >= 100%. batch10: Combined per-unit and per-batch times at batch processing steps. cost11: Total fixed cost values on tool group results worksheet. nis5: Product and tool group WIP outputs for multi-product models. nis4: Product and tool group WIP outputs for models with unit rework. nis3: Product and tool group WIP outputs for models with lot rework. nis2: Product and tool group WIP outputs for models with unit scrap. nis1: Product and tool group WIP outputs for simple models. pcost17: Product cost calculations for models with multiple sub-assemblies. pcost16: Product cost calculations for models with scrap and assembly. pcost15: Product cost calculations for models with scrap and transform. pcost14: Product cost calculations for models with assembly. pcost13: Product cost calculations for models with transform. pcost12: Product cost calculations for multi-product models that share operators. pcost11: Product cost calculations for multi-product models that share tools. pcost10: Product cost calculations for models with scrap and operator wages. pcost9: Product cost calculations for models with operator wages. pcost8: Product cost calculations for models with scrap, tool fixed cost, and tool recurring cost. pcost7: Product cost calculations for models with tool fixed cost and tool recurring cost. pcost6: Product cost calculations for models with scrap, rework, and supplies & consumable cost. pcost5: Product cost calculations for models with scrap and supplies & consumable cost. pcost4: Product cost calculations for models with supplies & consumable cost. pcost3: Product cost calculations for models with unit scrap. pcost2: Product cost calculations for models with lot scrap. pcost1: Product cost calculations for simple models. gclock3: Mixture of GroupClock and clock-time interrupts. gclock2: GroupClock interrupts with -UseSugg enabled. gclock1: Resource Group-level clock-based interrupt (GroupClock type). doetst1: DOE calculations for full factorial and screening designs. btwild11: Varying maximum batch size using embedded %Step batch I.D. wildcard. btwild10: %Process and %Step batch I.D. wildcards. btwild9: %Product and %Step batch I.D. wildcards. btwild8: %Step batch I.D. wildcard. btwild7: %Process batch I.D. wildcard.
24.8. Verification Test Suite 591. 592. 593. 594. 595. 596. 597. 598. 599. 600. 601. 602. 603. 604. 605. 606. 607. 608. 609. 610. 611. 612. 613. 614. 615. 616. 617. 618. 619. 620. 621. 622. 623. 624. 625. 626. 627. 628. 629. 630. 631. 632. btwild6: %Product batch I.D. wildcard. btwild5: %Process and %Step batch I.D. embedded wildcards. btwild4: %Product and %Step batch I.D. embedded wildcards. btwild3: %Step batch I.D. embedded wildcard. btwild2: %Process batch I.D. embedded wildcard. btwild1: %Product batch I.D. embedded wildcard. hist4: Histogram/percentile calculations for long-tailed service time distributions. hist3: Histogram calculations for multi-product system. hist2: Histogram/percentile calculations with ClearStats option. hist1: Histogram/percentile calculations for single product system. cap1: Input rate calculation for models with goto's to immediate next process step. qapprox1: Queue delay and number in queue predictions. cost9: Raw unit cost WIP valuation with delayed assembly. cost8: Raw unit cost WIP valuation for multiple products. cost7: Long-run raw unit cost WIP valuation. cost6: Raw unit cost WIP valuation when model includes assembly. cost5: Raw unit cost WIP valuation when model includes transform. cost4: Raw unit cost WIP valuation. cost3: Cost per unit prediction when model includes assembly. cost2: Cost per unit prediction when model includes transform. cost1: Gross margin prediction. lslack: LSLACK dispatch rule. rwkpct: Capacity analysis and simulation for models with Rework statements. scrappct: Capacity analysis and simulation for models with Scrap statements. gotopct: Capacity analysis and simulation for models with Goto statements. rlist: Release list specified with ReadRList option. repairrq: Operator repair of tool groups. caporder: Order in which capacity analysis is performed when assembled-from products are specified after assembled-into products. usesugg: UseSugg and SuggLoading options. excelall: Excel to ASCII conversion process. mm1: Model of an M/M/1 queue bdrate: Units of work completed failure rate prediction, operator group repair rate prediction. testbed: Testbed option. batch9: Average batch size estimation at batch tools with setup. batch8: Setup rate approximation at batch tools. batch7: Average batch size calculation at batch tools with setup. delscrap: DelScrap option. delops: DelOpGroups option. service: Service time mean and coefficient of variation calculations. assmbl2: Assembly of multiple products with common sub-assemblies. assmbl1: Assembly of two products into a third with scrap. batch6: Capacity and average batch size at tools with maximum batch size less than lot size.
24. Reference Topics: Verification Tests 633. 634. 635. 636. 637. 638. 639. 640. 641. 642. 643. 644. 645. 646. 647. 648. 649. 650. 651. 652. 653. 654. 655. 656. 657. 658. 659. 660. 661. 662. 663. 664. 665. 666. 667. ccomprpt: Closest-to-completion by raw process time dispatch rule. opcalc14: Predicted operator group setup% when # of operators differs from # of tools. opcalc13: System util% when constrained by operators with setups. opcalc12: System util% when constrained by operators with interruptions. opcalc11: System util% when constrained by operators. opcalc10: Predicted operator group setup% with varying lot sizes and operator usage. opcalc9: Average batch, capacity loading% for operator groups used on batch and non-batch tools. opcalc8: Predicted operator group repair% with multiple tool group failure processes. opcalc7: Predicted operator group setup% when proc% set. opcalc6: Predicted operator group setup% when some setups use operator, others don't. opcalc5: Average batch size, capacity loading% prediction for operators using batch tools. opcalc4: Capacity loading% prediction for operator group with processing and travel duties. opcalc3: Capacity loading% prediction for operator group with load%, proc%, unload% set. opcalc2: Capacity loading% prediction for operator group with processing % set. opcalc1: Capacity loading% prediction for operator group with no processing % set. batch5: Processing of batches at batch tools in series. batch4: Failure rate approximation for busy-time failures at batch tools. batch3: Queue delay approximation at batch tools. batch2: Average, maximum batch size, batch capacity loading% statistics. md1same: Queue length calculation for M/D/1 with two products, same processing times. md1diff: Queue length calculation for M/D/1 with two products, different processing times. tscrap: Transform statement in models with scrap. split2: Splitting second product into first product using Transform. unused: Models with unused tools. transf2: Transform statement in models with some forced splitting of lots. transf1: Transform statement in models with no forced splitting of lots. binom3: Binom(N,1) distributed service times. binom2: Binom(N,0) distributed service times. binom1: Binomial distributed interarrival times. setup2: Steady-state avoid setups setup rate approximation. setup1: Steady-state FIFO setup rate approximation. split1: Splitting lots via Transform statement in configuration files. seqseq1: Sequence-dependent setups. deldown: DelDown option. delrwk: DelRework option.
24.8. Verification Test Suite 668. 669. 670. 671. 672. 673. 674. 675. 676. 677. 678. 679. 680. 681. 682. 683. 684. 685. 686. 687. 688. 689. 690. 691. 692. 693. 694. 695. 696. 697. 698. 699. 700. 701. 702. 703. 704. 705. 706. 707. 708. 709. 710. 711. 712. stagcd1: StaggerFirst statement in configuration files. cvest: Coefficient of variation estimation for interarrival times. fullpref: Priority-full-FIFO dispatch rule. jtsetup3: Setup-avoidance approximation for % product setups. jtsetup2: FIFO approximation for % product setups. opset3: Percent busy waiting for operator statistic. strictav: Strict setup-avoidance policy. mg1-h: Erlang distributed service times. mg1-i: Hyperexponential(2) distributed service times. mg1-j: Hyperexponential(3) distributed service times. mg1-k: Shifted exponential distributed service times. gpsetup2: Setup avoidance with dedication, group setups. gp2setup: Secondary group setups. batchid2: Operator requests at batch tools with minimum batch sizes. batchid: Batch formation logic with batch codes. rwscrap: Scrap inside rework loops. dmultop: DownMultOp option. dmultst: DownMultTG option. savoid4: Setup avoidance, FIFO dispatch rule. savoid3: Setup avoidance, priority-FIFO dispatch rule. bfirst1: FirstInterrupt tool group statement with busy-time based interrupts. cfirst2: FirstInterrupt tool group statement with clock-based interrupts. wfirst3: FirstInterrupt tool group statement with units-based interrupts. sstate: WIP outputs. lstate:Individual lots. rework0: Setting percentage of rework occurs at zero. savoid1: Setup avoidance without dedication. savoid2: Setup avoidance with dedication, product setups. downreq: Memory allocation of operator requests. onestrm: OneStream option. clrstats: ClearStats option. delay: Delay process step statement. delayop: Delay process step statements with operators. batchin: Simultaneous arrivals to tool groups. times1: Load, process, unload, and travel percents and times with operator failures. times: Load, process, unload, and travel percents and times with operators. random: Random dispatch rule. batch1: Batch tools. busyd: Busy-time based tool group interruptions. unitsd: Units-based tool group interruptions. clockd: Clock-based tool group interruptions. opset2: M/M/3 queue constrained by 2 operators. jtsetup: Product-dependent setups. mms-a: Steady-state cycle time for M/M/1 queue (FIFO). mms-b: Steady-state cycle time for M/M/2 queue (FIFO).
24. Reference Topics: Verification Tests 713. 714. 715. 716. 717. 718. 719. 720. 721. 722. 723. 724. 725. 726. 727. 728. 729. 730. 731. 732. 733. 734. 735. 736. 737. mms-c: Steady-state cycle time for M/M/10 queue (FIFO). mms-d: Steady-state cycle time for M/M/15 queue (FIFO). mms-al: Steady-state cycle time for M/M/1 queue (LIFO). mms-bl: Steady-state cycle time for M/M/2 queue (LIFO). mms-cl: Steady-state cycle time for M/M/10 queue (LIFO). mms-dl: Steady-state cycle time for M/M/15 queue (LIFO). gpsetup: D/D/1 queue with group setups. mg1-a: Steady-state cycle time for e(10)/u(2,4)/1 queue. mg1-b: Steady-state cycle time for e(20)/u(5,10)/1 queue. mg1-c: Steady-state cycle time for e(10)/c(3)/1 queue. mg1-d: Steady-state cycle time for e(20)/c(7.5)/1 queue. mg1-e: Steady-state cycle time for e(10)/up(3,33.3)/1 queue. mg1-f: Steady-state cycle time for e(15)/tp(5,50)/1 queue. mg1-g: Steady-state cycle time for e(15)/tri(2.5,5,7.5)/1 queue. series: M/M/1 queues in series. scrap: M/M/1 queues in series with scrap. rework: M/M/1 queues in series with rework. priority: M/M/1 queue with two priority classes. load: M/M/1 queue with load and unload times. compstep: Closest-to-completion by step dispatch rule. duedate: Earliest due-date dispatch rule. spt: Shortest processing time dispatch rule. predd: Priority-EDD service dispatch rule. conwip: Constant WIP product dispatch rule. reps: Multiple replications.
25. Bibliography
C.R. Aragon and R.G. Seidel. 1989. Randomized Search Trees. Proceedings of the 30th Annual Symposium on Foundations of Computer Science, 540-545. S. Asmussen. 1987. Applied Probability and Queues. John Wiley & Sons. P. Bratley, B. Fox, and L. Schrage. 1987. A Guide to Simulation. Springer-Verlag. J.A. Buzacott and J.G. Shanthikumar. 1993. Stochastic Models of Manufacturing Systems. Prentice Hall. F. Chance, J. Robinson, and J. Fowler. 1996. Supporting Manufacturing With Simulation: Model Design, Development, And Deployment. In: Proceedings of the 1996 Winter Simulation Conference, eds. J.M. Charnes, D.M. Morrice, D.T. Brunner, and J.J. Swain, 114-121. Institute of Electrical and Electronics Engineers, Piscataway, New Jersey. F. Chance, J. Robinson, J. Fowler, O. Gihr, B. Rodriguez, and L. Schruben. 1996. A Design of Experiments Methodology for Capacity Planning of Wafer Fabrication Facilities. In Progress. H. Chen and B. Schmeiser. 1994. Stochastic Root Finding: Problem Definition, Examples, and Algorithms. In: Proceedings of the Third Industrial Engineering Research Conference, forthcoming. D. Connors, G. Feigin, and D. Yao. 1996. A Queuing Network Model for Semiconductor Manufacturing. IEEE Transactions on Semiconductor Manufacturing, Vol. 9, No. 3, 412427. J. Fowler and J. Robinson. 1995. Sematech MIMAC Final Report. Sematech unclassified report #95062861A-TR. S.J. Hood, A.E.B. Amamoto, and A.T. Vandenberge. 1989. A modular structure for a highly detailed model of semiconductor manufacturing. In: Proceedings of the 1989 Winter Simulation Conference, eds. E.A. MacNair, K.J. Musselman, and P. Heidelberger, 811-817. Institute of Electrical and Electronics Engineers, Piscataway, New Jersey.
25. Bibliography W. Kraemer and M. Langenbach-Belz. 1976. Approximate formulae for the delay in the queuing system GI/G/1. Congressbook, 8th Internat. Teletraffic Congress, Melbourne, 235-1/8. A.M. Law and W.D. Kelton. 1991. Simulation Modeling and Analysis. McGraw-Hill. R. Leachman, R.F. Benson, C. Liu, and D.J. Rarr. 1996. IMPReSS: An Automated Production Planning and Delivery Quotation System at Harris Corporation Semiconductor Sector. Interfaces 26#1 (Jan/Feb): 6-37. B. Nelson. 1992. Statistical Analysis of Simulation Results. In Handbook of Industrial Engineering, 2nd Edition: 2567-2593. S.S. Panwalker and W. Iskander. 1977. A Survey of Scheduling Rules. Operations Research 25: 45-61. N. Prabhu. 1981. Basic Queuing Theory. Technical Report No. 478, School of Operations Research and Industrial Engineering, Cornell University, Ithaca, New York. W. Press, S. Teukolsky, W. Vetterling, and B. Flannery. 1992. Numerical Recipes in C: The Art of Scientific Computing, 2nd Edition. Cambridge University Press. R. Schoenberger. 1982. Japanese Manufacturing Techniques: Nine Hidden Lessons in Simplicity. Free Press. R. Schoenberger. 1987. World Class Manufacturing Case Book: Implementing JIT and TQM. Free Press. L. Schruben. 1980. Establishing the Credibility of Simulation. Simulation 34: 101-105. L. Schruben. 1991. Sigma: A Graphical Simulation System. Scientific Press. L. Schruben, H. Singh, and L. Tierney. 1983. Optimal Tests for Initialization Bias in Simulation Output. Operations Research 31: 1167-1178. P. Welch. 1983. The Statistical Analysis of Simulation Results. The Computer Performance Modeling Handbook. Academic Press. W. Whitt. 1983a. The Queueing Network Analyzer. Bell Systems Technical Journal 62: 2779-2815. W. Whitt. 1983b. The Performance of the Queueing Network Analyzer. Bell Systems Technical Journal 62: 2817-2843.
26. Index
1
1900 date system Excel's 1900 and 1904 date systems, 65 1904 date system Excel's 1900 and 1904 date systems, 65
A
A1-style references required by Factory Explorer, 28 acknowledgments, i ACTIVE column sample model, 88 ACTIVE column, Process flow worksheets, 59 actual max processing rate definition, 23 actual maximum processing rate prediction by capacity analysis, 368 AddPct run-time option, 305 AddRate run-time option, 305 AddRateUM run-time option, 305 AddStream run-time option, 306 AddSuggPct run-time option, 305 ADJPCTS column, Products worksheet, 48 adjusted DGR definition, 21 alternate operator groups, 236 alternative step definition, 23 alternative steps a sample model with alternative steps, 209 including alternative steps in a model, 209 specifying an alternative step percentage, 61 specifying step names, 59 using estimated alternative step percentages when writing final model, 314 alternative% definition, 23 ALTPCT column, Process flow worksheets, 61
Amamoto, A.E.B., 423 analyzing output complete list of output charts, 140 complete list of output reports, 146 complete list of output worksheets, 108 Aragon, C.R., 391, 423 ASCII models Syntax for ASCII models, 331 Asmussen, S., 398, 423 assembly a sample model with assembly, 185 adjustable assembly percentages, 187 defining assembly information for a product, 49 modeling product assembly using the assembly statement, 185 treatment of completed but as-yet unused subassembly inventory at product ramp points, 187 assembly product definition, 20 ASSMINTO column, Products worksheet, 49 ASSMPCT column, Products worksheet, 49 ASSMREQD column, Products worksheet, 49 AVOIDSETUPS column, Tools worksheet, 51 AVOIDSETUPS option, 51
B
base wage rate, 242 batch processing a sample model that restricts batches to a single process with the %Process wildcard, 165 a sample model that restricts batches to a single product and process step with the %Product and %Step wildcards, 170 a sample model that restricts batches to a single product with the %Product wildcard, 162 a sample model that varies batch sizes at process steps with embedded wildcards, 173 a sample model with simple batch processing, 160 algorithm used to form batches, 68
26. Index
average maximum batch size prediction performed by capacity analysis, 363 defining batch I.D.'s for a tool group, 52 difference between capacity loading% and occupied%, 368 difference between occupied% and 100-free%, 368 forcing nearly full batches at run-time, 308 modeling batch processing, 160 number of batches processed at once, 67 specifying a batch I.D. for a process step, 60 specifying that batch sizes are given in terms of lots rather than units, 51 batch tool definition, 22 BATCHID column, Tools worksheet, 52 Benson, R.F., 424 BETWEEN column, Products worksheet, 47 bias. See initialization bias binning units a sample model with unit binning, 184 modeling unit binning using the transform statement, 184 Bratley, P., 359, 393, 423 BSLOTS column, Tools worksheet, 51 BSLOTS option, 51 Buzacott, J.A., 423 suggested maximum capacity loading calculation, 371 suggested whole tool and operator count prediction, 371 throughput and yield predictions, 375 tool group capacity by product worksheet, 126 traffic analysis, 359 capacity loading% definition, 23 prediction by capacity analysis, 368 CBUFFER column, Operators worksheet, 58 CBUFFER column, Tools worksheet, 55 CELL column, Factory worksheet, 46 Chance, F., 423 changing values within a single model. See ramp data chart wizard, 144 charts. See output charts CHECKPRI column, Operators worksheet, 58 CHECKPRI column, Tools worksheet, 55 Chen, H., 356, 423 CILevel run-time option, 306 ClearStats run-time option, 306 cluster tools modeling, 226 columns keyword/column definitions for Excel models, 44 CompareFlows run-time option, 306 Connors, D., 359, 423 console console output file, 105 output console, 105 suppressing wait prior to close of output console, 309 conventions formatting conventions used in this manual, 24 conversion. See translation CONWIP specifying a work-in-process target level for a product, 48 CONWIP column, Products worksheet, 48 copyright notices, ii cost analysis a sample model with cost / revenue data, 198 details of Factory Explorer cost analysis calculations, 377 enabling cost analysis at run-time, 307 expense item summary worksheet, 115 gross margin worksheet, 114 including cost / revenue data in a model, 198 product cost worksheet, 114 specifying a per-unit direct material cost at the process step, 61 specifying a per-unit overhead at the process step, 61 specifying a per-unit supplies & consumable cost at the process step, 61 specifying per-operator hourly wage rate for an operator group, 58 specifying per-tool annual recurring cost for a tool, 55 specifying per-tool depreciation life for a tool group, 55
C
capacity analysis assumptions, 359 average maximum batch size prediction, 363 bottleneck resource worksheet, 117, 120 capacity loading% prediction for resources that perform only repair, 369 capacity loading% prediction for resources that perform processing, 368 cluster tool adjustment, 362 DGR calculation, 369 discussion, 3 enabling capacity analysis at run-time, 307 interarrival and service time coefficient of variation prediction, 373 leadtime and purchase date, 373 max going rate calculation, 369 maximum stable input rate prediction, 375 nested rework flows, 361 nonscheduled rate prediction, 363 occupied% prediction, 368 offline rate prediction, 363 operator group capacity by product worksheet, 131 processing rate prediction, 362 queue length and queue delay prediction, 374 raw process time prediction, 375 repair rate prediction, 364 resource planning worksheet, 121, 122 setup% prediction, 364 specifying the analysis run length, 311 specifying the unit of measure for the analysis run length, 311 suggested exact tool and operator count prediction, 372
26. Index
specifying per-tool fixed cost for a tool group, 55 specifying per-tool useful life for a tool group, 55 specifying per-unit raw material cost for a product, 48 specifying per-unit revenue for a product, 48 tool group expense item worksheet, 127 COST column, Products worksheet, 48 COSTPERUNIT column, Process flow worksheets, 61 costs units of measure, 77 critical path definition, 22 custom chart wizard, 144 custom charts custom cycle time characteristic curve chart, 145 custom fixed cost & cycle time vs. suggested capacity loading% chart, 145 custom product cost & total fixed cost vs. release rate chart, 146 custom WIP and cycle time by period chart, 145 customizing Factory Explorer creating your own user.dll, 350 introduction, 345 cycle time definition, 22 cycle-time constrained capacity definition, 351 discussion, 351 estimation via brute-force, 353 estimation via curve-fitting, 356 estimation via stochastic approximation, 356 Delphi, i DelRework run-time option, 307 DelScrap run-time option, 307 DelSetups run-time option, 307 DEPLIFE column, Tools worksheet, 55 DEPLINE column, Factory worksheet, 44 detail data records documentation, 317 DGR definition, 21 prediction by capacity analysis, 369 dispatch rule definition, 22 dispatch rules a sample model with priority-based dispatch rules, 91 adding custom dispatch rules to Factory Explorer, 345 definition and list, 70 operator dispatching, 394 priority-based dispatch rules, 90 setups and dispatch rules, 94 specifying a dispatch rule for a tool group, 51 specifying a dispatch rule for all tool groups and operator groups at run-time, 307 specifying a dispatch rule for an operator group, 58 Dispatch Rules CCOMPRPT, 72 CCOMPSTEP, 71 EDD, 72 FIFO, 72 LIFO, 72 LSLACK, 72 ODD, 72 PRCCOMPSTEP, 73 PRCRITICAL, 73 PRCRITICAL2, 73 PREDD, 73 PRFIFO, 74 PRFULLCR, 74 PRFULLFIFO, 74 PRLIFO, 74 PRWORKAPD, 74 RANDOM, 75 SPT, 75 Dispatch Rules ATCS, 71 DISPATCHRULE column, Operators worksheet, 58 DISPATCHRULE column, Tools worksheet, 51 DispatchRule run-time option, 307 DIST keyword, 44 DIST row, Excel models, 64 DISTANCE column, Factory worksheet, 46 distributions distributions available in Factory Explorer, 70 specifying distributions in an Excel model, 64 DoCap run-time option, 307 DoCost run-time option, 307 DOE run-time option, 307 DOEAppend run-time option, 308 DoSched run-time option, 308 DoSim run-time option, 308
D
daily going rate definition, 21 prediction by capacity analysis, 369 DATA keyword, 44 datasets Sematech semiconductor testbed datasets, 341 DATE column, Operators worksheet, 57 DATE column, OpSchedule worksheet, 57 DATE column, OpSkill worksheet, 56 DATE column, Process flow worksheets, 59 DATE column, Products worksheet, 46 DATE column, Tools worksheet, 51 dates Excel's 1900 and 1904 date systems, 65 including hours and minutes in dates, 65 specifying the starting date for analysis at run-time, 312 day of the week that ends the schedule entry, 57 day of the week that starts the schedule entry, 57 deadlock running simulations even when deadlock is possible, 306 DeadlockOK run-time option, 306 dedication. See alternative steps DELAY column, Process flow worksheets, 60 DelInt run-time option, 307 DelLots run-time option, 307 DelOpGroups run-time option, 307
26. Index
DownMultOp run-time option, 308 DownMultTG run-time option, 308 downtime. See interruptions modeling downtime with interruptions, 177 DUEDATE column, Products worksheet, 48 due-dates setting the due-date offset to a constant multiple of raw process time at run-time, 311 specifying a due-date offset for a product, 48
F
FabTime, 243 FabTime run-time option used to write FabTime-compatible movement transaction log, 314 factory defining a factory space type, 46 defining a factory step type, 46 defining a factory tool type, 46 definining a factory product type, 46 definining a factory unit type, 46 specifying a factory fixed cost, 44 specifying a factory layout area, 46 specifying a factory recurring cost, 45 specifying a factory schedule, 45 specifying a travel matrix record, 46 Factory, 42 Factory Explorer hardware security (HASP) keys, 27 factory schedules modeling a factory schedule, 190 FactoryX menu, 243, 265 failures modeling failures with clock-time interruptions, 180 modeling failures with units-of-work completed interruptions, 179 requiring an operator to repair a tool, 178 FCAMOUNT colum, Factory worksheet, 44 FCNAME column, Factory worksheet, 44 Feigin, G., 341, 359, 423 file formats documentation for results data file, 317 FINISHID column, Process flow worksheets, 61 FirstStream, 265 FirstStream run-time option, 308 fixed costs specifying a factory fixed cost, 44 FIXEDCOST column, Tools worksheet, 55 FlagNoSetup run-time option, 308 Flannery, B., 424 Flow, 265 FLOWFACTOR column, Products worksheet, 49 ForceFull run-time option, 308 Fowler, J., 341, 351, 364, 423 Fox, B., 359, 393, 423 free after step definition, 23 free% definition, 23 FREESTEP column, Process flow worksheets, 62 FROM column, Factory worksheet, 46 FROMID column, Tools worksheet, 53 FRSTATE column Tools worksheet, 54 fx.con file, 105 fx.opt file, 103
E
end product definition, 20 engineering time modeling engineering time with group-clock interruptions, 182 errors suppressing the warning generated when releasing a lot with no units, 314 event graph event graph for Factory Explorer simulation, 389 event traces generating a detailed event trace after a particular simulated time, 311 generating a detailed event trace for a particular event, 311 generating a detailed event trace for a particular lot, 311 generating a detailed event trace for a particular Operator Group, 311 generating a detailed event trace for a particular ToolGroup, 311 generating a detailed event trace starting with a particular replication, 311 Excel Excel 97 or later required for Windows platforms, 28 Excel's 1900 and 1904 date systems, 65 Excel 97 error during first load of Factory Explorer in Excel 97, 29 Excel models, 42 automatic conversion to ASCII format at run-time, 32 distribution templates, 64 general formatting rules, 43 keyword/column definitions, 44 new Excel model, 42 required worksheets, 42 run-time option used when writing Excel models, 314 translating Factory Explorer Excel models, 337 exit code file, 105 exit rate definition, 21 expense items expense item summary worksheet, 115 tool group expense item worksheet, 127 export exporting Factory Explorer models to the testbed format, 342
G
Gihr, O., 423
26. Index
goto a sample model with goto's, 194 modeling non-random routing with the goto's, 192 modeling random routing with process step goto's, 192 specifying a non-random goto after a process step, 63 GOTOSTEP / GOTOPCT column, Process flow worksheet, 63 group DGR adjustment definition, 21 GroupClock interruptions, 177 Excel 97 or later required for Windows platforms, 28 strange Factory Explorer start-up behavior in Windows NT 4.0, 28 upgrading from a prior version of Factory Explorer, 29 version 2 user interface cannot be installed as an automatic Excel add-in, 28 what to do if version 1 was installed as an automatic Excel add-in, 28 Windows 3.1 not supported, 28 installing Factory Explorer Windows platforms, 27 INSTATE column Tools worksheet, 54 interarrival time coefficient of variation prediction by capacity analysis, 373 interruption definition, 22 interruptions a sample model with interruptions, 79 modeling downtime with interruptions, 177 modeling engineering time with group-clock interruptions, 182 modeling failures with clock-time interruptions, 180 modeling failures with units-of-work completed interruptions, 179 modeling interruptions, 79 modeling preventive maintenance with betweentime interruptions, 181 modeling preventive maintenance with busy-time interruptions, 181 removing all interruptions from a model at runtime, 307 requiring an operator to repair a tool, 178 scaling all operator group interruptions at run-time, 308 scaling all tool group interruptions at run-time, 308 introduction to Factory Explorer, 1 Iskander, W., 70, 424
H
hold step definition, 23 hold tool definition, 23 hold tool region definition, 23 hold tool regions holding a tool across multiple process steps, 211 HOLDTOOLPCT column, Process flow worksheets, 62 Hood, S.J., i, 423 hot lots modeling hot lots, 188 modeling hot lots as priority changes within a process, 189 modeling hot lots as separate products, 189
I
IBUFFER column Tools worksheet, 51 IMPACT column Tools worksheet, 54 IMPACTOP column Tools worksheet, 54 IMPACTST column Tools worksheet, 54 import importing testbed models to Factory Explorer, 342 ManSim(TM) models to Factory Explorer, 337 INACTIVE column sample model, 88 INACTIVE column, Process flow worksheets, 59 individual lots removing all individual lots from a model at runtime, 307 initial conditions specifying the initial WIP state, 194 initialization bias testing for initialization bias, 393 input of a skill factor for a given operator group, 56 input rate definition, 23 installation notes A1-style references required, 28 error during first load of Factory Explorer in Excel 97, 29
K
Kanban modeling, 214 Kelton, W.D., 389, 424 keywords keyword/column definitions for Excel models, 44 Kraemer, W., 374, 424
L
Label run-time option, 309 LAREA column, Factory worksheet, 46 LAREA column, Tools worksheet, 54 Law, A.M., 389, 424 layout analysis a sample model with layout data, 207 details of Factory explorer layout analysis calculations, 385 including layout data in a model, 207 tool space by layout area worksheet, 138
26. Index
tool space by type worksheet, 138 travel matrix by distance rate worksheet, 139 travel matrix by move rate worksheet, 138 layout areas specifying a factory layout area, 46 specifying layout area for a tool group, 54 Leachman, R., 424 lead time factors specifying a lead time factor for a product, 48 lead time for a product definition, 22 lead time for a tool definition, 22 LEADTIME column, Tools worksheet, 56 lead-time factors setting all lead-time factors to a specific value at run-time, 312 LEADTIMEUM column, Tools worksheet, 56 line yield prediction by capacity analysis, 375 Liu, C., 424 LOAD column, Process flow worksheets, 60 LOAD column, Tools worksheet, 52 lot definition, 20 LOT column, Lots worksheet, 49 lot size specifying a default number of units for a product, 47 lot splitting mid-process lot splitting, 62 mid-process split, 220 splitting a lot into multiple smaller lots for a subsection of a process flow, 62 splitting and recombining lots within a process flow, 216 lots specifying an individual lot's current or initial step, 50 specifying an individual lot's due date, 50 specifying an individual lot's I.D., 49 specifying an individual lot's priority, 50 specifying an individual lot's process flow, 49 specifying an individual lot's product, 49 specifying an individual lot's start date, 50 specifying an individual rework child lot's parent lot, 50 specifying an individual split-lot child's parent, 50 specifying an individual split-lot parent's remaining number of children, 50 specifying an individual split-lot parent's total number of children, 50 specifying individual lots, 194 specifying that an individual lot is a rework child, 50 specifying that an individual lot is a rework parent, 50 specifying that an individual lot is a split-lot child, 50 specifying that an individual lot is a split-lot parent, 50 specifying the number of units in an individual lot, 50 Lots, 42 LTF column, Products worksheet, 48
M
ManSim importing ManSim(TM) models to Factory Explorer, 337 MATERPERUNIT column, Process flow worksheets, 61 max going rate definition, 21 prediction by capacity analysis, 369 MAXBATCH column, Tools worksheet, 52 MAXDELAY column, Tools worksheet, 53 MAXQUEUE column, Tools worksheet, 53 MAXTOOLS column, Tools worksheet, 53 Merge Flow Data, 245 Merge Lot Data, 246 Merge Model Data, 243 Merge Product Data, 246 Merge Product Flows, 265 mid-process split definition, 23 MIDPROCESSSPLIT column Process flow worksheets, 62 MINBATCH column, Tools worksheet, 52 MINDELAY column, Tools worksheet, 53 MINQUEUE column, Tools worksheet, 53 MINTOOLS column, Tools worksheet, 53 model validation, 104 model verification comparing model process flows against an external file, 306
N
names rules for naming products, tool groups, etc., 66 NBatch run-time option, 309 Nelson, B., 424 non rework% definition, 22 NONSCHED column, Factory worksheet, 45 nonscheduled% definition, 22 prediction by capacity analysis, 363 NoPeriodOutput run-time option, 309 NoRelease run-time option, 309 NoRepOutput run-time option, 309 NoWait run-time option, 309 NRGOTO column, Process flow worksheet, 63 NUMBER column, Operators worksheet, 57 NUMBER column, Tools worksheet, 51
O
OBUFFER column Tools worksheet, 51 occupied%
26. Index
definition, 22 prediction by capacity analysis, 368 ODD, 264 offline definition%, 22 offline% prediction by capacity analysis, 363 OneStream run-time option, 309 OneUnitRPT run-time option, 310 operating systems strange Factory Explorer start-up behavior, 28 Windows 3.1 not supported, 28 OPERATION column, Process flow worksheets, 60 operation I.D.'s specifying an operation I.D. for a process step, 60 operator group definition, 21 operator groups schedule name, 58 specifying a capacity buffer for suggested operators calculation, 58 specifying a check-request priority for simultaneous simulation events, 58 specifying a dispatch rule, 58 specifying a name, 56, 57 specifying a required operator group for a process step, 59 Specifying a required operator group for setup, 61 specifying a required operator group for travel, 61 specifying a unit type for an operator group, 58 specifying an effective date, 56, 57 specifying per-operator hourly wage rate for an operator group, 58 specifying the number of operators, 57 operator overtime, 236 Operator Overtime, 241 Operator Schedules, 237 Operator Skills, 240 operator work schedules, 236 operators a sample model with operators, 85 modeling operators, 85 removing all operator uses from a model at runtime, 307 specifying load time operator percentage for a tool group, 52 specifying processing time operator percentage for a tool group, 52 specifying setup time operator percentage for a tool group, 52 specifying unload time operator percentage for a tool group, 52 Operators, 43 OPGROUP, 240 OPGROUP column, Operators worksheet, 57 OPGROUP column, OpSkill worksheet, 56 OPGROUP column, Process flow worksheets, 59 OpSchedule, 43 OpSchedule worksheet, 237 OpSkill, 43, 240 OPSKILLFACTOR, 241 OPSKILLFACTOR column, OpSkill worksheet, 56 options. See run-time options OTFACTOR, 59, 241 OTHORIZON, 58, 241 OTVALUE, 58, 241 OutBase run-time option, 310 OutCTUM run-time option, 310 output discussion of output analysis, 107 enabling detail data records output at run-time, 313 specifying the base file name for output files, 310 specifying the unit of measure for cycle time outputs, 310 specifying the unit of measure for start / throughput rate outputs, 310 suppressing all end-of-period output at run-time, 309 suppressing all end-of-replication output at runtime, 309 output charts bottleneck resource chart, 140 complete list, 140 custom chart wizard, 144 cycle time by lot exit time chart, 143 cycle time characteristic curve chart, 143 cycle time contribution by tool group chart, 143 cycle time histogram, 144 fixed cost & cycle time vs. suggested capacity loading% chart, 144 product cost & total fixed cost vs. release rate chart, 144 resource group capacity by product chart, 140, 141, 142 WIP and cycle time by operation chart, 142 WIP and cycle time by period chart, 142 output console, 105 output files exit code file, 105 output reports adding a label to output reports at run-time, 309 complete list, 146 dispatch rules information report, 147 factory information report, 146 numeric run-time options, 148 operator group / tool group cross-reference report, 147 operator group information report, 147 process information, 147 product information, 146 string run-time options, 148 tool group / operator group cross-reference report, 147 tool group batch information report, 147 tool group information, 147 tool group setup information report, 147 yes/no run-time options, 147 output worksheet WIP and cycle time by operation worksheet, 132 output worksheets alternative steps summary worksheet, 137 analysis run details worksheet, 108 bottleneck resource worksheet, 117, 120 complete list, 108
26. Index
expense item summary worksheet, 115 factory summary worksheet, 109 gross margin worksheet, 114 operator group capacity by product worksheet, 131 operator group results worksheet, 128 process step detail worksheet, 134 product cost worksheet, 114 product lead time worksheet, 131 resource planning worksheet, 121, 122 scheduling worksheet, 115 tool group capacity by product worksheet, 126 tool group expense item worksheet, 127 tool group results worksheet, 122 tool group setups worksheet, 127 tool space by layout area worksheet, 138 tool space by type worksheet, 138 travel matrix by distance rate worksheet, 139 travel matrix by move rate worksheet, 138 warnings worksheet, 139 WIP snapshot worksheet, 133 OutRateUM run-time option, 310 OVHDPERUNIT column, Process flow worksheets, 61 process step definition, 20 specifying a step type for a process step, 60 process steps adjusting a lot's priority, 63 holding a tool and freeing it after a later process step, 62 resetting a lot's priority to its default value, 63 setting a lot's priority, 63 specifying a batch I.D., 60 specifying a list of active products, 59 specifying a list of inactive products, 59 specifying a load time, 60 specifying a name, 59 specifying a non-random goto, 63 specifying a per-batch processing time, 60 specifying a per-lot processing time, 60 specifying a per-unit direct material cost, 61 specifying a per-unit overhead, 61 specifying a per-unit processing time, 60 specifying a per-unit supplies & consumable cost, 61 specifying a required operator group, 59 Specifying a required operator group for setup, 61 specifying a required operator group for travel, 61 specifying a required tool group, 59 specifying a setup group and I.D., 61 specifying a travel time to next step, 61 specifying an alternative step percentage, 61 specifying an effective date, 59 specifying an extra delay time, 60 specifying an operation I.D., 60 specifying an unload time, 60 specifying goto step and goto persentage, 63 specifying scrap parameters, 61 splitting a lot into multiple smaller lots for a subsection of a process flow, 62 process time coefficient of variation prediction by capacity analysis, 373 processing rate prediction by capacity analysis, 362 processing time specifying process time parameters for step, 67 PRODTYPE column, Factory worksheet, 46 PRODTYPE column, Products worksheet, 47 product definition, 20 PRODUCT column, Lots worksheet, 49 PRODUCT column, Products worksheet, 46 product cost product cost worksheet, 114 product flow data, 244 product lead time definition, 22 product mix definition, 21 product type definition, 20 product types defining a factory product type, 46 specifying a product type for a product, 47 products
P
Panwalker, S.S., 70, 424 PERBATCH column, Process flow worksheets, 60 Percentile run-time option, 310 PERLOT column, Process flow worksheets, 60 PERUNIT column, Process flow worksheets, 60 Prabhu, N., 398, 400, 424 PRADJUST column, Process flow worksheets, 63 PRCCOMPSTEP, 264 PRDEFAULT column, Process flow worksheets, 63 Press, W., 360, 424 preventive maintenance modeling preventive maintenance with betweentime interruptions, 181 modeling preventive maintenance with busy-time interruptions, 181 priorities. See also hot lots a sample model with priority adjust, 92 a sample model with priority-based dispatch rules, 91 adjusting a lot's priority upon exit from a process step, 63 modeling dynamic adjustment of priorities, 92 priority-based dispatch rules, 90 resetting a lot's priority to its default value upon exit from a processing step, 63 setting a lot's priority upon exit from a process step, 63 specifying a default priority for a product, 47 PRIORITY column, Lots worksheet, 50 PRIORITY column, Products worksheet, 47 PROC column, Tools worksheet, 52 Process, 43 PROCESS column, Lots worksheet, 49 PROCESS column, Products worksheet, 47 process flow definition, 20
26. Index
a sample model with multiple products, 88 adjusting transform and assembly percentages to match demand, 48 defining assembly information, 49 defining transformation information, 49 modeling active and inactive process steps, 88 modeling multiple products, 88 modeling product assembly using the assembly statement, 185 modeling unit binning using the transform statement, 184 modeling unit splits using the transform statement, 183 specifying a default number of units, 47 specifying a default priority, 47 specifying a due-date offset, 48 specifying a lead time factor, 48 specifying a name, 46 specifying a product type for a product, 47 specifying a release pattern, 47 specifying a unit of measure for a product start rate, 47 specifying a unit of measure for a product throughput rate, 47 specifying a unit start rate, 47 specifying a unit throughput rate, 47 specifying a unit type for a product, 47 specifying a work-in-process target level, 48 specifying an effective date, 46 specifying per-unit raw material cost for released units, 48 specifying per-unit revenue for finished units, 48 specifying the time to first release, 48 specifying the worksheet that contains process steps, 47 Products, 42 programming customizing Factory Explorer, 345 PRSET column, Process flow worksheets, 63 purchase date prediction by capacity analysis, 373 specifying the starting date for analysis at run-time, 312 ramp data entering multiple definitions for an object, 44 general definition of ramping, 154 general notes on including ramp data in models, 154 how changes to interrupts are handled in the simulation, 156 how Factory Explorer handles ambiguous situations, 156 how interrupt additions are handled in the simulation, 157 how interrupt deletions are handled in the simulation, 157 how model validation works in models with ramp data, 156 how process flow changes are handled in the simulation, 156 how to ramp an object, 155 including operator ramp data in a model, 152 including process step ramp data in a model, 153 including product ramp data in a model, 150 including ramp data in a model, 149 including tool ramp data in a model, 151 restrictions in changes in basic product type, 156 restrictions on attributes that can be ramped, 156 restrictions on finite vs. infinite resources in tool and operator groups, 156 restrictions on hold tool and split lot regions, 156 restrictions on rework steps, 156 startup object definitions, 155 using color to ease data maintenance in Excel models, 155 what dates can be used for ramping?, 156 what happens if the first definition for an object specifies an effective date, 155 what happens if you don't specify all object definitions sequentially, or with ordered effective dates, 155 what happens if you don't specify an effective date, 155 what happens if you don't specify attributes for subsequent definitions of an object, 155 random numbers incrementing the starting stream between replications, 306 number of random number streams provided, 389 random number generator used in the simulation, 389 specifying a single stream for the simulation, 309 specifying distributions in a model, 70 specifying the starting random number stream, 308 random routing modeling with process step goto's, 192 randomized search trees, 391 Rarr, D.J., 424 rates units of measure, 75 raw material cost specifying per-unit raw material cost for a product, 48
Q
queue delay predicted by capacity analysis, 374 queue length predicted by capacity analysis, 374 queuing theory M/G/1 queue, 398 M/M/1 queue with loading and unloading, 400 M/M/1 queue with two priority classes, 400 M/M/1 queues in series, 398 M/M/1 queues in series with rework, 399 M/M/1 queues in series with scrap, 399 M/M/s queue, 397 queue length and queue delay prediction in capacity analysis, 374
R
ramp analysis
26. Index
raw process time prediction by capacity analysis, 375 raw process times basing raw process time calculation on single-unit lots, 310 RCAMOUNT column, Factory worksheet, 45 RCNAME column, Factory worksheet, 45 RECCOST column, Tools worksheet, 55 recurring costs specifying a factory recurring cost, 45 reference style A1-style references required by Factory Explorer, 28 RELEASE column, Products worksheet, 47 release product definition, 20 release rate definition, 20 release rates maximum stable release rate prediction, 375 modifying release rates as a percentage of system capacity between replications, 305 modifying the total unit input rate between replications, 305 specifying the system capacity loading%, 310 specifying the total system unit release rate, 310 specifying the unit of measure for the AddRate run-time option, 305 specifying the unit of measure for the ReleaseRate run-time option, 311 ReleasePct run-time option, 310 ReleaseRate run-time option, 310 ReleaseRateUM run-time option, 311 releases specifying a release pattern for a product, 47 specifying the time to first release for a product, 48 supressing all regular lot releases at run-time, 309 repair% definition, 22 prediction by capacity analysis, 364 REPEATS column, Factory worksheet, 45 replications specifying the number of replications at run-time, 311 reports. See output reports Reps run-time option, 311 resource definition, 21 resource group definition, 21 results data file documentation, 317 REVENUE column, Products worksheet, 48 rework a sample model with scrap and rework, 80 handling of nested rework flows by capacity analysis, 361 modeling rework, 80 removing all rework from a model at run-time, 307 rules for modeling rework, 84 rework% definition, 22 Robinson, J., 339, 351, 364, 423 Rodriguez, B., 423 RunLen run-time option, 311 RunLenUM run-time option, 311 running a model complete list of run-time options, 305 example, 37 exit code file, 105 model validation, 104 output console, 105 required run-time information, 102 run-time options, 103 specifying run-time options in an options file, 104 specifying run-time options, platforms without Excel, 103 specifying run-time options, Windows platforms, 103 Windows platforms, 101 run-time model manipulation removing all individual lots, 307 removing all interruptions (downtime), 307 removing all operator uses, 307 removing all rework, 307 removing all scrap, 307 removing all setups, 307 scaling all operator group downtime, 308 scaling all tool group downtime, 308 setting all lead-time factors to a specific value, 312 setting the due-date offset to a constant multiple of raw process time, 311 specifying a dispatch rule for all tool groups and operator groups, 307 run-time options complete list of run-time options, 305 specifying run-time options, 103 specifying run-time options in an options file, 104 specifying run-time options, platforms without Excel, 103 specifying run-time options, Windows platforms, 103
S
sample model a sample model controlling the order of simultaneous check-request events, 222 a sample model of a hold tool region, 213 sample models a sample model of a burn-in area with split lots, 217 a sample model of a cluster tool, 227 a sample model of a cluster tool with multiple operations, 229 a sample model of a Kanban cell, 214 a sample model of tool group buffering, 234 a sample model that restricts batches to a single process with the %Process wildcard, 165 a sample model that restricts batches to a single product with the %Product wildcard, 162 a sample model that varies batch sizes at process steps with embedded wildcards, 173 a sample model with assembly, 185
26. Index
a sample model with downtime, 79 a sample model with goto's, 194 a sample model with multiple products, 88 a sample model with operators, 85 a sample model with priority adjustment, 92 a sample model with priority-based dispatch rules, 91 a sample model with scrap and rework, 80 a sample model with setup, 96, 224 a sample model with simple batch processing, 160 a sample model with tool states, 227, 229 a sample model with unit binning, 184 a sample model with unit splitting, 183 a very basic sample model, 32 SCHED column, Factory worksheet, 45 SCHEDCLOCKEND column, OpSchedule worksheet, 57 SCHEDCLOCKSTART column, OpSchedule worksheet, 57 SCHEDDAYSTART column, OpSchedule worksheet, 57 SchedEv run-time option, 311 SchedLot run-time option, 311 SCHEDNAME column, Operators worksheet, 58 SCHEDNAME column, OpSchedule worksheet, 57 SchedOG run-time option, 311 SCHEDPERIOD column, OpSchedule worksheet, 57 SchedRep run-time option, 311 SchedShowAll run-time option, 311 SchedStart run-time option, 311 SchedTG run-time option, 311 Schedule name, 57 scheduled DGR definition, 21 schedules nonscheduled rate prediction performed by capacity analysis, 363 specifying a factory schedule, 45 scheduling scheduling worksheet, 115 scheduling analysis enabling scheduling analysis at run-time, 308 Schmeiser, B., 356, 423 Schoenberger, R., 424 Schrage, L., 359, 393, 423 Schruben, L., i, 389, 393, 423, 424 scrap a sample model with scrap and rework, 80 modeling scrap, 80 removing all scrap from a model at run-time, 307 specifying scrap parameters for a process step, 61 SCRAP column, Process flow worksheets, 61 SCRAPLOT column, Process flow worksheets, 61 SCRAPUNIT column, Process flow worksheets, 61 Seidel, R.G., 391, 423 Select Data dialog, 245 Sematech support for Delphi research, i Sematech semiconductor testbed datasets, 341 Sematech MIMAC Project, 351 Sequence, 265 service disciplines. See dispatch rules SetDueXRPT run-time option, 311 SetLTF run-time option, 312 setup a sample model with setup, 96, 224 defining setup for a tool group, 53 definitions of sequence-dependent and sequenceindependent setups, 94 example of setup groups, 93, 224 example of setup I.D.'s, 94 flagging the lack of default or sequence-dependent setup times at run-time, 308 modeling setups, 93, 224 setups and dispatch rules, 94 specifying a setup group and I.D. for a process step, 61 specifying an avoid-setup strategy for a tool group, 51 specifying setup operators, 94 SETUP column, Tools worksheet, 53 setup% definition, 22 prediction by capacity analysis, 364 prediction by capacity analysis for operator groups, 367 prediction by capacity analysis for tool groups with no setup avoidance, 365 prediction by capacity analysis for tool groups with setup avoidance, 366 SETUPID column, Process flow worksheets, 61 SETUPID column, Tools worksheet, 53 SETUPOP column Process flow worksheets, 61 SETUPPCT column Tools worksheet, 52 setups notes on wildcards and setup I.D. names, 98 removing all setups from a model at run-time, 307 tool group setups worksheet, 127 SETUPTIME column, Tools worksheet, 53 Shanthikumar, J.G., 423 ShowAll run-time option, 312 ShowDisp run-time option, 312 ShowDist run-time option, 312 ShowGen run-time option, 312 ShowOpt run-time option, 312 ShowSyn run-time option, 312 simulation allowing simulation of unstable models, 312 enabling simulation at run-time, 308 event graph for Factory Explorer simulation, 389 specifying the analysis run length, 311 specifying the unit of measure for the analysis run length, 311 simultaneous events controlling the order of simultaneous check-request events, 221 specifying a check-request priority for operator groups, 58 specifying a check-request priority for tool groups, 55
26. Index
Singh, H., 424 SIZE column, Products worksheet, 47 space specifying a per-tool space requirement, 54 space analysis a sample model with space data, 207 details of Factory Explorer space analysis calculations, 385 including space data in a model, 207 space types defining a factory space type, 46 SPACEAMT column, Tools worksheet, 54 SPACETYPE column, Factory worksheet, 46 SPACETYPE column, Tools worksheet, 54 split lot region definition, 23 split lot size definition, 23 split step definition, 23 SPLITSIZE column, Process flow worksheets, 62 splitting units a sample model with unit splitting, 183 modeling unit splits using the transform statement, 183 SQL Server database, 243, 265 start rates specifying a unit of measure for a product start rate, 47 specifying a unit of measure for a product throughput rate, 47 specifying a unit start rate for a product, 47 StartDate run-time option, 312 STARTRATE column, Products worksheet, 47 STARTUM column, Products worksheet, 47 statistics calculating confidence intervals, 391 estimated number of visits, 394 specifying the clear-statistics time, 306 specifying the confidence interval level at runtime, 306 specifying the number of statistical batches at runtime, 309 specifying the upper percentile value at run-time, 310 testing for initialization bias, 393 Step, 265 STEP column, Lots worksheet, 50 STEP column, Process flow worksheets, 59 step types defining a factory step type, 46 specifying a step type for a process step, 60 STEPTRAVEL column, Process flow worksheets, 61 STEPTYPE column, Factory worksheet, 46 STEPTYPE column, Process flow worksheet, 60 sub-assembly product definition, 20 sub-transform product definition, 20 suggested capacity loading% modifying the suggested capacity loading% between replications, 305 specifying the suggested capacity loading% at runtime, 312 using suggested resource quantities for a model run, 313 suggested exact operator count prediction by capacity analysis, 372 suggested exact tool count prediction by capacity analysis, 372 suggested maximum capacity loading calculation by capacity analysis, 371 suggested operators specifying a capacity buffer for suggested operators calculation, 58 suggested tools specifying a capacity buffer for suggested tools calculation, 55 suggested whole operator count prediction by capacity analysis, 371 suggested whole tool count prediction by capacity analysis, 371 SuggLoading run-time option, 312 super operator, 236 support for Factory Explorer, i, 29
T
target cycle time divided by the raw processing time, 49 technical support for Factory Explorer, i, 29 terminology definitions, 20 testbed datasets run-time option used when writing Testbed models, 314 Sematech semiconductor testbed datasets, 341 Teukolsky, S., 424 text to more fully describe the schedule, 57 theoretical max processing rate definition, 23 throughput prediction by capacity analysis, 375 specifying a unit throughput rate for a product, 47 throughput rate definition, 20 Tierney, L., 424 time in queue definition, 22 time of day that ends the schedule entry, 57 time of day that starts the schedule entry, 57 times units of measure, 75 TIMETOFIRST column, Products worksheet, 48 TLSTATE column Tools worksheet, 54 TMSTATE column Tools worksheet, 54 TO column, Factory worksheet, 46 tool group definition, 21 tool group buffer definition, 23 tool group buffers
26. Index
modeling, 232 rules, 234 tool groups defining batch I.D.'s, 52 defining setup, 53 modeling process times, 67 specifying a capacity buffer for suggested tool calculation, 55 specifying a check-request priority for simultaneous simulation events, 55 specifying a dispatch rule, 51 specifying a name, 51, 56 specifying a per-tool square requirement, 54 specifying a required tool group for a process step, 59 specifying a tool type for a tool group, 54 specifying a unit type for a tool group, 51 specifying an avoid-setup strategory, 51 specifying an effective date, 51 specifying layout area for a tool group, 54 specifying load time operator percentage, 52 specifying per-tool annual recurring cost for a tool group, 55 specifying per-tool depreciation life for a tool group, 55 specifying per-tool fixed cost for a tool group, 55 specifying per-tool useful life for a tool group, 55, 56 specifying processing time operator percentage, 52 specifying setup time operator percentage, 52 specifying that batch sizes are given in terms of lots rather than units, 51 specifying the number of tools, 51 specifying tool group buffers, 51 specifying unload time operator percentage, 52 tool lead time definition, 22 tool states definition, 24, 54 initial, 54 process rate multipliers, 54 time in state, 54 transition percentages, 54 tool types defining a factory tool type, 46 specifying a tool type for a tool group, 54 TOOLGROUP column, OpSkill worksheet, 56 TOOLGROUP column, Process flow worksheets, 59 TOOLGROUP column, Tools worksheet, 51 tools holding a tool across multiple process steps, 62, 211 Tools, 43 TOOLTYPE column, Factory worksheet, 46 TOOLTYPE column, Tools worksheet, 54 TOSTATE column Tools worksheet, 54 TPUTRATE column, Products worksheet, 47 TPUTUM column, Products worksheet, 47 trademark notices, ii traffic analysis traffic analysis performed by capacity analysis, 359 TRANINTO column, Products worksheet, 49 TRANMULT column, Products worksheet, 49 TRANPCT column Tools worksheet, 54 TRANPCT column, Products worksheet, 49 transform adjustable transform percentages, 187 modeling unit binning using the transform statement, 184 modeling units splits using the transform statement, 183 transform product definition, 20 transformation defining transformation information for a product, 49 translating Factory Explorer Excel models, 337 translation translating Factory Explorer models to the current version, 301 travel matrix specifying a travel matrix record, 46 TRAVELOP column, Process flow worksheets, 61
U
unit definition, 20 unit type definition, 20 unit types defining a factory unit type, 46 specifying a unit type for a product, 47 specifying a unit type for a tool group, 51 specifying a unit type for an operator group, 58 UNITS column, Lots worksheet, 50 units of measure, 75 specifying a unit of measure for a product start rate, 47 specifying a unit of measure for a product throughput rate, 47 specifying the unit of measure for cycle time outputs, 310 specifying the unit of measure for start / throughput rate outputs, 310 specifying the unit of measure for the AddRate run-time option, 305 specifying the unit of measure for the ReleaseRate run-time option, 311 specifying the unit of measure for the analysis run length, 311 UNITTYPE column, Factory worksheet, 46 UNITTYPE column, Operators worksheet, 58 UNITTYPE column, Products worksheet, 47 UNITTYPE column, Tools worksheet, 51 UNLOAD column, Process flow worksheets, 60 UNLOAD column, Tools worksheet, 52 UNSPLIT column, Process flow worksheets, 62 unsplit step definition, 23 Unstable run-time option, 312
26. Index
upgrades upgrading from a perior version of Factory Explorer, 29 USEBATCHID column, Process flow worksheets, 60 USELIFE column, Factory worksheet, 44 USELIFE column, Tools worksheet, 55 user.dll creating your own user.dll, 350 customizing Factory Explorer, 345 UserInt run-time option, 313 UserParm1 run-time option, 313 UserParm2 run-time option, 313 UserParm3 run-time option, 313 UserParm4 run-time option, 313 UserParm5 run-time option, 313 UserStart run-time option, 313 USESETUP column, Process flow worksheets, 61 UseSugg run-time option, 313 wait suppressing wait prior to close of output console, 309 warnings warnings worksheet, 139 Welch, P., 393, 424 Whitt, W., 359, 373, 424 wildcards notes on wildcards and setup I.D. names, 98 Windows 3.1 Windows 3.1 not supported, 28 Windows NT 4.0 strange Factory Explorer start-up behavior, 28 WIP modeling limited storage, 232 specifying the initial WIP state, 194 WIP snapshot worksheet, 133 wizards custom chart wizard, 144 Working%, 22 worksheets. See also output worksheets worksheets required in an Excel model, 42 WriteDetail run-time option, 313 WriteEstAlt run-time option, 314 WriteExcel run-time option, 314 WriteFabtime run-time option, 314 WriteTestbed run-time option, 314
V
validation model validation, 104 Vandenberge, A.T., 423 verification Factory Explorer verification, 397 the Factory Explorer verification test suite, 401 version number significance of the Factory Explorer version number, 30 Vetterling, W., 424
Y
Yao, D., 359, 423
W
WAGERATE column, Operators worksheet, 58
Z
ZeroUnitOk run-time option, 314

Handbuch Factory Explorer FX210

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Handbuch Factory Explorer FX210

Enviado por

Direitos autorais:

Formatos disponíveis

User Manual

User's Guide Reference Topics

Wright Williams & Kelly, Inc.

Exclusive Distribution Rights

Copyright WWK 1995-2009

Software License Agreement

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Factory Explorer vii

19.4 19.5 20.

Copyright WWK 1995-2009

Factory Explorer viii

Copyright WWK 1995-2009

1. Introduction to Factory Explorer

1.1 Overview of Factory Explorer

Figure 1-1: Factory Explorer System Diagram.

Copyright WWK 1995-2009

Copyright WWK 1995-2009

1.2. Analytic Methods vs. Simulation Methods

Product / Lot Follows...

Process Consists of...

Step Requires Tool from...

Step Requires Operator from...

Figure 1-3: Overview of the Factory Explorer object model.

1.2 Analytic Methods vs. Simulation Methods

1.3 Benefits of Integrated Cost Analysis

Copyright WWK 1995-2009

1.4. A Quick Tour of Factory Explorer's Excel Interface

1.4 A Quick Tour of Factory Explorer's Excel Interface

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Figure 1-9: Table of contents for Factory Explorer's on-line help.

1.5 Getting Answers with Factory Explorer

Copyright WWK 1995-2009

$800.00 $50,000,000 $700.00

Cost Per Good Unit Out

$40,000,000 Total Fixed Cost

$500.00 $30,000,000 $400.00

Cost Per Good Unit Out Total Fixed Cost

$200.00 $10,000,000 $100.00

Copyright WWK 1995-2009

7.0 $40,000,000 6.0

Total Fixed Cost

Cycle Time Over RPT

Total Fixed Cost Cycle Time Over RPT

2.0 $10,000,000 1.0

$0 55.0% 65.0% 75.0% Sugg Capacity Loading 85.0% 95.0%

Copyright WWK 1995-2009

1. Introduction to Factory Explorer

$900.00 5.0 $800.00

Cost Per Good Unit Out Cycle Time Over RPT

$400.00 2.0 $300.00

$200.00 1.0 $100.00

$0.00 55.0% 65.0% 75.0% Factory Capacity Loading 85.0% 95.0%

Copyright WWK 1995-2009

Copyright WWK 1995-2009

Copyright WWK 1995-2009