with your host…

Dr. Hyland

426, Lecture 2 - Questions AddressedWhat are the life-cycle phases of a space mission and which phase and point of view will we consider?

What are some systematic approaches to space system design and analysis?

What approach will we take and what are the steps involved?

How will the class be organized to carry out these steps and what is the schedule of events?

Suggested reading:L&W, Chapter 1 (and Chaps. 2 and 3 for more detail)

The Space Mission Life Cycle - Four PhasesThe Space Mission Life Cycle - Four PhasesConcept exploration: The initial study phase that results in a broad definition of the mission and its

componentsDetailed development: The formal design phase

which results in a detailed definition of the system components and, in larger programs, development

of test hardware or software.Production and deployment: The construction of the ground and flight hardware and launch of the

first full constellation of satellites.Operations and support: The day-to-day operation of the space system, its maintenance and support, and finally its de-orbit or recovery at the end of the

mission life.

Various parties & constituencies:Sponsor: The group that provides and controls the program budget

Operators: The group (typically an applied engineering organization) that controls and maintains the space and ground assets

End users: Groups who receive and use the products and capability of the space mission

Developer: The procuring agent, e.g. DOD, NASA or a commercial enterprise

In this class, we concentrate on the Concept Exploration Phase from the point of view of the Contractor - Developer

Space Mission Analysis and Design Process- The Eightfold Path -

Typical Flow

Phase Step

Define Objectives

A. Define broad objectives and constraints.

B. Estimate quantitative needs and requirements.

Characterize the Mission

C. Define alternative mission concepts.

D. Identify system drivers for each.

E. Characterize mission concepts.

Evaluate the Mission

F. Identify driving requirements.

G. Evaluate mission utility

H. Define mission concept (baseline)

Step A: Define Broad Objectives and Constraints

• Define what the mission needs to achieve. What are our qualitative goals and why?

• The qualitative goals are summarized in the Mission Statement - a 3 to 4 sentence, crisp and cogent statement of overall goals.

• This is the all-important starting point. We need to repeatedly refer back to the Mission Statement to ensure we remain "on track".

• Usually, missions have several objectives. Besides the primary objectives, there may be secondary objectives that can be met by the defined set of equipment, or additional objectives that may demand more equipment.

•Almost always, missions have a hidden agenda - which consists of secondary non-technical, objective, frequently of a political, social or cultural nature.

Example:Our mission is to demonstrate, on-orbit, technology for detecting near Earth asteroids that are too small to discover by conventional means, yet are large enough to threaten significant damage. (Some hidden agendas: Boost space

activity, encourage public interest and support for space exploration, imply economic benefits, etc.)

Step B: Estimate Quantitative Mission Needs and Requirements

•In contrast to Step A, this quantifies how well we wish to achieve the broad objectives, given our needs, applicable

technology and cost constraints.

•These quantitative requirements should be subject to trade as we go along. In the early stages of design, it is very important not

to set these requirements "in concrete".

•To transform mission objectives into requirements, look at three broad areas:

o Functional requirements, which define how well the system must perform to meet its objectives.

o Operational requirements, which determine how the system operates and how users interact with it to achieve its broad objectives.

o Constraints, which limit cost, schedule and implementation techniques available to the system designer.

• Establishing top-level mission requirements is extremely difficult. Therefore, we should be prepared to iterate the numerical requirements many times in the design process.

• The first estimate of requirements should come from the goals and objectives combined with some view of what is feasible. Then be prepared to iterate.•Also, look at the "hidden agenda", which contains the implicit goals and constraints.

Quantitative requirements – Asteroid Discovery and Imaging via Stellar Occultation

Example:

Size/distance of NEAs that can be detected = ?

Minimum brightness of stars that can be used =?

Resolution of final Silhouette determination = ?

Accuracy of distance, size and velocity determination = ?

Step C: Define Alternative Mission ConceptsAs used here (as distinct from the usage in Larson and Wertz) a mission concept or architecture is a broad sketch of how the mission will work plus a definition of each of the principal components of a space mission:

Subject: The thing that interacts with or is sensed by the space payload.

Spacecraft or Space Segment: The self-contained portion that resides in space to carry out the mission long-term, comprising:

Payload: The hardware and software that sense or interact with the subject.

Spacecraft Bus: Subsystems that support the payload by providing orbit and attitude maintenance, power, command, telemetry and data handling, structure and rigidity and temperature control.

