Design Fundamentals
Module
Space Systems Engineering, version 1.0
Space 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
2
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?
Space 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.
Space Systems Engineering: Design Fundamentals Module
4
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.
Space Systems Engineering: Design Fundamentals Module
5
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.”
Concept #1 - Rover
Concept #2 - Airplane
Space Systems Engineering: Design Fundamentals Module
Concept #3 Balloon
• Create reference
scenarios
(ConOps) to
investigate critical
issues.
6
How Inventive Must You Be?
Level
Degree of
Inventiveness
% of
Solutions
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.
Space Systems Engineering: Design Fundamentals Module
7
Design Solution Drivers
Satisfy everyone?
Architect
Conform to
standards,
reusability,
keep people
employed!
Developing
Organization’s
Management
Stakeholder
Neat
features,
short time to
market, low
cost, what’s
in it for my
constituents!
Neat
technology,
fun, career
enhancing!
Development
Staff
Political
Stakeholder
Space Systems Engineering: Design Fundamentals Module
Behavior,
performance,
science,
reliability!
End-User
Stakeholder
Neat
features,
pictures, TV,
new
technology
Public
Stakeholder
Low cost, low
risk, timely
delivery, keep
politicians
happy
Headquarters
Stakeholder
8
Concept and Design
Development Methods
Methods
Normative
Basis
Solution based
Rational
Method based
Participative
Stakeholder based
Heuristic
Lessons learned
Examples
Building codes, comm.
standards
System analysis and
engineering (functional
analysis, object
oriented analysis, etc.)
Concurrent
Engineering and
brainstorming
Simplify, simplify,
simplify
Ref.: Rechtin and Maier, The Art of Systems Architecting
Space Systems Engineering: Design Fundamentals Module
9
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
Space Systems Engineering: Design Fundamentals Module
10
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., straightforward 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?”)
Space Systems Engineering: Design Fundamentals Module
11
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.
Space Systems Engineering: Design Fundamentals Module
12
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.
Space Systems Engineering: Design Fundamentals Module
13
NASA AO Heritage Grading Scale
Full Heritage
Partial Heritage
No Heritage
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
Built and successfully
ground tested
Not yet successfully
ground tested
Referenced Mission In operation
Space Systems Engineering: Design Fundamentals Module
14
The Stardust - Genesis Mission Heritage Story
Space Systems Engineering: Design Fundamentals Module
Stardust – Utah Landing, 1/16/06
Space Systems Engineering: Design Fundamentals Module
16
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 LockheedMartin design.
Space Systems Engineering: Design Fundamentals Module
G-Switch Orientation
Acceleration
Vector
Required for
G-Switch to
Function
Mounting Base of AU
Space Systems Engineering: Design Fundamentals Module
Heatshield
Actual
Aerodynamic
Braking
Force
Direction
Switches
were
Reversed!
18
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
Space Systems Engineering: Design Fundamentals Module
Breakdown
Heritage
Design Review Weakness
Systems Engineering
Breakdown; Heritage
Systems Engineering
Breakdown
Systems Engineering
Breakdown; Heritage
Design Review Weakness;
Heritage
Systems Engineering
Breakdown
19
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.
Space Systems Engineering: Design Fundamentals Module
Module Summary: Design Fundamentals
 The basic steps in the design process include:
1.
2.
3.
4.
5.
6.
7.
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.
Space Systems Engineering: Design Fundamentals Module
21
Backup Slides
for Design Fundamentals Module
Space 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
Space Systems Engineering: Design Fundamentals Module
23
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
Space Systems Engineering: Design Fundamentals Module
24
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
Space Systems Engineering: Design Fundamentals Module
25
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.
Space Systems Engineering: Design Fundamentals Module
26
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?
Space Systems Engineering: Design Fundamentals Module
27
Genesis – September 8, 2004
Space Systems Engineering: Design Fundamentals Module
28
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
Space Systems Engineering: Design Fundamentals Module
29
Morphological Matrix
Example Morphological Matrix for a High-speed Civil Transport
30
Space Systems Engineering: Design Fundamentals Module
30
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)
Space Systems Engineering: Design Fundamentals Module
31