Proceedings o! the 1996 Winter Sirn71.lation C'on!eTen If

ed. J. AI. Cllarnes, D. J. AJorrice, D. T. Brunner, and J. J. Sn'ain

PROGRESS IN MODULAR SIMULATION ENVIRONMENTS

Charles R. StandridgeJames F. KellyThomas KelleyJack Walther

Department of Industrial EngineeringFlorida A & M University - Florida State University College of Engineering

2525 Pottsdamer StreetTallahassee~ FL 32310. U.S.A.

ABSTRACT

How each simulationist can design and implementsoft\vare tailored for each particular simulation projectis addressed by modular simulation environments. Therequirements of such cnvi ronmcnts are derived from thcneeds of four distinct types of users. Inter-toolmodularity deals \vith ho\v data £1o\,"s bct\veen a non­homogeneous sct of soft\vare tools that can be changedon an ad hoc basis. Both simulation spccific and \videlyapplicable soft\varc tools may be used. Theorganization and management of simulation inputs andresults to achievc this goal is important. Intra-toolmodularity has to do \vith supporting simulation projecttasks in a modular fashion. Modular modeling is \vcllestablished. Possibilities for modular animation and themodular use of \vidcly applicable tools. spccificallyspreadsheets. arc discussed. An example modularsimulation environnlcnt is given.

INTRODUCTION

Ideally. e3ch simulationist \vould be able to select theset of soft\"are tools to use on each si nlulation project(Standridge and Centcno. 1994). The selection wouldbe based on the particular requirements of that project.The tool set \\'ould contain both simulation specific toolssuch as model builders and simulation engines as \vellas tools \"ith \vide applicability such as ,,'ord processors.statistical analysis packagcs~ and spreadshcets.

Modular simulation environnlent concepts seek toproyide the standard by \vhich ad hoc collections ofsofuvare tools can be used together to perform asimulation project. These concepts specify ho\"simulation related data flo\vs bet\\'een tools in a general"'ay so that heterogeneous soft\\'are can \vork together.The concepts address ho\\' tools can be tailored for usc

714

on particular problems and ho\\' general purpose toolscan be tailored for application in simulation.

Modular simulation environments arc based on anapproach similar to that of computer operatingenvironments such as Microsoft Windov.s for personalcomputers and X-Windo\vs for Unix-based \\lork stationcomputers. The \vindo\\ling systems provide the design.structure and mechanisms for tool integration.Windo\,"s and X-Windo\\'s provide a user interfacestandard for soft\\"arc tools as \vell as standardmechanisms for sharing information bcl\\'ccn tools.

Some benefits of modular simulation environmentsare as [01l0\vs:

1. High flexibility for end user sclection ofsimulation soft\\'are. This supports sinlultaneous use ofsimulation soft\\'arc fronl multiple soft\\'are providers as,veIl as locally dcveloped tools.

2. Usc of \videly applicable soft,,'are \\lith \\'hichthe end user is already familiar.

3. Inclusion of tools such as spreadsheets. \\'ordprocessors and presentation graphics generators thathave not traditionally bcen a part of simulationenvironments,

4. Usc of standard "'indo\\'s techniques forsharing information bet\vccn tools.

5. Management and selective use of simulationinputs. results. and modcls.

6. Definition of a standard for simulationenvironment structure and user interface. Because of itsflexibility. end users may generally adopt such astandard and tool builders may find developing soft\varccompatible \vith its requirements helpful.

This paper describes the design and initialimplementation of modular simulation environments as\yell as an example application. Requirements fornl0dular sinlulation environments are based on theirfour different types of users. Thesc user types arcderived from those proposed by Standridge and Centeno

Progress in AJod111ar SiIllulatioll Environnlellts 'lIS

(1991). The flow of information bet\veen tools isdescribed. The use of modular modeling concepts totailor simulation specific and general purpose soft\\"aretools for particular applications is discussed. Modularmodeling for net\\'ork simulation languages is revie\ved(Standridge. 1995).

2 SIMULATION ENVIRONMENT OVERVIEW

Modular simulation environments are distinct fromthese existing environments in that the set of soft\\'arctools are not pre-determined.. the use of \videl)'applicable soft\vare is encouraged.. and the user­interface relics on the standards set by existinggraphical computer operating system interfaces.Database management must accommodate the open­ended nature of the en\'ironment.

3 USER TYPE REQUIREMENTS

\4odel L..en IIII

! A)lemalve 3 i

