Understanding the Orbital Transfer Vehicle Trade Space

1American Institute of Aeronautics and Astronautics

UNDERSTANDING THE ORBITAL TRANSFER VEHICLE TRADE SPACE

Hugh L. McManus*

Metis Design, 46 Second St., Cambridge, MA 02140and Todd E. Schuman†

Massachusetts Institute of Technology, Cambridge MA 02139

* Senior Special Projects Engineer, Associate Fellow AIAA† Graduate Research Assistant, Department of Aeronautics and AstronauticsCopyright © 2003 by Hugh L. McManus. Published by the American Institute of Aeronautics and Astronautics, Inc. with permission.

ABSTRACT

This study uses new methods to explore the theoreticalperformance of over a hundred possible orbital transfervehicle designs. The designs have varying propulsiontypes, fuel mass fractions, and grappling/observationequipment capabilities. Simple sizing rules are used tocalculate the performance of the designs and theirutility to several types of users. Designs of interest arefurther explored using Integrated ConcurrentEngineering techniques, resulting in completeconceptual designs. The results give an understandingof the trade-space for such vehicles, includingsensitivities to both design variables and assumed userneeds. This clarifies some of the challenges involvedsuch as physical constraints and sensitivities touncertain user preferences. Several potentially viabledesigns are identified including an electric-propulsionhigh delta-V vehicle dubbed the Electric Cruiser, and aclass of lower delta-V vehicles dubbed Tenders whichare studied in a companion paper.

NOMENCLATURE

C Cost ($)cd Dry mass cost coefficient ($/kg)cw Wet mass cost coefficient ($/kg)Isp Specific impulse (sec)g Acceleration due to gravity (9.8 m/sec2)Mb Bus mass (kg)mbf Bus mass fraction coefficientMc Mass of observation/manipulator system (kg)Md Dry mass (kg)Mf Fuel mass (kg)Mp Mass of propulsion system (kg)mp0 Propulsion system base mass (kg)mpf Propulsion system mass fraction coefficientMw Wet mass (kg)Utot Total utilityVc Single attribute utility for capabilityVt Single attribute utility for response timeVv Single attribute utility for delta-VWc Utility weighting for capabilityWt Utility weighting for response timeWv Utility weighting for delta-VDv Change in velocity (m/sec)

INTRODUCTION

An orbital transfer vehicle, or “space tug,” is oneinstance of a broad class of vehicles that can perform avariety of on-orbit servicing functions. The simplestfunction of such a vehicle would be to observe spaceassets, hereafter referred to as targets, in situ. Thetargets may be cooperative (designed for servicing),partially cooperative (e.g. maneuverable in wayshelpful to the tug), uncooperative (inert), or evenhostile. The later case covers spinning or tumblingvehicles that would be hazardous to approach. A tugchanges the orbits of these targets for operationalreasons (e.g. life extension), to retrieve the targets,bringing them out of orbit or to other assets (e.g. Shuttleor ISS), or to eliminate debris. Similar vehicles mayinteract or service targets in a variety of other ways.The ability to interact with objects in space is adesirable capability, but clearly the range of possibleapproaches is large, and it has proven difficult to designviable tug systems.

The concept of tug vehicles goes back to the early yearsof the space program. A literature review is included ina companion paper.1 Here, we will only note thathypothetical tugs designed for a single mission rarelyshow an economic pay-off, although there is someevidence that if an infrastructure for on-orbit servicecould be created it would have positive value.2 Theconcept in practice is made difficult by unfriendlyorbital dynamics (many desired maneuvers areextremely energy-intensive), environments (the vehiclemust be radiation hard, and/or hard against some levelof debris damage, to last useful lifetimes in manyorbits), and economics (markets are uncertain, andpayoff is difficult to prove). Some missions requirenuclear or other advanced propulsion systems, and mostrequire advances in control systems and docking orgrappling hardware.

In this work, new space system architecture andconceptual design techniques have been applied to thetug problem. A capability referred to as Multi-AttributeTradespace Exploration (MATE) with ConcurrentEngineering (MATE-CON) was used. MATE is amethod for examining many design concepts to

Space 200323 - 25 September 2003, Long Beach, California

AIAA 2003-6370

Copyright © 2003 by Hugh McManus. Published by the American Institute of Aeronautics and Astronautics, Inc., with permission.


understand the possibilities and problems of the spaceof possible solutions – the tradespace.3 It wasdeveloped at MIT from earlier work on informationsystems analysis applied to space systems.4 IntegratedConcurrent Engineering (the CON in MATE-CON, butusually referred to on its own as ICE) is a method forrapidly producing preliminary designs in a “designroom” environment. The system used in this studydescends from work at JPL5 and the AerospaceCorporation,6 by way of Caltech.7 The overall MATE-CON system, along with other front-end design tools,was developed by a consortium of MIT, Caltech, andStanford.8

