HLA and Simulation Frameworks - · PDF fileHLA and Simulation Frameworks Bent Bruun Kristensen...

HLA and Simulation Frameworks�

Bent Bruun Kristenseny Ole Vilmannz

yThe Maersk Mc-Kinney Moller Institute for Production TechnologyUniversity of Southern Denmark/Odense University, DK 5230 Odense M, Denmark

e-mail: [email protected]

zDanish Maritime InstituteHjortekærsvej 99, 2800 Lyngby, Denmark

e-mail: [email protected]

COT/6-29

AbstractAn outline of a simulation framework is presented. The framework is based on the High-Level

Architecture (HLA) framework, but is specific to Danish Maritime Institute (DMI). The frameworkpresented defines a universe of real-time simulation concepts which support the more informalconcepts available at DMI, but which respect the principles of HLA. Elements of the analysis,design and implementation of the framework are included.

1 Introduction

This work is initiated because Danish Maritime Institute (DMI) has decided to investigate High-LevelArchitecture (HLA) in order to be able to utilize the standard and its principles in real-time simulationsystems of the future. DMI therefore designed and conducted experiments with a preliminary versionof the Simulation framework [11], [12]. The objective of the Simulation framework is

� to simplify the development of part of the simulator,

� to decrease the needed relevant level of abstraction of understanding,

� to concretize the needed understanding,

� to further develop and mature what is known as the DMI model for simulation systems,

� to restrict and simplify the HLA universe of concepts and terminology and

� to expose a minimal, necessary interface to the universe of HLA by means of a number ofrelated application frameworks all based on HLA and thus compatible with the principles ofHLA.

The bridge of a simulator at DMI is shown in Figure 1. The simulators at DMI are used for trainingof navigators, captains and whole crews in both ship handling, casualty prevention, and human factorstraining (CRM).

�This research was supported in part by Danish National Center for IT Research, Project No. 74.

1

Figure 1: Entity Level Ship Simulator at DMI

Paper Organization. In section 2 we give a very brief overview of the objective and contents ofHLA. In section 3 we give a brief introduction to framework technology, and we outline variouspossibilities of applying HLA at DMI in the context of framework technology. In section 4 we de-scribe, discuss and illustrate the existing simulation framework (based on HLA, but specific to DMI),through a simulation domain model, a comparison of HLA concepts and the DMI universe, and il-lustrative schematic examples. In sections 5, 6 and 7 we outline a revised simulation framework. Inthe analysis part, section 5, the model of the simulation domain is elaborated further, and describedin UML-like notation. In the design part, section 6, various aspects of design are discussed. In theimplementation part, section 7, program fragments in Java are presented.

2 High-Level Architecture Overview

HLA is a conceptual framework because it defines a collection of related concepts for organizationof simulation systems. HLA is also to some extent an application framework because it defines in-teraction interfaces between the federates of the system. Furthermore implementations of the RTI areprovided. An implementation of the RTI and the interaction interfaces can be seen as an applicationframework. Finally, additional tools to support the development of simulation systems are provided.

HLA is used as the basis for a special use at DMI. Based on HLA and an object-oriented pro-gramming language (C++) we provide another application framework, the Simulation Framework.Thus a collection of DMI internal, but HLA compatible concepts are defined and supported by thisSimulation framework.

Background. The vision for HLA cf. [1]: “To allow maximum utility and flexibility, these modelingand simulation environments will be constructed from affordable, reusable components interoperatingthrough an open systems architecture”.

Terminology. In Figure 2 we illustrate a conceptual Crane Simulator Architecture. The whole il-lustration is a federation. The architecture level is the lowest level, i.e. the simulator entity level.Each of the Timer, Oper, etc elements is a federate. The separation of the federation into a number offederates is done based on a functional view. The separation as shown is also based on the concept ofseparation in autonomous federates for obtaining reusable federates with a reasonable and as low as

2

RTIand

FEDEX

(HLA)

Timer

Ship

Crane

Oper

LiftObject

Logger

Visual

HandleCrane

OperatorCabin

Collisiondetection

Environ-ment

Figure 2: Crane Simulator Architecture

possible level of coupling. The RTI illustrates that the federates communicate through this commoninterface.

We briefly describe the following terminology from HLA [1]:

� Federation. A collection of federates with a common Federation Object Model. The federationconstitutes of a number of sub-systems that together with a Runtime Infrastructure (RTI) forma simulation model, i.e. a simulator.

� Federate. A member of a Federation. A federate can be a sub-system of a simulator or a wholesimulator in a multi-simulator Federation.

� Federation Execution. A part of a Federation that is executed in common.

� Runtime Infrastructure (RTI). The central kernel in the architecture of a simulator. All Federatescommunicate through the runtime infrastructure.

� Simulation. A synonym of Federate.

� Support Utility. In a simulator several support utilities are normally part of the Federation.Support tools can be any kind of application interfaced to the simulator with other purpose thandirectly participating in a simulation. The support utilities are for example the tools that canbe used to collect data for debriefing, utilities for monitoring the status of the simulator andsimulator network monitoring tools.

3

� Interfaces to Live Players. Any kind of interface to/with live players. Can range from livesystems of live players, over positional information of live players to dumb terminal interfaceswhere information about live players is manually entered or shown.

� Interface Specification. Describes the way in which communication between architectural el-ements must be accomplished. The interface specification for the HLA software is made inOMG IDL.

� Object Model Template (OMT). A documentation standard that must be used for the documen-tation of the data and interactions to be communicated for HLA Federates.

� Federation Object Model (FOM). The common description of what and when can be commu-nicated between Federates in a Federation. The Runtime Infrastructure (RTI) uses the FOM forrouting the information between Federates.

� Simulation Object Model (SOM). Each Federate provides Objects and Interactions to a Feder-ation. The description of a Federate Objects and Interactions is called the SOM. All the SOMsof all Federates together constitutes the Federation Object Model (FOM).

� Object. An entity that is simulated by one or more Federates and that is of interest to morethan one Federate. Is send and received as requested by the Federate through the RuntimeInfrastructure (RTI).

� Interaction. An entity that is a time marked event simulated by one Federate. Is send from oneFederate to other Federates through the Runtime Infrastructure (RTI).

� Attribute. A named datum belonging to an instance of a class of type Object. The datum can beof any type including integer, float, double and string and have defined cardinality.

� Parameter. A named datum belonging to an instance of a class of type Interaction. The datumcan be of any type including integer, float, double and string and have defined cardinality.

Intention. The ten rules for relations between federation components [1]:

1. Federations shall have an HLA Federation Object Model (FOM), documented in accordancewith the HLA Object Model Template (OMT).

2. In a federation, all representation of objects in the FOM shall be in the federates, not in theruntime infrastructure (RTI).

3. During a federation execution, all exchange of FOM data among federates shall occur via theRTI.

4. During a federation execution, federates shall interact with the runtime infrastructure (RTI) inaccordance with the HLA interface specification.

5. During a federation execution, an attribute of an instance of an object shall be owned by onlyone federate at any given time.

6. Federates shall have an HLA Simulation Object Model (SOM), documented in accordance withthe HLA Object Model Template (OMT).

4

7. Federates shall be able to update and/or reflect any attributes of objects in their SOM and sendand/or receive SOM object interactions externally, as specified in their SOM.

8. Federates shall be able to transfer and/or accept ownership of attributes dynamically during afederation execution, as specified in their SOM.

9. Federates shall be able to vary the conditions (e.g., thresholds) under which they provide updatesof attributes of objects, as specified in their SOM.

10. Federates shall be able to manage local time in a way which will allow them to coordinate dataexchange with other members of a federation.

3 Use of HLA in Frameworks

A framework is a generic program. By the use of the framework a number of related applications canbe constructed. An application is constructed by completing and tailoring the framework to a specificsituation.

Aspects of Framework Technology. For descriptions of various aspects of framework technologywe refer to the following material [3], [4], [5], [6], [7], [8], [9]. The important aspects include:

� Framework and Application Framework: We distinguish between two forms of frameworks —for a framework the collection of related concepts can be used in various kinds of applications— for an application framework the general form of application is an essential part of theframework.

� Development and Use of Frameworks: We develop a framework as a special kind of program,and we use the program, but not as an application.

