development of a high level architecture federation of ...development of a high level architecture...

Defence R&D Canada – Atlantic

DEFENCE DÉFENSE&

Development of a High Level Architecture

Federation of Ship Replenishment at Sea -

Initial Prototype

Dan BleichmanCogSim Technologies

R.G. LangloisR.G. Langlois Engineering Analysis

Murray GambleCogSim Technologies

Dave BrennanMartec Limited

Martec LimitedSuite 400, 1888 Brunswick St.Halifax, Nova Scotia B3J 3J8

Contract Number: W7707-063647/001/HAL

Contract Scientific Authority: Dr. Kevin McTaggart, 902-426-3100 ext 253

Contract Report

DRDC Atlantic CR 2007-222

August 2007

Copy No. _____

Defence Research andDevelopment Canada

Recherche et développementpour la défense Canada

This page intentionally left blank.

Development of a High Level Architecture Federation of Ship Replenishment at Sea - Initial Prototype

Dan Bleichman

CogSim Technologies

R.G. Langlois

R.G. Langlois Engineering Analysis

Murray Gamble

CogSim Technologies

Dave Brennan

Martec Limited

Contract Number: W7707-063647/001/HAL

Contract Scientific Authority: Dr. Kevin McTaggart, 902-426-3100 ext 253

Defence R&D Canada – Atlantic

Contract Report


August 2007

Scientific Authority

Kevin McTaggart

Approved by

Neil Pegg

Head/Warship Performance

Approved for release by

James L. Kennedy

Chair/Document Review Panel

Terms of release: The scientific or technical validity of this Contract Report is entirely the responsibility of the contractor and the contents do not necessarily have the approval or endorsement of Defence R&D Canada.

© Her Majesty the Queen as represented by the Minister of National Defence, 2007

© Sa majesté la reine, représentée par le ministre de la Défense nationale, 2007

Original signed by Kevin McTaggart

Original signed by Neil Pegg

Original signed by James L. Kennedy

DRDC Atlantic CR 2007-222 i

Abstract In order to carry out the Navy's mission effectively, fleet units must be capable of remaining at sea for prolonged periods of time, possibly in areas of the world where friendly re-supply ports are not available, and remain fully ready to carry out any assigned tasks. Supply ships are equipped to replenish combatants underway with fuel, ammunition, provisions, and spare parts. The Canadian Department of National Defence is looking to use a simulation infrastructure called the High Level Architecture (HLA) to provide integrated, joint simulation environments for the development of tactics and doctrine as well as for training and systems acquisition. In order to support this effort, the Warship Performance Section at DRDC Atlantic has initiated a research and development effort aimed at producing a simulation of ship replenishment at sea. The objective of the proposed technical solution described in this report is to provide a simulation environment that models the interactions between the various components in order to simulate conditions that lead to the adverse events of payload immersion and RAS gear breakage. This report covers progress made during the first of three project phases.

Résumé Pour être en mesure de remplir leurs missions efficacement, les unités de la flotte doivent pouvoir garder la mer pendant des périodes prolongées, parfois dans des parties du monde où il n’y a pas de ports de rapprovisionnement amis, et être prêtes en tout temps à exécuter les tâches qui leur sont assignées. Les navires de ravitaillement sont spécialement conçus et équipés pour ravitailler en mer les navires combattants en carburant, en munitions, en provisions et en pièces de rechange. Le ministère de la Défense nationale du Canada envisage d’utiliser une infrastructure de simulation appelée « architecture évoluée » pour concevoir des environnements de simulation conjoints intégrés pour l’aider à développer ses tactiques et sa doctrine et se doter de nouveaux outils d’instruction et d’acquisition de systèmes. Pour être en mesure de soutenir cet effort, la Section de l'évaluation de la performance des navires de combats de RDDC Atlantique a mis sur pied un programme de recherche et de développement qui vise à créer un programme qui simule le ravitaillement en mer (REM) des navires. L’objectif du projet de solution technique décrit dans le présent rapport est de doter les FC d’un environnement de simulation qui modélise l’interaction entre les divers éléments en jeu afin de simuler les conditions qui peuvent provoquer certains événements indésirables comme l’immersion de la charge utile et le bris du matériel de REM. Le présent rapport décrit les progrès faits au cours de la première des trois phases du projet.

ii DRDC Atlantic CR 2007-222


DRDC Atlantic CR 2007-222 iii

Executive summary

Introduction Defence R&D Canada – Atlantic is developing a capability for distributed simulation of naval platforms using the High Level Architecture (HLA). A simulation of ship replenishment at sea (RAS) is being developed as an initial federation to demonstrate this capability. The expertise of both contractor and DRDC Atlantic staff are being utilized in the development of the federation.

Principal Results An initial prototype federation for ship replenishment at sea was developed. The prototype federation uses simplified federates and successfully demonstrates the feasibility of the proposed federation framework. The Federation Object Model (FOM) is an extension of the Real-time Platform Reference Federation Object Model (RPR FOM), which is widely used for defence simulations.

Significance of Results The prototype federation can be used as the basis for development of a full federation of ship replenishment at sea. This development can now proceed with minimal technical and financial risks. Utilization of the RPR FOM as the basis FOM increases the likelihood that developed federates can be inserted into other federations with minimal effort.

Future Plans Development of the full RAS federation is proceeding. The contractor is responsible for modelling of the RAS gear, overall federation design, and integration of software components. DRDC Atlantic is providing ship motion models based on the ShipMo3D ship motion library, and a visualization federate.

Bleichman, D., Langlois, R.G., Gamble, M., and Brennan, D. August 2007. Development of a High Level Architecture Federation of Ship Replenishment at Sea - Initial Prototype. DRDC Atlantic CR 2007-222. Defence R&D Canada – Atlantic.

iv DRDC Atlantic CR 2007-222

Sommaire

Introduction R & D pour la défense – Atlantique est en train de développer un logiciel de simulation distribuée des plates-formes navales à l’aide de l’architecture évoluée. Une simulation de ravitaillement en mer (REM) est présentement développée à titre de fédération initiale pour en démontrer les capacités. L’expertise du personnel de l’entrepreneur et de celui de RDDC Atlantique est mise à profit pour le développement de la fédération.

Résultats Un prototype initial de fédération simulant un ravitaillement en mer a été développé. La fédération prototype, qui utilise des fédérés simplifiés, a démontré de façon concluant la faisabilité du cadre de fédération proposé. Le modèle d’objet de la fédération ou FOM (de l’anglais Federation Object Model) est un prolongement du modèle d’objet de la fédération de la référence plate-forme en temps réel ou RPR FOM (de l’anglais Real-time

Platform Reference Federation Object Model) largement utilisé dans les simulations de la défense.

Portée La fédération prototype peut être utilisée à des fins de développement pour une fédération de simulation globale du ravitaillement en mer des navires. Le développement de cette dernière peut maintenant se poursuivre avec un minimum de risques du point de vue technique et financier. L’utilisation du RPR FOM en tant que FOM élémentaire augmente la probabilité que les fédérés développés puissent être insérés dans d’autres fédérations avec un minimum d’effort.

Recherches futures Le développement d’une fédération de REM globale se poursuit. L’entrepreneur est responsable de la modélisation du matériel de REM, de la conception d’ensemble de la fédération et de l’intégration des composants du logiciel. La contribution de RDDC Atlantique comprend la fourniture des modèles pour les mouvements des navires à partir de sa bibliothèque de mouvements de navires ShipMo3D et d’un fédéré de visualisation.

Bleichman, D., Langlois, R.G., Gamble, M., and Brennan, D. August 2007. Development of a High Level Architecture Federation of Ship Replenishment at Sea - Initial Prototype. DRDC Atlantic CR 2007-222. Defence R&D Canada – Atlantic.

DRDC Atlantic CR 2007-222 v

Table of contents

1.0 Introduction ............................................................................................................................ 1 1.1 Background ............................................................................................................... 1 1.2 Problem Statement .................................................................................................... 1 1.3 Project Objectives ..................................................................................................... 1 1.4 Technical Approach.................................................................................................. 1

2.0 Mathematical Modelling ....................................................................................................... 3 2.1 Ship Motion............................................................................................................... 5 2.2 RAS Equipment ...................................................................................................... 10

3.0 Federation Implementation ................................................................................................. 14 3.1 Introduction ............................................................................................................. 14 3.2 HLA time management .......................................................................................... 14 3.3 Runtime Infrastructure (RTI) Selection................................................................. 18 3.4 FOM Development ................................................................................................. 19 3.5 The RAS federates .................................................................................................. 21 3.6 RAS simulation execution...................................................................................... 23

