The Application of the DoDAF within the Federation Development Process

1
The Application of the DoDAF within the
Federation Development Process

• Mike deSylva
• Robert Lutz
• Scott Osborne
• Johns Hopkins University
• Applied Physics Laboratory

2
Overview

• Introduction
• DoDAF Overview
• FEDEP Overview
• DoDAF Overlay on FEDEP
• Summary

3
Introduction

• Background
• A well thought out architectural description of a
  modeling and simulation federation leads to
• a better federation design
• enhanced communications among developers
• simplified VVA
• composability and reuse
• DoDAF defines a common, standardized approach for
  DoD architecture descriptions

4
Why use DoDAF for MS

• DoDAF lends itself to describing a federation
  architecture
• A federation is a system
• The DoDAF defines multiple views that can be used
  to document many aspects federation requirements
  and design
• Why use DoDAF instead of another standard?
• Common across the DoD
• Mandated for new DoD acquisition programs
• Understood by both technical and management
  personnel
• DoDAF models of real-word systems can be reused
  as federation conceptual models
• Defines a common XML schema (CADM) that will
  promote data interchange among different tools
  and models

5

• Introduction
• DoDAF Overview
• FEDEP Overview
• DoDAF Overlay on FEDEP
• Step through FEDEP Process
• Sample Products
• Conclusion

6
DoDAF Overview

• Motivation
• Increasing joint and multi-national operations
  require DoD systems that communicate and
  interoperate with each other
• A common architectural approach lays the
  foundation for developing and acquiring
  interoperable systems by encouraging a rigorous
  systems engineering effort up front
• DoDAF developed to define this common approach

7
DoDAF Overview

• Intent - Defines a common approach for DoD
  architecture description development,
  presentation, and integration for both
  warfighting operations and business operations
  and processes.
• Evolved from the C4ISR Architecture Framework
• Provides more detailed guidance
• Increased emphasis on data

8
DoDAF Views
9
Data Standardization

• CADM Core Architecture Data Model
• A formal model defining the data organization for
  a repository of DoDAF compliant architecture
  products
• A repository based on the CADM should be able to
  store architecture products from multiple
  projects in a common way, so that products from
  different projects using different tools could be
  analyzed and compared

10
Related DoD Policy

• DoDAF views mandated for new Acquisition Programs
• CJCS Manual 3170.01A, Operation of the Joint
  Capabilities Integration and Development System
  3
• CJCS Instruction 6212.01C, Interoperability and
  Supportability of Information Technology and
  National Security Systems 4

11

• Introduction
• DoDAF Overview
• FEDEP Overview
• DoDAF Overlay on FEDEP
• Step through FEDEP Process
• Sample Products
• Conclusion

12
FEDEP Overview

• FEDEP - Federation Development and Execution
  Process
• Structured, systems engineering approach to HLA
  federation development and execution
• Defines the process and products, but the
  structure and format of the products is left to
  the discretion of the federation development team
• 7 Step Process

13

• Introduction
• DoDAF Overview
• FEDEP Overview
• DoDAF Overlay on FEDEP
• Step through FEDEP Process
• Sample Products
• Conclusion

14
FEDEP Step 1Define Federation Objectives
Step 1 Define Federation Objectives
15
FEDEP Step 1 Define Federation Objectives

• Use existing program level DoDAF products to
  identify sponsor needs
• Based on sponsor needs, develop federation
  objectives
• Ex OV-5 activities are high-level system
  requirements

Example Program Level OV-5
16
FEDEP Step 1 Define Federation Objectives

• Step 1 should result in
• Needs statement
• Federation Objectives Statement
• Initial Planning Document
• May use AV-1, Overview and Summary Information

17
FEDEP Step 2Perform Conceptual Analysis
Step 2 Perform Conceptual Analysis
18
FEDEP Step 2Perform Conceptual Analysis

• Conceptual Model
• An implementation independent representation of
  the real-world domain that applies to the
  federation problem space
• The real-world domain could be modeled using the
  DoDAF
• The federation conceptual model relates to the
  DoDAF model of the real-world system of interest
  (SOI)
• Conceptual model can be documented nicely using
  the same DoDAF views used to describe system of
  interest

19
FEDEP Step 2Perform Conceptual Analysis
20
FEDEP Step 2Perform Conceptual Analysis

• Federation Requirements
• SV-5 diagram is an Operational Activity to
  Systems Function Traceability Matrix
