10.1 Introduction

This chapter presents a particular perspective on conducting discrete-event simulation (DES) projects with software and gives the reader enough information about the use of one particular software package to get started with simple, practical, simulation building and running.

Although it is only one perspective, the author has, over too many years to remember, been involved with the creation of about eight different DES software products, so the perspective is a little wider than one product and this chapter is intended to be a perspective on DES with software, not on software products.

Most, if not all, DES software products nowadays do much more than run simulations. In addition to explaining how to use DES software, this chapter also explains what the different parts do and why the products have evolved to where they are now.

Of course the software for DES is just a small part of doing DES projects, so this chapter first explains how to use software in the context of a project. It concludes with a look at the problems still to be solved by DES software.

10.2 How Software Fits into the Project

The only reason for building and running simulations is because of a need to understand something about a process, probably because of the desire to improve that process but without yet knowing how.

This means the objective is not directly to build a simulation, but to help create understanding and knowledge so the clients of the work then know enough to be able to change the process they manage. This might seem a really obvious point. However, it is always surprising how often builders of simulations think the simulation itself is the main objective. It is all too easy to lose oneself in the technical niceties and details of a simulation rather than directly helping the client.

What does this mean in practice? In a DES project it means working with the client most of the time (Elder, 1992). If one really needs to go off to a back room to do some intricate work on the innards of a simulation model then this should only be done for a couple of days at most. There are many reasons for this, in addition to the obvious: it is worthwhile to maintain visible contact with the clients in case they think you are not working hard enough on their project! Here are some of the more important reasons:

• The issues relevant to a business decision do change. If a business decision maker is left alone for a couple of days, the issues will have evolved by the time the consultant building the simulation returns. So the work done on the simulation needs to include these changes. Indeed the simulation, if effectively used, can be the prime driver for this evolution of the decision maker's thinking.
• Most business decisions need to be taken quickly. There are exceptions – especially when the client's project is part of something larger where there might be a few weeks before the results of a simulation project are required to feed into some other part of the project. But for the majority of occasions when simulation is useful, the decision makers need to know the answers to the questions before they can move forward, and if building the simulation takes weeks it is likely the clients will make decisions using the seat of their pants and not the simulation.
• The scope of what needs to be simulated changes with the progress of the simulation project. For example, one may start by building a strategic model looking at an entire system at a very global level of detail. This will help the clients understand where they need to focus their investigation. Then a detailed simulation model, or several models, are required, focusing on exactly what happens in specific parts of the process. These might feed back changes to the high-level model, or indicate that a new investigation is required at an even more detailed level. It is the answers returned by the simulations that drive this investigative process. If the clients are not involved, they will not understand the need for multiple models.
• The journey is often more important than the destination: if the simulation results are seen as the destination then the process of building and refining the simulation model (or models) is the journey. It is this journey that leads to most of the discoveries along the way and so the client needs to be involved in it. If left in the dark while the simulation builder makes all the discoveries then the client simply will not understand, or buy into, the conclusions reached. The client will not have experienced the blind alleys, or overcome the same hurdles as the simulation builder. So the client cannot be left out of the loop for long if the project is going to be a success.
• Simulation model builders are often quite technical people. They like data and facts to be clear and unambiguous so it is clear how the simulation should behave. But the real business world is not quite like this. Often, subjective judgements need to be made while trying to find ways to improve a process. Clients sometimes have to ‘bend’ what they might state as their ‘hard constraints’ when they start to see (from a simulation) the consequences of the limitations that they have imposed on the simulation builder. If they are involved they will appreciate the need to ‘bend’ and this might lead to a clever way forward for their business. If the client/decision maker is not involved in the process of building and evolving the simulation model(s) then these kinds of judgements will not be included and the project will be less successful.
• Finally clients do not tell everything upfront because either they are forgetful or they simply do not realize the detail required to build the simulation. It is not good to spend two weeks on building a simulation, and then present a finished model to a client, only to be asked, ‘Did I mention that there are three types of product?’

