Thesis Defense Alvar Saenz-Otero May 4, 2005

Space Systems Laboratory Massachusetts Institute of Technology

SPHERES

Design Principles for the Development of Space Technology Maturation Laboratories Aboard the International Space Station

Thesis Defense

Alvar Saenz-Otero

May 4, 2005


SPHERES Committee Members

• Prof. David W. Miller Chair– MIT Space Systems Laboratory

• Prof. Jonathan P. How Member– MIT Space Systems Laboratory

• Prof. Eric Feron Member– MIT Laboratory for Information & Decision Systems

• Javier de Luis, PhD Member– Payload Systems Inc.

• Prof. Brian Williams Member/Minor Advisor– MIT Space Systems Laboratory / Minor Advisor

• Prof. Jeffrey A. Hoffman Reader– MIT Man Vehicle Laboratory

• Prof. Dava Newman Reader– MIT Man Vehicle Laboratory/Technology Policy Program


SPHERES Motivation

• Extract the design methodologies behind two decades of research at the MIT SSL in the design of facilities for dynamics and control experiments– What are the common design elements?

– Which elements eased the technology maturation process?

– Can these apply to future experiments?

– Is there a facility for microgravity research equivalent to wind-tunnels for aeronautics research?

• National Research Council calls for the institutional management of science aboard the ISS in 1999– Promote the infusion of new technology for ISS research

– Provide scientific and technical support to enhance research activities

– Selected science use on the basis of their scientific and technical merit by peer review

Problem Statement


SPHERES Approach / Outline

Create a design methodology for the development of micro-gravity laboratories for the research and maturation of space technologies

– Review of g and remote research facilities

The conjunction of– The International Space Station– The MIT SSL Laboratory Design Philosophy

present a perfect low-cost environment for the development and operation of facilities for space technology research

Build and operate SPHERES using the MIT SSL Laboratory Design Philosophy for operations aboard the ISS

– Description– Iterative Research– Support Multiple Scientists

Design Principles that guide the design of a research facility for space technology maturation utilizing the ISS

The application of the principles to review SPHERES indicates the Design Principles and frameworks present a valid methodology for the development of research facilities for maturating space technologies aboard the ISS

Problem Statement

Chapter

Conclusions

&

Contributions

Results

Experimentation

Hypothesis

ObjectiveMotivation

& Other Facilities

ISS & Facility Characteristic

SPHERES

Design Principles & Frameworks

Evaluations

Conclusions/

Contributions

1

2

3

4

5

6

7

SSL Design Philosophy


SPHERES Outline

Chapter

Conclusions

Results

Experimentation

Hypothesis

ObjectiveMotivation

& Other Facilities


SPHERES


Evaluations

Conclusions

1

2

3

4

5

6

7


• Motivation / Approach -g and Remote Research Facilities• The International Space Station• MIT SSL Laboratory Design Philosophy

• SPHERES: from testbed to laboratory– Description

– Iterative Research Process

– Supporting Multiple Scientists

• Design Principles

• Application of Principles• Contributions


SPHERES

• Space based– Shuttle Middeck

– Shuttle Payload

– ISS

– Free Flyer

3(5) ~ h w $$

6 s w ~ $$$

6 h w ~ $$$

6 ~ s w ~ $$$

-g Research Facilities

• In-house– Simulation

– Air table

– Robot Cars

– Helium Balloons

– 6 DOF Robot Arms

– Robot Helicopters

Literature Research

• 3rd Party Ground based– Flat Floor

– Drop Towers

– Neutral Buoyancy Tank

– RGA (KC-135)

gDur.

MisDur.DOF Dyn. Exp. Ops. Data Acc. Cost

6 s-y mo-y $

3(5) ~ m-h mo-y $

3(5) h mo-y $

4(6) h mo-y $$

6 h mo-y $$$

4(6) h mo-y ~ $$

6 ~ h-w w ~ $$$$

6 h-w w ~ $$$$

6 h-y mo-y ~ $$$$

6 mo-y mo-y $$$$$

ISS

- N

AS

AJS

FC

RG

O K

C-1

35 -

NA

SA

MIT SSL/ACL

Environment Operations


SPHERES Remote Research Facilities

• Antarctic Research– Scientific research is primary directive

[NRC], [Elzinga, ‘93], [Burton, ‘04]

– International system [SCAR]

– Development of shared facilities in a harsh environment [Ashley, ’04]

• Ocean Exploration Research– Multiple types of research vessels

[Penzias, ’73]

– Concentrate on conducting an experiment, not data analysis [Cunningham, ’70]

– Similarities with space challenges

Literature Research

• Past Space Stations Crew

Duration

