project_report.pdf

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.

iAbstract

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 objects

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.

ii

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.

iii

Table of Contents

PREFACE..........................................................................................................................................VII

PART I: BACKGROUND INFORMATION .................................................................................... 1

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

1.1 INTRODUCTION ......................................................................................................................... 1

2 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

3 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 SCENARIO EXECUTION............................................................................................................ 23

4.5.1 Tasks............................................................................................................................. 23

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

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

5 FEDERATION DESCRIPTION ............................................................................................. 25

5.1 INTRODUCTION ....................................................................................................................... 25

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

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

iv

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

7 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

vList of Figures

FIGURE 1 TRADITIONAL APPROACH TO SIGNAL PROPAGATION MODELLING........................................ VII

FIGURE 2 APPROACH TO SIGNAL PROPAGATION TAKEN IN THIS REPORT. ............................................ VIII

FIGURE 3 FEDERATES COMMUNICATE VIA THE RTI ............................................................................... 3

FIGURE 4 DMSO RTI DISTRIBUTION COMPONENTS ............................................................................... 9

FIGURE 5 FEDERATE-FEDERATION INTERPLAY..................................................................................... 10

FIGURE 6 DIAGRAM OF THE ACTIVE SONAR EQUATION PARAMETERS ................................................. 12

FIGURE 7 REVERBERATION LEVEL DIMINISHES WITH RANGE................................................................ 15

FIGURE 8 DIAGRAM ILLUSTRATING THE PASSIVE SONAR EQUATION PARAMETERS ............................... 17

FIGURE 9 SIMPLE BEAM PATTERN OF AN ACTIVE SONAR....................................................................... 19

FIGURE 10 SIGNAL PROPAGATION FEDERATION DIAGRAM .................................................................. 26

FIGURE 11 CLASS DIAGRAM FOR GENERALFEDERATE ......................................................................... 37

vi

List of Tables

TABLE 1 INTRINSIC BEHAVIOURS OF ENTITIES IN THE SIGNAL PROPAGATION APPLICATION ................ 22

TABLE 2 INTERACTIONS BETWEEN ENTITIES IN THE SIGNAL PROPAGATION APPLICATION ................... 23

vii

Preface

Traditionally, signal propagation is modelled in the sensor models. This approach is

shown in Figure 1. This approach to signal propagation modelling means that sensor

models need to maintain or obtain information about the environment and objects

within the environment. For example, for a detector to model the signal scattered

from a target, 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. When this approach is applied to

distributed applications, the amount of data that needs to be transferred across the

network becomes prohibitive. Generally the solution to this has been to limit the

fidelity with which the signal emission, propagation, scattering and detection is

modelled.

This project looks at implementing a new approach to modelling signal propagation

within a distributed simulation. The approach taken is illustrated in Figure 2. Instead

of the sensors modelling the signal propagation, a dedicated simulation model is used

to model the signal propagation. The previous example is then solved by the emitter

radiating a signal into the signal propagation model. The signal propagation model

then simulates the signal propagation on towards targets and detectors, and passes

information about the received signal to them.

Emitter

Emitter

Emitter

DetectorSignal

PropagationModel

DetectorSignal

PropagationModel

Figure 1 Traditional Approach to Signal Propagation Modelling.

viii

Emitter

Emitter

Emitter

SignalPropagation

Model

Detector

Detector

Scatterer

Figure 2 Approach to Signal Propagation taken in this report.

The targets themselves calculate their scattered signal and radiate this back into the

signal propagation model. The propagation is once again modelled and passed on to

detectors (and possibly other scatterers).

This approach allows for complex emission, scattering and detection behaviours to

be encapsulated within the simulation models representing these behaviours.

This project concentrates on the undersea environment, and hence, acoustic signal

propagation. One of the conclusions from this report will be whether or not the

approach adopted would be extensible to electromagnetic signal propagation.

The format for this report is as follows.

Part I presents some background information on which this project is dependant.

Section 1 discusses the Virtual Ship, a task undertaken at the Defence Science and

Technology Organisation, Australia. This project was performed in support of this

task.

Section 2 discusses the High Level Architecture (HLA), a framework for distributed

simulation mandated by the US Department of Defence (DoD) and adopted by the

ix

Virtual Ship. The approach to signal propagation modelling discussed in this

document was implemented using the HLA.

Section 3 discusses the fundamentals of acoustic signal propagation. This provides a

basis for the section discussing the implementation details of the signal propagation

model.

Part II presents the technical information of the report.

Section 4 introduces an Application Description of the Signal Propagation

Federation. An Application Description is an analysis tool for the development of

federation executions.

Section 5 discusses the Signal Propagation Federation. The federation is represented

diagrammatically and the process of signal propagation within the federation

execution is discussed.

Section 6 discusses the individual simulation models that take part in the Signal

Propagation Federation. The simulation models are Active Sonar, Passive Sonar,

Noise Source, Scatterer, C2, Simulation Controller, and Propagation. These models

are identified as the major participants in the Signal Propagation Federation.

Section 7 discusses some details of the implementation of the Signal Propagation

Federation. This includes the development of a standard base class for the

construction of HLA compliant simulation models, the development of a federate

side event queue and the development of Java graphical user interfaces (GUIs).

Section 8 presents some lessons learned from this project and discusses extensions

and recommendations for the further development of the central signal propagation

model.

The Appendices provide documentation that is used as reference material throughout

this report.

1PART I: Background Information

1 Virtual Ship.

1.1 Introduction

The aim of Virtual Ship [1] is to simulate a surface warship. Conceptually, a warship

is the sum of its components. A warship has sensors (radar, sonar, ESM1, etc),

weapon systems (missiles, guns, etc), motion, a physical platform and facilities to

control other aspects of the warship (command and control, helm, etc). Virtual Ship

will simulate a warship by simulating and interoperating a warships components.

This decomposition naturally lends itself to the distributed simulation paradigm.

The Virtual Ship will be used for many applications, some of which are listed below.

The operational utility of warship systems can be demonstrated and refined.

Issues relating to integration of warship systems can be explored. In combination

with the previous point, this will allow tendered systems to be integrated and

evaluated in virtual form before acquisition.

The Virtual Ship will allow for the development of tactics and operational

concepts.

The essential components of the Virtual Ship will be system models, the data that