Launch System: Includes the launch facility, launch vehicle and any upper stage required to put the spacecraft in orbit as well as interfaces payload fairing and ground support.Orbit: The spacecraft's trajectory or path. Usually, there is an initial parking orbit, a transfer orbit and final mission orbit.Communications Architecture: The arrangement of components that satisfy the mission's command, control and communication (C3) requirements.Ground System: Fixed or mobile ground stations used to command and track the s/c, receive and process data and distribute the information to operators and users.Mission Operations and Timeline: The overall strategy and schedule for planning, building, deployment, operations, replacement and end-of-life.

Process for Identifying Alternative Mission ConceptsFive Steps:

1. Identify the mission elements subject to trade

2. Identify the main options for each tradeable element

3. Construct a trade tree of available options.

4. Prune the trade tree by eliminating unrealistic combinations.

5. Look for other alternatives that could substantially influence how we do the mission

Trade Tree – Basic Concept (illustrated by the manned asteroid mission )

Each line connecting one “node” at each level marks out a distinct design

Mission Phase Alternatives for each mission phase

Launch-to-orbit

Earth orbit to Asteroid vicinity

Proximity Operations

Launch single vehicle

Separate vehicle and

crew

Assemble mission on-

orbit

Chemical propulsion

Low thrust

Chemical propulsion

Low thrust

Landing mode

Combo

Chemical propulsion

Low thrust

Etc. …

Standoff mode

Tradeoffs – Choosing one branch of the tree (Earth orbit to Asteroid vicinity)

Pro

puls

ion s

yst

em

m

ass

Tri

p T

ime

Solar sail Electric propulsion

Chemical

The above diagrams showed fully branched trade trees – i.e., where each option at a given level branches to all the possible options at

the next level. In practice, only the distinct alternatives at each level are shown. Using this convention, previous diagrams look like:

Mission PhaseAlternatives for each mission phase

A line connecting one option at each level marks out a distinct design

Launch single vehicle

Separate vehicle and

crew

Assemble mission on-

orbitLaunch to orbit

Earth orbit to Apophis vicinity

Proximity operations

Chemical Propulsion

Low thrust

Standoff mode

Landing mode

Combo

Cautions

• Make sure that composing the trade tree and pruning it are separate steps!

• Do not prematurely throw out a design option – even if it seems far-out!

• Prune the tree only after you have assembled all possible options.

TRADES LIST

These suggested possibilities are not claimed to be comprehensive. They are offered to help start the thought process

Mission Component/Issue Design options

Launch methods Secondary payload on a launch vehicle Dedicated launch vehicle Transport to ISS and launch from there

Orbit lifetime 2 months 1 year >1 year

Type of telescope Refractor Neutonian Cassegrain “Light bucket”

TRADES LIST

These suggested possibilities are not claimed to be comprehensive. They are offered to help start the thought process

Mission Component/Issue Design options

Formation configuration Linear array Y shaped Circular, equally spaced Concentric circles

Propulsion system (for V maneuvers) Cold gas thrusters Electric propulsion No propulsion (attitude control

actuation only)

Formation sensing instrumentation Navigation cameras Laser range finders Star trackers GPS All of the above

TRADES LIST

These suggested possibilities are not claimed to be comprehensive. They are offered to help start the thought process

Mission Component/Issue Design options

Processing architecture All intensity processing on-orbit Shadow function estimation on-orbit, remaining computation on the ground Raw data down-linked, all processing ground-based

Spacecraft utilities Power source(s) Nuclear RTGs Solar-electric/batteries

Communications system Computation and data handling

Step D. Identify System Drivers for Each Mission Concept

1. In any real system, overall cost and performance or the design of detailed components are mainly influenced by a relatively small number of key

parameters or components (which the user or designer can control) - called drivers

2. In this step, we identify the cost and performance drivers for each alternative system concept.

3. For most missions, system drivers include the number of satellites, altitude, power, instrument size and weight

4. In identifying the drivers, we must clearly determine whether we are looking for drivers of performance, cost, schedule or risk.

5. The results of this step tell us where to put most of our effort when we do detailed performance estimation for each mission concept in the next step.

More on “Drivers”There are two qualitatively distinct Characterizations of a system design:

Quality or Performance: Measures of how well the system performs its mission. “How good it is going to be”.

Burden or Penalty: Usually summarized in the cost. Also: Schedule, risk. This is what we have to pay in order to get the performance offered by the design.

In addition, both of these types of measurements have uncertainty attached to them. The decision-maker needs to know: How good is it going to be; what’s the price, and how sure are you of both?

Distinct from Quality and Burden (or Performance and cost) are design parameters – e.g. size and power of communications antenna, size/weight of transponder unit, propulsion system thrust, etc. Performance and cost describe the utility of the design and are functions of the design parameters.