� Black and White Box Frameworks: A black box element of a framework can be used throughits interface only, whereas a white box element can be used only through an exposition of itsinternal organization.

� Refactoring of Frameworks: A framework can be seen as a generalization over a number ofsimilar applications — the program parts of the framework can be seen as refactorings overprogram parts of these applications.

� Framework Documentation:

Two distinct types of documentation exist for frameworks:

– The documentation intended for the developer of the framework to be used for mainte-nance and evolution of the framework.

– The documentation intended for the user of the framework to be used for the constructionof an actual application based on the framework.

5

Aggregation

Legend:

Specialization

Framework

Hot Spot

Figure 3: Framework Composition

Framework Composition. Frameworks can be organized as a collection of frameworks. A frame-work can be related to another framework in various ways by specialization, aggregation and asso-ciation. If a framework is used in another framework the combination of frameworks can still be aframework.

In general we can imagine that frameworks are classified and given names. Frameworks can thenbe related either in aggregation hierarchies, where one or more frameworks are used as part elementsin the description of a whole framework, or in generalization hierarchies, where one framework isdescribed as a specialization of another framework. In Figure 3 we illustrate framework compositionschematically.

Horizontal and Vertical Frameworks. In the situation of one framework being a specialization ofanother framework, the more specific framework can in two extreme situations either

� add more concepts, structure and interaction at the existing level of generality. The intention isto preserve the application area but explicitly to support more applications by directly offeringa variety of well-known alternatives to the user of the framework. We characterize a frameworkas horizontal if the intention (and its major elements support this intention) is to stay at a givenlevel of generality but to increase the amount of functionality at that level (if we move awayfrom a given starting point and decrease the amount of functionality or if we move back towardsthe starting point), or

� move from a given level of generality to a more specific level, by introducing a number ofspecial concepts, their structure and interaction at this more specific level. The intention is tonarrow the applicability of the more specific framework to a application part area, and at thesame time be more powerful for the support for the applications in this area (by adding specificconcepts, structure and interaction to the disposition of the user). We characterize a frameworkas vertical if the intention (and its major elements support this intention) is to move from amore general level to a more specific level (if we move down from one level to another, and ifwe move up from form one level to another we decrease the amount of functionality from thespecific application area and extends the application area as such).

6

The notions of horizontal and vertical specializations appear to be similar til the notion of hori-zontal and vertical slices of functionality across client domains from [10].

Hierarchy of Simulation Frameworks. The HLA framework is used as the basic framework1. Assuch the HLA framework forms the root of a collection of frameworks. We see the collection offrameworks as combined generalization and aggregation hierarchies of frameworks.

Ver

tical

Horizontal

HLA Framework

Simulation Framework DMI Simulation Framework

Crane Simulation Framework Ship Simulation Framework

Legend:

Specialization

Engine Framework Instrument Framework

. . .

. . .

Figure 4: Horizontal and Vertical Framework Specialization Diagrams

The Simulation framework is a specialization (in the sense that the rules of the HLA frameworkis adhered to) of HLA. The intention of the Simulation framework is to restrict the universe pro-vided by HLA, to ease the construction of HLA compatible simulator (given these restrictions) byproviding an environment that supports the usual DMI-simulator environment, but according to HLAprinciples. The Simulation framework itself provides an initial set-up for a simulation system. Wecharacterize the Simulation framework as a vertical framework (in relation to the HLA framework).To summarize: The Simulation framework does not change anything in the principles and rules ofHLA, it merely creates a limited but structured environment (supported explicitly by the applicationframework), based on the DMI way of understanding of simulation but compatible with the HLAconventions and principles, and it runs based on HLA RTI as the infrastructure.

As a specialization of the Simulation framework we imagine a DMI-Simulation framework inthe sense that the Simulation framework does not necessarily provide a variety of features for typicalsimulation systems. The DMI-Simulation framework applies the Simulation framework, but it adds anumber of more or less standard structures and behaviors as found in simulation systems. The featuresinclude for example threads and processes using shared memory for combining the modeling part of afederate with the infrastructure part supported through the Simulation framework. Of other examplescan be mentioned automatically logging of state and behavior of a federate through the framework. Wecharacterize the DMI-simulation framework as a horizontal framework (in relation to the Simulationframework). In Figure 4 we illustrate (horizontal and vertical) framework specialization diagrams.

Based on the DMI-simulation framework a number of application area specific frameworks maybe found. For the time being only one Crane simulation application exists, but imagine a number ofsuch similar crane simulation systems. It is obvious to re-factor the common elements from these,

1Even though the New Generation software (HLA 1.3NG) is itself based on CORBA which can be seen as a frameworkalso.

7

and form Crane simulation and Ship simulation frameworks as some out of several possibilities asa specialization of the simulation framework. The crane simulation framework includes specific cranefeatures only. All common simulation features are kept in the more general simulation framework.We characterize the crane simulation framework as a vertical framework (in relation to the DMI-Simulation framework). Examples of features of the crane simulation framework include for examplethe need for a generic mathematical crane model, the availability of objects to be lifted, the possibilityof collisions between the environment and objects and the position of an object is modeled by themathematical crane model when the object is being lifted by the crane hook or crane spreader.

Crane Simulation Framework Ship Simulation Framework

* *

Legend:

Aggregation

Engine Framework Engine Framework Instrument FrameworkInstrument Framework. . .

. . . . . .

. . .n n

1 1

Figure 5: Part-Whole Framework Diagrams

Furthermore a number of part frameworks may exist. A part framework is dedicated to a partof the system only, and the application constructed from a part framework is a part of the entireapplication only. We imagine part frameworks for various kinds of engines (Engine framework),mathematical/physical model frameworks (Math-Model framework), frameworks for various kindsof graphical user interfaces (GUI’s) such as the operator GUI (Oper-GUI framework), frameworksfor the construction of software implemented simulator instruments (Soft-Instrument framework),frameworks for interfacing a simulator with physical hardware systems and instruments (Instrumentframework), frameworks for development of visual systems (Visuals framework), etc. In Figure 5 weillustrate part-Whole framework diagrams.

An example of a part framework is a mathematical crane model framework with common elementsfactored out. The common elements of a mathematical crane model include function for modelingthe base of the crane, the tower, the arm, the line and the winch with winch engine. As possiblespecialization of the model, movements such as driving of the crane base along a track, rotation of thebase, lifting of the arm, rotation of the arm and rotation of the hook or spreader, must be available inthe framework. The framework can also include different engine types to be used for the specializationof the crane.

Architectural Levels for Use of HLA. HLA can be used either at the overall architectural levelto create and compose large simulation systems of other simulation systems. HLA can also be usedinside a simulation system to organize small simulator parts which themselves cannot be consideredas independent simulators. Such simulator parts only make sense together with a number of federateswith similar simulator parts. There is no restrictions on intermixing different kinds of simulationarchitectures on different levels of abstraction. An example on a possible system architecture couldbe to use 3MS (DMI’s proprietary simulator architecture) on the simulator level and use HLA onthe inter-simulator level, i.e. SimFlex Navigator is based on 3MS and when interoperability betweenseveral SimFlex Navigator’s are asked for they can be interconnected in an architecture through theHLA framework.

The effect (if any) of simulation frameworks based on HLA on several levels is unknown. Effi-ciency could be a problem. It is often seen that the higher architectural level we operate on the larger

8

objects, i.e. the more data we need to communicate for each of the federates time steps. On the higharchitectural level the update frequency is often seen to be relatively low. The lower architectural levelthe higher frequency with smaller amounts of data per cycle. This is though not always true but canoften be used as a rule of thumb. The performance of the HLA software is documented on the DMSOwebsite with very promising results2.

ShipCrane

SimulatorRTIand

FEDEX

(HLA)

HarborCrane

Simulator

ShipSimulator

OperatorGUI

ShipCrane

Simulator

StatusLogger

CommonEnviron-

ment

RTIand

FEDEX

(HLA)

Timer

Ship

Crane

Oper

LiftObject

Logger

Visual

HandleCrane

OperatorCabin

Collisiondetection

Environ-ment

ContainerInfo

Figure 6: Simulator to Simulator Interoperability Level

