simulation - vanderbilt university

http://sim.sagepub.com/SIMULATION

http://sim.sagepub.com/content/early/2011/03/09/0037549711401950The online version of this article can be found at:

DOI: 10.1177/0037549711401950

published online 17 March 2011SIMULATIONGraham Hemingway, Himanshu Neema, Harmon Nine, Janos Sztipanovits and Gabor Karsai

approachRapid synthesis of high-level architecture-based heterogeneous simulation: a model-based integration

Published by:

http://www.sagepublications.com

On behalf of:

Society for Modeling and Simulation International (SCS)

can be found at:SIMULATIONAdditional services and information for

http://sim.sagepub.com/cgi/alertsEmail Alerts:

http://sim.sagepub.com/subscriptionsSubscriptions:

http://www.sagepub.com/journalsReprints.navReprints:

http://www.sagepub.com/journalsPermissions.navPermissions:

at VANDERBILT UNIV LIBRARY on April 28, 2011sim.sagepub.comDownloaded from

http://sim.sagepub.com/

http://sim.sagepub.com/content/early/2011/03/09/0037549711401950

http://www.sagepublications.com

http://www.scs.org/

http://sim.sagepub.com/cgi/alerts

http://sim.sagepub.com/subscriptions

http://www.sagepub.com/journalsReprints.nav

http://www.sagepub.com/journalsPermissions.nav


Simulation

Rapid synthesis of high-levelarchitecture-based heterogeneoussimulation: a model-basedintegration approach

Graham Hemingway, Himanshu Neema, Harmon Nine,Janos Sztipanovits and Gabor Karsai

Abstract

Virtual evaluation of complex command and control concepts demands the use of heterogeneous simulation environ-

ments. Development challenges include how to integrate multiple simulation engines with varying semantics and how to

integrate simulation models and manage the complex interactions between them. While existing simulation frameworks

may provide many of the required run-time services needed to coordinate among multiple simulation engines, they lack

an overarching integration approach that connects and relates the interoperability of heterogeneous domain models and

their interactions. This paper outlines some of the challenges encountered in developing a command and control

simulation environment and discusses our use of the Generic Modeling Environment tool suite to create a model-

based integration approach that allows for rapid synthesis of complex high-level architecture-based simulation

environments.

Keywords

domain-specific modeling language, distributed simulation, heterogeneous simulation, high-level architecture, model-

based integration, multi-paradigm modeling

1. Introduction

The evaluation of emerging command and control(C2)1 concepts necessitates a sophisticated modelingand simulation infrastructure that allows for the con-current modeling, simulation and evaluation of (1) theC2 system architecture (advanced system-of-systemsmodeling), (2) the battle space environment (scenariomodeling and generation), and the (3) human organi-zations and (group and individual) decision-makingprocesses (human performance and man–machineinteraction modeling). Using simulated C2 environ-ments to evaluate design concepts, validate new systemsand components, and explore hazardous, as well asambiguous, scenarios is easily justified from both acost and a practicality perspective. However, complexC2 environments have many disparate facets that needto be orchestrated, all of which cannot be handledby a single simulation engine. As a result, a heteroge-neous collection of integrated simulations, all acting

in a tightly coordinated environment, must beemployed. This collection is referred to as a simulationfederation.

In a federation, individual simulations are composedof two parts: an underlying simulation engine, such asSimulink, and a domain-specific model, such as anautomatic flight control system, designed to run onthe engine. In addition, each simulation engine mayhave its own unique execution semantics that need tobe accounted for. All of the engines and models in afederation must be coordinated in a meaningful way inorder for the larger C2 simulation environment to

Institute for Software Integrated Systems, Vanderbilt University,

TN, USA.

Corresponding author:

Janos Sztipanovits, Institute for Software Integrated Systems, Vanderbilt

University, Nashville, TN, USA

Email: [email protected]

Simulation: Transactions of the Society for

Modeling and Simulation International

0(00) 1–16

! The Author(s) 2011

Reprints and permissions:

sagepub.co.uk/journalsPermissions.nav

DOI: 10.1177/0037549711401950

sim.sagepub.com



be useful. Issues encountered in developing these envi-ronments relate to integrating simulations at both theengine and model levels.

Existing frameworks, such as the high-level architec-ture (HLA),2,3 provide application programming inter-faces (APIs) that have helped to reduce the complexityof integrating multiple different simulation engines, butmany challenges remain in such environments. HLA,for example, does not specify any tools to design ordeploy a federation. It primarily standardizes run-time support for various tasks, such as coordinatedtime evolution, message passing, and shared objectmanagement. As a result, these frameworks require asignificant amount of tedious and error-prone hand-developed integration code.

Additional complications stem from the fact thatexisting frameworks typically do not have centralizedrepositories for the configuration of the entire environ-ment. Ideally, this repository would include configura-tion data for each of the individual simulation enginesand models involved, as well as for the deployment andexecution of the overall simulation. Lacking such arepository leads to the possibility of conflicting orinconsistent configurations. These types of problemscan be difficult to diagnose and can greatly increasethe burden of manually coordinating the design,deployment, and execution of the simulationenvironment.

In this paper, we present the C2 wind tunnel(C2WT), a graphical environment for designing anddeploying heterogeneous C2 simulation federations.Its primary contribution is to facilitate the rapid devel-opment of ‘integration models’, and to utilize thesemodels throughout the lifecycle of the simulated envi-ronment. An integration model defines all the interac-tions between federated models and captures otherdesign intent, such as simulation engine-specific param-eters and deployment information. This informationcan be leveraged to streamline and automate significantportions of the simulation lifecycle.

The C2WT uses a custom developed domain-specificmodeling language (DSML) for the definition of inte-gration models. This language facilitates the easy cap-ture of all of the design details for the simulationenvironment. C2WT integration models follow the con-ceptual architecture depicted in Figure 1. A simulationenvironment is composed of multiple ‘federates’, eachof which includes a simulation model, the engine uponwhich it executes, and some amount of specialized gluecode to integrate the engine with the simulation bus.Both the engine configuration and the integration (or‘glue’) code needed for each federate is highly depen-dent upon the role the federate plays in the environ-ment, as well as the type of simulation engine beingutilized.

While manually developing the glue code is possible,by leveraging the integration model, the C2WT is ableto synthesize all of the code, greatly reducing errors andeffort. We developed a suite of tools, called model inter-preters, integrated directly with the DSML, that auto-matically generate engine configurations and glue code,as well as scripts to automate simulation execution anddata collection. The integration model DSML com-bined with our generation tools provides a robust envi-ronment for users to rapidly define complex,heterogeneous C2 simulations.

