Comprehensive Mine and Sensor Simulation Functional Overview

1. Comprehensive Mine and Sensor SimulationFunctional Overview Mid Self Deputy Director, Modeling & Simulation CECOM RDEC Night Vision & Electronic Sensors Directorate mid.self@nvl.army.mil 703-704-1285

2. Intelligent Munitions SystemConcept Economy of Force • Remote deployment • 15 – 50 Km • Rocket, Mortar, Helo, AVN • Extended communications • Air and/or ground relays • Networked, smart engagement strategy 40 - 50 Km Intelligent Munitions System Troop Cdr Tactical UGS ARES 15 Km Precision Strike UA CDR AREMS

3. Smart UGS Cluster • 4 multi-mode sensors working as an integrated cluster • 3 non-imaging acoustic/seismic nodes • Each node as 3 microphone array • Cluster gateway node with imaging & non-imaging sensors • Cluster computes target classification, range and line of bearing estimates based on acoustic/seismic sensor response • When target range < 500m, cluster cues IR sensor to LOB and captures an image • Image and target report are sent to Human in the loop controller Acoustic footprint from ABFA

4. Smart UGS Components 12 cm dia • Gateway with imaging IR sensors • 8 lbs • 1 per M87A1 volcano canister • Cluster • 1 Gateway • 3 Pointers • Equivalent to 155 mm M718 RAAM payload • Non-imaging “pointer” node • 2.5 lbs • 3 per M87A1 volcano canister 36 cm 96 cm Stowed Deployed Non-imaging Sensors Comm module Processor Power source 12 cm 12 cm

5. Generic IMS Model 2 WATAM ~ 20 SM 2 WATAM ~ 20 SM 2 WATAM ~ 20 SM • Smart UGS Field • Support the munitions field • Target recognition, ID, and BDA • Target location & tracking for supporting IDF • Feeds the FCS C4ISR • C2 FCS Battle Command System • Universal Controller • Intelligent Munitions • Wide Area Top Attack Munition (WATAM)-AT/AV • Smart Munition (SM)-AT/AV/AP Comm Relay ~ 200 m SUGS Cluster Coverage Area ~ 500 m ~ 200 m Integrated suite of sensors, C2 system & munitions

6. Intelligent Munitions Systems • Wide area top attack munitions • 3 microphone acoustic array • Seismic sensor • Target classification • Range & LOB estimation • Engage when closest point of approach < 100 m • Smart AT Munitions • Single microphone acoustic array • Seismic sensor • Target classification • Range & LOB estimation • Engage when target range < 5 m

7. UGS/IMS Control • All FCS vehicles have common C2 system • UGS/IMS share common sensor architecture and communications • UGS/IMS controller is a SW module that runs on the common C2 system • UGS/IMS gateway module communicates via standard FCS combat net radio • LOS range approx 8 km • UGS/IMS communicate using a standard message and data structure • Sensor Interface and Access Management System • Any controller can initialize and assume control of an UGS/IMS cluster • Control can be passed from one controller to another

8. UGS Reporting to the Network • UGS cluster generates target reports each time they detect a target • Gateway node in the field filters these reports before sending them to a controller to prevent the field from constantly chattering (and to reduce simulation network load) • Gateway node uses three criteria: • Target reports are re-transmitted after a configurable timeout (default timeout is 1minute) • Reports are transmitted once the target moves a configurable distance (default distance is 500m) • Report is sent immediately if the acquisition level is upgraded

9. UGS Controller Model • Human in the loop controller receives the target spot reports sent by UGS clusters • Controller maintains a database of targets reports • When a target spot report is received, the report is fused into the target database using the following algorithm: • Quad-tree lookup is performed for existing targets using a configurable region of interest • ROI is scaled according to reported velocity, so that fast-moving targets are fused properly • For targets close enough to report location, target types are compared • If existing target with compatible type is within query region, the targets are considered to be same • Existing or previous target’s location and velocity are updated • If the spot report provides more detailed information than the database had on the target, then the target type and acquisition level are upgraded • If no target with a compatible type is within the query region, or no targets are within the query region, a new target is generated • Targets, which are not updated for a configurable amount of time, have their acquisition certainty downgraded • Once the certainty reaches zero, the target is removed form the database

