Principles of Systems Engineering Introduction & Overview

1. Principles of Systems Engineering Introduction & Overview Jim Andary NASA Goddard Space Flight Center James.F.Andary@nasa.gov October 22, 2009

2. Agenda • Definitions of system and systems engineer • The role of a systems engineer • Systems engineering vs. project management • Systems engineering functions and processes • Requirements Development and Management • Operations Concept • Decomposition • Technology Planning • System analysis and design • System Integration • Resource Management • Quality Control • Verification and Validation

3. Definitions What is a System? “A System is a set of interrelated components which interact with one another in an organized fashion toward a common purpose” NASA Systems Engineering Handbook SP6105

4. Definitions (Continued) What is Systems Engineering? “Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.” INCOSE Handbook

5. Definitions (Continued) Another Definition “Systems Engineering is a robust approach to the design, creation, and operations of systems.” NASA Systems Engineering Handbook SP-6105

6. Definitions (Continued) In simple terms, the systems engineering approach consists of: • Identification and quantification of system goals, • Creation of alternative system design concepts, • Performance of design trades, • Selection and implementation of the best design, • Verification that the design is properly built and integrated, and • Post implementation assessment of how well the system meets (or met) the goals

7. Definitions (Continued) “Engineering of Systems” Anyone involved in engineering a system should exercise good systems engineering practices.

8. Twelve Systems Engineering Roles 1. Requirements Owner 2. System Designer 3. System Analyst 4. Validation and Verification Engineer 5. Logistics & Operations Engineer 6. Owner of the “Glue” among subsystems 7. Customer Interface 8. Technical Manager 9. Information Manager 10. Process Engineer 11. Coordinator of the Disciplines 12. “Classified Ads” Systems Engineer from Sarah A.Sheard (INCOSE proceedings of 1996)

9. Systems Engineering vs. Project Management

10. Tools help engineers evaluate their systems more quickly and more efficiently, but they do not replace the “Art” and “Creativity” necessary to conceive them “The objective of systems engineering is to see to it that the system is designed, built, and operated so that it accomplishes its purpose in the most cost-effective way possible, considering performance, cost, schedule and risk.” NASA Systems Engineering Handbook SP6105 Key Systems Engineering Functions Verification and Validation Project Objectives and Constraints Requirements Development and Management Architecture and Design Verification and Validation Verification and Validation Project Objectives Met, Ready for Operations Operations Concept Systems Engineering Management Plan

11. Systems Engineering Process “V” Understand User Requirements, Develop System Concept and Validation Plan Demonstrate and Validate System to User Validation Plan Develop System Performance Specification and System Verification Plan Integrate System and Perform System Verification to Performance Specification Expand Performance Specifications Into CI “Design-to” Specifications and Inspection Plan Assemble CIs and Perform CI Verification to CI “Design-to” Specifications Integration and Verification Sequence Evolve “Design-to” Specifications into “Build-to” Documentation and Inspection Plan Inspect to “Build-to” Documentation Decomposition & Definition Sequence Fabricate, Assemble, and Code to “Build-to” Documentation CI = Configuration Item

12. Systems Engineering Process “V” (Continued) Promotes a risk-responsive, phased system development process • Developed by Kevin Forsberg and Harold Mooz* • Starts with user needs on the upper left and ends with a user-validated system on the upper right • Adds concurrent risk management • User involvement • User approval and in-process validation • Adds verification problem resolution *Kevin Forsberg and Harold Mooz, "The Relationship of System Engineering to the Project Cycle," Proceedings of the First Annual Symposium of National Council on System Engineering (NCOSE), Chattanooga, Tennessee, Oct. 1991, pp 57 - 65.

13. Requirements Development • Collect top-level requirements from customers and stakeholders • Develop an operations concept • Derive lower-level requirements to support top-level requirements and the operations concept • Writing requirements without a fully understood, agreed upon and documented operations concept will result in poor and misunderstood requirements, cost overruns and schedule slips.

