Close
About
FAQ
Home
Collections
Login
USC Login
Register
0
Selected
Invert selection
Deselect all
Deselect all
Click here to refresh results
Click here to refresh results
USC
/
Digital Library
/
University of Southern California Dissertations and Theses
/
A declarative design approach to modeling traditional and non-traditional space systems
(USC Thesis Other)
A declarative design approach to modeling traditional and non-traditional space systems
PDF
Download
Share
Open document
Flip pages
Contact Us
Contact Us
Copy asset link
Request this asset
Transcript (if available)
Content
A Declarative Design Approach to Modeling Traditional
and Non-Traditional Space Systems
by
Lucy M. Hoag
Submitted to the USC Graduate School in partial fulfillment of the requirements for the degree
of
Doctor of Philosophy
in Astronautical Engineering
University of Southern California
May 2014
Advisory Committee:
Professor Azad M. Madni (Chair)
Professor Daniel Erwin
Professor Joseph Kunc
Professor Berok Khoshnevis
ii
© Copyright by Lucy Hoag 2014
All Rights Reserved
iii
Abstract
The space system design process is known to be laborious, complex, and computationally
demanding. It is highly multi-disciplinary, involving several interdependent subsystems that
must be both highly optimized and reliable due to the high cost of launch. Satellites must also be
capable of operating in harsh and unpredictable environments, so integrating high-fidelity
analysis is important. To address each of these concerns, a holistic design approach is necessary.
However, while the sophistication of space systems has evolved significantly in the last 60 years,
improvements in the design process have been comparatively stagnant. Space systems continue
to be designed using a procedural, subsystem-by-subsystem approach. This method is inadequate
since it generally requires extensive iteration and limited or heuristic-based search, which can be
slow, labor-intensive, and inaccurate.
The use of a declarative design approach can potentially address these inadequacies. In the
declarative programming style, the focus of a problem is placed on what the objective is, and not
necessarily how it should be achieved. In the context of design, this entails knowledge expressed
as a declaration of statements that are true about the desired artifact instead of explicit
instructions on how to implement it. A well-known technique is through constraint-based
reasoning, where a design problem is represented as a network of rules and constraints that are
reasoned across by a solver to dynamically discover the optimal candidate(s). This enables
implicit instantiation of the tradespace and allows for automatic generation of all feasible design
candidates. As such, this approach also appears to be well-suited to modeling adaptable space
iv
systems, which generally have large tradespaces and possess configurations that are not well-
known a priori.
This research applied a declarative design approach to holistic satellite design and to tradespace
exploration for adaptable space systems. The approach was tested during the design of USC’s
Aeneas nanosatellite project, and a case study was performed to assess the advantages of the new
approach over past procedural approaches. It was found that use of the declarative approach
improved design accuracy through exhaustive tradespace search and provable optimality;
decreased design time through improved model generation, faster run time, and reduction in time
and number of iteration cycles; and enabled modular and extensible code. Observed weaknesses
included non-intuitive model abstraction, increased debugging time, and difficulty of data
extrapolation and analysis.
Thesis Supervisor: Azad M. Madni
Title: Professor, Department of Astronautical Engineering
v
Acknowledgements
Thank you to Dr. Azad Madni for providing a voice and guidance to this research, as well as
tireless help and support, in spite of distance and unconventional circumstances. Thank you to
Dave Barnhart for being the genesis of this work and a continuous source of inspiration. Thank
you to Dr. Tatiana Kichkaylo, without whom I could not have done any of this work. Thank you
to Dr. Gordon Roesler, for pushing me on and enabling great opportunities. Thank you to Dr.
Dan Erwin and Dr. Joseph Kunc, supportive from day one even though I was just an undergrad
turning in her homework late, and to Dr. Berok Khoshnevis. Thank you to Marrietta Penoliar for
making things happen each and every time. And thank you to the various professors, colleagues,
and fellow women in engineering who have offered insight along the way, which has been
invaluable. Last, thank you to my amazingly supportive family and friends.
vi
Table of Contents
Abstract .......................................................................................................................................... iii
Acknowledgements ......................................................................................................................... v
List of Figures .............................................................................................................................. xiv
List of Tables ............................................................................................................................. xviii
List of Acronyms ......................................................................................................................... xix
Chapter 1 ......................................................................................................................................... 1
Introduction ................................................................................................................................. 1
1.1
Motivation ...................................................................................................................... 2
1.2
Dissertation Overview .................................................................................................... 5
1.3
Contributions .................................................................................................................. 7
Chapter 2 ......................................................................................................................................... 8
Background ................................................................................................................................. 8
2.1
Cost and Complexity Factors ......................................................................................... 8
2.2
Uncertain Futures ......................................................................................................... 11
2.2.1
Technical Failures ................................................................................................. 11
2.2.2
Market Uncertainties ............................................................................................. 13
vii
2.2.3
On-Orbit Collisions ............................................................................................... 14
2.3
New Morphologies ....................................................................................................... 16
2.3.1
Small Satellites ...................................................................................................... 19
2.3.2
CubeSats ............................................................................................................... 26
2.3.3
Disaggregation ...................................................................................................... 27
2.3.4
Standardization, Modularity and Reconfigurability ............................................. 34
2.3.5
Space Ecosystem ................................................................................................... 40
2.4
Declarative Modeling ................................................................................................... 45
2.4.1
Constraint-based Reasoning .................................................................................. 47
Chapter 3 ....................................................................................................................................... 50
Space System Design ................................................................................................................ 50
3.1
The Design Process ...................................................................................................... 51
3.2
Modeling Design .......................................................................................................... 55
3.3
Decision Making ........................................................................................................... 58
3.3.1
Analysis of Alternatives (AoA) ............................................................................ 58
3.3.2
Analytic Hierarchy Process (AHP) ....................................................................... 59
3.3.3
Multi-Attribute Utility Theory .............................................................................. 59
3.3.4
Quality Function Deployment (QFD) and the House of Quality (HoQ) .............. 60
3.4
Optimization ................................................................................................................. 62
3.4.1
Multidisciplinary Design Optimization (MDO) ................................................... 63
viii
3.4.2
Distributed Optimal Design .................................................................................. 67
3.5
Value-Centric Design ................................................................................................... 68
3.5.1
Defining Value ...................................................................................................... 73
Chapter 4 ....................................................................................................................................... 78
Spacecraft Design Approaches .................................................................................................. 78
4.1
Satellite Design at Various Organizations .................................................................... 80
4.1.1
Aerospace Corporation, SSDM, 1998 .................................................................. 80
4.1.2
Aerospace Corporation, SmallSatCEM, 2001 ...................................................... 81
4.1.3
Ecole Polytechnique Federale de Laussan, CO
2
DE, 2008 .................................... 83
4.1.4
Jet Propulsion Laboratory, MIDAS, 1995 ............................................................ 86
4.1.5
Jet Propulsion Laboratory, ISDE, 1998 ................................................................ 87
4.1.6
JHU-APL, 2000 .................................................................................................... 88
4.1.7
MIT, MATE-CON, 2004 ...................................................................................... 91
4.1.8
MIT, RSC, 2009 .................................................................................................... 92
4.1.9
NASA, ISE, 2008 .................................................................................................. 94
4.1.10
National University of Defense Technology, SIDE, 2006 ................................. 95
4.1.11
Princeton Satellite Systems, Spacecraft Control and CubeSat Toolbox ............. 96
4.1.12
Purdue University, 2003 ..................................................................................... 97
4.1.13
QuickSat/Step_SATdb, 2013 .............................................................................. 98
4.1.14
Tsinghua University, SDIDE, 2003 .................................................................... 99
ix
4.1.15
TU Munchen, MUSSat, 2000 ............................................................................. 99
4.1.16
TU Delft, SCALES, 2009 ................................................................................. 100
4.1.17
University of Colorado, SCOUT, 1999 ............................................................ 103
4.1.18
Other Satellite Design Resources ...................................................................... 104
4.2
Non-Traditional Design Approaches .......................................................................... 105
4.2.1
AFRL, Mission and Satellite Design Toolkit, 2010 ........................................... 105
4.2.2
Crowd-sourced Design ........................................................................................ 108
4.2.3
DLR, iBOSS Design Tool, 2012 ........................................................................ 109
4.2.4
Parameter Influence Method, 2013 ..................................................................... 110
Chapter 5 ..................................................................................................................................... 112
Modeling Fractionated Systems .............................................................................................. 112
5.1
Past Research Efforts .................................................................................................. 112
5.1.1
2003 – de Weck .................................................................................................. 115
5.1.2
2004 – Brown and Eremenko ............................................................................. 118
5.1.3
2004 – Jilla .......................................................................................................... 121
5.1.4
2005 – Chaize ..................................................................................................... 122
5.1.5
2006 – Rooney .................................................................................................... 123
5.1.6
2007 – DARPA System F6 VCDM .................................................................... 124
5.1.7
2008 – LoBosco .................................................................................................. 130
5.1.8
2009 – Lafleur ..................................................................................................... 131
x
5.1.9
2009 – O’Neill .................................................................................................... 131
5.1.10
2011 – DARPA System F6 VCAD ................................................................... 132
5.1.11
2011 – Daniels .................................................................................................. 135
5.1.12
2011 – Kwon ..................................................................................................... 135
5.1.13
2011 – Tamaskar ............................................................................................... 136
5.1.14
2012 - Yao ......................................................................................................... 137
5.1.15
2013 - Aliakbargolkar ....................................................................................... 139
5.1.16
2013 - Salado .................................................................................................... 140
5.1.17
2013 - Xu .......................................................................................................... 141
5.2
Enabling Technologies ............................................................................................... 141
5.3
Evaluation of Previous Studies ................................................................................... 144
Chapter 6 ..................................................................................................................................... 145
Methods, Processes, and Tools ............................................................................................... 145
6.1
Constraint Satisfaction ................................................................................................ 146
6.2
Branch-and-Bound Search .......................................................................................... 148
6.3
Development of a Comprehensive Component Database .......................................... 149
Chapter 7 ..................................................................................................................................... 151
Declarative Satellite Design .................................................................................................... 151
7.1
Development of SPIDR-Sat ........................................................................................ 152
7.1.1
Modeling in Rules and Constraints ..................................................................... 152
xi
7.1.2
Declarative Model Abstraction ........................................................................... 156
7.1.3
Translation into Interval Arithmetic ................................................................... 161
7.1.4
Design Architecture ............................................................................................ 167
7.2
Validation of the Approach: Design of Aeneas Nanosatellite .................................... 176
7.2.1
Effectiveness in Satellite Design ........................................................................ 176
7.2.2
Strengths and Weaknesses in CubeSat Design ................................................... 180
Chapter 8 ..................................................................................................................................... 187
Declarative Modeling of Fractionated Architectures .............................................................. 187
8.1
Development of F-SPIDR .......................................................................................... 187
8.1.1
Designing a Backbone Constellation .................................................................. 188
8.1.2
Optimal Cluster Design ....................................................................................... 197
8.1.3
Advanced Declarative Modeling ........................................................................ 200
Chapter 9 ..................................................................................................................................... 202
Case Study: Comparing Procedural and Declarative Approaches .......................................... 202
9.1
Metric: Accuracy ........................................................................................................ 203
9.1.1
Tradespace Size .................................................................................................. 205
9.1.2
Optimality ........................................................................................................... 206
9.2
Metric: Time ............................................................................................................... 208
9.2.1
Model Abstraction .............................................................................................. 208
9.2.2
Debugging ........................................................................................................... 210
xii
9.2.3
Runtime ............................................................................................................... 211
9.2.4
Data Analysis ...................................................................................................... 212
9.3
Metric: Scalability ...................................................................................................... 213
9.4
Summary ..................................................................................................................... 214
Chapter 10 ................................................................................................................................... 217
Conclusion ............................................................................................................................... 217
10.1
Findings .................................................................................................................... 217
10.2
Research Contributions ............................................................................................. 220
10.2.1
Automated Satellite Design .............................................................................. 220
10.2.2
Declarative Modeling of Adaptable Space Systems ......................................... 221
10.2.3
Value of Non-traditional and Adaptable Space Systems .................................. 222
10.3
Recommendations for Future Research .................................................................... 222
10.3.1
Automated Hardware-in-the-Loop Testing ....................................................... 222
10.3.2
Fluid Mission Requirements ............................................................................. 223
10.3.3
Other Adaptable Systems .................................................................................. 224
10.3.4
Integration with Existing Research and Methods ............................................. 224
10.4
Final Summary ......................................................................................................... 225
References ................................................................................................................................... 226
Appendix A ................................................................................................................................. 248
SPIDR-Sat v.0 ......................................................................................................................... 248
xiii
A.1
Terminology .............................................................................................................. 248
A.2
Web Portal for Satellite Design ................................................................................. 250
Appendix B ................................................................................................................................. 258
F-SPIDR .................................................................................................................................. 258
B.1
Model Parameters and Relationships ......................................................................... 258
B.1.1
Constellation Token ........................................................................................... 258
B.1.2
Orbit Calculation Arule ...................................................................................... 260
B.1.3
Cluster-Module Arules ....................................................................................... 261
B.1.4
Parameter Totals Srule ....................................................................................... 262
B.1.5
Launch Arule ...................................................................................................... 266
B.1.6
Time to Operability Srule ................................................................................... 269
Appendix C ................................................................................................................................. 271
SPIDR-Lite .............................................................................................................................. 271
C.1
Overview .................................................................................................................... 271
C.2
Example Satellite Design Optimization Problem ...................................................... 272
Appendix D ................................................................................................................................. 281
Additional Observations .......................................................................................................... 281
xiv
List of Figures
Figure 1. The “Space Spiral” fuels increasing costs and longer schedules. Adapted from [262] 10
Figure 2. Concepts of disaggregation ........................................................................................... 28
Figure 3. iBOSS structural building block [257] .......................................................................... 37
Figure 4. iBOSS system building block [257] .............................................................................. 38
Figure 5. Artist's depiction of an iBOSS spacecraft and servicer on-orbit [18]. .......................... 39
Figure 6. Example excel-based House of Quality design matrix [294] ........................................ 62
Figure 7. Optimization approaches [193] ..................................................................................... 66
Figure 8. Commercially available software tools for MDO [252] ................................................ 67
Figure 9. Closed-loop design and analysis in Aerospace Corporation's SmallSatCEM [153] ..... 83
Figure 10. Small satellite design constraints in CO
2
DE [118] ..................................................... 85
Figure 11. Architecture of CO2DE environment [118] ................................................................ 86
Figure 12. JHU/APL component decomposition into relevant parameters, attributes and
interfaces [75] ............................................................................................................................... 89
Figure 13. Flow diagram of the Thermal Control Subsystem in TU Delft’s SCALES [1] ........ 102
Figure 14. Graphical depiction of AFRL’s MSDT toolflow [68] ............................................... 106
Figure 15. Definition of attributes according to change and response framework [39] ............. 123
Figure 16. High-level approach to modeling and simulation in the F6 VCDM effort [173] ...... 126
Figure 17. Example implementation of attitude control options in the procedural approach ..... 154
xv
Figure 18. Example implementation of attitude control options in the constraint-based approach
..................................................................................................................................................... 155
Figure 19. Excerpt of attitude control design logic in SPIDR-Sat (sanitized) ............................ 156
Figure 20. UML-based rule diagram proposed by Kichkaylo .................................................... 159
Figure 21. Graphical rule creation in SPIDR-Lite ...................................................................... 160
Figure 22. Logical flow for calculating atmospheric density (ρ) using interval math. ............... 166
Figure 23. Logical flow for calculating Earth IR using interval math. ....................................... 167
Figure 24. Input screen for SPIDR-Sat small satellite design tool ............................................. 168
Figure 25. SPIDR-Sat can accept an STK satellite file as input for orbit and mission fields ..... 169
Figure 26. Payload parameters input screen in SPIDR-Sat ........................................................ 170
Figure 27. Global variables input screen in SPIDR-Sat ............................................................. 170
Figure 28. ADCNS subsystem input screen in SPIDR-Sat......................................................... 171
Figure 29. Preferences and sub-systems screen in SPIDR-Sat ................................................... 172
Figure 30. Selection of desired optimization metric based on exploration of feasible designs .. 173
Figure 31. Final output screen in SPIDR-Sat. The requested number of output designs are
ordered according to the optimization metric ............................................................................. 174
Figure 32. Designs export to XML in SPIDR-Sat for further analysis ....................................... 175
Figure 33. Power profile time series embedded in SPIDR-Sat optimization loop ..................... 179
Figure 34. Side-by-side comparison of two potential designs. Parameters differing between
designs are displayed in bold. ..................................................................................................... 180
Figure 35. Aeneas’s 0.5m mesh dish antenna, which deploys longitudinally out of the aft end of
the vehicle ................................................................................................................................... 183
Figure 36. Fractionation options in the Shared Space Imager problem [301] ............................ 189
xvi
Figure 37. Key parameter relationships in the F-SPIDR Shared Space Imager model .............. 190
Figure 38. The maximum delay experienced for having an imager overhead a desired location is
determined by altitude and filling factor [301] ........................................................................... 192
Figure 39. Comparison of the number of imagers divided by resolution at 1264 km. Cluster IDs
of 1 correspond to the monolithic design configurations, whereas 2-5 correspond to fractionated
configurations ............................................................................................................................. 193
Figure 40. Comparison of imagers/resolution vs. cost/lifetime for the three constellation orbits
considered [115] .......................................................................................................................... 194
Figure 41. The lowest-cost designs are found at all three altitudes. The middle altitude (896 km)
achieves the highest total productivity. ....................................................................................... 195
Figure 42. Plot of images per day vs. cost per year ($M/year) for the two F6TP image
compression options [115] .......................................................................................................... 196
Figure 43. At higher levels of investment, delay and resolution improve, and different
fractionated configurations are preferred to the monolithic configuration [301] ....................... 197
Figure 44. For these conditions, the monolithic configuration is shown to almost always be the
most optimal [301] ...................................................................................................................... 198
Figure 45. Plot of inter-module distance vs. cost per image for the two available module
navigation schemas [115] ........................................................................................................... 199
Figure 46. Requirements page of the spacecraft design workbook created to seed SPIDR-Sat . 251
Figure 47. Power system page of the spacecraft design workbook created to seed SPIDR-Sat . 252
Figure 48. User input fields of the SPIDR-Sat v.0 spacecraft design portal .............................. 253
Figure 49. Sample design results from SPIDR-Sat v.0 ............................................................... 254
Figure 50. Excerpt of the interactive component database in SPIDR-Sat v.0 ............................ 255
xvii
Figure 51. Graphical problem specification in the SPIDR-Lite tool .......................................... 273
Figure 52. Creation of system and subsystem token types in SPIDR-Lite ................................. 273
Figure 53. Variables are added to components, systems and subsystem tokens ........................ 275
Figure 54. Creation of discrete variables in SPIDR-Lite ............................................................ 276
Figure 55. Creation of a mathematical constraint in a SPIDR-Lite token .................................. 277
Figure 56. Creation of rules in SPIDR-Lite ................................................................................ 278
Figure 57. Final output screen of the SPIDR-Lite satellite design example problem, with
resultant designs on the left and individual design information on the right .............................. 280
xviii
List of Tables
Table 1. DARPA Phoenix satlet efforts to date. Adapted from [21] ............................................ 32
Table 2. Space mission engineering process for a need-driven mission. Adapted from [262] ..... 53
Table 3. Manifestations of flexibility. Adapted from [32] ............................................................ 77
Table 4. Manifestations of robustness. Adapted from [32] .......................................................... 77
Table 5. Summary of DARPA System F6 VCDM tools. Adapted from [34] and [173] ............ 124
Table 6. Uncertainty types and associated embedded real options (ERO). Adapted from [45] . 133
Table 7. Readiness of key fractionation enabling technologies (in 2009). Adapted from [81] .. 142
Table 8. Rule- and constraint-based model elaboration process ................................................. 157
Table 9. Parameters of five representative optical payloads modeled in F-SPIDR .................... 191
Table 10. Summary of case study results .................................................................................... 215
xix
List of Acronyms
ADCS Attitude Determination and Control System
AFRL Air Force Research Laboratory
AHP Analytic Hierarchy Process
AI Artificial Intelligence
ALASA Airborne Launch Assist Space Access
AoA Analysis of Alternatives
ASAT Anti Satellite [system]
B&B Branch-and-Bound
BOL Beginning Of Life
BOM Bill Of Materials
CAE Computer-Aided Engineering
CAPM Capital Asset Pricing Model
CDGPS Carrier-phase Differential GPS
CDH/C&DH Command and Data Handling
CE Concurrent Engineering
CER Cost Estimating Relationship
CM Configuration Management
COTS Commercial Off The Shelf
CSP Constraint Satisfaction Problem
DARPA Defense Advanced Research Projects Agency
DART Demonstration for Autonomous Rendezvous Technology
DES Discrete Event Simulator
DFM Design For Manufacturability
DFT Design For Test
DLR German Aerospace Center
DMCO Distributed Multidisciplinary Concurrent Optimization
DoD Depth of Discharge
DOD Department of Defense
DSS Distributed Satellite Systems
EELV Evolved Expendable Launch Vehicles
ELaNa Educational Launch of Nanosatellites
EOL End of Life
EOS Earth Observing Satellites
EPS Electrical Power System
ERO Embedded Real Options
ESA European Space Agency
ESPA EELV Secondary Payload Adapter
xx
F6 Future, Fast, Flexible, Fractionated, Free-Flying Spacecraft united by Information
eXchange
FBC Faster Better Cheaper
FDK F6 Developer’s Kit
GAO Government Accountability Office
GEO Geosynchronous Orbit
GNC Guidance, Navigation and Control
GPS Global Positioning System
GUI Graphical User Interface
HEO Highly Elliptical Orbit
HIL Hardware-in-the-Loop
HoQ House of Quality
HTML HyperText Markup Language
ICD Interface Control Document
ISI Information Sciences Institute
ISRO Indian Space Research Organisation
ISS International Space Station
ITAR International Traffic in Arms Regulations
JAXA Japan Aerospace Exploration Agency
JHU-APL Johns Hopkins University Applied Physics Laboratory
JPL Jet Propulsion Laboratory
KADS Knowledge Acquisition and Document Sharing
KBS Knowledge-Based Systems
kg kilogram
km kilometer
LAO Lorentz-Actuated Orbit
LCROSS Lunar Crater Observation and Sensing Satellite
LEO Low Earth Orbit
LEP Lottery Equivalent Probability
M&S Modeling and Simulation
MATE Multi-Attribute Tradespace Exploration
MCDM/A Multi-Criteria Decision Making/Analysis
MDO Multidisciplinary Design Optimization or Multi-Disciplinary Optimization
MOO Multi-Objective Optimization
OOS On-Orbit Servicing
ORS Operationally Responsive Space
ORU Orbital Replaceable Unit
OSD Office of the Secretary of Defense
MATE Multi-Attribute Tradespace Exploration
MAUT /A Multi-Attribute Utility Theory/Analysis
MDOO Multi-Disciplinary and Objective Optimization
MEO Medium Earth Orbit
MIT Massachusetts Institute of Technology
NASA National Aeronautics and Space Administration
NICM NASA Instrument Cost Model
NPV Net Present Value
xxi
NRE Non-Recurring Engineering
NRL Naval Research Laboratory
PIN Parameter Influence Net
PIVOT Pleiades Innovative VCDM Optimization Tool
PnP Plug-n-Play
PnPSat Plug-n-Play Satellite
P-POD Poly-PicoSatellite Orbital Deployer
POD Payload Orbital Delivery system
QFD Quality Function Deployment
RAFTIMATE Risk Adjusted, Flexible, Time Integrated, Free-Flying, Multi-Attribute
Tradespace Exploration
RASCAL Rapid/Responsive Access, Small Cargo, Affordable Launch
RE Recurring Engineering
RF Radio Frequency
RINGS Resonant Inductive Near-field Generation System
ROM Rough Order of Magnitude
RRM Robotic Refueling Mission
SA Systems Architecting
SAMS Space Assembly, Maintenance and Servicing
SATCOM Satellite Communications
SE Systems Engineering
SeeMe Space Enabled Effects for Military Engagements
SMAD Space Mission Analysis and Design
SMAD Spacecraft Modular Architecture Design
SMC Space and Missile Systems Center
SMC/XR Space and Missile Systems Center Development Planning Directorate
SoC State of Charge
SPA Space Plug-n-Play Avionics
SPA-S,-U Space Plug-n-Play Avionics Spacewire, USB
SPIDR System Portal for Integrated Design in Real-time
SSCM Small Satellite Cost Model
SSDM Small Satellite Design Model
SSPS Spaceflight Secondary Payload System
STP Space Test Program
SVM System Value Modeling
SWaP Size, Weight and Performance
SWORDS Soldier-Warfighter Operationally Responsive Deployer for Space
SysML Systems Modeling Language
TCS Thermal Control System
TRL Technology Readiness Level
TT&C Telemetry, Tracking and Command
UAV Unmanned Aerial Vehicle
USAF United States Air Force
USC University of Southern California
V&V Verification and Validation
VBA Value-Based Acquisition
xxii
VCAD Value-Centric Architecture and Design
VCDM Value-Centric Design Methodologies
XML eXtensible Markup Language
xTEDS eXtensible Transducer Electronic Data Sheet
1
Chapter 1
Introduction
Satellites provide a range of valuable services, from national security, to communications, to
scientific advancement. Maintaining the ability to efficiently design and deploy resilient space
systems is critical. But as budgetary and political environments become increasingly constrained,
engineers and decision makers remain challenged to cost-effectively deploy cutting edge
capabilities. Coupled with the inevitability of programmatic and technical uncertainties, from
funding fluctuations to on-orbit failures, these concerns have led to a growing desire for new
approaches, including cost reduction, non-traditional methodologies, and adaptable space
systems.
Although the state of the art in deployed space systems has steadily advanced, innovations in the
computer-aided design and optimization tools that are employed to realize them have been
comparatively modest. Existing tools still generally rely on conventional approaches, such as
slow, iterative procedural design, and assumptions of high-cost and high performance. These
approaches are inadequate for both traditional systems and for innovative, next-generation
systems. To improve the ingrained space system design process and to demonstrate the
opportunities offered by non-traditional architectures, a flexible and powerful design and
analysis environment is needed. The purpose of this research is to develop and investigate the
2
effectiveness of a declarative, as opposed to procedural, approach for the search, design,
evaluation and optimization of both traditional space systems (e.g. monolithic spacecraft and
small satellites) and non-traditional space systems (e.g. CubeSats, fractionated architectures, and
other adaptable systems).
1.1 Motivation
We have come to rely on space assets for a myriad of services, including weather, defense,
intelligence, communications, entertainment, navigation, science, Earth monitoring, cargo
tracking, international relations, and exploration. New and potentially valuable possibilities are
on the horizon as well, including colonization, space tourism, and resource utilization (e.g. solar
power satellites, asteroid mining, and He3 from lunar regolith) [262]. The success of these
systems is indicative of great engineering achievement within the short span of the space age.
However, the methods we use to design and deploy these systems have not fundamentally
changed from those developed over fifty years ago, and the cost of producing spacecraft remains
enormously high. This renders spaceborne assets highly vulnerable to failures, cancellations, and
hostile events. Considering the rate at which the rest of the world continues to advance their
activity in space [174], critics of the U.S. space program have referred to it as the nation’s
“Achilles heel” [79,144].
A 2001 report by the Commission to Assess United States National Security Space Management
and Organization concluded that the U.S. has an “urgent interest in promoting and protecting the
peaceful use of space and in developing the technologies and operational capabilities that its
3
objectives in space will require”. The report urged that a focus on the long-term goals of national
security space activities is critical in large part because of the dynamic and evolving security
environment that we face. To the U.S. Government, successful promotion of the peaceful use of
outer space includes the ability to deter and defend against hostile acts directed at U.S. space
assets. To achieve this, the report stressed that decision makers must invest in technologies that
enable the fielding of systems that are one generation ahead of what is available commercially
and what is produced by international competitors [287].
The existence of dependable design, modeling, analysis and evaluation tools is critical in
realizing systems that are both capable and reliable yet also cost-effective. Resources for the
development and maintenance of space systems are increasingly constrained, engendering an
acute need to “wring out” every last drop of a program’s budget. The ability to perform
exhaustive analysis of a system’s design tradespace helps ensure that all available options are
being accurately evaluated, and that no potentially better alternatives are being neglected or
dismissed. However, this is a difficult task in space system design. The disparate subsystems and
components of a satellite are both individually complex and highly interrelated, and the system
design needs to be highly optimized and reliable. In addition, space vehicles must be capable of
operating in harsh and unpredictable environments, making the inclusion of simulation,
verification and analysis early in the development cycle important. Space system design is best
characterized as a mixed continuous/discrete optimization problem, and generally exhibits a
design space that is non-convex (multi-modal) and nebulous. As such, traditional numerical
optimization techniques are not well-suited to this problem. Heuristics-based methods have been
used with success, but these techniques are only able to provide good solutions, not optimal
solutions.
4
A declarative approach has the potential to overcome these limitations, as it allows engineers to
model complicated systems with compact, modular expressions; optimize “in the loop” without
iteration; and perform rapid, comprehensive search of large tradespaces, generating provably
optimal results. It also achieves automatic propagation of the interdependencies and ripple
effects between subsystems, making global (system-level) implications of any local (subsystem-
level) design choices easier to ascertain in real-time.
Deploying adaptable space systems to reduce cost or increase value is another emerging concept
that is gaining traction. Adaptable architectures offer to impart value to a system in new and
different ways, such as through increased survivability, robustness, flexibility, etc. For example,
fractionation entails disaggregating assets to achieve mission-level reliability or ingressing assets
into existing orbiting clusters to share networked resources [291,293]. In cellularized systems, a
cellular design morphology is used to decompose a satellite into an aggregation of homogeneous
building blocks [295]. Or through the use of on-orbit servicing, space-based assets can rely on an
orbiting infrastructure to perform maintenance or life extension. In the current risk-averse space
culture, being able to computationally demonstrate the feasibility and business case for such
conceptual architectures is important.
To do this, a flexible design and analysis environment is needed that can handle the
fundamentally different architecture possibilities that adaptable space systems present. Again,
however, existing tools are not adequate for modeling such complex systems or traversing the
large tradespaces they imply. Since current design and analysis approaches generally employ a
procedural modeling approach, all candidate architectures must be explicitly enumerated a priori,
and the results must be iterated upon extensively. With architectures of unknown shape, size, and
morphology, it can be challenging and laborious to explicitly define all potential configurations.
5
A declarative approach can improve upon these limitations by requiring only implicit
instantiation of candidate architectures, i.e. the declaration of rules and constraints that apply to
the system and its environment. From this knowledge base, all feasible configurations can be
discovered dynamically by a reasoning engine.
While potentially advantageous for modeling both traditional and non-traditional space systems,
the declarative style of modeling is not yet widely used for design, especially in the space
engineering disciplines. A system modeled in the declarative style may be more readily
understandable than one written in the procedural approach [223], but the methodology used to
create it may be counter-intuitive to engineers who are well accustomed to modeling in the
traditional sense. An objective evaluation of the effectiveness of a declarative approach against
existing methods is thus required.
1.2 Dissertation Overview
Previous efforts at holistic satellite design have generally used procedural, iterative approaches.
Similarly, existing efforts at modeling and exploring tradespaces of non-traditional space
systems are limited in scope and rarely flexible or comprehensive. Thus the aim of this research
is to demonstrate the superiority of a declarative modeling approach over past efforts for the
design, optimization and tradespace exploration of traditional and non-traditional space system
architectures.
To this end, this dissertation is organized is as follows:
6
• Chapter 2 provides a background on the current state of space system development with
respect to growing cost and complexity and to the threats posed by uncertain futures; an
explanation of the resultant need for new approaches, including small satellites, CubeSats
and other adaptable space systems; and an overview of the declarative design approach.
• Chapter 3 describes the current state of space system design, including the decomposition
of the design process, modeling the design problem, selected decision-making
methodologies, optimization techniques, and value-centric design theory.
• Chapter 4 is an analysis of previous space system design approaches.
• Chapter 5 is an analysis of previous efforts to model and evaluate the feasibility of
fractionated space systems.
• Chapter 6 introduces the new declarative approach, which applies a constraint-based
methodology to the problem of designing and evaluating traditional and future space
system concepts. The constraint satisfaction and branch-and-bound optimization
techniques are described, and a background on the component database development is
provided.
• In Chapter 7, the new declarative approach is applied to the design of small satellites and
CubeSats, and validation of the declarative approach in the design of an actual flight
system is described.
• Chapter 8 describes the research performed on applying a declarative approach to the
exploration and evaluation of fractionated space architectures, wherein a Shared Space
Imager model is generated and explored.
• Chapter 9 presents the case study performed to assess the effectiveness of the new
declarative approach over past procedural approaches.
7
• Chapter 10 summarizes research observations and findings, identifies key contributions,
and proposes valuable avenues for future work.
1.3 Contributions
The primary contribution of this research is an improved methodology for the design and
optimization of space systems using a declarative modeling approach. This new approach offers
valuable improvements to the traditional satellite design process, as well as to the modeling and
tradespace exploration processes for non-traditional space systems. Using this new method, this
research also shows the potential for non-traditional space systems in enhancing value and
reducing the cost of next-generation space systems. The novel declarative approach is thus a
useful tool for stakeholders in developing and fielding space assets that are simultaneously
adaptable, reliable and cost-effective.
8
Chapter 2
Background
This chapter provides a background on the current space status quo, which is characterized by a
high cost, high complexity design culture, a growing threat of uncertainties, and the resultant
desire for a paradigm shift. Emerging approaches and solutions are reviewed, including existing
efforts at improved computer-aided design. Finally, a background on declarative modeling is
provided, explaining the potential advantages and known risks of this fundamentally new
approach.
2.1 Cost and Complexity Factors
The design of space systems is a notoriously labor-intensive, costly, and time-consuming
process. It is highly multi-disciplinary, involving several diverse and interdependent subsystems
that are each critical to mission success. While this is true of many complex engineering systems,
spaceborne systems are particularly onerous due to the high cost of launch. The exorbitant
launch cost per kilogram to orbit necessitates strict optimization of tightly coupled system
attributes and a high level of design confidence, since re-deploying in the case of failure is
9
generally not a readily available option [288]. In addition, the design process of space systems
differs from that of most other complex technical systems in that once the satellite is launched, it
is unreachable. Troubleshooting, debugging, rework and maintenance are virtually impossible
[188], and satellites remain the only complex engineering system that lack an infrastructure to
provide these services [205].
This slow, expensive culture of satellite development and acquisition to which we have become
accustomed has persisted in industry for years. The U.S. Government Accountability Office
(GAO) reported in 2009 that weapon systems development programs were overrun by 42% and
25% in development and production costs, respectively, and were behind schedule by an average
of 22 months [34,212]. A study in the same year by low-cost space access proponent Dr. James
Wertz looked at U.S. space activity and budget in the preceding 5 years. The study showed that
the U.S. launched 95 space missions in the half decade span, resulting in an associated average
cost of roughly $2.5 billion per mission [261]. To recount the hefty investment required to
deploy such a system, spacecraft design lifetimes continue to grow in order to generate more
total profit over time for a given system cost, resulting in a Space Spiral [262] (depicted in
Figure 1), or as some even refer to it, the “cost-complexity death spiral” [31].
10
Figure 1. The “Space Spiral” fuels increasing costs and longer schedules. Adapted from [262]
As Saleh et al point out in a Massachusetts Institute of Technology (MIT) study, design lifetime
has increased from 7 to 15 years since the 1980’s (due in part, albeit, to the emergence of better
hardware that makes life extension technically feasible, for example, nickel-cadmium batteries
and solid-state power amplifiers in place of traveling wave tubes) [205]. While at first glance this
seems logical and positive, the growth in a system’s physical size and operational complexity
that also accrue with this increased design lifetime likely induce a directly proportional effect on
the system’s price tag and cost of failure. Thus this tendency is potentially neutralizing or even
worsening the cost savings that is sought [39]. A broader consideration of factors beyond
technical feasibility would enable a more realistic representation of a system’s cost and utility as
a function of lifetime, for example ability to upgrade or replace obsolete technologies,
responsiveness to changes in the market or to customer needs, etc. Such capabilities are attributes
of adaptable space systems, and their consideration in space architecture design has increased in
recent years due to the appeal of being able to respond favorably in the face of uncertain events.
Demand
for
Higher
Reliability
Higher
Cost
Longer
Schedules,
Fewer
Missions
11
2.2 Uncertain Futures
Stakeholders in the space industry remain victim to a confluence of uncertainty in the technical
performance of their systems (due to an inability to easily or cost-effectively test and mitigate
these uncertainties), uncertainty about the environment in which these systems operate, and
uncertainty and fluctuation in the marketplace that exists for them. It is the goal of the value-
centric design paradigm to convince stakeholders of the worth of adaptable systems based on the
unpredictability of a system’s future given the wide range of potential unknowns, from the
technical to the programmatic.
2.2.1 Technical Failures
The challenges implied by spacecraft design have, in general, necessitated that these systems be
designed and built with a high degree of reliability and a trustworthy fault management system.
This has ingrained in space system developers an engineering mantra that “Good designs do not
fail” [168], as well as an acceptance of the price tag that accompanies this mindset. However,
historical analysis suggests that approximately one out of seven satellites do indeed fail before
End of Life (EOL), owing to an average 9% failure rate during operation and a 4-5% average
launch vehicle failure rate [227]. The space system development marketplace that has evolved, at
least in the US and in Europe, thus appears to accept the continuing escalation of costs for the
sake of reliability even though failures still invariably occur. Space programs such as Roscosmos
12
(Russia’s Federal Space Agency) and ISRO (India’s Space Research Organization) have
attempted to operate within lower budgets, but at the expense of increased failures [242].
Indeed, entire books chronicle the vast array of space system failures that have occurred and the
diverse reasons why, whether they are attributable to human engineering error or the natural
space environment [24,86]. Yet space programs continue to exhibit component, subsystem,
system, and launch failures, from the minor to the catastrophic. Some well-known examples
include Intelsat’s Galaxy 15 GEO satellite, which drifted 36 degrees in longitude over the course
of a nine month period after loss of telemetry and control, and then loss of autonomous control
[214], the Jet Propulsion Laboratory’s Mars Climate Orbiter failure, which was infamously
caused by incorrect use of units in its flight software [138], etc.
As our need for and reliance on reliable space systems has only further solidified over time, the
ability to characterize faults and failures is so critical it has practically become an art form.
However, in general engineers and decision makers continue to approach space system build in
the same way, i.e. a flat infrastructure of monolithic, massively expensive satellites. Regardless
of how much reliability we are able to instill into one singular system, it still by design has the
ability to manifest itself as a single point failure given the right unfortunate circumstances or
hostile adversary. Unfortunately, the cost of failure itself at some point becomes debilitating,
further contributing to a growth in cancelled programs and shunted capabilities. Thus we find
ourselves faced with an “ever-smaller number of both large companies and large programs that
we cannot afford” [261].
13
2.2.2 Market Uncertainties
While technical failures arising from endogenous issues and/or exogenous circumstances (i.e. the
operating environment) pose a clear threat to successful mission operation, the condition of the
political environment and marketplace play a critical role as well. A good example of the power
that market fluctuations have on a satellite program is seen in the development of communication
constellations in the early 1990’s to address then-projected cellular telephone and mobile satellite
service (MSS) markets.
Large-scale Low Earth Orbit communication satellite constellations like Iridium and Globalstar
began development in the early 1990’s (December 1990 and June 1991, respectively, based on
their initial applications to the Federal Communications Commission, or FCC) in response to
what appeared to be a promising combination of circumstances. First, projections for the U.S.
terrestrial cellular telephone market were very optimistic, with an expected 40 million
subscribers emerging by the year 2000. In addition, then-current technologies and infrastructure
for accommodating this demand were lacking - there were not yet any common terrestrial
standards in Europe (such as GSM, the Global System for Mobile communications) and cellular
network development there was modest. However, by the time these constellations were
deployed in 1998 and 2000, the market had transformed dramatically. The number of U.S.
terrestrial cellular subscribers had reached 110 million by the year 2000, almost three times the
forecasted number. Conversely, demand for MSS did not grow nearly as high as expected. Both
companies ultimately filed for bankruptcy (Iridium in August 1999 and Globalstar in February
2002), citing >$4 billion and $3.34 billion in debt, respectively. Clearly, the traditional approach
of designing costly systems for such demand-uncertain market is a risky undertaking [254,255].
14
In an analysis reviewed in more detail in section 0, a staged deployment approach to fielding
such a constellation is proposed. Such an approach would have enabled a more flexible design,
which would have enabled a dynamic response to the ultimate level of user demand, knowing
that it could end up being higher or lower than initially expected. However, as the authors of this
analysis succinctly explain, it is simply “difficult to convince designers to incorporate flexibility
when the requirement for it cannot absolutely be proven a priori” [255]. Therein lies a major
challenge in selling the concept of adaptability to stakeholders, regardless of historical horror
stories like Iridium and Globalstar.
2.2.3 On-Orbit Collisions
Space debris is another non-trivial problem in space operations today that only continues to
worsen. It is known to pose a serious risk to the reliable operation of spacecraft, and yet the
amount of debris is steadily growing as space “junk” is abandoned in Earth orbit (e.g. leave-
behind components, defunct satellites and spent rocket stages), spaceborne vehicles are
deliberately detonated (e.g. the Chinese test of a kinetic anti-satellite system, or ASAT, in 2007
[238]) and accidental collisions occur (such as the collision between the Iridium-33 and Kosmos-
2251 satellites in 2009, which at the time were active and retired, respectively). The ESA
estimates that more than 170 million pieces of junk currently exist in Earth orbit, including
29,000 pieces that are larger than 4 inches [40].
NASA Johnson Space Center scientists Kessler and Cour-Palais theorized in the 1970’s that on-
orbit collisions could cause a cascade, i.e. as the number of artificial satellites increases, the
15
probability of collisions increases, which create further debris as collisions occur, in turn causing
more and more collisions [111]. This “Kessler effect” or “Kessler Syndrome”, if not actively
mitigated, could someday lead to the existence of a “Debris Belt” in orbit, which would be
disastrous for the maintenance of an operable space infrastructure. The authors asserted that
eventually, the debris flux could become exponential, even if the net input rate is zero (an
important concern, since this should galvanize the case for mitigating or reducing the
contribution of debris, at least to match the rate at which it is being injected into the atmosphere,
if not more). Some models suggest that the Kessler effect is actually already happening now
[76].
Various mitigations have been enacted and solutions proposed, from deorbit requirement
regulations that must be followed before deployment to active removal methods after-the-fact.
Currently, NASA requires any newly fielded system to adhere to a requirement that it deorbits
within 25 years after final mission operation (or is relocated into a graveyard orbit) [296]. Some
proposed ideas for active removal include single capture missions such as Switzerland’s
CleanSpaceOne [119], Japan’s proposal to deploy an actual (very large) fishing net that could
sweep up debris [195], a fleet of small, solar powered, ElectroDynamic Debris Eliminator
(EDDE) satellites each equipped with nets [135,249], and a “Space Sweeper with Sling-Sat” (or
4S) which would utilize the momentum imparted by capturing and ejecting one object to
“slingshot” on to the next piece [50], among others. Other concepts look to increase drag in order
to hasten deorbit, for example through the injection of micron scale dust [179], focused pulses of
atmospheric gases [76], and ground- [83] and space-based lasers [272]. Economists Adilov et al
also proposed the adoption of a satellite launch tax that would incentivize “competitive firms to
choose the socially optimal level of launches” [3]. Until a successful mitigation or removal process
16
is enacted, it may be in the interest of space system stakeholders to fly systems that possess
increased robustness to the threat of debris.
The ability to maintain a defensive position in space is an area of interest to the US and other
nations for accidental (i.e. collision with debris) as well as deliberate (i.e. collision with a hostile
adversary [125], such as an ASAT or co-orbital intercept system as demonstrated by the Soviet
Union in the 70’s and 80’s [189]) events. A passive architectural solution is to disaggregate
monolithic spacecraft into separate, free-flying modules, such that debris-invoked failure of one
spacecraft only incrementally degrades the functionality of the system. Conversely, fractionating
high-value assets in space into clusters could enable the modules to actively maneuver out of the
way in order to prevent collision. Such a technique, often referred to as a scatter and re-gather or
“scatter-gather” maneuver, was one of four key capabilities to be performed in DARPA’s System
F6 on-orbit demonstration [291]. DARPA’s emphasis was the demonstration of a scatter-gather
maneuver to prevent collision with orbital debris, but also as a “defensive scatter,” presumably
alluding to the ability to defend against attack from a hostile adversary [293].
2.3 New Morphologies
The endemic creep of requirements and complexity, coupled with inevitable technical and
programmatic uncertainty, schedule slips and budgetary fluctuations, continues to feed cost
overruns, project delays, capability degradation and even program cancellations [125]. To
maintain a space infrastructure that reliably provides services for national security, science,
education, commerce and global presence, the inefficient status quo approach needs to evolve
17
[261]. A movement has emerged in the space industry that recognizes this need for a paradigm
shift, and various solutions have been explored.
The “faster, better, cheaper” (FBC) initiative was one of the first such responses [152].
Introduced in NASA in 1992, FBC called for space programs to strive for simultaneous
improvement in cost, schedule, and performance [251]. Sixteen NASA missions were born and
deployed over the eight-year span of the program, including four Earth-orbiting satellites, five
Mars missions, one to the moon, three space telescopes, two comet/asteroid rendezvous and one
ion propulsion demonstration (although the initiative was not necessarily restricted to NASA
alone). In the first seven years, nine of the ten FBC programs were a success, yielding
encouraging initial results. Then in 1999, the agency suffered five critical failures, totaling a final
success rate of ten out of sixteen, or 63%.
The failures that occurred during the FBC era, which included flagship-class missions such as
the Mars Climate Orbiter and Mars Polar Lander, were seen by many as a direct result of
management problems and insufficient funding that stemmed directly from the lean initiative
[286]. In particular, managers appeared to be cutting cost and schedule while neglecting to do the
same with program complexity. However, champions of FBC are more optimistic, and identify
the Near Earth Asteroid Rendezvous (NEAR) and Mars Pathfinder programs as indicators of the
program’s great success: these programs succeeded with price tags of $122 million instead of the
$200 million estimate, and 6.7% of the predecessor Viking Mars mission cost, respectively
[251].
Adaptable space systems offer another potential solution. Used in the context of describing space
systems, the term “adaptable” can take on a variety of meanings [203]. Indeed, many
18
frameworks exist which offer specific definitions for the varying flavors of value, or ilities, of a
space system based on the technical and/or non-technical benefits they enable. In this paper, the
term adaptable will be used generically to describe space systems that are designed to exhibit
some characteristic(s) that enhance or strengthen the singular mission(s) they are meant to
perform, i.e. some improvement in the value (quality, frequency, reliability, usability, robustness,
etc.) of data (images, bits-to-ground, etc.). In other words, a space system that offers increased
value in a non-traditional sense, e.g. through its flexibility, maneuverability, scalability,
survivability, resilience, etc., will be referred to as an “adaptable space system”. (Existing
definitions of ilities referenced in the literature, e.g. adaptability, flexibility, and robustness, are
presented in section 3.5.1.)
Adaptable systems have proven their worth in terrestrial contexts. Flexibility has emerged as a
key attribute in many disciplines, including planning, architecture, finance, manufacturing,
software design and others [203]. In commercial use, smart phones (e.g. the Apple iPhone,
Android) and tablets (e.g. the Apple iPad, Samsung Galaxy) represent a technology that can be
used in a wide variety of ways given the different applications (“apps”) that it can accommodate.
In military and defense, the B-52 bomber is considered an extraordinarily flexible engineering
system due to its almost century-long lifetime, even if this design trait may have been accidental
[88,203]. The UH-60/S-70 helicopter, originally designed for military purposes, now boasts
more than 35 derivatives that perform duties ranging from medical evacuation to VIP transport.
This was achieved because the baseline architecture was designed to accommodate changes
resulting from new customer requirements.
As for space systems, the Galileo spacecraft completed its original two-year Jovian mission in
1997 and then went on to successfully perform a completely new extended mission of two of the
19
planet's moons. This resilience and flexibility is owed in large part to the various margins that
were built into the spacecraft's original design [203].
A contrasting example is the Navy's first Littoral Combat Ship Freedom. A smaller and more
maneuverable approach to the traditional warship, Freedom was designed to cost-effectively
accommodate sophisticated robots that could carry out a suite of combat duties in various
contexts. However, the ship fell victim to a lack of clearly defined objectives, resulting in a
product that is “theoretically capable of almost anything, and increasingly optimized for nothing”
[15]. These examples aim to show that there is potential for the successful integration of
adaptable systems into space applications, but that the technology must be approached correctly
and implemented in a way that most reliably brings value into the system.
These new methods propose to rework some aspect of the design, test, integration, configuration,
launch and/or operation of a space system. While such evolutions occur more naturally in other
industries and domains, the space industry has yet to see large-scale changes. This is perhaps due
to the massive cultural inertia that has existed since the early days of space exploration, the
extremely narrow (but growing) market that exists for space-based products, or both [243].
The following sections describe five growing areas of new space system morphologies.
2.3.1 Small Satellites
The promulgation of small (100 to 500kg mass), micro- (10 to 100 kg mass), nano- (1 to 10 kg
mass) and pico- (0.1 to 1 kg mass) satellites [242] has increased dramatically in recent years in
20
response to the aforementioned high-performance, high reliability, high cost culture in space
1
.
Given their significantly smaller mass and volumetric envelope, these systems generally do not
require a dedicated launch. Thus, they can be launched via alternative methods, i.e. as a
secondary (or tertiary) payload on a vehicle with a larger primary payload, which provides
significant cost savings. These smaller, cheaper vehicles can achieve performance comparable to
that of larger crafts and offer a number of other benefits, including eased development,
integration and test processes, responsiveness to orbit, system-level redundancy via spares,
potential for deployment in constellations, robustness to change in market demands or
stakeholder needs, etc.
An example of a successful military small satellite program is the Operationally Responsive
Space (ORS) office’s TacSat program. The TacSat (Tactical Microsatellite) program [99] was
commissioned by the Office of the Secretary of Defense’s (OSD) Office of Force
Transformation (OFT) to demonstrate the ability of a series of small satellites to provide
performance comparable to that of a single larger spacecraft. Historically, a large spacecraft is
required for most tactical missions because it is traditionally seen as the only way to achieve
fielding of a large aperture [68]. However, the hope for smallsats within the military realm is that
if the price tag becomes sufficiently small (i.e. <$20M), they could become as attractive of assets
to military commanders as other airborne assets, such as unmanned aerial vehicles (UAVs). Four
TacSat systems have been completed, and all but the first successfully launched. A fifth is now
in the conceptual stages [55,256].
1
Except where explicitly specified, this study will use “small satellite” or “smallsat” interchangeably to encapsulate
all smaller classes of satellites (small, micro, nano, pico and femto)
21
At the extreme of the reduction spectrum is the concept of femto-satellites, which have a mass of
less than 100 grams and a footprint comparable to that of a cell phone [242]. The goal of femto-
sats is to accommodate all the functions of a satellite (command and data handling,
communications, attitude control, power, etc.) on a single chip, and achieve a desired level of
performance by deploying them in swarms [244]. The idea is being developed at the Polytechnic
University of Catalonia (UPC Barcelona Tech) [244] as well as by Morehead State University
Professor Bob Twiggs, co-pioneer of the CubeSat, in the PocketQub program [194,302]. A
similar effort is that of the “Spacecraft on a Chip” (SOC), in which all necessary spacecraft
subsystems (power, attitude control, communications, etc.) will be housed on a millimeter-scale
silicon microchip [13]. With this technology, a space system can be fielded as an orbiting
“swarm”.
One key advantage in fielding small satellites is the ability to incorporate commercial grade, or
COTS (Commercial Off The Shelf) components and subsystems. By allowing the use of
components not initially designed for or qualified for operation in the space environment [100],
designers are relieved of the constraint to consider only space qualified and heritage hardware,
yielding potentially massive cost reductions, and non-traditional vendors are provided the
opportunity to enter into the space industry. NASA’s recent PhoneSat and Edison missions
demonstrated ultra-low cost nanosats designed entirely around consumer smartphones [308].
Perhaps the largest catalyst of the use of COTS components is, however, the CubeSat initiative
(described in the following section).
However, the ability to secure a launch for small satellites is not yet an easy, or oftentimes even
feasible, task. Current launch costs for dedicated smallsat launch vehicles, such as the Orbital
Sciences Corporation’s Minotaur IV [309] and Pegasus [310], remain extremely high [99]. Most
22
often, smallsats are relegated to multi-manifested and secondary payload opportunities [41].
Although there has been progress in the growth of both dedicated and secondary launchers, the
lack of a strong market demand and the comparatively small profit that launch of small satellites
offers continues to plague launch vehicle providers. And while the idea of secondary launch is
attractive, the actual launch opportunities are few and far between. For example, SpaceX
cancelled its dedicated small sat launcher program, the Falcon 1/1e, after troubled success since
its inception in 2002 [64]. As the company’s Business Development Manager has stated, SpaceX
“had the Falcon 1 offered for a lengthy period of time and could not securely manifest a
sustainable amount to keep the product line going” [65]. Moreover, the probability that the
secondary payload will precisely reach its desired orbit is not guaranteed, as priority is given to
the primary payload.
SpaceX, the United Launch Alliance (ULA) and others offer rideshares for secondary (and
tertiary) payloads as well, but this can be a complicated approach A partially-failed Falcon 9
launch in 2012 caused the deorbit of its secondary payload Orbcomm satellite [147], which
resulted in SpaceX effectively discontinuing its secondary payload rideshare initiative.
Spaceflight Inc. announced in June 2012 that they signed an agreement with SpaceX to begin
manifesting secondary payloads on Falcon 9 flights starting in 2013, which would be via their
Spaceflight Secondary Payload System, or SSPS [303].
The SSPS is a ring-based turnkey system for faster integration of small satellites as secondary
payloads on intermediate vehicles [304]. The SSPS ring itself is developed by Moog CSA, the
manufacturer of the similar EELV (Evolved Expendable Launch Vehicle) Secondary Payload
Adapter (ESPA) ring, which launches on Atlas V’s and Delta IV’s [276]. However, the ESPA
has only actually flown once as a deployer of small satellites: its maiden voyage, the STP-1 in
23
2007. It also flew NASA’s Lunar Crater Observation and Sensing Satellite (LCROSS) mission in
2009, but it served as the craft’s actual structural bus on this mission [181].
Other programs that have emerged for nano- to small-satellite launch include: air-launched
rockets such as through DARPA’s RASCAL (Rapid/Responsive Access, Small Cargo,
Affordable Launch) [37] (cancelled in 2005 [289]) and ALASA (Airborne Launch Assist Space
Access) [277] programs, which awarded funds to Boeing Corp., Lockheed Martin, and Virgin
Galactic (for their also privately developed, White Knight Two-based LauncherOne [53]), as
well as three other companies for supporting research [260]; conventional launchers such as
ATK and Lockheed Martin’s Athena (cancelled in 2001, restarted in 2010 for military satellites,
and selected to become part of the U.S. Air Force’s Orbital/Suborbital small and medium space
lift program (OSP-3) in 2012) [42,166], Orbital Sciences Corporation’s Antares, also selected as
a candidate for the USAF OSP-3 [35,311], the U.S. Army’s SWORDS (Soldier-Warfighter
Operationally Responsive Deployer for Space) [278], and the Sprite launcher from the
Microcosm spinoff, Scorpius Space Launch Company [23,279]; and NASA-awarded Garvey
Spacecraft and Ventions for CubeSat and nanosatellite launch, i.e. for payloads with mass of 10
kg or less [260]. Non-conventional approaches such as NASA’s Towed Glider Air-Launch, for
launch of CubeSats via unmanned, autonomous gliders [248], electromagnetic railgun launch
[155], near-space balloon launch (e.g., used for the WikiSat program [242]), and others are being
researched as well.
The concept of hosted payloads, a more integrated form of rideshares, greatly facilitates access to
space as well [297]. A hosted payload rideshare is defined as the physical hosting of a payload,
such as an experimental Government sensor, onto a commercial satellite bus. This strategy
maximizes the launch capacity for the commercial satellite provider, who generally will have
24
some surplus in space and power, while allowing an inexpensive launch opportunity for a hosted
payload. As current launch costs can exceed $100 million (including fuel, engine manufacture,
and launch operations), this is an attractive approach for both parties even in spite of the obvious
compromises, such as integration costs and sharing of resources, pointing, orbit, etc. with the
host craft [217,218].
DARPA is exploring the idea of deployed or ejected hosted payloads as part of its Phoenix
program, where resources for on-orbit repurposing (e.g. satlets, tools, propellant) would be
delivered to orbit in a POD (Payload Orbital Delivery system) hosted by a commercial GEO
satellite, which could be ejected once the desired orbital location is reached [229,295]. The
deployed POD would then need to be captured by a robotic servicer and manipulated accordingly
in order to retrieve the packaged resources.
Interestingly, the inability of smallsat developers to obtain launch providers can also be viewed
as the converse problem, i.e. as an imbalance in the smallsat launch marketplace. Futron
Corporation, for example, asserts that supply for nano- to micro-sized spacecraft is actually high
(there are many emerging very-small satellite launch efforts), but demand remains low (the
profitability of and market for such satellites is still questionable) [41]. The market for small
satellite launchers has also been discussed in further detail by The Space Review [65].
Finally, as the proliferation of small satellites increases, the existence, or lack thereof, of a
market for their capabilities becomes an important question [63,230,242]. For some space-based
endeavors, the basic physics of the mission itself constrain the satellite bus to a certain size – for
example, to image something on the ground with a 0.3m resolution from a 500km orbital
altitude, a telescope mirror needs to be at least 1 meter in diameter, which is too large to be
25
hosted by any “very small” satellite (a collection of multiple satellites, however, could fly in
formation to form a virtual aperture or to act as a frame for a membrane mirror) [177].
In a 2006 study, Futron identified 30 markets for small satellites based on market feasibility and
existence of customer interest across four sectors: military, civil/commercial communications,
civil/commercial remote sensing, and other. Of the thirty, six “most promising” markets were
identified, including 1) Science and Technology and 2) Intelligence, Surveillance and
Reconnaissance (ISR) [in the Military sector]; 3) Polling of Unattended Sensors and 4) Remote
Site Communications [in the Civil/Commercial Communications sector]; and 5) High-resolution
Earth Observation and 6) Landsat-class Data for Environmental Modeling [in the
Civil/Commercial Remote Sensing sector]. Assuming an average satellite price of $7.5M per
year and a deployment rate of 39 – 76 satellites per year (total, across all six top markets), the
study calculated a potential revenue stream of $292.5 – 570M per year for these selected markets
alone [63]. A more recent 2013 study by SpaceWorks projected that 121 to 188 nano- to micro-
satellites (1 to 50 kg mass) would need launches by 2020 [98].
Recently, two commercial companies have emerged that demonstrate the somewhat newfound
willingness of private ventures to invest significant capital uniquely to small satellites: Skybox
Imaging and Planet Labs (self-proclaimed “purpose driven space company”). Both organizations
aim to field constellations of low-cost, high res imagers [66,207]. The Planet Labs approach is to
fly a CubeSat-class constellation of vehicles with minimal spaceflight heritage, achieving
resilience from the constellation size, i.e. it will be comprised of more satellites than the
minimum number necessary to provide global coverage [259]. Another company, Mapbox,
hopes to provide near-realtime satellite imagery within a six hour delay to its customers [91,149],
presumably from sources like these and other commercial entities.
26
2.3.2 CubeSats
The CubeSat, first developed by the California Polytechnic State University (CalPoly) and the
Space Systems Development Laboratory (SSDL) at Stanford University, is a new class of
pico/nano-satellite that offers standardized geometry and form factor, hardware, and launch
adaptor/orbit injection technology via the Poly Picosatellite Orbital Deployer (PPOD). The
PPOD is standardized deployment system that can eject several CubeSats at a time on a wide
range of launchers as secondary payload [185]. The standardized geometry and requirements are
conducive to lower cost and smaller schedule development projects, and the PPOD facilitates
more frequent launch opportunities. A single CubeSat, or a 1U, is a 10 x 10 x 10 cm cubic
structure. Configurations of two, three, six or more are also possible (i.e. a 2U, 3U, 6U, etc.), as
are fractional derivations, such as 1.5U.
Because of its dramatically lower price tag and quicker time-to-orbit, the CubeSat has become a
popular vehicle for student teams, who can develop them easily to gain real, hands-on experience
with satellite design, build and operation within the span of their academic careers. The CubeSat
has since expanded to the commercial world and even to the military and national security
realms, both domestically and abroad [185]. The advantages of CubeSats come not only from
their diminutive size, but also from the savings they reap via standardization. Standardized
interfaces, environments and requirements for launch enable vendors to much more easily
manufacture and sell components, which in turn can be hugely beneficial to the satellite design
process which otherwise requires the expenditure of significant time and resources on non-
recurring engineering (NRE), integration, and verification.
27
However, the standardized structure by nature limits the number of options available to the
spacecraft designer, and as the missions attempted with the CubeSat paradigm have increased in
complexity, the achievable performance and the optimality of the design both come into
question. In particular, the sacrifice of design freedom may not be justified by the benefit gained
(or at least according to traditional perceptions of optimality). The utility and applicability of
standardized components can quickly begin to decrease due to the propagation of implications of
a local design decision onto every other related subsystem: this high interdependency is a well-
known attribute of spacecraft. For example, the limitations on structural configuration due to the
highly constrained form factor end up limiting the possibilities for mission operations, attitude
control, communication link, thermal control, etc. [93].
Regardless of the potential markets that smallsats might enable, reducing the size of a satellite
unsurprisingly tends to produce an equal or similar degradation in its performance attributes, i.e.
resolution, data rate, agility, etc. [18]. Thus, while it achieves a reduction in cost, the smallsat
approach may not necessarily be a promising solution for achieving large-scale change in the
space industry. Other nascent non-traditional approaches include disaggregation; standardization,
modularity and reconfigurability; cellularization; on-orbit servicing and the vision for a “space
ecosystem”; and new design paradigms (or value-centric design).
2.3.3 Disaggregation
The concept of disaggregation, or decomposing the traditional notion of a monolithic satellite
into smaller, independent entities, has garnered significant discussion in the space industry
28
within the past decade. Many concepts have emerged which vary widely in implementation. In
Figure 2, a classification strategy is proposed that categorizes disaggregated systems by their
degree of homogeneity and level of physical connectedness. In this high level schema,
heterogeneous and free flying = fractionated, heterogeneous and connected = modular,
homogeneous and free flying = swarms/granular, homogeneous and attached = cellular.
Figure 2. Concepts of disaggregation
While “disaggregation” can mean many things to many people, perhaps the most tangible and
easily implemented manifestations are architectures that favor smaller, less complex satellites,
hosted payloads, distributed sensors and assets, and incremental launch strategies. The
application of these concepts would not necessarily require a dramatic departure from the status
29
quo, yet they still offer the potential for cost reduction, responsiveness, reduced vulnerability and
improved resiliency. Because of this, the U.S. Air Force (USAF) and its Space and Missile
Systems Center’s Development Planning Directorate (SMC/XR) in particular have identified
distributed architectures as a potential game changing technology [312], with wide applicability
to missions from weather satellites [36] to Overhead Persistent Infrared (OPIR) [25]. A recent
white paper released by the USAF Space Command provides a detailed description of the new
strategy, and asserts that it is a key way for preserving the United States’ operational advantage
in space [79].
Fractionation generally refers to a more pure, literal interpretation of disaggregation. It implies
the physical separation of a spacecraft’s payload and support subsystems into free-flying,
wirelessly interconnected modules. This concept exhibits the enhanced resiliency and robustness
to vulnerability offered by disaggregated architectures, but also proposes the potential benefits of
resource sharing, cluster-level fault tolerance, decoupling of requirements, eased design and
integration processes, ability to defensively maneuver, and responsiveness to orbit, to name a
few. While less palatable to large stakeholders due to the low TRL (Technology Readiness
Level) of the general concept as well as some of the specific enabling technologies (e.g. wireless
power transfer), the idea of fractionation has gained significant momentum in academic and
research communities.
Perhaps the most extreme implementation of a disaggregated space system is that of granular
spacecraft, which are “complex multibody systems composed of a spatially disordered
distribution of a large number of elements, for instance a cloud of N grains in orbit”, where
N>10
3
, as described by Quadrelli et al [186]. Granular matter, considered to be the fifth state of
matter (after solid, liquid, gaseous and plasma), can potentially be designed and controlled in
30
such a way that it exhibits some desirable collective behavior. An example application used by
the authors is a primary aperture in a spaceborne optical imaging system that is essentially a
cloud of grains instead of a monolithic aperture. The primary advantage of deploying a granular
system is that the aperture size could be several times greater than the maximum size achievable
by a continuous, monolithic aperture, thus enabling astrophysical advances such as the resolution
of exo-planet details and spectroscopy of very distant objects. Presently, however, very little is
known about the dynamics and controllability of granular matter, thus prompting the authors to
propose a model of the multi-scale grain and grain cloud dynamics, as well as a suggested
control approach. Although still in the early stages, the success of such an endeavor would
demonstrate the achievement of the intriguing but purely “philosophically satisfying” concept of
a spacecraft comprised of a cloud of microstructural components, or “pixie dust”, as first
introduced by Brown, Eremenko and Roberts in 2006 [30].
As described by Atchison and Peck [13], a fully integrated “Spacecraft on a Chip” (SOC) is also
currently in development. Such a “spacecraft” would be housed on a single millimeter-scale
silicon microchip, and would contain all the necessary spacecraft subsystems (power, attitude
control, communications, etc.). The SOC would rely on transmission of RF (radio frequency)
beacon signals to the ground for ground-based obit determination, would generate power from
solar cells, and would operate a microchip payload. A number of advantages for such extreme
miniaturization are suggested, including savings in rocket fuel due to lower launch mass, high-
volume, low-cost production that is enabled by manufacturing processes for silicon technology,
and the ability to deploy swarms of SOCs that can perform distributed sensing with high
redundancy. Perhaps most importantly, however, is that the on-orbit forces usually ignored due
to the relatively slow perturbations they enact on larger craft would now serve as a source of
31
infinite specific-impulse propellantless propulsion. The authors describe their research on the
promise of this Lorentz force actuation for SOC, which utilizes the magnetic field from a rotating
planetary object to transfer energy and momentum to a spacecraft’s orbit, resulting in a Lorentz-
augmented orbit (LAO).
A follow-on concept, the Sprite, is now being developed at Cornell University as part of their
KickSat program (whose funding source is KickStarter.com) [180]. The Sprite is a computer
chip equipped with a gyroscope, radio transceiver, microcontroller, magnetometer, and solar
cells. The KickSat goal is to launch 128 of the chips in a CubeSat, which would then deploy into
a swarm, to demonstrate the potential for monitoring of the space environment with these ultra-
small “nano-nanosatellites” [194].
Another emerging idea is that of cellularization. This concept proposes the decomposition of a
satellite into elemental building blocks that alone provide only a small fraction of necessary
performance, but can be aggregated to achieve any desired level of operation. A cellularized
satellite, whose constituents are sometimes referred to as “satlets” [21], could either be statically
integrated on the ground or could be dynamically configured and reconfigured on-orbit
2
.
Advantages of cellularization include rapid integration and test, flexibility to a wide range of
missions and payloads, and the ability to include components with diminished reliability, since a
system comprised of a large number of cells can withstand failure of some of its constituents
without experiencing system failure or drastic performance degradation. This principle is drawn
from its biological analogy, in which the death of a small number of cells in a biological system
does not severely threaten the ability of the system itself to continue functioning [18]. This
2
Reconfigurable, modular satellites is an area of research in the AAReST program at Surrey Satellite
Technology/CalTech [247] and in the German iBOSS program [257]. Although fundamentally similar to the concept
of cellularization, these projects emphasize modularity for the sake of on-orbit servicing, and are thus discussed in
the following section.
32
ability to consider lower fidelity components imparts obvious cost savings and also opens the
door for a much larger pool of vendors, lowering the barrier to entry for manufacturing in the
space industry.
DARPA has begun research and development of cellularized satellites, or “satlets”, through its
Phoenix program, which entails the robotic harvesting and repurposing of usable components
from retired satellites on-orbit [259]. The objective of the program is to physically remove
salvageable parts from otherwise non-functional satellites, i.e. large apertures or antennas, and
use them to build new systems in space via the integration of satlets that comprise the remainder
of the necessary spacecraft subsystems. The Phoenix program sees satlets as a key enabler of the
Phoenix mission, but also as a potentially paradigm-shifting approach to the development of any
space system. Barnhart et al investigated the potential market for and impact of satlets on the
space industry, and found that the satlet methodology can impart greatly improved reliability to a
space system [18]. Table 1 summarizes the six research and development efforts being
performed on cellularized satlets in the Phoenix program [21].
Table 1. DARPA Phoenix satlet efforts to date. Adapted from [21]
Organization Key Advancements
Aurora Flight Sciences Modularized, Aggregatable Satlets for Repurposing Retired
Assets [110]
Busek Space Propulsion and
Systems
Electrospray Propulsion for Satlets
The Charles Stark Draper
Laboratory, Inc.
ADCS and Momentum Management employing Zero Propellant
Maneuvers (ZPM) technology
Intentional Software
Corporation
Integrated Systems Health Management (ISHM) for satlets
NovaWurks Hyper-Integrated (HISat) System [102]
SRI International Electrostatic adhesion for inter-satlet contact interfaces
33
Jaeger and Mirczak describe development of a Hyper-Integrated Satlet, or HISat [102], which is
a homogeneous building block satellite that can be aggregated to achieve the required
performance, imparting rapid scalability and robustness into a system. They suggest that this
approach, which differs from the heterogeneous approach in which “subsystem satlets” are
created, is preferable if certain design and development challenges can be surmounted. While the
heterogeneous approach is more traditional and likely results in greater Size, Weight, and Power
(SWaP) efficiency, a “tipping point” is thought to exist with the homogeneous approach that
would bring value in resource capability and economy. As such, the authors suggest a new
satellite morphology based on a cellular architecture (comprised of HISats) that has breakthrough
potential for lowering costs in space systems.
Conversely, Kerzhner et al posit that optimally designed, specialized satlet variants (i.e.
heterogeneous satlets) offer the best solution for cellularized architectures [110]. In their study,
they perform model-based tradespace exploration using the Systems Modeling Language
(SysML) to arrive at the optimal degree of heterogeneity/homogeneity in satlet design, which
drives recommended hardware selections.
Furthermore, decomposing a single, custom-designed, and expensive system into an aggregation
of many smaller, identical parts enables the building block components themselves to be mass-
produced. The cost reduction made possible by high volume manufacturing is significant, both in
eased testing requirements and in the efficiencies of a production line-like environment, and is
heretofore essentially unheard of in the space industry. Finally, there are many benefits to the
adoption of standardized interfaces and components, which would certainly be an integral aspect
of a successful cellularization paradigm. These are discussed further in the next section.
34
2.3.4 Standardization, Modularity and Reconfigurability
Standardization is a commonly accepted approach for reducing the engineering resources
required to deploy a product. It has been successfully employed in military domains, such as
aircraft and communication electronics equipment [190], as well as in more ubiquitous,
terrestrial applications, for example cell phone power adapters. Standardization is closely
interrelated with modularity, as the standardization of interfaces and behavior is what allows
disparate components to be employed in a modular fashion.
A modular architecture is one in which a system’s constituent pieces are made to be easily
swapped out or changed with others via the use of standardized interfaces and known
performance (e.g. software). For many applications, this implies that the system’s parts can be
rearranged in order for it to perform some number of different tasks. Modular systems offer
improved responsiveness compared to traditional systems due to savings in design, analysis,
verification and validation (V&V), and integration time (however they also require increased
testing up front), and they boast more flexibility ability to optimize compared to purely
standardized systems (where the gains in responsiveness come with the price of greater
inefficiencies and sub-optimality) [43]. Increased modularity also has the potential to make the
concepts of on-orbit servicing and maintenance much more achievable, as discussed by Weise et
al in Germany [257], Guariniello and Delaurentis in the United States [80], and others.
Modularity offers advantages for lunar and planetary exploration missions as well. Smith of
SPACEHAB, Inc. asserts that a modular design philosophy will be essential in fielding such
futuristic missions, in particular lunar colonies and other surface habitats, because of the
35
advantages this approach imparts to reducing cost, improving performance, and ensuring the
safety of exploration crews. Using the traditional “point-solution” approach would prevent such
missions from being able to adapt to dynamic changes and failures [220]. NASA’s recently
launched LADEE moon mission spacecraft is also touted to be based on a modular architecture
[121]. The $280 million LADEE spacecraft was designed with a generalized approach, and
created from a series of general-purpose modules that can be mixed and matched to comprise a
system that is applicable towards a wide number of space missions.
The Air Force Research Laboratory (AFRL) Space Vehicle Directorate’s office of Operationally
Responsive Space (ORS) and others have pioneered research on “plug-n-play” (or PnP) space
systems [38,43,68,148,269]. The goal of the PnP effort is to demonstrate the capability to rapidly
assemble, integrate and test modular components and subsystems with standardized interfaces
within a very short timeframe, i.e. on the order of weeks, with the ultimate goal of a “six-day
spacecraft [68]” (from the time of mission call to launch). The ability to field an operational
system on such a short timeline provides a responsiveness to orbit that would prove invaluable
during time-critical tactical events, as current systems generally require five to ten years
development time [43].
In a 2006 study by Cohan et al, the authors performed a MATLAB simulation-based quantitative
analysis of two options for satellite bus standardization using the PnP approach: a monolithic
design and a modular architecture. Communications (in LEO and HEO) and optical (in LEO)
payloads were considered, and were represented parametrically by their mass, power, pointing
accuracy, and data rates. The analysis modeled the cost, efficiency, reliability, response time and
net present value of each configuration across a range of payloads in order to find the optimal
degree of modularity for a responsive satellite bus, taking into consideration the extra overhead,
36
cost, testing and lead time that such an approach entails [43]. The results indicated that out of the
32 possible combinations, the optimal configuration was comprised of approximately 60%
modular and 40% integrated subsystems.
The AFRL’s PnPSat-1 was set to launch on a Falcon-1 in 2008 but was not selected for final
integration [122]. The AFRL/University of New Mexico Trailblazer CubeSat program applied
the PnP techniques to CubeSat build [117], and was selected as one of twenty possible CubeSats
for NASA’s 2011 ELaNa (Educational Launch of Nanosatellites) program, part of the CubeSat
Launch Initiative (CSLI) [280], but it does not yet appear to have launched. Some SPA-U and
SPA-S technologies were tested and demonstrated on orbit in the AFRL’s Spacecraft Avionics
Experiment aboard TacSat-3 [148].
The concept of modularity is attractive to commercial endeavors as well. Remias et al explained
how commercial satellite constellation production of modularized buses leveraged to reduce
mission cost [90]. SNC’s SN-100 bus, initially developed for the Orbcomm Generation 2 (OG2)
constellation, was selected as the foundation for three testbed buses to fly in the DARPA System
F6 on-orbit demonstration.
Weise et al describe development of the intelligent Building blocks for On-orbit Satellite
Servicing (iBOSS) project, which seeks to decompose a conventional satellite bus into an
aggregation of numerous identical (by group), intelligent building blocks such that it can be
conducive to on-orbit robotic satellite servicing, in particular as a solution for maintenance of
space systems (e.g. replacing damaged components), life extension, and the resultant decrease in
orbital debris [257]. In this manifestation of modularity, each iBOSS standardized element or
fragmentation contains some subset of the necessary system components that comprise a
37
spacecraft, for example a structural building block or a system building block (models of which
are shown in Figure 3 and Figure 4), but at a fractional level. In this way, a satellite is produced
by assembling a large number of these very small building blocks (a la the well-known LEGO®
toy [313]), as opposed to the traditional method in which a small number of large, singular
components are integrated together in a much more custom approach.
Figure 3. iBOSS structural building block [257]
38
Figure 4. iBOSS system building block [257]
Intelligent software concepts are also being developed to equip the modularized satellite with the
autonomy necessary to govern the fragmented constituents. To mirror the modular hardware
architecture, a distributed, data-centric software framework is employed that enables flexible
distribution and management of the individual software modules, as well as control of each
building block. The result is a publish-subscribe style software architecture that allows each
software module to be agnostic to the specific building block in which it resides and to the
computational unit on which it runs.
These components, which can be much more readily assembled and disassembled than can
traditional heterogeneous spacecraft parts, engender a system that can be much more easily
accessed and manipulated by a robotic servicer (as depicted in Figure 5). The authors also
39
describe a computer-aided satellite design tool in development that governs the modeling and
optimization of an iBOSS-built satellite (see section for further discussion).
Figure 5. Artist's depiction of an iBOSS spacecraft and servicer on-orbit [18].
The AAReST (Autonomous Assembly of a Reconfigurable Space Telescope) program aims to
achieve autonomous assembly of a modularized system on-orbit [247]. AAReST, a joint effort
out of the Surrey Space Center (SSC) and CalTech/NASA JPL, will be a next generation space
telescope in which reconfigurable mirror elements assemble autonomously on-orbit to form a
large aperture. A technology demonstration flight mission is planned for 2015. If successful,
autonomous reconfigurability could enable space-based telescopes with primary optics greater
than 20 meters in diameter, allowing imaging far greater than anything we can currently achieve
40
with monolithic optics due to the physical constraints of launch vehicle fairings (for reference,
the diameter of the primary mirror on the Hubble Space Telescope is 2.4 m [18]).
2.3.5 Space Ecosystem
The existence of infrastructure support and on-orbit robotic servicing for spaceborne assets,
which would enable lower cost and adaptable systems to be deployed [120], could enable a new
space “ecosystem”. On-orbit servicing (OOS) is being explored at various levels in the space
industry, from the successful refueling and maintenance techniques demonstrated in DARPA’s
Orbital Express, NASA’s Robotic Refueling Mission, and other programs, to commercial
ventures like MDA’s Space Infrastructure Services (SIS) refueling vehicle [213] and
ATK/ViviSat’s physical-dock life extension program [95], both of which seek to create a
business for on-orbit life extension of high value GEO assets [20], to the repurposing of
apertures or other resources on retired satellites to achieve new capabilities in space altogether
[295]. Proponents claim that the potential market for on-orbit servicing could reach $3-5M per
year [227].
OOS encompasses a range of in-situ services [105]: orbit modification via space “tugs” [71],
assembly, maintenance (including upgrades and repair) and/or consumable replenishment of
operating satellites [250], especially fueling via servicers [161] and/or in-space fuel depots [47],
and most recently, harvest of valuable components from retired GEO satellites [295]. From a
customer perspective, this type of service could provide such desirable attributes as life
41
extension, capacity upgrade, and modification to meet new mission goals or market demands
[129].
According to Waltz's definition [250], servicing encompasses 1) assembly, 2) corrective and
preventative maintenance and 3) replenishment of consumables and expendables. Lamassoure
[129] provides a different classification that is from the customer's perspective. It consists of 1)
life extension, 2) upgrade of operational capacity to meet original goals and 3) modification of
the system to meet new goals. Saleh provides one further level of bifurcation: servicing can be
either on demand or on a scheduled basis [205]. In order to constrain the cost and resource
considerations for servicing, Reynerson offers the definition of a serviceable craft as “any
spacecraft for which the benefits of on-orbit servicing outweigh the associated cost” [190]. A
few of the most significant servicing events to date include the Skylab missions, the Solar
Maximum Mission (SMM) spacecraft, the booster attachment and re-launch of the Intelsat 6
satellite and the Hubble Space Telescope.
Numerous studies have been performed on the design and characteristics of a space-based
servicing infrastructure. The 1988 Space Assembly, Maintenance and Servicing (SAMS) study
done by the Air Force, the Strategic Defense Initiative Office and NASA is perhaps the most
extensive to date [284]. SAMS studied five design reference missions and derived the program
requirements, hardware and space/ground infrastructure necessary to support it. The resultant
architecture included a servicing facility at the space station, a reusable orbit transfer vehicle, a
remotely piloted orbital maneuvering vehicle that can carry the servicer and spare modules, an
on-orbit fuel storage facility, a propellant transfer system, a tele-operated servicer and a crewed
orbital transfer module. However, assumptions of routine, inexpensive access to space and a
significant human presence in space were critical to the study’s servicing model, causing it to be
42
perceived as less than realistic or cost-ineffective. Subsequent studies have shifted from the high-
cost, crewed infrastructure to low-cost robotic missions, for example the Spacecraft Modular
Architecture Design (SMAD) and global positioning system (GPS) servicing studies.
The SMAD study, performed in 1996 by the U.S. Naval Research Laboratory, examined low-
cost robotic servicing of a 10-satellite remote sensing LEO constellation [190]. The servicer was
designed to replenish consumables and degradables, replace failed functionality and integrate
new technology, where all replacements are done “functionally” and not physically, i.e., the
replacement parts reside on a single payload module that attaches to a docking interface on the
client satellite. Costs were evaluated for the development of the servicer, the necessary redesign
of the constellation satellites to make them serviceable as well as lifecycle costs of several on-
orbit scenarios. The study demonstrated cost savings from 10.3 to 38.2% depending on the
length of the life extension [205].
Leisman et al [134] and Hall and Papadopoulos [85] investigated servicing of the GPS
constellation. The first study was aimed at identifying the most responsive (i.e. shortest cycle
time) and still minimum-cost solutions to the logistical support needs of the GPS constellation,
mainly upgrade. The architectures considered varied in number of servicers per orbital plane,
propulsion type and mass delivery capacity. The authors concluded that the on-orbit servicing
approach did in fact offer greater benefits and a lower cost than the current paradigm, which
assumes two replacements per year. While current methods cost approximately $100 million to
replace one satellite, the most expensive servicing architecture could upgrade the entire
constellation for $60 million per satellite. Hall and Papadopoulos examined the structural
modifications necessary to make the GPS satellites serviceable. They concluded that an
43
additional 3-15% mass would be required, however they did not consider any subsystem level
modifications.
Saleh performed an investigation that valued a servicing architecture using Decision Tree
Analysis (DTA) and real option theory (for further detail on real options, the reader is directed to
section 3.5) [205] . Servicing is generally studied from the service provider's perspective and
focuses on the architectural costs of servicing one satellite constellation. In reality, the cost of the
architecture could be amortized over several missions, and not necessarily one event or
customer. Saleh calculated this flexibility value from the customer’s perspective, considering
both “non-profit” customers, for whom the value was derived via a cost-equivalence principle, as
well as “for-profit" customers, using a variant of the Black-Scholes equation from real option
theory.
McVey et al investigated feasibility of GEO servicing architectures using a valuation framework
that looked at both the client’s and the provider’s value [156]. In this study, the design process is
approached from the customer’s perspective instead of the servicer’s perspective in order to
arrive at a value for the optimization metric from a different direction [156,205]. In this way,
instead of searching for the most cost-optimal design (i.e. the lower limit on the cost variable) of
a servicing system using CERs, the minimum price that a customer would pay for the system is
sought, thus defining an upper limit on the cost of the system.
Richards et al developed an agent-based model to assess a multi-year GEO servicing campaign
as a multi-variable optimization problem in order to evaluate the amenability of satellites to OOS
[191].
44
The University of Maryland Space Systems Laboratory has extensively researched servicing,
especially with regards to methods for evaluating its technical and economic feasibility
[227,228]. Sullivan developed a comprehensive database of satellite characteristics and on-orbit
failures which he used to establish servicing markets via a new, expected-value-based servicing
method [226]. Ref. [226] also provides a comprehensive background on servicing studies. Later,
Sullivan and Barnhart analyzed the economics of repurposing existing, retired spacecraft in orbit
as an example of servicing [20].
Guariniello and Delaurentis of the Systems Engineering Research Center used Functional
Dependency Network Analysis (FDNA) to analyze on-orbit servicing and maintenance as a two-
level System of Systems [80]. FDNA was used to examine the key attributes, i.e. availability,
redundancy, and capability, from a Systems-of-Systems (SoS) perspective. The authors assert
that availability is not only a function of a component, but also of interactions with other
spacecraft and assets. Thus, a tool such as SoS tool is needed for these futuristic systems because
they are too complex and their scope is too broad for traditional Systems Engineering
approaches. The FDNA framework was originally proposed by Garvey and Pinto as a
deterministic method for evaluating a “capability portfolio”. This concept effectively represents
how the operability of certain systems is affected by the degradation of other systems.
Guariniello and Delaurentis focused on stochastic use of the tool, and utilizing it to help
determine the most critical elements (or nodes) in a system (or network). In the context of
servicing, multiple satellites may be used to achieve an overall objective, which an FDNA
network can model.
The authors examine a use case in which there are 30 satellites, with between 17 and 25 modules
per satellite, and 10 constellations (or “missions”), of which three are comprised of a singular
45
satellite. Certain assumptions were made, including that the servicers were always 100%
effective, they were not subject to failures, and the cost was modeled by deltaV only.
Robotic manipulators and servicing in space have extended to the domain of smallsats as well,
such as the four degree-of-freedom manipulator DYMAFLEX (DYnamic FLight MAnipulation
EXperiment) project currently in development as part of the USAF University Nanosat Program
(UNP). The University of Maryland (UMd) Space Systems Laboratory (SSL) recently proposed
an end-to-end flight demonstration of smallsat servicing technologies via the Smallsat Concept
for Advanced Manipulation and Proxops (SCAMP) program, which would leverage technologies
from DYMAFLEX as well as from their Exo-SPHERES project, which is an advanced modular
smallsat architecture jointly supported by DARPA and NASA [10].
2.4 Declarative Modeling
It is evident that a wide spectrum of non-traditional space system concepts is on the horizon.
Computationally demonstrating the value of these systems and navigating the expansive search
space they entail to identify optimal architectures is critical. While there is growing acceptance
of Value-Centric Design Methodologies (VCDM), which espouse the quantitative consideration
of enhanced “ilities” in a system (see section 3.5), few tools exist that can reliably employ them.
Existing computer-aided engineering tools for the design of such systems are lacking as well.
Current approaches embrace high-cost, high-performance, monolithic satellites that follow
conventional design morphologies. In general, these methodologies utilize procedural design
46
frameworks, which are slow, cumbersome and inaccurate. The use of a declarative modeling
approach offers many potential advantages over these methods.
In declarative programming, computational logic is defined without explicit definition of a
desired control flow or procedure. In other words, the language focuses on what the author wants
the program to do rather than precisely how to accomplish the task [223]. Similarly, the practice
of declarative modeling enables a system to be represented simply as a set of facts that are true
about it, while the order in which the facts are presented is irrelevant. A reasoning engine is used
to dynamically discover the end state based on the facts (or rules) that have been described about
the model, its environment, and its operations [298]. So, while procedural/imperative design calls
for the modeler to say “how to do something”, the declarative approach only requires an
indication of “what is required”, thus allowing the system to determine how to best achieve it
[182,200]. Spreadsheets are sometimes used in the literature as a simplistic example of a
declarative visual language [123].
Touted advantages of the declarative approach are the improved ability to write, maintain, and
change code, increased reliability due to more concise capture of the desired model or task (i.e.
shorter code) [223], and, importantly, greater flexibility than is found in the procedural approach.
In addition, Kunstmann et al explain that in order to identify the solution to a complex problem,
it first must be defined roughly, then further specified through iterations of varying input values
and observation of the results. The use of a declarative approach aids designers in generating
complex models in this way, since it allows for a problem declaration to contain several degrees
of freedom, which can be refined and constrained in subsequent stages, and it ensures that at any
time, the problem declaration is considered to be in a consistent state [123]. Such attributes are
highly valuable in the context of spacecraft design, as they enable a flexible modeling
47
environment. These traits also offer consistency, since they would enable the continued
utilization of a singular modeling environment throughout a project’s lifecycle, from example
from conceptual to preliminary to detailed design.
Aiello et al first suggested in 1977 that a tendency towards a more declarative style was
emerging in the field of programming [7]. The authors described that the process of
programming consists of the specification of a series of actions to be performed in order to
achieve some end goal. In general, some static (or declarative) goal is formulated, and the
specific way in which this goal must be achieved is then specified using dynamic
(computational) concepts. However, if these dynamic concepts differ greatly from the
overarching static goal, a significant number of coding details must be put forth. It is this process
that leads to confusion and errors, including bugs and inefficiencies.
2.4.1 Constraint-based Reasoning
One manifestation of the declarative method is constraint propagation or constraint-based
reasoning. In the traditional procedural approach to developing a model or design space, every
existing execution alternative must be explicitly defined a priori. Such a requirement is time
consuming and limiting, and severely constrains the ability to navigate a tradespace when
massive combinatorics are involved. In contrast, a declarative model based on rules and
constraints can be thought of as a problem declaration that is made “top down”, or “outside-in”,
such that the initial tradespace is the exhaustive set of all feasible design choices, and the set of
48
solutions shrinks as constraints are added or enforced [182]. Tack succinctly describes the
advantage of solving problems with constraints [232]:
The success (and the beauty) of constraint programming is due to the clear separation
between model and solver: The problem is stated declaratively, in terms of variables and
constraints, modeling real-world objects and the relations the objects are engaged in.
Then, this high-level model is passed to a constraint solver, which, given enough time,
will return a solution to the problem.
Friedman provided a detailed overview of constraint theory in 1976 in the context of determining
the consistency of mathematical models and the allowability of associated computations [67]. He
explains that a constraint is defined as the specification onto a variable that limits its range to
less than its full allowable set. An intrinsic constraint is one that arises internally from the
mathematical model, while an extrinsic constraint is one that is imposed onto the model from
some external source. To illustrate this concept, consider the following simple example:
∝:𝑥=𝑦
!
(1)
Friedman explains that the relation α places an intrinsic constraint on x because it limits it to
x≥0 (i.e. it shrinks the domain of x to [0, ∞]), but it places no constraint on y. The relation β
places no constraint on x or y (assuming their interval domains are equal).
𝛽:𝑥=𝑦 (2)
Now, if the composite relation αβ is made, such that A
αβ
=A
α
∩
A
β
(or both relations have been
enacted in a model), an intrinsic constraint has been placed on both x and y since their allowable
sets have thus been shrunk to x = 1 and y = 1 [67]. Conversely, if a computational request, or
input specification, is placed on the variables (such as x = 3 and y = [3,9]), this qualifies as an
external constraint. Friedman emphasizes that the difference between a relation and a constraint
49
is non-trivial: consider the relation x + y + z = 0. Although this relation enacts restrictions on the
space (or domain) of the associated variables, they are not experiencing a constraint. This
distinction is important in the context of visualizing and interpreting models through graphs
(such as a bipartite graph), which is a key theme in Friedman’s paper [112].
There are few instances of a declarative method being applied to space systems. Constraint
satisfaction was used by Tsang and Cardonne for the preliminary design electronic equipment for
satellites in 1992 [245]. Plaunt et al presented the use of Dynamic Constraint Satisfaction
Problems (DCSP) for the dynamic scheduling and allocation of resources for communication
satellites in 1999 [183]. Kim and Xirouchakis applied CSP to the design of small satellites in a
simplified case study [118]. The declarative approach has been successfully deployed in other
engineering domains, for example in the optimal scheduling and degradation of Quality of
Service (QoS) in multi-media services (using the knapsack combinatorial optimization problem)
[162], in 3D architectural scene sketch modeling [54], and for business process modeling [182].
Constraint-based reasoning has been suggested for automated search and design optimization
[236] and as an evolution of CAD in mechanical design [141]. However, despite its clear
advantages, Friedman was correct in his concluding notation in reference [67] that “the ability of
Constraint Theory to fulfill its potential will depend not only on further theoretical work, but,
more importantly, on how widespread its usage will be”.
50
Chapter 3
Space System Design
A system is a set of different elements so connected or related as to perform a unique function
not performable by the elements alone. [154]
The design of a satellite is by nature a highly interactive process that requires the expertise of
several engineering disciplines. Achieving a successfully functioning system in space requires
that each of the independent subsystems perform properly on orbit, yet many if not all of a space
vehicle’s subsystems are also highly interdependent (in, unfortunately, both obvious and non-
obvious ways). Thus, the role of system engineering and the ability to track the
interdependencies of subsystems and components in space system design is equally as critical as
detailed subsystem design. In addition, many goals exist that a space system must strive to
simultaneously meet, including meeting the mission requirements, attaining a high payload to
spacecraft launch mass ratio, exhibiting high reliability, all at the lowest possible cost [87]. As a
result, methods for capturing, modeling, navigating, and optimizing the design trade space for
satellites has grown significantly, both for cross-discipline/systems engineering processes and for
high fidelity subsystem design.
51
3.1 The Design Process
The design process itself can be abstracted into a set of design tasks, systems and approaches.
Such abstractions ensure that the exploration of a design tradespace and delivery of a final
product is done systematically and effectively. Generally, a first step involves breaking down the
design process into phases and steps [27]. The lifecycle of an engineering system is typically
characterized as a set of phases ranging from identification of customer needs to definition,
design, production, operations, until final disposal or decommission [203]. NASA categorizes a
mission’s system engineering timeline into six major phases [262]:
1. Pre-Phase A: Concept Studies
2. Phase A: Concept & Technology Development
3. Phase B: Preliminary Design and Technology Completion
4. Phase C: Final Design and Fabrication
5. Phase D: System Assembly, Integration & Test, Launch
6. Phase E: Operations and Sustainment
These serially occurring phases mimic the traditional waterfall model [96,154], wherein each
phase can only commence once the previous one has achieved some defining milestone(s) that
give the design a “pass” to continue on. These are most often executed as design reviews such as
the System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design
Review (CDR), etc. (SMAD provides a list of 20 such reviews that exist in NASA’s human
space flight and robotic mission programs). Alternatives to this standard, black-and-white system
engineering methodology have also emerged, in particular the spiral model, which proposes a
52
development cycle where iterations occur on a shorter timescale thus allowing higher fidelity
knowledge of the soundness of a design to be ascertained early on. An example is the “build a
little, test a little, fly a little” ideology, wherein a program elects to begin integration and test of a
prototype system before the design is completely finalized. This approach is favored in faster
turnaround, lower cost, and university setting programs (such as the USC/ISI Space Engineering
Research Center [290]).
In either approach, the ultimate goal, as defined by the seminal Space Mission Analysis and
Design (SMAD) text [262], is to meet the broad objectives of a space mission in a timely manner
at minimum cost and risk (The “Need-Driven” Process). Other precepts do exist that challenge
this guideline, including design centered around existing or newly identified capabilities (The
“Capability-Driven” Process); Design-to-Cost, which focuses first on meeting a cost objective,
and secondarily on performance; and Value-Centric Design, which looks at designing for
enhanced value, even at the risk of increased cost (further discussion on Value-Centric Design is
provided in section 3.5). Furthermore, Design for Test (DFT) and Design for Manufacturability
(DFM) are examples of design methodologies that take into consideration the needs of other
lifecycle phases in parallel with the traditional design towards system requirements [197]. In the
former, the design process strives to achieve a system that exhibits high testability, or the
optimized ability of a design to support all envisioned verification, test environments and test
requirements” [145]. In the latter, a system is designed such that it can be produced efficiently
(with respect to both time and cost) and also maintain robustness towards any long-term,
dynamic variations in the processes or materials that are used to manufacture it [26,208]. Finally,
designing for complexity is an approach that looks to achieve better system designs by
considering a system’s level of “difficulty”, which is driven by such complicating factors as
53
customer needs, external constraints, and complexity that is acquired due to mitigating risks or
uncertainties that exist in satisfying the functional requirements [140].
The design phase itself is then generally broken down further into stages that are characterized
by the degree of design fidelity, i.e. conceptual design, then preliminary design, and finally
detailed design (or critical/formal design). The design, or mission engineering, process for a
space system as defined by SMAD (assuming a need-driven mission) is characterized by four
broad categories, altogether encompassing fourteen top level steps. This process is depicted in
Table 2. It is important to note that this process is defined by its focus on achieving mission
goals at the lowest possible cost and risk. In addition, the SMAD authors indicate that
information flows down linearly from step 1 down through step 14, but information from steps 8
through 14 is also fed back up into steps 1 through 7, presumably to support any necessary
iteration.
Table 2. Space mission engineering process for a need-driven mission. Adapted from [262]
Goal Step
Define Objectives and
Constraints
• Define the Broad (Qualitative) Objectives and Constraints
• Define the Principal Players
• Define the Program Timescale
• Estimate the Quantitative Needs, Requirements and Constraints
Define Alternative
Mission Concepts or
Designs
• Define Alternative Mission Architectures
• Define Alternative Mission Concepts
• Define the Likely System Drivers and Key Requirements
Evaluate the Alternative
Mission Concepts
• Conduct Performance Assessments and System Trades
• Evaluate Mission Utility
• Define the Baseline Mission Concept and Architectures
• Revise the Quantitative Requirements and Constraints
• Iterate and Explore Other Alternatives
Define and Allocate
System Requirements
• Define System Requirements
• Allocate the Requirements to System Elements
54
There are some important properties to note in SMAD’s stepwise process. First, it is emphasized
that the top-level objectives of a mission should actually be kept qualitative, vague and poorly
defined, such that the details (i.e. the final “mission requirements”) are determined by what can
reasonably be achieved. The objectives of the Apollo program are referenced as an example –
success was achieved because the “requirements” were simple and vague: go to the moon. No
requirements were levied on length of stay, number of people, etc.). [These broad goals should
be revisited throughout the process to ensure that the design is still achieving them and at the
best cost possible.] Second, once the requirements are quantified (step four), they should not be
set in concrete, but should be left fluid and allowed to change and be traded throughout the
course of design. Third, the distinction between steps 5 and 6 is important. Step 5 establishes the
alternative, or set of, mission architectures that could satisfy the individual mission elements, e.g.
a payload or required orbit, while Step 6 looks at the possible set of fleshed out mission
concepts. Oftentimes, programs skip step 5 and immediately start with mission concepts, usually
due to bias based on experience with past programs, comparison to known programs, etc. Fourth,
an ideal assessment of the designed mission’s utility (captured by its Measures of Effectiveness
(MoEs)/Figures of Merit (FoMs) would involve the stakeholder, and would examine how well
the needs of the end user are being met and what the specific associated costs are. Last, iteration
occurs in step 12, which finalizes the concept exploration portion of the 14 steps. This step is
follow by the penultimate step, wherein the now better-defined objectives are translated into the
numerical system requirements. This is the point where a traditional system engineering process
actually begins, which drives the destructive tendency to let system requirements become
concrete, thus blindly driving potentially costly design choices.
55
In summary:
• Keep objectives broad, qualitative, and vague
• Allow quantitative requirements to remain fluid
• Identify alternative mission architectures, not just concepts
• Evaluate MoEs/FoMs and their associated costs with the end user/stakeholder
Engineering systems continue to increase in size and complexity at a steady pace, to the point
that in many domains (e.g. aerospace) they have now actually exceeded the capacity of Systems
Engineering. As a result, the field of Systems Architecting (SA) has emerged to provide a new,
expanded way to deal with these complex endeavors. Systems Architecting is concerned with the
effective and responsible architecture of the actual systems, i.e. system of systems. In USC’s
Systems Engineering and Architecting (SAE) department, eight recurring elements are identified
that shape the field of SA: Complexity, Exogenous Factors, Heuristics, Balance & Fit, Systems,
Representations, Expertise and Achievement [154]. Use of these elements as guiding principles
in the development of a system of systems provides a higher-level framework with which to
approach effective design.
3.2 Modeling Design
In addition to establishing the architecture of the design process, modeling the design itself is
also important. Model-Based Systems Engineering (MBSE) is an emerging but widely accepted
56
methodology that urges engineers to create a computer-interpretable abstraction of their system
up front, in order to support all phases of its lifecycle as it progresses. Modeling the structure of a
system and the relationships between its constituents is important in ensuring that consistent and
verifiable design processes are maintained.
As defined by INCOSE, MBSE is “the formalized application of modeling to support system
requirements, design, analysis, verification and validation activities beginning in the conceptual
design phase and continuing throughout development and later life cycle phases.” In the IEEE
definition, a model (or abstraction) is an approximation, representation, or idealization of
selected aspects of the structure, behavior, operation, or other characteristics of a real-world
process, concept, or system. Such a model allows different views of a system in order to serve
different purposes and address different concerns or issues [281].
Georgia Tech’s MBSE Center is currently exploring the many advantages of MBSE, including
investigations of dependency management, descriptive modeling of complex systems, and
development of model transformations, which can serve to automate workflow and reduce
human error [305]. The INCOSE MBSE Space Systems Modeling program was a joint effort
between MIT and Georgia Tech to provide a SysML (System Modeling Language) based model
of a space system as part of the INCOSE MBSE Challenge. The project applied the SMAD
FireSat mission as a use case [281]. (However, since the fictional FireSat mission was never
fielded, the practical use of the model could not be verified.) A follow-on study examined the
use of SysML to model a standard CubeSat, which was then applied to the Radio Aurora
Explorer (RAX) CubeSat mission, developed by the Michigan Exploration Lab (MXL) and SRI
International [222]. JPL’s Integrated Model-Centric Engineering (IMCE) project aims to bring
Model Based Engineering methods, tools and practices into use by systems engineers [110]. The
57
German Aerospace Center (DLR) has undertaken the infusion of a continuous mission
verification process, analogous to that used in software engineering, into their concurrent
engineering (CE) environment [210]. The DLR’s goal is to be able to perform verification of a
design after each iteration via the use of an executable MSE data model representation of the
spacecraft.
The Object Management Group’s (OMG) Unified Modeling Language (UML), a high-level
modeling language for the specification and description of software architectures, is also used in
several software and non-software approaches. Gross et al propose the use of UML as the
cornerstone of a “unified central product” that can manage the multiple heterogeneous models
and modeling tools in satellite design [78]. The use of UML has also been applied by Tranchero
in the creation of a co-design environment for nano-satellite design and verification [239].
Knowledge-based system (KBS) approaches to modeling have also been embraced in the
research community for the potential they hold to improve the design process [16]. KADS is one
effort for providing knowledge-based guidance to the knowledge engineering process. KADS
was first developed in the 1980’s at the University of Amsterdam. The CommonKADS
methodology has appeared to have gained momentum in the field of Knowledge-Based Systems
(KBS) in Europe and Japan [282] in the 1990’s, but it is unclear how far the concept has
progressed since then.
58
3.3 Decision Making
Many methodologies exist for aiding engineers and stakeholders in the decision making process,
especially when in the presence of multiple possibly conflicting criteria (this is sometimes
broadly referred to as multi-criteria decision making (MCDM) or analysis (MCDA)). In general,
expressing system goals in an objective function is the preferred approach, but pure
mathematical optimization (described in section 3.4) is not always feasible or applicable. Here, a
review of selected alternative methods is provided.
3.3.1 Analysis of Alternatives (AoA)
Analysis of Alternatives (AoA) is an effort that has been embraced by the Office of Management
and Budget (OMB) and the Department of Defense (DoD) to ensure that multiple different
alternatives have been analyzed and compared each time a significant investment decision on a
project must be made. AoA aims to move from the acceptance of justification of a single
alternative to the consistent exploration of a number of alternatives such that agencies can be
confident they are funding the most optimal projects, taking into account risk and uncertainty.
This methodology is similar to other top level decision-making tools in that it is most effectively
applied in a higher-level context, for example in an Enterprise Architecture framework. An AoA
process can result in one of four levels of AoA maturity based on the number of alternatives
considered, the inclusion of uncertainty in the analysis, and the type and nature of decision
support used.
59
3.3.2 Analytic Hierarchy Process (AHP)
In the Analytic Hierarchy Process (AHP), first introduced by Saaty in 1977, problems are
decomposed into a hierarchy of objectives, criteria and available alternatives. AHP enables the
evaluation of both qualitative and quantitative factors via the application of weighting and
priorities, ultimately enabling relative ranking of alternatives [240]. Lavagna and Finzi applied
the AHP technique and genetic algorithms to improve the concurrent engineering process for
spacecraft, in particular addressing inconsistencies and bottlenecks that occur as subsystems are
designed in parallel [132]. The authors propose the use of Fuzzy Logic to capture causal
relationships between variables and objectives, and interval algebra to size aspects of the system
while uncertainty is still present in the design process [133].
3.3.3 Multi-Attribute Utility Theory
Multi-attribute utility theory (MAUT) is used to map the preferences of decision makers for a
system attribute into a normalized utility function. The MAUT method combines single-attribute
utility functions into one function in order to quantify how certain attributes are valued over
others [108,237]. This enables continuous ranking of the designs [197]. Thurston explains that
MAUT is useful when technical aspects of a design must be considered concurrently with
economic aspects of manufacturing, with the further complicating factor that different decision
makers may rationally favor different alternatives. She proposes a “design flexibility” attribute
60
that aggregates both technical and economic aspects in the context of an illustrative automotive
case study.
MAUT has been used extensively by MIT in their MATE frameworks (see section 4.1.7). In
systems where utility is not generally expressed in dollar terms, for example military systems,
MAUT interviews can be performed with stakeholders in order to infer the equivalent value and
revenue figures [31]. The Contingent Valuation Method is a similar such technique that provides
an effective valuation of “public” goods, for example national defense, environmental amenities,
or the Apollo space program [158].
3.3.4 Quality Function Deployment (QFD) and the House of
Quality (HoQ)
Quality Function Deployment (QFD) is a systematic method for streamlining a product
development process towards a customer’s desires, specifically by quantifying otherwise
qualitative and often subjective criteria such that it can be measured [285]. As described by
Akao, QFD is a “method to transform user demands into design quality, to deploy the functions
forming quality, and to deploy methods for achieving the design quality into subsystems and
component parts, and ultimately to specific elements of the manufacturing process” [8]. QFD
was originally developed by Akao in 1966, through a combination of his work in quality
assurance and quality control points with function deployment used in value engineering. The
House of Quality (HoQ) matrix diagram is one tool that has been widely used to capture the
QFD process and represent how well the user desires are being met [89]. It was first used in 1972
61
by Mitsubishi to address oil tanker design, and it has since been accepted and employed by large
organizations such as Ford, AT&T, Hewlett-Packard and Toyota (see Figure 6).
The HoQ matrix is described as a tool that enables “interfunctional planning and
communications”, for example as a medium through which the engineering and marketing
departments of an organization can effectively communicate about a design. This capability
could also be extended to serve the “owners” of disparate aspects of a space system’s design (i.e.
subsystems, operations, etc.). This has been explored in design-to-cost satellite systems at the
University level [51], in integrating parametric cost analysis into cost deployment at NASA
Langley [52], and in aerospace weapons systems [267].
62
Figure 6. Example excel-based House of Quality design matrix [294]
3.4 Optimization
Optimization can be defined as the process of “making something as fully perfect, functional, or
effective as possible” [314]. It is used in numerous aspects of spacecraft design, including the
design of a spacecraft thermal control system [72], the optimal orientation of directional sensors
and instruments [224], multi-objective optimization of a seven element antenna design [184], and
maximizing the communication capacity of space-to-ground networks via optimal scheduling of
Earth Observing Satellites (EOS) [221,222]. At the system level, the design of a space vehicle is
63
best characterized as a mixed continuous/discrete optimization problem, which generally results
in a design space that is non-convex (multi-modal), and nebulous. Therefore, traditional
optimization techniques are not well-suited to space system design. Examples of non-traditional
techniques that have been applied in this domain include genetic algorithms, which mirror the
behavior that is observed in biological populations [87] and simulated annealing, which is a
heuristic technique inspired by the cooling process of a material to a state of minimum energy
[104]. While useful, however, such heuristics-based methods do not guarantee optimality.
3.4.1 Multidisciplinary Design Optimization (MDO)
Multidisciplinary design optimization
3
(MDO) integrates independent disciplinary analyses with
system level optimization, effectively extending the processes of Concurrent Engineering into
the conceptual design phase. MDO enables the systematic evaluation of system-level
consequences of subsystem-level design decisions, components, and configuration options. This
is critical, since the optimal system solution is generally not equal to the aggregation of
subsystem solutions that have been optimized individually (for a nonlinear objective function,
these two solutions are not the same). A solution to this problem is particularly valuable in space
system design, where most to all subsystems and their design parameters are interrelated in some
direct or indirect way, complex spacecraft models generally cannot be represented by any closed-
form expression, and design spaces exhibit complicated non-convex topographies. The necessary
3
MDO is also sometimes used to mean “Multi-Disciplinary Optimization”. These two meanings will be considered
to be interchangeable in this context.
64
combinatorial analysis of discrete information, which increases exponentially with number of
discrete variables, is often prohibitively time-consuming [193].
In 2000, Taylor investigated and provided an evaluation of the various optimization techniques
that can be applied to spacecraft design [192,193], including traditional (i.e. mathematically
tractable closed-form solutions) and non-traditional (which employ heuristic techniques and do
not necessarily converge to optimality) approaches. The author identifies three guiding
requirements for the selection of an optimization technique in spacecraft design, but only
discusses the first in her study: 1) Accommodate the mathematical structure of the problem
(allow discrete variables, computationally expensive function evaluations, and model noise and
uncertainty); 2) Work with existing analysis tools, including separate disciplinary models (as
very few integrated system-level models for spacecraft design currently exist); and 3) Be
compatible with the current design philosophy and culture (enabling the generation of designs
that are robust to changes, and a knowledge of sensitivity to parameters). Taylor provides a
breakdown of existing optimization approaches, depicted in Figure 7, and suggests that the
spacecraft design problem can best be described as a discrete or mixed continuous/discrete
optimization problem, and thus most often formulated as a Mixed Integer Nonlinear
Programming (MINLP) problem.
The optimization techniques that fall within the MINLP categorization are only made feasible
with application of specific advanced structuring techniques and significant computer processing
capacity. In addition, these techniques are still difficult to employ due to the multi-modal,
nebulous design space that is often generated with spacecraft design. Taylor notes that an
algorithm closely related to these methods is that of dynamic programming, which was
introduced by Bellman in the 1950s. This algorithm is very similar to the branch-and-bound
65
technique in that it performs an intelligent but exhaustive enumeration of all feasible points of a
problem
4
. However, doing so requires that a sequence of multiple decisions must be made in the
problem structure, or the algorithm will prove inefficient or unuseful for problems that involve a
large number of discrete and continuous variables. Thus modified dynamic programming is
identified as the most promising closed-form solution procedure if it is feasible and achievable
(i.e. sufficiently small number of variables).
Alternatively, another option for spacecraft design optimization is found in non-traditional
methods, which often employ numerical search to find a set of heuristic solutions. While useful
and capable in this respect, these methods produce an approximate optimal solution that is not
necessarily better than others, thus requiring extra attention be paid by the engineer to ensure its
validity as an “optimal” solution. Popular and efficient techniques include Tabu search,
simulated annealing, and genetic algorithms, termed metaheuristics. Taylor’s study investigated
this approach using a hybrid scatter/Tabu search methodology via the commercially available
OptQuest software package from Decisioneering, Inc.
4
For further discussion on the branch-and-bound and dynamic programming methods, the reader is referred to
Papadimitriou, C. and K. Steiglitz, Combinatorial Optimization: Algorithms and Complexity, Dover, 1998.
66
Figure 7. Optimization approaches [193]
67
A 2007 publication on the State-of-the-Art in MDO (and desired future research areas) by the
technical organizing committee for the 2006 European-U.S. MDO Colloquium provides a
broader overview of MDO for any engineering domain [252]. Some commercially available
software tools for MDO are summarized in Figure 8.
Figure 8. Commercially available software tools for MDO [252]
Similarly, a multi-objective (or multicriteria) optimization process is one in which several
separate criteria are optimized upon simultaneously. The confluence of MDO and multi-
objective optimization is termed Multi-Disciplinary and Objective Optimization, or MDOO (the
reader is directed to reference [173] for further discussion on MDOO in space system design).
3.4.2 Distributed Optimal Design
Collopy proposes a method for distributed optimal design in which a formal design cycle is used
to evaluate projected attributes, capital investment analysis is employed to create a system-level
objective function that provides an ordinal valuation of a set of system attributes, and a
derivation of component level objectives is performed from the system level objectives. The
68
study identifies how the performance of the launch system affects the final value of the system
[44]. Brown and Eremenko prescribe a similar “Design Scoreboard” approach, which is
essentially a linear objective function represented in more visually tractable table format.
Zhuoyan et al propose Distributed Multidisciplinary Concurrent Optimization (DMCO), which
integrates concurrent engineering and MDO with a distributed network computing technology, to
enable efficient multilevel optimization and design of spacecraft [97].
3.5Value-Centric Design
The Value-Centric Design Methodology (VCDM) implies a quantitative consideration for
system attributes that enhance value beyond the specific service or resource that is being
provided, such as flexibility, survivability, adaptability, etc. These so-called “ilities” (named for
the frequency with which the suffix “ility” appears in such terms) contribute to the assurance that
the primary profit-generating (or otherwise valuable) service of a system can consistently be
produced, even in the face of uncertainties. Space systems that exhibit these ilities and are
capable of responding favorably in the face of uncertain events are often referred to as adaptable
systems. The potential advantages of these systems over traditional systems are many, including
responsiveness to orbit, flexibility to changes in market demands or user needs, robustness to
funding or political fluctuations, etc.
The growing movement towards value-centric design aims to provide engineers and decision
makers with the tools to assess a system’s worth based on more than traditional factors, such as
69
absolute minimum cost, and instead focus on attributes that exhibit enhanced value. Adopting
this new mindset would serve to “close the business case” on otherwise seemingly-suboptimal
approaches, such as fractionation. Compared to traditional architectures, a fractionated
architecture will likely exhibit much higher cost, mass, etc., but if the added attributes are
correctly and sufficiently valued, these tradeoffs become justified. Value-centric decision making
could thus have a significant effect on acquisition strategy in space systems, from a
requirements-centric (and minimum cost) to a value-centric view.
The benefit of the additional or enhanced capabilities becomes evident when the system is able
to continue providing value in spite of unforeseen circumstances, such as failure, component
obsolescence, attack, etc. For example, if one spacecraft module in a cluster architecture fails,
mission success drops only incrementally instead of completely to zero. This concept is the space
equivalent of avoiding “putting all your eggs in one basket” [31], wherein a single failure can
and often does lead to total system failure.
Conversely, a focus on value could reveal new and potentially profitable or otherwise valuable
outcomes and markets, such as responsive satellites or resource sharing. An analogy given by
Brown is that of sending a letter via express mail across the globe: it costs a premium to achieve,
but the high price is justified when weighed against the benefits of how quickly the sender
receives it. Indeed, the very metrics we use to assess the value of our systems are skewed. For
example, as Brown argues, “cost per pound is a flawed metric” in the context of the questionable
cost-effectiveness of launching small satellites, because it ignores the [more immeasurable] value
of the launch’s timeliness [144].
70
For example, Saleh argued that there is value in having the option to defer design decisions into
the future [32], such as through on-orbit servicing. However, traditional net present value
calculations (such as discounted cash flow techniques) are not sufficient in showing the true
value of flexibility, especially in highly uncertain environments. Saleh presented the adaptation
of Real Option theory to better capture this value [204], in particular with the use of the Black-
Scholes equation. The Black-Scholes equation, which earned its developers the Nobel Prize in
Economics in 1997 [205], is central to the foundation of option pricing [241]. The equation
expresses value based on the price of the underlying asset (e.g. revenue of an additional payload
module deployed to a cluster), volatility in price of the asset (projected volatility in the demand
for the payload), and exercise price (or strike price) of the option:
𝑉
!"#!"#
= 𝑆×𝑁 𝑑
!
−𝐾𝑒
!!"
×𝑁 𝑑
!
(3)
where S is the price of the asset, 𝐾𝑒
!!"
is the present value of the exercise price of the option
using the risk-free interest rate r, and N is the cumulative normal distribution function:
𝑁 𝑥 =
!
!!
𝑒
!!
!
𝑑𝑦 (4)
of d
1
:
𝑑
!
=
!" !/! ! !!
!
!
!
×!
! !
(5)
71
and d
2
:
𝑑
!
=𝑑
!
−𝜎 𝑡 (6)
where σ is the volatility of the asset [31,170,206].
In the context of fractionation, having the ability to augment an existing fractionated satellite
cluster with an additional payload at some point in the future is of value to the decision maker
and can be quantified as such an “option”. The exact value is a function of the revenue that the
additional module would generate if deployed, the projected volatility of the demand for this new
module’s service, and the cost of deploying it [31]. Use of real option theory was also
investigated by Glaros in evaluating organizational flexibility in a military context [74] and by
JPL in examining present strategic value via a time-expanded decision network [299].
For demonstrating the most effective mix of homogeneous and heterogeneous fractionation in
space systems, Brown and Eremenko suggest that there exists an optimal “portfolio” that can be
found to deliver the greatest value with respect to failure. This can be found in analogizing
Markowitz’s financial theory on diversification [146], which proposes an investment strategy
that focuses not purely on maximum returns, but instead on maximum returns with minimum
volatility. In Markowitz’s analysis, it is shown that “efficient frontiers” exist which allow one to
maintain desired levels of return while minimizing risk through diversification [29]. The value of
diversification can be estimated using a risk premium pricing model such as the Capital Asset
Pricing Model, or CAPM, for insurance [157]. CAPM, which is based on early theory from
Nobel Prize winning economist Harry Markowitz, values “assets” according to their respective
market risks. Brown and Eremenko suggest that the financial instrument of insurance is
72
analogous to the “engineering instrument” of fractionation. Similarly, Collopy proposed a
method for distributed optimal design that uses a system-level objective function based on
capital investment analysis [44].
Saleh examined the utility in moving focus away from cost-centric metrics through an
investigation of cost per operational day and cost per transponder for communications satellites.
He showed that while these may be applicable in a supply-constrained market [204] they do not
necessarily guarantee maximum profit in a competitive market as revenues are not guaranteed to
remain constant over time [202]. A revenue model was proposed that better captures the
expected net present value a system will deliver over time via the use of an appropriate utility
model. The equation was derived according to the continuity equation from fluid dynamics:
𝑉
!"!#$%
𝑇
!"#$
= 𝑢 𝑡 −𝜃 𝑡 ×𝑒
!!"
𝑑𝑡−𝐶
!"#
𝑇
!"#$
(7)
where 𝑉
!"!#$%
𝑇
!"#$
is the expected NPV of a system as a function of its design lifetime; 𝑢 𝑡 is
the “utility model” of the system, or the expected flow of service per unit time, and 𝐶
!"#
𝑇
!"#$
is
the total cost of the system to initial operating capability, or IOC. 𝑢 𝑡 may be a simple
expression, such as a constant revenue independent of system lifetime (e.g. 𝑢 𝑡 =𝑢
!
), or it may
consider the impact of technology obsolescence:
𝑢 𝑡 =𝑢
!
×𝑒𝑥𝑝 −
!
!
!"#
!
(8)
73
where time to obsolescence 𝑇
!"#
can be a simple deterministic variable or a random variable with
a probabilistic distribution [206].
3.5.1 Defining Value
Non-traditional value attributes, or ilities, have been defined and used in a variety of differing
ways in the literature.
In 2001, Saleh, Hastings and Newman [203] set forth to define and distinguish flexibility and
robustness. They capture and frame the following definitions from the literature as follows:
• Flexibility in Flexible Manufacturing Systems (FMS):
o Volume flexibility – the ability of a production system to handle changes in daily
or weekly volume of the same product, thus allowing the factory to operate
profitably at varying overall production levels
o Product mix flexibility – the ability to manufacture a variety of products without
major modification to existing facilities
o Routing flexibility – the ability to process a given set of parts on alternative
machines
o Operation flexibility – the ability to interchange the ordering of operations on a
given part, thus allowing the ease of scheduling of its production
• Flexibility in multidisciplinary design processes (i.e., any common design endeavor that
relies on input from multiple technical disciplines):
74
o Identification of a range of solutions within the design process that involve
information passing between multiple disciplines, as opposed to a single point
solution in any one discipline. This imparts the ability to generate better products
in less time due to the decreased number of iterations required
o The customer’s ability to reduce, eliminate, or defer their ‘requirements’ (via the
ability and/or willingness to lower product expectations) such that the product’s
requirements can be matched with the development resources available in the
desired cycle time, and/or the developer’s ability to invest more resources to
reduce technical risks and other gaps
• Flexibility in real options and managerial flexibility (designing in an uncertain
environment):
o The ability of management to affect the course of a project by acting in response
to the resolution of market uncertainty over time.
• Robustness [in design]:
o Characteristic of a system that exhibits minimal deviation away from the ideal
performance expected by the customer regardless of production or manufacturing
variations (changes in raw material, manufacturing variability), variation in
operating conditions, or variation due to time and use (deterioration)
• Flexibility vs. Robustness
o Flexibility “implies the ability of a design to satisfy changing requirements after
the system has been fielded”
o Robustness “involves satisfying a fixed set of requirements despite changes in the
system’s environment or within the system itself”
75
This framework speaks to an important distinction in the term flexibility in the context of system
design: flexibility can be used as a term describing an attribute of the actual design process, or an
attribute of the ultimate system design itself (i.e. flexibly designed system vs. flexible system
design). The authors further define this as flexibility to uncertainties occurring prior to the
operations phase, or after the operations timeframe has commenced [203]. Their work focuses on
the latter.
Baldwin and Clark defined how the execution of certain module actions, for example
substituting, augmenting, or excluding a module, correspond to various manifestations of
flexibility in the context of fractionation specifically [17].
Hastings and McManus [88] presented a framework in 2004 for better understanding
uncertainties and the techniques for mitigating and exploiting them, including the types of
uncertainties, the risks and opportunities they create, the strategies used to mitigate or take
advantage of them, and the system attributes that result. The authors highlight rapidly changing
technologies and markets on the commercial side, as well as technologies, threats, needs and
budgets on the defense side. While decision-makers today are calling for “robust”, “flexible” or
“evolutionary” systems, tools for assessing the uncertainties in a system or mission are immature
and methods for these types of designs are in their infancy. The authors presented a breakdown
of definitions of several key terms with respect to uncertainty and uncertainty mitigation field is
as follows:
• Reliability - Probability that the system will do the job it was asked to do (i.e. it will
work).
76
• Robustness - Ability of the system to do its basic job in unexpectedly adverse
environments.
• Versatility - Ability of the system, as built/designed, to do jobs not originally included in
the requirements definition, and/or or to do a variety of required jobs well.
• Flexibility - Ability of the system to be modified to do jobs not originally included in the
requirements definition.
• Evolvability - Ability of the system to serve as the basis of new systems (or at least
generations of the current system) to meet new needs and/or attain new capability levels.
• Interoperability - Ability of the system to “play well with others”, both with systems it
was originally designed to work with, and with future systems.
Ross et al [199] focused on the definition of changeability in 2008, classifying it as an
overarching term that encompasses the following:
• Flexibility - The ability to be changed by an agent that is external to the system
• Adaptability - The ability to be changed by an agent that is internal to the system
• Scalability - The ability to change the level of a parameter
• Modifiability - The ability to change the membership of the parameter set (i.e. enabling it
to display a new function and/or form)
• Robustness - The ability to remain “constant” in parameters in spite of system internal
and external changes
Brown and Eremenko present a slightly different framework, wherein a space system's flexibility,
or its ability to change on demand, encompasses scalability, evolvability, maintainability and
adaptability (or reconfigurability), and its robustness, or its retention of functionality in response
77
to an internal or external stimulus, includes reliability, survivability, resilience to fragility and
fault tolerance [32]. The definitions are summarized in Table 3 and Table 4.
Table 3. Manifestations of flexibility. Adapted from [32]
Term Synonyms Definition
Scalability Incremental deployment Ability to add components or capability
to a system throughout its lifetime
Evolvability Upgradeability Ability to replace components due to
technology obsolescence
Maintainability Sustainability Ability to replace components that have
failed or are near end of life
Adaptability Reconfigurability,
versatility
Ability to reconfigure existing system
functionality to meet new needs or
circumstances
Table 4. Manifestations of robustness. Adapted from [32]
Term Synonyms Definition
Reliability - Ability of a system to function under
nominal conditions
Survivability - Ability of a system to function under off-
nominal or unanticipated conditions
Resilience to fragility Robustness to fragility The (in)frequency with which a system
succumbs to unmodeled, catastrophic,
cascading failures
Fault tolerance Graceful degradation Gradual loss of system functionality due
to one or more failures
Clearly, many of the existing frameworks share commonalities. Simpler frameworks exist as
well, such as that from de Neufville, which suggests that uncertainty can be managed with either
passive system modification (robustness) or active system modification (flexibility) [168].
78
Chapter 4
Spacecraft Design Approaches
Design is an iterative process. The necessary number of iterations is one more than the number
you have currently done. This is true at any point in time. – Akin’s 3
rd
Law of Spacecraft Design
[9]
In the typical approach to spacecraft design, subsystem experts gather and flesh out design
concepts over the timescale of weeks, meld analyses from multiple heterogeneous modeling
tools, and iterate until they converge upon a mutually agreeable design. Most aerospace
organizations have dedicated facilities to accommodate this process, known as the Concurrent
Engineering (CE) design process. Such centers include the Jet Propulsion Laboratory’s (JPL)
Team X [219] and its Innovation Foundry/A-Team (the latter focuses on development of early
concepts) [274]; Goddard SpaceFlight Center’s Integrated Design Center (IDC) [137], in
particular the Mission Design Lab (MDL)
5
[315]; the Integrated Concept Development Facility
(ICDF) at Northrop Grumman [137]; the Concept Design Center (CDC) at the Aerospace
Corporation [4,5]; the European Space Agency’s Concurrent Design Facility (CDF) [306]; the
Satellite Design Office (SDO) at Dornier Satellite Systems GmbH [225], and others.
5
The GSFC design center was formerly the Integrated Mission Design Center (IMDC) [106]
79
In general, these facilities accommodate a number of engineers dedicated to system and
subsystem functions, and rely on the use of some central repository that houses design
information and performs design convergence and requirements tracking (for example, Alenia
Spazio’s CODE environment [275]). Many, however, are very simplistic, and still rely heavily
on the use of interlinked Excel spreadsheets that are either controlled by a system engineer, or
possibly by an automated database system (such as that developed in 1992 by the former
Rockwell International Corporation [77]). Additionally, most existing satellite design tools and
resources are proprietary, and thus little information on the specific algorithms and methods used
is publicly available.
At the University level, the Aerospace Systems Design Laboratory at the Georgia Tech
Guggenheim School of Aerospace Engineering has created the Collaborative Design
Environment (CoDE) facility for Multidisciplinary Conceptual Systems Design [176], and MIT
explores space system design from a systems architecting perspective in their System
Architecture Lab [316]. USC/ISI’s Space Engineering Research Center (SERC) developed an
integrated system engineering design workflow which facilitated the automated, interlinked
execution of various mission analysis and subsystem design environments, all of which were
driven by the SPIDR engine [6,19], which is employed in this study.
Within these processes, numerous computer-aided engineering (CAE) tools exist, for design of
varying subsystems, and to support the many phases of space system development, including
conceptual design, tradespace exploration, detailed design optimization, system and subsystem
analysis, validation and verification [19], and integration, assembly and test (IA&T) [107]. These
CAE tools, often grouped into CAD (Design or Drafting), CAM (Manufacturing), CAT
(Testing), and work Planning (CAP), may exhibit a high level of detail and accuracy but
80
generally only consider aspects of one localized subsystem. And although the output from each
independent analysis is likely dependent upon or affects some other aspect of the system, they
are still usually performed in parallel, and the results are exported in incongruent design formats.
The resultant process is costly and time-consuming, and can yield suboptimal results because the
tradespace cannot be explored exhaustively.
Despite significant growth in the number, types, and sophistication of available tools and
frameworks, this progress appears to generally be limited to the domains of traditional systems.
Moreover, these tools generally only support design approaches that are founded on the pursuit
of traditional metrics such as cost, mass and performance. Many research efforts and
commercially available tools have emerged that attempt to offer a more comprehensive approach
to the overall design process. This chapter reviews a selection of existing approaches and tools,
including for the design of satellites, fractionated architectures, and other non-traditional systems
and approaches.
4.1 Satellite Design at Various Organizations
4.1.1 Aerospace Corporation, SSDM, 1998
The Aerospace Corporation’s Small Satellite Design Model (SSDM) was an early tool developed
specifically for the domain of small satellites [165]. The spreadsheet-based tool enables
estimation of mass, power and cost for both earth orbiting and interplanetary spacecraft based on
81
actual parameters of more than 30 small spacecraft. Individual worksheets contain modeling of
major subsystems, associated component databases, mission requirements, payload and cost
drivers. The SSDM was calibrated against known missions based on their input mission
requirements, and SSDM values came out to be within 15-20% of actuals. This level of accuracy
is useful for first pass, conceptual design, but is likely insufficient beyond that stage.
The SSDM was coupled with the Aerospace Corporation’s Small Satellite Cost Model (SSCM)
to create the ASSESS (Aerospace Small Satellite Evaluation Spreadsheet Suite) tool, which
enables rapid spacecraft architecture analysis, in particular to support early feasibility studies. At
the time of its initial introduction, several versions of ASSESS were being generated, with
fidelity ranging from high level rules of thumb to detailed subsystem design with selection of
actual components. The tool was identified as a resource that would be made available to the
small satellite community, with differing organizations having access to differing levels of
fidelity based on restrictions (i.e. simplistic models available to the general public, detailed
design models available to government entities). However, the SSCM is the only resource that
appears to be currently available [317].
4.1.2 Aerospace Corporation, SmallSatCEM, 2001
The Aerospace Corporation’s SmallSat Concurrent Engineering Model (SmallSatCEM) is a
spreadsheet-based approach with Visual Basic that was developed to duplicate the functionality
of more complicated algorithms and external programs for design and analysis [153]. The
environment contains spreadsheets linked in a Concurrent Engineering Model (CEM) that is
82
owned by the systems engineer, and the effect of any change within one subsystem can be
communicated to the CEM and then propagated to all other subsystems. The current model state
is reflected in a singular Model State worksheet. This approach, which mirrors the concurrent
design approach used in Aerospace’s CDC, relies on a serial design method where design and
analysis are performed independently by subsystem and iteration is enacted manually to achieve
convergence. The tool is aimed to be useful for generating rapid answers given broad trade
spaces, in particular when low fidelity is acceptable.
Key to the CEM approach is the goal of enabling both design and analysis of a conceptual
spacecraft in a closed-loop form. Because the analysis can only use conceptual design phase-
level information, certain estimating techniques are employed in order to approximate high
fidelity analysis. For example, mass properties using are calculated based on the establishment of
mass “zones”, solar illumination is based on true anomaly, thermal analysis is performed using a
small set of nodes (comprised of each panel, body surface and interior zone) and conduction
coupling factors, etc. (see Figure 9).
The authors point out that using standard tools for the design of small satellites is problematic
since the characteristics of these systems can vastly differ from those of traditional large
satellites. For example small satellites can much more readily utilize fixed solar arrays, might
exhibit reduced thermal inertia, and can be comprised of parts from non-traditional vendors.
Furthermore, parametric resource estimates are difficult since there exists far less historical data
at this end of the size spectrum.
While the CEM approach enables exploration of a large tradespace, the Aerospace’s CDC
approach does provide higher fidelity design due to inclusion of more complex subsystem design
83
algorithms in the loop. The CEM also obtains cost estimates using the Aerospace Corporation's
Small Satellite Cost Model (SSCM), a parametric model for estimating development and
production costs for small satellites [317]. However, the SSCM is based on historical data and is
in large part predicated on high TRL space-qualified components. Consideration of non-
traditional space components would greatly increase the accuracy of this model in the small
satellite domain.
Figure 9. Closed-loop design and analysis in Aerospace Corporation's SmallSatCEM [153]
4.1.3 Ecole Polytechnique Federale de Laussan, CO
2
DE, 2008
The Ecole Polytechnique Federale de Laussan (EPFL) of Switzerland introduced the
COllabOrative DEsign decision support system, or CO
2
DE, to facilitate collaborative
engineering during the conceptual design phase of a system. Kim and Xirouchakis used a small
satellite conceptual design as a case study for the tool [118]. In CO
2
DE, constraints are used to
84
represent compatibility between design principles, or DPs, which are essentially the design
options for outputs of sub-functions. For example, in satellite design, a sub-function might be
“Determine and control the Attitude (ADCS)”; a design output, or DO, for this sub-function
might be point stability; and DP’s for this DO might be [0.01 to 0.05] degrees/second for one
ADCS option and [0.03 to 0.07] degrees/second for another ADCS option. Design constraints for
a small satellite design problem are depicted in Figure 10, where each DO corresponds to some
design variable such as mass, data storage, image size, etc.
The tool then uses filtering to identify the optimal design that fits a set of constraints. The
architecture of the system is depicted in Figure 11. While CO
2
DE presents a novel constraint
satisfaction problem (CSP) approach to satellite design (using Excel spreadsheets for inputs), the
specific case study only considered six simplified small satellite sub-functions (payload, ADCS,
command and data management, power, and communications to and from the ground station). In
addition, the environment only performs the filtering and selection steps of the conceptual design
process. It does not cover the generation of design concepts.
85
Figure 10. Small satellite design constraints in CO
2
DE [118]
86
Figure 11. Architecture of CO2DE environment [118]
4.1.4 Jet Propulsion Laboratory, MIDAS, 1995
JPL’s Multi-Disciplinary Integrated Design Assistant for Spacecraft (MIDAS) [73] attempted to
integrate disparate computer aided design elements (e.g. design tools such as NASTRAN and
SPICE and legacy codes) to identify the best global design given multiple distributed and
concurrently occurring design efforts. The goal of MDIAS was to achieve the following
87
objectives: 1) Enable graphical entry of an engineer's design methodology for their element, and
facilitate interconnection with other elements; 2) Allow consideration of both mission
requirements and requirements levied via the designs of other elements; 3) Automatically invoke
the necessary design tools; 4) Also integrate user-defined design programs; 5) Be platform
agnostic (from personal computers to parallel computers); and 6) Employ and compare different
multidisciplinary optimization algorithms to select the globally optimal design.
While long term objectives sought to achieve automated looping and searching in MIDAS, no
such result is currently found in the literature. Thus while this preliminary system did offer a
unique graphical approach to system design specification and identification of interdependencies,
it still required extensive manual iteration.
JPL’s work on an Optimization Assistant (OASIS) [69,70] aimed to apply generic metaheuristic
optimization algorithms (such as genetic algorithms and simulated annealing) to MIDAS to find
optimal solutions. Other work has investigated the utility of genetic algorithms in spacecraft
design, including JPL's DEVO project [70], an evolutionary optimization system also used in
conjunction with MIDAS.
4.1.5 Jet Propulsion Laboratory, ISDE, 1998
JPL’s Immersive Synthetic or Interactive Sharable Design Environment (ISDE) furthered the
MIDAS work with the inclusion of a web-based, real-time collaboration capability [128]. The
ISDE aimed to improve distributed collaborative design across NASA centers and other vendors
88
and organizations through real-time interaction, and by allowing incorporation of design
performance observations gleaned through simulation. It was partially performed in support of
the DARPA Rapid Design Exploration and Optimization (RaDEO) project.
The ISDE enabled users to develop a reproducible design methodology, or methogram, which
captured and stored some aspect of the design process for future use. Design elements within a
methogram are interconnected and invoked by a central Programmable Tool Server (the Millenia
Engine, also the basis for MIDAS). The ISDE appears to have led to the immersive design
capabilities in the Intelligent Synthesis Environment (ISE), described in section 4.1.9.
4.1.6 JHU-APL, 2000
The Johns Hopkins University Applied Physics Laboratory (JHU-APL) proposed a knowledge-
based approach to spacecraft design that aims to facilitate and standardize distributed Modeling
and Simulation (M&S) efforts as well as design knowledge sustainment [75]. The APL’s
simulation-focused endeavor would provide a framework that could support real-time interaction
of distributed models and simulations across any platform over the internet. (This approach is
similar to USC/ISI’s endeavor to enable automated hardware-in-the-loop testing via device
drivers that are written for each component and stored alongside their normal spec sheets and
associated parameters, as described in section 10.3.1). Their effort aims to achieve this seamless
integration via an object-oriented decomposition of spacecraft components and interfaces and a
standards-based abstraction of disparate simulations.
89
Central to APL’s project is the instantiation of publicly available libraries of simulation software
that emulate the behavior of different spacecraft components. These simulation packages are
conceptually analogous to the prevalence of “spec sheets” describing component performance
currently available via vendors. Written in industry-standard formats, the reusable simulations
could be downloaded by engineers and combined with other component and subsystem
simulations in a plug-n-play fashion to comprise a federated simulation of the entire system in
design, essentially a virtual spacecraft. To achieve this, each component inherits from a standard
class for its type (e.g. reaction wheel class or battery class), thereby eliminating the task of
identifying and parsing pertinent performance aspects each time a new part is considered (see
example decomposition in Figure 12).
Figure 12. JHU/APL component decomposition into relevant parameters, attributes and
interfaces [75]
90
While this greatly simplifies the job of declaring and describing a component’s properties and
behavior, it also constrains the pool of components that can participate in a federated simulation
to those that adhere to the known, traditional format, limiting the inclusion of innovative, COTS,
and non-traditional parts. The simulation methodology does, however, consider both the physical
and functional decomposition of a spacecraft’s constituents, i.e. physical properties such as mass
distribution, heat generation and data flow are decoupled from functional properties such as
power, attitude control, etc. Thus APL’s approach could be conducive to non-traditional
fulfillment of subsystems (e.g. a plastic battery in their standardized abstraction can functionally
provide energy storage and also physically provide structural support). Lastly, while the
description of each component must be manually specified in this concept, other programs such
as USC/ISI’s Active Catalogs have attempted to automate that process (see following section).
While the bulk of this effort focuses on interlinking simulations of spacecraft subsystems,
another integral aspect is the implementation of a Web-based repository for “living”
representations of past and current spacecraft programs that can be accessed and explored by the
broader community. The goal is to provide the opportunity for space system engineers to
leverage the cumulative experience of the greater spacecraft design community, which is
knowledge that is otherwise either lost or available but difficult to interpret and apply. Examples
of such lessons learned that are rarely effectively stored and propagated include design rationale,
feasibility of certain concepts, effects of parameter choices on other subsystems and components,
performance under particular conditions, etc. The APL team emphasizes that this effort does not
intend to automate any portion of the design process, but rather to provide a framework that
enables the valuable knowledge gained during the design process to be intelligently stored such
that it can be leveraged and utilized by others, reducing the cost and time necessary for
91
subsequent designs. The authors proposed to utilize the CommonKADS architecture [264], a
Knowledge Acquisition and Document Structuring (KADS) methodology for structured
knowledge engineering developed by the University of Amsterdam, to drive this Knowledge-
Based System (KBS). Finally, the authors proposed the development of a Spacecraft Design
Markup Language (SDML), based on XML standards, which would facilitate the execution and
display of simulations and accommodate the Web documents that contain the spacecraft
knowledge.
APL’s efforts were first instantiated in a simulation of their Thermosphere-Ionosphere-
Mesosphere Energetics and Dynamics (TIMED) satellite’s ACS system, however it is unclear
how far the endeavor has progressed beyond this initial demonstration.
4.1.7 MIT, MATE-CON, 2004
MIT’s Multi-Attribute Tradespace Exploration for Concurrent Design (MATE-CON) [197] is a
framework that entails 1) Need identification, 2) Architecture Solution Exploration (models and
simulations are used to transform design vectors to attribute), 3) Architecture Evaluation
(attributes are evaluated in utility-cost space), 4) Design Solution Exploration (Caltech’s
ICEMaker is used to perform design-level work for the selected “best” architectures) and 5)
Design Evaluation.
Ross et al applied MATE-CON to space system design to enable consideration of stakeholder
preferences, uncertainty analysis, and design for downstream phases (i.e. designing for
92
manufacturability, operations, decommission) in the traditionally “front end” phase. The
concurrent design in MATE-CON relies on models and simulations linked via a central server,
and the architecture evaluation and design evaluation stages are serial. The authors indicate an
inability to generate a tradeoff frontier since only partial enumeration can be performed. The tool
does, however, provide a utility metric that enables evaluation across different system design
options.
MATE-CON is built upon the Generalized Information Network Analysis (GINA) technique
first developed by Shaw, and used in several contexts as a model for satellites by treating a space
system as a network of information disseminators [215]. Shaw, Miller and Hastings applied
GINA to assess the performance of distributed satellite systems [216], an analysis that was
further refined by Jilla to include multidisciplinary design optimization in a case study for
broadband communications satellites [103,104] (see section 5.1.3). Wood applied it to evaluate
operational complexity in the conceptual design of complex space architectures [266].
4.1.8 MIT, RSC, 2009
MIT’s Multi-Epoch/Epoch-Era Analysis methodologies were developed to enable quantification
of the impact of changing “contexts” (such as changes in budgets, administrations, warfighter
needs or customer needs) on space system architectures. Because these shifts in context often
occur on timescales that are shorter than the development timeline of a space-based system, it
would be beneficial to integrate the consideration of future anticipated needs with current
93
performance constraints and requirements in the design process. These analysis frameworks
utilize MATE to generate large sets of design alternatives for each time context, or “Epoch”.
The Multi-Epoch Analysis method was applied to the design of a satellite radar system by Ross
et al in a Responsive Systems Comparison (RSC) process [198]. The framework is comprised of
the following seven sub-processes:
1. Value-Driving Context Definition, to identify the overall problem and needs
2. Value-Driven Design Formulation, to elicit stakeholder needs (termed “attributes”) and
generate system solution concepts (“design variables”)
3. Epoch Characterization, in which the range of contextual uncertainties (“epochs”) under
consideration are identified and parameterized
4. Design Tradespace Evaluation, where modeling and simulation methods are used to
characterize how key design variables fulfill the overall value-space, measured by
attributes, in certain epochs
5. Multi-Epoch Analysis, which identifies the system designs that are most robust across
differing epochs
6. Era Construction, to develop a timeline of enumerated epochs (“era”)
7. Lifecycle Path Analysis, to develop system value delivery strategies in response to
dynamic contextual uncertainties, as defined by the era timeline(s)
Fitzgerald and Ross later applied the Epoch-Era Analysis approach to the design of a space tug in
a small case study to further illustrate the implications of changing contexts on a system’s value
[60,61]. The authors offer up this “changeability analysis” strategy as a means of quantifying the
value of a system’s changeability (defined here as the ability of the actual design to change, not
94
the design process), enabling a decision maker to justify (or prove against) the inclusion of
changeability despite the additional cost that it necessitates.
4.1.9 NASA, ISE, 2008
The Intelligent Synthesis Environment (ISE) is in development by NASA, the University of
Virginia, and JPL to enable rapid creation of high-science payoff missions and aerospace
systems at affordable cost through. ISE aims to enhance the design, manufacture, and operation
of innovative and cost-effective products through a combination of technologies, including high-
performance computing, high-capacity communications and networking, virtual product
development, knowledge-based engineering, computational intelligence, human-computer
interaction and product information management. The goal is to synthesize the development
process and interlink designers and stakeholders in a way that enables us to effectively design for
the critical characteristics that future aerospace systems must exhibit, including autonomy,
multifunctional materials and structures, modularity, miniaturization, advanced operations, and
robustness in harsh environments.
Indeed, existing tools for mission synthesis, sequential design and manufacturing processes are
still inadequate in these respects [171]. However, the ISE does not appear to have progressed
into operation yet, and the focus still appears to be on a generic design environment for
aerospace missions as opposed to space systems specifically.
95
4.1.10 National University of Defense Technology, SIDE, 2006
Zhao et al developed the Satellite Integrated Design Environment (SIDE) [273] for integrated
multidisciplinary optimization of satellites.
Additionally, Guo et al developed the Collaborative Design and Simulation Environment for
Spacecraft (CDSES) [82], which aims to integrate design and MDO with flexible simulation and
virtual test. The preliminary software tool synthesizes data between Design, Simulation &
Validation, and Engineering Data modules to improve spacecraft design quality, standardize
product development processes, etc. However, little detail is provided regarding the Design
module itself.
Wen-bo et al also generated a model for space system development in which the boundary
between the launch vehicle design and the satellite design, which are traditionally individual
design endeavors, is broken. The authors assert that their new integrated model enables improved
reliability and increased capacity, especially for uncertain and unpredictable missions [258]. This
broadened systems view of spacecraft design introduces a greater opportunity for global
optimization, but inclusion of higher fidelity spacecraft subsystem design information would be
valuable.
96
4.1.11 Princeton Satellite Systems, Spacecraft Control and CubeSat
Toolbox
Princeton Satellite Systems offers the commercially available Spacecraft Control Toolbox
(SCT), which provides a set of MATLAB-based functions for spacecraft design [318]. The
SCT’s main goal, however, is to provide functions for the control of spacecraft, with a focus on
analysis and simulation. It was developed for the design of the Indostar/Cakrawarta-1 transfer
and geosynchronous attitude control systems, and has also been used for the TDRS momentum
management system, and to aid in the development of formation flying systems for some
projects at NASA/GSFC. The Academic Edition provides attitude control system design and
analysis at the undergraduate/graduate-level, while the Pro Edition includes additional software
for estimation and Kalman filters, orbit mechanics and mission analysis, and communication
link, propulsion, and thermal analysis. Additional modules exist for formation flying, fusion
propulsion, launch vehicles, solar sails, and spin-axis attitude determination.
A Cubesat toolbox has been developed as well, which offers spacecraft design specifically
tailored to CubeSats, but applicable to generic small satellites. The applications enable trade
studies, visualization, design of the control system, and analysis of the power, thermal, and
communication systems, among other computations.
Unfortunately, without access to the full MATLAB source code, it is unclear what methodology
is used for the Spacecraft and CubeSat toolboxes.
97
4.1.12 Purdue University, 2003
Hassan and Crossley developed a satellite design approach that attempts to address the ill-
structured system-level concept definition process [87]. The tool, which is comprised of a
satellite sizing model (based on simple design estimating relationships, or DERs) and a
deterministic reliability analysis model, is integrated with multi-objective optimization to allow
the evaluation of a large number design alternatives and subsequent identification of optimal
solutions. The approach utilizes the two-branch tournament Genetic Algorithm, wherein the
operator evaluates the designs against two objective functions independently during the search
process. The result is a set of designs that are [approximately] Pareto optimal for two objectives:
total satellite launch mass and overall system reliability.
The authors applied the tool to the design of a commercial communications satellite to
demonstrate how a structured optimized design process could enable high-performance goals to
be met under the tightly constrained budgets of the space industry. Optimal solutions were those
that best minimized total launch mass while maximizing overall spacecraft reliability (minimized
risks). These two objective functions were evaluated over 27 design parameters, including 14
that described the satellite payload and subsystems and 13 that represented redundancy options
(the parameters include both discrete and integer variables, both of which can be handled by
genetic algorithms). In addition, five constraints were placed on the tradespace, for example that
solar panel and radiator length do not exceed launch vehicle fairing length, etc. The authors
found that the tool’s generation of a Pareto optimal set of designs was helpful in aiding engineers
to identify major design tradeoffs and rapidly evaluate several concepts over two distinct
objectives.
98
While the ability to optimize on these two objectives is valuable, the DER-based design portion
of this approach is overly simplified and only applicable to large communication satellites.
4.1.13 QuickSat/Step_SATdb, 2013
Sci_Zone’s QuickSat/Step_SATdb efforts aim to provide a holistic, web-based approach to
automated concurrent satellite design, analysis, verification and manufacturing based on
customer requirements [208]. The QuickSat SDA (Satellite Design Automation) environment
was originally developed to support the PnPSat program, but aims to be an open source
environment to which other software tools and approaches can be applied. Design wizards and
integration with existing external design tools provides rapid design generation, which relies on
the step_SATdb data architecture “cloud environment” for data management and sharing. The
project has also been leveraged by DARPA to support the development of an open source space
hypervisor program to support the virtualization of space payloads [209].
While little detail is provided regarding the design process itself, it appears to rely largely on past
space programs and empirically drawn relationships from known systems. Reference is also
made to the use of Artificial Intelligence (AI) techniques, in particular Bayesian Networks, to
draw inferences from historical data and observations in order to produce likely designs.
99
4.1.14 Tsinghua University, SDIDE, 2003
Hu et al describe their Spacecraft Distributed Design Environment (SDIDE), led by Professor
You of Tsinghua University’s Tsinghua Space Centre (TSC) and Hangtian Tsinghua Satellite
Technology LTD (HTSL). SDIDE applies the team’s proposed concept of Distributed
Multidisciplinary Concurrent Optimization (DMCO) to enable more rapid and efficient perform
spacecraft design [97]. DMCO is essentially a synthesis of concurrent engineering and MDO,
where collaborative design is enabled by multilevel concurrent optimization methods within a
distributed network computing technology.
4.1.15 TU Munchen, MUSSat, 2000
MUSsat is a concurrent engineering design tool in development at the Technical University of
Munich for use in Phase 0 and Phase A [246]. It attempts to synthesize modeling and simulation
efforts that typically occur across multiple spacecraft design and analysis phases. The approach
would reduce cost, time, and inefficiency by sustaining knowledge throughout the development
cycle via a common database and infrastructure. However, there does not appear to be any
progress since MUSsat’s initial publication in 2000.
100
4.1.16 TU Delft, SCALES, 2009
Aas et al at the Delft University of Technology (TU Delft) developed SCALES, an Excel-based
tool for the conceptual design of micro- and nano-satellites in the 1 – 50 kg mass range [1,2].
Inputs to the tool were synthesized into one worksheet, and included specifications regarding the
payload, mission, orbit, launcher and ground station. Feasible designs were then created via mass
and power budget, operating temperature, attitude accuracy, propellant mass, transmit power and
data rate analyses, as well as algorithms and scaling rules adapted from industry-standard
material that enable scaling of the results down to the smaller satellite class. While the authors
indicated that the full effects of subsystem minimization are not fully known, some preliminary
indications exist. For example, transmission power requirements do not change for a given bit
rate, antenna gain, and orbital altitude, regardless of system size. Similarly, there exists a
minimum structural thickness that enables safe and feasible production, integration and handling.
The contribution of SCALES is thus a set of rules that appropriately scales results from small
satellite conceptual design to be applicable to and accurate for micro- and nano-satellites.
The TU Delft team performed user surveys of candidate tools in order to better determine the
most desirable capabilities and useful set of inputs and outputs. The results indicated five key
user preferences, indicating that the final tool should 1) Be intuitive and easy-to-use; 2) Enable
rapid feasibility analysis; 3) Function without detailed user inputs from the user (conceptual
design level only); 4) Be flexible to users with varying levels of background knowledge; and 5)
Give the user control to manually perform trade-off analysis. In addition, it was observed that
users wanted the ability to manually provide new components into the predefined list, thus
101
allowing for the inclusion of new technology. Last, visibility into interactions between satellite
subsystems was deemed desirable.
Three architecture options were envisioned for the tool. One concept would utilize iteration, a
second option would serially pass design information from the "most important" subsystem
down to the last, or a third option would rely on a combination of the two. Based on an analysis
of which architecture offered the best speed, user control, and reliability, among other features,
the third architecture was selected.
102
Figure 13. Flow diagram of the Thermal Control Subsystem in TU Delft’s SCALES [1]
One observation from the TU Delft team was that users found simplicity and lack of excessive
detail to be an important feature on the input worksheet. Thus detailed calculations were moved
to separate add-on sheets, which could be used by power users if desired. Another observation
was the importance of design flow. For example, the tool initially performed thermal analysis by
first selecting components, then generating the thermal operating temperature envelope, and then
iterating until the design satisfied the thermal constraints. It was found that this was a laborious
103
and inefficient process, and was re-architected such that a baseline thermal envelope was
identified as the starting point, and conceptual designs generated using this as a strict baseline
(see Figure 13).
4.1.17 University of Colorado, SCOUT, 1999
The University of Colorado’s SCOUT (Spacecraft Concept Optimization and Utility Tool)
[163,164] aimed to replace the iterative “change design” approach in spacecraft design and
optimization with an “intelligent search” using genetic algorithms. Mosher et al note that
SCOUT was successful in finding a number of feasible and optimal configurations. However, it
relied heavily on the use of Cost and Design Estimating Relationships (CERs and DERs), and
allowed only a small set of system trades to be enacted to discover alternative configurations.
CERs and DERs, which are parametric in nature and derived from historical data on past space
systems, can be inaccurate and limiting.
While the SCOUT tool was developed almost 15 years ago, many such tools and processes still
rely heavily on CERs and DERs. This approach is in general still widely-accepted due to the lack
of practical alternatives, yet it can lead to poor and severely restrictive results, especially when
dealing with new design contexts. Perhaps a more realistic approach would involve basing cost
estimations and design decisions on as many physically correct, non-parametric “design rules” as
is feasible in the design problem at hand.
104
4.1.18 Other Satellite Design Resources
Other satellite design resources include the Space Mission Engineering: The New SMAD text and
web-based software (previous versions of this text were entitled Space Mission Analysis and
Design, more commonly known as SMAD), Space-Point web services, cost modeling tools, and
the SYSTEMA software.
SMAD is likely the most widely used and relied upon text for designing space systems. The
latest edition provides the equations, algorithms, processes, thumb rules and look-up tables
necessary for satellite design, but it is now also complemented by a web-based portal for design.
Previous literature references intentions of the SMAD editors to create a satellite design tool [1],
although at the time of this writing it is unclear if that refers to this web enabled resource of
support software. At the time of this writing, the SMAD website (www.sme-smad.com) reports
that not all of functionality of the website is complete (for example only 70% of the “Get More”
informational access buttons are available, only 75% of the “Live Calc” Excel-based calculation
functions are complete, etc.).
Space-Point is a database of spacecraft components and their key technical specifications, such
as power, mass, and volume, etc., as well as accompanying information such as level of space
qualification, heritage, and country of origin. The aim of the Space-Point database is to
streamline the important but “tedious” satellite design engineering process, however it is
available only via a fee-based consultation package [62].
105
These design- and component-centric resources are often also accompanied by cost estimation
resources, for example the Aerospace Corporation Small Satellite Cost Model (SSCM) [317] and
NASA’s Cost Estimation Toolkit (CET) [307].
Finally, SYSTEMA
6
is a software tool for multidisciplinary support of space systems
engineering that is in development by ASTRIUM [292]. It offers modules for designing
spacecraft geometry, orbit, mission scenario(s), propulsion and power subsystems, and other
elements, and enables visualization and setup for analysis [101].
4.2 Non-Traditional Design Approaches
A wide range of design considerations can and have been sought in spacecraft design
approaches, from purely cost- and performance-based design metrics, to design for
manufacturing, operation and maintenance, stakeholder preferences [197], etc. This section will
review a selection of past approaches that address the design process in a non-traditional way, or
are developed for the design of specific non-traditional systems.
4.2.1 AFRL, Mission and Satellite Design Toolkit, 2010
The Air Force Research Laboratory (AFRL)’s Mission and Satellite Design Toolkit (MSDT) is a
wizard-driven, push-button “toolflow” environment that automates the design of a plug-n-play
6
Due to its purchase price, the SYSTEMA software was not evaluated in this research.
106
satellite from mission “capture”, to orbit design, to spacecraft design and verification [38]. The
goal is not necessarily to produce the best satellite configuration, but a “good enough” satellite,
as well as the associated required bill of materials [68]. Notably, the bill of materials that is
generated contains not only the necessary components, but also their specifications at a high
enough level of detail to allow configuration of the components within the larger system. To
achieve this, each component in the PnP tradespace is accompanied by an xTEDS (eXtensible
Transducer Electronic Data Sheet) document, which is essentially an Interface Control
Document (ICD) that identifies the component and describes its function, characteristics, and
data exchange information.
Figure 14. Graphical depiction of AFRL’s MSDT toolflow [68]
From the 2006 Cohan et al study [43], the following subsystems were sized according to the
following methodology:
1. ADCS:
107
• Sensors (star trackers, inertial measurement units, sun sensors, earth sensors, and
magnetometers) were sized based on the required payload pointing accuracy
• Reaction wheels were sized based on the desired slew rate and momentum storage
required (the mass of the reaction wheel assembly was obtained using a curve fit
generated from known reaction wheels) [150]
2. C&DH:
• Sized for the processing and data transfer needs of the payload and other subsystems
• Mass, power and volume were estimated using historical information, i.e. SMAD
[262]
3. Communications:
• Sized for the telemetry, command and downlink rates required by the bus
• Link equation determines the gain and power required, which translates into an
aperture diameter with a mass and volume
4. Power:
• Solar arrays and batteries were sized according to subsystem power requirements
over a 1 year mission lifetime
• Assumed 25% efficient gallium-arsenide solar cells and lithium-ion batteries
5. Propulsion:
• Thrusters were sized to perform the necessary desaturation of the reaction wheels,
minor orbit changes, and pre-defined slew maneuvers
• Selection was made from list of available devices, which determined the heat, weight
and power for the thruster and propellant
6. Structure:
108
• Mass and volume of the system were determined assuming constant diameter
stacking modules (where the volumetric efficiency was dependent on whether a
subsystem was modularized or integrated)
7. Thermal:
• Radiator size was determined from orbit and thermal environment, min/max
operating temperatures of components, and internal heat generation
• Selection of passive cooling technique was made from a list of reflective paints and
materials
The bus output was represented by mass, volume, power and cost. The cost included that of the
subsystems themselves (including development costs), testing, launch (assuming a RASCAL
launch, where cost was based on launch mass), upgrades, and inventory. Net Present Value was
calculated using a stochastic model that simulated the effect of selling price, cost and modularity
on demand and profit.
4.2.2 Crowd-sourced Design
Trends in open source software and crowd-designed systems have emerged in the design of
space systems, which enable design efforts that help contribute to the democratization of space.
USC/ISI’s LEAPFROG Generation-X project is leveraging crowdsourced design to develop their
vehicle, which is a “robotic precursor to human exploration of the Martian surface” [175].
109
Moon2.0 is an open source toolkit for low-cost design of the engineering lifecycle phases for
unmanned space missions [243]. The toolkit, developed by Universitat Politecnica de Catalunya,
is meant to support design according to the “Space Payload Paradigm”, which encourages
designing a space mission around its payload and not around the space industry. The team has
used the software toolkit to aid development of the ultra-low cost WikiSat campaign [244].
DARPA’s META and C2M2L programs [300] seek to radically transform the systems
engineering, design and verification processes of innovative defense systems in order to
compress the development timelines of complex vehicles. The META design representation
formalism and design/verification tools will be used in the vehicleforge.mil endeavor, which
aims to realize a crowd-sourced design and collaboration site.
4.2.3 DLR, iBOSS Design Tool, 2012
Weise et al of the DLR describe their computer-aided satellite design tool that is in development
for aiding engineers in selecting and arranging iBOSS satellite building blocks [257]. The
automated tool approaches the design process in three steps: modeling, deducing constraints, and
optimizing. In the first step, the catalog of standardized building blocks (e.g. structural building
block, system building block, etc.) is modeled using OWL, a human readable ontology language.
Then, a greedy algorithm is used to fulfill the identified design rules for the selection of the
appropriate and necessary building blocks, including resultant support systems such as blocks
that provide power. The satellite ontology that is generated from this step is processed by a
reasoner that defines allowable arrangements (considering constraints such as distance between
110
certain blocks and orientation requirements), which are then optimized by an evolutionary
algorithm. The optimizer begins with some legal but random arrangement and iterates a large
number of times (e.g. 500 times) to produce a Pareto-optimal set of solutions.
4.2.4 Parameter Influence Method, 2013
Nemetzade and Forstner, of Astrium GmbH and the University of the German Federal Armed
Forces, use the Parameter Influence Network to examine the influence of design parameter
choices on system design decisions [167]. The authors assert that better design decision methods
are needed, in particular for dealing with design changes that occur as a result of iteration and
recursive design as constraints and requirements evolve. Their approach aims to help identify
how some percentage change in one or several design parameters affects the performance of the
overall system. The methodology consists of the following:
1. System Definition and Modeling (including parameters of interest, relations/algebraic
equations, and a reference design point) to provide a holistic but not overly detailed view
of the system
2. Quantification of Parameter Influence
3. Application into a Graphical Representation, i.e. the “Net”
The approach appears to potentially be useful in time constrained situations when simulation and
test are not feasible. The authors note that the quality of the results depend on how well the
111
system of interest has been modeled, and that this method is not a valid substitution for “good
judgment”. The method was demonstrated in the power subsystem of a satellite in Earth orbit.
112
Chapter 5
Modeling Fractionated Systems
The basic functions of a satellite, distilled to their quintessence, include only the absorption,
processing and subsequent re-radiation of photons. [30]
This chapter reviews existing research efforts for modeling and evaluating fractionated space
system concepts and identifies gaps in existing approaches. As stated by Brown et al, “in order to
design an optimal fractionated architecture, the potential cost penalties due to the overhead must
be balanced against the value enhancement due to improved flexibility and robustness” [34].
While seemingly straightforward, this computational balancing of strengths and weaknesses
requires completely new approaches for measuring value (as described in section 3.5), as well as
a framework that can deal with scenarios based on uncertainties.
5.1 Past Research Efforts
A fractionated space architecture is one in which the functionality of a traditional monolithic
spacecraft is replaced by a cluster of free-flying, wirelessly interconnected modules.
113
Functionality of the traditionally cohabitant subsystems can be distributed (as in “heterogeneous”
fractionation) and/or duplicated (“homogeneous” fractionation) amongst the modules, enabling
the cluster to deliver value that is comparable to or improves upon that of the original monolith,
but with increased robustness to risk and uncertainty [31,32].
The term “fractionated” is often used interchangeably with the similar terms “disaggregated”
7
(or, formerly, “distributed” [291]), where both terms have evolved to represent a system in which
the delivery of value (whether it be images, communication, etc.) from space is accomplished in
a way that departs from the traditional model, i.e. from a large, singly-reliable, highly optimized
satellite into a system where some aspect of capability is decentralized. This can manifest itself
in a variety of ways, from the concept of small satellite swarms, to the incremental launch and
deployment of a constellation, to the existence of an orbiting space-based internet [109]. It is also
closely related to the concepts of cellularization and modularity, which are detailed in following
sections.
There are several possible advantages of deploying space assets in a fractionated architecture,
from launch to on-orbit operations. Considering launch alone, fractionation can enable a more
responsive, or timely, approach to deploying valuable space systems, a cluster-level tolerance to
launch vehicle failure, the ability to launch large and otherwise infeasible architectures, and a
reduction in elemental launch costs via the use of novel, low-cost launchers [29,196]. On orbit,
fractionated space systems can leverage shared on-orbit services and resources to reduce cost
(such as data storage, processing, uplink and downlink bandwidth, command and control
operations, navigation and timing data, and even power or propulsive forces), transfer
7
In this paper, the terms fractionated, disaggregated, and distributed in the context of satellite systems will be used
interchangeably
114
functionality between modules, lessen technology obsolescence, improve survivability, and
others. In addition, fractionation can achieve a diversification of vendors (and with it, increased
competition [31]) and can reduce the barrier-to-entry for participation in the space industry, for
example by launch of “naked” payloads [81,125,293]. Fractionation could also support new or
larger endeavors that are not currently achievable with a monolith, for example the ability to
reconfigure on-orbit to achieve different missions (e.g. radar mode to geo-location mode), or the
synthesis of large apertures, which could benefit technologies such as space-based radar,
detection of slow moving targets in clutter, mobile jam resistant communications and
interferometric imaging [203]. Other programs currently being pursued with fractionated
architectures include coastal salinity measurements [211], a space weather “base” at the Sun-
Earth L5 Lagrange point using CubeSats and solar sails [136], and others.
Lastly, these orbiting resources, as well as the emergence of possible space-based applications or
“apps” that could be hosted on the modules, could of course also lead to possible
implementations that have not yet been conceived. In this way, proponents liken the
transformative potential of fractionation in the space industry to that of microcomputers in the
once mainframe-dominated computing industry. Given the explosive of certain enabling
technologies (i.e. integrated circuits in the computing domain), fractionation could potentially
transform the existing spacecraft paradigm as we know it [31].
It has been noted that the first appearance of fractionation in academic research was in a study by
Molette et al. in 1984 [159]. Based on the hypothesis that increasing communication channels
per space segment will continue to lead to increased satellite mass, size and number, perhaps
exceeding the capabilities of existing launch vehicles, two concepts were envisaged and
compared for a comsat capability: 1) a large platform assembled on-orbit and 2) a cluster of
115
satellites. The concepts were evaluated based on adaptability to other missions, flexibility and
growth potential and a cost/benefit analysis was presented for each. While the authors concluded
that the cluster of satellites was less cost effective than the assembled platform, this is based on
results that do not account for any quantified value-add from the flexibility, adaptability or
growth potential [81].
The concept of fractionation has since been studied extensively in academia. A selection of
research is reviewed in the following sections, as well as a summary of the state of the art of
critical enabling technologies.
5.1.1 2003 – de Weck
As discussed by De Weck et al [254], disaggregation of a space system enables assets to be
deployed into operation in a staged manner instead of all at once, which offers various benefits.
This incremental launch strategy lowers the cost of an investment by spreading the expenditures
over time, a clearly advantageous approach due to the time value of money and the large costs
implied by deployment of a space system. The relationship is expressed in the commonly known
present value equation, where Q is the cost of a deployed asset, PV(Q), is the present value of
this cost, which is discounted according to the discount rate, r, and the discount period, or time to
deployment, t:
𝑃𝑉 𝑄 =
!
!!!
!
(9)
116
It also reduces the impact of launch vehicle failure on a system (i.e., placing the proverbial
‘eggs’ of a space system across multiple ‘baskets’), allows for inclusion of technological
advancements and thus minimization of obsolescence, and enables the modification of an
investment according to changes in the market (i.e., reduction or increase in capacity to
accommodate lower or higher demand than expected, respectively).
De Weck et al. examined the value of staged deployment in a communications satellite system
[255], and found that it could have significant potential for the commercial LEO business case.
While the staged deployment approach can reduce economic risks (or exploit unexpected
opportunities), it poses new design challenges as well. First, possible evolutions between
architectures (i.e. initial fielded system to higher capacity system) must be identified, understood,
and modeled. This is difficult due to the fact that legacy components will inherently be involved,
reducing the number of design degrees of freedom in later stages of the system. Second, it is not
immediately clear how much one should invest in order to embed this flexibility into their
system, i.e. how much flexibility itself is worth. Last, the uncertainty in demand must be
modeled and integrated into the design process.
The analysis, based on a framework originally developed by de Weck and Chang [253], aims to
find the optimally flexible architecture for enabling designers to adapt to the resolution of market
conditions over time using Real Options. The authors explain the traditional approach of sizing
the capacity requirement based on market studies, and then designing the constellation and
satellites to meet this requirement while minimizing life cycle cost (LCC), a figure that includes
the costs of Research, Development, Test & Evaluation (RDT&E), manufacture, launch,
deployment and checkout, ground stations, operations and replenishment. The trade space is
produced by varying the design variables in design vector x:
117
𝒙= ℎ,𝜀,𝑃
!
,𝐷
!
,𝐼𝑆𝐿 (10)
(where h is the orbital altitude, ε is minimum elevation angle, P
t
is transmitter power, D
t
is
antenna diameter, and ISL represents the use of intersatellite links) within a multidisciplinary
simulation, then mapping each resultant design to the corresponding capacity and LCC.
In the flexible approach, a subset of the variables in the design vector are considered to be
evolvable, and architecture “paths” are produced that represent the evolution from one
architecture to another based on changes in these variables. The real options available to the
designer for accomplishing these evolutions, or future deployed stages, are captured as additional
propellant and phased array antennas for beam pattern tuning. Finally, market uncertainty is
represented in a Monte Carlo simulation of demand, which is modeled to follow a geometric
Brownian motion, given by the following equation commonly used to describe the price of a
stock, S:
∆!
!
= 𝜇∆𝑡+𝜎Γ Δ𝑡 (11)
Here S represents the current stock price, Γ is a random variable with a standardized normal
distribution, 𝜇 is the expected return per unit time on the stock (or, in this framework, increase in
demand, which is set to 20%), 𝜎 the volatility of the stock (or volatility of demand, set to 70%),
and Δ𝑡 is the time step, such that
∆!
!
is the rate of change of the stock price (or the demand)
during Δ𝑡. The final lifecycle cost of the flexible system can be compared to that of the
traditional system – if it is less, this defines the maximum price one would be willing pay to
embed this flexibility. If not, then other avenues of flexibility should be explored.
118
The results of de Weck et al’s study showed that it is indeed preferable to launch a set of small,
affordable satellites initially and add to them over time than it is to deploy a single constellation
of a few high-powered satellites, confirming the value of staged deployment.
Staged deployment has been studied in other domains as well, including water supply
infrastructure [187] and fusion materials irradiation facilities [233].
5.1.2 2004 – Brown and Eremenko
The concept of fractionation has been explored in depth by Brown and Eremenko beginning in
2004 [29]. Central to their research is the assertion that a space system's true value is derived
from more than just the intrinsic capability it offers, i.e. the singular value provided by a unit of
communications bandwidth or unit of area of coverage. These systems also must offer some
level of assurance that the primary service or capability being delivered can be done so robustly
in the face of both anticipated and unanticipated risks. The authors suggest that these
uncertainties can be at least somewhat mitigated in a system simply by distributing or
disaggregating some aspect(s) of the architecture. This approach emphasizes the value of
architectural robustness, which while desirable, is traditionally considered to be less important
than performance and/or cost optimization in the domain of space systems. But while
fractionation can likely imply a more costly, heavier, and/or more complex system due to
increased parts, interfaces, and other overhead, these are effectively traded for reduced
complexity at the mission level. Such an architecture offers other advantages as well, for
119
example in permitting a system’s performance to degrade gradually, or the ability to increase or
decrease its service levels easily [32].
The physics of a spacecraft’s support subsystems can be conducive to fractionation as well. For
example, strict payload requirements often drive pointing, and by physically decoupling it from
the other subsystems, it relieves them of the same strict requirements. This has also been
investigated by O’Neill and Weigel [172] and Xu et al [268]. In addition, smaller inertias of the
separated payload module ease ADCS constraints, structural dynamics and vibrations.
In order to prove these advantages, however, they must be quantitatively demonstrated through
computational modeling. To accomplish this, Brown, Eremenko and Roberts evaluated the
potential advantages of fractionation in a notional satellite communications (SATCOM)
architecture in 2006. The analysis was based on stochastic calculations of total system lifecycle
value and cost under uncertainty using Monte Carlo simulations [30]. Value was considered to
be derived from four sources: 1) the value of the service being provided (e.g. a unit of
bandwidth), 2) the additional service gained by being able to incrementally deploy the
constellation as well as gracefully degrade if one or more modules individually experience
failures (including via hostile actions), 3) the flexibility to increase service levels in response to
increased demand, and 4) reduction in lifecycle cost risk, quantified using a self-insurance model
with industry average rates. A simplistic cost model was generated based on Cost Estimating
Relationships (CERs) from SMAD [131].
The operational modules were modeled to produce discrete cash flows throughout the time
history of the system, which were summed to represent the total monetary value being delivered.
Valuations for incremental service and service level flexibility were derived from de Weck, de
120
Neufville and Chaize, who considered the variance in number of users and level of activity in the
context of communications satellites [254]. Historical data in a RAND Corp. study by Bonds et
al was then used to compute the volatility of demand. The value of having the flexibility to
increase service levels is likened to a “call option” in the economic sense, and was thus
expressed using the Black-Scholes equation (refer to section 3.5 for further detail). Value of
reduction in lifecycle cost risk was calculated using a self-insurance analogy, where premiums
were estimated based on industry average rates provided by the Department of Transportation.
Finally, the utility of satellite communications in a military context is difficult to discern due to
the absence of a market-based, monetary need for the asset. Thus, the authors use Multi-Attribute
Utility Theory (MAUT) to establish the utility of the calculated availability. MAUT enables the
construction of a composite utility function comprised of single-attribute utility functions and
weighting coefficients. To elicit the single-attribute utility functions, the authors use the lottery
equivalent probability approach (LEP) in interviews with decision makers, which has been
shown to reduce bias in responses. Then, by tying one attribute to a well-known market based
value, it is possible to infer the utility of the non-market based attributes based on the relative
weightings. The authors used this calibration method to infer the utility of availability based on
the commercial market value of communications bandwidth, thus translating this dimensionless
ordinal into dollar terms [33].
The model was exercised to produce sample results. In one specific case in which small failures
and one catastrophic failure are modeled to occur, it was shown that the present value of total
lifetime value delivered by the system minus the total lifecycle cost could prove to be positive in
the fractionated SATCOM use case, whereas it could be negative in the monolithic case. Thus
the use of fractionation in such a scenario may be a cost-effective decision [30]. These findings
121
contributed to the birth of DARPA’s System F6 (Future, Fast, Flexible, Fractionated, Free-Flying
Spacecraft united by Information eXchange) Program, which aimed to demonstrate the
feasibility of spacecraft fractionation (the first instantiation of which began in 2008, with a
follow-on program in 2011) [173].
5.1.3 2004 – Jilla
Jilla and Miller describe a methodology developed for multi-objective, multidisciplinary design
of distributed satellite systems (DSS) [104]. The work was not explicitly designed to treat
fractionated architectures, but a DSS is defined as “a system of multiple satellites designed to
work together in a coordinated fashion to perform a mission”. The wealth of design trades that
the designer of a DSS must face are also directly applicable to fractionated architectures, for
example number of spacecraft in an array, orbit and thus launch vehicle (which is also influenced
by the number and size of spacecraft that need to be deployed), formation flight considerations,
etc. And since the design problem is combinatorial, very large design tradespaces can ensue.
These large tradespaces, which often contain discrete variables in nonlinear relationships, are
intractable by linear optimization techniques and integer programming methods. Thus, an
algorithm that can handle discrete variables, nonlinear problems, and multi-criteria objectives is
needed for this type of analysis.
The authors developed the Multiobjective, Multidisciplinary Design Optimization Systems
Architecting Methodology (MMDOSA) for their analysis. Within this framework, the DSS
architecture is modeled as a generalized information network analysis (GINA) (described in
122
section 4.1.7), which treats satellites as disseminators of information, and thus the satellite
system as an information transfer network. This allows the engineer to use the same quantitative
metrics to characterize architectures that may physically be very different. To select the proper
optimization algorithm, four single-objective optimization algorithms were run to identify the
best performing technique for this problem: Taguchi methods, heuristics (simulated annealing),
gradient methods, and univariate methods. The simulated annealing algorithm was found to most
consistently and accurately identify the optimal solution, and thus was employed in MMDOSA.
With this, the authors produced two new multi-objective variants of the underlying heuristic
optimization algorithm, single-solution and multiple-solution, for use in architecting conceptual
DSS designs.
5.1.4 2005 – Chaize
A study by Chaize and Weigel [39] examined fractionation by comparing the lifecycle costs
(LCC) of several fractionated satellite architectures (using navigation and communications
satellites) with monoliths from a customer perspective. Using Multi-attribute Trade-Space
Exploration, the authors found that fractionation can be sufficiently compelling to a customer if
non-traditional attributes (Figure 15) are valued highly enough. They were able to identify two
fractionated configurations with significantly lower LCCs, both of which involved a break-out of
the communication, data handling and computation functions onto one or more modules. O'Neill
and Weigel later looked at how pointing-intensive, remote sensing missions specifically may be
123
conducive to fractionation due to the advantages derived from physically decoupling subsystems
and payloads with strict pointing requirements [172].
Figure 15. Definition of attributes according to change and response framework [39]
5.1.5 2006 – Rooney
In 2006 Rooney assessed the cost-effectiveness of fractionation using the existing Boeing 601HP
geostationary communication as a use case. His study, based on Design Rules [81], indicated that
lifecycle costs were significantly higher in the fractionated scheme. The system overhead and
duplicated functionality outweighed the economies of the cheaper, smaller launch vehicles.
However, the econometric framework in Rooney's study also did not consider the value gained
from adaptability [196].
124
5.1.6 2007 – DARPA System F6 VCDM
In the first of two System F6 (Future, Fast, Flexible, Fractionated, Free-Flying Spacecraft united
by Information eXchange) efforts, four major space industry teams (Boeing, Lockheed Martin,
Northrop Grumman and Orbital Sciences) competed in the development of Value-Centric Design
Methodologies (VCDM) to enable a quantitative comparison of the risk-adjusted values of
fractionated and monolithic systems [173], thus supporting the design of fractionated satellite
systems that are optimized for net lifecycle value [34]. Of these teams, Northrop Grumman [92]
and Lockheed Martin [142] both developed System Value Modeling (SVM) tools. Lockheed
Martin focused on the comparison of the net present value utility of candidate architectures using
Generalized Information Network Analysis and Time-Expanded Decision Networks. Orbital
Sciences and Boeing developed the Pleiades Innovative Value Centric Design Methodology
Optimization Tool (PIVOT) [58] and the Risk Adjusted, Flexible Time Integrated, Free Flying,
Multi-Attribute Tradespace Exploration (RAFTIMATE) [151], respectively. A summary of the
approaches is provided in Table 5.
Table 5. Summary of DARPA System F6 VCDM tools. Adapted from [34] and [173]
Organization Tool Supported
Missions
Findings
Lockheed
Martin
SVM (System Value
Modeling) Tool
Remote
sensing
payloads
only
• Only VCDM tool with a GUI (Excel-
based)
• Least # database inputs (26)
• Least # architecture inputs (28)
• Only tool to consider Wireless Power
Transfer
• Value is represented by NPV
• Model is able to run custom scenarios
125
Northrop
Grumman
SVMTool (Space
Architecture Design
and System Value
Modeling Tool)
Remote
sensing
payloads
only
• Highest # architecture inputs (197)
• Value is represented by utility vs.
lifecycle cost
• Model is able to run custom scenarios
Orbital
Sciences
Corporation
PIVOT (Pleiades
Innovative VCDM
Optimization Tool)
Remote
sensing and
telecommuni
cations
payloads
• Tool does not allow user to disable
inclusion of enabling technologies
• Value is represented by NPV
• Demo-oriented model, unable to run
custom scenarios
• Produced negative EPNV in all six
applicable use case runs
• Potentially inconsistent declarations
of variables locally vs. globally in
underlying models
Boeing RAFTIMATE (Risk
Adjusted, Flexible,
Time Integrated,
Free-Flying, Multi-
Attribute
Tradespace
Exploration)
Remote
sensing
payloads
only
• Highest # database inputs (1,433)
• Value is represented by benefit vs.
present cost (and also as dollar value
using a “monetizer” feature)
• Demo-oriented model, unable to run
custom scenarios
The driving objective behind the VCDM tools was to close the business case on fractionation,
i.e. identify where the cost penalties due to the additional overhead were outweighed by the
increase in value due to enhanced flexibility and robustness. To do so, the four performing teams
modeled reference scenarios and evaluated them based upon their net present values (NPV) and
volatility of NPV. Each of the four tools used MATLAB as a back-end for the necessary
computations, and each tool in some fashion performed discrete event simulations with Monte
Carlo Analysis (MCA) to generate a spacecraft lifecycle simulation (Figure 16 depicts the
common high-level modeling approach in each of the tools).
126
Figure 16. High-level approach to modeling and simulation in the F6 VCDM effort [173]
None of the teams integrated optimization into their tools, but instead focused on being able to
perform trade studies and then employ engineering judgment for final selection. The four teams
also provided final conjectures or “thumb rules” that emerged from their analysis of past,
existing reference missions. Unfortunately, Brown, Eremenko and Collopy cite that the rules
generated by the teams offered little insight beyond common sense engineering judgment. Or,
conversely, the rules seemed to suggest broad, unrealistic overgeneralizations. This is likely due
to budget and time constraints, as well as the inability to draw sound generalizations from the
very limited set of legacy systems that were analyzed. Lastly, while the VCDM tools produced
did utilize rigorous Monte Carlo simulations to model detailed life cycles, the inclusion of
optimization would greatly enhance the utility of the results generated. Unfortunately, because
Monte Carlo processes are necessarily random, employing numerical optimization would prove
difficult. In addition, the run times would likely be extremely long with the addition of
optimization, thus necessitating a simplified model in order to make the tool usable in an
engineering setting [34].
127
O’Neill et al [173] provided an in-depth qualitative and quantitative evaluation of the tools
across four categories: 1) model structure and implementation; 2) input specification; 3)
inclusion of enabling technologies; and 4) outputs and value proposition quantification. The
study also compared the performance of each tool using eight case study missions with varying
architectures, orbits, and lifetimes as a common use case. However, of the eight use cases, half of
them were “modelable” (i.e. all necessary parameters could be captured by the tool’s model) by
either three or all four of the tools. The other half of the cases were modelable by none or only
one of the tools. Because of this, it is difficult to ascertain the soundness of any one tool’s results
over another’s with respect to the specific use cases put forth in this study, which the authors
recognized. (In addition, the authors of this study make remarks in their discussion of the case
study results about the lack of instances in which fractionated architectures have both higher
utility and lesser cost than the monoliths. It should be noted that this is not necessarily a useful
interpretation of the results, since a key facet of value-centric design is that cost reduction should
not necessarily be a guiding design metric.)
Nevertheless, the study produced interesting results with respect to the value of fractionation
over traditional systems. Only one of the four tools, NG’s SVMTool, actually generated results
that were favorable to fractionation in the specified use cases (although, the monolith still had
lower lifecycle cost). The RAFTIMATE and SVM (LM) tools produced results favorable to
monoliths. The results of the PIVOT tool were essentially inconclusive - this tool was discovered
to have possible consistency issues with the declaration of its variables locally and globally in
the underlying models, which severely reduces the trustworthiness of any results. Indeed, for all
six of the applicable use cases the OSC PVIOT tool was able to model, the resultant expected
NPV (ENPV) figures were actually negative.
128
Interestingly, at the end of the base period, the Orbital Sciences Corporation was the only team
downselected to move forward into Phase II of the program for further refinement of its PIVOT
VCDM tool.
To complement the first investigation of the four VCDM tools, O’Neill et al also performed a
multi-disciplinary and objective optimization (MDOO) of the PIVOT tool. Three MDOO
algorithms were employed: genetic algorithm, simulated annealing, and full-factorial search.
Design variables used were orbit altitude and module lifetime, which were selected via a design
of experiments. The objective function values were averaged over numerous MCA trials to yield
mean program cost and program revenue. A number of challenges were discovered in this
secondary investigation, including the inability to alter the PIVOT code directly (primarily for
configuration control reasons), insufficient documentation for adequately understanding the
working assumptions of the tool and exploring the results, and the fact that any proprietary data
had been “scrubbed” from tool, resulting in models that were heavily reliant on publicly
available, generalized relationships (and, thus, questionably accurate study results). All three of
these constraining conditions are common and well-known challenges in the world of computer-
aided tools for space system design.
Most importantly, however, was the realization that optimizing an objective function that is
stochastic in nature is quite different than with deterministic functions. Due to the randomness
inherent in non-deterministic functions, the ability to find maxima and minima and thus converge
is challenging at best. The solution stability of MDOO methodologies in VCDM tools is
significantly inhibited due to the nested uncertainties, and thus non-deterministic functions, these
tools necessarily exhibit.
129
After studying the four VCDM tools delivered as part of the first DARPA System F6 program,
O’Neill et al made a set of recommendations for future tool development:
1. Tool composition
a. Employ a hierarchical spacecraft architecture characterization. Decomposition
into varying levels of detail (e.g. spacecraft, module, subsystem, component)
facilitates tracking of architectures from inputs to outputs.
b. Employing a bus and payload database (COTS and/or custom) would be helpful
for designing and sizing a given architecture based on real-world systems
c. Employ a centralized, non-redundant data input (structure) to ensure consistency
of variables and tracking of input/output relationships
d. A capable user interface would be necessary to bridge the gap between effective
user-specification of inputs and subsequent dissemination of inputs to the
underlying simulations.
2. Need for upfront definition of desired model functionality – for example, is it a point
design tool or a tradespace exploration tool? Knowing the answer to this question is key
in controlling the tool’s development.
3. Further incorporation of mission valuation capabilities, i.e. inclusion of value-based risk
in addition to technical risk, would be desirable.
130
5.1.7 2008 – LoBosco
LoBosco et al of proposed the Pleiades architecture for achieving responsive access to space via
the rapid launch of modules or retasking of existing modules [139]. In their approach, modules
can be produced more quickly and cheaply due to single-string design (reliability is achieved
through redundancy) and economies of scale. This lowers the barrier to deploying space assets
for space agencies and other organizations that otherwise cannot afford it. The authors suggest
that their fundamental innovation and the key to fractionation is that of information integration,
and not physical decomposition. Current space systems possess stovepiped architectures that
inhibit information movement between elements (including ground), which precludes them from
meeting evolving mission needs. Distributed computing, supported by wireless communications
and packet networking, is then the major enabler of fractionated spacecraft.
In their analysis, fractionation of core subsystems is not attempted or modeled due to the belief
that significant technology breakthroughs must first occur in order for these to be feasible.
Instead, they decouple the payload, which allows for necessary development of electro-optical
(EO) sensors to occur (which in their analysis are not available at the time of initial system
deployment), enabling launch of a more mature sensor to occur sooner.
131
5.1.8 2009 – Lafleur
Lafleur et al developed the Georgia Tech F6 Architecture Synthesis Tool (GT-FAST), a point
design tool for rapid sizing and synthesis fractionated spacecraft, which aims to enable a
combinatorial analysis of the tradespace of architectures generated in the exploration of a
fractionated system. The authors argue that the two key systems analysis challenges that exist for
the architecturally complex concept of fractionated spacecraft include the ability to 1) perform
comprehensive and systematic generation of candidate architectures, and 2) evaluate and
quantify the cost and benefits of each in order to accurately rank them. Thus the goal of the
Georgia Tech research is to navigate and identify Pareto-optimal architectures in the expansive
pool of architecture options that emerges as new fractionable component choices are brought into
consideration [126,127]. GT-FAST enables a probabilistic cost analysis of various candidate
architectures [126,127], and it was used as the design generator for the Orbital Sciences team’s
approach in the F6 program [33].
5.1.9 2009 – O’Neill
Pointing-intensive, remote sensing missions may be conducive to fractionation because of the
ability to physically decouple subsystems and payloads with strict pointing requirements. An on-
orbit configuration of a central module surrounded by a circle of supporting infrastructure
modules is assumed in this 2009 study by O’Neill and Weigel [172]. The research hopes to fill in
gaps in existing fractionation studies with a high-fidelity, dynamic quantitative assessment, use
132
of cardinal, “traditional” measures of effectiveness (MOE), and an exploration of value
propositions in both breadth and depth. Assumes 22 launch vehicles, 20 lifecycle & design
parameters, and 112 spacecraft architecture parameters. No aspect of the physics-based model
relies on parametric models. The criteria for the launch vehicle(s) selection are to minimize the
aggregate launch vehicle cost and maximize reliability (cost and risk-averse). Some results: as
the use of shared resources increases, the mass tends to increase. Sharing Comm/CD&H and
ADS/GNS resources, but not power, leads to the most lifecyle cost (LCC)- and mass-competitive
method of shared resources in fractionation. As ground resolution decreases (i.e. lowered
performance), the LCC-competitiveness decreases (i.e. there is less of an incentive to decouple
the pointing payload from its support subsystems).
5.1.10 2011 – DARPA System F6 VCAD
The second of two F6 efforts commenced in 2011, wherein six teams were selected to provide
software tools and research within the VCAD technical area: NASA’s Jet Propulsion Laboratory
(JPL), Stevens Institute of Technology, University of Southern California Information Sciences
Institute (USC/ISI), Catholic University, and Xerox PARC. USC/ISI’s approach to tradespace
analysis of architectures in a Shared Space Imager “SSI” problem [301] utilized the declarative,
SPIDR-based approach described in this study, and further detail is provided in Chapters 8 and 9.
JPL and Stevens were down-selected to continue their research, which focused on the delivery of
a GUI-enabled design tool and a set of theoretical research to DARPA, respectively.
133
JPL produced the Adaptable System Design and Analysis (ASDA) tool, which simulates
lifecycle cost and value of monolithic and fractionated architectures given the occurrence of
specific “stimuli” (e.g. launch failure, funding delay, orbital debris event) that occur during their
lifetimes, and the Embedded Real Options (ERO) that exist in response to these events. ASDA
calculates the value of each architecture and the associated Options in order to quantify the
desirability of alternative candidate designs in terms of their adaptability and survivability. The
set of uncertainties that the model considers and the associated ERO are summarized in Table 6.
The ASDA environment consists of a JPL-developed spacecraft Discrete Event Simulator (DES),
a cost model based on the Aerospace Corporation’s Small Satellite Cost Model (SSCM), design
models based on industry-standard (i.e., SMAD) Cost and Design Estimating Relationships
(CERs and DERs), a payload model based on the NASA Instrument Cost Model (NICM) [84], a
standard spacecraft bus catalog, and a set of modeled stimuli. These models are wrapped and
integrated in ModelCenter, a COTS software package provided by Phoenix Integration [45,56].
Table 6. Uncertainty types and associated embedded real options (ERO). Adapted from [45]
Adaptability Uncertainty Type Embedded Real Options
Technology Development Risk Option to Switch Technologies
Option to Suspend/Slow Ancillary Developments
Supply Chain Delays Option to Switch Payloads
Option to Switch Technologies
Option to Suspend/Slow Ancillary Developments
Changes in User Needs Option to Switch Payloads
Option to Discontinue
Option to Abandon
Option to Accelerate Development
Option to Switch Technologies
Program Funding Fluctuations Option to Defer Development
Option to Accelerate Development
Option to Delay Launch
134
Option to Switch Technologies
Option to Switch Payloads
Option to Discontinue
Option to Abandon
Technology Obsolescence Option to Abandon
Option to Switch Technologies
Option to Delay Launch
Option to Accelerate Development
Option to Switch Payloads
Survivability Uncertainty Type Embedded Real Options
Launch Failure Option to Accelerate Development
Option to Not Replace
Operator Failure Option to Accelerate Development
Option to Not Replace
Component Failure Option to Accelerate Development
Option to Not Replace
Orbital Debris Option to Accelerate Development
Option to Not Replace
Collision Option to Accelerate Development
Option to Not Replace
Stevens’ research focused on measuring the value of adaptability and flexibility in uncertain
systems, and how uncertainties, complexity, and requirements affect the ability of a system to
exhibit these attributes. They developed an Adaptability Measurement Framework that aims to
better capture the value of fractionated space systems where other predominant methods fail,
namely optimization with Monte Carlo simulations and the Black-Scholes equation. The former
approach, the authors assert, is unable to differentiate between the different types of uncertainties
since the application of numerical optimization on top of stochastic, random simulations is
invalid. And while the latter approach is able to make this distinction, they argue it has “limited
applicability”, and may even be unnecessary if a discrete event simulation of a system’s lifecycle
already exists [169].
135
5.1.11 2011 – Daniels
Daniels et al studied the effect of management decisions on net present value of a fractionated
satellite constellation using two analysis models: a heuristics-based decision model with Monte
Carlo simulation to produce value distributions; and a multi-stage decision process model
utilizing dynamic programming to find value-optimal decisions [49]. The analysis used a generic
DoD meteorological satellite program (comprised of two payloads distributed across three
wirelessly connected spacecraft modules) as a case study, and aimed to quantify when the design
flexibility introduced by fractionation demonstrated realizable benefits. Their investigation
concluded that the cost and schedule risk of fractionation do not make it desirable for space
system decision makers.
5.1.12 2011 – Kwon
Kwon and Cheplak investigated promising potential applications of fractionation. They suggest
that the NASA A-Train, a distributed space system, is ideal for fractionation. The string-of-pearls
formation of such systems is well-suited due to the simplified geometry and the benefit that can
be gained from utilizing in-track resources. Distributed space systems also allow small and large
companies to expand capabilities in smaller instruments and can benefit underserved markets
(who seek/require cost-effective access to space). Kwon emphasizes three examples of
applications specifically enabled by the F6 program, including resource sharing (specifically data
136
storage), transfer of functionality to a different module, and addition of a new module [125]. The
authors assert that “fractionation is intended to be an evolvable architecture driven by value.
Given sufficient value, then the architecture will adapt, thus expanding the market”.
5.1.13 2011 – Tamaskar
Tamaskar and Delaurentis first analyzed a special “modular architecture” case of fractionation in
which one or more dedicated payloads is supported by a set of support modules that are each
identical (heterogeneous) [234]. Finch and Delaurentis then proposed the idea of dichotomous
spacecraft, essentially a simplified form of fractionation wherein the payload and support
subsystems are physically decoupled. This so-called “orbit bus/payload split capability” would
allow a satellite/mission reconfiguration to occur only by changing out the payload [59].
In 2011, Tamaskar et al built upon these earlier results to compare complexity values of
monolithic, fractionated and modular systems, using the Terra spacecraft for demonstration
(motivated by [172]) [235]. Their framework 1) represents the system at an appropriate level of
abstraction, 2) generates the structural and functional system representations, 3) maps the
functional representation onto the structural graph, and 4) calculates complexity of the weighted
network. Their work extends that of Summers and Shah to include measurement of coupling
complexity that accounts for directivity, weighting, and feedback loops. It also includes a
“design practices factor” that accounts for reduction in coupling via modularity. The structural
graph is based on similar depictions found in SMAD [131] and Reducing Space Mission Cost
137
[263]. The results show that fractionated architectures do exhibit greater system complexity than
modular ones, but both have increased robustness and flexibility relative to monolithic.
5.1.14 2012 - Yao
Yao et al created a fractionated spacecraft system assessment tool that uses a stochastic lifecycle
simulation based on uncertainty [270]. The authors assert that two general approaches exist to
quantitative, multi-attribute assessment of fractionated spacecraft: 1) Express value of system
attributes in terms of monetary units (i.e. revenue and cost) [in this paper, a stochastic lifecycle
cost metric which is adjusted to account for cost impact due to dealing with unforeseen events, or
'uncertainties', such as launch failures; and a net present value (NPV), or the total stochastic
value delivered to the user minus the cost expenditure over the lifecycle of the system] and 2)
Express value of a system through multi-attribute utility theory (MAUT), where attributes are
scored against decision maker-established criteria and then aggregated into a single synthetic
utility value.
In 1), there are a few different approaches in the literature. I) Uncertainties are modeled as
random variables with some assigned probability distributions and a stochastic lifecycle cost and
value is produced using Monte Carlo simulations (where mean and standard deviation of NPV
and cost are key), and II) Uncertainties occur deterministically at a specific modeled time (i.e.
JPL ASDA's Pre-Planned Surprises)
138
Failure profiles defined to describe the performance uncertainties exhibit high likelihood of
failure in the infant and wear-out (end of life) periods of the spacecraft lifetime. In the middle
operation period, the failure rate is stable and low. The exponential model is used to characterize
the distribution of failure probability with failure density function f(t), where lambda is the
constant failure rate (according to the MTTF, θ = 1/λ).
𝑓 𝑡 = 𝜆𝑒
!!"
(12)
The author notes that the infant mortality and end of life failure rates are assumed to be 5% for
ease of calculation. Future work could assign a failure rate based on TRL/heritage to better
capture the value of higher reliability components and architectures. (Note, however, the authors
do consider TRL when applying cost growth uncertainties)
The authors also identify four logical failure scenarios (bus failure equating to module failure,
single-string component failure equating to module failure, redundant components must all fail
to equate to module failure, and multi-type components must all fail to equate to module failure),
and the circumstances in which a replacement module is deployed (the functionality is not
existent elsewhere in the cluster).
In this paper, a simple NPV model taken from the Lockheed Martin SVM tool is used, where
revenue R = N
Payload Data
* P
Data Price
, where N is the total amount of payload data downloaded by
the user, and P is the data price which is determined by resolution and size. The NPV is also
adjusted to account for uncertainty in orbit altitude fluctuation due to Earth oblateness,
atmospheric effects, and orbit insertion accuracy, which directly affects payload resolution and
communication access (i.e. downlink) time.
139
All conclusions seem to note that fractionated architectures exhibit higher risk adjusted NPV but
also increased cost. This is an obvious conclusion as the overhead of multiple buses and launch
vehicles is not trivial. Decision of which is optimal still appears to be somewhat subjective.
However, the authors are able to identify, in one conclusion, two schemas that exhibit
comparable cost and NPV but where one schema demonstrates significantly lower standard
deviation.
5.1.15 2013 - Aliakbargolkar
Aliakbargolkar applied the Stakeholder Value Network (SVN) modeling methodology to
examine the viability of Federated Satellite Systems (FSS) in commercial applications [11]. The
authors explored the development of opportunistic cloud computing in space: their vision is to
create a virtual network, i.e. an infrastructure of heterogeneous satellites each equipped with an
FSS plugin payload that allows the satellites to trade resources (e.g. the space equivalent of a
WiFi PCMCIA card). Benefits include scalability of capacity (both up and down), secondary
streams of revenue for supplier missions (in particular science and human spaceflight missions –
from the ISS), enabling new missions by repurposing partially failed spacecraft, enabling use of
small satellites in new contexts because of the ability to leverage FSS infrastructure capacity,
ability to communicate to nearest node on the network instead of all the way down to earth
(lessening requirements on link budget), and improved reliability. Of course technical “costs”
exist as well, for example the necessary inclusion of tracking antenna and avionics to handle fast
handovers, new communication and interface control protocols, and programmatic risks
140
introduced by FSS. Policy “costs” or issues exist as well, for example stakeholder acceptance,
etc. Stakeholder value network (SVN) was developed to better understand and characterize the
impact of stakeholder in order to gauge the viability of a concept such as FSS. SVN was first
introduced at MIT Systems Architecture lab.
It is noted that the concept is very similar to the use of a standardized technology package and
radio, namely the F6TP and F6 WICS, which were proposed and developed in the DARPA
System F6 program.
5.1.16 2013 - Salado
Salado and Nilchiani analyzed the effect of decoupling conflicting requirements by fractionating
into physically separate modules in order to isolate dependencies [201]. To do this, the authors
created networks depicting how requirements and associated design attribute affect and are
influenced by each other (for example, increased pointing accuracy lessens the requirement for
transmitter EIRP, which then reduces required power, etc.), which are then used to show how a
designer can decouple the most critically interdependent requirements into separate “fractions”
(modules). This approach reduces the impact of requirements change, as dependencies seem to
decrease, changes do not propagate outside fractions, and the impact of development uncertainty
decreases. They concluded that fractionation thus has advantages both on orbit and also in
development, as it can resolve conflicting objectives and reduce risk in programs with highly
volatile requirements. However, their study fails to consider the overhead that will also be
introduced via this approach, i.e. increased mass and power, more launches, and added
141
operations. In order to quantify the benefits, tangible metrics are needed to accurately show the
tradeoff.
5.1.17 2013 - Xu
Xu et al studied the benefits of fractionation in remote sensing missions due to the ability to
physically decouple the pointing-intensive imaging payload, thus reducing lifecycle costs
[268].The authors used an unscented transformation to stochastically model the uncertainties
during a mission, and applied genetic algorithm optimization to quantitatively identify winning
architectures.
5.2 Enabling Technologies
Previous research efforts have also looked at the development of certain enabling technologies,
which will be critical to the ultimate success of fractionation.
In [33], Brown identified four such key technologies: networking, wireless communication,
cluster flight and distributed computing. The concept of networking in for distributed, adaptive
and real-time applications found fractionated architectures poses a significant challenge, in
particular to the dynamic nature of the applications, autonomous adaptation that must exist as
system resources change, and multi-level security [265]. Wireless power transfer would enable
142
the fractionation of the power system such that each individual model would be freed from
having to generate its own power, and instead must only be equipped with a receiver that can
collect power transmitted from another module acting as the source.
A 2009 survey from University of Delft provided an overview of the state of the art of
fractionation technologies. Based on their study, they summarized the Technology Readiness
Level (TRL) of four fractionation enabling technologies [81], as shown in Table 7.
Table 7. Readiness of key fractionation enabling technologies (in 2009). Adapted from [81]
Technology TRL Explanation
Networking 5 Partially demonstrated
Wireless Communication 5 Partially demonstrated
Wireless Power Transfer 2 Not even used on ground
Distributed Computing 4 Mature for ground
applications
Two other technologies that could facilitate fractionation of key payload support systems include
fractionated navigation and propellantless transmission of forces and torques [31]. Study of the
latter, in particular electromagnetic formation flight (EMFF), is a field of research occurring at
MIT, JAXA, UMD and other institutions.
Kwon [124] proposes achieving EMFF via modules equipped with orthogonal electromagnetic
coils made from high temperature superconducting (HTS) wire. The coils can affect a steerable
magnetic dipole when energized, and interactions between these dipoles can create torques and
moments between the modules. EMFF can be used to control the relative separation, relative
143
attitude and inertial rotation of modules in a formation or cluster. The authors found that
symmetric EMFF systems (e.g. a mother-daughter spacecraft relationship) tend to have an
increased performance, as does adding EMFF intermediaries into an array which bridge the
magnetic field (including on an extreme scale, with two large spacecraft and several smaller ones
between them). Other applications of EMFF include power transmission (by rotating a magnetic
dipole attached to a reaction wheel on a non-EMFF satellite) and defensive (or offensive)
maneuvers.
The University of Maryland Space Systems Laboratory has undertaken the Resonant Inductive
Near-field Generation System (RINGS) experiment, a technology demonstrator of EMFF in the
full six degree of freedom (6DOF) environment of the International Space Station (ISS)
[12,231]. Another propellantless propulsion technique that would apply to very small
(millimeter-scale) spacecraft is Lorentz force actuation.
Navigation techniques in High Earth Orbit (HEO) have been proposed by Parker et al [178]. In
this study, one module in a fractionated cluster could be a designated navigation module that
knows its position and attitude in the inertial reference frame. Other modules in the cluster can
then determine their own position and attitude relative to the first module. Relative distance and
orientation information could possibly be determined through data, power and force/torque
crosslink signals [31].
Cluster flight, or persistently proximate orbital positioning, can be achieved with halo orbits,
perturbing altitude and eccentricity. For data links, designers can choose low power, omni
spread-spectrum (like IEEE 802.11), ultra wideband (which also provides cm-precision relative
144
position info), or even modulation of the comm signal over optical signals or RF power beaming
(dependent, of course, on the evolution of wireless power transfer).
Other research endeavors include software cost estimation for fractionated architectures [28] and
attitude control simulation architectures.
5.3 Evaluation of Previous Studies
Much research has been done on the viability of adaptable space systems. With respect to
fractionation, most research has involved a specific mission type as a case study, for example
communication satellites [30] or pointing-intensive remote sensing missions [172]. This
indicates the need for a modeling environment that is flexible to a more general set of
fractionation scenarios. In addition, the vast majority of research efforts to quantify the value of
fractionation use probabilistic methods. While these are useful for modeling uncertain futures,
the necessary use of random variables and expected variation in results makes this approach ill-
suited to approaches that offer optimization.
145
Chapter 6
Methods, Processes, and Tools
Based on the limitations observed in previous efforts described in Chapters 4 and 5, a new,
declarative approach to automated, holistic satellite design and optimization was developed. By
modeling the space system design problem as a constraint satisfaction problem, the efficiency,
accuracy, and comprehensiveness of previous approaches can be improved upon. An AI-based
reasoning engine called the System Platform for Integrated Design in Real-time, or SPIDR, was
selected as the solver and computational foundation for the modeling environment. Satellite
design algorithms and equations were modeled as a network of rules and constraints, and an
extensive satellite component database was created. The integration of this knowledge base and
component catalog with the SPIDR engine is called SPIDR-Sat.
To demonstrate the effectiveness of the new approach, its performance against a set of objective
criteria was evaluated and compared to performance observed in other traditional approaches. To
validate the new approach, SPIDR-Sat was used for the design of USC’s nanosatellite Aeneas,
which was successfully launched and flown in 2012. The approach was then applied to the
development of a tradespace exploration environment for fractionated space systems, or F-
SPIDR. In F-SPIDR, a “shared space imager” problem was modeled in which a constellation of
space-based imagers can be accommodated by monolithic spacecraft or fractionated clusters.
146
Numerous tradespaces were generated and explored to locate scenarios where an architecture
based on simplified fractionated clusters was preferable to the monolithic case.
SPIDR (the SPIDR-Sat engine) is a rule- and constraint-based engine that was originally
developed by Kichkaylo at USC/ISI [16,114] to support the domain of planning. It is well known
that the problem of planning is isomorphic to that of design, which makes the SPIDR engine
potentially well-suited for the design of complex engineering artifacts [114,143]. This unique
tool relies on a reasoning engine that combines constraint-based planning from the field of
Artificial Intelligence (AI) with branch-and-bound search, which utilizes interval analysis. The
combination of these techniques allows for concise and elegant model construction, precludes
the need for iteration, permits implicit instead of explicit definition of all architecture
alternatives, and enables rapid comprehensive search of the tradespace, generating provably
optimal results.
6.1 Constraint Satisfaction
A constraint satisfaction problem requires a set of variables, their domains, and constraints.
Design variables in SPIDR are nodes of a constraint network, which is the base layer of the
engine’s data representation. These nodes then correspond to various properties of systems,
components, or activities. Variables can occupy discrete or continuous domains, or sets of
values, and are mapped onto a specific value via the use of assignments, where a constraint is a
subset of all possible assignments. Constraints, which are typically represented as mathematical
expressions, define what values certain variables can take in one design context. Through
147
constraint propagation, the domains of variables are pruned so as to remove infeasible values. A
solution is an assignment that satisfies all constraints. In this “set-based design” approach, the set
of allowable designs is implicit in the requirements (expressed as rules and constraints) and
component database that are provided. To optimize, one of the variables in the problem is chosen
to be the optimization metric, and the solution is an assignment that either minimizes or
maximizes the value of that variable. SPIDR relies on a copy-based search algorithm to reach a
solution in cases when constraint propagation alone cannot detect the absence of a solution.
In SPIDR, variables belong to tokens, which represent various objects in a design (such as
subsystems and components) as well as states and actions. Tokens can be of a certain type that
defines a set of variables and constraints that are inherent to it. For example, a token type for a
satellite component could have variables such as mass, volume and power. The token type could
also have constraints that require the mass of the component (regardless of what it is) to be less
than or equal to the mass of the satellite itself.
Through SPIDR's use of AI, the “length” of a design, i.e. the number of elements it contains, is
not known a priori. There is no predefined structure for the design process, and thus the
generated designs never follow a fixed recipe. The planning algorithm assembles the exact
necessary sequence and combination of elements that satisfies the mission requirements, no more
and no less [112].
Further detail on how rules and constraints were applied is provided in section 7.1.1.
148
6.2 Branch-and-Bound Search
Branch-and-bound (B&B) search is an algorithm used to achieve global optimization, especially
in discrete and mixed discrete/continuous problems, by systematically and exhaustively
enumerating all candidate solutions. Comprehensive search is made feasible by the rejection of
infeasible candidate solutions, which can be discarded by representing the optimization metric by
its estimated upper and lower bounds. The method was first introduced by Land and Doig in
1960 [130]. The use of interval analysis in this non-heuristic technique, where domains of all
variables are represented as a range of possible values, enables provably optimal results.
Combining the B&B search algorithm with AI planning techniques allows consideration of the
entire tradespace by starting search from a high-level problem specification, enabling a very
efficient design parsing process. This greatly reduces the number of designs for which an
optimization metric function must be evaluated, providing for rapid search of such large
tradespaces.
B&B is a well-known approach for global optimization of Mixed Integer Nonlinear
Programming (MINLP) problems (i.e. mixed discrete/continuous, non-convex tradespace, non-
linear, which is generally the case in spacecraft design) [193]. As in dynamic programming, this
technique also performs an intelligent enumeration of all feasible points of a problem through
partitioning [193]. B&B search offers an analog to the concept of iteration, since all variables are
defined as interval domains that represent the widest possible range of values, then split and
shrunk according to rules and constraints until single point solutions are discovered.
149
6.3 Development of a Comprehensive Component Database
A database of existing components, including associated technical, performance and cost
specifications, plays an integral role in the fidelity and usability of a conceptual design
environment. As such, the development of a declarative approach was coupled with the
generation of a current and comprehensive component catalog. This effort drew from the Active
Catalogs work by Coutinho et al, which was geared towards the improvement of component
engineering.
The Active Catalogs project began in response to the well-known “eighty percent” rules that
dominate design and manufacturing. Most specifically, that 80% of a product’s cost is comprised
of the component cost, 80% of manufacturing costs are determined in the first 20% of the design
phase, and that 80% of an engineer’s time during the design process is spent on communications,
i.e. obtaining necessary information and specifications on components and coordinating with
other engineers [46]. Thus the ability to more easily identify, select, and engineer around a set of
components that best fit a design (considering not only technical performance but also reliability,
cost and schedule) would greatly improve the product development process.
Active Catalogs aimed to enable more rapid identification and evaluation of components and
their behaviors according to collections of constraints specified by the designer. This includes the
ability to query for parts based on their intended use, rather than their parametric specifications;
the ability to refine queries based on constraints that are imposed by other components; the
provision of multi-modal information to help designers assess and compare components; and the
generation of component simulations that could be integrated to engender simulation models of
150
whole candidate systems. The final result, after iterations, would be a Bill Of Materials (BOM)
that is known to fit the requirements.
151
Chapter 7
Declarative Satellite Design
This chapter describes the application of the new declarative modeling approach to the
development of a systems engineering environment for automating space system design and
optimization. In the declarative programming style, the focus of a problem is placed on what the
objective is, and not necessarily how it should be achieved (see Section 2.4 for further
background). In the context of design, this entails knowledge expressed as a declaration of
statements that are true about the desired artifact instead of explicit instructions on how to
implement it. A well-known technique is to represent a design problem as a network of rules and
constraints that are reasoned across by a solver to dynamically discover the optimal candidate(s).
This enables implicit instantiation of the tradespace and allows for automatic generation of all
feasible design candidates.
Section 7.1 describes the development of the declarative-based SPIDR-Sat [19] environment, in
particular the modeling and mathematical approaches that were used, as well as the specific
model architecture that was created. The declarative approach applied in this research is
characterized by its use of a constraint-based search and design framework and the use of
interval arithmetic to support global optimization with branch-and-bound search.
152
Section 7.2 describes the validation of SPIDR-Sat in the design and analysis of the Aeneas
nanosatellite [6], which was successfully launched and flown in 2012 [57].
7.1 Development of SPIDR-Sat
Expressing satellite design algorithms and equations as a constraint satisfaction problem is a
significant departure from past approaches. The satellite design problem must be modeled as a
network of rules and constraints that describe the desired artifact (satellite, nanosatellite, satellite
system, etc.), its payload, orbit, mission requirements (including aspects such as pointing schema
and deorbit), operating environment, and applicable component types that can fulfill necessary
subsystem functions. Then, to support the use of a branch-and-bound search algorithm employed
by the SPIDR engine, all mathematical relationships within the design problem must be
expressed in interval math.
7.1.1 Modeling in Rules and Constraints
Satellite design knowledge in SPIDR-Sat was modeled as a set of rules and constraints
describing the system and subsystem behavior, performance requirements, design choices,
orbital dynamics, operating environment, mission requirements, etc. Rules and constraints were
written in the SPIDR pseudo-language, which is comprised of a constraint network, or Cnet, and
a token network, or Tnet.
153
The Cnet level deals with variables, domains of variables, and constraints between variables. A
domain, which can be infinite, is the set of values that a variable can take. Both discrete domains
(where the value of the variable is an identifier of some entity) and interval domain (the value is
a number) are considered. A constraint is a relation between variables that limits the domains
that the variables can take. For example, Sum is a numeric constraint between the sum and the
addends.
The Tnet level, which comprises the relation to the field of Planning in AI, is where variables
become organized into collections called tokens, which may correspond to systems, components,
states of a system, actions or tasks, etc., depending on the application. Some tokens are classified
as goals, meaning they require elaboration or fulfillment (which prompts a pursuit of some
aspect of the design, e.g. the addition of new tokens or components). Rules in the Tnet layer
describe possible or necessary elaborations of a design state or context. A rule that can possibly
fulfill some elaboration is termed an achievement rule, or arule. A rule that must be enacted if
triggered by an elaboration is termed a safety rule, or srule
8
. For example, an srule may enforce
size constraints that should be always satisfied regardless of what components are used to fulfill
tasks in individual subsystems. Each rule contains a header and a body, where necessary trigger
conditions are defined in the header, and resultant actions are defined in the body.
Describing a model in these terms is a non-trivial task, as it necessitates the proper adjudication
of subsystem functions into different rules, of types of rule (arule vs. srule), and of header
conditions. It is also potentially non-intuitive for many engineering domains, including in
8
The terminology behind arules and srules comes from the planning domain, where certain actions that had to occur
for safety reasons where termed srules, and certain actions that could occur to satisfy some achievement requirement
were termed arules
154
aerospace engineering, since the traditional approach generally involves straightforward
expression in procedural environments such as MATLAB.
For example, consider the representation of the design options for an attitude determination and
control subsystem (ADCS). Typically, a design engineer may specify options in an if-then-else
structure, where higher fidelity options are considered only in the presence of stringent design
requirements, such as pointing accuracy (see illustrative example in Figure 17). Generally, this is
likely due to processing power constraints: since it is unlikely that the selection of the highest
fidelity control option will lead to an optimal design for a mission with lax pointing
requirements, it is not considered in the design loop. However, in the new approach, processing
power is not as significant of an issue, and thus it is no extra burden to consider the higher
fidelity options for any applicable mission requirements (Figure 18). While the option might not
be optimal at the subsystem level, it could lead to a design that is more globally optimal. This is
a desirable aspect of the SPIDR-Sat approach since it allows inclusion of far more design
options, increasing the chances of design results that engineers may have otherwise excluded.
Figure 17. Example implementation of attitude control options in the procedural approach
Control
High
Accuracy
Needed
Reaction
Wheels
+
Thrusters
Medium
Accuracy
Needed
Magnetic
Torque
Coils
Low
Accuracy
Needed
Gravity
Gradient
Stabilized
155
Figure 18. Example implementation of attitude control options in the constraint-based approach
In SPIDR-Sat, the logic behind a set of design options such as the example depicted in Figure 18
is expressed by creating an arule for each option, and applying conditions in the header for each
that are increasingly more constraining on the problem space as the mission requirements are
more lax. An excerpt of the SPIDR-Sat code is shown in Figure 19 that illustrates this
9
. Reading
from top to bottom, the fidelity of the five options (i.e. the hardware selected to fulfill the attitude
control) increases, but the number of conditions in the header decreases).
9
The excerpt of code has been sanitized of the body statements in each arule. Because portions of the knowledge
base and component database in SPIDR-Sat are proprietary or may be considered ITAR controlled, they have not
been explicitly provided in this thesis. The reader is directed to contact the author directly for access to these items.
Control
High
Accuracy
Needed
Reaction
Wheels
+
Thrusters
Medium
Accuracy
Needed
Reaction
Wheels
+
Thrusters
Magnetic
Torque
Coils
Low
Accuracy
Needed
Reaction
Wheels
+
Thrusters
Magnetic
Torque
Coils
Gravity
Gradient
Stabilized
156
Figure 19. Excerpt of attitude control design logic in SPIDR-Sat (sanitized)
7.1.2 Declarative Model Abstraction
The process of understanding and then expressing the satellite design tradespace in this rule and
constraint language requires a significant investment of time. In addition, lengthy debugging and
157
troubleshooting can be required (see section 9.2.2), although this is expected in most complex
programming endeavors.
Addressing these challenges is important for potential adoption of the declarative approach.
These observations indicate that it would be, for example, challenging for additional design team
members lacking knowledge of SPIDR (or another constraint based system) to understand,
verify, or add to existing code. Thus the need for documentation and/or guidelines to support and
facilitate this type of approach is clear. As such, a step-by-step process for elaborating a model
was developed (Table 8).
Table 8. Rule- and constraint-based model elaboration process
Step Tasks
1. Establish objective • Identify the objective of the design problem, e.g. a small
satellite design that meets all performance requirements at
minimal cost
2. Define rules • Express the system as a goal, i.e. as an arule token
• Define the set of primary subsystems that provide the
functions to fulfill the system goal. Express each of these
subsystems as an arule goal
• Identify the possible design choices, and associated
instantiations of components, that can fulfill each subsystem
arule
• Express any other requirements, mission specifications, and
operating rules that exist at the system and subsystem levels
3. Generate a catalog of
available options that can
fulfill rule tokens
• Express each component or option as a set of parameters that
are pertinent to the rule base
• Parameters can exist as continuous (e.g. mass = [0,inf]) or
discrete (e.g. color = {blue, yellow}) variables
4. Provide mission
specific inputs
• Express any dynamic constraints as user inputs that are
specific to the desired mission
5. Apply desired
optimization metric
• Select the desired optimization metric and function, such as
minimize cost, maximize performance, or maximize value
(where value is, for example, calculated as cost/performance)
158
In addition, it was observed that existing flow diagram methods are not adequate for capturing a
declarative knowledge base, and thus a new abstraction construct is necessary. An adaptation of
the UML standard was identified as a reasonable starting point for a graphical representation of
the declarative design flow (see proposed method from Kichkaylo in Figure 20). This could be
employed as a future standard for such an approach, or used as an actual input methodology
within a graphical user interface.
Still, if a design problem cannot be adequately or easily modeled by an engineer, the modeling
environment is useless. For this reason, an application of the SPIDR engine that employs a user
interface for the actual construction of a design problem was conceived, and then generated by
the SPIDR engine developers. The tool, termed “SPIDR-Lite”, relies on the exact same
functionality of SPIDR-Sat “under-the-hood” but with a highly simplified, graphical approach to
problem set-up (see Figure 21). A high-level satellite design example problem using the SPIDR-
Lite was created that can potentially aid designers in modelling space systems using the new
declarative approach.
159
Figure 20. UML-based rule diagram proposed by Kichkaylo
160
Figure 21. Graphical rule creation in SPIDR-Lite
This would allow an engineer to more easily compose a design a problem if the task of manually
encoding it in SPIDR's Tnet language is not feasible [114]. Another potential application is in
academia. If users are receptive to the UI style problem specification, it could be used to help
teach students and engineers about the spacecraft design process and could provide quick insight
into high-level tradeoffs within a design space. The tool was proposed to a Capstone spacecraft
design course at USC but has yet to be implemented.
161
7.1.3 Translation into Interval Arithmetic
In the initial stages of this research, mathematical relationships had to be manually expressed in
interval math. This was done in Java, the programming language visible at the level of the
domain author (i.e. the author of the domain-specific engineering knowledge). In later stages of
this research, an advanced version of the SPIDR engine became available in which a pseudo
language was enabled for the author. This feature enabled the interval math to be performed
“under-the-hood” by SPIDR, relieving the author of the task of hard coding most mathematical
conversions. However, many complex, trigonometric, and/or non-closed form expressions
cannot be handled by such conversions, and still must be explicitly coded by the domain author.
While this translation is not a difficult undertaking for most simple mathematical operations,
complicated expressions require more thoughtful inspection. With a large design problem and
numerous mathematical operations, this quickly becomes a non-trivial process. In addition, the
existence of programming logic within mathematical constraints is a challenge when using
interval math. In particular, constraints with operations such as for loops, if-then statements,
case-switch statements, etc. must be programmed manually by the user.
Expressing constraints with interval arithmetic requires that all mathematical operations
essentially be performed twice: once to locate the lower bound of the solution and again to locate
the upper bound. Common relationships are as follows [160]:
Addition:
𝑎,𝑏 + 𝑐,𝑑 = [𝑎+𝑐,𝑏+𝑑] (13)
162
Subtraction:
𝑎,𝑏 − 𝑐,𝑑 = [𝑎−𝑑,𝑏−𝑐] (14)
Multiplication:
𝑎,𝑏 × 𝑐,𝑑 = [min 𝑎𝑐,𝑎𝑑,𝑏𝑐,𝑏𝑑 ,max 𝑎𝑐,𝑎𝑑,𝑏𝑐,𝑏𝑑 ] (15)
Division, provided [c,d] does not contain zero:
𝑎,𝑏 ÷ 𝑐,𝑑 = [a,b]×
!
!
,
!
!
(16)
Consider the simple equation A = B + C. If variables A, B and C all represent single values, e.g.
B = 3 and C = 6, then A = 9. However, if these variables occupy interval domains, e.g. B = [3, 4]
and C = [1, 6], then the sum of B and C produces the solution interval [4, 10]. If the initial
domain of A = [2, 9], then the solution for A is [4, 9]. A manual encoding of this would
resemble the following, where the expression .getLow() extracts the lower bound of the
variable’s domain and .getHigh() extracts the upper bound:
A.getLow() = B.getLow() + C.getLow()
A.getHigh() = B.getHigh() + C.getHigh()
More complicated expressions require identification of which bounds (upper or lower) of each
variable need to be selected in which operation in order to find the correct minimum and
163
maximum bounds of the solution. For example, consider the equation for calculating the required
power generated by a solar array during daylight for powering a satellite through orbit [262]:
𝑃
!"
=
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
(17)
The code would resemble the following:
Psa.getLow() = ( Pe.getLow() * Te.getLow() / Xe.getHigh() + …
…Pd.getLow() + Td.getLow() / Xd.getHigh() ) / Td.getHigh()
Psa.getHigh() = ( Pe.getHigh() * Te.getHigh() / Xe.getLow() + …
…Pd.getHigh() + Td.getHigh() / Xd.getLow() ) / Td.getLow()
If trigonometric functions are involved, it may not be clear a priori which bound selections will
yield the correct values for the solution interval unless the initial domain is within a known
quadrant(s). For example, 𝐴= 𝐵𝑐𝑜𝑠 𝜃 can be represented by the following statements if the
domain of 𝜃 in degrees is, for example, 𝜃= 0,90 :
A.getLow() = B.getLow() * cosD(theta.getHigh())
A.getHigh() = B.getHigh() * cosD(theta.getLow())
However, if the domain of 𝜃 occupies more than one quadrant, for example 𝜃= [65,175], then
the above statements could result in a solution where the lower bound A is greater than its upper
164
bound, yielding a null problem solution. Thus correct code would resemble the following, where
the expressions min() and max():
A.getLow() = B.getLow() *min( cosD(theta.getLow()), …
…cosD(theta.getHigh()))
A.getHigh() = B.getHigh() *max( cosD(theta.getLow()), …
…cosD(theta.getHigh()))
Furthermore, not all logic can be represented in a closed form mathematical equation. For
example, consider the logical formulation of the value for β
s
, or the beta angle, which is the angle
of the Sun above or below the orbital plane [131]. To express this figure in interval math, logic
according to the following was developed:
Double betal = inc.getLow() + 23.5;
Double betah = inc.getHigh() + 23.5;
if (betal <= 90 && betah >= 90)
max = 90 ;
if (betal > 180) {
betal -= 180 ;
} else if (betal > 90) {
betal = 180 – betal;
if (betah > 180) {
betah -= 180;
} else if (betah > 90)
betah = 180 – betah;
165
return new IntervalDomain(Math.min(betal, betah), Math.max(max,
Math.max(betal, betah)));
This type of if-else statement is not directly supported by the SPIDR framework, which can only
accept closed form relations. Explicitly coded Java exceptions were created for each instance of
a non-closed form expression, including beta angle, or β
s
, maximum and minimum atmospheric
density, or ρ, orbit-average Earth-emitted infrared energy, or IR, maximum and minimum orbit
average albedo value, orbit angular radius and ratio, atmospheric scale height, or H, Earth’s
magnetic field at perigee and apogee, the latitude of the orbit pole, and eclipse time. Flow
diagrams for ρ and IR are shown in Figure 22 and Figure 23.
166
Figure 22. Logical flow for calculating atmospheric density (ρ) using interval math.
167
Figure 23. Logical flow for calculating Earth IR using interval math.
7.1.4 Design Architecture
In large part, the structure and flow of the user interface (UI) directly mirrors the architecture of
the models that were developed in SPIDR-Sat. The windows and steps of the UI are presented
here in lieu of the model architecture itself (see footnote 9 on page 155). The main input fields of
the SPIDR-Sat design environment are shown in Figure 24.
168
Figure 24. Input screen for SPIDR-Sat small satellite design tool
The user has the option to load an existing STK satellite file (.sa file) that populates all
applicable orbit and mission operations parameters (Figure 25). This is indicated by the grey “S”
icon that is to the left of the input field.
169
Figure 25. SPIDR-Sat can accept an STK satellite file as input for orbit and mission fields
This first
10
window also contains several tabs for additional inputs, including payload specific
inputs (Figure 26), global variables (Figure 27), and subsystem specific constraints and estimates
(Figure 28).
10
Note, the “first” input screen reads “Step 2” - there is also a preceding “Step 1” window that allows the user to
optionally select pre-defined and saved input scenarios.
170
Figure 26. Payload parameters input screen in SPIDR-Sat
Figure 27. Global variables input screen in SPIDR-Sat
171
Figure 28. ADCNS subsystem input screen in SPIDR-Sat
Figure 29 shows the next step in the design process after all inputs have been specified, which
displays preferences and feasible designs and associated subsystem parameters before pruning
and optimization has taken place.
172
Figure 29. Preferences and sub-systems screen in SPIDR-Sat
At this point, the user can explore the branching design contexts at an intermediate stage and
select an optimization metric accordingly (see Figure 30), e.g. system cost, mass, power
consumption, or volume (as well as the desired number of design results).
173
Figure 30. Selection of desired optimization metric based on exploration of feasible designs
Finally, in step 4, the user can browse the resultant designs, evaluate the system concept based
on the optimization metric selected, and identify other metrics to potentially pinpoint and
optimize on in subsequent runs given the knowledge of the design space that resulted from the
original metric selection (see Figure 31).
174
Figure 31. Final output screen in SPIDR-Sat. The requested number of output designs are
ordered according to the optimization metric
The user can also export the design to XML or another desired format for further analysis (see
Figure 32).
175
Figure 32. Designs export to XML in SPIDR-Sat for further analysis
Design results from SPIDR-Sat can be exported for further use in multiple ways: in XML format
to be used in external verification models; as a medium for interface control documents; as raw
data to feed into tradespace analysis; or potentially with component device drivers for software-
and hardware-in-the-loop simulations to support automated integration and testing.
176
7.2 Validation of the Approach: Design of Aeneas Nanosatellite
The SPIDR-Sat environment was applied to the development of USC/ISI’s Space Engineering
Research Center (SERC)’s first satellite effort, Aeneas [94], to validate its utility and accuracy as
a systems engineering environment for nano-/pico-satellite design and decision support. Aeneas
is a 3-axis stabilized asset tracking nanosatellite built using a Colony I CubeSat kit as its baseline
bus. It was designed and built at the SERC by a team of both students and professionals and
launched in June 2012. A set of SPIDR-Sat rules for nanosatellite design was developed that
augmented and extended the existing small satellite design knowledge base in order for the
modeling environment to be applicable to the specialized case of CubeSats. SPIDR-Sat’s design
and optimization capability was employed numerous times during the preliminary phases of the
project, and its systems engineering workbench functions were utilized for the duration of the
development phases.
The following sections describe observations of the effectiveness of this approach in the generic
domain of small satellite design and then specifically in the case of CubeSat design.
7.2.1 Effectiveness in Satellite Design
In the Aeneas effort, an automated workflow capability was enacted wherein design information
was flown from STK, to SPIDR-Sat, then to a power profile analysis, a thermal analysis tool, a
mass budget spreadsheet, an attitude control analysis, a communication access scheduler, a
177
communication link budget spreadsheet, and other design elements. XML design files were
periodically exported to the team’s web-based collaboration repository, then downloaded by
subsystem leads in the desired formats and used to perform subsystem analysis, the results of
which would be communicated back to the system engineer and integrated into the next SPIDR-
Sat design sequence. Integration with these external analyses was made possible via the use of an
XML-XSLT translator that can convert design results into other text-based formats for import
into other XML-based resources, Excel spreadsheets (e.g. the power profile and mass/CG/MOI
spreadsheets), and third-party validation tools. In this way, SPIDR-Sat served as the
configuration management (CM) master in the design process, where component, orbit and
design parameters were provided to subsystem analysis tools directly from the XML files
generated by SPIDR-Sat.
To ensure accurate incorporation of the most current design results, SPIDR-Sat updates any pre-
existing design data in a previously performed analysis element (e.g. cells in an Excel
spreadsheet) by matching XML tags instead of, for example, simply linking fields. This dynamic
approach helps prevent errors if any fields of the analysis template itself have changed, or if the
number and/or types of parts in the SPIDR-Sat file have changed from previous runs. This is
possible since the make-up or “recipe” of components in a design is discovered dynamically by
SPIDR-Sat, and not necessarily constant. As such, this aspect of the SPIDR-based constraint
propagation approach is particularly useful in this respect.
Streamlining design and analysis in this way improved the efficiency of the development process
since the subsystem engineers did not have to manually update design data when performing
analysis. However, a degree of serial iteration still exists in this process since results of
subsystem analyses must be fed back into the design loop. Because dynamically linked interfaces
178
were created between the singular design element and the disparate analysis efforts, these serial
computational endeavors should in theory be able to be automated in one SPIDR optimization
loop. While enabling this level of automation was out of the scope of this research, a proof-of-
concept demonstration was performed wherein integration of dynamic subsystem analysis was
executed internal to the design loop.
The satellite’s mode-by-mode power profile was selected as the analysis element to be encoded
into the power subsystem model within SPIDR-Sat. This allowed the depth of discharge (DoD)
of a selected battery, a dynamically acquired parameter, to be considered in the static design
process (see Figure 33). The DoD is dependent on orbit, solar panel parameters, power
consumption of the selected components and mission operations (which specify modes for these
components). If the calculated DoD exceeds the nominal limit for the selected battery at any
point in some projected time period (in other words, the State of Charge, or SoC, drops too low),
the design is known to be infeasible. Changes to some time-independent parameters must then be
enacted to fix the problem, including potentially changing the selected set of components.
Consider a design loop wherein a tool converges on two potential final designs, A and B, where
A is the more cost-optimal, rendering it superior. Then, however, the power subsystem engineer
could run the power profile analysis with the Bill Of Materials (BOM) from the XML results for
both A and B, and discover that the depth of discharge of A exceeds that allowed by the battery.
Then, B becomes the best (and only feasible) design. Integration of the time-dependent DoD as a
variable that can have upper and lower bounds in the optimization loop would allow non-feasible
and/or sub-optimal designs to be discarded earlier in the design cycle, saving significant time and
resources. In general, this has only been done serially in previous efforts (with exception of
certain preliminary attempts such as that described in Reference [153]).
179
Figure 33. Power profile time series embedded in SPIDR-Sat optimization loop
Lastly, Figure 34 shows the use of the SPIDR-Sat approach in tracking tradeoffs and changes
between different designs. Since the declarative modeling approach can easily produce designs
that differ both in component selections and in architecture, it is critical to be able to compare the
propagated effect of changing input parameters or constraints on the final design outcome.
The use of a declarative approach to holistic design, analysis and optimization greatly improved
knowledge of options, efficiency, and design accuracy for the Aeneas satellite design team.
SPIDR-Sat was valuable in enforcing design configuration control, characterizing global
180
implications of local design decisions, and tracking the “delta” (or change) in performance
parameters between designs. However, some observations were made on CubeSat-specific
challenges associated with this approach.
Figure 34. Side-by-side comparison of two potential designs. Parameters differing between
designs are displayed in bold.
7.2.2 Strengths and Weaknesses in CubeSat Design
In CubeSat projects, budgets are often severely restricted, as is the pool of available options for
components. Hence, the “delta” in system performance can vary widely as component changes
are enacted. Because of this, the Aeneas mission was an apropos test case for SPIDR-Sat’s
181
component selection and optimization logic as it led to straightforward and readily verifiable
comparisons. The improved trade-off analysis ability engendered by this approach also became
evident when dealing with the volatile nature of a CubeSat mission’s nominal orbit. Since
CubeSats are not primary payloads, but rather secondary (or tertiary) payloads, the launch
specifics are not under the control of the designer but rather belong to the primary payloads on
the launch vehicle. For this reason, the nominal launch vehicle, launch date, and associated orbit
specifics can change many times during a CubeSat project. Aeneas was no exception, and indeed
many launch vehicle and resulting orbit changes had to be accommodated in the design process.
In particular, the orbital parameters (altitude, eccentricity, and inclination) were not firmly
known for much of the project and fluctuated several times. This uncertainty and frequent
fluctuation incurs significant redesigns on the attitude control system (which is highly sensitive
to changes in altitude at such low altitude orbits, especially when very small margins exist on the
reaction wheel performance and electromagnetic torque rod control), the power system (differing
orbits led to different solar power configurations, for example 90° deployed “flower petal”
configuration vs. 180° deployed “dart” configuration), and the communications system (differing
orbits lead to different antenna component and configuration selections).
Moreover, the changes of these aforementioned subsystems of course have “trickle down”
effects throughout the rest of the system as well. This forced the design team to juggle design
manifestations and analyze system-level effects of local component changes often. Thus, the
ability to compare the tradeoff between designs is valuable (for example, decreased altitude will
require more capable attitude control due to the increased aerodynamic torque, but it will also
decrease strain on the communication link, while the converse is true for increased altitude). The
182
declarative environment proved adept at handling this type of problem since design changes
were easily enacted and real-time propagations of their consequences were readily tracked.
However, the task of designing a CubeSat in the open-ended, declarative environment proved to
be challenging. Initially, it was unclear how to approach the modeling problem, since much of
the CubeSat design was already constrained due to the use of a Colony I bus. In addition, much
of the design was necessarily modular given the available components, requiring little from-
scratch, blank canvas type design. Conversely, it did enable the inclusion of detail that generally
would only get integrated at a more mature design state. The task of defining and accurately
interrelating detailed information was found to be challenging with the new declarative
approach, although this was somewhat eased by the simplicity of the CubeSat design space. This
challenge led to some important findings about what was and was not feasible with the CubeSat
design itself.
In particular, due to coupling of the highly constrained structural configuration with the low orbit
regime necessitated by the rideshare opportunity, the choice of payload and the ability to conduct
certain desirable payload operations was very limited. In the Colony I CubeSat bus design, the
most intuitive system level design choice is to utilize the payload section, i.e. the ~1.5U section
at the aft end of the vehicle, for a longitudinally (long axis) mounted or deployed payload (for
example an optic or RF antenna, such as the 0.5m deployable dish in Aeneas [6] shown in Figure
35). With a longitudinally configured payload (meaning the field of view of the payload is down
the long axis of the vehicle and out the aft end, not perpendicular out of one of the short axes),
the most beneficial pointing scheme would generally be nadir or anti-nadir pointing. However, it
was known that the vehicle would be constrained to a very low altitude LEO orbit, which has
183
many implications on the ability of any small satellite to maintain proper pointing. It is especially
difficult for CubeSats, which traditionally utilize passive pointing control.
Figure 35. Aeneas’s 0.5m mesh dish antenna, which deploys longitudinally out of the aft end of
the vehicle
First, the density of Earth’s atmosphere increases rapidly with decreasing altitude. At LEO, the
atmospheric density is significant, causing both drag and aerodynamic torque on a satellite. Drag
severely limits the satellite lifetime (the length of time it is in orbit before its orbit naturally
decays back to Earth atmosphere, where it likely burns up completely), and the aerodynamic
torque experienced in this altitude region can make flying nadir or anti-nadir oriented along the
long axis of a CubeSat extremely difficult.
184
Aerodynamic torque is proportional to atmospheric density, the square of the orbital velocity
(which is also higher for lower orbits), and the average aerodynamic surface area, coefficient of
drag, and projected difference between the center of gravity and center of pressure (Cg-Cp) of
the satellite [131]. The Cg-Cp thus becomes a limiting factor, since the velocity and density are
unchangeable, and the coefficient of drag and surface area difficult to change at best. As a result,
the best way to minimize this type of disturbance torque is to align the center of gravity with the
center of pressure of the satellite. Unfortunately, this is generally most difficult with the
longitudinal axis perpendicular to the velocity vector. In this orientation, the vehicle most likely
is asymmetric about the short axis, especially with a potentially deployed payload extending
even farther from the body. In addition, the payload may add significantly to the projected
surface area of the vehicle but not much to the mass in that region, further widening the distance
between the center of the gravity and the centroid of the vehicle’s projected surface area.
The easiest solution to this problem is simply to use higher performance attitude control
hardware. If magnetic torque rods are used, they would likely have to be very large and power-
hungry. If reaction wheels are used, they would need to have a high momentum storage capacity
and be accompanied by a momentum dumping mechanism (thrusters or torque rods). The last
option is to use thrusters, which are expensive, require on-board fuel, and are thus far a very new
technology for the CubeSat world. If none of these options are viable, which may be the case for
most low-budget missions, the pointing ability of the satellite and/or the number of possible
mission passes for the satellite will likely need to be reduced. One compromise would be to
inertially point the spacecraft. In this case, the aerodynamic torque experienced will be cyclic
instead of constant, lessening the burden on the attitude control system, but the nadir or anti-
nadir view will also only be periodic.
185
Similarly, there are severely limiting power constraints due to the CubeSat structure and [Colony
I-specific] solar array configuration options. An advantage of the 3U CubeSat is the relatively
high power generation that is achievable due to the large surface area for solar arrays via
deployable panels. The Colony I bus, for example, has solar cells mounted on three of the body
faces as well as on four panels that deploy from the end of the satellite at some specified fixed
angle (90°, 120°, 180°, etc.).
Assuming that a mission desires mounting or deployment of a payload out of the nadir or anti-
nadir end, and likely has minimal pointing capability, the panels most likely cannot extend fully
to 180°. This is due to the fact that flying in an inertially pointed (instead of nadir pointed)
configuration would likely incur too much aerodynamic torque due to the doubled surface area of
the deployed panels. Thus, 180° deployment would likely only work in a mode where the
longitudinal axis was oriented in parallel with the velocity vector, in which case the long axis
will never be oriented toward nadir. Instead, the panels might best be deployed to 90°. However,
still assuming the vehicle must be inertially fixed, the satellite must then have a very specific
orientation so as to prevent the deployable panels from completely shadowing the body panels at
period or even all times during the sunlight portion of the orbit. If the requirements disallow this
orientation, the solar cells on the body panels are then effectively wasted.
The communication link is similarly affected, as antenna choice and orientation become an issue
due to inconsistent gain pattern on the ground since the vehicle cannot be nadir oriented. For
thermal control, heat from external sources (solar radiation, Earth albedo, etc.) will not be
distributed around the vehicle during the course of an orbit but instead accumulated continuously
on the same sides of the satellite, which is also problematic. Clearly, even with such a simplistic
186
bus, the interrelatedness of the subsystems, components and operations presents a significant
modeling challenge.
Clearly, the inclusion of high-fidelity design information was challenging but critical to the
Aeneas design process. Integrating higher detail mission aspects such as spacecraft geometry,
operations, pointing, etc. is known to be challenging in any early design stages, yet these design
parameters, and the relationships between them, have a significant effect on the fidelity of the
ultimate design results. It was clear that the gap between a design environment that is useful at
the conceptual level and one that is useful at the preliminary design level is significant; they are
two very different tools. This finding speaks to the lack of design tools available today that
approach the design process from a holistic, integrated system-level perspective, and offer
reliable accuracy and detail (indeed, the majority of existing tools use CERs and DERs, gross
estimations of subsystem behavior and system relationships, etc.).
187
Chapter 8
Declarative Modeling of Fractionated Architectures
Following successful demonstration of the application of a constraint-based approach to satellite
design, the new declarative modeling approach was applied to the conceptual design of
fractionated space architectures. The resultant environment is called F-SPIDR. F-SPIDR served
as the foundation for an F6 Developer’s Kit (FDK) modeling environment, termed SatTrade,
developed in support of the VCAD effort for the DARPA System F6 program [301]. This
research in F-SPIDR focused on the modeling and evaluation of a “shared space imager” (SSI)
architecture, wherein an imaging constellation leverages resources from an orbiting backbone
infrastructure. Sharing of resources within the SSI example would be made possible by F6
Technology Packages (F6TPs), or standardized component subassemblies that facilitate wireless
networking and resource sharing within a fractionated cluster.
8.1 Development of F-SPIDR
A fractionated system is a major departure from traditional monolithic satellites, since
functionality can be distributed and possibly duplicated across multiple modules in a wide
188
variety of ways. Modules participating in a cluster can also be launched and decommissioned at
different times, and modules can be added to an existing system to expand the range of
capabilities of the existing cluster, or to add new capabilities and support new missions (with
only incremental costs). Because of these incremental modernization and expansion properties of
the F6 infrastructure, the cost and value of any individual module in an F6 system can only be
estimated in the context of the whole constellation and its evolution. The potential savings in cost
and time that could result from the incremental upgrades are balanced against the added
complexity of sharing resources and supporting cluster flight. The approaches and rules of thumb
used for traditional monolithic systems may not be optimal for design of fractionated systems.
As such, this research aimed to investigate SPIDR's ability to efficiently generate preferred
architectures and design thumb rules for fractionated systems, including a backbone constellation
infrastructure and the optimal cluster design.
A selection of results is presented here. (The reader is referred to Appendix B for further detail
on the calculation of available orbits, selection of architecture options, mass, power and cost
models, etc.)
8.1.1 Designing a Backbone Constellation
Several engineering dimensions were modeled: fractionation of the imager (three principal
components - optics, processing, and power - distributed among one or more spacecraft); imager
resolution; compression provided by processing within the cluster (including impact on electrical
power); power modules (including the cost of development of power beaming capability, if
189
chosen); and propulsion type. Inter-module distance could be varied from 1 to 10 kilometers.
This separation is a key value-determining parameter: shorter separation distances provide
increased data transmission rates, but also require additional propellant consumption to maintain
safe separation between modules. For the launch campaign, three different types of launch
vehicles were modeled (based on existing launch vehicles), with different cost, payload and
scheduling properties. Additional dimensions of the trade space were representative of possible
customer requirements for the imager: number of imagers to be orbited (this number determined
the delay between choosing a site to be imaged and the time that an orbiting imager could be
overhead); imager altitude; and cost. A crude cost model of $200,000 per kilogram of dry
spacecraft mass was used. Other costs included development, additional design, and launch
costs; operations costs were not modeled. Figure 37 shows the relationships between 43 key
parameters modeled in the SSI problem.
The backbone constellation was defined to consider spacecraft constituents in one of the five
following configurations: monolithic (C1), or fractionated into two or three modules according to
the available combinations (C2 through C5) of three fractionable subsystems (processing, power,
and optics payload), as shown in Figure 36.
Figure 36. Fractionation options in the Shared Space Imager problem [301]
190
Figure 37. Key parameter relationships in the F-SPIDR Shared Space Imager model
191
Three ground track repeating, “filled” (horizon-to-horizon spacing) orbits were considered
(orbits at these altitudes have an integer number of revolutions per day for a polar inclination):
• 569 km – 15 revs/day, 8 rings, 16 clusters per ring
• 896 km – 14 revs/day, 6 rings, 12 clusters per ring
• 1264 km – 13 revs/day, 5 rings, 10 cluster per ring
Key metrics included cost, resolution, time-to-orbit (or responsiveness), images transmitted per
day, and maximum delay (or timeliness). Resolution is determined by altitude and choice of
optic, where representative optical payloads considered are summarized in Table 9 (note only the
resolution at 569km is listed, as equivalent resolution for the 896 and 1264 km orbits was
calculated using a scaling factor).
Table 9. Parameters of five representative optical payloads modeled in F-SPIDR
Resolution (m) @ 569 km Image Size (Mbytes) Orbit Average Power (W)
5 20 15
3 30 30
2 50 50
1 100 150
0.65 200 500
Delay is the worst-case duration of time to have an imager within range to image some
determined location, which is determined by both the altitude and the filling factor, i.e. number
of imagers (where each cluster possesses one imager), as shown in Figure 38.
192
Figure 38. The maximum delay experienced for having an imager overhead a desired location is
determined by altitude and filling factor [301]
In general, image resolution worsens as altitude increases. However, higher altitudes also require
fewer spacecraft to achieve a given timeliness of image acquisition. Figure 39 shows results of
an analysis on the number of imagers divided by unit resolution at an altitude of 1264 km. The x
axis indicates the cluster ID type, C1 through C5. The y axis gives the number of transmitted
images per day from the whole constellation. The z axis gives the total capability cost divided by
the estimated lifetime ($M/year). It was found that if more than 200,000 images were required
per day, the optimal configuration is fractionated. In particular, configurations C2 and C3 reveal
some design instances that achieve high productivity at low cost.
0.01
0.1
1
10
100
0
20
40
60
80
100
120
140
Max.
&me
to
have
spacecra1
overhead
(hr)
#
Cameras
on
orbit
569
km
896
km
1264
km
193
Figure 39. Comparison of the number of imagers divided by resolution at 1264 km. Cluster IDs
of 1 correspond to the monolithic design configurations, whereas 2-5 correspond to fractionated
configurations
In another analysis, F-SPIDR was used to explore which infrastructure provided the lowest
annual costs for maximum number of imagers (in some cases referred to as capabilities or
“caps”) and best resolution (in some cases referred to as “res”, or via the combined
representative metric of imagers/resolution or “caps/res”). Results shown in Figure 40
demonstrate a Pareto-optimal frontier exists for architectures with orbits at the lowest altitude,
569 km.
194
Figure 40. Comparison of imagers/resolution vs. cost/lifetime for the three constellation orbits
considered [115]
Similarly, Figure 41 shows architecture trade-offs only according to productivity, i.e. images
taken and transmitted per day. Here, maximum productivity at lowest cost is found for the 896
km orbit.
195
Figure 41. The lowest-cost designs are found at all three altitudes. The middle altitude (896 km)
achieves the highest total productivity.
Another analysis explored whether or not the F6TP should include a processor for use in cluster
support services and/or payload operations, such as image compression. When the tech package
processor does not offer compression, it must be provided by the cluster’s processor. In other
words, if you don't compress at the point of data origin, you may be limited by the data capacity
of the inter-module wireless link. Furthermore, a shared cluster processor may become capacity-
limited if a large part of its workload is the compression, rather than executing other
applications. Figure 42 shows that for maximum images per day, it is advantageous for the F6TP
0
200
400
600
800
1000
0
200000
400000
600000
800000
1000000
Cost/Life&me
($M/year)
Total
Constella&on
Images
Per
Day
(#)
569
km
896
km
1264
km
196
processor to offer compression. This results from the limitation on productivity imposed by the
data rate of the inter-module wireless link.
Figure 42. Plot of images per day vs. cost per year ($M/year) for the two F6TP image
compression options [115]
197
8.1.2 Optimal Cluster Design
Figure 43 and Figure 44 show how the optimal fractionation configuration varies according to
level of investment for a given delay and imaging resolution, and to annual lifecycle cost versus
delay, respectively. In the latter, it is observed that the monolithic configuration is almost always
the optimal configuration
Figure 43. At higher levels of investment, delay and resolution improve, and different
fractionated configurations are preferred to the monolithic configuration [301]
198
Figure 44. For these conditions, the monolithic configuration is shown to almost always be the
most optimal [301]
Figure 45 compares two schemas for navigation: relative ranging and absolute, in which Carrier-
phase Differential GPS (CDGPS) is used. In this analysis only the 569km orbit is considered. For
simplicity, both schemas are assumed to have equal costs. However, because relative ranging
introduces a much higher navigational error, system designs with this schema are penalized with
0
10
20
30
40
50
60
70
80
90
100
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
Cost/Life&me
($M/year)
Delay
(hrs)
C1
C2
C3
C4
C5
199
ten times more ∆V for collision avoidance. The graph also shows that for CDGPS, low and mid-
range inter-module distances provide lowest cost per image. For relative ranging, inter-module
distances below 3km and above 8km are preferable.
Figure 45. Plot of inter-module distance vs. cost per image for the two available module
navigation schemas [115]
These results show compelling preliminary data for an analysis of fractionation with respect to
shared resources. Surprisingly, fractionated architectures were in some cases more economical
than monolithic systems (e.g. Figure 39).
200
8.1.3 Advanced Declarative Modeling
When designing a fractionated system, the total number of entities is variable. A cluster may
consist of one or many modules, the components required can be distributed over these modules
in various ways, and the modules can even be distributed across several launch vehicles of
various sizes. The number of possible arrangements grows combinatorially, so manually
enumerating all possible arrangements is feasible only for small models (few modules per cluster
and per launch). Further, when multiple permutations are specified manually, it is easy to
introduce copy-paste mistakes into the mathematic expressions. To overcome these issues,
quantified relations were introduced. Used together with the rule mechanism, this new feature
enabled compact representation of the possible permutations, which is very useful when size,
degree of fractionation, etc. are unknown a priori. For example, instead of enumerating possible
ways to distribute components between modules of a cluster, a rule could specify that for each
component in the design, there must be exactly one module to which it can belong. Implicitly,
this allows components to share modules, or have their “own” module. This enabled F-SPIDR to
automatically generate all possible component allocations during the search.
The quantified relations are described below:
• Reuse enables component-module assignments to be performed either by using existing
modules or creating new ones, obviating the need to explicitly define architecture size
and configuration
• Sumcluster and summodule allow implicit definition of a module or cluster property
depending only on the components assigned only to it by SPIDR
201
• Setmodulecount enables implicit definition of the size of a cluster based on the number of
payload capabilities attached and the highest possible degree of fractionation that results
from the support subsystems needed and the shared resources available.
The proper aggregation of component properties into module- and cluster-level functionalities is
described in further detail in Reference [115].
202
Chapter 9
Case Study: Comparing Procedural and Declarative
Approaches
The purpose of the case study was to assess the advantages of the declarative approach over past
procedural approaches. To this end, a preliminary spacecraft design portal, SPIDR-Sat v.0
11
, was
developed. The performance of the procedural SPIDR-Sat v.0 approach was evaluated against
the declarative SPIDR-Sat approach for multiple satellite cases, with varying orbits, inputs and
constraints, and ranging from small satellites to CubeSats. However, since a high level of detail
and wide array of design options are achievable in the constraint-based approach, it was not
feasible to establish a one-for-one correspondence between the declarative and procedural
approaches. (It is important to note, however, that such an endeavor would be a valuable
investigation in future research.) To overcome this shortcoming in the analysis approach,
observations associated with the new approach were also compared to the performance of
competing approaches reviewed in the literature (Chapter 4). The performance of the F-SPIDR
environment was also evaluated. However, since developing a one-to-one correspondence
between the models used in the procedural and declarative approaches was beyond the scope of
11
Full details of this approach are provided in Appendix A.
203
this research, the performance was compared to that of past approaches reviewed in the literature
(Chapter 5), especially the JPL ASDA tool (section 5.1.10).
The metrics used to compare and evaluate the two approaches were: accuracy, time, and model
scalability. Quantitative data was gathered, where feasible, and qualitative observations are made
in all other cases.
9.1 Metric: Accuracy
A key attribute that needs to be addressed in the development of a design, modeling, or analysis
approach is accuracy. Clearly, if a process or methodology does not lead to accurate results, the
presence of any other desirable performance attribute is diminished (except perhaps cost/time,
which, if sufficiently reduced, can make low fidelity results acceptable in certain contexts).
There are many ways to measure the accuracy of a design approach, such as by responsiveness
of the designed artifact’s performance against mission requirements, by inputting requirements
of a known mission and verifying the result against the appropriate use case, and by comparing
the optimality of design results with those produced using other approaches.
The first measure is arguably the most critical, since the ability of a design to operate
successfully is a necessary precursor to optimization. But because this is such an important
feature, it is not generally an attribute that is expected to vary significantly between approaches.
Thus “measuring” it is something of a moot point. In the SPIDR-Sat approach (as in most past
approaches), the design equations themselves are essentially industry standard. They are taken
204
from textbooks and other authoritative resources that have been sufficiently used and verified
that they can be considered correct by construction. If incorrect design results are uncovered in
refinement or in verification of the design tool (e.g. through a bug, typo, or incorrectly expressed
algorithm), attempts should be made to fix the problem before evaluation of the tool resumes.
This was experienced repeatedly in the development, test and verification of the SPIDR-Sat
approach until the discovery of bugs or anomalous results became sufficiently infrequent that a
reliable case study could be performed.
The second measure is what engineers tend to look to first since it enables them to validate
against a design that they know and trust, and that likely went through a design process they
understand well. However, this is not necessarily a valuable measurement since the optimality of
the known design is not guaranteed just because it was the one that was selected. Since many
factors go into the final nuances of a design, it is difficult to capture these in a blank-canvas
design process (especially one that encompasses socio-technical factors, such as politics, budget
fluctuations, etc.).
The last measure is particularly important in this context since broadening the searchable
tradespace and enabling provable optimality is a primary concern of this research. As such, it
was selected as the measure of accuracy for the approach considered in this study. This subject is
elaborated in the following sections.
205
9.1.1 Tradespace Size
First, the performance in traversing a large tradespace was examined for satellite design and then
adaptable system design.
In the procedural approach, attempting to create and explore a large tradespace is time-
prohibitive. Exhaustive enumeration of all feasible configurations requires, in general,
enumeration of all possible configurations, where infeasible architectures can be discarded only
after they have been generated and evaluated. Accordingly, in the procedural SPIDR-Sat v.0
approach, no attempt was made to produce an exhaustive tradespace of candidate designs.
Instead, the approach to identifying a minimum cost design was to satisfy each subsystem’s
required functions with the hardware that met the required mission and technical performance
parameters at the lowest cost. This approach creates a narrowing of the tradespace, where there
may be multiple feasible options available in the fulfillment of the subsystem that is sized first, a
reduced subset available to the next subsystem due to constraints imposed by the preceding
selection, and so on. Unless mission requirements are extremely lax, the size of this tradespace is
very likely much smaller than, and by definition never larger than, the tradespace achievable in
the declarative approach.
In the new declarative approach, SPIDR-Sat enumerates all feasible configurations. This is
achieved through branch-and-bound search; as constraints are propagated, the domains of design
variables are shrunk, and it becomes possible to identify and discard infeasible solutions early
on.
206
The new approach also enables the generation of solutions that may not have been otherwise
included in the tradespace by the engineer a priori. For example, the selection of attitude control
option in traditional approaches is almost always done by explicitly matching an option to the
mission requirements. Considering the subsystem solutions that are less likely to be optimal
would require increased processing power and/or runtime, with low likelihood of affecting the
final solution. In the declarative approach, all options can be considered as long as they do not
violate the mission requirements, which enables truly system-level optimization.
For adaptable systems, the disparity in searchable size is even more apparent. In the vast
majority of previous approaches, all candidate configurations had to be explicitly defined a
priori. In the F-SPIDR approach, especially with the use of quantified relations (see section
8.1.3), the number and composition of architecture elements can be instantiated implicitly,
significantly increasing the number of configurations that are considered. Since adaptable space
systems tend to still be conceptual in nature, and thus possess architectures that are fuzzy or
poorly defined, it is desirable to generate very large tradespaces with a plethora of configuration
options.
9.1.2 Optimality
The degree of optimality obtained was also examined. Past approaches generally follow one of
three methodologies for obtaining an “optimized
12
” solution:
12
Most design and optimization tools aim to provide an optimal result, but in practice, results are generally only
“good”, since they are not provably optimal. Thus the term “optimized” is used loosely here.
207
1. Sequential design approaches
This technique, introduced in the previous section, entails a single design run where subsystems
are fleshed out sequentially, and components are selected that fulfill the requirements while
optimizing locally on the desired optimization metric. This approach causes undesirable
weighting to occur because the subsystems that are sized first affect the sizing of the subsystems
that are considered later. It is well known that optimizing at the subsystem level does not
necessarily guarantee global optimization. This technique was used in the procedural SPIDR-Sat
v.0 environment.
2. Iterative design processes
The vast majority of approaches utilize manual iteration to obtain optimal designs. In a common
scenario, subsystem designs occur independently at distributed workstations, a central design
element synthesizes the information, and this process is repeated until convergence is achieved.
This introduces “snowballing” because each iteration might increase the sizing of a subsystem or
element selected in the preceding iteration to enable convergence on other aspects of the design.
3. Heuristics-based optimization
Heuristics-based optimization techniques have become popular in multi-disciplinary
optimization problems. While useful in obtaining solutions that are reliably “pretty good” with
respect to the optimization metric(s), these algorithms do not guarantee optimal results.
208
In the new approach, since the ability to perform exhaustive exploration of a tradespace is
realized, results are provably optimal: the best one is simply identified by ordering the designs
according to the optimization metric.
9.2 Metric: Time
Given a tool that is accurate and reliable, cost and time are the next most critical attributes of an
approach. Cost, however, is difficult to measure, since all approaches considered in this research
are computational in nature. Likewise, the cost of a specific tool or design resource varies and
can be considered negligible (no single software tool exists that provides holistic, provably
optimal design, regardless of price). As such, performance with respect to time was the next
metric to be evaluated in this case study. As with accuracy, this metric can also be measured in
multiple ways. In this research, the measures considered included the length of time required for
model abstraction, debugging, run time, and data analysis.
9.2.1 Model Abstraction
Abstracting a space system design problem into an actionable model or set of algorithms is a
relatively straightforward endeavor when done in a procedural manner. In SPIDR-Sat v.0, the
209
design of the system was partitioned into modules for the mission, payload, each subsystem, and
system-level summations. The most difficult aspect of this approach was the need to enact a
directional design flow, and the related task of handling global variables accordingly. The
calculation of any prominent and frequently called variable, such as system mass, power, or cost,
was observed (and is well-known) to be problematic, as it requires the use of margins, estimates
and/or multiple iteration cycles in order to converge.
In the declarative approach, abstraction is in some ways just as straightforward, as subsystems
and design elements can be partitioned into modules in a similar manner. However, the process
was observed to be significantly easier in other ways, since it was not necessary to enact a
directional flow. Specifically, any rule or constraint can reside anywhere in the code architecture.
Furthermore, there is no such thing as a circular relationship in a constraint based approach.
Instead of having to manually link parameters where they interrelate between subsystems or
other modules, they only needed to be instantiated once in SPIDR-Sat then treated with an
appropriate constraint. For example, the Sum constraint can be applied to the system mass
variable in such a way that it is calculated as the sum of any other component parameter with the
“mass” label. The SPIDR engine aggregates these values as the design evolves, and constrains
the system mass variable’s interval domain accordingly. The variable can then be called at any
other location in the rule base.
This is a highly useful characteristic of the declarative approach to this problem. There appears
to be attempts by JHU/APL in their knowledge-based spacecraft modeling & simulation
approach (section 4.1.6.), and by EPFL in their constraint-based approach (section 4.1.3).
However, with APL’s methodology, the mass and power of the system are likely static
summations of the values obtained from each component through their “getMass()” and
210
“getPower()” calls [75], not dynamic summations. At EPFL, the design fidelity attempted does
not appear to have progressed beyond initial stages.
On the other hand, the declarative approach is so new that a steep learning curve was observed in
adapting to this unfamiliar technique. Similarly, as previously stated, the approach to
enumerating design options and associated conditions is counter-intuitive when compared to
existing approaches (see section 7.1.1).
9.2.2 Debugging
In most procedural approaches, the debugging process is reasonable, since tracking the design
flow and calculations of variables is facilitated in some way in most languages and tools (e.g.
Java, MATLAB, Excel). Debugging was found to be straightforward in the procedural SPIDR-
Sat v.0 approach, since all calculations could be traced back in the [Python] code, and any typo
or similar bug would lead to a clear error.
In the declarative approach, the debugging process took considerably longer. The dynamic
constraint propagation, interval domain shrinking, and design pruning that occurs in a constraint-
based system makes tracing back most calculations impossible. Instead, deeper inspection of the
model is required each time an error is discovered. In the absence of any tools to facilitate this
process, this involved searching for errors in models rules and in the problem inputs (mission
requirements and other inputs), tracking causal chains, and visualizing the complex relationships
211
between system, subsystems, components and other parameters to identify erroneous pathways
of calculation.
9.2.3 Runtime
Runtime of the procedural approach was fast. However, this is because the design run itself was
straightforward and low level: the results were of low fidelity. To achieve greater fidelity, the
process would have to be run multiple times and iterated upon to achieve better results. This
appears to be the case with the vast majority of approaches.
With the declarative approach, the actual run-time (of the engine) was also found to be extremely
fast (i.e. on the order of seconds, or minutes in the worst case). Only when a problem space was
not sufficiently constrained did the run time exceed this scale. In most methods used today, run
time can be on the scale of hours. And when accounting for iteration cycles, the runtime
observed in the declarative approach is likely many orders of magnitude lower than that of
procedural approaches, assuming comparable level of fidelity in design results and optimality.
This was also true for the time required for enacting design changes, re-running with changing
requirements, and performing tradeoff analysis. The immediate propagation of design changes is
another highly valuable attribute of the SPIDR-Sat performance that is not achievable in
previous approaches. This was found to be especially useful in CubeSat design, since high-level
mission elements can change often for this type of project (launch vehicle, orbit, launch date,
etc.). Lastly, since this eliminates the need to manually enforce changes and re-run tools to
212
identify the results of design changes, it not only reduces time but also the likelihood of
introducing error.
In the case of adaptable systems, the declarative approach exhibited significant improvements in
run time over existing approaches (in particular the JPL ASDA tool [45,56]). The runtime of the
former was on the order of minutes (maximum being 10s of minutes), while the runtime of the
latter is on the order of hours (approximately eight hours for a run involving a small set of design
alternatives, i.e. less than five). However, design fidelity also varies significantly between these
two examples, since ASDA runs a detailed spacecraft Discrete Event Simulator (DES).
9.2.4 Data Analysis
Finally, the time required for data analysis was examined.
In the procedural SPIDR-Sat v.0 environment, exporting satellite design data (e.g. a BOM) for
plotting and for analysis in external tools was straightforward given the features available in the
Python language. Similarly, in the majority of existing procedural approaches, there are well-
known embedded analysis capabilities, such as plotting in MATLAB and Excel. Thus, the time
for this process is negligible.
This was also straightforward in the new declarative approach, since the ability export in XML
enables a multitude of analysis options. The timescale here is also negligible, although it should
be noted that the automation enabled here decreases the time of the design through analysis
cycle.
213
In the case of tradespace exploration for adaptable systems, most existing approaches have
similar built-in capabilities. Indeed, plotting for analysis appears to be a paramount feature of
several past approaches. For instance, the ASDA approach is founded on the integration
capabilities of the ModelCenter environment, which enables visualization of complex, multi-
dimensional design spaces and interactive manipulation of the data [320]. The caveat in this case
is that the ModelCenter software is orders of magnitude more expensive than more common
tools.
However, the time required for data analysis in the SPIDR approach was significant since the
translation had to occur from XML to Excel, and in this process much of the metadata behind
each design data point is lost. For this reason it took a considerable amount of time to extract
meaning from the vast sets of data that were generated by the tool, then sanitized, exported, and
plotted.
9.3 Metric: Scalability
Last, the scalability of the approaches was assessed. The objective of this aspect of the study was
to evaluate the ability of each approach to scale, grow, or adapt to either higher fidelity design
phases (i.e. from conceptual and preliminary to detailed design), to new domains (e.g. from
satellites to CubeSats), or to the inclusion of new hardware, software or other approaches as it
becomes available.
214
In the procedural approach, this was observed to be a difficult undertaking. The specificity with
which variables and interrelationships must be defined makes the code fragile and inflexible.
This is likely true for most code-based procedural approaches, while Excel-based approaches
may not experience as much difficulty with this. Constraint based approaches such as EPFL’s are
likely less afflicted by this fragility as well.
In SPIDR, however, this is greatly improved. The code is not only modular, but the lack of
directionality and the ability to implement circular relationships makes the addition of new rules,
components and design options comparatively simple. It also renders this approach extensible to
new domains, as evidenced by the adaptation and extension of the initial SPIDR-Sat satellite
design knowledge to the domain of CubeSats. This was observed for both the satellite design and
the adaptable systems exploration efforts. With existing procedural approaches to adaptable
system modeling, these generally are highly specific to the domains and inflexible to changes.
The exception is, again, the ASDA approach, which functions by “wrapping” any design or
analysis element in the ModelCenter framework. This is a desirable and valuable approach, and
appears more robust than the SPIDR-based approach, but likely requires much more time to
implement (and as stated previously, is expensive).
9.4 Summary
A summary of the results of this case study is provided in Table 10:
215
Table 10. Summary of case study results
Metric Data Point Declarative Approach Procedural Approach
Accuracy Searchable
space
Greatly increased.
Satellite design: Exhaustive
enumeration and inclusion of non-
traditional options enabled.
Adaptable systems: Non-a priori
specific configurations are enabled.
Limited.
Optimization Greatly increased.
Provable global optimization
achieved.
Limited.
Time consuming, and no
guarantee of optimality.
Snowballing and weighting
can occur.
Time Model
abstraction
Improved, except up front
investment.
There is no need to specify
directionality or explicitly avoid
circular relationships.
However, learning curve is high
initially, requiring increased
investment of time up front.
Slow, but straightforward.
Explicitly defining
relationships and
interdependencies is slow.
Debugging Time significantly increased.
Few methods exist for debugging; it
is laborious and time consuming.
Fast and straightforward.
Many methods exist for
debugging.
Run time Satellite design: Greatly decreased.
Time and number of iteration
cycles decreased.
Adaptable systems: Dramatically
decreased.
Satellite design: Slow.
Runtime can be slow or fast
but extensive iteration
required.
Adaptable systems: Slow.
Data analysis Slow.
Difficult due to lack of embedded
options, loss of metadata during
transfer to external analysis
platforms.
Fast.
Existing methods generally
have internally embedded
features.
216
Scalability Code
modularity,
extensibility,
adaptability
Greatly improved.
Easy to add new rules. Easy to add
new components but laborious to
instantiate them.
Limited.
Fragile due to specificity of
parameter relationships and
code directionality.
217
Chapter 10
Conclusion
This research applied a new declarative approach to integrated, holistic space system design, and
to modeling and exploring tradespaces of complex, adaptable space systems. This chapter
discusses key findings of this research
13
, summarizes specific contributions made, and makes
recommendations for future research.
10.1 Findings
While there have been many efforts made to innovate on the satellite development process, the
vast majority of attempts continue to approach the problem in fundamentally the same way.
Regardless of any improvements made in design synthesis [246], visualization [45], or
knowledge sustainment [75], a central challenge persists: space system design involves a large
number of complex elements that are both multi-disciplinary and highly interrelated. With the
exception of some preliminary research that has implemented satellite design as a constraint
satisfaction problem [118], all past approaches to space system design employ serial design of
13
See Appendix D for additional general observations.
218
subsystem elements coupled with extensive iteration. This study’s use of a declarative design
approach (coupled with a database of existing components to enable useful and realistic results)
has demonstrated the ability to break this paradigm. As the case study showed, the declarative
approach improves accuracy, reduces run time, and allows use of modular and extensible code.
Specific associated benefits that are by nature not realizable with procedural approaches include
reduced iteration and implicit instantiation of tradespaces.
It has been shown that in order to achieve design convergence between multiple mutually
dependent subsystems, procedural approaches generally require either extensive iteration, or they
must enact some ordered flow that effectively weights certain subsystem design choices and
component sizing equations. By expressing variable domains as intervals and allowing pruning
via constraints, a closed-loop, bidirectional design can occur, thus reducing (or eliminating) the
need for iteration to achieve convergence. In addition to preventing the “snowball effect” in
sizing operations, this also removes the danger of circular relationships, significantly lowering
the complexity of code generation. In the same vein, this enables propagation of high-level
changes as well as local design decisions in real-time. Resultant outcomes can be compared with
each other for rapid identification of the “ripple effects” that certain design decisions or
requirements can have on a system. These characteristics are particularly useful for high fidelity,
highly constrained satellite design problems.
When modeling adaptable space systems, capturing high fidelity, complex constraints is not so
much a challenge as is generating tradespaces large and general enough that they adequately
cover the multitude of configurations that an architecture may possess. These may not be well
known a priori, may be laborious to define a priori, or both. For example, in the new declarative
approach, ascertaining the optimal size, number of clusters, degree of homogeneity, etc. in a
219
fractionated architecture is realizable without explicit definition of all possible configurations
beforehand. This was demonstrated with the use of quantified relations, which enable highly
compact expression of how modules and functionality can be distributed in any system.
In spite of these advancements, addressing certain weaknesses of the new declarative approach
would be beneficial in the adoption of this new technique. First, non-intuitive model abstraction
could hinder the ability of engineers and decision makers to understand, verify, change, and
interpret results from models using this approach. Thus an improved means for abstracting a
problem in a declarative manner and then capturing it in an actionable model is necessary (see
section 7.1.1). In addition, it was seen that debugging declarative code can be significantly more
challenging than in a procedural environment, where tracking design flow and calculations of
variables is straightforward. The dynamic discovery that occurs with a reasoning engine such as
SPIDR makes this impossible, thus requiring deeper inspection of a model. Some solutions for
handling this problem in declarative environments have been attempted, for example Daley et
al’s PlanWorks, a debugging environment for constraint based planning systems [48].
Finally, an observation was made regarding some results in the F-SPIDR study, which were
exemplified in Figure 44 of section 0, where certain fractionated systems appeared optimal over
others at unexpected points in the search space. In tradespace exploration, the goal of the SPIDR
engine is to identify and provide to the user the optimal design within each X search intervals
requested. Thus, F-SPIDR did not produce and display all possible designs generated by a
model, which can be problematic when differing configurations are equally optimal for a given
search. The resultant data plots may mislead an interpreter to believe that certain architecture
selections are the best fit for certain data points, and that all other designs are inferior for that
interval. This was exhibited in some results that initially looked anomalous. It was later
220
discovered that since the resultant designs were equal according to the optimization metric,
SPIDR selected certain architectures seemingly arbitrarily (based on its own dynamic search and
selection process).
10.2 Research Contributions
The primary contributions of this research are to the use of an innovative declarative modeling
approach to automated satellite design and optimization, modeling of adaptable space systems,
and in demonstrating the value of non-traditional approaches to the design and deployment of
cost effective, next-generation space systems. Importantly, this research provides valuable
contributions to our nation’s ability to field reliable, ground-breaking space systems that can
uphold our status as a world leader in commercial, military, national security, and scientific
space endeavors. Specific contributions in each of these fields are described in the following
sections.
10.2.1 Automated Satellite Design
The use of a declarative approach was shown to address the challenge of balancing the need for a
detailed modeling environment for conceptual and preliminary design, and the desire for a
simple and efficient user interface. The approach provides a novel framework for synthesizing
the design and analysis aspects of space system development, in one holistic, closed-loop
221
environment. This presents the opportunity for a more condensed and effective design process,
since steps such as the identification of cost drivers and the characterization of mission trades
and alternatives can be reduced. A method for implicit identification of trades and system-level
implications of localized design decisions was also established. Finally, this research provides a
set of rules and constraints that captures a conceptual- to preliminary-level knowledge base for
small satellite design and CubeSat design, as well as accompanying component databases. This
includes the provision of expressions for certain orbital and space system parameters that are
calculated via logical and mathematical operations, and thus cannot be solved closed-form by the
embedded interval math translator in reasoning engines such as SPIDR.
10.2.2 Declarative Modeling of Adaptable Space Systems
With respect to the design of adaptable space systems, this research has identified a modeling
approach that is both modular and scalable with respect to its knowledge base, since rules and
constraints can be added incrementally as new technologies become available. This
methodology, which is realized with a compact and elegant code structure, also presents a novel
approach to modeling adaptable space systems that is simultaneously flexible and powerful for
such architectures and large tradespaces. To improve the likelihood that this new approach can
become a useful tool for space system engineers, a set of modeling guidelines and a potential
abstraction methodology have been provided (section 7.1.2).
222
10.2.3 Value of Non-traditional and Adaptable Space Systems
Lastly, through the demonstrated ability to rapidly and reliably model adaptable space systems,
this research has provided compelling preliminary results that offer insight into the potential
economic advantages of fractionated space systems, as well as into the difficulties and possible
inefficiencies associated with CubeSats. The ability to computationally demonstrate the
advantages or disadvantages of fundamentally different, next-generation architectures (such as
fractionated systems, cellularized systems, systems enabled by on-orbit servicing, etc.) is an
increasingly valuable tool.
10.3 Recommendations for Future Research
Based on the findings that emerged from this research, several avenues for future research with
high payoff are proposed.
10.3.1 Automated Hardware-in-the-Loop Testing
One initial long-term goal of the SPIDR-Sat environment was the automatic flowdown of
component specifications from the generated design list to actual hardware-in-the-loop (HIL)
testing. The aim of this effort was to show that such high-fidelity information as data pin-outs
223
and software device drivers for hardware in the component database could be used in automatic
HIL testing based on SPIDR’s generation of a recommended design. Essentially, a software
device driver could be ported directly from the SPIDR-Sat results, or BOM, to the HIL setup,
which could then be run remotely over the internet. This was demonstrated through the test of
the thruster system on an Aeolus spacecraft test module at the USC/ISI SERC (in Marina del
Rey, CA) via GNC software being run remotely from Palo Alto, CA, in an entirely closed-loop
system [22]. While the demonstration did not occur directly from a SPIDR-Sat run, this would be
a valuable area for future research.
The AFRL’s research into the development and use of xTEDS [38] to reduce the need for ICDs
and enable automatic HIL test is similar to this effort, and while the use of xTEDS within this
framework was explored, collaboration was not pursued.
10.3.2 Fluid Mission Requirements
SPIDR-Sat aimed to provide information on the delta in cost, performance, or other system
parameters between nominal and off-nominal missions (i.e. the next best design(s) that still meet
mission objectives, or most closely meet mission objectives). However, a more valuable feature
may be to allow the driving inputs and mission requirements to change, essentially providing
reverse insight into the delta in performance (e.g. pointing accuracy, lifetime, or coverage) that,
if allowed, would enable some desirable savings in cost. With this information, an engineer can
decide whether a compromise in mission performance may be justified or desirable.
224
10.3.3 Other Adaptable Systems
Based on the work provided in this research, it is clear that the declarative SPIDR framework
may be very well suited to the problem of cellularized satellites, both in the design of the cells
(i.e. which functions should be allocated to which modules, what degree of homogeneity, and
what level of performance), and to the optimal aggregation of the cells into a system. Since both
of these problems could be addressed and designed in one integrated problem specification, the
declarative approach presents a unique and valuable capability for this field.
10.3.4 Integration with Existing Research and Methods
Integrating the declarative modeling approach developed in this study with existing research
methods could provide valuable results. For example, “wrapping” SPIDR-Sat or F-SPIDR in
Phoenix Integration’s ModelCenter environment would enable the inclusion of a closed-loop
optimization engine within a broader design or tradespace exploration process, for example in
JPL’s ASDA environment [45]. However, combining the SPIDR-based approach with
probabilistic-based tools (i.e. ASDA) would be problematic since the latter are based on the use
of random variables, and thus would not be well-suited to SPIDR’s search and optimization
methods. The use of B&B search could be used with such approaches as a basis for heuristic
analysis, for example by stopping the search when the optimization metric reaches some interval,
in order to accommodate noisy data. Similar approaches have been explored, for example by
Zabinsky et al through their Probabilistic Branch & Bound method [271], and by Attiya and
225
Haman in the application of B&B to near optimal results from a Simulated Annealing algorithm
[14].
Another area that would benefit greatly from further research is that of the data generation and
analysis capabilities in F-SPIDR. In the F6 program, it became clear that the SPIDR engine
could produce massive quantities of data, and depending on the complexity of the design
problem and inputs, extracting meaningful information from such a vast amount of data and
interpreting it is a non-trivial challenge. Pairing F-SPIDR with the ModelCenter environment,
which can handle large quantities of data and express compelling results in a more user friendly
manner, is one promising solution.
Last, the Parameter Influence Net (PIN) seeks to identify implications of subsystem design
choices on system level parameters [167], which resonates with a primary objective of the
SPIDR-based framework. Integration of the PIN technique internal to a SPIDR-based design and
optimization loop, or analyzing a set of designs using PIN after a SPIDR run, may be an
interesting pairing of capabilities.
10.4 Final Summary
In summary, the research presented in this dissertation demonstrates a novel, declarative
approach to space system design. The key contributions of this research are improved
effectiveness via increased accuracy, speed, and model scalability.
226
References
[1] C. Aas, B.T.C. Zandbergen, R.J. Hamann, E. Gill, Development of a System Level Tool
for Conceptual Design of Small Satellites, in: Proc. Conf. Syst. Eng. Res., Loughborough,
England, 2009.
[2] C. Aas, B.T.C. Zandbergen, R.J. Hamann, E.K.A. Gill, SCALES – A System Level Tool
for Conceptual Design of Nano- and Microsatellites, in: Proc. IAAA Symp. Small Satell.
Earth Obs., Berlin, Germany, 2009: pp. 1–8.
[3] N. Adilov, P.J. Alexander, B.M. Cunningham, Earth Orbit Debris: An Economic Model,
2013.
[4] J.A. Aguilar, A. Dawdy, Scope vs. Detail: The Teams of the Concept Design Center, in:
Proc. IEEE Aerosp. Conf., Big Sky, MT, 2000.
[5] J.A. Aguilar, A. Dawdy, G.W. Law, The Aerospace Corporation’s Concept Design
Center, in: Proc. Int. Symp. Int. Counc. Syst. Eng., 1998.
[6] M.R. Aherne, J.T. Barrett, L. Hoag, E. Teegarden, R. Ramadas, Aeneas -- Colony I Meets
Three-Axis Pointing, in: Proc. AIAA/USU Conf. Small Satell., 2011.
[7] L. Aiello, G. Attardi, G. Prini, Towards a More Declarative Programming Style, in: Proc.
IFIP Work. Conf. Form. Descr. Program. Concepts, Stuttgart, Germany, 1977.
[8] Y. Akao, G.H. Mazur, The leading edge in QFD: past, present and future, Int. J. Qual.
Reliab. Manag. 20 (2003) 20–35.
[9] D.L. Akin, Akin’s Laws of Spacecraft Design, Http://spacecraft.ssl.umd.edu/. (n.d.).
[10] D.L. Akin, N. Limparis, K. McBryan, Enabling Dexterous Manipulation and Servicing by
Smallsats Conference on Small Satellites, in: Proc. AIAA/USU Conf. Small Satell.,
Logan, Utah, 2012.
[11] A. Aliakbargolkar, Architecting Federated Satellite Systems for Successful Commercial
Implementation, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[12] D. Alinger, System Analysis and Design for the Resonant Inductive Near-field Generation
System (RINGS), University of Maryland, 2013.
227
[13] J.A. Atchison, M. Peck, A Millimeter-Scale Lorentz-Propelled Spacecraft, in: Proc. AIAA
Guid. Navig. Control Conf. Exhib., Hilton Head, South Carolina, 2007: pp. 1–23.
[14] G. Attiya, Y. Hamam, Two Phase Algorithm for Load Balancing in Heterogeneous
Distributed Systems, in: Proc. Euromicro Conf. Parallel, Distrib. Network-Based Process.,
Ieee, A Coruna, Spain, 2004: pp. 434–439.
[15] D. Axe, How the Navy’s Warship of the Future Ran Aground, WIRED. (2011).
[16] E. Balaban, M. Orosz, T. Kichkaylo, A. Goforth, A. Sweet, R. Neches, Planning to
Explore: Using a Coordinated Multisource Infrastructure to Overcome Present and Future
Space Flight Planning Challenges, in: Proc. AAAI Spring Symp. Distrib. Plan Sched.
Manag., Palo Alto, CA, 2006.
[17] C. Baldwin, K. Clark, Design Rules: The Power of Modularity, MIT Press, Cambridge,
MA, 2000.
[18] D. Barnhart, L. Hill, E. Fowler, R. Hunter, L. Hoag, B.R. Sullivan, et al., A Market for
Satellite Cellularization? A First Look at the Implementation and Potential Impact of
Satlets, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013: pp. 1–11.
[19] D. Barnhart, T. Kichkaylo, L. Hoag, SPIDR : Integrated Systems Engineering Design-to-
Simulation Software for Satellite Build, in: Proc. Conf. Syst. Eng. Res., Loughborough,
England, 2009.
[20] D. Barnhart, B.R. Sullivan, Economics of Repurposing In Situ Retired Spacecraft
Components, in: Proc. AIAA Sp. Conf., Pasadena, CA, 2012.
[21] D. Barnhart, B.R. Sullivan, R. Hunter, J. Bruhn, E. Fowler, L. Hoag, et al., Phoenix
Project Status 2013, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[22] J.T. Barrett, D. Barnhart, J. Kunc, R. Karkhanis, E. Vartanian, M. Guzman, et al., USC’s
Approach to Satellite-Based, Hands-On, Training: The Engineering Teaching Hospital, in:
Proc. AIAA Sp. Conf., Long Beach, CA, 2011: pp. 1–8.
[23] T.P. Bauer, R.C. Conger, J.R. Wertz, N. Sarzi-Amade, Design, Performance, and
Responsiveness of a Low-Cost Micro-Satellite Launch Vehicle, in: Proc. AIAA
Responsive Sp. Conf., Los Angeles, CA, 2010: pp. 1–13.
[24] K.L. Bedingfield, R.D. Leach, M.B. Alexander, Spacecraft System Failures and
Anomalies Attributed to the Natural Space Environment Spacecraft System Failures and
Anomalies Attributed to the Natural Space Environment, Huntsville, AL, 1996.
[25] S.W. Beidleman, AFCEA Luncheon Development Planning Directorate Overview, Los
Angeles, CA, 2012.
228
[26] J. Belmonte, Design for Manufacturability (DFM), Design for Assembly (DFA), in: Proc.
SMTA Guadalajara Tech Forum Expo, Guadalajara, Mexico, 2012.
[27] F.M.. Brazier, P.H.. van Langen, J. Treur, Strategic knowledge in design: a compositional
approach, Knowledge-Based Syst. 11 (1998) 405–416.
[28] A.W. Brown, R. Moazeni, B. Boehm, Software Cost Estimation for Fractionated Space
Systems, in: Proc. AIAA Sp. Conf., San Diego, CA, 2008.
[29] O. Brown, Reducing Risk of Large Scale Space Systems Using a Modular Architecture,
in: Proc. Sp. Syst. Eng. Risk Manag. Symp., Manhattan Beach, CA, 2004.
[30] O. Brown, P. Bremenko, C. Roberts, Cost-Benefit Analysis of a Notational Fractionated
SATCOM Architecture, in: Proc. AIAA Sp. Conf., Long Beach, CA, 2006.
[31] O. Brown, P. Eremenko, The value proposition for fractionated space architectures, in:
Proc. AIAA Sp. Conf., San Jose, CA, 2006: pp. 1–22.
[32] O. Brown, P. Eremenko, Application of Value-Centric Design to Space Architectures: The
Case of Fractionated Spacecraft, in: Proc. AIAA Sp. Conf., San Diego, CA, 2008.
[33] O. Brown, P. Eremenko, M. Bille, Fractionated Space Architectures: Tracing the Path to
Reality, in: Proc. AIAA/USU Conf. Small Satell., Logan, Utah, 2009.
[34] O. Brown, P. Eremenko, P.D. Collopy, Value-centric design methodologies for
fractionated spacecraft: progress summary from Phase 1 of the DARPA system F6
program, (2009) 1–14.
[35] A. Butler, USAF Announces Contenders For OSP-3 Launches, Aviat. Week. (2012).
[36] A. Butler, USAF Studies “Disaggregated” Weather Satellite Concept, Aviat. Week.
(2013).
[37] P. Carter, O. Brown, T. Rice, DARPA’s Rapid Access Small Cargo Affordable Launch
(RASCAL), in: Proc. AIAA Responsive Sp. Conf., Redondo Beach, CA, 2003.
[38] K.B. Center, D. Fronterhouse, M. Martin, The Software Strategy for SPA Plug and Play
Spacecraft, in: Proc. IEEE Aerosp. Conf., Ieee, 2010: pp. 1–11.
[39] M. Chaize, A.L. Weigel, Assessing the flexibility provided by fractionated spacecraft, in:
Proc. AIAA Sp. Conf., 2005.
[40] D. Chow, Europe Gets Serious About Space Junk Menace, SPACE.com. (2013).
[41] I. Christensen, D. Vaccaro, D. Kaiser, Market Characterization: Launch of Very-Small
and Nano Sized Payloads Enabled by New Launch Vehicles, Bethesda, MD, 2010.
229
[42] S. Clark, Athena rocket reborn under aerospace industry alliance, SpaceflightNow.com.
(2010).
[43] L.E. Cohan, R. Chambers, R.K. Lee, C.J.E. Keesee, Analysis of Modular Spacecraft Bus
Design for Rapid Response Missions, in: Proc. AIAA Responsive Sp. Conf., Los Angeles,
CA, 2006.
[44] P.D. Collopy, Economic-based distributed optimal design, in: Proc. AIAA Sp. Conf.,
Reston, VA, 2001: pp. 1–9.
[45] S. Cornford, R. Shishko, S. Wall, B. Cole, S. Jenkins, N. Rouquette, et al., Evaluating a
Fractionated Spacecraft System: A Business Case Tool for DARPA’s F6 program, in:
Proc. IEEE Aerosp. Conf., IEEE, Albuquerque, NM, 2012: pp. 1–20.
[46] M. Coutinho, R. Eleish, J. Kim, V. Kumar, S.R. Ling, R. Neches, et al., Active Catalogs:
Integrated Support for Component Engineering, in: Proc. ASME Des. Eng. Tech. Conf.,
Atlanta, GA, 1998.
[47] K. Cowing, Internal NASA Studies Show Cheaper and Faster Alternatives to the Space
Launch System, Spaceref.com. (n.d.).
[48] P. Daley, J. Frank, M. Iatauro, C. Mcgann, W. Taylor, PlanWorks: A Debugging
Environment for Constraint Based Planning Systems, in: NASA Tech. Doc., Moffett
Field, CA, 2005.
[49] M. Daniels, B. Tracey, J. Irvine, W. Schram, M.E. Pate-Cornell, Probabilistic Simulation
of Multi-Stage Decisions for Operation of a Fractionated Satellite Mission, in: Proc. IEEE
Aerosp. Conf., Ieee, Big Sky, MT, 2011: pp. 1–16.
[50] L. David, “Sling-Sat” Could Remove Space Junk on the Cheap, SPACE.com. (2013).
[51] S. V. Deal, V. Coverstone-Caroll, A Simplified Use of Quality Function Deployment as a
System Tool for Designing to Cost, in: n.d. pp. 1–22.
[52] E.B. Dean, Parametric Cost Deployment, (n.d.) 1–8.
[53] C. Dillow, Virgin Galactic Unveils Its Satellite-Launching Rocket, Will Be Lofted Into
Orbit By WhiteKnightTwo, Pop. Sci. (2012).
[54] S. Donikian, G. Hegron, A Declarative Design Method for 3D Scene Sketch Modeling,
Comput. Graph. Forum. 12 (1993) 223–236.
[55] T. Doyne, P. Wegner, R. Riddle, M. Hurley, M. Johnson, T. Duffey, TacSat and ORS
activity, in: Proc. 4S Symp. Small Satell. Syst. Serv., Sardinia, Italy, 2006.
230
[56] G. Dubos, S. Cornford, Modeling Temporal Processes in Early Spacecraft Design:
Application of Discrete-Event Simulations for DARPA’s F6 Program, (n.d.) 1–13.
[57] K. Dunham, Space Engineering Research Center Launches Nanosatellite, Univ. South.
Calif. Viterbi Sch. Eng. News. (2012).
[58] E. Eichenberg-Bicknell, M. Wisniewski, S. Choi, D. Westley, Using a Value-Centric Tool
Framework to Optimize Lifecycle Cost, Value, and Risk of Spacecraft Architectures, in:
Proc. AIAA Sp. Conf., Reston, VA, 2009.
[59] A. Finch, Dichotomous Spacecraft: Simplified Fractioantion, Purdue University, 2011.
[60] M.E. Fitzgerald, A.M. Ross, Mitigating Contextual Uncertainties with Valuable
Changeability Analysis in the Multi-Epoch Domain, in: Proc. IEEE Int. Syst. Conf., Ieee,
Vancouver, Canada, 2012: pp. 1–8.
[61] M.E. Fitzgerald, A.M. Ross, Sustaining Lifecycle Value: Valueable Changeability
Analysis with Era Simulation, in: Proc. IEEE Int. Syst. Conf., Ieee, Vancouver, Canada,
2012: pp. 1–7.
[62] R. Fleeter, G. Colonna, M. Menapace, E. Stefanini, M. Stipa, Space-Point Web Services:
Injecting reality into concurrent system engineering, in: Int. Work. Syst. Concurr. Eng. Sp.
Appl., Lisbon, Portugal, 2012.
[63] J. Foust, If you Build It, Who Will Come? Identifying Markets for Low-Cost Small
Satellites, in: Proc. AIAA/USU Conf. Small Satell., Logan, Utah, 2008.
[64] J. Foust, Emerging Opportunities for Low-Cost Small Satellites in Civil and Commercial
Space, in: Proc. AIAA/USU Conf. Small Satell., Logan, Utah, 2010.
[65] J. Foust, New opportunities for smallsat launches, TheSpaceReview.com. (2011).
[66] J. Foust, Smallsat constellations: the killer app?, TheSpaceReview.com. (2013).
[67] G. Friedman, Constraint Theory: an overview, Int. J. Syst. Sci. 7 (2010) 1113–1151.
[68] D. Fronterhouse, J. Lyke, S. Achramowicz, Plug-and-play Satellite (PnPSat), in: Proc.
AIAA Infotech@aerosp. Conf. Exhib., Rohnert Park, CA, 2007.
[69] A.S. Fukunaga, A. Stechert, S. Chien, Towards a Self-Configuring Optimization System
for Spacecraft Design, in: Proc. I-Sairas Conf., Tokyo, Japan, 1997.
[70] A.S. Fukunaga, A.D. Stechert, An Evolutionary Optimization System for Spacecraft
Design, in: Proc. Tenth Int. Conf. Ind. Eng. Appl. Artif. Intell. Expert Syst., 1997.
231
[71] K. Galabova, Architecting a Family of Space Tugs Based on Orbital Transfer Mission
Scenarios, Massachusetts Institute of Technology, 2004.
[72] R.L. Galski, F.L. De Sousa, F.M. Ramos, I. Muraoka, Spacecraft Thermal Design with the
Generalized Extremal Optimization Algorithm, in: Proc. Inverse Probl. Des. Optim.
Symp., Rio de Janeiro, Brazil, 2004.
[73] J. George, J. Peterson, S. Southard, Multidisciplinary Integrated Design Assistant for
Spacecraft (MIDAS), in: Proc. Am. Inst. Aeronaut. Astronaut., 1995.
[74] G. Glaros, Transformation Trends, Arlington, VA, 2003.
[75] A. Goldfinger, D. Silberberg, J. Gersh, J. Hunt, F. Weiskopf, T. Spisz, et al., A
knowledge-based approach to spacecraft distributed modeling and simulation, Adv. Eng.
Softw. 31 (2000) 669–677.
[76] D. Gregory, J. Mergen, A. Ridley, Space Debris Elimination (SpaDE) Phase I Final
Report, 2012.
[77] H.R. Grooms, W. Blanchard, D. Hawthorne, K. Fisk, An Automated Database System for
Preliminary Spacecraft Design, Eng. Data Manag. Key to Integr. Prod. Dev. Proc. 1992
ASME Int. Comput. Eng. Conf. Expo. (1992).
[78] J. Gross, A. Reichwein, S. Rudolph, D. Bock, R. Laufer, An Executable Unified Product
Model Based on UML to Support Satellite Design, in: Proc. AIAA Sp. Conf., American
Institute of Aeronautics and Astronautics, Pasadena, CA, 2009.
[79] M. Gruss, U.S. Air Force Report Cites Benefits of Disaggregation, Sp. News. (2013).
[80] C. Guariniello, D.A. Delaurentis, Maintenance and Recycling in Space: Functional
Dependency Analysis of On-Orbit Servicing Satellites Team for Modular Spacecraft, in:
Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[81] J. Guo, D. Maessen, E. Gill, Fractionated Spacecraft: The New Sprout in Distributed
Space Systems, in: Proc. Int. Astronaut. Congr., Daejeon, Korea, 2009.
[82] Z. Guo, Z. Chen, Z. Wang, Multi-discipline Collaborative Design and Simulation
Environment of Spacecraft, in: Int. Symp. Syst. Control Aeronaut. Astronaut., Harbin,
China, 2010: pp. 1208–1211.
[83] S. H. Choi, R. S. Pappa, Assessment Study of Small Space Debris Removal by Laser
Satellites, Recent Patents Sp. Technol. 2 (2012) 116–122.
[84] H. Habib-Agahi, J. Mrozinski, G. Fox, NASA Instrument Cost/Schedule Model, in: Proc.
IEEE Aerosp. Conf., Big Sky, MT, 2010.
232
[85] E. Hall, M. Papadopoulos, GPS Structural Modifications for On-Orbit Servicing, in: Proc.
AIAA Sp. Technol. Conf. Expo., Albuquerque, NM, 1999.
[86] D. Harland, R. Lorenz, Space Systems Failures: Disasters and Rescues of Satellites,
Rocket and Space Probes, Springer Praxis, 2005.
[87] R.A. Hassan, W.A. Crossley, Multi-Objective Optimization of Communication Satellites
with Two-Branch Tournament Genetic Algorithm, J. Spacecr. Rockets. 40 (2003).
[88] D.E. Hastings, H. McManus, A Framework for Understanding Uncertainty and its
Mitigation and Exploitation in Complex Systems, in: Proc. MIT Eng. Syst. Symp.,
Cambridge, MA, 2004.
[89] J. Hauser, D. Clausing, The House of Quality, Harv. Bus. Rev. (1988).
[90] G. Hegemann, D. Goldstein, L. Curtis, P. Remias, Leveraging Commercial Satellite
Constellation Production to Reduce Mission Cost: Advantages and Challenges, in: Proc.
AIAA Sp. Conf., San Diego, CA, 2013.
[91] C. Herwig, Real Time Imagery via MapBox Satellite Live, Mapbox.com. (2013).
[92] L. Hill, K. Leavitt, W. Voshell, A.L. Weigel, A Value Centric Design Approach to Earth
Observing Missions, in: Proc. AIAA Sp. Conf., Reston, VA, 2009.
[93] L. Hoag, CubeSats and the Standardization of Satellite Structures, Los Angeles, CA, 2010.
[94] L. Hoag, T. Kichkaylo, D. Barnhart, A Systems Architecting Approach to Automation and
Optimization of Satellite Design in SPIDR, in: Proc. Int. Conf. Eng. Meta-Engineering,
Orlando, FL, 2010.
[95] E. Horowitz, There’s a Sat App for That, SpaceNews.com. (2011).
[96] D. Howard, USC Systems Architecting and Engineering Department - SAE 549 Lecture
Notes, (n.d.).
[97] Z. Hu, Z. You, J. Guo, D. Ren, A New System Engineering Method for Spacecraft
Design, in: Proc. AIAA Sp. Conf., Long Beach, CA, 2003.
[98] T. Hunsaker, M. Bille, P. Kolodziejski, Nanosat Launch Vehicles: A Global Perspective
and Business Case, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[99] M. Hurley, Micro-Satellite Deployment On-Demand, in: Proc. AIAA Responsive Sp.
Conf., Redondo Beach, CA, 2003.
[100] B. Jackson, A low-cost, responsive microsat bus utilizing COTS parts and components, in:
Proc. IEEE Aerosp. Conf., Poway, CA, 2008.
233
[101] M. Jacquiau, SYSTEMA / THERMICA version 4 Overview of the new capabilities, in:
Eur. Work. Therm. ECLS Softw., 2002.
[102] T. Jaeger, W. Mirczak, Satlets - The Building Blocks of Future Satellites - And Which
Mold Do You Use?, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[103] C.D. Jilla, A Multiobjective, Multidisciplinary Design Optimization Methodology for the
Conceptual Design of Distributed Satellite Systems, Massachusetts Institute of
Technology, 2002.
[104] C.D. Jilla, D. Miller, Multi-Objective, Multidisciplinary Design Optimization
Methodology for Distributed Satellite Systems, J. Spacecr. Rockets. 41 (2004).
[105] M. Kaplan, Linking JWST and Human Spaceflight, TheSpaceReview.com. (2011).
[106] G. Karpati, J. Martin, M. Steiner, The Integrated Mission Design Center (IMDC) At
NASA Goddard Space Flight Center, in: Proc. IEEE Aerosp. Conf., Big Sky, MT, 2003.
[107] A.T. Kavelaars, E. Bloom, R. Claus, K. Fouts, S. Tuvi, Electronic Logbook for Space
System Integration & Test Operations, IEEE Trans. Aerosp. Electron. Syst. 45 (2009)
167–178.
[108] R. Keeney, Value-Focused Thinking: A Path to Creative Decisionmaking, Harvard
University Press, Cambridge, MA, 1992.
[109] J. Keller, DARPA eyes space-based Internet for persistent battlefield data
communications, surveillance, and satellite control, MilitaryAerospace.com. (2010).
[110] A.A. Kerzhner, M.O. Khan, M.D. Ingham, J. Ramirez, J. Hollman, J. de Luis, et al.,
Architecting Cellularized Space Systems using Model-Based Design Exploration, in:
Proc. AIAA Sp. Conf., San Diego, CA, 2013: pp. 1–24.
[111] D.J. Kessler, B.G. Cour-Palais, Collision Frequency of Artificial Satellites: The Creation
of a Debris Belt, J. Geophys. Res. 83 (1978).
[112] T. Kichkaylo, Tnet HowTo, Marina del Rey, CA, 2008.
[113] T. Kichkaylo, D. Barnhart, L. Hoag, Engineering Design with SPIDR, Marina del Rey,
CA, 2010.
[114] T. Kichkaylo, C. van Buskirk, S. Singh, H. Neema, M. Orosz, R. Neches, Mixed-Initiative
Planning for Space Exploration Missions, in: Proc. ICAPS Work. Mov. Plan. Sched. Syst.
into Real World, Marina del Rey, CA, 2007: pp. 1–8.
234
[115] T. Kichkaylo, L. Hoag, E. Lennon, G. Roesler, Highly Efficient Exploration of Large
Design Spaces : Fractionated Satellites as an Example of Adaptable Systems, in: Proc.
Conf. Syst. Eng. Res., St. Louis, MO, 2012.
[116] T. Kichkaylo, G. Roesler, Automating Trade Space Analysis in Systems Design, in: Proc.
Conf. Syst. Eng. Res., Redondo Beach, CA, 2011.
[117] C.J. Kief, B. Zufelt, S.R. Cannon, J. Lyke, J.K. Mee, The Advent of the PnP Cube
Satellite, in: Proc. IEEE Aerosp. Conf., Albuquerque, NM, 2012.
[118] D.Y. Kim, P. Xirouchakis, CO2DE: a decision support system for collaborative design, J.
Eng. Des. 00 (2008) 1–18.
[119] J. Koebler, Switzerland Announces Plan to Clean Up Space Junk, USNews.com. (2012).
[120] R. Kohl, Low Earth Orbit (LEO) Infrastructure: Services, Stakeholders and Challenges for
Economic Development, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[121] M. Kramer, NASA Spacecraft Cruising to Moon With Novel Design, SPACE.com.
(2013).
[122] G.D. Krebs, PnPSat 1, Gunter’s Sp. Page. (n.d.).
[123] T. Kunstmann, M. Frisch, R. Muller, A Declarative Programming Environment Based on
Constraints, in: Proc. IEEE Symp. Vis. Lang., Darmstadt, Germany, 1995: pp. 120–121.
[124] D.W. Kwon, Propellantless formation flight applications using electromagnetic satellite
formations, Acta Astronaut. 67 (2010) 1189–1201.
[125] D.W. Kwon, M. Cheplak, Applications of Fractionated Spacecraft Architectures, in: Proc.
AIAA Sp. Conf., Long Beach, CA, 2011.
[126] J.M. Lafleur, Exploring the F6 Fractionated Spacecraft Trade Space with GT-FAST,
Atlanta, GA, 2009.
[127] J.M. Lafleur, J.H. Saleh, GT-FAST: A Point Design Tool for Rapid Fractionated
Spacecraft Sizing and Synthesis, in: Proc. AIAA Sp. Conf., Pasadena, CA, 2009: pp. 1–
20.
[128] N. Lamarra, J. Dunphy, Interactive Sharable Environment for Collaborative Spacecraft
Design, in: Proc. IEEE Aerosp. Conf., Big Sky, MT, 1998.
[129] E.S. Lamassoure, A Framework to Account for Flexibility in Modeling the Value of On-
Orbit Servicing for Space Systems, Massachusetts institute of Technology, 2001.
235
[130] A.H. Land, A.G. Doig, An Automatic Method of Solving Discrete Programming
Problems, Economoetrica. 28 (1960) 497–520.
[131] W.J. Larson, J.R. Wertz, Space Mission Analysis and Design, 3rd ed., Published jointly by
Microcosm Press and Springer, 1999.
[132] M. Lavagna, A.E. Finzi, Preliminary Spacecraft Design: Genetic Algorithms and AHP to
Support the Concurrent Process Approach, in: Proc. Int. Astronaut. Congr., Bremen,
Germany, 2003: p. 2003.
[133] M. Lavagna, A.E. Finzi, A MADM Approach Towards Space System Design Automation
by a Fuzzy Logic-Based Analytic Hierarchy Process, in: Proc. Int. Symp. Artif. Intell.
Robot. Autom. Sp., NARA, Japan, 2003.
[134] G. Leisman, A. Wallen, S. Kramer, W. Murdock, Analysis and Preliminary Design of On-
Orbit Servicing Architectures for the GPS Constellation, Am. Inst. Aeronaut. Astronaut.
(1999).
[135] E. Levin, J. Pearson, J. Carroll, J. Oldson, Orbital Debris: Time to Remove, Mount
Pleasant, SC, 2011.
[136] P.C. Liewer, A.T. Klesh, M.W. Lo, N. Murphy, R.L. Staehle, V. Angelopoulos, et al., A
Fractionated Space Weather Base at L5 using CubeSats & Solar Sails, in: Proc.
Interplanet. Small Satell. Conf., Pasadena, CA, 2013.
[137] C.F. Lillie, B.E. Thompson, Parametric Cost Estimation for Space Science Missions,
SPIE, Adv. Opt. Mech. Technol. Telesc. Instrum. 7018 (2008) 1–12.
[138] R. Lloyd, Metric mishap caused loss of NASA orbiter, CNN.com. (1999).
[139] D.M. LoBosco, G.E. Cameron, R.A. Golding, T.M. Wong, The Pleiades Fractionated
Space System Architecture and The Future of National Security Space, in: Proc. AIAA
Sp. Conf., San Diego, CA, 2008.
[140] S.C.-Y. Lu, N.-P. Suh, Complexity in Design of Technical Systems, CIRP Ann. - Manuf.
Technol. 58 (2009).
[141] H. Luo, J. Yu, J. Zhou, Issues on constraint-based design approaches, in: Proc. Int. Conf.
Comput. Des. Comput. Graph., Wuhan, China, 1996.
[142] D.B. Maciuca, J.K. Chow, A. Siddiqi, O.L. de Weck, S. Alban, L.D. Dewell, et al., A
Modular, High-Fidelity Tool to Model the Utility of Fractionated Space Systems, Encycl.
Aerosp. Eng. (2010) 1–37.
[143] A. Madni, The Role of Human Factors in Expert Systems Design and Acceptance, Hum.
Factors J. Hum. Factors Ergon. Soc. 30 (1988) 395–414.
236
[144] S. Magnuson, Scientists Pursue Flexible, Adaptable Space Systems,
NationalDefenseMagazine.org. (2007).
[145] J. Manas, L. Guise, Systems Engineering for Test: Implementation of Test Strategy &
Architecture at Raytheon Missile Systems, Proc. IEEE Int. Syst. Conf. (2013) 305–311.
[146] H. Markowitz, Mean Variance Analysis in Portfolio Choice and Capital Markets, Frank J.
Fabozzi Associates, New Hope, PA, 1987.
[147] P. Marks, SpaceX satellite loss is a warning for ride sharers, Newscientist.com. (2012).
[148] M. Martin, J. Summers, J. Lyke, AFRL Plug-and-Play Spacecraft Avionics Experiment
(SAE), in: Proc. IEEE Aerosp. Conf., Ieee, Albuquerque, NM, 2012: pp. 1–6.
[149] B. Mason, MapBox Plans to Bring You Super-Fresh Satellite Imagery, WIRED. (2013).
[150] R.A. Masterson, D. Miller, Development and Validation of Empirical and Analytical
Reaction Wheel Disturbance Models, Massachusetts Institute of Technology, 1999.
[151] D. McCormick, B. Barrett, M. Burnside-Clapp, Analyzing Fractionated Satellite
Architectures Using RAFTIMATE - A Boeing Tool for Value-Centric Design, in: Proc.
AIAA Sp. Conf., Pasadena, CA, 2009.
[152] H. McCurdy, Faster, Better, Cheaper: Low Cost Innovation in the US Space Program,
Johns Hopkins University Press, Baltimore, MD, 2001.
[153] A.I. McInnes, D.M. Harps, J.A. Lang, C.M. Swenson, A Systems Engineering Tool for
Small Satellite Design, in: Proc. AIAA/USU Conf. Small Satell., 2001.
[154] T. McKendree, USC Systems Architecting and Engineering Department - SAE 549
Lecture Notes, (n.d.).
[155] I. McNab, Launch to Space With an Electromagnetic Railgun, IEEE Trans. Magn. 39
(2003) 295–304.
[156] M. McVey, Valuation Techniques for Complex Space Systems: An Analysis of a Potential
Satellite Servicing Market, Massachusetts Institute of Technology, 2002.
[157] S. Meyers, R. Brealey, Principles of Corporate Finance, 7th ed., McGraw Hill, 2003.
[158] R.C. Mitchell, R. Carson, Using Surveys to Value Public Goods: The Contingent
Valuation Method, Johns Hopkins University Press, Baltimore, MD, 1989.
[159] P. Molette, C. Cougnet, P. Saint-Aubert, R.W. Young, D. Helas, Technical and
Economical Comparison Between A Modular Geostationary Space Platform and A
Cluster of Satellites, Acta Astronaut. 12 (1984) 771–784.
237
[160] R. Moore, R.B. Kearfott, M. Cloud, Interval Analysis, Philadelphia, PA, 2009.
[161] F.J. Morring, MDA, Intelsat Launch Sat Refueling Business, Aviat. Week. (2011).
[162] M. Moser, Declarative Scheduling for Optimally Graceful QoS Degradation, in: Proc.
IEEE Int. Conf. Multimed. Comput. Syst., IEEE Comput. Soc. Press, Hiroshima, Japan,
1996: pp. 86–94.
[163] T. Mosher, Spacecraft Design Using A Genetic Algorithm Optimization Approach, in:
Proc. IEEE Aerosp. Conf., 1998: pp. 123–134.
[164] T. Mosher, Conceptual Spacecraft Design Using a Genetic Algorithm Trade Selection
Process, J. Aircr. 36 (1999) 200–208.
[165] T. Mosher, M. Barrera, D. Bearden, N. Lao, Integration of Small Satellite Cost and Design
Models for Improved Conceptual Design-to-Cost, in: Proc. IEEE Aerosp. Conf., Aspen,
CO, 1998.
[166] G. Napier, Lockheed Martin Athena Launch Vehicles Selected as an Air Force Launch
Services Provider, LockheedMartin.com. (2012).
[167] T. Nemetzade, R. Forstner, Quantification of the Influence between Satellite Design
Parameters for the Support of System Design Decisions, in: Proc. AIAA Sp. Conf., San
Diego, CA, 2013.
[168] R. de Neufville, Uncertainty Management for Engineering Systems Planning and Design,
in: MIT ESD Eng. Syst. Monogr., Cambridge, MA, 2004.
[169] R. Nilchiani, M. Efatmaneshnik, K. Dalili, Measuring the Value of Adaptability of
Fractionated Spacecrafts, in: Proc. INCOSE Int. Symp., Rome, Italy, 2012.
[170] R. Nilchiani, B. Heydari, New Paradigms in Systems Design of the Future Fractionated
Spacecrafts: Uncertainties, Hoboken, NJ, 2011.
[171] A.K. Noor, S.L. Venneri, ISE : Intelligent Synthesis Environment for Future Aerospace
Systems, IEEE Aerosp. Electron. Syst. Mag. (2008).
[172] M.G. O’Neill, A.L. Weigel, Assessing the Impacts of Fractionation on Pointing-Intensive
Spacecraft, in: Proc. AIAA Sp. Conf., Pasadena, CA, 2009: pp. 1–14.
[173] M.G. O’Neill, H. Yue, S. Nag, P. Grogan, O.L. de Weck, Comparing and Optimizing the
DARPA System F6 Program Value-Centric Design Methodologies, in: Proc. AIAA Sp.
Conf., Anaheim, CA, 2010.
[174] P. Olson, US falling behind in battle for ultimate high ground — space, TheHill.com.
(2012).
238
[175] M. Ortega, A. Thakur, E. Aldana, M. Jacobs, P. Kranenburg, A. Coco, et al., LEAPFROG
Generation-X: Exploring Modularized Martian Robotic Exploration through
Crowdsourcing the Open-Source Community, in: Proc. AIAA Sp. Conf., San Diego, CA,
2013.
[176] J. Osburg, D. Mavris, A Collaborative Design Environment to Support Multidisciplinary
Conceptual Systems Design, SAE Trans. 114 (2005).
[177] J. Pappalardo, How small can satellites get and still be functional? From Nanosats to
Femtosats., AirSpaceMag.com. (2006).
[178] G.G. Parker, L.B. King, H. Schaub, Charge Determination for Specified Shape Coulomb
Force Virtual Structures, in: Proc. AIAA/ASME/AHS/ASC Struct. Struct. Dyn. Mater.
Conf., Newport, Rhode Island, 2006.
[179] D. Parry, NRL Scientists Propose Mitigation Concept of LEO Debris, Nrl.navy.mil.
(2012).
[180] M. Peck, Chips in Space: How Satellites the Size of Chips Could Revolutionize the Way
We Explore Space, IEEE Spectr. (2011).
[181] B. Perry, FOCUS: ESPA: An Inexpensive Ride to Space for Secondary Payloads,
Milsatmagazine.com. (2012).
[182] P. Pichler, B. Weber, S. Zugal, J. Pinggera, J. Mendling, H.A. Reijers, Imperative versus
Declarative Process Modeling Languages: An Empirical Investigation, in: Bus. Process
Manag. Work. BPM 2011 Int. Work. Clermont-Ferrand, Fr. August 29, 2011, Revis. Sel.
Pap. Part I, Springer Berlin Heidelberg, 2011: pp. 383 – 394.
[183] C. Plaunt, A.K. Jonsson, J. Frank, Run-Time Satellite Tele-Communications Call
Handling as Dynamic Constraint Satisfaction, in: Proc. IEEE Aerosp. Conf., Aspen, CO,
1999.
[184] M. Poian, S. Poles, F. Bernasconi, E. Leroux, W. Steffe, M. Zolesi, Multi-objective
Optimization for Antenna Design, in: Proc. IEEE Int. Conf. Microwaves, Commun.
Antennas Electron. Syst., Tel Aviv, Israel, 2008.
[185] J. Puig-suari, C. Turner, W. Ahlgren, Development of the Standard CubeSat Deployer and
a CubeSat Class PicoSatellite, in: Proc. IEEE Aerosp. Conf., Big Sky, MT, 2001.
[186] M. Quadrelli, S. Basinger, G. Swartzlander, Dynamics and Control of a Disordered
System In Space, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[187] N. Ramirez, Valuing Flexibility in Infrastructure Developments: The Bogota Water
Supply Expansion Plan, Massachusetts Institute of Technology, 2002.
239
[188] E. Rechtin, Systems architecting: Creating and building complex systems, Prentice Hall,
Englewood Cliffs, NJ, 1991.
[189] J. Rendleman, R. Ryals, Cyber Operations to Defend Space Systems, in: Proc. AIAA Sp.
Conf., San Diego, CA, 2013.
[190] C.M. Reynerson, Spacecraft Modular Architecture Design For On-Orbit Servicing, Am.
Inst. Aeronaut. Astronaut. (1999).
[191] M.G. Richards, N.B. Shah, D.E. Hastings, Agent Model of On-Orbit Servicing Based on
Orbital Transfers, in: Proc. AIAA Sp. Conf., Long Beach, CA, 2007: pp. 1–12.
[192] E. Riddle, Use of Optimization Methods in Small Satellite Systems Analysis, in: Proc.
AIAA/USU Conf. Small Satell., Logan, Utah, 1998: pp. 1–8.
[193] E. Riddle Taylor, Evaluation of Multidisciplinary Design Optimization Techniques as
Applied to Spacecraft Design, in: Proc. IEEE Aerosp. Conf., Big Sky, MT, 2000.
[194] M. Rivera, A. Boyle, Space for all: Small, cheap satellites may one day do your bidding,
NBCNews.com. (2013).
[195] J. Roach, Japan to go fishing...for space debris, NBCNews.com. (2011).
[196] K. Rooney, An Exercise in Spacecraft Mission Fractionation, (2006) 1–9.
[197] A.M. Ross, D.E. Hastings, J.M. Warmkessel, N.P. Diller, Multi-Attribute Tradespace
Exploration as Front End for Effective Space System Design, J. Spacecr. Rockets. 41
(2004) 20–28.
[198] A.M. Ross, H. McManus, D. Rhodes, D. Hastings, A. Long, Responsive Systems
Comparison Method: Dynamic Insights into Designing a Satellite Radar System, in: Proc.
AIAA Sp. Conf., American Institute of Aeronautics and Astronautics, Pasadena, CA,
2009.
[199] A.M. Ross, D.H. Rhodes, D.E. Hastings, Defining Changeability: Reconciling Flexibility,
Adaptability, Scalability, Modifiability, and Robustness for Maintaining System Lifecycle
Value, Syst. Eng. 11 (2008) 246–262.
[200] P. Van Roy, S. Haridi, Concepts, Techniques, and Models of Computer Programming,
The MIT Press, Cambridge, MA, 2004.
[201] A. Salado, R. Nilchiani, Fractionated Space Systems: Decoupling Conflicting
Requirements and Isolating Requirement Change Propagation, in: Proc. AIAA Sp. Conf.,
San Diego, CA, 2013: pp. 1–15.
240
[202] J.H. Saleh, Flawed metrics: Satellite cost per transponder and cost per day, IEEE Trans.
Aerosp. Electron. Syst. 44 (2008) 147–156.
[203] J.H. Saleh, D.E. Hastings, D.J. Newman, Extracting the essence of flexibility in system
design, in: Proc. NASA/DoD Work. Evolvable Hardw., 2001.
[204] J.H. Saleh, D.E. Hastings, D.J. Newman, Weaving time into system architecture: satellite
cost per operational day and optimal design lifetime, Acta Astronaut. 54 (2004) 413–431.
[205] J.H. Saleh, E.S. Lamassoure, D.E. Hastings, D.J. Newman, Flexibility and the Value of
On-Orbit Servicing: New Customer-Centric Perspective, J. Spacecr. Rockets. 40 (2003)
279–291.
[206] J.H. Saleh, J.-P. Torres-Padilla, D.E. Hastings, D.J. Newman, To Reduce or to Extend a
Spacecraft Design Lifetime?, J. Spacecr. Rockets. 43 (2006).
[207] D. Samuels, The Watchers, WIRED. (2013).
[208] A.D. Santangelo, QuickSAT/step_SATdb: A Satellite Concurrent Design Automation and
Design for Manufacturability cloud based environment for PnP based Satellites, in: Proc.
Infotech@aerosp. Conf., St. Louis, MO, 2011.
[209] A.D. Santangelo, An Open Source Space Hypervisor For Small Satellites, in: Proc. AIAA
Sp. Conf., San Diego, CA, 2013.
[210] V. Schaus, M. Tiede, P. Fischer, D. Ludtke, A. Gerndt, A Continuous Verification Process
in Concurrent Engineering, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[211] B. Schwarz, A.R.L. Tatnall, H.G. Lewis, A Fractionated Satellite Approach to Coastal
Salinity Measurement, in: Proc. Int. Astronaut. Congr., Prague, CZ, 2010.
[212] R. Schwenn, H. Brink, C. Mebane, S. Seales, J. Wintfled, Defense Acquisitions:
Assessment of Selected Weapons Programs, Washington, D.C., 2009.
[213] P.B. de Selding, Intelsat Signs Up for Satellite Refueling Service, SpaceNews.com.
(2011).
[214] K. Shallberg, B.J.P. Potter, P. Class, Geostationary Satellite Reference Station Multipath
Characterization: Using Galaxy 15 Failure to Refine the WAAS Multipath Threat, in:
Proc. Int. Tech. Meet. Satell. Div. Inst. Navig. (ION GNSS), Portland, OR, 2011.
[215] G.B. Shaw, The Generalized Information Network Analysis Methodology for Distributed
Satellite Systems, Massachusetts Institute of Technology, 1998.
241
[216] G.B. Shaw, D. Miller, D.E. Hastings, Development of the Quantitative Generalized
Information Network Analysis (GINA) Methodology for Satellite Systems, in: Proc. IEEE
Aerosp. Conf., Aspen, CO, 1999.
[217] J. Simonds, J.Z. Jacquot, C. Kersten, P. Lew, G. Sullivan, Lessons Learned from Hosting
an Infrared Payload on a Communications Satellite, in: Proc. IEEE Aerosp. Conf., Big
Sky, MT, 2010.
[218] J. Simonds, A. Mitchell, DoD experiments on commercial spacecraft, in: Proc. IEEE
Aerosp. Conf., Ieee, Big Sky, MT, 2009: pp. 1–9.
[219] J. Smith, Concurrent Engineering in the Jet Propulsion Laboratory Project Design Center,
in: Soc. Automot. Eng., Long Beach, CA, 1998.
[220] K. Smith, Advantages of Modularity and Commonality In a Spacecraft Architecture, in:
Proc. ASCE Aerosp. Div. Int. Conf. Eng. Constr. Oper. Challenging Environ. Earth Sp.,
Reston, VA, 2006.
[221] S.C. Spangelo, J. Cutler, Optimizing the Communication Capacity of Space Networks,
Ann Arbor, Michigan, 2012.
[222] S.C. Spangelo, D. Kaslow, C. Delp, B. Cole, L. Anderson, E. Fosse, et al., Applying
Model Based Systems Engineering (MBSE) to a standard CubeSat, in: Proc. IEEE
Aerosp. Conf., Ieee, Albuquerque, NM, 2012: pp. 1–20.
[223] D. Spinellis, The Importance of Being Declarative, IEEE Softw. 30 (2013) 90–91.
[224] J.C. Springmann, J.W. Cutler, Optimization of Directional Sensor Orientation With
Application to Photodiodes for Spacecraft Attitude Determination, in: Proc. AAS/AIAA
Spacefl. Mech. Meet., Kauai, Hawaii, 2013: pp. 1–19.
[225] H. Stoewer, R. Hartmann, B. von Richter, An Advanced Methodology for the Design
Process of a Satellite, in: Proc. INCOSE Int. Symp., Minneapolis, MN, 2000.
[226] B.R. Sullivan, Technical and Economic Feasibility of Telerobotic On-Orbit Satellite
Servicing, University of Maryland, 2005.
[227] B.R. Sullivan, D.L. Akin, A Survey of Serviceable Spacecraft Failures, in: Proc. AIAA
Sp. Conf., Albuquerque, NM, 2001: pp. 1–8.
[228] B.R. Sullivan, D.L. Akin, Satellite Servicing Opportunities In Geosynchronous Orbit, in:
Proc. AIAA Sp. Conf., Pasadena, CA, 2012: pp. 1–12.
[229] B.R. Sullivan, D. Barnhart, L. Hill, P. Oppenheimer, B. Benedict, G. van Ommering, et
al., DARPA Phoenix Payload Orbital Delivery (POD) System: “FedEx to GEO,” in: Proc.
AIAA Sp. Conf., San Diego, CA, 2013.
242
[230] P.P. Sundaramoorthy, E. Gill, C.J.M. Verhoeven, Systematic Identification of
Applications for a Cluster of Femto-Satellites, in: Proc. Int. Astronaut. Congr., Prague,
CZ, 2010: pp. 1–5.
[231] D. Szondy, RINGS Propels Satellites Without Propellants, Gizmag.com. (2013).
[232] G. Tack, Constraint Propagation - Models, Techniques, Implementation, Saarland
University, Germany, 2009.
[233] H. Takeuchi, M. Sugimoto, H. Nakamura, T. Yutani, M. Ida, S. Jitsukawa, et al., Staged
Deployment of the International Fusion Materials Irradiation Facility (IFMIF), in: Proc.
Int. At. Energy Agency Fusion Energy Conf., 2000.
[234] S. Tamaskar, D. Delaurentis, Modular Spacecraft Architecture, A New Paradigm in
Spacecraft Design, in: Proc. Int. Astronaut. Congr., Prague, CZ, 2010.
[235] S. Tamaskar, K. Neema, D. Delaurentis, Complexity Analysis of Spacecraft Architectures,
in: Proc. AIAA Sp. Conf., Long Beach, CA, 2011: pp. 1–9.
[236] A. Thornton, The use of constraint-based design knowledge to improve the search for
feasible designs, Eng. Appl. Artif. Intell. 9 (1996).
[237] D. Thurston, Multiattribute Utility Analysis in Design Management, IEEE Trans. Eng.
Manag. 37 (1990) 296–301.
[238] J. Tirpak, Breaking the Space Status Quo, Air Force Mag. (2013) 5.
[239] M. Tranchero, HW-SW design flow of a nano-satellite using UML and CodeSimulink co-
design environment, in: Proc. IEEE Mediterr. Electrotech. Conf., Ieee, Malaga, Spain,
2006: pp. 85–88.
[240] E. Triantaphyllou, S.H. Mann, Using the Analytic Hierarchy Process for Decision Making
in Engineering Applications: Some Challenges, Int. J. Ind. Eng. Appl. Pract. 2 (1995) 35–
44.
[241] L. Trigeorgis, Real Options: Managerial Flexibility and Strategy in Resource Allocation,
1st ed., MIT Press, Cambridge, MA, 1996.
[242] J. Tristancho, Implementation of a femto-satellite and a mini-launcher, Universitat
Politecnica de Catalunya, 2010.
[243] J. Tristancho, Moon2.0 an open source toolkit for real space missions: The Space Payload
Paradigm definition, (2012).
[244] J. Tristancho, J. Gutierrez-Cabello, A probe of concept for femto-satellites based on
commercial-of-the-shelf, in: Proc. Digit. Avion. Syst. Conf., Seattle, WA, 2011.
243
[245] J.P. Tsang, G. Cardonne, An AI approach to automate the preliminary design phase of
electronic equipment for satellites, Futur. Gener. Comput. Syst. 7 (n.d.) 353–364.
[246] S. Ullmann, M. Wilke, Advanced Simulation System Design Process for LunarSat, in:
Proc. Int. Conf. Explor. Util. Moon, Noordwijk, The Netherlands, 2000.
[247] C. Underwood, S. Pellegrino, V. Lappas, C. Bridges, B. Taylor, S. Chhaniyara, et al.,
Autonomous Assembly of a Reconfigurable Space Telescope (AAReST) - A
Cubesat/Microsatellite Based Technology Demonstrator, in: Proc. AIAA/USU Conf.
Small Satell., Logan, Utah, 2013.
[248] N. Ungerleider, NASA’s Space Gliders and the DIY Satellite Revolution,
FastCompany.com. (2013).
[249] M. Wall, Want to Get Rid of Space Junk? Catch It in a Giant Net, SPACE.com. (2011).
[250] D. Waltz, On-Orbit Servicing of Space Systems, Krieger, Malabar, FL, 1993.
[251] D. Ward, Faster, Better, Cheaper Revisited: Program Management Lessons from NASA,
Def. AT&L. (2010) 48–52.
[252] O.L. de Weck, J. Agte, J. Sobieszczanski-Sobieski, P. Arendsen, A. Morris, M. Spieck,
State-of-the-Art and Future Trends in Multidisciplinary Design Optimization, in: Proc.
AIAA/ASME/AHS/ASC Struct. Struct. Dyn. Mater. Conf., Honolulu, HI, 2007.
[253] O.L. de Weck, D. (Datong) Chang, Architecture Trade Methodology for LEO Personal
Communication Systems, in: Proc. Int. Commun. Satell. Syst. Conf., Montreal, Canada,
2002.
[254] O.L. de Weck, R. de Neufville, M. Chaize, Enhancing the Economics of Communications
Satellites via Orbital Reconfigurations and Staged Deployment, (2003).
[255] O.L. de Weck, R. de Neufville, M. Chaize, Staged Deployment of Communications
Satellite Constellations in Low Earth Orbit, J. Aerosp. Comput. Information, Commun. 1
(2004) 119–136.
[256] P.M. Wegner, R.R. Kiziah, Pulling the Pieces Together at AFRL, in: Proc. AIAA
Responsive Sp. Conf., Los Angeles, CA, 2006.
[257] J. Weise, K. Brieb, A. Adomeit, H.-G. Reimerdes, M. Goeller, R. Dillmann, An Intelligent
Building Blocks Concept for On-Orbit Satellite Servicing, in: Proc. Int. Symp. Artif.
Intell. Robot. Autom. Sp., Turin, Italy, 2012.
[258] H. Wen-bo, Z. Wei-hua, C. Ye-quan, S. Shuai, Systems Analysis on Spacecraft Design,
in: Proc. Int. Conf. Syst. Sci. Eng. Des. Manuf. Informatiz., Ieee, Guiyang, China, 2012:
pp. 197–200.
244
[259] D. Werner, Planet Labs Unveils Plan To Launch 28 Nanosats on Antares’ 1st Cargo Run,
SpaceNews.com. (2013).
[260] D. Werner, Rocket Builders Scramble to Capture Growing Microsat Market, Sp. News.
(2013).
[261] J.R. Wertz, Dramatically Reducing Space Mission Cost, (2009) 1–5.
[262] J.R. Wertz, D.F. Everett, J.J. Puschell, Space Mission Engineering: The New SMAD,
Microcosm Press, Hawthorne, CA, 2011.
[263] J.R. Wertz, W.J. Larson, eds., Reducing Space Mission Cost, Springer, 1996.
[264] B.J. Wielinga, A.T. Schreiber, J. a. Breuker, KADS: a modelling approach to knowledge
engineering, Knowl. Acquis. 4 (1992) 5–53.
[265] T.M. Wong, R.A. Golding, H.M. Ruback, W. Plouffe, S.A. Brandt, The Virtual Mission
Bus, San Jose, CA, 2010.
[266] B.C. Wood, An Analysis Method for Conceptual Design of Complexity and Autonomy in
Complex Space System Architectures, Massachusetts Institute of Technology, 2001.
[267] W. Xiuhong, Innovation Method of Space Weapons Systems Based on quality Chain, J.
Converg. Inf. Technol. 8 (2013) 512–521.
[268] M. Xu, J. Wang, A. Zhang, S. Liu, Probabilistic Value-Centric Optimization Design for
Fractionated Spacecrafts Based on Unscented Transformation, Math. Probl. Eng. 2013
(2013) 1–10.
[269] I. Yachbes, Roopnarine, S. Sadick, B. Arritt, H.E. Gardenier, Rapid Assembly of
Spacecraft Structures for Responsive Space, in: Proc. IEEE Aerosp. Conf., Ieee, Big Sky,
MT, 2009: pp. 1–10.
[270] W. Yao, X. Chen, Y. Zhao, M. van TOOREN, A Fractionated Spacecraft System
Assessment Tool Based on Lifecycle Simulation Under Uncertainty, Chinese J. Aeronaut.
25 (2012) 71–82.
[271] Z.B. Zabinsky, W. Wang, Y. Prasetio, A. Ghate, J.W. Yen, Adaptive Probabilistic branch
and Bound for Level Set Approximation, in: Proc. Winter Simul. Conf., Phoenix, AZ,
2011: pp. 4146–4157.
[272] Z. Ze, Space Debris and Present Active Debris Removal Techniques, in: Proc. Beijing Sp.
Sustain. Conf., Beijing, China, 2011.
245
[273] Y. Zhao, X. Chen, Z. Wang, SIDE: A Tool for Integrated Multidisciplinary Design
Optimization of Spacecraft, in: Proc. AIAA/ISSMO Multidiscip. Anal. Optim. Conf.,
Portsmouth, VA, 2006: pp. 1–10.
[274] J. Ziemer, J. Ervin, J. Lang, Exploring Mission Concepts with the JPL Innovation Foundry
A-Team, in: Proc. AIAA Sp. Conf., San Diego, CA, 2013.
[275] G.P. Zoppo, G.L. Sembenini, C. Paccagnini, A. Martelli, CODE: A Concurrent Approach
to Virtual Spacecraft, in: Proc. Int. Astronaut. Congr., Vancouver, Canada, 2004.
[276] ESPA: The EELV Secondary Payload Adapter, Moog.com. (n.d.).
[277] Airborne Launch Assist Space Access (ALASA), Darpa.mil. (n.d.).
[278] SWORDS Soldier-Warfighter Operationally Responsive Deployer for Space Fact Sheet,
Huntsville, AL, n.d.
[279] Scorpius Space Launch Company - Products, Scorpius Sp. Launch Co. (n.d.).
[280] CubeSat Selections - February 2011 Selection, NASA.gov. (n.d.).
[281] Model Based Systems Engineering - Space Systems Modelling, INCOSE Model Based
Syst. Eng. Chall. (n.d.).
[282] Engineering and Managing Knowledge - CommonKADS, (n.d.).
[283] Space Engineering Research Center, (n.d.).
[284] Space Assembly, Maintenance and Servicing Study (SAMS): Final Report, 1988.
[285] Quality Function Deployment, (1994).
[286] NASA reexamines faster, better, cheaper strategy, Issues Sci. Technol. 16 (2000).
[287] Report of the Commission to Assess United States National Security Space Management
and Organization, 2001.
[288] Space Transportation Costs: Trends in Price Per Pound to Orbit 1990-2000, Futron
Corporation, Bethesda, MD, 2002.
[289] DARPA cancels RASCAL program, Spacetoday.net. (2005).
[290] Class rushes to build a flying prototype in a single semester, USC Viterbi Sch. Eng.
(2006).
246
[291] DARPA Broad Agency Announcement, Tactical Technology Office: System F6.
DARPA-BAA- 07-31, (2007).
[292] SYSTEMA, Astrium SAS. (2007).
[293] DARPA Broad Agency Announcement, Tactical Technology Office: System F6.
DARPA-BAA-11-01, (2010).
[294] QFD and House of Quality Templates, QFDonline.com. (2010).
[295] DARPA Broad Agency Announcement, Tactical Technology Office: Phoenix. DARPA-
BAA-12-02, (2011).
[296] NASA TECHNICAL STANDARD, Process for Limiting Orbital Debris, Washington,
D.C., 2011.
[297] 7 Satellite Firms Form Hosted Payload Alliance, SpaceNews.com. (2011).
[298] Declarative Modelling, Simulistics Ltd. (2011).
[299] Adaptable Systems Design and Analysis, Pasadena, CA, 2011.
[300] DARPA Broad Agency Announcement, Tactical Technology Office: Component,
Context, and Manufacturing Model Library 1 (C2M2L-1). DARPA-BAA-11-47, 1 (2011)
1–44.
[301] Optimal Configurations and Practices for the Design of Adaptable Space Systems and the
Implementation of Shared Space Services, 2011.
[302] PocketQub, Pocketqub.org/. (2012).
[303] Spaceflight Signs Agreement with SpaceX to Manifest Secondary Payloads on Upcoming
Falcon Launches, Spaceflightservices.com. (2012).
[304] Spaceflight Completes Secondary Payload System Preliminary Design Review with
Hardware Fabrication Underway, Spaceflightservices.com. (2012).
[305] Georgia Tech Model-Based Systems Engineering Center, MBSEC. (2012).
[306] ESA Concurrent Design Facility, Www.esa.int. (2012).
[307] Cost Estimation Toolkit (CET) Software Package, Gsfc.nasa.gov. (2012).
[308] PhoneSat Flight Demonstrations, NASA.gov. (2013).
[309] Minotaur IV Space Launch Vehicle Fact Sheet, (2013).
247
[310] Pegasus Patented Air Launch System Fact Sheet, Orbital.com. (2013).
[311] Antares Medium-Class Space Launch Vehicle Fact Sheet, (2013).
[312] Global Horizons - Final Report, 2013.
[313] LEGO, LEGO.com. (2013).
[314] Definition of optimization, Merriam-Webster.com. (2013).
[315] Goddard Space Flight Center Integrated Design Center Mission Design Lab, NASA.gov.
(2013).
[316] System Architecture Lab, MIT Syst. Archit. Lab. (2013).
[317] Small Satellite Cost Model, Www.aerospace.org. (2013).
[318] Princeton Satellite Systems, Www.psatellite.com. (2013).
[319] Python Programming Language – Official Website, Python Softw. Found. (2013).
[320] PHX ModelCenter Desktop Trade Studies, Www.phoenix-Int.com. (2014).
248
Appendix A
SPIDR-Sat v.0
A procedural systems engineering environment for use in automating the satellite design and
optimization process was developed at the USC/ISI Space Engineering Research Center (SERC),
which is ran in conjunction with USC’s Department of Astronautical Engineering. The SERC is
dedicated to space engineering, space research, and the build, test and flight demonstration of
spacecraft and satellites [283].
In section A.1, clarification on SPIDR terminology is provided. Section A.2 describes the initial
creation of what is termed SPIDR-Sat v.0: a procedural, web-based design portal developed in
parallel with and supported by the tradespace of the Alcyone small satellite program.
A.1 Terminology
The genesis of this research was the development of a web-based portal for real-time, system-
level, component-based satellite design. The goal of the initial pilot environment was to employ
industry-standard spacecraft design knowledge in the conventional, procedural approach (with
“hooks” embedded to enable users to readily substitute default models with private, homegrown
249
or higher fidelity models), and couple it with a comprehensive and up-to-date database of
existing space hardware. This web environment was termed the Spacecraft Portal for Integrated
Design in Real-time. As the research evolved, it became apparent that the domain knowledge
could potentially be adapted from the original computational foundation to a much more
powerful AI- and interval arithmetic-based search and design engine. This reasoning engine had
been developed at ISI and innovatively applied to the design of mission plans for astronauts
[114]. While the name SPIDR remained, the acronym was generalized to refer to the System
Platform for Integrated Design in Real-time, thus referring to the new AI environment. Thus, as
it stands now, the acronym SPIDR refers to the search and optimization engine that can
accommodate the application domain-specific design knowledge, whether it be for spacecraft
design, fractionated constellations in space, undersea energy harvesting vehicles or other
engineering artifacts [113]. However, it is important to note for clarity that earlier versions of the
satellite design environment generated in this research that do not employ the SPIDR engine also
utilize this naming convention.
Henceforth, this study will use the following terms to describe the associated evolutions of the
SPIDR tool: “SPIDR v.1” refers to the initial web-based portal for design, which employed a
conventional, procedural approach to the design of small satellites; “SPIDR-Sat” refers to the
satellite design environment based on a declarative modeling approach, which addressed the
domains of small satellites and CubeSats; “F-SPIDR” refers to the extension of the SPIDR-Sat
environment to the domain of fractionated constellations for the DARPA System F6 program
(within the broader SatTrade environment); and “SPIDR-Lite” refers to the GUI-based
environment to enable rapid modeling of design problems from a blank slate and academic
applications.
250
A.2 Web Portal for Satellite Design
The pilot approach taken in this research was that of a web-based portal for component-level
satellite design coupled with a database of existing space hardware components and associated
technical specifications, parameters and cost values. Top level goals of the web portal included
the ability to size subsystems and identify suitable existing hardware, interchange subsystem
models with user-supplied models, allow the user to override any of the program’s selected
hardware choices, and to display both nominal (first choice hardware selections determined by
closest match to calculated performance) and off-nominal design choices (next-best hardware
selections), as well as the “delta” in performance, i.e. the difference in mission performance and
cost between nominal and off-nominal designs. The tool was also intended to support the design
of the 100kg-class Alcyone small satellite [22], which was occurring simultaneously at
USC/ISI’s SERC.
To begin the research process, a Microsoft Excel spreadsheet-based environment was created to
seed the development of the web portal by identifying key parameters of the satellite, mission
and orbit, as well as high level equations for each subsystem and resulting relationships between
subsystems and components. Two example sections from the exploratory workbook are shown in
Figure 46 and Figure 47, which depict the requirements input section and the power subsystem
section, respectively.
251
Figure 46. Requirements page of the spacecraft design workbook created to seed SPIDR-Sat
252
Figure 47. Power system page of the spacecraft design workbook created to seed SPIDR-Sat
Models for the SPIDR-Sat v.0 environment were then created using the Python programming
language [319]. These included satellite subsystem design files, a catalog of space components
developed through exhaustive internet and database searches as well as frequent contact with
manufacturers for higher fidelity technical specifications and cost figures, and a framework to
host and display the user interface, database, and designs results on the web in HTML.
A web-based graphical user interface (GUI) was developed that provided input fields for top-
level mission specifications supplied by the user (Figure 48), output summaries of the nominal
and off-nominal hardware selections (Figure 49), and interactive displays of the hardware
catalog that allowed user-override of SPIDR-enacted component selections (Figure 50).
253
Figure 48. User input fields of the SPIDR-Sat v.0 spacecraft design portal
254
Figure 49. Sample design results from SPIDR-Sat v.0
255
Figure 50. Excerpt of the interactive component database in SPIDR-Sat v.0
The subsystem design knowledge was expressed in a procedural manner, meaning it identified
the explicit procedure with which the equations would be executed and the hardware selected.
The models were based on industry-standard satellite design algorithms and equations taken
from Larson and Wertz’s Space Mission Analysis and Design textbook [131], undergraduate and
graduate coursework from USC’s Astronautical Engineering Department, and other satellite
subsystem texts and materials. The design was executed according to a unidirectional, waterfall
methodology, according to the following ordered sequence:
1. model1 (ADCS)
2. model2 (Power)
256
3. model3 (Comm)
4. model4 (Thermal)
5. model5 (Propulsion)
Procedural approaches to satellite design must generally either be iterated upon numerous times
in order to achieve design convergence, or must follow some schema that determines the flow of
the design, with estimates and margins incorporated to support convergence. As the first option
is slower in execution and necessitates extra programming logic to enable iteration (or manual
iteration), the second option was selected for this study. However, the schema that must be
enacted in this approach is problematic in that effectively prioritizes the design of certain
subsystems above others, as the sizing of any “downstream” component or subsystem is
essentially dependent upon the results of the preceding ones. Such methods often rely heavily on
cost- and size-estimating relationships, partitioning optimization at the subsystem level, and
other techniques.
While this methodology embeds an unwanted weighting into various aspects of the designed
system, design solutions generated from the alternative are not ideal either, as the snowball effect
that can occur in certain sizing operations as iterations are performed can likely result in
suboptimal designs. An innovative solution is to apply interval arithmetic to the problem of
satellite design. In this approach, all variables in the system are initially instantiated as intervals
where the lower and upper bounds represent the absolute minimum and maximum feasible
values for that parameter. The union of the interval domains of all variables in the system
comprises the complete tradespace, which contains every feasible configuration (or the complete
set of solutions) given the starting bounds of the design variables considered. Applying rules and
257
constraints that enforce the applicable mathematic relationships between system parameters then
shrinks the intervals until a single point solution is discovered.
258
Appendix B
F-SPIDR
B.1 Model Parameters and Relationships
153 separate variables were defined in the shared space imager problem modeled by F-SPIDR.
They either have explicit values (such as component parameters), or their values are calculated
by logical and mathematical relationships. These are described in the following sections, and are
grouped according to the rule or token in which they are modeled. (For a diagram of the
relationships between 43 key parameters, see Figure 37).
B.1.1 Constellation Token
Delay, or the approximate worst-case time to have spacecraft overhead a desired location, where
delayFactor is equal to 32 at 569km, 18 at 896km, and 16 at 1264km:
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
−
=
r delayFacto
caps
delay
1 * 38 . 1
10 (B-1)
259
This variable approximates the exact maximum delay for the three constellation altitudes as a
function of the population of imagers described in the previous section.
If the number of clusters (aka capabilities or “caps”) is not directly divisible by the number of
rings, some number of rings will have x clusters, while the rest have x-1 clusters. The higher
number of clusters on a ring (x) is equal to:
maxCaps = ceil(caps/rings) (B-2)
and the lower number of clusters (aka capabilities or “caps”) on a ring is equal to:
minCaps = floor(caps/rings) (B-3)
The number of rings that contain the higher number of clusters is:
ringsWithMax = caps – minCaps * rings (B-4)
and the number of rings that contain the lower number of clusters is:
ringsWithMin = rings - ringsWithMax
(B-5)
The Boolean flag enableCoverage can be set to {1} to enforce the attachment of sufficient
capabilities to enable gapless coverage. If the flag is set to {1}, the number of capabilities is set
to be greater than or equal to coverageCaps, where:
coverageCaps = 2 * rings (B-6)
260
B.1.2 Orbit Calculation Arule
Orbital radius (km):
r = alt + r
e
(B-7)
Distance to horizon (km):
2 2
e
r r h − = (B-8)
Rings in constellation (which can be hard coded to equal 8, 6, and 9 at 569, 896, and 1264km,
respectively, as an embedded INT function was unavailable in the SPIDR computational engine):
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
+ = 5 . 0
2a
r
INT rings
e
π (B-9)
Orbital period (sec):
µ
π
3
2
r
T = (B-10)
Passes per day:
T
N
3600 * 24
= (B-11)
Circular orbital velocity (km/s):
r
V
µ
= (B-12)
261
Eclipse time (sec) and density (kg/m
3
) are calculated as interpolation between tabulated SMAD
values by altitude and solar activity level (mean solar activity is assumed).
B.1.3 Cluster-Module Arules
Ballistic coefficient (kg/m
2
), where M
wet
is the module wet mass, C
d
= 2.2, and area A = 1m
2
for
C1; 0.75m
2
for all modules in C2 - C4; and 0.5m
2
for all modules in C5:
A C
M
B
d
wet
= (B-13)
ΔV due to drift (m/s/year), where r is expressed in m, v in m/s, and T and life are in years:
life
T
rv
B
V
drift
* ⎟
⎠
⎞
⎜
⎝
⎛
= Δ
ρ π
(B-14)
ΔV due to stationkeeping (m/s/year), where r
s
is the intermodule distance expressed in km, life is
in years, and penalty = 10 if relative ranging is used and 1 if CDGPS navigation is used:
life
r
penalty V
s
ping stationkee
*
1
12 *
2
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
= Δ (B-15)
ΔV for egress (m/s), where the perigee of the deorbit ellipse, H
e
, is equal to 50km:
( )
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
+ +
+
− = Δ
alt H r
H r
V V
e e
e e
egress
2
2
1 * 1000 (B-16)
262
Total ΔV, where ΔV for ingress = 2 m/s, and ΔV for cluster scatter-gather = N * 66m/s, where
n
sg
is the desired number of scatter maneuvers. 10% of total ΔV is added on for reserve:
( ) ( )
ping stationkee drift sg egress ingress total
V V n V V V Δ + Δ + + Δ + Δ = Δ 66 * 1 . 1 (B-17)
Propulsion system mass (kg), where massFactor is 0.05 for cold gas, 0.10 for monoprop, and
0.25 for biprop:
( )
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
−
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
Δ
+ = 1
* 81 . 9
exp * 1
sp
propulsion
I
V
mass massFactor M (B-18)
B.1.4 Parameter Totals Srule
Battery capacity required (Ahr), where P
comp
is the total required operating power for
components (W), eclipse time T
eclipse
is in hours, DOD is max allowable battery Depth of
Discharge in %, transmission efficiency H is 0.9, and bus voltage V
bus
is 28V:
bus
eclipse comp
V H
DOD
T P
Capacity
* *
100
*
⎟
⎠
⎞
⎜
⎝
⎛
= (B-19)
Energy that needs to be returned to the battery during daylight (W.s), where the recharge ratio is
1.1 and the battery discharge efficiency n
dc
is 0.9:
263
dc
eclipse comp
ret
n
eRatio rech T P
E
arg * *
= (B-20)
Solar array power required to recharge the battery (W), where the battery charge controller
efficiency is 0.9:
cc daylight
ret
chg
n T
E
P
*
= (B-21)
Solar array power required during daylight (W), where path efficiency in eclipse, X
e
, is 0.65, and
in daylight, X
d
, is 0.85:
daylight
d
daylight comp
e
eclipse chg
sa
T
X
T P
X
T P
P
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
+
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
* *
(B-22)
Wet mass (kg) of a module, where the subtotal of dry mass, M
subdry
, is equal to the sum of the
components, and it is multiplied by a mass factor of 1.25 for C1; 1.05 and 1 for C2a and C2b;
1.15, 1.05 and 1 for C3a, C3b, and C3c; 1 and 1.05 for C4a and C4b; and 1 for C5:
M
wet
= ( M
subdry
* massFact ) + M
propulsion
(B-23)
Total mass (kg) of a cluster is the summation of wet masses for all modules in a cluster:
m wet
n
m
cluster
M M
,
1 =
Σ = (B-24)
Manufacturing and Integration cost ($M):
264
Cost
MI
= 0.2 * M
dry
(B-25)
Production cost learning curve exponent B, where the learning curve slope (%) S is 95% for 1-9
capabilities, 90% for 10-50 capabilities, and 85% for more than 50 (from SMAD p. 809 [131]):
( )
2 ln
/ % 100 ln
1
S
B − = (B-26)
Production cost including learning curve, where the cost of the theoretical first unit, TFU, is
equal to the Manufacturing and Integration cost, Cost
MI
:
B
od
caps TFU Cost *
Pr
= (B-27)
Constellation cost ($M) where Design cost Cost
D
and Research and Development cost (for power
beaming) Cost
RD
are equal to, respectively, 25 and 0 for C1; 50 and 50 for C2 and C4; 50 and 0
for C3; and 75 and 50 for C5:
Cost
Constellation
= Cost
D
+ Cost
RD
+ (Cost
MI
* Caps) (B-28)
Total capability cost ($M) where Cost
Launches
is the total cost of all launches:
Cost
Cap
= Cost
Constellation
+ Cost
Launches
(B-29)
Inter-module bandwidth (Mbps), where the peakRange (km) and peakBandwidth (Mbps) are
sqrt(50) and 0.2, sqrt(10) and 1, and sqrt(2) and 5 for SB-SAT, Iridium, and Iridium-high
crosslinks, respectively:
265
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
2
* , min
s
R
peakRange
dth peakBandwi dth peakBandwi bandwidth (B-30)
Compressed image size (Mb) where, if the F6 Tech package processor does not provide image
compression, comp is the compression factor of the processor for configurations 1, 2 and 3 and
comp = 1 for configurations 4 and 5. If the F6 Tech Package processor does provide image
compression, comp is equal to the F6TP compression factor:
comp
size
size
image
comp
= (B-31)
Transmit time (sec) where size
comp
is in bits and bandwidth is in bps:
bandwidth
size
Time
comp
tx
=
(B-32)
Images transmitted per full day across entire constellation:
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
−
tx
day full
Time
caps images
3600 * 24
(B-33)
Images transmitted per daylight portion of day across entire constellation:
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
tx
daylight
daylight
Time
Time N
caps images
*
(B-34)
Total images transmitted during daylight during constellation lifetime:
25 . 365 * *life images images
daylight total
= (B-35)
266
Dollars per image transmitted:
$perImage = Cost
cap
/ images (B-36)
Camera resolution at constellation altitude, where baseRes is the resolution at the base altitude
for the selected camera and resFactor is equal to 1 for 569km, 1.5 for 896km and 2 for 1264km:
Resolution = resFactor * baseRes (B-37)
B.1.5 Launch Arule
The cost of all launches, where qty is the number of launches required to put all clusters in orbit
using the selected launch vehicle:
LV launches
Cost qty Cost * = (B-38)
The number of launches required varies based on how the modules are distributed between the
launch vehicles and how many must go to each ring. Three options are presented as follows:
1. Option 1: Launch whole cluster(s) at a time (C1 – C5)
267
Launch vehicle must be able to lift at least 1 cluster:
PSW >= M
cluster
(B-39)
Clusters per launch vehicle (CPL), where PSW is the payload systems weight, or max launchable
mass, of the selected launch vehicle (kg):
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
cluster
M
PSW
floor CPL (B-40)
Number of launches needed, recalling maxCaps is the higher number of clusters on a ring, and
ringsWithMax is the number of rings with the maximum, and the converse for minCaps and
ringsWithMin:
⎟
⎠
⎞
⎜
⎝
⎛
+ ⎟
⎠
⎞
⎜
⎝
⎛
=
CPL
Caps
ceil in ringsWithM
CPL
Caps
ceil ax ringsWithM qty
min
*
max
*
(B-41)
2. Option 2: Launch only 1 type of module at a time (C2 – C5)
Launch vehicle must be able to lift the heaviest module:
PSW >= max(M
module1
, max(M
module2
, M
module3
)) (B-42)
Modules per launch vehicle, where M
module1
, M
module2
, and M
module3
are the wet masses of modules
1, 2 and 3 respectively:
268
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
3 , 2 , 1 mod
3 , 2 , 1
ule
M
PSW
floor CPL (B-43)
Number of launches needed for each type of module:
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
+
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
3 , 2 , 1 3 , 2 , 1
3 , 2 , 1
min
*
max
*
CPL
Caps
ceil in ringsWithM
CPL
Caps
ceil ax ringsWithM qty (B-44)
3. Option 3: Launch a group of 2 modules and a launch of 1 module (C5)
Launch vehicle must be able to lift the heaviest module or group of modules:
PSW >= max(M
module
, M
group
) (B-45)
Groups of modules per launch vehicle, where CPL
1
is a grouping of either Modules 1 and 2, 1
and 3, or 2 and 3, and CPL
2
is the remaining module in each combination. M
group
is the mass of
Modules 1 and 2, 1 and 3, or 2 and 3, and M
module
is the mass of the remaining module.
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
ule group
M
PSW
floor CPL
mod ,
2 , 1
(B-46)
Number of launches needed for each group/module:
269
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
+
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
=
2 , 1 2 , 1
2 , 1
min
*
max
*
CPL
Caps
ceil in ringsWithM
CPL
Caps
ceil ax ringsWithM qty (B-47)
B.1.6 Time to Operability Srule
Design time for a cluster (months) based on number of modules moduleCount:
t
design
= 18 + 6*moduleCount (B-48)
Integration time for a cluster (months):
t
int
= 12 + 6*moduleCount (B-49)
Test time for a cluster (months):
t
test
= 12 + 3*moduleCount (B-50)
Launch vehicle integration time for a cluster (months):
t
lvi
= 2*moduleCount (B-51)
Overlap time, headStart, which is the amount of time a cluster n+1’s development can start
before cluster n finishes development. Cluster n+1 is assumed to be able to begin integration
270
when cluster n-1 begins testing. (Only the first cluster has design time. All subsequent clusters
begin with integration time.)
headstart = t
test
+ t
lvi
(B-52)
The amount of time to full cluster operability, timeToOp, then can be calculated as:
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
+ + + =
int
,
12
max * t
manifest
caps t t t timeToOp
lvi test design
(B-53)
271
Appendix C
SPIDR-Lite
The use of a lightweight, editor-based declarative design approach for rapid model generation
and academic use is described here.
C.1 Overview
As the development of SPIDR-Sat progressed, both in spacecraft design and in other domains
(e.g. undersea energy harvesting vehicles [116]), the power of its innovative search and
optimization engine is clear. A major drawback, however, is also evident: The modeling
language, although concise and lightweight, is not immediately intuitive to the average
aerospace/satellite system (or other engineering domain) engineer. A declarative environment
can produce very elegant code but it is a dramatic departure from the language with which most
engineers are accustomed. Clearly, if a design problem cannot be adequately or easily modeled
by an engineer, the modeling environment is useless.
272
For this reason, the developers of the SPIDR engine worked to provide an environment with a
user interface for the actual construction of a design problem like in SPIDR-Sat. This would
allow an engineer to more easily compose a design a problem if the task of manually encoding it
in SPIDR's Tnet language is not feasible [114]. Another potential application is in academia. If
users are receptive to the UI style problem specification, it could be used to help teach students
and engineers about the spacecraft design process and could provide quick insight into high-level
tradeoffs within a design space. The tool was proposed to a Capstone spacecraft design course at
USC but has yet to be implemented.
The tool, termed “SPIDR-Lite”, relies on the exact same functionality of SPIDR-Sat “under-the-
hood” but with a highly simplified approach to problem set-up. The following section describes
the creation of a high-level satellite design example problem that can aid designers in modelling
space systems with the SPIDR-Lite editor.
C.2 Example Satellite Design Optimization Problem
In the first step, a system token named “satellite” is created in the Token types tab by right
clicking on the system token type and selecting “Add child” (Figure 51). The satellite will
consist of six subsystems, which are composite entities themselves. Six subsystem tokens are
created and named for each subsystem: “ADCS”, “CDH”, “Comm”, “EPS”, “Structures”, and
“TCS”. Each of these seven entities (subsystems plus system) appear in the system Token types
folder (Figure 52).
273
Figure 51. Graphical problem specification in the SPIDR-Lite tool
Figure 52. Creation of system and subsystem token types in SPIDR-Lite
274
If applicable, child tokens can be created that extend from any token and inherit their parent’s
properties (one can think of the parent token as serving as a template for sets of similar
problems). For example, a satellite token template may be created that contains variable types
mass and power. Tokens for types of satellites, e.g. “cubeSat” or “smallSat”, can then be created
as child tokens extending from the “satellite” token. Definitions for cubeSat and smallsat tokens
would then also inherit variable types mass and power.
At this point, the user might define components that belong to the composite problem.
Component tokens would be created for components that are available to fulfill system tasks,
either partially or entirely. For example, the token “solarArray” may be created such that it can
fulfill part of the Electrical Power System task (power generation), while a token “CDHunit”
may be created that can fulfill the entire Command & Data Handling task. (In an extreme, a
“cubesatKit” component token may be created that fulfills the entire satellite token).
Then, variables must be assigned to components and/or systems. Variables can be numeric, such
as mass, power, cost or reliability; or discrete, such as color (silver, black, blue…) or flight-
qualified (yes/no). Here the variables mass, cost and reliability have been added to the
component parent token, and are carried down to each of the child components (Figure 53).
Additional, subsystem-specific variables are added to individual components, e.g. power,
capacity for a battery, area for a solar panel, etc.
275
Figure 53. Variables are added to components, systems and subsystem tokens
Variables may represent inherent properties of a component (for example, the mass of a sun
sensor), or values that will are calculated elsewhere (the area of the solar array will be calculated
in the solar array rule using the efficiency and areal density of the selected solar cells and the
total power requirement of the satellite). Variables can also be defined and read from a .csv file.
A variable can also have a discrete value domain, which is done by creating a “Set” in the
Variable types tab (Figure 54).
276
Figure 54. Creation of discrete variables in SPIDR-Lite
Numeric values can also be defined as variable types. For example, mass can be defined as a
variable type. Then, any component or system variable can be tagged with this “type”, allowing
it be considered by some operation specified for mass. For example, the total satellite mass can
be calculated by SPIDR-Lite by declaring that the Sum operation occurs to all variables tagged
with the type mass.
Mathematical constraints can then be established between any variables in the problem space.
For “local” relationships, or constraints that only involve variables from within the same token,
math constraints can be defined in that token’s definition space (Figure 55).
277
Figure 55. Creation of a mathematical constraint in a SPIDR-Lite token
Now, rules must be created that capture the engineering decisions and options for designing the
satellite (Figure 56). First, the rule “subsystems” is created that defines an action to be taken if
the target design token, satellite, is present (which can be enacted by the user based on the
creation of this token back in the first step). Under “If have” (in the top portion of the screen),
the token that triggers the rule is added: “satellite”. This token must be present in the design for
the rule to apply and be enacted (i.e. subsystems created and fulfilled).
278
Figure 56. Creation of rules in SPIDR-Lite
Under “Then” (in the bottom portion of the screen), the resultant tokens, systems, or components
that the rule should bring into the design are added. Selecting the “Could have” radio button
identifies the rule as just one possible approach to satisfy the trigger token. Additional ways may
or may not exist. Selection of the “Should have” radio button means that the following specified
additions and/or actions will be enforced if the trigger token is present. Thus in the “subsystems”
rule, tokens are added for each of the six subsystem tokens. “Could have” is selected, as other
rules might be added that present different ways to fulfill the satellite token goal, for example
another possible system instantiation might not have an ADCS token. Since no other fulfillment
279
rules exist here, the subsystems rule will be chosen by default (assuming all conditions are
satisfied).
Note that in this example, four subsystem tokens (Comm, CDH, EPS and ADCS) and two
component tokens (generic Thermal and Structure components) are attached in the subsystems
rule when satellite is present. For each of the Comm, CDH, and EPS token, three more rules are
created that will attach one or more components to fulfill each subsystem task. For ADCS, a rule
is created that attaches two more sub-subsystem goal tokens (where “goal” indicates that it is a
token that must be fulfilled): determination and control. These are separated so that different
methods can be selected dynamically by the SPIDR engine to fulfill the determination and
control tasks according to the mission specifications present. “Determ” and “control” rules are
created that then attach components that fulfill their respective goals when those tokens are
present.
Finally, a problem can be created that specifies the token to be designed and the metric to
optimize. When executed, a popup window emerges that displays the resultant designs on the left
half of the output screen, ordered by optimization metric, and the individual design information
for each result on the right side (Figure 57).
280
Figure 57. Final output screen of the SPIDR-Lite satellite design example problem, with
resultant designs on the left and individual design information on the right
281
Appendix D
Additional Observations
This section presents some additional, general observations made with respect to holistic satellite
design.
First, the ability to accumulate sufficient detail about available COTS spacecraft components is a
challenging process. Much of this information is proprietary (especially cost) and/or ITAR
(International Traffic in Arms Regulations) controlled (especially high-fidelity information such
as drawings and pinouts). For a modeling environment to generate meaningful design results,
however, it was found that the information about each component in the database should ideally
be both complete and accurate. In the absence of sufficient component data, many of these fields
must be populated with rough order of magnitude (ROM) estimates that do not differ greatly
from each other, and thus the ability of an optimizer to do its job is diminished. In addition,
ITAR and proprietary considerations could affect the ability of a collaborative modeling
approach if the component catalog is to be openly available. A potential solution is to have such
data firewalled from the user in a secure portion of the database, such that it can be considered
by and can affect the design process, but would not visible to the user. While this approach may
work in theory, such data is so strictly controlled that use of a simple firewall may not be
considered sufficient by the user or vendor community. The ability to control access would still
282
be questionable, and users may still be able to extrapolate or reverse engineer information about
the secure data from supposedly sanitized results.
A second observation was that of balancing a simplistic user interface with a detailed model
14
.
With the approach used in this research, advantages are gained in the ability of the engine to
efficiently handle numerous different potential configurations and track a high number of
relationships. Meaningful behavioral relationships between components, environment,
operations, etc. often emerge as detailed mission-specific user inputs are provided, but this leads
to a more complicated and lengthy input specification process. This is generally an undesirable
attribute, and it negates the enhanced efficiency and rapidity offered by an environment such as
the one used in this study. However, the use of a declarative approach does at least improve this,
because it allows for a large number of user inputs to be left unspecified (i.e. left as default
values), while still leaving the design problem in a consistent state. Thus a user interface can
offer a comprehensive suite of inputs for a “power user”, but can also be useful to lesser matured
programs and users seeking simple, rapid conceptual design.
A long-term goal of this research is to streamline the relationships between the input parameters
and the rule network to the extent that, ideally, the user only needs to provide very top level,
payload and mission specific parameters. Theoretically, a comprehensive knowledge base should
be able to determine all resultant system parameters from these inputs. However, the complexity
required to achieve such a pure design flow, in particular the number of interdependencies
accurately expressed between rules, and associated high fidelity analysis (for example orbital
maneuvers), is too great.
14
This challenge was also observed by Aas et al at TU Delft [1,2], wherein users found the solicitation of orbital
maneuver parameters in a tool’s main input screen to be too high of detail. However, such information is necessary
in order to calculate necessary ΔV for the mission. The solution identified by the TU Delft team was to simply ask
the user to provide the ΔV values themselves, which is clearly not an ideal approach.
283
A related issue that emerged was the difficulty of capturing increasing design fidelity in a rule
and constraint network. As a design matures, knowledge of all the different system constituents
(operational choices, components, etc.) that affect a certain design decision grows. For example,
a challenging situation that emerged in the CubeSat development project was that of the
interrelatedness of spacecraft geometry, placement of an antenna on a specific face, operations
enabled or infeasible because of that specific type of antenna selected, pointing profile that must
be used as a result, required solar array configuration, etc., etc. It was found that it becomes
difficult to adequately capture all of these relationships and express them via constraints and
trigger conditions in each of the applicable rules.
Furthermore, the need for high-fidelity structural and thermal analysis in the design loop is
apparent. It is often difficult to generate the necessary input files required by such analyses from
text-based, tabular, or XML data. In addition, problems such as thermal analysis require
significant high-level detail, including geometry, materials (down to connectors and brackets,
etc.), blanketing, pointing, etc. However, if this could be implemented, it would be enormously
valuable due to the ability to automatically generate items such as structural and thermal models
during the conceptual design phase. While progress was made in integrating thermal analysis,
structural analysis is an even more complicated challenge
Relative to thermal modeling, it was also observed that the available rule expressions in SPIDR,
i.e. arule and srule (refer to section 7.1.1) were potentially insufficient for some of the desirable
logic and design aggregations that occur in space system design. For example, the fulfillment of
a thermal control system (TCS) can occur via a variety of aggregated components with varying
levels of performance, such as a radiator, reflective coatings and paints, and active thermal
dissipators. A set of rules that are optional (similar to arules), and each can be sized to achieve
284
some desired performance on aggregate, were deemed to be a useful addition, if possible. This
was conveyed to the SPIDR engine developer, who integrated this feature and provided it as a
choice rule, or crule. Then, assuming a thermal dissipation of X needs to occur, the size of the
radiator, type of reflective coating, and existence of other active/passive components would be
dynamically selected and sized by the SPIDR engine. In a procedural approach, this could only
be done through explicit selection by the engineer, and would likely be based off subjective
experience or thumb rules (e.g. size as much of the reflective coating as possible first, then a
radiator if more heat exists that needs to be dissipated, then add and size further components,
etc.). This adoption of crules occurred specifically for space system design, but obviously could
have applications in many domains beyond that as well.
Abstract (if available)
Abstract
The space system design process is known to be laborious, complex, and computationally demanding. It is highly multi‐disciplinary, involving several interdependent subsystems that must be both highly optimized and reliable due to the high cost of launch. Satellites must also be capable of operating in harsh and unpredictable environments, so integrating high‐fidelity analysis is important. To address each of these concerns, a holistic design approach is necessary. However, while the sophistication of space systems has evolved significantly in the last 60 years, improvements in the design process have been comparatively stagnant. Space systems continue to be designed using a procedural, subsystem‐by‐subsystem approach. This method is inadequate since it generally requires extensive iteration and limited or heuristic‐based search, which can be slow, labor‐intensive, and inaccurate. ❧ The use of a declarative design approach can potentially address these inadequacies. In the declarative programming style, the focus of a problem is placed on what the objective is, and not necessarily how it should be achieved. In the context of design, this entails knowledge expressed as a declaration of statements that are true about the desired artifact instead of explicit instructions on how to implement it. A well‐known technique is through constraint‐based reasoning, where a design problem is represented as a network of rules and constraints that are reasoned across by a solver to dynamically discover the optimal candidate(s). This enables implicit instantiation of the tradespace and allows for automatic generation of all feasible design candidates. As such, this approach also appears to be well‐suited to modeling adaptable space systems, which generally have large tradespaces and possess configurations that are not well‐known a priori. ❧ This research applied a declarative design approach to holistic satellite design and to tradespace exploration for adaptable space systems. The approach was tested during the design of USC’s Aeneas nanosatellite project, and a case study was performed to assess the advantages of the new approach over past procedural approaches. It was found that use of the declarative approach improved design accuracy through exhaustive tradespace search and provable optimality
Linked assets
University of Southern California Dissertations and Theses
Conceptually similar
PDF
Systems engineering and mission design of a lunar South Pole rover mission: a novel approach to the multidisciplinary design problem within a spacecraft systems engineering paradigm
PDF
Incorporation of mission scenarios in deep space spacecraft design trades
PDF
The system architecting process for a solar power satellite concept
PDF
Designing an optimal software intensive system acquisition: a game theoretic approach
PDF
Optimal guidance trajectories for proximity maneuvering and close approach with a tumbling resident space object under high fidelity J₂ and quadratic drag perturbation model
PDF
Integration of digital twin and generative models in model-based systems upgrade methodology
PDF
Context-adaptive expandable-compact POMDPs for engineering complex systems
PDF
Quantifying the effect of orbit altitude on mission cost for Earth observation satellites
PDF
Extending systems architecting for human considerations through model-based systems engineering
PDF
The development of an autonomous subsystem reconfiguration algorithm for the guidance, navigation, and control of aggregated multi-satellite systems
PDF
Increased fidelity space weather data collection using a non-linear CubeSat network
PDF
Techniques for analysis and design of temporary capture and resonant motion in astrodynamics
PDF
Relative-motion trajectory generation and maintenance for multi-spacecraft swarms
PDF
COSYSMO 3.0: an extended, unified cost estimating model for systems engineering
PDF
Cooperative localization of a compact spacecraft group using computer vision
PDF
Reduction of large set data transmission using algorithmically corrected model-based techniques for bandwidth efficiency
PDF
Trajectory mission design and navigation for a space weather forecast
PDF
Advanced nuclear technologies for deep space exploration
PDF
Building cellular self-organizing system (CSO): a behavior regulation based approach
PDF
Experimental and numerical investigations of charging interactions of a dusty surface in space plasma
Asset Metadata
Creator
Hoag, Lucy M.
(author)
Core Title
A declarative design approach to modeling traditional and non-traditional space systems
School
Viterbi School of Engineering
Degree
Doctor of Philosophy
Degree Program
Astronautical Engineering
Publication Date
03/19/2014
Defense Date
10/24/2013
Publisher
University of Southern California
(original),
University of Southern California. Libraries
(digital)
Tag
adaptable systems,declarative design,design automation,fractionated spacecraft,OAI-PMH Harvest,satellite design,tradespace exploration
Format
application/pdf
(imt)
Language
English
Contributor
Electronically uploaded by the author
(provenance)
Advisor
Madni, Azad M. (
committee chair
), Erwin, Daniel (
committee member
), Khoshnevis, Berok (
committee member
), Kunc, Joseph (
committee member
)
Creator Email
lucyhoag@gmail.com
Permanent Link (DOI)
https://doi.org/10.25549/usctheses-c3-371507
Unique identifier
UC11295826
Identifier
etd-HoagLucyM-2302.pdf (filename),usctheses-c3-371507 (legacy record id)
Legacy Identifier
etd-HoagLucyM-2302.pdf
Dmrecord
371507
Document Type
Dissertation
Format
application/pdf (imt)
Rights
Hoag, Lucy M.
Type
texts
Source
University of Southern California
(contributing entity),
University of Southern California Dissertations and Theses
(collection)
Access Conditions
The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...
Repository Name
University of Southern California Digital Library
Repository Location
USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA
Tags
adaptable systems
declarative design
design automation
fractionated spacecraft
satellite design
tradespace exploration