An Approach to End-to-End System Simulation

An Approach to End-to-End _ _

Simulation Thomas V. Huynh

Advanced Technology Center Lockheed Martin Missiles & Space Co.

3251 Hanover Street, Palo Alto, CA 94304 (408) 756-1486, [email protected]

"'Beginning at the beginning,' the King said, gravely, 'and go 'til you come to the end; then stop. "

Lewis Carroll

Abstract -- We describe an end-to-end system simulation approach which employs UNIX programming, shared memory and semaphores for interprocess communication (IPC), and SESlworkbench [4] as a modeling and simulation environment. We illustrate it with a rather simplified K9 defense system (K9DS). We also provide the C code segments effecting the communication among the processes of the K9DS simulation, which runs on a workstation# with a single CPU.

TABLE OF CONTENTS

1. INTRODUCTION 2. APPROACH 3. ILLUSTRATION WITH K9DS 4. CONCLUSION

1. INTRODUCTION

Simulation is a viable means for evaluating the performance of large, complex military and aerospace systems. It enables a meaningful and complete evaluation of the performance of such systems. A simulation is a logical system consisting of logical processes to simulate a physical system [l]. It duplicates the behavior of a physical system, using asynchronous logical components representing the actual components of the system. Simulation involves designing and putting together a

# The KBDS simulation runs on an HP workstation. Any end-to-end simulation built with our approach can run on workstations which hosts the SESlworkbench software.

System

Howard G. Titrud Missile System Product Center

Lockheed Martin Missiles & Space Co. 1 1 1 1 Lockheed Martin Way, Sunnyvale, CA 94089

(408) 756-5583.

model (a computer program) to represent a system of interest and carrying out experiments on it as it progresses in1 time. Modeling a system amounts to writing computer programs to represent the system components and assembling them to construct the system model. In our work, the computer programs are third-party, independently developed (in either C or FORTRAN) and must be glued together to simulate the system.

Interactions among many complex components of a system are triggered lby events that occur in their deployment or operations. An end-to-end simulation starts with an instigating event and ends with a concluding event. An instigating event precipitates a response from the system or sets it in motion, while a concluding event marks the end of the response of the system. Like the actual components of a system, the computer programs (processes) are executed concurrently (that is, they share the same CPU or share memory in the same time frame) and need to communicate asynchronously among themselves. A process is an instance of a program in execution; its execution has started but has not terminated [3]1. The mechanism by which a program becomes a process is discussed in great detail in Ref. 3. Gluing the separate computer programs must thus allow for concurrency and communication among the corresponsing processes; (hence the phrase interprocess communication (IPC)).

Interprocess communication means the processes can send messages and/or data to each other while the simulation is run; one cannot wait until the simulation is completed before passing the messages. To achieve this, they may share a given region of memory, hence the phrase shared memory. Shared memory is the fastest form of interprocess communication [3], for the data need not be

0-7803-374 1 -7/97/$5.00 0 1997 IEEE

447