In Figure 6 we illustrate two architectural federation levels. The first level is on the level ofseveral entity level simulators interoperating, i.e. two ship crane simulators, a ship simulator anda harbor crane simulator. The simulator on this level has special purpose supporting federates asillustrated with an operator GUI (operator console), common environment federate, a federate forlogging data and a container information federate. The purpose of the operator GUI is to provide aninterface for controlling the simulation at that specific architectural level. The environment federateis to provide information to the entity level simulators about the common environment. The purposeof the federate for logging parts of the data that is being communicated between the federates is toprovide data for debriefing and performance analysis of a training session. The container informationfederate provides information about objects that the cranes can operate on with position, velocity andother kind of information.

The second architectural level is a so-called entity level simulator level. The illustration is a shipcrane simulator with the federates of such a stand-alone simulator. The federates include mathematicalcrane model federate, interface to hardware handles, buttons and joysticks federate, visual systemfederate, collision detection federate etc. The bridge of an entity level ship simulator at DMI is shownin Figure 1.

4 Existing Simulation Framework

In this section we present and discuss the existing Simulation framework. We present the conceptualmodel underlying the framework, and we compare this model to the HLA concepts and the DMI uni-

2The efficiency of the New Generation software (HLA 1.3NG) based on CORBA is probably less impressive.

9

verse. The presentation and discussion is based on a few concrete, but schematic examples on theactual use of the existing Simulation framework [12]. Unfortunately the examples are not very com-prehensive, but they are intended to be simple and small. The examples form a common backgroundand material for the following three sections about analysis, design and implementation of the revisedSimulation framework. The contents of the present section and sections 5, 6 and 7 has been devel-oped integrated and in an iterative manner. However, for presentation purposes we have organized thematerial in these sections.

4.1 Simulation Domain

We discuss the problem domain for the user, i.e. the universe by which the user understands thesimulation, and by which the user forms the actual elements of the simulation system. By the user wemean the user of the framework, not the user of a simulation system constructed as an application fromthe framework. The user needs to have an understanding of the problem domain (i.e. the simulationconcepts) and the software domain (i.e. the framework as a piece of software), because the users bothhave to design a model in terms of the simulation concepts, and realize this model as a refinement ofthe framework.

The simulation concepts are a mixture of the usual DMI-universe and the HLA concepts. We usethe names from the HLA framework, but we shall later list both the important concepts of the DMIcommunity which are no longer available, and explain the new ones from HLA.

A federation (in DMI terminology a simulation system or a simulator) consists of a collection ofrelated federates (in DMI terminology a subsystem). Each federate maintains and controls a collectionof objects (in DIM terminology a message). A federate owns a collection of federate objects. Afederate object has a number of attributes. An federate object has no methods or similar features, butattributes only. The federate objects can be partially shared among the federates. An federate canuse federate objects of another federate by means of subscribing to some of the attributes of federateobjects of the other federate. The other federate can temporarily transfer the control over an attributeto the subscribing federate. An attribute can either be federate, foreign or transferable. The federateobjects form the “data model” of a federate.

Each federate has a collection of private objects. A private object has attributes, methods etc. asusual objects known from object-oriented programming languages. Typically the specific format ofprivate objects is given by the actual object-oriented programming language used. The private objectsof a federate can not be accessed from other federates, and as such private objects are not part of theshared objects of the simulation.

The objects of a federate in the framework are implemented in a number of embedded datastruc-tures that are used to control the execution and communication with other federates of the federation.Updated attributes of the federate objects are automatically transfered to subscribing federates andexecution is based on updated attributes that are subscribed to from other federates.

Timing and syncronization in simulation systems is an essential topic. HLA provides mecha-nisms to support timing and syncronization. A selection of these mechanisms are imbedded in theframework.

In a federation execution communicated data must be kept as low as possible due to performance.HLA per default only routes updated data and supports Routing that is used to limit communicationbased on rules when to route and when not to route data (e.g. based on distance between simulatedvehicles).

� federation: A federate is the system of a simulator. The running system used for training of

10

personnel, in either handling of some kind of a system, in co-operation and team working inexecution of some tasks, is the federation.

� federates: Each of the conceptual architectural elements on some kind of appropriate granularityis the federate.

� object: An object is the instantiation of a class. The object is owned by a federate. An object asa singleton or many objects of same class can exist.

� attribute: The attributes of an object describe the type and cardinality of the values that it keeps.An attribute is kept by an object. The attributes carry other information such as who owns itand if the ownership can be given over to another federate, how accurate the transmission of theattribute should be etc.

� interaction: An interaction is an object, with the difference that the object is send only whentimestep are granted, while an interaction is time stamped and send and received as fast aspossible.

� parameter: The parameter of an interaction is analog to an attribute of an object. At the momenta parameter has no type and cardinality.

� federate, foreign or combined (object): An object of a specific class type can normally be ownedby one federate only. By use of the combined object type several federates can own the sametype of objects.

� federate, foreign or transferable (attribute): An attribute is normally initially owned by thefederate that initializes the object. The attribute is thus federate, or if not owned by the federateit is foreign. If the attribute is transferable it means that the attribute is initially owned by thefederate that initializes the object and that the ownership can be given over to another federate.

� subscribe (to an attribute): Ask the RTI to send attributes that are subscribed to the subscribingfederate. The values of the attribute are automatically updated and can be requested through thedata handling class of the simulation framework.

� publish (an attribute): Inform the RTI that the publishing federate is to provide value updatesto the attribute in question.

� Timer or time step: The time step is given initially and is used throughout the simulation.Though if asked for a function for changing the time step for a federate can easily be imple-mented and included in the framework.

� Routing: At the moment routing is not supported by the framework.

4.2 HLA Concepts Versus DMI Universe

Downgraded DMI Concepts. A list of the important DMI-concepts (used in the 3MS architectureand by the 3MS utilities) which are no longer supported by the Simulation framework include:

� Message, the concept by which data is structured (in the form of a C-structure). In 3MS amessage is constructed by a header, followed by an data area of various kinds of information.The header holds information about the C-structure name, the size of the data structure, the

11

sender and the receiver. Through this information the sub-system should implicit know howto interpret the list of information. The information on what to receive and what to provide ofinformation to/from the Federation is directly stored in the sub-system logic.

� Intermessagepassing, the logic by which data is distributed between the various sub-systems inthe 3MS framework. In a HLA federation the data distribution is part of the RTI, the logic ofhow and when the data should be distributed is based on requests from the federates. The logicis decided by the subscription and provision of data of the federates. The 3MS infrastructure(the Task Manager) is initialized with information on how and when to distribute data amongfederates and is executed by the intermessagepassing function of the 3MS framework. The logicis static in the sence, that it is the same at all times of a federation execution.

� Timer, the handshake to the Task Manager to start an advance of the time in the simulator. In aHLA Federation the time must be controlled by the federates themselves. The federates informthe RTI what their strategy concerning the time stepping, and controlling of time etc. is. Whenthe federates know the time they can ask the RTI if a time advance can be granted, i.e. the RTI isin control of the entire simulation time, whereas the federates know their local time and specifyhow they want to be part of the timing of the Federation.

� Subsystem, is now called a federate. Conceptually there is no difference in between a subsystemand a federate. Though many details are different and the method of communicating withthe federation, i.e. the simulator is very different. A federate has extended responsibilitiescompared to the subsystem.

� Line/Connection, is the tcp/ip, streams, NT pipe and other technological solution to send achunk of data from one running subsystem to another. This is replaced by the CORBA technol-ogy which again is based on tcp/ip, streams, etc.

Upgraded HLA Concepts. A list of new important concepts from HLA which have no correspond-ing elements in the DMI-universe include:

� Federate objects and their attributes as shared entities between federates. Ownership of at-tributes. Transfer of ownership of attribute: Several advanced possibilities are available inHLA.

� The notion of a proxy object representing the object and its attributes which a federate sub-scribe to. When a subsystem in 3MS sends data the Task Manageren can pack messages intoother structures. The data received by a subsystem are usually also stored as a whole packagecorresponding to some kind of proxy. In HLA the proxies are proxy objects.

� Selective simulation time steps for a federate. In 3MS a unique length of each time step isnormally applied for all subsystems. In HLA each federate has its own length of its time stepas requested by the federate.

� Routing of data. The RTI can be requested only to provide data from one federate to anotherfederate when certain criteria are fulfilled.

