Using JTLS and HLA for Distributed Training

1
Using JTLS and HLA for Distributed Training
Dave Prochnow, MITRE Zach Furness, MITRE Jonathan
Roberts, Rolands Associates
2
Outline

• Introduction
• JTLS-NATO Federation
• JTLS-EADSIM Federation
• Future of JTLS Federations
• Conclusions

3
Introduction

• The Joint Theater Level Simulation (JTLS) is an
  interactive multi-sided wargame used for training
  for over 15 years.
• In 1998, DMSO began exploring use of JTLS with
  HLA.
• This evolved into the JTLS-NATO federation, which
  includes NATO command-and-control systems.
• In past year, JTLS also operated in an HLA
  federation with Extended Air Defense Simulation
  (EADSIM).

4
JTLS Federation Usage

• Both JTLS federations supported training
  exercises in the first half of 2000.
• In March, the JTLS-NATO federation executed in
  the Disciplined Warrior exercise (Izmir, Turkey).
• In May, the JTLS-EADSIM federation ran at the
  Lucky Sentinel exercise (Kuwait).
• Lessons learned from both of these federations
  are described in this briefing.

5
Non-Federated JTLS Exercise Configuration
OTH-GEM
JTLS
40-50 clients per GDS GDSs can be chained
G-Protocol messages
(Secondary) GDS
6
Outline

• Introduction
• JTLS-NATO Federation
• JTLS-EADSIM Federation
• Future of JTLS Federations
• Conclusions

7
JTLS-NATO Federation
JTLS CEP
RunTime Infrastructure (RTI)
8
JTLS-NATO Federation Experience

• At Disciplined Warrior, the JTLS-NATO federation
  successfully demonstrated the use of HLA at a
  NATO exercise.
• Federation performance, a large concern in 1999,
  was acceptable.
• Several technical issues were encountered and
  resolved, primarily at two formal test events
  prior to the exercise.
• Subsequent slides examine the technical issues.

9
Federation Initialization

• As the HIP (main data producer) and other
  federates (subscribers) enter the federation, we
  must ensure data integrity while completing the
  initialization as fast as possible.
• In 1999, use of synchronization points failed.
• A new scheme using update requests ensured data
  integrity but resulted in many needless updates.
• We ended up using a combination of pull and
  push mechanisms.

10
Federation Performance

• Until December 1999, it was feared that poor
  performance would prevent use of the federation.
• Performance problems led to re-design of original
  system architecture.
• HIP federate created to offload processing from
  CEP
• Became more selective of what would be an HLA
  object
• Still, a large amount of data had to be
  processed
• Represent about 10,000 objects per side
• 60-70 attributes per object class

11
Federation Performance(continued)

• Biggest problem was time required to register and
  update all objects
• Benchmarks showed exponential relationship
  between initialization time and number of objects
• Required close coordination with RTI developers
• Problem solved when we migrated to RTI 1.3v7
• We ran performance tests prior to Disciplined
  Warrior exercise
• Modified FMT captured registration and throughput
  data.
• Devised the new initialization mechanism
• At exercise, performance was not an issue.

12
Data Distribution Management

• The JTLS-NATO federation employs DDM to control
  different perceptions by each side.
• Utilize a routing space with 11 regions, one for
  ground truth and one for each of 10 sides
• Federates subscribe to their region of interest
  (i.e., their sides perception)
• This approach significantly increases the number
  of HLA objects in the federation.
• Still, this proved to be an effective method of
  managing perceptions compared with the
  alternative of passing perception data in arrays.

13
Treatment of Time in JTLS-NATO Federation

• The 1998 JTLS-GCCS-NATO federation used HLA time
  management.
• Although JTLS manages time internally, we decided
  it was not necessary to use HLA time management.
• Because subscribing federates just wanted the
  simulation time for their displays, it was more
  efficient to create a new object class,
  GAME_INFORMATION, that is periodically updated
  with the simulation time.

14
RTI Problems

• This federation turned out to be a very stressful
  applications, as several previously unseen
  problems with RTI 1.3v7 were encountered
• Intermittent problem of missing discoveries of
  all object instances of a particular class
• Sometimes deletes were not processed after
  federate owning objects resigned