The remainder of this paper is organized as follows.The next section discusses background material.Section 3 details the C2WT DSML and our approachfor model integration using the C2WT environment.Section 4 reviews the details of the integration of sev-eral simulation engines. Section 5 discusses our inte-grated approach to simulation deployment andexecution. Section 6 covers results from using theframework in a real-world scenario. Section 7 discussessome of the decisions and factors that drove the toolsuite’s development. Section 8 reviews work related toour research. Section 9 concludes the paper and out-lines planned future work.

2. Background information

One of the primary contributions of our effort is ourfocus on developing a completely model-based integra-tion approach. Our efforts leverage the GenericModeling Environment (GME)4 tool suite for design-ing the integration model DSML and a customizableHLA integration and configuration framework toprovide run-time support as the ‘simulation bus’.

The HLA is a standardized architecture for distrib-uted computer simulation systems. Communicationsbetween different federates is managed via the run-time

Simulation Bus (HLA)

Integration

Model

C2WT

Glue Code

CP

NT

ools

Simulation

Engines

…

Mat

lab

HLA

Config.

Glue Generation

Engine

Config.

Simulation

Models

Figure 1. Conceptual command and control wind tunnel

architecture. HLA: high-level architecture.

2 Simulation: Transactions of the Society for Modeling and Simulation International 0(00)



infrastructure (RTI) layer – an implementation ofthe HLA standard. The RTI provides a set of services,such as time management, data distribution, messagepassing, and ownership management. Other compo-nents of the HLA standard are the object model tem-plate (OMT) and the federate interface specification(FIS).

The HLA standard focuses on three primary areas.First is time coordination throughout the federation.The evolution of time is a key thread through each ofthe integrated simulators. Each simulation engine mustslave its progression of time to that of the overall HLAclock. The HLA standard provides several methods toaccomplish this. Second is coordination of inter-federatemessages and shared data objects. The HLA standardprovides a publish-and-subscribe mechanism for passingmessages and object updates throughout the federation.Thirdly, the HLA standard provides for basic simula-tion execution control. A limited ability to start, pause,and stop the execution of a simulation is built directlyinto the HLA standard. The C2WT relies upon the ser-vices provided by the RTI during run time.

As HLA is an accepted standard, a number of com-mercial, academic, and alternate RTI implementationsare available. Currently, we use the Portico RTI,5

which provides support for both Cþþ and Java clientsand is compliant with version 1.3 of the HLA standard.

The GME is a meta-programmable model-inte-grated computing (MIC)4 toolkit that supports the cre-ation of rich domain-specific modeling and programsynthesis environments. Configuration is accomplishedthrough meta models, expressed as unified modelinglanguage (UML)6 class diagrams, specifying the model-ing paradigm of the application domain. Meta modelscharacterize the abstract syntax of the DSML, definingwhich objects (i.e. boxes, connections, and attributes)are permissible in the language and how they compose.Another way to view this is that the meta model is aschema or data model for all of the possible models thatcan be expressed by a language. Using finite statemachines as an example, the DSML would supportstates and transitions. From these elements any statemachine can be realized. The inherent flexibility andextensibility of the GME via meta models make it anideal foundation for the C2WT environment. Alternatemeta modeling frameworks, such as AToM3,7

MetaCase,8 and Microsoft DSL,9 exist but extensiveprior experience with the GME led to its selection forthe C2WT.

3. Model-based integrationenvironment

Complex C2 simulations require coordination betweenmultiple heterogeneous simulation engines. The HLA

provides a standard for the RTI that supports the coor-dinated execution of distributed simulations. However,designing the model integration, coding the engine-to-RTI glue code, and testing and deploying all of thevarious run-time components across multiple engine-specific simulation tools remains a challenging prob-lem. Our project introduces a new approach for thesimulation integration problem. The primary contribu-tions of this effort are the development of a compre-hensive modeling and management environment builtaround a custom DSML, implemented in the GME,and a related suite of model interpreters to coordinatebetween the integration model and the engine-specificsimulation tools involved in the overall environment.

3.1. Integration overview

A common problem with developing large-scale hetero-geneous simulations is the complexity and effortrequired to integrate distinct simulation tools into thelarger environment. In the case of a HLA-based envi-ronment, not only does the RTI require a common fed-eration definition, but each involved simulation toolmust also be integrated (via simulation engine-to-RTIglue code) and configured (in an engine-specific way)according to its role in the environment. Existingapproaches treat the definition and creation of theseartifacts as separate, but not necessarily related, steps.Our custom DSML is able to capture all of this inte-gration information and provide a single view of theentire simulation environment. In this section, we willdiscuss the design of the DSML, our approach for cre-ating integration models, and the execution semanticsof these models.

Throughout this paper we will refer to an examplescenario we have modeled using the C2WT, illustratedin Figure 2. It involves the deployment of one or moreunmanned aerial vehicles (UAVs) (simulated usingSimulink10 models) into a combat zone. The deploy-ment zone and the physical positioning of the groundand aerial vehicles are modeled using a custom Javafederate and visualized using Google Earth.11 TheUAVs may have objectives including: data collection,target acquisition and engagement, or battle damageassessment. Video sensors (implemented and simulatedusing custom-written Java federates) mounted on theUAVs must collect information and relay it via a com-munications network (implemented in OMNeTþþ12)back to a centralized decision-making organization(implemented as a colored Petri-net (CPN) model inCPN Tools13). The organization must react appropri-ately to the information and provide guidance to thevehicles. In addition, the UAVs are themselves highlyautonomous and must utilize collected sensor data topursue their given objectives.

Hemingway et al. 3



3.2. Integration model DSML

Fundamental to the C2WT environment is the over-arching model integration DSML. This language isconsidered overarching in the sense that it providesall of the modeling primitives required to specify theintegration, deployment, and execution of the federatedsimulation. Once the integration model hasbeen defined for a given environment, a set of reusablemodel interpreters are executed to automaticallygenerate engine-specific glue code and all deploymentand execution artifacts. All generation and deploy-ment steps directly rely upon the initial integrationmodel.

Figure 3 shows the primary portion of the DSMLthat defines the universe of composition elements. Thethree primary elements in a federation (defined by themodel FOMSheet) are Interaction (on right-hand sideof Figure 3), Object (on the left-hand side), andFederate (in the center), representing a HLA-interac-tion, HLA-object, and a HLA-federate respectively.Note that proxy elements are simply references totheir respective target model elements and can beused in place of their targets to help structure or orga-nize a model. As defined by the HLA standard, feder-ates in a federation communicate among each otherusing HLA-interactions and HLA-objects – both ofwhich are managed by the RTI.

Interactions and objects, in an analogy with inter-process communications in operating systems, corre-spond to message passing and shared memory respec-tively. As seen in Figure 3, the meta model fullysupports the key HLA-defined attributes of these com-munication elements, such as delivery method, messageorder (timestamp or receive order), and parameters.Also notable is that via the InteractionInheritance andObjectInheritance connection elements, interactions andobjects can form inheritance trees where derived types