– Salyut 2-6~1y (2x)

• International cooperation, EVA’s

– Skylab [Belew, ’77] 3<1y

• Science driven: solar exp., physiology

– Space Lab [Emond, ’00] 7~2w

• International coop. aboard shuttle

– Mir [NASA], [Burrough, ‘98] 3~15y

• Tech. research, Earth & space sciences, biology, life support, shuttle docking, ISS Phase I

Space stations do provide a unique environment for microgravity researchAllow the researcher to be in-location with

facilities to conduct specific experiments

WH

OI

BA

S Skylab - [Belew] MIR - NASA

How do you design and build experiments to operate remotely under a microgravity environment?


SPHERES Outline

Chapter

Conclusions

Results

Experimentation

Hypothesis

ObjectiveMotivation

& Other Facilities


SPHERES


Evaluations

Conclusions

1

2

3

4

5

6

7









SPHERES The International Space Station

• Experiment Operation Types– Observation– Exposure– Iterative Experiments

Hypothesis

The purpose of the ISS is to provide an “Earth orbiting facility that houses experiment payloads, distributes resource utilities, and supports permanent human habitation for conducting research and science experiments in a microgravity environment.” [ISSA IDR no. 1, Reference Guide, March 29, 1995]

• Major areas of study– Educational– Pure Science– Technology

• Special Resources of the ISS– Crew

• Provide oversight of experiments, reducing the risk of using new technologies

– Communications• Reduce the costs and improve the availability of data for researchers on the ground

– Long-term experimentation• Enables taking many individual steps to slowly mature a technology

– Power• Reduces the launch requirements (mass and cost) for missions to provide basic utilities

– Atmosphere / Benign environment• Reduces cost and complexity of developing test facilities (e.g., thermal, radiation protection)


SPHERES MIT SSL LaboratoryDesign Philosophy (1)

• Lessons learned from past experiments– MODE - Middeck 0-g Dynamics Experiment

• STS-48 (‘91): fluid slush and jointed truss structures• STS-62 (‘94): truss structures, pre-DLS

– DLS - Dynamics Load Sensor• MIR: crew motion sensors

– MACE - Middeck Active Controls Experiment• STS-67 (‘95): robust, MCS algorithms for space

structures• ISS Expedition 1 (‘00): neural networks, non-linear &

adaptive control

Hypothesis

MO

DE

DLS

MA

CE



• Lessons learned from past experiments– MODE - Middeck 0-g Dynamics Experiment

• Modular, generic equipment,hardware reconfiguration

– DLS - Dynamics Load Sensor• Extended investigations

– MACE - Middeck Active Controls Experiment• Multiple investigators, human observability,

iterative research, risk tolerant environment, SW reconfiguration

Hypothesis

MO

DE

DLS

MA

CE

Spe

cifi

c ve

rsus

ge

neri

c

Har

dwar

e re

conf

igur

atio

n

Ext

ende

d in

vest

igat

ions

Ris

k to

lera

nt

envi

ronm

ent

Sof

twar

e re

conf

igur

atio

n

Hum

an

obse

rve/

man

ip

Iter

ativ

e re

sear

ch

proc

ess

Mul

tipl

e in

vest

igat

ors

MODE MODE-Reflight DLS MACE MACE-Reflight



• The identification of these features led to the development of MIT SSL Laboratory Design Philosophy

– Based on the need to demonstrate control and dynamics algorithms, these features guide the design of a laboratory such that the results provided in the laboratory validate the algorithms themselves, and not the capabilities of the facility

Hypothesis

Group FeatureFacilitating Iterative Research Process Facilitating Iterative Research ProcessExperiment Support Data Feedback Precision

Repeatability and ReliabilityHuman Observability and ManipulationSupporting Extended InvestigationsRisk Tolerant Environment

Supporting Multiple Investigators Supporting Multiple InvestigatorsReconfiguration and modularity Generic versus Specific Equipment

Physical End-to-End SimulationHardware ReconfigurationSoftware Reconfiguration


SPHERES Outline

Chapter

Conclusions

Results

Experimentation

Hypothesis

ObjectiveMotivation

& Other Facilities


SPHERES


Evaluations

Conclusions

1

2

3

4

5

6

7









SPHERES SPHERES Design

• SPHERES is...– A testbed for formation flight

• Allow reconfigurable control algorithms• Perform array capture, maintenance and retargeting

maneuvers• Enable testing of autonomy tasks• Ensure traceability to flight systems• Design for operation in the KC-135, shuttle mid-deck, and ISS

– Design guided by the SSL Laboratory Design Philosophy

• Sub-systems designed to accommodate specific features

Lab FFAvionics Software Communications Interface/Operations Propulsion Structures

