Date post: | 14-Sep-2015 |
Category: |
Documents |
Upload: | nguyen-thao |
View: | 218 times |
Download: | 0 times |
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.
Acoustic signal data
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.
Acoustic signal data
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 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.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