High speed bottle manufacturing lines: Case studies and simulation software selection techniques

HIGH SPEEDBOTTLE MANUFACTURING LINES: CASE STUDIES AND SIMULATION SOFTWARE SELECTION TECHNIQUES

Karthik Vasudevan | Ravi Lote | Edward Williams | Onur Ulgen

  

ABSTRACT

Simulation Engineers and model users (industrial engineers, manufacturing engineers and sometimes even executives) can vouch for the importance of effective software selection when it comes to modeling a complex real-world system. Implementing and customizing these models for day-to-day use is an involved process that requires a firm understanding of the system from both the software (model) and plant floor perspectives. This paper describes from a holistic perspective the software selection methods, tools & techniques of creating a model for a high-speed bottle manufacturing line. While contribution towards a standardized simulation software selection approach is the primary contribution of this paper, the bottle manufacturing simulation models are used as three distinct case studies to explain the same.

 

INTRODUCTION

Simulation, historically, was first and most vigorously applied to traditional manufacturing applications; these uses, predating uses in logistics, service, and health-care industries, date back to at least the early 1960s (Law and McComas 1998). Many of these early applications were devoted to traditionally strictly discrete processes, such as job shops and assembly lines, due in part to the strictly discrete capabilities and world-view of pioneering simulation languages and tools such as GPSS®, as documented by (Gordon 1975) – note the prominence of the word “discrete” in his title. However, in due course the enticements of simulation’s analytical powers attracted attention of managers and industrial engineers responsible for the design and improvement of high-volume processes. In this context, “high-volume” signifies that the output of the production system is sufficiently large, and sufficiently well approximated by a continuous world view, that modeling every increment of pro- duction discretely is unnecessary, impractical, or both, in at least some portions of the system under study. Examples of out- put flow amenable to this world view are the production of cement, pills, cereals, or bottled beverages. Specifically, a model of such a production line may well eschew viewing each pill, or each milliliter of liquid, as a separate entity. As one example from the literature, (Yenradee, Sarochsuwan, and Nakornsri 1996) merged and integrated the concepts of discrete and continuous processes when conducting a performance analysis of an electric-wire factory. Similar integration of discrete concepts (allocation of material-handling equipment) and continuous concepts (production rate of a blast furnace) appears in a study of pig iron allocation to widely separated steel mills (Díaz et al. 2007). Analogously, a study of airport baggage systems (Savrasovs, Medvedev, and Sincova 2009) treats suitcases discretely when passengers check them, but continuously during conveyor belt flow.

Selecting the most appropriate simulation software tool for an application always requires thought and care. Typical items meriting consideration are the animation required (two- or three-dimensional), the level of programming skill required to use the tool effectively (e.g., familiarity with object-oriented or agent-based concepts), the availability of any constructs explicitly needed (e.g., bridge cranes, conveyors, automatic guided vehicles), the level of vendor support for the software, and many other interacting considerations. These considerations are thoroughly enumerated in (Banks 1998). This paper de- scribes three case studies in high-speed bottle manufacturing, associated results and inferences. In the case studies described, AutoMod® (Rohrer 2003) and Enterprise Dynamics® (Hullinger 1999) were used for simulation modeling. These examples are used to present a simulation software selection methodology. Relative to projects such as that described in this paper, additional criteria of importance include: the objectives of the model, discrete-event capabilities of the software, continuous modeling capabilities of the software, and the ability of these two world-views to interface smoothly and productively in the same model.

 

 

PROCESS FLOW

This section describes the production flow in the high-speed bottle manufacturing line. Note that three different systems (one facility in each case study) are explained here.

 

2.1 Introduction

The high speed bottle manufacturing line consists of the following equipment types

