1. Space Systems Engineering: Design Fundamentals Module Design Fundamentals Module Space Systems Engineering, version 1.0

2. Space Systems Engineering: Design Fundamentals Module 2 Module Purpose: Design Fundamentals  To understand the design process and the different methods for conducting a design effort.  To consider previous design solutions in addition to various alternatives early in the process to satisfy initial requirements.  For spacecraft hardware, to understand the appropriateness of heritage applications and how to characterize them.  To discuss a NASA example of heritage use.

3. Space Systems Engineering: Design Fundamentals Module For those who have taken the senior mission design class: Thoughts on your “design experience”… Why do we need a process for design? Lessons learned for future design classes?

4. Space Systems Engineering: Design Fundamentals Module 4 Mission Design Process - Overview Steps in the design process: Establish the need Define mission scope Establish evaluation criteria Generate feasible alternatives Evaluate alternatives Downselect to baseline mission Detailed design Image from “Human Spaceflight Mission Analysis and Design,” ed. W. Larson.

5. Space Systems Engineering: Design Fundamentals Module 5 Do Your Research  Investigate past missions similar to yours to draw on previous design solutions.  Understand mission analogies and the current state-of-the-art (e.g., comparing the ISS to a Mars transfer habitat module) Questions to ask:  Has this type of mission ever been done before?  Yes…were the objectives the same? What challenges were encountered? What new approaches were used?  No…what “paper” designs exist? Are objectives and constraints the same? Are advanced technologies employed?  Warning: the design team should be careful to avoid early adoption of a candidate system from a previous mission in order to avoid being locked into a system that only marginally meets or does not meet your objectives/requirements.

6. Space Systems Engineering: Design Fundamentals Module 6 Alternative Mars Exploration Concepts Concept #3 - Balloon Requirements can often be satisfied multiple ways. Use the creativity of your team. Avoid rejecting “obvious misfits.” Avoid premature adoption of “The Solution.” Create reference scenarios (ConOps) to investigate critical issues. Concept #1 - Rover Concept #2 - Airplane

7. Space Systems Engineering: Design Fundamentals Module 7 How Inventive Must You Be? Level Degree of Inventiveness % of Solutions Source of Knowledge 1Obvious solution32%Personal knowledge 2Minor improvement45%Knowledge within company 3Major improvement18%Knowledge within industry 4New concept4%Knowledge outside the industry 5Discovery1%All that is knowable Based on Genrich S. Altshuller, the “Father of TRIZ” screening of over 40,000 patents.  Conclusion: Most concepts and designs are modifications of previous concepts and designs with relatively little inventiveness. Seek them first!!  Effective system engineering is required to implement solutions to meet user needs at the required level. Based on Genrich S. Altshuller, the “Father of TRIZ” screening of over 40,000 patents.  Conclusion: Most concepts and designs are modifications of previous concepts and designs with relatively little inventiveness. Seek them first!!  Effective system engineering is required to implement solutions to meet user needs at the required level.

8. Space Systems Engineering: Design Fundamentals Module 8 Design Solution Drivers Developing Organization’s Management Stakeholder Political Stakeholder End-User Stakeholder Public Stakeholder Headquarters Stakeholder Development Staff Satisfy everyone? Conform to standards, reusability, keep people employed! Neat technology, fun, career enhancing! Neat features, short time to market, low cost, what’s in it for my constituents! Behavior, performance, science, reliability! Neat features, pictures, TV, new technology Low cost, low risk, timely delivery, keep politicians happy Architect

9. Space Systems Engineering: Design Fundamentals Module 9 Concept and Design Development Methods Ref.: Rechtin and Maier, The Art of Systems Architecting MethodsBasisExamples NormativeSolution basedBuilding codes, comm. standards RationalMethod basedSystem analysis and engineering (functional analysis, object oriented analysis, etc.) ParticipativeStakeholder basedConcurrent Engineering and brainstorming HeuristicLessons learnedSimplify, simplify, simplify

10. Space Systems Engineering: Design Fundamentals Module 10 Spacecraft Environments  Launch environment Is your spacecraft manifested on a designated launch vehicle? Vibration, noise, g-loads, aerodynamic loads, transition to vacuum, etc.  Space environment Is your spacecraft flying beyond the Van Allen belts or in LEO/GEO? Hard vacuum, radiation, temperature extremes, orbital debris  Planetary environment Is your vehicle entering a planetary atmosphere? Entry aerodynamics and the accompanying loads and heating  Planetary surface environment Is your spacecraft landing on a planetary surface? Moon, Mars, asteroid? Gravity levels, terrain, atmosphere, dust, temperature Research and know the environments in which your spacecraft must survive.

