Operational Concept Modeling for Responsive Space

1
Operational Concept Modeling for Responsive Space

• Herschel Melton
• Yvonne Sheets
• April 20, 2004

2
Recent Operations Concepts Utilizing This Approach

• Responsive Launch System for SMC
• Integrated Theater-wide ABM defense concepts for
  BMDO(MDA)
• Various portions of the Future Combat System
  acquisition system for the Army (NetFires,
  Cooperative Engagement, "A Day in the Life of the
  First Platoon)
• NUMAS system-wide performance monitoring for
  AFSPC
• ISC2 SoS Engineering and Migration for AFSPC
• WMD trafficking detection concepts
• Ground System Crew Tasking concepts for TRW CCSC
• Space Based Surveillance System (SBSS)

3
Initial Notional Concept
Trans-stage Un-folded
Trans-stage Un-folding
Trans-stage
AOR
4
More Fully Developed CONOPS in Theater
MC2A
Trans-stage Un-folding
Trans-stage Un-folded
Trans-stage
LOS
CONUS
AOR 2
Responsive Launch System
AOR 1
JFC AOC
5
Top Level Model Diagram
6
Sample Pages from the Model Notebook
7
Lessons Learned from Recent Applications

• Early modeling helps drive valid system
  definition
• Clarification and Validation of the Logic of the
  Process diagram
• Enforces rigor in the application of system
  definition techniques
• Allows consideration of characterization of the
  interrelationships between components of system
• Allows the requirement of thorough and definitive
  definition of communication among components
• Provides means for the verification of the logic
  implied by the system definition
• Multiple Measures of Performance can be
  incorporated into the process early to drive the
  design of the system definition, especially the
  modelling.

8
Lessons Learned from Recent Applications (contd)

• Valuable, quantitative sensitivity studies are
  available early to help direct the system
  definition.
• (e.g., Sensitivity of overall system response to
  effectiveness of different components)
• Provides support for decision making relative to
  options available in system definition.
• (E.g., is it better to group functions in one
  manner vs. another.)
• Performance Requirements (expressed in terms of
  MOPs) can be developed, allocated and tracked
  during development as well as rebalanced as
  development proceeds.

9
Operational Concept Modeling

• Model Characteristics
• Requirements Representation (especially the
  ability to flow down to lower levels)
• Physical interfaces (ability to represent
  different options)
• Command and Control Operations Structure (clearly
  illustrate C2 implementation)
• Human Interaction (allow inclusion of the
  contribution of the human involvement)
• Tool Characteristics
• Model construction/modification from beginning to
  completion lt one day (on the order of minutes or
  hours not days).
• Models systems that can be analyzed by applying
  queuing theory and/or continuously integrated
  mathematical models.
• Highly visible function/Data-Flow representations

10
Role of Modeling in a Distributed Team

• Each member of the team is given a free Player
  version of Extend
• The most recent version of the model is
  distributed (email or by virtue of a file sharing
  system of some sort) to the team members.
• The team members run the model through any
  scenarios that they would be interested in.
• Comments and suggestions are returned to the
  facilitator and are either incorporated directly
  into a new version of the model or are floated to
  the other members for discussion. Once a
  consensus is reached the consensus is
  incorporated.
• This is redistributed for the next iteration.

Group 2
Group 1
Facilitator
Group 4
Group 3
11
Systems Engineering Process
Operational Concept Modeling Fits Here

• Process Input
• Technical Architecture
• Product Lines
• Customer Needs/Objectives/ Requirements
• Missions
• Measures of Effectiveness
• Environments
• Constraints
• Technology Base
• Output Requirements from Prior Development
  Efforts
• Program Decision Requirements
• Requirements Applied Through Specifications and
  Standards

System Analysis Control (Balance)

• Requirements Analysis
• Analyze Business Goals (costs, common
  use/scalability,) and Performance Goals

• System Configuration Management
• Tradeoff Studies
• Effectiveness Analysis
• Risk Management
• Configuration Management
• Interface Management
• Data Management
• Performance Management

Requirements Loop

• Functional Analysis/Allocation
• Define an Architecture which identifies critical
  Interfaces
• Define level of openess
• Apply Modularity
• Re-evaluate stringency of requirements
• Consider reallocation of performance or business
  requirements

Design Loop

• Synthesis
• Make implementation decisions based on mission
  requirements
• Prototype to delay implementation decisions
• Trade alternative interfaces/standards
• Develop acquisition logistics
• Develop relationships with standards community

Verification Loop

• Process Output
• System Architecture
• Development Level Dependent
• Decision Data Base
• System/Configuration Item Architecture
• Specifications Baselines

• Related Terms
• Customer Organizations responsible for Primary
  Functions
• Primary Functions Development, Manufacturing,
  Verification, Deployment, Operations, Support,
  Training Disposal
• System Elements Hardware, Software, Personnel,
  Facilities, Data, Material Services, Techniques

12
Conclusions

• Modeling at the conceptual level to allow the
  consideration of the next level of detail is
  important for several reasons
• Puts enough meat on architecture bones to brief
  decision makers
• Helps drive and identify system requirements and
  interfaces
• Provides a method for collaborative stakeholder
  involvement which can continue thru the
  development process