• Memory leaks led to a crash at the exercise when
  all system memory was exhausted
• Workarounds were developed for each of the above.

15
Crash Recovery

• At one time or another, all federates in our
  federation experienced a crash.
• Production of crash recovery procedures allowed
  us to quickly recover from crashes at the
  Disciplined Warrior exercise.
• The FMT became an essential part of the
  federation as it allowed us to quickly identify
  the missing discovery problem.

16
User Perspective of JTLS-NATO Federation

• Despite problems encountered, the desired
  training occurred
• Training audience shielded from HLA
  infrastructure
• Quick crash recovery and good run speed allowed
  us to recover from crashes without the training
  audience knowing that any problems had even
  occurred
• NC3A believes use of HLA has potential to become
  default method for interfacing their systems with
  JTLS
• But they want a more stable version of the RTI
  than they had with 1.3v7

17
Outline

• Introduction
• JTLS-NATO Federation
• JTLS-EADSIM Federation
• Future of JTLS Federations
• Conclusions

18
JTLS-EADSIM Federation Overview

• The JTLS-EADSIM federation reused much of the
  JTLS-NATO federation, including
• JTLS, GDS, and HIP components
• Federation Object Model (FOM)
• The federation added the Extended Air Defense
  Simulation (EADSIM).
• HLA time management was used, with game speed
  controlled by a new federate called the Pacer.
• The federation executed at the Lucky Sentinel
  exercise in May 2000.

19
JTLS-EADSIM Federation
RunTime Infrastructure (RTI)
20
JTLS-EADSIM Interoperability

• Unlike the JTLS-NATO federation, two simulations
  owned the simulated entities.
• Challenges stemmed from the differences in
  fidelity of the JTLS and EADSIM simulations.
• JTLS aggregate-level EADSIM entity-level
• Certain items (e.g. entity locations) must be
  extrapolated when transferring data from JTLS to
  EADSIM
• EADSIM also had to handle more data than to which
  it is usually accustomed.

21
JTLS-EADSIMTime Management

• All federates ran as regulated and constrained.
• Most time management work was devoted to
  development of a new federate, Pacer, to regulate
  game time
• While development of a pacing federate would seem
  to be straightforward, many subtle issues arose
• Ability to pause federation or change game rate
  requires that there is not already a pending time
  advance
• Longer time steps needed when trying to advance
  very quickly

22
JTLS-EADSIMUser Perspective

• JTLS-EADSIM federation was a success at the Lucky
  Sentinel exercise.
• All components were stable, allowing desired
  training to occur.
• Use of HLA proved far superior to a prior
  exercise that integrated JTLS and EADSIM with a
  file sharing mechanism.
• Much more detailed data passed between
  simulations
• Interface more dynamic and efficient
• Causality ensured with HLA time management

23
Outline

• Introduction
• JTLS-NATO Federation
• JTLS-EADSIM Federation
• Future of JTLS Federations
• Conclusions

24
Future of JTLS Federations

• Both JTLS and EADSIM have migrated to RTI NG
• Problems encountered with RTI 1.3v7 are no longer
  applicable
• NC3A has not yet migrated their NATO C2 systems,
  and it is uncertain when or if this will be
  funded
• Next year, JTLS will also be used in federations
  with the Global Command and Control System (GCCS)
  and the Joint Conflict and Tactical Simulation
  (JCATS)
• GCCS linkage will evolve a 2-way interface
  between simulation and C4I system
• JCATS integration will allow representation of
  entity-level objects

25
Outline

• Introduction
• JTLS-NATO Federation
• JTLS-EADSIM Federation
• Future of JTLS Federations
• Conclusions

26
Observations

• HLA was an excellent enabler for reuse.
• From the training audiences perspective, the use
  of JTLS with HLA was positive.
• Federations that test the limits of the RTI may
  experience unexpected problems.
• RTIs are still maturing
• You might discover a new bug!

27
Recommendations

• Design your federation with performance in mind.
• Develop an initialization mechanism to ensure
  data integrity while reducing redundant updates.
• For complex federations, plan several formal test
  events.
• For long-running applications, produce crash
  recovery procedures for every component in the
  federation.