Use of OneSAF in Complex Web Defense: Progress Report

1. Use of OneSAF in Complex Web Defense:Progress Report Larry RiegerPaul MondayEngin Z. Altan ARCIC JAMSD Lockheed MartinSAIC Inc. BLCSE Technical Manager Mounted Warfare Testbed BLCSE Experimentation Support Team

2. Agenda • Background • CWD Experiment Architecture • Terrain • Classified Performance Data • Experiment-Specific Models • DIS and HLA Specific changes • Operational Usage • Lessons Learned • Future Development for BLCSE Use • Summary

3. Background • What is TRADOC ? • What is the Battle Lab Collaborative Simulation Environment (BLCSE)? • DIS background of BLCSE • Highly customized OneSAF Test Bed, OTB, entity driver usage in BLCSE Experiments • First use of OneSAF V1.5.1 OF in a BLCSE Distributed Event.

4. CWD Description • Objectives: • To inform the Tactical Maneuver Capabilities Based Assessment (CBA) • Enable adjustments to the Abrams and Bradley Capability Development Documents (CDD) • Inform the Intelligence, Surveillance and Reconnaissance (ISR) Concept Capability Plan (CCP) • Shape the Way-Ahead for HBCT Modernization • Timeframe: 2017 • Threat: 2017-2024 • BLUFOR Description: BCT (HICON) and enablers: • HBCT CAB: Ft Knox • Stryker BN: Ft Benning • Fires: Ft Sill • Aviation: Ft Rucker • Air Defense: Ft Bliss • C4ISR: SMDC, Huntsville • Execution Construct: • Asymmetric Threat War-game (ATWG) 8-11 JAN 08 • and Mid Planning Conference (MPC) • Computer Assisted Map 3-7 MAR 08 Exercise (CAMEX) /TNG (5 days) • Rehearsals and Pilot Run (5 days) 10-14 MAR 08 • Simulation Exercise (SIMEX) 17-28 MAR 08 Record Runs (10 days) • Federation Architecture: DIS-HLA Hybrid, distributed to six sites • Classification: Secret

5. NetRouter OTB MCT OTB OTB HLA Interop SimCore MCT SimCore NetRouter SimCore MCT OTB Middleware MCT OTB OTB OTB HLA Interop SimCore MCT SimCore MCT SimCore NetRouter DIS Interop DIS Interop DIS Interop DIS Interop DIS Interop MCT MCT MCT MCT MCT CWD Experiment Architecture(OTB & OneSAF Only) MMBL – Ft Knox SBL – Ft Benning DIS Compressed DIS (WAN) HLA OneSAF

6. Terrain • Over 3000 buildings across one geocell • Created using Presages TerraVista • UHRB/MES buildings from U2MG • Struggled with numerous terrain issues, tiling, build and load issues • Lack of proficiency in producing OTF terrain (first time production headache) • Even Presages lacked proficiency in solving some OTF production challenges • Steep learning curve of OTF-specific issues

7. Compliance with BLCSE FOM Some messages are required by the BLCSE federation. • Outgoing Spot Report for SA Server • Outgoing Mounted Entity for SA Server • Incoming Effect from Effects Server • Incoming Dynamic Terrain from DT Server.

8. Use of Classified Performance Data • Sensor and Weapon data supplied by TRAC-WSMR – converted from OOS 1.0 to AMSAA format • Sensor and Weapon Components supplied by TRAC-WSMR • Entity Compositions created by MWTB

9. Open OneSAF Functionality Needs Sensor Model (Acquire) • Partial Exposure not taken into account • Sensor selection (DVO vs IR) didn’t work Weapon Model • Gaps in performance data are hidden from user • Developed additional surrogation model to fill gaps • Developed Parameter Display with data validation to find gaps PTRs to follow as part of post-event process

10. Experiment-Specific Models Scenario was based on a moderately-armed, dismounted force evading detection by hiding and by blending with the civilian population - Armed / Unarmed • Entities could “drop” their weapons by unloading their ammo, or by disabling their weapon. Other simulations needed to show the Unarmed entity as indistinguishable from a Civilian • Red < - > Green • OneSAF entities became Unarmed by switching sides to Neutral

11. Experiment-Specific Models(Cont.) • Dig-in / Concealed • Entities could hide by assuming a dugin position and/or becoming Concealed • Building effects • All entities in a building were killed if the building was destroyed • Illumination calculated using offset time • Start time – used time in scenario instead of wall clock

12. OneSAF Fixes and ModificationsFiles Changed

13. OneSAF Fixes and Modifications • Model double tap: every model ticked twice each frame. Fixed with OneSAF-supplied software. It is fixed in V2.0 • Entity speed didn’t honor terrain slope • Sensor FOV model didn’t work • FCS entities couldn’t move after dark • Added safety checks within PVD to handle TDB issues without crashing the MCT All fixed “on the spot” – developing PTRs or OneSAF-standard code for inclusion in baseline