Experimentation


SPHERES SPHERES Overview

• SPHERES is...– A testbed for formation flight

• SPHERES free-flier units– Up to 5 independent units with propulsion, power,

communications, metrology, and data processing– Sensors and actuators provide full state vector (6DOF)

• Laptop unit– Standard PC laptop serves as a base station

• Metrology– Five external metrology transmitters create frame of reference

• Communications– Satellite-to-satellite (STS)– Satellite-to-laptop (STL)

Upload program

Download data Thrusters

UltrasoundSensors

PressureRegulator

Battery

PressureGauge

Control Panel

Experimentation


SPHERES

• Support Multiple Scientists– Guest Scientist Program

• Information Exchange• SPHERES Core Software• GSP Simulation• Standard Science Libraries

– Expansion port

– Portability

– Schedule flexibility

• Reconfiguration and Modularity– Generic satellite bus

– Science specific equipment: on-board beacon and docking face

– Generic Operating System

– Physical Simulation of Space Environment• Operation with three units• Operation in 6DOF• Two communications channels

– Software interface to sensors and actuators

– Hardware expansion capabilities

– FLASH memory and bootloader

• Facilitate Iterative Research– Multi-layered operations plan

– Continuous visual feedback

– Families of tests

– Easy repetition of tests

– Direct link to ISS data transfer system

– De-coupling of SW from NASA safety

• Support of Experiments– Data Collection and Validation Features

• Layered metrology system• Flexible communications: real-time & post-

test download• Full data storage• 32 bit floating point DSP• No precision truth measure

– Redundant communications channels

– Test management & synchronization

– Location specific GUI’s

– Re-supply of consumables

– Operations with three satellites

– Software cannot cause a critical failure

SPHERES Features to Meet theMIT SSL Laboratory Design Philosophy

Experimentation


SPHERES

"Research is the methodical procedure for satisfying human curiosity. It is more than merely reading the results of others' work; it is more than just observing one's surroundings. The element of research that imparts its descriptive power is the analysis and recombination, the "taking apart" and "putting together in a new way," of the information gained from one's observations." [Beach]

Four major steps which support the iterative process:1) Test execution (science time: allow enough time)2) Data collection and delivery to researcher (overhead time: minimize)3) Data evaluation and algorithm modification (science time: allow enough time)4) Modification to tests and new program upload (overhead time: minimize)

[Gauch]

HypothesisHi

Design Experiment True State of Nature

New DataPrevious Data

Deduction Model of Hi

Induction New Hypothesis

Hi+1

Noise

+

Problem Statement

Initial Modeling

Hardware Test

Data evaluation

Technology Maturation

Implementation & Test Setup

4

2

Initial Implementation

TheoreticalModel

Data Collection

3

The initial modeling and implementation is not part of the

iterative research process

1Initial Setup

Science Time

Overhead Time

AlgorithmModifications

SPHERES: Iterative Research Process

• Scientific Method Steps– Design

– Deduction

– Experimentation

– Induction

– New Hypothesis

New

Hyp

oth

esis

Ded

uct

ion

Induction

ExperimentDesign

Experimentation


SPHERES SPHERES: IterationsSteps 1, 2, 4

Hardware Test

Data evaluation



4

TheoreticalModel

Data Collection

3

1

AlgorithmModification

2

Experimentation

• Continuous visual feedback • Families of tests• Easy repetition of tests• Location specific GUI’s• Re-supply of consumables• FLASH memory and bootloader

Optionalreal-timedata display

Debugreal-timedata One-key commands

Satellite status summary

Program and testnumbers, timing

Initialization

Data recording status

Communications status

Single key test start/stop


SPHERES SPHERES: IterationsStep 3

Hardware Test

Data evaluation



4

TheoreticalModel

Data Collection

3

1


2

• Guest Scientist Program– Standard Science Libraries

• Multi-layered, multi-environment operations plan

Experimentation

Analyze dataSPHERES provides Matlab functions

Collect data files

Update algorithms with CCSC or C++

Compile new program image



Data evaluation


TheoreticalModel

3AlgorithmModification


• Multi-layered, multi-environment operations plan– Simulation: science time determined by researcher

Experimentation

All these tests are performed at the researcher home facility using their own computers.

Initial Algorithm DevelopmentResearcher

Simulation TestResearcher

Data AnalysisResearcher

Deployment to Hardware Tests

Implementation & SetupHours

1Data Collection

Minutes

2 3

4debug

Hardware Test


4

Data Collection

1

2



Data evaluation


TheoreticalModel



• Multi-layered, multi-environment operations plan– Simulation: science time determined by researcher– SSL Off-site Tests: science time determined by researcher and SSL availability

