Embed Size (px)
Citation preview
Overview
• Military Simulation Architecture
• Distributed Training Problems
• Implemented Solution
• Towards a Common Operational Picture
Simulation Architecture
• Different Types of Simulations– Live– Constructive– Virtual
• We will limit ourselves to 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
• 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
• 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
• 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
• 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
• 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
• 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!
AHA!
Even though the simulators are built distributed,
THEY DON’T PLAY WITH EACH OTHER!
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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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
• 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.
• 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
• 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• 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