• Forming Machine – Creates the flexible plastic material
• Blow Molder – Creates bottles (or logs – pairs of bottles joined at the neck) by blowing a puff of air through the flexible plastic material
• Leak Tester (or ALPS) – Tests the bottles for defects (leaks) using an air-test mechanism
• Hopper (or Accumulator) – A large bin system where bottles are dumped if the line backs up
• Unscrambler – used to orient and organize dumped bottles to be able to put them on the conveyor system
• Demoiler – Splits the logs into bottles (used in cases only where blow molder makes logs)
• Palletizer – Last step on the manufacturing line that involves organizing groups of bottles into a pallet for Number and configuration of bottles on a pallet vary depending on bottle size.
• Mass Conveyor – Large bulk conveyor system on which bottles are dumped in unorganized fashion
• Cleated Conveyor – conveyors on which bottle dumps are spaced using cleats (or protrusions)
• Air Conveyor – High speed conveyor on which bottles are held by the A stream of high velocity air moves the bottles through the line
• Lane Divider – Gate system used to route bottles from one main conveyor line into multiple
• Lane Merger – Gate system used to send bottles into one conveyor from multiple source conveyors

 

2.1.1 Case Study I

The manufacturing line under consideration uses a blow molder (3600 bottles per hour) that blows logs. The logs are then dumped onto a mass conveyor after which they go through multiple dividers, are oriented uniformly, and then travel to a transfer conveyor that changes their orientation by 90°. The last step in the process is the cutting of these logs into individual bottles on the demoiler. The hopper is used only when the line backs up all the way to the start of the mass conveyor (usually due to downstream equipment failure). This event triggers the opening of a dump door, through which the hopper is filled to avoid blocking and eventually stopping the blow molder operation.

In an alternate scenario, a system with an inline hopper/unscrambler system is tested. All bottles in the line are sent into the hopper, unscrambled, and then sent to the demoilers. This setup involves lower capital costs, but with a potential risk of increasing lead times beyond acceptable levels.

 

2.1.2 Case Study II

The bottle manufacturing line uses a network of air conveyors to transport bottles through the system. The process begins at the forming and blow molding steps. The blow molder (40k+ bottles per hour) creates individual bottles and puts them on an air conveyor. The air conveyor transports the bottles to the leak tester through a 2:1 lane merger. If the line backs up to- wards the blow molder exit point, bottles are dumped into the hopper based on a photoelectric eye trigger. Bottles in the hopper are unscrambled and fed into a re-entry line that feeds that second arm of the 2:1 lane merger. The merges allows bottles from the main line by default and from the re-feed line when the main line is clear (detected using photo-eye triggers). The leak tester can operate at three speeds depending on the level of accumulation in front of it. The greater the accumulation, the faster the tester is run. The leak tester experiences a time lag (approx 3 seconds) between speed changes.

After leak test, bottles are sent down a long air conveyor to a 1:6 lane divider. The 6 lanes then feed a palletizer machine that creates a 15×14 matrix (14 rows of 15 bottles each) of bottles on the pallet. (Figure 2) The status of each lane is tracked by three photo eyes.   Each lane can be in an ‘off’ state, ‘want short slug’ state or the ‘want long slug’ state.   A slug is a stream of bottles released by the 1:6 gate. The 1:6 gate has to accumulate at least a long slug of bottles (sensed by a priming photo eye) before it can feed any of the palletizer lanes. By default, the 14 rows are created using bottles from the lanes in three passes using a 6 lanes – 6 lanes – 2 lanes configuration. If one of the lanes is off (not enough bottles), then other configurations can be used.  After each pass, the palletizer indexes before the next pass can begin.

 

2.1.3 Case Study III

The system in case study III has a very similar flow in comparison to case II. However, the layout and lengths of conveyor sections are distinctly different. The major difference from the operational perspective is the presence of a 8-lane palletizer. Also, the re-feed line does not feed the main leak tester, but has a separate line and a dedicated leak tester (smaller) that feeds the last palletizer lane directly (Figure 2b). The default configuration of the palletizer is a 8-lane – 6-lane operation sequence to make the 14 columns on the pallet.

 

2.2 Challenges

Modeling the above described high-speed manufacturing lines has distinct challenges

