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
• Pitch ABSweden
• 04E-SIW-089

2
Outline

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

3
Background 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
4
Rationale for 1.3 to 1516 interoperability

• 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
• 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

5
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

6
HLA 1516 migration strategy
7
Summary of improvements in HLA 1516
8
Improvements from HLA 1.3 to 1516

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

9
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

10
HLA 1516 OMT Building Blocks
Object Classes with Attributes
Interactions withParameters
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 integer
11
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
12
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
• Filtering of information (with DDM) is easier
  more flexible
• Some additions that allows for better performance
  and scalability
• For example for simulations with many objects

13
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
14
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
Register new object nameWait for global
checkApplication blocked by waitFunction
Returns OK Register next object name Etc
Register new object name Do something
elseRegister next object name Do something
else Register next object name Do something else
Register next object name
Callback OK Callback OK Callback OK
15
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.

16
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 manually 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!
17
1516 AdapterConcept of operation
18
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
• Connects to a HLA 1516 RTI
• Minimal performance impact

19
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

20
Considerations for a mixed federation

• Must use compatible FED (1.3) / FOM.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 the data encoding of the HLA 1.3
  federates
• Exchanged data must be buffer compatible
• Some restrictions on HLA 1.3 DDM dimension usage
• Dimension is globally defined in HLA 1516
• You may need to understand some differences in
  the MOM

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

• Data encoded in the 1.3 Federate must be 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

22
Practical experiences
23
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 Defense
  FMV (Feb-Mar 2004)

24
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
25
Result

• Federation, Declaration, Object and Time
  management were used successfully
• 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
• Adapter calls RTI using HLA 1516 API

26
Conclusions

• It is possible to create an adapter that allows
  HLA 1.3 federates to interoperate using HLA 1516
• The adapter has been used for real HLA 1.3
  federates
• 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