1/24

Introduction Methodology Example of Application Conclusion

Optimizing Commonality and Performance inPlatform-Based Earth Observing SmallSat

Architectures

Zvonimir Stojanovski Daniel Selva

March 10, 2017

Partially funded by the Cornell University Engineering Learning Initiatives

2/24

Introduction Methodology Example of Application Conclusion

Background

CubeSats and other small satellites are becoming important inEarth-observing systems [1]

Often large constellations of similar or identical satellites

Can we use commonality to reduce mission costs withoutsacrificing performance?

Images from NASA.gov

3/24

Introduction Methodology Example of Application Conclusion

Commercial Off-the-Shelf (COTS) Components

Increasingly used for small satellitesCan significantly reduce development costAutomated tool developed by Jacobs and Selva [2]

Equipped with catalog of COTS componentsGenerates and evaluates design for a CubeSat

We want to extend this concept to families of satellites

endurosat.com

4/24

Introduction Methodology Example of Application Conclusion

Platform-Based Design

Widely used in mature industries, e.g.,automotive and aircraft [3]

Scale-Based

Variants obtained by scaling variables such aslength or area

E.g., Airbus A3xx family

Modular – Used Here

Variants obtained by combining different sets ofcommon components

E.g., Volkswagen A family

More appropriate for using COTS components

“Airbus A320Family,”Global Traffic.

5/24

Introduction Methodology Example of Application Conclusion

The Optimization Problem

Maximize Performance and Minimize Cost subject toFeasibility Constraints

Cost model accounts for commonality and modularity

When commonality is used:Cost is typically lowerbutDesign is not tailored specifically to each mission

This is the main trade-off in this problem

6/24

Introduction Methodology Example of Application Conclusion

How the Tool Works

GeneticAlgorithm(NSGA II)

Catalog

ResultsSelect Module

Scheme

Requirements

Compute Cost

Feasible?Apply

Penalty

ComputePerformance

ComponentsSelected forEach Mission

No

Yes

EvaluatedPlatformDesign

7/24

Introduction Methodology Example of Application Conclusion

Representation of a Satellite Design

Each satellite must have certain componentsWe call these abstract components component slots

Some slots may be empty (e.g., ADCS Actuator 2 andPropulsion)Components may be redundant

To design a satellite means to select components from thecatalog to fill the component slots.

8/24

Introduction Methodology Example of Application Conclusion

Modules and Platforms

A module is a set of one or morecomponents that is assembled prior tothe main assembly of the spacecraft

A module may fill multiplecomponent slots at once

Modules are assembled fromcomponents from the catalog

The module scheme indicateswhich component slots are placedtogether in modules

A platform is a family of spacecraft withshared modules

In a platform, all missions use thesame module scheme

9/24

Introduction Methodology Example of Application Conclusion

Cost Model for Mission Platform

Total cost:C = CP +CIAT +CL (1)

Component Cost CP: Sum of retail costs of COTS components

Launch Cost CL: based on prices given by a launch provider

Integration, Assembly and Testing (IAT) Cost CIAT : affected bymodular design and commonality

Assume other costs are not affected by choice of componentsor modules

10/24

Introduction Methodology Example of Application Conclusion

IAT Cost of Modules

Model based on Tsai, Chen, and Lo [4]

Aj = γj∑

imijaij (2)

Aj: IAT cost of module jaij: non-modular IAT cost of component imij number of component i in module jγj: “the savings ratio when module j is used”

Learning curve is used for multiple identical modulesThen Aj is the first unit IAT cost of module j

Small γj is better—gives lower module IAT cost

11/24

Introduction Methodology Example of Application Conclusion

Connectivity Coefficients

For each pair of components {i,k}, we define a connectivitycoefficient εik

Note that εik = εki

This is the cost increase or decrease factor when i and k areplaced together in a module

We compute γj by averaging εik over all pairs of components inmodule j

Sample Module j:

ε Antenna Transceiver BatteryAntenna \ Sym.Transceiver 0.8 \Battery 1.0 0.9 \

=⇒ γj = 0.9

12/24

Introduction Methodology Example of Application Conclusion

Heuristic for Selecting Module Schemes

Computationally expensive (if not impossible) to evaluate allmodule schemes

115 975 modules schemes for 10 component slots1 382 958 545 for 15 slots

Instead, we use a heuristic based on graph theory

Groups components together based on two factors:Frequently occurring pairs (take advantage of learning factor)Low connectivity coefficients (lower first-time IAT cost)

13/24

Introduction Methodology Example of Application Conclusion

Procedure for Determining Module Schemes

(A part of ) the initial graph

3

5

2

44

4

3.3

2.7

5

5

5

5

34

2.7

Propulsion

Antenna

Battery Transceiver

ADCS Actuator 2

ADCS Actuator 1