14. Requirements Development (Continued) Writing Good Requirements • “Functional Requirements” - What needs to be done • Functional Requirements are generally not Verified because Performance Requirements specify how good the function needs to be • Functional Requirements define a logical breakdown • “Performance Requirements” - How well it needs to be done • Performance Requirements are Verifiable • Requirements Decomposition and Parent-Child Relationship • Requirements flow from higher to lower levels • Requirements at lower levels (“children”) must trace from a higher level requirement (“parent”) • Eliminate any “orphan requirements” (requirements without parents) • Add rationale or comments to the requirements to help trace “why” that requirement was created

15. Requirements Development (Continued) • Decompose the requirements in a hierarchical, parent-child relationship • Requirements flow from higher to lower levels • Requirements at lower levels (“children”) must trace from a higher level requirement (“parent”) • Eliminate any “orphan requirements” (requirements without parents) • Add rationale or comments to the requirements to help trace why that requirement was created

16. Requirements Development (Continued) • Writing the right requirements • What is necessary to Achieve Full Mission Success Criteria? • Levels of requirements (Level 1, Level 2, etc.) • Level 1 Generally Highest Level Agreement with Ultimate Customer • Lower Levels up to each Project to choose • Traceability (Parent, child, orphan, widow, etc.) • Priorities • Organizing the requirements (templates and guidelines) • Reviewing Requirements • Gate keepers • Formal reviews (SRR, PDR, CDR) • Verification Plan must addresses how each requirement will be verified

17. Requirements Development (Continued) • Use the word “shall” when defining requirements and only for requirements: • “The attitude control system shall point the instrument boresight to within 6 arc seconds of the commanded attitude.” • Make it clear to the reader exactly what must be done. • Requirements should be: • Measurable • Avoid vague statements like “shall point as accurately as possible” • Verifiable • If no one can demonstrate that a system does or does not meet a requirement, then there is no requirement: shall not exceed 55 kg, but we aren’t going to weigh it • Document rationale! • Capture the “why” while it is fresh. • Enable future changes—people are afraid to change things they don’t understand.

18. What the Proposal Promised Preliminary Design Design Drawings What the Customer Wanted As Built by Manufacturing Following Inspection and Rework Design Change Specification What Happened to The Engineering Team After Rework Requirements Development (Continued) The Customer’s Swing The customer requested a new kind of swing that allowed the customer more than one way of swinging. Communication and Understanding is Key!

19. Requirements Management • Collect top-level requirements from customers and stakeholders • Develop operations concept • Derive lower-level requirements to support top-level requirements and the operations concept • Choose an appropriate tool to store and manage the requirements • This can range from an Excel spreadsheet for simple projects to sophisticated tools such as DOORS, Team Center, CORE, etc. for more complex projects • Baseline the requirements at a System Requirements Review (SRR) • “Baseline” means requirements are signed off and put under configuration control • Control any future changes to requirements through a configuration management process

20. Requirements Management (Continued)

21. Operations Concept • An Operations Concept is a vision (in general terms) for what the system is, and a description of how the system will be used. • An Operations Concept consists of a set of scenarios describing how the system will be used during all of its operational phases. • The scenarios are often accompanied by illustrations of the system operations. • An Operations Concept: • Serves as a validation reference for the design throughout the life cycle • Describes how the design can accomplish the mission described by the objectives • Key to defining all the requirements • Evolves into the flight operations plan later in the life cycle

22. Operations Concept (Continued) • Stakeholders participate in the development of the Operations Concept • Trade studies and analyses are used to demonstrate that the operations concept will meet the mission requirements within cost and schedule constraints

23. Operations Concept (Continued) • Considerations for developing an Operations Concept for a Space Mission: • Allocation of functions between ground segment and flight segment • Mission operational modes and configurations • Time ordered sequence of mission activities • Identification of facilities, equipment and procedures needed to ensure the safe development and operation of the system • Operations team size, staffing and extent of automation • Ground segment functions • Contingency concepts • Ground test configurations necessary to accomplish verification including GSE, BTE, simulators and non-flight articles such as ETU’s • Description of functions that cut across various subsystems • Observation strategy • Date collection, storage and downlink • Ground station utilization • Mission orbit maintenance and maneuvers • Power and battery management

