design fundamentals module space systems engineering, version 1.0
DESCRIPTION
Design Fundamentals Module Space Systems Engineering, version 1.0. Module Purpose: Design Fundamentals. To understand the design process and the different methods for conducting a design effort. - PowerPoint PPT PresentationTRANSCRIPT
Space Systems Engineering: Design Fundamentals Module
Design FundamentalsModule
Space Systems Engineering, version 1.0
2Space Systems Engineering: Design Fundamentals Module
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.
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?
4Space Systems Engineering: Design Fundamentals Module
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.
5Space Systems Engineering: Design Fundamentals Module
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.
6Space Systems Engineering: Design Fundamentals Module
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
7Space Systems Engineering: Design Fundamentals Module
How Inventive Must You Be?
Level Degree of Inventiveness
% ofSolutions
Source of Knowledge
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.
8Space Systems Engineering: Design Fundamentals Module
Design Solution Drivers
Developing Organization’s Management Stakeholder
Political Stakeholder
End-User Stakeholder
Public Stakeholder
Headquarters Stakeholder
DevelopmentStaff
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
9Space Systems Engineering: Design Fundamentals Module
Concept and Design Development Methods
Ref.: Rechtin and Maier, The Art of Systems Architecting
Methods BasisExamples
Normative Solution basedBuilding codes, comm. standards
Rational Method basedSystem analysis and engineering (functional analysis, object oriented analysis, etc.)
Participative Stakeholder basedConcurrent Engineering and brainstorming
Heuristic Lessons learnedSimplify, simplify, simplify
10Space Systems Engineering: Design Fundamentals Module
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.
11Space Systems Engineering: Design Fundamentals Module
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?”)
12Space Systems Engineering: Design Fundamentals Module
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.
13Space Systems Engineering: Design Fundamentals Module
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)
14Space Systems Engineering: Design Fundamentals Module
NASA AO Heritage Grading Scale
Design Identical Minimal modifications Major modifications
Manufacture Identical Limited update of parts and processes necessary
Many updates of parts or processes necessary
Software Identical Identical 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 Identical Same interfaces and similar use within a novel overall context
Significantly different from original
Operating Environment
Identical Within margins of original Significantly different from original
Referenced Mission In operation Built and successfully ground tested
Not yet successfully ground tested
Full Heritage Partial Heritage No Heritage
Space Systems Engineering: Design Fundamentals Module
The Stardust - Genesis Mission Heritage Story
16Space Systems Engineering: Design Fundamentals Module
Stardust – Utah Landing, 1/16/06
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.
18Space Systems Engineering: Design Fundamentals Module
Acceleration Vector Required for G-Switch toFunction
Actual AerodynamicBraking Force Direction
Mounting Base of AU
Heatshield
SwitchesSwitcheswere were
Reversed!Reversed!
G-Switch Orientation
19Space Systems Engineering: Design Fundamentals Module
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
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.
21Space Systems Engineering: Design Fundamentals Module
Module Summary: Design Fundamentals
The basic steps in the design process include:1. Establish the need2. Define mission scope3. Establish evaluation criteria4. Generate feasible alternatives5. Evaluate alternatives6. Downselect to baseline mission7. 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.
Space Systems Engineering: Design Fundamentals Module
Backup Slidesfor Design Fundamentals Module
23Space Systems Engineering: Design Fundamentals Module
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
24Space Systems Engineering: Design Fundamentals Module
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
25Space Systems Engineering: Design Fundamentals Module
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
26Space Systems Engineering: Design Fundamentals Module
Creative Methods: Brainstorming
1. Establish a diverse team, preferably <10 people2. 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 session7. 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.
27Space Systems Engineering: Design Fundamentals Module
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.
28Space Systems Engineering: Design Fundamentals Module
Genesis – September 8, 2004
29Space Systems Engineering: Design Fundamentals Module
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
30Space Systems Engineering: Design Fundamentals Module30
Morphological Matrix
Example Morphological Matrix for a High-speed Civil Transport
31Space Systems Engineering: Design Fundamentals Module
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)