10.09.08
Simulation as a Leading Indicator
Over the past twenty years I’ve seen many cycles in the marketplace (especially automotive). Our current downturn/recession/depression (pick your term) has been particular stark. What I have noticed in the past is that capital investment is often preceded by the need to simulate and make sure the investment is justified. We have started to see an uptick in simulation requests in the past few months. Hopefully the trend continues. Usually there is a 6-12 month lag between the pickup in simulation and the economy in general. I don’t have any historical documentation on this but I’m thinking that Spring of ‘09 (for those of us in the northern hemisphere) will hopefully bring better times for the economy. I would be curious if any of you have seen similar trends and whether or not things are picking up for you……
Winter Simulation Conference
It’s that time of year again!!!! This year’s conference is in Miami from December 7-10 at the Hotel Intercontinental.
This is a great conference with about 700 attendees, great speakers, and a chance to see all the vendors in the simulation community. The conference is in conjunction with MASM (Modeling and Analysis for the Semiconductor Manufacturing) this year so attendance should be even higher.
For more information on the conference, visit www.wintersim.org.
08.07.08
Effective Communication
At the start of every project it is necessary to define the goals of the project and frame how the model will be built to satisfy these goals. One goal that is implied in every project but rarely discussed is communication. For a simulation to have any value, the results must be understood and appreciated by the decision makers. As simulation modelers it is our job to determine the most effective way to get our point across. The extreme example is GPSS programmers. As late as the 1980s I would see the results from a model formatted as a 200 page printout off a VAX mainframe. The customer would need to be able to pour through the data with the programmer and understand the nuances of the model to have any appreciation for the results.
Now that is not going to happen today. Almost every simulation is either graphical or has the benefit of a PowerPoint presentation to ease the burden of understanding. However, we still have a wide gamut of methods for presenting results. In some circles, detailed presentation of confidence intervals, type II error, chi-squared analysis is expected as part of result presentation. To leave them out will only cause more question and doubt on the part of the customer that the modeler knows what he/she is doing. More commonly, customers want to know is results are statisically relevant (significant) and they are more than happy to leave the verification to the analyst.
The point here is that you need to know your customer. Are they the type that want to see the gory details of the statistics? Can you present terms like statisitical significance without losing them in the process? Do they want a highly visual model to involve plant floor personnel in the model validation?
We can make simulation models do so many things and present them in so many ways, it is necessary to make the method of communication known from the start. A few tips to head off problems….
1) Always have detailed statistics available during your presentation in case you are called on to present them. You don’t need to make them part of your base presentation but they should be available.
2) View the results from the perspective of the customer. For those of you familiar with Lean Manufacturing and Value Stream Mapping. Stick with the value added statistics. Try to tie each slide, graph, or statistic back to the original goals of the model. Presenting utilization details for non relevant operations just serves to hide the real point you are trying to get across.
3) Don’t feel like you need to overwhelm people with numbers. In the end, simulations make decisions. Hit the high points early in your presentation. Tell them what the results are early and then back it up with the detail.
4) Make things visually recognizable. You do not need to be explaining what each graphic on your screen represents. If it is not obvious to someone who is familiar with the system, then you did not do a good job presenting the animation in your model. Legends, Color Coding, Dynamically changing labels, and visual detail all get people past “what is that?” to “why is that?”
5) It is hard to over communicate in these situations. Feel free to stress important points several times in several ways. Just avoid Powerpoint poisoning. We have all been in presentations with 50 slides that could have been done better in 15. Ask yourself, why do I have that slide? If it does not tie back to the original goals, keep it as back up material for those that want more detail.
Good luck and know your customer.
07.07.08
Improving Existing Systems
It’s been a while since I posted. I thought I would discuss a topic that has some relevance in today’s market. Given the state of the economy, many of the automakers and many of the businesses in the US are pulling back from new capital investments and reassessing their strategies. As simulation engineers, we turn our focus to improving the systems that are already in place. Modeling existing systems and looking for places to improve is a slightly different challenge that helping design a new (greenfield) facility or system.
A few questions/opportunities to consider when modeling an existing system.
- You should be excited about the data. Ok, excited is a bit over the top but, there should be a lot of historical cycle time and downtime data just waiting for some to find out why its relevant.
- Existing models. Some systems have models that have been built and recommendations that were made from past studies. Has anyone followed up to see if the recommendations were followed? Has anyone checked that the assumptions made were valid (i.e. do the real cycle times match the assumptions from the first model?)
- What advancedments/standards or generally good ideas have you seen implemented at other locations/lines within your organization? Do they apply to this system?
- Is there a gap in communication? Would a simulation video/presentation help focus the existing team on the goals and areas for improvement?
- What are the complaints of the operators that are on the current line or in the current facility? How can simulation address these issues?
There is a myriad of possibilities. Ask the right questions and embrace the challenge of continuous improvement. Every system can benefit from a critical, helpful eye that wants to quantify why changing practices will improve the way things are done.
05.21.08
The “Worst Case” Trap
One of the biggest problems with most simulation projects is the availability of good data. The phrase Garbage-In-Garbage-Out gets tossed around liberally. However, this is a double-edged sword. As an analyst, villifying the existing data is meant to prompt your customer to go get better data. Many times poor project timing or the lack of a convienent comparable system leads to the project team to take the easy way out. That easy way is to look for the worst case scenario on the data and use that as an input. The logic behind the decision is that if the system can handle the worst case, it will be sufficient for any production goals that have been set.
The phallacy in that approach is twofold. First, using worst case data can easily lead to a system that is over-designed. Too much capacity is required to support the wild variations introduced by worst case data. Second, if your goal is something other than production (say inventory reduction), your worst case data may have the opposite effect.
I ran into this problem on a recent engine-chassis marriage project. The engine-chassis marriage operation at an auto plant involves ”stuffing” the powertrain for a car into the shell of the car and fastening it in place. Usually the power train is moved up into place while the car body moves overhead. A separate build-up line is used to assemble the powertrain component and the sequence of the engines and transmissions matches the sequence of cars being built on the main production line. A picture of a vehicle that “stuffs” the powertrain in place is shown below.
For this project, there were two main car styles that were produced by the plant. Each “style” required different tooling for the cart shown. the time to change the tooling was several job cycles so extra carts with a mixtures of tooling options were used to allow time to switch plates without interrupting production. The key to sizing the system was how often these tooling plates would need to change. This is driven by the sequence of cars going down the line. Getting this sequence proved to be a challenge because the vehicle sequencing program at an assembly plant is quite complex. Initially, we tried a completely random mix of jobs. The rationale was that this would be the worst case. While it truly was a very bad case for the system, it would have driven us to expensive changes to the system had we not tried to find a more realistic solution. By spending the time to get an accurate reflection of the sequence, we were able to proceed comfortably with a system that had a lower capital investment.
In short, the competitive landscape of the manufacturing does not allow us to take the easy road and protect for the worst case scenarios. We need to be diligent about gathering the appropriate data. An error to the side of caution can be as damaging to a company as an error that causes a system to be undersized.
05.06.08
Estimating Project Time
When starting a simulation project, one of the more difficult things to do is estimate the expected time required. If you are part of an internal group, this is critical to the usefulness of a model. If it is not ready in time, the conclusions may be moot. Decisions will need to be made and often those decisions will not be postponed while waiting for a simulation to be completed. As a consultant, our profit is usually tied to our ability to estimate. On long term projects, it may be possible to provide an hourly rate and work as part of a team. While this allows your profit margin to remain in tact, your ability to estimate well and deliver models on time will dictate whether or not you get the next project.
So what are the issues? I have an acronym that I use when looking at a project to determine the time required. I need to look at the F-A-C-T-S
F- FOCUS
Why are we building this model? What questions need to be answered and what questions do NOT need to be answered. It is easy to assume that the model needs to do everything. In a rush to make the end customer happy it is easy to say, “I can model anything”. While it might be true, this leads to complicated models that take too long to build, too long to change, and ones that are not nimble enough to be part of a team decision making process. Use a rifle approach to defining the scope of the model, not a shotgun. Be clear with the end customer that the model is designed for specific purposes. Its like designing a car. You are not going to bolt a trailer hitch on a sub compact at the last minute because you have decided you want to tow a boat. If they need an SUV model, decide that early on and let the customer decide.
A - Assumptions
I am not referring to the assumptions that are made as part of the model building process. Once a project begins you can collect cycle times and understand how decisions are made. I am referring to project level assumptions like - “the timing on this project is tight” or “animation is important” or “there are a lot of variables to test” or “we want to have a scripted video file as an output” or “we have complex 3D data that needs to be filtered and included in the project”. These are game changing expectations that the customer has. You need to ask as many relevant questions as you can. These can be very generic questions but they will strike at the heart of why the model is being built and what will be considered a successful outcome. Even if you write a scope that says the model will not do X and not do Y, the customer’s satisfaction will win out in the end. For the most part they do not know what is easy and what is difficult to model. It is common for customers to assume that all their changes are minor. You need to tell them up front what will be difficult to change later so they can make decisions about how the model will be used.
C- Confidence
Confidence in the model to be built. Have you built or supervised the building of a model like this in the past? If not, you better leave some time for the unknown. The first time I build a new type of model, I add 20-30% to the time for the unexpected. It is hard enough to deal with the changing landscape of a typical engineering project. This time is useful for researching the most effective way to model a particular aspect of the system or simply for extra model verification to be sure that the new model you built is functioning correctly.
T - Training
Does the end user want to use this model later? Does the model need a friendly interface to make is accessible to others? Are you supervising someone else building the model? Do you need training on a specific aspect of the software that you have not used before?
S- Software
Does the model need to be built in a specific software package? What version of the software? Have you used that specific version of the software? Do you know what bugs are published for that specific version? Is there a reason to lobby for a different software package? How fast will experimentation run? Will the animation requirements place an undue burden on the software? Do you have the proper hardware to run the model in the allotted project schedule?
In summary - interview the customer to find out what they know about the project. Treat it as an interrogation without the bright lights. Your organization and methodology will give the end customer confidence that they have placed the project in the right hands.
03.26.08
Software Selection (part 2)
My previous post talked about the role of animation on software selection. Another key factor in software selection is level of use. Over the years, the “home” for simulation within an organization has been debated.
If an organization has enough simulations, often an expert is crowned and all simulations flow through that person or even group. The benefits of this structure is that the models tend to be more standardize, the quality of the models is easier to control, the analysis is more rigorous, and the models tend to get done on schedule. The downside to this centralized approach is that the modelers are often unfamiliar with what they are modeling. Subject matter experts need to be involved to guide them through the nuances of the process and the models will often have too much detail since centralized groups do not know what is important and what is not important for a model (that is a whole another post!!!). Centralized groups tend to select generic software with a lot of features. These programs are usually more difficult to use but they produce models that are more elegant in terms of animation and/or logic. These packages will often have a full programming language and users will tell you they have never built a simulation that did not involve some sort of custom programming.
If organizations integrate simulation into the job of the industrial engineer responsible for the a project or plant, simulation is no longer the prime focus of the individual. In this case, the software by nature tends to be less driven by elegance and more driven by functions. Models are less standardized and tend to look more like flow charts than plant layouts. These are often single use models that only include the information required to answer a specific question or series of questions. The analysis is often more common sense and usually take less time. These models are often only built when other analysis techniques (spreadsheets, linear programming, or other decision methods) fail to produce a consensus. While some programming is used in these models, users will tend to avoid it unless it is required.
So what does this mean? Really some common sense conclusions. If you are a full time simulation modeler, you should tend toward software that allows you to develop models that are standardized, reusable, and relatively complex. Programs like AutoMod, FlexSim, QUEST, GPSS/H, and other language based software products excel.
If you are only going to use simulation occassionally, products like Simul8, Witness, ProModel, Extend, and other flowchart based tools whose programming tends to be broken up into smaller groups of statements are probably the best choice since their learning curves are easier. These products make it easier to come back to modeling after several months working on other issues.
Now I know that these are not absolutes. I can hear the comments already about how I called Product X a “programming based system” but its easy to use and how Product Y has all the features and capability of anything on the market. The reality is that each of these products has found its niche in the market place. Some products are great for building simple models very quickly (Simul8). Other products are designed to create very large and complex models that can still execute fast enough for analysis on a basic computer (AutoMod).
When looking for software you need to understand not only the features of the software but also the time you have to commit to the process.
03.14.08
Software Selection (part 1)
About 10 years ago I gave a presentation to the Michigan Simulation Users Group (MSUG) on the role of 2D versus 3D animation. Computers have gotten faster since then but we are still challenged by the ability of simulation modelers to build models that our computers can’t handle. That being said, the following question still holds true—
When should I use 2D versus 3D animation?
Traditionalists feel like 3D animation does not add value to the analysis of a project. The technophiles in the group often think that everything should be in 3D because its how we see and learn most naturally. I’ve always drawn the line in a different place.
If a simulation includes spatial characteristics, it should be modeled to-scale. Almost every to-scale software package that I have seen does not limit itself to 2D. For example if I am modeling the movement of forklifts to handle material on a dock, I would rather import a CAD file, place my objects at the appropriate location in the layout, and describe how fast the vehicle can drive. This is more natural than figuring out the time or distance required for a forklift to move between locations. If the simulation can derive input information by leveraging information entered about specific objects, by all means, model that way. I would not use a 3D (to-scale) package to model a call center. The distance between phones or the layout of the call center does not really matter unless I’m trying to figure out the effect of operators walking to a poorly located break room.
You should let the computer do the calculations whenever possible. The time to develop the models are nearly identical and the time to update a model is usually much lower when modeled to scale. Imagine I have my dock area modeled in 3D. If I need to move docks or move potential storage locations. I simply move them. I do not have to figure out how far the new travel distance is or what time different exists. In a 2D world I also lose the concept of congestion unless I model all potential stopping points as destinations.
So, how does this effect software selection? You need to consider the types of models you are building. Do not focus simply on the number of times you are going to use the software or a percieved ease-of-use. I have not seen an appreciable difference in ease of use when it comes to 2D versus 3D software products. Often 3D packages are used to solve more complicated problems. If you apply a 2D software package to a problem that should be solved in 3D (or simply to-scale), you will either make assumptions that can harm the accuracy of the model or you will spend more time wedging the problem in to the normally limited constructs available in a 2D package.
03.07.08
The Taurus in the Tree
Those of you who know me have probably heard this story but I thought it would entertaining for a Friday. My first trip after September 11th was to Nashville, TN for a simulation project review. I rented a car from Hertz (Ford Escape). I got about 30 miles from the airport and the engine basically blew-up. I think they forgot to put oil in the car or something. Anyway, I called Hertz and they said they would send a flatbed with a Taurus on the back. The driver would swap my Escape for the Taurus and I would be on my way.
So I relaxed with a copy of USA today and waited for the flatbed to show up. After about 45 minutes, I saw the flatbed crest the hill behind me with a white Taurus on the back. As I put away the newspaper, the flatbed started to pull past me. When the flatbed was directly next to me it was rear-ended by a semi-truck going about 70 miles per hour!! The noise was deafening.
Luckily, the flatbed narrowly missed the front of the Escape but that was just the beginning. While the flatbed was careening down an embankment, the semi-truck went left across several lanes of traffic and a grass median. The Semi ended up about 200 yards into a farmer’s field and miraculously, it did not hit another vehicle.
Back to the flatbed….. About 50 feet in front of my vehicle, the chains holding the Taurus on the back of the flatbed broke. This resulted in the Taurus launching into the air like a gymnast on a tumbling run. I would guess that it was about 20 feet in the air when it entered a stand of trees by the side of the road. The Taurus never hit the ground.
After several more calls, several more hours with the State police and another car from Hertz (driven down by an employee), I was back on the road to my meeting a mere four hours late. Later that night I had to fly to Toronto. While we were in the air space near Toronto, an F-16 was scrambled to talk to an Air Canada flight from LA that was not responding. Our flight had to clear the airspace around Toronto because as the pilot put it — ” There is an F-16 that really wants to talk with one of our colleagues….” This put a cap on quite a day. Whenever I feel like I’ve had a tough day on the road, this day puts things in perspective. I consider myself very lucky. In case you were wondering, I had one on of the first Handsprings (Palm Pilot Predecessor) with a camera. The photos from that day are below…..
The Appropriately Named “Ford Escape”
Semi Truck in the Farmer’s Field
The Flatbed Truck (the driver was shaken but not hurt)
The Taurus in the Tree
02.29.08
System Types and Simulation Objectives
Whenever I see a new system that may need simulation, one of the first things I need to do is figure out the system type. Generally speaking, system types are defined by features of the system. Some of the features that I key on include:
Open Versus Closed Loop - In automated systems, carriers or pallets might be used to deliver parts from a load station, through a series of operations, and then to an unload station. After the unload station, the carrier/pallet needs to return to the load station to pick up a new part. This is an example of a Closed System. An example of an Open System would be a delivery conveyor that ships boxes from point A to point B. Nothing has to return to the beginning of an open system.
Simple or Complex Flow - Many large systems has a very straight forward flow. Higher production systems tend to be dedicated to specific task. The “Flow” of these high production systems is often very simple (largely linear) in nature. An example of a system with a “Simple Flow” would be a traditional assembly line. While the functions performed at any given station could be very complex, the decision on where to go next is usually constant. Parts flow through a series of stations. If a system has a “Complex Flow”, the decision making process for deciding how to route parts between operations can be quite complex. An example of a system with a “Complex Flow” is a job shop. A job shop often has a wide variety of machines that perform dedicated tasks. Depending on the part being built, the queue in front of each machine, and the current work in process, a part can be routed through the machines in a different order. The process at any one machine might be simple, deciding when to go to a specific machine is the challenge.
High versus Low Process Variation - This system characteristic refers to the cycle times on individual operations. As each part moves through an operation, does the cycle time vary significantly? Usually when systems are designed, one goal is to remove variation. This isn’t always possible. An example of a system with a high process variation is a paint shop for Semi-trucks. These trucks can vary in size and complexity. As they enter the paint booth, the time for a robot to paint the truck could be double or half the last truck that was painted. There are a lot of examples of Low Process Variation systems. This concept is really the basis for any line balancing algorithm. How can work content be moved around a system to make each station perform a similar amount of work? As systems age, changes will often disrupt an initial balance and take the system from a low process variation classification to that of a high process variation.
So what do these system level characteristics mean when considering a simulation? Each of these system types tend to exhibit different challenges during the modeling process, different questions that typically need to be addressed, and different types of software packages that are ideal for modeling. For today, I’m going to focus on the typical questions that are asked. We’ll leave modeling challenges and software packages for another day because they are related and part of a much larger conversation.
Typical Questions by System Type
Closed Systems - These systems can be very tricky. Its not always obvious where the system is being constrained. A typical problem in the design of these system is that not enough room is left between the unload station and the load station. The diagram below shows a typical closed system.
The part is loaded on to a carrier and it proceeds through three processes (Proc A, Proc B, and Proc C). There are buffers between each operation. If the ”empty return” area cannot hold all of the carriers that can exist in the Buffer portions of the loaded system, the system will not operate at peak performance. Buffers are only effective if they can exist as full or empty. Imagine that each of the Buffers can hold 5 carriers. Now imagine that the Load station has a serious downtime. If the Empty Return can only hold 15 carriers, the last buffer will not be able to empty out and the unload station will have to stop even though there are five more carriers that could be unloaded. Simulations are excellent at helping you determine the optimal size for empty returns. This might not always be the cumulative size of all buffers on the loaded side. Depending on downtimes and travel times between processes, the empty return size could vary significantly. Often, inexperienced system designers will simply close the loop in the shortest distance possible. If you size the empty return too small, you can severely cripple the throughput of a system by making the planned buffers unusable.
Simple Flow Related questions - When a system has a simple flow, you are normally trying to balance the net production across the various processes. If unplanned downtime is higher for a specific process (i.e. - it is naturally more complex), you might introduce some overspeed to a particular station to allow a higher gross throughput. If the average length of a downtime is longer, you might evaluate the benefits of a buffer before and/or after the station to allow other operations to process for a longer period of time before becoming synchronously locked to the failed process. Students of lean manufacturing will want to alter the process to eliminate these differences. While this is an admirable goal, sometimes the capital expense and floor space of an existing system makes process changes impractical. In summary, simple flow systems often drive questions about process speed and the benefits of localized buffering.
Complex Flow Related Questions - complex flow systems are very dependent on the sequence of jobs and operations. The system can yield very different results by altering the order that jobs are processed by the system. This is largely a scheduling problem. Heuristics are useful in evaluating which job to pick from a stack as the next one to process. Often this discussion revolves around batch size.
High Process Variation - Complex Flow systems often have a high process variation too. In a system where you are trying to minimize inventory, it is often desireable to have a batch size of 1. If there are setup times or a wide variation in cycle time between part types, larger batch sizes often make operations have a higher utilization. High process variation systems often dictate questions about the impact of cycle time variation and the contrast between inventory and throughput.
This post is getting long. I’ll continue this discussion next time and talk about some of the less obvious questions that can be driven by the type of system being modeled.
