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.

1. 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. 
2. 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?)
3. What advancedments/standards or generally good ideas have you seen implemented at other locations/lines within your organization?  Do they apply to this system?
4. Is there a gap in communication?  Would a simulation video/presentation help focus the existing team on the goals and areas for improvement?
5. 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.

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.

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.

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.

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.

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

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.

One application of simulation that does not get a lot of attention is PLC emulation.  Using a simulation engine and various communication methods, several simulation packages can provide a way to talk directly with a PLC running ladder logic.  This is advantageous because you can prove out (validate) the ladder logic before the real system exists.  This cuts down on costs and enables project managers to sleep better at night.

Seriously, validating ladder logic virtually can be done quicker and more effectively in a virtual world than it can in the real world.  An engineer at a computer can force IO to a specific state, watch the ladder logic execute and see the reaction of the entire real system without leaving the office.  On the floor, multiple people are required to force the IO and see the reaction.  

The other cost that is avoided is support personnel.  Often union labor needs to be called in to support the commissioning process on site.  Millwrights, electricians, and other labor are required to be paid just in case they are needed.  By testing ahead of time, these resources can be reduced by up to 70%.

Other cases have seen manufacturers avoiding an entire step in their process.  traditionally automated systems are partially, if not completely, set up and run off prior to final installation.  This is primarily done to ensure the operation of the controls.  Now that this can be done virtually, the projects are shorter and cheaper than they were in the past.

One last benefit, controls engineers now have remote access to automated systems around the world.  If the PLC code is changed and stops operating correctly, the logic can be emailed to the support engineer and debugged remotely on the virtual model of the plant.  This saves on travel and leads to better response times. 

For those of you who don’t know, this is a bit of a shameless plug.  Currently I work with V-Sim on a software product that does PLC emulation and I am organizing sessions for the this year’s Winter Simulation Conference in Miami.  If you have an interest in PLC emulation, visit our website, www.v-sim.com.  If you want to be involved in an emulation session at Winter Sim this year, email me at jhugan@gmail.com

Happy Modeling…..

TheSimBlog has been going for one month now.  We have had over 1500 views in the past month.  Thanks to everyone who has visited and commented on blog.   — Joe

There are many ways to measure the usefulness and benefit of simulation projects.  One of the overlooked areas is training.  Training simulations tend to give a lot of benefit for the effort required.  Usually these models are used over long periods of time so the cost is spread over a long time horizon.  There are a number of different ways you can use simulation as a training tool.  Here are some past ways that I have worked on that had training components:

1. Sequence of Crane Operations - A large airplane manufacturer had operators who operated multiple cranes in concert to build up the major pieces of an airplane.  Often two cranes had to work in concert and carry a large part across many bays that would halt work in those bays during the slow, arduous move.  A simulation model was created to train operators on the best sequence for the infinite number of potential timing decisions they would have to make.  The model was run with different rules to minimize the time to assemble the plane based on the sequence of operations.  As the operator interacted with the model to instruct the move he/she wanted to see next, the model would provide feedback that the model agreed with the choice or that it would have made a different move.  This was a really cool way to use the model as a repository of best practices because the model could be updated to reflect the better decisions that real world experienced operators would naturally choose.
2. Time Based Resource Allocation - An aluminum can manufacturer uses molten aluminum to create ingots that are rolled and formed into cans.  The molten aluminum is made up of a mixture melted aluminum ore and shredded aluminum cans that were collected from the public.  Each of these two sources is melted at independent locations and transported to the furnace that feeds the ingot molding process.  The transportation mechanism for the melted ore and melted shredded cans is a crucible that holds about 1500 pounds of aluminum.  Once aluminum is poured into a crucible, it must be used within 6 hours or it will harden and ruin the crucible.  The chemistry required by the ingot dictates that a certain percentage of the aluminum needs to be pure ore and some of the ingot can be formed from melted “reclaimed” cans.  A Metal Caller has the job of deciding which crucibles of melted aluminum gets used on which ingot.  They also have to tell the aluminum sources when they need more aluminum and how much to send.  A simulation model was used to train the metal caller to maximize throughput and minimize the number of crucibles that were “frozen” since they were not used in the 6 hour window.  This type of feedback helped train new metal callers or assisted people unfamiliar with the process if the normal metal caller was away or on vacation.
3. New Employee Training - We have built many models that were used initially to make a traaditional capital decision about throughput or manpower.  After the project, these models get repurposed as introductory tools that help new employees visualize a large process or understand how a system should react to various conditions as they arise.  This comes back to the communication value of models and the power of getting everyone on the same page within a particular process.
4. Operator Instructions - For more detailed models that include the steps of an assembly process, simulations can be used to create visual work instructions for an operator.  These instructions can be used as part of a formal training session at a new facility or available at an operator workstation for a refresher on operations that are not used that often.