Using MATE, several hundred possible space tugvehicles are evaluated for their ability to move mass inorbit and interact with targets. The resulting tradespaceis examined to clarify some of the fundamentaldifficulties with the space tug concept, understand thesensitivities of the tradespace to uncertainties in usersneeds, identify the Pareto front of “good” designs, andfind some design points that are promising for multi-purpose tugs. ICE is then used to create ten conceptualdesigns for a range of hypothetical mission scenarios.The ICE designs lend credibility to the crude MATEmodels, further clarify design issues, and provide astarting point for further development of missions ofinterest.

This paper covers the MATE and ICE models createdto do the analyses, the MATE tradespace and itsinterpretation, and the conceptual design of four tugvehicles for a mission involving the rescue of aGeosynchronous Earth Orbit (GEO) satellite stranded ina transfer orbit by the failure of its apogee motor. Acompanion paper looks at a variety of specific missions,suggested originally by this tradespace analysis, thatconcentrate on servicing groups of satellites in similarorbits.

MATE METHOD

In MATE, user needs are defined in terms of thesystem’s attributes, or capabilities of the desiredsystem, rather than the characteristics of the desiredspace vehicle. These needs are expressed andquantified in utility metrics, often through the use ofMulti-Attribute Utility Theory. Then a design vector isselected, consisting of a very large number (hundreds tohundreds of thousands) of possible systems that couldbe used to meet the user needs. Simulation models areused to calculate the attributes of the proposed systems.The systems are then evaluated against the users’utilities to understand which systems best satisfy theusers’ needs. The results, collectively referred to as thetrade space, can then be explored. This process consistsof the search for not only optimal solutions, but also forunderstanding of design sensitivities, key trade-offs,dangerous uncertainties, and vulnerabilities to changesin the market or national policy. Often theseunderstandings will change a user’s perception of his or

her need, and/or the designer’s perception of theappropriate design space, resulting in a need to repeatthe analysis. The semi-automated nature of thecomputations allows this valuable exploitation ofemergent understanding with little cost or time penalty.Eventually, a design or designs from the trade space areselected for further consideration.9

In this study, a somewhat simplified version of theMATE method was used. The method was adapted inresponse to difficulties including the lack of animmediate customer and a very open design space. Thecustomer utilities were handled parametrically tounderstand the sensitivities of the tradespace to rangesof, and changes in, user needs. The analysis was doneat a high level, using low-fidelity models, but coveringa large range of possible designs.

Attributes and UtilitiesThe capabilities of a space tug vehicle determined to beuseful to a potential user include: (1) total delta-Vcapability, which determines where the spacetug can goand how far it can change the orbits of target vehicles;(2) mass of observation and manipulation equipment(and possibly spare parts, etc.) carried, whichdetermines at a high level what it can do to interact withtargets, referred to here as its capability; and (3)response time, or how fast it can get to a potential targetand interact with it in the desired way. Note that thedesign of observation and manipulation equipment andits corresponding software is outside the scope of thisstudy – the equipment is treated as a “black box” withmass and power requirements.

These attributes are translated into a single utilityfunction. In the absence of real users from which tocollect more sophisticated functions,9 it was decidedthat a simple function that could be exploredparametrically was most appropriate. The threeattributes are assigned single-attribute utilities. Theseare dimensionless metrics of user satisfaction from zero(minimal user need satisfied) to one (fully satisfieduser). The utilities are combined as a weighted sum.

The delta-V utility is shown in Fig. 1. Delta-V is acontinuous attribute calculated for each systemconsidered. Utility is assumed to increase linearly withdelta-V, with diminishing returns above the levelsnecessary to do Low Earth Orbit (LEO) to GEOtransfers. Variations on this utility are shown in Figs. 2and 3, which show respectively the utilities of a GEO-centric user (large steps in utility for achieving GEOand GEO round-trip capabilities) and a delta-V-hungryuser (continued linear utility for very high delta-V).The manipulator mass (capability) attribute has discretevalues, assumed to correspond to increasing utility asshown in Table 1. The response time of a real systemwould be a complex function of many factors; at thelevel of the current analysis it is reduced to a binaryattribute Vt, valued at one for high impulse systems, andzero for low impulse ones.


The combined utility is calculated as follows:

†

Utot = WvVv +WcVc +WtVt (1)

