html5-img
1 / 51

Dr. Martin Falk

Systems Engineering and Open Systems. Dr. Martin Falk. Mr. Glen Logan. Systems Engineering. Recent OSD & Service Initiatives NASA Accident Experience Current Challenges Related to Technical Management. Uneasy Feeling that You are Headed for Trouble?. Perception.

justis
Télécharger la présentation

Dr. Martin Falk

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Systems Engineering and Open Systems Dr. Martin Falk Mr. Glen Logan

  2. Systems Engineering • Recent OSD & Service Initiatives • NASA Accident Experience • Current Challenges Related to Technical Management

  3. Uneasy Feeling that You are Headed for Trouble?

  4. Perception • Growing realization that systems engineering focus was lost in DoD, NASA, and NRO during last decade. • Systems engineering capabilities have deteriorated in both government and industry. • Substantial efforts and initiatives now underway to fix the problem.

  5. Cost OverrunRisk vs. Systems Engineering Effort 90% Assurance Average Cost Overrun Source: SECOE 01-03, INCOSE 2002

  6. Schedule OverrunRisk vs. Systems Engineering Effort 90% Assurance Average Schedule Overrun Source: SECOE 01-03, INCOSE 2002

  7. Systems Engineering Process • RISK MANAGEMENT • TPM/METRICS • COST-PERFORMANCE TRADES • TEST EFFECTIVENESS REVIEWS • CONFIGURATION MANAGEMENT • TECHNICAL REVIEWS Requirements SYSTEMS ANALYSIS & CONTROL REQUIREMENTS ANALYSIS • Objectives • Track progress • Ensure requirements traceability • Evaluate alternatives • Manage risk FUNCTIONAL ANALYSIS & ALLOCATION DESIGN SYNTHESIS Designs Systems Engineering Fundamentals, DAU Press

  8. DESIGN System Development ‘V’ SYSTEM LEVEL DESIGN REQUIREMENTS V SYSTEM LEVEL SVR SFR ITEMS FAB, INTEGRATE & TEST TRR PDR ITEM LEVEL DESIGN REQUIREMENTS ASSEMBLIES COMPONENTS CDR DESIGN REQUIREMENTS COMPLETE

  9. The Defense Acquisition Management FrameworkDoDI 5000.2 (Spring 2003) User Needs & Technology Opportunities (BA 1 & 2) C B A FRP Decision Review Design Readiness Review Concept Decision Increment II Increment III BA 3/4 BA 5 BA 5 BA 5/Procurement Proc/Operations & Maintenance Validated & approved by operational validation authority CDD CPD ICD Low-Rate Initial Production Concept Refinement Technology Development System Integration System Demonstration Full-Rate Prod &Deployment • Conduct AoA, refine initial concept & develop Technology Development Strategy • Reduce technology risk & determine the appropriate set of technologies to be integrated into a full system • Demo the technologies in a relevant environment • Integrate subsystems, complete detailed design, and reduce system-level risk • Complete development • Demonstrate ability of system to operate in useful way consistent with KPPs • Combined DT/OT • Create efficient manufacturing capability • LRIP • IOT&E, LFT&E of prod-rep articles • Full rate production • Deployment of system IOC FOC • Process entry points at Milestone A, B, or C • Entrance criteria met before entering phase • Evolutionary Acquisition or Single Step to Full Capability FRP & Deployment System Integration System Demo LRIP Technology Development Concept Refinement Operations & Support System Dev & Demonstration Production & Deployment Sustainment Systems Acquisition Pre-Systems Acquisition Funding: Rqmnts: BDRRC FRP BDRRC FRP

  10. Prelim Sys Spec • T&E Strategy • SEP • Support & Maintenance • Concepts & Technologies • Inputs to: • -draft CDD, -TDS, -AoA • - Cost / Manpower Est • ICD • AoA Plan • Exit Criteria • Alternative Maintenance & • Logistics Concepts Systems EngineeringAs Applied ToConcept Refinement Analyze & Fix ASR Interpret User Needs, Analyze Operational Capabilities & Environmental Constraints Operational Expectations Analyze/Assess Concepts Versus Defined User Needs & Environmental Constraints MS A Analyze & Fix Trades Develop Concept Performance (& Constraints) Definition & Verification Objectives System Functional Expectations Assess/Analyze Concept & Verify System Concept’s Performance Integration & Verification/ Validation Decomposition & Definition Trades Analyze & Fix Decompose Concept Performance into Functional Definition & Verification Objectives Configuration Item Expectations Assess/Analyze System Concept Versus Functional Capabilities Systems Engineering Responsibility, Component Engineering Participation Trades nalyze & Fix Decompose Concept Functional Definition into Component Concepts & Assessment Objectives Assess/Analyze Enabling/Critical Components Versus Capabilities Component Expectations Component Engineering Responsibility, Systems Engineering Participation Trades Develop Component Concepts, i.e., Enabling/Critical Technologies, Constraints & Cost/Risk Drivers

  11. ICD & Draft CDD • Preferred Sys Concept • Exit Criteria • T & E Strategy • Support & Maintenance • Concepts & Technologies • AoA • SEP • TDS • Sys Performance Spec • LFT&E Waiver Request • TEMP, SEP, PESHE, PPP, TRA • Validated Sys Support & • Maintenance Objectives & • Requirements • Footprint Reduction • Inputs to : - IBR, -ISP,- STA, • CDD, - Acq Strategy • -Affordability Assessment • -Cost / Manpower Est Systems EngineeringAs Applied ToTechnology Development Analyze & Fix MS A Interpret User Needs. Analyze Operational Capabilities & Environmental Constraints Operational Expectations Demo & Validate Sys Concepts & Technology Maturity Versus Defined User Needs SRR Analyze & Fix Trades Develop System Performance (and Constraints) Specification and Critical Technology Verification Plan System Functional Expectations Demo/Model Integrated System Versus Performance Spec Integration & Verification/ Validation Decomposition & Definition Trades Analyze & Fix Demo System Functionality Versus Plan Configuration Item Expectations Develop Functional Definitions for Enabling/ Critical Technologies & Associated Verification Plan Systems Engineering Responsibility, Component Engineering Participation Trades Analyze & Fix Decompose Functional Definitions into Critical Component Definition & Tech Verification Plan Component Expectations Demo Enabling/Critical Technology Components Versus Plan Component Engineering Responsibility, Systems Engineering Participation Trades Develop System Concepts, i.e., Enabling/Critical Technologies, Update Constraints & Cost/Risk Drivers

  12. Sys Performance Spec • Exit Criteria • Validated Sys Support & • Maintenance Objectives • & requirements • APB, CDD, SEP • ISP, TEMP • Initial Prod Baseline • Test Reports, TEMP • Elements of Product Support • Risk Assessment • SEP, TRA, PESHE • Inputs to: • -CPD,-STA, - ISP • -Cost / Manpower Est Systems Engineering As Applied To System Development and Demo MS B Analyze & Fix SVR/PRR Combined DT&E/OT&E/LFT&E Demonstrate System to Specified User Needs & Environmental Constraints Interpret User Needs, Refine System Performance Specs & Environmental Constraints Operational Expectations Trades Analyze & Fix SRR OTRR Develop System Functional Specs & System Verification Plan System DT&E, LFT&E & OAs, Verify System Functionality & Constraints Compliance to Specs System Functional Expectations Integration & Verification/ Validation Decomposition & Definition Trades Analyze & Fix SFR Evolve Functional Performance Specs into CI Functional (Design to) Specs and CI Verification Plan Integrated DT&E, LFT&E & EOAs Verify Performance Compliance to Specs Configuration Item Expectations Systems Engineering Responsibility, Component Engineering Participation Trades PDR Analyze & Fix Evolve CI Functional Specs into Product (Build to) Documentation and Inspection Plan Component Expectations Individual CI Verification DT&E Component Engineering Responsibility, Systems Engineering Participation Trades CDR Fabricate, Assemble, and Code to “Build-to” Documentation DRR

  13. NASA Small SatellitesAccident Investigation • A concise set of mission success criteria should be established early in program • Solid engineering discipline is required at all program stages, especially transition to ops • Continuous risk management is a must. Risk should be considered on a par with cost, schedule, and performance • Entire team must take personal responsibility for the product

  14. Areas Most Common to Failed Programs • Poorly structured and conducted technical reviews (6 of 8) • Poor risk management practices (6 of 8) • Inadequate testing, simulation, and V&V (6 of 8) • Poor communications (5 of 8)

  15. How Did We Get Here? • Acquisition reform expectations were not clearly communicated to working level program managers, engineering and contractor staffs. • We convinced ourselves that we could have it all – faster, better, and cheaper. • We compromised performance and management discipline to save time and money.

  16. Challenges in Systems Engineering Management Interoperability Systems of Systems Insight vs Oversight Technology Change Rate Commercial-NDI Technical expertise in short supply Design for…everything

  17. Systems of Systems • SE Issues • Capstone Capabilities vs. System Level Requirements • Interoperability • Commonality • Modular Designs Missile Defense System Capstone SYSTEM Cooperating Systems Detection C3I Weapon

  18. Interoperability • Systems of Systems demand interoperability among systems • Requires ‘reasoned sub-optimization’ to select interface standards that benefit the integrated system. • “Systems Thinking” must be a way of life. • Demands that systems be integrated from the outset – a top down process vice the system up process used to date • Gives rise to JCIDS and Joint Technical Architecture

  19. Problem: IER Scalability One-to-One Current Interoperability KPP centers around one DoD architectural view (OV-3) that contains “Information Exchange Requirements” (IERs) • One-to-one relationship (point-to-point) This example: 10 systems IERs 10(10-1) = 90

  20. Solution: The Net-Ready Approach One-to-Many Net Ready approach centers on central network: • Focus on organizational contributions and consumption of information • One-to-network paradigm Network This example: 1 system has to deal with 1 interface

  21. Net-Ready KPP “Consists of measurable and testable characteristics and/or performance metrics required for timely, accurate, and complete exchange and use of information to satisfy information needs for a given capability.” CJSI 6212.01C Comprised of compliance with: Net-Centric Operations and Warfare Reference Model Global Information Grid Key Interface Profiles DOD information assurance requirements Supporting integrated architecture products J-6 certifies NR-KPP JITC evaluates and certifies Joint interoperability C4ISP replaced by Information Support Plan *

  22. Architectures

  23. DoD Architecture Framework Working Group DoD Architecture Framework Version 1.0 Systems Systems Technical Technical Operational Operational Vol ume II: Product Description 9 February 2004 DoD Architectural Framework Source for direction and information on the development of Operational, System, and Technical Architectures to support system developments.

  24. Integrated Architecture:One Architecture - 3 Views Operational The Operational View describesand interrelates the operational elements, tasks and activities, and information flows required to accomplish mission operations. Systems The Systems Viewdescribes and interrelates the existing or postulated technologies, systems, and other resources intended to support the operational requirements. Technical The Technical Viewdescribes the profile of rules, standards, and conventions governing systems implementation.

  25. Insight vs. Oversight • Concept: • Contractor flexibility to innovate, seek improved means to deliver improved products (faster, better, cheaper) • Government retains control of top level requirements, has required visibility to make informed key decisions • Practice: • Technical managers in some cases believe they have little or no leverage to require information or to effect change • Frustration with perceived responsibility absent authority Government has obligation to ensure that technical management practices are sound; may at times feel like oversight.

  26. Commercial and Non-Developmental Items • CI-NDI offer real benefits: • Shorter development cycles • Development costs already amortized • Continuing benefits from commercial competition • …but also have real (sometimes not apparent) costs: • May bias requirements to favor current, known capabilities • Integration difficulties may be overlooked • Updates and sustainment subject to marketplace • Testing is a continuous activity • Modified commercial items lose most of perceived benefits

  27. Design for...everything • [Some of the] design considerations (per Defense Acquisition Guidebook): • Producibility – Interoperability • Quality – Survivability • Supportability – System Security • Open Systems – Electromagnetic Effects • Software – Value Engineering • Environmental, Safety, Health – Unplanned Stimuli • Human Systems Integration – Vertical Integration • Standardization • Reliability, Maintainability, Availability Corrosion

  28. Technical Expertisein Short Supply • Fewer technical experts available in government • Downsizing • Hard to attract needed expertise • Aging workforce eligible for retirement • Inevitable consequence is more dependence on contractors to make technical management judgments • Substantial evidence that, when budget and schedule pressures are applied, contractors may not make good technical management decisions

  29. Technology Change Rate • Computer and communications technologies have very short life cycles; much shorter than systems of which they are a part. • Designs must accommodate frequent updates - during development and after • Open systems architectures and modular designs are recommended design approaches to address problem • While conceptually easy to grasp, these strategies are often poorly understood at the implementation level.

  30. Technical ManagementLeading Indicators • Change vs. Time • Requirements • Designs • Testing • Specs and ICDs: Approved vs. Planned Development Specs: 50% by PDR; 100% by CDR • Subcontracts: Signed vs. Planned 30-50% by PDR; 100% by CDR 5-10% max deviation USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs http://cse.afit.edu

  31. Technical ManagementLeading Indicators • Engineering Manpower: Total vs. Plan • Design Documentation: Actual vs. Plan Drawing release: 40% by PDR; 90% by CDR • Trade Studies: Completion 75-100% design definition studies complete by PDR • Software Products: Complete vs. Time 10% variance threshold typical • EVMS: Completion and Complexity USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

  32. Technical ManagementLeading Indicators • HW and SW Deliveries vs. Plan • Technical Performance Measures: Technical performance vs. plan profile • Deficiency Reports: Actual vs. expected • Maintenance and Support Facility Changes Minimal after Milestone C • Action Item Closure after Design Reviews • Key Characteristics Defined 70-90% by PDR; 100% by CDR USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

  33. Technical ManagementLeading Indicators • Testing Activities: Approved vs. Planned • Proposed schedule vs. Actual • Subcontract Management Listed indicators monitored by prime for subs USAF/AQ Guidance 01/07/04 Robust Engineering of Air Force Acquisition Programs

  34. Systems Engineering“Things to Look For” • Systems Engineering Management Plan • Requirements Management/Traceability • Risk Management Plan/Process • Technical Performance Measures • Configuration Management Plan/Process • Systems Engineering Training

  35. Summary • Systems engineering is in the process of a comeback as a discipline central to acquisition success. • Today’s issues and challenges are complex – made more so by virtue of joint warfighting and systems of systems. • There is no free lunch – this stuff is hard and it takes time and money to get it right.

  36. Backup

  37. Requirements The Inputs to the Systems Engineering Process Systems Engineering Process • Operational • Function • Performance • Interfaces • Support • Funding • Technology • Legal • Regulation • Compliance

  38. Operational Requirements • Mission Area Analyses • Comprehensive, analytic evaluations of capability vs. requirements in an assigned mission area • Mission Needs Statement (MNS),Initial Capabilities Document (ICD) • Non-specific statement of operational capability required to accomplish a given mission • Operational Requirements Document, Capabilities Development Document (CDD) • Objectives and minimum acceptable thresholds for a specific concept or system. • Capabilities Production Document (CPD)

  39. REQUIREMENTS ANALYSIS Requirements Analysis OBJECTIVE: Define the Problem • Functions – WHAT must system do? • Performance – HOW WELL? • Interfaces – UNDER WHAT CONDITIONS? • Other Constraints • Performance Specifications describe products and services • In terms of • Function • Performance • Interface

  40. Requirements Analysis – Two Part ProcessOperational Concept Definition functions Cruise Altitude Speed Distance Climb Attack Rate Altitude Takeoff performance Distance Surface …to get agreement between users and developers on key mission requirements and parameters timeline 0 2 12 70

  41. TAKE-OFF CLIMB CRUISE ATTACK Requirements AnalysisDesign Requirements Definition ORD Distance Surface Detect Ident • Identify and confirm explicit requirements • Identify key implicit requirements – function, performance, and interface • Trace flow down of requirements • Establish design constraints

  42. Requirements Flowdown • Aircraft landing weight NTE 50,000 lb... • Approach/landing speeds NTE 150 and 110 kts respectively... • System will be supportable by existing USN logistics system... AIRFRAME ENGINE SPEC SPEC • Empty gross • Weight NTE 15,000 lb... weight NTE • Thrust NLT 30,000 lb at 15,000 lb... max power (SL/std day)... • Absorb shock ...15 fps rate of descent... • ...tailhook... • Aircraft will be capable of air operations from carrier... ORD SYSTEM SPEC ITEM SPECS

  43. ATTACK • Target Types • PK • Time DETECT IDENTIFY AIM TRACK Functional Analysis & Allocation • INPUTS: • Functions • Performance • Interfaces • Other Products From • Requirements Analysis REQUIREMENTS ANALYSIS ANALYSIS & CONTROL FUNCTIONAL ANALYSIS & ALLOCATION DESIGN SYNTHESIS OUTPUT: Functional Architecture – Logical Description, Performance Allocated to Functions CRUISE ATTACK CLIMB TAKEOFF

  44. Detect Comm ID Track Aim Fire TD PD TC PC TID PID TT PT TA PA TF PF AFDS Example function performance Requirement:Attack light armored vehicles within 30 minutes of identification under <defined> weather conditions, with a Pk not less than 0.85. Coordination and control exercised by Army Fire Direction System. interface • 30 min • Pk 0.85 Attack

  45. Alternative Architecture Or…? • Key functions accomplished by off-board system • May require less development if capabilities already exist • On board attack function requires less time for this system • More interfaces, more complexity Is this a better choice? Depends on technical and cost issues

  46. Functional Analysis & Allocation Steps in Functional Analysis and Allocation • Decompose top level functions to next lower level • Allocate performance requirements to functions (higher level to lower level) • Evaluate alternative architectures • Select and refine preferred architecture Result: a logical description of the product with performance parameters such that specific hardware and software elements capable of performing the required functions (at the required levels of performance) can be identified- the Functional Architecture

  47. Design Synthesis Once a preferred architecture is selected, design alternatives can be developed and compared. A selected Functional Architecture should suggest several alternative concepts or designs that could conceivably do the job. The issue becomes cost-effectiveness. Which will be most effective for the mission in terms of both performance and cost?

  48. Design Synthesis • INPUTS: • Functional Architecture REQUIREMENTS ANALYSIS ANALYSIS & CONTROL FUNCTIONAL ANALYSIS DESIGN SYNTHESIS This is the product element of the WBS! AIR VEHICLE • OUTPUT: • Physical Architecture • An architecture of physical • elements capable of performing • the functions required at the levels of performance specified AIRFRAME PROPULSION AVIONICS WEAPON

  49. Design RequirementsPrime Item Specification Development • As functions and performance parameters are associated with physical elements, a set of design criteria are developed for those elements • Detection • Tracking • Range • Probability Detect • Weapon, Chassis Functions Performance Interfaces

More Related