Merging Approaches for CBML

1
A Model Driven Architecture (MDA)Approach
Supporting PEO SoldierUsing IWARS, OneSAF, and
Combat XXI LTC Robert KewleyDepartment of
Systems Engineering United States Military
Academy Dr. Andreas TolkDepartment of
Engineering Management and Systems
Engineering Old Dominion University
2
Outline

• The Soldier as a System
• Operational requirements PEO Soldier
• The PEO Soldier Simulation Roadmap
• How to use MS in support of Acquisition
  Evaluations
• History and Current State of the Project
• Where we come from
• Where we are going
• The role of OneSAF
• Technical Points of General Interest
• Applying the Model Driven Architecture

3
The Soldier as a System

• operating in a virtual world
• integrated into the System of Systems

4
Soldier System

• PEO Soldier has the task to optimize
  theequipment of Soldiers
• Soldier as a System
• Improvements of one capability may result in
  decreasing another capability
• Example Body Armor improves Survivability but
  decreases Mobility
• Challenge How are the ilities connected?
• Soldier in the System of Systems
• Improvement of the System Soldier may result in
  decreasing of other capabilities
• Example Body Armor and Transportability
• Challenge How are the Systems interconnected?

Typical System Engineering/SoSE Tasks
5
Soldier System in the Virtual World

• Based on the requirements, we can identify
• mission essential tasks
• required capabilities
• required associations
• metrics to measure success
• Systems are not generally available, i.e.
• virtual system can be set up
• accepted virtual systems can be used to set up
  the environment
• Multiple levels are needed,
• to generate the operational context
• to conduct the detailed analysis

6
Soldier as a System
Soldier as a System Engineering And Value
Analysis
Joint Systems and Requirements
Army Requirements
Soldier Simulation and Analysis
Other Quantitative Analysis
Qualitative Analysis
Program and Supplemental Budgets
Current Future Operating Environment
7
The PEO Soldier Roadmap

• How to use MS in Support ofAcquisition
  Evaluations

8
PEO Soldier Simulation Road Map

• Purpose
• Develop a modeling federation that integrates
  the capabilities of IWARS, OneSAF, and Combat XXI
  in order to analyze the effects of soldier as a
  system design alternatives on tactical missions.
• Objectives
• Develop standards (Terrain, Scenario description,
  HLA object model)
• Develop HLA integration and infrastructure
• Continue algorithm development in individual
  models
• Develop analysis capabilities for federation
• Replication, Data management, Time management

• Technical Approach
• Refine PEO analysis needs
• Assign analysis tasks to individual models
• Focus on HLA interoperability
• Support federation development with model driven
  architectures
• Work toward analysis capability

• Deliverables
• Working IWARS-OneSAF HLA Federation
• Code stubs for Combat XXI HLA integration
• Development plan for AY2009
• Technical report

9
Overview of the PEO Soldier Project Family

• Where do we come from?
• Where are we?
• Where are we going?

10
History of the Project

• PEO Soldier commissioned study in 2003
• Previous studies
• AY 03-04 Recommended 3-model approach (IWARS,
  Combat XXI, OneSAF)
• AY 04-05 Developed modeling requirements
• AY 05-06 Developed agreements and approach
• AY 06-07 Achieved file based interoperability

Current TargetSetting-up a Federation for PEO
Soldier Support
11
The Current Team

• Guidance (PEO Soldier)
• Management and oversight (ORCEN)
• MS interoperability expertise (VMASC)
• Development
• IWARS Nattick Soldier Center
• OneSAF PEO STRI
• Combat XXI TRAC White Sands

• Literature review
• Levels of Conceptual Interoperability Model
  (Tolk)
• Model Driven Architectures (MDA) (Eyermann and
  Casanave)
• RDECOMs MATREX Project
• Federation Development and Execution Process
  (FEDEP)
• MDA tools for simulation interoperability
  (Simplicity)

QuestionsWhat Middleware to use? Which
version?What Tools support the
Development? Alternative Evaluation for System
Engineering Principles?
12
Technical Points ofGeneral Interest

• Applying the Model Driven Architecture
• For operational Requirement Analysis
• for technical Integration Support

13
Model Driven Architecture
CIM

• Model Driven Architecture
• Computer Independent Model (CIM)
• Operational Idea, high-level view
• Platform Independent Model (PIM)
• Algorithmic Solutions
• Identifies classes, associations, etc.
• Platform Specific Model (PSM)
• Code-level solution
• Platform and language specific
• All models are connected via transformation
  patterns
