Gateway To Space ASEN ASTR 2500 Class 12

Gateway To Space ASEN / ASTR 2500 Class #12 Colorado Space Grant Consortium 1 T-37

Today… - Announcements - One Minute Reports - Guest Lecture on Systems Engineering Next Week - p. CDR 2

Announcements… - Grades posted - Passwords? - Hardware is coming in, please check your email - HW 6 due today, reviewed end of class - DD Rev A/B is due 10/05 7: 00 AM - p. CDR slides are due 10/05 7: 00 AM 3

p. CDR… - pre Critical Design Review (NEW!) - Each team will have 8 minutes to present and 7 minutes for questions - Template is on the class website - Presentation order will be… 10/05 10/07 10, 8, 6, 4, & 2 9, 7, 5, 3, & 1 4

One Minute Reports… - Reading them but… - Look for an email this week with answers - Sending ones to Jim Paradise and then will send his responses back to you via email - Jim’s email is… jim. paradise@lmco. com 5

One Minute Reports… 6

One Minute Reports… 7

One Minute Reports… 8

Rocky outcrop Victoria Crater in the distance Image credit: NASA/JPL-Caltech MRO

Questions? Colorado Space Grant Consortium 10

Systems Engineering Julia Chu Lockheed Martin Class #11 Colorado Space Grant Consortium T-39

Introduction to Systems Engineering Julia Chu September 15, 2009 Some material developed by P. Robitaille and INCOSE 12

How Would You Define SE? 13

Systems Engineering… • Is a systematic, interdisciplinary approach that transforms customer needs into a total system solution • Is led by systems engineers - But all functions play a role; Integrated via clear roles & responsibilities • Must be rigorously applied across program • Is the technical "glue" which makes separate design disciplines and subsystems function together to provide an integrated system which performs a specific job. Systems Engineering is a PROCESS Not an organization 14

The Systems Viewpoint • The Design Engineer has the specialist's viewpoint. Views the system from the inside. - Concerned with other system elements only as they affect their own design task; but not necessarily how theirs may affect others • The Systems Engineer has the systems viewpoint. Views the system from the outside. - Concerned with the effect of all system elements as they affect overall system design / performance / cost / schedule 15

Why Systems Engineering? Systems Engineering must focus on the entire problem: optimize the whole, not the parts! 16

Systems Engineering Objectives • Systematic elimination of less desirable concepts and early selection of a single preferred system approach. • Early identification and resolution of critical problem areas. • Focusing of technical expertise to match program needs. • Maintaining compatibility among separate but interrelated technical activities. • Maintaining technical oversight and configuration control throughout concept definition, design, implementation, and support phases. Key objective: achieve a balanced, affordable design that meets stakeholder needs 17

Integrated Product Teams (IPTs) Customer Program Business Support IPT Program Management Integrated Product Team (IPT) Systems Engineering Integration Team (SEIT) Customer Product 1 IPT Product 2 IPT Product 3 IPT Product N IPT Customer The SEIT Provides SE Guidance & Support to other IPTs which apply SE Process to their activities. 18

Systems Engineering Tasks No temporal flow is intended for performing these tasks 19

Requirement/Integration/Verification Roadmap Systematic Build-Up of Orion Capabilities “design to” uire Req “design to” System T&V Plans, Procedures, Reports Verify to requirements in Section 4 of Module Specs Element T&V Plans, Procedures, Reports Integration “design to” Component, CSCI Specs Procurement Specifications Make-Buy decisions Verify to requirements in Section 4 of Component, CSCI Specs HW Drawings, Design Docs Inspections bench test SW SDDs, UML, etc Inspect, unit test, integrate units into CSCs (CSC I&T) CSCI, Comp. T&V Plans, Procedures, Reports d Ve Subsystem T&V Plans, Procedures, Reports n an Verify to requirements in Section 4 of Subsystem Specs ratio “design to” Subsystem Specs Integ n itio efin d. D n an itio pos com t De rifica men Element Specs tion System Specs Pe r Pe form rfo rm I&T & Pre activ forma T&V pa ities l ve ac r c As s ver e rep acco rifica ordin Int emb ific orts rdi tion g t eg l o n atio Pe rate e & in n a docu g to t & qua plan rfo t m e C e c lif s rm g tivi S e ties nting t proc icatio info Cs i rate rm nto com a ll fo edur n al i C rm es nte SCI pone al nt gra tion act ivit ies (te sts , d em os) 20

