A GENERAL APPROACH TO HIGH FIDELITY MODELING, SIMULATION

AND CONTROL OF TACTICAL ENTITIES AND IMPLEMENTATION IN A

COMMERCIAL COMPUTER GENERATED FORCES TOOLKIT

(a) (b) (c) (d) (e)

Deniz Aldogan , Mehmet Haklidir , Levent Hakkı Senyurek , Seniha Koksal , Omer Eroglu ,
(f) (g) (h) (i)
Cemil Akdemir , Semuel Franko , Isa Tasdelen , Sevgi Akgun

TUBITAK Marmara Research Center, Information Technologies Institute,

41470, Gebze-Kocaeli, TURKEY

(a) (b) c)
deniz.aldogan@bte.mam.gov.tr, mehmet.haklidir@bte.mam.gov.tr, levent.senyurek@bte.mam.gov.tr,
(d) (e) (f)
seniha.koksal@bte.mam.gov.tr, omer.eroglu@bte.mam.gov.tr, cemil.akdemir@bte.mam.gov.tr,
(g) (h) (i)
semuel.franko@bte.mam.gov.tr, isa.tasdelen@bte.mam.gov.tr, sevgi.akgün@bte.mam.gov.tr

ABSTRACT integration of simulators that execute on different

High-fidelity modelling for motion, response to
physical stimuli and attack behaviours along with
realistic control are vital requirements for training-
critical military simulations. In addition, whenever
simulation components are built on different
infrastructures, maintaining coordination becomes a
challenging problem. There are several COTS
frameworks that facilitate development of computer
generated forces (CGF), scenario management and
run control for distributed simulations. However,
they may not always afford to meet the
requirements of virtual military training simulation
systems. In this paper, we present modeling and
simulation of surface vessels, submarines and
rotary wing platforms with complex motion
equations, several sensors, weapons and fuzzy logic
controllers within a high-fidelity virtual military
training simulation. Modules and libraries for high-
fidelity entity simulation are integrated into
component architecture of a commercial CGF
simulation engine, namely VR-Forces. An original
control architecture, which is able to manage all
kinds of simulation components with different
infrastructures, has also been realized.
Keywords: Computer Generated Forces (CGF),
Military Training Simulation, HLA, RTI
1. INTRODUCTION
The requirement for building virtual military
training simulations can be mostly traced to the fact
that military field exercises are generally too costly
to be used generously for staff training on military
instruments. Such military simulations generally
utilize a distributed simulation infrastructure since
they mostly require reduced execution time,
geographical distribution, fault tolerance and
hardware platforms (Fujimoto 2000).
For training-critical military simulations, one
of the most crucial tasks that can be assigned to a
simulation component is the modelling and
simulation of army forces. In order to meet the
needs of high-fidelity military simulations, both
realistic models and realistic controls should be
employed for realizing the behaviour of computer
generated forces (CGF). Besides CGF capabilities,
tactical simulations mostly require a scenario
preparation application. Another equally important
necessity in such systems is the achievement of
cooperation betweeen simulators built on different
infrastructures in the simulation. This integration
may become challenging for the control
architecture of the system.gn
A COTS toolkit can be utilized for developing
a complex military distributed simulation in order
to save time and effort. Many commercial tools are
readily available for providing the fundamental
CGF and scenario management capabilities.
However, they may not provide a control
architecture that is able to manage simulators of
different infrastructures. In addition, they may not
satisfy the necessities of a complex military system
with high-fidelity platforms that exhibit advanced
dynamic behaviours and other capabilities such as
land or entity avoidance.
This study aims to provide an overall view of
an on-going simulation system, which embodies
commercial CGF toolkit-integrated simulation of a
wide range of high-fidelity platforms. These
platforms use complex motion equations and
realistic controllers in which land avoidance
behaviours are integrated into fuzzy controllers for
course keeping and speed control of entities.
The simulation system under study necessiates the
integration of commercial framework independent
simulation applications that are mainly responsible
for algorithmic behaviours. These simulators are
implemented by using an original infrastructure to
avoid the cost of using a commercial tool and to
maintain reusability. Therefore, a simulation that
embodies simulators using both a commercial
infrastucture and a different original infrastructure
is to be realized.
As a test application to be used for
implementing the CGF unit and a front-end unit,
which is responsible for supplying GUI, scenario
management and run control operations, belonging
to the system, VR-Forces has been chosen due to
the fact that it facilitates easy customization and
extension of its capabilities. VR-Forces is a flexible
software that is produced as a solution for military
simulation purposes. It uses RTI (Run-Time
Infrastructure) for providing communication and
coordination services to the simulation components.
Its simulation components are of two types: front-
end and back-end applications. The back-end
application is where the actual CGF simulation
takes place whereas the remote front-end GUI
controls the back-end(s) existing in the whole
simulation. VR-Link is an isolation layer which has
been developed for enabling VR-Forces based
applications to be used in DIS or HLA compliant
simulations. It keeps the user away from the burden
of architectural details (Figure 1). For better
understanding the reasons for the usage of HLA
compliant simulations and currently offered HLA
services, Duman et al. (2003) can be referred.
VR-Forces VR-Forces Back-
Front-end end
VR-Forces
GUI
VR-Forces
CGF Layer
VR-Forces
Remote
Control API
VR-Link
HLA/DIS
VR-Link Interface
HLA/DIS
Interface
RTI
Figure 1: VR-Forces Architecture
The GUI application provides features for
scenario management and simulation execution
control. As for the scenario management, it enables
choosing a battle field for the current tactical
scenario, addition, deletion and modification of
predefined platforms, task assignments and task
planning for the entities in the scenario. It also
achieves overall scenario run control by its
embedded remote control mechanism via sending
messages for starting, stopping, loading or saving
the scenario on the back-ends.
Back-end applications are responsible for
modelling and simulating the CGF, managing
property settings and task executions of entities
according to the user commands sent from GUI,
broadcasting each of the CGF component attributes
to the simulation, receiving the attributes of CGF
components on other simulation assemblies and
responding to the run control messages delivered
by the remote control on the GUI application. The
details about the inner workings of VR-Forces
architecture can be sought in VR-Forces
Developer’s Guide (2006) or “VR-Forces The
Complete Simulation Toolkit” article on the
website belonging to the company named “MAK
Technologies”. It should hereby be noted that the
entities simulated by VR-Forces have simple
motion equations with environmental parameters
that are not of appropriate fidelity to develop
realistic movement models.
The software modules for the motion models,
sensors, weapons and the fuzzy controllers
belonging to platforms have been implemented in
the C++ programming language and have been
integrated to the component architecture of VR-
Forces CGF application (VR-Forces back-end) as
composite objects.
The rest of the paper is divided into 5 sections.
In Section 2, integration of motion models into the
entities in the simulation system is given. Section 3
is dedicated to the implementation of fuzzy logic
controllers and maintenance of land avoidance.
Section 4 explains the addition of sensor and
weapon models to the entities. A control
architecture built from stratch to coordinate both
commercial toolkit dependent and independent
simulators is in Section 5. Finally, possible
extensions and conclusions are given in Section 6.
2. INTEGRATION OF HIGH-FIDELITY
MOTION MODELS INTO THE
SIMULATION SYSTEM
In this study, movement models that take into
account the environmental conditions (wave,
current, wind, season, day and night difference) and
hydrodynamic forces have been developed for
surface, submarine and rotary wing platforms each
with 6 degrees of freedom. The motion of all
platforms are considered in 6 degrees of freedom
since six independent coordinates are necessary to
calculate state information of a rigid body.
Modelling details such as coordinate frames,
motion equations, forces and moments acting on
each type of platforms as well as simulation results
are described in the following papers: the type of
platform under study is surface vessels in Haklidir,
Aldogan and Tasdelen (2008), rotary wing
platforms in Franko, Koksal and Haklidir (2009)
and submarines in Haklidir, Guven, Eroglu,
Aldogan and Tasdelen (2009). A software library is
implemented for the motion of each type of
platform to maintain modularity and reusability.
The integration of the software modules for
motion models into the back-end application, i.e.
the current CGF simulation engine, is realized by
the usage of VR-Forces component architecture.
VR-Forces back-end(s) simulate tactical object
behaviours by utilizing a component architecture.
According to this architecture, there are three
different types of components that an object may
possess: sensors, controllers and actuators. Sensors
help entities to gain information about their
surrounding environment. Controllers receive task
commands from GUI and direct the entity for the
completion of the assigned tasks. To illustrate,
when an entity is ordered to follow a given route
defined on the current scenario, the controller
specialized for this task may provide the rudder
angle or shaft r.p.m.(revolutions per minute) to the
actuator component, which actually performs the
entity motion by applying the relevant motion
models and updating the entity’s state information
such as position, speed, etc. according to the
outcomes of the models used. There are other
actuator types such as weapon or damage actuators.
An object may have several components of same or
different types. For an object, three component lists
are maintained, i.e. list of sensor components, etc.
The component manager belonging to the entity
ticks each of the components while preserving this
order: sensors, controllers and actuators.
In the military simulation system that is
introduced in this study, the movements of the
entities must be governed by high-fidelity motion
models. Each of these motion models have been
developed as VR-Forces independent software
modules. These modules are then integrated into
the VR-Forces component architecture. This is
achieved by following the steps explained below
for each different entity category, i.e. surface
vessels, submersible vessels and rotary-wing
entities:
• A new actuator class has been derived
from the original VR-Forces component
that is specific to the entity domain, i.e. an
actuator for surface vessels, etc.
• A software module that calculates the next
state of the entity given the current state
values and commanded task related
parameters has been implemented.
• The software module for realizing the
entity behaviour is defined as a member
variable to the corresponding actuator
class.
• The main loop of the actuator class is
overriden so that it updates the platform’s
state information such as position, speed,
etc. by utilizing the software module in
each simulation frame time.
Component Architecture
Surface Entity Motion Model Library
Controller Motion Actuator
Sensor State Repository
Figure 2: Integration of Surface Entity Specific
Motion Model Library into the VR-Forces
Component Architecture
Figure 2 displays the integration of a high-
fidelity model library, motion model library for
surface entities in this case, into the component
architecture of VR-Forces CGF application. The
data flow between the components has been
displayed as arrows. All the components in the
figure except from the model library have been
derived from original VR-Forces components to
adapt the model library.
3. INTEGRATION OF FUZZY
CONTROLLERS AND LAND AVOIDERS
FOR GUIDING THE ENTITY
Realistic control is a crucial necessity to simulate
entities of high-fidelity in military simulation
systems. In this study, commercial toolkit
independent controllers are used to simulate
quartermasters of the surface platforms. A flexible
fuzzy logic library (FLL) capable of simulating
human expert behavior has been implemented in
the C++ programming language. Fuzzy logic
controllers (FLC), which are in fact heading and
speed controllers that utilize FLL for their
calculations, are implemented in conjunction with
land avoidance calculations.
A multi-input-single-output (MISO) PD type
FLC for controlling the direction and a MISO PI
type FLC for controlling the speed of the surface
vessel have been produced. Big Bang – Big Crunch
(BB-BC) optimization algorithm, proposed by Erol
and Eksin (2006), has been utilized to sample some
reference course/speed values in the physically
allowable range and to find corresponding scaling
factors. The error between the desired and the
actual heading and speed values are used as
controller inputs along with their integrals and
derivatives. The inputs and the outputs are defined
by seven linguistic variables over the specified
range, namely, NL (negative large), NM (negative
medium), NS (negative small), Z (zero), PS
(positive small), PM (positive medium) and PL
(positive large). For input representation,
symmetric triangles have been used as membership
functions (MFs), whereas singleton membership
functions have been chosen for the output MFs.
The rule base for FLC consists of 49 rules, each of
which are displayed in Table 1. To illustrate, when
the input values are PS for ∆e and PS for e, the
output becomes a PM value.
Table 1. The Rule Base for Fuzzy Logic Heading
and Speed Contollers
∆e/e NL NM NS Z PS PM PL
PL Z PS PM PL PL PL PL
PM NS Z PS PM PL PL PL
PS NM NS Z PS PM PL PL
Z NL NM NS Z PS PM PL
NS NL NL NM NS Z PS PM
NM NL NL NL NM NS Z PS
NL NL NL NL NL NM NS Z
The implemented fuzzy logic controllers have
been compared with classical PD controllers even
in extreme cases. Results show that the designed
fuzzy logic controllers are superior to classical PD
controllers in all cases. A more detailed explanation
as well as simulation results for FLC’s can be
found in Senyurek et al. (2008).
Below, the integration of originally developed
FLCs into the component architecture of the
commercial toolkit, specifically into the task
controller component in the VR-Forces back-end
architecture, is explained by describing a sample
flow of control for the surface vessels.
When a task such as moving to a waypoint or
moving along a route has been commanded by the
user from GUI application, the entity’s task
controller, which is the VR-Forces component
responsible for adjusting the bearing and speed
parameters for the current task, receives a message
related to the assigned task through the VR-Forces
messaging interfaces. The obtained message
includes parameters related to the entity’s assigned
task. These parameters are mainly commanded
point/bearing, commanded speed and/or
commanded task duration. Ordered bearing value
with respect to the current commanded point is
calculated unless a commanded bearing value is
specified directly during task assignment. The
parameters are then transferred to FLCs, i.e rudder
and shaft controllers for the surface vessels, which
are owned by the entity’s commercial toolkit based
task controller component. In each simulation
frame, FLCs supply FLL with the error between the
desired bearing/speed and the actual heading/speed
values along with their integrals and derivatives. By
the way, heading refers to the direction that the
entity is headed, while bearing means the direction
that the entity ought to be headed.
The outcomes of FLL calculations are rudder
angle and shaft speed for the entity movement.
These values are stored to be used by the actuator
component. The actuator component takes these
values and feeds them to the motion module, which
is owned and managed by the actuator, to calculate
the entity’s next position. These steps are repeated
until the task is accomplished.
VR-Forces Front-end
User Task
Command
GUI
Task Controller
Motion Actuator
Shaft Controller Rudder Controller
FLL FLL
VR-Forces Back-end including CGF Engine
Figure 3. Integration FLLs into the VR-Forces Task
Controller Component
Figure 3 displays the integration of FLCs and
FLLs into the component architecture of VR-Forces
CGF application. The data flow between the
components has been displayed in the form of
arrows.
The task control process mentioned above
deviates from its normal flow whenever there are
land points within a certain range around the
entity. Then, a land avoidance vector can be
calculated for the surface entity. This vector is
calculated by using the points of land area on the
scenario map within a predefined proximity to the
entity. The direction from the gravity centre of the
relevant land points to the entity gives the direction
of the land avoidance vector for the current
simulation frame time. The magnitude of the
current land avoidance vector is proportional to the
distance from the entity to the calculated centre of
gravity. For now, a land avoidance vector for an
entity with an on-going task is calculated at each
simulation frame. Here, an optimization process is
vital so that land avoidance vectors are calculated
less often to relieve the resulting time complexity.
Land avoidance vectors are used to keep the
surface entity away from land areas. The x,y
components of the land vectors are combined with
ordered bearing and speed parameters of the task at
hand. The outcome is the new ordered bearing and
speed values that take into account the land
avoidance vectors.
In Figure 4, a sample gravity center G, the
corresponding land avoidance vector a and its
projection on the entity a’, the surface entity S, its
ordered bearing direction b and finally the
combined ordered bearing vector c are given.
Owing to the calculated land avoidance vector, the
entity is able to carry out the commanded task by
moving around the land points.
y G
a Maintaining coordination for scenario management
b components which are devoted to perform different
c responsibilities are built on different infrastructures
a' S in the same simulation. An original infrastructure in
x two main facts. Firstly, requirements for the
Figure 4. The Illustration for the Combination of a
Sample Land Avoidance Vector to the Entity’s
Ordered Bearing Vector
The flow of control explained above continues
by supplying the modified ordered bearing and
speed parameters to the FLL.
4. INTEGRATION OF SENSOR AND
TORPEDO LIBRARIES INTO THE
PLATFORMS
Sensor components of a platform provide models of
the simulated environment, which are then used by
the controller components to make decisions and
perform tasks.
Currently, there are three types of sensors that
an entity in our system may have. These are passive
sonar, active sonar and radar components.
Natural and traffic noises belonging to the
acoustic communication along with entity’s own
noises are produced by a noise generating
simulation component according to entity’s
propeller revolutions per minute (rpm). These data
are sent in the form of object updates via RTI to the
CGF simulation component. This component
possesses lists that maintain such remote objects.
Besides, there exists an acoustic transmission
simulation component that is responsible for
supplying the necessary transmissions in the form
of interaction messages for the sensor components
to work.
Each sensor model is implemented as a
software module. Developing every advanced
feature to be integrated into the entity behaviours as
commercial toolkit independent software modules
has been adopted throughout the realization of our
system to maintain modularity and reusability.
A VR-Forces component has been derived for
each sensor type. The corresponding sensor library
has been integrated into the component as a
composite object. This policy closely resembles the
method that is used to embed motion models and
fuzzy control.
5. CONTROL ARCHITECTURE FOR THE
INTEGRATION OF DIFFERENT
SIMULATION SYSTEMS
and simulation execution control behaviours
become a critical problem whenever simulation
addition to a commercial toolkit infrastructure,
namely VR-Forces, is used in the current
simulation system. The reason for this utilization of
an original infrastructure can be mostly traced to
simulation of algorithmic behaviours such as noise
generation or acoustic transmission are not fully
satisfied by the commercial toolkit at hand.
Moreover, increasing the licence costs of the
commercial toolkit can be avoided while
maintaining reusability.
Two different solutions for the problem of
integrating different simulation infrastructures can
be stated: modifying the remote control mechanism
of the commercial application(s) as displayed in
figure 4 or developing an original control
application from stratch, which is illustrated in
figure5. The second solution has been adopted in
the current study since it provides isolation from
the commercial framework, modularity and
reusability. The control architecture developed for
the current hybrid infrastructure is HLA and RPR-
FOM (Real-Time Platform-Level Reference
Federation Object Model) compliant. That means
communication between different simulation
components is performed by sending/receiving
messages that are in the form of object and
interaction classes that are defined in the file named
“Federation Object Model (FOM)” (Figure 5). Commercial Original Framework
If the whole simulation under study, i.e. all the Application
simulation components in the simulation, had been Framework Original Algorithmic
developed by using only VR-Forces infrastructure, Simulation Behaviour
the remote control ability on the VR-Forces GUI Control Simulation
Component Component
would be sufficient for run control. All of the
scenario and run control messages of VR-Forces
Original Original
remote control are sent by using the same
Infrastructure Infrastructure
interaction class, namely the Data Interaction,
defined in RPR-FOM. Owing to a VR-Forces
specific encoding/decoding layer, this interaction
is decoded on the receiving VR-Forces back-end. Derived
Adopting the same process for the VR-Forces RPR-FOM
independent simulation components in the current Message
RPR-FOM
system has two main disadvantages. In addition to
Message
the burden of integrating a VR-Forces dependent RPR-FOM
encryption layer to all the VR-Forces independent Message
simulation components, the denseness of messaging
traffic would be highly raised since all the
simulation components would receive all the
messages sent by the remote controller whether Figure 6. Display of Message Flow where an
they were relevant or not. This type of architecture Original Simulation Control Component is utilized
is illustrated in Figure 4.
As a solution, a new simulation component Upon receiving a derived interaction
built by the original infrastructure has been corresponding to a user command such as
assigned as the scenario and run control manager. “load/save scenario” or “start/stop simulation”, the
Therefore, the control of execution for the whole simulation controller sends the corresponding
simulation has been isolated from the VR-Forces standard RPR-FOM interaction messages to the
remote control mechanism. New interaction classes simulation components with the original
have been derived and used in the communication infrastructure. In this way, the execution of the
between the VR-Forces GUI and the new whole simulation is controlled.
simulation controller for receiving user commands.
6. EXPERIMENTAL RESULTS
6.1 Results on Surface Entities
Commercial Application Original Framework Surface platforms are tested in a scenario in which
Framework a surface platform makes four zig-zag maneuvers
of 45° with a velocity of 8 m/s. The route
VR- Algorithmic Behaviour information regarding this task is inputted by
Forces Simulation Component
defining four waypoints as shown on the VR-
GUI VR-
Forces Forces graphical user interface (Figure 7).
Modified CGF
Remote
Control
API Original VR-
RTI Forces
VR-Link VR-Link Layer Encoding
HLA/DIS HLA/DIS Decoding
Interface Interface Layer