11. Space Systems Engineering: Design Fundamentals Module 11 Basic Design Principles  It is better to make a few “questionable” decisions that keep the design process moving forward rather than delay decisions to make the design “perfect”. Remember, “better is the enemy of good enough;” hence, avoid the temptation to make the design better if it is already good enough.  Designs should employ a “keep it simple” philosophy (i.e., straight- forward designs) to reduce risk and cost and to enable easy implementation and flight operational usage.  Design descope options should be identified early in design conceptualization. (Where descope means content, such as an instrument or operational capability, is removed from the scope of the system or mission). The impacts on the design performance resulting from exercising these options should be understood.  Projects should use independent peer review of designs. (“what do your colleagues think?”)

12. Space Systems Engineering: Design Fundamentals Module 12 Heritage Instructions in NASA’s Announcement of Opportunity Missions (1/2) Describe the heritage for each instrument, each spacecraft subsystem, each ground system, and each major module of flight or ground software. The description should address: The design basis:  Describe the closest heritage system, including recent application(s), dates of use, developer institution, and cost.  Is the developer (institution) on the proposing team?  Will the individuals who participated in the heritage basis be available to the proposing team?  State whether spaceflight-proven, ground or aircraft application, or other status.  Indicate the highest assembly level at which full heritage is claimed.

13. Space Systems Engineering: Design Fundamentals Module 13 Difference between the basis and the proposed design:  Describe differences in the environment and/or application.  Why is the design modification required?  Specify exactly what will be modified.  Characterize the difference in relevant terms: mass reduction, reduced power draw, cost saved, etc. Development challenges:  Describe any circumstances that might adversely impact the proposer’s ability to achieve the planned design heritage or to deliver the new technology item.  Describe the steps planned to ensure that claimed design heritage is captured.  Describe remedial action plan should the expected design prove undeliverable within resources. Heritage Instructions in NASA’s Announcement of Opportunity Missions (2/2)

14. Space Systems Engineering: Design Fundamentals Module 14 NASA AO Heritage Grading Scale Design IdenticalMinimal modificationsMajor modifications Manufacture IdenticalLimited update of parts and processes necessary Many updates of parts or processes necessary Software IdenticalIdentical functionality with limited update of SW modules (<50%) Major modifications (>=50%) Provider Identical provider and development team Different however with substantial involvement of original team Different and minimal or no involvement of original team Use IdenticalSame interfaces and similar use within a novel overall context Significantly different from original Operating Environment IdenticalWithin margins of originalSignificantly different from original Referenced Mission In operationBuilt and successfully ground tested Not yet successfully ground tested Full Heritage Partial HeritageNo Heritage

15. Space Systems Engineering: Design Fundamentals Module The Stardust - Genesis Mission Heritage Story

16. Space Systems Engineering: Design Fundamentals Module 16 Stardust – Utah Landing, 1/16/06

17. Space Systems Engineering: Design Fundamentals Module Genesis Mishap When the Genesis spacecraft returned to Earth on September 8, 2004, the parachutes failed to deploy. The spacecraft plunged into the Utah desert at 200 mph and broke apart. The redundant sets of switches controlling parachute deployment failed to respond to reentry deceleration because both sets were installed backwards as specified in the Lockheed- Martin design.

18. Space Systems Engineering: Design Fundamentals Module 18 Acceleration Vector Required for G-Switch to Function Actual Aerodynamic Braking Force Direction Mounting Base of AU HeatshieldSwitcheswereReversed!SwitcheswereReversed! G-Switch Orientation

19. Space Systems Engineering: Design Fundamentals Module 19 The String of Events  Schematic copied from Stardust  Box CDR lacked technical content  Verification requirements not clear Centrifuge test expected (in CDR package), but not required. Verification matrix had test, but no detail Systems Engineering did not have to sign off on Subsystem plans  Designer verified function (open/close) of switches; Systems Engineering believed orientation of switches were verified  Electrical designer incorrectly performed orientation verification via Mechanical drawing inspection  Red Team review assumed design was correct because it was a “heritage” design  Systems Engineering did not close the loop with the designer Systems Engineering not required to review test result Breakdown  Heritage  Design Review Weakness  Systems Engineering Breakdown; Heritage  Systems Engineering Breakdown  Systems Engineering Breakdown; Heritage  Design Review Weakness; Heritage  Systems Engineering Breakdown

20. Space Systems Engineering: Design Fundamentals Module Heritage Hardware – Treat It Like a New Design Gold Rule (1.11): All use of heritage flight hardware shall be fully qualified and verified for use in its new application. This qualification shall take into consideration necessary design modifications, changes to expected environments, and differences in operational use. Here is a New Gold Rule currently in review: Do not qualify by similarity - use the traditional verification methods of test, analysis, inspection, and demonstration instead of similarity.

