military simulation case study l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Military Simulation Case Study PowerPoint Presentation
Download Presentation
Military Simulation Case Study

Loading in 2 Seconds...

play fullscreen
1 / 24

Military Simulation Case Study - PowerPoint PPT Presentation


  • 170 Views
  • Uploaded on

Military Simulation Case Study. Victor Jimenez Sr. Engineer, Northrop Grumman victor.jimenez@ngc.com. Overview. Military Simulation Architecture Distributed Training Problems Implemented Solution Towards a Common Operational Picture. Simulation Architecture.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Military Simulation Case Study' - grizelda


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
military simulation case study

Military Simulation Case Study

Victor Jimenez

Sr. Engineer, Northrop Grumman

victor.jimenez@ngc.com

overview
Overview
  • Military Simulation Architecture
  • Distributed Training Problems
  • Implemented Solution
  • Towards a Common Operational Picture
simulation architecture
Simulation Architecture
  • Different Types of Simulations
    • Live
    • Constructive
    • Virtual
  • We will limit ourselves to Virtual Simulations
virtual simulations
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
flight simulation architecture
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
standard protocols
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
distributed training problems
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
protocol issues dis
Protocol Issues - DIS
  • DIS broadcasts – can’t 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 didn’t want the data anyway
protocol issues hla
Protocol Issues - HLA
  • Assumes that Multicast groups are free
  • ATM doesn’t support multicast
  • HLA is an interface
  • IEEE 1516 support is just starting
  • No IIOP specified
  • Data sent is defined on the fly – doesn’t necessarily match what other guy uses
common battlespace issues
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!
slide11
AHA!

Even though the simulators are built distributed,

THEY DON’T PLAY WITH EACH OTHER!

integrate vs interoperate
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”
the path less followed
The Path Less Followed
  • We decided to interoperate
    • Couldn’t change other company’s simulations
    • Didn’t want to change since this would lead to having continuously changing sims
    • Didn’t make sense since each has a different battlespace
  • We wanted to isolate each site from each other
  • Oh, the Horror!
implemented solution
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
standards standards standards
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
object model tim
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
lost in the translations
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 CGF’s
  • Integrate on Site
unit tests
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
factory acceptance testing
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!)
scenario testing
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
on site integration
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
towards a c o p
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
change review board
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
conclusion
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