characterise the models, and a federated architecture within which these models are

brought together. The federated architecture of the Virtual Ship will be based upon

the US standard for distributed simulation, the High Level Architecture (HLA). The

core of the HLA is the definition of a standard for the exchange of data amongst

simulations. The existence of a data exchange standard enables models to be brought

together in a plug and play fashion. The basis of the Virtual Ship upon the HLA

1 ESM is Electronic Support Measures. An ESM sensor is essentially a passive radar. The sensor

searches the environment for radio wave emissions.

2will provide natural interoperability with virtual air and land environments also

developed with the HLA. The Virtual Ship should also be interoperable with

simulations developed by the NATO countries (see 2.1).

2 The High Level Architecture (HLA).

2.1 Introduction

Under the authority of DoD Directive 5000.09, and as prescribed by the DoD

Modelling and Simulation Master Plan, I designate the High Level Architecture as

the standard technical architecture for all DoD simulations. Dr. Paul Kaminski,

Under Secretary of Defence, Acquisition and Technology, 10 September 1996.

With this statement, all simulations developed by, or for, the US DoD will utilise the

High Level Architecture. To enforce this mandate, the following No Can Dates

have been set.

No Can Pay first day of FY99: No funds will be allocated for

developing/modifying non-HLA-compliant simulations after this date.

No Can Play first day of FY01: All non-HLA-compliant simulations will be

retired after this date.

NATO has also adopted the HLA as a standard framework for developing

simulations [2].

The HLA fulfils objective 1-1 of the US DoD Modelling and Simulation (M&S)

Master Plan [3]. 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, as well as to facilitate reuse

of M&S components.

2 C4I is Command, Control, Communications, Computers and Intelligence.

3The HLA is being defined by the Defence Modelling and Simulation Office

(DMSO). In order to distribute knowledge of the HLA, DMSO has set up an HLA

web site at http://hla.dmso.mil.

An HLA federation is a named set of interacting federates, a common Federation

Object Model (FOM) and supporting runtime infrastructure (RTI), that are used as a

whole to achieve some specific objective.

An HLA federate is a member of a federation. Each federate can be such applications

as,

Simulations

Data Loggers

Passive (Stealth) Viewers

Live Entity Surrogates

Federates communicate with each other via services provided by the runtime

infrastructure, or RTI. The RTI is a software implementation of the services

specified in the HLA Interface Specification.

The above concepts are illustrated in Figure 3.

Figure 3 Federates Communicate via the RTI

R u n T Im e In fra s tru c tu re

S im u la tio n sS u p p o rt U tilit ie s(D a ta L o g g e rs ,

S te a lth V ie w e rs ,e tc )

L ive E n tityS u rro g a te s

L ive P a rtic ip a n ts

4The data exchanged during federation execution are grouped into classes. Object

classes represent data that have some persistent state in a federation execution.

Object classes are defined by their attributes. Interaction classes are used to

represent transient events during a federation execution. Interaction classes convey

information through the interaction class name and parameters.

The data passed around the federation can be sent in time-stamped order or receive

order. The RTI delivers time stamped ordered data to federates when the federates

local time reaches the time stamp of the data. Receive ordered data are sent

regardless of a federates local time.

The RTI manages the time advancement of the federates participating in a federation.

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 federates past.

The HLA defines four types of time management policy.

Time regulating: A federate that is time regulating is capable of sending data with

time stamps.

Time Constrained: A time constrained federate is capable of receiving time

stamped data.

Both Time Regulating and Time Constrained.

Neither Time Regulating nor Time Constrained: Federates with this policy run as

fast as they want.

In May 97, an HLA standards nomination was submitted by DMSO to the SISO3

Standards Activity Committee for IEEE standardisation. Three IEEE 1516 standards

are expected by the end of 1999. The three standards comprise the three formal

components of the HLA. These are:

The HLA Rules (HLA Rules IEEE 1516.1)

3 SISO is the Simulation Interoperability Standards Organisation.

5 The HLA Interface Specification (I/F Spec IEEE 1516.2)

The Object Model Template (OMT IEEE 1516.3)

These three components are discussed in more detail in the following sections.

2.2 The Rules

The HLA Rules [4] define standards to which every federate and federation must

adhere. Adherence to these rules facilitates interoperability amongst models

developed using the HLA. There are ten rules, five pertaining to federations and five

pertaining to federates.

The rules for federations are:

1. Federations shall have an HLA federation object model (FOM), documented in

accordance with the Object Model Template (OMT).

2. In a federation, all simulation-associated object instance representation shall be in

the federate, not in the runtime infrastructure (RTI).

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

occur via the RTI.

4. During a federation execution, federates shall interact with the RTI in accordance

with the HLA interface specification.

5. During a federation execution, an instance attribute shall be owned by at most one

federate at a given time.

The rules for federates are:

6. Federates shall have a Simulation Object Model (SOM), documented in

accordance with the HLA OMT.

7. Federates shall be able to update and/or reflect any attributes and send and/or

receive interactions, as specified in their SOMs.

8. Federates shall be able to transfer and/or accept ownership of attributes

dynamically during a federation execution, as specified in their SOMs.

69. Federates shall be able to vary the conditions (e.g. thresholds) under which they

provide updates of attributes, as specified in their SOMs.

10. 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.

2.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, to include objects, attributes, interactions, and

parameters, but it does not define the specific data that will appear in the object

models.

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. The HLA OMT provides a template for documenting HLA-relevant

information about classes of simulation or federation objects and their attributes and

interactions.

An object model used to describe an individual federate is termed a Simulation

Object Model (SOM). An HLA SOM is a specification of the intrinsic capabilities

that an individual simulation could provide to HLA federations. The standard format

in which SOMs are expressed facilitates determination of the suitability of simulation

systems for participation in a federation.

A federation object model (FOM) is used to describe a named set of interacting

federates, or federation. The primary purpose of an HLA FOM is to provide a

specification for data exchange among federates in a common and standardised

format. The content of this data includes an enumeration of all object and interaction

classes pertinent to the federation, along with a specification of the attributes or

parameters that characterise these classes.

HLA object models are composed of a group of interrelated components specifying

information about classes of objects, their attributes, and their interactions. The

7template for the core of an object model uses a tabular format and consists of the

following components.

Object model identification table: to associate important identifying information

