Upcoming SlideShare
Loading in...5







Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

AU-SAT1_System_Engineering.ppt AU-SAT1_System_Engineering.ppt Presentation Transcript

  • System Engineering on AU-SAT1 Industrial and Systems Engineering Department Auburn University, Auburn, AL. Jeremy Barnes August 2008
  • Module Description
    • Module Name: Systems Engineering
    • Module Objective: To provide the reader with an overview of the system engineering principles and processes being implemented in the AU-SAT1 program. The context of the module will be describing the involvement of system engineering throughout the relevant portion of the remaining life-cycle of the project.
  • What is Systems Engineering?
    • Systems engineering is a multidisciplinary (technical and business) approach with the purpose of leading the engineering of a complex interrelated set of components working together toward a common purpose. The scope of the practice ranges from concept to production and acquisition to post-deployment support (operation). 1,2
    • The objective of system engineering to be involved through all phases of a system to ensure that the end product has the optimal cost-effective solution. 11
    Fundamentals System Engineering Guides the Engineering of a System Through Its Life-Cycle
  • Example System Fundamentals System Subsytem-2 Subsystem-1 Subsystem-3 Legend CI – Configuration Item HW – Hardware SW – Software FW – Firmware SI – Software Item HW HW HW SI-2.1 FW CI-3.1 HW HW SW Process System Engineering Involvement A System is comprised of Subsystems containing HW, SW, FW and Processes SW SI-1 SW
  • What do System Engineers Do?
    • System engineers have a wide variety of responsibilities. These include but are not limited to:
      • Requirements Analysis*
      • Trade-Off Analysis (Decision Modeling)*
      • System Test and Evaluation
      • Requirements Verification*
      • Technical System Design Reviews*
      • Risk Management*
      • Configuration Management*
      • Reliability, Maintainability and Availability (RMA) Engineering
      • Producibility Engineering
      • Safety Engineering
      • Human Factors Engineering
      • System Integration*
    Fundamentals * - SE Tasks to be Implemented on AU-SAT1
  • System Engineering Process Overview
    • SIMILAR Method: S tate the Problem, I nvestigate Alternatives, M odel the System, I ntegrate, L aunch the System, A ssess Performance and R e-evaluate.
    Fundamentals Bahill and Gissing (1998) System Engineering is involved from start to finish.
  • Business Aspects (Management) Fundamentals (DAU, 2001) Systems Engineering Related to System Engineering Management Project Management System Engineering Related to Project Management System Engineering System Architecture Resource Allocation System Integration Project Planning and Control Project Planning Resource Allocation Financial Contract Management Task Definition Risk Management Customer Interaction (Kossiakoff, 2003)
  • Business Aspects (SEMP) Fundamentals
    • The SEMP defines and guides the tasks associated with the system engineering function. The document is intended to be a living document updated as needed.
    • Elements of a SEMP include: Development Program Planning and Control, System Engineering Process and Engineering Specialty Integration
      • Development Program Planning and Control includes:
        • Statement of Work (SOW), Organization, Scheduling, Technical Performance Measurement (TPM), Risk Management
      • System Engineering process includes:
        • Operational Requirements, Functional Analysis, System Analysis, System Test and Evaluation Strategy
      • Engineering Specialty Integration
        • RMA Engineering, Producibility Engineering, Safety Engineering, Human Factors Engineering
    (Kossiakoff, 2003) The SEMP is a Vital Step in Successful System Engineering for a Project
  • Business Aspects (Scheduling Interrelationships) Fundamentals (MIL-STD 499B)
  • Business Aspects (Risk Management) Fundamentals
    • Risk is involved throughout the system life-cycle hence should be managed closely 1
    • NASA divides risk into the following areas: risk planning, risk identification and characterization, risk analysis and risk mitigation and tracking 8
      • Risk planning, identification and characterization and analysis:
        • Defines the methods of managing risk, establishes likelihood and criticality for risks and sets priority methods for handling risks 1
      • Risk mitigation and tracking:
        • This is the process of identifying steps to reduce a risk while establishing a plan to monitor the progress
    • A common technique used in risk management is a waterfall chart. A variation is shown on the next slide. Waterfall charts can include mitigation steps that will decrease the likelihood and consequence scores
  • Business Aspects (Risk Management) Fundamentals ( NASA Independent Verification & Validation Facility, 2008.)
  • Business Aspects (Risk Management) Fundamentals
    • Identifying/Characterizing risks can be done in various methods such as:
      • Expert Interviews
      • Independent Assessment
      • Use of Risk Templates
      • Lessons Learned
      • Failure Modes, Effects, and Criticality Analysis (FMECA)/Failure Modes and Effects Analysis (FMEA), digraphs, and fault trees 8
    • Analyzing Risks can be done with the following methods:
      • Decision Modeling and Analysis
      • Probabilistic Risk Assessment Profiles (R = ∑ s PS CS) where P S is the probability of outcome s, and C S is the consequence of outcome s
      • Probabilistic Network Schedules such as program evaluation and review technique (PERT)
      • Probabilistic Cost and Effectiveness Models
    (NASA System Engineering Handbook, 1995)
  • System Engineering in the Product Life Cycle
  • NASA System Life Cycle Life-Cycle Note: The phases are explained on the following charts with some context to the DoD System Life Cycle (shown on the next chart). The NASA and DoD System Life Cycles are closely related and with be used interchangeably to some extent in this section to address the purpose and the process approach.
    • Pre-Phase A – Advanced Studies (finding a concept)
    • Phase A – Preliminary Analysis (assessment of concept)
    • Phase B – Definition (define and establish preliminary design)
    • Phase C – Design
    • Phase D – Development (build, integrate and verify)
    • Phase E - Operations
    (NASA System Engineering Handbook, 1995)
  • DoD System Life Cycle Life-Cycle (MIL-STD 499B)
  • Reviews/Control Gates Life-Cycle
    • Preliminary Design Review (PDR)
      • Conducted to demonstrated that the people, processes and product solutions satisfy the functional baseline
    • Critical Design Review (CDR)
      • Conducted to demonstrate the total system is complete and ready for manufacturing and coding. CDRs can be conduction for subsystems as well
    • System Verification Review (SVR)
      • Verifies the system meets its requirements in the functional and allocated configuration document. The system is ready for production, support, training, deployment, operations, continuing verifications, continuing development (if follow-on contracts are required) and disposal
    • Physical Configuration Audit (PCA)
      • Conducted per configuration management procedures as outlined in the configuration management plan to verify that the baselined system is in accordance with its documented configuration (i.e. As Built/As Designed)
    (MIL-STD 499B) Note: Reviews are not limited to the list above.
  • Configuration Baselines Life-Cycle
    • The essential idea of baselines is that in order to reach a destination it is necessary to know your starting point. In order to plan for, approve, or implement a configuration change, it is necessary to have a definition of the current configuration that is to be changed. In order to manage a program effectively it is necessary to baseline the objectives for cost, schedule, and performance.” 9
    • Functional baseline - The approved configuration documentation describing a system's or top level configuration item's performance and the verification required to demonstrate the achievement of those specified characteristics.
    • Allocated baseline - The current approved performance oriented documentation, for a CI to be developed, which describes the functional and interface characteristics that are allocated from those of the higher level CI and the verification required to demonstrate achievement of those specified characteristics.
    • Development configuration - the contractor's design and associated technical documentation that defines the contractor’s evolving design solution during development of a CI. It consists of that contractor internally released technical documentation for hardware and software design that is under the developing contractor's configuration control.
    • Product baseline - The product baseline is the approved technical documentation which describes the configuration of a CI during the production, fielding/deployment and operational support phases of its life cycle. The product baseline prescribes all necessary physical or form, fit, and function characteristics of a CI, the selected functional characteristics designated for production acceptance testing, and the production acceptance test requirements
    (MIL-HDBK 61A, August 2007.) See the configuration management topic on the AAQ site for more information on configuration management.
  • Integrating Specialty Engineering into System Engineering
  • Quality Assurance (QA) Functions Integrating Specialty
    • Provides an independent assessment to the system engineer on the quality of the hardware and processes used in creating the system
    • As with reliability, the QA program must be tailored according to the NASA payload classifications
    • Tasks associated with the quality engineer are as follows:
      • Develop a QA program plan
      • Monitors the configuration management of procedures and documentation
      • Evaluation and selection of procurement services
      • Inspects facilities during fabrication
      • Ensures quality of training and technical documentation
      • Ensures test methods of verification for requirements are adequate
      • Monitors quality and acceptance testing
      • Monitors resolution and closure of non-compliances (NCs)
      • Verifies the as-built/as-coded documentation at CDR
      • Maintains QA data for subsequent failures
    • Quality Assurance tools are the PCA, in-process inspections, QA surveys and Material Review Boards
    (NASA System Engineering Handbook, 1995)
  • Integrated Logistics Support (ILS) Integrating Specialty
    • ILS supports the system during Phase D and E (Development and Operations)
    • Proper ILS support greatly reduces the total life cycle costs of a system. ILS employs supportability tactics into a deployed/installed system and plan for post-production tactics to ensure cost-effective development and operations
    • ILS contains nine elements:
      • Maintenance
      • Design Interface
      • Technical Data
      • Training
      • Supply Support
      • Test and Support Equipment
      • Transportation and Handling
      • Personnel Planning
      • System Facilities
    • ILS planning will begin earlier than Phase D and will be documented either in its own plan or as a section in Part III of the SEMP. ILS will identify and relay supportability design factors back to the system engineer in these earlier phases
    • ILS will be tasks with development and verification of the system’s supportability requirements
    • ILS will also focus on disposal of the system
    (MIL-STD-499B and NASA System Engineering Handbook, 1995)
  • Verification Integrating Specialty
    • Verification plays a critical role in mission success and is a vital part of integrating specialty engineering to system engineering. Verification can either be looked at as a specialty function or a primary function of system engineers
    • Verification is the task of validating the system against its documented requirements
    • Verification can be done by several methods
      • Demonstration
      • Test
      • Inspection
      • Analysis
    • All verification methods are documented at the end of its corresponding requirements document in a verification requirements matrix. This documentation also includes a “numerical designator assigned to each requirement, a statement of the specific requirement to be verified, the "pass/fail" criteria and tolerances for each requirement, any constraints that must be observed, any remarks to aid in the understanding of the requirement, and location where the requirement will be verified” 11
    • Methods can change based on needs, schedule and cost throughout the life-cycle. That is a requirement that may be grossly expensive to test, could be more analysis at a fraction of the cost and still yield a high confidence that the requirement has been validated
    • Verification starts early in the project life cycle with the development of the master verification plan which provides project direction of the verification activities to be performed
    • Verification reports ideally (budget, manpower and schedule) allowing should be generated for each requirement. This is the documented proof that each requirement has been fulfilled. Compilations of the reports may be delivered as contract deliverables (CDRLs) if performed by the prime contractor
  • Verification Integrating Specialty
    • Verification occurs in several stages:
      • Development
      • Qualification
      • Acceptance
      • Pre-Launch
    • Development: Verification during this stage provides confidence that the system can meet its performance requirements. PDR and CDR may provide verification of some requirements as well
    • Qualification: Verification at this stage is performing the appropriate verification methods on flight hardware at conditions more severe than its planned operational environments.
    • Acceptance: Verification at this stage identifies the flight hardware is ready for flight and will meets its operational environmental requirements
    • Pre-Launch: Verification at this stage proves out the remaining requirements that require final integration and preparatory steps
    (NASA System Engineering Handbook, 1995)
  • Appendix
  • References
    • Systems Engineering . Kossiakoff and Sweet. Wiley. 2003.
    • What is System Engineering? June 2004. INCOSE. < >.
    • System Engineering Fundamentals . 2001. Defense Acquisition University. < >.
    • G2SEBoK . 2001. INCOSE. < >.
    • What is System Engineering? A Consensus of Senior Systems Engineers . 2004. Terry Bahill and Frank Dean. <>.
    • MIL-STD-499B . 1994. Systems Engineering. Department of Defense. < >.
    • Brief History of System Engineering . 2006. INCOSE. < >.
    • Risk Review Template . T2006 Revision: A. NASA Independent Verification & Validation Facility. Effective Date: April 01, 2008. < www . >.
    • MIL-HDBK 61A: Configuration Identification . August 2007. < >.
    • Definitions – Supply Chain Management . 2000-2008. NCSU. < >.
    • NASA System Engineering Handbook . SP610S. June 1995. NASA. < >.
  • Acronym/Abbreviation List AAQ Academy of Aerospace Quality ASR Alternative System Review CDR Critical Design Review CDRL Contract Deliverable CI Configuration Item DAU Defense Acquisition University DemVal Demonstration and Validation DoD Department of Defense EMD Engineering and Manufacturing Development EV Earned Value FFBD Functional Flow Block Diagram FMEA Failure Modes Evaluation and Assessment FMECA Failure Modes Evaluation and Criticality Assessment FW Firmware HW Hardware ILS Integrated Logistics Support MDT Mean Downtime MIL-STD Military Standard
  • Acronym/Abbreviation List MLDT Mean Logistics Delay Time MMT Mean Maintenance Time MNS Mission Need Statement MTTF Mean Time to Failure MTTMA Mean Time to Maintenance Action MTTR Mean Time to Repair MS Milestone NC Non-Conformance ORD Operational Requirements Document PCA Physical Configuration Audit PDR Preliminary Design Review PERT Program Evaluation and Review Technique PMBOK Program Management Book of Knowledge PPBS Planning, Programming and Budgeting System QA Quality Assurance RMA Reliability, Maintainability and Availability SEMP System Engineering Management Plan SEWG System Engineering Working Group
  • Acronym/Abbreviation List SFR System Functional Review SI Software Item SOW Statement of Work SRR System Requirements Review T&E Test and Evaluation WBS Work Breakdown Structure
  • Other Useful Sources
    • Books:
      • PMBOK
    • Websites:
      • INCOSE
      • DoD Instruction 5000.2
      • IEEE P1220. Standard for System Engineering
      • Defense Acquisition Guidebook
      • AAQ (See for the full SE learning module)