The combined utility is a dimensionless ranking of thepresumed usefulness of the system to a nominal user. Itneeds to be interpreted with care, as it provides ranking(0.8 is better than 0.4) but not scale (0.8 is not

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

0 2000 4000 6000 8000 10000 12000

Delta-V (m/sec)

Del

ta-V

Uti

lity

Vv

(dim

ensi

on

less

)

Leo-Geo

Leo-Geo RT

Fig. 1. Nominal single attribute utility for delta-V

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

0 2000 4000 6000 8000 10000 12000

Delta-V (m/sec)

Del

ta-V

Uti

lity

Vv

(dim

ensi

on

less

)

Leo-Geo

Leo-Geo RT

Fig. 2. Delta-V utility for GEO-centric user

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

0 5000 10000 15000 20000 25000 30000 35000 40000

Delta-V (m/sec)

Del

ta-V

Uti

lity

Vv

(dim

ensi

on

less

)

Leo-Geo

Leo-Geo RT

Fig. 3. Delta-V utility for delta-V hungry user

necessarily twice as good as 0.4) or any physicalmeaning. The nominal weightings and two other casesstudied are shown in Table 2.

Design vector and calculation of attributesA set of design variables (in MATE parlance, a designvector) was selected to represent possible tug vehicles.The following variables were selected: (1) observationand manipulator system mass; (2) propulsion type, and(3) mass of fuel carried.

Table 1 shows the relationship assumed betweenmanipulator mass, assumed capability, and utility value.No attempt was made to design or even specify themanipulator system, but for reference the 300 kg size istypical of small industrial robots, while the highcapability (3000 kg) is taken from a postulated systembased on shuttle arm technology.10

Table 3 shows the choices of propulsion systemconsidered, along with some assumed properties of thepropulsion systems. The total mass of the propulsionsystem is taken to be

†

M p = mp0 + mpf M f (2)

The fuel mass Mf was set at 30, 100, 300, 600, 1200,3000, 10000, 30000 or 50000 kg, obviously spanning alarge range of possible delta-Vs.

Table 1. Manipulator capability attribute, withcorresponding utility and mass

Capability Utility value Vc(dimensionless)

Mass Mc(kg)

Low 0.3 300Medium 0.6 1000High 0.9 3000Extreme 1.0 5000

Table 2. Utility weightings

Attribute NominalWeights

CapabilityStressed

ResponseTime

StressedDelta-V 0.6 0.3 0.2Capability 0.3 0.6 0.2Response Time 0.1 0.1 0.6

Table 3. Propulsion system choices and characteristics

PropulsionSystem

Isp(sec)

BaseMass

mp0 (kg)

MassFract.

mpf

HighImpulse

Storable biprop 300 0 0.12 YCryo 450 0 0.13 YElectric 3000 25 0.30 NNuclear 1500 1000 0.20 Y


The design vector described above represents 144possible designs. A few of the more extreme of thesedesigns were omitted, more for clarity of the resultinggraphics than for computational ease. A few designswith intermediate values of fuel mass, corresponding tospecific missions described in this and the companionpaper, were added; the final design vector contained137 possible designs.

The attributes of each design were calculated asfollows. The capability, and its utility, are determineddirectly from the manipulator system mass as shown inTable 1. The response time attribute is determineddirectly from the propulsion system choice. Thosecapable of high impulse are given a response timeutility Vt of one; those not capable are given a Vt ofzero. The delta-V attribute, and the cost, are calculatedby some simple vehicle sizing rules and the rocketequation.

The vehicle bus mass is calculated as

†

M b = M p + mbf M c (3)

The vehicle dry mass is calculated as

†

M d = M b + M c (4)

and the vehicle wet mass is

†

M w = M d + M f (5)

The total delta-V attribute is then

†

Dv = g Isp ln M w M d( ) (6)

The delta-V utility is then calculated (by aninterpolation routine) from Fig. 1, Fig. 2, or Fig. 3.Note that Eq. 6 calculates the total delta-V that thevehicle can effect on itself. Use of this value issupported by the fact that most missions studied spendmost of their fuel maneuvering the tug vehicle withoutan attached target. Alternately, this delta-V can bethought of as a commodity. If a target vehicle isattached to the tug, more of this commodity must beexpended. Mission specific true delta-V’s for a varietyof missions are discussed in the companion paper.

The individual utilities having been calculated, the totalutility is calculated using Eq. 1. The first-unit deliveredcost is estimated based on a simple rule-of-thumbformula.

†

C = cw M w + cd M d (7)

Equation 7 accounts for launch and first-unit hardwareprocurement costs. Technology development costs arenot included. The values for the coefficients in Eqs. 2,

