You are on page 1of 54

An Application of the High Level Architecture –

Virtual Ship
Author: Anthony Cramp
Academic Supervisor: A/Prof. Peter Moylan.
Industry Supervisor: Dr. John P. Best (MOD, DSTO).

A thesis submitted in partial fulfillment of the
requirements for the degree of Bachelor of Engineering in
Computer Engineering at the University of Newcastle,
Australia.

Abstract
The Virtual Ship task is being undertaken at the Defence Science and Technology
Organisation (DSTO), Australia. The aim of this task is to simulate the operations of
a warship, with an emphasis on human-in-the-loop simulation. The Virtual Ship is
being built by integrating distributed models of warship components.
An essential component of the Virtual Ship is the representation of signal
propagation. Signals emitted from active sensors, such as radars and sonars,
propagate away from a platform to be intercepted by signal detectors or scattered
(reflected) by objects in the environment. Traditionally, the modelling of signal
propagation has been performed in the models of the sensors. This means that sensor
models need to maintain or obtain information about the environment and objects
within the environment. For example, if a detector is to determine the intensity of the
signal scattered from an object, the detector model needs to know the object’s
position, velocity, orientation and detailed scattering properties. The quantity of data
needed to specify the scattering properties may not be able to be transported over a
network in real time and the typical solution is to limit the fidelity with which the
scatterer is represented.
This project examines a concept for modelling signal propagation within a
distributed simulation. The idea is to perform the simulation of the signal
propagation in a central simulation model. Complete simulation is then achieved
through the collaboration of the sensor models and the model of the signal
propagation. This approach will allow complex scattering, emission, detection and
propagation behaviors to be encapsulated within the models that represent these
behaviours. The collaboration amongst the models will be achieved by building the
simulation using the High Level Architecture (HLA), a framework for distributed
simulation mandated by the US Department of Defence (DoD) and adopted by the
Virtual Ship.

i

Key Contributions
The following is a list of contributions I have made to this project.

Performed analysis into the use of a central propagation model in a distributed
simulation environment.

Developed a distributed simulation modelling the emission, propagation and
detection of acoustic signals. This simulation was developed using the High
Level Architecture.

Developed guidelines for the development of distributed simulations using the
High Level Architecture.

Implemented graphical user interfaces to the simulation models using the Java
Swing API.

Developed a concept for scenario control in an HLA federation.

ii

Table of Contents
PREFACE..........................................................................................................................................VII
PART I: BACKGROUND INFORMATION .................................................................................... 1
1

VIRTUAL SHIP. ........................................................................................................................ 1
1.1

2

3

INTRODUCTION ......................................................................................................................... 1

THE HIGH LEVEL ARCHITECTURE (HLA)...................................................................... 2
2.1

INTRODUCTION ......................................................................................................................... 2

2.2

THE RULES ............................................................................................................................... 5

2.3

THE OBJECT MODEL TEMPLATE (OMT)................................................................................... 6

2.4

INTERFACE SPECIFICATION ....................................................................................................... 8

2.5

DMSO RUNTIME INFRASTRUCTURE (RTI)............................................................................... 9

ACOUSTIC PROPAGATION IN THE UNDERSEA ENVIRONMENT ........................... 11
3.1

INTRODUCTION ....................................................................................................................... 11

3.2

SONAR EQUATIONS................................................................................................................. 11

PART II: SIGNAL PROPAGATION MODELLING .................................................................... 18
4

SIGNAL PROPAGATION APPLICATION DESCRIPTION............................................. 18
4.1

DESCRIPTION .......................................................................................................................... 18

4.2

EXAMPLE SCENARIO ............................................................................................................... 20

4.3

OUTCOMES ............................................................................................................................. 21

4.4

ENTITIES ................................................................................................................................. 21

4.4.1

Intrinsic Behaviours ..................................................................................................... 22

4.4.2

Static Relationships ...................................................................................................... 23

4.4.3

Interactions................................................................................................................... 23

4.5

5

6

SCENARIO EXECUTION............................................................................................................ 23

4.5.1

Tasks............................................................................................................................. 23

4.5.2

Initial Conditions.......................................................................................................... 24

4.5.3

Termination Conditions................................................................................................ 24

FEDERATION DESCRIPTION ............................................................................................. 25
5.1

INTRODUCTION ....................................................................................................................... 25

5.2

FEDERATION EXECUTION ....................................................................................................... 25

FEDERATE DESCRIPTIONS................................................................................................ 30

iii

7

6.1

INTRODUCTION ....................................................................................................................... 30

6.2

SIMULATIONCONTROLLER FEDERATE .................................................................................... 30

6.3

PROPAGATION FEDERATE ....................................................................................................... 31

6.4

ACTIVE SONAR FEDERATE...................................................................................................... 31

6.5

PASSIVE SONAR FEDERATE .................................................................................................... 32

6.6

NOISE SOURCE FEDERATE ...................................................................................................... 33

6.7

SCATTERER FEDERATE ........................................................................................................... 33

6.8

C2 FEDERATE ......................................................................................................................... 34

IMPLEMENTATION DETAILS............................................................................................ 34
7.1

INTRODUCTION ....................................................................................................................... 34

7.2

FEDERATE IMPLEMENTATION ................................................................................................. 35

7.3

JAVA DISPLAYS ...................................................................................................................... 40

8

CONCLUSIONS ....................................................................................................................... 41

9

LIST OF REFERENCES......................................................................................................... 43

APPENDIX ......................................................................................................................................... 44

iv

.. ........................ VII FIGURE 2 APPROACH TO SIGNAL PROPAGATION TAKEN IN THIS REPORT.....................List of Figures FIGURE 1 TRADITIONAL APPROACH TO SIGNAL PROPAGATION MODELLING......................................................................................................... 9 FIGURE 5 FEDERATE-FEDERATION INTERPLAY ...... 12 FIGURE 7 REVERBERATION LEVEL DIMINISHES WITH RANGE......................................................................... 3 FIGURE 4 DMSO RTI DISTRIBUTION COMPONENTS .................................................................................... 19 FIGURE 10 SIGNAL PROPAGATION FEDERATION DIAGRAM .......................................................................................................... VIII FIGURE 3 FEDERATES COMMUNICATE VIA THE RTI ....... 37 v ............................. 15 FIGURE 8 DIAGRAM ILLUSTRATING THE PASSIVE SONAR EQUATION PARAMETERS ............................................................... 17 FIGURE 9 SIMPLE BEAM PATTERN OF AN ACTIVE SONAR ...... 26 FIGURE 11 CLASS DIAGRAM FOR GENERALFEDERATE ......................................................................................................................... 10 FIGURE 6 DIAGRAM OF THE ACTIVE SONAR EQUATION PARAMETERS ....................................

.................List of Tables TABLE 1 INTRINSIC BEHAVIOURS OF ENTITIES IN THE SIGNAL PROPAGATION APPLICATION ....... 23 vi ......... 22 TABLE 2 INTERACTIONS BETWEEN ENTITIES IN THE SIGNAL PROPAGATION APPLICATION ...

