Space Systems LaboratoryMassachusetts Institute of Technology SPHERES Design Principles for the Development of Space Technology Maturation Laboratories

Design Principles for ISS ExperimentsThesis Defense
Alvar Saenz-Otero
MIT Space Systems Laboratory
MIT Space Systems Laboratory
Prof. Eric Feron Member
Javier de Luis, PhD Member
Payload Systems Inc.
MIT Space Systems Laboratory / Minor Advisor
Prof. Jeffrey A. Hoffman Reader
MIT Man Vehicle Laboratory
Prof. Dava Newman Reader
Space Systems Laboratory
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
Create a design methodology for the development of micro-gravity laboratories for the research and maturation of space technologies
Review of mg and remote research facilities
The conjunction of
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
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
The International Space Station
Description
International system [SCAR]
Development of shared facilities in a harsh environment [Ashley, ’04]
Ocean Exploration Research
[Penzias, ’73]
Concentrate on conducting an experiment, not data analysis [Cunningham, ’70]
Similarities with space challenges
Space Lab [Emond, ’00] 7 ~2w
International coop. aboard shuttle
Tech. research, Earth & space sciences, biology, life support, shuttle docking, ISS Phase I
Literature Research
Space stations do provide a unique environment for microgravity research
Allow the researcher to be in-location with facilities to conduct specific experiments
WHOI
BAS
Skylab - [Belew]
MIR - NASA
How do you design and build experiments to operate remotely under a microgravity environment?
Description
Technology
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]
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)
STS-48 (‘91): fluid slush and jointed truss structures
STS-62 (‘94): truss structures, pre-DLS
DLS - Dynamics Load Sensor
MIR: crew motion sensors
STS-67 (‘95): robust, MCS algorithms for space structures
ISS Expedition 1 (‘00): neural networks, non-linear & adaptive control
Hypothesis
MODE
DLS
MACE
Modular, generic equipment,
Multiple investigators, human observability,
SW reconfiguration
MIT SSL Laboratory
Design Philosophy (2)
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
Feature
Description
Allow reconfigurable control algorithms
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
Experimentation
Lab
FF
Avionics
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
Metrology
Communications
Facilitate Iterative Research
Multi-layered operations plan
Continuous visual feedback
Families of tests
De-coupling of SW from NASA safety
Support of Experiments
Layered metrology system
Full data storage
No precision truth measure
Support Multiple Scientists
Guest Scientist Program
Generic Operating System
Operation with three units
Hardware expansion capabilities
New Hypothesis
"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]
3
The initial modeling and implementation is not part of the iterative research process
1
Data evaluation
Technology Maturation
3
Algorithm
Modification
Experimentation
All these tests are performed at the researcher home facility using their own computers.
Initial Algorithm Development
Simulation: science time determined by researcher
SSL Off-site Tests: science time determined by researcher and SSL availability (days/weeks/months)
Data evaluation
Performed at the researcher’s home facility.
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)
Data evaluation
Performed at the researcher’s home facility
KC-135 RGA: science time determined by parabola time (~60s), and length of stay at remote location (1-3 days)
Data evaluation
Maximum 4 days total operations
Researcher Remote Location (e.g. hotel)
KC-135
Algorithm Modification
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)
Data evaluation
Researcher Remote Location
Algorithm Modification
Direct link to ISS data transfer system
De-coupling of SW from NASA safety
Physical Simulation of Space Environment
Operation with three units
Software (Appendix C)
Generic Operating System
Test management & synchronization
Test Time 2
[ms]
n/a n/a n/a n/a -1000 -800 -600 -400 -200 0 200
User
Input
Laptop
Control
sync
7865 8065 8265 8465 8665 8865 9065 9265 9465 9665 9865
Sat 2 Time
Sat 1 Time
TX 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
Avionics (Appendix B)
Layered metrology system
Communications (Appendix D)
Full data storage
DSP Memory Buses
enable transmission SWI
manage state of health packets
manage background telemetry packets
process large data transmissions
Guest Scientist Program
Information Exchange Operations
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
LABORATORY
Experimentation
Description
Design Principles for -g
Laboratories 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 Optimized Utilization
Principle of Focused Modularity
Principle of Requirements Balance
Principle of Iterative Research
A laboratory allows investigators to conduct multiple cycles of the iterative research process in a timely fashion
Three iteration loops:
Results
Concept
Hypothesis
Technology
Maturation
Conception
Deduction
Induction
3
Modify the hypothesis about the goals and performance requirements for the technology.
New Hypothesis
Modify the experiment design to allow for comparison of different designs.
2
Design
1
Experiment
Repeat the test to obtain further data.
The iterative research process requires to close the loop on several steps.
The most basic loop, the first loop, is the one that allows repetitions of an experiment without any changes to demonstrate the repeatability of the experiment. The loop can also close in software changes to allow different types of control of the experiment that will provide data to further validate the research.
The second loop allows the experiment physical design to be changed, which allows to test different dynamics or other physical elements of the testbed. This results in the ability to test the theory in a broad range of areas.
The third loop enables the scientist to re-thing the hypothesis itself and allow the testbed to change substantially showing a full range of analysis on the hypothesis and demonstrating its useful range of operations.
Collection bandwidth, precision, accuracy
Flexible operations plan
Flexible time between
small
large
The metric for iterative research, qualitatively, is the determination of an experiment’s ability to close any of the loops previously mentioned.
The quantitative measure is one that takes into consideration:
- How many times the experiment can run (n)
- The cost of running that experiment over time (C), which takes into account the period of time between experiment runs
- The cost of launching the experiment, including the fact that it may be launched multiple times if the second or third loop are not available while the facility resides in the ISS.
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
Results
Covers the “breath” of the research, how much of a field of study can be covered by the facility
This principle covers the ‘breath’ of the research, how much of the full technology can be covered by the laboratory.
This principle, when fully met, indicates that the facility is actually a laboratory for that field of study, rather than a facility that allows testing of a specific area.
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)
Results
Increased cost
Expensive area
The metrics for this facility include, qualitatively, to determine the range of the field of study covered. Quantitatively, the following factors are considered:
- The number of areas that compose the whole field (m)
- The number of areas covered by the facility (n)
- The cost of creating a facility to cover only one area, K1, repeated multiple times (n)
- The cost of launching a shared facility, K2, added to the cost of launching each individual component that allows testing of an area, Ci.
The goal is to ensure that J5 is less than one, meaning that a broad area of the field of study is covered and the cost of the facility is lower than using one experiment for each area.
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
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
While the ISS allows humans to be in the loop for continuos supervision of the experiments, and possibly also allows continuous communications with the experiment, the fact is that the operator of the facility is not the researcher. Because of this a vast majority of the experiments currently in the ISS are simply ‘exposure’ experiments that collect data on their own and do not present data to the operator to determine the operation of the experiment.
The concept of utilization of the ISS does call for an increase in human participation in the use of the facilities and therefore, in turn, it will be necessary to consider the interaction of humans with the facility.
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
Iterative Research
Optimized Utilization
Focused Modularity
Description
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
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
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
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
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
This principle presents the need to realize what the ISS can offer to the scientist, rather than what the scientist needs, and calls for a balance. If an experiment does not utilize the ISS resources correctly, then it may be better to use an independent facility/experiment rather than under-utilizing resources in the ISS which may be better used for other facilities.
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 ~12h
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
All experiments contain basic elements that can support other similar experiments; during the design phase of said experiments these elements can be identified. If the development of these facilities as generic equipment that can be used by future experiments and does not compromise the mission of the original experiment, they should be made available. In this fashion, a facility is created by accepting single experiments that each provide some form of generic equipment which can be later used by new experiments.
This principle, therefore, accepts the fact that a single experiment may not itself constitute a laboratory, but by making parts of an experiment modular a laboratory may be built after launch of several facilities with similar goals.
Note that this requirement does not call for every single facility to be fully modular and allow anything to happen. The ISS itself is the ‘do everything’ environment, but it needs to be complemented by other modular systems that provide support for specific fields. Trying to create a ‘do everything’ module again will not allow any specific technology to mature as its needs will most likely not be met.
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
Results
To evaluate the modularity of a system a truth table is presented with categories that identify the nature of each sub-system of the facility. The description of these criteria are:
· Inter-disciplinary use: if the component can be used in different disciplines within the field it should be generic equipment
· Reconfiguration: if the component easily allows the experiment to change the general area of study of the experiment, while supporting all other functions, it should be generic equipment
· Obsolescence: only those components that are not expected to be obsolete by the time of re-use should be made generic
· Life-time: only those components whose life-time is over the anticipated time to re-use should be made generic
· Cost amortization: if the component cost is likely to be amortized by future use in different experiments it should be generic equipment
· Maintain original goals: the immediate research should not be compromised by making a specific equipment generic
Inter-discipline
Reconfigure
Obsolete
Life-limited
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 & concept
TRL 3-4: Proof-of-concept & laboratory breadboard
TRL 5: Component validation in relevant environment
TRL 6: System prototype demonstration in relevant environment
TRL 7: System prototype demonstration in space environment (usually skipped due to cost)
TRL 8: Flight system demonstration in relevant environment
TLR 9: Mission Operations
Complexity
Risk
Cost
ISS Projects
A major factor in consideration of new technologies is their level of maturation, a place where the NASA New Millennium Program took the initiative to create a set of “Technology Readiness Levels”. These levels provide scientists with guidelines on where their technology is such that it can be used in flight systems.
There are two goals expected out of this principle:
- Should the TRL’s be reviewed to allow for a smoother transition from ground to flight?
- How can the ISS be used to create a smoother transition, whether the same levels are kept or new ones are created
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
$1
Risk1
$2
Risk2
$3
Risk3
Results
The metric to evaluate how well the introduction of the ISS is simplified into a comparison of the cost of launching the technology direction from ground, or going through the ISS in at least one extra step. The cost, though, is defined not only in the actual monetary terms of the cost of the experiment, but also as a function of the risks taken in skipping TRL levels.
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
All the previous principles will create a large set of requirements, and it is likely that some will have a much larger effect on the success and cost of the mission than others. Therefore, it is useful to separate the many requirements into different levels of importance, and realize the costs of meeting each requirement, terminating in the balancing of the requirements so that the mission objectives are met as effectively as possible.
The two divisions are:
-Hard requirements are usually set at the start of a project to determine the goals that must be met; they are requirements determined to be essential to the mission success, and should be met. The majority of hard requirements should be quantitative, providing a clear determination of when they are met or not. The qualitative ones should be defined clearly enough that no ambiguity exists on whether they are met or not.
-Soft requirements are features desired by the scientists. These features are not essential to the mission, but in general they allow the mission to be carried out easier or provide extra features or data that improves its performance. Soft requirements, though, usually contribute to “requirement creep”, something that should be prevented.
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
Effective
Iterative
Research
Ineffective
Iterative
Research
MIT SSL – On Site
Minutes
Possibility of two iterative loops: on site and at remote location
ISS
Evaluation Framework
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
Optimized Utilization
Start ISS GUI
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
hours
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
d
x
x
f
y
f
x
l
y
l
Follower
Leader

Documents

Space Systems LaboratoryMassachusetts Institute of Technology SPHERES Design Principles for the Development of Space Technology Maturation Laboratories