Bi-directional Requirements. Traceability Flow [System to Item Overview] Analyze System Requirements 2. 3. 3 -T 1 -Sys. Eng-1. 0 -P System Requirements/Des ign Task 4 Step 4. 2 Design System 2. 3. 4 -T 1 -Sys. Eng-1. 0 -P Task 3. 5 Establish and maintain bi-directional traceability between system requirements and their allocated element… Develop/Acquire Element 2. 3. 5 -T 1 -Des. Eng-1. 0 -P Item Requirements/Des ign Establish and maintain… bi-directional traceability between the allotted element requirements, the detailed derived requirements and the work products… e Task 2. 5 Drawings Schematics Part lists/Specs Traceability Flow Task 2. 3 Develop/Acquire Item 2. 3. 6 -T 1 -Des. Eng-1. 0 -P r tu c ite ch Ar ts/ n en w m do ire low F qu Re Element Requirements/Des ign …Document…traceability to mission requirements. System requirements are flowed down to lower level requirements…. Computer Models Establish and maintain bi-directional traceability between item requirements and the higher level element requirements. Item Requirement Database 2. 3. 6 -T 1 -Des. Eng-1. 0 -P W 1 Sect 4 The Item reqmt Database shall include …Traceability from a reqmt to its source reqmt… 21 reqmt… …Traceability from a reqmt to its derived

Bi-directional Requirements Traceability Flow [Verification Activity] • A verification matrix that provides the map from system requirements( specs and interface docs) to the verification program activities. • The SVP shall identify component configurations that shall be subject to each verification activities. …The requirements shall show the bi-directional traceability between the system requirements and their associated verification…ensuring that every product requirement is assigned at least one verification activity. Task 2: Prepare for Verification Activities Task 2. 2 p on R Task 1. 7 Element Product/Verificati on -u The SVP (Sys Verif Plan) shall contain or reference as a minimum: oll Task 1. 4. 1 Item Product/Verificati on ati Document Verification Requirements Traceability rifi c Task 1. 1. 7 System Product/Verificati on Ve Task 1: Perform Verification Planning Verify system 2. 3. 8 -T 1 -Sys. Eng-1. 0 -P The procedures shall contain, as a minimum, the elements defined below: • Identification of the item and specific requirement being verified • Traceability to the requirement identifier, including references to governing plans Task 3: Executing Verification Task 3. 1. 1 Qualification tests, design analyses, demonstrations and inspections shall be conducted to…have resulted in a product that conforms to specification requirements. Drawings Schematics Part lists/Specs Computer Models Traceability Flow 22

SE throughout Product Life Cycle SE begins with program or proposal, whichever comes first, and continues throughout a program’s life cycle SE Effort 15 to 20 Percent of total engineering effort on complex development programs Program Life-Cycle Phases Do. D 5000. 2 2003 Pre 2002 -2003 Demonstration Production & Pre-Concept Disposal & Validation Deployment System Production & & Technology Concept Operations Concept & Operations Development&& Deployment Development Refine. Support Technology &&Support Demonstration ment Development Concept Engineering & Operation Exploration & Manufacturing & Support Definition Development 23

Requirements Tasks • Ensure clear, consistent requirements • Decompose requirements from highest to lowest level - complete - unambiguous - verifiable • Understand constraints - cost - schedule - technical capability 24

Why are Requirements Important? • Ensure that engineers understand problem to be solved • Provide contractual basis for verification and acceptance • If requirements are wrong, so is everything else - architecture, design, tests Poor Requirements yield Wrong Products! 25

Why are Requirements important? As Contracts Specified It As Manufacturing Assembled It As Engineering Designed It As Test Verified It As Materiel Ordered It What the Customer Wanted Clearly communicating requirements is essential 26

