The Johns Hopkins University Applied Physics Laboratory

1
The Johns Hopkins University Applied Physics
Laboratory
Critical Elements for Distributed Product
Description Data 2003 Spring Simulation
Interoperability Workshop Orlando (Kissimmee),
Florida March 31 April 4, 2003
Peter Eirich JHU/APL
2
Presentation Outline

• Background
• Simulation Based Acquisition (SBA) Concepts
• Support for Weapons Systems Analysis
• Future Combat Systems (FCS) Program
  (as an illustration)
• Logical Information Modeling
• Principles
• Notation
• Designing a Logical Model
• What problem does this solve?
• Critical Elements for Distributed Product
  Description (DPD) Data

3
DPDs, Data Interchange Formats (DIFs),and Tools
Adapted from A Roadmap for Simulation Based
Acquisition Report of the Joint Simulation
Based Acquisition Task Force, Acquisition Council
Draft for Coordination, December 4, 1998.
April 2003
03S-SIW-096
3
4
DPD Support to MS Hierarchy
from P. L. Eirich, J. E. Coolahan, and E. M.
Purdy, A Collaborative Environment Architecture
for Future Combat Systems (FCS) Modeling and
Simulation, paper 02S-SIW-026, in Proc., 2002
Spring Simulation Interoperability Workshop,
March 10-15, 2002, Orlando, FL.
5
Weapon Systems Effectiveness Framework
from P. L. Eirich, J. E. Coolahan, and E. M.
Purdy, An FCS MS Construct and Its Support of
Testing, in Proceedings of the Eighth
International Test and Evaluation Association
(ITEA) Modeling and Simulation Workshop, Las
Cruces, NM, December 11, 2002.
6
Top-Level View of the FCS Collaborative
Environment Structure
from P. L. Eirich, J. E. Coolahan, and E. M.
Purdy, An FCS MS Construct and Its Support of
Testing, in Proceedings of the Eighth
International Test and Evaluation Association
(ITEA) Modeling and Simulation Workshop, Las
Cruces, NM, December 11, 2002.
7
Presentation Outline

• Background
• Simulation Based Acquisition (SBA) Concepts
• Support for Weapons Systems Analysis
• Future Combat Systems (FCS) Program
  (as an illustration)
• Logical Information Modeling
• Principles
• Notation
• Designing a Logical Model
• What problem does this solve?
• Critical Elements for Distributed Product
  Description (DPD) Data

8
A Simple Notation (1)
April 2003
03S-SIW-096
8
9
A Simple Notation (2)
April 2003
03S-SIW-096
9
10
System Decomposition Structures
from P. L. Eirich, J. E. Coolahan, and E. M.
Purdy, A Collaborative Environment Architecture
for Future Combat Systems (FCS) Modeling and
Simulation, paper 02S-SIW-026, in Proc., 2002
Spring Simulation Interoperability Workshop,
March 10-15, 2002, Orlando, FL.
11
Collaborative Environment Support Throughout the
Program Life Cycle
from P. L. Eirich, J. E. Coolahan, and E. M.
Purdy, An FCS MS Construct and Its Support of
Testing, in Proceedings of the Eighth
International Test and Evaluation Association
(ITEA) Modeling and Simulation Workshop, Las
Cruces, NM, December 11, 2002.
12
Presentation Outline

• Background
• Simulation Based Acquisition (SBA) Concepts
• Support for Weapons Systems Analysis
• Future Combat Systems (FCS) Program
  (as an illustration)
• Logical Information Modeling
• Principles
• Notation
• Designing a Logical Model
• What problem does this solve?
• Critical Elements for Distributed Product
  Description (DPD) Data

13
System Decomposition
April 2003
03S-SIW-096
13
14
System Inputs and Outputs
April 2003
03S-SIW-096
14
15
System Boundary
boundary
April 2003
03S-SIW-096
15
16
System Ports
April 2003
03S-SIW-096
16
17
System Assemblies
April 2003
03S-SIW-096
17
18
System Properties
April 2003
03S-SIW-096
18
19
System Requirements (1)
April 2003
03S-SIW-096
19
20
System Requirements (2)
April 2003
03S-SIW-096
20
21
Summary

• A logical model provides a roadmap for
  implementing a data structure to manage
  Distributed Product Description (DPD) data
• DPD data exists at the core of a collaborative
  system design environment
• DPD data is needed for systems analysis, modeling
  and simulation, test and evaluation, Verification
  and Validation, etc.
• The seven presented critical elements portray
  patterns of product data relationships that
  should appear -- somewhere -- in a structure of
  product data for use in describing a realistic,
  real-world system
• These patterns can be used as key nodes, or
  anchor points, for recognizing and understanding
  the overall organization and utility of a DPD
  data structure of practical size, scope, and
  complexity
• Missing or incomplete patterns indicate certain
  corresponding limitations in the functionality
  that can be provided by a DPD

22
Discussion
Peter Eirich JHU/APL [phone] peter.eirich
_at_jhuapl.edu