Improving Interoperability: A C4IM

1
Improving InteroperabilityA C4I-MS Reference
Object Model(C-ROM)

• Verlynda S. Dobbs, Ph.D.
• William P. Sudnikovich
• Atlantic Consulting Services, Inc.
• Shrewsbury, NJ
• vdobbs_at_acsinc-nj.com, wsudnikovich_at_acsinc-nj.com

2
Simulation to C4I InteroperabilityIssues

• Lack of alignment documented by studies
• Different models data models for tactical
  systems, object models for simulations
• Multitude of translation interfaces resource
  intensive and error prone
• Strategy AMSEC chartered SIMCI OIPT

3
C-ROMProject Description

• Funded by SIMCI OIPT and DUSA(OR)
• Reference Object Model, implemented in Unified
  Modeling Language (UML)
• Captures requirements for interoperability
  between C4I and MS systems
• Reference for both tactical and simulation system
  development

4
C-ROM What is a Reference Object Model?

• Based on Object Oriented concepts
• Objects are the nouns from the vocabulary of
  the domain
• Relationships exist between the objects
• Represented in class diagrams with classes,
  attributes and operations
• Provides a generic template
• Represents more than a single perspective
• Does not specify a design

5
C-ROM Key Requirements

• Use NATO Land C2 Information Exchange Data Model
  (LC2IEDM) with extensions from GH5 as starting
  model requirement resulted from thorough
  evaluation of several possibilities
• Align with current JCDB Data Model (JDM)
• gtBoth models build on 5 key entities of the
  domain organization, materiel, facility,
  feature, person

6
C-ROM Three Phase Approach

• Each phase incorporates specific entities from
  the domain
• Phase I Organization and Materiel
• Phase II Feature, Facility, Person
• Phase III Planning and Battle Management
  Language

7
C-ROM Phase I Class Hierarchy
8
C-ROM Phase I Organization Class Hierarchy
9
C-ROM Phase I Materiel Class Hierarchy
10
C-ROM Phase I Equipment Class Hierarchy
11
C-ROM Phase I Analysis for Usability

• Issues that result due to transformation from the
  initial starting point include
• Object model has artifacts of data model
• Two separate class hierarchies exist object
  type and object item
• Class hierarchies uneven and inconsistent

12
C-ROM Phase ITwo Class Hierarchies
ITEM
TYPE
13
Two Categories of InformationWhy are they
needed?

• To represent the set of relationships required
  for a robust model for C4I
• Described in LC2IEDM documentation
• Establishments
• Holdings
• Classification
• Association
• Status
• Capabilities
• Assignment

14
Required RelationshipsEstablishments

• Authorizations that associate under specified
  conditions an object type with specific numbers
  of other object types
• Example A UK Armoured Regiment (an object type)
  could be authorized in peace time 48 Challenger
  MBTs and 25 Bradleys (both object types)

15
Required RelationshipsHoldings

• Possession of object types by object items.
• Example The 101st UK Armoured Regiment (an
  object item) has (is holding) 40 operational
  Challenger MBTs (an object type)

16
Representing Object Type and Object Item
Information 2 Options

• Establish one class hierarchy that contains both
  object type and object item information
• Maintain two class hierarchies one for object
  type and one for object item information

17
Discussion of Alternatives Option 1

• Establish one class hierarchy that contains both
  object type and object item information
• Requires collapsing the Object Type and Object
  Item hierarchies to eliminate the Type hierarchy
• Requires adding a new mechanism to support the
  required relationships
• Conclusion no elegant mechanism to support the
  required relationships

18
Discussion of Alternatives Option 2

• Maintain two class hierarchies one for object
  type and one for object item information
• Best technical approach based on requirements
• Requires fewer changes to Phase I Model
• Approach taken by LC2IEDM and JDM

19
Benefits of Phased Development

• Opportunity to analyze the resulting model and
  set clear direction for follow on phases
• Incorporate enhancements before proceeding
• Establish symmetric object type and object item
  hierarchies (increases understandability)
• Examine and allocate existing attributes based on
  whether they are static or dynamic
• Apply relationships to the hierarchies
  consistently

20
Phase IDemonstration Description

• Classes for organization and materiel entities to
  be demonstrated
• Process
• Instantiate an object model built from C-ROM
  using a C4I database populated with a tactical
  scenario
• Initialize a simulation system using the data
  from the object model
• Accomplished with no human operator intervention
  or translation function

21
Demonstration Data Flow
22
Future Efforts

• Complete Phase I demonstration
• Continue development by incorporating Phase II
  and Phase III entities
• Develop a set of use cases
• Create standards package

23
Issues

• JCDB scheduled to be eliminated and replaced by a
  query service (the information is still required)
• Need for community participation
• Acceptance of resulting model
• Working Group membership is open

24
Conclusion Key Points

• C4I - MS interoperability is of critical
  importance to support Army Transformation
• A standard reference model will facilitate
  implementations
• Community awareness and consensus is critical for
  standardization efforts
• Final products will be posted on SIMCI website
  https//simci.army.mil