space systems engineering: design fundamentals module design fundamentals module space systems...

Space Systems Engineering: Design Fundamentals Module

Design FundamentalsModule

Space Systems Engineering, version 1.0

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.


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?


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.


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.


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


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.

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.


Design Solution Drivers

Developing Organization’s Management Stakeholder

Political Stakeholder

End-User Stakeholder

Public Stakeholder

Headquarters Stakeholder

DevelopmentStaff

Satisfy everyone?Satisfy everyone?

Conform to standards, reusability,

keep people employed!

Conform to standards, reusability,

keep people employed!

Neat technology, fun, career enhancing!

Neat technology, fun, career enhancing!

Neat features,

short time to market, low cost, what’s in it for my

constituents!

Neat features,

short time to market, low cost, what’s in it for my

constituents!

Behavior, performance,

science, reliability!

Behavior, performance,

science, reliability!

Neat features,

pictures, TV, new

technology

Neat features,

pictures, TV, new

technology

Low cost, low risk, timely

delivery, keep politicians

happy

Low cost, low risk, timely

delivery, keep politicians

happy

Architect


Concept and Design Development Methods

Ref.: Rechtin and Maier, The Art of Systems ArchitectingRef.: 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


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.


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?”)


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.


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)


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


The Stardust - Genesis Mission Heritage Story


Stardust – Utah Landing, 1/16/06


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.


Acceleration Vector Required for G-Switch toFunction

Actual AerodynamicBraking Force Direction

Mounting Base of AU

Heatsh

ield

SwitchesSwitcheswere were

Reversed!Reversed!

SwitchesSwitcheswere were

Reversed!Reversed!

G-Switch Orientation


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


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.


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.


Backup Slidesfor 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


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


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


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.


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.


Genesis – September 8, 2004


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


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 design fundamentals module space systems...

Documents