3, 6, and 7 are found in Tables 3 and 4. These valuescomprise the constants vector in MATE parlance. Thecalculations are set up so that these values can be easilyaltered. These values were varied +/- 10% and nostrong sensitivity was found to any of them. However,it must be noted that some of them (e.g. the nuclearpropulsion properties) are quite speculative, and thetrade space may look different if they were drasticallyaltered.

Table 4. Misc. Coefficients

Constant Value (units)

mbf 1 (dimensionless)

cw 20 (k$/kg)

cd 150 (k$/kg)

MATE RESULTS

Figure 4 shows the tradespace as a plot of utility vs.cost with each point representing an evaluated design.The Pareto front of desirable designs are down (lowcost) and to the right (high performance). The Paretofront features an area of low-cost, lower utility designs(at the bottom of Fig. 4). In this region, a large numberof designs are available, and additional utility can behad with moderate increase in cost. On the other hand,very high levels of utility can only be purchased at greatcost (right hand side of plot).

The propulsion system is highlighted in Fig. 4, withdifferent symbols showing designs with differentpropulsion systems. The propulsion system is not adiscriminator in the low-cost, low utility part of thePareto front, except that nuclear power is excluded. Atthe high end, on the other hand, the Pareto front ispopulated by nuclear-powered designs. Electricpropulsion occupies the “knee” region where highutility may be obtained at moderate cost

Figure 5 shows the cost banding due to differentchoices of manipulator mass, or capability. For thelower-performance systems, increased capabilitytranslates to large increases in cost with only modestincreases in utility. High capabilities are only on thePareto front for high utility, very high cost systems.This indicates, for the nominal set of user utilities used,cost effective solutions would minimize the mass andpower of the observation and manipulation systemscarried. Using the utility weights for the “CapabilityStressed” user (Table 2) results in Fig. 6. As expected,increasing capability systems now appear all along thePareto front, although capability still comes at a fairlysteep price.


0

500

1000

1500

2000

2500

3000

3500

4000

0.0 0.2 0.4 0.6 0.8 1.0

Utility (dimensionless)

Co

st (

M$)

Biprop

CryoElectric

Nuclear

0

500

1000

1500

2000

2500

3000

3500

4000

0.0 0.2 0.4 0.6 0.8 1.0


Co

st (

M$)

Biprop

CryoElectric

Nuclear

Fig. 4. Trade space for nominal user, with propulsion system indicated

0

500

1000

1500

2000

2500

3000

3500

4000

0.0 0.2 0.4 0.6 0.8 1.0


Co

st (

M$)

Low Capability Medium Capability

High CapablityExtreme Capability

Fig. 5. Trade space for nominal user, with capabilityindicated

0

500

1000

1500

2000

2500

3000

3500

4000

0.0 0.2 0.4 0.6 0.8 1.0


Co

st (

M$)

Low Capability Medium Capability

High CapablityExtreme Capability

Fig. 6. Trade space for capability stressed user


Using the utility weightings for the “Response TimeStressed” user (Table 2) results in Fig. 7. The resultsare clear; electric propulsion is eliminated fromconsideration. In the nominal case (Fig. 4) electricpropulsion appears at the “knee” of the Pareto front,and would appear to give good utility for modest cost,but that conclusion will be very sensitive to theweighting given response time by an actual user.Conversely, if the nominal weights and the delta-Vutility function from Fig. 3 are used (representing a userwith a demand for very large delta-V) the result is Fig.8. Now, almost all the designs on the Pareto frontfeature electric propulsion.

A more detailed view of the lower right-hand corner ofthe nominal Pareto front (from Fig. 4) is shown in Fig.9. Only low-capability systems are shown. The linesconnect designs that differ only by fuel load carried.

0

500

1000

1500

2000

2500

3000

3500

4000

0.0 0.2 0.4 0.6 0.8 1.0


Co

st (

M$)

Biprop

CryoElectric

Nuclear

Fig. 7. Trade space for response time stressed user

0

500

1000

1500

2000

2500

3000

3500

4000

0.0 0.2 0.4 0.6 0.8 1.0


Co

st (

M$)

Biprop

CryoElectric

Nuclear

Fig. 8. Trade space for user with large delta-V needs

All the propulsion systems appear to hit a “wall” wherecosts increase sharply at little or no advantage in utility.Examination of the designs on this wall reveal two verydifferent phenomena. The bi-propellant andcryogenically fueled systems are up against the limits ofthe rocket equation. Each small increment in utility isgained only by carrying a lot more fuel, most of whichis used to push fuel around. The nuclear and electricsystems, on the other hand, are limited only by the factthat they achieve a high enough delta-V to score a 1.0on the delta-V utility, and there is simply no value incarrying more fuel. If that limit is removed, bothsystems show large advantages, as shown in Fig. 8.