inherit the parameters or attributes respectively of basetypes. The ParameterType attribute on the Parameterand Attribute elements defines the data type of thatelement (i.e. float, int, string). The Interaction andAttribute elements also support the HLA-definedattributes of Delivery and Order. The Delivery attributespecifies the desired method of delivering the interac-tions (and attribute updates), such as reliable or best-effort. The Order attribute specifies the order in whichthe interactions (and attribute updates) must be deliv-ered, such as time-stamped, or receive. When time-stamped order is used, the RTI maintains a time-stamped queue of interactions (and attribute updates)and delivers them in that order. When the receive orderis used, the RTI forwards the interactions (and attrib-ute updates) as soon as it receives them without guar-anteeing the order in which they will be finally receivedby the recipient federates.

The Federate element directly corresponds to anysingle instance of a simulation tool involved in the fed-eration. The primary attribute of a federate, as far asHLA-based synchronization is concerned, is itsLookahead – the interval into the future during whichthat federate guarantees that it will not send an inter-action or update an object.

We have sub-classed the Federate element withCPNFederate and OmnetFederate elements. These ele-ments are used to represent two supported simulationengines that benefit from having more detailed federatemodels. Places and EndPoints represent contained ele-ments within larger CPN Tool and OMNeTþþmodels, respectively. These ‘children’ elements appearas ports on their parent container, see Figure 4, andallow the federate to relate interactions or objectsdirectly to the child elements. For many federatetypes, such as Matlab/Simulink or Java/Cþþ, childrenelements do not have a semantic equivalent, and assuch do not need specific support in the meta model.

Lastly, the attributes of the FOMSheet element cap-ture the names and locations for configuration codethat enables the integration of supported simulationengines. We will describe this capability in detail inSection 4.

Collectively, these language elements are required todefine the relationships between all federate types.Developing an actual integration model using these spe-cial simulation elements is discussed in the subsequentsection.

Figure 5 shows additional portions of the C2WTDSML. The top portion of the figure shows the lan-guage elements necessary to model federates publishingand subscribing interactions, objects, and attributes.A Federate (bottom center of the top portion)can be related to an interaction (inheritedvia the InteractionBase element – bottom right).

Figure 2. Example simulation. UAV: unmanned aerial vehicle.




Two relationships are possible, publish (via aStaticInteractionPublish connection – middle right) orsubscribe (via a StaticInteractionSubscribe connection –top right). Similar relationships exist between objects(via the ObjectBase element) and federates. Since theHLA standard allows federates to subscribe to individ-ual object attributes, the Attribute element supports thesubscribe connection to federates. The PubSubFilterelement provides a simple means to organize publish-and-subscribe relationships.

The lower two portions of Figure 5 are extensionsspecific to the CPN Tools and OMNeTþþ engines inte-grated into the C2WT. The middle portion of the modelcaptures publish-and-subscribe links with Place ele-ments. Similarly, the model at the bottom of the

figure captures the connection with special-purposeEndPoint elements for the integration of OMNeTþþfederates.

This language, and its set of modeling elements, isvery closely related to the HLA standard for futureextensions to other RTIs in addition to the one cur-rently supported (viz. Portico RTI5). With these ele-ments a designer is able to completely specify theintegration model of the entire federation and its con-stituent simulation engines. Federates define thedetails of the engine-specific models that are involved,and their relationships are captured via publishingand subscribing to various interactions and objects.Further extensions to the language have been imple-mented that include primitives for specifying

Figure 3. Integration model meta model.

Hemingway et al. 5



deployment and execution. These extensions are dis-cussed in Section 5.

3.3. Creating integration models

The semantic relationship between federates can bedefined primarily using two main aspects: the data rep-resentation and the data flow. These are common ele-ments of most simulation modeling paradigms, and wehave adopted these as the key concepts of our integra-tion models. An integration model describes both datarepresentation and data flow elements, and, in somecases, includes special elements as the placeholders forconcepts specific to particular simulation engines.

Data representation models consist of interactionand object models. Interactions are stateless, and canhave parameters, while objects have states, which arerepresented as a set of attributes. Both interactions andobjects are permitted to have inheritance hierarchies.These data representation models directly map to theHLA federation object model (FOM).

Figure 6 shows two data representation models fromour example: an interaction class-inheritance tree onthe top (elements not shaded), and an object class-inheritance tree on the bottom (elements shaded). Allinteractions must initially inherit from the

InteractionRoot element; likewise, all objects mustinherit from the ObjectRoot element. While root inher-itance is mandated in the HLA standard, we havedirectly incorporated this concept into the DSML toboth clarify the visual representation and to simplifythe interpretation of the model tree. Deriving elementsvia inheritance is an intuitive approach readily under-stood by modelers.

Once the data representation models are created, themodeler must define publish–subscribe data flow rela-tions with federates. This is accomplished by connect-ing federates to interactions or object attributes withdirectional links. Federates publish and subscribe toany set of interactions or objects, dictated solely bythe desired operational semantics. Federates can alsopublish or subscribe to entire data elements or to asubset of their attributes. Figure 4 shows a simpledata flow from our example specifying the publish-and-subscribe relationships between federates (elementsshaded) and interactions (elements not shaded).

Integrating engine-specific models together in thecentral modeling environment is simply a matter ofconnecting federates to those interactions and objectswith which they have a publish or subscribe relation-ship. This greatly simplifies the designer’s job,since they no longer need to directly incorporate

Figure 4. Example publish/subscribe relationships.




engine-specific considerations and can focus solely onthe high-level interactions of the model. The lower-levelintegration details, such as clock management and mes-sage passing, are addressed once and for all when thesimulation engine is integrated into the general C2WTenvironment.

3.4. Federation execution semantics

The integration model defines all of the relationshipsbetween federates via publish-and-subscribe mecha-nisms on interactions and objects. We have purpose-fully not included any timing-related information intothe integration model beyond the Lookahead parameterwithin each Federate object.

The HLA standard provides numerous schemes forcoordinating time among federates. These can rangefrom completely lacking time synchronization, whereone federate can execute arbitrarily far into thefuture, to completely synchronized, where all federatesevolve time within a tightly bound window. Our inte-gration models always assume that time is strictly con-trolled. Using HLA terminology, all federates must beboth ‘time regulating’ and ‘time constrained’. A time-regulating federate’s progression constrains all time-constrained federates. Likewise, a time-constrained fed-erate’s advance is controlled by all time-regulating fed-erates. Because within the C2WT framework allfederates are both time regulating and time constrained,time progresses only when all federates are ready to

Figure 5. Command and control wind tunnel meta model continued.

Hemingway et al. 7



proceed and then only as far as the smallest permissibletime step across all of the federates. Without both char-acteristics for all federates, the overall behavior of thesimulation can become non-deterministic due to reor-dering of events in time. Determinism is necessary ifscenarios must be executed multiple times without var-iance in the events or outcomes, such as for scenarioanalysis. While our envisioned scenarios rely upondeterminism, other uses, such as for training purposes,may not, and therefore the requirement for federates tobe both time constrained and time regulating could berelaxed.