(days/weeks/months)

Experimentation

Performed at the MIT SSL facilitiesPerformed at the researcher’s home facility.


Algorithm TranslationDays

Hardware Test20 minutes

Data CollectionHours

Maturation

Algorithm Modification

Hours

24

Data AnalysisResearcher

Integration to flight code

4 1

debug

Verification Deployment to ISS 4


1

Data CollectionMinutes

2 3

Hardware Test


4

Data Collection

1

2



Data evaluation


TheoreticalModel


Experimentation

Performed at the MIT SSL facilitiesPerformed at the researcher’s home facility


Algorithm TranslationDays



Maturation/ deployment to

ISS

Algorithm Modification

Minutes

1 2

4Data AnalysisTravel Time

3debug


• Multi-layered, multi-environment operations plan– Simulation: science time determined by researcher– SSL Off-site: science time determined by researcher and SSL

availability (days/weeks/months)– SSL On-site: science time determined by availability / residence at

SSL facilities (days/weeks/months)

Hardware Test


4

Data Collection

1

2



Data evaluation


TheoreticalModel


Experimentation

Researcher’s home facility / MIT SSL

Maximum 4 days total operations

Researcher Remote Location (e.g. hotel)KC-135Researcher’s home facility / MIT SSL


Hardware Test20 seconds

Data CollectionHours Maturation or

deployment to ISS

Algorithm ModificationMinutes

1 2

4

Data Analysis24-72 Hours

3

Visual Analysis60 seconds

3



availability (days/weeks/months)– SSL On-site: science time determined by availability / residence at SSL

facilities (days/weeks/months)– KC-135 RGA: science time determined by parabola time (~60s),

and length of stay at remote location (1-3 days)

Hardware Test


4

Data Collection

1

2



Data evaluation


TheoreticalModel


Experimentation

Limited to length of travel to MSFC

Researcher Remote Location(e.g. hotel)

MSFC Flat Floor

Researcher’s home facility / MIT SSL



Data CollectionHoursMaturation or

deployment to ISS

Algorithm ModificationMinutes

1

24Data Analysis

Days

3

Visual Analysisminutes

3


2Data Analysis

Few Hours

3Algorithm Modification

Minutes

4



availability (days/weeks/months)– SSL On-site: science time determined by availability / residence at SSL

facilities (days/weeks/months)– KC-135 RGA: science time determined by parabola time (~60s), and

length of stay at remote location (1-3 days)– MSFC: science time determined by test operations (minutes), work

day (hours) and length of stay at remote location (days)

Hardware Test


4

Data Collection

1

2


SPHERES

ISSISS Laptop

Minutes

4

Program LoadMinutes

4

Maximum total time:2 Hours

6DOF Test30 minutes

1Astronaut feedback

MinutesData in Laptop

1

2

Preview analysisMinutes

1

VideoISS ServerMinutes

2

PSI STP JSC

Total overhead:~2 days

To JSC 1 Day

4

ISS Server1 Day

4

Performed at the researcher’s home facility.


Maturation

Algorithm ModificationGND: Hours

ISS: 2 weeks cycle

4

Data Analysis2 week cycle

3Data Collection

Minutes

2

Total overhead:Hours or2 weeks cycle


1

SPHERES: IterationsISS Steps

MIT SSL


Data CollectionHours

2

Integration to flight codeDays

4 1

debug

Verification Days

4Total overhead:Days

JSC STP PSI

Data Download2-3 days

Video Delivery~1 week

2

Experimentation


SPHERES SPHERES: IterationsISS Steps 1, 2, 4

• Direct link to ISS data transfer system

• De-coupling of SW from NASA safety

• Physical Simulation of Space Environment– Operation with three units– Operation in 6DOF– Two communications channels

ISSISS Laptop

Minutes

4

Program LoadMinutes

4

Maximum total time:2 Hours

6DOF Test30 minutes

1Astronaut feedback

MinutesData in Laptop

1

2

Preview analysisMinutes

1

VideoISS ServerMinutes

2

Crew

ISS Laptop

SPHERES (3)

Beacons (5)

Courtesy Boeing CoStart ISS GUI

Experimentation

Hardware Test

Data evaluation



4

TheoreticalModel

Data Collection

3

1


s

2


SPHERES SPHERES: More Iterative Research Features

• Software (Appendix C)– Generic Operating System– Software cannot cause a critical failure– Test management & synchronization

Test Time 2 [ms]

n/a n/a n/a n/a -1000 -800 -600 -400 -200 0 200

UserInput

LaptopControl

Sat 1

Sat 2

15ms

Bad

RX

sync