r----II S~"!Iem) i

Em~rI BwJden'l1F.rt\1fCIlIllIerl31

------

-----~todu.lcB-UlI<kn1

F!J ~)J I____ - I

r----JI S~em ~ .

_.1-

I E~]

I~-- r_~_1~3

Modular simulation environment capabilities arebased on the needs of four user types \\-'hose relationshipis given in Figure 1. The user types represent typicalroles. In any particular situation. the same individualmay take on multiple roles or many individuals mayparticipate in the same role.

Figure 1: Modular Simulation Environment User Types

An environment builder gathers the soft\\"are toolsthat form a simulation environment. The builder canconstruct multiple environments in this \\·ay. Forexample. an environment bui lder could select theSLAMSYSTEM simulation environment.. the PROOFanimation tool. and the EXCEL spreadsheet to comprisethe environment.

In addition. an environment builder tailors the engineof any tool selected. SLX (Henriksen. 1995) andY"ANSL (Joines and Roberts. 1994 and 1995) aresimulation engines. For example. the environmentbuilder could construct a ne\\' transaction creationmechanisnl in SLX that reads the time of the nextarrival and its attributes from a file as opposed to thetraditional specification of a random or constant timcbet\veen transaction creation. The extensibilit\,capabilities of SLX \vould be used to define the nc\·\"creation statement and encode the logic, The nc\\'

Traditional simulation environments have threemajor components: (1) a fixed set of software toolsprescribed by the environment designers andimplementers. (2) a database management system thattransparently to the environment users controls the flowof data behveen the soft\vare tools.. and (3) a userinterface that gives access to all environmentcapabilities. Each soft\vare tool uses existinginformation in the database and adds the results of itsown operations to the database.

TESS (Standridge.. 1985: Standridge and Pritsker.1987) \-vas an early.. pre-graphical user-interface.simulation environment built on this strategy. Soft\varetools provided for building SLAM II net\\'ork models.editing sets of SLAM II control statements. constructinganimations. making statistical computations. graphingdata. and reporting data. Simulation results could becollected automatically from SLAM II. GPSSIH.. andMAPII simulations. A conlnland language served asthe user interface. Selective querying of the database,,'as supported. A database subprogram library allo\\'edcomputer programs to store and retrieve data from theTESS database. The database manager organizedsimulation inputs and outputs.

Balci and Nance (1987. 1992) have used a similarstrategy in designing and inlplementing a simulationmodel development environment. This ,,"ork has lead tothe visual simulation environment (Balci et al. .. 1995).A visual user interface supports the development andsimulation of visual models that nlay be hierarchicaland object oriented. The collection of tools includes a\"isual editor. a library of existing component models. astatic model analyzer~ a nlodel dynanlics tester. asimulator. an analyzer for simulation results. a multi­media learning support system. and an e\'aluator foraccessing the credibility of a simulation study.

Centeno and Standridge (1991) describe aninformation based simulation environment constructedusing the same approach. Its distinguishing featuresinclude the description of a manufacturing system ofinterest as information stored in the database.Alternative models can be generated by querying thedatabase. In addition. a kno\vledge-based user interfaceis proposed to guide the user through the steps of asimulation project.

716 Standridge et ai.

Modular Simulation Environment Demonstration

Figure 2: Dcmonstration Modular SimulationEnvironment Tool Set

specific and ".idely applicable tools arc included. Toolsdeveloped to achieve inter-tool modularity arc sho\vn inlo\'~'er case.