Design Drivers are those design parameters that most sensitively affect Performance or Cost (or other selected measures of quality and burden). One says: “This parameter is a cost driver” or “This is a performance driver”. Not: “Cost is a design driver”, etc.

Step E : Characterize Mission Concepts

1. This step defines in detail what the system is and does. We determine the power, weight and pointing budgets and decide what

to process on the ground or in space.

2. The objective here is to define the mission concepts in enough detail to allow meaningful evaluations of effectiveness and the

relative merits of the various concepts and architectures.

Process for characterization: There are a variety of processes used - see Larson and Wertz, Section 2.4 -- but we suggest you follow the outline provided by the TECHNICAL APPROACH STUDY PRODUCTS

LIST given in this lecture

TECHNICAL APPROACH STUDY PRODUCTS LIST

1. Mission System Description (including at least the following)

1.1 Launch components to LEO1.2 Overview of all system elements1.3 Mass lists and power requirements, including at

least current best estimate and identification of mass and power growth rationale for margin levels, power budgets should identify power utilization and margins during critical mission phases

1.4 Functionality1.5 Block diagrams for system and critical

subsystems (where appropriate)1.6 Computing needs and margins1.7 Degree of autonomy

1.8 Identification of all relevant margins, including mass margin above expected mass including growth contingency

1.9 Heritage assumptions1.10 Critical interface properties1.11 Robustness to off-nominal conditions1.12 Redundancy, treatment of single point failures

2. Required Infrastructure2.1 Tracking requirements2.2 Ground station requirements

3. Operations3.1 Operations concept3.2 Operations development3.3 Command & control team composition and

responsibilities

3.4 Operations margins (for example, up and downlink system buffers and required data download intervals)

3.5 Operations phase flow diagram showing data and command flow to and from system

4. Technology4.1 Assumed performance for advanced technology

elements and basis of assumptions4.2 Fallback options if technology performance is

not achieved and impact4.3 Required technology demonstrations

5. Cost and Schedule5.1 Overall mission schedule including

development, integration and test, and operations5.2 Overall development cost, and cost

profile per development phase and per NASA fiscal year

5.3 Assumptions regarding benefits from duplicating systems flown in technology demonstrations

5.4 Cost and schedule risk, cost uncertainty5.5 Basis of cost (nominal and uncertainty)

and cost estimating methodology (analogy, parametric, grass-roots are some examples)

5.6 Identify schedule and cost reserves5.7 Cost elements (estimates not required)

for technology development and demonstration and for mission operations

Step F: Identify Driving Requirements

Having defined and characterized the alternative mission concepts, we return in this step to our initial quantitative

requirements and identify the driving requirements.

These are the key requirements principally responsible for determining the cost and complexity of the system.

This step forces us to get a deep understanding of the relationships between the system design drivers and the driving

requirements. These are the all-important "pressure points" in the design.

We can use this understanding to see how to improve chances of success by:

Striking a compromise in the initial requirements.Finding potential technology advances in subsystems areas that relieve the system

drivers.Identify new approaches that circumvent the drivers.

The end result of this step is to revisit the requirements in the light of the drivers and revise as necessary.

Cautions

• Do not declare that the challenge of meeting a particular driver is impossible. (Unless you are good at prediction – but almost no one is! See the “Black Swan”.)

• Instead, if current technology seems unable to meet the challenge, state what advances are needed.

• It is easy to say something is impossible.

The Mission Analysis Hierarchy

Analysis Type Goal Depth

Feasibility Assessment

To establish whether an objective is achievable and its approximate degree of complexity

Quick, limited detail

Sizing Estimate To estimate basic parameters such as size, weight, power or cost

Point Design To demonstrate feasibility and establish a baseline for comparison of alternatives

Trade Study To establish the relative advantages of alternative approaches or options

More detailed, complex tradesPerformance

AssessmentTo quantify performance parameters for a given system

Utility Assessment To quantify how well the system can meet overall mission objectives

Step H: Define Mission Concept (Baseline)

Having evaluated alternative designs and done a preliminary assessment of mission utility for each, we select one or more system designs.

A baseline design is a consistent definition of the system that meets most or all of the mission objectives.

A consistent system definition is a single set of values for all of the system parameters that fit with each other

In designing a space system, many parameters are being defined and changed simultaneously. The baseline provides a temporary milestone

against which to measure progress.

It also allows us to limit the number of options that must be evaluated. Rather than looking at all possible combinations and variations of

parameters, it is much more feasible to look at the impact of varying several of the more important parameters relative to one or two baseline designs.

