560 likes | 749 Vues
Design Principles for the Development of Space Technology Maturation Laboratories Aboard the International Space Station. Thesis Defense Alvar Saenz-Otero May 4, 2005. Committee Members. Prof. David W. Miller Chair MIT Space Systems Laboratory Prof. Jonathan P. How Member
E N D
Design Principles for the Development of Space Technology Maturation Laboratories Aboard the International Space Station Thesis Defense Alvar Saenz-Otero May 4, 2005
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
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
Approach / Outline Chapter Objective 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 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 Motivation & Other Facilities 1 Hypothesis ISS & Facility Characteristic 2 SSL Design Philosophy 3 Experimentation SPHERES 4 Results Design Principles & Frameworks 5 Conclusions & Contributions Evaluations 6 Conclusions/ Contributions 7 Problem Statement
Outline Chapter Objective • 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 Motivation & Other Facilities 1 Hypothesis ISS & Facility Characteristic 2 SSL Design Philosophy 3 Experimentation SPHERES 4 Results Design Principles & Frameworks 5 Conclusions Evaluations 6 Conclusions 7
In-house Simulation Air table Robot Cars Helium Balloons 6 DOF Robot Arms Robot Helicopters 3rd Party Ground based Flat Floor Drop Towers Neutral Buoyancy Tank RGA (KC-135) m-g Research Facilities Environment Operations mg Dur. Mis Dur. 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 ~ $$ DOF Dyn. Exp. Ops. Data Acc. Cost MIT SSL/ACL 3(5) ~ h w $$ 6 s w ~ $$$ 6 h w ~ $$$ 6 ~ s w ~ $$$ JSFC RGO KC-135 - NASA • Space based • Shuttle Middeck • Shuttle Payload • ISS • Free Flyer 6 ~ h-w w ~ $$$$ 6 h-w w ~ $$$$ 6 h-y mo-y ~ $$$$ 6 mo-y mo-y $$$$$ ISS - NASA Literature Research
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 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 Remote Research Facilities Skylab - [Belew] MIR - NASA BAS WHOI Space stations do provide a unique environment for microgravity research Allow the researcher to be in-location with facilities to conduct specific experiments How do you design and build experiments to operate remotely under a microgravity environment? Literature Research
Outline Chapter Objective • 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 Motivation & Other Facilities 1 Hypothesis ISS & Facility Characteristic 2 SSL Design Philosophy 3 Experimentation SPHERES 4 Results Design Principles & Frameworks 5 Conclusions Evaluations 6 Conclusions 7
Experiment Operation Types Observation Exposure Iterative Experiments Major areas of study Educational Pure Science Technology The International Space Station 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) Hypothesis
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 MODE DLS MACE Hypothesis
MIT SSL LaboratoryDesign Philosophy (1) • 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 MODE DLS MACE Hypothesis
MIT SSL LaboratoryDesign 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
Outline Chapter Objective • 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 Motivation & Other Facilities 1 Hypothesis ISS & Facility Characteristic 2 SSL Design Philosophy 3 Experimentation SPHERES 4 Results Design Principles & Frameworks 5 Conclusions Evaluations 6 Conclusions 7
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 SPHERES Design Experimentation
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) SPHERES Overview Control Panel Pressure Regulator Ultrasound Sensors Pressure Gauge Upload program Download data Battery Thrusters Experimentation
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
Initial Setup Science Time Overhead Time 1 4 Implementation & Test Setup Hardware Test Data Collection 2 Initial Implementation 3 Algorithm Modifications Problem Statement Initial Modeling Theoretical Model Data evaluation The initial modeling and implementation is not part of the iterative research process Technology Maturation Noise Design Experiment True State of Nature + Previous Data New Data New Hypothesis Hi+1 Induction Hypothesis Hi Deduction Model of Hi SPHERES: Iterative Research Process • Scientific Method Steps • Design • Deduction • Experimentation • Induction • New Hypothesis Design Experiment New Hypothesis Deduction Induction [Gauch] "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) Experimentation
SPHERES: IterationsSteps 1, 2, 4 • Continuous visual feedback • Families of tests • Easy repetition of tests • Location specific GUI’s • Re-supply of consumables • FLASH memory and bootloader 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Communications status Theoretical Model Data evaluation Technology Maturation Data recording status Initialization Optional real-time data display Satellite status summary Program and test numbers, timing Debug real-time data One-key commands Single key test start/stop Experimentation
SPHERES: IterationsStep 3 • Guest Scientist Program • Standard Science Libraries • Multi-layered, multi-environment operations plan 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Theoretical Model Data evaluation Technology Maturation Collect data files Compile new program image Analyze data SPHERES provides Matlab functions Update algorithms with CCS C or C++ Experimentation
SPHERES: IterationsStep 3 • Guest Scientist Program • Standard Science Libraries • Multi-layered, multi-environment operations plan • Simulation: science time determined by researcher 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Theoretical Model Data evaluation Technology Maturation All these tests are performed at the researcher home facility using their own computers. 1 2 3 Initial Algorithm Development Researcher Simulation Test Researcher Data Collection Minutes Data Analysis Researcher Deployment to Hardware Tests debug 4 Implementation & Setup Hours Experimentation
SPHERES: IterationsStep 3 • Guest Scientist Program • Standard Science Libraries • 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) 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Theoretical Model Data evaluation Technology Maturation Performed at the researcher’s home facility. Performed at the MIT SSL facilities 4 1 Integration to flight code Hardware Test 20 minutes Initial Algorithm Development Researcher Algorithm Translation Days debug 1 4 Simulation Test Researcher Algorithm Modification Hours 2 Data Collection Hours 2 3 Data Collection Minutes Data Analysis Researcher 4 Verification Deployment to ISS Maturation Experimentation
SPHERES: IterationsStep 3 • Guest Scientist Program • Standard Science Libraries • 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) 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Theoretical Model Data evaluation Technology Maturation Performed at the researcher’s home facility Performed at the MIT SSL facilities 1 2 Initial Algorithm Development Researcher Algorithm Translation Days Hardware Test 20 minutes Data Collection Minutes debug 4 3 Algorithm Modification Minutes Data Analysis Travel Time Maturation/ deployment to ISS Experimentation
SPHERES: IterationsStep 3 • Guest Scientist Program • Standard Science Libraries • 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) • KC-135 RGA: science time determined by parabola time (~60s), and length of stay at remote location (1-3 days) 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Theoretical Model Data evaluation Technology Maturation Researcher’s home facility / MIT SSL Maximum 4 days total operations Researcher’s home facility / MIT SSL KC-135 Researcher Remote Location (e.g. hotel) 1 2 3 Hardware Test 20 seconds Data Collection Hours Data Analysis 24-72 Hours Initial Algorithm Development Researcher Maturation or deployment to ISS 3 4 Visual Analysis 60 seconds Algorithm Modification Minutes Experimentation
SPHERES: IterationsStep 3 • Guest Scientist Program • Standard Science Libraries • 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) • 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) 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modification 3 Theoretical Model Data evaluation Technology Maturation Limited to length of travel to MSFC MSFC Flat Floor 3 Visual Analysis minutes Researcher’s home facility / MIT SSL 2 3 4 1 Data Collection Minutes Data Analysis Few Hours Algorithm Modification Minutes Hardware Test 10 minutes Initial Algorithm Development Researcher Researcher Remote Location (e.g. hotel) 4 3 2 Algorithm Modification Minutes Data Analysis Days Data Collection Hours Maturation or deployment to ISS Experimentation
Performed at the researcher’s home facility. MIT SSL 4 1 Total overhead: Hours or 2 weeks cycle Integration to flight code Days Hardware Test 20 minutes Initial Algorithm Development Researcher debug 1 4 Simulation Test Researcher Algorithm Modification GND: Hours ISS: 2 weeks cycle 2 Data Collection Hours 2 3 Data Collection Minutes Data Analysis 2 week cycle 4 Total overhead: Days Verification Days Maturation PSI STP JSC Total overhead: ~2 days 4 To JSC 1 Day JSC STP PSI Data Download 2-3 days Video Delivery ~1 week 4 2 ISS Server 1 Day ISS 4 ISS Laptop Minutes 2 ISS Server Minutes Video 1 1 4 Astronaut feedback Minutes 6DOF Test 30 minutes Program Load Minutes Data in Laptop 2 1 Preview analysis Minutes Maximum total time: 2 Hours SPHERES: IterationsISS Steps Experimentation
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 4 1 Implementation & Test Setup Hardware Test 2 Data Collection Algorithm Modifications 3 Theoretical Model Data evaluation Beacons (5) ISS Laptop Technology Maturation SPHERES (3) Crew Courtesy Boeing Co ISS 4 ISS Laptop Minutes 2 ISS Server Minutes Video 1 1 4 Astronaut feedback Minutes 6DOF Test 30 minutes Program Load Minutes Data in Laptop 2 1 Preview analysis Minutes Maximum total time: 2 Hours Experimentation
HW DSP/BIOS SPHERES Core GSP Standard Science Libraries HW Interrupts IMU IMU Met. (IMU) Global Met. Global Met Met. (Global) SW Interrupts Controllers Propulsion Propulsion Test Init Estimators Data TX Data RX “Start Test” Packet TX Window Controller Control Maneuvers User Input Laptop Control Sat 1 Sat 2 Comm Comm Mixers 15ms Housekeeping Terminators Laptop Time [s] 572.1 572.3 572.5 572.7 572.9 573.1 573.3 573.5 573.7 573.9 574.1 Tasks SPHERES Met. Task Math Sat 1 Time 4321 4521 4721 4921 5121 5321 5521 5721 5921 6121 6321 Utilities GSP Background Task Background Task n/a -1000 -800 -600 -1000 -800 -600 -400 -200 0 200 Bad RX Test Time 1 [ms] sync sync start GSP Metrology Task Metrology Task 7865 8065 8265 8465 8665 8865 9065 9265 9465 9665 9865 Sat 2 Time n/a n/a n/a n/a -1000 -800 -600 -400 -200 0 200 Test Time 2 [ms] User-accessible Interface Hidden Interfaces SPHERES: More Iterative Research Features • Software (Appendix C) • Generic Operating System • Software cannot cause a critical failure • Test management & synchronization
Avionics (Appendix B) Layered metrology system 32 bit floating point DSP Communications (Appendix D) Flexible communications: real-time & post-test download Full data storage STL RF STS RF COMM Rx Watchdog receive data, put into RX pipes HWI CLK (BIOS) Micro Processor (C6701 DSP) Communications Avionics (PIC MCU’s) CLK Comm TDMA Mgr enable transmission SWI Expansion Port COMM Tx send packets to DR2000 when enabled Priority PRD (BIOS) SWI Fast Housekeeping manage state of health packets Gyroscopes Telemetry manage background telemetry packets Metrology Avionics FPGA Control Panel COMM Mgr prepare TX packets; process RX packets A2D TSK DataComm STL DataComm STS process large data transmissions CP Monitor initialize commports Power Propulsion Beacon US/IR 12x Amplifiers Accelerometers DSP Memory Buses Serial Lines Digital I/O signals Analog signals Battery Packs Solenoids SPHERES: More Iterative Research Features
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 SPHERES: Supporting Multiple Scientists Current Programs Future Programs TPF ARD Mass ID Multi-stage TPF Tethers MOSR NASA Experimentation
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… DARPA NASA NASA MOSR Terrestrial Planet Finder SPECS Orbital Express NASA SPHERES: A Laboratory LABORATORY • A separated spacecraft laboratory! • It is a reconfigurable and modular laboratory which supports conducting-g iterative experiments by multiple investigators Experimentation
Outline Chapter Objective • 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 Motivation & Other Facilities 1 Hypothesis ISS & Facility Characteristic 2 SSL Design Philosophy 3 Experimentation SPHERES 4 Results Design Principles & Frameworks 5 Conclusions Evaluations 6 Conclusions 7
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 Results
Three iteration loops: A laboratory allows investigators to conduct multiple cycles of the iterative research process in a timely fashion New Hypothesis 3 • Repeat the test to obtain further data. • Modify the experiment design to allow for comparison of different designs. • Modify the hypothesis about the goals and performance requirements for the technology. 2 Design 1 Experiment Principle of Iterative Research Concept Hypothesis Deduction Facility Design Experiment Design Experiment Implement Experiment Operation Data Collection Conception Science Time Overhead Time Technology Maturation Data Analysis Induction Studies the “depth” of the research Results
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 betweeniterations • Too little time preventssubstantial data analysis • Too much time createsproblems with resourcesand institutional memory • Maximize number ofiterations possible n>>1 ISS Shuttle RGA Effective Iterative Research MACE MIR DLS Number of iterations Ineffective Iterative Research MODE-Reflight MACE-II 0 Time between iterations ti good bad good bad small large 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 Results
Increased cost per area of study Expensive area Fractional cost of Laboratory 1 0% 25% 50% 75% 100% % of field of study covered 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
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 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 • 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
Science Requirements Functional Requirements Engineering Requirements Management Requirements Enabling a Field of Study Iterative Research Focused Modularity Mission Objective Req’s Balance Optimized Utilization Remote Operation Facility Design Technology Maturation 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 Results
Outline Chapter Objective • 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 Motivation & Other Facilities 1 Hypothesis ISS & Facility Characteristic 2 SSL Design Philosophy 3 Experimentation SPHERES 4 Results Design Principles & Frameworks 5 Conclusions Evaluations 6 Conclusions 7
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
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
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
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
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
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
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 Results
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 Now with ISS Complexity Risk Cost 1 2 3 4 5 6 7 8 9 TRL ISS Projects Principle of Incremental Technology Maturation 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 Results
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: Principle of Incremental Technology Maturation $1 Risk1 ISS $2 Risk2 GND Flight $3 Risk3 Results
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