Weight: wij = εij × (# distinct component pairs)

14/24

Introduction Methodology Example of Application Conclusion

Procedure for Determining Module Schemes

Edges are removed from heaviest to lightest

Graph splits into n connected components, for n = 1,2,3, ...

This is for n = 3: Three Groups2

2.7

2.7

Propulsion

Antenna

Battery Transceiver

ADCS Actuator 2

ADCS Actuator 1

15/24

Introduction Methodology Example of Application Conclusion

Evaluating Performance for Mission Platforms

Threshold and Target values given for performance metrics foreach mission, e.g.

LifetimeDownlink data rateSlew ratePointing accuracy

Each performance metric is normalized using a sigmoidfunction

Performance of a mission is the average of its normalizedperformance metrics

Platform Performance Score – to be maximized

Weighted average of missions’ performance

Weight used is the mission’s “importance”

16/24

Introduction Methodology Example of Application Conclusion

Problem Overview

Inputs – For Each Mission

Payload

Orbit

Threshold and Target valuesfor performance

Number of satellites

“Importance” number

Feasibility constraintsBasic requirements foroperational satelliteE.g., solar panels producesufficient power

Ouptuts

Modular design for missionfamily

Total cost and costbreakdown (by mission,components, IAT, andlaunch)

Performance metrics formissions

17/24

Introduction Methodology Example of Application Conclusion

Sample Missions – Used for Testing the Tool

Mission #Sats Importance OrbitA 20 5 LEO, 400 km, PolarB 16 6 LEO, 600 km, Near-PolarC 8 8 SSO, 600 km, MorningD 5 10 SSO, 600 km, AfternoonE 15 10 LEO, 800 km, PolarF 5 15 SSO, 600 km, Morning

18/24

Introduction Methodology Example of Application Conclusion

Payload Specifications for Sample Missions

Mission Mass (g) Power (W) Height (mm) Data Rate (KB/s)A 1000 3 100 1.0B 200 1 30 2.5C 2000 20 150 12.5D 3000 30 200 25.0E 1200 10 100 5.0F 1500 15 150 50.0

For all sample payloads:

One-year reliability is 99.9%

Length and width are 100 mm

19/24

Introduction Methodology Example of Application Conclusion

Sample Mission Requirements

Mission A B C D E F

Lifetime (years) Thr. 0.4 0.4 1.5 4 1.8 2Tar. 0.5 0.5 2 5 2.2 2.5

Pointing Accuracy (deg) Thr. 1 2 0.2 0.005 0.5 0.005Tar. 0.5 1 0.1 0.001 0.1 0.001

Downlink Data Rate (kbit/s) Thr. 72 160 800 1600 320 3200Tar. 80 200 1000 2000 400 4000

Slew Rate (sec. to slew 30◦) Thr. 150 — 90 45 90 120Tar. 120 — 60 30 60 75

Thr. — Threshold value

Tar. — Target value

20/24

Introduction Methodology Example of Application Conclusion

Plot of All Feasible Designs Found

0.72 0.74 0.76 0.78 0.8 0.82 0.84 0.86 0.8830

35

40

45

50

55

60

Performance Score

Co

st($

100

000

0)

DominatedNon-Dominated

21/24

Introduction Methodology Example of Application Conclusion

Sample Module Schemes

Illustrate the trade-off between commonality and performance

Highest-Performance Platform Lowest-Cost Platform

Group Component Slots V1 ADCS Sensor 42 ADCS Actuator 1 23 ADCS Actuator 2 24 OBC 45 Battery 6

6AntennaTransceiver

3

7 Solar Panel 48 Structure 29 Propulsion 1

Group Component Slots V1 ADCS Sensor 32 OBC 53 Battery 4

4AntennaTransceiver

3

5ADCS Actuator 1ADCS Actuator 2Propulsion

2

6StructureSolar Panel

3

V is the number of variants of each module.

22/24

Introduction Methodology Example of Application Conclusion

Limitations

Performance model uses rough approximations

Component catalog is small

Cost model does not account for ground operations, etc.

Connectivity coefficients are guesses

Emphasis was on methodology

23/24

Introduction Methodology Example of Application Conclusion

Future Work

Expand component catalog and performance and cost models

Determine connectivity coefficients more accurately

Investigate results using more advanced genetic algorithms,e.g., with adaptive operator selection

Evaluate the heuristic used for finding module schemesApproach 1: Mathematical proof (if possible)Approach 2: Experimental – For some concrete examplesproduced by our tool, generate all possible module schemes,select the one with the lowest cost, and compare it with themodule scheme selected by our heuristic

24/24

Introduction Methodology Example of Application Conclusion

References

D. Selva and D. Krejci, “A survey and assessment of the capabilities ofCubesats for Earth observation,” 5 2012.

M. Jacobs and D. Selva, “A CubeSat Catalog Design Tool for a Multi-AgentArchitecture Development Framework,” Aerospace Conference, 2015 IEEE,pp. 1–10, 2015.

T. W. Simpson, “Product platform design and customization: Status andpromise,” Ai Edam, vol. 18, no. 01, pp. 3–20, 2004.

C. Y. Tsai, C. J. Chen, and Y. T. Lo, “A cost-based module mining method forthe assemble-to-order strategy,” Journal of Intelligent Manufacturing, vol. 25,pp. 1377–1392, 11 2014.