RPR-FOM
Message
RPR-FOM
Message

Figure 7. The Route Defined for the Platform

Figure 5. Display of Message Flow on the System
Developed by Modification of VR-Forces Remote The results below have been produced after
Control API running the simulation for 800 seconds.
 to the first point. The first loop is accomplished in
approximately 295 seconds. The results are
acceptable for the movement behaviors that are
supposed to be realized by a large platform and
satisfactory in terms of simulation. Detailed
discussion for simulation results can be obtained
from the study Haklidir, Aldogan and Tasdelen
(2008).

6.2 Results on Submarine Entities

6.2.1 Route Tracking
In this application, it is aimed to realize the
submarine tracking on a non – equilateral pentagon
route with 10 m/s cruise speed. Route information
is defined via VR-Forces graphical user interface
(a) which can be seen by the red lines in Figure 9. The
blue symbol to the left of the red route points refers
to the submarine entity.

(b)
Figure 9. Display of the Route Defined by Red
Points (and lines in between) on the VR Forces
Graphical User Interface.

Simulation time is set to 800 seconds and the

following results are obtained. In the light of the
below results, it is clearly said that the model
follows desired route successfully and the
simulation results are satisfactory. (Figure 10).

(c)

Figure 8. (a) Change of Location for the Surface

Platform (b) Change of Velocity for the Surface
Platform (c) Changes in the Yaw Angle and Rudder
Angle of the Surface Platform