with the HLA object model.

Object class structure table: to record the namespace of all simulation/federation

object classes and to define their class-subclass relationships.

Interaction class structure table: to record the namespace of all

simulation/federation interaction classes and to describe their class-subclass

relationships.

Attribute table: to specify features of object attributes in a simulation/federation.

Parameter table: to specify features of interaction parameters in a

simulation/federation.

Routing space table: to specify routing spaces for object attributes and

interactions in a federation.

FOM/SOM lexicon: to define all of the terms used in the tables.

To assist in the creation of HLA object models, AEgis Research Corporation4 have

developed the Object Model Development Tool (OMDT). This software allows the

tables in the OMT to be filled out via a graphical user interface. The OMDT allows

for the object model data to be saved as federation execution data, as required at

runtime by the RTI, and also in the native OMT data interchange format. A free

version of the OMDT can be downloaded from the HLA software distribution

center5.

4 http://www.aegisrc.com

5 http://www.dmso.mil/RTISUP/hla_soft/hla_soft.htm

82.4 Interface Specification

The HLA requires a language independent specification and multiple language

bindings to support inter-simulation communication in a distributed simulation

domain. 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.

These interfaces are arranged into six basic RTI service groups:

Federation Management: Federation management includes such tasks as creating

federations, joining federates to federations, observing federation-wide

synchronization points, effecting federation-wide saves and restores, resigning

federates from federations, and destroying federations.

Declaration Management: Declaration management includes publication,

subscription, and supporting control functions.

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. Object management also includes

methods associated with sending and receiving interactions and controlling

instance updates based on consumer demand.

Ownership Management: Ownership management groups services relating to the

sharing of responsibility for the updating of object instances amongst many

federates. When update responsibility for an object is shared, each of the

participating federates has responsibility for a mutually exclusive set of object

attributes.

Time Management: The focus of time management is on the mechanics required

to implement time management policies and negotiate time advances.

9 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.

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.

2.5 DMSO Runtime Infrastructure (RTI)

To support the shift towards the use of the HLA, DMSO has released an

implementation of the RTI services. The current version of the RTI implements

version 1.3 of the interface specification. The DMSO RTI distribution is comprised

of the RTI Executive process (RtiExec), the Federation Executive process (FedExec)

and the libRTI library. The use of the DMSO RTI distribution is illustrated in Figure

4. The DMSO RTI distribution can be downloaded from the HLA Software

Distribution Center.

The RtiExec is a global process. The RtiExecs primary purpose is to manage the

creation and destruction of FedExec processes. Federate communications with the

RtiExec are directed to the appropriate FedExec.

Figure 4 DMSO RTI distribution components

...RtiExec FedExec Federate(s)libRTI

Federate(s)

libRTI

Inter-Process Communications

RTI Provided Federate Provided

10

Each FedExec manages a federation. A FedExec allows federates to join and resign,

and facilitates data exchange between participating federates. The libRTI provides

the services specified in the HLA Interface Specification to federate developers.

Federates use libRTI which communicates with the RtiExec, a FedExec, and other

federates to invoke HLA services. Within libRTI, the class RTIambassador bundles

the services provided by the RTI. The abstract class FederateAmbassador identifies

the callback functions each federate is obliged to provide. A federate must implement

the functionality declared in FederateAmbassador. 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.

Figure 5 Federate-Federation Interplay

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

resign

begin shutdown

remove federate

11

3 Acoustic Propagation in the Undersea Environment

3.1 Introduction

Sound transmission is the single most effective means of directing energy transfer

over long distances in seawater. Neither radio wave nor optical propagation is

effective for this purpose, as the former, at all but the lowest useable frequencies,

attenuates rapidly in the conducting salt water and the later is subject to scattering by

suspended material in the sea [7].

Two sets of equations are used to define underwater acoustic propagation. The active

sonar equation involves a source emitting an acoustic signal. This signal then

propagates to a target where it is reflected back to the source. This is the basic echo

location concept. The passive sonar equation involves one way propagation only. An

acoustic signal is radiated into the environment and propagates to a receiver.

In acoustics, signal levels are measured6 in decibels with respect to a reference wave

at a standard range from the acoustic centre of a sensor. The reference wave is a

plane wave of rms pressure 1Pa, and the standard range is 1m. This fact is

conveyed by stating a signal level as SL dB re 1Pa.

The variables used in this section come from those defined by Urick [8] and used in

most texts on underwater acoustics since.

3.2 Sonar Equations

The basic active sonar situation is illustrated in Figure 6. An active sonar emits an

acoustic signal at a source level, SL. The source level is given by

SL = 10 log 10 (intensity of source / reference intensity).

6 In practice, acoustic signals are measured in the far field and scaled back to the standard range of

1m. This is done so as the measurement is not corrupted be near field effects such as resonance.

12

Target Strength,TS, at 1m fromacoustic centre.

Sea surface

Sea Floor

Source Level,SL, at 1m.

Noise Level,NL.

ReverberationLevel, RL.

Self-NoiseLevel, NL

Two way transmissionloss, 2TL

Target

Figure 6 Diagram of the Active Sonar Equation Parameters

13

At a standard range of 1m, the emitter is surrounded by a spherical envelope of

surface area 4r2 = 12.6m2. If the emitter radiates with power P omnidirectionally,

the intensity of the source is

Intensity of source = Power / Area = P / 12.6 Pa.

With a reference intensity of 1Pa, this gives a source level of

SL = 10 log 10 P + 167 dB.

This signal propagates to a target incurring a transmission loss, TL. Transmission

loss refers to the reduction in signal intensity over distance. There are two main

causes of transmission loss, spreading and absorption. Spreading refers to the

broadening of the emitted acoustic wave with distance. The effect of spreading

generally ranges between two extremes, spherical spreading and cylindrical

spreading.

Spherical spreading occurs in environments where no acoustic channelling can occur.

This is usually the case in deep-water environments. Spherical spreading results in a

reduction in signal level proportional to the inverse square of range

TL = 20 log 10 R.

Cylindrical spreading occurs when channelling of acoustic energy occurs. The sea

surface and sea floor are good channellers of acoustic energy and hence cylindrical

spreading occurs most often in relatively shallow water. Cylindrical spreading results

in a reduction in signal level proportional to the inverse of range

TL = 10 log 10 R.