3.6.1 Phase 1 – Create Federation ................................................................. 23 3.6.2 Phase 2 - Execute simulation steps ...................................................... 23 3.6.3 Phase 3 – resign and destroy federation............................................... 24

3.7 Performance ............................................................................................................ 24 3.7.1 Calculation of grant time ...................................................................... 24 3.7.2 Performance of the RAS federation ..................................................... 26

4.0 Sample Results ..................................................................................................................... 28 4.1 Parameter Selection ................................................................................................ 28 4.2 Results ..................................................................................................................... 30 4.3 Discussion ............................................................................................................... 33

5.0 Future Work ......................................................................................................................... 34 5.1 Federation Implementation .................................................................................... 34

5.1.1 New federates: ....................................................................................... 34 5.1.1.1 Visualizer Federate.......................................................................... 34 5.1.1.2 Data Logger Federate...................................................................... 36

5.1.2 ShipMo3D integration: ......................................................................... 37 5.1.3 Performance optimization:.................................................................... 37

5.2 Mathematical Modelling ........................................................................................ 37

6.0 Conclusion............................................................................................................................ 39

7.0 References ............................................................................................................................ 40

vi DRDC Atlantic CR 2007-222


DRDC Atlantic CR 2007-222 vii

List of figures FIGURE 1: ARCHITECTURE OF RAS DEVELOPMENT ENVIRONMENT AND FILE STRUCTURE. .......... 5 FIGURE 2. EFFECT OF SHIP OFFSET ON WAVE ENCOUNTER TIMES OF RECEIVING AND SUPPLY

SHIPS...................................................................................................................................... 8 FIGURE 3. SAMPLE TRANSIENT-DYNAMIC SHIP MOTION INPUT FILE (SUSHDY.INP) ..................... 9 FIGURE 4. TYPICAL RAS SYSTEM CABLING AND COMPONENTS (REPRODUCED FROM

“SEAMANSHIP RIGGING AND PROCEDURES MANUAL”, NATIONAL DEFENCE, REPORT

B-GN-181-105/FP-E00). ................................................................................................... 10 FIGURE 5: END AND SIDE VIEWS OF RAS HIGHLINE ATTACHMENT POINTS.................................... 11 FIGURE 6: SAMPLE RAS EQUIPMENT MODEL INPUT FILE................................................................ 13 FIGURE 7: TIME MANAGEMENT SERVICES IMPLEMENTATION IN FEDERATE AND RTI .................. 16 FIGURE 8: SIMULATION TIME ADVANCE REQUEST/GRANT PROCESS ............................................ 17 FIGURE 9: TIME STEPPED SIMULATION, TYPICAL EXECUTION SEQUENCE ..................................... 18 FIGURE 10 EXAMPLE OF THE TREE BARRIER PROCESS .................................................................... 25 FIGURE 11 EXAMPLE OF THE BUTTERFLY BARRIER PROCESS......................................................... 26 FIGURE 12: TIME ADVANCE GRANT PERFORMANCE FOR VARIOUS RTIS....................................... 27 FIGURE 13: RELATIVE SHIP POSITIONING USED FOR GENERATING SAMPLE RESULTS. .................. 29 FIGURE 14: SUPPLY SHIP LINEAR DISPLACEMENTS.......................................................................... 30 FIGURE 15. SUPPLY SHIP ANGULAR DISPLACEMENTS....................................................................... 31 FIGURE 16: RECEIVING SHIP LINEAR DISPLACEMENTS.................................................................... 31 FIGURE 17: RECEIVING SHIP ANGULAR DISPLACEMENTS................................................................ 32 FIGURE 18: HIGHLINE TENSION......................................................................................................... 32 FIGURE 19 - PROOF-OF-CONCEPT RAS VISUALIZATION................................................................. 36

List of tables

TABLE 1: RECEIVE ORDER VS. TIME STAMP ORDER MESSAGING .................................................. 15 TABLE 2: OUTLINE OF RAS FOM CLASS STRUCTURE.................................................................... 21 TABLE 3 VISUALIZER SOFTWARE OPTIONS CONSIDERED............................................................... 34

viii DRDC Atlantic CR 2007-222

This page intentionally left blank

DRDC Atlantic CR 2007-222 1

1.0 Introduction

1.1 BACKGROUND

In order to carry out the Navy's mission effectively, fleet units must be capable of remaining at sea for prolonged periods of time, possibly in areas of the world where friendly re-supply ports are not available, and remain fully ready to carry out any assigned tasks. Supply ships are equipped to replenish combatants underway with fuel, ammunition, provisions, and spare parts [1]. The Canadian Department of National Defence is looking to use a simulation infrastructure called the High Level Architecture (HLA) to provide integrated, joint simulation environments for the development of tactics and doctrine as well as for training and systems acquisition [2]. In order to support this effort, the Warship Performance Section at DRDC Atlantic has initiated a research and development effort aimed at producing a simulation of ship replenishment at sea.

1.2 PROBLEM STATEMENT

In order to simulate the conditions leading to these adverse events, the interaction of ships, RAS gear, and environmental conditions must be modelled. Current methods of simulation either limit the interaction of these components or do not include the simulation of specific elements.

1.3 PROJECT OBJECTIVES

The objective of the proposed technical solution is to provide a simulation environment that models the interactions between the various components in order to simulate conditions that lead to the adverse events of payload immersion and RAS gear breakage. This report covers progress made during the first of three project phases.

1.4 TECHNICAL APPROACH

The RAS HLA federation currently consists of 4 federates (phase I) and will consist of up to 10 federates (phases II/III), where each federate can be replaced/upgraded independently of the other federates. This architecture allows for greater flexibility and a gradual development where federates can be added or replaced by ones of a higher fidelity as development progresses. The only major constraint on the development of specific federates is that they have to comply with a predefined FOM.

2 DRDC Atlantic CR 2007-222

Most federates consist of a HLA front-end and a mathematical modeling back-end where the mathematical modeling end can be upgraded over time (for better fidelity) while maintaining present external interfaces (the HLA front-end). In phase I the following components were modeled: RAS-gear, supply ship, and receiving ship. Each one is modeled as a separate HLA federate, in addition a federation manager federate was introduced. Additional models for seaway and hydrodynamic-interaction are low fidelity representations (phase I) and are embedded in the ship mathematical models. Their fidelity will be upgraded and they will become separate HLA federates over the next phases of the contract.


2.0 Mathematical Modelling

In the phased approach to developing a federation that is applicable for accurate simulation of a RAS operation, the primary purpose of the first phase was to develop and implement simple models necessary to demonstrate correct interactions through the HLA federation and to form the basis for detailed model development and implementation in Phase II. To this end, modelling decisions were made based on the anticipated requirements of the detailed federation and the objective of minimizing required reworking of defined model component interfaces and changes to model frameworks. As will be discussed subsequently, the two largest implications of this were rationalizing the interaction between the linear ship models and nonlinear RAS equipment model, and in defining data interfaces that in many cases will only be required in Phase II. In effect, the simple models that were implemented for the supply ship, receiving ship, and RAS equipment are effectively placeholder models. More complete and accurate models will be developed and implemented in Phase II. However, the current models are sufficiently representative of the real system dynamics to demonstrate correct functioning of the mathematical modelling and federation implementation and to give a sense of the type of results that can be expected in Phase II. To facilitate model development, a Development Environment for RAS (DERAS) program was created that effectively emulates interaction between each of the three mathematical models and the federation. This development and testing environment is illustrated schematically in Figure 1 along with the associated input and output file structure. This development environment allowed mathematical models to be developed and tested in parallel with federation implementation and provided the ability to confirm consistency between the expected simulation output and the output of the federation during development. As will be discussed subsequently, the structure used in DERAS is reflected in the final federation implementation. The control program DERAS simulates interaction between the federation and the ship and RAS equipment models. The subroutines SUSHPR and RESHPR evaluate prescribed ship motion for the supply and receiving ships respectively using a superposition of sinusoidal components, based on conventional response amplitude operators, for each of the six ship degrees of freedom. These models were used during the development of the RAS equipment model but do not form part of the final federation. Instead, simple transient-dynamic models of the supply ship (SUSHDY) and receiving ship (RESHDY) were implemented to generate representative ship motion, including the effect of the RAS gear. Subroutine RASEQ evaluates the highline tension between the ships as well as the associated equipollent forces and moments acting on each of the two ships. Individual input files for each routine contain information specific to their function. The models SUSHDY, RESHDY, and RASEQ are the ones that have been carried forward from the development environment into the Phase I federation.


