MICHAEL GILI~

~lichael Geller received his B.S. degree in Mathematics fr~ Rensselaler Polytechnic Institute in 1966, .his M.S. degree in Mathematics from the University of Connecticut in 1968, and his doctoral candidate in Mathematics at Polytechnic Institute of N.Y. Since receiving his M.S. degree he has worked as a Systems Analyst at Cr~man Data Systems; as a Resident Visitor at Bell Laboratories ~n the Ocean Systems Division; and as a membor of Technical Staf~ at Bradford National Gorporation. lle has been involved with the develop~lent of several large real time systems and has been interested in the use of simulation for design, development~ and testin~ these systems. He has recently returned to Bell Laboratories as a member of Technical Staff and is involved with new micro c~puter based real time signal processing systems that are being developed. Ha is also a part-time lecturer in the Mathematics and Computer Science Department at Fairleigh Dickenson University.

MICSIM--THE SIMULATION MODEL OF FDNY'S COMPUTER-AIDED DISPATCH SYSTEM

Michael Geller

ABSTRACT

F i re f ight ing units in the borough of Brooklyn are current ly dispatched with the aid of FDNY's new computer dispatch system, MICS. The system is designed around dual PDP l l /45s which are supported in a " fa l lback" (or back-up) mode by dual INTEL 8080 micro-processors. The computer processes alarms, recommends the assign- ment of available uni ts, no t i f i es assigned units by voice and hard copy terminals located in f i r e stat ions, monitors status changes of f i r e f i g h t i n g units and incidents, and dynamically adjusts the borough's f i r e f i g h t i n g coverage by recommending schemes for the relocation of units in order to minimize future (ant ic ipated) response times. The system has been so successful in Brooklyn that i t is being expanded to cover al l f ive boroughs through a shared central ized PDP l l / 70 computer system. The ci ty-wide system wi l l be called CMICS.

Simulation techniques were employed during al l phases of MICS system development to insure that the necessary system c r i t e r i a would be met under the ever-increasing alarm rates experienced in New York.

This paper describes the primary simulation tool , the GPSS simulation model, MICSIM, which was used to study the complex relat ionships between real-t ime system software, communication software, device handlers, and the appl icat ion programs (components t yp ica l l y found in al l mult i - programming real-t ime systems). The end product of MICSIM is an explanation and quant i f icat ion of the response times achieved by the system when responding to dispatchers' CRT requests.

Even with the sophisticated performance monitors that were used to measure CPU u t i l i z a t i o n and perform I/O and CPU accouting on a task-by-task basis, i t was not possible to determine the real l im i t ing factors in the system when the rates of CRT operator actions and input messages from the f i e l d increased. The increased

overhead required to extract this data in te rna l l y from the operational system would cause substantial interference there- by inval idat ing the data. Only with the aid of MICSIM was i t possible to " p ro f i l e " a task and determine the nature of the events that take place within MICS as i t responded to external actions. The basic understanding provided by the model made i t possible to take the necessary steps to achieve the desired performance standards.

Key Words and Phrases

Discrete simulation, Monte Carlo simulation, real-t ime systems, communication systems, performance measurement, response time, queues, bottlenecks, u t l i za t i on , GPSS, hardware, software, throughput, mult i- programming, systems design, f ine tuning, input/output.

I . Introduction

New York Ci ty 's Fire Department (desig- nated FDNY), placed on- l ine, in Brooklyn, a Management Information and Control System (MICS) which provides computer assistance for the department's dispatch- ing and communication functions. The system replaced manual procedures which were rapidly becoming inadequate for the soaring alarm rates current ly experienced.

Since time is c r i t i c a l in the dispatching of f i r e f i g h t i n g resources, careful at tent ion was given to the performance aspects of MICS. Performance c r i t e r i a were established for the system's response time to dispatcher CRT requests under peak alarm rates. Realizing that i t would be in to lerable for a dispatcher to wait long for the computer to process his request, the Fire Department specif ied acceptable performance parameters to insure that the system would not " l im i t " the number of alarms which a dispatcher could process due to internal queueing problems. Bradford National Corporation, the developer of the MICS system, was

473

MICSIM - FDNY's Simulation Model...Cont'd

thus contractual ly obligated to demonstrate that the performance requirements would be met. Addi t iona l ly , this necessitated the development of a r t i f i c i a l techniques to provide peak alarm rate conditions so the performance would be documented pr ior to system cutover [ l ] .

When developing a real-t ime system which must meet t igh t performance c r i t e r i a , i t is essential to have the means to measure the performance of the key system com- ponents and then to understand quanti- t a t i ve l y how these elements in terac t . While the measurements may be obtained through some other type of performance monitoring, fu l l understanding w i l l probably require the use of a simulation model.

2. The Need for a Simulation Model