The other cause of transmission loss is absorption. Absorption occurs through

viscous friction at high frequencies and molecular resonance at lower frequencies.

Taking spreading and absorption together gives the following equation for

transmission loss:

TL = k log 10 R + R

14

where the value of k depends upon whether the wave experiences spherical

spreading, k = 20, or cylindrical spreading, k = 10, and =is the absorption loss

coefficient.

Target strength, TS, is the decibel intensity returned from a target relative to the

incident intensity. Target strength is measured in the far field and scaled back to 1m

taking into account transmission losses. 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.

The signal reflected from the target changes in intensity by the target strength. The

reflected signal propagates back to the active sonar, incurring another reduction in

signal level due to transmission loss. The signal level received by the active sonar is

given by SL 2TL + TS.

The signal received by the active sonar will be masked to some extent by an ambient

noise level, NL, and a reverberation level, RL. In general, either noise or

reverberation will be dominant.

Ambient noise comes in many forms including waves, rain, biologics, shipping, etc.

Reverberation refers to the echoes received from the incident signal reflecting off the

sea surface, sea floor and the sea volume. The reverberation level is therefore

affected by range and transmission losses. Noise level is ambient with no fixed

source and will appear to be approximately constant at all positions. This results in a

range where the reverberation level will drop below the ambient noise level. This is

illustrated in Figure 7. This dominance of reverberation level over noise level (and

vice versa) results in two forms of the active sonar equations, one reverberation

limited the other noise limited.

Another source of noise is self-noise. This is the noise radiated from the platform on

which the receiver resides, being picked up by the receiver. Such sources of noise

include machinery, wake, bow wave, flow noise over the sonar array, etc.

15

Sign

al L

evel

Range

Noise Level, NL

ReverberationLevel, RL

active sonarequations

reverberationlimited

active sonar equatoinsnoise limited

Figure 7 Reverberation Level diminishes with range

Ambient noise impinges on a detector omnidirectionally. The detector, however, will

only receive the noise from a certain direction. The actual noise received by the

detector is NL DI, where DI is the directivity index of the detector. The directivity

index can be derived from the beam pattern of the detector. For a beam pattern

subtending steradians of solid angle, the directivity index is given by

DI = 10 log 10 (4/).The reverberation level is directional, so its reception is subject to the normal

operation of the sonar's receiver.

The previous discussion results in the active sonar equations. These equations

provide expressions for the signal-to-noise ratio (SNR) received by the detector.

The noise limited active sonar equation is given by

SNR = SL 2TL + TS (NL DI).

The reverberation limited active sonar equation is given by

SNR = SL 2TL + TS - RL.

16

The passive sonar case is shown in Figure 8. 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. The detector receives the radiated signal and an

ambient noise level modified by the receivers directivity index. This results in the

passive sonar equation as

SNR = SL TL (NL DI).

17

Target sourcelevel, SL.

Sea surface

Sea Floor

Noise Level,NL.

Self-NoiseLevel, NL

Transmission loss, TL

Target

Figure 8 Diagram illustrating the passive sonar equation parameters

18

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. Part of the FEDEP is to define scenarios for federation

execution. The Virtual Ship Architecture Working Group (VSAWG) has extended

this concept into Application Descriptions. An Application Description gives an

entity level analysis of the federation as well as a scenario for federation execution.

This section provides an application description for the Signal Propagation

Federation. The format used follows the layout defined in the VSAWG Application

Description Template. This template can be found in Appendix I. The numbering

scheme of the following application description has been modified so as to fit into

the format of this project report.

4.1 Description

All facets of acoustic signal propagation in the undersea environment have inherent

complexities.

Active sonars and other acoustic noise sources generally do not radiate acoustic

energy omnidirectionally. Rather, the acoustic signal radiated is modified in certain

directions due to the emitters beam pattern. Generally, an active sonar will have a

beam pattern that consists of a main lobe centered on the sonars axis. In addition,

the beam pattern may have a number of sidelobes separated by nulls. A simplistic

beam pattern is shown in Figure 9.

Passive sonars can also have receiver beam patterns. It is possible to modify the

shape of the beam pattern dynamically so as to cancel out noise coming from a

certain direction. This concept is referred to as adaptive beam forming.

7 http://hla.dmso.mil/hla/federation/

19

Figure 9 Simple beam pattern of an active sonar

The scattering properties of acoustic reflectors are anything but simple. As an

example, suppose an acoustic signal is incident on a hollow cylinder. 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. A signal will be reflected with higher

intensity if the signal is incident broadside to the cylinder rather than end on. This

results from the cross section of the cylinder being larger when incident broadside.

In addition to cross sectional changes, the incident signal may set the scatterer into

resonance resulting in reflected signals at different frequencies and strengths.

The propagation of signals through the subsurface environment also encounters

many complexities. Most of the complexities stem from the fact that the speed of

sound varies with depth8. 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

(Snells Law).

Modelling all these complexities at high fidelity within a single simulation requires

heavy computational resources. Distributing the simulation offers the opportunity to

8 Actually, speed of sound varies with temperature, pressure and salinity. These parameters vary with

depth.

Acoustic centre

Acoustic axis

Main lobe

Side lobe

20

simulate all the models at high fidelity without incurring high computational

requirements.

The problem of how to interact the various simulation models must then be

examined.

This application intends to set up a framework for the collaboration of models for

active sonars, passive sonars, acoustic scatterers, noise sources and propagation. This

framework will consist of the concept for signal propagation and the interface to the

RTI to achieve this concept. Initially low fidelity models will be implemented to

allow the framework to be developed and tested. Once the framework is in place,

more complex models can be implemented at a later date.

4.2 Example Scenario

A multistatic system will be implemented as a scenario for this application. A

multistatic system is one that involves a source of acoustic energy emitting into the

environment, while several remote passive sensors listen for returns from the

transmitted signal.

This scenario will be called the Active Multistatic Scenario.

The scenario will consist of an active sonar, one passive sonar located remotely from

the active sonar, and an acoustic scatterer acting as a target for detection. A C2

system9 will display the signals received by the active and passive sonar.

The active sonar emits an acoustic signal into the propagating medium. This signal

propagates through the medium to impinge on the passive sonar and target. The

passive sonar records the signal level received. 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.

A second scenario, called the Passive Multistatic Scenario, will replace the active