In terms of data transfer, each of the ship models receives as input a flag (p) indicating whether the model should evaluate initial conditions or advance the solution one time step by numerical integration, the current simulation time (t), the equipollent force (F) applied to the ship, and the equipollent moment (M) applied to the ship. Using these, and constant parameters from the ship motion input file, the linear and angular position vector (r), linear and angular velocity vector (v), and linear and angular acceleration vector (a) corresponding to the ship motion are evaluated. With reference to Figure 1, it should be noted that subscript su indicates variables specific to the supply ship and subscript re indicates variables specific to the receiving ship. As will be expanded upon subsequently, the linear position, velocity, and acceleration data are measured relative to the inertial coordinate system that through the input file can be specified to be either translating-earth or fixed-earth. It should be noted that acceleration data is calculated and output such that it is available should dead-reckoning be required within the RAS equipment model in the future. In general, with mechanical systems, acceleration data is not required to evaluate displacement dependent forces such as those comprising the RAS gear as these forces are only dependent on the system state (displacement and velocity level data) and time. The rotational coordinates are interpreted to be XYZ Euler angles (also known as Bryant angles) and their first and second time derivatives. Therefore the angular components of the velocity and acceleration vectors are actually first and second time derivatives of the Bryant angles and not true angular velocity and angular acceleration vectors. Interpretation of the independent angles as Euler angles provides the desired ability to develop the RAS equipment model assuming fully correct and nonlinear representation of ship orientation and associated homogeneous rotational transformation matrices. The drawback is that the output from the simple ship models based on independent angles is not strictly being interpreted as is intended with a model of that type. However, since the RAS equipment model will be carried forward to Phase II whereas the simple ship model will presumably not be, this seems to be a reasonable choice. The RAS equipment model receives as input, a flag (p) indicating whether the model should evaluate initial conditions or advance the solution one time step by numerical integration though this feature will only be required in Phase II as no numerical integration of the RAS equipment model is currently required in Phase I, and ship kinematics for both the supply and receiving ships (rsu, vsu, asu, rre, vre, are). It then uses this information to compute the equipollent forces and moments acting on the supply ship (Fsu, Msu) as well as those acting on the receiving ship (Fre, Mre). In addition, the highline tension (Thl) is provided as output for subsequent data logging. Additional variables representing the cargo body position and orientation (rc) and the in-haul and out-haul cable tensions (Tih, Toh) are passed through the model interface but are simply set to zero by the model as these elements are beyond the scope of Phase I but will be essential for Phase II. The mathematical models have been implemented in FORTRAN. This decision was based on the developer’s experience with FORTRAN and the ability to re-use various proven routines and mathematical functions. All modelling assumes that input is provided in consistent basic units (unless noted otherwise in the input file documentation). This allows the models to be run using either metric or Imperial units; with the only additional requirement being that the correspondingly correct value of acceleration due to gravity (g) be provided in the input files. Basic units are kg, N, m,


and s in metric and slug, lbf, ft, s in Imperial. Individual subroutines have been extensively documented in the code clearly defining the calculation sequences used, variable definitions and declarations, and subroutine inputs and outputs. The choice to include the extensive documentation directly in the code is to mitigate the possibility of the code and associated documentation diverging over time. The material included in this report is intended to provide a high-level overview of the modelling. Implementation details are available in the source code. Similarly, the definitions of input parameters are clearly defined in the appropriate input files.

Figure 1: Architecture of RAS development environment and file structure.

2.1 SHIP MOTION

The transient-dynamic ship motion model implemented and applied for both the supply and receiving ships is implemented as described in Reference [3]. This model comprises ship degrees of freedom that are assumed to be uncoupled. The ship dynamic equations are driven by a single sinusoidal wave component and the equipollent force and moment contributions arising from the RAS equipment. Appropriate stiffness and damping terms are included to represent the effect of active helm control either by an operator or auto-helm system. Numerical integration is performed using a fixed-time-step fourth-order Runge-Kutta integrator.


The decision to interpret output of the ship model as Bryant angles and their time derivatives was motivated by the fact that a homogeneous rotational transformation is essential for preserving the distances between fixed points on the ships undergoing rotation and is critical for Phase II. As an example, a complete representation of the RAS equipment will include cables spanning sheaves at various fixed points on the ships. If a nonhomogeneous transformation were used, incorrect changes in cable lengths and associated tensions would be computed. However, this approach is implicitly incompatible, strictly, with the simple linear ship motion model implemented in Phase I. The decision was made to interpret the independent angles arising from the ship models as the XYZ Euler angles and the local rotation derivatives as time rates of change of Euler angles. This approach works fairly well in the translating-earth coordinate system but becomes more complex when extended to fixed-earth coordinates. In either case, small inconsistencies introduced by this interpretation do not propagate as the solution advances because the original linear ship motion is always used as the basis for numerically advancing the ship motion solutions. Were follow-on modelling not anticipated, the alternative approach of implementing a linearized model of the highline attachment point kinematics, that is consistent with the simple ship model, likely would be the favoured approach. This would represent a relatively simple change to the simulation but would only work as long as the RAS equipment is represented by a single attachment point on each ship. Figure 2 contains a sample annotated ship input file. The input data is categorized into ship design parameters, ship operating parameters, seaway parameters, and coordinate system parameters. The parameter definitions are generally self-explanatory though a couple merit special consideration. First, due to the presence of two ships in the simulation, their relative positioning must be addressed. Each is positioned relative to the translating coordinate system using the parameters dltax and dltay which are measured positive forward and to port respectively. In the sample case presented in this report and distributed with the Phase I federation, the translating-earth coordinate system is taken to be coincident with the receiving ship centre of mass position upon starting the simulation. The centre of mass of the supply ship is taken to be 40 m ahead and 100 m to port of the receiving ship leading to values of 0 m for both dltax and dltay in the receiving ship input file and values of 40 m and 100 m respectively in the supply ship input file. The relative position of the two ships is illustrated subsequently in Figure 6. The offset between ships results in the wave encounter times also being delayed between ships. This can be accounted for in one of two ways: either using the phase offset as described in Reference [1] (Appendix A), or using the time delay t. The time delay can readily be related to the ship heading relative to the sea direction, the relative positioning of the ships, and the incident wave encounter period. The delay time can be derived as follows, considering the geometrical parameters identified in Figure 3. Point A identifies the intersection of the wave crest passing through the supply ship centre of mass and a line parallel to the sea direction passing through the receiving ship centre of mass. Considering distances in the nominal ship longitudinal direction, the following equality holds

sincos lxd =+ . Now considering the ship lateral direction, the following equality holds

yld =+ cossin .


These two equations can be expressed in matrix form as

=y

x

l

d

cossin

sincos

and can be solved for the two unknown distances d and l assuming the relative placement of the two ships, specified by x and y, is known resulting in

=y

x

l

d

cossin

sincos.

The length d, given by yxd += sincos

is the distance the wave crest must travel between encountering the receiving ship centre of mass and encountering the supply ship centre of mass. Considering the expression for wave celerity c for water having a depth greater than half the wave length

2egT

c =

where g is acceleration due to gravity and Te is the wave encounter period (that itself is a function of the ship speed and ship heading relative to the sea direction), the time delay between wave crests encountering the receiving and supply ships is given by

egT

d

c

dt

2==

with the negative sign reflecting that the wave crests encounter the supply ship after the receiving ship. The time delay may be specified explicitly in the ship motion input file or alternatively may be specified. The value for can be calculated as

ecT

d= .

It is important to note that values should be specified either for or t but not both as the effects are additive in the ship simulation code. The signs of x and y must be considered carefully if the configuration of the ships, in terms of relative placement, is significantly different from what has been assumed in the above derivation. Using a flag, the option to output data from the ship models in the translating-earth coordinate system or fixed-earth coordinate system is available. If the fixed-earth coordinates are selected, the heading of the ship relative to the fixed-earth frame and the constant speed at which the translating-earth frame advances relative to the fixed frame must be specified consistently with the forward speed specified for the ships. The RAS equipment model is unaffected by the choice of coordinate system.


Figure 2. Effect of ship offset on wave encounter times of receiving and supply ships