In this application, which is known as the zig

zag test of Kempf in the literature (Kempf 1932),
the initial speed of the platform has been given as
0. The platform is ordered to move to the specified
waypoints one by one by increasing its velocity up (a)
to 8 m/s. It takes the platform 96 seconds to reach
 (b)
Figure 10. (a) Submarine Route Tracking (b)
Submarine Yaw and Rudder angles
6.2.2 Depth Control
To analyze the effectiveness of the submarine depth
controller, firstly, the submarine entity is ordered to
accomplish the following task. With a cruise speed
of 10 knot (5 m/s), it initially dives to periscope
level (14 m) and then down to 50 m. Simulation
results are summarized as depth values and rudder
angle differences (Figure 11 and 12 respectively).
Figure 11. Submarine Depth Tracking
In this simulation, the submarine which hovers
at 2.5 m dives to desired depths (14 m and then 50
m) in 42 seconds and 120 seconds respectively.
Simulation results are acceptable according to
dynamics of a submarine and they are satisfactory
with respect to simulation performance, as well.
Besides, the control signals are on an admissible
level for realization. Detailed discussion for
simulation results can be obtained from the study
Haklidir et al. (2009).
Figure 12. Submarine Bow and Stern Rudder
Angles
6.3 Results on Rotary Wing Entities
For testing the controllers’ performance, the
following scenarios were formed. In the first
scenario, the user orders the helicopter to move to
four waypoints one after another. In the latter one, a
route has been established and the entity has been
commanded to move along this route.
6.3.1 Movement Through Waypoints
For testing the controller, a scenario that contains a
waypoint has been formed. Initial point is set as [x
z y] = [0 0 0] meters. Commanded composite
velocity (of u and v) is 20 m/sec. Four waypoints
were selected as follows:
• Waypoint 1= [2000 -300 -1500]
• Waypoint 2= [4000 -300 -1500]
• Waypoint 3= [2000 -300 0]
• Waypoint 4= [0 -300 0]
In the figure below, the small circles on the
cornes of the quadrilateral indicate the waypoints,
while lines that denote the edges es show the actual
trajectory of the helicopter.
Figures 13: 2D View of Rotary Wing Entity Motion
through Waypoints

