Discrete event simulation is a powerful tool for evaluating what-if processes or processes where a high degree of random variability exists.

PlantServices.com

By David Saas

My father used to tell me, “When all you have is a hammer, everything looks like a nail.” This analogy often holds true for the way we approach plant process problems. We attack them with a trial and error approach because it’s the only hammer commonly available. Discrete event simulation is a powerful tool for evaluating what-if processes or processes where a high degree of random variability exists. Instead of incurring the time and cost of a trial and error technique, the mistakes can be made and studied harmlessly in a computer model. However, simulation isn’t right for every type of problem. Many processes are easily characterized using pen and paper or a spreadsheet, and information gleamed from this analysis is more than adequate to make useful and accurate decisions.

Right tools and skills
Simulation software has made great strides in usability, accuracy and cost during the past five years. Many commercial packages ranging in price from less than $1,000 to more than $10,000. Capabilities vary, but most include a graphical user interface to build the model as well as the ability to represent results graphically. Many packages provide an animation of the simulation. This feature is highly useful in the debugging stage and in final model presentation. In addition, some packages are specialized to handle specific classes of simulation, such as 3D material handling or financial simulations.

The software that performs the simulation is important, but the largest predictor of a successful simulation analysis is the skill of the practitioner. Simulation is an engineering discipline, not just a computer programming exercise. The user should have knowledge of statistics and strong logic skills, and while not essential, experience in the process simulated is a big plus. While most software packages use a graphical interface, all but the simplest models require some type of custom scripting or programming. Therefore, some background in programming is helpful. If the organization is large enough and simulation needs great enough, having a person on staff dedicated (or partially dedicated) to simulation is best.

Tackling material handling
Simulation is an engineering discipline and a simulation project that proceeds in an orderly manner produces the best results. The probability of wasting time and producing dubious results increases dramatically if you lack a solid methodology.

For example, let’s assume that a maintenance department is responsible for maintaining spare parts inventory and performing planned and corrective plant maintenance in several plant areas (Figure 1).
The department manager is being pressured to improve service times and better manage inventory carrying cost. In this example, service time is defined as the time from the moment a part is requested to when that part is delivered for repair. A stockout on any repair part results in expedited replenishment and a longer service time. The manager plans a simulation to determine the optimum inventory to carry to minimize service time and inventory cost.

Know the question
Formulating the problem or question to be answered is crucial to a successful simulation project. Identify the quantifiable key metrics in the process and structure the simulation to gage these metrics. For example, a goal such as “improving the fulfillment process” is much too vague. While the wording might be appropriate for the overall objective, the simulation needs to address measurable variables such as time, capacity and utilization. Better wording that details a measurable goal might be “decrease the maximum fulfillment time by 25%.”

One possible quantifiable goal for managing maintenance inventory is to minimize the service time per inventory dollar carried. Expect planning and running the simulation to produce additional questions. One of the great benefits of a good simulation is that it provides not only data for the process, but also inspires additional insight. And insight often enhances your ability to reengineer a better process.

Data quality is critical
Gathering data is often the most difficult step in a simulation project. Reliable data is required if you expect to achieve meaningful results. Using bad data only leads to erroneous outputs and results in poor and costly conclusions. Project data may already exist as written records, computer logs, spreadsheets and databases. If suitable data doesn’t exist, you’ll need to collect it using a time study with a stopwatch on the shop floor.

If the process modeled varies randomly (stochastic), use statistical methods to characterize the distribution of input data. In turn, run the model many times using the distribution to determine the effect of the random variability on the output. The ability to run a simulation repetitively over a wide range of data is one of a simulation’s most powerful benefits.

The final part of the data gathering stage involves defining the model’s operating logic. This step documents both the existing and desired operating process. Interviewing maintenance technicians, studying procedure reviews and conducting a design review for the new inventory approach are reliable methods for detailing model logic.

The maintenance inventory example will require several sets of input data. First, examine existing inventory SKUs and a spare parts list for the different equipment in the plant and produce a master inventory list of what parts are candidates for including in inventory. Second, determine the population of that part in the plant for each line item in the master inventory list.

Finally, determine the mean time between failures (MTBF) for each part. This determines the demand for each part by modeling its failures as an exponential distribution.