Ship design parameters: 22.d6 ship mass, M 8.5 roll radius of gyration, rxx 41. pitch radius of gyration, ryy 41. yaw radius of gyration, rzz 0.02 surge nondimensional added mass, A11/M 0.6 sway nondimensional added mass, A22/M 2. heave nondimensional added mass, A33/M 0.15 roll nondimensional added mass, A44/(M rxx^2) 1. pitch nondimensional added mass, A55/(M ryy^2) 0.3 yaw nondimensional added mass, A66/(M rzz^2) 75. surge natural period (due to course-keeping), T1 75. sway natural period (due to course-keeping), T2 8. heave natural period, T3 22. roll natural period, T4 8. pitch natural period, T5 75. yaw natural period (due to course-keeping), T6 0.5 surge damping ratio, zeta1 0.5 sway damping ratio, zeta2 0.5 heave damping ratio, zeta3 0.5 roll damping ratio, zeta4 0.5 pitch damping ratio, zeta5 0.5 yaw damping ratio, zeta6 Ship operating parameters: 5.1444 nominal forward speed [basic units: m/s or ft/s], U 210. wave heading direction relative to the ship (+ve cw viewed from above) [deg], beta Seaway parameters: 4. wave amplitude, a 0.6 incident wave frequency [rad/s], w_I 0. phase lead angle for the wave at the origin [rad], epsilon_I Integration parameters: 9.81 acceleration due to gravity (consistent with Imperial or metric units) 0.1 time step 0. 0. 0. 0. 0. 0. linear and angular displacement initial conditions 0. 0. 0. 0. 0. 0. linear and angular velocity initial conditions 40. 100.0 -1.2 dltax,dltay,dltat Translating-earth coordinate system parameters (must be consistent with RESHDY.INP): 0 integer flag indicating use of translating-earth(0) or fixed-earth(1) coordinates -45. ship heading relative to fixed-earth coordinate system (Xibar) [deg] 5.1444 inertial coordinate system constant forward speed [basic units: m/s or ft/s]

Figure 3. Sample transient-dynamic ship motion input file (SUSHDY.INP)


2.2 RAS EQUIPMENT

Figure 4 illustrates schematically components of a RAS system. Key components include the supply ship kingpost (not labelled, but the device to which cables are attached on the supply ship), receiving ship pad eye, traveller, highline cable, inhaul cable, and outhaul cable in addition to actuation and control systems. Accurate simulation of RAS requires detailed modelling of the cargo dynamics and the influence of each of the three cables and the actuation and control system. For the purpose of the Phase I federation, only the highline cable is modelled as a displacement-dependent force element spanning attachment points on the supply ship kingpost (S) and the receiving ship padeye (R). Points S and R are defined in Figure 5. The following describes the kinematics and tension evaluation that form the core of this simplified model. Superscripts are used to express the coordinate systems in which the various vectors are defined with sp indicating the inertial coordinate system (fixed-earth or translating-earth as selected in the ship input files) and sh indicates the local ship coordinate systems.

Figure 4. Typical RAS system cabling and components (Reproduced from

“Seamanship Rigging and Procedures Manual”, National Defence, Report B-GN-

181-105/FP-E00).


Figure 5: End and side views of RAS highline attachment points.

First, the position (sp

Sr ) and velocity (sp

Sv ) of the supply ship attachment point are evaluated as

sh

GSSshsp

su

sp

GS

sp