• Similar system engineering view like captured in
  DoDAF (OV, SV, TV) and as supported by the
  Military Missions and Means Framework (MMF)

OV
MissionMeans
PIM
SV
SystemCapabi-lity
PSM
TV
Com-ponent MOE
14
Application of MDA
15
Use Case 1 MDA for Operational Requirements

• PEO Soldier looks at new equipment
• Operational question What tasks are effected?
• Look tasks up in Mission Essential Task List(or
  related list of relevant tasks, such as UJTL)
• Construct or reuse scenarios that comprise
  all identified tasks in relevant contexts
• Alignment with MSDL necessary to improve
  efficiency
• Common registry for scenarios and vignettes based
  on agreed METL (or alternatives)
• Identify how to measure capability
  increase/decrease

ResultAn implementation independent list of
systems and their capabilities in the context of
scenarios and vignettes incl. metrics
16
Example Operational Scenario

• Situation. Based on intelligence from a local
  source, a US squad engaged in counter-insurgency
  operations has planned a raid to capture an
  insurgent leader in the town of Shugart-Gordon.
  Multiple sources of intelligence have confirmed
  the location of the leader at . Additionally,
  they have reported that his cell members have
  stationed themselves on rooftops within the town
  to identify potential Coalition forces and
  provide early warning to their leader. They also
  have mortar support. The citizens of
  Shugart-Gordon have fled the village, and it is
  primarily used as an insurgent planning and
  training center.
• Mission. 1/1/A/1-5CAV conducts raid at
  011500MAY08 at 31.1057N 91.1193W in order to
  capture local insurgent leader and deny the use
  of Shugart-Gordon as a training sanctuary.
• Execution. The purpose of this operation is to
  capture the local insurgent leader in order to
  gain further intelligence about insurgent
  operations. At the end of this operation, we
  would like to have the insurgent leader alive and
  in Coalition custody with no Coalition
  casualties. Because the citizens of
  Shugart-Gordon have fled the area, collateral
  damage is of little concern. 1st squad will
  conduct the raid with direct support from the
  mortar section. They will conduct the raid in
  three phases, mounted movement, dismounted
  movement, and clearing the objective. During the
  operation, one fire team will provide overwatch
  while a second fire team enters the objective
  building to capture the insurgent leader and
  clear it of enemy fighters. Mortar fires will be
  used to help clear rooftops of enemy fighters.

17
Identified Missions and Means

• Missions (and Capabilities)
• Infantry in Urban Operations
• Close Combat in Buildings
• Mounted and Dismounted Operations
• Call for Fire (focus report of coordinates of
  hostile forces)
• Supporting Fire of Mortars

• Means (and Systems)
• Infantry (Combatants)
• HMMVs
• Mortars

ResultIdentification of Classes, Objects,
Activities, and Sequences
18
Use Case 2 MDA for Model Assignment

• The Scenario is mapped to the simulation and
  evaluation capabilities of available systems
• Example
• OneSAF
• Soldiers (mounted and dismounted)
• Mortar Fire
• IWARS
• Soldiers (dismounted)
• Effect of Direct Fire
• Effect of Indirect Fire

19
Use Case 3 Supporting the Federation

• Based on the Scenario-Model mapping (or
  traditional analysis), the interfaces between the
  systems are identified
• Who is in charge of which objects
• Which FOM elements are needed to update
  attributes
• Which Interactions are needed
• What is the overall sequence of updates and
  actions directly derived from the scenario

20
Technical Results of Use Cases 1-3

• Model Independent description of the Scenario
• Alignment with MSDL is an open challenge
• Model Specific (but Middleware independent)
  Sequence and Update Scenario
• Who is responsible for what part of the Scenario
• What are the metrics used to evaluated
  capabilities
• How is the execution orchestrated
• Middleware Specific Artifacts
• Model Specific Sequence is translated in
  Middleware specific call between the model
  interfaces
• HLA 1.3 NG or HLA 1516
• DIS, TENA, ALSP
• Other formats, such as web service calls

21
Summary

• Where are we now

22
Summary

• Current Project Phase has two parallel tasks
• Task One Federation Development
• OneSAF and IWARS developers build a federation
• Task Two MDA Support Evaluations
• VMASC documents the decisions in UML
• CIM, PIM, and PSM are generated
• Feasibility of all use cases are demonstrated
• Immediate use for next phase
• HLA stubs for the integration of Combat XXI
• Evaluation of MDA-based MS tools (such as
  SIMPlicity)
• Project Management support with additional
  artifacts