• Large number of entities in the system – The WIP (number of bottles) in the system could be anywhere up to 40,000 Large number of model entities (or loads) means long runtimes.
• Slug modeling on intensive material handling systems – Decelerations around bends, causes the bottles on an air conveyor to This has to be modeled to ensure accurate representation of intermittent starving of equipment.
• Control system level logic (photo eye positions play a key role in system performance) – the model has to be physically accurate given that moving a photo eye impacts system performance. A detailed study of photo eye positions and their specific functions was
• Numerous palletizer configuration settings – The need for involved logic using photo eye feedback is a challenge. Breaking the contention between two possible configurations was also a

 

 

CASE STUDIES DESCRIPTION

3.1 Case Study I

The main objective of this project is to compare performance of two proposed line designs. Line throughput and blow mold- er blocked time percentage are two important key performance indicators. Hopper utilization is also a parameter of interest. One of the secondary objectives of the study was to determine the optimal speeds of conveyors and interacting equipment.

The simulation models were built using Enterprise Dynamics®. A custom input-output interface was developed in Excel®. Figure 3 shows the time in state chart for each line design option. As seen in the chart, the blow molder is blocked for 23% of the run-time. However, the hopper is hardly utilized. Further investigation of simulation results and standalone capacities revealed that the system bottleneck was the mass conveyor system in option 1. Increasing the speed of the mass conveyor to balance the line reduces the blocked percentage to nearly 0%.   This result is comparable to the performance of the alternative option (Figure 3b). However, the hopper utilization for the alternative option exceeds planned capacity by 300%. Hence, a recommendation was made to use Option 1 design with a line balanced mass conveyor system. Average throughput from the system is 35,900 bottles per hour. Further sensitivity analysis was conducted to ensure robustness of the system to large downtime fluctuations.  Maximum hopper accumulations were recorded in each case.

Several key issues surfaced during the analysis phase of this model, including long run-times when parts accumulated in the hopper system (in excess of 10 hours). Data recording was sluggish given the large number of entities in the system.

Several solutions were considered to resolve these issues including using variables to record part accumulations in the buffer, switching to a rate based model etc.

 

3.2 Case Study II

The main objective of this project is to test the throughput capability of the system and identify the key bottlenecks on a throughput improvement roadmap to achieving the target. Evaluating the performance of the palletizer system in interaction with the rest of the line was also an important objective. The plant also wanted to analyze the best combinations of equipment speed settings, hopper size and photo eye positions. The effect of the 2:1 gate and re-feed line was also under scrutiny. Like Case Study I, the two main key performance indicators were throughput and blow molder blocked percentage.

Given the importance of modeling conveyors and photo eyes, AutoMod® was chosen as the simulation modeling tool. Model parameters were initialized using an Excel® data sheet. The hopper was implemented as a variable count, rather than a queue in AutoMod®. This helped reduce the model run-time significantly (to under 1 hour). As seen in the TIS chart in Figure 4, the ALPS (leak tester) seem to be limiting throughput in the system. The availability of the leak tester was in turn influenced by blockage due to downtime on the palletizer and starvation due to downtime at blow molder. Even when the ALPS speed was increased, throughput did not increase. It was inferred that the conveyor line and palletizer lanes do not provide sufficient cushion to palletizer downtimes. It was recommended the plant focus on improving palletizer reliability. Also increasing conveyor lengths, helped in increasing system throughput. Given the impact of only the downstream equipment on the line performance, the hopper did not have significant impact. Tests showed that running the system without an hopper increased blow molder blockage by less than 1.5%. The one issue with the model was its limitation in experimenting with different conveyor lengths. Each scenario involving change in conveyor lengths required relaying of conveyor sections and re-organization of photo-eyes.

3.3 Case Study III

The main objective of this project is to test the throughput capability of the system and the usefulness of using a 8-lane palletizer system with a dedicated re-feed line.   As in case study II, different photo eye positions and hopper capacities were tested. The model was built in AutoMod®. Base model results (Figure 5) show a 6% blockage on blow molder equipment. Different palletizer operation modes were tested. Optimal palletizer speeds were determined to reduce blow molder blockage to under 4%. The base model shows several hours when the system throughput drops to zero. When the dedicated re-feed line was used to build complete pallets (in cases when the main line was starved), the system throughput never dropped to zero in any given hour and the throughput increased by almost 2%. The plant implemented the correct combination of parameters to achieve throughput target.