S rTrr /][+=

and

)]([ /

sh

GSS

sh

SUshsp

SU

sp

GS

sp

S rTvv +=

where sp

GSr is the position of the supply ship centre of mass, ][ shsp

suT is the rotational

transformation matrix from the ship frame to the inertial frame, sh

GSSr / is the relative

position vector from the supply ship centre of mass GS to the attachment point S, sp

GSv is

the supply ship centre of mass linear velocity, and sh

SU is the angular velocity of the ship expressed in the ship local coordinate system. Analogous calculations are performed to

determine the position and velocity of the receiving ship attachment points (sp

Rr andsp

Rv ) using the relevant receiving ship kinematic variables. Next, the distance ( ) between the attachment points S and R is evaluated as

=rr

sp

S

sp

R

and a unit vector ( un ) directed along the highline cable from S to R is defined by

=

sp

S

sp

Run

rr


The rate of change of distance between points S and R is evaluated by projecting the relative velocity vector between the two points onto the axis of the cable using a dot product

un

sp

S

sp

R vv•

=

The highline tension ( hlT ) is evaluated as the sum of a nominal cable tension ( 0T ), a

stiffness term corresponding to the effective stretch in the cable, and a damping term corresponding to the effective rate of stretch of the cable. The actual effective stiffness (k) and effective damping (c) is primarily the result of the RAS system paying out and reeling in cable. The resulting equation is

++= &clkTThl )( 00 )0( hlT

where 0l is the nominal cable length. The above equation is subject to the constraint that

the cable cannot develop a compressive force.

The equipollent force acting on the supply ship (sp

sueqF ) can be obtained by expressing the cable tension as components in each inertial coordinate system component direction using the cable direction unit vector resulting in

unhl

sp

sueq TF =

The equipollent force acting on the receiving ship (sp

reeqF ) is simply equal but opposite to that acting on the supply ship such that

sp

sueq

sp

reeq

FF =

This expression is true provided cable inertia is neglected as is the case for Phase I.

The equipollent moments acting on each of the two ships (sh

sueqM and sh

reeqM ) are evaluated as the first moment of the forces about the ship centres of mass and are evaluated in the local ship coordinate systems

[ ]sp

sueqspsh

su

sh

GSS

sh

sueq FTrM = / and [ ]sp

reeq

spsh

re

sh

GRR

sp

reeq

FTrM = / .

It should be noted that consistent with the way in which Newton-Euler equations are usually applied, equipollent forces are evaluated in the inertial coordinate system and equipollent moments are evaluated in the local coordinate system. This approach will be carried forward to Phase II. However, in Phase I with the simple linear ship model, it is necessary, for compatibility, to transform the equipollent moments from the local ship frames to the global frame prior to introducing the moments into the ship governing equations. This transformation is performed by the ship models. It is anticipated that this step will not be required in Phase II. A sample input file for the RAS equipment model is provided below in Figure 6.


0.0 -5.0 18.0 supply ship attachment point relative to the ship centre of mass expressed in the ship frame (rcmkps(j),j=1,3) 40.0 5.0 15.0 receiving ship attachment point relative to the ship centre of mass expressed in the ship frame (rcmkpr(j),j=1,3) 1850.0 1.d3 90.0 150.d3 highline cable effective stiffness, damping, nominal length, and nominal tension xk,xc,xl0,t0

Figure 6: Sample RAS equipment model input file


3.0 Federation Implementation

3.1 INTRODUCTION

While the overall objective of this project is to provide a simulation environment that is able to model the behaviour of RAS gear, an important secondary objective is the provision of a flexible, extendable HLA federation which will form the basis for future development. The RAS HLA federation that has resulted from the efforts of Phase 1 can accommodate the further development anticipated for Phases 2 and 3 of this project due to the development of a RAS-specific, proprietary, and comprehensive federation object model (FOM) that is tightly based on the standard RPR-2.0 v17 FOM [4]; and the selection of an appropriate run-time infrastructure (RTI). The performance of the RAS HLA federation was confirmed by the implementation and testing of 4 basic RAS federates: the execution management federate, the RAS-gear federate, the Supply Ship federate, and the Receiving Ship federate. Additional federates can be readily included during the following phases of the project by implementing appropriate aspects of the RAS FOM. The first phase of RAS Federation implementation is a text-book case of HLA design and development. As such, there is little need for exhaustive descriptions of the activities undertaken and this section limits itself to overviews of the areas of prime interest:

• the selection of an RTI • the development of the FOM • the development of the 4 federates • the simulation execution of the RAS federation which implements and tests the

data exchange between the mathematical models described in Section 2 of this report.

This section starts, though, with a detailed discussion of HLA Time Management due to its early adoption in the project. This work was originally planned for Phase 2 but the need for accurate data exchange (to produce meaningful experimental results for analysis) drove the use of “time-stepping”. The impact of time management on the RAS simulation system is discussed in Section 3.7.

3.2 HLA TIME MANAGEMENT

In order to meet analysis requirements of DRDC Atlantic, it was determined that the RAS federation would implement the standard time-stepping services provided by the RTI as a method for controlling and sequencing events as they occur during the simulation. This determination was made based on a comparison between the two baseline types of HLA message ordering:


1. Receive Order (RO)

a. messages are passed federates in an arbitrary order b. messages are not ordered by time

2. Time Stamp Order (TSO) a. message sender assigns a timestamp to the message b. successive messages passed to each federate have non-decreasing

timestamps Table 1 below provides comparison between the two message ordering types:

Table 1: Receive Order vs. Time Stamp Order messaging

A time-stepped federation is inherently a Time Managed (TM) federation where all federates are synchronized to be at the same logical time during each simulation step. Figure 7 below illustrates the way time management services are implemented in HLA federations. The RTI is responsible for passing messages between federates in an ordered fashion while the federate is responsible for the advancement through the simulations execution (by invoking the HLA time management services) and for association of logical time with wall-clock time (if required).

typical applications training, T&E analysis

Latency

Reproduce before and after relationships

All federates see same ordering of events

Execution repeatable

PROPERTY

low

no

no

no

Receive Order (RO)

higher

yes

yes

yes

Time Stamp Order (TSO)


Figure 7: Time Management Services implementation in federate and RTI

In HLA, logical time is synonymous with simulation time and these time advances by each federate must be properly managed to ensure no federate receives a message in its past. HLA Time Management (TM) services define a protocol for federates to advance their logical time and the RTI will ensure TSO messages are not delivered in a federate’s past. This is a vital component of the RAS federation given the importance of accurate data exchange between the mathematical models acting as the simulation engines beneath each federate.


Federates are defined within the time managed federation as either: 1. Time Regulating

a. can send TSO messages b. can prevent other federates from advancing their logical time c. can enable Time Regulation d. can disable Time Regulation and/or:

2. Time Constrained a. can receive TSO messages b. time advances are constrained by other c. can enable Time Constrained d. can disable Time Constrained

Furthermore, each federate in a federation execution can be

• Time regulating only (e.g., message source) • Time constrained only (e.g., Stealth) • Both time constrained and regulating (common case for analytic simulations) • Neither time constrained nor regulating (e.g., DIS-style training simulations)

In Phase 1 of the RAS federation, all federates are both time regulating and time constrained and the federation makes use of time advance requests and grants, where each federate issues a request to advance in time and the RTI grants the request when all federates are in sync. Figure 8 below illustrates the process of time advance request issued by the federate and the time advance grant provided by the RTI.

Figure 8: Simulation time Advance Request/Grant process

If the logical time of Federate in Fig 8 is T, then the RTI guarantees no more TSO messages will be passed to the federate with time stamp < T. A more detailed description of Time Advance Requests (TAR) and Time Advance Grants (TAG) typically used by time stepped federates, follows in Figure 9:

Federate

Time Advance Request

Time Advance Grant

RTI


Figure 9: Time Stepped simulation, typical execution sequence

In this process, the Federate invokes Time Advance Request (TAR 20) to request its logical time be advanced to T (LT 20). The RTI then delivers all TSO messages with time stamp T (RAV 14 and RAV 18). Once complete, the RTI advances federates’ time to T, and invokes Time Advance Grant (TAG 20) when it can guarantee all TSO messages with time stamp T have been delivered. Note that Grant Time always matches the requested time.

3.3 RUNTIME INFRASTRUCTURE (RTI) SELECTION

Runtime Infrastructure (RTI) is a collection of software that implements the RTI interface specification. RTIs are available from several commercial vendors; usually in the form of software libraries with which the developer links the source code making up each federate. The services provided to federates by the RTI software are:

1. Federation management: creation, dynamic control, modification and deletion of federation execution.

2. Declaration management: Federates declare to the RTI their desire to publish and/or subscribe to object-state attributes and interactions.

3. Object management: Each object is assigned an ID that is used by the federate in order to transmit the object’s state attributes.

4. Ownership management: Allows federates to transfer ownership of object attributes or complete objects since only the owner of a specific object instance may publish value for that instance.

5. Time management: Provides time-ordered exchange of events among federates in a federation.

6. Data Distribution Management (DDM): Supports efficient routing and distribution of data by abstract regions.

Although all RTIs implement HLA specifications (in part or in full), they can differ significantly in their internal architecture and in capabilities. After a careful review of

Wall clock time

Federate RTI

TAR(20)

RAV (14)

RAV (18)

TAG(20)

TAR: Time Advance Request RAV: Reflect Attribute Values TAG: Time Advance Grant Federate calls in black RTI call-backs in red

LT=10

LT=20


capabilities of a variety of RTI’s, MAK Technologies version 3.1.1 was selected for the RAS federation. This particular RTI was chosen for a number of reasons including the stability of the product, the level of technical support available from the vendor, and the fact that it is commonly used throughout the Canadian defence community. In addition, this RTI provides relatively high performance which is key to providing robust, time-managed federations.

3.4 FOM DEVELOPMENT

The RPR FOM 2.0 draft 17 is a recognized industry standard federation object model for use in this kind of simulation environment. It is compliant with the IEEE HLA 1516 specification and forms the basis for the development of the RAS FOM. This helps to ensure easy integration with other HLA compliant simulation systems and federations. The RAS FOM was created by extending the RPR FOM through the addition of those classes and attributes required by the RAS federates using the mathematical models developed as part of this project.

The following describes the classes, attributes, interactions, and parameters that were added (or modified) in the RPR FOM to create the RAS FOM:

-Feqssp

-Meqssh -Feqrsp

-Meqrsh

-Thl

-Tih

-Toh

RasGearVectors

RasGearVectors is a new class added to facilitate the forces applied to the ships by

the RAS-gear.

SeaWay

The SeaWay class is a new class, added to facilitate seaway input(s) to both ship federates. This class is currently acting as a placeholder and will be more fully developed in future phases of the project.

EnvionmentObject PointObject

-Dimension

OtherPointObject

1 1..* 1 1..*

The existing EnvironmentObject.PointObject.OtherPointObject class (which has no attributes of its own in RPR FOM 2.0) was extended by adding an attribute to represent the pay-load.


-EntityIdentifier .*

-EntityType.*

-IsPartOf.*

-RelativeSpatial.*-Spatial.*

-Spatial.AngAccelVec

BaseEntity

The Spatial attribute of BaseEntity was extended by adding angular acceleration vector.

-JoinStatus

-ExecutionCommand

-FedName

RASManagement

RasManagment is a new interaction class which was added to facilitate simulation management data exchange between the execution manager federate and the other federates.

Each of the Phase 1 RAS federates are represented in the RAS FOM. Both ship objects are represented by the "BaseEntity.PhysicalEntity.Platform.SurfaceVessel" class, while the pay-load object is represented by the EnvironmentObject.PointObject. OtherPointObject class, and the RAS cable segments are represented by the “EnvironmentObject.ArealObject” class. The following is a table of all new or modified FOM elements:

Class Attribute/Parameter Function/Comment

Feqssp supply ship equipollent force vector expressed in the inertial frame

Meqssh supply ship equipollent moment vector expressed in the ship frame

Feqrsp receiving ship equipollent force vector expressed in the inertial frame

Meqrsh receiving ship equipollent moment vector expressed in the ship frame

Thl actual highline cable tension Tih actual in-haul cable tension (not

applicable in Phase I) Toh actual out-haul cable tension (not

applicable in Phase I)

RasGearVectors

SeaWay TBD seaway input(s) to both ship


federates Location Position of Pay-Load

Orientation of Pay-Load

EnvironmentObject. PointObject. OtherPointObject

Dimension of Pay-Load

BaseEntity. PhysicalEntity.Platform

Spatial All “Spatial” data for ships. angular acceleration was added to this attribute since it doesn’t exist in RPR 2.0 v17

JoinStatus used through the federation joining process

ExecutionCommand used for execution commands such as reload initial configuration or end simulation (and resign)

RasManagment

FederateName federate’s name EnvironmentObject.ArealObject PointsData represents segments of the RAS

cables Table 2: Outline of RAS FOM Class Structure

3.5 THE RAS FEDERATES

Phase 1 of this project implements 4 basic federates, which are used to exercise the simulation system at a fairly simplistic, fundamental level. This approach allowed for major efforts to be focused on proper framework, HLA, and FOM design within Phase 1 and less effort directed to specific federate development. The federates implemented during this Phase are: Execution Management Federate This federate monitors and controls the general execution of the simulation system and has 5 major roles:

1. Insure that all participating federates have joined the federation before simulation can start.

2. Bring all federates to a known state before simulation starts (through synchronization points).

3. Pace the execution based on wall clock time (real-time, faster than real-time or slower than real-time).

4. Stop execution and insure that all federates resign the federation before federation is being destroyed.

5. When a new configuration (start up conditions) is required, halt the simulation, then manage in new configuration.


RAS-gear Federate. The RAS-gear federate calculates RAS-gear forces and moments and outputs them to both ship federates. These calculations are performed at each time-step when the federate receives kinematics data from both ship objects. Supply Ship Federate

The supply ship federate receives forces and moments from the RAS-gear federate at each time-step, calculates and publishes kinematic data back to the RAS-gear.


Receiving Ship Federate

Like the supply ship, this federate also receives forces and moments from the RAS-gear federate at each time-step, calculates and publishes kinematic data back to the RAS-gear.

3.6 RAS SIMULATION EXECUTION

The execution of the RAS simulation system can be broken out into three major phases: create the federation and allow all federates to join; execute the simulation steps beginning from predefined initial conditions for a desired duration; and, finally, gracefully resign from the federation and destroy the federation.

3.6.1 Phase 1 – Create Federation

Each federate that tries to join the federation will first attempt to create the federation by calling createFedEx(). This will ensure that a federation is created regardless of which federate starts first. Only the first federate to join should be successful in creating the federation and all subsequent federates will receive the message that the FedEx already exists and the call will generate a soft exception. This soft exception will have no impact on the federation execution or the federate. After attempting to create the federation, each of the federates will join the federation by making a call joinFedEx().

Part of the process of joining the federation is the initialization of data and establishing which data the federate is going to publish and subscribe to. This data can be either an “object” or an “interaction”. In the RAS federation “interactions” are used for execution management and hence require all federates to subscribe to those “interactions”. During the creation and initialization of the federation it is the Execution Manager Federate’s responsibility to bring the federation to a state where it is ready to start the simulation. Each federate waits for instructions from the Execution Manager and responds to its requests until the Execution Manager federate signals that all federates are joined and ready to start the simulation. As soon as all federates are synchronised, a call to synchronizationPointAchieved()is made and the federation is ready to advance to phase 2.

3.6.2 Phase 2 - Execute simulation steps

Once all four federates are synchronised, the actual simulation begins. During the first time-step, the RAS-Gear federate and both ship-motion federates read their initial parameters from corresponding input files. This means that all physics parameters can be changed between simulation runs by modifying the input files where initial parameters are held.


During each subsequent simulation time-step two concurrent activites take place:

1. The RAS-Gear federate uses spatial data from both ship-motion federates from the previous time step and calculates force vectors, which it then distributes to the ship-motion federates for use in the next timestep.

2. Both ship-motion federates use the force vectors generated by the RAS-gear during the previous time-step as input for calculating the latest spatial data. Then each ship-motion federate distributes the new spatial data to be used by the RAS-Gear federate during its next time-step.

Once the three federates (RAS-Gear, supply ship-motion, receive ship-motion) send their data, they each make a request to move to the next time-step by calling timeAdvanceRequest(). This request is granted by the RTI once two conditions are met:

1. All federates have published the results of their respective calculations, and 2. All federates are requesting to advance to the next time step.

In this way, the execution-manager federate can pace the simulation by issuing a timeAdvanceRequest()at given wall-clock intervals. The Execution Manager federate measures a given wall-clock time period and places a time advance request to the next simulation time-step. In addition, the Execution Manager acts upon such operator input as requests to terminate or restart the simulation. When a request to terminate the simulation is issued to the Execution Manager, it initiates phase 3.

3.6.3 Phase 3 – resign and destroy federation

When a request to terminate is received, the Execution Manager federate sends an interaction to all federates to terminate the simulation. Federates quit the simulation loop and move to a synchonization point. When all federates are past this point they resign from the federation by calling resignAndDestroy(). The result of this call is the destruction of the federation by the last federate to resign.

3.7 PERFORMANCE

3.7.1 Calculation of grant time

From the description in the previous section, one can see that in order for the time managed federation to advance to the next step, the system must wait until all federates have completed their calculations before processing all time advance requests initiated by the federates and the corresponding grants given by the RTI. It is easy to see why the use of time management in a federation can be the cause of reduced performance of the simulation system as a whole. This reduction may be due to the simple overhead of making time advance requests and grants between each federate and the RTI but may also be due to the interval of logical time, which is driven by the calculation of the Lower Bound on Time Stamp (LBTS). The following considerations should be made with respect to the LBTS:


1) The LBTS value computed for a federate is the lowest (earliest) time stamp of messages that are destined for that federate later in execution;

2) For each federate, the RTI must ensure that:

i) Time Stamp Ordered (TSO) messages are delivered to the federate in time-stamped order, and

ii) No message is delivered to the federate with a time stamp that is earlier than its logical time.

3) Once the LBTS for a federate is computed:

i) The RTI delivers to the federate all TSO messages with a time stamp earlier than LBTS, and

ii) If the RTI prevents the federate from advancing its logical time beyond LBTS, it guarantees that the federate receives no messages in its past.

4) To compute the LBTS, the RTI must consider:

i) The earliest time stamp of a TSO message that any federate might generate in the future (the current logical time of a federate is one boundary since no federate can generate a TSO message in its past), and

ii) The time stamps of messages within the RTI and the interconnection network (transient messages).

All commercially available RTIs use the butterfly scheme for LBTS computation and, given their proprietary nature, are not modifiable by the developer or user of the system. The Butterfly Barrier scheme organizes processes into trees which are computationally superimposed over one another. At the individual node level, the process proceeds as follows:

Figure 10 Example of the Tree Barrier Process


1. The process sends a message to its parent process when the process has reached

the barrier point 2. The root detects completion of the barrier when a message has been received from

each of its children processes 3. The root broadcasts a message down the tree to release processes (2 log N time if

all processes reach barrier at same time) to advance to the next step.

Figure 11 Example of the Butterfly Barrier Process

The butterfly barrier process can be considered to be a superimposition of a number of tree barrier processes [5].

A single LBTS computation is initiated when a federate requests a time advance and requires NlogN messages to be exchanged between the federates, where N is the sum of time-regulating and time-constrained federates in the federation. Actual LBTS calculations may require between Nlog N and (T+N)log N messages [5] (where T is the number of transient messages in the system when the LBTS calculation is initiated) , where each message contributes its own message latency to the overall LBTS calculation. Some of these messages can be processed concurrently but a significant degree of serialization will be present and will be proportional to the depth of a binary tree with a federate at each node. For example, in a federation of 8 federates that are all time-regulating and time-constrained, and which are interconnected over a LAN with average network latency of 0.01 seconds, the minimal delay for a federate to advance to the next point in time is: log 8 * 0.01sec = 30 milliseconds (the amount of serialization is log N not Nlog N).

3.7.2 Performance of the RAS federation

Currently calculation of grant time (with only 4 federates) requires about 25 milliseconds (40 grants/second). Since the simulation time step is at 100 ms, the RAS federation is capable at running at up to X4 than real-time. It is expected that during Phase 2, with its planned 10 federates, the grant time calculation will take longer. Figure 10 shows the impact of additional federates on time managed federations using various RTIs. It is worth noting that the RTI planned for use in Phase 2 is not represented in the figure and


higher performances may be encountered. In any case, efforts will be made in the next phase to optimise the federates/federation in order to achieve optimal performance.

Average Grants/Sec

1

10

100

1000

2 4 6 8

Federation Size

Gra

nts

/Sec

Georgia Tech Multi Threaded

Georgia Tech Single Threaded

DMSO NG4

Figure 12: Time advance Grant performance for various RTIs


4.0 Sample Results

A sample simulation case is presented in this section for the purpose of demonstrating the performance of the simulation.

4.1 PARAMETER SELECTION

The input data fall into the following three categories: a. ship parameters; b. ship operating conditions; and c. RAS equipment parameters.

The ship parameters used for the simulation are those recommended in Reference [3]. For the sample run, calculations are performed and output in the translating-earth coordinate system. The sinusoidal wave approaches the ship from a heading of 30 degrees off the starboard bow (beta = 210 degrees) and the ships are travelling at a constant speed of 10 knots (U = 5.1444 m/s). The wave amplitude is 4 m and the incident wave frequency is 0.6 rad/s. Based on conditions representative of proposed heavy RAS and based on the location of existing heavy jackstays on the AOR and CPF ships, the relative positioning of the ships is such that the centre of mass of the supply ship (AOR) is 40 m ahead and 100 m to port of the receiving ship (CPF). This positioning, illustrated in Figure 6, allows the RAS highline to be approximately parallel to the Y axis. The operating conditions suggest a time delay of 1.2 seconds for wave crests encountering the supply ship centre of mass relative to the receiving ship centre of mass. The supply ship attachment point is assumed to be 5 m to starboard of the ship centreline and 18 m above the centre of mass. The receiving ship attachment point is assumed to be 5 m to port of the ship centreline and 15 m above the centre of mass. The effective stiffness was determined to be 1850 N/m calculated based on the expected tension fluctuation of plus or minus 15 percent of nominal tension using a maximum total wire rope payout of 12 m. Effective damping was estimated arbitrarily to be 1000 Ns/m, the nominal cable length is 90 m based on the selected nominal ship positioning, and the nominal cable tension is 150 kN based on the proposed specification for heavy RAS. Initial conditions relative to the translating-earth coordinate system are set to 0 for each ship so that the starting transient may be observed in the simulation output. Because the forcing function is simple sinusoidal wave excitation, following the decay of transient motions relative to a constant cycle, the output of the simulation in terms of both ship motions and highline tension should settle to a constant cycle. The sample simulation was run for 100 seconds from an initial time t = 0 s using an integration time step of 0.1 s.


