Simulation is a tool you can use to place your system under a microscope.

The starting point of a simulation is a system.

It may be a new system, or it may be an existing system that you wish to modify. Wolverine's SLX and GPSS/H have been used to simulate a wide variety of systems, including surface transportation, air traffic control, trans-border security, telecommunications, health care, material handling, and manufacturing systems. Although such  systems differ greatly, they all share two common characteristics: high cost and complexity of operation. In the private sector, the motivation for doing simulation most often is to maximize profits. In the public sector, the motivations most often are to provide for the well being and safety of the public, and to reduce the risk of negative events, such as injury or death.

Most systems of interest are complex, and many are controlled by computer programs that allow them to react to current circumstances and intelligently modify their behavior in real time or near real time. If systems were simple, we could predict their behavior without resorting to simulation.

We build a model of a system through a process of abstraction.

We can't include every last system detail in a model. If we did, the model would take too long to build. So, through a process of abstraction, we select those details that are most critical to characterizing the operation of the system. This is an iterative process. We must validate the model to assure that it properly represents our system.

The degree of detail required in a model depends on the nature of the system. For example, if we're modeling a nation-wide network of truck transportation, we can safely ignore acceleration and deceleration of trucks.  On the other hand, if we're modeling an urban street grid, acceleration and deceleration are critical.

Once we've constructed a model of our system, we write a simulation program that can execute the model on a computer.

SLX and GPSS/H contain features and capabilities that allow you to easily convert a model into a simulation program. These languages are extremely good for describing activities that occur in parallel. Even in the simplest of systems, competing requests for service must be handled exactly as the design of our system requires. This is where simulation languages, such as SLX and GPSS/H have a distinct advantage over point-and-click, graphically-based simulation packages. A simulation tool that provides 20 kinds of conveyor belts may be of little use to you if what you have is the 21^st type. With SLX and GPSS/H, you can build that 21^st type yourself.

Building a simulation program is an iterative process. At each step, we must verify our simulation program to make sure it's operating the way our model says it should. SLX and GPSS/H have been used by large numbers of customers in widely varying applications, so they have been "hardened and tempered" to an extent rarely achieved in home-grown software. You can be sure that their built-in features operate correctly.

Once our simulation program is running, we run experiments to explore our system.

Many computer programs produce simple numeric answers. With simulations, the complexity of our answers reflects the complexity of our systems. Suppose you've built a very detailed model of your local street grid, and as a test case you'd like to know how long it should take you to get to your office. You can't simply run the model once and say the answer is 10.5 minutes. If the model you've built is realistic, the answer may be 8 minutes on a really good day and 20 minutes on a horrible day. Getting an average travel time and a range of travel times with their relative likelihoods (a statistical distribution) might satisfy your curiosity as a commuter. However, for designers of traffic systems, the real issues are "What leads to a good day?" and "What problems lead to bad days?" By putting your traffic simulation "under a microscope," you can explore such matters under laboratory conditions.

For many systems, using animation to visualize system behavior greatly enhances your ability to spot problems. Bottlenecks that might get lost in a mountain of statistical output are readily apparent as long queues in an animation. Animation is also a great help in debugging models.  For example, if you see two cars pass through one another at a traffic intersection, you instantly know that something's dreadfully wrong with the logic of your model.

Putting it all together...

As you analyze the output of your simulations, you'll encounter surprises that result from design flaws. Simulations almost always result in the discovery of unforeseen bottlenecks and deficiencies. Given the complexity of the systems we model, it should come as no surprise that our initial designs are rarely perfect.

Any simulation project goes through stages. In the early going, when your simulation produces incorrect results, you'll discover that you've incorrectly modeled a system component. Later, when your simulation produces incorrect results, you'll discover that your model is OK, but you've made simulation programming errors. Finally, you'll reach a point at which your simulation's output shows unsatisfactory results, but both the model and your programming of the model are correct. When this happens, you've discovered a problem in the system itself.

The name of the game is learning, and with simulation, we learn of many problems before they become problems in real systems. A disaster that appears on a computer screen is infinitely preferable to one that appears in a real system.