The C2WT environment also assumes that all inter-actions and object updates are strictly time ordered andmust have timestamps. The HLA standard specifiesthat messages can be sent at any time but may onlybe received while the federate is waiting for a timeadvance request to be granted. This ensures that all

incoming messages will have a timestamp greater thanor equal to a federate’s current time, that is, no time-stamps are allowed on a message that make a messageappear that it was received in the past. Once a timeadvance request is granted a federate can simulate for-ward in time and processes incoming messages accord-ing to their timestamp order.

Given these assumptions, the operational semanticsof a federation become straightforward. Each federateoperates in a loop consisting of two steps: request atime advance from the RTI and wait, receive a timeadvance grant from the RTI, and simulate up to thattime. The glue code generated from the C2WT integra-tion model must be able to control the simulationengine execution to abide by this scheme. In the nextsection, we will provide several examples of how vari-ous simulation engines are controlled.

A complete C2WT integration model does not con-tain information about the detailed execution of eachfederate. Nor does it replace in any way the internaloperational semantics of any simulation engine. Everyfederate references an engine-specific model (e.g. ourSimulink-based UAV model) and it is within thismodel that the details of the internal semantics of thefederate are contained. The C2WT only builds upon thestandard time management and message passing mech-anisms provided by the underlying HLA infrastructure.

4. Integrating simulation engines

This section describes the process of integrating severalexample domain-specific simulation engines into theoverall C2WT environment. For each engine, we out-line how the engine aligns with the overall frameworkand the primary considerations involved in integration.The three example engines are OMNeTþþ, Matlab/Simulink, and CPN Tools. This set was selected as rep-resentative samples of the stereotypical types of enginesthat are incorporated into C2 simulations.

Each integrated simulation engine has its ownunique underlying execution semantics, CPNs forCPN Tools, synchronous data flow for Simulink, dis-crete event systems for OMNeTþþ, etc. These execu-tion semantics directly impact the approach of how anengine is integrated into the C2WT environment.Integration approach details, such as how an enginecoordinates clock management or how it passes inter-simulation interaction events to the HLA, must besolved for each engine individually.

In addition to those simulation engines coveredbelow, the C2WT environment currently supportsDEVSJava,14 Delta3D,15 Google Earth, and C/Cþþand Java-based custom federates. This set of supportedengines allows for the simulation of quite complex anddiverse scenarios.

Figure 6. Interaction and object hierarchies.




4.1. OMNeTþþ – communications federate

In a C2 simulation environment it is essential to modeland simulate communication networks in order tostudy mission critical situations, such as network fail-ures or attacks. After evaluating multiple publicdomain network simulators, OMNeTþþ was selectedas our network simulation engine. A primary advan-tage of OMNeTþþ is its modular architecture, whichallows for the event scheduler to be easily replaced – arequirement for HLA integration.

We developed a tool called NetworkSim, which is aHLA-compliant reusable communication network sim-ulator based on OMNeTþþ. NetworkSim provides aset of high-level communication protocols (e.g. reliablesend, streaming) while internally maintaining a faithfulsimulation of the full network stack. A key advantageof NetworkSim is its ability to utilize communicationsnetwork models built using the standard OMNeTþþmodeling tools. It simply handles the translation ofmessages from the RTI into appropriate networkactions, and vice versa, and injects these messagesonto the correct simulated network node. In additionto maintaining the underlying semantics ofOMNeTþþ, this mechanism also serves to isolate gen-eral RTI traffic from traffic on the simulated network.

Each OMNeTþþ model deployed ontoNetworkSim must have some code synthesized for inte-gration with the RTI. All OMNeTþþ models are com-posed of connected nodes that form a communicationsnetwork. When simulated via NetworkSim, some ofthese nodes are end points, responsible for passing mes-sages between the RTI and the OMNeTþþ engine. Thecode that implements these nodes must be generated.

A GME-based model interpreter traverses theC2WT integration model and generates the Cþþcode needed for end-point nodes within anOMNeTþþ model. The integration model providesall of the information to understand, for a givenOMNeTþþ federate, which interactions may be sentor received and which objects attributes may be pub-lished or updated. As seen in the bottom center ofFigure 3, an OMNeTþþ federate contains a set ofend-point atoms. In addition, as demonstrated inFigure 4, any federate may be related to a set of inter-actions and objects. The interpreter understands theserelationships and synthesizes code for each end point inan OMNeTþþ federate. The generated code buildsupon the OMNeTþþ API and is compiled directlyinto the model-independent NetworkSim tool.

In addition to inter-federate communication, evolu-tion of the OMNeTþþ internal simulation clock mustalso be synchronized with the RTI. NetworkSimincludes a reusable class that extends the basicOMNeTþþ scheduler. Figure 7 shows the key

scheduler function that implements RTI time synchro-nization. The function is called by OMNeTþþ to deter-mine the next event, originated either internally orexternally. If the timestamp on the next messageplaces it outside of the window of time granted by theRTI, then a time advance is requested using rti->advanceTime().

An internal dispatch mechanism routes all RTIinteractions to the appropriate OMNeTþþ protocolmodule, which interprets them and can schedule newinternal OMNeTþþ messages. A similar mechanisminterprets and routes OMNeTþþ messages bound forexternal dispatch into the RTI. Using these mecha-nisms, both the evolution of time and message passingwithin an OMNeTþþ federate is tightly coordinatedvia the RTI with the federation.

4.2. Matlab/Simulink – plant andcontroller federate

Matlab/Simulink10 is a widely used simulation environ-ment for dynamic and embedded systems, such as com-munications, controls, and signal processing. It is avisual language that uses a set of pre-built block librar-ies for designing and controlling the simulation.

Integration of the Simulink simulation engine is sim-ilar to that of the OMNeTþþ engine in that all of theengine-specific glue code is generated based on the over-arching integration model. The GME-based modelinterpreter generates code that, in conjunction with sev-eral generic classes, is used to directly integrate anySimulink model with a C2WT federation. The genericclasses are completely reusable Java code and provideall of the fundamental RTI integration requirements:providing interfaces for converting between Simulinktypes and RTI types, encapsulating interfacing withthe RTI for initializing the federate, synchronizing theSimulink engine’s simulation clock, and managing anypublish-and-subscribe relationships with other feder-ates. The automatically generated Java and Simulinkfiles for the engine integration depend on this reusablecode.

Figure 7. OMNeTþþ scheduler function.

Hemingway et al. 9