The implication of the above is that simulation activity runs all the way through the project. By this it is particularly meant that it is not a good idea for simulation to be brought in at the last minute, once the designs for change are complete, ‘just to check the design is right'. From the above discussion it is clear that simulation helps to get the design right, so it is inefficient to use it only to ‘check' a design. Furthermore, if at that late stage simulation shows the design is wrong, the designers may have a problem with their time schedule!

The simulation work should therefore take place in parallel with and integrated into most of the rest of the project on improving or designing a process.

How do you get started? How do you know when to finish? When starting a project there are some very basic questions to ask:

• What do you want to improve?
• What is your measure of success? And then:
• What can you change?

These questions start a conversation that will indicate what will be worth simulating first.

The next step is then to build quickly (and roughly) a small simulation that captures some of what the client has indicated that needs to be included. Do this live in front of the client. Do not worry about complications or data. Press the Run button and let the client see the animation. At that point there had better not be an urgent flight to catch – because the members of the client group will now spend two more hours avidly discussing what really happens in their different departments and starting to understand each other in a way they never have before. And no real data has been entered yet! Indeed the author knows of two different occasions where projects have started like this and there has been no need to do more work because the conversation it generated caused the client group to realize the solution to their problem. On another occasion the client saved over $10 million in that initial session, but the project continued because there were many more savings to be had with several properly built and validated simulations.

As stated above, probably several simulations will be built during the project. When do you stop?

That is easy – stop when the client says, ‘OK, thanks, I know what decision I'm going to take.' This is really important. But so many simulation people seem to get this wrong. Do not stop when ‘The model is finished.' The model is not the objective of the project. The objective is to get the client to learn enough about the way the process works, or could work, so that the client knows what to do.

10.3 Building a DES

Having stated all the above caveats about simulation projects being rather more than building and running a simulation, it is now time to build one.

The client for the project that will be used as an example is Table Corporation. Table Corp. is trying to get as much product as possible through its small factory with as little resource as possible. Table Corp. can change the number of people and/or the number of machines, but obviously does not want to spend money if it does not have to.

Table Corp. makes metal tables and the process is really simple. It only involves welding the parts together and then painting the tables. The parts are made by an external supplier and delivered to the factory at the expected rate of demand.

Ideally the reader should follow the process in the software, but if that is not possible there is sufficient here to understand what is being done and the impact of doing it.

Any version of SIMUL8 is sufficient to create and run this simulation, for example a student version or an evaluation version, but not the ‘runtime viewer', which does not build simulations, but only runs them. The same simulation can be built and run with similar results using most modern simulation software, but the instructions here are for SIMUL8.

Once the software is installed, draw the process flow shown in Figure 10.1 (see Figure 10.2).

Use a start point, two activities and an end point (Figure 10.3).

Click on the Run button.

What has happened so far is that a first, oversimplified, version of a simulation of Table Corp.'s factory has been built and run in one DES software product. Soon it will be extended and improved, but first a few comments should be made on what the software has done in the background.

Many of the underlying necessities that were detailed in Chapter 2 have been taken care of by the software. For example, deciding what events are going to be handled in the simulation, compiling a table of those events, marshalling them in time, and sampling from random number generators to decide when events should happen, have all been managed automatically based on the process flow that was drawn on the window in the software. Some important detail remains to be added to the process flow, but that will be taken care of and used to modify the underlying events, entities, and so on that are being created and handled by the software.

When the Run button was pressed the simulation software knew that the user had not entered data for many options (e.g. how long the simulation should run), so it made reasonable assumptions about each of the options so it could run the simulation and show some animation of the factory in action.

The final position shown in Figure 10.4 shows (a) the current simulated time is 5 p.m. on Friday; (b) how many packs of parts for tables have entered the factory (120); (c) how much work is currently in the weld process (none); (d) how much work is currently in the paint process (none); and (e) how many complete tables have been shipped (120).

There are many more items of data that the simulation software collected as the simulation ran and could be displayed. These are usually important because they reveal how the process is performing and how it could be improved. However, in this case the simulation needs to do some more work before it is worth looking at that data.

