Practical Experiences from HLA 1.3 to HLA 1516 Interoperability

1
Practical Experiences from HLA 1.3 to HLA 1516
Interoperability

• Björn Möller
• Lennart Olsson
• Pitch AB, Sweden
• 04F-SIW-045

2
Outline

• Rationale for HLA 1.3 to HLA 1516
  interoperability
• Summary of improvements in HLA 1516 and
  implications on 1.3 to 1516 interoperability
• Concept of operation for a 1516 adapter
• Considerations for a mixed federation
• A sample practical experience FbSim
• Conclusions

3
Rationale Interoperability and Life-Cycles

• Federations need to be composed of existing and
  new federates, COTS and in-house applications
• This means that federates may be in very
  different stages of their life-cycles

Development Funding
time
4
Federations over Time
time
In-house Training System A
A
Partner System B
COTS Tool C
Temp Syst.
Interoperate!
Interoperate!
5
Standards over Time
1990
1996
2000
2005
DIS
HLA 1.3
HLA 1516
HLA 1.3Federate
HLA 1516Federate
DISApplication
Adapter
Adapter
pRTI 1516
6
HLA 1.3 HLA 1516
HLA Baseline
First certified1516 RTI
HLA to IEEE for standardization
HLA Initial definition
HLA adopted by OMG
First 1516RTI
1516 to 1.3interoperability

• Olderstandards
• ALSP
• DIS

95 96 97 98 99 00 01
02 03 04 05 ...
DoDMasterplan
HLA 1.3standard
HLA 1516standard
First 1516federations
HLA 1516evolved (1516.2006)
HLA 1.3 US DoD standard
IEEE 1516 open standard
7
Rationale for 1.3 to 1516 Interoperability

• Migrating a HLA 1.3 federate to 1516 may not make
  sense for federates approaching end-of-life
• Migrating an HLA 1.3 federate may be very costly
• May apply to the cost of migration, testing,
  VVA, etc
• Migrating an HLA 1.3 federate to 1516 may not
  even be possible
• No access to source code or development
  environment/competence
• COTS tools
• Incremental migration A federation can start
  using 1516 immediately. Federates can migrate,
  one by one, as it fits their schedule

8
Rationale against

• A mixed federation may not be able to benefit
  from all of the 1516 improvements
• Performing a full 1516 migration of HLA 1.3
  federates will yield a cleaner solution
• Properties of the HLA 1.3 federate will impose
  some limitations on the 1516 federation/federates
• Described later

9
HLA 1516 migration strategy
10
Summary of Improvements in HLA 1516 and
Implications on1.3 to 1516 Interoperability
11
Improvements from HLA 1.3 to 1516

• Note The interoperability solution will have to
  handle some of these differences, the federate
  developer will have to handle some of them
• Object Model Template
• A big step forward!
• Interface Specification
• Some concepts, semantics, interaction patterns
• API Signatures, data types
• Changes in MOM
• Rules
• No changes

12
Improvements in 1516 OMT

• More complete documentation of object model
• Speeds up integration reduced cost reduced
  risk fewer conflicts
• Maybe the greatest improvement in 1516 for
  sponsors and PMs!
• FOM is used directly by the RTI no more
  FED-file!
• Standardized data types
• HLAinteger32BE, etc
• Standardized encoding
• Including padding/alignment, variable arrays,
  cardinality, etc
• Object model now uses industry standard XML
  format
• Opens more possibilities (tools, code generation,
  )
• Uses industry standard Unicode instead of ASCII
• Better for international use

13
HLA 1516 OMT Building Blocks
Object Classes with Attributes
Interaction classes with Parameters
Uses
Datatypes Predefined or User-defined
Modified/added in 1516
Array
Fixed Record
Variant Record
Enumerated
Simple
Uses
Primitive Datatypes Predefined or User-defined
BasicData
1516
Example 32 bit big-endian integer
14
More 1516 OMT Building Blocks
General Documentation
Identification
Notes
Additional Federation Execution Data
Synchronization Points
Dimensions
User Supplied Tags
1516
1516
1516
Routing spaces removed
Infrastructure Settings
1516
1516
Time Representation
Switches
Transportation Types
1516
15
Improvements in 1516 Interface Specification

• The 1516 standard solves a number of problems
  found during practical use of HLA 1.3
• It is also more strictly defined
• The behavior of many functions is more logical
• Some additions that allow for better performance
  and scalability
• For example for simulations with many objects
• Filtering of information (with DDM) is easier and
  more flexible

16
Example Additive subscriptions in 1516
HLA 1.3 Now subscribes only to Plane.z
HLA 1516 Now subscribes to Plane.x, y and z
Federate subscribes to Plane.x Plane.y
Federate subscribes to Plane.z
t1
t2
time
17
Example Object name registration

• Object registration performance
• Object names are globally unique in federation