10. Comprehensive Mine and Sensor Server (CMS2) • Redesign of CERDEC NVESD/ ARDEC FSAC Comprehensive Mine Simulator • Operates as a server to primary force-on-force simulation engine (OneSAF Testbed, JCATS, etc) • Allows large scale simulation of mines or distributed sensors with minimal network burden • Scaleable to the simulation environment and task • Models may run on multiple processors or machines • Low to high fidelity • Physics-based sensor models • NVESD Acquire IR search and target acquisition model • ARL Acoustic Battlefield Aid • ERDC CRREL Seismic Rule-of-Thumb model • System models • Composable “UGS’ model (can vary sensor configurations) • Conventional and smart AT and AP • Dispersion patterns for a variety of deployment mechanisms

11. CMS2 Data Flow Architecture OTB 1 Publishes environment variables 1 Publishes target state data (truth) 1 Publishes “deployment” event for creation of UGS/IMS field • Calculates target damage state 1 Sends target damage to network CMS2 1 Instantiates UGS/IMS field 1 Publishes location & status of individual mines/UGS • Computes in-field go/no-go message completion & delay • UGS/IMS go dormant until interaction with target entity 1 Monitors target locations/states • Sends detonation event to SAF OTB Target entity enters UGS/IMS ROI • Calculates Pd/Pc/Pr • Calculates estimated target range & velocity • Calculates target track 2 Sends/updates target “spot” report from field 2 Sends detonation event to controller 1 2 2 / 3 2 / 3 1 = Ground truth 2 = Perceived truth w/out comm effects 3 = Perceived truth with comm effects 2 / 3 3 MITL Controller • Monitors field activity • Sends commands to field (arm / detonate / neutralize / etc) CES • Simulates tactical network & comms effects

12. CMS2 Architecture CMS2 “Federation” CMS2 Core IMS “Platform” (System) Model Infrastructure / Terrain Library / Map GUI / RTI Interface / etc Command & Control Logic Attack Logic Sensor Fusion Model Target Tracking Model Sub-system Models Other as required Contractor Provided Models or Data Subsystem Model Data or Model Services Contractor Provided Models or Data Munitions Model/Data Acoustic Model/Data Seismic Model/Data Other as required Comms Image Server

13. “0th” Order Multi-mode Sensor P =0.95 Class|Det P =0.85 Class|Det Radial Ranges (km) Acoustic/Seismic/Magnetic Ground Sensor Model Look up tables derived from higher fidelity model Radial Ranges (km) P = 0.95 @ 0.6 km det P = 0.85 @ 1 km det Probability of Detection (Pdet) Light Heavy Light Heavy Wheeled Wheeled Tracked Tracked 0.50 0.50 1.00 1.00 0.70 0.70 2.00 2.00 PDet=0.70 PDet=0.85 0.25 0.25 0.50 0.50 0.35 0.35 1.00 1.00 PDet=0.95 0.15 0.15 0.35 0.35 0.25 0.25 0.60 0.60 Probability of Probability of Classification Classification Given Given (P (P ) ) Detection Detection Class Class | | Det Det Pclass|Det=0.85 >0.25 >0.50 >0.35 >1.00 P = 0.70 @ 2 km det UGS Parameters for Heavy Tracked Vehicle 0.25 0.50 0.35 1.00 Pclass|Det=0.95

14. 1st Order Acoustic Model • Rule-of-thumb look up tables generated by the Acoustic Battlefield Aid • Variable target, terrain, and environmental parameters • Based on field derived data • CMS2 implementation • 10 specific targets • 4 generic targets • Low / medium / high speed • Day vs night • Light vs moderate-heavy wind • Open grassy vs forested terrain • Gentle rolling vs mountainous terrain

15. 1st Order Seismic Model Geology andTopography Target Forces h ¶ s ¶ ¶ s ¶ s u xy r = + + + xx xz f x/t x ¶ ¶ ¶ ¶ t x y z INPUT INPUT 3-D PropagationPhysics • Rule-of-thumb look up tables generated by ERDC CRREL seismic model • Modular algorithms based on hi-fidelity simulation • Field derived target and environment approximations • Low computational burden • CMS2 implementation • 3 generic targets (tracked / wheeled / human) • Variable speed • APG homogeneous costal ("normal" silty sands) • YPG homogeneous desert aluvium (strong sandy attenuation) • CRTC unconsolidated glacial till (highest attenuation)