sonar with a second passive sonar. A noise source (for example, machinery noise or a

9 C2 is command and control.

21

SUS charge10) will then be introduced. The acoustic signal radiated from the noise

source will propagate through the medium to be received by the passive sonars. 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. The signal received by the

passive sonars will be displayed on a C2 system.

4.3 Outcomes

The primary outcome of this application will be the establishment of a framework for

the collaboration of simulation models for acoustic emitters, acoustic detectors and

acoustic propagation.

4.4 Entities

The major entities will be active sonars, passive sonars, scatterers, noise sources, C2

systems and a global propagation entity.

10 SUS is Signal Underwater Sound.

22

4.4.1 Intrinsic Behaviours

Entity Behaviour Inputs Outputs Fidelity

Active Sonar An active sonar

operates by emitting an

acoustic signal and

then listening for

reflections off

scatterers.

Control information

from a C2 entity. An

acoustic signal from

the Propagation

entity.

A radiated acoustic

signal to the

Propagation entity.

Acoustic signal data

to a C2 entity.

Low

Passive Sonar A passive sonar listens

for acoustic signals

only.

Control information

from a C2 entity. An

acoustic signal from

the Propagation

entity.


to a C2 entity.

Low

Noise Source A noise source is a

continuous radiator of

acoustic noise.

Acoustic signals to

the Propagation

entity

Low

Scatterer A scatterer is an

acoustic signal

reflector.

Acoustic signals from

the Propagation

entity.

Acoustic signals to

the Propagation

entity.

Low

C2 A C2 entity allows

commands to be sent to

sonars, and sonar data

to be displayed.


from the active and

passive sonars.

Commands to the

active and passive

sonars.

Low

Propagation The Propagation entity

is a global entity used

to model signal

propagation.

Acoustic signals from

acoustic emitters

(active sonars, noise

sources, and

scatterers).

Acoustic signals to

the acoustic

detectors (active

sonars, passive

sonars, and

scatterers).

Low

Table 1 Intrinsic behaviours of entities in the Signal Propagation Application

23

4.4.2 Static Relationships

There exist static relationships between C2 entities and the sonar entities it controls.

There also exists a static relationship between acoustic emitters, acoustic detectors

and the propagation entity.

4.4.3 Interactions

The following table identifies some specific collaboration instances between the

entities. In the table, acoustic emitter refers to the entities active sonar, scatterer and

noise source, and acoustic detector refers to the entities active sonar, passive sonar

and scatterer.

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

acoustic signals

C2

Table 2 Interactions between entities in the Signal Propagation Application

4.5 Scenario Execution

4.5.1 Tasks

For the Active Multistatic Scenario:

Create active sonar

Create passive sonar

Create scatterer

Create C2

The active sonar emits an acoustic signal

24

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 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.2 Initial Conditions

There are no initial conditions for the scenarios. A human administrator creates all

entities dynamically during scenario execution.

4.5.3 Termination Conditions

Termination of the scenarios is performed manually be a human administrator.

25

5 Federation Description

5.1 Introduction

This chapter discusses the federation developed in solution of the problem at hand.

5.2 Federation Execution

Figure 10 illustrates the Signal Propagation federation. The diagramming standards

used follow those defined by the Virtual Ship Architecture Working Group

(VSAWG). These standards are presented in Appendix J.

Appendix A gives the Signal Propagation Federation Object Model (SigPropFOM).

The SigPropFOM provides information regarding the Object Classes, Attributes,

Interaction Classes, and Parameters that exist in the Signal Propagation Federation.

This information includes tables of lexicons for each of the Object Classes,

Attributes, Interaction Classes and Parameters.

26

Figure 10 Signal Propagation Federation Diagram

SimulationController

ActiveSonar

PassiveSonar

Scatterer

NoiseSource

Propagation

C2

Control

Status

Co

ntr

ol

S

t

a

t

u

s

RequestDirections

ProvideDirections

OutgoingSignals

IncomingSignals

Status

27

From the federation diagram it can be seen that the federation consists of seven

interoperating federates. The federates are:

SimulationController: This federate provides a human operator with an interface

to the entities existing within the federation.

Propagation: The modelling of acoustic signal propagation occurs in this

federate. The propagation federate maintains lists of all acoustic emitters and

acoustic detectors that exist within the federation.

ActiveSonar: The ActiveSonar federate manages the active sonar entities

participating in the environment. Active sonar entities are instances of the Active

Sonar Object Class (see Appendix A.1).

PassiveSonar: The PassiveSonar federate manages the passive sonar entities

participating in the environment. Passive sonar entities are instances of the

Passive Sonar Object Class (see Appendix A.1).

NoiseSource: The NoiseSource federate manages the noise source entities

participating in the environment. Noise Source entities are instances of the Noise

Source Object Class (see Appendix A.1).

Scatterer: The Scatterer federate manages the scatterer entities participating in

the environment. Scatterer entities are instances of the Scatterer Object Class (see

Appendix A.1).

C2: The C2 federate manages the C2 entities participating in the environment. C2

entities are instances of the C2 Object Class (see Appendix A.1).

Each of the federates are described in more detail in section 6.

These federates collaborate with each other in order to fulfil the goal of modelling

signal propagation.

The federation achieves the modelling of signal propagation through the interaction

of active sonar, passive sonar, scatterer and noise source object instances and the

Propagation federate.

28

The major simulation component of the federation execution is in the interplay of the

ActiveSonar, PassiveSonar, NoiseSource, Scatterer, and Propagation federates. The

four interactions, RequestDirections, ProvideDirections, OutgoingSignals and

IncomingSignal simulate the propagation of signals from emitters to detectors.

The process of an acoustic signal being radiated, propagating to a detector and being

received by the detector proceeds as follows:

1. The federate responsible for managing the acoustic emitter sends a

RequestDirections interaction to the Propagation federate. The name of the

acoustic emitter is passed as a parameter.

2. The Propagation federate receives the RequestDirections interaction. The

Propagation federate searches through its acoustic emitter list for the name

passed as a parameter to the RequestDirections interaction. This provides the

position of the acoustic emitter. The Propagation federate then constructs a

direction array and a destination array. The direction array is an array of vectors

from the acoustic emitter to all acoustic detectors. Each direction is a Vector3D