The wide variety in the types of demands made for Fire department services, coupled with the random nature of alarm a r r i va l s , and constantly increasing alarm rates make i t d i f f i c u l t to formulate a s t a t i s - t i ca l descript ion of the performance of these tasks which MICS is called upon to perform during a peak alarm period. The complexity of the real-t ime system's interact ioas and dependencies fur ther complicates the process or analyzing the system at any "moment in time" to discover the nature of the competition between tasks and system routines for the various system resources. A simulation model is a convenient aid for use in the study of a system driven by random phenomena and composed of a var iety of tasks competing for f i n i t e and interdependent resources [3, 4].

A single alarm i n i t i a t e s a series of operator a c t i v i t i e s at several CRTs to dis- patch and no t i f y f i r e units. These are followed by inputs made on special purpose panels in both the central communications o f f i ce and the firehouses to update unit and incident status f i l e s . Alarms may or ig inate from mechanical s t reet boxes (BARS), from newer e lectronic s t reet boxes (ERS) which permit voice communication as well as the transmission of d ig i ta l signals and via d i rec t telephone contact. Each source requires d i f f e ren t i n i t i a l process- ing with the l a t t e r two requir ing computer in tervent ion. Figures l and 2 show the MICS hardware configurat ion and the operation environment, respect ively.

I t was d i f f i c u l t under these conditions to predict the work load that the MICS system would face at alarm rates projected to be as high as three alarms per minute. One alarm can:resul t in twenty to t h i r t y dis- patcher in teract ions, each one causing a task which, in turn, is a series of p r o - grams required to process the par t i cu la r input message.

The execution of each task requires precise coordination of key hardware and software components. Messages are transmitted over various types of mult ip lexer equipment from the terminals (CRT and other terminal types) d i rect ing the message to the central processing uni t . Communication software controls the transmissions by pol l ing the various terminals. In MICS, this software is called Line Control. Each message is received character-by,character in a s i lo where i t is removed by programs (cal led SILO programs) into buf fers, forming a