Also shown on Fig. 9 are some specific designs capableof carrying out the mission mentioned in theintroduction—moving from a LEO parking orbit toGEO transfer orbit, grappling a stranded target vehicle,inserting it in GEO, and (optionally) returning to LEO.The biprop design is “on the wall”, needing a very largefuel load to create the necessary delta-V. Thecryogenically fueled design is not as bad, but is clearlysensitive to the details of its design – slight increases inmanipulator mass etc. will send it too “up the wall.”Neither chemical fuels can (without refueling) return avehicle to LEO. The electric vehicles, both one-way“tug” and round-trip “cruiser” do not have this problem.The Electric Cruiser design, in fact, sits in the lower-right corner of the tradespace because it has maximizedthe delta-V utility, not because it is limited by physics.

To flesh out the vehicles briefly described here, andverify the reasonableness of the very approximatemethods used in the tradespace analysis, conceptualdesigns for these vehicles were created using ICE.

ICE METHOD

ICE is a way of streamlining the design process to makeit more efficient. ICE addresses some of the majorproblems of spacecraft development includingcomplicated interdisciplinary interfaces and inefficienttime usage. Caltech’s Laboratory for Spacecraft andMission Design has made several importantcontributions to the ICE method, including theICEMaker software that was used throughout theproject.7

ICEMaker is a parameter exchange tool that facilitatessharing of information amongst the design team. Thedesign problem is broken down into individualmodules, also known as “sheets”’ or “clients” which arelinked together via the ICEMaker server. Users canquery the server to either send their latest numbers orreceive any recent changes made in other modules thataffect their work. The querying process is manual,preventing values from being overwritten withoutpermission from the user. The combination of a humanexpert and a computational module is referred to as a“chair.”


0

100

200

300

400

500

600

0 0.2 0.4 0.6 0.8 1


Co

st (

M$)

Storable BipropCryo

ElectricNuclear

Biprop GEO tug

Cryo GEO tugElectric GEO tug

Electric GEO cruiser

Fig. 9. Low capability systems, showing effect of increasing fuel load, with GEO rescue vehicles

ICE design sessions typically last several hours andusually address one major trade per design session. Asenior team member, or “facilitator,” leads the designsessions and helps to resolve disconnects between theclients. The design sessions are iterative, with eachsubsystem sending and receiving many times in orderfor the point design to converge. Although it hasrecently become possible to automate this iterativeprocess, human operation of the client stations is almostalways preferred. The human element is actually key tothe method. The human expert can guide the iterations,catching bugs, nonsensical answers, divergence, andother pathologies that complex computational systemsare prone to. More importantly, the experts make majordiscontinuous design decisions, or go “outside the box”by stretching parameter ranges or even adding newcomputational capabilities, making the ICE method atrue design tool, not just a non-linear equation solver.

ICE ModelEach session was broken down into three segments:pre-processing, design, and post-processing. Customerinputs, payload design, and mission objectives weredecided by an Architecture chair during pre-processing.These inputs were fed to the design team and were used

to develop a point design. Finally, cost was estimatedduring the post-processing segment.

Ten ICEMaker modules were developed, with eachmodule representing a different spacecraft subsystem ordiscipline. The six main modules were Mission,Systems, Propulsion, Link, Configuration, and Power.Each sheet performed all the calculations necessary todesign its specific subsystem based on the inputsprovided to it. The models were developed using firstprinciples whenever possible, but rules-of-thumb basedon current technology were also used to reducecomplexity and coding time. These sheets wereelectronically linked through the ICEMaker server andinteracted throughout a design session sharinginformation and updating each other of changes to thedesign made by the individual chairs. The ICEMakerserver works primarily with Microsoft Excel®

spreadsheets. This work also made innovative use of anew software tool (Oculus CO®) that was used to linkroutines written in Mathworks Matlab® and aparametric solid geometry model done in Solidworks®

to the spreadsheets.

Several key simplifying assumptions were made. First,the sheets were only required to handle one vehicle per


design session. The Mating and Payload subsystemswere treated as “black boxes” with their specifications(mass, power, volume) fixed during the pre-processingsegment by the Architecture chair. Software, controlsystems, and operations were not considered beyond acosting rule of thumb. Finally, a few aspects of thevehicle design were handled by “dummy chairs” at alow level of model complexity. Structures, Thermal,Attitude Control, and Command and Data Handlinghistorically have a low impact on overall vehicle designat this level of analysis and can be handled adequatelyby rules of thumb. These dummy chairs can easily beexpanded for future work without changing the overallarchitecture if desired.

The following is a summary of the six main ICEMakermodules including their inputs and outputs:

Mission: determines delta-V requirements and otherhigh-level specifications

