GTpF: Georgia Tech Radar proto Federation

1
GTpF Georgia Tech Radar proto Federation

• Presented by
• David W. Roberts
• dw.roberts_at_gtri.gatech.edu

2
Experimental Objectives

• Sept. 1996 How will HLA affect GTRI simulations?
• Modeling and simulation pervasive across GTRI
• Develop new simulations
• Use existing simulations
• Internally sponsored project with goals similar
  to DMSO protofederations
• To create a federation of legacy simulations
• To gain experience in leveraging from existing
  legacy simulations to build HLA compliant
  federations

3
Georgia Tech proto Federation

• A constructive simulation involving
• Target Engagement Radar (TER) federate based on
  radar simulator
• Propagation and backscatter federate based on
  J-MASS environment and target players
• Engineering domain
• Build on legacy simulations with new HLA
  interface code

4
GTpF Block Diagram
Shaded boxes indicate software developed or
modified under this project
5
GTpF Network System Architecture Overview
6
GTpF Characteristics

• New FOM developed
• RTI version 1.0.3
• No routing spaces or DDM
• Used OMDT to build object models
• HLA compliance was NOT certified
• Object models were NOT submitted to Library
• Development process based on FEDEP, with
  allowance for use of legacy simulations
• Time management was a critical issue

7
Critical Issue Time Management

• GTpF integrates periodic (TER) and event-driven
  (JMASS) simulations
• TER federate is synchronous, based on physical
  radar system design
• JMASS federate is event-driven, based on
  complexities of real world propagation modeling
• Lookaheads differ by orders of magnitude
• JMASS lookahead 5ms based on minimum range
• TER lookahead 16ms based on subframe intervals

8
Time Management - contd

• RTI allows interleaving of simulation events
• Scheduling may occur at any time in future
• Retrieval based on simulation requirements
  (NextEventRequest or TimeAdvanceRequest)

9
Time Management in GTpF

• TER time management mirrors system behavior
• Uses received signals to calculate
  TransmittedSubFrame mode
• Passes transmission description to socket I/F
• I/F schedules TransmittedSubFrame with RTI
• I/F listens for ReturnSignals and passes to TER

10
Time Management in GTpF

• JMASS time management is event-based
• ProxyRadarPlayer schedules periodic updates to
  tick the RTI and look for TransmittedSubFrame
• ProxyRadarPlayer reacts to receive incoming
  return pulses, converting them to ReturnSignals
  sent to RTI

11
Time Management in GTpF

• When TransmittedSubFrame is received, JMASS
  player
• Schedules another periodic update at the end of
  the subframe
• Updates antenna position and schedules return
  signals for next lookahead time
• Reacts to incoming return pulses until next
  TransmittedSubFrame

12
Modeled Sequence
Pulse Descriptor Calculation Time
Returns Received
XMTR lookahead
XMTR
Pulse Group
Time
Returns
Returns

JMASS RF Player
Pulse Received
JMASS Fedt lookahead
Returns Calculated and Sent
13
Simulation Event Order
New Pulse Group Calculated
Pulse Group Calculated
Pulse Group Scheduled
XMTR
XMTR lookahead
Returns received in time order
Time Advance Request
Time Advance Grant
RTI Mediation of Events
Time Advance Grant
Next Event Request
Fedt lookahead

JMASS RF Player
JMASS blocked just prior to next external event
Pulse Group Received
Returns are calculated and scheduled up to the
next possible external event
echoes
14
Major Milestones

• July 1996 - Project initiation
• June 1997 - GTpF demonstrated
• March 1998 - Design of Distributed Simulation
  Interface Framework
• June 1998 - Alpha version of DSIF
• November 1998 - DSIF released to GTRI community
• June 1998 - DSIF made available to community for
  mutually beneficial research

15
HLA Lessons Learned

• Object Model Development
• Not all legacy simulations are good candidates
  for HLA compliance
• A FOM is not necessarily a simple sum of SOMs
• Building a SOM for one particular FOM only is
  shortsighted and limits future opportunities for
  the legacy simulation to join other federations

16
Lessons Learned - continued

• Network traffic considerations affect data format
  decisions
• Split up pulse_data parameter structure
• Middleware can be useful in adapting legacy
  simulations to HLA
• Automatic generation of C header files from
  standard FOM files
• Data conversion from datatypes to strings and
  back
• Standard task automation
• Time management issues

17
Summary and Conclusions

• Middleware can be useful in adapting legacy
  simulations to HLA
• Much of that conversion process can be automated
• Tools can enable the conversion to be
  accomplished by simulation subject matter
  experts, lessening the need for HLA experts