DESIGN OF A NAVAL SURFACE TACTICAL MANEUVERING SIMULATION SYSTEM (NSTMSS)∗ Okan Topcu and Halit Oguztuzun Department of Computer Engineering Middle East Technical University 06531 Ankara, Turkey e-mail:
[email protected],
[email protected] Keywords: High Simulation, Naval Environment
Level Architecture, Interactive Simulation, Networked Virtual
ABSTRACT This paper introduces a Distributed Interactive Simulation (DIS) application called “Naval Surface Tactical Maneuvering Simulation System (NSTMSS)” and describes its architecture. NSTMSS serves as a Networked Virtual Environment (NVE) testbed for naval surface actions in which new tactics, operations and formations can be evaluated as well as the present ones can be analyzed. NSTMSS is being developed by using the concepts of High Level Architecture (HLA), which provides a structural basis for interoperability and reusability. NSTMSS uses Runtime Infrastructure (RTI) functions for data communication and object exchange mechanism; OpenGL Optimizer/Cosmo3D for 2D and 3D graphical interfaces and virtual environment. 1.
INTRODUCTION
1.1 Motivation Shiphandling, coupled with understanding of the forces which act on one’s vessel, is a skill which all naval watch officers must develop. A junior bridge officer can train in a stand-alone, high-fidelity, full scale ship simulator with the goal of developing shiphandling skills. On the other hand, many tasks in real world are accomplished by a team, especially in a naval surface operation, which is carried out by the participation of many ships; therefore team training is very important. Monolithic simulations can not provide the full benefits of team training. To gain the full benefits of team training in a virtual environment, several users from different levels must participate in the virtual environment. For example, in Turkish Navy, there are ‘platform level training
simulations’ like ship driving simulators and ‘tactical level training simulations’ like naval surface warfare simulations; however, these are used in separation. The primary objective of NSTMSS is to link these two simulations to create a realistic virtual environment for the simulation of highly interactive naval surface operations. NSTMSS primarily aims at combining platform and tactical level simulations to form a distributed, man-in-the-loop, interactive simulation, as well as providing reusability and interoperability. NSTMSS is based on HLA to achieve these goals. Interoperability and reusability are two key issues for the military and civilian Modeling and Simulation (M&S) Community. In this regard, the HLA as the newest technology for distributed simulation-based systems is considered a big step forward (Klein et al.1998). The design and execution of a networked virtual environment are challenging tasks made even more difficult by the fact that DIS applications are becoming more complex and difficult to manage. In an HLA environment this includes the Federation Development Process (FEDEP). In a distributed environment a federate not only computes its own behaviors and publishes them to the network, but it also accurately represents all other federation entities participating in the simulation (Watsen et al 1997). HLA provides the network communication capabilities via the services of RTI. All the functionality of the recently proposed HLA and its components (RTI, rules and Object Model Template OMT) are being tested by the development of NSTMSS (DMSO 1998c, DMSO 1998d, DMSO 1998e). 1.2 Problem Definition In a surface operation, the Surface Task Group (STG), which is composed of surface ships (e.g. frigates, destroyers) to achieve a specific task and commanded by the Officer in Tactical Command (OTC) (also called STG Commander (STGC) or Commodore), should operate in
* This work has been partially supported by Middle East Technical University grant AFP-97-07-04-01
Formations according to the maneuvering and formation rules given in the Tactical Publications. OTC gives an order to form one of these formations in accordance to Operation Phase and the Officer Of the Decks (OODs) of ships must adjust their ship’s course and speed to take the appropriate position and to construct the ordered formation as well as keeping their positions in a formation, which is known as Formation Steaming. All OODs, their first duty, should know the formation and maneuvering rules. Officer Scheduling the Exercise (OSE) will give the task and the operation details to STGC. 1.3 Objectives NSTMSS, which will be a Distributed Interactive Simulation (DIS) application, should provide a training platform for the Officer Of the Decks (OODs) and Junior Officer Of the Decks (JOODs) to carry out tactical maneuvering exercises and the OTC to develop tactical picture and leadership. The System will also create an environment for naval surface actions in which new tactics, operations and formations can be tested and evaluated as well as the present ones can be analyzed. 2.
NSTMSS ARCHITECTURE
The overall intention is to bring heterogeneous federates from different simulation domains together to form a distributed naval simulation within a virtual environment.
2.1 Software Architecture Software components are classified into four groups: ♦ RTI provided Processes ♦ Simulation Entity Processes/Federates ♦ Environment Generation Processes/Federates ♦ Federation Management Processes/Federates There are two different kinds of federates in Simulation Entity Group. The ships are brought into federation by the KNOX Federates (KNOXFd’s) which are platform level simulations allowing a person to steer the ship in real-time. The other federate is OTC Federate (OTCFd) which is a tactical level simulation allowing the user to control the surface task group, which is composed of the ships in the virtual environment. Federation Management Federates are the OSE Federate (OSEFd) and the Federation Monitor Federate (FEDMONFd). They provide functions for controlling and monitoring the federation activity as well as distributing roles and scenarios to players. There is one federate in Environment Generation Group, called Environment Generation Federate (EnviFd), which generates the virtual environment data for the other federates to render the virtual environment. EnviFd also manages GIS server-federation communications. All these processes together make up a NSTMSS federation. Figure-1 graphically depicts the software components of NSTMSS and their processes.
Figure-1 Architectural Overview of NSTMSS
2.1.1 RTI provided Processes Runtime Infrastructure provides inter-object communication between processes. a. RTIexec: RtiExec (RTI Executive) is a global process. Each federate communicates with RtiExec to initialize RTI components. The RtiExec’s primary purpose is to manage the creation and destruction of FedExecs. The RtiExec directs joining federates to the appropriate federation execution. RtiExec also provides a naming service for federation executives and ensures that each FedExec has a unique name (DMSO 1998a). b. FEDexec: Each FedExec (Federation executive) manages a Federation. It allows federates to join and to resign, and facilitates data exchange between participating federates. A FedExec process is created by the first federate to successfully invoke the “Create Federation Execution” service for a given Federation Execution name. FedExec assigns a unique handle to each federate joining the federation (DMSO 1998a).
♦
ahead, right and left sectors of the ship, can control the helm and the engine order telegraph (EOT), can use GPS (Global Positioning System) monitor and navigation radar and can look at the navigation charts. An HLA compliant, reusable library, both behavioral and graphical. This library is consisted of simulation object models (SOMs) of these modules.
2.1.2 Simulation Entity Processes and User Interface Processes Each simulation entity, which could also be thought as a Bamboo module [Watsen et al 1997], has two major components: ♦ The entity’s polygonal representation (User Interface part) ♦ Its behavior (behavioral model of object ) KNOX Federate (KNOXFd): KNOXFd implements a three-dimensional shiphandling simulator of Knox Class Frigates with a single user interface. The Officer Of the Deck can adjust the ship’s course and speed through the use of rudder and engine controls. Many KNOX frigates can join into virtual environment. When designing the single graphical user interface (sGUI), the conning officer’s viewing position is attached to one of four possible locations on the ship model: the center of pilot house, the right bridge, the left bridge, and the astern of the ship. Movement between these positions is accomplished through inputs from the Command Toolbar Interface (CTI). Internal structure of a KNOX federate is depicted in the Figure-2. The two module repositories called ‘Model Modules Repository’ and ‘ User Interface Module Repository’ are being developed to provide: ♦ Functions to allow the user of the ship, OOD, to control the ship. OOD can see 3D views of back,
Figure-2 KNOX Federate Modular Structure The module repositories of the federate are plug-ins to each other. The user interface modules are just models that interact with the user, they have no functionality. The functionality is being achieved by the corresponding behavioral models. For example, GPS_UI, the user interface of the GPS, must know the position and velocity of the ship to be able to display the values of these. While UI modules are being created, they are attached to corresponding behavioral models. Otherwise, they can not be created. Therefore, a one-way communication channel, through user interface modules to behavioral modules is being established. A well-defined interface is formed to achieve the communication. Thus, the UI modules know which behavioral model’s interface they are. For example, while GPS_UI is being created, it knows that a GPS behavioral model exists and it is attached to that model, therefore it knows where it will get the values of velocity and position of the ship to display them.
A class interface is being depicted in Figure 3, using small circles connected with a line to the class in UML notation.
Figure-3 Repository Connections By separating the modules, we increase the reusability. For example, a new one can easily write a new GPS interface without knowing the internal structure of the ship and federate programmer can select one of two GPS interfaces. Tracking Sub-System (TSS) is a module which ♦ Implements the collision detection algorithms. These algorithms provide the detection of vehicle-vehicle and vehicle-non vehicle collisions. ♦ Implements the Dead Reckoning algorithm using the “players and ghosts” paradigm (Grossweiler et al.1994] and provides the dead reckoning data (position, speed, course) from other federates to the modules inside the repositories. Message center and message dispatcher modules are being designed to give the ability to OOD to send and receive tactical messages. Message center module generates and displays the messages that will be sent or received, while message dispatcher module checks the receiver addresses for incoming messages. If the message sent is being addressed to local ship, than message dispatcher accepts the message and warns message center. HydroShip module is responsible from the movement of the ship. This module implements the hydrodynamic equations of the movement of the ship. It dynamically calculates the velocity and the heading of the ship in real time. RTILib is consisted of two classes: ♦ RTI Ambassador: Federate-initiated services are invoked as an instance of RTIAmbassador. For example, when the ship is changed her course, then the KNOXFd can inform other federates by using RTI Ambassador services. ♦ Knox Federate Ambassador (KNOXFd Ambassador): RTI-initiated services are invoked as an instance of federate ambassador. The Federation (via RTIlib) responds asynchronously to federate requests. Federate Ambassador “callback” functions provide a mechanism for the Federation to “signal” the
federate. For Example, when an object is being updated by other remote federates, this update is being reflected by KNOXFd Ambassador to the local federate. OTC Federate (OTCFd): OTC Federate is designed to model formations and maneuvers at the Tactical Level (map-view). It provides bird’s eye view of all the warships and the operational area. OTCFd provides interfaces to user OTC to control and order the formations of ships to achieve a given duty. OTCFd uses an event-oriented time advancement approach and relies on strict causality. Internal Structure of OTC Federate is depicted at the Figure 4:
Figure-4 OTC Federate Modular Structure Tactical Message System (TMS) Module deals with all the communication messages between the commodore (OTC) and captains (OODs). TMS describes the message formats, defines the senders and receivers. TMS handles three message types: weather reports, task orders and formation messages. TSS module of OTCFd is the same with KNOXFd TSS module. 2.1.3 Federation Management Processes Scenario Monitor Federate/OSE Federate (OSEFd): Scenario Monitor simulates the Officer Scheduling the Exercise (OSE), therefore it is also called OSE federate (OSEFd). This module organizes the entities. Figure 5 depicts the modular structure of OSEFd. Scenario Chooser Module selects a scenario from ‘Scenario Database’. Casting Module distributes the scenario and the roles to the other simulation entities in the distributed environment and Data Collector Module accomplishes the collection of critical performance data (CPD) by filtering.
All interfaces are method calls on objects. Federateinitiated services are invoked on an instance of RTIambassador. The abstract class Scenario Manager Ambassador implements the callback functions of RTI by providing methods that the RTI calls during the OSEFd’s tick period. During the tick where the RTI is making calls to the OSEFd’s Ambassador, the OSEFd directs updates and interactions to its database, queues the Ids of newly discovered objects and the objects that have left the federation.
up to date) is being used. This is the minimal configuration to demonstrate the system. Figure 6 graphically depicts the experimental system configuration and describes the specific type of platforms of each of the federates in the system. Bracketed items in the figure indicate other components hosted on a particular platform in various setups for execution.
Figure-5 Modular Structure of OSEFd
Figure-6 Experimental System configuration
Data Collector Module design has been aimed at rapidly providing a baseline capability for logging a federation. Data Collector collects critical performance data for after-action review of the exercise. Federation Monitor Federate (FEDMONFd): FEDMONFd mainly monitors the network and collects network-related data. It uses all the functionality of Management Object Model (MOM) which identifies objects and interactions used to manage a federation. Rationale for Federation Monitor Federate: ♦ To analyze the performance of dead reckoning algorithms. Dead reckoning algorithms have some critical parameters, such as threshold and heartbeat rate, which should be fine-tuned to reduce overhead without incurring significant loss in precision. ♦ To identify the bottlenecks of the system, by monitoring the network load, network delay, lost messages etc. 2.2 Hardware Architecture /Experimental System Configuration Ship Federates and OTC Federate are C++ applications using the OpenGL Optimizer/Cosmo3D on SGI workstations. DMSO RTI1.3 release 6 (latest release
3. DEVELOPMENT METHODOLOGY The Federation Development and Execution Process (FEDEP) is used. The FEDEP describes the activities involved in HLA federate and federation development and execution (DMSO 1998b). The FEDEP does not specify a single way of constructing and executing an HLA federation, but rather identifies the key steps in federation development and execution (Scrudder et al.1998). It is based on ‘Waterfall with Feedback Paradigm ’, so it relies on a well-scoped sequence of phases. Reusability is based on Federation Object Models (FOMs) and Simulation Object Models (SOMs), which are prototypes of simulation classes and interactions. NSTMSS is being developed in a full Object-Oriented Approach. The analysis and design notation is Unified Modeling Language (UML 1.1)(Muller 1997). 4. CONCLUSION NSTMSS is a completely HLA based application which tests the functionality of HLA. It also provides a testbed for fine tuning RTI and its management service parameters. NSTMSS will also be a test bed to analyze the efficiency of dead reckoning algorithms. An HLA compliant reusable object library for naval simulations is being constructed in the course of developing NSTMSS.
Work is continuing on the development of NSTMSS. After the first release of NSTMSS, we plan to focus on these aspects: ♦ To gather data for evaluating HLA and RTI efficiency by using NSTMSS. ♦ To add “ Tactical Voice Message Interface “, a speech recognition system, to NSTMSS for the internal communication of surface task group. ♦ To add the models of air and surface radars and interfaces to NSTMSS. ♦ To add Local Meteorology Station Federate to NSTMSS and corresponding environmental effects. ♦ To develop a FEDEP implementation methodology based on iterative development. REFERENCES Defense Modeling and Simulation Office, 1998(a) “High Level Architecture Run-time Infrastructure Programmer’s Guide v1.3r4”Oct. Defense Modeling and Simulation Office, 1998(b) “HLA Federation Development and Execution Process (FEDEP) Model, Version 1.2 Draft”26 May. Defense Modeling and Simulation Office, 1998(c) “HLA Interface Specification, Version 1.3” 20 April. Defense Modeling and Simulation Office, 1998(d) “HLA Rules, Version 1.0” 5 February. Defense Modeling and Simulation Office, 1998(e) “HLA Object Model Template, Version 1.3” 5 February. Grossweiler R., Laferriere R., Keller M.L., Pausch R. 1994; “An Introductory Tutorial For Developing MultiUser Virtual Environments”, Presence, December,3: 4,pp.255-264. Muller Pierre-Alain 1997; ”Instant UML”, Wrox Press Ltd. Klein U, Schube t., Strasburger S.1998; ”Distributed Traffic Simulation Based On the HLA” Simulation interoperability Workshop. IST, Fall (98F-SIW-016). Scrudder R., Lutz R., Dahmann J.1998;”Automation of the HLA federation development and execution process.”; Fall Simulation Interoperability Workshop.IST. Watsen K., Liles S., Zyda M. 1997;” Dynamic Discovery of Simulation Entities using Bamboo and HLA”; Spring
Interoperability Workshop, IST, Orlando, FL, March 1997.
Author Biographies: Lieutenant Okan Topcu is a navy officer in Turkish Navy and He is pursuing a M.S. degree in Computer Engineering from Middle East Technical University, Ankara, Turkey. Topcu graduated from Turkish Naval Academy in 1993 in Computer Engineering Department. After graduation, He has spent the next 4 years in the navy as comms officer and XO. His last assignment was in the Naval Training Command as project officer in Research Department. Halit Oguztuzun is an assistant professor in the Depatment of Computer Engineering of the Middle East Technical University, Ankara, Turkey. He received B.S. and M.S. degrees in Computer Engineering from METU in 1982 and 1984, and PhD in Computer Science from the University of Iowa, Iowa City, IA in 1991. He is the manager of the recently established Modeling and Simulation Laboratory at METU.