complex datatype (see Appendix A.5). 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. The

Propagation federate then sends the ProvideDirections interaction with

parameters being the name of the acoustic emitter, the direction array and the

destination array.

3. All federates managing acoustic emitter entities (the ActiveSonar, NoiseSource

and Scatterer federates) receive the ProvideDirections interaction. 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. If so, the federate

uses the direction array and destination array parameters to construct an array of

Signal complex datatypes (see Appendix A.5). 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. Once the signal array is

29

constructed, it is passed as a parameter in the OutgoingSignals interaction. Once

the OutgoingSignals interaction has been sent, the signal can be considered to

have been emitted.

4. The Propagation federate receives the OutgoingSignals interaction. The signal

array passed as a parameter is decomposed and each signal undergoes signal

propagation. Each signal in the signal array is a complex datatype Signal. Each

Signal datatype consists of a source identifier, a destination identifier (these

identifiers are character strings), an incident direction and signal parameters

strength and frequency. 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. Once found, the distance between the

emitter and detector is determined, allowing the transmission loss and time delay

to be calculated. The strength of the signal is decreased by the transmission loss

and then sent as the parameter in the IncomingSignal interaction. This interaction

is sent with a timestamp that reflects the time delay from emission to detection.

5. The IncomingSignal interaction is received by all federates managing acoustic

detector entities (the ActiveSonar, PassiveSonar and Scatterer federates). 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. If so, the response to the interaction depends on the

federate. If the destination is the ActiveSonar or PassiveSonar federates, the

federate updates the correct entities received signal. If the destination is the

Scatterer federate, the process returns to step 1 so as to model the reflection of

the acoustic signal.

The federation employs a scaled real time approach to time management. The

SimulationController federate requests time advances after a certain period of real

time has elapsed. Each time advance is fixed at an increment of one second. All other

federates will advance their local time conditional on the SimulationController

advancing its local time.

30

6 Federate Descriptions

6.1 Introduction

This chapter provides a description of the individual federates. The federates

involved in the Signal Propagation Federation are:

SimulationController

Propagation

ActiveSonar

PassiveSonar

NoiseSource

Scatterer

C2

6.2 SimulationController Federate

The SimulationController federate provides an interface through which a human

operator can control the federation. Control in this case refers to the dynamic

creation and deletion of object instances.

The SimulationController federate maintains information about object instances in

existence by subscribing to the Physical_Entity object class. The Physical_Entity

object class is the super class of the ActiveSonar, PassiveSonar, NoiseSource,

Scatterer and C2 object classes. By subscribing at the Physical_Entity level the

SimulationController federate is notified of all object instances created that are

subclasses of Physical_Entity.

The SimulationController is an event driven federate in that all functionality for

interacting with the federation derives from human input. The simulation loop is

therefore relatively sparse with most functionality being in the FederateAmbassador

callbacks.

31

The SimulationController federates publication and subscription interests are

presented in its Simulation Object Model located in Appendix H.

6.3 Propagation Federate

The Propagation federate performs the signal propagation modelling. In order to do

this, the federate needs to know the positions of all acoustic emitters and acoustic

detectors. The federate obtains this knowledge by subscribing to the

Emitter_Detector object class. By subscribing to this class, the Propagation federate

will discover all acoustic emitters and acoustic detectors created in the federation.

The Propagation federate models signal propagation by collaborating with the

ActiveSonar, PassiveSonar, NoiseSource and Scatterer federates through the

interactions RequestDirections, ProvideDirections, OutgoingSignals and

IncomingSignal.

The signal propagation model implements straight line propagation of signals only.

Transmission loss occurs through spherical spreading and the speed of sound is

assumed to be constant at 1500 ms-1.

The Propagation federate is an event driven federate in that its functionality comes

from reacting to the interactions sent by the acoustic emitter federates. This results in

most of the functionality of the federate residing in the federate ambassador

callbacks.

The Propagation federates publication and subscription interests are presented in its

Simulation Object Model located in Appendix G.

6.4 Active Sonar Federate

The ActiveSonar federate manages the active sonar object instances existing in the

federation. This management involves the dynamic creation and deletion of active

sonar object instances based on interactions sent by the SimulationController

federate (CreateActiveSonar, DeleteActiveSonar).

32

The ActiveSonar federates 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.

Each active sonar object instance has a member variable indicating the time for the

next emission. Once the ActiveSonar federates local time exceeds an object

instances time for next emission, the ActiveSonar begins the RequestDirections,

ProvideDirections, OutgoingSignals triumvirate of interactions required to emit a

signal. Once complete, the active sonar object instances time for next emission is

incremented by its pulse rate.

The ActiveSonar federate responds to the IncomingSignal interaction by updating the

appropriate active sonar object instances received signal.

Initially all active sonars will emit and receive acoustic signals omnidirectionally.

The ActiveSonar federates publication and subscription interests are presented in its

Simulation Object Model located in Appendix B.

6.5 Passive Sonar Federate

The PassiveSonar federate manages the passive sonar object instances existing in the

federation. This management involves the dynamic creation and deletion of passive

sonar object instances based on interactions sent by the SimulationController

federate (CreatePassiveSonar, DeletePassiveSonar).

The PassiveSonar federate is event driven. Its functionality stems from reacting to

the IncomingSignal interaction. The functionality is determining the received signal

strength and modifying the correct passive sonar instance accordingly. Initially all

passive sonars will receive acoustic signals omnidirectionally.

The PassiveSonar federates publication and subscription interests are presented in

its Simulation Object Model located in Appendix C.

33

6.6 Noise Source Federate

The NoiseSource federate manages the noise source object instances existing in the

federation. This management involves the dynamic creation and deletion of noise

source object instances based on interactions received from the SimulationController

federate (CreateNoiseSource, DeleteNoiseSource).

The functionality of the NoiseSource federate is very similar to that of the

ActiveSonar federate. The output from an acoustic noise source is continuous over

the time that it exists. To simulate this in the Signal Propagation Federation, noise

sources will have to radiate a signal at every time step. For this reason, there is no

need to maintain a time for next emission variable or a pulse rate. Initially noise

sources will exist for the duration of the federation execution.

The NoiseSource federates simulation loop will involve calling the interactions

RequestDirections, ProvideDirections and OutgoingSignals for every noise source

instance.