• Can use SV-5 to detail federation requirements
• Benefit of using this construct will become
  apparent when designing the federation

21
FEDEP Step 2Perform Conceptual Analysis

• Scenario
• Scenario should be selected or developed that
  will exercise the activities and provide an
  analysis framework for the real-world system
  requirements
• One possibility is to use OV-5 activities as
  events within the scenario
• These OV-5 activities can be detailed using
  OV-6Cs (Operation Event-Trace Description)

22
FEDEP Step 2Perform Conceptual Analysis

• Scenario will be a series of these vignettes
  combined with other information such as laydowns,
  planned movements, etc.
• Full scenario can be documented using tool of
  choice

Example Engage Enemy Boat OV-6C
23
FEDEP Step 3Design Federation
Step 3 Design Federation
24
FEDEP Step 3Design Federation

• Select Federates

Example SV-5 used to Select Federates
25
FEDEP Step 3Design Federation

• Prepare Federation Design

Example Federation SV-1
26
FEDEP Step 4Develop Federation
Step 4 Develop Federation
27
FEDEP Step 4Develop Federation

• Develop FOM
• DoDAF products useful during initial phase of FOM
  development.
• SV-5 to correlate HLA objects and interactions
  with the federates publishing and subscribing to
  them

28
FEDEP Step 4Develop Federation
Example SV-5 Mapping Federation Requirements to
Simulations
29
FEDEP Step 4Develop Federation

• SV-11s to represent HLA Objects and Interactions
• Visually depicts relationships
• Inheritance easy to visualize
• SV-10a for timing, constraints, etc.

Example SV-11 for HLA Air Object Class
30
FEDEP Step 4Develop Federation

• SV-10cs could be used to show how the simulations
  within the federation will communicate

Example SV-10c for Weapon Engagement Sequence
31
FEDEP Steps 5 - 7

• DoDAF products used primarily for reference

32
How it Usually Works
Using misc documentation formats during FEDEP
Additional Coordination Possible
Confusion Misunderstandings More Difficult VVA
MS Users
MS Developers
Analysts Engineers Program Managers
33
How it Could Work
All using DoDAF
Common Language Better Communication Easier VVA
MS Developers
MS Users
DoDAF
34
Summary

• Primary benefit is a common language
• All IPTs will have a common consistent set of
  products to refer to
• Prevents duplication of effort
• Encourages cooperation
• Reduces misunderstandings
• Aids VVA

35
Summary

• Some Limitations
• DoDAF not specifically designed for MS, so some
  creativity is required to use it to the maximum
  benefit
• Potential areas for further study
• Consider updates to the DoDAF to include diagrams
  and views important to MS
• Others?

36
The Application of the DoDAF within the HLA
Federation Development Process
QUESTIONS?
37
References

• 1 DoD Architecture Framework Working Group
  DoD Architecture Framework Version 1.0, Volume
  I Definitions and Guidelines, 9 February 2004
• 2 DoD Architecture Framework Working Group
  DoD Architecture Framework Version 1.0, Volume
  II Product Descriptions, 9 February 2004
• 3 Joint Chiefs of Staff Chairman of the
  Joint Chiefs of Staff Manual (CJCSM) 3170.1,
  Operation of the Joint Capabilities Integration
  and Development System, Enclosure A, Joint
  Capabilities Integration and Development System
  (JCIDS) Analysis, June 2003
• 4 Joint Chiefs of Staff Chairman of the
  Joint Chiefs of Staff Instruction (CJCSI)
  6212.01C, Interoperability and Supportability of
  Information Technology and National Security
  Systems, November 2003
• 5 R. Lutz, R. Little, R. Scrudder, K. Morse
  IEEE 1516.3 The HLA Federation Development and
  Execution Process (FEDEP), 03E-SIW-022, European
  Simulation Interoperability Workshop, June 2003
• 6 IEEE Recommended Practice for High Level
  Architecture (HLA) Federation Development and
  Execution Process (FEDEP), IEEE 1516.3, April 2003

38
Backup SlideHigh-level Concept

• Start with the program level operational
  architecture
• Product area teams extend the architecture with
  system-specific information (SVs)
• An entity modeled in the SV architecture should
  reflect the real-world system
• An entity modeled in the MS environment should
  also reflect the real-world system
• Federation Architecture is a subset of the
  overall system architecture

Program Level Operational Architecture (OVs)
Mission Level System Architecture (SVs)