• Inputs – target orbits, tasks, timeline• Outputs – orbital elements, mission sequence,

delta-Vs, lifetime, mission durationPropulsion: sizes the propulsion subsystem, determinesfuel requirements

• Inputs – initial dry mass, delta Vs, thrustrequirements, target satellite masses, refuelingrequirements

• Outputs – fuel mass and volume, propulsionsystem type with mass and power requirements,wet mass of Space Tug

Power: sizes the power subsystem• Inputs – power requirements (average and peak)

from each subsystem by mode, orbit periods andeclipse length by phase

• Outputs – solar array mass and area, battery andpower management mass, temperature constraints

Link: sizes the telecommunications subsystem,calculates mission link budget

• Inputs – transmit station location, Space Tug orbitparameters, uplink and downlink margins, totaldata rate, mode durations

• Outputs – antenna type and dimensions, powerrequirements by mode, telecomm subsystem mass

Configuration: produces a visual representation of thevehicle

• Inputs – system hardware dimensions and mass,fuel volume

• Outputs – inertia tensor, surface areas, CAD modelSystems: maintains summaries of all majorspecifications (mass, power, etc.)

• Inputs – mass by subsystem, power consumptionby mode, total delta V, overall dimensions

• Outputs – total wet and dry mass by mode, linkbudget, cost estimate, contingencies, margins,mission summary

A summary of the ICE model and the main moduleinteractions are illustrated in Fig. 10.

Fig. 10. ICE model components and interactions

A full MATE-CON analysis would include thetradespace analysis explicitly in the above modelingsystem. In this effort, the MATE model was often runconcurrently with the ICE session, with key systemparameters passed manually, so that the position of thedeveloping design on the tradespace (as shown in Fig.9) could be tracked in real time.

ICE Results

Two main mission architectures were studied using theSpace Tug ICE model: a GEO Tug and a GEO/LEOTender. The GEO Tug is parked in LEO and waits fora single target mission, nominally a cooperative targetof up to 2000 kg stranded in GEO transfer orbit. It thenrendezvous with the target and inserts it into a GEOorbit, and if possible returns itself to LEO. TheGEO/LEO Tender is parked in a populated, target-richorbit and performs multiple missions during its lifetime.Possible missions include moving or disposing oftargets near its original parking orbit. Both of thesearchitectures assume a 300kg / 1kW mating device.

GEO TugsTugs were designed for both one-way and round-tripmissions using three different propulsion systems:bipropellant, cryogenic, and electric. The bipropellantand cryogenic round-trip missions could not close theirdelta-V budgets, leaving four feasible designs. Table 5and Figs. 11-13 summarize the GEO Tug designs. Themasses and power figures are taken from the ICEsession results. The delta-V, utility, and cost numbersare taken from the MATE analyses to allow directcomparison to the tradespace results (e.g. Fig. 9). TheICE system created considerably more design detailthan shown in Table 5. Mass, power, and link budgetswere created—see Fig. 14 for a typical result. Thephysical sizes and layouts of major components werealso determined and linked to a parametric solid model,which can be seen in Fig. 11-13. The view in Fig. 12shows internal layout.


Table 5. GEO Tug Design Summary

Design Dry Mass (kg) Wet Mass (kg) Power (w) Delta-V (km/s) Total Utility Cost (M$)Biprop one-way 1300 11700 1200 5.5 0.65 510Cryo one-way 1100 6200 1200 7.1 0.69 310Electric one-way 700 1000 3600 9.8 0.65 130Electric cruiser 700 1100 3600 12.6 0.69 140

Fig. 11. Cryo one-way tug, showing extremely largefuel tanks; Bi-prop tug appears similar

Fig. 12. Electric Cruiser (GEO round-trip tug)

The bi-prop one-way tug is very large and thereforevery expensive. It is also very sensitive to changes inany of the design assumptions; any increase in dry masscauses a very large increase in fuel required. There issome danger that such a design would not “close” (i.e.the required fuel mass would become infinite) if the drymass fraction or delta-V requirements were greater thananticipated. The best that can be said is that such avehicle could fill a niche for missions where a largepayload must be moved quickly using existingtechnology.

Fig. 13. Comparison of all GEO Tug designs

Structures & Mechanisms

18%

Thermal5%

Mating System

27%

Propellant36%

Link1%

Propulsion (dry)2%

Power11%

C&DH0%

Fig. 14. Mass breakdown of Electric Cruiser design

The cryo one-way tug is significantly lighter than thebiprop tug, but is almost as large due to low fueldensity. It would have a very limited life on-orbit dueto the need to keep the fuel cold. It is less sensitive tomass fractions and other assumptions, but still cannotmake a round trip to GEO.