Building the model
With the operating logic in hand, begin to build the model. This can take several hours or several weeks, depending on its complexity. As mentioned, most of the software packages provide a GUI to perform the task, but some scripting or programming will probably be required to maximize the information obtained from the model. For complex material handling systems, where true dimensioning and scaling is required, the user can cut down on some of the model building by importing directly from a CAD package. A maintenance inventory example typically doesn’t include a physical bottleneck, so the process is modeled using system logic and simple animation to ensure the model is functioning as designed.

Verifying and validating
Verifying your model involves comparing its results and behavior with its intended logical behavior. Again, this is when a software package’s animation features can prove to be useful. Verifying your model’s logic is a repetitive process, often requiring several iterations to evoke the desired behavior. Validation, on the other hand, refers to the validity of the model’s output data, which should match or coincide with the real-world system. The two common and effective methods for validating the model is by comparing the output data to real-world data (if available) and letting system experts analyze the output data and model behavior.

Validating our example simulation would involve comparing the model’s output and demand to the demand observed in the inventory system, as well as recorded service times for known scenarios.

Experiment without consequence
High computer clock speeds allow running a simulation many times, systematically changing variables for each run. Analyzing many scenarios quickly provides valuable comparison data. The key is to vary the variables that are pertinent to the real-life system and to record the key performance indicators identified earlier.

Scenarios involving random processes must be run perhaps thousands of times using a different random number seed each time. This quantifies the effects of random variations on the model’s behavior. The number of runs required is a function of the required confidence in the measurement and the variability of the output.

In our example, the inventory could be partitioned into three categories: fast, medium and slow movers. Breaking the inventory in to three groups provides more granular control over the inventory, therefore providing a more optimized solution. Varying the units of inventory kept on hand for each group provides one set of experimental variables. Run the model enough times to represent six months of real time and determine the average inventory cost and service time. Because part failure is random, multiple runs are required for each scenario to determine the effect of randomness on the service time and inventory cost.

The flexibility of discrete event simulation makes it simple to record additional process information, such as categorizing the average service time by type of repair. Only imagination and development time impose a limit on the information recorded.

Analyze results
With the experimentation complete, you’ll need to analyze the information to address the problems and questions you defined at the onset. Many tools are available to the analyst, but simply graphing the data is a powerful first choice for visualizing the model’s behavior. Some data sets may require the application of additional statistical methods before they provide a clear picture. Many software packages animate the model’s execution and output to provide a visual view for formal presentations. Though these animations can be quite impressive, in the end, hard decisions require hard data. Depending on the model’s intent and design, it’s possible for an operating model to be used repeatedly as an ongoing operational tool.

In the example, the model under discussion here is designed to determine optimum inventory level while minimizing service times. The model’s output can be presented graphically. Figure 2 plots both average service time and average inventory cost versus days of inventory kept on hand for Group A (the fast moving items). The plots reveal that exceeding the optimum inventory level and the corresponding increases in inventory cost have little effect on service times. Figure 3 shows a similar result for items in Group B (the medium movers).

Further analysis of Group B reveals that a small number of items dictate the value of the optimized inventory, and additional inventory rules for these items could reduce the total inventory cost with no effect on service times. Plotting Group C reveals little change in both inventory and service time as days of inventory on hand increases (Figure 4). This is attributed to the inventory rule of requiring a quantity of at least one item be kept for each SKU. Because Group C represents the items in the plant with a low occurrence and low failure rate, keeping more than one in inventory has little effect on the service time. This is true until the inventory is doubled, when the service time for this group is completely minimized.
In the end, simulation should be another tool in your bag to help solve plant problems beyond the question of inventory. Applied to the wrong problems or applied incorrectly, however, it can cause much frustration and waste valuable resources. When used correctly, it can help answer your organization’s what-if scenarios and save months of time and millions of dollars. It’s just a matter of using the technique when it makes cents.

You can find an interactive simulation of the maintenance stores example this article explored at http://www.bdssimulations.com/ps/simulation.html.
David Saas is president of BDS Simulations, L.L.C. in Marshall, Va. reach him at dave.saas@bdssimulations.com and (703) 880-6358.