SOFTWARE SELECTION

This section addresses the issues discussed in Section 3.3.1, 3.3.2 & 3.3.3 with regards to software selection. Methodologies are discussed from three perspectives – Brainstorming, questions from vendor to user, and questions from user to vendor. Key considerations in the process are also summarized.

4.1 Brainstorming

During the software selection phase of the simulation project, brainstorming different aspects of the system and software capabilities is vital to making an informed decision. The team (cross-functional) should characterize the system under consideration and evaluate the need and importance of software features (such as 3D, price etc). Each of the features should be dis- cussed, keeping in mind the objective of the project from each department’s perspective.   Brainstorming helps in orienting the team towards a common goal and sets up a firm project objective.

4.2 Questions to ask

• Self-Evaluation
  • A simulation software filter is a quick yet effective way of narrowing down options. After the brainstorming session, questions about the situation at hand (system, budget etc.) should be transformed into a rating for each software. A sample simulation software filter is shown in Figure 8.

4.2.2 User to Vendor 

When the software selection brainstorming session has been completed, a firm objective has been devised, and self-analysis of requirements has been performed, it is then time to start talking to the software vendors. These days most software can be used to model any given scenario or logic. The effort involved in modeling, though, can be enormously variable depending on the system and the objectives. The set of questions provided below is a collection of questions that prospective users have posed to the authors, and information that the authors feel is necessary to provide (even if the prospective user does not ask for the same). As a part of obtaining answers to these questions and the selection process, the potential user can also leverage the power of online social networking (especially for new simulation users) such as LinkedIn’s <www.linkedin.com> many active simulation groups as well as PMC Forums <forums.pmcorp.com>. Given the enthusiasm for social networking and media web-sites these days, a lot of experienced simulation users participate actively on these forums and their opinion tends to be very informative and unbiased.

4.3 Abstraction Levels

The biggest challenge for a simulation engineer during the conceptual design phase of the project is modeling at the right abstraction level. Abstraction levels can overlap and sometimes making a binary decision can prove tricky. However, the ease of use of a particular software hinges on the level at which the prospective user wants to model. Some simulation tools can be very easy to use when modeling assembly line workstations to study throughput, but can be extremely tricky to use when handling work-cell type robotic interactions or cross-transfer type conveyor systems to study acceleration parameters. Note that the software selection depends not only on the abstraction level but also on the objective. Figure 10 shows the classification of abstraction levels. The list is not meant to be comprehensive, but can serve as a general framework/guideline for classifying models by abstraction.

At the enterprise level, the model usually involves a supply chain system with each echelon serving as a building block. Such models can be used to evaluate interaction between production fluctuations at every echelon and the impact of a transportation model on delivery lead times. Plant level models use each shop or component manufacturing facility within a plant as a building block. Such model can be used to analyze intra plant material handling, end of line inventories and impact of inter-department product sequences. Shop level models are usually built to analyze line speeds, interaction of production lines with subassembly lines, color banks, cross transfers etc. Cycle times are usually modeled as a line speed. At the line level, building blocks are individual stations. These models may or may not involve labor. Objectives include bottleneck identification, disruption analysis, what-if scenarios relating to new equipment, setup times, downtimes etc. Work cell level models incorporate a specific portion of the line in great detail. Applications are for detailed analysis within a strictly defined scope such as examining man-machine interaction on a three speed cross transfer or control logic simulation of a multi-crane (on a single bay) system.

 

4.4 The 5-Why approach

A key lesson from the lean culture is attacking the root cause. The 5-why approach to a problem yields an answer that is very close to the ultimate reason (cause) for the symptom being observed. This technique is directly applicable to the software se- lection methodology by helping to identify the abstraction level at which to model.   During software selection, questions to be asked include:

• Why do I need simulation?
  • Sample Answer: To validate throughput of the system
• Why do I need to validate throughput?
  • Sample Answer: To ensure that there are no unforeseen bottlenecks
• Why would there be unforeseen bottlenecks?
  • Sample Answer: Because the system is very complex
• Why the system is considered complex?
  • Sample Answer: Because of the presence of a multi-level conveyor system