Within any given Simulink model the user mustinsert an S-function block (a visual block that callssome textual code, specified in a ‘.m’ file, for execution)for each interaction or object to which the model eitherpublishes or subscribes. It is via these blocks that theSimulink engine interacts with the remainder ofthe federation. The modeler must specify whether theblock either publishes or subscribes an interaction orobject. This is done by instantiating the correspondingsender or receiver S-function from those that were gen-erated from the integration model. The modeler mustalso tell the S-function block which interaction orobject it should call. This is done by passing the nameof the interaction or object via a string parameter to theblock. The naming convention of the. m files and ofthe parameters is standardized and easily derivedfrom the primary C2WT model. Once the S-functionblocks have been incorporated and their values set, nofurther manual steps are typically necessary to preparethe model to be integrated. Some effort may have tobe spent to properly order the signals entering andexiting the S-function blocks so that they correspondto the attribute ordering of the corresponding RTIinteraction.

The key mechanism for synchronizing the clock pro-gression of the Simulink model with that of the RTI isthe basic time-progression model for S-function blocks.During its execution, the Simulink engine consults eachblock in a model about when it can generate an output.With all S-function blocks, code must be supplied, viaan implementation of the mdlGetTimeOfNextVarHit()method, to respond to this request from the engine. Forour integration, the synthesized integration code in anS-function block uses this method to synchronize themodel with the RTI and allow simulation time withinSimulink to progress only when the RTI allows it toproceed. Until the RTI allows federation time to prog-ress, we do not return from the method call within theS-function block, thus not allowing the Simulink engineto progress. We keep the Simulink engine step size low(typically �0.1 seconds) to minimize any event timingerrors due to the passing of input and output eventsbetween the Simulink model and the HLA. For incom-ing events, the glue code uses a polling scheme at everytime step to check if the federate has received an inputfrom the remainder of the federation.

General experience shows that very small step sizesin any Simulink model can lead to a significant slow-down in simulation speed. In the context of the C2WT,possible performance penalties due to having small stepsizes must be weighed against minimizing timing errorsdue to overly large time steps. After thorough evalua-tion, we found that the performance penalty is negligi-ble in comparison to the basic lock-stepped simulationwe use for synchronizing federates.

4.3. CPN – organizational decision-makingfederate

A very important goal in C2 simulations is to evaluatethe response of decision makers to the evolving situa-tion. The C2WT environment integrates CPNs tomodel and simulate human decision-makingorganizations.

We use CPN Tools augmented with the BRITNeY16

extension. This extension provides a low-level bridgebetween the native CPN Tools API and Java, whichsimplified integration with our Java-based RTI.

The primary challenge involved in integrating theCPN Tools engine into the C2 environment was correcttime synchronization. In order to ensure that the CPNmodel execution stops at desired times one extra placeand a transition, which is set to fire with a predefinedfrequency of 1 kHz, are added into a CPN model. TheCPN Tools engine optimistically progresses ahead ofthe HLA clock, but when needed, it can be rolledback to a desired time. This save and restore function-ality might be useful for increasing performance usingan optimistically large step size and lookahead.However, with our experiments, we found that the per-formance penalty incurred by using the small step sizeand lookahead was negligible. Thus, we currently use astep size of �1 second and lookahead of �0.1 secondsfor the CPN federate. Internally, while executing theCPN model via the BRITNeY Java library, the CPNclock moves forward 1 millisecond at a time. Whiletime progresses internal to the CPN simulation, wecompare its current time with the time granted by theRTI to the CPN federate. If the CPN cannot proceed intime, it requests the RTI to advance time and waitsuntil it receives a time advance grant. While the smallinternal time step of CPN federates has the potential togenerate significant HLA communications (if there wasan interaction every time step for example), our expe-rience has shown that typical CPN models do not needto interact with the HLA every time step and thus donot incur a significant overhead.

As illustrated in Figure 8, CPN models areimported into a C2WT integration model via an auto-mated interpreter. Upon importing a CPN model, aCPNFederate element is created within the integrationmodel and the CPN places become corresponding portson this federate. The ports on this element can then beconnected to either interactions or objects to specifyinputs and outputs for the CPN model, as discussedin Section 3.2. This graphical step is the only integra-tion effort necessary for CPN models. All of the engine-specific code to communicate via the RTI and to syn-chronize the CPN federate with the rest of the federa-tion is automatically generated from the GMEintegration model.




A custom GME output interpreter generates anextensible markup language (XML) file that describesall of the input–output bindings. The run-time CPNexecution engine reads this file and simulates the CPNaccording to its specification. The set of places to mon-itor during execution can also be specified. Tokens onthese monitored places are shown during run time in asimple Java graphical user interface (GUI) provided bythe C2WT framework.

5. Simulation deployment andexecution

The deployment and execution of large-scale heteroge-neous simulations can be quite complex. Typically,deployments span multiple computers and executionrequires the coordination of many independentprocesses.

The HLA specification does not provide any man-date for how simulations are to be deployed or con-trolled, and available RTIs also do not provide suchfacilities. As C2 scenarios grow larger they must spanmultiple computers and the deployment of multi-domain simulations can impose a significant adminis-trative burden. Manual approaches, such as hand-crafted batch files, tend to not scale well and are typi-cally not well suited to highly dynamic environmentswhere deployment parameters change frequently. Ourteam has made additional contributions in this area inorder to ease the administrative burden imposed bythese complex environments.

5.1. Deployment modeling

Our team encountered numerous deployment-relatedhurdles as we tried to execute scenarios built uponour environment. As the complexity of our scenariosgrew, manual deployment processes quickly began to

consume more time than the actual execution of scenar-ios. Our solution to this problem was to incorporate amodel for deployment and execution directly into ourcentral modeling environment. Figure 9 shows severaladditional elements that augment the C2WT metamodel: Experiment, Host, Computer, Network, andDeployment. Now a single model incorporates boththe federation integration design and the deploymentinformation. With this extension, a model interpreterautomatically generates all of the necessary scripts andfiles, copies the files to the appropriate computers, andprepares the environment for execution.

As discussed in previous sections, the overall simu-lation model is a composition of federates and theirrelationships via interactions and objects. For anygiven experiment, a simulation scenario may only uti-lize a subset of the federates defined in the model.Similarly, each engine-specific model involved may beparameterized to allow for run-time flexibility. Exampleparameters are the duration of a network attack (forthe network simulator engine) or the weight a givencommand decision may be given (for the CPN Toolsengine). An experiment is the set of federates includedin a specific deployment and their run-timeparameterization.

Frequently, an experiment is run on more than onehardware setup. A designer may run the entire simula-tion on one machine during development, while deploy-ing the simulation onto a cluster for full-scaledemonstrations. The network element of the languageextension is the physical set of computers involved in aspecific deployment.

The deployment element is where an experimentconfiguration is mapped to a network configuration.Specific federates are assigned to hosts in the network,thus allowing complete flexibility in defining which sim-ulation tools execute on which hardware.