24. Operations Concept (Continued) Satellite Operators Control Center Military Planners Request for Data Data Inter -Satellite Link Data Download Command Transmission Image Recording

25. Decomposition Many types of decomposition • Requirements Decomposition • Functional Decomposition • Functional Architecture • Physical Decomposition • Physical Architecture • Operational Architecture • Allocates functions to physical subsystems • Provides complete description of the system design • Integrates the requirements decomposition with the functional and physical architectures

26. Decomposition (Continued) System Requirement User Defined non-exhaustive inclusive based on content and allocation Effectiveness Measure Functional Requirement Performance Requirement Physical Property Requirement Interface Requirement Imposed Design Requirement Reference Requirement

27. Technology Planning • Projects are sometimes initiated with known technology shortfalls • Technology “Pull” • Often there are areas for which new technology will result in substantial product improvement • Technology “Push” • Technology development can be done in parallel with the project evolution and inserted as late as the PDR • Risk mitigation requires a parallel approach that is not dependent on the development of new technology • The technology development activity should be managed as a critical activity

28. Technology Readiness Levels

29. Systems Analysis and Design Modeling • Models are the language of the designer. • Models are representations of the system-to-be-built or as-built. • Models are a vehicle for communications with various stakeholders. • Models allow reasoning about characteristics of the real system. • Models can be used for verification by analysis. • All models must themselves be verified.

30. Systems Analysis and Design (Continued) • There are two basic approaches that are commonly used for system design and integration • Structured Analysis • Object-oriented Analysis and Design • It can be shown that either approach can be translated into the other.

31. Structured Analysis • Structured Analysis • Process Modeling, also known as Data Flow Modeling or Functional Decomposition • IDEF0* • SADT (Structured Analysis & Design Technique) • Data Modeling • IDEF1x • Entity-Relationship Diagrams • Behavior Modeling • Rules • State Transition Diagrams *The IDEF process was developed by the Air Force in the early 1970’s as part of the ICAM program (Integrated Computer Aided Modeling). IDEF originally stood for “ICAM Definition” but NIST later changed it to “Integration Definition”.

32. Structured Analysis (Continued) IDEF0 Student Registration System

33. Structured Analysis (Continued) “ICOM” Control Input Function Output Mechanism

34. Structured Analysis (Continued) Behavior Modeling: State Transition Diagram Ready User ID and Password entered (User_ID, Password)/ accept Verifying start Do: display login page Do: wait for login Do: verify user [Invalid user]/Display:”Access Denied” [Valid user] Validating Options Retrieving [Option selected not allowed]/ Display error message: “Option not allowed” Request for course search Do: display user options Do: check option vs access permission Do: display course search page Do: retrieve course selections [Registration rejected] Request to register (course_nr, user_ID) Request to generate report (User type) Request to register (course_nr, user_ID) Registering Validating Report [Report not allowed]/ Display error message “Option not allowed” Do: display report page Do: validate user vs report selected See superstate diagram [No Conflicts] (course_nr) Report printed (Report type) [Report allowed] Drop request (course_nr) Updating Schedule Generating Report Do: update student schedule Updating complete/ University-updated class roster Do: send database request (report parameters) Do: format report Do: print (report)

35. Structured Analysis (Continued) IDEF1x DATA MODEL

36. Object-Oriented Analysis and Design • Object-Oriented Analysis and Design • The concept of “object” or “object class” is the result of a long history of software engineering design. • From a programming viewpoint, an object is a collection of specialized data packaged with the functions (operations and methods) which are needed specifically by that specialized data. • From a systems design viewpoint, an object is a system or component which maintains its own information and is able to perform some specific functions. • Developed more recently for software engineering, object- oriented design is now migrating to systems engineering. • Object-oriented design defines the relationships between object classes and the behavior of the classes.