• Why is there a multi-level conveyor system?
  • Sample Answer: To ensure automated and high-velocity routing of the many SKUs in the system

For the above example, this series of questions probably moves the decision towards a software that has strong material handling capabilities.

 

4.5 Summary

This paragraph summarizes the key inferences from the proposed software selection methodology. First and foremost, listen to the voice of the customer (the process) i.e. the objective statement. Next, analyze how you can meet this objective. This involves dropping the software, and building a valid conceptual model. As mentioned before, one should ask at every stage, “at what level of detail should I be modeling to meet my objective?” An important step in this process is to make sure that one does not get stuck with the ‘fixed tool’ mindset. The non-avoidance of this syndrome could yield a sub-optimal choice and hence longer than needed model development lead time. Once the conceptual model is at a fair degree of maturity, study features in each tool (use the software selection filter, abstraction levels and brainstorming sessions) that will help to realize the conceptual model. Also, keep up to date with latest interfaces and developments in software.  The prospective user should remember that nowadays a few things are a given (E.g. Excel® reporting).

 

CONCLUSION

Case studies with results and inferences on three bottle manufacturing lines are discussed. The pros and cons of the software selection in each case are also explained. Based on the case studies, a detailed methodology for software selection is presented. Brainstorming, using the 5 why (root cause approach) technique, or employing a simple software filter are all effective ways of narrowing down options during software selection. A key component that is usually missed during software se- lection is considering the objective of the project. Though the system or industry of use may play a vital role is software selection, it is the objective (also decides the abstraction level) that should drive the decision. A classification of abstraction levels and their importance in modeling is also presented. Staying up-to-date with software developments and standards is also an important factor in making good software selection decisions. Given the capabilities and cross-industry application of most simulation tools in the market, selection of the right tool for the right job could prove vital to keep development costs and analysis efforts down.  This in turn ensures an effective and quick ROI on the simulation project.

 

REFERENCES

Banks, J. 1998. Software for Simulation. In Handbook of Simulation Principles Methodology, Advances, Applications, and Practice, ed. Jerry Banks. New York, New York:  John Wiley & Sons, Incorporated, 813-835.

Díaz, D., F. J. Lago, M. T. Rodríguez, and S. Rodríguez. 2007. Knowledge Based Extendable Simulation of Pig Iron Allo- cation. In Proceedings of the 21st European Conference on Modeling and Simulation, eds. I. Zelinka, Z. Oplatková, and

49. Orsoni, 45-49.

Gordon, G. 1975. The Application of GPSS V to Discrete System Simulation. Englewood Cliffs, New Jersey: Prentice-Hall Incorporated.

Hullinger, D. R. 1999. Taylor Enterprise Dynamics. In Proceedings of the 1999 Winter Simulation Conference, eds. P. A. Farrington, H. B. Nembhard, D. T. Sturrock, and G. W. Evans, 227-229. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.

Law, A. M., and M. G. McComas. 1998. Simulation of Manufacturing Systems. In Proceedings of the 1998 Winter Simulation Conference, eds. D. J. Medeiros, E. F. Watson, J. S. Carson, and M. S. Manivannan, 49-52. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.

Rohrer, M. W. 2003. Maximizing Simulation ROI with AutoMod. In Proceedings of the 2003 Winter Simulation Conference, Volume 1, eds. S. E. Chick, P. J. Sanchez, D. M. Ferrin, D. J. Morrice, 201-209. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.

Savrasovs, M., A. Medvedev, and E. Sincova. 2009. Rīga Airport Baggage Handling System Simulation. In Proceedings of the 23rd European Conference on Modeling and Simulation, eds. J. Otamendi, A. Bargiela, J. L. Montes, and L. M. D. Pedrera, 384-390.

Yenradee, P., S. Sarochsuwan, and T. Nakornsri. 1996. Performance Analysis of Continuous and Discrete Processes in an Electric Wire Factory. In Proceedings of the 1st Annual International Conference on Industrial Engineering Applications and Practice, eds. J. J. Chen and A. Mital, 708-713.

 

AUTHOR BIOGRAPHIES

 