21. Space Systems Engineering: Design Fundamentals Module 21 Module Summary: Design Fundamentals  The basic steps in the design process include: 1.Establish the need 2.Define mission scope 3.Establish evaluation criteria 4.Generate feasible alternatives 5.Evaluate alternatives 6.Downselect to baseline mission 7.Detailed design  There are four basic methods for concept and design development: normative, rational, participative and heuristic.  Most concepts and designs are modifications of previous concepts and designs with relatively little inventiveness.  Design descope options should be identified early in design conceptualization. (Where descope means content is removed from the scope of the system or mission).  There are numerous questions to ask regarding the application of heritage hardware to a new system or mission. Thorough systems engineering is required to ensure the application is viable.

22. Space Systems Engineering: Design Fundamentals Module Backup Slides for Design Fundamentals Module

23. Space Systems Engineering: Design Fundamentals Module 23 Normative Methods The solution is driven “By-the-Book” Codes and standards are established over time. For public safety or to assure conformance with over-arching requirements To assure interface compatibility across company, industry, country issues Little freedom for innovation Examples: –Telecom network standards –Corporate design standards –Government regulations –Legacy or interfacing system design –Codes & Standards

24. Space Systems Engineering: Design Fundamentals Module 24 Rational Methods Techniques to aid the transformation from a requirements mapping to a design solution Identifies solution elements (decomposition) and allocates functionality and performance to them Methods are rule-based and are chosen to optimize solution features (re-usability, modifiability, implementation independence) Team should choose their preferred methods Train as required Examples: –Structured design techniques –Object oriented analysis techniques –Data analysis techniques –Textbook system analysis and design Deductive Methods

25. Space Systems Engineering: Design Fundamentals Module 25 Participative Methods Processes involving multi-functional teams Integrated product team (IPT) Concurrent engineering Timely involvement of all stakeholders to assure all life cycle requirements and interests are accommodated Examples: –Knowledge café –Brainstorming –Tiger teams –Skunk works –Quality circles –Delphi sessions

26. Space Systems Engineering: Design Fundamentals Module 26 Creative Methods: Brainstorming 1.Establish a diverse team, preferably <10 people 2.Determine who in the group will facilitate the brainstorming Discussion facilitator should try to get everyone to contribute 3.Clearly define the problem you want solved, and lay out criteria to be met 4.Initiate process with quiet time; group members start by writing down first ideas that come to mind 5.Take turns reading ideas and submitting to group If ideas written on yellow stickies, then facilitator can post and sort during feedback session. Caution: no criticisms during session Want to encourage creativity 6.Reflect and build on each other’s ideas during session 7.End session when creativity appears to be tapped out Goal: generate lots of ideas; improve on each other’s ideas; encourage creative solutions; save analysis for later.

27. Space Systems Engineering: Design Fundamentals Module 27 Genesis – Missed Technical Review Opportunities  Questions: What happened at the technical reviews? Were the “design-to” specifications and evidence supporting the design approach provided at PDR? Were they assessed? Were the detailed designs, supporting analyses and development test data provided at CDR? Were they assessed? Were verification data proving compliance with specifications provided at SAR? Were they assessed? When the Genesis spacecraft returned to Earth on September 8, 2004, the parachutes failed to deploy. The spacecraft plunged into the Utah desert at 200 mph and broke apart. The redundant sets of switches controlling parachute deployment failed to respond to reentry deceleration because both sets were installed backwards as specified in the Lockheed-Martin design.

28. Space Systems Engineering: Design Fundamentals Module 28 Genesis – September 8, 2004

29. Space Systems Engineering: Design Fundamentals Module 29 Establishing and Identifying Options  Given a prohibitively large number of possible options, how does one determine which ones to evaluate and compare?  Morphological Matrix Purpose: to help consolidate brainstorming results, to identify possible new combinations for a system, or as a spur to creativity A functional and structured means of decomposing a system or product and identifying options Procedure Functionally decompose the existing system or product For each function, list all the possible ways in which it might be satisfied Organize into a Morphological Matrix Examine the matrix for possible new permutations

30. Space Systems Engineering: Design Fundamentals Module 30 Morphological Matrix Example Morphological Matrix for a High-speed Civil Transport

31. Space Systems Engineering: Design Fundamentals Module 31 Multi-Attribute Decision Making (MADM)  In any decision to be made, one will always evaluate a decision based on some implicit or explicit evaluation criterion (i.e. reliability, cost, “Oooo… I like that one,” etc.)  In general, more than one criterion will describe a system and is typically in conflict with another criterion  Thus, making a decision will inherently be subjective if multiple criteria exist  A number of methods exist for selecting the best alternative  For the purposes of this class, we will take a closer look at one of these many methods – the Analytical Hierarchy Process (AHP)