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. Page 1 Page 4 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 (cont’d) • 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 < 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 Requirements Loop • System Configuration Management • Tradeoff Studies • Effectiveness Analysis • Risk Management • Configuration Management • Interface Management • Data Management • Performance Management • 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