signal propagation is modelled in the sensor models.Preface Traditionally. propagation. a dedicated simulation model is used to model the signal propagation. scattering and detection is modelled. The previous example is then solved by the emitter radiating a signal into the signal propagation model. for a detector to model the signal scattered from a target. This project looks at implementing a new approach to modelling signal propagation within a distributed simulation. Instead of the sensors modelling the signal propagation. the amount of data that needs to be transferred across the network becomes prohibitive. The signal propagation model then simulates the signal propagation on towards targets and detectors. This approach to signal propagation modelling means that sensor models need to maintain or obtain information about the environment and objects within the environment. Emitter Signal Propagation Model Detector Signal Propagation Model Detector Emitter Emitter Figure 1 Traditional Approach to Signal Propagation Modelling. When this approach is applied to distributed applications. vii . This approach is shown in Figure 1. For example. The approach taken is illustrated in Figure 2. and passes information about the received signal to them. the detector model must know the scattering properties of the target as well as the positions of the source of the signal and the target so as to determine the direction of signal incidence upon the target. Generally the solution to this has been to limit the fidelity with which the signal emission.

a task undertaken at the Defence Science and Technology Organisation. The format for this report is as follows.Emitter Emitter Detector Signal Propagation Model Emitter Detector Scatterer Figure 2 Approach to Signal Propagation taken in this report. Australia. scattering and detection behaviours to be encapsulated within the simulation models representing these behaviours. and hence. This project concentrates on the undersea environment. Part I presents some background information on which this project is dependant. The propagation is once again modelled and passed on to detectors (and possibly other scatterers). Section 2 discusses the High Level Architecture (HLA). acoustic signal propagation. The targets themselves calculate their scattered signal and radiate this back into the signal propagation model. One of the conclusions from this report will be whether or not the approach adopted would be extensible to electromagnetic signal propagation. Section 1 discusses the Virtual Ship. This project was performed in support of this task. This approach allows for complex emission. a framework for distributed simulation mandated by the US Department of Defence (DoD) and adopted by the viii .

ix .Virtual Ship. This includes the development of a standard base class for the construction of HLA compliant simulation models. The approach to signal propagation modelling discussed in this document was implemented using the HLA. the development of a federate side event queue and the development of Java graphical user interfaces (GUIs). An Application Description is an analysis tool for the development of federation executions. Section 6 discusses the individual simulation models that take part in the Signal Propagation Federation. The federation is represented diagrammatically and the process of signal propagation within the federation execution is discussed. Passive Sonar. and Propagation. Scatterer. Part II presents the technical information of the report. Section 7 discusses some details of the implementation of the Signal Propagation Federation. The simulation models are Active Sonar. Section 8 presents some lessons learned from this project and discusses extensions and recommendations for the further development of the central signal propagation model. This provides a basis for the section discussing the implementation details of the signal propagation model. These models are identified as the major participants in the Signal Propagation Federation. Section 4 introduces an Application Description of the Signal Propagation Federation. Section 5 discusses the Signal Propagation Federation. Noise Source. Section 3 discusses the fundamentals of acoustic signal propagation. The Appendices provide documentation that is used as reference material throughout this report. C2. Simulation Controller.

sonar. motion. The sensor searches the environment for radio wave emissions. this will allow tendered systems to be integrated and evaluated in virtual form before acquisition. weapon systems (missiles.1 Introduction The aim of Virtual Ship [1] is to simulate a surface warship. some of which are listed below. The core of the HLA is the definition of a standard for the exchange of data amongst simulations. a physical platform and facilities to control other aspects of the warship (command and control. The existence of a data exchange standard enables models to be brought together in a “plug and play” fashion.PART I: Background Information 1 Virtual Ship. a warship is the sum of its components. • The operational utility of warship systems can be demonstrated and refined. etc). 1 . This decomposition naturally lends itself to the distributed simulation paradigm. The Virtual Ship will be used for many applications. • The Virtual Ship will allow for the development of tactics and operational concepts. ESM1. Virtual Ship will simulate a warship by simulating and interoperating a warship’s components. • Issues relating to integration of warship systems can be explored. Conceptually. The essential components of the Virtual Ship will be system models. the High Level Architecture (HLA). A warship has sensors (radar. In combination with the previous point. The federated architecture of the Virtual Ship will be based upon the US standard for distributed simulation. etc). and a federated architecture within which these models are brought together. An ESM sensor is essentially a passive radar. helm. 1. The basis of the Virtual Ship upon the HLA 1 ESM is Electronic Support Measures. the data that characterise the models. guns. etc).