KARTHIK VASUDEVAN is a Technical Leader at PMC in Redmond, WA. His technical skills span simulation, software, controls and scheduling domains with experience in AutoMod®, Witness®, Simul8®, Extend®, Emulate3D®, VB, C++ and Asprova®. He is an ASQ certified Six Sigma Black Belt and is APICS Certified in Production & Inventory Management. He received a Master’s degree in Industrial Engineering from the University of Arizona, Tucson, USA and a Bachelor’s degree in Electrical and Electronics Engineering from Sathyabama University, Chennai, India. He received the “Dean’s award for Outstanding Graduate Student” and the “Award for Excellence” at the University of Arizona. His career and research in- terests lie in multi-paradigm simulation modeling and analysis and in the efficient integration of various IE techniques and software systems with computer simulation for creating better business strategies. He is a professional member of the IIE (Institute of Industrial Engineers), ASQ (American Society of Quality) and is on the steering committee of the MSUG (Michigan Simulation User Group).

 

RAVI LOTE is a Consulting Project Manager at PMC, Dearborn. Over the last ten years, Ravi has built simulation models for dozens of customers in the U.S. and overseas. His functional areas of expertise include simulation modeling, process im- provement and supply chain optimization. Ravi has a Bachelors’ Degree in Mechanical Engineering from Shivaji University, India and a Masters’ Degree in Industrial Engineering from the University of Massachusetts, Amherst. He is currently pursuing an M.B.A. from the University of Michigan, Ann Arbor. Ravi has completed several professional certifications, is a certified Six Sigma Black Belt and a certified MODAPTS® professional for conducting Industrial Engineering time studies.

 

EDWARD WILLIAMS holds bachelors and master’s degrees in mathematics (Michigan State University, 1967; University of Wisconsin, 1968). From 1969 to 1971, he did statistical programming and analysis of biomedical data at Walter Reed Army Hospital, Washington, D.C. He joined Ford Motor Company in 1972, where he worked until retirement in December 2001 as a computer software analyst supporting statistical and simulation software. After retirement from Ford, he joined PMC, Dearborn, Michigan, as a senior simulation analyst.   Also, since 1980, he has taught evening classes at the University of Michigan, including both undergraduate and graduate simulation classes using GPSS/HÔ, SLAM IIÔ, SIMANÔ, ProModel, SIMUL8, or Arena®. He is a member of the Institute of Industrial Engineers [IIE], the Society for Computer Simulation International [SCS], and the Michigan Simulation Users’ Group [MSUG]. He serves on the editorial board of the International Journal of Industrial Engineering – Applications and Practice. During the last several years, he has given in- vited plenary addresses on simulation and statistics at conferences or seminars in Monterrey, México; İstanbul, Turkey; Ge- nova, Italy; Rīga, Latvia; Göteborg, Sweden; and Jyväskylä, Finland. He has served as Program Chair of the 2004, 2005, and 2006 Summer Computer Simulation Conferences, and also for the 2005 IIE Simulation Conference. In May 2007, he was the Track Coordinator for the simulation track at the annual Institute of Industrial Engineers conference.

 

ONUR ÜLGEN is the president and founder of Production Modeling Corporation (PMC), a Dearborn, Michigan, based industrial engineering and software services company as well as a Professor of Industrial and Manufacturing Systems Engineering at the University of Michigan-Dearborn. He received his Ph.D. degree in Industrial Engineering from Texas Tech University in 1979. His present consulting and research interests include simulation and scheduling applications, applications of lean techniques in manufacturing and service industries, supply chain optimization, and product portfolio management. He has published or presented more that 100 papers in his consulting and research areas. Under his leadership PMC has grown to be the largest independent productivity services company in North America in the use of industrial and operations engineering tools in an integrated fashion. PMC has successfully completed more than 3000 productivity improvement projects for different size companies including General Motors, Ford, DaimlerChrysler, Sara Lee, Johnson Controls, and Whirlpool. The scientific and professional societies of which he is a member include American Production and Inventory Control Society (APICS) and Institute of Industrial Engineers (IIE). He is also a founding member of the MSUG (Michigan Simulation User Group).