SLAMSYSTEM is used for modeling and simulationactivities. It is interesting to note that anothersimulation environnlent can be used \\ithin a modularsimulation environment. PROOF provides animationcapabilities. EXCEL spreadsheets are used for modelinput value entry and for processing simulation results.ACCESS databases can be used to organize.. manage.examine. and present sinlulation results, A text editorhelps \\lith input valuc entry.

Template-based tools havc been dcvclopedspecifically for organizing. specifying. and optionallyentering model input values \\"ithin a modularsimulation environment. Multiple data sets can be inputto a model. A template or format is dcfined for eachinput data set. A list of tcmplates needed for aparticular simulation is maintained. A template toolprovides for defining the format of one input data sct.listing the input data scts necded for simulation input.and entering values.

Simulation result collection can be specified.Generic tools for organizing and collecting results areprovided. The capability to extract values from eachsimulation language of interest must be coded. This hasbeen done for SLAM II.

Results processing has to do \\'ith making simulationresults ready for input to other soft\\'are tools. Itincludes joining together results collected from thesimulation of multiplc alternatives. This facilitates thecomparison of alternatives.

Finally, a ne\\' tool can be attached to theenviron~ent. This involves describing the input dataformats It accepts and the format of the output data it

PROOF

ResultProcessing

ACCESS

ResultCollection

ToolDc-attachment

EXCEL

Inputs

SLAMSYSTEM

ToolAttachment

4 INTER-TOOL MODULARITY

One type of modularity in a simulation environmenthas to do \vith ho\\' data flo\vs behveen tools. This isreferred to as inter-tool modularity. It mustaccomplished in such a \vay that ne\\' tools can be addedto the environment on an ad hoc basis. No modificationof existing tools can be required though the ability toexport data and capabilities for tailoring existingfunctionality can be exploi ted.

Figure 2 sho\vs the tool set of the first demonstrationmodular simulation environment. Existing conlmercialtools are sho\vn in capital letters. Both simulation

statement could then be used as \vould any otherstatement.

A module builder deals with one environment. Theenvironment is tailored multiple times. once for eachapplication domain of interest.

Consider a module builder concerned with discreteparts manufacturing. Using the capabilities of thesimulation language selected by the environmentbuilder. the module builder could construct modules formodeling individual work stations, material handlingbetween work stations. serial lines and the like.Spreadsheet macros for processing observations ofperformance measure values could be written. Suchmacros could compute confidence intervals using themethod of replicates. help find the truncation point in asteady state simulation.. and graph simulationperformance measure observations. Interfaces to thesecapabilities \\"ould "speak the language" of the domain.Thus.. the simulation environment \\'ould more closely~~use the language" of the application domain. .

A model builder is concerned about multiple systemsin one domain. Using the domain specific modelingmodules provided by the module builder. a modelbuilder constructs a si mulation model of any particularsystem in the domain. Other tools tailored by themodule builder for the donlain can be further tailored bvmodel builder for the system. For example.. a tool fo'rgraphing time series of observations could be labeled asgraphing the number of parts ina buffer. The range ofthe number of batches considered in computing aconfidence interval from one series of observationscould be specified.

A model user evaluates nlultiple alternatives aboutone system. The alternatives are described using inputdata to the simulation model constructed by the modelbuilder. Other tools tailored by the model builder areused to exanline.. compare. and analyze performancemeasures resulting from sinlulations. For examples.spreadsheet macros can be used to graph performancemeasure values and perform statistical analysis.

Progress in Modular Simulation Environments 717

corresponding name in the simulation language. Forexample~ the performance measure, #INBUFFER couldcorrespond to the SLAM II function NNQ( I). A list ofthe simulation result sets to be gathered is created usingthe TEMPLATE tool.

Figure 4 sho\vs the flow of information for thecollection of simulation results. Each result template isdefined using the TErvtPLATE tool. A list of the all ofthe result templates desired for each simulation run isprepared. Based on the result template list, the resultcollector interacts \vith a simulation run to gather theperformance measure values of intcrest. The resul tcollector consists of a generic part and an intcrface to aparticular simulation engine. Results can be stored inan ACCESS database for further processing.

