Military Simulation Case Study

1. Military Simulation Case Study Victor Jimenez Sr. Engineer, Northrop Grumman victor.jimenez@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 – 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

9. 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

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 DON’T 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 • 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!

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 CGF’s • 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