Military Simulation Case Study

1
Military Simulation Case Study

• Victor Jimenez
• Sr. Engineer, Northrop Grumman
• victor.jimenez_at_ngc.com

2
Overview

• Military Simulation Architecture
• Distributed Training Problems
• Implemented Solution
• Towards a Common Operational Picture

3
Simulation Architecture

• Different Types of Simulations
• Live
• Constructive
• Virtual
• We will limit ourselves to Virtual Simulations

4
Virtual Simulations

• Place the warfighter into the midst of the action
• Also called man-in-the-loop sim
• May or may not control path through world
• Has a first person perspective (sort-of)
• Flight sims are virtual

5
Flight Simulation Architecture

• The ownship is a distributed application
• Physics, Haptics, Weather, Combat Resolution may
  be separate computers
• Graphics is usually a cluster of computers
• May have a motion platform
• Computers for an ownship usually talk private
  protocol over separate network
• Usually talk to external platforms using standard
  protocol on an external network

6
Standard Protocols

• Distributed Interactive Simulation (DIS)
• Broadcasts entire state of an entity
• Has different packets (PDU) for each action
• IEEE1278.1a is last version
• High Level Architecture (HLA)
• Sends only update of what changed
• Has Objects and Interactions separated
• IEEE1516 is latest

7
Distributed Training Problems

• Has to be fast
• Has to be reliable
• Has to work in a WAN configuration
• Has to be AFFORDABLE!
• In terms of Bandwidth
• In cost to implement
• Problems with protocols
• Problems with conception of battlespace

8
Protocol Issues - DIS

• DIS broadcasts cant send over long haul WAN
  unless some type of bridge is setup
• Bridge is very hard to set up for more than 2
• Additional Bandwidth costs
• Hard to manage what is sent
• Usually, you just didnt want the data anyway

9
Protocol Issues - HLA

• Assumes that Multicast groups are free
• ATM doesnt support multicast
• HLA is an interface
• IEEE 1516 support is just starting
• No IIOP specified
• Data sent is defined on the fly doesnt
  necessarily match what other guy uses

10
Common Battlespace Issues

• Your training mission defines your battlespace
• Differences in fidelity crop up
• Differences in what you implement appear
• Differences in how you use the protocol
• IMPEDANCE MISMATCH OCCURS!

11
AHA!

• Even though the simulators are built distributed,
• THEY DONT PLAY WITH EACH OTHER!

12
Integrate vs Interoperate

• Integrate means that things are reworked to
  create one common way to do things
• Everybody becomes the same
• Interoperate means that disparate systems can
  talk to each other have limitations
• Everybody stays the the same

13
The Path Less Followed

• We decided to interoperate
• Couldnt change other companys simulations
• Didnt want to change since this would lead to
  having continuously changing sims
• Didnt make sense since each has a different
  battlespace
• We wanted to isolate each site from each other
• Oh, the Horror!

14
Implemented Solution

• Created ATM cloud
• Tie individual sites into cloud with appropriate
  edge device
• Created an architectural device to handle
  impedance problems
• Customized Software
• Runs on normal computers under W2K

15
Standards, Standards, Standards

• Defined Standards
• Network Services and Setup
• Protocol Representation
• Object Representation
• Certify different sites as to level of
  compatibility
• Sites work with other sites with some limits

16
Object Model TIM

• Had a series of Technical Information Meetings
  (TIMs) to discover what is important to each
  site
• Figured out mapping from local representation to
  global objects

17
Lost in the Translations

• We realized we needed to created never-fail
  software
• The Key is Test, Test and Test Some More
• Sequence of testing steps
• Unit tests
• Factory Acceptance
• Scenario test with CGFs
• Integrate on Site

18
Unit Tests

• Just for the particular software unit - written
  first!
• Created by the programmer to test
• normal running conditions
• boundary conditions
• tricky calculations
• Whatever else fails later on
• Automated, runs before check-in
• Requires discipline lots of it

19
Factory Acceptance Testing

• Test Cases created by the test team
• Inputs and Outputs defined by requirements
• Programming team involved only to create tools
• Uses carefully crafted data
• Runs every night in an automated fashion
• Immediate feedback to Programmers
• Not necessarily representative (oops!)

20
Scenario Testing

• Needed something to cover data gap
• Between CGF from MTC and other standard CGFs
• Run manually by test team
• Slowly being automated, requires Deep Knowledge
  and understanding
• Longer cycle (2 weeks) to run

21
On Site Integration

• Install lines, equipment, software
• Testing On the Site
• Using actual equipment
• Typical small scenario
• Surprises still occur!
• Mini-Development Cycle we can change things
  with impunity

22
Towards a C.O.P.

• Common Operational Picture
• Subset of the battlespace that everybody
  understands well enough to work
• Standards continue to evolve
• Protocols
• Capabilities
• New Simulators
• Updated Simulators
• New Training objectives

23
Change Review Board

• Found out we need this to manage complexity
• Too many changes occurring due to different
  development schedules
• Need to coordinate rollout of capabilities and
  needs

24
Conclusion

• Networks are message passing architectures
• Provide abstraction
• Contracts between participants formalized in
  standards and models
• Not perfect but close enough
• Very useful to have something in the middle
• Manage bandwidth
• Prioritize data
• Translate to/from COP
• Hide network details from users