� Availability of federates. In 3MS all specified subsystems must be part of the federatioon execu-tion at all times, whereas HLA provides mechanisms for federates to join and leave a federationexecution.

12

Application

HLA Framework

SimBase

SIMInfoHandle

ObjectCreatorBase

TheSimulationClass SimHLACreator

HLA Software

RunThread()

Figure 7: Overall Framework Architecture

4.3 Organization: Existing Simulation Framework

The following subsections give only a logical view on the Simulation framework — both with respectto the concepts defined and with respect to the notation used in the examples. The presentation hasabstracted from the very concrete aspects of the concepts as well as the concrete forms of the variousrepresentation of the descriptions as for example omt-, dat- and cpp-files. In this section we brieflyoutline the practical organization of the existing simulation framework cf. [12].

The framework makes use of the standard HLA input files, such as the FOM. This file is the so-called FED file. Besides this file the framework makes use of an object and an attribute definition filethe dat file. A number of examples of the format are included in the present section together with theexamples. No tools to support the implementation of the dat file exists, whereas the HLA standardOMDT tool, for definition of the SOM (FOM) is used for the construction of the FED file.

A comparison of the formats of the OMT and the FED files for class/object is made in appendix A.In this appendix the example 2 included in the present section is detailed.

The actual realization of these concepts from the simulation domain are supported by a num-ber of partially defined interaction classes with partially specified methods and attributes. The usershould feel that the framework offers the right software components for development of his federates.There is though a difference between understanding the concepts and utilizing an actual softwaresystem to realize the use of these concepts, therefore this description is not intended to be used as atutorial/manual for the framework. The existing simulation framework contains the following com-ponents HLASoftware, SIMinfoHandle, SimBase, ObjectCreatorBase, TheSimulatorClass, SimHLACreator,RunThread. The organization of these components are illustrated in Figure 7.

The user of the framework must implement the SimHLACreator and the TheSimulatorClass. Tem-plates of these classes are included in the framework.

13

4.4 Schematic Examples: Existing Simulation Framework

We include three characteristic, but schematic examples on the use of the existing simulation frame-work. The examples are included to demonstrate the capabilities of the framework. The source codefor example 2 is included in appendix A as a C++ program.

Example 1 demonstrates the use of the framework for using several federates of the same typeproviding federate objects to each other and subscribing to attributes of each others objects. This typeof simulation is used when several of the same type of simulators are used in a common simulation,e.g. implemented in a bridges between equal simulation systems. Example 2 is used to demonstratesimple subsription of attributes of another federates object. The last example is used to demonstratethe possibility to transfer ownership of attributes between federates.

RTIand

FEDEX

(HLA)

MultipleLifeobject 1

MultipleLife1

MultipleLife2

MultipleLifeproxy 2

MultipleLifeproxy 1

MultipleLifeobject 2

Figure 8: Example 1 architecture

Federation Application Example 1. In Figure 8 the example 1 architecture is shown. Two federatesof the same type are given. A federate has its own object and has a proxy object of the same classfrom the other federate. The data set up file (MultipleLife.dat) used by both federates for example 1has the form:

OBJECTSOBJECT-MULTIPLE MultipleLife COMBINED

ATTRIBUTE OWNER-SELF ID int 1ATTRIBUTE OWNER-SELF Counter int 1

EOAEOA

The COMBINED tag implies that the object can be of type federate (owned by the federate) and oftype foreign (owned by an other federate).

14

RTIand

FEDEX

(HLA)

A object

A

B

B proxy

B object


Federation Application Example 2. In Figure 9 the example 2 architecture is shown. Two feder-ates, A and B, of different types are illustrated. Each of the federates has their own object, i.e. the A andthe B object, respectively. The federate A subscribes to some of the attributes of the federate B objectB. The attributes provided by the federate B are b1, b2 and b3, whereas the federate A has a proxy of theattributes b1 and b3. Only the attributes b1 and b3 of B are provided by the federate B. The data set upfiles for example 2 have the form (AFederate.dat):

OBJECTSOBJECT-SINGLE A FEDERATE

ATTRIBUTE OWNER-SELF a1 int 1EOA

OBJECT-SINGLE B FOREIGNATTRIBUTE OWNER-SELF b1 int 1ATTRIBUTE OWNER-SELF b3 int 1

EOAEOA

and (BFederate.dat)

OBJECTSOBJECT-SINGLE B FEDERATE

ATTRIBUTE OWNER-SELF b1 int 1ATTRIBUTE OWNER-SELF b2 int 1ATTRIBUTE OWNER-SELF b3 int 1

EOAEOA

Federation Application Example 3. In Figure 10 the example 3 architecture is shown. Two feder-ates, C and D, of different types are illustrated. Only one federate object (the object C) is operated on

15

RTIand

FEDEX

(HLA)

C objectpartly

(ownership toD of part)

C

D

C proxy partly(ownershipfrom C of

part)


by both federate C and D. The example illustrates that the federate C gives up ownership of the attributec2 to federate D. Thus the C object is originally owned by the federate C but the federate D acquiresownership of the c2 attribute of the C object. The object C is still located with the federate C, but onlythe federate D is allowed to provide the attribute c2 and thus the C object is partly a proxy object (atleast for the attribute c2). The object D, as object of federate D and proxy object of federate C is notshown in Figure 10. The data set up files for example 3 have the form (CFederate.dat):

OBJECTSOBJECT-SINGLE C FEDERATE

ATTRIBUTE OWNER-SELF c1 int 1ATTRIBUTE OWNER-TRANSFERABLE c2 int 1

EOA

OBJECT-SINGLE D FOREIGNATTRIBUTE OWNER-SELF d1 int 1

EOAEOA

and (DFederate.dat)

OBJECTSOBJECT-SINGLE D FEDERATE

ATTRIBUTE OWNER-SELF d1 int 1EOA

OBJECT-SINGLE C FOREIGNATTRIBUTE OWNER-SELF c1 int 1ATTRIBUTE OWNER-TRANSFERABLE c2 int 1

EOAEOA

16

5 Analysis: Simulation Framework

In this section we identify the need for a more simple and understandable universe of simulationconcepts, and especially richer description of the classes and objects being central elements of sim-ulations. Actual proposals for alternative descriptions are included in the design section. Here weelaborate on the model of the simulation domain from the previous section, and we illustrate theresulting federation ontology in UML-like notation.

Elaboration of Model of Simulation Domain. A simulation, i.e. a federation, is an executingsystem. It is interactive in the sense that federates dynamically can join or leave the federation. Theobject models of any potential federation is statically described, and is part of the federation objectmodel. The federation object model is given once and for all to the RTI and the federation executionerwhich represents the given federation object model.

A federate is described. An actual federate is instantiated from the description. The descriptionincludes the description of the objects of the federation. Two kinds of objects exist. The one kind areusual objects which are part of the federate. The other kind of objects are proxy objects, which usuallyrepresent objects of other federates. A proxy object exist when one federate subscribe to attributes ofanother federate. The proxy object then has exactly the attributes subscribed to.

We introduce the notion of the Federate Class Model (FCM) The FCM contains all the classdescriptions from which the objects of the federates can be described. A federate utilizes a class fromthe FCM by instantiating one or several objects of the class. For each object (and not class) of afederate, the federate specifies for each attribute if the attribute is federate, foreign or transferable.A federate attribute belongs to the object of the federate, a foreign attribute belongs to an object ofanother federate, and a transferable attribute belongs to the object of either the federate itself or aforeign federate. The ownership of the transferable attribute can be transfered between federates. Ifall the attributes are federate attributes the object is seen as a usual object. If all the attributes areforeign the object is a proxy object. If one or more of the attributes are either foreign or the ownershipof the attributes are transferable to a foreign federate the object can be a mixed usual and proxy objector a proxy object. The last case is possible when all attributes are federate and ownership is transferedto a foreign federate.

Several instances of the federates can be instantiated from a description. Upon instantiationthe objects of the federate are instantiated. An instantiated federate joins an executing federation.When registering for participation in a federation, the federate announces its objects to be availableto other federates of the federation. Upon registration, the federate announces objects (and implicitlyattributes) it wants to provides to other existing federates, and the federate requests which objects (andimplicitly attributes) of existing federates to which it wants to subscribe.

Federation Ontology. A partial federation ontology is summarized as follows:In Figure 11 we illustrate the following structures