7865 8065 8265 8465 8665 8865 9065 9265 9465 9665 9865Sat 2 Time

Sat 1 Time

Laptop Time[s]

sync

Test Time 1 [ms]

star

t

Data TXData RX“Start Test” PacketTX Window

n/a -1000 -800 -600 -1000 -800 -600 -400 -200 0 200

4321 4521 4721 4921 5121 5321 5521 5721 5921 6121 6321

572.1 572.3 572.5 572.7 572.9 573.1 573.3 573.5 573.7 573.9 574.1

HW DSP/BIOS SPHERES Core GSP

Comm

IMU

Global Met.

SW Interrupts

StandardScienceLibraries

Tasks

HW Interrupts

Controller

Propulsion

Housekeeping

Comm

IMU

Global Met

Propulsion

GSP BackgroundTask

Control

Met. (IMU)

BackgroundTask

TestInit

Controllers

Estimators

Maneuvers

Mixers

Met. (Global)

GSP MetrologyTask

MetrologyTask

SPHERESMet. Task

Hidden Interfaces User-accessible Interface

Terminators

Math

Utilities


SPHERES SPHERES: More Iterative Research Features

• Avionics (Appendix B)– Layered metrology system– 32 bit floating point DSP

• Communications (Appendix D)– Flexible communications: real-time &

post-test download – Full data storage

DSP Memory BusesSerial LinesDigital I/O signalsAnalog signals

Micro Processor(C6701 DSP)

Metrology AvionicsFPGA

CommunicationsAvionics

(PIC MCU’s)

A2D

US/IR12x

STLRF

STSRF

Watchdog

ControlPanel

Power Propulsion

Solenoids

Amplifiers

Accelerometers

Gyroscopes

ExpansionPort

BatteryPacks

Beacon

HW

I COMM Rx

CLK (BIOS)

CL

K

Comm TDMA Mgr

SW

I

COMM Tx

PRD (BIOS)

Fast Housekeeping

TelemetryT

SK

COMM Mgr

DataComm STL DataComm STS

CP Monitor

Pri

ori

ty

receive data, put into RX pipes

enable transmission SWI

send packets to DR2000 when enabled

manage state of health packets

manage background telemetry packets

prepare TX packets; process RX packets

process large data transmissions

initialize commports


SPHERES SPHERES: Supporting Multiple Scientists

• Families of tests Software, Operations

• Guest Scientist Program– Information Exchange Operations– SPHERES Core Software Software– GSP Simulation Operations

• Expansion port Avionics, Software

• Portability System

• Schedule flexibility Operations

Research Year Application Guest ScientistFF Communications 2000-03 DSS GoddardFF Control 2000+ TPF JPLDocking Control 2002+ Orbital Express (DARPA)Mass ID / FDIR 2003+ Modeling AmesTethers 2003+ SPECS GoddardMOSR 2004+ Mars Sample Return

Current Programs

dx

xf

yf

xl

yl

Follower

Leader

f

dy

l 0dx

xf

yf

xl

yl

Follower

Leader

f

dy

l 0

Mass IDARD

Future Programs

Tethers MOSRMulti-stage TPFTPF

Experimentation

NA

SA


SPHERES

Group Av

ion

ics

Co

mm

.

Op

era

tio

ns

So

ftw

are

Facilitating IterativeResearch Process

Experiment Support

Supporting MultipleInvestigators

Reconfiguration andmodularity

SPHERES: A Laboratory

• SPHERES is...– A testbed for satellite formation flight

– The SPHERES implementation satisfies all four groups of the philosophy

• Laboratory: a place providing opportunity for experimentation, observation, or practice in a field of study

– Therefore, by following the SSL Laboratory Design Philosophy, SPHERES is…

• A separated spacecraft laboratory!– It is a reconfigurable and modular laboratory which supports conducting

-g iterative experiments by multiple investigators

LABORATORYLABORATORY

Experimentation

Terrestrial Planet FinderMOSR SPECS Orbital Express

NA

SA

NA

SA

DA

RP

A

NASA


SPHERES Outline

Chapter

Conclusions

Results

Experimentation

Hypothesis

ObjectiveMotivation

& Other Facilities


SPHERES


Evaluations

Conclusions

1

2

3

4

5

6

7









SPHERES

Results

Design Principles for -gLaboratories Aboard the ISS

• These principles were derived from the implementation of the MIT SSL Laboratory Design Philosophy in SPHERES for operations specifically aboard the ISS– The principles encompass all features of the philosophy following the four

main groups presented above

– The principles incorporate the special resources of the ISS

• The following seven principles capture the underlying and long enduring fundamentals that are always (or almost always) valid [Crawley] for space technology maturation laboratories:– Principle of Iterative Research