Initially all noise sources will radiate acoustic signals omnidirectionally.

The NoiseSource federates publication and subscription interests are presented in its

Simulation Object Model located in Appendix D.

6.7 Scatterer Federate

The Scatterer federate manages the scatterer object instances existing in the

federation. This management involves the dynamic creation and deletion of scatterer

object instances based on interactions sent by the SimulationController federate

(CreateScatterer, DeleteScatterer).

The Scatterer federate is an event driven federate. It responds to the IncomingSignal

interaction by modelling the reflected signal. The reflected signal is radiated using

the RequestDirections, ProvideDirections and OutgoingSignals interactions.

Initially the scatterers will receive and reflect sound omnidirectionally.

The Scatterer federates publication and subscription interests are presented in its

Simulation Object Model located in Appendix E.

34

6.8 C2 Federate

The C2 federate manages the C2 object instances existing in the federation. This

management involves the dynamic creation and deletion of C2 object instances based

on interactions sent by the SimulationController federate (CreateC2, DeleteC2).

A C2 object instance will allow for human control of the sonars within the

federation. Initially the strength, frequency and pulse rate of active sonars will be

modifiable. A C2 object instance will display the acoustic data received by the active

and passive sonars that it controls. A C2 object instance is associated with active and

passive sonars by having the same parent identifier11.

The C2 federates publication and subscription interests are presented in its

Simulation Object Model located in Appendix F.

7 Implementation Details

7.1 Introduction

This chapter describes some of the implementation issues that arose in the

development of the Signal Propagation Federation.

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. Bindings to the

libRTI do exist for CORBA, IDL and Java. Of the possibilities available, C++ offers

the most power for simulation programming. Although the models implemented in

the Signal Propagation Federation are very simple, it is intended to integrate much

more complex models at a later date. These models will almost certainly be

implemented in C++ (or C), so using C++ now will ease the integration process in

the future.

11 In the Virtual Ship Federation Object Model, a parent ID attribute is used to group component

entities into a conceptual composite entity.

35

The problem with using C++ is that any graphical user interfaces implemented will

use the windowing system of a specific platform. This limits the portability of the

code across multiple platforms.

The Java Swing API allows platform independent displays to be developed. Since the

displays are platform independent, it is possible to maintain a standard look and feel

across platforms. For these reasons, 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. The use of graphical user interfaces also facilitates the

inputting of data by not having to remember console commands.

7.2 Federate Implementation

There is a lot of commonality in the development of HLA federates. This stems from

the fact that all federates generally follow the same lifecycle. The following lists the

lifecycle of an HLA federate.

1. Create and join a federation

2. Publish and Subscribe Object Classes and Interaction Classes

3. Enable time management

4. Start the simulation loop

5. Perform simulation

6. Request time advances

7. Tick the RTI12

8. Unpublish and unsubscribe Object Classes and Interaction Classes

9. Resign from and destroy the federation.

12 Ticking the RTI refers to the federate code yielding time to the runtime infrastructure to allow it to

perform federate ambassador callbacks.

36

The federates developed for the Signal Propagation Federation were unique in that

they used Java displays. In order to instantiate Java classes, the Java Virtual Machine

must be running. This provides an altered federate lifecycle. The modifications are as

follows.

3a. Start the Java Virtual Machine

3b. Instantiate the Java display.

8a. Destroy the Java Virtual Machine.

This commonality saw the development of a base class GeneralFederate. The class

diagram for the GeneralFederate class is shown in Figure 11.

Using the operations presented in the class diagram, the federate lifecycle becomes.

1. The function CreateAndJoinFederation is used by the federate to attempt to create

the federation execution and then join the federate to it.

2. The functions used to publish and subscribe Object and Interaction Classes are

PublishObjectClasses, PublishInteractionClasses, SubscribeObjectClasses and

SubscribeInteractionClasses. These are pure virtual functions in the GeneralFederate

class and must be implemented by the subclass.

3. Time management can be enabled using the functions EnableTimeRegulation and

EnableTimeConstrained. These functions result in the federates local time being set.

3a. The Java Virtual Machine is started and initialized using the function

InitializeJVM.

3b. The functions RegisterNativeMethods and InitiateDisplay are specific to a

federate and hence are pure virtual functions in the GeneralFederate class. The

RegisterNativeMethods function is used to notify a Java class of the native functions

that are called from the display.

4. The simulation loop iterates until the member variable flag finished is set to true.

This usually occurs when the display is closed.

37

Logical View

GeneralFederate

+CreateAndJoinFederation()+ResignAndDestroyFederation()+PublishObjectClasses()+UnPublishObjectClasses()+SubscribeObjectClasses()+UnSubscribeObjectClasses()+PublishInteractionClasses()+UnPublishInteractionClasses()+SubscribeInteractionClasses()+UnSubscribeInteractionClasses()+EnableTimeRegulation()+EnableTimeConstrained()+RequestTimeAdvance()+Initialize()+InitializeJVM()+RegisterNativeMethods()+InitiateDisplay()+Simulate()+ProcessEventQueue()+AddEventToQueue(evObject : EventObject*)+DoTick()

#finished : Boolean#genFedAmb : GeneralFederateAmbassador*#rtiAmb : RTI::RTIambassador#env : JNIEnv*#jvm : JavaVM*#jobject : display#eventQueue : Queue*#currentTime : RTIfedTime#timeAdvancePending : RTI::Boolean

Figure 11 Class Diagram for GeneralFederate

5. Each federate will have simulation specific code to implement each time through

the simulation loop. This code will generally involve interacting with object

instances of the Object Classes defined in the FOM.

A federate event queue is processed at each iteration. This event queue is used to

cache events that have to be processed in the simulation loop of the federate. This

requirement stems from the fact that the RTI cannot process services when it is

performing federate ambassador callbacks. If RTIambassador services are called

38

from within federate ambassador code, a ConcurrentAccessException is thrown. The

solution developed involves the following.

When a federate ambassador callback requires an RTIambassador service call, the

service call information is bundled into an event object and placed on the event

queue using AddEventToQueue. The next time through the simulation loop the event

queue will be processed by calling ProcessEventQueue. ProcessEventQueue decodes

all event objects in the event queue and performs the necessary function calls.

6. At the completion of an iteration in the simulation loop, the federate requests a

time advance to a new time by calling RequestTimeAdvance. The federate then