Figure 13: Relative ship positioning used for generating sample results.


4.2 RESULTS

Linear and angular ship displacement results for the supply ship are plotted in Figures 12 and 13 respectively. Displacement results for the receiving ship are plotted in Figures 14 and 15. Fluctuation in highline tension is plotted in Figure 16.

-20

0

20

40

60

80

100

120

0 10 20 30 40 50 60 70 80 90 100

time, seconds

su

pp

ly s

hip

cm

dis

pla

ce

me

nt,

m

sush dx

sush dy

sush dz

Figure 14: Supply ship linear displacements.


-10

-8

-6

-4

-2

0

2

4

6

8

10

0 10 20 30 40 50 60 70 80 90 100

time, seconds

su

pp

ly s

hip

an

gu

lar

dis

pla

ce

me

nts

, d

eg

sushdrx,deg

sushdry,deg

sushdrz,deg

Figure 15. Supply ship angular displacements.

-20

0

20

40

60

80

100

120

0 10 20 30 40 50 60 70 80 90 100

time, seconds

rec

eiv

ing

sh

ip c

m d

isp

lac

em

en

ts,

m

resh dx

resh dy

resh dz

Figure 16: Receiving ship linear displacements.


-10.00

-8.00

-6.00

-4.00

-2.00

0.00

2.00

4.00

6.00

8.00

10.00

0 10 20 30 40 50 60 70 80 90 100

time, seconds

rec

eiv

ing

sh

ip a

ng

ula

r d

isp

lac

em

en

ts,

de

g

reshdrx,deg

reshdry,deg

reshdrz,deg

Figure 17: Receiving ship angular displacements.

0

20000

40000

60000

80000

100000

120000

140000

160000

180000

0 10 20 30 40 50 60 70 80 90 100

time, seconds

hig

hli

ne

te

ns

ion

, N

Figure 18: Highline tension.


4.3 DISCUSSION

The sample results presented are in agreement with expected behaviour. Several relevant observations are made below.

1. Linear displacements of the supply ship oscillate about the nominal position (40, 100, and 0) m that was specified in the supply ship input file. Similarly, receiving ship linear displacements oscillate about (0, 0, 0) m as they should given the input data.

2. The amplitudes of angular displacements are larger for the smaller receiving ship than they are for the more massive supply ship.

3. The supply ship shows no offset in the pitch or yaw directions consistent with the RAS gear attachment point being collocated with the ship centre of mass in the x direction. A positive roll offset to starboard appears as is expected due to highline tension and the attachment point above the centre of gravity. The receiving ship shows a negative roll offset and a positive yaw offset consistent with the highline attachment point being forward and above the centre of mass.

4. Highline tension has the correct initial value of 150 kN but drops slightly due to the angular offsets in the ship orientations (and to much a lesser extent positions).

5. Following initial transients, the motions tend toward a “steady-state” oscillation cycle having a frequency consistent with the sinusoidal wave encounter frequency.


5.0 Future Work

5.1 FEDERATION IMPLEMENTATION

5.1.1 New federates:

The following new federates will be introduced: • Visualizer Federate – This federate will subscribe to both ship objects, pay

load object and RAS cable objects and will display their position in a 3D format.

• Data Logger Federate - This federate will subscribe to all data objects exchanged between the federates and will record them in a time-stepped order. A COTS implementation should be used, if possible.

• Seaway federate - This federate will provide inputs for both ship motion federates using the “SeaWay” class FOM extension.

• Hydrodynamic Interaction Federate – This federate will generate (calculate) and distribute predicted interaction forces to both ship federates based on kinematics data distributed by the ship federates. It will distribute the data using the “HydrodynamicForces” class FOM extension.

5.1.1.1 Visualizer Federate

Requirements for the visualizer federate include an ability to provide an accurate rendering of the seaway, ships, replenishment gear, and transferred payload. The visualizer federate is also assumed to have a requirement for rendering a scene comprising the elements described above at interactive frame rates (30 Hz or better preferred). It is also assumed that the visualizer should be capable of operating both in time-step with a live federation execution, as well as off-line using previously recorded data. The visualizer should be capable of operating in real-time, with an option for slower-than and faster-than real-time operation. Several software options for supporting the implementation of the visualizer federate were identified in the Request For Proposal (RFP) and additional options were identified during the conduct of Phase I work. These options are:

Table 3 Visualizer Software Options Considered

Software Pros Cons

HOOPS 3D (TechSoft3D)

• High performance rendering for technical applications

• Limited to MS Windows O/S

• Specialized • Limited user base


• Low-level API, requiring significant development

Vega Prime (MultiGen-Paradigm)

• Cross-platform portable (MS Windows & Linux)

• Marine module available providing realistic representation of sea states, ocean surface and related special effect (e.g., bow wave, wake, etc.)

• General purpose • Addresses broad

spectrum of visualization needs

• Extensive user base • High-level API

supporting rapid application development

• Commercially licensed • Cost of acquisition can

scale quickly depending upon options required

OpenSceneGraph (Robert Oldsfield, et al.)

• Cross-platform portable (MS Window, Linux, IRIX, others)

• General purpose • Open Source (LGPL)

• Low-level API, requiring significant development

• Lack of commercial support

HOOD TK (DRDC-Atlantic)

• Opportunity to leverage work already performed by DRDC-Atlantic

• Multi-layer framework, simplifying software development

• Specialized • Limited user base

This list of options is by no means exhaustive, but the types of software tools/libraries described in Table 3 do address a reasonable cross-section of 3D visualization technology. It is recommended that a more in-depth analysis of requirements for the visualizer federate be conducted early on in Phase II of the project. As a proof-of-concept, a 3D visualization application was developed in parallel to, but independent of the Phase I activities. This 3D visualization application utilized MultiGen-Paradigm Vega Prime and included the use of Vega Prime Marine and Special Effects modules. This application provides a visualization of


a CPF and Provider class ships interacting with a dynamic ocean model. A simulated constant tension line was also used to provide a simplified rendering of the RAS line(s). A screen capture of this proof-of-concept application is provided in Figure 19.

Figure 19 - Proof-Of-Concept RAS Visualization

5.1.1.2 Data Logger Federate

Requirements for the Data Logger federate include an ability to record and playback data recorded during a federation execution. Additionally, it is understood that the Data Logger federate should be capable of making recorded data available in human-readable form in order to support post-execution analyses.


Given that the RAS federation utilizes a version of the RPR-FOM with only minor expansions implemented to support a representation of the RAS gear, it is recommended that a commercial HLA Data Logger be leveraged in order to respond to these requirements. A commercial data logger must be extensible in order to accommodate the recording and replay of object class and attribute extensions added to RPR-FOM during the course of Phase I work. The MÄK Data Logger is an example of a commercial HLA data logger product that is mature, robust and extensible. The MÄK Data Logger supports the RPR-FOM by default, but also includes a FOM-mapping capability and can be extended to accommodate additional FOM data. The MÄK Data Logger supports the use of Time Management during recording and playback, which is an important consideration in order to be usable in the RAS federation. Lastly, the MÄK Data Logger includes a capability to export recorded data to any SQL-compliant database. Once transferred to an SQL database, the data can be queried and filtered directly or imported into Microsoft Excel for additional analysis.

5.1.2 ShipMo3D integration:

Both supply and receiving ship federates will be replaced by HLA compliant versions of the ShipMo3D software. It is assumed that modification of the ShipMo3D software to become HLA compliant will require a significant amount of effort.

5.1.3 Performance optimization:

As stated previously, in order to achieve faster than real-time simulation, an effort will be made to reduce the latency of “grant time” calculation. This may include careful modifications to the RID file and/or a request to MAK Technologies to improve their product. From experience with other RTIs, the latency of calculation of “grant time” with 6 time regulating and time constrained federates (the visualizer federate and the data logger federate don’t have to be time managed) can be better (lower) than 50 milliseconds.

5.2 MATHEMATICAL MODELLING

It is suggested that future implementation of the mathematical modelling be sequenced. First, the currently-implemented linear ship motion model should be replaced with a three-dimensional accurate ship motion model based on the ShipMo3D library. This will remove the requirement to interpret independent ship orientation angles as Bryant angles as ShipMo3D also uses the Bryant angle convention. Second, the current RAS equipment model should be expanded to include the physical modelling of the RAS gear described in the original proposal. This consisted of including accurate representation of