16. “2nd” Order Acoustic/Seismic Model • Currently evaluating two approaches for a dynamic, real-time implementation of AFBA and Seismic ROT models • Background model to generate on-the-fly look up tables • Specific to sensor, terrain location, environment • Periodic updates to accommodate environment changes • Incorporate algorithm modules directly into CMS2 • Scalability • Requires synthetic target signature generators for both spectra Each block below represents a run-time code module or library input Target and Environment Sensor System Target (Type, speed, direction) • Detection • Information • Bearing • Range • Track • Class • (w/Statistical variations based on field observations Signature (Sum of Harmonics) Signal Level (Propagation) Sensor Thresholds S Environment Parameters Background Noise (Empirical) Receiver Directivity Index/ Geophone Transfer Function Input Output

17. Acoustic/Seismic Sensor Fusion for Target Location • Acoustic model (ABFA) outputs a single target location estimate with an error estimate (circular ellipse) • Seismic model outputs “n” sample estimates of target location • Generally an ellipse with better range than azimuth accuracy • NVESD computes weighted center of mass and error estimate of the “n” samples • We then compute a weighted center of mass of the intersection of the 2 ellipses Location error output from Acoustic model Area of intersection Northing Location error output from seismic model UGS center of mass Easting

18. Example Acoustic Detection Models Day / Flat / Forest Day / Flat / Grass Night / Flat / Forest Night / Flat / Grass NSfOF UGS Cluster – light wind

19. Example Target Location Models NSfOF UGS Cluster – seismic sensor components 1024 samples per second 2 second integration time Tracked Vehicle Coastal Region at 400mLine of Bearing STD = + 5 deg; Range STD = + 46 mAverage Location Error = + 53 m Tracked Vehicle Coastal Region at 800mLine of Bearing STD = + 10 deg Range STD = + 71 mAverage Location Error = + 125 m

20. Traditional Software Design Approaches • Top-Down Design • Advantages: Cohesive system architecture due to higher-level abstractions • Disadvantages: Minimal code reuse, potentially poor performance • Bottom-Up Design • Advantages: Efficient, reusable code • Disadvantages: Hard to foresee how low-level pieces will serve overall architecture

21. Software Development Approach • Bi-Directional ('Sandwich') Design • Top-Down: Application-level components based on Architectural Design Patterns • Bottom-Up: Simulation Libraries, each written to satisfy a domain-specific requirement • Top-Down portion is relatively simple because we use well-known solutions • Most of our time is spent developing domain-specific libraries

22. Software Hierarchy Applications UC GEC CMS2 Snap Server Simulation Libraries Interface Libs: ALCES, DaVinci, DIS 2.0.4, JVB, SEM GUI Libs: GLCanvas, GnomeUtils, GTK2Scheme, MapGUI, MapRenderer, Overlays, Symbols Miscellaneous Libs: GeomUtils, Coordinates, Joysticks, NITF, ATM, XMLUtils Roam Libs: RoamCore, RoamContext, RoamPluginManager, BasePlugins, SimPlugins, ShapeFile Sim Libs: CommEffects, Detection, Entity, Munitions, Sensors, TargetDatabase Invoke Open-Source Libraries Scheme Libs: scheme-access, config-system, command-line, data-streams, scheme-utility, shader-lib Base Libs:utility, multicast, threadlib, data_streams, sim_utility, sim_math

23. CMS^2 Design • CMS^2 represents mines and sensors internally as individual, high-fidelity 'field entities'. • Field entities are assembled from component objects such as target sensors and warheads. • New field entities may be assembled from existing components by modifying data files. No programming effort is required as long as the necessary components exist. • Field entity behavior can be modified without re-compilation by modifying scripts and data files. This can even be done at run-time.

24. CMS^2 Design • Component objects encapsulate all data and logic need to model themselves. Existing components include: • Target sensors • Tripwire, Pressure fuse, Tiltrod, Acoustic (ARL model), Seismic, Magnetic, Passive IR • Munitions • AP warhead, AT warhead, Shape charge, Top-attack fly-out, grenades • Mine Casings • Metallic, Plastic, Wooden • Miscellaneous • Transmitter, Receiver, Antenna, CPU, Battery

25. CMS^2 Design • Field entities are grouped into fields. • Fields are a convenient, familiar concept that allow the user to manipulate large numbers of entities as a whole. • Fields reduce network load. CMS^2 publishes one message that describes an entire field instead of a separate message for each entity within that field.

26. CMS^2 Design • Scalability • CMS^2 can represent very large numbers of field entities without reducing modeling fidelity. • Geometric algorithms are used to eliminate all out-of-range target-sensor pairings. • Performance data is pre-calculated whenever possible. • Example: ARL statistical detection tables. • Efficient coding practices streamline the target detection process. • A single CMS^2 workstation has modeled 140,000 mines while tracking 25,000 target entities.

27. CMS^2 Design • Current work • Extract the CMS^2 simulation module into a separate back-end process. • Implement a controller process which manages multiple back-ends running on separate processors or workstations. • Modify the CMS^2 GUI to communicate with the controller process. • When complete, a user will be able to create and simulate millions of mines and sensors through a single CMS^2 GUI at the existing level of fidelity.

28. Simulation Libraries • Define domain-specific vocabularies ('interfaces') • Usable (and reusable) at the binary level • Encapsulate and establish resource management policies • Encapsulate algorithms

29. Library Advantages • Flexibility/Adaptability • Can be used in the native environment of any experiment or system • Examples: UACEP (DIS), LSI Capstone (JVB), C4ISR OTM (DaVinci) • Can be composed in different ways, depending on requirements (scalability, simplicity, reliability) • Doesn't require us to predict future environments • Reusability • Approximately 85% of the code written for CMS^2, UC, Snap Server, and other applications is in the simulation libraries • Changes to a library are reflected in all applications that use it • Scalability • Not limited by the scalability of communication infrastructure • Programs that use libraries are as scalable as the libraries themselves • Libraries scale up and down

30. Implementation Details • Algorithms are encapsulated for easy upgrading • Examples: GLCanvas, SymbolRenderer • Each library sets resource management policies • Examples: LibDetection • Libraries make no assumptions about the process environment • Examples: LibDIS

31. IMS “Platform/System” Simulation • Utilize CMS2-Armament Server Federation as the “system” simulation of IMS • UA / FCS warfighter-in-the-loop simulations (Generic IMS) • LSI SoSIL integration and interoperability testing (contractor specific designs) • IMS PAT support and augmentation (contractor specific designs) • Utilize CMS2 as surrogate T-UGS to provide Layer 1 sensor information to IMS • PM-RUS is funding use of CMS2 to support FCS T-UGS development • Utilize Government-LSI defined data/messaging interface (Sensor Data Link) between the IMS field and the FCS network • Sensor Data Link (SDL) data and message framework under development by PM-NV/RSTA and NVESD • SDL will be the “standard” interface from T-UGS to FCS C2 network • CMS2 readily supports implementation of tactical messaging interface to support IMS in the SoSIL • Migrate to MATREX simulation architecture when that environment becomes mature and available • Armament server is core component of MATREX • PM-FCS has previously funded integration of CMS2 into JVB • CMS2 architecture readily supports “decoupling” of embedded sensor services IAW the proposed MATREX architecture • NVESD is tracking the migration of JVB to MATREX

32. IMS HW/SW-in-the-Loop Simulation (Proposed) FireSim OTB C4I Gateway IPS 1&2 CMS2 “Federation” Contractor Provided Models or Data CMS2 Core Acoustic Model/Data Seismic Model/Data Other as required Comms Munitions Model/Data Image Server Target Emulator IMS Innerfield Simulation Net IPS 3+ Tactical Message XLATOR Engage Mgr Gateway Prototype Munitions / Sensor Prototype Tactical CS / UC Surrogate HWIL Tactical IMS Net Tactical C2 Net Tactical C2

33. Other Features & Planned Upgrades • DIS message interface • Spotted PDUs • Signal PDUs • HLA interface • JVB FOM • MATREX FOM migration • Tactical message interface (XML) • Heartbeat (periodic entity status and SA update) • Contact report (target acquisition) • Target track database • Correlation algorithm to minimize multiple reports on same target • 2nd Order sensor algorithm implementation • Sensor Data Link message interface • Improved acoustic/seismic fusion algorithm • ATR implementation for UGS imagers • Additional sensor types (magnetic, impulse radar) • Embedded intra-field communications & network model • Integration with external communications effects server

34. FCS Interoperability • PM-NV/RSTA is funding the definition and development of Sensor Data Link as a proposed new standard • Migration of SLP messages to Joint Variable Message Format transport protocol • LSI reviewing for incorporation into FCS architecture • NVESD is funding Sensor Interface and Access Management System (SIAMS) • Provides the data structure and messaging formats for the NSfOF ATD • Provides a flexible prototyping methodology to develop new message/data requirements and data management techniques • FCS LSI is responsible for developing a sensor data management architecture for FCS • PM CCS is responsible for developing a command and control, and information architecture for integrating IMS with FCS and T-UGS • SDL/SIAMS provides a common framework for the basis of the interface from IMS & T-UGS to FCS • CMS2 architecture supports the implementation of tactical messaging (SDL) to support or stimulate the development and testing of tactical or sensor command and control systems

35. Recommended FCS Interoperability Approach T-UGS IMS Fusion Soldier CMS2 FCS Information Management Layer Cluster IV Systems Common Data & Message Interface (Sensor Data Link) Target Msg. Status Msg. Self-Position Msg. C2 (local) Tasking Attack Guidance Sensor Performance data Target Msg. Status Msg. Self-Position Msg. Target Reports Status Msg. Self-Position Msg. UGS/IMS Control API Tasking Tasking FCS NET2 Sensor Comm. interface Sensor Fusion Target Msg. Status Msg. Self-Position Msg. Fused data Tasking Raw data Target Msg. Status Msg. Self-Position Msg. NET1 Tasking

36. Development Methodology • Spiral development of PM-NV/RSTAs proposed Sensor Data Link standard • Requirements development and prototyping demonstrations using NVESDs SIAMS and DSIF development environments • Focus on standards to govern how sensor data is integrated into the common operating picture • Compatible with the current Tactical Internet, but structured to take advantage of a future, and more robust FCS TI • Define a common means to store, catalog, and maintain, and then facilitate the transfer of sensor data • Evolve from focus on unattended systems to an architecture that addresses tactical sensor interfaces: • Vehicle or platform to-from a remote sensor • Remote communications gateway to-from a remote sensor • Vehicle or platform to-from an on-board sensor • Soldier to-from soldier-carried or weapon mounted sensor • Ground control or processing station to-from a remote sensor

37. SIAMS(Sensor Interface and Management System) User Application Header String of Data Key/Data Structures Encryption/Special Functions Data Link/Network The SIAMS effort is divided in two parts: • The development and implementation of a message protocol – (Sensor Data Link & future extensions called “Portable Sensor Data” (PSD) – that communicates between sensor systems and control stations • The development of a Sensor Information Management Layer (SIML) to facilitate the communication between distributed sensor systems and Command and Control Systems MC2 S I M L C 2 A P I SUAV Sensor Cloud SDL/PSD UGS M&S UGV CETS SEAMS SDL • FBCB2 Legacy Sensors PSD Translator . . .

38. Bit Steam View of Transmitted Message SDL Message User Application Header String of Data Key/Data Structures Encryption/Special Functions Data Link/Network Portable Sensor Data

39. Identify the Information to be Sent Example: Spot Report/Target Detection Fields • Date Time Group (DTG) • Sensor SYSTEM Type • Self Location • Self Heading • Self Speed • Sensor (Component) Type • Search Area: • Field of Regard - Left • Field of Regard - Right • Maximum Range • Target Track: • DTG • Target Reference • Target Location • Target Heading • Target Speed • Target Identification • Target Classification • Target Image (file)* *Depending on File Size, Bandwidth, etc. the image may be included or sent separately.

40. Generate the PSD Message Portion TGT SPEED Speed (m/s) SELF SPEED Speed (m/s) “Data Key” TARGET IMAGE <Filename.jpg> TARGET CLASS Reference No. DTG (ZULU) Year, Month, Day, Hour, Minutes, Seconds SYS TYPE System Name (e.g., UGV) SELF LOCATION Latitude, Longitude, Altitude MSL, Datum SELF HEADING Degrees (True North) SEARCH AREA Left FOR (deg) Right FOR (deg) FOR Max Range TARGET REF Reference No. TARGET LOC Latitude, Longitude, Altitude MSL, Datum TGT HEADING Degrees (True North) TARGET ID Type/ID COMP TYPE Type (e.g., FLIR) Field 1, Field 2, Field 3, …, …, Field N The SIAMS Message is formed by the concatenation of the desired data structures.

41. The “PSD” Portion is packed into the User Data Portion of the overall SDL Bit Steam Other necessary components are assembled (e.g., User Application Header, Network Header/Footer) Bit Steam is then transmitted as a complete message Complete the Bit Stream and Transmit

42. Summary • CMS2 provides a proven and affordable platform to support such simulation and experiment events • Government owned software • 2-4 PC servers can support simulation with 10,000’s of entities • CMS2 is now the primary simulation tool being used to represent and support development and evaluation of UGS and IMS • Networked Sensors for the Objective Force ATD • Spider APLA • Intelligent Munitions Systems for FCS • Tactical UGS • UA MBL