HLA 1.3
HLA 1516
Federate wants to register 10 000 objects
Federate wants to register 10 000 objects
Reserve object name Do something elseReserve
next object name Do something else Reserve next
object name Do something else Reserve next
object name
Register new object instanceWait for global
checkApplication blocked by waitFunction
Returns OK Register next object instance Etc
Callback OK Callback OK Callback OK
18
Example Differences in DDM
News.messageManchester United wins 2 1
News sender
News listener
News.message Beatles reunited in Liverpool
News.message Faster laptops next year
Whats new in England?

• We want to send news messages.
• We want to be able to filter these depending on
  what country the news apply to as well as the
  area (politics, sports, financial, music, etc).
• The message may have country and/or area or none
  of them.

19
Differences in DDM - continued
HLA IEEE 1516
HLA 1.3
FOM
FOM
Declare Dimensions country, area Dimension
names can be reused. Declare Routing Space
as country_and_area
Declare Dimensions country, area Dimension
names are globally unique.
For news.message define possible dimensions
country and area
For news.message define routing space
country_and_area (only one allowed)
At RunTime
At RunTime
Use the routing space and provide default
extents explicitly for unused dimensions
Select from possible dimensions dynamically.
Unuseddimensions doesnt matter.
Adding a new dimension?Modify existing federates!
Adding a new dimension?No changes to old
federates!
20
1516 AdapterConcept of Operation
21
Desired properties

• No changes to the federates should be required
• Standard library/class names
• HLA 1.3 API presented to the HLA 1.3 federate
• HLA 1.3 semantics/functionality
• Implements 100 of the HLA 1.3 API
• Minimal performance impact
• Connects to a HLA 1516 RTI

22
Concept of operation
Legacy 1.3Federate
1516Federate
1516Federate
1516 Adapter
HLA 1.3 API
pRTI 1516

• Provides the old HLA 1.3 APIs and behaviour to
  HLA 1.3 federates
• RTI-NG v6 C API, standard DLL name entry
  points
• pRTI 1.3 v2.x C API, standard DLL name entry
  points
• pRTI 1.3 Java API, standard class/package names
• Provides interoperability with 1516 federates
  through a full 1516 RTI

23
Inside the 1516 Adapter
HLA 1.3 API C, Java
Syntactic Transformations Handles, Collections,
MOM, etc
Semantic Transformations DDM, Declaration,
Ownership, etc
pRTI 1516
HLA 1516 API
Adapter Support Services
24
Considerations for a mixed federation

• Must use compatible FED (1.3) / FDD.xml (1516)
• OMT tools can provide automatic conversion
• Must use a 1516 time representation that is
  compatible with the existing HLA 1.3 time type
• Compatible time types provided
• Must use compatible data encoding, usually the
  one of the HLA 1.3 federates
• Exchanged data must be buffer compatible
• Some restrictions on HLA 1.3 DDM dimension usage
• A dimension is globally defined in HLA 1516
• MOM interactions have different names on the 1.3
  and the 1516 side

25
Buffer compatible data
HLA 1.3 Everything is a byte-array
HLA 1516 Standardized encoding, cardinality,
padding
?

• Data encoded in the 1.3 Federate is decoded in
  the 1516 Federate and vice-versa
• Major drawback your federation may not be able
  to implement the standardized HLA 1516 data
  encoding
• May only apply to a subset of the FOM

26
Practical Experiences
27
A 1516 Adapter Use Case

• Swedish Army Tactical Trainer
• Fb-SIM, PC-Dart, developed for HLA 1.3
• Used at two occasions at the Swedish Defence
  FMV (Feb-Mar 2004)

28
Test setup
General system for building force-level
simulations Developed since 1989 by major Swedish
defence industries and FOI.
Short formatted text messages Multiple
communication modes (Radio, LAN, etc) Used for
the majority of C2 traffic in the Swedish Army
FbSim
PC Dart
1516 Adapter
1516 Adapter
pRTI 1516
HLA 1.3 Federates interoperating through an HLA
1516 RTI
29
Test Result

• Federation, Declaration, Object and Time
  management were used successfully
• Other services were not used
• No modifications necessary to the federates
• No performance problems
• Having two HLA APIs on one machine available
  requires careful installation
• Federate calls Adapter using HLA 1.3 API, the
  adapter calls RTI using HLA 1516 API
• Having a native HLA 1.3 RTI installed as well
  requires even greater carefulness

30
Conclusions

• It is possible to create an adapter that allows
  HLA 1.3 federates to interoperate with each other
  and 1516 federates using HLA 1516
• The adapter has been used for real HLA 1.3
  federates using a certified 1516 RTI
• Using the adapter to avoid 1516 migration for
  some federates makes sense in the short run
• HLA 1.3 federates may put some limitations on HLA
  1516 federates
• Full 1516 migration is a cleaner solution