enters a loop until a time advance is granted. This is indicated by the member

variable timeAdvancePending being set to false.

7. While the federate is waiting for a time advance, it should yield time to the RTI so

that the RTI can perform federate ambassador callbacks. This is done by calling the

function DoTick (yielding time to the RTI is referred to as ticking the RTI).

8. When the federate has finished operation (the member variable finished becomes

true) some tidying up needs to be performed. The functions UnPublishObjectClasses,

UnPublishInteractionClasses, UnSubscribeObjectClasses and

UnSubscribeInteractionClasses unpublish and unsubscribe any object or interaction

classes previously published or subscribed. These functions are federate specific and

are therefore declared as pure virtual functions in the GeneralFederate class.

8a. The Java Virtual Machine is destroyed through a call to DestroyJavaVM. This

function is part of the Java Invocation API.

9. Finally the federate resigns from the federation and attempts to destroy the

federation execution. This is accomplished by a call to ResignAndDestroyFederation.

The functions mentioned in points 8, 8a and 9 are called from the destructor of the

GeneralFederate class.

This discussion leads to the following code snippets.

39

The main function creates an instance of the federate and then calls its Simulate

method. The GeneralFederate constructor calls CreateAndJoinFederation.

void main()

{

SpecificFederate sf;

sf.Simulate( );

}

The function Simulate is declared as a pure virtual function in GeneralFederate. It is

in Simulate that a federate performs the functions discussed in points 2 7.

SpecificFederate::Simulate( )

{

Initialize( ); // calls the publish and subscribe methods

InitializeJVM();

RegisterNativeMethods();

InitiateDisplay();

// start simulation loop

while( !finished )

{

// check for input

// simulate

ProcessEventQueue()

RequestTimeAdvance( /* new time */ )

if( timeAdvancePending )

{

DoTick();

/* Calling ProcessEventQueue here enables events generated by the

previous call to DoTick( ) to be processed */

ProcessEventQueue();

}

}

}

The class hierarchies implemented for the Signal Propagation Federation are

presented in Appendix K.

40

7.3 Java Displays

Java was selected as the language for writing the federate GUIs. In particular, the

Java Swing API was used. 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. This allows for a common

look and feel to be maintained across different platforms.

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. There is no way of guaranteeing that the RTI is not being ticked when an

input event is handled.

The Java displays execute in a different thread of execution to the federate code. If

the input handler code were to use the federate event queue for caching the input, the

classic producer/consumer problem arises.

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. The federate code then receives inputs by polling the

input ready flag each time through its simulation loop. If it finds the input ready flag

is true, the federate analyses the input string and performs the functionality encoded

in the string.

At the time of writing only displays for the SimulationController and ActiveSonar

federates had been developed and integrated. However, the lessons learned from

developing these displays should allow for rapid development and integration of the

remaining displays.

41

8 Conclusions

The High Level Architecture is a very new framework in Australia, therefore, there is

little technical experience in using the HLA to draw on. The Virtual Ship task is the

largest project utilising the HLA being undertaken in Australia. Work on the Virtual

Ship has only just begun to look at the implementation details of federates. As a

result, this project represents one of the most complex applications of the HLA to be

implemented from scratch in Australia13.

The main outcomes of this project were

The establishment of a framework for modelling signal propagation in an HLA

enabled distributed simulation.

The establishment of some guidelines for the development of federates and

federations.

The establishment of guidelines for the implementation of Java GUIs with C++

simulation code.

A general increase in Australias level of technical expertise in developing HLA

federations.

Future work in this project will include

Analysing the performance of the approach established in this project.

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. The impact of using Java displays on performance

is another area to be explored.

13 There have been federations implemented that modify existing models to use the HLA and

integrating these models into a federation.

42

The approach adopted is not really suited to the case of noise sources radiating

acoustic energy. In this case, the acoustic signals are fairly persistent and may be

better represented as Object Classes.

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. A

new approach will have to be developed if real time modelling is necessary.

At some point more complex models will replace the basic models used in this

project. When this occurs the performance of the federation will be tested again.

The central propagation model concept will be integrated into the Virtual Ship at

a point in the future. This concept will be used for modelling acoustic signals,

electromagnetic signals and possibly communications (intra-ship, inter-ship, ship

to land via microwave or satellite, etc).

43

9 List of References

1. Best, J. P.: The Virtual Ship A New Capability in Support of Maritime Forces,

DSTO General Document 0198 (DSTO-GD-0198), 1999.

2. NATO Modelling & Simulation Master Plan,

http://www.dmso.mil/dmso/docslib/mspolicy/nato_msmp.

3. US DoD Modelling & Simulation Master Plan,

http://www.dmso.mil/dmso/docslib/mspolicy/msmp.

4. High Level Architecture, Rules, Version 1.3, US Department of Defence,

http://hla.dmso.mil/hla/tech/rules/.

5. High Level Architecture, Object Model Template Specification, Version 1.3, US

Department of Defence, http://hla.dmso.mil/hla/tech/omtspec/.

6. High Level Architecture, Interface Specification, Version 1.3, US Department of

Defence, http://hla.dmso.mil/hla/tech/ifspec/.

7. Coates, R.F.W.: Underwater Acoustic Systems, John Wiley & Sons, Inc., 1989.

8. Urick. R. J.: Principles of Underwater Sound, 2nd Edition, McGraw-Hill Book

Company, 1975.

44

Appendix

Virtual Ship.Introduction

The High Level Architecture (HLA).IntroductionThe RulesThe Object Model Template (OMT)Interface SpecificationDMSO Runtime Infrastructure (RTI)

AAcoustic Propagation in the Undersea EnvironmentIntroductionSonar Equations

Signal Propagation Application DescriptionDescriptionExample ScenarioOutcomesEntitiesIntrinsic BehavioursStatic RelationshipsInteractions

Scenario ExecutionTasksInitial ConditionsTermination Conditions

Federation DescriptionIntroductionFederation Execution

Federate DescriptionsIntroductionSimulationController FederatePropagation FederateActive Sonar FederatePassive Sonar FederateNoise Source FederateScatterer FederateC2 Federate

Implementation DetailsIntroductionFederate ImplementationJava Displays

CConclusionsLList of References

project_report.pdf

Documents

Transcript of project_report.pdf