As the system design matures, the baseline becomes firmer and eventually becomes the system design.

Uncertainty and PredictionSee: N. N. Taleb, The Black Swan, Random House, 2010

Mediocristan ExtremistanMild randomness Wild or super-wild randomness

The most typical member is mediocre The most typical is either giant or dwarf

Winners get a small segment of the total pie

Example: Audience of an opera singer before the gramophone

Winner takes all, almost always

Example: Today’s audience for an artist

Impervious to the Black Swan Vulnerable to the Black Swan

Subject to physical constraints No physical constraints on what a number can be

Corresponds to physical quantities, i.e., height Corresponds to numbers, say, wealth

When you observe for a while you can get to know what’s going on

It takes a long time to know what’s going on

Easy to predict from what you see and extend to what you do not see

Hard to predict from past information

History crawls History makes jumps

History is dominated by Black Swan events. A Black Swan three attributes:1. It lies outside the realm of regular expectations, because nothing in the past can convincingly

point to its possibility. Almost no one predicts it.2. It carries an extreme impact3. Despite its outlier status, human nature makes us concoct explanations for it after the fact

• We tend to both tunnel and think “narrowly” (epistemic arrogance). We ignore “unknown unknowns”

• There is an ingrained tendency in humans to underestimate outliers – or Black Swans

• Our prediction record is highly overestimated – many people who think they can predict actually can’t

• Not only have forecasters generally failed dismally to foresee the drastic changes brought about by unpredictable discoveries, but incremental change has turned out to be generally slower than forecasters expected.

Uncertainty and PredictionSee: N. N. Taleb, The Black Swan, Random House, 2010

• Mediocristan model of the process of discovery: Someone sits in a cubical and concocts the discovery according to a timetable

• Classical model of real discovery: You search for what you know (say, a new way to reach India) and find something you didn’t know was there (America).

• Almost everything of consequence is the product of serendipity– Serendipity was coined in a letter by Hugh Walpole, who derived it

from a fairy tale, “The Three Princes of Serendip”. These princes “were always making discoveries by accident or sagacity, of things which they were not in quest of.”

• Example: In 1965 two radio astronomers at Bell Labs, New Jersey, discovered the cosmic background microwave radiation (which revived the big bang theory)

Uncertainty and PredictionSee: N. N.Taleb, The Black Swan, Random House, 2010

• Forecasting fallacies:– First Fallacy: Neglecting variability. Taking a projection too seriously,

without heeding its accuracy. • For planning purposes, the accuracy in your forecast matters far more than

the forecast itself.

• Don’t cross a river if it is four feet deep on average

– Second fallacy: Failing to take into account forecast degradation as the projected period lengthens

• We tend to underestimate the difference between the near and far futures

• Look at forecasts made in 1975 about the prospects for the new millennium

– Third fallacy: Misunderstanding the random character of the variables being forecast

• Owing to the Black Swan, these variables can accommodate far more optimistic – or far more pessimistic – scenarios than are currently expected

• Statistics of Mediocristan = Gaussian. Statistics of Extremistan = Mandelbrotian

Uncertainty and PredictionSee: N. N.Taleb, The Black Swan, Random House, 2010

• Some tips for dealing with uncertainty:– At the start, try to imagine all possible design options. Don’t

commit prematurely to one option (based on linear prediction).

– Build in redundancy (duplicative and functional redundancy)

– Tally up all “grey swans” (known unknowns), as well as Mediocristan uncertainties.

– For each set of design options, try to identify the worst cases (in Extremistan)

– Now identify the worst cases that produce the least damage. This mini-max, robust design, is your design. It is armed against uncertainty

– Be prepared for Black Swans (negative or positive)

Uncertainty and PredictionSee: N. N. Taleb, The Black Swan, Random House, 2010

Design Process and Class Teaming Arrangements

Phase Step Class org./Activity

Define Objectives A. Define broad objectives and constraints.

Up through midtermClass forms Contractor Teams (CT’s)

Midterm to Final ReviewPM and APM elected, Mission Scientist selected,Technical Groups formed

B. Estimate quantitative needs and requirements.

Characterize the Mission

C. Define alternative mission concepts. Up to midterm, each CT

defines one mission concept and carries out steps C through G.

PTAR – Mission Concept Downselect(choice of baseline concept)

D. Identify system drivers for each.

E. Characterize mission concepts.

Refined execution of steps E, F, G. and H

Baseline (point) DesignRoadmap of Technology development

Evaluate the Mission F. Identify driving requirements.

G. Evaluate mission utility

H. Define mission concept (baseline)

We are ready to gear up!

THE END