Figures 14: View of Rotary Wing Entity Motion
through Waypoints in VR-Forces GUI
6.3.2 Movement Along Route
Initial point is set as [x z y] = [0 0 0] meters. A
route consists of seven points was selected as
follows:
• Point 1= [-1282482 0 1055818]
• Point 2= [-1271867 0 1059178]
• Point 3= [-1251208 0 1077556]
• Point 4= [-1250465 0 1107525]
• Point 5= [-1288555 0 1111868]
• Point 6= [-1289796 0 1082805]
• Point 7= [-1272898 0 1062745]
Composite velocity was the same with that of
the previous scenario. The result of the simulation
can be observed in the following figure. Detailed
discussion for simulation results can be obtained
from the study Franko, Koksal and Haklidir
(2009).
Figures 15: 2D View of Motion through Route
Figures 16: View of Motion through Route in VR-
Forces
6.3 Fuzzy Library Simulation Results
Figure 17 and Figure 18 show the change of the
heading of the ship with respect to time for two
extreme cases. The Fuzzy Logic heading controller
is compared with manually tuned PD controller in
which classical Ziegler-Nichols method is utilized
as a starting parameter set. In both cases, the initial
heading angle is considered as zero. In the first case
(Figure 17), the initial shaft speed of the vessel is at
maximum level (240 rpm) and the ship is forced to
a 5° (small) rotation, while in the second case the
initial shaft speed is 70 rpm (resulting a slow speed
value of about 5 knots) and the desired rotation is
180° (maximum possible change). The result
obtained by the Fuzzy controller is represented by
solid lines, while the dashed lines are the results of
the classical PD controller.
7
6
4
heading angle/[°]
-1
0 50 100 150 200 250 300 350 400 450 500
time/[sec]
Figure 17. Change of Heading of the Ship in time,
Controlled by a Fuzzy Logic and a Classical PD
Controller (dashed line) in a High Speed - Small
Rotation Case
 200