What typically happens next is the client saying something like ‘that does not look quite right to me' and starts talking about how the process map does not exactly reflect what really happens in the factory, and there is some detail missing. In this case the welding takes 11 minutes on average and the painting takes 10 minutes. Change Weld to 11 minutes by clicking on it and changing the time to 11 (Figure 10.5). There is no need to change Paint, as the default time happens to be 10 minutes.

Often, before making this type of comment, the client will ask, ‘Where is all the work-in-progress?' The average process map, or client description of a process, tends to mention the value-added parts of the process (places where work takes place, like the welding and painting machines) but not the non-productive, though quite real, parts of the process (like queues of work). Projects are sometimes about trying to eliminate these non-productive parts; nevertheless, they should still be included in the simulation because only then can the model be matched to current working and the impact of reducing or removing them evaluated. Sometimes, completely eliminating a queue means a bottleneck machine is starved of work, severely restricting throughput, and thus queue reduction rather than elimination becomes the objective.

In this case the client had not mentioned that work often queues prior to the two activities. In the software remove the arrows into each of the activities, drop some queues in using the buttons on the left of SIMUL8 and connect up new arrows as shown in Figure 10.6.

Run the simulation and look at the difference between Figure 10.4 and Figure 10.7.

Despite the weld machine being slower (it takes an average of 11 minutes for each table now, whereas before it took only 10 minutes), the output of the factory is close to double that shown in Figure 10.4. This shows the positive value of some queues in buffering processes that are constraining the work. For example, without queues the welding machine must stop and do nothing if it has finished work, but simultaneously the paint machine is busy and cannot accept its welded table.

We are getting near an accurate simulation of the factory now (more later on how to make sure it is as accurate as it needs to be). However, the client then mentions a couple more points that are not obvious from the process flow diagram:

1. Although there is only one welding process that tables go through, there are two welding machines to choose between, giving extra capacity to welding.
2. Welding and painting are not completely automatic; an operator is required at each machine while it is working. There are only two operators to handle the three machines.

People (operators) are normally simulated using ‘Resources' in SIMUL8. Resources are facilities that are shared between activities. Activities are not allowed to work unless they have all the resources they need.

Add a resource using the buttons on the left, then name it and set the number of people in the team to 2 as shown in Figure 10.8.

Now tell both ‘Weld' and ‘Paint' that they need an Operator to be able to work. Click on Weld and use the Resources button and the Add button to add Operators to the list of resources required by Weld (Figure 10.9). Then do the same for Paint.

Now make a second welding machine by copying the first welding machine. Do this just by dragging the first welding machine with the CTRL button on the keyboard held down (Figure 10.10).

Now the client will be happy that the simulation is showing a similar situation to what happens in a typical week in the real factory (Figure 10.11).

Notice that there is quite a large queue for the paint activity. Let us examine some more detailed results. For example, click on the paint activity and then its Results button.

Despite the queue of work, Paint is only working for about 80% of the time (see Figure 10.12):

• What is it doing the rest of the time?
• What can be done about that?
• Try it.
• Is there a way to solve this problem without spending money?

Answering these questions will be left to the reader because they are starting to show some of the benefits of simulation. The act of exploring the simulation results gives rise to ideas on how to improve the process.

10.4 Getting the Right Results from a DES

There are two important stages in the process of providing results to clients that are easy to forget in the heat of getting the technical work done in a simulation project:

• Ensuring the simulation behaves in the same way as the real process.
• Providing results that account for natural variability.

10.4.2 Replications

Providing results that account for natural variability is part of what simulation is about, as shown in Chapter 2. In the Table Corp. example used earlier in the current chapter the times taken to weld and paint a table were quoted not as 11 and 10 respectively, but as an average of 11 and an average of 10. By this it was meant that actual individual times would vary around 11 and 10 but that the averages (taken over a long time) would be those values. Random numbers (as discussed in Chapter 2) are automatically used by DES software to sample times around the specified average.

This is a very important benefit of using DES: that it has behaviour like the real world rather than a smooth, fixed (and unnatural) behaviour that would be shown (for example) in a spreadsheet model that did not include variability.