� A federation is (an underlying, possibly shared) RTI, a federation executioner and one or morefederates.

� A federate is either a basic federates or a composite federate.

� A basic federate has no further parts and is seen as an atomic unit. A basic federate correspondsto a DMI-subsystem.

17

Legend:

Nested description

Federation

BasicFederate CompositeFederate

FederationObject*

1

1

Federate*

* Federate FederationAttribute

Federation

FederationObject

Figure 11: Federation and Federate

� A composite federate has federate parts, and is similar to a federation. A composite federatecorresponds to a DMI-simulator.

� A federate consists of a number of federation objects.

� Descriptions of federates, federation objects and federation attributes are internal to a federa-tion.

FederationObject

TransferableAttribute

FederateClass ForeignClass

FederateAttribute ForeignAttribute**

**

1 *

FederateAttribute

ForeignAttribute

FederateAttribute


1 1

Figure 12: FederationObject and FederateAttribute

In Figure 12 we illustrate the following structures

� Two kinds of federation objects exist, namely federate class (objects) and foreign class (objects).

� Each foreign class (object) is related to exactly one federate class (object). Any federate class(object) can be related to a number of foreign class (objects). A foreign class object models aproxy object of the federate class (object).

� Three kinds of federation attributes exist, namely federate attributes, foreign attributes andtransferable attributes.

18

� A federate class (object) consists of federate and transferable attributes only. A foreign class(object) consists foreign and transferable attributes only.

� The attributes of a foreign class (object) and (the attributes of) its federate class (object) arerelated as follows (not shown in Figure 12)

– A federate attribute of the federate class (object) can be a foreign attribute of the foreignclass (object).

– A transferable attribute of the federate class (object) can be either a foreign or a transfer-able attribute of the foreign class (object).

6 Design: Simulation Framework

In this section we discuss various aspects of design. We have deliberately postponed further elab-oration of the class diagrams from the analysis section until the implementation section. Instead inthe following subsections, we discuss the notion of proxies in simulation systems, we discuss defi-ciencies of the existing object model format and outlined an improved format, and present a possiblerealization of the composite federate.

6.1 Proxies are Concepts in Simulations, not Implementation.

The focus is on the situation in which one federate subscribes to (some attributes of) a federate objectof another federate. According to the rules of HLA this could not be supported by means of distributedobject systems. By distributed objects the subscription mechanism could be seen simply as a matterof one federate accessing the methods/attributes of an object in another federate. In simulation theunderstanding implies that the subscribing federate must itself have a proxy object of its own torepresent (the relevant attributes only of) the object of the other federate. It is an essential conceptof the simulation domain to explicitly think (and implement) in terms of proxies, not because theuser of the system has to implement the proxy or any special functionality in accordance with this, butbecause it is part of the understanding of simulation based on independent subsystems. The simulationproceeds in time steps. Each federate has its own length of a time step. An executing federate withattributes of an object, which are subscribed to from another federate are updated after the executingfederate has finished its current time step, and before a subscribing federate initiates its next time step.

6.2 Object Model Format

In HLA the OMT format is used to describe HLA objects. The OMT format is supported by an OMTEditor. The SOM and FOM descriptions are given in a format called the FED format. The FED for-mat is a subset of and generated from OMT descriptions. The OMT format is a list of class/objectdescriptions. To each of the classes all its attributes are described throughout including type, cardi-nality, transfer of ownership allowance, update reliability, update type, accuracy and ordering of themessages. The OMT Editor supports sub-classing. The FED format is a very simple format describingthe class/object and the name, update reliability and ordering of the messages of its attributes.

Problems with the OMT Description. The problems and deficiencies with the existing descriptionsinclude

19

� Only limited use of abstraction.

Set-up data files support a very limited form of abstraction only3. Furthermore such data filesare typically kept separate from the simulation system, instead of being an integrated part of thesystem configuration software.

Alternatively, abstraction is introduced, in the sense that we introduce the possibility to namea delimited chunk of data, to use it in the description of other chunks of data (as a kind ofaggregation), and to organize named chunks of data in generalization hierarchies (as a kind ofspecialization).

� Only limited support for reuse.

The typical form of reuse is by means of copy and paste, where the relations between theexisting parts and the new parts are lost.

Alternatively, the descriptions can be organized in classification and aggregation hierarchies tosupport refactoring of descriptions. More advanced kinds of descriptions could even be used toform frameworks for such descriptions to enable explicit reuse.

� The need for more information.

The information included in the OMT format fulfills the requirements for an ordinary use ofHLA, but in the case where another world of simulation concepts is created the informationmay not be sufficient.

To construct the more powerful Simulation framework additional redundant information aboutthe objects is necessary.

Additional Information and Features. The additional redundant information includes

� The owner of the object. Is the object the primary object or a copy as a proxy of the object. Thefederate that owns the object and instantiates the object holds the object while other federatesthat are subscribing to information of the object (value of attributes of the object) can have acopy as a proxy of the object.

� The owner of an attribute. The object can be owned by one federate while another federate canown or at least get the rights to own the attribute.

� The types of the attributes. Types are present in the OMT description, but are not included inthe FOM description.

� Multiplicity of a given object. Can a given object only exist as a singleton in a Federation orcan multiple instances of an objects exist at the same time. This information is provided.

The additional features of HLA include:3The notation is similar to, but not as bad as, various kinds of data files at DMI for the specification of set-up data.

Comprehensive amounts of data is organized as sequences of logical related chunks of data in files that are read and parsedat set-up time of the simulation systems. The structure and the interactions (and rules for these) are specified by meansof this kind of data files. Instead this kind of data could be organized in terms of classes and objects. Certainly thiswould improve the readability. It could be that no object-oriented programming language is able to support this kind ofdescription in a flexible and efficient way. It may not be relevant or acceptable to use an object-oriented programminglanguage. Abstractions move the description at another abstraction level, the relations among the various abstractions aremade explicit, and the understandability of the description is improved considerably.

20

� Multiple instances of an object. In 3MS typically a logically individual objects are technicallyorganized as one object with all necessary properties (as an example the various traffic shipsused in a simulation to form natural surroundings for the simulated ship are organized as oneobject in 3MS).

� Transferable attributes. In 3MS an attribute always belongs to and is entirely controlled by agiven subsystem.

� Joining and cancellation a federation. A federate can join and be part of a federation at anytime. The same federate can cancel its role to be part of the federation. This is not possible inthe 3MS system.

Revised OMT Description. The overall intention of the revised description is to support the under-lying understanding of a simulation organized as a collection of federates, each of which controls acollection of objects. The objects belong to a federate but can be accessed by other federates, or theycan be temporarily transferred to another federate to under its control. The objects and their attributesare controlled by the federate in the sense that the actual reading and setting of the values of the at-tributes are done by the federate as part of the realization of a simulation step of the federation andthe federate.

� Class based as well as object based (singular objects) description is possible. The cardinality ofa singular object is one, and many for a class.

� Class descriptions are either global to a federation or local to a federate.

� Object instances (either as singular object descriptions or instantiations of objects by means ofreference to class descriptions) are local to a federate.

� A federate can refer to an object instance of another federate, and specify the needed attributesof that object.

� An object is owned by the federate at which the object is instantiated.

� An attribute is per default owned by the federate at which its object is instantiated. Alternatively,an attribute can be specified to be either transferable or foreign.

� For each attribute the type and cardinality is specified.

Revised OMT Description: Example. Here we outline a revised OMT description for a schematicexample. The Definition of class Oper for a federation (File: xx.dat):

class Oper : An other class {attribute Attrib1 <Type> <Cardinality>attribute Attrib2 <Type> <Cardinality>attribute Attrib3 <Type> <Cardinality>

}

And the instantiation of object Oper in a federate sub-system: (File: yy.dat):

21

\#include <xx.dat>

object Oper {Cardinality <MULTIPLE, SINGLE> (mandatory)Owner <FEDERATE, FOREIGN> (mandatory)Attributes-I-want-to-know-about Attrib1, Attrib3 (mandatory)Attributes-OwnerShip <attribute navn>

<TRANSFERABLE, FEDERATE, FOREIGN> (optional)}

6.3 Composite Federates.

Composite federates are not supported directly in HLA. We may see a composite federate as an entirefederation, and then support the interaction between federations.