produces if these are non-standard. Standard formatsinclude text (ASCII) files~ spreadsheet files, anddatabase files. Existing tools may be removed.

Multiple data sets can be input to a model. Atemplate or format is defined for each input data set. Alist of templates needed for a particular simulation ismaintained. A template tool provides for defining thefonnat of one input data set. listing the input data setsneeded for simulation input:- and entering values. .

Figure 3 shows the flo,,' for input data. TheTEivtPLATE tool is used to describe the data. Valuescan be entered using anyone of a variety of tools,including a spreadsheet such as EXCEL, a text editorsuch as NOTEPAD, or the TEMPLATE tool. Thisillustrates how a variety of tools can be employed toaccomplish the same purpose in a modular simulationenvironment. Which tool is employed depends on eachparticular user. TENfPLATE

ResultCollectionTemplate

Result SLA.\f IICollector Inter-

face

SLA.I\1SYSTE~(

TEl\1PLATE

Input DataTemplate

• EX(::'EL.Text Edi tor,TEtvlPLATE

Input Tool­

Input Data IValues~

--...-

SLAMSYSTEM

U!\erData

----.------'----~

TEMPLATE

Li5l of InputTemplates

Data Fil~ TE~1PLATE

List of InputTemplates

ACCESS

Figure 3: Flo\v of Simulation Input Data

The TEN1PLATE tool also is used to define the datainput requirements of a simulation model. Thisdefinition is a list of the templates for \vhich valuesmust be supplied in order to run the simulation.Running a simulation requires creating a list of thespecific input data sets, one corresponding to eachrequired tenlplate. This list defines the simulation inputfor one particular simulation run. Again, this input datalist is created using the TElv1PLATE tool. The inputdata list and the input data files are supplied toSLAMSYSTEM in its standard form for user data.

Within an input data set values can be organizedinto ro,vs and columns. Each row gives new values forthe variables represented by the columns. Alternatively~

each ro,,, can correspond to a different variable. Aprompt at the beginning of the row specifies the inputrequirements.

The TEN1PLATE tool is used to define the simulationresults collected. Multiple result sets can be gatheredfor each simulation run. A template is given for eachset. The template shows the name of the performancemeasure as kno\\:n in the sinlulation result set and the

Figure --1-: Simulation Rcsult Collection

Result processing has to do \vith preparing simulationperformance nlcasure values gathered by the resultcollector for processing by other tools. Values ofdifferent performance measures from one alternativc(different result sets) or values of the same performancemeasure from different alternatives can be organizedtogether. EXCEL and PROOF can be used to analyzcand display performance measure values.

Result processing is summarized in Figure 5. TheTEtv1PLATE tool is used to specify which simulationresults from \vhich alternatives are of interest. Theresult processor produces a file of these result which beinput to another tool. Data files collected from thesimulation can be used directly in other tools if no re..organization of the simulation results is needed. Thissho\v the flexibility of a modular simulationenvironment is meeting user requirements.

718 Standridge et al.

Figure 5: Simulation Result Processing

Scenario -- What alternative is being described.Variable -- Identifying name of an input quantity.Value -- As specified by the nlodel user

The organization of input values and simulationresults is a fundamental aspect of achieving inter-toolmodularity. Input data arc labeled as follo\vs:

The second type of modularity has to do \\'ith ho\\'each tool does its \vork. Moduiar modeling conceptshave long been discussed and are \vell implemented. SecZeigler (1990). Cota and Sargent (1992). and Sandersonet al. ( ~ 992) for basic definitions. concepts. andexample lnlplementations.

6 INTRA-TOOL MODULARITY

Abrams. Standridge, et al. (1995) describe asimulation model of local caching policies. Files areretrieved via the World Wide Web to support distancelearning. Caching allows the files to remain local.avoiding multiple retrievals of the same file. Cachingpolicies tell \vhat files to replace when a ne\\' file tries toenter a full cache.

A modular simulation environment supports thismodel. There arc t\VO input data sets: simulationoptions and experiment specification. Typicalsimulation options are the number of replications ofeach experiment. internet transmission time for files.and the name of the file listing the names of the filesgiving the files transmitted on the internet. This inputdata set in organized \\'ith a different variable and itsvalue on each line. The experiment specificationincludes parameters such as the cache size. thereplacemcnt policy. and the parameters of thereplacement policy. It is organized in a tabular format\\ith one experinlcnt per fO\\". Columns correspond toexperiment parameters.

The TEMPLATE tool is used to describe the t,,'ofiles. The Windo\\'s notepad editor is used to entcrvalues. This sho\\'s the flexibility of a modularsimulation environment. Either the TEMPLATE tool.the notepad editor. or a spreadsheet could have used toenter the valucs. The model uscrs arc computcrscientists \\ho arc comfortable using the notepad editor.

Thc primary simulation rcsults are gathcred at theend of the simulation run (ty-pc end of simulation ani\')into one set. Results include the expcriment~1parameter values and performance nlcasures such as thehit ratc. the percent of files found in the cache \,"henrequested.

Statistical analyses. such as regression and ANOYA.are used to determine \vhich of the expcrinlcntalparameters significantly affect the hit rate. Thesestatistical analysis capabilities exist \\"ithin aspreadsheet. Since only one result set is collected. it isstore? by the results collector in a file fonnat acceptablefor dIrect spreadsheet input.

5 AN EXAMPLE MODULAR SIMULATIONENVIRONMENT

PROOF

EXCELResultProcessor

Result ValuesFil~

ACCESS orData Files

TEMPLATE

Result ProcessingTemplate

Note that there are multiple scenarios. versions.possible for each input data set. For exanlple. therecould be an input data set for the routes of parts througha job shop. Each scenario "'ould represent a differentpossibility for routing jobs through the shop.

In addition. that there are multiple input data sets.Thus. a simulation alternative is defined by a modeluser by specifying the sccnario of each input'data set tobe employed.

Performance mcasure values resulting from asimulation are labeled as in the follo\ving \\'ay.

Scenario -- What system alternative \\'as simulated.Type of values -- Time-persistent observed. trace.

end of simulation only,Replicate -- ID numberVariable -- Identifying nanle of an performance

measure.Time or time interval -- When observedValue -- As observed

For example. the follo"ing data sets could becollected: queue lengths. resource utilization, part timein the system. and throughput. The first t\VO are timepersistent the third obsen·cd. and the last end ofsimulation only.

For result proccssing. the utilization of a particularresourcc and the correspondi ng queue length could bejoined in a single data set. Alternatively. the queuelengths corresponding to a particular resource from eachof t\\"o scenarios could be joined for comparison of thet,vo alternatives.

Progress in AJodular SiInulatioIl EnvirOIlIllents 719

Standridge (1995) discusses modularity of net\vorksimulation languages and describes a modular networklanguage, ModNet. This paper defines thecharacteristics of a module and the communicationbct\\'een modules. Module parameters are passed to areceiving module via a construct that resembles callinga subprogram in a general purpose programminglanguage. Performance measure values are madepublic. that is accessible to all modules. Signals arepublic quantities that indicate that an event of note hastaken place in a module. Other modules may respond tothat event.

ModNet places bounds on the common entities of anehvork language. transactions and resources.Transactions may not cross module boundaries.Transactions may not be cloned. The need for cloningis satisfied by using a different module. A resource isdefined and controlled by one module. This modulemay pass a resource name as input to another module touse. For example. a module may define and control aVt'orker resource. The \vorker may perform tasks at t\vodistinct \\'ork stations. Each "'ork station is represcntedby a module. The name of the \vorker resource ispassed to each \\'ork station module by the defining andcontrolling module.

ModNet is being implemented in the SLX simulationengine. An environment builder uses the extensibilityproperties of SLX to define the fundamental modelingcapabilities available in ModNet. A module builderdevelops MOONet nlodules frool \\'hich a model builderconstructs nlodels.

Consider the possibilities for the use of modularityconcepts in other tools. A nlodcl user \vould like aspreadsheet interface and functionality tailored to thesystem under study. This could be constructcd asfol1o\\'s. The environment builder is unlikely to havethe capability of changing the spreadsheet engine. itscore functions. The module builder \,,"ould \vritespreadsheet macros that generate graphs and performstatistical computations generic to the domain ofinterest. For a exanlplc. a spreadsheet nlacro couldgraph the number of parts ina buffer versus simulationtime. Another macro could use the nlcthod of batches toestimate a confidence interval concerning the meannumber of parts in the buffer. The model builder couldfurther tailor these macros to refer to the specific buffersin the model and specify the number of batches used inthe confidence interval computation. Thus. the modeluser could simply ask for the graph of the number in thedrill press buffer and the confidence interval concerningthe mean.

Figure 6 sho\vs one possible organization foranimating a simulation. An aninlJtion is generated by ascript that specifies a time ordered list of changes to a

scene starting with an initial frame. Changes includemodification to object attributes such as color ormovement of objects. This sJXX:ification allo\\'s theanimation engine to produce a set of frames that sho\\'the time dynamics specificd by the script.

Figure 6: An Organization for Simulation Animation

The script can be based on the event trace producedby a simulation engine. A set of rules can be used tomap the evcnts of the simulation into a script thatproduces the animation of a simulation. In the case of asimulator such as ProModeL these rules are implicit inthe specification of the model. In other \\·ords. the rulesare embedded in the sinlulation engine. In the case of asimulation cnvironment such as SLA!v1SYSTEM. therules must be explicitly provided by a user.

Modular animation is achicved as fol1o\\"s. An initialframe is associated \vith each model module. The traceto script rules are specified. Thus. the animation foreach instantiation of that module is specified. Thecombination of thc animation of each module results inthe animation of the model.

Animation of cach module can be made optional.For example. an animation of the main module onh'gives a high level overvie\\' of the model. Th~animation can be expanded to include only thosenl0dules referenced by the main module to increase thelevel of detail. An animation of all modules sho\\"s allof the detail of the model.

7 SUMMARY

Current progress in the area of modular simulationenvironments has been discussed. Requirements forthese environments arise from the four distinct types ofusers that take part in a simulation activity. Inter-toolmodularity has to do \\'ith ho\\" data flo\\' bet\\'eenheterogeneous tools. Intra-tool modularity is concerncd,,·ith performing tasks in a modular fash·ion. Modularmodeling is \vell established. Concepts of modularit,"can be applied to other tools such as spreadsheets andanimators. The organization of simulation model inputs

720 Standridge ct ai.

and outputs in a modular simulation environment isdiscussed. An overview of a modular simulationenvironment for a simulation of local caching of WorldWide Web files is given.

REFERENCES

Balci.. O. and R. E. Nance. 1987. Simulation modeldevelopment environnlents: a research prototype.Journal of the Operational Research Society 38:753­763.

BalcL O. and R. E. Nance. 1992. Simulation modeldevelopment environment. In Proceedings of the1992 fl'infer Si!llulation Conference. ed. 1. 1. S\vain.D. Goldsman.. R. C. Crain. and J. R. Wilson. 726­735. IEEE. Piscata\vay. Ne\\' Jersey.

Balci. 0 .. A. 1. Bertelrun. C. M. Esterbrook. and R. E.Nance. 1995. A Picture-Based Object OrientedVisual Simulation Environment. In Proceedings ofthe 1995 Irinter Sin/ula/ion Conference. ed. C.Alexopoulos. K. Kang. W. R. Lilegdon. and D.Goldsman. 1333-13-l.0. IEEE. Piscata\\,ay. N.J.

Cota. B. A. and R. G. Sargent. 1992. A modification ofthe process interaction \\"orld vie\v. ACJ\ f

Transactions on j\!odeling and COlllpuler Sil11Ulation2: 109-129.

Centeno. M. A. and C. R. Standridge. 1991. Modelingmanufacturing systems: an information-basedapproach. In Proceedings oj' the 24th AnnualSiJnulation l~v/l/posiuJ1/. ed. A. H. Rutan. 230-239.IEEE Computer Society Press. Los Alamitos.California.

Henriksen. J. O. 1995. An introduction to SLX. InProceedings of the J995 Ifrinter SilllulationConference. cd. C. Alexopoulos, K. Kang, W. R.Lilegdon. and D. Goldsman. 502-509. IEEE.Piscata\vay. N.J.

Joines. J. A. and S. D. Roberts. 199~, Design of object­oriented simulations \vith C++. In Proceedings ofthe 199../ JFinfer Sinlulation (~on.ference. ed. J. D.Te\v. S. Manivannan. D. A. Sado\\t·ski. and A. F.Seila. 157-165. IEEE. Piscata\vay. N.J.

Joines. 1. A. and S. D. Roberts. 1995. Design of objcct­oriented simulations in C++. In Proceedings of the1995 If'inter SiJllulation Conference. ed. C.Alexopoulos. K. Kang. W. R. Lilcgdon. and D.Goldsnlan. 82-89. IEEE. Piscata\vay. N.J.

Sanderson. D. P.. R. Sharnla. R. Rozin. and S. Treu.1991. The hierarchical SiJllUlation language HSL: aversatile tool for process-oriented simulation. ACi\!Transactions 0/1 fa. fodeling and (~v/nputer SiJnulation1: 113-153.

Standridge. C. R. 1985. Performing simulation projects\vith the extended simulation system (TESS).SiJnulation 45: 283-291.

Standridge, C. R. and A. A. B. Pritsker. 1987. TESS:The Extended SiJllulation Support S.vstel1l. Ne\", York:Halsted Press.

Standridge. C. R. and M. A. Centeno. 1994. Conceptsfor modular simulation environments. In Proceedingsof the 1994 U/inter SiJllulation Conference. cd. J. D.Tew. S. Manivannan.. D. A. Sado\\'·ski.. and A. F.Seila. 657-663. IEEE, Piscata\vay. N.J.

Standridge. C. R.. 1995. Modular modeling for net\\'orksimulation languages: concepts and examples. InProceedings of the 1995 ~rinter Si/llulationConference. ed. C. Alexopoulos.. K. Kang. W. R.Lilegdon. and D. Goldsman. 736-743. IEEE.Piscata\\'ay, N.J.

Ziegler.. B. P. 1990. Object oriented si111ulation withhierarchical ",ot/ular !"odels. Ne\v York: AcademicPress.

AUTHOR BIOGRAPHY

CHARLES R STANDRIDGE is an associateprofessor in the Departmcnt of Industrial Engineering atthe Florida A&M University - Florida State UnivcrsityCollege of Engineering. He Icd the dcYclopmcnt of thcSimulation Data Language (SOL) and of Thc ExtendedSimulation Support System (TESS) for PritskerCorporation. His current research intercsts are modularsimulation environmcnts and health systemengineering. He is co-dc\'eloping a simulation model oflocal file caching of internet filcs as "'ell as models ofne\\' family therapy processes.

JAMES F. KELLY is a graduate student in theDepartment of Industrial Engineering at Florida A&MUniversity - Florida State Univcrsity Collcge ofEngineering. He is \\Titing his masters thesis on intcr­tool modularity in modular simulation environments.

THOMAS KELLEY is a graduate student in theDepartment of Industrial Engineering at Florida A&MUniversity - Florida State University College ofEngineering. He is \\Titing his masters thesis on intra­tool modularity in modular simulation environmcntsfocusing on spreadsheets and animation.

JACK WALTHER is a graduate student in theDepartment of Industrial Engineering at Florida A&MUniversity - Florida State University College ofEngineering. He is \\Titing his masters thesis on intra­tool modularity in modular simulation environmentsfocusing on the implementation of ModNet in SLX.