The electric one-way and round-trip tugs seem to bepractical, versatile designs with reasonable sizes andcosts. The electric designs do have the drawback ofslow transit time, but they appear to be well suited for


missions where speed is not essential. The designimpact of the large total power requirement seen inTable 5 can be minimized by managing power use. Notrunning the manipulator and the full thruster set all atonce, and trading thruster power (and hence impulse)vs. solar panel size results in panels not much biggerthan those required for the chemical propulsion designs(see Figs. 11 and 12).

GEO / LEO TendersA family of tender missions was developed based onresearch of target satellite population densities. All ofthe tender missions use storable bipropellant systemsfor reduced cost and complexity. Each tender lives in aheavily populated orbit and is capable of performingfive or more missions involving moving or disposing ofsatellites near that orbit. The result of the tender studywas a line of similar vehicles with different fuel loadsdepending on the delta V requirements of the desiredorbit. These designs are discussed in the companionpaper.

A note on model consistency and accuracyThe differences between the results of the detailed ICEand very simple MATE analyses were remarkablysmall. Calculated masses differed by only a fewpercent. The only exceptions were the chemical fuelone-way GEO tug designs, due to their extreme fuelloads. These differences did not affect the points madehere. Power was not calculated by the MATE model.Delta-V was calculated differently by the ICE andMATE models, with the ICE model taking into accountthe details of the mission including rendezvousmaneuvers and the masses of target vehicles, but theresults were consistent given this difference. A checkof the ICE models’ Theoretical First Unit (TFU) pluslaunch costs against the simple MATE cost model againshowed remarkable agreement (within 15% in allcases). The ICE model also included development andengineering cost outputs, but these were not used duethe wide variation in technological maturity betweenthe different propulsion systems considered, which themodel made no provision for.

The above comparison, along with sensitivity studycarried out for the MATE analysis, and the relativesimplicity of the calculations, help verify that themodels are accurate predictors of their outputs, for theoften estimated or parametric inputs used. The modelresults should therefore be useful for ranking anddiscussion, but the values given in all cases should betaken to be estimates with accuracy appropriate forconcept evaluation and comparison only.

DISCUSSION

The tradespace analyses clarify the challenges ofdesigning spacetug vehicles. Visualization of the manypossible solutions to the problem of moving massaround in near-earth orbits reveals key constraints andtrades, and concentrates attention on a set of viable

solutions. The rapid conceptual designs help to validatethe crude tradespace models, further clarify designissues, and add detail and credibility to the designs ofviable vehicles. The combined set of models representsa capability that can be exercised to look at the specificneeds of customers (by identifying their utilities);exploring the possibilities of specific missions (bydesigning vehicles for them, and understanding theirposition in the overall tradespace) and investigating theimpact of specific technologies (by adding them to thetradespace and/or design analyses, and seeing theresults).

A number of lessons that should be widely applicable tothis class of vehicle were learned during the study.First, the unfriendly physics of high delta-V missions(the “rocket equation wall”) make carrying out thesemissions with chemical propulsion systemsproblematic. Even if a design of this type looksfeasible, it will be very vulnerable to unforeseenincreases in mass fraction and/or mission requirements,and it may be very expensive. Higher specific impulsesystems show promise, although caveats are in order.The electric propulsion systems examined appeared tooffer the best overall mix of performance and cost, butat the expense of speed. The postulated missions aresomewhat outside the current range of experience withthese technologies—it was assumed, for example, thatgetting operating lifetimes beyond those of currentsystems would be feasible. Nuclear systems lookinteresting if there is need for very high-capabilitysystems with quick response times; they are the onlytechnology studied that can meet such a need. They arealways expensive however, and the costs quoted heredo not include any technology development. Also, thepolicy and/or political issues surrounding thistechnology were not addressed here. Methods forquantifying the costs of policy choices were recentlystudied by Weigel,11 and could be applied to this case.

The comparison of the performance of current and nearfuture propulsion systems give hints as to the potentialvalue of other technologies applied to this problem. Ahigh-Isp, high impulse system without the large masspenalty of a nuclear system would be ideal; solarthermal, or stored-solar-energy systems (e.g. flywheelstorage) might be worth investigating for this purpose.On the other hand, the good results with existingelectric propulsion options make other low thrust (e.g.solar sail) technologies less interesting, unless there is avery large demand for delta-V. The trade-off betweenIsp, impulse, and total delta-V was found to be verysensitive to user needs. Thus, any further discussion ofthe value of various propulsion systems needs to takeplace in the context of the needs of a real user or at leasta more completely specified desired capability.