Federation

Federate

CompositeFederate2

BasicFederate

Bridge1

Figure 13: CompositeFederate and Bridge

� A composite federate is represented as an independent federation.

� A composite federate consists of a basic federate (which is part of the given federation, andworks like a placeholder in the given federation), and another entire federation. A bridge is therelation between this basic federate and a similar federate of the other federation (a placeholderin the other federate).

� The relation between two composite federates can be either lateral or nested (both cases arerepresented by a bridge between two of their respective federates). The relation is lateral if thecomposite federates are considered to be at the same level. The federates of the bridge simplyrelate to equally important federates. The relation is nested if the one composite federate isconsidered to be a part of the other federate. The federates of the bridge then relate a part fed-eration to a whole federation. In Figure 13 we illustrate how a bridge connects two (composite)federates of (different) federations.

HLA gives no special support for relating federates of a bridge4. The federates have to be con-nected by means of specific software. A bridge is then seen as a component of the framework to a

4A general approach could be to consider the RTI a potential federate at another level. By giving the RTI an federateinterface a bridge between two federations could be constructed by making the RTI’s of the federations to federates at onelevel higher and connect these by means of yet another RTI at the higher level.

22

large extent probably as a black box component. Each federate of a bridge will have each own ob-jects as part of its federation. The software makes the two object models exchange values, as well ascoordinates time aspects.

Bridges may exist for federates in general, and between DMI-3MS simulations disguised as fed-erates. This type of bridges are expected to be very important in the situation where existing DMIsimulators are going to be part of larger simulations. The 3MS systems works as a federate in a realHLA federation. In this situation the software of the bridge has to coordinate the existing messagesystem of 3MS with an object model of the HLA federate. Again a black box type of component isexpected to solve integration of the two federate types. Alternatively, the framework could contain awrapper which in general turns a 3MS subsystem into a real HLA federate.

7 Implementation: Simulation Framework

In this section we discuss the essential elements of a preliminary Simulation framework in a JAVA-likenotation.

7.1 Framework Development

The following collection of abstract classes supports the (partial) federation ontology from the analysissection.

Classes Federation and Federate. The classes form the entire federation universe, but they do notsupport the interactive nature of a federation with federates which are registered and removed froman executing federation. As an exemplification the main part include the instantiation of a federation(ff) and insertions and removals of federates (bf11 and bf2) from the federation (the insertFederate

and removeFederate methods are among other utilities given in appendix B).

class hla {public static void main ( String[] args) {

FF ff = new FF();...FF.BF1 bf11 = ff.new BF1();ff.insertFederate(bf11);...FF.BF2 bf2 = ff.new BF2();ff.insertFederate(bf2);...ff.removeFederate(bf11);...

};}

Classes Federation and Federate. Class Federate is described internal to Federation. The actualFederate’s are registered in a list (the RegisteredFederates, among the utilities given in appendix B).Class Federate includes a number of abstract methods to be specified in concrete Federate’s and a fewconcrete methods (not specified in detail).

class Federation {...abstract class Federate extends Record {

abstract void takeTimeStep(double dT, double sT);

23

abstract void registeredInstance(FederationObject fo);abstract void removedInstance(FederationObject fo);abstract void acquiredOwnerShip(FederationAttribute a);abstract void releasedOwnerShip(FederationAttribute a);

void acquireOwnerShip(FederationAttribute a) ...void releaseOwnerShip(FederationObject o, FederationAttribute a) ......

}abstract class BasicFederate extends Federate {

...}abstract class CompositeFederate extends BasicFederate {

Bridge theBridge;...

}abstract class Bridge {

...}...

};

GetAttribute

SetAttribute

OwnerAttribute

ForeignAttribute

FederateAttribute


FederationAttribute

FederationClass ForeignClass FederationObject FederationAttribute

GetAttribute SetAttribute OwnerAttribute

Federation

FederateAttribute ForeignAttribute


Figure 14: FederationObject and FederationAttribute

Classes FederationObject and FederationAttribute. In Figure 14 we illustrate a reorganization ofthe attributes. The attributes FederateAttribute, ForeignAttribute and TransferableAttribute arespecializations of respectively GetAttribute, SetAttribute and OwnerAttribute which are all describedinternal to FederationObject.

Class FederateClass has internal attribute classes FederateAttribute and TransferableAttribute,and class ForeignClass has internal attribute classes ForeignAttribute and TransferableAttribute.

class Federation extends Record {...abstract class Federate extends Record {...};

class FederateClass extends FederationObject {...protected class FederateAttribute extends SetAttribute { ... };protected class TransferableAttribute extends OwnerAttribute { ... };

};

24

class ForeignClass extends FederationObject {...protected class ForeignAttribute extends GetAttribute { ... };protected class TransferableAttribute extends OwnerAttribute { ... };

};

class FederationObject extends Record {...class GetAttribute extends FederationAttribute { ... };class SetAttribute extends GetAttribute { ... };class OwnerAttribute extends SetAttribute { ... };

};

class FederationAttribute extends Record { };...

};

Lists of ForeignObjects and FederationObjects. Class Federate has two lists of FederationObject’s,a list of ForeignObjects and a list of FederateObjects (see appendix B for details). The FederationObject

is inserted in the corresponding list upon instantiation through the constructor. Each FederationObject

is related to its Federate by the myFederate reference. Each ForeignClass object is related to itsFederateClass object by the myFederateObject reference. These references are set up through ini-tialization as well.

class Federation extends Record {...abstract class Federate extends Record {

...FederationObjectQueue ForeignObjects = new FederationObjectQueue();FederationObjectQueue FederateObjects = new FederationObjectQueue();

}

class FederateClass extends FederationObject {FederateClass(Federate f) {

myFederate = f;f.FederateObjects.insertObject(this);

};...

};

class ForeignClass extends FederationObject {ForeignClass(Federate f, FederationObject fo) {

myFederate = f;myFederateObject = fo;f.ForeignObjects.insertObject(this);

};protected FederationObject myFederateObject;...

};

class FederationObject extends Record {protected Federate myFederate;...

}...

};

7.2 Framework Use

Federation Class FF and FederationObject Classes. We illustrate the use of the framework fromthe previous subsection by extending the abstract concepts. The federation is FF as a specialization of

25

class Federation. Two federation classes BF1 and BF2 (shown in further detail in the next paragraph)are specializations of BasicFederate. In class FF we describe the FederateClasses and ForeignClassesof the federation, namely FEC1, FO1C1, FO2C2, FEC2 and FOC2. We describe how these are implicitlyrelated by means of conventions. The restrictions among related objects are only secured partially andalso by conventions only. Instances of these classes are used in the federation classes BF1 and BF2.

Class FEC1 is a FederateClass with fa as a FederateAttribute and ta as a TransferableAttribute.Classes FO1C1 and FOC2 are ForeignClasses for FEC1. Class FO2C1 has with fa as a ForeignAttribute

and ta as a TransferableAttribute. Class FO1C2 has both fa and ta ForeignAttributes.Class FEC2 is a FederateClasswith fa1 and fa2 as FederateAttributes and ta1 and ta2 a TransferableAttributes.

Classes FOC2 is a ForeignClass for FEC1. Class FOC2 has with fa2 as a ForeignAttribute and ta2 as aTransferableAttribute.

In respectively FO1C1, FO2C1 and FOC2 the reference myFederateObject is type casted to respectivelyFEC1, FEC1 and FEC2, as well as their attributes are instantiated with their respective attribute of theirrespective FederateClass as a parameter.