DIP S)lmm "A" [ ~

~tm,h, ces ---...<

[

N N N N

I q ~ 1 I ~ c co~158uracloa of litooklyln MK~. Coe~ol comput~ is backed up by l d e e ~ i t , ~ y ,~4y.. bmb d w h i c h have accem co du~l d i e mbeyEe~ Ore- Roe and sUL~lby mlcmpeocemm" o0mmolleu m.v,e u dual b~:imp m Lvo I ~ e ~ peocemmL ~ ~ so~,--. ,y,,m b w,,md .... ,~,.

I n t ~ f ~

DP

LAne Switch/S

.FIGURE | . M I C S HARDWAt~

474

OeCmON 06~TCN

t SUPEeVtS~

t ~ E t ~

Fig 2 MtCS modes of operation. All five modes are assisted by computer recommendatiors but operator or supervisor makes final decision. Box alarm readout system and city-wide deployment CPUs are not ac- tual ly part of MICS but function with i t

message for each l ine. When the message for a l ine is complete, the l ine control software passes the buffer to the Queue Control ler , the program which interfaces with appl icat ion tasks and controls the queueing of messages back to the terminals. Terminals may be associated with any number of modes of operation depending on the function which the dispatcher is performing. This requires a highly sophisticated queue cont ro l le r . F ina l ly , the input message is processed by appl i - cation programs which invoke other device- dependent tasks when they perform I/O to update f i l e s or when program modules not current ly in core are needed. These applications tasks are diverse and may range from a program that takes only f ive to ten milliseconds of CPU time and performs no I/O, to a sequence of mathematical programs performing several I/Os and requir ing t h i r t y seconds of CPU time. Coordinating al l the software is a real-t ime operating system, wri t ten by Bradford, which provides the appropriate multi-programming environment with emphasis on timely and e f f i c i e n t dispatch- ing of tasks, memory management, in ter rupt handling, etc. Figure 3 shows the flow of an alarm as i t is handled by each dispatch- er in teract ing with computer generated screens and making entr ies into special purpose equipment. I t can be thought of as a macroscopic view of the GPSS modeling e f fo r t . Figure 4, on the other hand, is a more microscopic :iew fol low- ing a message from i ts i n i t i a t i o n at a dispatcher's CRT, thru the hardware and software processing that fol lows, unt i l a response is transmitted to the i n i - t i a t i ng CRT. The l a t t e r modeling e f f o r t would be simi lar for other real-t ime systems and is discussed in more detai l

in the next section.

Almost every developer of large real- time systems must face this type of environment.and i t can be very d i f f i c u l t to project system performance. Many questions arise during system design:

Is the CPU fast enough?

How much core is needed?

W i l l t h e r e be a b o t t l e n e c k a t the d i s k ?

Which programs should be core resident and how much core should be allocated to task execution?

How should we p r i o r i t i z e the task.(;, the queues?

475

MlCSlM - FDNY's S i m u l a t i o n Model . . . Cont 'd

BLINK ERRORS

CONTACT JNITS ~VAILABLE 'ON THE AIR'

KEY

~RD-ALARM RECEIPT DIS- PATCHER

DO-DECISION DISPATCHER

RD-RADIO DIS- PATCHER

VD-VOICE DIS- PATCHER

PHONE

1 " KEY /

A L A R M R E C E I P T

ALARMS ARRIVE FROM 3 SOURCES

B

• I, ME(~HANICAL STREET BOX JBARS PROcEsSOR I (BARS) INPUTS ALARM i

MESSAGE i

I MICS DISPLAYS ALARM SCREEN

ARD COMPLETES SCREEN

MICS EDITS SCREEN

D E C I S I O N

D I S P A T C H &

IMICS I PROMPTS DECISION DISPATCHERS (DD)

DD PRESSES "NEXT" KEY

ELECTRONIC STREET BOX (ERS)

qB

ERS PROCESSOR INPUTS ALARM MESSAGE

MICS FORMS i ALARM SCREEN BOX # & ADDRESSJ

b

I MICS PROMPTS ALARM RECEIPT DISPATCHER

I A R D HITS "NEXT" IREST SAME AS

I PHONE

RADIO

J MICS PROMPTS RADIO DISPATCHER

IRADIO IDISPATCHER IHITS 'NEXT'

,L IRD READS I RADIO I NOTIFICATION I SCREEN I

I RD ENTERS UNIT ACKNOWLEDGEMENTS INTO STATUS ENTER PANEL

i

DD REVIEWS,MODIFIES RECOMMENDED DIS- PATCH SCREEN "HITS RELEASE"

I N O T I F I C A T I O N

T E L E P R I N T E R & TELEPRINTER 1 MESSAGES TO FIREHOUSES

I UNITS ACKNOWLEDGE ] VIA SELECTOR PANELS IN FIREHOUSE

I S T A T U S M O N I T O R I N G

ADDITIONALNEEDED? UNITS 1

WHO HAS NOT L__~PR PT ACKNOWLEDGED? OM

REQUIRED?

INCIDENT & UNIT STATUS UPDATES FROM FIELD

OVERVIEW OF ALARM ROCESSlNG

!

(15 SECOND DELAY UNLESS TELEPRINTER

DOWN)

V O I C E q

I MICS PROMPTS VOICE DISPATCHER

I VOICE DISPATCHER HITS "NEXTI'

l VD READS voICE ~OTIFICATION (UNLESS ALL UNITS HAVE ACKNOWLEDGED)

VD ENTER UNIT ACKNOWLEDGEMENT INTO STATUS ENTRY PANEL

FIGURE 3

476

_~)

(2) and (3)

OP•ATOR PRESSE 1 KEY

IMICS POLLS

i,,, I

I CHARACIER TRANSMITTED OVER DH MULTIPLEXER

I MICS HIGHEST PRIORITY PROGRAM "DHSlLO" EMPTIES SILO EVERY I0

WHEN END OF TEXT CHARACTER RECEIVED BUFFER PASSED TO QUEUE CONTROL PROGRAM

II UEUE CONTROLLER NITIATES APPLI-

CATION TASK - PASSES BUFFER 0 IT

IF MAXIMUM ALLOWED TASKS ARE ACTIVE WAIT IN TASK .QUEUE

IF PROGRAM IS NOT IN CORE LOADER PROGRAM LOADS IT

J ®

(2)

(2)

(2)

(3)

PROGRAM WAITS UNTIL CPU IS AVAILABLE

I CPU PROCESSING UNTIL I /0 IS REQUIRED

I RELEASE CPU TO PERFORM I/0

I TASK SWITCHING OCCURS - OTHER APPLI- CATION OR IDLE TASK

~ISK HANDLER I IPROGRAM CPU

I PROCESSING

DiF DISK IS NOT AVAIL- ABLE WAIT IN

ISK QUEUE

PERFORM I/O

MESSAGE BUFFERS PASSED TO QUEUE

CONTROLLER

SIMPLIFIED MESSAGE FLOW THRU MICS~I j l ~

FIGURE 4

( I ) This f low occurs each time a CRT funct ion key is pressed.

(2) Contention for CPU by programs - lower p r i o r i t y tasks are preempted. (3) Contention for disk.

(2) and (3) I

QUEUE CONTROLLER INITIATES OTHER TASKS AND/OR PASSES MESSAGE TO LINE CONTROL

I TRANSMIT MESSAGE TO CRT(s)

LINE CONTROL

I LINE CONTROL PROGRAM (LC) POLLS 1CRT FOR INPUT

ILC POLLS 1 STATUS ]ENTRY PANEL FOR

I INPUT

L

l OLLS ALL ELECTOR PANELS

POLLS ALL TERMINALS FOR OUTPUT

t C WAITS 90 ILLISECONDS

l

477

MICSIM - FDNY's S i m u l a t i o n M o d e l . . . C o n t ' d

The e x p e r i e n c e s d e s c r i b e d in t h i s paper demons t ra te t h a t a s i m u l a t i o n model o f a system not on l y he lps to answer these q u e s t i o n s but may, in f a c t , be the on l y means to assure t h a t the c o r r e c t s teps are taken to ach ieve the d e s i r e d p e r f o r - mance.

Even e a r l y i n c o r p o r a t i o n o f a s o p h i s t i c a t e d per fo rmance m o n i t o r [ I ] to make c a r e f u l measurements o f CPU u t i l i z a t i o n , t a s k - b y - task CPU and I / 0 a c c o u n t i n g , and measure- ments o f the e lapsed t ime o f tasks ( response t i m e s ) , o n l y enab led us to a s c e r t a i n a measure o f the pe r fo rmance and not to e x p l a i n the reasons f o r the p e r f o r - mance. The measurements t o l d us where we s t o o d , bu t we were f r u s t r a t e d in d e t e r - m in ing what s teps to take to a c h i e v e our pe r fo rmance g o a l s . The i n c r e a s e d overhead r e q u i r e d to i n t e r n a l l y e x t r a c t enough data to p i n p o i n t the cause o f de lays in the system would have caused enough i n t e r f e r e n c e to i n v a l i d a t e the measure- ments. The amount o f work i n v o l v e d in i n t e r p r e t i n g these measurement was y e t a n o t h e r f a c t o r l e a d i n g to the s i m u l a t i o n approach . I t was a t the p o i n t when s e v e r a l key pe rsonne l who s t u d i e d the PM r e p o r t s were unab le to p i n p o i n t the component (s ) r e s p o n s i b l e f o r l i m i t i n g sys - tem t h r o u g h p u t , t h a t the idea o f a s i m u l a t i o n model was born . F o r t u n a t e l y , in our case, the need f o r a s i m u l a t i o n model was r e a l i z e d in t ime f o r us to employ t h i s t e c h n i q u e in o r d e r to unde r - s tand the system response t i m e s , make a d j u s t m e n t s , and u l t i m a t e l y ach ieve the d e s i r e d pe r fo rmance . The rema inde r o f t h i s paper d e s c r i b e s the MlCSlM s i m u l a t i o n model , w r i t t e n in GPSS H (an i n t e r a c t i v e v e r s i o n o f GPSS), and d i s c u s s e s some o f the s t u d i e s t h a t were pe r fo rmed w i t h the model i n c l u d i n g examples o f the s teps t h a t were taken to meet the pe r fo rmance s p e c i - f i c a t i o n s .

An i n t e r e s t i n g f o o t n o t e is t h a t the model i d e n t i f i e d the CPU as the p r i n c i p a l b o t t l e - neck in the sys tem, whereas p r e v i o u s l y , we t h o u g h t t h a t the CPU was no prob lem. I t was o v e r l o o k e d as a b o t t l e n e c k because MICS tasks o r d i n a r i l y took l ess than I00 m i l l i s e c o n d s so t h a t even a t peak r a t e s o f 1 to 2 tasks per second, i t seemed t h a t CPU a v a i l a b i l i t y would be ample. Even c o n s i d e r i n g the communica t ions overhead ( l i n e c o n t r o l ) , t h i s seemed to be t r u e . What we d id no t v i s u a l i z e was t h a t the s e r v i c e overhead ( l o a d i n g t a s k s , I / 0 , task s w i t c h i n g ) which occurs d u r i n g task e x e c u t i o n would lead to such h igh CPU u t i l i z a t i o n a t the t ime when the tasks r e - q u i r e the p r o c e s s o r . Our i n i t i a l guess was t h a t the d i s k was the b o t t l e n e c k , and, in f a c t , we expec ted t h a t MICSIM would prove t h i s t h e o r y .

3. The MICSIM Model An O u t l i n e

MICSIM is a model which s i m u l a t e s the f l o w o f messages as they are t r a n s m i t t e d over l i n e s by v a r i o u s hardware d e v i c e s and s i m u l a t e s t h e i r p r o c e s s i n g by the r e a l - t ime system s o f t w a r e in the MICS system. Th is model is w r i t t e n us ing GPSS which is an i d e a l language f o r s i m u l a t i n g the f l o w o f t r a n s a c t i o n s th rough a system which " s e r v i c e s " them, ( i . e . , a system where queues may form because o f the f i n i t e r e s o u r c e s and t ime r e q u i r e d to process the t r a n s a c t i o n s ) . By chang ing o n l y a few c a r d s , r e p r e s e n t i n g GPSS f u n c t i o n and v a r i a b l e s , i t i s p o s s i b l e to va ry the a larm mix (BARS, ERS, Phone) , the a larm r a t e , ( a l a r m / m i n u t e ) , to change the p ro - c e s s i n g speed o f ha rdware , s o f t w a r e , e t c . , and to change the d i s t r i b u t i o n s o f the s e r v i c e and a r r i v a l t imes and the number o f d i s p a t c h e r s . Th is made i t easy to use the model f o r s e n s i t i v i t y a n a l y s i s and i d e t e r m i n i n g the " b r e a k i n g p o i n t s " in the system. For example , an a n a l y s i s was done on how d i s p a t c h t imes va ry depend ing on i n - coming a larm r a t e s and number o f d i s p a t c h - e r s . The f i r e depa r tmen t used the r e s u l t i n g a larm response data and i n f o r m a t i o n about u n i t a v a i l a b i l i t i e s as the bas i s f o r d e v e l - op ing s p e c i a l ( " f a l l b a c k " ) d i s p a t c h i n g p rocedu res f o r use d u r i n g p e r i o d s when a larm r a t e s are u n n a t u r a l l y h igh ( b l a c k o u t s or d i s a s t e r s , Four th o f J u l y , e t c . ) . These p rocedu res i n c l u d e s p e c i a l s t a f f i n g ( t he use o f an a d d i t i o n a l d i s p a t c h e r to he lp work o f f the D e c i s i o n D i spa t ch queue ) , as we l l as p o l i c y measures ( chang ing the num- ber a n d / o r t ypes o f equ ipment r e q u i r e d to respond to a p a r t i c u l a r type o f i n c i d e n t ) [ 2 ] .

Communicat ion

When an Alarm R e c e i p t d i s p a t c h e r comp le tes e n t e r i n g or r e v i e w i n g i n f o r m a t i o n on h is s c r e e n , b e p resses the RELEASE f u n c t i o n key. When MICS p o l l s h is CRT and d e t e r m i n e s t h a t t h e r e is i n f o r m a t i o n to be t r a n s m i t t e d to the CPU, i t a l l o w s the t r a n s m i s s i o n to occu r . The data is t r a n s m i t t e d over a DEC's DH m u l t i p l e x e r ( d i r e c t memory access on o u t p u t ) where each c h a r a c t e r is p laced in a s i l o used to s t o r e i n p u t f rom a l l the DH l i n e s . Each c h a r a c t e r takes about a m i l l i s e c o n d to be t r a n s m i t t e d . Data f rom o t h e r dev i ces such as the S ta tus E n t r y Panels in the Cnmmunica- t i o n s O f f i c e and s e l e c t o r pane ls in each

f i r e h o u s e reaches MICS in a s i m i l a r f a s h i o n a l t h o u g h the p o l l i n g c y c l e s and t r a n s m i s s i o n speeds are d i f f e r e n t . For e x a m p l e , d a t a from the f i r e h o u s e f o r acknow ledg ing the r e c e i p t o f an a larm or f o r u p d a t i n a a u n i t ' s s t a t u s is t r a n s m i t t e d v ia DEC's DJ m u l t i p l e x e r ( c h a r a c t e r i n t e r r u p t i o n o u t p u t ) over 600 baud l i n e s . Each Dj l i n e is p o l l e d each t ime the l i n e c o n t r o l program is i n v o k e d , and the c h a r a c t e r - b y - c h a r a c t e r

47B

t r a n s m i s s i o n s are s t o red in a s i l o f o r DJ i n p u t . CRT l i n e s , are p o l l e d f o r i n p u t in a c y c l i c a l f a s h i o n (once each t ime l i n e c o n t r o l i s i nvoked) as are the S ta tus En t ry Panels which are used f o r e n t e r i n g i n c i d e n t and u n i t s t a t u s updates and can a lso be l o g i c a l l y connected to c o n t r o l a CRT.

The LINK and UNLINK b locks are GPSS i n - s t r u c t i o n s which make i t s imp le to s i m u l a t e p o l l i n g . Whenever a message i s genera ted a t a CRT or one of the o t h e r d e v i c e s , i t i s LINKED to a user cha in u n t i l a c o r r e s - ponding UNLINK i n s t r u c t i o n i s execu ted . Thus, the s i m u l a t i o n o f the l i n e c o n t r o l so f twa re i s a s i n g l e loop in which UNLINK b locks are executed a t the proper t i m i n g i n t e r v a l s . The e x e c t u i o n o f the UNLINK b lock a l l o w s the message ( t r a n s a c t i o n ) to be removed from i t s user cha in and con t i nue through a s e r i e s o f GPSS i n s t r u c - t i o n s s i m u l a t i n g the c h a r a c t e r - b y - c h a r a c t e r t r a n s m i s s i o n and subsequent s to rage i n t o the s i l o . Note t h a t because the l i n e c o n t r o l program runs at a lower p r i o r i t y than some o t h e r s e r v i c e r o u t i n e s , the ra te o f p o l l i n g may decrease as the a larm r a t e i n c r e a s e s . MICSIM p e r m i t t e d us to s tudy t h i s r e l a t i o n s h i p .

The c h a r a c t e r s t h a t are t r a n s m i t t e d e n t e r t h e i r r e s p e c t i v e s i l o s (one s i l o f o r each type m u l t i p l e x e r - - DH or DJ) where t'hey j o i n ano the r GPSS user cha in . They w a i t t he re u n t i l one o f the DHSlLO or DJSILO programs removes them i n t o a b u f f e r f o r t h e i r p a r t i c u l a r l i n e . These two programs are executed eve ry 20 m i l l i s e c o n d s and remove a l l the c h a r a c t e r s found in t h e i r r e s p e c t i v e s i l o s . I t takes a p p r o x i m a t e l y 40 microseconds to move each c h a r a c t e r . When an e n t i r e message o f the l i n e has been c o m p l e t e l y p laced in the b u f f e r , i t i s tu rned over to the Queue Cont ro l Program which , in t u r n , causes the a p p r o p r i a t e task to be i n i t i a t e d ( " a t t a c h e d " ) . These events are s i m u l a t e d in GPSS again us ing the LINK/UNLINK comb ina t i on to cause the c h a r a c t e r s to remain in the s i l o u n t i l the DHSILO and DJSILO programs are execu ted . The use o f the CPU f o r 40 microseconds per c h a r a c t e r removed from each s i l o is s imu- l a t e d by the PREEMPT of the CPU, the ADVANCE o f V2 or V4 (number o f c h a r a c t e r s on s i l o x 40 mic roseconds) and the RELEASE of the CPU. The c h a r a c t e r s pass through an ASSEMBLE b lock which has the e f f e c t o f ho l d i ng the b u f f e r u n t i l the end o f t e x t c h a r a c t e r i s removed from the s i l o .

Task Process in 9

Each i n p u t message r e s u l t s in the execu- t i o n o f an a p p l i c a t i o n t a s k , a sequence o f programs which process the message, update a p p r o p r i a t e t a b l e s and f i l e s , and a f o r - mulate response messages to the d i s p a t c h e r

who i n i t i a t e d the i n p u t message and /o r o t h e r d i s p a t c h e r s . For example, the r e l e a s e of a Recommended D ispa tch Screen is processed by a task which s t a r t s w i t h the program DDEDIT which can l i n k to as many as ten o t h e r programs to update u n i t and i n - c i d e n t s t a t u s t a b l e s and f i l e s , cause t e l e - p r i n t e r messages to be t r a n s m i t t e d to the f~ rehouses i n v o l v e d in the d i s p a t c h , prompt Voice and Radio d i s p a t c h e r s to n o t i f y the u n i t s , p r i n t a f i r e t i c k e t f o r the i n c i d e n t , check f o r uncovered response ne ighborhoods . These tasks per fo rm I / 0 to update the a p p r o p r i a t e f i l e s or p o s s i b l y to load pro- grams which are not found in core when they are r e q u i r e d . The l a t t e r i s done by the LOADER program whenever programs LINK to one another~ When an I / 0 i s i ssued by an a p p l i c a t i o n s program, task s w i t c h i n g occurs. One r e a d / w r i t e r e s u l t s in 6 task s w i t c h e s , each o f which takes .70 m i l l i s e c o n d s . Queue s e r v i c e s are r e q u i r e d by each task to t r a n s m i t ou tpu t messages to the e x t e r n a l dev i ces ( u s u a l l y the CRTs) or to i n i t i a t e independent t asks . The Queue C o n t r o l l e r i s then invoked and more I / 0 may occur . A l l the above p rocess ing was s i m u l a t e d in one GPSS s u b r o u t i n e c a l l e d TASK. Whenever a task was to be i n i t i a t e d , the amount o f CPU p rocess ing and the number o f I /Os are s to red in the t r a n s a c t i o n (GPSS t r a n s - a c t i o n s have parameters f o r s t o r i n g t h i s i n f o r m a t i o n ) and i t i s t r a n s f e r r e d to the TASK s u b r o u t i n e . The l oad ing o f programs, the w a i t f o r a v a i l a b l e co re , the p e r f o r - mance o f I / 0 i n c l u d i n g the e x e c u t i o n o f the d i sk hand le r program, RPDDT, and the seek and t r a n s f e r t ime o f the d i sk are a l l s i m u l a t e d . M u l t i - p r o g r a m m i n g s i m u l a t i o n is made p o s s i b l e by hav ing each task RELEASE the CPU when pe r f o rm ing I / 0 .

GPSS c o n v e n i e n t l y s i m u l a t e s the p r i o r i t y scheme o f p rocess ing programs. For example, the d i sk hand le r RPDDT is g iven the same p r i o r i t y in the GPSS model t h a t i t has in the MICS system. A p p r o p r i a t e p r i o r i t i e s are a l so g iven ~o L ine C o n t r o l , Queue C o n t r o l , Loader , and the r e a l - t i m e c lock h a n d l e r , and each o f the a p p l i c a t i o n t asks . GPSS a u t o m a t i c a l l y p rov i des queue and u t i l i z a t i o n s t a t i s t i c s f o r the d i s k , the CPU, and f o r core ( the t h ree g r e a t e s t p o t e n t i a l b o t t l e n e c k s ) .

Through the use of o t h e r GPSS f e a t u r e s , i t was p o s s i b l e to deve lop a c r o s s - m a t r i x o f preempt ing versus preempted programs showing the r e l a t i v e amounts o f t ime i n v o l v e d . A s i m i l a r m a t r i x was developed f o r w a i t i n g tasks versus the t a s k ( s ) or system program(s) caus ing the w a i t . I t i s i n t e r e s t i n g to note t h a t on l y a modest number o f i n s t r u c t i o n s were r e q u i r e d to s i m u l a t e a m u l t i - p r o g r a m m i n g env i ronment .

4. Making Dec is ions Using MICSIM

479

MICSIM - FDNY's Simulation Model . . . Cont'd

This section discusses the output of the model and describes some of the studies which we performed with MICSIM to f ind ways to improve performance.

The single most important piece of in fo r - mation that the model provided was the fact that the CPU was the major bo t t le - neck in the system, s i g n i f i c a n t l y more so than e i ther the disk or core. Table l is a machine component analysis extracted from the output of the MICSIM model. I t should be noted that GPSS automatical ly provides queueing and u t i l i z a t i o n s t a t i s t i c s as well as frequency d is t r ibu t ions of t r ans i t times without the need of addit ional coding. Queue s t a t i s t i c s for the CPU show that each time a task completes an I/O and returns to continue processing, i t s aver- age wait for the CPU is 80 mil l iseconds. The most t i m e - c r i t i c a l p rograms, such as DDRECM and DDEDIT, which are used to recommend d i s p a t c h ass ignments and n o t i f y the u n i t s in the f i r e h o u s e where to go, pe r fo rm more than I0 such I /Os and hence spend a s i g n i f i c a n t p o r t i o n o f t h e i r t ime w a i t i n g f o r the CPU. The queue s t a t i s t i c s f o r CORE and DISK f o r these programs show r e l a t i v e l y small wait times.

The storage and f a c i l i t y s t a t i s t i c s des- cribe the u t i l i z a t i o n of the hardware and software components. The communication l ines are treated as f a c i l i t i e s as is the CPU since they process one transactinn at a time representing characters and tasks, respect ively. CPU u t i l i z a t i o n , for the 3-alarm per minute simulat ion, is shown to be 75% with the average seizure of the CPU being lO mil l iseconds. From the

TABLE I. MACHINE COMPONENTS ANALYSIS

UTILIZATION (%)

Alarms/Min CPU Core Disk

i 52.6 18.1 17.8 2 60.8 25.2 23.4 3 (i DD) 75.3 45.7 35.6 3 (2 DDs) 72.5 44.0 33.4 6 (i DD) 79.3 52.7 38.2 6 (2 DDs) 88.6 79.7 48.1

WAIT TIME (Sec.)

Alarms/Min CPU Core Disk

i .04 .01 .01 2 .05 .01 .01 3 (I DD) .08 .07 .01 3 (2 DDB) .09 .13 .01 6 (i DD) .i0 1.31 .01 6 (2 DDs) .14 .86 .02

storage s t a t i s t i c s , we can seen the behavior of components which can serve more than one entry at a time. For example, the number of characters entering the s i l o , the average time they spend there, and the maximum number in the s i l o at one time are a l l shown. In this run, a maximum of 26 characters were found in the DH s i lo at any one time. We know a SILO can hold a maximum of 64 characters. A hardware in ter rupt for the DH SILO program was set to occur i f the number of characters in the s i l o exceeded 32. The user chain s t a t i s t i c s t e l l us how long messages wait to be polled on the i r respective l ines. Histograms of task elapsed times are given for each type of task as well as one for a l l tasks. F ina l ly the 'task versus task preemption' and 'CPU wait time' matrices describe why and by whom each task is preeempted from the CPU and why, how long, and

f o r whom each task must wait for the CPU.

The CPU u t i l i z a t i o n , the p o l l i n g t i m e s , and the e lapsed t ime o f task agreed ve ry c l o s e l y to those measured from the ope ra - t i o n a l system. Th is gave us c o n f i d e n c e in the v a l i d i t y o f the model and t r u s t t h a t the b o t t l e n e c k which i t p i n p o i n t e d (CPU) was c o r r e c t . Th is was s u b s t a n t i a t e d when we e v e n t u a l l y cu t CPU p r o c e s s i n g t ime o f key s o f t w a r e e lements and improved per fo rmance as p r e d i c t e d .

NOTE: CPU and Disk wait times are for each I/O

done by a task.

DD = Decision Dispatcher

480

F igu re 5 is an average p r o f i l e o f DDEDIT, a h i g h l y c r i t i c a l and t ime consuming t ask . I t occurs f o r each a larm and any de lay which i t causes w i l l h i n d e r the D e c i s i o n D i s p a t c h e r (DD), who must r ev iew the d i s - patch recommendat ions and make d i s p a t c h ass ignmen ts . S ince a larms are f u n n e l l e d to h is p o s i t i o n by s e v e r a l Alarm R e c e i p t D i s p a t c h e r s , h is is the p o s i t i o n most l i k e l y to deve lop a queue ing prob lem. The p r o f i l e shows DDEDIT w a i t i n g f o r the CPU f o r more than a second, spend ing a lmost 0 .5 seconds p e r f o r m i n g I / 0 and w a i t i n g f o r i n i t i a t i o n f o r 120 m i l l i - seconds. Dur ing t h i s p a r t i c u l a r 3 -a la rm per minute s i m u l a t i o n , the number o f task i n i t i a t o r s was t h r e e , which was adequate to reduce average task w a i t f o r i n i t i a t i o n to l ess than 0.13 seconds (see Table 1 ) . The model a l s e y i e l d s a h i s t o - gram o f DDEDIT e lapsed t imes ( i . e . , the i n t e r v a l between i n p u t message r e c e i p t and the t ime When the f i r s t c h a r a c t e r o f the response is r e t u r n e d ) .

A p r e v i o u s s i m u l a t i o n run showed ( i n the task versus Task Wait M a t r i x ) t h a t the DDEDIT program was f r e q u e n c y "s lowed down" by a l ess c r i t i c a l program, SUMCRT, which r e q u i r e d 0.5 seconds o f CPU and per fo rmed f o u r I /Os a t the ve ry end o f i t s p r o c e s s i n g . The SUMCRT program s imp ly updates the summary d i s p l a y s o f i n c i d e n t s c u r r e n t l y a c t i v e in B r o o k l y n . Lower ing the p r i o r i t y o f SUMCRT d r a m a t i c a l l y reduced the response t ime o f the d i s p a t c h e d i t t ask . Other s i m i l a r cases were found where in a l ess c r i t i c a l task c o n s i s t e n t l y ' i n t e r f e r e d ' w i t h one o f a more c r i t i c a l n a t u r e . S i m i l a r p r i o r i t y changes improved the o v e r a l l response t imes o f the c r i t i c a l t a s k s .

MICS SIMULATION MODEL

3 Alarms Per Minute

TASK PROFILE - DDEDIT

• Waiting for Core (3 initiators) : 120MS

• Waiting for CPU (i) = 1068MS

3. Waiting for Disk = 96MS

4. Performing I/0 = 480MS

5. Executing CPU = lOOMS

6. Preempted (interrupted) by (different than

waiting for)

LOADER = 36MS

RPDDT = 13MS QUEUE CTL = 30MS

LINE CTL = IOMS

TASK SWITCHING = 19MS

1.972 sec.

FIGURE 5 (i) Wait for other tasks as well as system routines

A f t e r d i s c o v e r i n g the CPU as the pr ime b o t t l e n e c k , a c o n c e r t e d e f f o r t was made to shave p r o c e s s i n g t ime from c r i t i c a l s e r v i c e r o u t i n e s which were r e s p o n s i b l e f o r a good deal o f CPU p r o c e s s i n g d u r i n g the pe r i ods o f t ime when the a p p l i c a t i o n s programs a l so r e q u i r e d the CPU. These r o u t i n e s are the d i s k d e v i c e h a n d l e r , the l o a d e r , the r e a l - t i m e c l o c k h a n d l e r , the s c h e d u l e r , and the task s w i t c h e r . By a l t e r i n g p r i o r i t i e s , r e f i n i n g the s e r v i c e r o u t i n e s , and chang ing some of the a p p l i - c a t i o n s programs, we were ab le to meet the s p e c i f i e d per fo rmance g o a l s .

s i m u l a t i o n mode l ing he lped us to make the d e c i s i o n not to buy more core ( i n c r e a s i n g the two machines from 96K to 128K words) but r a t h e r to implement s o f t w a r e changes to reduce CPU p r o c e s s i n g as d e s c r i b e d above.

Summary

The development of a simulation model for this real-t ime system was not only bene- f i c i a l but necessary for developing an understanding of system performance. The insights obtained allowed us to meet speci- f ied performance goals for the system. In addit ion, i t was possible to project the dispatch times under increasing alarm rates with d i f f e ren t quant i t ies of dispatchers. The saturation point of MICS was determined This is the point where system response time becomes the l im i t ing factor not the number of dispatchers.

Work has begun on the CMICS s i m u l a t i o n model which w i l l be comple ted f o r the des ign phase and used to make i n t e l l i g e n t des ign t r a d e o f f s and ana l yze p r o j e c t e d pe r fo rmance . The CMICS system is even a g r e a t e r c h a l l e n g e f o r s i m u l a t i o n mode l i ng , s i nce i t i n c l u d e s a communicat ion ne twork emp loy ing c o n c e n t r a t o r s in each borough which c o n t r o l the message f l o w to the c e n t r a l computer . O b v i o u s l y , we b e l i e v e s i m u l a t i o n t o o l s should be c o n s i d e r e d in the deve lopment o f any o t h e r l a r g e r e a l - t ime system.

Acknowledgments

The a u t h o r wishes to acknowledge the e f f o r t s o f Dr. H. M o n t v i l l a , R. Scherma, C. F a r i s , J. Keenan and JL F i t z p a t r i c k o f B rad fo rd N a t i o n a l C o r p o r a t i o n and J. Mohan, I . S t e i n b e r g and L. R a i l i n g o f the New York C i t y F i r e Depar tment .

B i b l i o g r a p h y

I . An Env i ronmen ta l S i m u l a t o r f o r FDNY's Computer Aided D ispa tch System - J. Mohan, M. G e l l e r - 2nd I n t e r n a t i o n Confe rence on So f tware E n g i n e e r i n g October 1976.

481

2. MICS Brooklyn GPSS S imula t ion - Dis- patch Performance Pro jec t ions - M. G e l l e r , L. R a i l i n g - I n t e r n a l FDNY document.

3. Design of Real Time Computer Systems - Prent ice Hal l - 1967 - J. Mar t in .

4. Real Time System Design - E. Yourdon - Cambridge In fo rmat ion and Systems I n s t i t u t e .

482