Commercial Simulation Software

While a simulation model may be programmed using any development language such as C++ or Java, most models are built using commercial simulation software such as ProModel. Commercial simulation software consists of several modules for performing different functions during simulation modeling.

Typical modules are shown in Figure 4.7.

4.5.1 Modeling Interface Module

A modeler defines a model using an input or modeling interface module. This module provides graphical tools, dialogs, and other text editing capabilities for

i 1 i

=1

FIGURE 4.7 Typical components of simulation software.

Modeling

interface Simulation

interface Output interface

Modeling

processor Model

data Simulation

data Output

data Output

processor

Simulation

processor Simulation processor

entering and editing model information. External files used in the simulation are specified here as well as run-time options (number of replications and so on).

4.5.2 Model Processor

When a completed model is run, the model processor takes the model database, and any other external data files that are used as input data, and creates a simula-tion database. This involves data translasimula-tion and possibly language compilasimula-tion.

This data conversion is performed because the model database and external files are generally in a format that cannot be used efficiently by the simulation proces- sor during the simulation. Some simulation languages are interpretive, meaning that the simulation works with the input data the way they were entered. This al- lows simulations to start running immediately without going through a translator, but it slows down the speed at which the simulation executes.

In addition to translating the model input data, other data elements are created for use during simulation, including statistical counters and state variables. Statis- tical counters are used to log statistical information during the simulation such as the cumulative number of entries into the system or the cumulative activity time at a workstation.

4.5.3 Simulation Interface Module

The simulation interface module displays the animation that occurs during the simulation run. It also permits the user to interact with the simulation to control the current animation speed, trace events, debug logic, query state variables,

request snapshot reports, pan or zoom the layout, and so forth. If visual interactive capability is provided, the user is even permitted to make changes dynamically to model variables with immediate visual feedback of the effects of such changes.

The animation speed can be adjusted and animation can even be disabled by the user during the simulation. When unconstrained, a simulation is capable of running as fast as the computer can process all of the events that occur within the simulated time. The simulation clock advances instantly to each scheduled event; the only central processing unit (CPU) time of the computer that is used is what is necessary for processing the event logic. This is how simulation is able to run in compressed time. It is also the reason why large models with millions of events take so long to simulate. Ironically, in real life activities take time while events take no time. In simulation, events take time while activities take no time. To slow down a simulation, delay loops or system timers are used to create pauses between events. These techniques give the appearance of elapsing time in an animation. In some applications, it may even be desirable to run a simulation at the same rate as a real clock. These real-time simulations are achieved by synchronizing the simu- lation clock with the computer’s internal system clock. Human-in-the-loop (such as operator training simulators) and hardware-in-the-loop (testing of new equip- ment and control systems) are examples of real-time simulations.

4.5.4 Simulation Processor

The simulation processor processes the simulated events and updates the statisti-cal accumulators and state variables. A typistatisti-cal simulation processor consists of the following basic components:

• Clock variable—a variable used to keep track of the elapsed time during the simulation.

• Event calendar—a list of scheduled events arranged chronologically according to the time at which they are to occur.

• Event dispatch manager—the internal logic used to update the clock and manage the execution of events as they occur.

• Event logic—algorithms that describe the logic to be executed and statistics to be gathered when an event occurs.

• Waiting lists—one or more lists (arrays) containing events waiting for a resource or other condition to be satisfied before continuing processing.

• Random number generator—an algorithm for generating one or more streams of pseudo-random numbers between 0 and 1.

• Random variate generators—routines for generating random variates from specified probability distributions.

4.5.5 Animation Processor

The animation processor interacts with the simulation database to update the graphical data to correspond to the changing state data. Animation is usually

displayed during the simulation itself, although some simulation products create an animation file that can be played back at the end of the simulation. In addition to animated figures, dynamic graphs and history plots can be displayed during the simulation.

Animation and dynamically updated displays and graphs provide a visual rep- resentation of what is happening in the model while the simulation is running. Animation comes in varying degrees of realism from three-dimensional animation to simple animated flowcharts. Often, the only output from the simulation that is of interest is what is displayed in the animation. This is particularly true when simula- tion is used for facilitating conceptualization or for communication purposes.

A lot can be learned about model behavior by watching the animation (a pic- ture is worth a thousand words, and an animation is worth a thousand pictures). Animation can be as simple as circles moving from box to box, to detailed, real- istic graphical representations. The strategic use of graphics should be planned in advance to make the best use of them. While insufficient animation can weaken the message, excessive use of graphics can distract from the central point to be made. It is always good to dress up the simulation graphics for the final presenta- tion; however, such embellishments should be deferred at least until after the model has been debugged.

For most simulations where statistical analysis is required, animation is no substitute for the postsimulation summary, which gives a quantitative overview of the entire system performance. Basing decisions on the animation alone reflects shallow thinking and can even result in unwarranted conclusions.

4.5.6 Output Processor

The output processor summarizes the statistical data collected during the simula-tion run and creates an output database. Statistics are reported on such perfor-mance measures as

• Resource utilization.

• Queue sizes.

• Waiting times.

• Processing rates.

In addition to standard output reporting, most simulation software provides the ability to write user-specified data out to external files.

4.5.7 Output Interface Module

The output interface module provides a user interface for displaying the output results from the simulation. Output results may be displayed in the form of reports or charts (bar charts, pie charts, or the like). Output data analysis capabilities such as correlation analysis and confidence interval calculations also are often pro- vided. Some simulation products even point out potential problem areas such as bottlenecks.