class FF extends Federation {

class FEC1 extends FederateClass {FEC1(Federate f) {

super(f);};FederateAttribute fa = new FederateAttribute();TransferableAttribute ta = new TransferableAttribute();

};class FO1C1 extends ForeignClass {

FO1C1(Federate f, FederationObject fo) {super(f, fo);

};FEC1 myFederateObject = (FEC1) super.myFederateObject;ForeignAttribute fa = new ForeignAttribute(myFederateObject.fa);TransferableAttribute ta = new TransferableAttribute(myFederateObject.ta);

};class FO2C1 extends ForeignClass {

FO2C1(Federate f, FederationObject fo) {super(f, fo);

};FEC1 myFederateObject = (FEC1) super.myFederateObject;ForeignAttribute fa = new ForeignAttribute(myFederateObject.fa);ForeignAttribute ta = new ForeignAttribute(myFederateObject.ta);

};

class FEC2 extends FederateClass {FEC2(Federate f) {

super(f);};FederateAttribute fa1 = new FederateAttribute();FederateAttribute fa2 = new FederateAttribute();TransferableAttribute ta1 = new TransferableAttribute();TransferableAttribute ta2 = new TransferableAttribute();

}class FOC2 extends ForeignClass {

FOC2(Federate f, FederationObject fo) {super(f, fo);

};FEC2 myFederateObject = (FEC2) super.myFederateObject;ForeignAttribute fa2 = new ForeignAttribute(myFederateObject.fa2);TransferableAttribute ta2 = new TransferableAttribute(myFederateObject.ta2);

}

public class BF1 extends BasicFederate {...

26

}public class BF2 extends BasicFederate {

...}

}

Subclasses BF1 and BF2 of BasicFederate. Objects of FederateClass are instantiated in the construc-tor of the Federate (actually of BasicFederate). The effect is that these objects are registered in theFederateObjects list. As an example fec1 is a FederateClass object

fec1 = new FEC1(this);

Upon registration of the Federate its list of FederateClass (objects) are announced to existingFederate through the registeredInstance method. A subscribing Federate can then check the argu-ment of this method and possibly instantiate a ForeignClass (object) as a proxy object — for exampleas shown below

if (fo instanceof FEC1) fo1c1 = new FO1C1(this, fo)}).

Upon registration of the Federate the lists of FederateClass(objects) of the existing Federates aresimilarly announced to the new Federate through its registeredInstance method.

Upon removal of a Federate its list of FederateClass (objects) are announced to other Federate

through the removedInstance method. A subscribing Federate can then check the argument of thismethod and possibly remove a matching (proxy) ForeignClass (object) — for example as shownbelow by

if (fo == fo1c1.myFederateObject) {ForeignObjects.removeObject(fo1c1);

or by

ForeignObjects.new ForAllObjects() {public void Activity() {

ForeignClass foo = (ForeignClass) currentObject;if (ffo == foo.myFederateObject) {

ForeignObjects.removeObject(foo);};

};}.Do();

where the list of ForeignClass (objects) is scanned and checked to possibly be removed.

class FF extends Federation {

class FEC1 extends FederateClass { ... };class FO1C1 extends ForeignClass { ... };class FO2C1 extends ForeignClass { ... };class FEC2 extends FederateClass { ... };class FOC2 extends ForeignClass { ... };

public class BF1 extends BasicFederate {BF1 () {

fec1 = new FEC1(this);};private FEC1 fec1 ;private FO1C1 fo1c1 ;private FOC2 foc2 ;

public void takeTimeStep(double dT, double sT) {...

};public void registeredInstance(FederationObject fo) {

if (fo instanceof FEC1) fo1c1 = new FO1C1(this, fo);

27

if (fo instanceof FEC2) foc2 = new FOC2(this, fo);};public void removedInstance(FederationObject fo) {

if (fo1c1 != null)if (fo == fo1c1.myFederateObject) {

ForeignObjects.removeObject(fo1c1);fo1c1 = null;

};if (foc2 != null)

if (fo == foc2.myFederateObject) {ForeignObjects.removeObject(foc2);foc2 = null;

};};...


BF2 () {fec2 = new FEC2(this);

};private FO2C1 fo2c1 ;private FEC2 fec2 ;

public void takeTimeStep(double dT, double sT) {...

};public void registeredInstance(FederationObject fo) {

if (fo instanceof FEC1) fo2c1 = new FO2C1(this, fo);};public void removedInstance(FederationObject fo) {

final FederationObject ffo = fo;ForeignObjects.new ForAllObjects() {

public void Activity() {ForeignClass foo = (ForeignClass) currentObject;if (ffo == foo.myFederateObject) {

ForeignObjects.removeObject(foo);};

};}.Do();

};...

}}

Attribute Access. Each attribute has a Value (here in the form of type integer, but it could be areference to the general Object class). An attribute has the accessmethods GetValue and SetValue.By means of the GetValue method it is possibly to register which values have been updated and must(possibly, but dependent on the owner status for transferableAttributes) be delivered to proxy objectsin other federates.

class FederationObject extends Record {...class GetAttribute extends FederationAttribute {

private int Value;public int getValue() {

return Value;};...

};class SetAttribute extends GetAttribute {

private boolean Updated = false;public void makeUpdated() {

Updated = true;};

28

public void clearUpdated() {Updated = false;

};public void setValue(int v) {

makeUpdated();Value = v;

};};class OwnerAttribute extends SetAttribute {

public void setValue(int v) {if (isOwner()) super.setValue(v);

};protected boolean isOwner() {

boolean io = false;...return io;

};public void makeOwner() {

...};

};}

An attribute is access through the FederationObject reference, for example either by fec1.fa.setValue(7)

for a FederateAttribute, or by foc2.fa2.getValue() for a ForeignAttribute as illustrated as part of thetakeTimeStep method.

public class BF1 extends BasicFederate {BF1 () {

fec1 = new FEC1(this);};private FEC1 fec1 ;private FO1C1 fo1c1 ;private FOC2 foc2 ;

public void takeTimeStep(double dT, double sT) {fec1.fa.setValue(7);fec1.ta.setValue(7);fo1c1.fa.getValue();foc2.fa2.getValue();foc2.ta2.setValue(7);

...FederateObjects.new ForAllObjects() {

public void Activity() {...

};}.Do();...ForeignObjects.new ForAllObjects() {


};}.Do();

};public void registeredInstance(FederationObject fo) ...public void removedInstance(FederationObject fo) ...public void acquiredOwnerShip(FederationAttribute a) ...public void releasedOwnerShip(FederationAttribute a) ...


...}

29

References

[1] J. Dahmann: High Level Architecture for Simulation. Presentation, 1999.

[2] Federation Execution Planner’s Workbook. http://hla.dmso.mil, U.S. Department of Defense, DRAFT2, October 1999.

[3] E. E. Jacobsen, P. Nowack: Patterns and Frameworks: Elements of Architecture. Master’s Thesis, AalborgUniversity, 1996.

[4] E. E. Jacobsen, B. B. Kristensen, P. Nowack: Characterising Patterns in Framework Development. Pro-ceedings of International Conference on Technology of Object-Oriented Languages and Systems, 1997.

[5] Building Application Frameworks: Object Oriented Foundations of Framework Design (Mohamed E.Fayad, Douglas Schmidt, and Ralph Johnson, editors), Wiley & Sons, New York, NY, 1999.

[6] Implementing Application Frameworks: Object-oriented Frameworks at Work (Mohamed E. Fayad, Dou-glas Schmidt, and Ralph Johnson, editors), Wiley & Sons, New York, NY, 1999.

[7] Domain-Specific Application Frameworks: Framework Experience by Industry (Mohamed E. Fayad andRalph Johnson, editors), Wiley & Sons, New York, NY, 1999.

[8] R. E. Johnson, B. Foote: Designing Reusable Classes. Journal of Object-Oriented Programming, 1988.

[9] W. Opdyke: Refactoring Object-Oriented Frameworks. PhD thesis, University of Illinois at Urbana-Champaign, 1992.

[10] Taligent Whitepapers: http://www.ibm.com/java/education/oobuilding/ andhttp://www.ibm.com/java/education/ooleveraging/

[11] O. Vilmann: High-Level Architecture (HLA). Presentation at COT-Seminar, September 24, 1999.

[12] O. Vilmann: COT Project, Documentation, HLA Framework. Danish Maritime Institute, 1999.

A Illustrating Examples from Existing Framework

Two paragraphs in this appendix are used to go more into detail of the use of the existing framework.The two paragraphs are used to show the involved programming code (C++) and to show the FED andthe OMT files of the HLA standard.

The followind example is example 2 of subsection 4.4, with a federate A and a federate B.

AFederate.cpp and BFederate.ccp The federates A and B interoperate in a federation execution.Federate A subscribes two attributes of federate B (actually on two attributes of the B object).

In the present example federate A makes a getAttributeData on attribute m_b1 and m_b3. Normallythe federate would ask if the attributes where updated and then make a getAttributeData if updated.