– Principle of Enabling a Field of Study

– Principle of Optimized Utilization

– Principle of Focused Modularity

– Principle of Remote Operation & Usability

– Principle of Incremental Technology Maturation

– Principle of Requirements Balance


SPHERES

Studies the “depth” of the research

Results

Concept

Hypothesis

TechnologyMaturation

Conception

Science Time

Overhead Time

ExperimentImplement

ExperimentOperation

Data Collection

DataAnalysis

ExperimentDesign

Facility Design

Principle of Iterative Research

• A laboratory allows investigators to conduct multiple cycles of the iterative research process in a timely fashion

• Three iteration loops:3

– Modify the hypothesis about the goals and performance requirements for the technology.

New Hypothesis

Ded

uct

ion

Induction

– Modify the experiment design to allow for comparison of different designs.

2

Des

ign

1

Exp

erim

ent

– Repeat the test to obtain further data.


SPHERES Principle of Iterative Research

• Composed of three elements:– Data collection and analysis tools

• Collection bandwidth, precision, accuracy• Transfer rate, availability

– Enable reconfiguration• To allow the three feedback loops to be closed

– Flexible operations plan• Flexible time between

iterations– Too little time prevents

substantial data analysis

– Too much time createsproblems with resourcesand institutional memory

• Maximize number ofiterations possible

Results

good

bad

good bad

MACE

MACE-II

DLS

EffectiveIterativeResearch

IneffectiveIterativeResearch

ShuttleISS

MIR

RG

A

Time between iterations i

Num

ber

of

itera

tions

MODE-Reflight

0n>

>1

small large


SPHERES

Results

Principle of Enabling a Field of Study

• A laboratory provides the facilities to study a substantial number of the research areas which comprise a field of study– Every facility must be part of a clearly defined field of study

• The objective of a facility must clearly indicate what field of study it will cover

– The study of multiple topics requires multiple experiments to be performed• Individual scientists perform research on one or a few areas• The work on individual topics collectively covers the field of study• Therefore multiple investigators, who perform experiments in their specific area of

expertise within the field, must be supported

– The laboratory must facilitate bringing together the knowledge from the specific areas to mature understanding of the field of study

• Enable collaborative research

Covers the “breath” of the research, how much of a field of study can be covered by the facility


SPHERES Principle of Enabling a Field of Study

• The methods to evaluate the efficiency of a laboratory can be compared to the methods used to determine the efficiency of product platforms– Product platform evaluations compare the cost of developing a new product

with respect to the original product [Meyer]

– Laboratories compare the cost of testing specific areas (ki) in its facilities (with initial cost Klab) compared to creating original facilities for each area (Ki)

– Laboratories promote covering multiple areas (m/n)

n

ii

n

iilab

K

kK

n

mJ

1

1

Results% of field of study covered

Increased costper area of study

0% 25% 50% 75% 100%Fra

ctio

nal c

ost

of

Labo

rato

ry

1

Expensive area


SPHERES Principle of Remote Operation & Usability

• A remotely operated laboratory, such as one which operates aboard the ISS, must consider the fact that remote operators perform the everyday experiments while research scientists, who do not have direct access to the hardware, are examining data and creating hypotheses and experiments for use with the facility

• Remote facilities are remote because they offer a limited resource that the researcher cannot obtain in their location

• Therefore the operations and interface of a remote facility must– Enable effective communications between operator and research scientist

– Enable prediction of results

– Ultimately: create a virtual presence of the scientist through the operator

• Research Scientists– have little or no experience on the

operational environment

– are unable to modify the experiment in real-time

– are usually an expert in the field but not in implementation

– may not have direct contact with the facility

• Operators– are usually not an expert in the specific field

– are an inherent part of the ‘feedback’ loop to provide researchers with results and information

– are a limited resource

Results


SPHERES

FunctionalRequirements

EngineeringRequirements

ManagementRequirements

ScienceRequirements

MissionObjective

Enabling a Field of Study

Iterative Research

Optimized Utilization

Focused Modularity Req’s Balance

Remote Operation


FacilityDesign

Results

Design Framework

• How to use the principles in a laboratory design– Step 1 - Identify a Field of Study

• Select a large enough area in the field of study that the experiment can support technology maturation, but not so large that it is impossible to identify a clear set of science requirements

– Step 2 - Identify Main Functional Requirements• Identify data, reliability, and schedule requirements to enhance the iterative research process• Define representative environment and utilization of the ISS

– Step 3 - Refine Design• Identify opportunities for modularity to help both the project and the ISS program• Determine requirements for remote operations

– Step 4 - Review Requirements and Design• Balance requirements

