Design Fundamentals Module Space Systems Engineering, version 1.0

1. Design FundamentalsModule SpaceSystems Engineering, version 1.0

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. 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. Mission Design Process - Overview Image from “Human Spaceflight Mission Analysis and Design,” ed. W. Larson. 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

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. Alternative Mars Exploration Concepts • 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 #3 - Balloon Concept #2 - Airplane

7. How Inventive Must You Be? Degree of Inventiveness % of Solutions Source of Knowledge Level 1 Obvious solution 32% Personal knowledge 2 Minor improvement 45% Knowledge within company 3 Major improvement 18% Knowledge within industry 4 New concept 4% Knowledge outside the industry 5 Discovery 1% 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.

8. Developing Organization’s Management Stakeholder Development Staff Political Stakeholder End-User Stakeholder Public Stakeholder Headquarters Stakeholder Design Solution Drivers Satisfy everyone? Architect Low cost, low risk, timely delivery, keep politicians happy 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

9. Concept and Design Development Methods Methods Basis Examples Normative Solution based Building codes, comm. standards Rational Method based System analysis and engineering (functional analysis, object oriented analysis, etc.) Participative Stakeholder based Concurrent Engineering and brainstorming Heuristic Lessons learned Simplify, simplify, simplify Ref.: Rechtin and Maier, The Art of Systems Architecting

10. Spacecraft Environments Research and know the environments in which your spacecraft must survive. • 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

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. 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. Heritage Instructions in NASA’s Announcement of Opportunity Missions (2/2) 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.

14. NASA AO Heritage Grading Scale Full Heritage Partial Heritage No Heritage

15. The Stardust - Genesis Mission Heritage Story

16. Stardust – Utah Landing, 1/16/06

17. 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. G-Switch Orientation Acceleration Vector Required for G-Switch to Function Heatshield Actual Aerodynamic Braking Force Direction Switches were Reversed! Mounting Base of AU

19. 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 The String of Events

20. 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. Module Summary: Design Fundamentals • The basic steps in the design process include: • Establish the need • Define mission scope • Establish evaluation criteria • Generate feasible alternatives • Evaluate alternatives • Downselect to baseline mission • 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. Backup Slidesfor 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. 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. 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. Creative Methods: Brainstorming • Establish a diverse team, preferably <10 people • Determine who in the group will facilitate the brainstorming • Discussion facilitator should try to get everyone to contribute • Clearly define the problem you want solved, and lay out criteria to be met • Initiate process with quiet time; group members start by writing down first ideas that come to mind • 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 • Reflect and build on each other’s ideas during session • 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. Genesis – Missed Technical Review Opportunities 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. • 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?

28. Genesis – September 8, 2004

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. Morphological Matrix Example Morphological Matrix for a High-speed Civil Transport 30

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)