A model interpreter reads the deployment configu-ration from the model and generates all of the scriptfiles necessary to support the deployment. In caseswhere modeling deployments may only be partially spe-cified, for example in very large-scale or rapidly chang-ing environments, the interpreter generates thedeployment for whatever portion is defined. Once gen-erated, the environment is fully prepared for experi-ment execution.

Finally, the generated scripts manage the actualmovement of files and code to the various hosts beingused. Upon invocation, the scripts remotely connect toeach machine and create local copies of all necessaryfiles before the simulation begins execution. The scriptsthen coordinate the execution of all federates. After theexperiment is concluded, the scripts remotely stop allprocesses, collect output files, and clean all local copiesto restore the hardware to its original state.

Figure 8. Integration model workflow.

Hemingway et al. 11



5.2. Federation manager

The HLA standard prescribes basic methods for con-trolling the execution of a simulation: start, stop, andpause. However, the C2WT environment extends muchgreater control and coordination of federate executionthroughout a simulation. This is achieved by using aspecial federate called the federation manager (FM).

The FM is a generic federate, and so can be used as apart of any federation. It coordinates a simulationby: (1) waiting for all federates in an experiment tojoin the federation before allowing it to begin simula-tion; and (2) making sure all federates are initializedand ready to begin the simulation before allowing itto proceed.

The first item above is achieved by listing which fed-erates are part of the simulation in a configuration filethat is read by the FM upon its initial execution. Usingthis information, along with the HLA’s built-in‘FederateObject’ class, the FM can detect when eachfederate joins the federation, and allow the simulationto proceed only when all federates have joined.

Making sure all federates are fully initialized is nec-essary to avoid one or more federates proceeding withsimulation execution before others are ready. Suchbehavior can corrupt an execution and therefore inval-idate the simulation. The FM uses ‘synchronizationpoints’, as specified by the HLA standard, to guaranteethat all federates are ready to proceed with the simula-tion before any of them begin execution. In particular,it registers a synchronization point to allow federates toreport when they are initialized and ready to proceed

with the simulation. Once all federates have reportedthat they have reached the synchronization point, theFM allows the simulation to proceed.

The coordination the FM exerts over a simulation isextremely important in that it allows simulations to beprecisely repeated. Without the FM, for any sufficientlycomplex simulation, it would be nearly impossible toguarantee that all federates are always initialized andbegin simulation simultaneously. The FM also allowsthe user to exercise greater control over the execution ofthe simulation. This is realized via several differentmechanisms.

Firstly, the FM is capable of pacing the simulationin synchronization with the wall clock, or allowing thesimulation to run as fast as possible. This is accom-plished by coding the FM to monitor the wall clockand to use RTI calls to keep the wall clock and thesimulation clock synchronized. The FM is time regulat-ing and time constrained, similar to all other federates,and can therefore restrict or allow federation-wide timeevolution through control of its own virtual clock. Thisbehavior can be turned on and off using the FM’s GUI.Turned off, the FM allows the simulation to proceed asfast as hardware and network speeds allow.

Secondly, the FM provides fine-grained controls toallow for the simulation to be paused for examination(and subsequently resumed), or terminated, at anypoint in the simulation. This works by placing‘Pause’, ‘Resume’, and ‘End’ interactions directly intothe integration model. The FM sends out ‘Pause’,‘Resume’, and ‘End’ interactions either on demand

Figure 9. Command and control wind tunnel deployment and execution meta model.




(via GUI buttons) or at times pre-specified in its con-figuration file. Each federate is prepared to respond tothese interactions automatically by way of the automat-ically generated glue code.

Thirdly, the FM also allows federation-specific inter-actions to be injected into the simulation at pre-speci-fied times. This is very useful for both debugging andquick ‘what if’ considerations. The FM is automaticallyconfigured to publish every interaction in the integra-tion model. Interaction injections are controlled by spe-cifying in the FM configuration file which interactionsare to be injected with what parameter values and atwhat times. When the appointed time arrives the FMpublishes the interaction to the rest of the federation.

Finally, the FM allows interactions to be monitoredand logged as they are sent by federates during a sim-ulation. This is also specified in the FM configurationfile. Monitored interactions, as they occur, are dis-played in a text box in the FM’s GUI.

6. Experimentation with the framework

The C2WT project’s goal is to create a heterogeneoussimulation environment tailored towards scenariosinvolving, for instance, the interaction of multipleUAVs, their operating conditions, and the associatedC2 organization and infrastructure. Rapid evolution ofscenario details and easy evaluation of C2 effectivenessare key motivators.

Our first goal was to demonstrate that we could rap-idly synthesize such simulations using our model-basedintegration environment involving all the domain-spe-cific simulation engines described above. For demon-stration purposes, we used an urban scenario with two‘good-guy’ UAVs, and two ‘bad-guy’ ground vehiclesthat must be tracked in order to prevent an attack.Each UAV has video sensors and continuously trans-mits video data to the control station. The control sta-tion remotely controls the UAVs in a formation flightand assesses the targets one by one based on the initialposition estimates of the targets.

All network communications are simulated using anOMNeTþþ federate. We tested how a denial-of-servicenetwork attack affects mission performance. Theabstraction of low-level physical layer communicationin OMNeTþþ makes it straightforward to implementvarious types of network attacks.

Using a collection of ‘zombie’ nodes in dedicatedsub-networks, either parameterized or controlled by amaster node, any type of ‘dumb’ or non-adaptiveattacks can be simulated. For our purposes, a distrib-uted denial-of-service (DDoS) attack was sufficientlydisruptive. Each zombie machine sends, at specifiedintervals, service requests to every discovered validnode. As communications degrade, the effect on UAV

formation flight is pronounced. The formation flightdoes not loosen: rather it collapses altogether. TheUAVs continue in their individual directions, entirelyuncoordinated. Sensor information is lost, so the oper-ator becomes unable to repair the flight formationmanually.

The impact of these attacks on the C2 of the UAVsclosely mirrors predicted theoretical consequences. Thisgives the experimenters confidence that the results ofsimulation can be directly applied to the modeledscenarios.

Table 1 captures the engine type and update rate foreach of the federates involved in our simulation. Ourhardware configuration used during demonstrationsconsists of six dual-core 3.0GHz-class machines net-worked via a dedicated 100 Mb/s switch all withnVidia GTX 280 graphics cards. In a typical deploy-ment, each machine had between one and three feder-ates running on it. Despite highly complex engine-specific models, we have not experienced any significantperformance bottlenecks during simulations lasting anaverage of 30minutes. If our scenarios are deployedentirely onto one of our typical development machines(a clone of those in our demonstration cluster) perfor-mance is acceptable but noticeably slower. This is espe-cially true if multiple visualization federates are present.

Using our framework, new scenarios can be createdrelatively quickly. It took our team less than threeweeks to create a new scenario as compared to anec-dotal evidence from our sponsors that, prior to ourframework, individual scenarios could take betweenone and two years to develop. It is important to notethat our scenario did not necessitate the integration ofany new simulation engines and was able to leverageportions of existing custom Java federates.