1 2 3 4


SPHERES Outline

Chapter

Conclusions

Results

Experimentation

Hypothesis

ObjectiveMotivation

& Other Facilities


SPHERES


Evaluations

Conclusions

1

2

3

4

5

6

7









SPHERES Principles Applied to SPHERES

• Success– Enables iterative research (demonstrated)

• Fulfills the three parts of the Principle of Iterative Research: successful data management, flexible operations plan, and enable multiple levels of repetitions and iterations

– Supports multiple scientists (demonstrated)• The GSP has enabled at least six groups to participate in SPHERES

– Utilizes most ISS resources correctly (designed, expected)• Designed to utilize the crew, telemetry, long-term experimentation, and benign environment features

– Balances generic and specific equipment (demonstrated)• The satellite bus implemented by the SPHERES units provides generic equipment• The expansion port allows integration of science specific equipment

– Creates a remote laboratory environment (demonstrated in ground, expected in ISS)• The portability and custom interfaces create a remote laboratory outside of the main SSL facilities

– Allows incremental technology maturation up to TRL 6 (expected)• Creates the necessary representative environment to satisfy the definition of TRL 5 and TRL 6

• Recommendations– Design/Eval: Improve use of ISS power sources

• While power consumption is minimal (~50W), none comes from the ISS resource

– Design: Imbalance in resources allocated to metrology sub-system development vs. power/expansion

• Allocation of resources (esp. man power) to metrology prevented improved design of power/expansion

– Eval: Minimal modularity from ISS perspective• While modular from DSS perspective, provides no generic equipment for ISS use

Conclusions


SPHERES Contributions: Principles

• Identified the fundamental characteristics of a laboratory for space technology maturation

– Formalized the need for a laboratory to support iterative research• Based on the definition of the scientific method

• Called for reduced dependency on DOE

– Identified the need to enable research on a field of study• Requires support of multiple scientists in most cases

– Advocate the use of the ISS as a wind-tunnel-like environment for g research

• Established a set of principles to guide the design of research laboratories for space technology maturation aboard the International Space Station

– Enables the use of the ISS to incrementally mature space technologies– Developed a design framework– Developed an evaluation framework to respond in part to the NRC institutionalization of

science aboard the ISS• Calls for a change in attitude towards the use of resources aboard the ISS: don’t treat as costs

to minimize; treat as added value, so maximize their correct use

Conclusions


SPHERES Contributions: SPHERES

• Designed, implemented, and operated the SPHERES Laboratory for Distributed Satellite Systems

– Multiple researchers can advance metrology, control, and autonomy algorithms• Up to TRL 5 or TRL 6 maturation

– Demonstrates the implementation of miniature embedded systems to support research by multiple scientists

• Developed a real-time operating system with modular and simple interfaces

– Demonstrates the ability to create generic equipment– Enables future expansion through both hardware and software– Approaches virtual presence of the scientists in a remote location

• Present the operator with the necessary initial knowledge and feedback tools to be an integral part of the research process

Conclusions


SPHERES

Questions?


SPHERES Principle of Optimized Utilization

• A well-designed laboratory considers all the resources available and optimizes their use with respect to the research needs

• Understand the resources and limitations of the ISS– Crew

– Power sources

– Data telemetry

– Long-term experimentation

– Benign Environment / Atmosphere

• Determine the needs of the research– Allow flexibility in the needs of the laboratory; maximize the ability to use available

resources

• Realize which resources do not provide a benefit to the research

• Iterate this process to ensure all available resources are utilized as best as possible

Results


SPHERES Principle of Optimized Utilization

• Using the resources of the ISS provides a value to the laboratory– Based on the Taguchi values

– Using a resource should not be a “cost” to minimize

• Utilize crew ~12hper month

• Minimize power req.

• Maximize % of powerfrom ISS

• 100kbps-400kbpsbandwidth is best

• Lifetime ~1-5y


SPHERES Principle of Focused Modularity

• A modular facility identifies those aspects of specific experiments that are generic in nature and allows the use of these generic components to facilitate as yet unforeseen experiments. Such a facility is not designed to support an unlimited range of research, but is designed to meet the needs of a specific research area.

• During development of a facility identify the generic components but ensure that the initial research goals are met

– The original immediate research should not be compromised– The experiment generic components can become part of a larger array of generic

elements that brought together create a laboratory environment

• Do not try to design a “do-everything” system– The generic equipment should be identified after the design of the original

experiment; the original design should not be to create generic equipment

Results


SPHERES Principle of Focused Modularity

• Metric / Evaluation– Evaluate each major component (sub-system) of the testbed using the

following truth table:

– Determine the cost difference between making a sub-system modular or not

Inte

r-di

scip

line

Rec

onfi

gure

Obs

olet

e

Lif

e-li

mit

ed

Cos

t A

mor

tize

Ori

gina

l G

oals

Make Modular x x x x x 0 0 x x 0 x x x 0 x x x 0 x x 0 0 0 1 1 0 1 0 1 x 1 1 x 1 1 x 1 1 1 x 1 1 x x 1 1 1 1 1

Results


SPHERES Principle of Incremental Technology Maturation

• A successful ISS laboratory for technology maturation allows technology maturation to transition smoothly between 1-g development and the microgravity operational environment in terms of cost, complexity, and risk.

• Technology maturation is essential to advancement of space technologies

• Need to provide “smooth” path– Current “Technology Readiness Levels” (TRL) results on

steep increases from ground tests (TRL 1-4) to space environment demonstrations (TRL 5-7) and flight operations (TRL 8-9)

– Jump in complexity between TRL’s creates high-risk environments; cost of potential loss is very high

– Use human presence in space to reduce risk

TRL 1-2: Basic principles & conceptTRL 3-4: Proof-of-concept & laboratory breadboardTRL 5: Component validation in relevant environmentTRL 6: System prototype demonstration in relevant environmentTRL 7: System prototype demonstration in space environment

(usually skipped due to cost)TRL 8: Flight system demonstration in relevant environmentTLR 9: Mission Operations

TRL

1 2 3 4 5 6 7 8 9

ComplexityRiskCost

Now with ISS

ISS Projects

Results


SPHERES Principle of Incremental Technology Maturation

• Metric/Evaluation:– Use TRL definitions to determine how close the facility allows a technology to reach a representative (TRL 5/6)

and/or space environment (TRL 7)– Evaluate the cost of using the ISS as compared to testing the technology directly in a space environment

• Define a cost for the risk:

• Define a total cost for each step:

• Determine success of using ISS:

GND

ISS

Flight

$1Risk1

$2Risk2

$3Risk3

#

$

TRLwR TRL

R

RRJ

$

$$$,

332121 ,$,$$ RJRRJ

Results


SPHERES Principle of Requirements Balance

• The requirements of a laboratory are balanced such that one requirement does not drive the design in a way that it hinders the ability to succeed on other requirements; further, the hard requirements drive the majority of the design, while soft requirements enhance the design only when possible.

– All the previous principles will create different, but not necessarily independent, requirements

• A successful project balances all its requirements so that no single one overshadows all others

• Balancing the requirements ensures that all the other principles are accounted for and met as best as possible/viable

– There are hard and soft requirements• Hard requirements are usually set at the start of a project to determine the goals that must be

met; they are mostly quantitative

• Soft requirements are features desired by the scientists but which do not necessarily have a specific value or which are not essential for the success of the mission

– Maximize the ratio of hard requirements to soft requirements• Minimize the chance of bloating the facility with unused features

Results


SPHERES SPHERES: Iterations Efficacy

• Simulation: multiple iterations, flexible turnaround• SSL Off-site: multiple iterations, with turnaround of

days• SSL On-site: multiple iterations with hours-to-days

between iterations• KC-135: several iterations with fixed one-day period• KC-135: one iteration between each campaign• MSFC: perform multiple iterations with flexibility in

hours/days• MSFC: one iteration between each campaign• ISS: expected multiple iterations with turnaround in

increments of two weeks

MSFC-2

Simulation

EffectiveIterativeResearch

IneffectiveIterativeResearch

Time between iterations i

Nu

mb

er

of

itera

tion

s

KC-135-2

KC-135-1

MSFC-1

ISSSSL-on

SSL-off

Step Location 1 2 3 4 Comments

Simulation Researcher Minutes Researcher Hours Low fidelity MIT SSL – Off Site 20 min Hours Researcher Days SPHERES team member

runs tests MIT SSL – On Site 20 min Minutes Travel Minutes Maximum level of

support KC-135 20 sec Hours 24-72

hours Minutes Challenging

environment MSFC 10 min Minutes

/Hours Hours /Days

Minutes Possibility of two iterative loops: on site and at remote location

ISS 30 min 2 days 2-4 weeks 2 days Analysis time in increments of 2 weeks


SPHERES

• Evaluation Framework– Created to allow a member of the NGO or NASA team to evaluate a design to

determine:• Correct utilization of the ISS• Technology advancement• Mission scope

– Based on six principles:• Iterative Research

• Enabling a Field of Study

• Optimized Utilization

• Requirements Balance solely part of the design framework

Evaluation Framework

Documents

Thesis Defense Alvar Saenz-Otero May 4, 2005