In the methods registeredInstance and removedInstance the federate A registeres the name of thefederate B (actually one or more are possible). Federate A then gets the data and thereafter sets theupdated flag of the attributes to not updated.

Federate A updates (and thereby reflects the data to other federates if any has subscribed to it) byincreasing the value of m_a1 and thereafter setting the value through the function setAttributeData.

AFederate::AFederate(const RWCString name) : SimBase(name){AFederateInit();

}

AFederate::~AFederate()

30

{m_initialised = 0;

}

int AFederate::AFederateInit(){m_initialised = 1;m_a1 = 0;

return 0;}

int AFederate::takeTimeStep(double deltaTime,double simulationTime)

{RWCString theName;int b1, b3;unsigned int objNumb;

m_a1++;

for (objNumb = 0; objNumb<m_objectsRegistered.entries(); objNumb++) {theName = m_objectsRegistered(objNumb); // Get the instance name number objNumb

m_infoHandlePtr->getAttributeData(theName, "b1", b1);m_infoHandlePtr->getAttributeData(theName, "b3", b3);m_infoHandlePtr->unsetAttributeUpdated(theName, "b1");m_infoHandlePtr->unsetAttributeUpdated(theName, "b3");

}

m_infoHandlePtr->setAttributeData(m_myName, "a1", m_a1);

return 0;}

int AFederate::registeredInstance(RWCString theInstanceName,RWCString theObjectName)

{if (theInstanceName == m_myName) {} else {m_objectsRegistered.insert(theInstanceName);

}

return 0;}

int AFederate::removedInstance(RWCString theInstanceName,RWCString theObjectName)

{if (theInstanceName == m_myName) {} else {m_objectsRegistered.remove(theInstanceName);

}

return 0;}

int AFederate::userInit(int argc, char *argv[]){RWCString token;int i = 1;

while (i<argc) {token = argv[i++];token.toUpper();if (token == "-OBJECTNAME") {

31

m_myName = argv[i++]; // Continue to last is several}

}

return 0;}

int AFederate:: acquiredOwnerShip(RWCString theInstanceName,RWTValOrderedVector<RWCString> &theAttribNames)

{return 0;

}

int AFederate::releasedOwnerShip(RWCString theInstanceName,RWTValOrderedVector<RWCString> &theAttribNames)

{return 0;

}

The federate B does increase m_b1, m_b2 and m_b3 by one and provides the data through thesetAttributeData function. The federate B hasn’t subscribed to any attributes of other federates butthough registreres when other federates join or leave the federation execution (through the registeredInstance

and removedInstance.

BFederate::BFederate(const RWCString name) : SimBase(name){BFederateInit();

}

BFederate::~BFederate(){m_initialised = 0;

}

int BFederate::BFederateInit(){m_initialised = 1;m_b1 = 0;m_b2 = 0;

return 0;}

int BFederate::takeTimeStep(double deltaTime,double simulationTime)

{m_b1++;m_b2++;m_b3++;

m_infoHandlePtr->setAttributeData(m_myName, "b1", m_b1);m_infoHandlePtr->setAttributeData(m_myName, "b2", m_b2);m_infoHandlePtr->setAttributeData(m_myName, "b3", m_b3);

return 0;}

int BFederate::registeredInstance(RWCString theInstanceName,RWCString theObjectName)

{if (theInstanceName == m_myName) {} else {m_objectsRegistered.insert(theInstanceName);

}

32

return 0;}

int BFederate::removedInstance(RWCString theInstanceName,RWCString theObjectName)

{if (theInstanceName == m_myName) {} else {m_objectsRegistered.remove(theInstanceName);

}

return 0;}

int BFederate::userInit(int argc, char *argv[]){RWCString token;int i = 1;

while (i<argc) {token = argv[i++];token.toUpper();if (token == "-OBJECTNAME") {m_myName = argv[i++]; // Continue to last is several

}}

return 0;}

int BFederate:: acquiredOwnerShip(RWCString theInstanceName,RWTValOrderedVector<RWCString> &theAttribNames)

{return 0;

}

int BFederate::releasedOwnerShip(RWCString theInstanceName,RWTValOrderedVector<RWCString> &theAttribNames)

{return 0;

}

The OMT and the FED Formats for Class/Object. The OMT and the FED file formats are com-pared. Below an example of a Timer object with two attributes, an ID and the Time are compared.

The FED format defining the Timer class/object:

(class Timer(attribute ID reliable timestamp)(attribute Time reliable timestamp)

)

The OMT format defining the Timer class/object:

(Class (ID 2)(Name "Timer")(PSCapabilities PS)(Description "The Time basis")(Attribute (Name "ID")

(DataType "long")(Cardinality "1")(Accuracy "perfect")(AccuracyCondition "perfect")(UpdateType Periodic)(UpdateCondition "The Simulator settings")

33

(TransferAccept N)(UpdateReflect UR)(Description "Unique identifier")(DeliveryCategory "reliable")(MessageOrdering "timestamp")

)(Attribute (Name "Time")

(DataType "double")(Cardinality "1")(Accuracy "perfect")(AccuracyCondition "perfect")(UpdateType Periodic)(UpdateCondition "The Simulator settings")(TransferAccept N)(UpdateReflect UR)(Description "Time handle")(DeliveryCategory "reliable")(MessageOrdering "timestamp")

))

B JAVA Utilities.

Queue

FederateQueue FederationObjectQueue

ForAllFederates ForAllObjects

ForAllRecords

Record

Federate FederationAttributeFederationObject

Figure 15: Queue and Record

In Figure 15 we illustrate the organization of classesQueue and Record and the internal controlabstractions of Queue, FederateQueue and FederationObjectQueue.

Class Queue. We illustrate (an extract of) class Queue (of class Record elements) with the controlabstraction ForAllRecords (ForAllRecords is implemented by means of the methods of the controlabstraction RecordEnumeration):

class Record {...

}class Queue {

...class RecordEnumeration {

RecordEnumeration() { ... };public boolean hasNextRecord() ...public Record nextRecord() ...public boolean hasPrevRecord() ...public Record prevRecord() ...

};abstract class ForAllRecords extends RecordEnumeration {

34

abstract public void Activity();public void preActivity() {};public void postActivity() {};...public void Do() {

...};

};};

Class FederateQueue. Next we illustrate (an extract of) class FederateQueue as an extension of classQueue with the control abstraction ForAllFederates as an extension of the control abstraction ForAllRecords:

class FederateQueue extends Queue {...public void insertFederate(Federate f) ...public void removeFederate(Federate f) ...abstract class ForAllFederates extends ForAllRecords {

Federate currentFederate = null;public void preActivity() {

currentFederate = (Federate) current;};

};};

Next we illustrate (an extract of) class Federate including an instance of class FederateQueue, theobject RegisteredFederates, where we include additional methods for update of RegisteredFederates,namely insertFederate and removeFederate each of which has an application of ForAllFederates intheir implementation:

class Federation extends Record {...FederateQueue RegisteredFederates = new FederateQueue();

public void insertFederate(final Federate f) {...RegisteredFederates.new ForAllFederates() {


};}.Do();RegisteredFederates.insertFederate(f);

};public void removeFederate(Federate f) {

RegisteredFederates.removeFederate(f);...

};};

Class FederationObjectQueue. Finally, also as part of class Federate we illustrate (an extract of)class FederationObjectQueue as an extension of class Queue with update methods, and the controlabstraction ForAllObjects as an extension of the control abstraction ForAllRecords. Class Federate

include instances of FederationObjectQueue, namely ForeignObjects and FederateObjects:

abstract class Federate extends Record {...FederationObjectQueue ForeignObjects = new FederationObjectQueue();FederationObjectQueue FederateObjects = new FederationObjectQueue();

}

35

class FederationObjectQueue extends Queue {public void insertObject(FederationObject o) ...public void removeObject(FederationObject o) ...abstract class ForAllObjects extends ForAllRecords {

FederationObject currentObject = null;public void preActivity() {

currentObject = (FederationObject) current;};

};};

}

36

HLA and Simulation Frameworks - · PDF fileHLA and Simulation Frameworks Bent Bruun Kristensen...

Documents

Transcript of HLA and Simulation Frameworks - · PDF fileHLA and Simulation Frameworks Bent Bruun Kristensen...