- Email: [email protected]
Animating simulations using TESS
Comput. & Indus. Engng Vol. 10, No. 2, pp. 121-134, 1986
0360-8352/86 $3.00 + .00 © 1986 Pergamon Press Ltd.
Printed in Great Britain.
ANIMATING
SIMULATIONS
USING
TESS
CHARLES R. STANDRIDGE Pritsker & Associates, Inc., P.O. Box 2413, West Lafayette, Indiana 47906, U.S.A. (Received for publication 25 October 1985) Abstract--Animation techniques provide for displaying the dynamics and operating strategies of a simulation graphically. Thus, both analysts and decision makers can see how a simulation represented the modeled system. Within its framework for performing simulation studies, TESS provides a framework for animating simulations. Animations are performed as a post-simulation presentation tool using color-raster graphics. Animations are shown on a schematic diagram of the system, driven by a list of the event occurrences in the simulation, and related to the simulation by a set of statements called a rule. An example animation illustrates the use of the TESS animation framework. A case study shows its application to an actual system.
1.0 INTRODUCTION
Providing information which has an impact on decision making is a typical goal of a simulation project. Establishing the validity of the simulation model with a decision maker is fundamental to fulfilling this goal. Establishing such validity includes explaining the scope of the model, the structure of the system as captured by the model, the dynamics of the system included in the model, and the operating strategies employed during the simulation. In part from this explanation, the decision maker must decide whether the model represents the system accurately enough for simulation results to be useful input to the decision making process.
1.1. Showing validity with animation Because simulation reproduces the dynamics of a system, a verbal or written explanation of the model, its simulation and the simulation results may not convey the information necessary to establish validity. With the advent of raster graphics terminals, first monochrome and later color, the use of animation to present a model and its simulation became feasible. With animation, the dynamics and operating strategies of a simulation are captured graphically. Thus, the decision maker can see how the model represented the system, participate in the validation process and more easily decide upon the validity of the model. Before establishing the validity of a model with a decision maker, the analyst must become convinced of the validity of the model. In many cases, this process included examining a trace, the list of events which occurred in a simulation. This examination required pouring over a large volume of printed output. Often, it was difficult to assess the behavior of the model from this manual examination of the trace. As in establishing the validity of the model with a decision maker, animation helps to validate the model to the analyst. The behavior of the model can be seen graphically. Thus, issues concerning the structure, dynamics and operating strategies of the system can be addressed. 1.2. Modes of animation Animation capabilities have been included in several simulation packages. These capabilities provide for either simulation-concurrent animation or post-simulation animation. Post-simulation animation capabilities can be further divided into users of interactive graphics terminals and passive graphics, typically movies. The former usually use color, raster two dimensional graphics while the latter use color, vector three dimensional graphics. Simulation-concurrent animation provides for game playing with a simulation. A user can halt the simulation based on the condition of system as seen in the animation. 121
122
C . R . STANDRIDGE
Model parameters can be changed and the effect of these changes seen in the animation. In this environment, the game player can investigate the cause and effect relationships within a system. For example, the effect of changing service rates on relieving bottlenecks could be seen. However, such dynamic changes in model parameters invalidate any experimental design for analysis purpose. Thus, questions of system performance or design are best addressed in a non-gaming mode. In addition, simulation-concurrent animation is not possible for models whose simulation and animation cannot be computed interactively in a reasonable length of clock time. Several simulation packages provide for this kind of animation, for example the CINEMA add-on to SIMAN[3] and SEE WHY[l]. Post-simulation animation emphasizes the presentation of the dynamics and structure of a system as captured by a simulation. Selection of a subset of the simulation to animate is usually provided. In this way, the most interesting parts of the simulation. for example when an unusual combination of conditions occurs or when a queue length is particularly long, can be chosen for animation. Post-simulation animation allows any size simulation to be animated regardless of the amount of time required for simulation. One animation can be repeated several times or several animations can be generated from one simulation run. The major disadvantage of post-simulation animation is the lack of a gaming mode to explore system cause and effect relationships. Packages which provide post-simulation animation capabilities include IDSS 2.0[2], TESS[5], and Autosimulation. Interactive post-simulation and simulation-concurrent animations use color, raster graphics terminals. The terminal screen is updated in real time to show changes in the simulation, typically changes in resource status, queue lengths, or entity movements. Changes in numeric value displays, the color of blocks, or the visibility of ICONS implement the animation. Passive animations typically use three dimensional color, vector graphics. This technology does not currently provide for real time screen updates. Thus, a picture is taken each time a screen update is made. The pictures are combined into a movie. 1.3. Summary Animation provides a graphical mechanism for presenting the structure, dynamics and control logic used in a simulation. Such presentation capabilities make establishing the validity of a model, either with a decision maker or with the model builder, an easier task. Animation works hand-in-hand with the traditional quantitative measures of simulation performance to evaluate systems. The framework provided by TESS for performing post-simulation animations is discussed. An example illustrating this framework will be presented. An animation of an actual system will be described.
2.0 THE TESS FRAMEWORK FOR ANIMATION
TESS provides a framework for performing post-simulation animation as shown in Figure 1. An animation consists of three components: 1. A list of event occurrences (trace) in a simulation; 2. A schematic of a system (facility diagram) on which to show the animation: and 3. A set of statements (rule) for mapping between the trace and actions to be taken on the facility during the animation. In addition, the general data selection capabilities of TESS can operate on the trace. Selection of time intervals, particular events and types of entities are typical uses of the selection capabilities. Figure 2 shows the relationship between the trace, actions taken on a facility and a rule when using TESS with SLAM II[4]. Four event types comprise a SLAM II trace. For event models, discrete events occurring at a particular
123
Animating simulations using TESS List of Event Facility
Rule
Occurrences (Trace)
Ess Oata
k,~lection
I, Animation
Fig. I. The TESS animation framework.
Animation
SLAM I I Event Trace
Actions on a Facility
Rule
Fig. 2. The relationship between traces, rules and facilities.
time and state events occurring when particular conditions are met in the simulation are recognized. The start end completion of activities are the events which occur in network models. These four types of events are illustrated for a queuing system in Figure 3. Three actions can be taken during an animation. Movement can be shown to correspond to physical movements in a system. Color changes in blocks can be used to show changes in system status. Counter changes can be used to monitor variable values. These three types of actions are illustrated for a queuing system in Figure 4. A rule relates the events of a simulation to the actions to be taken on a facility during an animation. A many-to-many mapping is provided. A rule consists of statements; each statement relates one event to one animation action. The following table gives statements which relate the network segment in Figure 3C to the facility shown in Figure 4. EVENT
ACTION
Start Activity 1 Start Activity 1 Complete Activity 1
Subtract 1 from Q counter Change SERVER block to green Change SERVER block to red
Note that two actions are specified when the event "start of activity 1" occurs.
124
C. R. STANDRIDGE C SCHEDULEEND OF SERVICE EVENT EVENTCODE=I TIMETILEVENT=5.0 C ATRIB CONTAINS THE ATTRIBUTES C OF THE ENTITY BEING SERVICED CALL SCHDL(EVENTCODE, TIMETILEVENT, ATRIB) A.
Discrete Event Scheduled for End-of-Service
# in
Tshreshold to Add an Additional Server
Queue
tate event condition
7 FB.
State event time X
State Event Time to Add an Additional Server ALLOCATE SERVER
PERFORM SERVICE
A c t i v i t y Start
FREE SERVER
Activity Completion to
to Begin Service End Service C.
Start and Completion of Activity Events for Performing Service
Fig. 3. Illustration of event types. Counter Change to Show Number in Queue
Color Change to Show Change in Server Status
i
GREEN=BUSY RED=IDLE
SERVER
Movement From
T
Arrival Area to Processing Area
Processing Area to Departure Area
Movement From
Fig. 4. Illustration of animation actions.
3.0 AN EXAMPLE ANIMATION
An example illustrates the concepts presented in the previous section and shows the procedure for building animations in TESS. An animation showing a new scheduling option is needed as part of the evaluation of a quarry system. The TESS facility diagram depicting this system (Figure 5) shows that the quarry consists of three shovels, one crusher and trucks which carry rock from a shovel to the crusher and return empty. Each truck services a particular shovel. Two sizes of trucks are available, twenty-ton and fifty-ton. Larger trucks have priority at the shovels and crusher. In the scenario to be animated, two twenty-ton and one fiftyton truck provide service to each shovel. In Figure 5, the roadways along which the trucks move are shown as long, narrow rectangles. The crusher and the shovels are shown as rectangles while triangles represent parking areas for the crusher and shovels.
125
Animating simulations using TESS
SHOUEL1
CRUSHER
SHOUEL~
SHOVEL3
e TIIIE
I
le
I
2Q
30
4e
5e
60
?0
80
go
I
I
I
I
I
I
I
I
llO
I
Fig. 5. Facility diagram of the quarry system.
The animation must show: 1. The movement of the trucks between the shovels and the crusher; 2. The number in the parking area of each shovel and the crusher; and 3. The status (idle or busy) of each shovel and the crusher. The quarry may be modeled by a SLAM II network given in Figure 6. In the upper row of symbols, trucks initially enter the network as specified in user written code. The node PSVL marks the time the truck enters the parking area of a shovel. The node labelled SVLS and the branch which emanates from it work together to model the loading of the trucks at the shovels. The queue represents the parking areas and the following branch represent the loading process. All three shovels are represented by these two symbols. The second attribute of a truck, ATRIB(2), tells the shovel which loads the truck. Thus, the individual shovels are simulated. Trucks traveling from a shovel to the crusher are modeled by the branch emanating from the node labelled ENDL. The queue node labelled CRSH and the following activity model the parking area and unloading of the trucks at the crusher. Trucks returning from the crusher to their assigned shovel are modeled by the activity beginning at the node BRET. The simulation time taken to complete each cycle is collected at the COLCT node at the end of this activity. The optional identifier of an activity is a number placed in a rectangular block below the activity. The associated events are the start and completion of the activity. A TESS CONTROL statement specifies the event occurrences to be stored in the TESS database during a simulation run. In general, a CONTROL specifies how a simulation is performed, including which data to collect. In this case, all events associated with the numbered activities are collected. Figure 7 shows a part of the list of event occurrences of the simulation (trace). The first three columns give the identifier of the event (EVENTCODE), the simulated time the event occurred (TNOW), and the duration of activities for activity start events (ACTDUR). In addition, two truck attributes are collected for each event. These are the size of the truck in tons (SIZE) and the identifier of the shovel to which the truck is assigned (SHOVEL).
ADD CH~IGE DELETE EXZT ZNCLUI~ LAIEL LO~D
C M
LOADING
I
ROUE PRORPT QUIT SCROLL UIEU ZOOR
RENU
All~IB(5)
TO $HOUELS
~'r-]
INITIAL TRUCK ASSIGIIIqENT
1~(6
) ITsYs
@F--]
COIqRAND:
CRU,~'I[NG
EXPOtI(ATRIB(4 ) )
1 RAXIRUR PRORPTING IN EFFECT.
F-7
ATRIB(5 )÷1
TO CRUSHER
I PSUL
ATRTB(6)-TItO~
,-] >-
z
CP,
Animating simulations using TESS
127
TRACE OF QUARRY SIMULATIOM
EVEMTCODE
TNOW
ACTDUR
SIZE
SHOVEL
62. 22. 21. 41. 42. 51. 32. 31. 41. 52. 61. 42. 51. 62. 42.
10.73 10.87 10.87 10.87 11.94 11.94 11.95 11.95 11.95 12.79 12.79 13.87 13.87 14.29 14.95
0.00 0.00 8.04 3.00 0.00 0.85 0.00 6.56 3.00 0.00 1.50 0.00 1.40 0.00 0.00
20. 50. 20. 50. 20. 20. 50. 20. 50. 20. 20. 50. 50. 20. 50.
2 2 2 2 2 2 3 3 3 2 2. 2. 2. 2. 3.
PQUSE. . . . DO YOU WISH TO COMTIMUE? PLEASE ENTER (Y) OR (M)
Fig. 7. The trace o f t h e qua~y simulation.
The final step in specifying the animation is the preparation of a rule. A rule is a set of statements. Each statement relates one event to one animation action. The field in the statement can be partitioned into three categories as follows:
Category
Field
Field Definition
Event identifier
.A
Event type
.B
Event code
.C
Block name
.D
Color Change
.E
Duration
.F
Direction
.G .I .J .K
Counter IF Operator Value
Activity Start, Activity Completion, State or Discrete Event Integer activity label or state or discrete event code number The name of the facility diagram symbol affected by the action. If the action is a color change, the new color of the block. If the action is a movement, the color rectangle to move along the path. The length in simulated time of a movement on a path. The default is the value in the ACTDUR column of the trace. The direction of the movement on a path; + for in the direction the path was drawn and - for opposite to the direction the path was drawn The change in a counter value Column name from the trace One of the relational operators A constant or a column name from the trace
Animation action
Condition
The rule for animating the quarry system is shown in Figure 8. Statements 10-1 l0 update the counters showing the number of trucks in the parking area of each shovel
-|
+ •
NO CI-k~IGE NO CHANGE 110 CH~flG[ NO CHAHG£
$30
530
CRO
CRO
2
6
3
4
RCT/S
RCT/C
RCTI S
RCT/C
~CI'/S
7e
8e
9e
tee
11e
5
1
•
NO CH~tNGE
$20
6
RCT/C
$20
Fig. 8. Rule for quarry animation.
110 CHN'IGE +
•
6e
gig
NO CI,~HGIE
I
4~CT/S
•
5e
SIO
110 CHANGE
6
ACT/C
•
NO CHANGE
4e
S30
.~OPIMAHDs
-|
1
-1
t
1
1
7
•
NO CHANGE
RCTIS
S;30
3e
1
7
+
¢¢T/$
NO CHmqG(
2e
SlO
7
ACT/S
te
• TOP.
SHOVEL
SHOVEL
SHOUEL
SH OAL
SH OAL
SHOVEL
EO
[O
EQ
EO
[0
EO
EQ
IE0
[O
[0
[0
3
;3
li
3
2
S
;> Z
SHOUEL3
CRUSHER
S~CP
S3CP
ACTtS
ACS/C
ACT/S
ACT/C
~CT/S
ACT/S
I~CT/S
16e
17e
18e
Ige
2Be
211)
~CT/S
SHOUEL3
ACT/C
lge
;,3e
SHOVEl.2
ACT/S
14e
C$1P
SICP
CRUSHIER
SHOUI[LE
SHOVEL 1
~ACT/C
13e
SHO~ELI
~CT/S
f2e
¢VAN
BLUE
MAGEHTA
CYAN
RED
GREEN
I~ED
GREEH
RED
GREEN
RED
GREEN
e •
:OMNAHDs
SHOU£L
SHOUEL
EP
•~
0
SHOUq£L
•
÷
÷
SHOUqEL
e
•
e
e
+
i
•
e
1 2 3 1
EO EQ EQ EO
Eg
Eg
EO
EO
EO
EO
EG
EG
,-]
~rQ
;>
e
|LUE
CS3P
ACT/$
2SQ
• BOT •
e
n~GEMTA
CSLPP
~CT/S
P4D EO EO
SHOUEL
S~O~L 3
2
Animating simulations using TESS
131
and the crusher. The first three statements account for the initial arrival of trucks at the shovels. The next eight statements are in four pairs. The first of each pair, the even numbered lines, increment the counter upon an arrival to the parking area. The second decrements the counter when a truck begins loading or unloading. Statements 120-190 changes the color of the rectangles to show the change in status (busy, idle) of the shovels and the crusher. Again, the statements occur in pairs. The first of the pair turns the color of the rectangle to green when a shovel or the crusher begins processing a truck. This processing corresponds to an activity in the SLAM II network. When the activity is completed by a truck, its processing by the shovels or the crusher is over. The second of the pair of statements turn the rectangle to red for idle. Statements 200-250 animate the movements of the trucks along the roadways. Statements 200-220 show the movement of trucks from each shovel to the crusher. Statements 230-250 show the movement of trucks from the crusher to each shovel. Figure 9 summarizes the process of generating the animation of the quarry model. A SLAM II N E T W O R K models the quarry. A simulation CONTROL specifies the collection of trace information during the simulation. A facility schematically shows the quary system. A rule relates the event occurrences forming the trace to the animation actions shown on the facility diagram. The central TESS database links all components. Because the animation is related to the events in the simulation, changes to the animation are possible without rerunning the simulation. For example, suppose we wish to study the crusher area in more detail as follows: 1. Show the number of twenty-ton trucks and the number of fifty-ton trucks in the parking area of the crusher; 2. Show the total number of trucks in the crusher area; 3. Show the crusher in three states red for idle, cyan (light blue) for processing a twenty-ton truck and dark blue for processing a fifty-ton truck. Note that none of this information is computed in the simulation. Figure 10 shows the new facility diagram. Note that the triangle CRQ has been replaced by two triangles, CRQ20 for showing twenty-ton trucks and CRQ50 for show-
SIMULATION
SIMULATION
FACILITY
CONTROL
SLAM II NETWORK
RULE
TESS DATABASE
ANIMATION
Fig. 9. The Process of Constructing the Quarry Animation.
132
C. R, STANDRIDGE
SHOUELI I
U
AA
-1
,A[ o-
SHOUEL3
0 TIME I
10
I
20
30
4@
50
6@
7e
BO
I
I
l
I
l
I
i
9Q
LQe
l
t
Fig. 10. Facility diagram ~ r t h e s e c o n d animation. FIELDS
INDEX
,A Event
Type
.B Event
Code
.C Block
Name
.D
.E
Color
Change
Duration
.F
.G
.I
Direction Counter IF
.J Operator
,K Value
1
ACT/C
4
CRQ20
+I
SIZE
EQ
20
2
ACT/C
4
CRQ50
+I
SIZE
EQ
5Q
3
ACT/S
5
CRQ2O
-I
SIZE
EQ
20
SIZE
EQ
50
4
ACT/S
5
CRQ5O
-I
5
ACT/C
4
CRSYS
+i
6
ACT/C
5
CRSYS
7
ACT/S
5
CRUSHER
CYAN
SIZE
EQ
20
8
ACT/S
5
CRUSHER
BLUE
SIZE
EQ
50
9
ACT/C
5
CRUSHER
RED
-I
Fig. 11. Statements to be added to the rule for the second animation.
ing fifty-ton trucks. A triangle CRSYS has been added on top of the CRUSHER rectangle to show the total number of trucks in the crusher area. Figure 11 summarizes the statements which would be added to the rule. Statements 1-4 increment and decrement the counters for the number of twenty-ton and fifty-ton trucks in the parking area. Statements 5 and 6 increment and decrement the counter for the number in the crusher area. Statements 7 and 8 turn the CRUSHER block the appropriate color when the processing of a truck begins. Statement 9 turns the CRUSHER rectangle to red at the end of processing. In the original rule, statements 100, 110, 180 and 190 are deleted. 4.0 CASE STUDY
A case study illustrates the TESS animation framework. Using animation for validation is shown.
133
AnimatingsimulationsusingTESS FIFO
UORDS PROP
I
UORDS
I
I--? I I,,oP
0 TIRE tO
I
l
2e
l
30
l
40
I
SO
60
I
I
?0
I
80
I
90
l
100
I
Fig. 12. Facility diagram of FIFO queuing area.
4.1. A computer communications model A FIFO queuing area is a fundamental component of a computer communication network. Packets being transmitted along the network queue at such a component for needed system resources. The facility diagram shown in Figure 12 gives a detailed picture of the FIFO structure. Packets are generated by a SOURCE. Packets move through the FIFO a word at a time to the sink. A HOLE is created when a packet departs the FIFO for a SINK. Four counters are shown during the animation. 1. S O U R C E - - n u m b e r of words waiting for transmissions 2. WORDS P R O P - - n u m b e r of words moving across the FIFO 3. W O R D S - - W O R D S PROP plus number of words in the process of exiting the FIFO. 4. H O L E S PROP--number of holes moving across the FIFO The READY symbol is green when a word can begin propagating across the FIFO and red otherwise. The total of WORDS and HOLES PROP cannot exceed 6. Thus, a word must wait for a hole to return across the FIFO before it can begin propagating. Two questions prompted the animation of this system. First, the analyst needed to confirm that the control logic of the FIFO was modelled correctly. Specifically, the analyst needed to know if words at the source were waiting for holes to propagate across the FIFO. One to two weeks time was spent examining printed trace reports of the simulation without resolving the issue. The animation resolved the issue positively in about one-half day. Secondly, the designers of the FIFO did not believe that it could reach its capacity of propagating six words concurrently. The animation showed that this was possible and the conditions under which capacity was achieved. 5.0 SUMMARY
Animating simulations helps both managers and analysts to gain confidence in simulation results. Graphics portray the structure and dynamics of the simulation. TESS provides a framework for constructing animations of simulations. Schematic models called facilities represent the structure of the system. A list of event occurrences of a simulation drives the animation. A set of statements called a rule specify the dynamics of the animation by relating the event occurrence in the simulation to the symbols of a facility. Animation actions are the changing of counter values and symbol
134
C . R . STANDRIDGE
colors as well as the movement of entities. These actions show simulation components such as queue lengths, state changes and entity movements. 6.0 REFERENCES 1. B. W. Hollocks, Practical benefits of animated graphics in simulation. Proceedings of the 1984 Winter Simulation Conference, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1984). 2. R. J. Miner, M. E. Grant & R. J. Mayer, Decision support for manufacturing. Proceedings of the 1981 Winter Simulation Conference, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1981). 3. C. D. Pegden, Introduction to SIMAN. Proceedings of the 1983 Winter Simulation ConJerence, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1983). 4. A. A. B. Pritsker, Introduction to Simulation and SLAM H, Second Edition, Halsted Press, New York and Systems Publishing Corporation, West Lafayette, IN (1984). 5. C. R. Standridge, S. A. Walker & D. K. Vaughan, A tutorial on TESS: the extended simulation system. Proceedings of the 1984 Winter Simulation Conference, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1984).
0360-8352/86 $3.00 + .00 © 1986 Pergamon Press Ltd.
Printed in Great Britain.
ANIMATING
SIMULATIONS
USING
TESS
CHARLES R. STANDRIDGE Pritsker & Associates, Inc., P.O. Box 2413, West Lafayette, Indiana 47906, U.S.A. (Received for publication 25 October 1985) Abstract--Animation techniques provide for displaying the dynamics and operating strategies of a simulation graphically. Thus, both analysts and decision makers can see how a simulation represented the modeled system. Within its framework for performing simulation studies, TESS provides a framework for animating simulations. Animations are performed as a post-simulation presentation tool using color-raster graphics. Animations are shown on a schematic diagram of the system, driven by a list of the event occurrences in the simulation, and related to the simulation by a set of statements called a rule. An example animation illustrates the use of the TESS animation framework. A case study shows its application to an actual system.
1.0 INTRODUCTION
Providing information which has an impact on decision making is a typical goal of a simulation project. Establishing the validity of the simulation model with a decision maker is fundamental to fulfilling this goal. Establishing such validity includes explaining the scope of the model, the structure of the system as captured by the model, the dynamics of the system included in the model, and the operating strategies employed during the simulation. In part from this explanation, the decision maker must decide whether the model represents the system accurately enough for simulation results to be useful input to the decision making process.
1.1. Showing validity with animation Because simulation reproduces the dynamics of a system, a verbal or written explanation of the model, its simulation and the simulation results may not convey the information necessary to establish validity. With the advent of raster graphics terminals, first monochrome and later color, the use of animation to present a model and its simulation became feasible. With animation, the dynamics and operating strategies of a simulation are captured graphically. Thus, the decision maker can see how the model represented the system, participate in the validation process and more easily decide upon the validity of the model. Before establishing the validity of a model with a decision maker, the analyst must become convinced of the validity of the model. In many cases, this process included examining a trace, the list of events which occurred in a simulation. This examination required pouring over a large volume of printed output. Often, it was difficult to assess the behavior of the model from this manual examination of the trace. As in establishing the validity of the model with a decision maker, animation helps to validate the model to the analyst. The behavior of the model can be seen graphically. Thus, issues concerning the structure, dynamics and operating strategies of the system can be addressed. 1.2. Modes of animation Animation capabilities have been included in several simulation packages. These capabilities provide for either simulation-concurrent animation or post-simulation animation. Post-simulation animation capabilities can be further divided into users of interactive graphics terminals and passive graphics, typically movies. The former usually use color, raster two dimensional graphics while the latter use color, vector three dimensional graphics. Simulation-concurrent animation provides for game playing with a simulation. A user can halt the simulation based on the condition of system as seen in the animation. 121
122
C . R . STANDRIDGE
Model parameters can be changed and the effect of these changes seen in the animation. In this environment, the game player can investigate the cause and effect relationships within a system. For example, the effect of changing service rates on relieving bottlenecks could be seen. However, such dynamic changes in model parameters invalidate any experimental design for analysis purpose. Thus, questions of system performance or design are best addressed in a non-gaming mode. In addition, simulation-concurrent animation is not possible for models whose simulation and animation cannot be computed interactively in a reasonable length of clock time. Several simulation packages provide for this kind of animation, for example the CINEMA add-on to SIMAN[3] and SEE WHY[l]. Post-simulation animation emphasizes the presentation of the dynamics and structure of a system as captured by a simulation. Selection of a subset of the simulation to animate is usually provided. In this way, the most interesting parts of the simulation. for example when an unusual combination of conditions occurs or when a queue length is particularly long, can be chosen for animation. Post-simulation animation allows any size simulation to be animated regardless of the amount of time required for simulation. One animation can be repeated several times or several animations can be generated from one simulation run. The major disadvantage of post-simulation animation is the lack of a gaming mode to explore system cause and effect relationships. Packages which provide post-simulation animation capabilities include IDSS 2.0[2], TESS[5], and Autosimulation. Interactive post-simulation and simulation-concurrent animations use color, raster graphics terminals. The terminal screen is updated in real time to show changes in the simulation, typically changes in resource status, queue lengths, or entity movements. Changes in numeric value displays, the color of blocks, or the visibility of ICONS implement the animation. Passive animations typically use three dimensional color, vector graphics. This technology does not currently provide for real time screen updates. Thus, a picture is taken each time a screen update is made. The pictures are combined into a movie. 1.3. Summary Animation provides a graphical mechanism for presenting the structure, dynamics and control logic used in a simulation. Such presentation capabilities make establishing the validity of a model, either with a decision maker or with the model builder, an easier task. Animation works hand-in-hand with the traditional quantitative measures of simulation performance to evaluate systems. The framework provided by TESS for performing post-simulation animations is discussed. An example illustrating this framework will be presented. An animation of an actual system will be described.
2.0 THE TESS FRAMEWORK FOR ANIMATION
TESS provides a framework for performing post-simulation animation as shown in Figure 1. An animation consists of three components: 1. A list of event occurrences (trace) in a simulation; 2. A schematic of a system (facility diagram) on which to show the animation: and 3. A set of statements (rule) for mapping between the trace and actions to be taken on the facility during the animation. In addition, the general data selection capabilities of TESS can operate on the trace. Selection of time intervals, particular events and types of entities are typical uses of the selection capabilities. Figure 2 shows the relationship between the trace, actions taken on a facility and a rule when using TESS with SLAM II[4]. Four event types comprise a SLAM II trace. For event models, discrete events occurring at a particular
123
Animating simulations using TESS List of Event Facility
Rule
Occurrences (Trace)
Ess Oata
k,~lection
I, Animation
Fig. I. The TESS animation framework.
Animation
SLAM I I Event Trace
Actions on a Facility
Rule
Fig. 2. The relationship between traces, rules and facilities.
time and state events occurring when particular conditions are met in the simulation are recognized. The start end completion of activities are the events which occur in network models. These four types of events are illustrated for a queuing system in Figure 3. Three actions can be taken during an animation. Movement can be shown to correspond to physical movements in a system. Color changes in blocks can be used to show changes in system status. Counter changes can be used to monitor variable values. These three types of actions are illustrated for a queuing system in Figure 4. A rule relates the events of a simulation to the actions to be taken on a facility during an animation. A many-to-many mapping is provided. A rule consists of statements; each statement relates one event to one animation action. The following table gives statements which relate the network segment in Figure 3C to the facility shown in Figure 4. EVENT
ACTION
Start Activity 1 Start Activity 1 Complete Activity 1
Subtract 1 from Q counter Change SERVER block to green Change SERVER block to red
Note that two actions are specified when the event "start of activity 1" occurs.
124
C. R. STANDRIDGE C SCHEDULEEND OF SERVICE EVENT EVENTCODE=I TIMETILEVENT=5.0 C ATRIB CONTAINS THE ATTRIBUTES C OF THE ENTITY BEING SERVICED CALL SCHDL(EVENTCODE, TIMETILEVENT, ATRIB) A.
Discrete Event Scheduled for End-of-Service
# in
Tshreshold to Add an Additional Server
Queue
tate event condition
7 FB.
State event time X
State Event Time to Add an Additional Server ALLOCATE SERVER
PERFORM SERVICE
A c t i v i t y Start
FREE SERVER
Activity Completion to
to Begin Service End Service C.
Start and Completion of Activity Events for Performing Service
Fig. 3. Illustration of event types. Counter Change to Show Number in Queue
Color Change to Show Change in Server Status
i
GREEN=BUSY RED=IDLE
SERVER
Movement From
T
Arrival Area to Processing Area
Processing Area to Departure Area
Movement From
Fig. 4. Illustration of animation actions.
3.0 AN EXAMPLE ANIMATION
An example illustrates the concepts presented in the previous section and shows the procedure for building animations in TESS. An animation showing a new scheduling option is needed as part of the evaluation of a quarry system. The TESS facility diagram depicting this system (Figure 5) shows that the quarry consists of three shovels, one crusher and trucks which carry rock from a shovel to the crusher and return empty. Each truck services a particular shovel. Two sizes of trucks are available, twenty-ton and fifty-ton. Larger trucks have priority at the shovels and crusher. In the scenario to be animated, two twenty-ton and one fiftyton truck provide service to each shovel. In Figure 5, the roadways along which the trucks move are shown as long, narrow rectangles. The crusher and the shovels are shown as rectangles while triangles represent parking areas for the crusher and shovels.
125
Animating simulations using TESS
SHOUEL1
CRUSHER
SHOUEL~
SHOVEL3
e TIIIE
I
le
I
2Q
30
4e
5e
60
?0
80
go
I
I
I
I
I
I
I
I
llO
I
Fig. 5. Facility diagram of the quarry system.
The animation must show: 1. The movement of the trucks between the shovels and the crusher; 2. The number in the parking area of each shovel and the crusher; and 3. The status (idle or busy) of each shovel and the crusher. The quarry may be modeled by a SLAM II network given in Figure 6. In the upper row of symbols, trucks initially enter the network as specified in user written code. The node PSVL marks the time the truck enters the parking area of a shovel. The node labelled SVLS and the branch which emanates from it work together to model the loading of the trucks at the shovels. The queue represents the parking areas and the following branch represent the loading process. All three shovels are represented by these two symbols. The second attribute of a truck, ATRIB(2), tells the shovel which loads the truck. Thus, the individual shovels are simulated. Trucks traveling from a shovel to the crusher are modeled by the branch emanating from the node labelled ENDL. The queue node labelled CRSH and the following activity model the parking area and unloading of the trucks at the crusher. Trucks returning from the crusher to their assigned shovel are modeled by the activity beginning at the node BRET. The simulation time taken to complete each cycle is collected at the COLCT node at the end of this activity. The optional identifier of an activity is a number placed in a rectangular block below the activity. The associated events are the start and completion of the activity. A TESS CONTROL statement specifies the event occurrences to be stored in the TESS database during a simulation run. In general, a CONTROL specifies how a simulation is performed, including which data to collect. In this case, all events associated with the numbered activities are collected. Figure 7 shows a part of the list of event occurrences of the simulation (trace). The first three columns give the identifier of the event (EVENTCODE), the simulated time the event occurred (TNOW), and the duration of activities for activity start events (ACTDUR). In addition, two truck attributes are collected for each event. These are the size of the truck in tons (SIZE) and the identifier of the shovel to which the truck is assigned (SHOVEL).
ADD CH~IGE DELETE EXZT ZNCLUI~ LAIEL LO~D
C M
LOADING
I
ROUE PRORPT QUIT SCROLL UIEU ZOOR
RENU
All~IB(5)
TO $HOUELS
~'r-]
INITIAL TRUCK ASSIGIIIqENT
1~(6
) ITsYs
@F--]
COIqRAND:
CRU,~'I[NG
EXPOtI(ATRIB(4 ) )
1 RAXIRUR PRORPTING IN EFFECT.
F-7
ATRIB(5 )÷1
TO CRUSHER
I PSUL
ATRTB(6)-TItO~
,-] >-
z
CP,
Animating simulations using TESS
127
TRACE OF QUARRY SIMULATIOM
EVEMTCODE
TNOW
ACTDUR
SIZE
SHOVEL
62. 22. 21. 41. 42. 51. 32. 31. 41. 52. 61. 42. 51. 62. 42.
10.73 10.87 10.87 10.87 11.94 11.94 11.95 11.95 11.95 12.79 12.79 13.87 13.87 14.29 14.95
0.00 0.00 8.04 3.00 0.00 0.85 0.00 6.56 3.00 0.00 1.50 0.00 1.40 0.00 0.00
20. 50. 20. 50. 20. 20. 50. 20. 50. 20. 20. 50. 50. 20. 50.
2 2 2 2 2 2 3 3 3 2 2. 2. 2. 2. 3.
PQUSE. . . . DO YOU WISH TO COMTIMUE? PLEASE ENTER (Y) OR (M)
Fig. 7. The trace o f t h e qua~y simulation.
The final step in specifying the animation is the preparation of a rule. A rule is a set of statements. Each statement relates one event to one animation action. The field in the statement can be partitioned into three categories as follows:
Category
Field
Field Definition
Event identifier
.A
Event type
.B
Event code
.C
Block name
.D
Color Change
.E
Duration
.F
Direction
.G .I .J .K
Counter IF Operator Value
Activity Start, Activity Completion, State or Discrete Event Integer activity label or state or discrete event code number The name of the facility diagram symbol affected by the action. If the action is a color change, the new color of the block. If the action is a movement, the color rectangle to move along the path. The length in simulated time of a movement on a path. The default is the value in the ACTDUR column of the trace. The direction of the movement on a path; + for in the direction the path was drawn and - for opposite to the direction the path was drawn The change in a counter value Column name from the trace One of the relational operators A constant or a column name from the trace
Animation action
Condition
The rule for animating the quarry system is shown in Figure 8. Statements 10-1 l0 update the counters showing the number of trucks in the parking area of each shovel
-|
+ •
NO CI-k~IGE NO CHANGE 110 CH~flG[ NO CHAHG£
$30
530
CRO
CRO
2
6
3
4
RCT/S
RCT/C
RCTI S
RCT/C
~CI'/S
7e
8e
9e
tee
11e
5
1
•
NO CH~tNGE
$20
6
RCT/C
$20
Fig. 8. Rule for quarry animation.
110 CHN'IGE +
•
6e
gig
NO CI,~HGIE
I
4~CT/S
•
5e
SIO
110 CHANGE
6
ACT/C
•
NO CHANGE
4e
S30
.~OPIMAHDs
-|
1
-1
t
1
1
7
•
NO CHANGE
RCTIS
S;30
3e
1
7
+
¢¢T/$
NO CHmqG(
2e
SlO
7
ACT/S
te
• TOP.
SHOVEL
SHOVEL
SHOUEL
SH OAL
SH OAL
SHOVEL
EO
[O
EQ
EO
[0
EO
EQ
IE0
[O
[0
[0
3
;3
li
3
2
S
;> Z
SHOUEL3
CRUSHER
S~CP
S3CP
ACTtS
ACS/C
ACT/S
ACT/C
~CT/S
ACT/S
I~CT/S
16e
17e
18e
Ige
2Be
211)
~CT/S
SHOUEL3
ACT/C
lge
;,3e
SHOVEl.2
ACT/S
14e
C$1P
SICP
CRUSHIER
SHOUI[LE
SHOVEL 1
~ACT/C
13e
SHO~ELI
~CT/S
f2e
¢VAN
BLUE
MAGEHTA
CYAN
RED
GREEN
I~ED
GREEH
RED
GREEN
RED
GREEN
e •
:OMNAHDs
SHOU£L
SHOUEL
EP
•~
0
SHOUq£L
•
÷
÷
SHOUqEL
e
•
e
e
+
i
•
e
1 2 3 1
EO EQ EQ EO
Eg
Eg
EO
EO
EO
EO
EG
EG
,-]
~rQ
;>
e
|LUE
CS3P
ACT/$
2SQ
• BOT •
e
n~GEMTA
CSLPP
~CT/S
P4D EO EO
SHOUEL
S~O~L 3
2
Animating simulations using TESS
131
and the crusher. The first three statements account for the initial arrival of trucks at the shovels. The next eight statements are in four pairs. The first of each pair, the even numbered lines, increment the counter upon an arrival to the parking area. The second decrements the counter when a truck begins loading or unloading. Statements 120-190 changes the color of the rectangles to show the change in status (busy, idle) of the shovels and the crusher. Again, the statements occur in pairs. The first of the pair turns the color of the rectangle to green when a shovel or the crusher begins processing a truck. This processing corresponds to an activity in the SLAM II network. When the activity is completed by a truck, its processing by the shovels or the crusher is over. The second of the pair of statements turn the rectangle to red for idle. Statements 200-250 animate the movements of the trucks along the roadways. Statements 200-220 show the movement of trucks from each shovel to the crusher. Statements 230-250 show the movement of trucks from the crusher to each shovel. Figure 9 summarizes the process of generating the animation of the quarry model. A SLAM II N E T W O R K models the quarry. A simulation CONTROL specifies the collection of trace information during the simulation. A facility schematically shows the quary system. A rule relates the event occurrences forming the trace to the animation actions shown on the facility diagram. The central TESS database links all components. Because the animation is related to the events in the simulation, changes to the animation are possible without rerunning the simulation. For example, suppose we wish to study the crusher area in more detail as follows: 1. Show the number of twenty-ton trucks and the number of fifty-ton trucks in the parking area of the crusher; 2. Show the total number of trucks in the crusher area; 3. Show the crusher in three states red for idle, cyan (light blue) for processing a twenty-ton truck and dark blue for processing a fifty-ton truck. Note that none of this information is computed in the simulation. Figure 10 shows the new facility diagram. Note that the triangle CRQ has been replaced by two triangles, CRQ20 for showing twenty-ton trucks and CRQ50 for show-
SIMULATION
SIMULATION
FACILITY
CONTROL
SLAM II NETWORK
RULE
TESS DATABASE
ANIMATION
Fig. 9. The Process of Constructing the Quarry Animation.
132
C. R, STANDRIDGE
SHOUELI I
U
AA
-1
,A[ o-
SHOUEL3
0 TIME I
10
I
20
30
4@
50
6@
7e
BO
I
I
l
I
l
I
i
9Q
LQe
l
t
Fig. 10. Facility diagram ~ r t h e s e c o n d animation. FIELDS
INDEX
,A Event
Type
.B Event
Code
.C Block
Name
.D
.E
Color
Change
Duration
.F
.G
.I
Direction Counter IF
.J Operator
,K Value
1
ACT/C
4
CRQ20
+I
SIZE
EQ
20
2
ACT/C
4
CRQ50
+I
SIZE
EQ
5Q
3
ACT/S
5
CRQ2O
-I
SIZE
EQ
20
SIZE
EQ
50
4
ACT/S
5
CRQ5O
-I
5
ACT/C
4
CRSYS
+i
6
ACT/C
5
CRSYS
7
ACT/S
5
CRUSHER
CYAN
SIZE
EQ
20
8
ACT/S
5
CRUSHER
BLUE
SIZE
EQ
50
9
ACT/C
5
CRUSHER
RED
-I
Fig. 11. Statements to be added to the rule for the second animation.
ing fifty-ton trucks. A triangle CRSYS has been added on top of the CRUSHER rectangle to show the total number of trucks in the crusher area. Figure 11 summarizes the statements which would be added to the rule. Statements 1-4 increment and decrement the counters for the number of twenty-ton and fifty-ton trucks in the parking area. Statements 5 and 6 increment and decrement the counter for the number in the crusher area. Statements 7 and 8 turn the CRUSHER block the appropriate color when the processing of a truck begins. Statement 9 turns the CRUSHER rectangle to red at the end of processing. In the original rule, statements 100, 110, 180 and 190 are deleted. 4.0 CASE STUDY
A case study illustrates the TESS animation framework. Using animation for validation is shown.
133
AnimatingsimulationsusingTESS FIFO
UORDS PROP
I
UORDS
I
I--? I I,,oP
0 TIRE tO
I
l
2e
l
30
l
40
I
SO
60
I
I
?0
I
80
I
90
l
100
I
Fig. 12. Facility diagram of FIFO queuing area.
4.1. A computer communications model A FIFO queuing area is a fundamental component of a computer communication network. Packets being transmitted along the network queue at such a component for needed system resources. The facility diagram shown in Figure 12 gives a detailed picture of the FIFO structure. Packets are generated by a SOURCE. Packets move through the FIFO a word at a time to the sink. A HOLE is created when a packet departs the FIFO for a SINK. Four counters are shown during the animation. 1. S O U R C E - - n u m b e r of words waiting for transmissions 2. WORDS P R O P - - n u m b e r of words moving across the FIFO 3. W O R D S - - W O R D S PROP plus number of words in the process of exiting the FIFO. 4. H O L E S PROP--number of holes moving across the FIFO The READY symbol is green when a word can begin propagating across the FIFO and red otherwise. The total of WORDS and HOLES PROP cannot exceed 6. Thus, a word must wait for a hole to return across the FIFO before it can begin propagating. Two questions prompted the animation of this system. First, the analyst needed to confirm that the control logic of the FIFO was modelled correctly. Specifically, the analyst needed to know if words at the source were waiting for holes to propagate across the FIFO. One to two weeks time was spent examining printed trace reports of the simulation without resolving the issue. The animation resolved the issue positively in about one-half day. Secondly, the designers of the FIFO did not believe that it could reach its capacity of propagating six words concurrently. The animation showed that this was possible and the conditions under which capacity was achieved. 5.0 SUMMARY
Animating simulations helps both managers and analysts to gain confidence in simulation results. Graphics portray the structure and dynamics of the simulation. TESS provides a framework for constructing animations of simulations. Schematic models called facilities represent the structure of the system. A list of event occurrences of a simulation drives the animation. A set of statements called a rule specify the dynamics of the animation by relating the event occurrence in the simulation to the symbols of a facility. Animation actions are the changing of counter values and symbol
134
C . R . STANDRIDGE
colors as well as the movement of entities. These actions show simulation components such as queue lengths, state changes and entity movements. 6.0 REFERENCES 1. B. W. Hollocks, Practical benefits of animated graphics in simulation. Proceedings of the 1984 Winter Simulation Conference, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1984). 2. R. J. Miner, M. E. Grant & R. J. Mayer, Decision support for manufacturing. Proceedings of the 1981 Winter Simulation Conference, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1981). 3. C. D. Pegden, Introduction to SIMAN. Proceedings of the 1983 Winter Simulation ConJerence, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1983). 4. A. A. B. Pritsker, Introduction to Simulation and SLAM H, Second Edition, Halsted Press, New York and Systems Publishing Corporation, West Lafayette, IN (1984). 5. C. R. Standridge, S. A. Walker & D. K. Vaughan, A tutorial on TESS: the extended simulation system. Proceedings of the 1984 Winter Simulation Conference, The Institute of Electrical and Electronics Engineers Inc., Piscataway, New Jersey (1984).