7. Discussion

The design of the C2WT has evolved considerably overthe three years it has been under development.

Table 1. Model information for experimental scenario

Federate Engine Update rate

UAV dynamics Simulink 100 Hz

UAV operators Simulink 100 Hz

Controller attack Java 10 Hz

Physics Java 10 Hz

Visualization G. Earth 10 Hz

Comm. Network OMNeTþþ 20 Hz

Decision making CPN Tools 1 Hz

UAV: unmanned aerial vehicle.

Hemingway et al. 13



A primary driver of its evolution has been to see how amodel-based approach can reduce the effort required todevelop distributed simulations. Generally, with eachiteration of the tools, previous functionality was refinedand new automation was added. Our approach of refineand extend has allowed us to incrementally build a toolsuite that would likely have been difficult to arrive at ina first attempt.

Our initial focus for the tool suite was on creatingscenario models that captured the HLA configuration,namely the interaction and object hierarchies.Manually creating the federation configuration file(the. fed file) was tedious and error prone even forsimple scenarios. With the core meta model in place,a very basic model interpreter was created to synthesizethe. fed file. These tools made configuring the HLAvery simple. At this point the largest burden in creatinga scenario was integrating each simulation engine-spe-cific model that would partake in the scenario.

The next iteration of the tool suite focused on inte-grating various simulation engines into the modelingenvironment. Integrating engine-specific modelsdirectly is not very reusable, so we instead focused onintegrating as deeply as possible with the simulationengines themselves. Our first attempt at engine-specificintegration led us to make numerous extensions to themeta model, namely sub-classing of the Federate ele-ment, as discussed in Section 3.1. The integrationmodel interpreter was extended for each engine sothat engine-specific glue code could be generated, asdiscussed in Section 4. Now the HLA configurationand all of the engine-specific code was being synthesizedautomatically from the integration model.

At this point, creating a new scenario was simplerbut the repeatability of scenario execution was provingproblematic. Our RTI did not offer tools to coordinatestarting or stopping numerous federates. Depending onthe order in which, and even the relative time at which,federates were started the scenario outcome wouldvary. We needed a means to allow arbitrary initializa-tion of federates and then a coordinated means to startprogression of the simulation. At the same time weneeded a means of injecting interactions into a simula-tion at specific times. This functionality was needed tosupport debugging of individual engine-specific modelsand to take the place of models that were not yet readyto be incorporated into the federation. The FM wascreated to solve both of these problems. The integrationmodel interpreter was again extended to synthesize asimple XML file that was used to configure the FM.With the FM in place, scenarios could be executedrepeatedly with perfect consistency and we gainedvery flexible control over interaction injection.

The most recent iteration of the C2WT tool suitesought to alleviate a problem we had been experiencing

since the project began. Individuals developing engine-specific models tended to run the entire federation ontheir local machine, while production runs of the fed-eration were performed on a dedicated cluster ofmachines. Developers sacrificed absolute performancefor the convenience of having the federation runninglocally. This approach worked well but developerswere spending significant amounts of time manuallycreating scripts to run their local instance of the feder-ation. Each developer’s local setup was different, butthey all relied upon a common scenario definition in arepository. A change in even a small scenario parameteroften forced every developer to have to manuallyrework their scripts. It occurred to the team that ifdeployment configurations were directly incorporatedinto the scenario model then each developer couldmaintain a separate configuration but a common inter-preter could generate all of the necessary deploymentscripts. The core meta model was extended, as discussedin Section 5.1, and a new deployment-specific inter-preter was developed. With these changes in place,the current C2WT automates many formerly manualprocesses and allows developers to focus on creatingengine-specific models and the overall integrationmodel.

8. Related work

There is prior research on the integration of multiplediverse simulation packages, both incorporating andnot incorporating HLA. Multi-paradigm modeling(MPM)17,18 addresses the methods, tools, and applica-tions related to engineering problems involving themodeling of multiple different domains. Similar toMPM, the most challenging problem for distributedheterogeneous simulation is composing domain-specificmodels.

One of the previous efforts that relates to heteroge-neous simulation, at our institute, is the MILAN frame-work.19 MILAN provides multi-domain simulation ofsystem-on-chip (SoC) designs and integrates severalsimulation tools in order to optimize performanceversus power consumption. This approach is verySoC specific and is not a general engine for heteroge-neous simulation. Co-simulation20–22 also involvesmany similar aspects of heterogeneous simulation,although all specifically focused on hardware/softwaresystems.

Other efforts exist that relate to integrating simula-tion packages via HLA, including OPNET,23

MATLAB-HLA,24 SLX,25 JavaGPSS,26

DEVSJAVA,27,28 and PIOVRA.29 As mentioned ear-lier, the HLA APIs provide run-time support but theproblem of model integration is not addressed in theseefforts.




Relevant commercial integration software does exist,such as the HLA Toolbox30 for MATLAB federates byForwardSim Inc.31 and MATLAB and Simulink inter-faces32 to HLA and driver information system (DIS)-based distributed simulation environments by MAKTechnologies.33 These products focus on integrationof models running on the same simulation engine anddo not provide support for heterogeneous simulations.

In addition, there have also been some efforts onenhancing HLA support by complementary simulationmethodologies, such as in Sarjoughian and Zeigler34

and Lu et al.35 However, these efforts, similar tothose above, pursue HLA integration of isolated simu-lation tools. Moreover, these efforts, except MILAN,do not have any support for model-based rapid inte-gration of simulation tools, and limited, or no, supportfor automated deployment and execution of the result-ing simulation environment. All of these are facilitiesthe C2WT environment natively provides.

9. Conclusion and future work

Integration of complex C2 simulations composed ofnumerous heterogeneous engines is a challenging prob-lem. Each simulation engine may have its own opera-tional semantics and requires integration at not onlythe engine level but also at the engine-specific modellevel.

Pervasive use of models throughout simulationengines opens the door to the use of model-integratedmethodologies for defining integration amongthese tools. In this paper, we discussed the use of acustom DSML-driven modeling environment for het-erogeneous simulation. In this environment, it is possi-ble to rapidly integrate domain-specific modelsfrom diverse simulation engines and to dynamicallygenerate all of the needed configuration and integrationcode. The environment also provides automated facili-ties to manage the deployment and execution of thesimulation itself. Together these tools greatly reducethe time required to design, modify, and test C2scenarios.

In the future, we expect to integrate additional sim-ulation engines to expand the range of possible scenar-ios. Consequently, new simulation engines will requireexpanding the existing integration DSML and infra-structure. These enhancements should allow for greaterscenario flexibility and reduced development, configu-ration, and operational costs. In addition, we areexploring alternatives to include capabilities in theC2WT framework to alter and configure the entire sim-ulation during run time, and to capture and analyzeadditional performance statistics during execution.The public distribution of the C2WT code is availableat http://wiki.isis.vanderbilt.edu/OpenC2WT.