150
heading angle/[°]
100
50
0
-50
0 100 200 300 400
time/[sec]
Figure 18. Change of Heading of the Ship in time,
Controlled by a Fuzzy Logic and a Classical PD
Controller (dashed line) in a Low Speed - Large
Rotation Case
Results show that in both extreme cases, the
designed fuzzy logic rotation controller is superior
to classical PD control even in auto steering only.
So it actually seems to be a good choice to use
fuzzy logic for simulating quartermaster behavior,
since FLC’s are also superior for designing expert
systems to simulate human operators.
Results also approve our choice of using two
MISO fuzzy controllers for controlling speed and
heading distinctly. Change in speed doesn’t have a
considerable effect on heading control. Detailed
discussion for simulation results can be obtained
from the study Senyurek et al. (2008).
7. CONCLUSIONS
This paper introduces an on-going study on a
virtual military training system which uses high
fidelity motion models ranging from 4 to 6 degrees
of freedom, several sensor models, a torpedo model
and fuzzy logic controllers that mimic captain
control strategies for realizing behaviours of
entities. The whole design is integrated into the
component architecture of VR-Forces, which
provides a framework for developing Computer
Generated Forces (CGF) applications. In addition,
commercial toolkit independent simulation
components that specialize on algorithmic
behaviours are integrated into the commercial
toolkit based CGF and GUI applications via
developing an original control architecture. The
overall integration has led the surface, submarine
and rotary-wing platforms of the VR-Forces
application to reach a high-fidelity level that is
necessary for training-critical military simulations.
REFERENCES
Duman, I., Savaşan, H., Şahin, I., 2003. Bir
Modelleme ve Simülasyon Standardı olarak
HLA ve Simülasyon Uygulamalarında
Kullanımı, (In Turkish), Turkish Navy
Research Center Command Publications.
Erol, O. K., Eksin, I., 2006. A new optimization
www.method: Big Bang–Big Crunch,
Advances in Engineering Software, 37, 106–
111.
Franko, S., Koksal, S., Haklidir, M., 2009.
Modeling, Simulation And Control Of Rotary
Wing Platforms In A Computer Generated
Forces Toolkit, The Industrial Simulation
Conference ISC 2009, Loughborough, United
Kingdom, 1-3 June 2009
Fujimoto, R. M., 2000. Parallel and Distributed
Simulation Systems, Wiley Series on Parallel
500 600 700 800 900 1000 and Distributed Computing, pp. 4-5.
Haklidir, M., Aldogan, D., Tasdelen, I., 2008. High
Fidelity Modeling and Simulation of Surface
Platforms in a Computer Generated Forces
Toolkit, SUMMERSIM 2008, Edinburgh,
Scotland.
Haklidir, M., Guven, A. F., Eroglu, O., Aldogan,
D., Tasdelen, I., 2009. High Fidelity Modeling
and Simulation of Submarine in a Commercial
Computer Generated Forces Toolkit, The
Society for Modeling & Simulation
International [SCS] 2009 Summer Computer
Simulation Conference (SCSC'09), Istanbul,
Turkey, 13-16 July 2009.
Kempf, G., 1932. Measurements of the Propulsive
and Structural Characteristics of Ships,
Transactions of SNAME, 40, pp. 42-57.
Senyurek, L., Koksal, S., Genc, H.M., Aldogan, D.,
Haklidir, M., 2008. Implementation Of Fuzzy
Control For Surface Platforms In A Computer
Generated Forces Toolkit, International
Conference on Computational Intelligence for
Modelling, Control and Automation
(CIMCA08), Vienna, Austria, 10-12
December.
VR-Forces Developer’s Guide, MAK
Technologies, 2006. Chapter 2, The VR-
Forces Simulation Engine, Chapter 5,
Creating New Components, Chapter 10, The
VR-Forces Remote Control API.
VR-Forces The Complete Simulation Toolkit. MAK
Technologies. Available from
http://www.mak.com/products/vrforces.php
[accessed 21 June 2009]