Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

Anisim : an animated interactive simulation monitoring system 1974

You don't seem to have a PDF reader installed, try download the pdf

Item Metadata

Download

Media
UBC_1974_A6_7 W34_5.pdf
UBC_1974_A6_7 W34_5.pdf [ 5.43MB ]
UBC_1974_A6_7 W34_5.pdf
UBC_1974_A6_7 W34_5.pdf
Metadata
JSON: 1.0051762.json
JSON-LD: 1.0051762+ld.json
RDF/XML (Pretty): 1.0051762.xml
RDF/JSON: 1.0051762+rdf.json
Turtle: 1.0051762+rdf-turtle.txt
N-Triples: 1.0051762+rdf-ntriples.txt
Citation
1.0051762.ris

Full Text

cl ANISIM: AN ANIMATED INTERACTIVE SIMULATION MONITORING SYSTEM by WARD WALKER, JR. B.A.(Honors), Washington State University, 1970 A THESIS SUBMITTED IN PARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE i n the Department of COMPUTER SCIENCE We accept t h i s thesis as conforming to the required standard THE UNIVERSITY OF BRITISH COLUMBIA A p r i l 1974 In presenting t h i s thesis i n p a r t i a l f u l f i l m e n t of the requirements f o r an advanced degree at the U n i v e r s i t y of B r i t i s h Columbia, I agree that the L i b r a r y s h a l l make i t f r e e l y a v a i l a b l e f o r reference and study. I fur ther agree that permission f o r extensive copying of t h i s thesis f o r s c h o l a r l y purposes may be granted by the Head of my Department or by h i s representat ives . It i s understood that copying or p u b l i c a t i o n of t h i s t h e s i s f o r f i n a n c i a l gain s h a l l not be allowed without my wri t ten permission. Department The U n i v e r s i t y of B r i t i s h Columbia Vancouver 8, Canada Date X I ABSTRACT An int e r a c t i v e system i s described which allows for the graphic construction, simulation, and simultaneous animation of an a r b i t r a r y network of queues. A method i s proposed and implemented for representing the events of a discrete simulation by a continuous animation on a graphics terminal. Techniques are presented f o r the display of p a r a l l e l animation "sequences," and a non-trival mapping of simulation time into animation time i s described which preserves the r e l a t i v e order and time relationships between events. The program implemented combines t h i s animation f a c i l i t y with other simulation monitoring and control features. The usefulness of thi s type of approach i s discussed with respect to computer-aided design applications, educational tools, and research tools. An i n t e r a c t i v e dialogue which makes use of the lightpen and a menu of commands i s implemented for the construction and modification of the queuing network. Certain relevent aspects of man-machine inte r a c t i o n are discussed. Also, some prospects are considered for applying the animation techniques developed i n thi s implementation to other discrete event processes. T A B L E O F C O N T E N T S INTRODUCTION 0.1 Animating Simulations 0.2 Scope 0.3 Queuing Networks 0.4 Simulation States And Events I. INTERACTIVE GRAPHICS FOR COMPUTER-AIDED MODELLING ... ...1 1.1 Types Of Systems 1 1.2. ANISIM 1 1.3 Important P r i n c i p l e s 1 1.4 Model Representation ...1 I I . ANIMATION TECHNIQUES 1; 2.1 Computer Animation .1c 2.2 Representing Events . .1 2.3 Animation Time Frame ...2 2. 3 . 1 -Types Of Sequences 2 2 . 3 . 2 Internal Cycles 2 2 . 3 . 3 Editing The Event L i s t . . . . . . 3 2.4 The Display Process 3 2.4 . 1 The Display Buffer . i . 3 2 . 4 . 2 Compiling Sequences Into Display Programs 3 2 . 4 . 3 Double Buffering .4 2.5 The Overall Visual E f f e c t 4 I I I . INTERACTIVE FEATURES 4 3.1 Simulation Monitoring And Control .4 i v 3.1.1 System Control 47 3.1.2 Simulation Monitoring 50 3.2 Model Design and Modification ........................57 3.2.1 Network Construction .57 3.2.2 Model V e r i f i c a t i o n ...65 IV UTILITY OF ANIMATION 70 4.1 Simulation Tool ........70 4.2 Educational Tool 73 4.3 Research Tool ...77 V CONCLUSIONS, PROSPECTS, AND EXTENSIONS 81 5.1 Analysis .81 5.2 Limitations ...82 5.3 Extensions 85 5.4 Prospects For Further Work .88 BIBLIOGRAPHY .92 APPENDIX A — PROGRAM DESIGN 94 APPENDIX B — DATA STRUCTURE ....104 APPENDIX C — USER'S GUIDE 106 V LIST OF FIGURES 1. A Simple Queuing Network » .......6. 2. Modelling Abstractions ........10 3. Animation Sequences For Display Of A Departure Event ...21 4. Simple Time Expansion 23 5. Mapping Events Into Sequences 23 6. The Internal Cycle 28 7. Display Program To Alter The State Of A Queue .......... 37 8. Display Program Timer Words 39 9. Buffer Co-Ordination , ......... 42 10. Commands Available , . . . . 4 9 ' 1 1 . Labelled E n t i t i e s .......52 1 2 . Display Of Blocked Items ..........56 1 3 . Menu For Network Design .59 14 . Specifying Queues -> 62 1 5 . Buffer Sketching ..63 16. Dialogue For Specifying Service Times ..66 17. Queuing Theory Comparison 76 1 8 . Simple Deadlock 78 ; 19. A P a r t i a l l y Deadlocked Network 79 2 0 . Transaction Grouping .T.. .-84 2 1 . System Configuration •••• • » » 9 4 2 2 . The NODE Record 104 2 3 . Data Structure For Queues 106 2 4 . The EVENT Record •••107 ACKNOWLEDGEMENT I would l i k e to acknowledge Dhirendra Chheda and Miguel Alemparte f o r th e i r s i g n i f i c a n t part in the programming and formulation of the o r i g i n a l system. I would also l i k e to thank Dr. Doug Seeley for his help and guidance, and Drs. Jim Varah and Dean Uyeno for th e i r suggestions. I would esp e c i a l l y l i k e to express my appreciation to Karen Hartley for her moral support and assistance i n f i n i s h i n g t h i s thesis. 1 INTRODU CTION 0 . 1 Animating Simulations Discrete event simulation has become an important t o o l in the analysis and design of complex systems. Conclusions about the performance of a system can be drawn from the s t a t i s t i c s produced by simulating a model of that system with various parameters and s p e c i f i c a t i o n s . When analyzing the output of such a simulation, the modeller must f i r s t of a l l be aware of the inherent assumptions of the model, as well as the values of the parameters. Secondly, he may need to know more about c e r t a i n c h a r a c t e r i s t i c s of the model that may be masked by s t a t i s t i c a l averages or extremes. Determining just how to a l t e r a model i n order to improve i t s performance can be a d i f f i c u l t or even counterintuitive process. If only the modeller could "step inside" his model and "watch" i t perform as the r e a l system might perform. This thesis describes the implementation of a system that brings the modeller to a closer understanding of h i s model by providing a graphical animation of i t s simulation. The animation f a c i l i t y i s the main feature of a complete i n t e r a c t i v e package which allows an on-line graphical d e f i n i t i o n of the model and extensive monitoring of i t s simulation. Considerable emphasis has been placed on providing f o r a reasonably smooth and meaningful dialogue between the user and the system. 2 One p a r t i c u l a r use of t h i s system, t h a t o f s t u d y i n g i n g e n e r a l t h e b e h a v i o r known as " d e a d l o c k " , w i l l be d i s c u s s e d , as w e l l a s a p p l i c a t i o n s t o computer a i d e d d e s i g n and t o computer a n i m a t i o n as an e d u c a t i o n a l t o o l . A g e n e r a l t e c h n i q u e i s devel o p e d f o r t h e mapping of s i m u l a t i o n " e v e n t s " i n t o a s e t o f c o - o r d i n a t e d a n i m a t i o n "sequences" f o r d i s p l a y . A l s o , some i m p l i c a t i o n s a r e drawn c o n c e r n i n g the use o f s i m i l a r a n i m a t i o n t e c h n i q u e s f o r m o n i t o r i n g o t h e r , perhaps r e a l - t i m e , p r o c e s s e s . B a e c k e r [ 1 ] sums up the u t i l i t y o f computer a n i m a t i o n i n v i s u a l i z i n g dynamic phenomena o f mathematics, s c i e n c e , and e n g i n e e r i n g : "The computer has proved p a r t i c u l a r l y u s e f u l because o f i t s a b i l i t y t o c o n s t r u c t p r e c i s e , m a t h e m a t i c a l l y determined images, because o f i t s a b i l i t y t o s i m u l a t e h y p o t h e t i c a l w o r l d s , because of i t s a b i l i t y t o expand or c o n t r a c t space and t i m e , and because o f i t s a b i l i t y t o p o r t r a y complex s p a t i a l phenomena, p a r t i c u l a r l y t hose i n t h r e e d i m e n s i o n s . " 2i2_Sco£e When c o n s i d e r i n g the o b j e c t i v e o f a n i m a t i n g s i m u l a t i o n s , perhaps t h e u l t i m a t e g o a l would be t o d e v e l o p a system t h a t c o u l d animate any a r b i t r a r y s i m u l a t i o n program. T h i s was not a t t e m p t e d , and i s p r o b a b l y not even p o s s i b l e . Baecker and h i s s t u d e n t s [ 1 ] a r e d e v e l o p i n g a v a r i e t y of s y s t e m a t i c t e c h n i q u e s f o r r e p r e s e n t i n g computer p r o c e s s e s w i t h dynamic images. T h e i r emphasis, so f a r , has been on a n i m a t i n g computer £ro<jrams, r a t h e r than p r o c e s s e s which a r e d e s c r i b e d by s i m u l a t i o n 3 programs. One conclusion they have already reached, i s that i t i s impossible to build a system which could produce a good animation of any program i n any language running on a s p e c i f i c machine. Instead, they want to build a variety of powerful special-purpose tools, each suited to the animation of a p a r t i c u l a r class of programs. an animation of a simulation must manipulate graphical symbols i n such a way that they resemble the objects and processes being modelled. Even a very i n t e l l i g e n t program could not create meaningful symbols and motions by scanning the code of a simulation program. After a l l , the model i t s e l f i s only an abstraction of r e a l i t y . The animation must create a vi s u a l image of a r e a l s i t u a t i o n ; a task which requires information often not available from, or important to, the model. In f a c t , in the case of a discrete event simulation (described i n Section 0.4), the animation must appropriately " f i l l i n " the time between simulated events i n order to provide a continuous display. A lesser goal, therefore, might be to animate programs written i n a s p e c i f i c simulation language, such as Simscript [21] or GPSS [ 9 ] . I t may be possible to provide a limited set of pre-defined, or e a s i l y defined, graphic primitives (both symbols and motions), and a set of function c a l l s to be inserted into the simulation where required to produce the desired animation e f f e c t s . This method would be d i f f i c u l t to implement and would place an overwhelming burden on the user to create a well-defined program with a l l of the necessary information a v a i l a b l e for the animation routines. Thus, the system which has been implemented, hereafter referred to as ANISIH, does not attempt to animate an exis t i n g simulation, but contains i t s own spe c i a l simulation program designed to handle a subclass of models known as queuing network models. This s t i l l involves a large variety of possible models, but the system i s now able to help the user formulate a well- defined model at the graphics terminal while i t creates the data structures necessary for the simulation and animation programs. It w i l l be shown l a t e r , how the techniques used i n ANISIM could be applied to certain other models or classes of models. The concept of a b u i l t - i n simulation means that the user works with a command language rather than a programming language. The trade-off i s between using a simple and convenient command language and having the a b i l i t y to t a i l o r the power of the simulation to handle s p e c i f i c needs. 0 i3_2ueuin3_Networks Before proceeding to further discussion of ANISIH, i t w i l l be useful to describe what i s meant by queuing networks and by simulation states and events. A queuing network model consists b a s i c a l l y of items t r a v e l l i n g along l o g i c a l paths of a network of "queues" and "servers". A queue represents a waiting l i n e of items (or "transactions") trying to get into one of the servers of the 5 "queue/server system". A server represents a delay of the item occupying i t before the item can move on to the next queue/server system or e x i t from the network. In c l a s s i c a l queuing theory, the "movement" of an item between any two nodes i n the network i s assumed to occur instantaneously. Items enter the network from a "source" and leave the network by going to a "sink". Figure 1 shows a queue/server system with ten items, s i x of them waiting to be served and four being served (the small squares). The symbols i n Figure 1 are those used by ANISIM and do not represent any queuing theory conventions. Certain f a i r l y simple queuing networks can be "solved" a n a l y t i c a l l y — t h a t i s , average queue lengths and waiting times can be found, mathematically, for the gueuing system when i t i s i n steady state [ 1 1 ] . Networks which can be solved i n t h i s manner are largely r e s t r i c t e d to those with i n f i n i t e queues and s p e c i a l constraints on a r r i v a l and service time d i s t r i b u t i o n s . Also, no information i s available regarding the performance of the system during more transient or time-dependent states. When a n a l y t i c a l solutions are inadequate or unavailable, simulation must be used to analyze the system. Like any other model, a queuing network i s an abstraction of r e a l i t y , although perhaps a more formal one than some. Thus any conclusions drawn about the behaviour of the queuing model can only be considered as approximations of the behavior of the r e a l system being modelled. 6 FIGUBE 1: A Simple Queuing Network From L e f t to B i g h t : Source, Queue, S e r v e r s , and Sink. 7 imul a t j o n g t a t eg_and The type of simulation involved here i s known as a discrete event simulation. This means that the model can be characterized by i t s "state" at any p a r t i c u l a r time and by a set of "events", or state changes, which occur at discrete time instants. Events can be exogenous (generated outside the system) or endogenous (generated within the system as a result of a previous event or s t a t e ) . There are a limited number of general types or "classes" of events that can occur, and each event i s an instance of an event class. Consider the following example of a discrete event model fo r a one-car f e r r y across a r i v e r , an observer on a nearby h i l l , sees an " a r r i v a l " as a car appearing at the l a s t bend of the road and moving to the end of the lineup. He sees a "service" as the loading of the f i r s t car into the fe r r y plus the actual crossing, the unloading, and perhaps the return t r i p of the f e r r y . F i n a l l y he sees a "departure" as the car moving on the other bank u n t i l i t disappears. A t y p i c a l discrete event model of t h i s s i t u a t i o n i s the so-called "single server f i r s t - i n f i r s t - o u t queue." The state of the system i s merely the number of cars in the lineup plus the one being served by the f e r r y . An " a r r i v a l " i s the instantaneous exogenous event that adds one to the state and a "departure" i s the instantaneous endogenous event that subtracts one from the state. The actual crossing or "service" i s the abstract concept of wait or delay between two 8 departures. Completely i r r e l e v a n t in t h i s p a r t i c u l a r model abstraction are the actions defined by the movement of the cars or the f e r r y (or the f a c t that they are cars at a l l ) . Of course, one could model a variety of s i t u a t i o n s using only these basic concepts. The modelling power may be increased by defining additional primitives while s t i l l maintaining the structure of a gueuing network. For example, at an early stage of development i t was decided that ANISIM should allow a "buffer" e n t i t y that imposes a f i n i t e common storage l i m i t on two or more queues. (e.g. I f the f e r r y terminal had two one- car f e r r i e s , each with t h e i r own waiting l i n e , but the two l i n e s had to share the same limited parking area.) I f the number of features added to the system to increase modelling power were allowed to become very large, (approaching, say, the c a p a b i l i t i e s of GPSS [ 9 ] ) , then two things might happen. F i r s t , the programming system, which i s large to begin with, may become too c o s t l y to use and awkward to maintain (as many large programming systems tend to be). More importantly, the graphical primitives would i n a l l probability f a i l to keep up with the much wider variety of modelling abstractions, each of which require v i s u a l aids to restore some r e a l i t y to the model being monitored. One of the main objectives of ANISIM i s to make i t possible for a human at the display terminal to monitor a simulation and to do i t as e a s i l y and accurately as possible. However, for 9 even a moderately complex system where the state of the system cannot be accurately represented by a simple number as i n the f e r r y example, but by a vector with many components, monitoring the simulation i s not a t r i v i a l task. What to display and how to display i t becomes the main problem. Solutions range from the display of the state vector i t s e l f every time i t changes (i.e. Display numbers or other symbols), to a sophisticated animation where sequences of moving elements are added as visual aids. ANISIM uses the l a t t e r , under the assumption that the mecessary abstractions which were, indeed, so useful for a n a l y t i c a l and computational purposes, hinder the process of monitoring the system (see figure 2 ) . Rea'l S y 5 tern 10 R e s t o r e R e a l i t y ( V i s u a ! A i d s ) D i s p l a y l I The M o n i t o r i n g Human A b s t r a c t i on o f R e a l i t y S i m u l a t i on C a l c u l a t i o n s S t a t i s t i c s I t The A n a l y z i n g Human FIGURE 2 : Modelling Abstractions 11 I. INTERACTIVE GRAPHICS FOR COMPUTER-AIDED MODELLING iiJ_Tv£gs_of_Svsterns A number of graphics systems have been developed i n the l a s t few years that provide a c a p a b i l i t y to model a process or s p a t i a l configuration in order to learn more about i t and, hopefully, improve i t s design. (Several of these are mentioned below. Further discussion and references may be found in Prince [18], Smith [23], and Newman and Sproull [16].) In many cases, the information available from such a model can be considerably enhanced by allowing the viewer to interact with the system that generates or displays the model, even i f t h i s interaction i s simply, say, the rotation about an axis of a 3-D model of a molecule [17]. Some systems use the graphics terminal as a sophisticated sketchpad, while others re l y on the terminal for input to, and output from, a non-graphics processing program. In almost a l l systems, a s u f f i c i e n t data structure must be created by the program to allow, at l e a s t , the saving and l a t e r restoring of models generated. Also, in even the simplest system, some thought must be given to the manner in which the user and the program communicate with each other (see Chapter III) . Consider the following two examples: a) an i n t e r a c t i v e program to design the s p a t i a l layout of integrated c i r c u i t s [19], and b) and a r c h i t e c t u r a l l y oriented program for generating 12 perspective drawings of three-dimensional polyhedra [14], In each case, the user can quickly sketch preliminary "models", at a convenient scale, of something he may l a t e r construct or design i n more d e t a i l . The processing program i s confined mostly to graphical techniques which help the designer create a well-defined model and then observe as much as possible about the model that he has just created. Another type of computer-aided modelling allows the user to see, and thus further comprehend, the results produced by a non- graphics processing program. For example, a number of int e r a c t i v e systems have been developed to aid i n c u r v e - f i t t i n g and other mathematical approximation techniques [15,23,12]. The user s p e c i f i e s input data, parameters and options, any of which he may wish to a l t e r a f t e r viewing graphical representations of the output (or of intermediate steps). Such systems usually must also make available more detailed printed information for la t e r study. ANISIM i s p a r t i a l l y t h i s type of system, as i t allows the user to quickly analyze the e f f e c t s of simulation parameters by displaying the r e s u l t s of the simulation. The int e r a c t i v e features which f a c i l i t a t e t h i s c a p a b i l i t y are also discussed i n Chapter III. On the other hand, there are cases when an in t e r a c t i v e graphics c a p a b i l i t y provides for a more natural ingut medium to a non-graphics program i n terms of speed, convenience, or possibly r e l i a b i l i t y [24], For example, Forrester [8], has 13 found i t necessary to d e s c r i b e complex dynamic s i m u l a t i o n models g r a p h i c a l l y , i n order to f o l l o w the i n t e r - r e l a t i o n s h i p s between the v a r i a b l e s , and then code the s i m u l a t i o n i n a programming language. Chheda [ 4 ] has developed an i n t e r a c t i v e system f o r c r e a t i n g t h i s g r a p h i c a l r e p r e s e n t a t i o n of a dynamic model on a g r a p h i c s t e r m i n a l i n such a way t h a t the program statements f o r the a c t u a l s i m u l a t i o n are a u t o m a t i c a l l y generated. Of course, t h i s type of system may r e q u i r e the user to enter a l a r g e amount of d e t a i l e d i n f o r m a t i o n at the g r a p h i c s t e r m i n a l . The q u a l i t y of the d i a l o g u e between the system and the user t h e r e f o r e , becomes of paramount importance to the success of t h i s approach t o model desi g n . 1. 2_ANISIM ANISIM i s a l s o , i n p a r t , t h i s l a t t e r type of system. In Chapter I I I we see how the program guides the model b u i l d e r through the necessary steps r e q u i r e d to b u i l d a w e l l - d e f i n e d queuing network, while c o n s t r u c t i n g the necessary data base f o r the s i m u l a t i o n (and animation). The advantages of g r a p h i c a l i n p u t , i n the case of network d e s i g n , a l s o i n c l u d e the immediate v i s u a l feedback t h a t the modeller can u t i l i z e i n order to help v e r i f y t h a t the intended model i s being p r o p e r l y c r e a t e d . Thus we see t h a t ANISIM combines the advantages of g r a p h i c a l i n p u t to a p r o c e s s i n g program with those of a g r a p h i c a l d i s p l a y of the r e s u l t s . In the case of s i m u l a t i o n 14 however, i t i s sometimes desirable to display not just the representation of a " f i n a l state", but a detailed animation of the model as the simulation progresses. In other words, the processing of the simulation and the display of i t s events must occur almost simultaneously i n order to enable the model designer to actually interact with the simulation (the "almost" i s explained i n Chapter I I ) . k user of AHISIM, once he has created a network, may decide to monitor an animation of i t s simulation for a while, interrupt the simulation when he i s not s a t i s f i e d with the model ,s performance, and possibly display some s t a t i s t i c s for further appraisal. He may then wish to edit one or more parameters or even the model structure, and resume monitoring the simulation (after reseting the s t a t i s t i c s and clock, i f necessary). 1 :3_Im£ortant_Princi£les There are then, three main p r i n c i p l e s that seem to be present i n most i n t e r a c t i v e graphics modelling systems: a) the system provides a means of testing model design that i s fa s t e r , e a s i e r , more r e l i a b l e , or otherwise more convenient than other possible methods, b) the system allows the modeller to proceed, with a r e l a t i v e l y short turn-around time, through the cycle of design, study, and re-design i n his attempt to optimize the model (or otherwise t e s t v a r i a t i o n s ) , and c) the system makes use of the graphics terminal as an additional I/O medium to augment the information that may be presented by other media. 15 In f a c t , i n some cases, the graphics terminal i s the only reasonable device on which the above two p r i n c i p l e s can be observed (such as i n the architecture program mentioned e a r l i e r ) . Furthermore, the int e r a c t i v e aspect of the system allows the user to s e l e c t i v e l y provide, display, or watch only that information which he fe e l s to be most pertinent. J i 4 _ H o del_Bej>r esent at ion One problem associated with monitoring the animation of a queuing network model in order to aid i n the design of a r e a l system l i e s i n the formulation of that system in the queuing network terms. The animation c e r t a i n l y aids i n the understanding of the queuing network, but i n some cases, the model i s formulated in such a way that i t does not v i s u a l l y resemble the real system that much. The formulation may be a very accurate approximation to the system, and the s t a t i s t i c s produced may provide important information about the system, but the animation i s of more value towards system design i f the modeller can mentally translate what he sees into what i t means i n the r e a l system. A simple example of thi s phenomenon i s that of an object which trav e l s between two service f a c i l i t i e s (say, a ship between two ports). The t r a n s i t time i s important to the model and cannot ea s i l y be combined with the delay of the f i r s t service f a c i l i t y (e.g. the loading times at the f i r s t port are assumed to be exponentially distributed and the travel times are uniformly d i s t r i b u t e d ) . The queuing network model of t h i s 16 s i t u a t i o n thus requires one server for each service f a c i l i t y and a t h i r d server to approximate the delay associated with the route. Of course the animation then shows the object en route as a box inside a server symbol. (We s h a l l see i n the next chapter how the animation shows the box moving between servers merely to display, smoothly, state changes which are assumed to be instantaneous in the model.) In a f a i r l y complex system, several occurrences of t h i s problem may multiply the complexity of the network, further reducing the usefulness of the o v e r a l l animation (although the modeller may s t i l l f i nd s p e c i f i c portions of the animation in s t r u c t i v e to watch). There are two ways of combating t h i s representation problem. A user of ANISIH, with some practice, soon learns to position the symbols of the network so that the animation most c l o s e l y resembles, i n a l o g i c a l sense, the processes being modelled. With a l i t t l e more practice he becomes more adept at thinking of things in terms of s t r i c t queuing network representations. A l t e r n a t i v e l y , ANISIH could be expanded to include optional features (such as t r a n s i t times) that would allow a wider range of models to resemble the r e a l systems. To a cert a i n extent t h i s can and should be done. The drawback i s that the model d e f i n i t i o n phase (Chapter III) would become increasingly tedious for the user and i t would be more d i f f i c u l t f o r the program to help insure that the model created was well- defined. Chapter V contains further discussion of potential extensions to ANISIH. 17 Additional comments on the u t i l i t y of animated monitoring as a simulation tool are i n Chapter IV. 18 I I . ANIMATION TECHNIQUES 2. 1, gomputer_Animation Combining computer animation with simulation as a design or education tool i s not new. This seems p a r t i c u l a r l y true in f i e l d s such as physics, chemistry, e l e c t r i c a l engineering, and medicine, where laboratory experiments are being replaced by graphic simulation systems. An example i s a system which allows a medical student to observe the e f f e c t s of d i f f e r e n t stimuli on a diagram of a l i v i n g , moving organ [13]. However, most such systems involve continuous simulation rather than discrete event simulation. The model consists of a set of mathematical relationships which determine the value of each variable at every time unit as the simulation proceeds. Thus, at each time increment, the position, s i z e , length, or whatever, of each ent i t y i n the animation i s recomputed and the display i s updated. There i s no problem with p a r a l l e l processes. On the other hand, an event-oriented model changes state by discrete steps at i r r e g u l a r time i n t e r v a l s . It i s usually necessary to invent short, meaningful animation sequences to portray the state change of each component of the model. Most of t h i s chapter describes how ANISIM accomplishes t h i s task while maintaining the time relationships of the simulation. One example of an animated continuous simulation system that otherwise contains some s t r i k i n g p a r a l l e l s to ANISIM i s the 19 DYNIS program at the University of Waterloo [ 2 0 ] . DYNIS simulates and displays the response of three-dimensional mechanical systems (composed of masses, springs, dampers, force drivers and position d r i v e r s ) . Like ANISIM, i n t e r a c t i v e control of the simulation i s provided and a standard set of representative symbols i s used. Both programs have a " f i r s t stage" which leads the user through a s e r i e s of systematic decisions by the use of "menus" offering c e r t a i n possible choices. The use of a closed set of simulation e n t i t i e s (and, therefore, animation primitives), i n each case, allows t h i s f i r s t stage to create a well-defined model without carrying out an overly tedious dialogue. Like ANISIM, the symbols used are abstractions representing a wide variety of possible real-world objects. On the surface, then, these systems perform i n much the same way when used i n an i n t e r a c t i v e , system design environment. The s i g n i f i c a n t difference LIES IN THE INTERFACE BETWEEN THE SIMULATION AND THE ANIMATION. 2«^.Representing_ Events As mentioned e a r l i e r , simulation events, or state changes, are assumed to happen instantaneously at discrete points i n time. However, such a change of state i s normally a modelling abstraction which corresponds to a real-world process that has some r e l a t i v e l y short duration. In the f e r r y terminal example of Chapter I, an a r r i v a l to the queue corresponds to a car dr i v i n g up to the parking area. In order to graphically monitor 20 a f e r r y terminal simulation, every time an a r r i v a l event occurred, one should see a symbol of a car moving to a symbol of the waiting area. Likewise, three common visual aids for events i n ANISIM are 1) an item moving from a source to a queue ( a r r i v a l event), 2) an item moving from a server to a new queue (departure event), and 3) an item moving from a server to a sink (departure-from-system event). These, and other v i s u a l aids for events w i l l be referred to henceforth as "animation sequences", although they are single components of the ov e r a l l network animation. (We s h a l l see in Section 2.4.2 how each animation sequence i s compiled into a small display program.) Some sequences have no duration, such as the sequence that displays one more or one less item i n a queue. Also, not a l l events require a sequence, such as a blocked departure which must be rescheduled again ( i . e . the next queue or buffer i s s t i l l f u l l ) . F i n a l l y , a single event may trigger o f f more than one sequence. This i s true of a departure event, which requires a sequence to update the state of the losing queue/server system, a moving sequence (with a duration), and a sequence to update the state of the gaining queue/server system (see Figure 3). If either queue i s in a "buffer", then a fourth of f i f t h sequence may be required to update the bar graphs that show how f u l l the buffers are. Additional sequences currently i n ANISIM use arrows and blinking to i d e n t i f y blocked items and blocking gueues or buffers. a,. S t a t e o f System B e f o r e D e p a r t u r e Event. 21 fc. A n i m a t i o n - T i m e = T: I n s t a n t a n e o u s Seguence Updates Queue/Server Systera; Moving Sequence B e g i n s . c. A n i m a t i o n Time = T+50: Moving Sequence i n P r o g r e s s . d. A n i m a t i o n Time = T+100: Moving Sequence Ends; I n s t a n t a n e o u s Sequence Updates Second Cueue/Server System. FIGURE 3: A n i m a t i o n Sequences f o r D i s p l a y c f a D e p a r t u r e "Event 22 2 ^ 3_A Q i m a t i o n_T i me_ F rame A r e q u i r e m e n t o f a n i m a t i n g a d i s c r e t e s i m u l a t i o n i s t o p r e s e r v e t h e r e l a t i v e p r e c e d e n c e o f e v e n t s a n d t o p r e s e r v e t h e r e l a t i v e t i m e b e t w e e n e v e n t s . T h u s t h e q u e s t i o n a r i s e s a s t o how a n d when t o d i s p l a y s e q u e n c e s w h i c h we c h o o s e t o g i v e a p o s i t i v e d u r a t i o n . The m a p p i n g o f s i m u l a t i o n t i m e i n t o a n i m a t i o n t i m e r e q u i r e s some f o r m a l i z a t i o n . 2a3.1_Typ.es ° f S e q u e n c e s O n e , p e r h a p s t r i v i a l , way o f a d d i n g s e q u e n c e s w o u l d be t o e x p a n d t h e s i m u l a t e d t i m e s c a l e b y t h e d u r a t i o n o f t h e s e q u e n c e e v e r y t i m e a n e v e n t o c c u r s ( s e e F i g u r e 4). T h i s m e t h o d , h o w e v e r , h a s o n e s e r i o u s d r a w b a c k w h i c h i s t h a t i t s t o p s o r " b i n d s " t h e o n g o i n g s i m u l a t i o n t i m e e v e r y t i m e a n e v e n t o c c u r s . A l s o , t h e d i s p l a y i s c o m p l e t e l y s e q u e n t i a l , l e a v i n g no p r o v i s i o n f o r p a r a l l e l s e g u e n c e s . F o r e x a m p l e , t a k e t h e c a s e w h e r e t w o c a r s a p p r o a c h t h e l i n e up f o r t h e f e r r y . A s m a l l d i s t a n c e s e p a r a t e s t h e m , a n d t h e y a r e g o i n g a t t h e same s p e e d . A l l o u r s i m u l a t i o n m o d e l k n o w s i s t h a t c a r " a " a r r i v e s a t t h e q u e u e a t t i m e " t ( a ) n , a n d t h a t c a r " b " a r r i v e s a t t i m e " t ( b ) " , w h e r e t h e d i f f e r e n c e b e t w e e n t h e t w o t i m e s i s a r e l a t i v e l y s m a l l p o s i t i v e n u m b e r . H o w e v e r , s i n c e t h e t w o " a r r i v a l s " a r e t w o s i m u l a t i o n e v e n t s i n s e r i e s , t h e t w o a n i m a t i o n s e q u e n c e s w i l l b e i n s e r i e s . C a r " b " w i l l n o t b e g i n m o v i n g t o w a r d s t h e q u e u e u n t i l a f t e r c a r " a " h a s a r r i v e d a n d 23 Event Event 1 2 Event 3 S imulat i on Output Sequence Sequence 1- 2 Sequence Expanded 3 Time Seale FIGURE 4 : Simple Time Expansion Event Event 1 2 • Event Event 3 k Event Event 5 .6 S imulat i on T i me — i sht-S i d ounded. fcequence . UnVoundea Sequence PTwo-S i de Bounded Sequence B l a d i n g Sequence £ert-Sice* Bounded Sequence An imat ion T i me FIGURE 5: Mapping Events i n t o Sequences 24 stayed i n the queue for t(a)-t(b) time units. We are not conveying the parallelism of the two a r r i v a l sequences; something that i s desirable for monitoring purposes. In general t h i s approach does not restore much r e a l i t y to the model. The display of p a r a l l e l sequences can, however, be achieved i f a few simulation events are somehow buffered before displaying. These buffers of events, or "event l i s t s " , can thus be manipulated so that a r r i v a l sequences for example, can s t a r t their motion on the screen ahead of time and arri v e at the correct spot i n the queue exactly at the time the a r r i v a l event i s to take place. Display sequences, which may overlap i n time, can be compiled from one event l i s t and displayed by the graphics computer while subsequent event l i s t s are being generated. The problem, then, becomes one of editing the event l i s t s so that the order and time relationships between events are preserved. To simplify t h i s problem, i t i s useful to group display sequences into certain classes. For the following d e f i n i t i o n s , consider an animation sequence on a horizontal time axis (as i n Figures 4 and 5). The l e f t side and right side refer to the sequence's s t a r t i n g time and f i n i s h time, respectively. Binding_Seg_uencej^ This i s the type discribed above where the simulation time i s expanded by the inse r t i o n of the sequence. &n example i s a departure of an item from a server to a new queue. 25 Rlaz§id.§_B_2y.Hd_e_d_Seguences__ This type of sequence must end exactly with a simulation event, but i t can be started at any time before that. The time scale i s not expanded. An a r r i v a l event can be represented by a r i g h t - s i d e bounded sequence. Left-side_Bounded_Se£uence_. This type must s t a r t with an event, but can end at any time. An example i s a departure to a sink. £Ui>i§£i§2§2i2S_Se3uence_^ Hot a l l "sequences" require a duration. Certain events can be represented p a r t i a l l y , or sometimes completely, by merely changing the representation of the state. The a r r i v a l to a queue requires a right-side bounded sequence for the moving item and an instantaneous sequence (at the time the event happens) which changes the queue symbol to show one more item. A blocked-departure event i s represented only by two instantaneous sequences which "switch on" the blinking of the f u l l queue and the blinking of an arrow pointing from the blocked item to the f u l l queue. The sequence types defined above are used to represent events only. Two further types of animation sequences, which are not required in AUISIM at present, may also be useful i n order to properly animate an event-oriented simulation. Hn.b°"BJg^-§.§2,ugB£,gi. A sequence (for example, an error or warning message) triggered by some process other than the simulation i t s e l f can be regarded as an unbounded sequence. 26 Twoz§i^5_l2U£Seguence^. This type of sequence must star t and end with simulation events. I t does not expand the time scale, but i t can be used to further elaborate on a component of the state of the system. For example, i f we wanted to animate the process that takes place during that abstract concept of a "service", we would have to co-ordinate the sequence with the event that started the service and with the event that terminated the service (e.g. a departure). In the ferry terminal simulation, a two-side bounded sequence could be used to i l l u s t r a t e the round t r i p of the f e r r y . Such a sequence would give the modeller no useful information and would probably provide more d i s t r a c t i o n than r e a l i t y . An example of a more useful two-side bounded sequence would occur i f ANISIM were extended to allow t r a n s i t times between servers and queues. As pointed out in section 1.5, t h i s extension would considerably ease the representation problem. As f a r as the simulation i s concerned, the t r a v e l l i n g item has entered into a delay or service of a s p e c i f i e d duration ( i . e . the state of that part of the system i s s t a t i c between the two events). But the viewer sees that service as a moving sequence which, of course, does not bind the other events (expand the time s c a l e ) . Figure 5 i l l u s t r a t e s the mapping of simulation events into animation sequences. I t should be noted that an instance of an event from an event class generates an instance of a sequence of a certain type. For example, an a r r i v a l event always generates a r i g h t - s i d e bounded . sequence. However, due p a r t i c u l a r l y to 27 sequences which change the graphical representation of the state of the system, the animation routines require c e r t a i n information about the system which was available i n the data base at the time the simulation routine processed the event. For example, a sequence which displays the new state of a queue due to an a r r i v a l requires knowing what the state of the queue was before the a r r i v a l event occurred. The simulation may provide t h i s information in one of two ways: 1) Record, along with the event c l a s s , one or more subclass designators, or modifiers. For example, the state of a queue must be passed to the animation routines along with an event that causes an addition to or deletion from the queue. 2) P a r t i t i o n the event c l a s s i n t o two or more d i s t i n c t event classes. For example, i n ANISIM a departure from a server which has been blocked must turn o f f the blinking of the arrow pointing from the no-longer-blocked item. It turned out to be more convenient to handle t h i s kind of departure as a separate event class, d i s t i n c t from a normal departure, due to the presence of the s p e c i a l , or " c r i t i c a l " state. No c l e a r generalization has become apparent as to which method requires le s s modification to the simulation when additional animation d e t a i l i s desired. Chapter V contains further discussion of sequence types as they r e l a t e to the modelling of processes other than queuing network simulations. 28 2.3.2 Internal Cycles As explained i n the previous section, i t i s not possible f o r the animation routines to process an event at the time i t occurs i n the simulation. Instead, the simulation routine must proceed u n t i l a s u f f i c i e n t number of events have happened, and then step and pass centre! to an " E d i t " routine, The E d i t r o u t i n e e d i t s the event l i s t produced by the simulation, c a l c u l a t i n g the animation time and duration for each event, and passes what i s now c a l l e d the "sequence l i s t " to a t h i r d routine which a c t u a l l y compiles the display programs and sends them to the graphics computer over a high speed channel. This.three- step process, c a l l e d the " i n t e r n a l c y c l e " , then repeats i t s e l f by returning c o n t r o l to the simulation routine (see figure 6). The i n t e r n a l cycle approach i s f e a s i b l e only because the display r 1 I r G r a p h i c s ConDute r SIMULATE I E v e n t ' L i s t j D i s p l a y I P r o g r a m ^ L _ _ _ J L •COMP I LE E D I T S e a u e n c e ] L i s t M a i n C o m p u t e r FIG08E 6: The Internal Cycle 29 of seguences by the graphics computer proceeds independently of the computation i n the main computer (Section 2.4.2). Of course, the problem of co-ordinating the timing of the seguences i n order to provide a smooth, accurate display i s s t i l l a d i f f i c u l t one. He see below how t h i s problem i s related to the l e v e l of user i n t e r a c t i o n with the simulation. There are two ways in which the simulation can terminate. &n upper l i m i t i s imposed by the user on certain simulation variables such as the clock, the number of a r r i v a l s , and the number of terminations (departures from the system). If the user chooses to simulate without the animation, the simulation w i l l proceed u n t i l i t reaches one of these l i m i t s . at that point i t w i l l terminate, and a s p e c i a l routine i s c a l l e d to scan the data base and display the current state. However, i f the user i s monitoring an animation, he may wish to interrupt the simulation a f t e r he has seen enough. This interrupt i s discovered by the program between i n t e r n a l cycles, suggesting that the number of events processed i n one cycle be kept as small as possible. In t h i s way, the user w i l l achieve a response to his interrupt within a reasonable time and the lag between the simulation and the animation w i l l be kept to a minimum. The "length" of the int e r n a l cycle must not be too short, however, or the continuity of the display w i l l be disrupted. B a s i c a l l y , the simulation must generate enough animation 30 sequences i n order to provide a display which l a s t s long enough on the screen to allow the next cycle time to prepare the subsequent display. Several factors influence the length of the display. For a given i n t e r n a l cycle length, the duration of the display depends b a s i c a l l y on the proportion of binding sequences generated, the user-controlled duration parameters (for each type of sequence), and a time conversion factor described in Section 2.4.2. Oser control of these parameters, and of the length of the i n t e r n a l cycle, i s discussed i n Section 3.1.2. (The simulation routine measures the cycle length by estimating the number of sequences that w i l l be generated from the event l i s t being produced.) 2» 3«3_|diting_thg_|Yent_List The Edit routine must accomplish two things. F i r s t , as mentioned e a r l i e r , i t must create a sequence l i s t with animation times from an event l i s t with simulation times. Second, together with the Compile routine, i t must coordinate the timing of the new sequence l i s t with that of the previous sequence l i s t and the following sequence l i s t . The f i r s t objective i s a matter of analyzing each event in order to determine whether i t i s a bound of a sequence and to determine the type of the sequence. Whenever the event that bounds a ri g h t - s i d e bounded sequence i s found, the time of the event i s moved up and a duration a t t r i b u t e i s assigned in such a 31 way that the sequence w i l l end exactly when i t i s supposed to, i . e . at the bound. Left-side bounded sequences only have a duration assigned. Two-side bounded sequences could be handled by deleting the ri g h t - s i d e bound and assigning to the l e f t - s i d e bound a duration equal to the time delay between the two events. In t h i s way, the event l i s t i s transformed into a sequence l i s t where each sequence has two time att r i b u t e s , i t s starting time and i t s duration. The Compile routine uses t h i s information both to compile the moving sequences and also to compile any necessary instantaneous sequences which must occur at the beginning or at the end of a moving sequence. Several problems are encountered in the process of edit i n g the event l i s t . The f i r s t one has to do with the in s e r t i o n of binding sequences and th e i r e f f e c t on the timing of the rest of the sequences. The solution requires the Edit routine to make two main passes through the event l i s t . The f i r s t pass takes care of events which do not reguire binding sequences (as described above) . When the second pass encounters an event that does require a binding sequence, two things must be done. The st a r t i n g times of a l l sequences which begin a f t e r the s t a r t of the binding sequence must be incremented by the duration of the binding sequence. In other words, the time scale i s expanded by the i n s e r t i o n of the binding sequence. Secondly, sequences which begin before the star t of the binding sequence, and overlap i t due to the i r duration a t t r i b u t e s , must be processed as follows: right-side bounded sequences must have t h e i r 32 s t a r t i n g times incremented by the duration of the binding sequence, and two-side bounded sequences must have t h e i r durations extended by the duration of the binding sequence. This procedure allows the display of an instantaneous event as a moving seguence while preserving a l l time relationships between i t and the other events. A second problem with the editing process involves coordination between i n t e r n a l cycles. If an event which requires an rig h t - s i d e bounded seguence i s found very near the beginning of the cycle, the edit procedure may assign i t a s t a r t i n g time i n the range already processed by the previous cycle. Hore seriously, the right-side bound of a two-side bounded sequence may very l i k e l y not be i n the same cycle as the l e f t - s i d e bound. The general coordination problem i s handled by dividing the edited sequences into two l i s t s : one i s composed of a l l of the sequences which s t a r t in the time range which has been completely resolved, and the other, referred to as the " t a i l " of the sequence l i s t , or " t a i l l i s t " , i s composed of those sequences starting i n the time range which could be affected by the next cycle or s t a r t i n g after the l e f t bound of an unresolved two-side bounded sequence. The f i r s t l i s t i s the sequence l i s t that i s sent on to the Compile routine and displayed. The t a i l l i s t i s saved and processed with the next cycle's event l i s t . Thus i t i s a c t u a l l y possible for a cycle to produce no displayable sequences ( i . e . a l l t a i l ) , increasing the chances of a v i s i b l e lag i n the animation. It has been found in 33 ANISIM however, that the cycle lengths and durations normally used produce a t a i l l i s t of manageable porportions. If any two-side bounded seguences were to be implemented, the problem may become more complex, depending on the nature of the seguences. If the durations of such sequences are known to be r e l a t i v e l y short, then the edit process described above would be suitable. To prevent a two-side bounded sequence from requiring more than two cycles to be resolved, the cycle length would be s p e c i f i e d long enough so that the sequences generated i n any one cycle normally span a range of time that i s longer than the duration of the two-side bounded seguence. If t h i s duration i s long, however, then some other technique i s required. For example, i t may be possible to break up the sequence into two or more sequences such that the f i r s t components can be displayed before the remainder of the time span i s resolved. This method i s very dependent on the pa r t i c u l a r graphics of the sequence, and would be generally awkward for the Edit and Compile routines to process. If the duration of the sequence i s not known u n t i l the ri g h t - s i d e bound i s found, then chances are the sequence can be re-formulated to be a s p e c i a l representation of a state, which can be switched on and o f f with instantaneous sequences (e.g. blinking a blocked item u n t i l i t i s able to depart). In the case of ANISIM, the two-side bounded sequences required to implement t r a n s i t times (discussed e a r l i e r ) would probably be short enough that the entire sequence could be displayed in one cycle ( i . e . the t a i l 34 i s not resolved u n t i l the rig h t - s i d e bound i s found). 2 i4_The_Dis£lay_Process Appendix A describes the system architecture on which ANISIM was implemented. Some general discussion of display methods used however, i s necessary for f u l l y understanding the animation technique. 24,_1_The_Display Buffer B r i e f l y , the processing program, written mostly in ALGOLW and run on an IBM 370/168, makes use of a basic graphics subroutine package [6] in order to communicate with a monitor program [14] i n the Adage Graphics Computer. This graphics computer has a 6000 word buffer where a word may contain either a display vector, or a control i n s t r u c t i o n . The monitor continually scans t h i s buffer to generate a display on the Adage Model 10 Graphics Display Scope. The s i g n i f i c a n t feature of th i s graphics monitor i s that i t scans the entire display buffer at a fixed rate (40 scans per second), allowing the accurate control of the timing of animation seguences. In ANISIM, the instructions f o r the display of the network structure, and most potent i a l state representations, are contained i n a region at the top of the buffer, and thus are continuously scanned and displayed. The remainder of the buffer, during the animation phase, i s free to contain the in d i v i d u a l display £rogj:ams 35 necessary f o r each animation sequence (see next section). The dynamic loading of these display programs into the buffer i s described in Section 2.4.3. Note that t h i s scheme avoids the necessity of sending a series of "frames" (as i n movie frames) to the graphics computer, each containing an entire description of the display. Once the network has been constructed, only the descriptions of the changing components need be sent to the display buffer. Thus a much longer sequence of apparent frames may be displayed with considerably l e s s time and space required f o r the transfer. also, the c a p a b i l i t y of updating the display 40 times per second allows moving sequences of very high resolution. 2.4.2,Compiling Sequences into.Display Programs The display buffer may contain a combination of vector words and control words. One or more contiguous buffer words (properly formated by the basic graphics subroutines) may be sent to the Adage i n any one t r a n s f e r . The Compile routine thus constructs a l l the displayable sequences for a cycle i n an array and sends t h i s entire batch of small display programs to the Adage, where they are e f f e c t i v e l y executed in p a r a l l e l , much in the manner described by Baecker [ 2 ]. Several buffer control words are c r i t i c a l in making t h i s scheme work. For example, control of the scan i n any one pass i s achieved through r e l a t i v e and absolute jump i n s t r u c t i o n s . 36 Thus, the number of items appearing i n a queue i s altered merely by changing a single r e l a t i v e jump in s t r u c t i o n i n the s t a t i c region at the top of the buffer (see Figure 7). This type of instantaneous sequence can be achieved by an animation display program containing a buffer command word which moves the following buffer word (the new jump command) to a spec i f i e d location in the buffer. It i s desirable then to compile such a program that executes the move in s t r u c t i o n at exactly the ri g h t time, and only once. A l t e r n a t i v e l y , a moving sequence consists of buffer words which must begin being scanned at the proper time and continue to be scanned for a specified number of scans before they are f i n a l l y skipped again. (To move a box in a straight l i n e , the vectors f o r the box are preceded by a set of two control words for each dimension. These control words consist of a command that adjusts, by a small amount each scan, the value of the following word, which w i l l be the control word that displaces the vectors along an axis.) Therefore, either type of display program must s t a r t with a set of "timer words" which are keyed to the scan. In addition, these timer words are a l l compiled with times r e l a t i v e to the sta r t i n g time of the f i r s t sequence i n that batch to begin displaying (i.e. the e a r l i e s t sequence in the cycle). The two key control words used i n the timers each have an integer counter which i s tested at each scan and decremented i f not already zero. In one case, the following word i s skipped only i f the counter i s zero, and i n the other case i t i s skipped only 37 Buffer V/ords for One Queue (Create* When the Queue wa s Defined) 1 tern *- — 1 tern 1 — r Sequence to Display^ Owe I tern in Queue , I! I?.-; D I tern 20 111 I tern 19 T i me r Words 1QVE to QJ JUMP 5 9 } Network St ructu re J Display Programs FIGURE 7: Display Program tc A l t e r the State of a Queue 38 i f the counter i s not yet zero. In the former case, i f the following word i s a jump r e l a t i v e , the counter becomes the number of scans before a seguence begins (figure 8a). Likewise, in the l a t t e r case, the counter becomes the duration of the sequence. An instantaneous seguence ( i . e . completed i n one pass of the scanner), once i t i s allowed to execute, moves a jump r e l a t i v e on top of the f i r s t timer word in order to prohibit any subsequent execution (figure 8b). The basic animation time u n i t , then, i s always a single scan of the display buffer. This brings up one additional requirement of the Edit routine. When mapping simulation time into animation time, the speed of the display can be controlled by multiplying a l l times by a suitable "factor." This factor i s available as a system variable for both user and program control. For example, i f the factor i s set to ten, then an i n t e r v a l of eight simulation time units w i l l l a s t 80 animation time units (scans), or two seconds. The manner i n which the Compile routine procedes through the seguence l i s t , compiling each display program into an array, leads to an additional problem in the Edit routine. An e a r l i e r version of ANISIM, when editing the event l i s t , actually moved the event records around i n order to always maintain the l i s t in animation time order. In t h i s way, the t a i l could be e a s i l y determined and designated by a single pointer to the s t a r t of the t a i l . However, i t i s not uncommon for two instantaneous S t a r t i n g T i me Du r a t i o n A c t u a l S e o u e n c e S K I P n e x t w o r d a f t e r c o u n t e r r e a c h e s z e r o JUMP SKIP- n e x t w o r d un t ? 1 c o u n t e r r e a c h e s z e r o JUMP a. Timer for a Sequence With a Duration, S t a r t i n g T i m e A c t u a l S e q u e n c e SK!P nekt word a f t e r c o u n t e r r e a c h e s z e r o JUMP MOVE t h e f o i l O K i n g wo r d t c t h e S K I P w o r d l o c a t i o n JUMP b. Timer for an Instantaneous Sequence, FIGURE 8: Display Program Timer Words 40 sequences to occur at the same animation time a fact which, i n the general case, requires them to appear in the display buffer in exactly the same order as their associated events were processed i n the simulation. For example, consider a gueue/server system with a state of ten. The simulation processes both a departure from and an a r r i v a l to the system at the same time and i n that order. The state of the system should remain ten. But, due to the rig h t - s i d e bounded sequence, the Compile routine w i l l process the a r r i v a l f i r s t . The instantaneous sequence that changes the state to ten precedes in the buffer the sequence that changes the state to nine. Thus, a f t e r the scan, the state w i l l appear to be nine. The only reasonable solution was to re-write the Edit routine in order that the simulation order of events i s always maintained and only the time parameters are edited. Two passes through the l i s t are required i n order to i d e n t i f y and separate the t a i l l i s t from the sequence l i s t . 2. _.3_Dquble_ Buff er ing Once the t a i l i s determined, and the display sequences are compiled into an array, the problem remains of how to send the array to the Adage buffer and s t a r t displaying the new sequences i n perfect co-ordination with the sequences of the previous cycle. F i r s t of a l l , the available buffer space i s divided into 41 two buffers of equal length. The basic scheme i s to send up a new set of sequences as soon as the older of the two buffers f i n i s h e s i t s display. Again, t h i s scheme i s possible due to a very useful buffer control word, c a l l e d a '•Notify", which works as follows. When the Compile routine has fini s h e d preparing the new sequences i t issues a Bead operation to the Adage computer. Each buffer in the Adage has one addit i o n a l timer sequence i n i t that executes a Notify after the duration of that cycle has expired. The Notify causes the graphics monitor to issue an I/O interrupt which i n effect cancels the pending Bead from the 370. The program i s then allowed to proceed with sending the new sequences up to the Adage. I f , for some reason, the 370 had not yet issued a Bead when the Notify i s executed, the control words are set up so that the fi n i s h e d buffer w i l l continue to be scanned and thus keep issuing a Notify u n t i l i t i s successful. Now this newly loaded buffer must be co-ordinated with the sequences i n the currently displaying buffer. Consider the simple example in figure 9. The in t e r n a l cycle length i s assumed to be f i v e sequences. Suppose that cycle n i s displaying i n buffer one and cycle n+1 has just been loaded into buffer two. I n i t i a l l y , the scanner i s unconditionally branching around buffer two. Note that when the t a i l of the sequence l i s t of cycle n was determined, i t was composed of a l l sequences whose s t a r t i n g times were i n the region which might contain sequences from cycle n+1 ( i . e . sequences e and f ) . Other sequences may s t a r t before that t a i l region but overlap with i t 42 Cycle n S i mu 1 atj^on Range r ~~~ Cycl e n Ed i t Range — i — 500 - 4 - 1001 An i ma t i on T I me 600] . t.30 > 900 Cycle n+1 Edi t Range Cyc le n+1 S i m u l a t i o n Range Cyc le n Cyc le n+1 Sequence L i s t a , b , c d,e,z,f,h, i T a i l L i s t . d / C / f . j , k FIGURE 9 : B u f f e r C o - o r d i n a t i c n 43 due to t h e i r durations (seguence d). In other words, i t i s necessary for the two buffers to be displaying simultanegusly f o r a short period. This i s handled by actually including i n the t a i l the l a s t sequence which st a r t s before the " r e a l " t a i l (seguence d) . The maximum length of cycle n*s display i s assigned as i f seguence d were to be displayed in buffer one. But instead of that sequence, another seguence i s compiled to be executed at that time (time 630 i n figure 9). This special seguence removes the branch around buffer two and allows i t to begin displaying. Of course, the sequence in buffer two with a r e l a t i v e s t a r t i n g time of zero i s simply that pseudo-tail seguence (sequence d) from cycle n. Thus, buffer one and buffer two are displaying simultaneously from time 630 to time 730. At time 730, cycle n executes the Notify command, allowing the 370 to send up cycle n+2 to buffer one. The co-ordination between cycles i s now complete. The fact that the old cycle expects the new cycle to be loaded and ready to s t a r t as soon as the branch i s removed i s , i n f a c t , the reason why a lag i n the animation w i l l be seen i f the old cycle has a very short display. 2i5_The_Overall_Visual_Effect It has been shown i n t h i s chapter why i n t e r n a l cycles are necessary and how the edit procedure transforms the event l i s t into a seguence l i s t and a t a i l l i s t . The mapping of simulation time into animation time has been described, and the d e t a i l s of a c a r e f u l l y co-ordinated double buffering scheme have been 44 e x p l a i n e d f o r t h e l o a d i n g i n t o t h e g r a p h i c s computer, o f d i s p l a y programs c o m p i l e d from the sequence l i s t . The t e c h n i q u e s d e s c r i b e d i n t h i s c h a p t e r were somewhat p a i n f u l t o d e v e l o p and implement, but they a r e a c t u a l l y q u i t e l o g i c a l . The c l a s s i f i c a t i o n o f sequences and t h e e d i t p r o c e d u r e s a r e g e n e r a l enough f o r o t h e r a p p l i c a t i o n s . Many of the d i s p l a y t e c h n i q u e s a r e q u i t e dependent on t h e s p e c i f i c hardware and s o f t w a r e a v a i l a b l e , but make e f f i c i e n t use o f t h e s e r e s o u r c e s . The r e a l t e s t i s i n t h e q u a l i t y o f the a n i m a t i o n . The o v e r a l l v i s u a l e f f e c t i s q u i t e i m p r e s s i v e . The a n i m a t i o n proceeds i n a smooth, c o n t i n u o u s manner and the v i s u a l a i d s , f o r t h e most p a r t , s u c c e e d i n add i n g enough r e a l i t y t o make the s i m u l a t i o n easy and i n f o r m a t i v e t o watch (see Chapter IV) . Some problems do s t i l l e x i s t , however, w i t h t h e s e t e c h n i q u e s . C o n s i d e r the sequences g e n e r a t e d by ANISIM when a d e p a r t u r e event o c c u r s . The event i s pr o c e s s e d i n E d i t as a b i n d i n g sequence, due t o t h e d e s i r e d move from the s e r v e r t o t h e new que u e / s e r v e r system. The Compile r o u t i n e g e n e r a t e s t h a t move sequence and i f t h e queue i s not empty, i t a l s o g e n e r a t e s an i n s t a n t a n e o u s sequence to d i s p l a y the new s t a t e of the queue. T h i s method i s an a r b i t r a r y s i m p l i f i c a t i o n t h a t was d e c i d e d on e a r l y i n t h e development of t h e program. The f l o w of t h e a n i m a t i o n would l o o k even smoother and more r e a l i s t i c i f an a d d i t i o n a l b i n d i n g sequence, a move from t h e queue t o the s e r v e r , were added such t h a t i t s t a r t e d a t the same time as t h e d e p a r t u r e move s t a r t e d . Two a d d i t i o n a l i n s t a n t a n e o u s sequences 4 5 would be required to switch o f f , then on, the symbol of the item i n the server. In general, i t seems that when one event generates two moving sequences, the Ed i t routine should make a separate copy of the event record so that both the seguences can be edited independently. In t h i s case, a better solution would be to always assign a duration to the new sequence that i s less than or equal to that of the departure sequence and l e t the Compile program use the information in the single event record to generate both binding sequences at the same time. In t h i s way, the Ed i t routine can treat a l l event classes which generate binding sequences the same. This leaves the p e c u l i a r i t i e s of certa i n events to the Compile routine, which must examine the various parameters of the event record anyway. The r e a l problem i s more basic than the above si t u a t i o n indicates. In a way, the animation does c e r t a i n l y d i s t o r t the time frame of the simulation. Two events which occur within a short time of each other i n the simulation may or may not do so i n the animation, depending on how many binding seguences come between them. The time between every pair of (timewise) adjacent events remains accurate, as does the actual progression of states of the network. This type of •»distortion" r e a l l y seems to be i n s i g n i f i c a n t , then, as long as one remembers that the beginning of a binding sequence i s the "same time" as the end. It would be nice to try to reduce t h i s d i s t o r t i o n by allowing two binding sequences to have the same s t a r t i n g time i f they correspond to the same event time i n the simulation. It i s 46 easy to f i n d c e r t a i n examples, however, of s i t u a t i o n s which r e q u i r e that the E d i t r o u t i n e increment the s t a r t i n g times even of b i n d i n g seguences whose events are simultaneous with that of the b i n d i n g sequence being processed. 47 I I I . INTERACTIVE FEATURES An interactive modelling system i s of l i t t l e p r a c t i c a l use unless s p e c i a l attention i s paid to the design of the dialogue between the user and the system. According to Newman and Sproull [16], the three main q u a l i t i e s that the programmer should attempt to optimize are 1) si m p l i c i t y of operation of the program, 2) consistency, i n the o v e r a l l construction of the command language and error recovery, and 3) economy from both the user's and program*s standpoint. The following discussion of these q u a l i t i e s , and other important features of the dialogue, distinguishes between the ove r a l l system and simulation control and the actual model construction and modification. 3 1_S i m u 1 a t i o n_M o n i torina_and_Control 3» j|»l_S;stem_control ANISIM provides a simple, but effect i v e , command language for top l e v e l i n t e r a c t i o n with the system. A l l commands at t h i s l e v e l are entered on the IBM 3270 Display Terminal which i s located next to the graphics terminal. Each command i s defined e x p l i c i t l y , rather than being i m p l i c i t i n the sequence of inputs. Furthermore, i t i s easy for the programmer to add new commands to the system, although no e x t e n s i b i l i t y i s provided to the user. The objective throughout the system has been to allow 48 the user maximum freedom of control of the sequence of operations, wherever f e a s i b l e . This f l e x i b i l i t y reduces the reliance on f r u s t r a t i n g questions which must be answered by the user, but places more emphasis on error recovery when he attempts to enter inappropriate commands or data. Also, in the i n t e r e s t of s i m p l i c i t y , a minimum of information about the system or the simulation i s displayed (on either terminal) unless otherwise requested. In order to aid in achieving these objectives, the program must help keep the user aware of what operations are available and what responses are required. The HELP and MOBHELP commands, shown in figure 10, l i s t a l l available commands along with a b r i e f reminder of t h e i r use. (MOBHELP l i s t s the less frequently used commands.) In addition, default values are used whenever applicable. This i s useful i n cases where the user does not yet know what value i s appropriate (e.g. display parameters), and keeps the number of mandatory inputs to a minimum. The current value (and thus the default value) of a system or display parameter can be found by entering the appropriate command without specifying any arguments. For example, entering "CYCLE" w i l l r e s u l t i n a print out of the current values of the four l i m i t s on the simulation. The command "CYCLE * * * 100" w i l l change the l i m i t on the number of terminations to 100 and print out the four values. The PBIHT command allows a selection of 17 options f o r printing out f u l l or s p e c i f i c d e t a i l s about the state and the s t a t i s t i c s of the simulation. The TBACK command 49 # $run walk:anisim.o+dhir:camadd+agt:basic par=size=150k # EXECUTION BEGINS ARE YOU USING THE ADAGE? TRUE OR FALSE fa l s e ENTER COMMAND OR HELP help BUILD TO BUILD OR MODIFY THE ACTIVE NETWORK NEWNET TO BUILD A NEW NETWORK EDITNET TO USE BUILD FOR SMALL CHANGES TO A NETWORK GO N TO SIMULATE AND TO DISPLAY THE ACTIVE NETWORK FOR N TIME UNITS FROM CURRENT TIME FASTER TO SPEED UP THE DISPLAY SLOWER TO SLOW DOWN THE DISPLAY SCAN TO INHIBIT MOVING SEQUENCES DESPEED TO RESTORE THE DEFAULT SPEED NODISP TO INHIBIT DISPLAY UNTIL NEXT GO COMMAND RESET TO RESET SIMULATION CLOCK AND STATS SAVE TO SAVE THE NETWORK RESTORE TO RESTORE A SAVED NETWORK LABEL TO DISPLAY LABELS AT EACH NODE CYCLE TO CHANGE SIMULATION LIMITS #OF TIME UNITS, #OF GEN,#OF ENTRIES,#OF TERM PRINT I TO DUMP RESULTS, FOR CODES SEE DOCUMENT 20 GIVES STATE, 1 STATS, 13 PARAMS, 7 QSTATS, ETC MORHELP ADDITIONAL COMMANDS STOP OR END TO TERMINATE EXECUTION ENTER COMMAND OR HELP morhelp UNLABEL TO REMOVE ALL NODE LABELS FACTOR DEFAULT=10; INCREASE TO SLOW DISPLAY DECREASE ONLY IF USE RESET INTERCY DEFAULT=15; INCREASE WHEN DISPLAY IS FAST SCALE TO CHANGE THE SCALE AND 'SCALER' DUR TO CHANGE THE 4 SEQUENCE DURATIONS TRACK I TO SET DEBUG FLAGS ON. 0=<I<7, SEE DOCUMENT PLOT S TO GET A HARDCOPY OF ADAGE DISPLAY S IS MAXIMUM PLOT SIZE, IN INCHES STOP OR END TO TERMINATE EXECUTION ENTER COMMAND OR HELP stop 000.03 SECONDS IN EXECUTION # EXECUTION TERMINATED FIGURE 10: Commands Available 50 turns on one of six debug fl a g s i n the program, providing detailed traces of the simulation, edit, and compile routines. In the case of both PRINT and TRACK, an optional second argument can be used to route the output to a disk f i l e of the user's choice. Most top-level commands reguire no further response from the user. The exceptions to t h i s are the BUILD, NEWNET, and EDITNET commands, which envoke an e n t i r e l y new dialogue (section 3.2), and the SAVE, RESTORE, PRINT, and TRACK commands, which may require further c l a r i f i c a t i o n of f i l e - h a n d l i n g operations. For example, i f the user t e l l s the program to "SAVE NET1", and the f i l e NET1 already exists, then the program must ask the user i f i t i s a l r i g h t to empty the f i l e and store the current network on i t . The user may also return temporarily to the MTS operating system by issuing an attention interrupt. At t h i s point he has f u l l access to any disk f i l e s created by the program, as well as run-time s t a t i s t i c s . The ANISIM program may then be re-entered, using the MTS SRESTART command. S»j»2_Simulation_Monitoring Two of the most important advantages of an i n t e r a c t i v e graphics system are the f a s t turnaround and the immediate graphical display of complex information. Smith [22] l i s t s as an equally important advantage the c a p a b i l i t y to allow the user to try "various attacks" on a p a r t i c u l a r problem during a single 51 session with the computer, with ANISIM, thi s can be interpreted i n two ways. The user should be able to quickly simulate several versions of a model, and he should be able to view the r e s u l t s of a simulation in several d i f f e r e n t ways. The f i r s t goal requires not only the c a p a b i l i t y to e d i t the model structure and parameters, but also quick access to the description of such information. It may be possible to display a l l of the d e t a i l s of the model on the screen, including rates, capacities, and routing data. This, however, would not be desirable, both from a s i m p l i c i t y and an economy point of view. It i s instead desirable to keep a minimum of information on the screen and make other data available on demand. For example, f o r each symbol i n the network, a l a b e l i s created i n t e r n a l l y . At present, a l l s t a t i s t i c s are printed on the 3270 terminal and the labels are used to reference s p e c i f i c simulation e n t i t i e s . The user, i n order to interpret these s t a t i s t i c s , can use the LABEL command to actually display the labels at each symbol (see figure 11). The labels are automatically removed during the building or animating of the model, to save space in the Adage buffer. Other information available on demand includes the rate and capacity parameters, obtained by the PRINT 13 command. The display of routing assignments poses some d i f f i c u l t problems and has not yet been attempted. The user should try to construct the network so that i t s graphical representation conveys much of the routing information. Section 3.2 describes an additional access to current parameters while actually e d i t i n g the network. S03 502 501 •SV3J FIGURE 11: Labelled E n t i t i e s 53 The second goal cited above—that of providing several ways of analysing the output of the simulation—has been met to a c e r t a i n extent. A NODISP command, given before st a r t i n g the simulation (with the GO command), allows the simulation to proceed quickly with no animation. This i s useful when i t i s desired to watch the animation a f t e r the model has advanced to a more steady state. The user i s not required i n t h i s case to watch the animation from the beginning. Whenever the simulation stops, the current state i s displayed and the PRINT command may be used to find certain standard s t a t i s t i c s such as the average and maximum gueue lengths and buffer sizes, the average time-in- system of items between source-sink pairs, and the number of a r r i v a l s and terminations at each source and sink. Blocked items are an important aspect of gueuing networks. An extended version of ANISIM might allow several options for the handling of blocked a r r i v a l s and departures. The e x i s t i n g protocol i s that blocked a r r i v a l s are l o s t (they move halfway to the gueue and disappear) and blocked departures remain i n the server and attempt to depart again after waiting the user-defined "re-send time". Thus, s t a t i s t i c s must also be available giving the number of l o s t a r r i v a l s and the number of blocked departures. The RESET command i s used to set the clock to zero, reset a l l s t a t i s t i c s , and restore the i n i t i a l random number seeds. If NODISP i s not s p e c i f i e d , then the animation w i l l automatically accompany the simulation, providing additional valuable information about the model. Two areas of in t e r a c t i o n 54 are e s s e n t i a l i n order to help the user monitor the animation: specifying how much to display, and how long to display i t . From any p a r t i c u l a r state, the length of the simulation can be controlled i n one of three ways. I f the GO command i s given without the argument, the simulation w i l l proceed either u n t i l one of the l i m i t s i n the CYCLE command i s exceeded or u n t i l the user h i t s the attention i n t e r r u p t . If the argument i s given, then i t s value i s the number of time units for which the simulation i s to proceed, provided no cycle l i m i t i s exceeded or interrupt issued. If the user wishes to monitor the simulation, not in d e t a i l , but to get a general f e e l for the progression of states of the model, then he may use the SCAN command. This command i n h i b i t s moving seguences by making a l l durations zero. Thus, the animation time frame i s not expanded by binding seguences, res u l t i n g i n a considerably faster display of events. (The factor i s also decreased and the i n t e r n a l cycle i s made longer, as discussed i n Chapter II.) The SCAN mode i s s l i g h t l y less pleasing to watch, but provides a quick, clear way of observing the general trends of the model. I t i s esp e c i a l l y useful i n a model that would, otherwise, slowly build up to a congested state. The following special state representations are also envoked by instantaneous sequences and thus appear in SCAN mode: the blinking of a f u l l queue or buffer due to an item attempting to get i n , and the blinking of a blocked item with an arrow attached which points to the f u l l queue or buffer (see figure 55 12} . Moving sequences, although a r t i f i c i a l , provide valuable v i s u a l continuity between states. The user has access to the basic variables which control the speed of the display and of each sequence. B r i e f l y , the DDR command controls the duration of each type of sequence, the FACTOR command controls the time conversion factor explained i n section 2.4.2, and the INTERCY command controls the length of the in t e r n a l cycle (i.e. the number of seguences generated each c y c l e ) . For example, the DUR command may be used to shorten the duration of binding sequences with respect to the other sequences. The inexperienced user should not have to use FACTOR to control the speed of the animation, for two reasons: 1) i t i s not always clear how to adjust the int e r n a l cycle length (INTERCY) to compensate for the change i n speed, and 2) i f the simulation i s not RESET, the t a i l of the sequence l i s t using the old factor w i l l no longer be coordinated with the new sequence l i s t . Thus, ANISIM provides a set of "speed" commands which make the necessary changes for a smooth t r a n s i t i o n to a faster or slower speed. Ba s i c a l l y , a set of seven standard speeds are available, three slower than the default and three f a s t e r . No provision has been made to store animation sequences on disk for l a t e r viewing without simulating, as in DYNIS [20]. This would probably be more expensive than re-simulating the saved model. One feature that can aid in the quick re-creation 56 -o FIGURE 12: Display cf Blocked Items 57 of a previously displayed sequence, as well as provide a powerful design t o o l , i s the a b i l i t y to save and restore a simulation state. In th i s way, the modeller can simulate forward from a given state several times, experimenting with various parameter values. Extensions which would provide additional ways of analysing simulation r e s u l t s are discussed i n Chapter V. 3.2 Model Design and Modification The BUILD, NEWNET, and EDITNET commands a l l cause the program to enter a d i s t i n c t phase with a dialogue of i t s own for constructing or modifying a network. A l l three commands envoke the same routine, although EDITNET appears somewhat d i f f e r e n t to the user, due to the setting of an "edi t f l a g " i n the program. Only NEWNET w i l l destroy any exist i n g active network (i.e. a RESTORE* d or newly constructed network) before proceeding. Otherwise, BUILD and NEWNET are i d e n t i c a l . A considerable amount of information must be provided to the system i n the network d e f i n i t i o n phase. It i s here that the quality of the dialogue becomes very important. The task of entering input must not become awkward and tedious and a trade- o f f must be made between allowing the user to decide what to input or leading him through a fixed sequence of inputs to 58 ensure a properly defined mode. Also, i t i s important to provide feedback to the user i n order that he may v e r i f y what has been entered. Opon entry into the build phase, then, a l i s t of possible commands, or "modes", are displayed on the graphics scope in the recommended order of use (when building a new network). This l i s t (see figure 13) i s cal l e d a "MENU", and the prompting message "MODE?" i s actually blinking in order to indicate to the user that i t i s time to select a mode by pointing to i t s name with the lightpen. At t h i s point the user s t i l l has freedom of control . He may enter or re-enter any mode at any time. Smith [22] c a l l s t h i s " i n t e r a c t i o n by an t i c i p a t i o n " , i n the sense that a l l possible desires of a user are anticipated. These p o s s i b i l i t i e s are presented as choices for the user to select rather than specify;, thereby allowing a simple lightpen h i t rather than reguiring a c o r r e c t l y spelled alphabetic command. On any given entry into the build phase, the program helps the user remember which modes he has already entered by displaying these names at a di f f e r e n t i ntensity. A further convenience i s that the user may position the menu anywhere on the screen, using a pair of d i a l s . The important thing i s that the modes break up a lengthy task into easier, d i s t i n c t subtasks. In his book, Design of Man-Computer Dialogues , Martin [13] states that short-term memory i s heavily u t i l i z e d i n complex problem solving and creation. He further states that humans SYMBOLS LINKS ASSIGNQ FIRST QUEUES ASSIGN BUFF ROUTES CAPACITIES FLOW SERVICE TIMES DONE FIGURE 13: Menu for Network Design 60 tend to organize a c t i v i t y into "clumps" that can be ea s i l y completed. Thus, the modes i n ANISIM are designed so that the user need only worry about a f a i r l y simple or d i s t i n c t aspect of the network at one time. In f a c t , when building a new network, the modes act as a se r i e s of Martin's "conversational checkpoints". The termination of a mode can be regarded as providing "mental c l o s u r e " — i . e . the user can assure himself that he has completed that phase of the input. If he gets confused or makes a mistake, he need only re-enter the current mode and s t a r t over from that point. When working i n a p a r t i c u l a r mode, the user s t i l l might forget what i s expected of him next,- or even which mode he i s i n , i f he i s at a l l distracted. To avoid t h i s s i t u a t i o n , the program always prompts the user with some kind of mental cue whenever a response i s expected. This prompt, often a one or two word message displayed at the bottom of the screen, serves only as a reminder rather than a detailed explanation. The blinking of symbols i s used to s i g n i f y which p a r t i c u l a r e n t i t i e s of the network are in question. Proceeding through the menu, then, a t y p i c a l dialogue would begin by entering the SYMBOLS mode. The menu disappears (as in a l l modes) and crosshairs appear. The crosshairs and a set of function buttons are used to position and select any one of the f i v e available symbols. An entry (ALGOLW record) i s created in the data base for the corresponding simulation entity. Two 61 symbols require in t e r a c t i o n beyond the i n i t i a l s e l e c t i o n : queues require a second crosshair s e t t i n g to define the orientation (angle) of the t a i l of the queue (see figure 14), and buffers are usually sketched, although a default i s available. Figure 15 shows a buffer symbol being sketched around two queues which w i l l l a t e r be assigned to the buffer entity. The lightpen may be used i n SYMBOLS mode in order to delete a symbol or a " l i n k " from the screen and the data base. A s p e c i a l function button terminates SYMBOLS mode, causing the re-appearance of the menu. LINKS mode allows the user to use the lightpen to connect pairs of symbols. These l i n e s are v i s u a l aids to help portray the network structure, but no entry i s made i n the data base. Also, the i n t e n s i t y of the l i n k s i s separate from the rest of the network and can be turned down by the twist of a d i a l . The mode i s terminated by a lightpen h i t on the prompting message. The next four modes (ASSIGNQ, FIRST QUEUES, ASSIGN BUFF, and ROUTES) are necessary to make a series of assignments of simulation e n t i t i e s that define the structure of the network. In each case, both the programmer and the user distinguish these e n t i t i e s graphically, rather than try i n g to refer to them by labels or entering numbers in matrix form. The advantage of t h i s approach i s that the user can actually "see what he i s doing." There i s no problem of i d e n t i f y i n g labels or numbers with symbols. For example, i n ASSIGNQ, the program goes through the l i s t of servers that has been created and for each server, blinks the symbol and prompts the user to designate a gueue. o 62 o T A I L ORIENTATION ? FIGUfils 14: Specifying Queues FIGURE 15: Buffer Sketching 64 The user need only point with the lightpen to the gueue he wishes to be assigned to the blinking server. Clearly at t h i s point i t i s advantageous to lead the user through a l l possible assignments i n order that none are l e f t out. This policy i s followed i n a l l the remaining modes as well. when the edit f l a g i s set, however, i t i s assumed that a l l assignments have been made once already, and that the user wishes to change one or two assignments only. In t h i s case, he must select with the lightpen a server, i n the example of ASSIGNQ, before the program w i l l prompt for a gueue. He may proceed to s e l e c t other servers or terminate the mode by h i t t i n g the prompting message. In the same manner, FIRST QUEUES i s used to assign a unique queue/server system to each source, and ASSIGN BUFF i s used to assign buffers to queues. ANISIM currently provides one form of r o u t i n g — a fixed routing scheme, although other schemes are possible (see Chapter V). Each item i s assigned a destination sink when i t i s generated at the source. At any p a r t i c u l a r queue/server system, the next queue/server system (or sink) i n the route i s dependent only upon t h i s destination. Thus, i n ROUTES mode, the user f i l l s an i n t e r n a l routing matrix by pointing to the next queue (or the sink) for each blinking queue-sink pai r . The f i n a l three modes require user input on the 3270 terminal. Newman and Sproull [16] advise that, i n general, a single-device approach often leads to simpler, more e a s i l y 65 learned command languages. However, in t h i s case i t was decided that i t would be easier for the user to switch from the lightpen to the keyboard than i t would be to enter numerical data at the graphics terminal. also, the 3270 screen o f f e r s the opportunity to e a s i l y display more detailed prompting messages, whereas the graphics approach would require valuable Adage buffer space. Figure 16 shows an example of the dialogue on the 3270. Of course, the program s t i l l designates e n t i t i e s by blinking symbols on the Adage display. The Adage scope prompt message of "TO 3270—>" reminds the user that his next response w i l l be at the keyboard. CAPACITIES mode allows the assignment of queue and buffer capacities other than the defaults. In FLOW mode, for each source, the i n t e r - a r r i v a l time d i s t r i b u t i o n i s sp e c i f i e d (similar to the service times dialogue), and also the percentage of a r r i v a l s from that source that are destined for each sink must be given, in order to f i l l i n an in t e r n a l "flow" matrix. In any mode requesting parameters, i f the edi t f l a g i s on, the current value of the parameter i s f i r s t printed on the 3270. If the edi t f l a g i s not on, the current value i s printed only for those parameters which are i n i t i a l l y assigned default values (e.g. queue c a p a c i t i e s ) . 3i2_.2_Model_Verif i c a t i o n The network construction dialogue, as mentioned e a r l i e r . FOR THE BLINKING SERVER, ASSIGN THE SERVICE DISTRIBUTION CODE: 1= EXPONENTIAL, 2 = DNIFOR M 1 ENTER MEAN TIME ( > 1) FOR EXP. DSTBN ENTER RE-SEND TIME FOR BLOCKED ITEMS FROM THIS NODE ELSE DEFAULT VALUE IS 4 2 DISTRIBUTION CODE (1 OR 2): 1 ENTER MEAN TIME ( > 1) FOR EXP. DSTBN 7 ENTER RE-SEND TIME FOR BLOCKED ITEMS FROM THIS NODE ELSE DEFAULT VALUE IS 7 1 DISTRIBUTION CODE (1 OR 2): 2 ENTER MEAN TIME (>1) AND DEVIATION FOR UNIFORM DISTR. *» 5 DEVIATION IS TOO LARGE. TRY AGAIN. ENTER MEAN TIME (>1) AND DEVIATION FOR UNIFORM DISTR. 4 2 ENTER RE-SEND TIME FOR BLOCKED ITEMS FROM THIS NODE ELSE DEFAULT VALUE IS 4 BACK TO ADAGE FIGURE 16: Dialogue f o r Specifying Service Times 67 uses a menu to guide the user through the necessary steps of making a well-defined model, while allowing him s u f f i c i e n t freedom of con t r o l . In other words, i t i s s t i l l quite possible to create a network with missing assignments and parameters— e s p e c i a l l y after editing the network. This problem i s attacked i n several ways, F i r s t of a l l , when the user f a i l s to h i t the proper type of symbol with the lightpen, the message "NO ASSIGNMENT" appears on the screen b r i e f l y . Also, the user i s asked to re-enter any numerical information that i s not in the proper range such as a deviation that i s greater than the mean f o r the uniform d i s t r i b u t i o n . After exit i n g from the build phase and before a new simulation i s allowed to begin, a l l servers and sources are checked to make sure then have been assigned a queue (in order to prevent a terminating error in the simulation program). The routing assignments are not checked at this time, but any undefined routes w i l l be caught i n the simulation. In that case, the item i s sent to i t s destination sink, a message i s printed on the 3270, and the simulation i s allowed to continue. The DYNIS system [20] makes use of yet another method of reducing errors due to careless modification of the o r i g i n a l model. I t s editing phase i s divided into two commands: REVISE and MODIFY. Their related functions in ANISIM might be as follows: REVISE would allow the user to add or delete symbols, analyze the e f f e c t s of t h i s change, and then prompt him to re-enter any modes necessary i n order to make the network well-defined again. MODIFY on the other hand, would 68 allow only the a l t e r i n g of parameter values, none of which could make the network i l l - d e f i n e d . MODIFY would be more economical for the user (quick, safe changes; minimal dialogue), and also f o r the program (abbreviated menu; less checking and prompting.) This approach would in f a c t be f e a s i b l e i n AHISIM, using the basic BUILD-EDITNET structure. Once we have insured that the model i s well-defined, there s t i l l remains the p o s s i b i l i t y that a mistake has been made in the model design, i . e . the model b u i l t i s not exactly the model intended. However, compared to any non-graphical simulation environment, t h i s p o s s i b i l i t y i s minimal. F i r s t of a l l , the modeller can see on the screen the effects of much of what he does. Also, he i s less l i k e l y to specify a wrong entity when he can actually point to i t s representation on the screen. Furthermore, assignment and parameter information can be v e r i f i e d by using the PRINT command, and the animation i t s e l f should expose most unintended routing s p e c i f i c a t i o n s . On the other hand, anyone who has written a non-trival simulation program i n a language such as GPSS [ 9 ] knows that the structrue of the model may e a s i l y become obscured i n the program statements and matrices. The input data i s l a r g e l y numerical and highly subject to mistakes as well. A second side e f f e c t of a graphically described a model, especially i n an i n t e r a c t i v e environment that helps the modeller create a well-defined model, i s that the process of building the 69 network may very well force the modeller to re-evaluate his conception of the model. To some extent he may more quickly see the inadequacies of his i n i t i a l formulation as a v a l i d abstraction of the real-world s i t u a t i o n . Bracchi and Somalvico [3] emphasize that a software system for computer-aided design should provide both a strong computational c a p a b i l i t y and a f l e x i b l e i n t e r a c t i o n with the designer during the design process. Likewise, ANISIM's usefulness as a simulation t o o l depends both on the power of the simulation routine and the quality of the user dialogue. The f i r s t part of t h i s chapter described the techniques used to provide simple, yet f l e x i b l e control over the simulation and the presentation of i t s r e s u l t s . Moreover, experience with users during the development of the preliminary versions of ANISIH has indicated that the quality of the network d e f i n i t i o n dialoque i s c r i t i c a l to insuring that the user w i l l have a successful session with the system. It i s t h i s phase where a large amount of information must be supplied to the system by a person who may be nervous, confused, or intimidated by conversations with machines. If the dialogue i s awkward or otherwise inadequate, the user i s not free to concentrate on such things as evaluating the conceptual v a l i d i t y of his model or v e r i f y i n g the accuracy of the network he i s building. There w i l l always be room for improvements i n the dialogue, but the current version of ANISIM seems to meet most of the c r i t e r i a for a smooth and e f f e c t i v e i n t e r a c t i o n . 70 IV UTILITY OF ANIMATION One of the points that Martin [13] makes about graphic systems, i s that the use of moving or changing images can c l a r i f y c e r t a i n ideas. Animation, l i k e color, i s a type of encoding that can increase the amount of information the limited human mind can grasp and ponder at one time. A reasonable guestion to ask, then, i s when and how should we use animation i n order to best take advantage of t h i s c a p a b i l i t y . 4 J_S imulation_Tool T r a d i t i o n a l simulation programs generally produce output in the form of s t a t i s t i c a l averages, variances, maxima, etc. They are generally expensive to execute and are often run i n a batch environment. Model design and testing i s done by analyzing the s t a t i s t i c s , a l t e r i n g the model or i t s parameters, re-compiling i f necessary, and then running the program again. Clearly, an i n t e r a c t i v e simulation program could improve t h i s turn-around time by producing r e s u l t s quickly (while the modeller s t i l l remembers what he was trying to do) and by providing convenient means f o r a l t e r i n g the model. This i s true, provided that the modeller can also analyze the simulation output quickly. I f he i s looking for the changes that appear i n a few simple s t a t i s t i c s , the improved turn-around may be s u f f i c i e n t for his purpose. However, i f he i s trying to understand the significance of the s t a t i s t i c s with respect to a f a i r l y complex 71 model, the program must provide him with additional aids. One such aid avai l a b l e i n an interactive environment i s a monitoring c a p a b i l i t y . The modeller not only gets the f i n a l r e s u l t s , but he sees some sort of representation of the state of the model while the simulation i s progressing. This may allow the modeller to quickly zero-in on the time range or parameter range that he i s interested i n , as well as providing information about the starting conditions and other transient e f f e c t s . Alos, monitoring i s l i k e l y to provide more information about the behavior of the model when i t reaches certain c r i t i c a l states. One simulation monitor system that has proven quite useful f o r e c o l o g i c a l models i s SIHCON—a Simulation Control Command Language [ 1 0 ] , SIMCON allows the user to plot during execution selected variables of a simulation program written i n FORTRAN. He may interrupt the simulation and display or a l t e r variables, and he may r e s t a r t the simulation from several states. Thus, i n many cases, a model can be adequately represented, for monitoring purposes, by l i n e plots of the le v e l s of certa i n e n t i t i e s (such as populations). In other cases, however, the r e a l understanding of the model l i e s not i n monitoring the value of a variable (or the length of a queue), but monitoring a process or rel a t i o n s h i p that determines the value of the variable. An example of a continuous simulation model where t h i s would be true might be a study of changing boundaries between several t e r r i t o r i a l populations. The simulation 72 s t a t i s t i c s may begin to make sense i f the modeller can a c t u a l l y see on a graphics screen a population being crowded out of existance by neighboring populations. S i m i l a r l y , a gueue that becomes too long may be analyzed by monitoring an animation showing just where the items are a r r i v i n g from and where (and when) they are going next. Without some movement of items between e n t i t i e s , the viewer, i n Martin's terminology, i s unable to keep enough information about the r e l a t i v e states of these e n t i t i e s i n the 'foreground* of his mind a l l at the same time. This issue of movement brings up an i n t e r e s t i n g point about ANISIM. When we think of the system being modelled as a gueuing network, then animating with moving sequences can be thought of as d i s t o r t i n g the m o d e l — p a r t i c u l a r l y with respect to the expansion of time caused by binding seguences. But i f we think of the system being modelled as some real-world system that i s only approximated by a queuing network, then animating with moving sequences can be thought of as restoring some r e a l i t y to the model. The user of ANISIM can use the SCAN mode for a true representation of the gueuing network, but he does not have the benefit of that extra information provided by movement. Or, he can se l e c t varying degrees of d i s t o r t i o n / r e a l i t y by c o n t r o l l i n g the durations of the moving sequences. In either case, animation techniques can at least be used to represent the progression of states, to show the changing i n t e r r e l a t i o n s h i p s amongst model components, and to signal the occurrence of c r i t i c a l states. 73 The concept of allowing the model designer optional degrees of " r e a l i t y " i s not unique to ANISIM. An i n t e r a c t i v e graphics system developed at IBM for designing and testing l o g i c c i r c u i t s allows the user to specify one of three modelling abstractions regarding the timing of pulses [13], The trade-off i s between a fa s t approximation and a slower, more r e a l i s t i c simulation. In t h i s case, however, i t i s the actual simulation that i s affected, not just the graphic representation, as in ANISIM. The ATOPPS system [5] discussed in the next section, i s an example of a discrete event simulation monitor which makes i t s point graphically without making any attempt to r e a l i s t i c a l l y model the timing between events. ii2_Educational_Tool I f the use of animation provides additional insight into the understanding of a complex process, then c e r t a i n l y i t i s desirable to apply t h i s c a p a b i l i t y toward educational purposes. This generally means placing less of the emphasis in the graphics system on a f l e x i b l e design optimization approach and placing more emphasis on c a r e f u l l y i l l u s t r a t i n g the process or reaction that i s of inte r e s t . In f a c t , i t may be reasonable i n some cases to exaggerate the more d i f f i c u l t features at the expense of the o v e r a l l accuracy of the animation. For example, the ATOPPS system [14] at Pennsylvania State 74 University i s presented as a "Computer Graphic Simulation of a Discrete Time Operating System for Introducing Elementary Concepts". Films have been made of the system, which displays the contents of the memory, active hardware, and major gueues of a t h e o r e t i c a l operating system. The objective i s to watch the flow of information from one job step to another in the discrete time simulation of d i f f e r e n t operating system configurations. The model appears to be f a i r l y simple, but allows enough s t r u c t u r a l and parameter options to demonstrate many of the important p r i n c i p l e s of operating system strategies. The graphic technigue does not involve animation i n the sense of elements moving on the screen. Instead, arrows and intensity are used to c a l l the viewer's attention to (and to further explain) each change of state. The state of each entity (e.g. a queue) i s described by a number rather than a symbol. The most signigicant difference between ATOPPS and ANISIM i s the manner i n which they graphically represent the timing of discrete events. ATOPPS makes no attempt to depict p a r a l l e l processes or the elapsed time between successive events. Instead, the clock time i s always shown and when an event has been displayed the clock i s updated to the time of the next event, which i s immediately displayed. In other words, a l l state changes bind the display, while they are represented i n some d e t a i l . To help the viewer understand the i n t e r - r e l a t i o n s h i p of events, the future events gueue i s displayed on the screen, allowing one to see exactly when and why each event i s scheduled during the 75 processing of the current event. This approach seems guite reasonable for the stated objective of understanding basic operating system p r i n c i p l e s . The emphasis i s on the detailed display of each event rather than an accurate o v e r a l l display of the performance of the model. ANISIH, on the other hand, has considerable potential as an educational t o o l , but in a s l i g h t l y d i f f e r e n t sense. I t would not be p a r t i c u l a r l y i n s t r u c t i v e to show how an a r r i v a l event causes a new a r r i v a l event to be scheduled and put i n the future events queue. It would, however, be useful i n demonstrating certa i n concepts of queuing theory which are based heavily on timing parameters. For example, a student trying to understand how the rela t i o n s h i p between the a r r i v a l rate and the service rate affect the queue length might benefit by watching an animation of a simple queue with various parameters. Another simple example would be the comparison of two one-server queues with one two-server queue (see Figure 17). If the service d i s t r i b u t i o n s have a large variance, the student can see how items tend to t r a v e l faster through the two-server system. one problem with demonstrating t h e o r e t i c a l r e s u l t s i s that they are based on steady state p r o b a b i l i t i e s . Monitoring the simulation at any particular period of time (especially the beginning) provides no guarantee that the state w i l l be anywhere near that s p e c i f i e d by the long term p r o b a b i l i t i e s . Of course the s t a t i s t i c a l summary i s s t i l l available a f t e r stopping the simulation. 76 FIGURE .17: Queuing Theory Comparison 77 i i J_Research_Tool One of the o r i g i n a l motivations for developing ANISIM was to study, i n a general way, the processes or conditions which lead to network congestion and system deadlock. It has already been pointed out how ANISIM can be used to design or optimize a s p e c i f i c model to avoid undesirable states. S p e c i f i c a l l y , the animation allows the modeller to watch the chain of events leading up to the c r i t i c a l state. However, perhaps the animation can add a d d i t i o n a l i n s i g h t to current research on the t h e o r e t i c a l aspects of deadlock. ANISIM can be used to construct and modify networks which, when simulated, a) lead to blocking conditions (see Figure 12 in Chapter I I I ) , b) become congested (gueues or buffers f i l l up from time to time but always eventually unblock), or c) reach deadlock (two or more items are mutually permanently blocked). One example of a simple two-node deadlock appears i n Figure 18. The more complicated network shown in Figure 19 i s deadlocked between the f i r s t two buffers, causing congestion i n the rest of the network. Time has not permitted the experimentation necessary in order to investigate the p r i n c i p l e s behind deadlock. A survey by Coffman, et a l [5], describes various strategies for dealing with the prevention, detection (and recovery), and avoidance of deadlocks. The discussion i s oriented towards operating systems design, dealing i n terms of tasks and resources, but would I H H U ' I I I I H I I imiiuii FIGURE 18: Simple Deadlock FIGURE 19: A P a r t i a l l y Deadlocked Network 80 p r o v i d e an e x c e l l e n t s t a r t i n g p o i n t on w h i c h t o b a s e e x p e r i m e n t a t i o n w i t h A N I S I M . 8 1 V CONCLUSIONS, PROSPECTS, AND EXTENSIONS 5 i l _ A n a l _ ; s i s I t must be emphasized at t h i s p o i n t t h a t ANISIM, i n i t s c u r r e n t form, can o n l y be thought of as a r e s e a r c h t o o l , and not as a f i n i s h e d p r o d u c t . I t has c l e a r l y demonstrated t h a t a n i m a t i o n can p l a y a v e r y p o w e r f u l and u s e f u l p a r t i n d i s c r e t e event s i m u l a t i o n m o d e l l i n g . H o p e f u l l y , f u t u r e a t t e m p t s a t such systems can b e n e f i t p a r t i c u l a r l y from t h e c l a s s i f i c a t i o n of sequences and from t h e event e d i t i n g p r o c e d u r e s of Chapter I I . Much o f t h e i n i t i a l e f f o r t i n implementing ANISIM went i n t o d e v e l o p i n g the s i m u l a t i o n and a n i m a t i o n t e c h n i q u e s . The system more or l e s s e v o l v e d as i t s c a p a b i l i t i e s became ap p a r e n t , r e s u l t i n g i n two g e n e r a l problems. The f i r s t problem c o n c e r n s t h e i d e a l o g u e . M a r t i n [13], i n h i s s u r v e y o f methods, f e a t u r e s , and p s y c h o l o g i c a l c o n s i d e r a t i o n s o f man-machine d i a l o g u e , emphasizes t h e need f o r comprehensive p l a n n i n g o f the d i a l o g u e b e f o r e programming b e g i n s . Such p l a n n i n g , i n t h e case of ANISIM, c o u l d have eased t h e programming t a s k , p a r t i c u l a r l y w i t h r e s p e c t t o p r o v i d i n g s i m p l e , u n i f o r m e r r o r r e c o v e r y p r o c e d u r e s . The second problem w i t h t h e l a c k of o v e r a l l p l a n a t t h e b e g i n n i n g i s t h a t not enough p r o v i s i o n can be made to e a s i l y handle e x t e n s i o n s and r e f i n e m e n t s . For example, i n ANISIM, as i n most g r a p h i c s systems, the d a t a s t r u c t u r e i s a c c e s s e d from j u s t about every phase of t h e program. R e p e r c u s s i o n s of any 82 changes to the structure or to the information stored i n i t tend to r i p p l e throughout the program. In concentrating on the needs of the animation routines while coding the simulation routine, some basic features were overlooked, such as the gathering of c e r t a i n s t a t i s t i c s and the allowance for more transaction parameters (i.e. i n addition to the destination sink and the time of a r r i v a l to the system). Adding these features, as well as further extensions (section 5.3), represent a rather tedious programming chore. Even i n l i g h t of what i t does not do, however, the current system i s s u r p r i s i n g l y inexpensive to use, considering the f a c t that i t i s a simulation program, i t i s i n t e r a c t i v e , and i t involves extensive I/O for graphics and for saving and restoring data on disk f i l e s . Furthermore, any attempt to re-write the program in a more modular fashion to perform more general tasks would be constrained by both the need for a f a s t , e f f i c i e n t simulation routine and the limited capacity of the Adage display buffer. 5«2_ Limitations One important conclusion, born out by this and the following sections, i s that animation i s mainly useful as an addit ionajL technique for analyzing simulations, not as a substitute for c l a s s i c a l technigues. When one gets down to ac t u a l l y using ANISIM to study a r e a l problem he finds that 83 1} he s t i l l needs to have certain s t a t i s t i c s available to summarize or validate when he saw (or didn*t see), and 2) most models require at least one or two simulation features that are not available i n a s t r i c t queuing network formulation. This second d i f f i c u l t y i s compounded by the l i m i t s on problem size imposed by the representation of the network. As already pointed out in the example of t r a n s i t times, the a v a i l a b i l i t y of additional simulation power tends to simplify the required network structure, allowing a more complex s i t u a t i o n to be represented on the screen. In discussing potential models f o r ANISIM with people f a m i l i a r with discrete simulations, a pattern began to emerge i n the simulation features reguired i n order to enable many models to be formulated. A few of the most important recommendations a r i s i n g from (or confirmed by) these discussions are mentioned here. In many queuing models, i n d i v i d u a l items must group together as they t r a v e l through the network. This i s true of ra i l r o a d cars, cargo on ships, and words i n a telecommunications network. To accomodate t h i s type of model in ANISIM, the concept of multiple servers must be changed to allow one server symbol to represent a server of unlimited (user specified) capacity. Also groups of items should be able to tr a v e l between nodes using one symbol (and generating single events). Figure 20 shows one way of animating t h i s . In the case of trains or 84 'FIGURE 20: T r a n s a c t i o n Grouping s h i p s , i t would a l s o be d e s i r a b l e to allow some f l e x i b i l i t y i n depa r t u r e p r o t o c o l s . F c r example, there i s c u r r e n t l y no way of s p e c i f y i n g p e r i o d i c or otherwise scheduled departures c f a s e t number of items ( i . e . dep a r t u r e s independent of when s e r v i c e begins) . Another necessary c a p a b i l i t y of many gueuing models i s to measure the average delay of items t r a v e l l i n g between a r b i t r a r y p o i n t s of the network; The c u r r e n t system only measure^ the delay between s o u r c e - s i n k p a i r s . The only drawback of adding t r a n s a c t i o n parameters (as t h i s would) i s the i n c r e a s e d s t o r a g e requirement f o r the ALGOLS r e c o r d s which c o n t a i n the i n f o r m a t i o n f o r each t r a n s a c t i o n i n a gueue. Two a d d i t i d n a l f e a t u r e s which would c o n s i d e r a b l y widen the c l a s s of models t h a t c o u l d be simulated are t r a n s i t times ( d i s c u s s e d e a r l i e r ) and l o g i c s w i t c h e s , or ga t e s . The l a t t e r would i n v o l v e t e s t i n g on u s e r - s p e c i f i e d t r a n s a c t i o n parameters and would c o n s i d e r a b l y complicate the di a l o g u e f o r d e f i n i n g the network. 85 5 i3_Extensions In addition to those discussed i n the previous section, the following potential extensions to AHISIH merit consideration. 1) As pointed out e a r l i e r , the animation f a c i l i t y does not preclude the need f o r s t a t i s t i c a l summaries. S t a t i s t i c s which should be added include the mean and variance of the delay at each gueue and buffer, as well as the variance of the gueue lengths and buffer contents. Of course, the animation then allows the viewer to watch the variations happening, i n order to get a better f e e l for the nature of the fluctuations and the relevance of the averages. Furthermore, the animation together with the s t a t i s t i c s on blocking, provides a better understanding of how occasional blocking (congestion) may d i s t o r t the signigicance of the other s t a t i s t i c s . 2) It may be possible to provide more meaningful ways of presenting s t a t i s t i c s to the user. One suggestion i s to provide a " t h i r d l e v e l " of information using a command which allows the modeller to view a plot of a s t a t i s t i c , such as queue length, over time. Another suggestion i s to provide a command which displays the average state of each entity rather than just the f i n a l state in which the simulation stopped. A more d i f f i c u l t to implement feature would be some type of continuous display during the animation of, for example, the average gueue length. (This would involve a separate symbol, or number, displayed near 86 the queue symbol.) It would also be helpful to display the simulation clock time during the animation. 3) Currently, only two p r o b a b i l i t y d i s t r i b u t i o n s have been implemented for a r r i v a l and service rates. Others, such as Erlang d i s t r i b u t i o n , must be added, as well as the a b i l i t y to create a d i s t r i b u t i o n from user-specified empirical data. Also, more f l e x i b i l i t y with the random number seeds would allow the user to st a r t two or more streams with the same seed, for comparison purposes. A further type of a r r i v a l rate that would be very useful f o r modelling closed systems i s a f i n i t e c a l l i n g population. A l i m i t e d number of a r r i v a l s are generated, possibly a l l at once, and new a r r i v a l s appear at sources only when items depart to sinks. 4) The routing mechanism used i n ANISIM represents one type of route s e l e c t i o n . Other possible types include a pre-defined routing scheme, where an item's route i s f u l l y s p e c i f i e d at the source, and a stochastic routing scheme, where the next node from any given node i s determined from a p r o b a b i l i t y d i s t r i b u t i o n . Other possible features than control routing are the transaction s p l i t t i n g and logic switching features of GPSS [9]. 5) As well as allowing a r r i v a l and service time options, ANISIM 87 should provide optional p o l i c i e s for queue d i s c i p l i n e s and blocked transactions. P r i o r i t y queues ( i . e . allow the generation of d i f f e r e n t types of transactions) would be somewhat d i f f i c u l t to i l l u s t r a t e , however, given the current representation. An example of an alternate blocked transaction policy i s that a blocked item go back to the end of i t s own queue, instead of waiting in the server. 6) Some t y p i c a l network configurations occur often enough that i t might be useful to provide a "network macro" f a c i l i t y for the automatic creation of previously defined sub-networks. Even better, there may be some models which can be suitable represented with entire sub-networks of the model replaced i n the animation by s p e c i a l , or user created, macro symobls. For example, i n Figure 19 i f each buffer (with i t s associated gueues and servers) were replaced by a network macro symbol, or i n t h i s case by a small version of the buffer symbol, the representation of the model would be considerably s i m p l i f i e d . Of course t h i s technique would allow ANISIM to handle larger models, since the main constraint on problem siz e i s the number of Adage buffer words used to represent the network. Also for t h i s reason, and for viewing s i m p l i c i t y , i t may be worthwhile to attempt a "windowing" c a p a b i l i t y , where only one portion of a large network i s displayed at one time. Windowing may not prove to be of too much value i n t h i s case however, since the modeller would never be able to view the entire network at once. 88 7) One problem with the animation of a non-trival network i s that a l l of the moving items look a l i k e . I t i s d i f f i c u l t , at times to follow the progress of an item through the network, e s p e c i a l l y i f i t spends time i n queues. A p a r t i a l solution to t h i s problem would be to shade, or otherwise mark, ce r t a i n items so that they can be distinguished from the others as they t r a v e l through the network. The drawback i s the space required by the additional transaction parameter f i e l d . Two methods of using t h i s shading feature are a) mark a l l items a r r i v i n g from a sp e c i f i e d source, and b) mark every tenth item, or whatever , generated by the system. 5 r o s p e c t s for Further Work Although i t i s possible to formulate a f a i r l y large number of models in terms of networks of queues, the guestion arises as to what other types of discrete models or r e a l processes might be animated using the techniques described i n Chapter II. It seems that most descrete event simulation models can make use of the i n t e r n a l cycle concept, the c l a s s i f i c a t i o n of sequences, and the editing procedure. The deciding f a c t o r s , then, f o r animation f e a s i b i l i t y , would be whether the model structure can be suitable represented on a graphics scope and whether meaningful animation seguences can be compiled and displayed using the graphics software available. (The length of any two-side bounded sequences might be a problem in some cases. 89 as noted i n Chapter II.) One type of simulation with a s l i g h t l y d i f f e r e n t emphasis from that used i n ANISIM would u t i l i z e the graphics c a p a b i l i t i e s to study models involving s p a t i a l layout problems. Consider, for example, a model of a warehouse operation, where the cost associated with an item t r a v e l l i n g between two points in the model i s derived i n t e r n a l l y from the physical distance between symbols on the screen. The user i s able to optimize the model, with respect to cost and space, by simulating and animating i t with various s p a t i a l arrangements. This type of model would also reguire queuing f a c i l i t i e s , only the representation of the length of the queue would now become important. The question of animating r e a l processes rather than simulations i s a more d i f f i c u l t one. For example, assume i t i s desirable to monitor an animation of some sort of i n d u s t r i a l or s c i e n t i f i c process which cannot be d i r e c t l y observed (e.g. due to the location or size of the components of the process). Further assume that the process must be monitored in terms of discrete events, rather than continuous updating. This may be due to the method of measuring i t s progress, or perhaps only the general stages of the process are important to the observer. I f the events are merely being recorded for l a t e r study (say the process happens too f a s t or too slow for real-time monitoring), then there i s no problem. The events can be edited and compiled as done for simulations. I f , however, i t i s desirable to display the animation simultaneously with the ongoing process. 90 then two basic problems arise. For one thing, the process can't be stopped every few events i n order to wait for the editing and compiling of sequences. Furthermore, the time expansion due "to binding sequences would result i n a continually increasing lag between the time of the event and the time i t i s displayed. F i r s t of a l l , the problem of time expansion may not be a problem at a l l . Recall that binding sequences were required i n order to add some sort of r e a l i t y to the modelling abstraction of an instantaneous movement. I t seems l i k e l y , however, that most r e a l processes monitored i n r e a l time w i l l require two-side bounded sequences rather than binding sequences to properly animate movements. Let us assume then, that we wish to animate a real-time process requiring no binding sequences and no two- side bounded sequences of unmanageable length. A system configuration that would probably make thi s task f e a s i b l e reguires three p a r a l l e l operations instead of the current two (370 program and Adage monitor). The f i r s t processor would continuously record the events of the ongoing process and make the event l i s t available to the second processor, which would then be able to use the i n t e r n a l cycle approach to edit events and compile sequences for the graphics computer to display. The animation would of course lag behind the actual events by a fixed start-up time, but the speed of the display could be made equal to that of the r e a l process. This discussion i s quite abstract and there would c e r t a i n l y 91 be bugs t o work out i n t h i s approach. The p o i n t i s t h a t t h e p o t e n t i a l e x i s t s f o r a p p l y i n g t h e g e n e r a l t e c h n i q u e s of C h a p t e r II t o t h e a n i m a t i o n o f systems o t h e r than s i m u l a t i o n s . 92 BIBLIOGRAPHY 1. Baecker, R.M. "Toward Animating Computer Programs: A F i r s t Progress Report," Proceedings of the Third Man-Computer Communications Seminar, NRC, Ottawa, Canada, May 1973. 2. Baecker, R. m. Interactive Computer-Mediated Animation, MAC-TR-61 (THESIS) 7"une~ 1969,"Project MAC, MIT. 3. Brocchi, G.; Somalvico, M. "An Interactive Software System f o r Computer-Aided Design: An Application to C i r c u i t Project," CACM, Vol.13, No.9, September 1970. 4. Chheda, D.P. "CAM, A Computer-Aided Modelling Program f o r Systems Dynamics Models," Master's Thesis, Department of Computer Science, U.B.C., 1974. 5. Coffman, E.G.; Elphick, M.J. ; and Shoshani, A. "System Deadlock," Computing Surveys, Vol. 3, No. 2, June 1971. 6. Coulthard, W.J.; Dekleer, J. "UBC:AGTBASIC - Basic Communication Package for the Adage Graphics Terminal," Computing Centre, U.B.C, 1973. 7. Coulthard, W.J. "UBC:GRAPH - A Simple Interactive Graphics Package," Computing Centre, U.B.C, 1973. 8. Forrester, J.W. World Dynamics, Wright Allen Press, 1971. 9. General Purpose Simulation System V tjser*_s Manual, IBM Publication~No7~~SH20-0851. 10. Hilborn, R. Simulation Control Command Language—SIMCON, Institute of Animal Resource Ecology, U.B.C, October 1972. 11. H i l l i e r , F.S.; Lieberman, G.J. JfiiE2JS£tion to Operations Research, Holden-Day 1967. 12. Lafata, P.; Rosen, J.B. "An Interactive Display for Approximation by Linear Programming," CACM, Vol. 13, No. 11, November 1970. 93 13. Martin, James Desicjn of Man^Computer Dialogues, Prentice-Hall, 1973. 14. Mcintosh, J.F. "GRAPHIC," Computing Centre, O.B.C., 1973. 15. Merchant, M. "Interactive Spline Approximation," Master's Thesis, Department of Computer Science, D.B.C., 1974. 16. Newman, W. M. ; Sproull, H.F. Pri n c i p l e s of Interactive Computer Graphics, McGraw-Hill, 1973. 17. Okaya, Y. "Interactive Aspects of Cr y s t a l Structure Analysis," IBM Systems Journal, Vol.7, Nos. 3 and 4, 1968. 18. Prince, M.D. Interactive Graphics for Computer-Aided Desicjn, Addison- Wesley,~1971. 19. Richardson, F.K.; Oestreicher, D.R. "Computer Assisted Integrated C i r c u i t Photomask Layout," in Pertinent Concepts i n Computer Graphics, Faiman, M., Nievergelt, J , , eds.. University of I l l i n o i s Press, 1969. 20. Savage, G. J. ; Andrews, G.C. "DYNIS: A Dynamic Interactive Simulation Program For Three-Dimensional Mechanical Systems," Proceedings of the Third Man-Computer Communications Seminar, NRC, Ottawa, Canada, May 1973. 21. The SIM SCRIPT II_.5 Reference Handbook, Consolidated Analysis Centers Inc., 1971. 22. Smith, L.B. "The Use of Interactive Graphics To Solve Numerical Problems," CACM, Vol. 13, No. 10, October 1970. 23. Smith, L.B. "A Survey of Interactive Graphical Systems for Mathematics," Computing Surveys, Vol. 2, No. 4, December 1970. 24. Sutherland, W. R. "On-Line Graphical S p e c i f i c a t i o n of Computer Procedures," MIT Lincoln Laboratory, TR 405, May 1966. 9n APPENDIX A — PROGRAM DESIGN ANISIH i s implemented cn an IEH 370/168 using the HIS (Michigan Terminal System) operating system, and an Adage Corporation Graphics Computer, as shown in Figure 21. ADAGE Model 10 G r a p h i c s D i s p l a y S c o p e — * .Fu'nct i ori But tons IBM 370/168 4. * 12 0 00 0 h i t s / s e c IBM 3270 D i s p l a y T e r m i n a l • 2. I T . ADAGE G r a p h i c s .Computer T e l e - t y p e . O p e r a t o r >s Cont r o l P a n e l FIGURE 21: S y s t e a C o n f i g u r a t i o n The program i s written c h i e f l y i n AIGCIW, with a few I/O operations i n. FORTRAN. Software provided by the D.E.C. Computing Centre consists of the HTS f i l e handling routines, the basic subroutine package f o r communicating with the Adage [ 6 ] , and the graphics monitor which resides in the Adage Computer £7]. Following i s a b r i e f d escription of the 95 major procedures in the ALGOLW program. MAIN: The main body of the program i s b a s i c a l l y the command monitor. Upon i n i t i a l execution, the procedure INITMAIN i s ca l l e d to i n i t i a l i z e various system variables, and the procedure SETUP i s c a l l e d to generate the Adage buffer words for the crosshairs, menu, messages, and symbols. The monitor then asks the user to enter a command, as shown i n Figure 10. The input s t r i n g i s compared to each possible command u n t i l a match i s found. Commands which allow parameters for changing the value of system variables always print out the new values of the variables. Thus, i f the parameters are ommited, the current values w i l l be printed. Simple commands are executed in li n e by the command processor, while other commands are executed by c a l l i n g one or more procedures. BUILD: The BUILD procedure monitors a l l network construction and modification. Upon entry, i t loads the words for the menu and prompting messages into the display buffer. The main loop consists of turning on the display of the menu, issuing a lightpen read, turning off the menu, and executing a procedure (depending on the location of the lightpen h i t ) . Also, upon termination of the procedure executed, control of the mode name in the menu i s switched from d i a l two to d i a l f i v e . NODES: This procedure i s c a l l e d when the SYMBOLS command i n the 96 menu i s h i t . Its main loop, after turning on the crosshairs, consists of issuing a read to the function buttons and executing the appropriate code. The buttons are used to create sources, servers, sinks, gueues, and buffers. For each such entity, the symbol i s displayed at the location of the crosshairs, the buffer words fo r the l a b e l are created, and a record i s created and added to the l i s t of records for that entity. Further use of the buttons i s required i n order to position a gueue or to sketch a buffer. A s p e c i a l button terminates the SYMBOLS mode. If a lightpen h i t i s read instead of a button, the symbol or l i n k pointed to i s no longer displayed. I f a symbol i s pointed to, i t s associated record i s also deleted from the data base. JtOKS: T ^ e LINKS mode makes use of the lightpen i n order to draw connecting l i n e s between pairs of symbols. No entry i s made in the simulation data base. The i n t e n s i t y of the l i n k s i s controlled by d i a l E, while the i n t e n s i t y of the symbols i s controlled by d i a l B. ASSIGNQ: This procedure i s c a l l e d , with d i f f e r e n t arguments, for the ASSIGNQ, FIRST QUEUES, and ASSIGN BUFF modes. For example, i f the arguments are the l i s t of queues and the l i s t of servers (ASSIGNQ mode), then the process i s as follows: a server i s made to b l ink; a prompting message asking for a queue i s displayed, and the lightpen i s read. If a gueue symbol was h i t , then a pointer to the queue record i s placed i n the server record, 97 otherwise the message "NO ASSIGNMENT" i s displayed. If the edit f l a g i s not on, then the process starts over with the next server i n the l i s t u n t i l a l l servers have been processed. If the e d i t f l a g i s on, then the user i s f i r s t prompted to point to the server he i s interested i n . ROOTING: The ROOTING mode requires a procedure s i m i l a r to that used i n ASSIGNQ i n order to f i l l a matrix of pointers to queue or sink records. Each entity i s assigned a number (unique within the e n t i t y type) when created in SYMBOLS mode. The number i s used to form the la b e l and to reference the entity whenever a pointer to i t s record i s not appropriate. In the case of the routing matrix, the f i r s t dimension i s indexed by queue numbers, and the second dimension i s indexed by sink numbers. Thus for each blinking queue-sink pair, the user i s asked to point to the next queue i n the route, or to the sink. This i s done by stepping through the l i s t of sinks and, f o r each sink, stepping through the l i s t of queues. If the edit f l a g i s set, the user i s asked for a sink but every queue i s processed for than sink. 2MACI2IJS: This procedure steps through the l i s t of queues and then the l i s t of buffers, blinking each i n turn and prompting on the 3270 for the capacity. Each queue and buffer i s given a default capacity (20 and 100, respectively) i n SYMBOLS mode. The default or otherwise current capacity i s printed with the 9 8 prompt. If a n u l l l i n e i s entered by the user, the f i e l d i n the queue or buffer record remains unchanged. If something other than a number i s entered, the capacity i s set at 1,000,000 and the gueue symbol i s altered to represent an i n f i n i t e gueue. I f a gueue capacity less than twenty i s entered, the gueue symbol i s shortened proportionately. SOORCEFLOW: The SOURCEFLOW procedure i s used for both FLOW and SERVICE TIMES modes, where the a r r i v a l and service d i s t r i b u t i o n parameters, respectively, are entered into t h e i r appropriate f i e l d s i n the source and server records (actually the DIS rec o r d s — s e e Appendix B). The method of blinking each symbol under consideration i s used here as well. Since defaults are not assigned, the current parameters are only printed with the prompt i f the edit f l a g i s on. In SERVICE TIMES mode the re- send time parameter i s also requested for each server. In FLOW mode the flow matrix, indexed by source number and sink number, i s f i l l e d i n the same manner as the routing matrix. If the fra c t i o n s of flow to each sink from a source do not add up to one, a message i s printed and that step i s repeated. This completes the major procedures within the BUILD procedure. SAVEgET: This procedure i s invoked by the SAVE command and allows a complete d e f i n i t i o n of a network model to be written onto an MTS f i l e of the user's choice. The filename i s prompted 99 f o r i f i t was not entered as a parameter to the command. MTS subroutines are used to create or empty the f i l e and to open i t . The information saved consists of 1) the buffer words for the network display, 2) an encoded description of the relevant f i e l d s of the records f o r each e n t i t y , 3) an encoded description of the routing matrix, and 4) the flow matrix. RESTORE: The inverse of SAVENET, thi s procedure reads i n and decodes the saved information, re-creating the data base and display. The restored network replaces any currently active network that may e x i s t , and the simulation s t a t i s t i c s are i n i t i a l i z e d to zero. LABEL: The LABEL procedure i s used to display or remove the labels at each symbol in the network. The buffer words for a l l of the labels are kept i n an array and only loaded into the buffer when required for display. This routine i s automatically c a l l e d to remove the labels before entering BOILD or s t a r t i n g the simulation. GO: GO i s a small procedure which monitors the Simulate-Edit- Compile cycle. It i s envoked by the GO command to s t a r t or re- start the simulation. Hhen st a r t i n g a simulation, GO f i r s t checks the data base i n order to make sure each source and each server has been assigned a queue. Between i n t e r n a l cycles, GO checks to see i f an attention interrupt has been issued or one 100 of the simulation l i m i t s has been exceeded. I f not, the SIMULATE procedure i s c a l l e d . The EDIT and COMPILE procedures are then c a l l e d , unless a HODISP command was issued before the current GO. SIMULATE: The main body of SIMULATE checks between the processing of each event to see i f a simulation l i m i t has been exceeded, an attention interrupt has been issued, or the required number of potential seguences for the i n t e r n a l cycle has been achieved. If none of these conditions hold, the GETEVENT procedure i s c a l l e d , otherwise control i s returned to the GO procedure. GETEVEHT: The c o l l e c t i o n of routines comprising the simulation program maintain two l i s t s of event records: the future events l i s t (or gueue) and the l i s t of processed events to be passed on to the EDIT procedure. GETEVENT processes the event at the head of the future events gueue and puts the altered record i n the output event l i s t . (If there are no future events scheduled, then GETEVENT f i r s t c a l l s GENABB.) The event record i s described in Appendix B. B a s i c a l l y , i t contains the event c l a s s , the time of the event, and various parameters further defining the s p e c i f i c simulation e n t i t i e s involved. The record also contains f i e l d s l a t e r used f o r the animation time and duration. GETEVENT begins by updating the clock to the time of the new event. It then tests on the event class and uses the more 101 s p e c i f i c information to appropriately update the state and s t a t i s t i c s of the model i n the data base. For each future event that must be scheduled as a r e s u l t of the current event, the procedure GETEVENT i s c a l l e d i n order to create the proper event record i n the future events queue. The aspects of the current state of the simulation that w i l l be required by the COMPILE procedure are then added to the current event record and i t i s placed i n the output event l i s t . 3ENABB: This procedure generates one a r r i v a l event at each source to i n i t i a l i z e the simulation. (An a r r i v a l event always causes the scheduling of the next a r r i v a l event at that source.) A pseudo-random number generator i s used to derive independent random number streams f o r each source (and each server). Thus the time of a r r i v a l i s determined by the stream and the user- specified probability d i s t r i b u t i o n for that source. GENABB must also use the flow matrix and a separate random number stream in order to determine the destination sink f o r the new a r r i v a l . GENEVENT: GEN EVENT i s c a l l e d from GETEVENT with an argument specifying the event class desired f o r the new event. GENEVENT then uses the information i n the current event record and in the data base to create the new event record. This record i s placed i n the future events queue. SENDSTATE: When the simulation stops, the data base contains the 1 0 2 current state of the model. SENDSTATE i s automatically c a l l e d at t h i s time to scan the relevant records and display the current state of each queue, buffer, and server. (This i s desirable since either NODISP was s p e c i f i e d , or the t a i l of the l a s t i n t e r n a l cycle was not displayed.) EDIT: The EDIT procedure edits the l i s t of event records output by the simulation. These same records are used to form the sequence l i s t and t a i l l i s t . Chapter II describes the editing process i n d e t a i l . COMPILE: The operations performed by the COMPILE procedure are also described i n Chapter II. The f i r s t part of the procedure steps through each record i n the sequence l i s t . Depending on the event c l a s s , selected smaller procedures are c a l l e d to ac t u a l l y compile the display programs for each sequence. The second part of the routine then compiles the buffer timer words and sends the completed array to the Adage. RESET: The RESET routine goes through the data base and, for each e n t i t y , changes the state and s t a t i s t i c s to t h e i r i n i t i a l value. It also displays a fresh copy of the network, restores the random number seeds, eliminates any remaining event or sequence l i s t s , and resets the simulation clock. SPEED: The SPEED procedure uses a small array of pre-defined 103 settings for the animation time conversion factor and the length of the i n t e r n a l cycle. The argument to the procedure s p e c i f i e s whether to assign the values for the next fa s t e r display, the next slower display, the default speed display, or the scan mode display (which also requires setting the sequence durations to zero). Also, i f a t a i l l i s t e x i s t s , the SPEED procedure w i l l go back and adjust the animation times i n the t a i l according to the new factor (see sections 2.3.3 and 2.4.2). 104 APPENDIX B — DATA STRUCTURE The b a s i c r e c o r d d e s c r i b i n g each model e n t i t y i s the NODE r e c o r d (see f i g u r e 2 2 ) . These r e c o r d s a r e grouped i n t o f i v e s e p a r a t e l i s t s o f s o u r c e s , s e r v e r s , s i n k s , queues, and b u f f e r s . S t a r t i n g B u f f e r L o c a t i o n E n d i n g I C u r r e n t B u f f e r \ S t a t e L o c a t i o n I d e n t i f y i n g N u m b e r Y - C o o r d i n a t e . o f S y m b o l X - c o o r c i n a t e o f S y m b o l Po i n t e r t o Q u e u e NODE i f a S e r v e r o r S o u r c e a n d t o B u f f e r NODE i f a Q u e u e P o i n t e r t o n e x t NODE i n L i s t P o i n t e r t o S t a t i s t i c s R e c o r d i f n o t a S i n k P o i n t e r t o M U L T S E R V i f a Q u e u e a n d t o D I S i f a S e r v e r , S o u r c e o r B u f f e r FIGURE 2 2 : The NODE Record The NODE r e c o r d i s augmented, when n e c e s s a r y , by t h e BIS, HULTSERV, and STATISTICS r e c o r d s . The DIS r e c o r d has t h r e e f i e l d s and c o n t a i n s t h e a r r i v a l o r s e r v i c e time d i s t r i b u t i o n code and p a r a m e t e r s , o r the b u f f e r c a p a c i t y . The STATISTICS r e c o r d a l s o has t h r e e f i e l d s . For queues and b u f f e r s , i t c o n t a i n s t h e s t a t i s t i c s f o r computing the average and maximum queue l e n g t h o r b u f f e r occupancy. For s o u r c e s i t c o n t a i n s the number o f l o s t a r r i v a l s and an i n t e g e r i d e n t i f y i n g t he random 105 number stream. For servers i t contains the stream i d e n t i f i e r , the re-send time, and the number of times found f u l l . Figure 23 shows the use of the MULTSER V record and the associated TRANPAR and HSPTR records. For each queue, there i s one TRANPAR record for every item i n the queue (not including items being served). Future transaction parameters would require expansion of thi s record. Also, f o r every server using the queue, there i s one HSPTR record. The network d e f i n i t i o n i s completed by the ROUTE matrix consisting of pointers to NODE records (queues or sinks), and the FLOW matrix of r e a l numbers. The EVENT record contains several f i e l d s which take on various meanings at d i f f e r e n t points in the processing. Figure 24 summarizes t h i s record. 106 MODE ( Q u e u e ) P o i n t e r S o u r c e N u m b e r . t o NODE . a n d A r r i v a l ( D e s t i n a t i o n T i m e S i n k . ) FIGURE 23: Data Structure for Queues 107 t E v e n t C l a s s C o d e P o i n t e r t o MODE R e c o r d s a s " S u b c l a s s D e s i e n a t o r s " S e q u e n c e D u r a t i o n S i m u l a t i o n I i me Q u e u e a n d B u f f e r S t a t e P a r a m e t e r s f o r C o m p i l e R o u t i n e P o i n t e r t o P r e v i o u s EVENT R e c o r d F Po i n t e r t o NODE ( D e s t i n a t i o n S i n k ) P o i n t e r t o n e x t EVENT R e c o r d F I G U R E 2 4 : T h e EVENT R e c o r d 108 APPENDIX C — USER'S GUIDE Purpose ANISIM provides a command language for creating, simulating, and animating a r b i t r a r y queuing network models. There are two main phases of execution: the normal command mode at the 3270, and the menu dialogue for network d e f i n i t i o n and modification using the Adage and the 3270. Running the Program Before attempting to run ANISIM, make sure that the graphics monitor has been loaded into the Adage computer. See the Computing Centre writeup UBC GRAPH for d e t a i l s . The following command may then be used to st a r t execution of ANISIM: $S0URCE WALK:ANISIM The program w i l l f i r s t ask the question "ARE YOU USING THE ADAGE—TRUE OR FALSE," which should be replied to by s p e l l i n g out the word "TRUE" (or "FALSE"). The program w i l l then clear the Adage screen and enter the command mode with the message "ENTER COMMAND OR HELP." On entering "HELP," a l i s t of available commands w i l l be presented along with a b r i e f reminder of t h e i r purpose. 109 Adage Input The six d i a l s connected to the Adage are used i n the following way: DIAL A DIAL D the horizontal crosshair the v e r t i c a l crosshair DIAL B in t e n s i t y of symbols and names of un-entered modes DIAL C X-co-ordinate of menu DIAL E in t e n s i t y of l i n k s and labels and names of entered modes DIAL F Y-co-ordinate of menu To use the function buttons (required during SYMBOLS mode of the menu dialogue) the yellow overlay card marked "ANISIM" should be used. If t h i s card cannot be located, the function of each button i s as follows: BUTTON 1: Creates a source. BUTTON 2: Creates a server. BUTTON 3: Creates a sink. BUTTON 5: Creates a queue. Orients the t a i l of the queue symbol. 110 BUTTON 6: Creates a buffer. Sketches the buffer symbol. BUTTON 7: Terminates buffer sketching. Terminates SYMBOLS mode. BUTTON Hz Selects the default buffer symbol. BUTTON 8: Allows a sketched buffer symbol. Bhen using the lightpen, the display w i l l blink when a h i t has been accepted, and the button should then be released to avoid an unintended second h i t . Also, as a general rule i n the menu dialogue, a lightpen h i t on the prompting message i s used to terminate a mode or avoid an assignment. Av a i l able Commands ^brackets denote optional parameters},! BUILD X NEWNETX or EDITNET Each causes the program to enter the menu dialogue phase. NEWNET f i r s t destroys any active network, and EDITNET should be used f o r small changes to the active network. The menu dialogue phase i s described l a t e r in more d e t a i l . C Y C L E _ n J J L s 2 J Ls^j [_MJ Changes the l i m i t s on the simulation and prints the resulting values. If any parameter i s missing or given as an asterisk (position holder), the current value i s retained and printed. The parameters are 1) the simulation clock time l i m i t , 2) the maximum number of a r r i v a l s generated, 3) the maximum number of entries into gueue/server systems, 4) the maximum number of 111 terminations (departures to s i n k s ) . Default values are 1000, 200, 200, and 50, respectively. DESPEED Returns to the default speed for subsequent animations. DOR LSiJ LS2J LRU LRU Alters the sequence durations (in simulation time) to the new values i f s p e c i f i e d , and prints the values. The sequences are 1) a r r i v a l s , 2) l o s t a r r i v a l s , 3) departures (binding), and 4) departures to sinks. A l l default durations are 10 simulation time units, except during SCAH mode when they are zero. EDITNET See BUILD. END Terminates the program. An attention interrupt also returns control to MTS but the program can be resumed with a $RESTART command. FACTOR LHJ Alters the animation time conversion factor to the new value i f sp e c i f i e d , and prints the value. The smaller the factor, the faster the display. The default factor i s set to 10. FASTER Increases the speed of subseguent animations, unless the current speed i s the f a s t e s t , and prints the new factor and cycle length values. 30 In J Simulates the active network for n time units from the current 112 state or u n t i l interrupted, or u n t i l a simulation l i m i t i s exceeded (see the CYCLE command). The animation accompanies the simulation unless a NODISP command i s f i r s t issued. INTERCY £nj Alte r s the length of the i n t e r n a l cycle to the new value i f sp e c i f i e d , and prints the value. For fast displays, the i n t e r n a l cycle should be made larger to avoid delays in the animation between cycles. Default value i s 15 sequences. LABEL Displays unique labels at each symbol. These labels allow reference to s p e c i f i c network e n t i t i e s by information available from the PRINT command. The inte n s i t y of the labels i s controlled by d i a l E. MORHELP Prints additional commands not l i s t e d by HELP. NEWNET See BUILD. NOJDISP Turns off the animation for the duration of the next GO command. PLOT [_sj Provides a hardcopy plot of the display. The maximum dimension i s 10 inches unless the parameter otherwise s p e c i f i e s . PL0T:Q must be run a f t e r termination ANISIH. PRINT ni |_n2J Prints the following information, according to the f i r s t argument. The second argument, i f not zero, w i l l cause the 113 program to ask f o r the name of an MTS f i l e on which to print the information. The codes are: 0) A l l of the information available from codes 2-8 and 16. 1) A l l of the information available from codes 3-8 and 16 ( i . e . a l l s t a t i s t i c s ) . 2) A description of the future events l i s t . 3) A l l of the information available from codes 4-8. 4) Source numbers and s t a t i s t i c s . 5) Sink numbers and s t a t i s t i c s . 6) Server numbers and s t a t i s t i c s . 7) Queue numbers and s t a t i s t i c s . 8) Buffer numbers and s t a t i s t i c s . 11) A description of the current seguence l i s t . 12) The most recently compiled animation buffer (for debugging) . 13) A summary of the current model e n t i t i e s and parameters. 14) The current value of each random number stream (for debugging). 15) The entire Adage display buffer (for debugging). 16) The average time-in-system s t a t i s t i c s by source- sink pairs. Any other number w i l l result i n the printing of the current status of the simulation. 111 RESET Resets the simulation variables, the s t a t i s t i c s , the model state, the random number seeds, and the display to the i r i n i t i a l status. RESTORE [_filenamej Destroys the current active network and makes active the network saved on the MTS f i l e s p ecified. SAVE j_filenamej Saves the active network on the MTS f i l e s p e c i f i e d . If the f i l e does not already e x i s t , i t w i l l be created. SCALE _xj Alte r s the scale of the display to the new value i f s p e c i f i e d , and p r i n t s the value. The default i s 0.6. SCAN Allows the animation to be displayed at an increased speed with no moving items ( i . e . a l l "seguence durations" are zero). The new factor and cycle length values are printed out. SLOWER Reduces the speed of subsequent animations, unless the current speed i s the slowest, and prints the new factor and cycle length va lues. STOP Same as END. TRACK n l [_n2J Sets debug f l a g s for the programmer. The second argument causes the program to ask for the name of an MTS f i l e on which to print 115 the output. The flags are 0) PRINTCYC, 1) PRINTSTEPOUTP, 2) LITDUMP, 3) TRACE, 4) DUMPER, 5) COMPTRACE, 6) COMTRACE, and 7) BUFTRACE. Flag 3 may also be of value to the user, as i t provides a detailed trace of the simulation. UNLABEL Removes the labels from the screen. (This i s done automatically before simulating and before entering the menu dialogue.) The Menu Dialogue Once t h i s phase of the program i s entered, commands are entered by pointing with the lightpen to a mode name i n the menu. The menu should be positioned by d i a l s C and F to a convenient location on the screen. It w i l l disappear during the execution of each mode. Also, Dials B and E should be adjusted such that un-entered modes are at normal i n t e n s i t y and entered modes are at a reduced i n t e n s i t y . A mode may be re-entered by turning the in t e n s i t y back up i n order that the lightpen h i t w i l l take. When building a new network, a recommended order of execution i s the order i n which the mode names are l i s t e d . The purpose of each mode i s outlined below, along with any inst r u c t i o n s for use not obvious from the dialogue. SYMBOLS: This mode i s used to create model e n t i t i e s with the function buttons and position t h e i r symbols at the locations defined by the crosshairs. Button 7 i s used to terminate the mode. When creating a gueue, a second button h i t i s reguested. 116 The head of the gueue w i l l be located at the f i r s t crosshair location and the t a i l w i l l be oriented i n the dire c t i o n of the second crosshair location. Buffer symbols may be sketched i n any shape. Upon selecting a buffer (button 6), the bargraph appears at the crosshairs location and the user i s asked whether he wants to sketch (button 8) or use the default shape (button 4). If i t i s sketch, button 6 i s used with the crosshairs to specify li n e endpoints. No l i n e w i l l be drawn to the f i r s t point s p e c i f i e d . Button 7 terminates the sketching, The lightpen may be used i n thi s mode to delete a symbol or l i n k by pointing to i t . A maximum of 19 gueues, 19 servers, 10 sources, 10 sinks, and 6 buffers are currently allowed, including any deleted ones, LINKS: This mode i s used to connect any pair of symbols with a li n e by pointing to the symbols with the lightpen. The in t e n s i t y of the l i n k s i s controlled by d i a l E. ASSIGNQ: Every server must be assigned a unigue gueue. These, and other assignments, are made by pointing to the symbol with the lightpen. The assignment i s made to the server that i s blin k i n g . FIRST QUEUES: Every source must be assigned a unigue queue to designate the f i r s t queue/server system i n the route for items generated at that source. ASSIGN BUF: This mode i s required i n order to t e l l the program where to send an item next, given that i t i s at a gueue/server system (blinking queue) and i s destined for the blinking sink. 117 The user should point to the next queue or to the sink. CAPACITIES: This mode i s required i f the default capacities of 20 f o r queues and 100 for buffers are not appropriate. The capacity of a queue does not include the servers, although the state of a queue refers to the queue/server system. FLOW: This mode i s required i n order to define the i n t e r - a r r i v a l time d i s t r i b u t i o n type and parameters. (Currently, the exponential and uniform d i s t r i b u t i o n s are available.) The mode i s also used to define the flow of items generated at each source, by entering the f r a c t i o n (decimal f r a c t i o n between 0.0 and 1.0, inclusive) of those items to be destined for each sink. I f the f r a c t i o n s do not add up to 1.0 for each source, the user w i l l be asked to try again. SERVICE TIMES: This mode i s required i n order to specify the d i s t r i b u t i o n and parameters of the service time for each server. It i s also used to specify the (constant) time a blocked item must wait i n the server before attempting to depart again. (An item i s blocked by either the next queue or i t s buffer being f i l l e d to capacity.) DONE: This i s not ac t u a l l y a mode, but causes the menu to disappear and control to be returned to the normal command phase at the 3270. Since there may s t i l l be bugs in ANISIM which could cause an unexpected termination of the program, any newly created or modified network should be saved at t h i s time using the SAVE command. This user's guide i s not intended to provide a thorough 118 understanding of the uses and c a p a b i l i t i e s of ANISIM. The interested user i s referred to the main body of t h i s thesis f o r further d e t a i l s .

Cite

Citation Scheme:

    

Usage Statistics

Country Views Downloads
Malaysia 1 0
Canada 1 0
China 1 1
City Views Downloads
Jitra 1 0
Winfield 1 0
Beijing 1 1

{[{ mDataHeader[type] }]} {[{ month[type] }]} {[{ tData[type] }]}

Share

Share to:

Comment

Related Items