copied between the client and server. The only trick in using shared memory is synchronizing access by multiple processes to the shared memory. Semaphores, which are data structures, do the trick. In this work, we employ standard C and UNIX programming [2 , 3, 8, 91, which supports concurrency and interprocess communication, and, specifically, we implement shared memory and semaphores to effect communication among the different processes.

As part of our approach to end-to-end system simulation, we select SESlworkbench [4] as a modeling and simulation environment. It enables graphical construction of the system model as well as the simulation controller. The latter connects all the diverse computer programs and controls their simulation. SESlworkbench was not selected in an arbitrary fashion. In fact, the initial intent for using SESlworkbench was to model and simulate communications networks to support analysis of performance of networks and computers [5 ] . But in the course of our simulation work at Lockheed Martin we, having gone through some lengthy investigation, realized that the Workbench environment was well suited to building end- to-end system simulations by integrating third- party C codes with Workbench models. Our investigation culminates in the approach described here, which is thus closely tied to the Workbench environment.

The graphical environment of Workbench allows model building from a palette of icons, which can be interconnected by arcs to form a hierarchy of directed graphs [6] denoting the system behavior. C codes can also be inserted in the model nodes to describe precise behavior. Model parameters can be entered from the command line or read from a data file, enabling scenarios to be simulated without rebuilding the model.

We have successfully employed our end-to-end system simulation approach to develop an end- to-end simulation of an air defense system. Performance evaluation is critical for the design, planning, improvement, and operation of complex systems such as the air defense system. Such a simulation is a relatively inexpensive method for evaluation of the air

defense system and will be used to (1) gain understanding of the behavior of the air defense system, (2) obtain estimates of average performance measures, (3) guide the selection of design parameters and/or operating strategies, and (4) fit the model to measurements of the system. As a matter of fact, the need for an end-to-end simulation of the air-to-air defense system motivates the development of our approach. In this paper, however, we demonstrate, mainly for the purpose of illustration, the end-to-end system simulation approach with a simplified defense system called K9 Defense System (K9DS). The K9DS is isomorphic to an air defense system. It has a surveillance camera (sensors) with a tracking algorithm, a security command post (battle management and command and control and communications and Intelligence (BMC3I) with an fire control algorithm, intruders (threats) and K9s (defensive weapons).

The goals of this paper are: Describe how we make use of

commercial-of-the-shelf tools such as SESlworkbench and existing facilities such as UNIX programming, shared memory, and semaphores to integrate third-party software modules into an end-to-end system simulation run on a platform with a single CPU.

Provide an example -- the K9DS simulation -- to illustrate the logic, simulation architecture, and Workbench models which underlie our approach to building end-to-end system simulations.

Supply the C code segments embedded in the K9DS Workbench models that are responsible for IPC and interaction among processes. A functional description of the user defined functions used in the C code segments and the relevant UNIX standard library functions are included. Using these C code segments and the synchronization logic explicitly enunciated herein, one with a general knowledge of C and UNIX and an introductory hands-on experience with SESlworkbench can readily construct end-to-end simulations of any complex aerospace and military systems.

The rest of the paper is organized as follows. Section 2.0 explains our approach and reveals the software (C code) embedded in the Workbench models of the K9DS example; the

448

C code implements the logic by which the processess communicate with each other using shared memory IPC. Section 3.0 discusses the end-to-end simulation of the K9DS and its results. Section 4.0 is the conclusion.

2. APPROACH

The ability to embed and/or link third party software from a variety of sources (developers) is crucial. One approach is to host the computer programs on a network of interconnected computers and to have a common interface at each of the computers and to allow them to communicate with each other during run time via UNIX sockets [6 ] . This approach is highly desirable if all the separate computer programs must reside at remote computers and if demonstration of a system concept is the main focus. In system performance analysis that involves, for instance, Monte Carlo analysis, this distributed simulation approach is not effective and quite inconvenient, if not outright impractical, because the uncertain availability and the slow or variable speed of the network can hamper the running of the simulation. In contrast, our end-to-end system simulation approach, which is predicated on running the simulation on a platform with a single CPU or multiple CPUs, is conducive to Monte Carlo analysis as required by our work.

As aforementioned, our end-to-end system simulation approach employs UNIX programming, shared memory and semaphores for interprocess communication (IPC), and SESlworkbench as a modeling and simulation environment. In this section we describe in detail our end-to-end system simulation approach and include elements of the code that make the gluing possible.

Interprocess Communication via Shared Memory and Semaphore

Again, in our approach, an end-to-end system simulation consists of an executive program and programs representing the various components of a system. The latter are called the non-executive processes during run time. The executive process controls the master clock and initiates and controls the non-executive processes. The primary means of interprocess

communication (IPC) among the processes is through the use of semaphores and shared memory.

Semaphore is derived from two Greek words: q p a meaning a sign or mark and QEPO meaning to bear or carry. A semaphore thus carries a signal from one process to another. In a nutshell, communication among all processes is the transfer of information among the processes during run time. During each time cycle, by using semaphores, the executive grants all supporting processes permission to read shared memory, waits until they all finish reading shared memory, grants permission to write to shared memory, and then waits until they all finish writing to shared memory. Conversely, each non-executive process waits for permission to read shared memory, signals that it is done reading, waits for permission to write to shared memory and then signals that it is done writing to shared memory. The semaphore operations thus consist of signaling and waiting, which are implemented by the UNIX C function semop(). The synchronization of access by processes to the shared memory follows,

Synchronization Among the Computer Processes

By synchronization it is meant an orderly, structured control of access to shared memory by a process, its action during the access, and the release of its control of the access.

The C function system() starts a new process; its argument - a character string - contains a UNIX command which includes the path name of the corresponding executable and two arguments -- a shared memory key and a semaphore key. With these keys, the process then obtains access to the shared memory, performs its action, and releases its control of the access to the shared memory. Two C functions, shmget() and semget(), are instrumental in providing, among other things, these two respective keys.

In specific terms, a process uses the C function shmget() to obtain a shred memory identifier (shmid) and to create a shared memory segment. Associated with the shared memory

449

identifier is a shared memory key, which is obtained by looping through a set of possible values until the key is found, which does not have a shared memory identifier associated with it. The C function shmat() then attaches the shared memory segment associated with the shared memory identifier. The process then calls the C function semget() to obtain a semaphore identifier (semid) and to create a semaphore IPC structure. Associated with the semaphore identifier is a semaphore key, which is found again by looping through a set of possible values until the key is found, which does not have a semaphore identifier associated with it. With these keys, the process now has access to the shared memory, performs its action, and subsequently releases its control of the access to the shared memory.

Following is the actual mechanization of the synchronization process, namely, the explicit logical steps taken by the executive and non- executive processes, respectively.

The executive controls the master clock, initiates processes and controls the processes. Table 1 depicts an abridged flow of the executive process.

Table 1. An Abridged Flow of The Executive Process

1. Read input and initialize. 2. Get shared memory area using

3. Get a semaphore using semget(). 4. Initiate a process using system(). 5. Repeat steps 3 and 4 for each new

process. 6. Allow the other processes to read shared

memory. 7. Wait until the other processes finish

reading shared memory. 8. Allow the other processes to write to

shared memory. 9. Wait until other processes finish

writing to shared memory. 10. Process messages and begin other new

processes as needed.

shmget().

1 1. Place in shared memory actions for the other processes.

12. Increment time. 13. Repeat steps 6 through 12 until it is

time to stop. 14. Clean up by freeing shared memory and semaphores. 15. Exit.

The non-executive processes are initiated, synchronized, and controlled by the executive. Table 2 contains an abridged generalized flow of a non-executive process.

Table 2. An Abridged Generalized Flow of A Non-Executive Process

1. Initialize. 2. Attach shared memory, using shmat(). 3. Get a semaphore, using semget(). 4. Wait for permission from the executive

to read shared memory. 5. Read shared memory including time and

execute commands. 6. Alert the executive that this process

finishes reading shared memory. 7. Execute commands. 8. Wait for permission from the executive

to write to shared memory. 9. Write to shared memory and execute

commands. 10. Alert the executive that this process

finishes writing to shared memory. 1 1. Execute commands. 12. Repeat steps 4 through 11 until time

for process to finish. 13. Clean up process by detaching shared

memory. 14. Exit.

Again, the executive and a non-executive process are synchronized using an semaphore with semop(). The steps dealing with waiting involve having the process wait until a semaphore value becomes a particular value. The steps dealing with permitting or allowing involve changing the value of the semaphore.

450

Send1ntruder.o i. 'a

'i, \L Q \.

Propce0utput.o \

L a ../utilities/util.a

Fig. 1 Workbench Executive Catalog

executive-declarations

l@l Global executive-headers e

process-segment

e initializeqrocess

+Ea+ exec-main

Fig. 2 Workbench exec-module Main Module

451

in intrusion

begin-executive Reference Reference increment-time to initializeqrocess to process-segment

operate-on-semaphores

end-executive terminateqrocesses free-shm-and-semaphores

Fig. 3 Workbench exec-main Submodel

i comm-module command-control ./ global-headers

I ./ \. I .*

i /./ *.\ i ,... i /_/

i .\.

.\. i ./ \.+e>.- \. -f + (> interprocess.. mal1char.o '.

'4. \.\. \. \. '.+a

../utilities/util.a

Fig. 4 Workbench Command Post Catalog

Index1 What 1 How

".. ., m.. . . , , ,

m interprocess-declarations"'.. . _ ._ ,

Global interprocess-headers

-+llElb clock-and-box

Fig. 5 Workbench interprocess Module

452

d begin-interprocess sim-clock-synchronizer t 4

write-tpshm 4,; 0;

initialize senhimage read--ac t ion

Reference end-interprocess to comand~control~comunicatioin

Fig. 6 Workbench clock-and-box Submodel

Workbench Models with Embedded C Code

This section contains the hooks (code) used to glue the various processes, which are embedded in the key Workbench models [6] corresponding specifically to the K9DS example.

The hierarchical structure of a Workbench model begins at the top with a catalog, which contains modules, each of which contains submodels, which in turn contain nodes and arcs [6]. A Workbench submodel is a directed graph, made up of nodes and arcs.

An explanation is in order on the notation. Workbench icons representing Workbench nodes, submodels, and modules are capitalized, while their names are italicized. For example, the execmain Submodel (Fig. 2) refers to the Workbench submodel named exec-main; the free-shm-and-semaphores User node (Fig. 3) refers to the Workbench node named free-shm-and-semaphores.

There are two separate Workbench models in this example, whence two separate catalogs: executivewb (Fig. 1) and commandwb (Fig. 3) . The other components of the K9DS are non-Workbench and represented by "third- party" software. Of course, they can also be modeled with SESlworkbench. The included C code comes from these two Workbench graph files, whose interaction is illustrated here.

Workbench catalog, executivewb (Fig. l), contains a Main Module icon, called exec-module, with Dependence Arcs (dashed lines with arrows) to Archive File icons (e.g., . ./utilities/utiVa) and Object File icons (e. g . , SendProtector.0). The Main Module icon represents the Executive Main Module with its Main function. The namies of the Archive File and Object File icons indicate the path names to the corresponding respective archive or object files. The Dependence arcs emerging from the Main Module indicate that the Main Module depends upon the archive files and object files.

The Executive Model -- Again, the executive model (or the end-to-end simulation controller) controls the master simulation clock and initiates and controls the component processes of the simulation. Fig. 2 contains the representation of exec-module (Fig. 1). Fig. 3 exhibits the graph of the exec-main Submodel. This is a cornerstone of the methodology espoused in this paper; the exec- - main Submodel represents the general structure of an executive iin our approach. The C code segments embedded in the icons (nodes) are revealed as we trace the exec-main graph. To facilitate the reading of the C code, we distinguish standard library functions from user (us) defined functions, which are shown in Table 3. The user defined functions* call the standard library functions appearing on the same line. Details of the user defined functions are excluded; their functional description is

Workbench Executive Catalog -- The executive (or the end-to-end simulation controller)

* Some of the user defined functions are based on prototypes developed by Dr. V. N. Do, who is no longer with Lockheed Martin Missiles & Space. Co.

453

given in Table 4. The relevant UNIX standard library functions are included and can be found in the online version of the UNIX manual (the man pages).

Workbench transactions are the basic entities representing execution of processes in a Workbench model [7]. A transaction flows

Table 2. C Functions Used

Functions For The Executive

User Defined Standard Library [ 2 , 3 ]

Readhp0 CreatS hm() shmget() shmat() GetASemkey() semget() semctl()

system() Chk4CompletnO

ProcessMsg() semget() semctl() system() IssueAction() ProduceQutput() Freesem() semctl() FreeShm() shmdt() shmctl()

QpSemh.IO semop0

Functions For The Command Component

User Defined Standard Library [ 2 , 3 ]

Amatrix() fopen0 fprint() exit() fscanf() fclose() getopt0 strcpy 0 atoi()

semget() exit()

Detactshmo shmdt()

AttachShmO shmget() shmat()

OpSemO SemoPO

exit()

from node to node, executing statements embedded in the nodes. The simulation begins with a transaction at the begin-executive Source node and continues to the read-input

User node, which initializes variables, reads an input file via

ReadInp(“inputtab”,&InpDat); I

The transaction then travels to a reference [7] to the initializeqrocess Submodel. Reference to initializeqrocess allows the submodel level to use the initializejrocess Submodel defined at the exec-module module level (Fig. 2) . The following lines or code embedded at this node create a shared memory segment, initializevariables, initiate a new non-executive (or component) process, get a semaphore, and create a file to be read by the new component process.

CreatShmO ; shm->nSteps =O; shm->time = 0; SemKeyID=GetASemKey(); j=SemKeyID%lO; i=SemKeyID/lO; shm->F’rocTyp[i]lj] = PT-TYPE1; shm->pid[i]lj] = 1; shm->component[O] .proc.SemKeyID=SemKeyID; shm-xomponent[O] .proc.action=ACT-INIT; shm->ComponentIdx[O] = 0; sprintf(UnxCmd, “cd ../componentdir/shm-inputs; xterm -sb -sl 1000 -e

../abs.component -m %d -s %d -p %d &,’, shm->ShmKey, SemKeyID,

shm-xomponentIdx[O]); system(UnxCmd);

Note: * Pl-TYPE1 is an enum variable used to specify the type of component process. * The structures component[] and componentIdx may be renamed to less generic names for the component.

Next, the transaction flows to the loop node, where a criterion to exit the loop is checked via

while (!Chk4Completn()); I

As the loop continues, the transaction flows to the begin-intrusion User node. Importantly, at this node the program gets access to the appropriate semaphore and spawns new component processes when appropriate based on input. In this example, the new process spawn here is the process that simulates intruders.

454

Table 4. Functional Description of User Defined Functions

User Defined Functions Functional Description

ReadInp() CreatShmO GetASemkey0

Chk4Completn()

OpSemMO ProcessMsg()

IssueAction() Produce Output() Freesem() Frees hm() Amatrix() AttachShmO

Detactshmo OpSemO

Read the input file and load input data. Create shared memory segment. Get an unused element from the semaphore set and create a new semaphore when needed. Check to see if the current time is greater than a specified stopping time. Perform semaphore operations on all active se,maphores. Process messages sent from the various components. Spawn processes. Set action flags. Set action flags. Open files and write output. Free semaphores. Free shared memory. Allocate a matrix of characters. Get shared memory segment identifier and attaches shared memory. Perform semaphore operations. Detach shared memory.

The transaction then traverses a reference to process-segment Submodel node. Again, Reference to process-segment Submodel, which is defined in the exec-module (Fig. 2), allows access by the exec-main Submodel. At this node the executive operates on semaphores to synchronize its actions with the other processes, by processing message data produced by the non-executive processes, initiating some other processes if needed, and setting action flags for the component processes, and write output. The action flags indicate actions to be performed by the various models during the next time step. The actions flags can have one of the following enum values ACT-INIT, ACT-RUN, ACT-ERM or ACT-NOP. The method at this node includes these statements:

OpSemM(ReadOp, 1); OpSemM(ReadWaitOp, 1); OpSemM(WriteOp, 1); OpSemM(WriteWaitOp, 1); ProcessMsgO; IssueAction(); ProduceOutput();

ReadOp, ReadWaitOp, WriteOp and WriteWaitOp are arrays of sembuf structures containing semaphore operations to signal to and wait for signals from the component processes.

The transaction flows next to the increment-time User node, where time is incremented via these statements:

shm->nSteps++; shm->time = shm->nSteps*shm->dt;

The transaction then travels back to the loop node, where once again the executive checks the loop exit condition. If it exits the loop, the transaction flows to the terminateqrocesses User node, where the folllowing statement sets action flags to terminate the component processes that have not yet been terminated.

shm->component[O] .proc.action = ACT-TERM;

The transaction then travels to the operate-on-semaphores User node, where it operates on the semaphores so as to allow the component processes to tcmninate themselves.

455

OpSemM(ReadOp, 1); OpSemM(ReadWaitOp, 1); OpSemM(WriteOp, 1); OpSemM(WriteWaitOp, 1);

Flowing into the free-shm-and-semaphores User node, the transaction frees the semaphore and shared memory segment with these statements:

Freesem(); FreeS hm();

Finally, this transaction terminates at the end-executive Sink node.

Having elaborated on the executive side of the interaction, we now elucidate the hooks on the non-executive process, in particular, the Workbench non-executive component.

The Workbench Component Or Non-Executive Model -- The second Workbench catalog, commandwb (Fig. 4) contains, among other things, the Main Module icon representing a component model (in this case, the K9DS command post) and the interprocess Module. It is the interprocess Module that effects the interface between the executive and the various modules making up the component model. The interprocess Module contains the key Submodel called clock-and-box. (Fig. 5), another key Submodel in our approach. In the graph (Fig. 6 ) representing the clock-and-box Submodel, the transaction begins at the begin-interprocess Source node and travels to the initialize User node. The method at the latter node initializes variables, reads an input file, attaches shared memory to an address, and gets access to the appropriate semaphore. The statements constituting the method are

argval = AMatrix(100, 100); if ((fpl = fopen(“inoutl”, “r”)) ==NULL)

I exit(1); 1

fprintf(stderr, “Can not read inoutl file. W’);

for(argnum=l; fscanf(fpl,”%s”, argval[argnum]) != EOF; argnum++ ); if (fclose(fp1) != 0)

( fprintf( stderr,”can not close inoutl fi1e.h); exit( 1); 1

while ((option=getopt(argnum, argval, “i:o:s:m:”)) != EOF)

I switch (option)

I case 3’ : strcpy(InpFile,optarg); break; case ‘0’: strcpy(OutFile, optarg); break; case 3’: SemKeyID = atoi(optarg); break; case ‘m’: ShmKey = atoi(optarg); break; 1

1 shm=AttachShm( ShmKey); SemKey = shm->SemKey[SemKeyID/lO]; if ((SemID = semget(SemKey, 0 ,O)) < 0)

{ fprintf(stderr, “main: semget() failed\n”): exit(-1); I

The transaction then flows to the read-uction User node, where, by means of the following statements, the process waits for permission from the executive (via semaphore) to read the shared memory and obtains the time, time step, and an action flag from the shared memory.

OpSem(shm, SemKeyID, ReadWait, 2); action=shm-xomponent[O] .proc.action; dt = shm->dt; timex = shm->time; nSteps = shm->nSteps;

There are three actions: initialize, run, and terminate. The action flag indicates which of the three actions to take during this time step.

The transaction now flows from the red-action User node to the send-image Split node. Here the ensuing statements in the method create instances of message containing structures, load these structures with data (including data obtained through the shared memory), and create a new sibling message transaction for each message sent to this process through the shared memory.

transaction-dataanumber-of-reports = shm->component 1 [O] .number-of-reports; for(i=O;ictransactiondata.number-of-reports;i++)

I transaction-data.report[i] .type =

transaction-data.report[i] .id =

transaction-data.report[i] .time =

shm->component1 [O].type;

shm->component1 [O].id;

456

shm->component1 [O].time;

shm->component1 [O] .position-x;

shm->component 1 [O].position_y;

split { category catl, phase phasel, quantity 1 , unshared };

The original transaction then flows from the send-image Split node to the sim-clock-synchronizer Delay node where it waits for a duration of one time step via

transaction-data.report[i] .position-x =

transaction-data.report[i] .position> =

1

delay shm->dt;

Workbench processes using the Workbench clock require a transaction loop with a Delay node to synchronize with the executive process. As shown in Fig. 6, the Delay node is between the reraa‘-action and the write-to-shm User node; that is, the time step takes place after the process has obtained permission to read shared memory and before the process alerts the executive that this process is done reading shared memory.

After the Workbench clock has registered the time delay, the original transaction flows to the write-to-shm User node. Here, the process signals the executive (via semaphore) that reading from the shared memory is completed, waits for permission from the executive to write to the shared memory (via semaphore), writes to the shared memory, and signals the executive (via semaphore) that writing to shared memory is done. The method consists of these lines:

switch (action) ( case ACT-INIT:

OpSem(shm, SemKeyID, ReadDone, 1); OpSem(shm, SemKeyID, Writewait, 2); OpSem(shm,SemKeyID,WriteDone, 1); break;

OpSem(shm, SemKeyID, ReadDone, 1); OpSem(shm, SemKeyID, Writewait, 2); strcpy(shm-xomponent[O] .proc.msg, sendto-shm.msg);

case ACT-RUN:

strcpy(send-to-shm.nisg, “”); OpSem(shm,SemKey [D,WriteDone, 1); break;

OpSem(shm, SemKeyID, ReadDone, 1); OpSem( shm, SemKeyID, Writewait, 2) strcpy(shm->component[O] .proc.msg,”end”); OpSem(shm,SemKeyl[D, WriteDone, 1); DetachShm(shm); exit(0);

case ACT-TERM:

The original transaction returns to the reat-action User node. The cycle continues until the action flag to terminate set by the executive is encountered . When the action to terminate reaches the write-to-shm User node, the process detaches the shared memory segment and terminates.

Meanwhile, the new message transactions flow from the send-image Split node a reference to command-control-communication Submodel. Transactions flowing out of the command-control-communication Submodel reference are destroyed in the endjnterprocess Sink node.

Again, to recapitulate, the exec-main and the clock-and-box submodels are the two critical Workbench graphs that glue the processes.

3. ILLUSTRATION WITH K9DS

We have successfully employed our end-to-end system simulation approach to develop an end- to-end simulation of an air defense system. In this paper, however, we demonstrate, mainly for the purpose of illustriation, the end-to-end system simulation approach with a simplified defense system called EL9 Defense System (K9DS). The K9DS is jsomorphic to an air defense system. It has a surveillance camera (sensors) with a tracking algorithm, a security command post (battle management and command, control, coimmunications, and intelligence (BMC3I) with a fire control algorithm, intruders (threats), and K9s (defensive weapons).

457

command-declarations

-+IF3 video-camera

+sit+ Global command-control-communication

Video-Image-Processing

+E3t+

Attack-Planning-Execution e +E3+ command-controlgost

Attack-Monitoring

+3l+

Fig. 7 Workbench command-control Module

SESIdesign 3.1 Index1 What 1 How

video-transmission-cable

11-71 48 Reference to video-camera

Reference to command-controlgost

Fig. 8 Workbench command-control-communication Submodel

The K9DS model contains an executive and the models representing the surveillance camera, the command post, intruders, and protectors (K9). The computer programs modeling the intruders, the surveillance camera, and the protectors are third-party, non-Workbench modules. Only the executive (Fig. 1) and the command post (Fig. 7, 8, and 9) are Workbench models. Fig. 9 shows the functions performed by the command post namely, Video-lmange-Processing , Attack-Planning-Execution, and Attack-Monitoring, modeled by the corresponding Submodels shown in Fig. 7.

The command-con trol-communication Submodel (Fig. 8 ) simulates the communication between the camera (Reference to video-camera) and the command and

commnd-controZ_post). We will not describe the C code embedded in these submodels, since it does not contribute to the discussion of the approach and the gluing issue.

control post (Reference to

The instigating event is the detection of the intruders by the camera. It obtains the position and identity of the intruders and sends surveillance reports to the command post. The command post then reads the reports, alerts

Reference to Video-Image-Processing

Reference to Attafk-Planning-Execution

Reference to Attack-Monitoring

Fig. 9 Workbench command-controlgost Submodel

K9s9 and sends messages to K9s to ~cx-n"md Let and denote the positions of an intruder an attack on the intruders. Upon receipt of an and a protector (K9) at time t, v p the attack 'Omand the K9s chase their protector's speed, and At the length of time assigned intruders. The camera now obtains interval. Then the protector chases the intruder the positions and identities of both the intruders and the protectors (K9s) and constantly sends according to the following scheme. Set reports containing the information to the G(t+At) =<(t), unless E- 4 >VpAt, in command post. The command post compares which case old camera images with new images to determine which intruders are still active. The concluding event is a confirmation by the

- - G(t+At) = rif(t) + Vp At - r1- rP E - q

command-post that the last intruder has been captured.

In words, from its position in the previous time steD a K9 moves in the direction of its assigned inkder by a distance equal to a constant Geed times the time step. If this distance exceeds the actual distance between the protector and the

that of its assigned intrude:r.

Intruders enter the surveillance area at a time and location and velocity specified by input. In

dimensional rectilinear motion with zero acceleration.

this Simplistic example, intruders follow a 2- intruder, then the K9's position is set equal to

459

100

80

60

* 40

20

0 0 20 40 60 80 100

X

Fig. 10 Trajectories of Intruders and Protectors (K9s)

The K9DS end-to-end simulation results are obtained with a scenario of three intruders. The time step is 1 (with appropriate time unit). For each intruder, a beginning time and an initial state (position and velocity vectors) are specified. In this example, Intruder 1 starts at (100,100) and moves with a velocity vector (- 1, -1); Intruder 2 starts at (50,50) and moves with a velocity vector (0,-1); and Intruder 3 starts at (100,O) and moves with a velocity vector (-1,O). The initial positions of the K9s coincide with the origin of the Cartesian coordinate system. The K9s all run with a constant speed of 3 (with appropriate speed unit). In this example, the K9s successfully catch all of the intruders.

In this paper we describe our end-to-end system simulation approach and we provide part of the necessary C code for gluing the different components of an end-to-end system simulation. Our end-to-end system simulation approach employs UNIX programming, shared memory and semaphores for interprocess communication (IPC), and SESlworkbench as a modeling and simulation environment.

We have successfully employed our end-to-end system simulation approach to develop an end- to-end simulation of an air defense system. In this paper, for simplicity and illustration purposes, we apply our approach to an example of defense system (K9DS) against intrusion.

4. CONCLUSION The requisite programming background for using our approach includes a general

460

knowledge of C and UNIX and <an introductory hands-on experience with SESlworkbench. With the description of the user defined functions and the synchronization logic explicitly enunciated in Table 1 and 2, our approach can be readily implemented for end- to-end simulation of any complex aerospace and military systems.

ACKNOWLEDGMENTS

The authors thank Dr. Steve Richard, Manager, Applied Systems, Advanced Technology Center, and John Snyder, Manager, System Analysis, Missile System Product Center, Lockheed Martin Missiles & Space, Co., for support.

REFERENCES

[ 11 J . Misra, "Distributed Discrete-Event Simulation," Computing Surveys, Vol. 18, No. 1, March 1986, pp. 39-65.

[2] W. R. Stevens, Advanced Programming in the UNIX Environment, Addison-Wesley, 1992.

[3] K. A. Robbins and S . Robbins, Practical UNIX Programming, A Guide to Concurrence, Communication, and Multithreading, Prentice-Hall, NJ, 1996.

[41 SESlworkbench is a registered trademark of Scientific and Engineering Software, Inc., Austin, Texas.

[5] T. V. Huynh and J . V. Lordi, "Simulation of m Air Defense Radio Protocol," 1996 IEEE Aerospace Applications Conference, Vol. 3, Snowmass, CO, Feb. 3-10, 1996, pp. 403-41 1.

[6] S. A. Rago, UNIX System V Network Programming, Addison-Wesley, 1993.

[7] SESlworkbench User's Manuals, Version 3.1.

[8] "UNIX in a Nutshell: A Desktop Quick reference for Sysrem V," OReilly & Associates, 1991.

Dr. Tom Huynh is a Senior Staff Scientist with the Advanced Technology Center (formerly, Pal0 Alto Research Laboratory), Lockheed Martin Missiles & Space Co. During his tenure at Lockheed Martin, he has engaged in research in nonlinear estimation, perturbation thelory, differential equations, and optimization. He has also developed and led development of simula6ions of satellite surveillance networks, defense systems, communications networks, managemenr;/communica!tions, control, and communications (BM/C3) systems. He obtained simultaneously a BS in Chemical Engineering and a BA in Applied Mathemutics from UC Berkeley and an MS and a PhD in Physics from UCLA.

Howard Titrud is a Senior Systems Engineer at Lockheed Martin Missiles & Space Co., where he has been working on trajectory and engagement analysis for 12 years. He obtained a BS in four diflerent fields, simultaneously: Mechanical Engineering, Economics, -- n Social Science, and Mathematics from Portland State University.

[9] M. G. Sobell, "A Practical Guide to the UNIX System," 3rd ed., BenjaminlCummings, 1995.

46 1