Comprehensive mine and sensor simulation functional overview
This presentation is the property of its rightful owner.
Sponsored Links
1 / 42

Comprehensive Mine and Sensor Simulation Functional Overview PowerPoint PPT Presentation


  • 44 Views
  • Uploaded on
  • Presentation posted in: General

Comprehensive Mine and Sensor Simulation Functional Overview. Mid Self Deputy Director, Modeling & Simulation CECOM RDEC Night Vision & Electronic Sensors Directorate [email protected] 703-704-1285. Intelligent Munitions System Concept. Economy of Force. Remote deployment 15 – 50 Km

Download Presentation

Comprehensive Mine and Sensor Simulation Functional Overview

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Comprehensive mine and sensor simulation functional overview

Comprehensive Mine and Sensor SimulationFunctional Overview

Mid Self

Deputy Director, Modeling & Simulation

CECOM RDEC

Night Vision & Electronic Sensors Directorate

[email protected]

703-704-1285


Intelligent munitions system concept

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


Smart ugs cluster

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


Smart ugs components

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


Generic ims model

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


Intelligent munitions systems

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


Ugs ims control

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


Ugs reporting to the network

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


Ugs controller model

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


Comprehensive mine and sensor server cms2

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


Cms2 data flow architecture

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


Cms2 architecture

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


0 th order multi mode sensor

“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


1 st order acoustic model

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


1 st order seismic model

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)


2 nd order acoustic seismic model

“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


Acoustic seismic sensor fusion for target location

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


Example acoustic detection models

Example Acoustic Detection Models

Day / Flat / Forest

Day / Flat / Grass

Night / Flat / Forest

Night / Flat / Grass

NSfOF UGS Cluster – light wind


Example target location models

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


Traditional software design approaches

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


Software development approach

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


Software hierarchy

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


Cms 2 design

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.


Cms 2 design1

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


Cms 2 design2

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.


Cms 2 design3

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.


Cms 2 design4

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.


Simulation libraries

Simulation Libraries

  • Define domain-specific vocabularies ('interfaces')

  • Usable (and reusable) at the binary level

  • Encapsulate and establish resource management policies

  • Encapsulate algorithms


Library advantages

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


Implementation details

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


Ims platform system simulation

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


Ims hw sw in the loop simulation proposed

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


Other features planned upgrades

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


Fcs interoperability

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


Recommended fcs interoperability approach

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


Development methodology

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


Siams sensor interface and management system

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

.

.

.


Bit steam view of transmitted message

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


Identify the information to be sent

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.


Generate the psd message portion

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.


Complete the bit stream and transmit

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


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


  • Login