Using Extensible Markup Language for Composability of C4I Devices in Warfighter's Simulation 2000

1
Using Extensible Markup Language for
Composability of C4I Devices in Warfighter's
Simulation 2000

• Jude Anthony
• SAIC Orlando

2
JSIMS

• WARSIM is a JSIMS federate
• So are NASM, MARITIME, JOINT
• All JSIMS federates must use a common set of
  simulation tools
• Common Component WorkStation (CCWS)
• Scenario Generation tool

3
JSIMS Interoperability

• FOM
• Common, jointly-defined data store
• Metadata defining how FOM data can be organized
  and combined
• Defined by each federate individually
• Schema and rules defined by the CCWS developers

I defined the metadata for the C4I Interface
federate
4
C4II Physical Architecture
TOC
CPI
TOC
CPI
5
C4II Logical Architecture
Command Post Interface
TOC
InterfaceManager
TAInteractionManager
Translator
JSIMSInteractionManager
CMP Interface
USMTF Determinator
USMTF Determinator
6
C4II Logical Architecture (cont)
Command Post Interface
Simulation
C4IIHandler
TAInteractionManager
C4IIRemoteInSim
JSIMSInteractionManager
7
C4II Components TOCHandler
TOC

• Represents an entire TOC, or the hardware
  interfacing with the TOC
• Start point for creating units at scenario
  generation time
• Single point for initializing C4II software

CPI
8
C4II Components C4IHandler

• Simulation endpoint of all communications for a
  single device

Simulation
C4IIHandler
TOC
C4IIRemoteInSim
9
C4II Components InterfaceManager

• A single path of communications for a single
  device

Command Post Interface
InterfaceManager
TAInteractionManager
Translator
JSIMSInteractionManager
CMP Interface
USMTF Determinator
USMTF Determinator
10
Arranging the Components

• All we need in order to represent - and
  communicate with - any TOC is the right
  combination of C4II components
• The combination of components is specified in the
  simulations initialization data

11
The FOM

• Physical things in the simulation correspond to
  object FOs persistent data items within the
  FOM
• C4II object FOs correspond to initialization
  data, with one per software module
• Most C4II object FOs are in the
  initialization.land.c4i. hierarchy
• A few are under c2_artifacts.land.state.

12
The Metadata Schema

• To allow an SG analyst to add a C4II to the
  simulation, the metadata schema must
• Define entities and software models
• Classify groups of interchangeable entities
• Organize entities into children and parents
• Associate entities with software models
• Associate FOs with software models

13
Defining Entities
14
Defining Software Models
15
The Metadata Schema

• To allow an SG analyst to add a C4II to the
  simulation, the metadata schema must
• Define entities and software models
• Classify groups of interchangeable entities
• Organize entities into children and parents
• Associate entities with software models
• Associate FOs with software models

16
Interchangeable Groups
17
The Metadata Schema

• To allow an SG analyst to add a C4II to the
  simulation, the metadata schema must
• Define entities and software models
• Classify groups of interchangeable entities
• Organize entities into children and parents
• Associate entities with software models
• Associate FOs with software models

18
Children and Parents
19
Children and Parents (cont)
20
The Metadata Schema

• To allow an SG analyst to add a C4II to the
  simulation, the metadata schema must
• Define entities and software models
• Classify groups of interchangeable entities
• Organize entities into children and parents
• Associate entities with software models
• Associate FOs with software models

21
Associating Entities and Models
22
The Metadata Schema

• To allow an SG analyst to add a C4II to the
  simulation, the metadata schema must
• Define entities and software models
• Classify groups of interchangeable entities
• Organize entities into children and parents
• Associate entities with software models
• Associate FOs with software models

23
Associating FOs and Models
24
Shortcomings

• Specifying X of Y choices
• Specifying the FOs that go with an entity

25
The C4II Metadata
Groups
C4I Device
Comm Path
c2_artifacts.land.state.toc_handler
C4II
initialization.land.c4i.c4i_handler
MCS
initialization.land.c4i.c4i_handler
via Email
26
The C4II Metadata
DomainConcrete1
JclBundle.C4II
C4II
DomainConcrete2
JclBundle.C4I_Device
C4I Device
27
The C4II Metadata
JCLBundle.C4II
LNMCTOCHandler
LNMCTOCElement
JCLBundle.C4I_Device
LNMCC4IHandler
Comm Path
LNMCC4IElement
28
Putting it Together

• The SG analyst composes the C4II from entities,
  constrained by the rules in the metadata, and
  fills out any specific data in all the FOs
• The SG tool puts the appropriate models and FOs
  in the scenario file
• The simulation uses the scenario file to
  initialize and run the scenario

29
Conclusion

• Using this component model, we can construct a
  C4II interface to talk to devices in any TOC
• The schema allows us to specify components and
  how they are related
• This strategy could be used to compose an
  interface to a TOC in other simulations