An issue that was relatively insensitive to user needswas the high penalty for dry mass on the tug vehicle.The higher capability (higher observation andmanipulator mass) vehicles showed large cost penalties.


Put another way, the total system costs were highlysensitive to the efficiency of the observation andmanipulation systems. Any user would be motivated toachieve the highest actual capability for the lowest mass(and, secondarily, power) when designing suchequipment.

The current tradespace analysis reveals three classes ofpotentially useful space tug vehicles. They arehighlighted on Fig. 15. The Electric Cruiser occupiesthe “knee in the curve” for our nominal utilities,providing good value for cost. It could potentiallyprovide even more value for a delta-V hungry user (seeFig. 8) although it is sensitive to user needs forresponse time. Its features have been discussed in thispaper. The “Nuclear Monsters” were not discussedhere, but appear to be the only designs (out of thedesign space considered) that can provide high delta-V,high capability, rapid response systems. A final rangeof vehicles occupies the lower left region of the Paretofront. These are cost effective vehicles built usingexisting technology (e.g. storable bi-propellant systems)that can do a variety of jobs requiring less delta-V thana LEO-GEO transfer. They could, for example, tendsets of vehicles in similar orbits, doing a variety ofmaintenance tasks. For this reason (and to extend thenaval support vessel metaphor) we have dubbed them“Tenders.” They are considered in depth in thecompanion paper.

ACKNOWLEDGEMENTS

This work was performed by the authors, MIT studentsLaura Condon, Todd Wesley, Devjit Chakravarti,Gerganna Bounova, Lisa Messeri, and Matt Richards,and Cambridge University students Nishant Lalwaniand Bill Cunliffe. The work was sponsored by DARPA(TTO) with Dr. Gordon Roesler as Program Manager.Funding was administerd via AFRL and the “GrandChallenges” contract number F29601-97-K-0010. Ms.Charlotte Gerhart served as the AFRL project manager.

0

200

400

600

800

1000

1200

1400

1600

1800

2000

0.0 0.2 0.4 0.6 0.8 1.0


Co

st (

$M)

Biprop

CryoElectric

Nuclear

Electric CruisersTenders

Nuclear Monsters

Fig. 15. Promising designs

REFERENCES

1. Galabonva, K., Bounova, G., de Weck, O. and

Hastings, D., “Architecting a Family of Space TugsBased on Orbital transfer Mission Scenarios,” AIAApaper 2003-6368.

2. Saleh, J. H., Lamassoure, E., and Hastings, D. E.“Space Systems Flexibility Provided by On-OrbitServicing: Part l,” Journal of Spacecraft andRockets, Vol. 39, No. 4, July-Aug. 2002, pp. 551-560.

3. McManus, H. L., and Warmkessel, J. M., “CreatingAdvanced Architectures for Space Systems:Emergent Lessons from New Processes,” Journal ofSpacecraft and Rockets, in press, modified fromAIAA paper 2001-4738.

4. Shaw, G. M., Miller, D. W., and Hastings, D. E.,“Development of the Quantitative GeneralizedInformation Network Analysis (GINA)Methodology for Satellite Systems,” Journal ofSpacecraft and Rockets, Vol. 38, No. 2, 2001, pp.257-269.

5. Smith, J. L., “Concurrent Engineering in the JPLProject Design Center,” Society of AutomotiveEngineers, Inc., Paper 98AMTC-83, 1998.

6. Aguilar, J. A., and Dawdy, A., “Scope vs. Detail:The Teams of the Concept Design Center,” 2000IEEE Aerospace Conference Proceedings, Big Sky,Montana, March 2000, Vol. 1, pp. 465-482.

7. Parkin, K., Sercel, J., Liu, M., and Thunnissen, D.,"ICEMaker: An Excel-Based Environment forCollaborative Design," 2003 IEEE AerospaceConference Proceedings, Big Sky, Montana, March2003.

8. McManus, H. L., Hastings, D. E., and Warmkessel,J. M., “New Methods for Rapid ArchitectureSelection and Conceptual Design,” Journal ofSpacecraft and Rockets, in press.

9. Ross, A. M., Diller, N. P., Hastings, D. E., andWarmkessel, J. M., “Multi-Attribute TradespaceExploration as a Front-End for Effective SpaceSystem Design,” Journal of Spacecraft and Rockets,in press.

10. “Project Freebird: An Orbital Transfer Vehicle”,Final report, 16.83 Space Systems Engineering,Aeronautics and Astronautics Department, MIT,Spring 1994.

11. Weigel, A. L., and Hastings, D. E., “Evaluating theCost and Risk Impacts of Launch Choices,” Journalof Spacecraft and Rockets, in press.

Documents

Understanding the Orbital Transfer Vehicle Trade Space