Acknowledgements

The authors acknowledge the invaluable contributions to this

project from our collaborators: Alexander Levis and LeeWagenhals’ group at George Mason University, ClaireTomlin’s and Shankar Sastry’s groups at the University ofCalifornia at Berkeley and Jonathan Sprinkle’s group at the

University of Arizona.

Funding

This work was supported by the US Air Force Office ofScientific Research under the project ‘Human CentricDesign Environments for Command and Control Systems:

The C2 Wind Tunnel’ (contract number FA9550-06-1-0267).

Conflict of interest statement

None declared.

References

1. Alberts DS and Hayes RE. Understanding command and

control. CCRP Publication Series, 2006.2. HLA standard. ‘IEEE standard for modeling and simu-

lation (M&S) high-level architecture (HLA) – framework

and rules’, http://ieeexplore.ieee.org/servlet/opac?

punumber¼7179.

3. Dahmann JS, Fujimoto RM and Weatherly RM. The

Department of Defense high level architecture. In:

Proceedings of the 1997 Winter Simulation Conference,

1997, pp.142–149.4. Sztipanovits J and Karsai G. Model-integrated comput-

ing. IEEE Comput 1997; 30: 110–112.5. Portico RTI. http://www.porticoproject.org.

6. UML – Unified Modeling Language. ‘The Object

Management Group’, http://www.uml.org.7. de Laura J and Vangheluwe H. AToM3: a tool for multi-

formalism and meta-modeling. Lect Notes Comput Sci

2002; 2306: 174–188.8. Tolvanen JP and Lyytinen K. Flexible method adapta-

tion in CASE. The metamodeling approach. Scand J Inf

Sci 1993; 5: 71–77.

9. Cook S, Jones G, Kent S and Wills A. Domain-specific

development with visual studio DSL tools. Addison-Wesley

Professional, 2007.10. Matlab/Simulink. ‘Get Started with MATLAB’, http://

www.mathworks.com.

11. Google Earth. http://earth.google.com.12. OMNeTþþ. http://www.omnetpp.org.13. CPN Tools. http://cpntools.org.14. DEVSJAVA. http://devs-suitesim.sf.net.

15. Delta3D. http://www.delta3d.org.16. Westergaard M. The BRITNeY Suite: A Platform for

Experiments. In: Proceedings of 7th Workshop on

Practical Use of Coloured Petri Nets and the CPN

Tools, 2006.

17. Vangheluwe H, de Lara J and Mosterman P. An intro-

duction to multi-paradigm modeling and simulation. In:

Proceedings of AIS2002, 2002, pp.9–20.

Hemingway et al. 15



18. Mosterman J and Vangheluwe H. Computer automatedmulti-paradigm modeling: an introduction. Simulation2004; 80: 433.

19. Agrawal A, Bakshi A, Davis J, Eames B, Ledeczi A,Mohanty S, et al. MILAN: a model based integratedsimulation. In: Proceedings of the 2001 ACM SIGPLANWorkshop on Optimization of Middleware and Distributed

Systems, 2001, pp.82–93.20. Hoffman A, Kogel T and Meyr H. A Framework for fast

hardware-software co-simulation. In: Proceedings of the

Conference on Design, Automation and Test in Europe,2001, pp.760–765.

21. Rowson J. Hardware/software co-simulation. In:

Proceedings of the Design Automation Conference, 1994,pp.439–440.

22. Becker D, Singh RK and Tell SG. An engineering envi-

ronment for hardware/software co-simulation. In:Proceedings of the 29th ACM/IEEE Conference onDesign Automation, 1992, pp.129–134.

23. Zhang F and Huang B. HLA-based network simulation

for interactive communication system. In: Proceedings ofthe First Asia International Conference on Modelling &Simulation, 2007, pp.177–180.

24. Pawletta S, Drewelow W and Pawletta T. HLA-basedsimulation within an interactive engineering environment.In: Proceedings of the Fourth IEEE International

Workshop on Distributed Simulation and Real-TimeApplications (DS-RT’00), 2000, p.97.

25. Henriksen JO. SLX: The X is for extensibility. In:Proceedings of the 32nd Conference on Winter

Simulation (WSC ’00), 2000, pp.183–190.26. Klein U, Straburger S and Beikrich J. Distributed

Simulation with JavaGPSS based on the high level archi-

tecture. In: Proceedings of the 1998 InternationalConference on Web-based Modeling and Simulation,1998, pp.85–90.

27. Zeigler BP and Lee JS. Theory of quantized systems:formal basis for DEVS/HLA distributed simulation envi-ronment. In: Enabling Technology for Simulation Science

(II), SPIE AeoroSense. Vol. 3369: 1998, pp.49–58.28. Zeigler BP, Ball G, Cho HJ, Lee JS and Sar-joughian H.

Implementation of the DEVS formalism over the HLA/RTI: problems and solutions. In: Spring Simulation

Interoperability Workshop (SIW), 1999, SISO.29. Zacharewicz G, Frydman C and Giambiasi N. Mapping

PIOVRA in GDEVS/HLA environment. In: Proceedings

of Summer Simulation Multiconference (SummerSim’07),The Society for Modeling and Simulation International,2007, pp.1086–1093.

30. HLA Toolbox for developing and executing HLA feder-ates from MATLAB. http://www.mathworks.com/prod-ucts/connections/product_main.html?prod_id¼696&prod_name¼HLA%20Toolbox.

31. ForwardSim Inc. http://www.forwardsim.com/.32. MATLAB and Simulink interfaces to HLA and DIS

based distributed simulation environments. http://

www.mathworks.com/products/connections/product_main.html?prod_id¼696&prod_name¼HLA%20Toolbox.

33. MAK Technologies. http://www.mak.com/.34. Sarjoughian HS and Zeigler BP. DEVS and HLA: com-

plementary paradigms for modeling and simulation.

Trans Soc Comput Simulat Int 2000; 17: 187–197.35. Lu T, Lee C, Hsia W and Lin M. Supporting large-scale

distributed simulation using HLA. ACM Trans ModelComput Simulat 2000; 10: 268–294.

Graham Hemingway is a graduate student at theInstitute of Software Integrated Systems, VanderbiltUniversity, USA.

Himanshu Neema is a staff engineer at the Institute ofSoftware Integrated Systems, Vanderbilt University,USA.

Harmon Nine is a senior staff engineer at the Institute ofSoftware Integrated Systems, Vanderbilt University,USA.

Janos Sztipanovits is the E. Bronson IngramDistinguished Professor of Engineering and directorof the Institute of Software Integrated Systems,Vanderbilt University, USA.

Gabor Karsai is Professor of Electrical Engineering andComputer Science and associate director of theInstitute of Software Integrated Systems, VanderbiltUniversity, USA.




simulation - vanderbilt university

Documents