Requirements and Design Q: Where do requirements end and design begin? A: There is no dividing line. Design work at one level generates requirements for the next lower level. Stakeholder Needs & Mission Requirements Operational Concepts op Pr s e ng ha Repeat to lowest item level C One Requirements Repository/Tool for ALL Data and Disciplines ed Element Requirements os System Architectural Design System Requirements Element Design Items 27

Why is it Important to Manage Requirements? • To ensure that there is a stable, consistent requirements baseline • To avoid requirements growth - “Better is the enemy of good” - Voltaire • To ensure everyone is working to the same set of requirements • To get appropriate cost impact assessments for proposed changes from all stakeholders 28

Integration Tasks • Optimize system design - the best solution for a subsystem may not be the best system solution • Ensure elements, subsystems, components will all work together - validate requirements - identify and resolve technical inconsistencies - identify and resolve interface issues • Manage program risk • Manage program plans 29

Why is Integration Important? • Plans allow the program to execute successfully - plan the technical effort, delineate roles & responsibilities - define tasks and schedules to accomplish the work - allow for changes along the way • Identify problems early enough to mitigate them at low cost - What is risk? “A potential event that would be detrimental to the program as related to system performance, cost, or schedule” 30

Cumulative Percentage Life Cycle Cost Impact of SE on Program Cost 100% 85% 90% 80% 70% 60% t to s Co 3 -6 X 50% 40% ts 500 -1000 X c e ef D ct a r t Ex 20 -100 X Prod/Test 30% 20% 10% 0% 95% Committed Costs Concept Phase 8% Design Phase 15% Phase Development 100% 50% 20% Time Full Program Expenditures Operations Through Disposal Defense Systems Management College - 9/1993 Typically, by the time system level design is complete, around 85% of the costs have been committed and the cost to extract defects goes up exponentially 31

Verification Tasks • Ensure that the design meets the requirements - done at every level (component to system) • Start with planning - how should each requirement be verified? - test, analysis, inspection, demonstration? - how much is enough? - what is cost-effective? • Ensure verifications are complete - inspection of test conditions and results, analysis reports, etc. 32

Why is Verification Important? • To ensure the system as built will work as planned before it becomes operational • Customers and designers love test - some test is always needed – the key is to choose wisely - test is often the most expensive verification method - cases that are difficult to test may be better to verify by analysis • Choosing the “wrong” verification methods may result in a failure - INTELSAT 33

Characteristics of SEs - Ability to focus on complex problems - Ability to balance risk and opportunity - Ability to facilitate problem solving (involving various domain experts) - Good interpersonal communications skills (to elicit requirements, etc. ) - Excellent logic capability and disciplined work habits Decision making capability (process data and come to conclusion in a timely manner) - Ability to work in teams across functional boundaries - Process awareness and applicability A Systems Engineer needs to be disciplined, balance risk and opportunity, and work across functional boundaries 34

In summary, Systems Engineering: - Focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceed with design. - Provides early IV&V to reduce cost, schedule, and risk - Integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. - Provides confidence that a design will operate successfully. - Considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. 35

Questions? Homework 6 Review Colorado Space Grant Consortium 36

In-Class Exercise: - During this exercise, you and your team will design a spacecraft that meets the following mission requirements. - This exercise is designed to give you and your team a glimpse into the world of a real systems engineer. - This exercise was designed by Julia Chu from Lockheed Martin with some formatting Chris. 37

In-Class Exercise: NASA Mission Announcement – Chu. Sat Design a spacecraft in 30 minutes that will meet the following two requirements: 1. The total mass of the power, science instruments, and propulsion shall not exceed 900 lbm. a. The propulsion mass shall include the mass of propellant 38

In-Class Exercise: NASA Mission Announcement – Chu. Sat Design a spacecraft in 30 minutes that will meet the following two requirements: 2. The spacecraft shall collect a minimum of 20 hours of scientific data a. The spacecraft shall collect data in the 1 x 10 -9 to 1 x 10 -10 wavelengths b. The spacecraft shall collect data in the 1 x 10 -3 to 1 x 10 -4 wavelengths The following subsystem capabilities and specifications are at your disposal. 39

In-Class Exercise: 40

In-Class Exercise: 41

In-Class Exercise: 42