and as prescribed by the DoD Modelling and Simulation Master Plan. To enforce this mandate. all simulations developed by.will provide natural interoperability with virtual air and land environments also developed with the HLA. This objective requires the establishment of a common high-level simulation architecture to facilitate the interoperability of all types of models and simulations among themselves and with C4I 2 systems. or for.1). Acquisition and Technology. 2 The High Level Architecture (HLA). 2 . as well as to facilitate reuse of M&S components. Communications. • “No Can Play” – first day of FY01: All non-HLA-compliant simulations will be retired after this date.” – Dr. Computers and Intelligence. • “No Can Pay” – first day of FY99: No funds will be allocated for developing/modifying non-HLA-compliant simulations after this date.1 Introduction “Under the authority of DoD Directive 5000. I designate the High Level Architecture as the standard technical architecture for all DoD simulations. NATO has also adopted the HLA as a standard framework for developing simulations [2].09. The HLA fulfils objective 1-1 of the US DoD Modelling and Simulation (M&S) Master Plan [3]. Paul Kaminski. the following “No Can” Dates have been set. The Virtual Ship should also be interoperable with simulations developed by the NATO countries (see §2. the US DoD will utilise the High Level Architecture. Under Secretary of Defence. 10 September 1996. With this statement. Control. 2 C4I is Command. 2.

L iv e P a r tic ip a n ts S im u la tio n s S u p p o rt U tilitie s (D a ta L o g g e rs . The RTI is a software implementation of the services specified in the HLA Interface Specification. An HLA federation is a named set of interacting federates. that are used as a whole to achieve some specific objective. The above concepts are illustrated in Figure 3. In order to distribute knowledge of the HLA. DMSO has set up an HLA web site at http://hla.dmso. An HLA federate is a member of a federation. or RTI. Each federate can be such applications as.The HLA is being defined by the Defence Modelling and Simulation Office (DMSO). a common Federation Object Model (FOM) and supporting runtime infrastructure (RTI). • Simulations • Data Loggers • Passive (Stealth) Viewers • Live Entity Surrogates Federates communicate with each other via services provided by the runtime infrastructure.mil. S te a lth V ie w e rs . e tc ) L iv e E n tity S u rro g a te s R u n T Im e In fra s tru c tu re Figure 3 Federates Communicate via the RTI 3 .

4 . The three standards comprise the three formal components of the HLA. In May 97. Three IEEE 1516 standards are expected by the end of 1999. The RTI delivers time stamped ordered data to federates when the federates local time reaches the time stamp of the data. • Both Time Regulating and Time Constrained. • Time regulating: A federate that is time regulating is capable of sending data with time stamps. an HLA standards nomination was submitted by DMSO to the SISO3 Standards Activity Committee for IEEE standardisation. Receive ordered data are sent regardless of a federates local time. • Neither Time Regulating nor Time Constrained: Federates with this policy run as fast as they want.1) SISO is the Simulation Interoperability Standards Organisation.The data exchanged during federation execution are grouped into classes. Object classes are defined by their attributes. Interaction classes convey information through the interaction class name and parameters. The RTI manages the time advancement of the federates participating in a federation. Object classes represent data that have some persistent state in a federation execution. These are: • 3 The HLA Rules (HLA Rules IEEE 1516. The data passed around the federation can be sent in time-stamped order or receive order. The RTI manages federate time advances by ensuring no time regulating federate will send data with a time stamp that would be in a time constrained federate’s past. • Time Constrained: A time constrained federate is capable of receiving time stamped data. The HLA defines four types of time management policy. Interaction classes are used to represent transient events during a federation execution.

In a federation. There are ten rules. an instance attribute shall be owned by at most one federate at a given time. 5.• The HLA Interface Specification (I/F Spec IEEE 1516. 2. 4. federates shall interact with the RTI in accordance with the HLA interface specification. 7. 3.2 The Rules The HLA Rules [4] define standards to which every federate and federation must adhere. Federations shall have an HLA federation object model (FOM). The rules for federates are: 6. all simulation-associated object instance representation shall be in the federate. documented in accordance with the HLA OMT. not in the runtime infrastructure (RTI). Adherence to these rules facilitates interoperability amongst models developed using the HLA. 5 . During a federation execution. The rules for federations are: 1. 8.2) • The Object Model Template (OMT IEEE 1516. five pertaining to federations and five pertaining to federates. 2. as specified in their SOMs.3) These three components are discussed in more detail in the following sections. documented in accordance with the Object Model Template (OMT). Federates shall be able to update and/or reflect any attributes and send and/or receive interactions. Federates shall have a Simulation Object Model (SOM). as specified in their SOMs. During a federation execution. During a federation execution. all exchange of FOM data among federates shall occur via the RTI. Federates shall be able to transfer and/or accept ownership of attributes dynamically during a federation execution.

A federation object model (FOM) is used to describe a named set of interacting federates. their attributes. HLA object models are composed of a group of interrelated components specifying information about classes of objects. The content of this data includes an enumeration of all object and interaction classes pertinent to the federation. interactions. The standard format in which SOMs are expressed facilitates determination of the suitability of simulation systems for participation in a federation.3 The Object Model Template (OMT) The HLA Object Model Template [5] prescribes the format and syntax for recording the information in HLA object models. attributes.9. and parameters. The primary purpose of an HLA FOM is to provide a specification for data exchange among federates in a common and standardised format. The HLA requires that federations and individual federates be described by an object model which identifies the data exchanged at runtime in order to achieve federation objectives.g. Federates shall be able to manage local time in a way that will allow them to coordinate data exchange with other members of a federation. or federation. but it does not define the specific data that will appear in the object models. The HLA OMT provides a template for documenting HLA-relevant information about classes of simulation or federation objects and their attributes and interactions. An HLA SOM is a specification of the intrinsic capabilities that an individual simulation could provide to HLA federations. The 6 . as specified in their SOMs. 10. Federates shall be able to vary the conditions (e. An object model used to describe an individual federate is termed a Simulation Object Model (SOM). to include objects. 2. thresholds) under which they provide updates of attributes. and their interactions. along with a specification of the attributes or parameters that characterise these classes.

This software allows the tables in the OMT to be filled out via a graphical user interface.com 5 http://www. To assist in the creation of HLA object models. 4 http://www. A free version of the OMDT can be downloaded from the HLA software distribution center5. as required at runtime by the RTI. and also in the native OMT data interchange format.template for the core of an object model uses a tabular format and consists of the following components.htm 7 . AEgis Research Corporation4 have developed the Object Model Development Tool (OMDT). • FOM/SOM lexicon: to define all of the terms used in the tables. • Parameter table: to specify features of interaction parameters in a simulation/federation. • Object model identification table: to associate important identifying information with the HLA object model.dmso. • Routing space table: to specify routing spaces for object attributes and interactions in a federation.mil/RTISUP/hla_soft/hla_soft. • Interaction class structure table: to record the namespace of all simulation/federation interaction classes and to describe their class-subclass relationships. The OMDT allows for the object model data to be saved as federation execution data. • Object class structure table: to record the namespace of all simulation/federation object classes and to define their class-subclass relationships. • Attribute table: to specify features of object attributes in a simulation/federation.aegisrc.

and supporting control functions. Object management also includes methods associated with sending and receiving interactions and controlling instance updates based on consumer demand. and destroying federations. These interfaces are arranged into six basic RTI service groups: • Federation Management: Federation management includes such tasks as creating federations. each of the participating federates has responsibility for a mutually exclusive set of object attributes. effecting federation-wide saves and restores. The HLA Interface Specification [6] defines the standard services and interfaces to be used by the federates in order to support efficient information exchange when participating in a distributed simulation and reuse of the individual federates. The runtime infrastructure provides services to federates in a manner that is analogous to how a distributed operating system provides services to applications. • Object Management: Object management includes instance registration and instance updates on the object production side and instance discovery and reflection on the object consumer side. • Time Management: The focus of time management is on the mechanics required to implement time management policies and negotiate time advances. subscription. 8 .2. • Ownership Management: Ownership management groups services relating to the sharing of responsibility for the updating of object instances amongst many federates. resigning federates from federations. joining federates to federations.4 Interface Specification The HLA requires a language independent specification and multiple language bindings to support inter-simulation communication in a distributed simulation domain. observing federation-wide synchronization points. When update responsibility for an object is shared. • Declaration Management: Declaration management includes publication.

The current version of the RTI implements version 1. 2. The RtiExec is a global process. The DMSO RTI distribution can be downloaded from the HLA Software Distribution Center.5 DMSO Runtime Infrastructure (RTI) To support the shift towards the use of the HLA. These six service groups describe the interface between the federates and the RTI. and the software services provided by the RTI for use by HLA federates.. Federate communications with the RtiExec are directed to the appropriate FedExec. DMSO has released an implementation of the RTI services.. Federate(s) libRTI Inter-Process Communications RTI Provided Federate Provided Figure 4 DMSO RTI distribution components 9 . The DMSO RTI distribution is comprised of the RTI Executive process (RtiExec). The RtiExec’s primary purpose is to manage the creation and destruction of FedExec processes. the Federation Executive process (FedExec) and the libRTI library.3 of the interface specification.• Data Distribution Management: Data Distribution Management (DDM) provides a flexible and extensive mechanism for further isolating publication and subscription interests – effectively expanding the sophistication of the RTIs switching capabilities. Federate(s) RtiExec FedExec libRTI . The use of the DMSO RTI distribution is illustrated in Figure 4.

a FedExec. An instance of this federate supplied class is required to join a federation execution. Figure 5 illustrates the interplay between a federate and a federation. The abstract class FederateAmbassador identifies the callback functions each federate is obliged to provide. and other federates to invoke HLA services. the class RTIambassador bundles the services provided by the RTI. A federate must implement the functionality declared in FederateAmbassador. Within libRTI. The libRTI provides the services specified in the HLA Interface Specification to federate developers. A FedExec allows federates to join and resign. Federates use libRTI which communicates with the RtiExec.Each FedExec manages a federation. and facilitates data exchange between participating federates. Federate Federation Create federation join publish object attributes and interactions create and register objects Subscribe and discover reflect object attributes and receive interactions exchange attribute ownership delete/remove object begin shutdown resign remove federate Figure 5 Federate-Federation Interplay 10 .

The passive sonar equation involves one way propagation only. Neither radio wave nor optical propagation is effective for this purpose.3 Acoustic Propagation in the Undersea Environment 3. An active sonar emits an acoustic signal at a source level. In acoustics.1 Introduction Sound transmission is the single most effective means of directing energy transfer over long distances in seawater. 3. This fact is conveyed by stating a signal level as SL dB re 1µPa. as the former. and the standard range is 1m. acoustic signals are measured in the far field and scaled back to the standard range of 1m. The source level is given by SL = 10 log 10 (intensity of source / reference intensity). 6 In practice. An acoustic signal is radiated into the environment and propagates to a receiver. The reference wave is a plane wave of rms pressure 1µPa. signal levels are measured6 in decibels with respect to a reference wave at a standard range from the acoustic centre of a sensor. Two sets of equations are used to define underwater acoustic propagation. This is done so as the measurement is not corrupted be near field effects such as resonance. This is the basic echo location concept. attenuates rapidly in the conducting salt water and the later is subject to scattering by suspended material in the sea [7]. 11 . This signal then propagates to a target where it is reflected back to the source. The active sonar equation involves a source emitting an acoustic signal. SL. at all but the lowest useable frequencies. The variables used in this section come from those defined by Urick [8] and used in most texts on underwater acoustics since.2 Sonar Equations The basic active sonar situation is illustrated in Figure 6.

TS. Source Level. RL. 2TL Self-Noise Level. Target Reverberation Level. at 1m. Two way transmission loss. NL Target Strength. NL. Sea Floor Figure 6 Diagram of the Active Sonar Equation Parameters 12 . at 1m from acoustic centre. SL.Sea surface Noise Level.

If the emitter radiates with power P omnidirectionally. Spherical spreading occurs in environments where no acoustic channelling can occur. This is usually the case in deep-water environments. the emitter is surrounded by a spherical envelope of surface area 4πr2 = 12. this gives a source level of SL = 10 log 10 P + 167 dB. Transmission loss refers to the reduction in signal intensity over distance. With a reference intensity of 1µPa. the intensity of the source is Intensity of source = Power / Area = P / 12. spherical spreading and cylindrical spreading. There are two main causes of transmission loss. Absorption occurs through viscous friction at high frequencies and molecular resonance at lower frequencies. Spherical spreading results in a reduction in signal level proportional to the inverse square of range TL = 20 log 10 R. The other cause of transmission loss is absorption. Taking spreading and absorption together gives the following equation for transmission loss: TL = k log 10 R + α R 13 . This signal propagates to a target incurring a transmission loss. Cylindrical spreading results in a reduction in signal level proportional to the inverse of range TL = 10 log 10 R.6m2. TL. Cylindrical spreading occurs when channelling of acoustic energy occurs.At a standard range of 1m.6 Pa. The sea surface and sea floor are good channellers of acoustic energy and hence cylindrical spreading occurs most often in relatively shallow water. The effect of spreading generally ranges between two extremes. Spreading refers to the broadening of the emitted acoustic wave with distance. spreading and absorption.

Measurements taken in the near field are subject to corruption from the resonance of the target and the standing waves set up by the interactions of the incident and reflected waves. etc. being picked up by the receiver. wake. Reverberation refers to the echoes received from the incident signal reflecting off the sea surface. biologics. The signal received by the active sonar will be masked to some extent by an ambient noise level. This results in a range where the reverberation level will drop below the ambient noise level. The signal reflected from the target changes in intensity by the target strength. Target strength is measured in the far field and scaled back to 1m taking into account transmission losses. NL. The reverberation level is therefore affected by range and transmission losses. bow wave. The reflected signal propagates back to the active sonar. and a reverberation level.where the value of k depends upon whether the wave experiences spherical spreading. etc. RL. k = 20. Such sources of noise include machinery. k = 10. or cylindrical spreading. flow noise over the sonar array. This is illustrated in Figure 7. Another source of noise is self-noise. Noise level is ambient with no fixed source and will appear to be approximately constant at all positions. 14 . one reverberation limited the other noise limited. is the decibel intensity returned from a target relative to the incident intensity. This is the noise radiated from the platform on which the receiver resides. Target strength. This dominance of reverberation level over noise level (and vice versa) results in two forms of the active sonar equations. incurring another reduction in signal level due to transmission loss. TS. The signal level received by the active sonar is given by SL – 2TL + TS. shipping. either noise or reverberation will be dominant. rain. and α=is the absorption loss coefficient. Ambient noise comes in many forms including waves. sea floor and the sea volume. In general.

For a beam pattern subtending φ steradians of solid angle. The reverberation limited active sonar equation is given by SNR = SL – 2TL + TS . so its reception is subject to the normal operation of the sonar's receiver. The previous discussion results in the active sonar equations. The detector.RL. where DI is the directivity index of the detector. The directivity index can be derived from the beam pattern of the detector. the directivity index is given by DI = 10 log 10 (4π/φ).Signal Level Reverberation Level. NL active sonar equations reverberation limited Range Figure 7 Reverberation Level diminishes with range Ambient noise impinges on a detector omnidirectionally. 15 . These equations provide expressions for the signal-to-noise ratio (SNR) received by the detector. The reverberation level is directional. will only receive the noise from a certain direction. RL active sonar equatoins noise limited Noise Level. however. The noise limited active sonar equation is given by SNR = SL – 2TL + TS – (NL – DI). The actual noise received by the detector is NL – DI.

In this case a signal of source level SL is radiated from a target and undergoes degradation in intensity due to transmission loss while propagating to a detector. 16 . This results in the passive sonar equation as SNR = SL – TL – (NL – DI).The passive sonar case is shown in Figure 8. The detector receives the radiated signal and an ambient noise level modified by the receiver’s directivity index.

Sea surface Noise Level. Target Sea Floor Figure 8 Diagram illustrating the passive sonar equation parameters 17 . SL. NL Target source level. Transmission loss. NL. TL Self-Noise Level.

dmso. The numbering scheme of the following application description has been modified so as to fit into the format of this project report. an active sonar will have a beam pattern that consists of a main lobe centered on the sonar’s axis. An Application Description gives an entity level analysis of the federation as well as a scenario for federation execution. the acoustic signal radiated is modified in certain directions due to the emitters beam pattern. Rather. The Virtual Ship Architecture Working Group (VSAWG) has extended this concept into Application Descriptions. the beam pattern may have a number of sidelobes separated by nulls. A simplistic beam pattern is shown in Figure 9. It is possible to modify the shape of the beam pattern dynamically so as to cancel out noise coming from a certain direction. This section provides an application description for the Signal Propagation Federation. Generally.PART II: Signal Propagation Modelling 4 Signal Propagation Application Description The Federation Execution Development Process (FEDEP)7 is a process used in the construction of federations. This template can be found in Appendix I. The format used follows the layout defined in the VSAWG Application Description Template. 4. Active sonars and other acoustic noise sources generally do not radiate acoustic energy omnidirectionally.1 Description All facets of acoustic signal propagation in the undersea environment have inherent complexities. In addition. Passive sonars can also have receiver beam patterns.mil/hla/federation/ 18 . 7 http://hla. This concept is referred to as adaptive beam forming. Part of the FEDEP is to define scenarios for federation execution.

19 . This results from the cross section of the cylinder being larger when incident broadside. speed of sound varies with temperature. The direction and strength of the reflected signal will depend on the direction of the incident signal with respect to the orientation of the cylinder. suppose an acoustic signal is incident on a hollow cylinder. pressure and salinity. A consequence of this variation in the speed of sound is that acoustic rays curve through the sea rather than propagating in a straight line (Snell’s Law). Modelling all these complexities at high fidelity within a single simulation requires heavy computational resources. The propagation of signals through the subsurface environment also encounters many complexities.Acoustic axis Main lobe Side lobe Acoustic centre Figure 9 Simple beam pattern of an active sonar The scattering properties of acoustic reflectors are anything but simple. Most of the complexities stem from the fact that the speed of sound varies with depth8. In addition to cross sectional changes. A signal will be reflected with higher intensity if the signal is incident broadside to the cylinder rather than end on. These parameters vary with depth. Distributing the simulation offers the opportunity to 8 Actually. the incident signal may set the scatterer into resonance resulting in reflected signals at different frequencies and strengths. As an example.

machinery noise or a 9 C2 is command and control. The active sonar emits an acoustic signal into the propagating medium. while several remote passive sensors listen for returns from the transmitted signal. A second scenario. A multistatic system is one that involves a source of acoustic energy emitting into the environment. This signal propagates through the medium to impinge on the passive sonar and target. 4. A noise source (for example.simulate all the models at high fidelity without incurring high computational requirements. The passive sonar records the signal level received. This scenario will be called the Active Multistatic Scenario. will replace the active sonar with a second passive sonar. noise sources and propagation. The problem of how to interact the various simulation models must then be examined. one passive sonar located remotely from the active sonar. 20 . more complex models can be implemented at a later date. passive sonars. Initially low fidelity models will be implemented to allow the framework to be developed and tested. Once the framework is in place. called the Passive Multistatic Scenario. The scenario will consist of an active sonar. This application intends to set up a framework for the collaboration of models for active sonars. and an acoustic scatterer acting as a target for detection. The target models the reflected signal based in the direction of the incident signal. The reflected signal propagates back through the medium and is received by the active sonar and passive sonar.2 Example Scenario A multistatic system will be implemented as a scenario for this application. A C2 system9 will display the signals received by the active and passive sonar. acoustic scatterers. This framework will consist of the concept for signal propagation and the interface to the RTI to achieve this concept.

10 SUS is Signal Underwater Sound. noise sources. 4. The acoustic signal radiated by the noise source will also be scattered by the target. The passive sonars will also pick up this scattered signal.SUS charge10) will then be introduced. passive sonars. 21 . acoustic detectors and acoustic propagation. scatterers. The acoustic signal radiated from the noise source will propagate through the medium to be received by the passive sonars. 4. C2 systems and a global propagation entity. The signal received by the passive sonars will be displayed on a C2 system.3 Outcomes The primary outcome of this application will be the establishment of a framework for the collaboration of simulation models for acoustic emitters.4 Entities The major entities will be active sonars.

entity. Propagation Low scatterers). passive scatterers). sonars.4. An signal to the acoustic signal and acoustic signal from Propagation entity. sonars. scatterers. Passive Sonar A passive sonar listens Control information 2 for acoustic signals from a C entity. The Propagation entity Acoustic signals from Acoustic signals to is a global entity used acoustic emitters the acoustic to model signal (active sonars. A C2 entity allows Acoustic signal data Commands to the commands to be sent to from the active and active and passive sonars. and sonar data passive sonars. then listening for the Propagation Acoustic signal data reflections off entity. Table 1 Intrinsic behaviours of entities in the Signal Propagation Application 22 . acoustic signal from Acoustic signal data Low 2 to a C entity. the Propagation entity. sources. An only. noise detectors (active propagation.4. to a C2 entity. and sonars. and Low Low Low to be displayed. entity A scatterer is an Acoustic signals from Acoustic signals to acoustic signal the Propagation the Propagation reflector.1 Intrinsic Behaviours Entity Active Sonar Behaviour An active sonar Inputs Control information 2 Outputs Fidelity A radiated acoustic Low operates by emitting an from a C entity. entity. Noise Source Scatterer C2 A noise source is a Acoustic signals to continuous radiator of the Propagation acoustic noise.

acoustic emitter refers to the entities active sonar.4. There also exists a static relationship between acoustic emitters.5 Scenario Execution 4. acoustic detectors and the propagation entity. 4. In the table.3 Interactions The following table identifies some specific collaboration instances between the entities.1 Tasks For the Active Multistatic Scenario: • Create active sonar • Create passive sonar • Create scatterer • Create C2 • The active sonar emits an acoustic signal 23 . and acoustic detector refers to the entities active sonar. Initiating Entity Interaction Receiving Entity Acoustic Emitter Radiates acoustic signal Propagation Propagation Propagates acoustic signal Acoustic Detector C2 Controls Active and Passive Sonars Active and Passive Sonars Communicate received C2 acoustic signals Table 2 Interactions between entities in the Signal Propagation Application 4. scatterer and noise source.5.4.2 Static Relationships There exist static relationships between C2 entities and the sonar entities it controls. passive sonar and scatterer.4.

4. 24 .5. A human administrator creates all entities dynamically during scenario execution.2 Initial Conditions There are no initial conditions for the scenarios.• The propagation entity propagates the acoustic signal • The scatterer reflects the acoustic signal • The propagation entity propagates the reflected signal • The passive sonar receives both the emitted signal and the reflected signal • The active sonar receives the reflected signal • The C2 displays the signals received by the active and passive sonars For the Passive Multistatic Scenario • Create passive sonar • Create passive sonar • Create noise source • Create scatterer • Create C2 • The noise source radiates an acoustic signal • The propagation entity propagates the acoustic signal • The scatterer reflects the acoustic signal • The passive sonars detect the radiated and reflected signals • The C2 displays the signals received by both passive sonars 4.5.3 Termination Conditions Termination of the scenarios is performed manually be a human administrator.

These standards are presented in Appendix J. Interaction Classes. 5. This information includes tables of lexicons for each of the Object Classes. 25 .1 Introduction This chapter discusses the federation developed in solution of the problem at hand. Interaction Classes and Parameters. and Parameters that exist in the Signal Propagation Federation.2 Federation Execution Figure 10 illustrates the Signal Propagation federation. Attributes. The SigPropFOM provides information regarding the Object Classes. Appendix A gives the Signal Propagation Federation Object Model (SigPropFOM).5 Federation Description 5. Attributes. The diagramming standards used follow those defined by the Virtual Ship Architecture Working Group (VSAWG).

Control S ta tu s Simulation Controller C2 C o n tro l Active Sonar Passive Sonar Request Directions Status Noise Source Propagation Provide Directions Outgoing Signals Scatterer Incoming Signals Status Figure 10 Signal Propagation Federation Diagram 26 .

C2 entities are instances of the C2 Object Class (see Appendix A. The propagation federate maintains lists of all acoustic emitters and acoustic detectors that exist within the federation. passive sonar. These federates collaborate with each other in order to fulfil the goal of modelling signal propagation.1).From the federation diagram it can be seen that the federation consists of seven interoperating federates. scatterer and noise source object instances and the Propagation federate. Each of the federates are described in more detail in section 6.1). Active sonar entities are instances of the Active Sonar Object Class (see Appendix A.1). • Propagation: The modelling of acoustic signal propagation occurs in this federate.1). • Scatterer: The Scatterer federate manages the scatterer entities participating in the environment. • PassiveSonar: The PassiveSonar federate manages the passive sonar entities participating in the environment. • ActiveSonar: The ActiveSonar federate manages the active sonar entities participating in the environment. The federation achieves the modelling of signal propagation through the interaction of active sonar. Scatterer entities are instances of the Scatterer Object Class (see Appendix A. 27 . • C2: The C2 federate manages the C2 entities participating in the environment. The federates are: • SimulationController: This federate provides a human operator with an interface to the entities existing within the federation. Passive sonar entities are instances of the Passive Sonar Object Class (see Appendix A. Noise Source entities are instances of the Noise Source Object Class (see Appendix A. • NoiseSource: The NoiseSource federate manages the noise source entities participating in the environment.1).

The major simulation component of the federation execution is in the interplay of the ActiveSonar. Each federate receiving the interaction uses the acoustic emitter name passed as a parameter to identify whether it is the correct destination of the interaction. NoiseSource. The direction array is an array of vectors from the acoustic emitter to all acoustic detectors. Once the signal array is 28 . The destination array is an array of acoustic detector identifiers. The arrays are constructed so that the direction stored in location j of the direction array is the direction from the acoustic emitter to the acoustic detector identified by location j of the destination array. Scatterer. The process of an acoustic signal being radiated. The Propagation federate then sends the ProvideDirections interaction with parameters being the name of the acoustic emitter. propagating to a detector and being received by the detector proceeds as follows: 1. RequestDirections. 3. The Propagation federate receives the RequestDirections interaction. and Propagation federates. 2. OutgoingSignals and IncomingSignal simulate the propagation of signals from emitters to detectors. The four interactions. NoiseSource and Scatterer federates) receive the ProvideDirections interaction. Using this approach allows the beam pattern of the acoustic emitter (scattering properties in the case where the emitter is a scatterer entity) to be taken into account. Each direction is a Vector3D complex datatype (see Appendix A.5). The federate responsible for managing the acoustic emitter sends a RequestDirections interaction to the Propagation federate. All federates managing acoustic emitter entities (the ActiveSonar. The Propagation federate then constructs a direction array and a destination array. The Propagation federate searches through its acoustic emitter list for the name passed as a parameter to the RequestDirections interaction. If so. the direction array and the destination array. This provides the position of the acoustic emitter. the federate uses the direction array and destination array parameters to construct an array of Signal complex datatypes (see Appendix A.5). The name of the acoustic emitter is passed as a parameter. PassiveSonar. ProvideDirections.

This interaction is sent with a timestamp that reflects the time delay from emission to detection. If so. 29 . PassiveSonar and Scatterer federates). The strength of the signal is decreased by the transmission loss and then sent as the parameter in the IncomingSignal interaction. The signal array passed as a parameter is decomposed and each signal undergoes signal propagation. The Propagation federate receives the OutgoingSignals interaction. a destination identifier (these identifiers are character strings). Once the OutgoingSignals interaction has been sent. Once found. the signal can be considered to have been emitted. the process returns to step 1 so as to model the reflection of the acoustic signal. The IncomingSignal interaction is received by all federates managing acoustic detector entities (the ActiveSonar. the response to the interaction depends on the federate. Each federate receiving this interaction uses the destination identifier extracted from the signal passed as a parameter to determine if this federate is the correct destination of the interaction. The propagation federate uses the source and destination identifiers to search through its acoustic emitter and acoustic detector lists for the positions of the emitter and detector.constructed. If the destination is the ActiveSonar or PassiveSonar federates. 4. it is passed as a parameter in the OutgoingSignals interaction. the distance between the emitter and detector is determined. The SimulationController federate requests time advances after a certain period of real time has elapsed. If the destination is the Scatterer federate. Each time advance is fixed at an increment of one second. Each Signal datatype consists of a source identifier. Each signal in the signal array is a complex datatype Signal. All other federates will advance their local time conditional on the SimulationController advancing its local time. an incident direction and signal parameters strength and frequency. 5. allowing the transmission loss and time delay to be calculated. The federation employs a scaled real time approach to time management. the federate updates the correct entities received signal.

2 SimulationController Federate The SimulationController federate provides an interface through which a human operator can control the federation. NoiseSource. Scatterer and C2 object classes. The federates involved in the Signal Propagation Federation are: • SimulationController • Propagation • ActiveSonar • PassiveSonar • NoiseSource • Scatterer • C2 6. The Physical_Entity object class is the super class of the ActiveSonar. 30 . Control in this case refers to the dynamic creation and deletion of object instances. PassiveSonar. By subscribing at the Physical_Entity level the SimulationController federate is notified of all object instances created that are subclasses of Physical_Entity.6 Federate Descriptions 6. The SimulationController federate maintains information about object instances in existence by subscribing to the Physical_Entity object class. The SimulationController is an event driven federate in that all functionality for interacting with the federation derives from human input.1 Introduction This chapter provides a description of the individual federates. The simulation loop is therefore relatively sparse with most functionality being in the FederateAmbassador callbacks.

6. By subscribing to this class. NoiseSource and Scatterer federates through the interactions RequestDirections. The Propagation federate models signal propagation by collaborating with the ActiveSonar. DeleteActiveSonar). the Propagation federate will discover all acoustic emitters and acoustic detectors created in the federation. The federate obtains this knowledge by subscribing to the Emitter_Detector object class. PassiveSonar. The Propagation federate is an event driven federate in that its functionality comes from reacting to the interactions sent by the acoustic emitter federates.3 Propagation Federate The Propagation federate performs the signal propagation modelling. The Propagation federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix G. ProvideDirections. the federate needs to know the positions of all acoustic emitters and acoustic detectors.4 Active Sonar Federate The ActiveSonar federate manages the active sonar object instances existing in the federation. 31 . 6. The signal propagation model implements straight line propagation of signals only. In order to do this.The SimulationController federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix H. This results in most of the functionality of the federate residing in the federate ambassador callbacks. This management involves the dynamic creation and deletion of active sonar object instances based on interactions sent by the SimulationController federate (CreateActiveSonar. Transmission loss occurs through spherical spreading and the speed of sound is assumed to be constant at 1500 ms-1. OutgoingSignals and IncomingSignal.

6. The PassiveSonar federate is event driven. The PassiveSonar federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix C. DeletePassiveSonar). the active sonar object instance’s time for next emission is incremented by its pulse rate. Once the ActiveSonar federate’s local time exceeds an object instance’s time for next emission. The ActiveSonar federate responds to the IncomingSignal interaction by updating the appropriate active sonar object instance’s received signal. Each active sonar object instance has a member variable indicating the time for the next emission. Initially all passive sonars will receive acoustic signals omnidirectionally. Its functionality stems from reacting to the IncomingSignal interaction. This management involves the dynamic creation and deletion of passive sonar object instances based on interactions sent by the SimulationController federate (CreatePassiveSonar. ProvideDirections. 32 .The ActiveSonar federate’s simulation loop consists of checking to see if any of the active sonar object instances are scheduled to emit an acoustic signal at the federates current time. Once complete. The functionality is determining the received signal strength and modifying the correct passive sonar instance accordingly.5 Passive Sonar Federate The PassiveSonar federate manages the passive sonar object instances existing in the federation. the ActiveSonar begins the RequestDirections. OutgoingSignals triumvirate of interactions required to emit a signal. Initially all active sonars will emit and receive acoustic signals omnidirectionally. The ActiveSonar federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix B.

6 Noise Source Federate The NoiseSource federate manages the noise source object instances existing in the federation. The functionality of the NoiseSource federate is very similar to that of the ActiveSonar federate. Initially noise sources will exist for the duration of the federation execution. Initially all noise sources will radiate acoustic signals omnidirectionally. 6. To simulate this in the Signal Propagation Federation. The Scatterer federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix E. DeleteNoiseSource). noise sources will have to radiate a signal at every time step. Initially the scatterers will receive and reflect sound omnidirectionally.6. ProvideDirections and OutgoingSignals interactions. The output from an acoustic noise source is continuous over the time that it exists. The NoiseSource federate’s simulation loop will involve calling the interactions RequestDirections. For this reason. 33 . This management involves the dynamic creation and deletion of noise source object instances based on interactions received from the SimulationController federate (CreateNoiseSource.7 Scatterer Federate The Scatterer federate manages the scatterer object instances existing in the federation. The NoiseSource federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix D. This management involves the dynamic creation and deletion of scatterer object instances based on interactions sent by the SimulationController federate (CreateScatterer. It responds to the IncomingSignal interaction by modelling the reflected signal. there is no need to maintain a time for next emission variable or a pulse rate. The Scatterer federate is an event driven federate. ProvideDirections and OutgoingSignals for every noise source instance. The reflected signal is radiated using the RequestDirections. DeleteScatterer).

C++ offers the most power for simulation programming. A C2 object instance will allow for human control of the sonars within the federation. IDL and Java.6. The C2 federate’s publication and subscription interests are presented in its Simulation Object Model located in Appendix F. frequency and pulse rate of active sonars will be modifiable. Bindings to the libRTI do exist for CORBA. it is intended to integrate much more complex models at a later date. This management involves the dynamic creation and deletion of C2 object instances based on interactions sent by the SimulationController federate (CreateC2. These models will almost certainly be implemented in C++ (or C). The RTI library libRTI (supplied with the DMSO RTI distribution) is written in C++ so is the language of choice for the implementation of federates. 11 In the Virtual Ship Federation Object Model. A C2 object instance will display the acoustic data received by the active and passive sonars that it controls. DeleteC2). a parent ID attribute is used to group component entities into a conceptual composite entity.8 C2 Federate The C2 federate manages the C2 object instances existing in the federation. 34 . Although the models implemented in the Signal Propagation Federation are very simple. A C2 object instance is associated with active and passive sonars by having the same parent identifier11. Initially the strength.1 Introduction This chapter describes some of the implementation issues that arose in the development of the Signal Propagation Federation. Of the possibilities available. 7 Implementation Details 7. so using C++ now will ease the integration process in the future.

The use of graphical user interfaces also facilitates the inputting of data by not having to remember console commands. Unpublish and unsubscribe Object Classes and Interaction Classes 9.2 Federate Implementation There is a lot of commonality in the development of HLA federates. Enable time management 4. 35 . For these reasons. Start the simulation loop 5. it is possible to maintain a standard look and feel across platforms. Create and join a federation 2. 12 Ticking the RTI refers to the federate code yielding time to the runtime infrastructure to allow it to perform federate ambassador callbacks. The Java Swing API allows platform independent displays to be developed. Resign from and destroy the federation. Java displays were developed for the federates. These displays visualise the object instances and signal data existing in the federation in graphical and tabular form. Request time advances 7. 7. Publish and Subscribe Object Classes and Interaction Classes 3. Since the displays are platform independent. Perform simulation 6. This limits the portability of the code across multiple platforms.The problem with using C++ is that any graphical user interfaces implemented will use the windowing system of a specific platform. This stems from the fact that all federates generally follow the same lifecycle. Tick the RTI12 8. The following lists the lifecycle of an HLA federate. 1.

36 . 1. 3a. Time management can be enabled using the functions EnableTimeRegulation and EnableTimeConstrained. The class diagram for the GeneralFederate class is shown in Figure 11. The functions used to publish and subscribe Object and Interaction Classes are PublishObjectClasses. 4. Destroy the Java Virtual Machine. In order to instantiate Java classes. This usually occurs when the display is closed. the federate lifecycle becomes. Instantiate the Java display. 3b. PublishInteractionClasses. The simulation loop iterates until the member variable flag finished is set to true. 2. 3. These are pure virtual functions in the GeneralFederate class and must be implemented by the subclass.The federates developed for the Signal Propagation Federation were unique in that they used Java displays. This provides an altered federate lifecycle. Using the operations presented in the class diagram. The RegisterNativeMethods function is used to notify a Java class of the native functions that are called from the display. the Java Virtual Machine must be running. The Java Virtual Machine is started and initialized using the function InitializeJVM. Start the Java Virtual Machine 3b. This commonality saw the development of a base class GeneralFederate. 8a. The function CreateAndJoinFederation is used by the federate to attempt to create the federation execution and then join the federate to it. SubscribeObjectClasses and SubscribeInteractionClasses. These functions result in the federates local time being set. The functions RegisterNativeMethods and InitiateDisplay are specific to a federate and hence are pure virtual functions in the GeneralFederate class. 3a. The modifications are as follows.

Each federate will have simulation specific code to implement each time through the simulation loop. This requirement stems from the fact that the RTI cannot process services when it is performing federate ambassador callbacks. If RTIambassador services are called 37 . A federate event queue is processed at each iteration. This code will generally involve interacting with object instances of the Object Classes defined in the FOM. This event queue is used to cache events that have to be processed in the simulation loop of the federate.Logical View GeneralFederate #finished : Boolean #genFedAmb : GeneralFederateAmbassador* #rtiAmb : RTI::RTIambassador #env : JNIEnv* #jvm : JavaVM* #jobject : display #eventQueue : Queue* #currentTime : RTIfedTime #timeAdvancePending : RTI::Boolean +CreateAndJoinFederation() +ResignAndDestroyFederation() +PublishObjectClasses() +UnPublishObjectClasses() +SubscribeObjectClasses() +UnSubscribeObjectClasses() +PublishInteractionClasses() +UnPublishInteractionClasses() +SubscribeInteractionClasses() +UnSubscribeInteractionClasses() +EnableTimeRegulation() +EnableTimeConstrained() +RequestTimeAdvance() +Initialize() +InitializeJVM() +RegisterNativeMethods() +InitiateDisplay() +Simulate() +ProcessEventQueue() +AddEventToQueue(evObject : EventObject*) +DoTick() Figure 11 Class Diagram for GeneralFederate 5.

6. the federate requests a time advance to a new time by calling RequestTimeAdvance. This is accomplished by a call to ResignAndDestroyFederation. 38 . ProcessEventQueue decodes all event objects in the event queue and performs the necessary function calls. This is indicated by the member variable timeAdvancePending being set to false. 7. The Java Virtual Machine is destroyed through a call to DestroyJavaVM. The federate then enters a loop until a time advance is granted. UnPublishInteractionClasses. This function is part of the Java Invocation API. When the federate has finished operation (the member variable finished becomes true) some tidying up needs to be performed. 9. At the completion of an iteration in the simulation loop. 8. The functions mentioned in points 8. Finally the federate resigns from the federation and attempts to destroy the federation execution.from within federate ambassador code. While the federate is waiting for a time advance. This discussion leads to the following code snippets. When a federate ambassador callback requires an RTIambassador service call. UnSubscribeObjectClasses and UnSubscribeInteractionClasses unpublish and unsubscribe any object or interaction classes previously published or subscribed. The solution developed involves the following. The functions UnPublishObjectClasses. The next time through the simulation loop the event queue will be processed by calling ProcessEventQueue. a ConcurrentAccessException is thrown. the service call information is bundled into an event object and placed on the event queue using AddEventToQueue. 8a. These functions are federate specific and are therefore declared as pure virtual functions in the GeneralFederate class. This is done by calling the function DoTick (yielding time to the RTI is referred to as ticking the RTI). it should yield time to the RTI so that the RTI can perform federate ambassador callbacks. 8a and 9 are called from the destructor of the GeneralFederate class.

39 . // calls the publish and subscribe methods InitializeJVM(). /* Calling ProcessEventQueue here enables events generated by the previous call to DoTick( ) to be processed */ ProcessEventQueue().Simulate( ). } } } The class hierarchies implemented for the Signal Propagation Federation are presented in Appendix K. InitiateDisplay(). // start simulation loop while( !finished ) { // check for input // simulate ProcessEventQueue() RequestTimeAdvance( /* new time */ ) if( timeAdvancePending ) { DoTick(). } The function Simulate is declared as a pure virtual function in GeneralFederate.The main function creates an instance of the federate and then calls its Simulate method. void main() { SpecificFederate sf. sf. SpecificFederate::Simulate( ) { Initialize( ). It is in Simulate that a federate performs the functions discussed in points 2 – 7. The GeneralFederate constructor calls CreateAndJoinFederation. RegisterNativeMethods().

There is no way of guaranteeing that the RTI is not being ticked when an input event is handled. The ConcurrentAccessException of the RTI poses a problem for an interface that issues events requiring calls to RTI services asynchronously with the RTI being ticked. The Java displays execute in a different thread of execution to the federate code. In particular. If it finds the input ready flag is true. The solution to these problems was to have input event handlers set a flag in the native code indicating an input event had occurred and by passing the event data through a formatted string.7. The Java Swing API provides an extensive library of GUI components that can be used to create complete interfaces. The Java Swing components are referred to as lightweight components because they do not utilise any native windowing code when displaying the interface. the classic producer/consumer problem arises. This allows for a common look and feel to be maintained across different platforms. the federate analyses the input string and performs the functionality encoded in the string.3 Java Displays Java was selected as the language for writing the federate GUIs. However. the Java Swing API was used. At the time of writing only displays for the SimulationController and ActiveSonar federates had been developed and integrated. 40 . the lessons learned from developing these displays should allow for rapid development and integration of the remaining displays. If the input handler code were to use the federate event queue for caching the input. The federate code then receives inputs by polling the input ready flag each time through its simulation loop.

there is little technical experience in using the HLA to draw on.8 Conclusions The High Level Architecture is a very new framework in Australia. this project represents one of the most complex applications of the HLA to be implemented from scratch in Australia13. As a result. • The establishment of guidelines for the implementation of Java GUIs with C++ simulation code. The Virtual Ship task is the largest project utilising the HLA being undertaken in Australia. • The establishment of some guidelines for the development of federates and federations. therefore. Performance issues include how much the federation slows down as the number of object instances increases and how much of the slow down can be attributed to network latencies or the RTI. Future work in this project will include • Analysing the performance of the approach established in this project. • A general increase in Australia’s level of technical expertise in developing HLA federations. The impact of using Java displays on performance is another area to be explored. Work on the Virtual Ship has only just begun to look at the implementation details of federates. The main outcomes of this project were • The establishment of a framework for modelling signal propagation in an HLA enabled distributed simulation. 41 . 13 There have been federations implemented that modify existing models to use the HLA and integrating these models into a federation.

ship to land via microwave or satellite. A new approach will have to be developed if real time modelling is necessary. the acoustic signals are fairly persistent and may be better represented as Object Classes. • At some point more complex models will replace the basic models used in this project. inter-ship. electromagnetic signals and possibly communications (intra-ship. • The central propagation model concept will be integrated into the Virtual Ship at a point in the future.• The approach adopted is not really suited to the case of noise sources radiating acoustic energy. • This approach can be extended to model electromagnetic propagation but it would not be possible to do it real time due to the short transmission delays. etc). This concept will be used for modelling acoustic signals. 42 . When this occurs the performance of the federation will be tested again. In this case.

3. Coates. 4.3.: Underwater Acoustic Systems. P. McGraw-Hill Book Company. High Level Architecture. Object Model Template Specification.mil/hla/tech/omtspec/.W. John Wiley & Sons.dmso.: The Virtual Ship – A New Capability in Support of Maritime Forces. J.3. Rules. 2.dmso.dmso. High Level Architecture. 1999. http://hla. NATO Modelling & Simulation Master Plan. http://hla. http://www.3. Version 1. R. US DoD Modelling & Simulation Master Plan.9 List of References 1. 7.mil/dmso/docslib/mspolicy/nato_msmp.mil/hla/tech/ifspec/. US Department of Defence. High Level Architecture.. 1975. 5. DSTO General Document 0198 (DSTO-GD-0198). US Department of Defence. Interface Specification. http://hla. R. Version 1.dmso. 8.: Principles of Underwater Sound. Inc. 2nd Edition.mil/dmso/docslib/mspolicy/msmp. J. 6. http://www. Best.dmso. US Department of Defence. Version 1. 1989.F. Urick. 43 .mil/hla/tech/rules/.

Appendix 44 .