37. Unified Modeling Language (UML) • UML is a language for visualizing, specifying, constructing and documenting the artifacts of software-intensive systems, as well as for business modeling and other non-software systems. • UML supports the entire development lifecycle. • UML is supported by many tools (e.g., IBM Rational ROSE, Visio, etc.). • SysML is the extension of UML to systems engineering.

38. (2) Category C C C C Verification (3) Domain of Interest contained in contained in reference for built from C categorizes (63) (5) System View Functional Breakdown (64) (7) (6) System Breakdown has view Stakeholder Environment Element exhibits part of Physical Breakdown (1) (65) has (62) (61) (4) (8) Interacts with Realization View Design View Stakeholder Need satisfied by System (11) (9) allocated to Reference Document System Requirement Property represented by reference for statement of (10) derived from (12) (13) (14) verifies Physical Property Structure Behavior allocated to budgeted to

39. C Unified Modeling Language (UML) (3) Domain of Interest Box means Class or Meta Class (top is name) or type 2nd box means attributes 3rd box means Methods or member functions Diamond means aggregation/decomposition Line means relationship (words on line describe relationship) (XX) Means look at Concept semantic dictionary Diamond with a C in the middle means a Complete decomposition Loop line with Diamond means hierarchal decomposition of items of the same type Arrow/triangle means specialization/generalization Depending on direction A number on each end of a line means multiplicity (1) (4) (22.10) 1 1 From MDSD Workshop 5 Feb 2003

40. UML vs. SysML

41. “Concurrent Design” Integrated Mission Design Center (IMDC) at Goddard Space Flight Center

42. “Concurrent Design” Collaborative, Rapid Design Improves Quality of Conceptual Designs Preliminary design in one week vs. six months

43. Small Explorers (SMEX) Built at GSFC Submillimeter Astronomy Satellite (SWAS) Transition Region And Coronal Explorer (TRACE) Wide-Field Infrared Explorer (WIRE) Solar Anomalous and Magnetospheric Particle Explorer (SAMPEX) Fast Auroral Snapshot Explorer (FAST)

44. System Integration • Integration is the process of assembling the system from components. • Integration begins with the elementary pieces or configuration items (CI’s) of the system. • After each CI is tested, components comprising multiple CI’s are tested. • This process continues until the entire system is assembled and tested. • Interface Specifications and Interface Control are critical to a successful system integration.

45. Work and Resource Management • A Work Breakdown Structure (WBS) is a hierarchical breakdown of the work necessary to complete a project. • The WBS should be a product-based, hierarchical division of deliverable items and associated services. • The WBS should contain the Product Breakdown Structure (PBS). • At the lowest level are products such as hardware items, software items, and information items (documents, databases, etc.) for which there is a cognizant engineer or manager. • A project WBS should be carried down to the cost account level appropriate to the risks to be managed.

46. Work Breakdown Structure (WBS)

47. Product Breakdown Structure (PBS)

48. Technical Resource Management • Critical mission resources shall be identified, allocated and managed • Acceptable resource margins shall be established • A margin management philosophy shall be set up based on design maturity and time • Required margins are reduced as the project matures • Margins are assessed based on the fidelity of the estimate • Care must be taken that margins are not added to margins • Stacked margins that do occur simultaneously in real life • Lead systems engineer holds the overall system margins • Subsystem engineers must be allowed to hold some margin in order to meet their design requirements • This hierarchy of margins must be taken into account so that the overall system margins do not drive the design and the cost

49. Example: Technical Resource Margins Tracking Estimates (Mass) • Allocations defined at SRR for appropriate total margin • Estimates tracked monthly • Changes to allocation via CCR • Estimates over total allocation trigger risk reduction activities

50. Specialty Engineering • Specialty engineers support the systems engineering process by applying specific knowledge and analytic methods from a variety of engineering specialty disciplines to ensure that the resulting system is actually able to perform its mission in its operational environment. • For space systems these specialty areas often include: • Quality Assurance • Reliability • Maintainability • Producibility • Logistics • Safety • Environment (e.g., radiation, atomic oxygen, atmospheric density, etc.) • Contamination • Parts Engineering