Embed Size (px)
Citation preview
Comprehensive Mine and Sensor Comprehensive Mine and Sensor SimulationSimulation
Functional OverviewFunctional Overview
Mid SelfDeputy Director, Modeling & Simulation
CECOM RDEC Night Vision & Electronic Sensors
703-704-1285
Intelligent Munitions SystemIntelligent Munitions SystemConceptConcept
Remote deployment 15 – 50 Km Rocket, Mortar, Helo, AVN
Extended communications Air and/or ground relays
Networked, smart engagement strategy
Tactical Tactical UGSUGS
Tactical Tactical UGSUGS
Troop Cdr
Intelligent Intelligent Munitions Munitions
SystemSystem
Intelligent Intelligent Munitions Munitions
SystemSystem
UA CDR
ARES
AREMS
15 Km
40 - 50 Km
Economy of Force
Precision Strike
Smart UGS ClusterSmart 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
CommRelay
NSfOF Cluster Coverage Area
~ 500 m
~ 200 - 400 m
CommRelay
NSfOF Cluster Coverage Area
~ 500 m
~ 200 - 400 m
Acoustic footprint from ABFA
Smart UGS ComponentsSmart UGS Components
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
Stowed
36 cm
Deployed
96 cm
Non-imaging Sensors
Comm module
Processor
Power source
12 cm
12 cm
12 cm dia
Generic IMS ModelGeneric IMS Model
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
CommRelay
SUGS Cluster Coverage Area
2 WATAM~ 20 SM
~ 2
00
m
2 WATAM~ 20 SM
~ 2
00
m
2 WATAM~ 20 SM
~ 500 m
Integrated suite of sensors, C2 system &
munitions
Intelligent Munitions SystemsIntelligent 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
UGS/IMS ControlUGS/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
UGS Reporting to the NetworkUGS 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
UGS Controller ModelUGS 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
Comprehensive Mine and Sensor Comprehensive Mine and Sensor Server (CMS2)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
CMS2 Data Flow ArchitectureCMS2 Data Flow Architecture
OTB 1 Publishes environment
variables1 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 field1 Publishes location & status of
individual mines/UGS Computes in-field go/no-go
message completion & delay UGS/IMS go dormant until
interaction with target entity1 Monitors target locations/states1 Sends detonation event to SAFOTB Target entity enters UGS/IMS
ROI Calculates Pd/Pc/Pr Calculates estimated target
range & velocity Calculates target track2 Sends/updates target “spot”
report from field2 Sends detonation event to
controllerCES Simulates
tactical network & comms effects
MITL Controller Monitors field activity Sends commands to field
(arm / detonate / neutralize / etc)
1
22 / 3
3
2 / 3
2 / 31 = Ground truth2 = Perceived truth w/out
comm effects3 = Perceived truth with
comm effects
CMS2 “Federation”
Subsystem Model Data or Model ServicesSubsystem Model Data or Model Services
CMS2 CoreIMS “Platform” (System) ModelIMS “Platform” (System) Model
CMS2 ArchitectureCMS2 Architecture
Command & Control Logic
Sensor Fusion Model
Target Tracking
Model
Other as
required
Contractor Provided Models or DataContractor Provided Models or Data
Attack Logic
Infrastructure / Infrastructure / Terrain Terrain
Library / Map Library / Map GUI / RTI GUI / RTI
Interface / etcInterface / etc
ImageServerComms
MunitionsModel/Data
AcousticModel/Data
SeismicModel/Data
Other as required
Contractor Provided Models or DataContractor Provided Models or Data
Sub-system Models
““00thth” Order Multi-mode Sensor ” Order Multi-mode Sensor
UGS Parameters for HeavyTracked Vehicle
Probability of Classification Given
Detection (PClass|Det )
1.000.350.500.25
>1.00>0.35>0.50>0.25
0.600.250.350.15
1.000.350.500.25
2.000.701.000.50
Heavy Tracked
Light Tracked
Heavy Wheeled
Light Wheeled
Probability of Classification Given
Detection (PClass|Det )
Pclass|Det=0.85
0.600.250.350.15
1.000.350.500.25
2.000.701.000.50
Probability ofDetection (Pdet)
Radial Ranges (km)
Pdet = 0.70 @ 2 km
Pdet = 0.85 @ 1 kmPdet = 0.95 @ 0.6 km
Radial Ranges (km)
PClass|Det=0.95
PClass|Det=0.85
Acoustic/Seismic/Magnetic Ground Sensor Model
Look up tables derived from higher fidelity model
Pclass|Det=0.95
PDet=0.95
PDet=0.85
PDet=0.70
11stst Order Acoustic Model 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
11stst Order Seismic Model Order Seismic Model
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)
Target Forces
x/t
x
xzxyxx
fzyxt
u
3-D Propagation Physics
Geology andTopography
INPUT
INPUT
Signature(Sum of
Harmonics)
Signal Level(Propagation)
BackgroundNoise
(Empirical)
Geophone Deployment
Transfer Function
SensorThresholds
DetectionInformation– Bearing– Range– Track – Class(w/Statistical
variations based on field observations
EnvironmentParameters
Target(Type, speed,
direction)
Target and Environment Sensor System
InputOutput
““22ndnd” Order Acoustic/Seismic Model” 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
Signature(Sum of
Harmonics)
Signal Level(Propagation)
BackgroundNoise
(Empirical)
Receiver Directivity Index/
Geophone Transfer Function
SensorThresholds
DetectionInformation– Bearing– Range– Track – Class
(w/Statistical variations based on field observations
EnvironmentParameters
Target(Type, speed,
direction)
Target and Environment Sensor System
InputOutput
Acoustic/Seismic Sensor Fusion Acoustic/Seismic Sensor Fusion for Target Locationfor 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
Easting
No
rth
ing
Location error output from Acoustic model
Location error output from seismic model
UGS center of mass
Area of intersection
Example Acoustic Detection Example Acoustic Detection ModelsModels
Day / Flat / Forest Day / Flat / Grass
Night / Flat / Forest
NSfOF UGS Cluster – light wind
Night / Flat / Grass
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
<300 450 600 750 900 1050 1200 1350 1500 1650
Range (meters)
T72
BMP
ZIL131
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
<300 450 600 750 900 1050
Range (meters)
Pro
bab
ility
of D
etec
tion
T72
BMP
ZIL131
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
<300 450 600 750 900 1050
Range (meters)
Pro
ba
bili
ty o
f D
ete
cti
on
T72
BMP
ZIL131
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
<300 450 600 750 900 1050 1200
Range (meters)
Pro
bab
ility
of D
etec
tion
T72
BMP
ZIL131
Example Target Location ModelsExample Target Location Models
NSfOF UGS Cluster – seismic sensor components1024 samples per second2 second integration time
Tracked Vehicle Coastal Region at 400m
Line of Bearing STD = + 5 deg; Range STD = + 46 m
Average Location Error = + 53 m
Tracked VehicleCoastal Region at 800m
Line of Bearing STD = + 10 deg Range STD = + 71 m
Average Location Error = + 125 m
Traditional Software Design Traditional Software Design ApproachesApproaches
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
Software Development ApproachSoftware 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
Software HierarchySoftware Hierarchy
Invoke Open-Source Libraries
UC
Simulation Libraries
Snap ServerCMS2GEC
Applications
GUI Libs: GLCanvas, GnomeUtils, GTK2Scheme, MapGUI, MapRenderer, Overlays, Symbols
Interface Libs: ALCES, DaVinci, DIS 2.0.4, JVB, SEM
Miscellaneous Libs: GeomUtils, Coordinates, Joysticks, NITF, ATM, XMLUtils
Roam Libs: RoamCore, RoamContext, RoamPluginManager, BasePlugins, SimPlugins, ShapeFile
Sim Libs: CommEffects, Detection, Entity, Munitions, Sensors, TargetDatabase
Scheme Libs: scheme-access, config-system, command-line, data-streams, scheme-utility, shader-libBase Libs:utility, multicast, threadlib, data_streams, sim_utility, sim_math
CMS^2 DesignCMS^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.
CMS^2 DesignCMS^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
CMS^2 DesignCMS^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.
CMS^2 DesignCMS^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.
CMS^2 DesignCMS^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.
Simulation LibrariesSimulation Libraries
Define domain-specific vocabularies ('interfaces') Usable (and reusable) at the binary level Encapsulate and establish resource management
policies Encapsulate algorithms
Library AdvantagesLibrary 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
Implementation DetailsImplementation 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
IMS “Platform/System” SimulationIMS “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
IPS
3+
IPS
1&
2
CMS2 “Federation”
IMS HW/SW-in-the-Loop Simulation IMS HW/SW-in-the-Loop Simulation (Proposed)(Proposed)
Tactical CS / UC Surrogate
CMS2 CoreOTB
ImageServer
Tactical C2 Net
HWIL Tactical IMS Net
IMS Innerfield Simulation Net
Engage MgrGateway Prototype
Munitions / SensorPrototype
Comms
Tactical C2
C4I Gateway
Tactical MessageXLATOR
MunitionsModel/Data
AcousticModel/Data
SeismicModel/Data
Target Emulator
Other as required
Contractor Provided Models or Data
FireSim
Other Features & Planned Other Features & Planned UpgradesUpgrades
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
FCS InteroperabilityFCS 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
Sensor C
omm
. interface
Sensor F
usion
AP
I
IMS
T-UGS
Soldier
Cluster IVSystems
Common Data & Message Interface
(Sensor Data Link)
FC
S N
ET
2
Recommended FCS Interoperability Recommended FCS Interoperability ApproachApproach
FCSInformation
Management Layer
NET1
C2
(local)
Target Msg.Status Msg.Self-Position Msg.
Attack Guidance
Tasking
Tasking
Target ReportsStatus Msg.Self-Position Msg.
Tasking
CMS2
Target Msg.Status Msg.Self-Position Msg.
Target Msg.Status Msg.Self-Position Msg.
UGS/IMSControl
FusionRaw data
Fused data
SensorPerformance data
Tasking
Target Msg.Status Msg.Self-Position Msg.
Tasking
Development MethodologyDevelopment 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
The SIAMS effort is divided in two parts:1. 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
2. The development of a Sensor Information Management Layer (SIML) to facilitate the communication between distributed sensor systems and Command and Control Systems
SUAV
UGV CETS
UGSSI
ML
Legacy Sensors PSD Translator SDL
C 2
API
MC2
M&S
SEAMS
FBCB2...
Data Link/Network Encryption/Special Functions
User Application Header String of Data Key/Data Structures
Sensor Cloud SDL/PSD
Sensor Cloud SDL/PSD
SIAMSSIAMS((Sensor Interface and Management System)Sensor Interface and Management System)
Bit Steam View of Transmitted Bit Steam View of Transmitted MessageMessage
Data Link/Network Encryption/Special Functions
User Application Header String of Data Key/Data Structures
Portable Sensor Data
SDL Message
Identify the Information to be SentIdentify 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.
Generate the PSD Message PortionGenerate the PSD Message Portion
“Data Key”
Field 1,Field 2,Field 3,…,…,Field NDTG (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)
SELF SPEED
Speed (m/s)
COMP TYPE
Type (e.g., FLIR)
SEARCH AREA
Left FOR (deg)Right FOR (deg)FOR Max Range
The SIAMS Message is formed by the concatenation of the desired data structures.
TARGET REF
Reference No.
TARGET LOC
Latitude,Longitude,Altitude MSL,Datum
TGT HEADING
Degrees (True North)
TGT SPEED
Speed (m/s)
TARGET ID
Type/ID
TARGET CLASS
Reference No.
TARGET IMAGE
<Filename.jpg>
Complete the Bit Stream and Complete the Bit Stream and TransmitTransmit
DTG (ZULU)*
Year, Month,Day, Hour,Minutes,Seconds
SYS TYPE
<SystemName>
SELF LOCATION*
Latitude,Longitude,Altitude MSL,Datum
SELF HEADING*
Degrees (True North)
SELF SPEED*
Speed (m/s)
COMP TYPE
FLIR
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)
TGT SPEED*
Speed (m/s)
TARGET ID
Type/ID
TARGET CLASS
Reference No.
TARGET IMAGE*
<Filename.jpg>
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
Summary 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