the highline and inhaul/outhaul attachment point geometry and kinematics; actively controlled highline tension; actively controlled in- and out-haul cable tensions; point to point geometrical representation of the highline and in/out-haul cable vectors between the supply ship, cargo body, and receiving ship; and six degree-of-freedom representation of the cargo body dynamics. In total it is expected that the model will have nine degrees of freedom. Relevant aspects of the control system, pulleys and winches, and cabling will be represented by equivalent STREAM rig parameters and behaviour at the delivery ship kingpost and receiving ship padeye. Extensions to what was originally proposed will be control of the elevation of the ship attachment points that is reflective of the real system and essential for lifting cargo off the deck and reducing cable tensions as the cargo mass leaves the supply ship and approaches the receiving ship. It is expected that this will result in a complete simulation of the RAS system including cable sag. It will however not include the effects of cable “droop” due to the distributed weight of the cable or flexible cable dynamics. It is suggested that any time available following the implementation of the point-to-point cable dynamic model be used to investigate and implement, to the extent possible, refinements to the modelling due to cable dynamics. In all cases, an approach similar to what was followed in Phase I, whereby models are developed and tested in a stand-alone development environment prior to their introduction into the RAS federation, should be adopted based on the perceived benefits of this approach observed in Phase I.


6.0 Conclusion

Based on the experience gained over the course of this first phase of the RAS modeling and simulation, the following conclusions can be drawn:

1. HLA provides the necessary functionality to support a time-stepped simulation. 2. The performance of the HLA time management may limit execution rates where

short time-steps are required. 3. HLA based simulation is flexible and modular, federates can be added easily.

Federates can be easily replaced by ones with higher fidelity or federates that are based on different algorithms.

4. The approach of developing and testing mathematical models in stand-alone environments in parallel with the federation implementation was shown to be an efficient method for developing a federation of this type and is recommended for subsequent phases.

5. The issue of essentially independent evaluation of supply ship dynamics, receiving ship dynamics, and the RAS equipment model did not pose any apparent problems in the implementation of the simple test federation in Phase 1. The weak coupling of the models, as compared with conventional tightly-integrated engineering analysis solutions, may require careful attention in Phase 2. This issue can be addressed in the development environment prior to integration into the federation to assess potential problems and propose solutions such as dead-reckoning that has been discussed during Phase 1.

6. In planning the content of individual federates, it was observed that careful attention to the placement of some calculations, such as coordinate transformations, can lead to long-term simplifications in reusing existing federates and integrating new ones. It is therefore suggested that, while the flexibility of HLA for simulation development is inherent, where possible it can be beneficial to have a long-term view of potential applications of federates at the time they are first developed. At the very least, choosing a convenient and versatile form for variables passed through the RTI is important.


7.0 References

1. J. Pike, “Underway Replenishment”, Federation of American Scientists, Washington D.C., 1999, http://www.fas.org/man/dod-101/sys/ship/unrep.htm.

2. D. Perrault, “Review of Architectures for Simulation of Virtual Naval Platforms”, DRDC Atlantic TM 2003-193, September 2003.

3. McTaggart, Kevin, “Simplified Modelling of a Seaway and Ship Motions for Phase 1 of Development of a High Level Architecture Federation for Ship Replenishment at Sea, Contract W7707–63647/001/HAL”. DRDC Atlantic, Feb. 15, 2007.

4. Simulation Interoperability Standards Organization, “Guidance, Rationale, and Interoperability Manual for the Real-time Platform Reference Federation Object Model (RPR FOM),” Version 2.0D17v3, 3 October 2003.

5. Brooks, D. E. 1986. The Butterfly Barrier. The International Journal of

Parallel Programming, vol. 14295-307.


DISTRIBUTION

Development of a High Level Architecture Federation of

Ship Replenishment at Sea - Initial Prototype


1. CANADA A. INTERNAL

1 Author – 1 paper copy 5 Library (4 CD’s, 1 paper copy) – STANDARD DIST.

B. DND AND SECURITY CLEARED ADDRESSES National Defence Headquarters MGen. George R. Pearkes Bldg. 101 Colonel By Drive Ottawa, Ontario K1A OK2 1 DRDKIM (normally 1 copy of all publications) 2 DMSS 2 (normally 2 copies) 2 MARLANT PO Box 99000 Stn Forces Halifax, NS B3K 5X5 Canadian Forces Maritime Warfare Centre PO Box 99000 Stn Forces Halifax, NS B3K 5X5 1 Maritime Synthetic Environment Coordinator Office (MSECO) 12 TOTAL Canada, DND and Security Cleared


DOCUMENT CONTROL DATA (Security classification of title, body of abstract and indexing annotation must be entered when the overall document is classified)

1. ORIGINATOR (the name and address of the organization preparing the document. Organizations for whom the document was prepared, e.g. Centre sponsoring a contractor's report, or tasking agency, are entered in section 8.) Martec Limited, Suite 400 - 1888 Brunswick Street, Halifax, NS B3J 3J8

2. SECURITY CLASSIFICATION (overall security classification of the document

including special warning terms if applicable). UNCLASSIFIED

3. TITLE (the complete document title as indicated on the title page. Its classification should be indicated by the appropriate abbreviation (S,C,R or U) in parentheses after the title). Development of a High Level Architecture Federation of Ship Replenishment at Sea - Initial Prototype

4. AUTHORS (Last name, first name, middle initial. If military, show rank, e.g. Doe, Maj. John E.) Bleichman, D., Langlois, R. G., Gamble, M., and Brennan, D.

5. DATE OF PUBLICATION (month and year of publication of document)

August 2007

6a. NO. OF PAGES (total containing information Include Annexes, Appendices, etc).

54

6b. NO. OF REFS (total cited in document)

5

7. DESCRIPTIVE NOTES (the category of the document, e.g. technical report, technical note or memorandum. If appropriate, enter the type of

report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period is covered).

CONTRACT REPORT

8. SPONSORING ACTIVITY (the name of the department project office or laboratory sponsoring the research and development. Include address).

Defence R&D Canada - Atlantic PO Box 1012 Dartmouth, NS, Canada B2Y 3Z7

9a. PROJECT OR GRANT NO. (if appropriate, the applicable research

and development project or grant number under which the document was written. Please specify whether project or grant). Project 11gv01

9b. CONTRACT NO. (if appropriate, the applicable number under which the document was written).

W7707-063647/001/HAL

10a ORIGINATOR'S DOCUMENT NUMBER (the official document

number by which the document is identified by the originating activity. This number must be unique to this document.)

10b OTHER DOCUMENT NOs. (Any other numbers which may be assigned this document either by the originator or by the sponsor.)


11. DOCUMENT AVAILABILITY (any limitations on further dissemination of the document, other than those imposed

by security classification) ( X ) Unlimited distribution ( ) Defence departments and defence contractors; further distribution only as approved ( ) Defence departments and Canadian defence contractors; further distribution only as approved ( ) Government departments and agencies; further distribution only as approved ( ) Defence departments; further distribution only as approved ( ) Other (please specify):

12. DOCUMENT ANNOUNCEMENT (any limitation to the bibliographic announcement of this document. This will normally correspond to the

Document Availability (11). However, where further distribution (beyond the audience specified in (11) is possible, a wider announcement audience may be selected).


13. ABSTRACT (a brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is

highly desirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of the security classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), (R), or (U). It is not necessary to include here abstracts in both official languages unless the text is bilingual). In order to carry out the Navy's mission effectively, fleet units must be capable of remaining at sea for prolonged periods of time, possibly in areas of the world where friendly re-supply ports are not available, and remain fully ready to carry out any assigned tasks. Supply ships are equipped to replenish combatants underway with fuel, ammunition, provisions, and spare parts. The Canadian Department of National Defence is looking to use a simulation infrastructure called the High Level Architecture (HLA) to provide integrated, joint simulation environments for the development of tactics and doctrine as well as for training and systems acquisition. In order to support this effort, the Warship Performance Section at DRDC Atlantic has initiated a research and development effort aimed at producing a simulation of ship replenishment at sea. The objective of the proposed technical solution described in this report is to provide a simulation environment that models the interactions between the various components in order to simulate conditions that lead to the adverse events of payload immersion and RAS gear breakage. This report covers progress made during the first of three project phases.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (technically meaningful terms or short phrases that characterize a

document and could be helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such as equipment model designation, trade name, military project code name, geographic location may also be included. If possible keywords should be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus-identified. If it not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title).

High Level Architecture Replenishment at sea Ship motions Simulation

development of a high level architecture federation of ...development of a high level architecture...

Documents