14. OneSAF Fixes and Modifications(Cont.) • Weapon model: detonation result wasn’t always set properly • Clear Room: ICs sometimes walked through walls, leaving and re-entering room • Dynamic Terrain: Indication added to show which buildings had been destroyed by DT Server Developing PTRs or OneSAF-standard code for inclusion in baseline

15. OneSAF Fixes and ModificationsDIS Interop • DIS Interop sent Entity State PDUs for remote entities • DIS Interop didn’t support multicast Developing PTRs or OneSAF-standard code for inclusion in baseline

16. HLA based OneSAF Interoperability HLA based OneSAF used in Solder Battle Lab (SBL) at Ft. Benning PLANNING • Created a Gateway with Middleware (MW) and OTB based Net Router • Software Configuration Management (CM) • BLCSE Experimentation Support Team (BEST) Integration Section (IS) supports SBL (On site)

17. OneSAF Fixes and Modifications – HLA • HLA Interop • Added enumerations for CWD vehicles and individual combatants (IC) • Modified MATREX FOM for new Objects and Interactions • Created Salute Report Converter to send out spotted report information Developing PTRs or OneSAF-standard code for inclusion in baseline

18. OneSAF Fixes and Modifications – HLA (Cont.) • Provided solution to allow a functional light-weight checkpoint of OneSAF operating in HLA environment • Fixed bug which prevented the HLA Interop node from being able to rejoin the OneSAF cluster and send HLA interactions and objects after a crash or shutdown • Created a new OneSAF Interop composition that allowed HLA Interop standalone node to have the same join and resign functionality that only existed previously when running with MCT Developing PTRs or OneSAF-standard code for inclusion in baseline

19. OneSAF Fixes and Modifications – HLA (Cont.) • Upgraded network switch to 1-Gbit from 100-Mbit to handle traffic load within the cluster • This is a known requirement; included in OneSAF documentation • Modified Entity Creator and HLA Interop to allow “operator” role to be able to view all external friendly entities Developing PTR or OneSAF-standard code for inclusion in baseline

20. Federation/OTB/OneSAF Configuration Management (CM) • MMBL at Ft Knox lead CM (part of Technical Lead function) • Lack of CM tool usage presented challenges to federate and federation integration • Files (patches, etc) were manually transferred successfully • Communications’ importance between teams/sites cannot be understated • Enumerations (DIS-HLA-OneSAF) CM is essential when using a federation

21. Operational Usage • Blue Stryker BN (SBL) • Movement to Contact Attack • Red Insurgent BN (MMBL) • Urban operations in defense • Used terrain features (trees, buildings) to hide • Mixed with Civilian population • 7000 entities in exercise • ~22 entities per OneSAF station in DIS mode

22. Operational UsageHLA • At Ft. Benning an HLA cluster operated 400 medium resolution entities in 1 large cluster as a single simulation • Cluster composed of: • 1 Battlemaster MCT • 1 HLA Interop • Approximately 20 Operator MCT • Approximately 10 SimCores • OneSAF functioned well in large cluster. Due to this functionality, it was able to retain OneSAF internal data sharing without loss of translation going over HLA/DIS

23. Future Development • Improve data validation checking • Improve portrayal of Insurgents in a Civilian population (Armed / Unarmed) • Add more BLCSE features • Full support for Dynamic Terrain Server • Interface with mine detection protocol • Reliable checkpoints and autosave Developing PTRs or OneSAF-standard code for inclusion in baseline

24. Lessons Learned • Proper integration time is important • Lost 5-6 weeks of integration work due to lack of event funding (Federal Budget issue) • First use of hybrid DIS-HLA architectures added complexity • Intent is to move to HLA in FY09 • First large-scale use of OneSAF in a large-scale distributed event added complexity • Need to follow established Configuration Control/Configuration Management procedures • Additional complexity of hybrid architectures and multiple federates makes this a requirement, not a “nice to have” • Multiple OTB enhancements/releases needed for event success drove at least as many OneSAF and other federate modifications • Event Management is important in distributed events • Communications between event technical lead and outlying sites is essential for efficient problem identification, troubleshooting, and solution implementation • Engage PM OneSAF for event support earlier rather than later • PM wants OneSAF to be successful, will provide resources within capability to assist integration and problem solving efforts • PM needs to monitor PTR submissions more closely – particularly when event integration is ongoing

25. Summary • Many problems, but it was usable • Plan in advance • After much work by the entire CWD Team (including PM OneSAF), OneSAF met basic requirements for use in CWD • Significant technical expertise required • Need better support from OneSAF group • Part of this was not getting PM engaged earlier in the process • Some problems are the result of OneSAF design decisions • Either need established work-arounds, or re-design • Further use and user comments will improve OneSAF