Review For SimWiz
Publisher: Moshe A. Cohen
System simulation is a standard tool of the industrial engineer, taught in virtually every undergraduate curriculum. Simulation is used to investigate systems with stochastic behavior in industry and services such as a job shop or a call center. System simulations describe the routes of entities, for example the route of jobs among different machines or the destiny of phone calls from ringing to hang-up. The entities are the jobs or calls and the time they spend in different locations during their route is stochastic, and even the route itself may be stochastic. The model building is the most challenging aspect of teaching an introductory course. This is the topic solved by the program SimWiz.
All other simulation programs have inventories of building blocks such as Arena, SimEvent or SimProcess. The model is formulated by selecting appropriate building blocks from the available inventory offered by the specific software, setting their parameters and connecting them. The connections describe the entities’ routes while the building blocks specify what happens with them in various points along their route. This process is similar to building with Lego blocks. The blocks are available, but not the plan. It is widely recognized among the experts that simulation tools do not actually assist in the model building process.
The problem with such software is that instead of being developed from the needs of people involved in a simulation projects, they grew out form simulation programming languages and their graphical constructs are a mere metamorphosis of several lines of program instructions. A user-centered re-inventing of simulation software is needed that is guided by the principles that focus on the users’ needs. This is achieved in SimWiz simulation program.
The problems that simulation software presents are more acute when the user is either a beginner or a practicing engineer who uses simulation sparingly. The questions that they ask when trying to translate a given case to a model, are:
- How do I start modeling?
- How do I continue?
- Which building blocks should be selected?
Unfortunately, no standard answers can be found to such question neither in text books nor in the literature. Modeling is treated as an art without any specific methodology or so to say a “recipe” that guides the model building process. Can such a recipe be ever created, fitting all the models of discrete event simulations? Yes, and it is delivered by SimWiz. It has been developed by observing the needs of prospective simulationists as follows.
In simulation projects there are two “actors”: the “builder” who formulates the case as a model ready to run on a computer and the “auditor”, who evaluates the model. Sometimes both actors are in the same person, sometimes both may be a group of people when the auditors may consist of the party interested in the results, experts of the case who are not familiar with simulation software and fellows who help to validate by “walking through” the model. The builder is interested to build the model quickly while the auditor needs a model that is clear and easily comprehensible. Theses super-goals can be reached by following the following principles, most of them can be found in the literature.
The principles helping the builder:
- Expert system-like behavior. The intention is that the user may follow a pre-defined path from start to the complete model that fits any discrete event simulation. At each stage a few details must be specified. This favors especially the beginner and can eliminate the questions listed above.
- Top-down design. This principle says that at first the model is described in general outline and the details are added only later on.
- World-view familiar to industrial engineer. Since the main audience is industrial engineers, at least the outline should resemble what the engineer sees on the factory floor: heaps of parts waiting for processing and work stations. He is not supposed to see any artificial constructs that for example assigns a value to a variable, a legacy from computer languages.
- Block diagramming. When this principle is applied in view with the previous one, it follows that the outline is a block diagram where the blocks represent either waiting of parts or places that process them.
- Modeling Flexibility: notwithstanding the above principles, one has to provide possibility for inclusion of program-like constructs. These consist, among other tasks, of reading or writing files, collecting statistics and assigning values. These may be done in according to Principles 2 and 3 at one of the latest stages and as additions to existing blocks.
- Statistical analysis made easy. Simulations must be run as controlled experiments and the software should supply aids to perform and analyze the experiments. Another desirable feature is treatment of random streams. Such techniques should be made easy, especially for the sake of the beginners.
The above principles also imply speedy development time – first super-goal – as well as minimum programming.
The principles helping the auditors are as follows.
- Clear, easily understandable and transparent statement of the model to facilitate communication that is important for making the model participative. Not all auditors are experts in simulation; still they must get all the implications of the model, including assumptions. They must follow the complete description of the simulation, termed as “code”, and this should be made easy for them as far as possible to This is possible only if the simulation “code” is plain text making sense to the laymen.
- Drilling down to details. Similarly to the builder, the auditors also want to see the over-all picture that obscures details and still enable them to “drill down” to any detail easily.
It is possible to find 15 clearly defined stages that following them in a pre-set order fits any discrete event system simulation. In each stage the user is supposed to supply information according to questions or requests that may depend only on information supplied previously. This is the expert-system-like behavior stated in Principle 1.
The first four stages define the over-all structure of the simulation model while the rest are the details, in line with Principle 2. They are:
- List of entity types such as caller types in a call center while each type gets different treatments.
- List of delays. Delays are commonly physical locations that may delay the advancements of entities such as buffers where parts may wait for processing or machines where the processing takes place that also causes time-delay. Thus, the delays represent all the spots that the engineer sees on factory floor, according to Principle 3.
- Outline of all possible movements of any entity between delays. This results a sketch drawn by the user on screen, required by Principle 4.
- Causes of delays.
There are many models, though, where delays are artificial or even the entities are artificial. However, it is possible to start model building activity with situations where entities and delays correspond to tangible objects on the factory floor.
The details that follow depend on the user’s responses in Stages 3 and 4. If entities exiting a delay may go to several other delays then either there are different alternative routes or an entity is split into several ones where each has different destination. This information is used later at Stage 8 where rules that govern the decision on the route to choose are prompted. The delays’ causes also contain valuable information about details that must be supplied for the model. An entity may be delayed until:
a.a process ends,
b.a resource becomes free,
c.a condition is satisfied,
d.a transporter becomes free,
e.a vacant place on a conveyor becomes free,
f.enough entities are assembled for a single batch,
g.a few entities are ready to exit at same time from different delays,
h.another entity causes its removal,
i.0 time passes; this is an artificial or dummy delay that is handy to deal with many situations.
At Stage 4 one of the causes from a. to i. is selected. In the sequel the cause is denoted as “type” of the delay.
In the following stages the details are entered. The details are (the numbers are the stage indexes):
5.Duration and resources usage for all type a. delays.
6.Resource parameters for each resource entered in Stage 5.
7.Arrival patterns, destinations and other parameters for each entity.
8.Rules of choosing a specific route in case of alternative routes.
9.Transorter routes and parameters for each d. type delay.
10. Conveyor routes and parameters for each e. type delay.
11.Additional tasks when an entity enters or exits a delay. These include input, output, separation of temporary batches, terminating the stay of entities in delays, freeing resources seized in other delays and assigning values to quantities or attributes. Part of additional tasks serves Principle 5.
12.Disciplines for all queues (delay types from b. to h. inclusive).
13.Information about conditions, batching, and synchronizing for each delay types c., f. and g., respectively.
14.Symbol definition for each symbol entered previously. Symbols my denote attributes, constants, variables, functions, stochastic state variables and time functions.
15.Priority for each resource used in more than at one type a. delay.
Except for Stages 7 and 11 the possibility of skipping them can be deduced from previous stages’ responses. Obviously, when the set of relevant delays is empty in Stages 5, 9, 10, 12 and 13, these stages may be skipped. Step 6 is not needed if no resource is entered in Stage 5. Stage 8 is skipped if entities exiting a delay may go at most to another single delay. Stage 14 is skipped if no symbols are used in previous Stages and Stage 15 is skipped if each resource is used only in a single delay.
These fifteen are sufficient for describing any simulation model. They direct the user what to do to obtain a correct model. They cover every aspect of simulation like any other simulator software, so that any discrete event model can be constructed, independent of the application. Each relevant stage is associated with a window that directs the user (the model builder) about the facts that must be supplied to complete the model. The user moves from stage to stage and provides the details that the program requires. The end-result of this process is the simulation model.
When the complete model is built, the model is described by the model file that is a simple text file. It is worthwhile to compare this model file with a comparable SimScript description or a Siman file (Siman file is the textual output of Arena). The difference between them and the model file here that the model file produced by SimWiz is concise and written in simple English, not a programming-language description of the model, faithful to Principle 7. Still, the model file is an accurate description of the model, no less than those in SimScript or Siman languages. The model file is also the only input to the simulator.
SimWiz also produces an HTML file that shows the outline containing the graphical objects and a list of non-graphical objects (such as entity types). This is the over-all description of the model. Clicking an object on the browser brings the details of that object; this implements Principle 7.
SimWiz has also menu items that perform either a response surface or a block design analysis on the model when various parameters are treated as controls in an experiment. The main point here is that these techniques can be used by the laymen, without any previous exposure to the language or the theory of experiment design, as desired by Principle 6.
SimWiz can reduce the frontal teaching of modeling to a single session in introductory simulation courses, even if one of the goals is to train students in commercial software commonly used in the industry. It is also useful as a thinking tool.