However, the downside of this is that the behaviour of the simulation can vary from run to run. Actually in most simulation software, rerunning the same simulation will not produce different results because the random numbers are automatically reset and are used again in the same way to make it less confusing for the clients! But if a run of a second week were conducted it would show different results. Try this in SIMUL8 by using the menu under the large Run button (Figure 10.13).

The results are different although of the same character.

To take account of this it is important when making most decisions with DES results to run multiple replications (in SIMUL8 this is known as a ‘Trial') and use the range of results from the many runs with different random numbers that are included in the one ‘Trial'. For the interested reader there are more detailed explanations available – see, for example, Sneddon (2013) – but try the following.

Open the detailed results panel for the paint activity in the weld and paint example and click on RIGHT in the ‘Working percent' result that was nearly 80% in the earlier discussion. Clicking on RIGHT for most values in SIMUL8 adds the result to the ‘Results Manager'. The Results Manager automatically calculates confidence limits to show how accurately the simulation is predicting each of the results it shows.

Now run a trial using the large Trial button on the Home tab. Once the trial is complete the Results Manager will show (Figure 10.14) that this trial has calculated that the real average working percentage of the paint activity is likely to be between 73 and 80%. Often the accuracy of a trial can be improved (reducing the size of the range) by increasing the number of runs in the trial. The only penalty for doing this is the time it takes to conduct this trial.

SIMUL8 includes technology to predict how many runs are required to achieve a given level of accuracy across the results selected as important (Hoad, Robinson and Davies, 2011).

10.5 What Happens After the Results?

Traditionally simulation projects have been seen as a linear activity (Pidd, 1988) but what happens in practice is that as soon as the clients see the results they ask new questions. This typically leads to trying new ideas in the simulation, leading to a new round of validation and results and yet more questions and ideas.

This loop (Belton and Elder, 1994) continues until the clients feel they know enough to make their decisions.

10.6 What Else does DES Software do and Why?

In the early days of software for DES the software consisted of libraries of routines that could be called to assist with the main tasks required to run a simulation. None of the software was related to building the simulation; the builders built the simulation by coding it themselves in their favourite language. Simulations were also black boxes. They took input files of data, ran the simulation and output results for a single run, like the numbers used in the Table Corp. example earlier in this chapter. There was nothing visual to see and it was not possible to stop and start the simulation or interactively explore it in any way.

Different software packages evolved along different routes. Many stayed as non-visual black boxes for many years but took some steps forward to reduce the workload on the builder. High-level languages designed specifically for simulation were created, such as GPSS (Gould, 1969) and Siman (Pegden, 1986), while other products stayed with coding in computer languages but became visual and interactive, making it possible to show clients what was happening in the simulation (Fiddy, Bright and Elder, 1982).

Nowadays probably less than 1% of a DES software package comprises the runtime engine (the part devoted to running the simulation), whereas over 50% is related to providing easy options for building the simulation that can be run by the runtime engine. A significant portion of the remainder relates to runtime animation in both 2D and 3D. Almost all DES software also has a portion for automatically optimizing the input variables (e.g. automatically changing the numbers of welding and painting machines, numbers of operators, etc.) to seek an optimal answer for the client.

Ways of displaying results, so that, rather than showing numbers, charts are used to drive understanding that leads to seeing what to improve, have been a key focus of all simulation vendors in recent years.

Another major element of DES software is interfaces to other ways of creating simulations. For example, simulations can now be automatically created from process maps created in standard office software products or CAD packages. Simulations can also be automatically created from direct live connection to corporate data so that they can be built and run to predict the afternoon's performance from the morning's data.

10.7 What Next for DES Software?

Compared with the early days of simulation, software for DES has achieved a great deal in taking simulation from a backroom activity conducted only by highly trained experts who might take months to build a single simulation to the situation nowadays where, instead, a simulation can be designed, created and run in a small number of hours, often by the people working directly in the process who need the answers.

This is very good news, but not quite good enough.

DES is still more difficult than building spreadsheet models. Admittedly, spreadsheet models do rather less, produce results that fail to account for variability and are difficult to use for communication because they lack animation. However, DES needs to be an order of magnitude easier than it is currently so that improving processes quickly and cheaply via simulations can be as easy as using navigation devices to map new journeys and tablet computers for video editing.