Replacing SLS/Orion using Starship HLS and Crew Dragon

[Robotbeat]

Well it’d be kind of inappropriate for NASA to NOT put it out for bid

[TheRadicalModerate]

Good idea. This thread was created in response to a "what if" question: how to salvage Artemis if congressional budget cutters kill SLS/Orion? If instead NASA (or elements inside congress) pitch it as an insurance policy, it might be a less unpalatable way to ease it in prior to an actual SLS/Orion cancellation.

There's the engineering, and then there's the politics.  One of the nice things about the D2/LSS kludge is that it completely divorces the engineering from the politics.  That's doesn't guarantee success, but the kludge is going to be (mostly) there, whether the politics likes it or not.

That's why discussing the (engineering) viability of the kludge is so interesting.

I don't think SpaceX could bid this for less than about $3 Billion for the development plus one mission, or for less than about $1.5 Billion for each subsequent mission. My GUESS is that other bidders would have no chance, since I think they need a lot more new hardware. This probably means NASA would not be able to award their cherished multiple bids, putting them in the same situation as the first HLS award.

That seems a bit pessimistic.  It implies that the kludge DDT&E (any long-duration D2 mods, mission planning, OTV-LSS software and nav qualification, OTV-to-HLS or OTV-to-Gateway docking, etc.) costs $1.5B.  I can believe $500M, but if it's much more than that, this probably ain't happening.

Let's work backward from the Option A and Option B awards, which require a bunch of DDT&E and three missions, all of them clean launches of three separate LSSes.  Total contract value:  $4040M.  Big arm-wave:  Let's say the DDT&E costs $2B,³ and Starship tanker launches stabilize at a price to NASA of about $50M.

$4040M total -
$2000M DDT&E -
$1200M in tanker launches (3 missions @ 8 launches¹ per mission @ $50M/launch) +
$250M in tanker savings if you only do proof-of-ascent for the Option A test article²
______
$1090M for 3 LSSes, each used once.

That would imply ~$365M to build and launch each LSS.  (That sounds about right?)

Now let's do kludge mission #1:

$500M DDT&E⁴ +
$365M for the OTV-LSS (which ought to be wildly reusable) +
$250M in tanker launches (5 to do LEO-NRHOfast-LEO) +
$300M for F9/D2 launch, with NASA hand-wringing included
______
$1415M for kludge #1

For subsequent kludge launches, which omit the DDT&E and the OTV-LSS cost ('cause it's wildly reusable), you're at $550M.

Plenty of room for disagreement here, but you're almost 3x worse.


_____________
¹Assumes 110t dry mass + crew module, 1200t tankage sent directly into a very modest HEEO, depot is filled in circular LEO, then propulsively ascends to HEEO and returns to LEO after doing its business, Isp=369s avg., TLI to BLT=3270m/s, the cislunar delta-v numbers from the old HLS trade study, everything with 1.5% FPR added, and about 150kg/day of boil-off in NRHO.

²Proof-of-ascent means you only need about 100m/s of prop at ascent, then you crash harmlessly (as opposed to crashing during engine startup).  I get 3 tankers, so a 5 tanker savings over full missions.

³This arm-wave assumes that NASA's paying for all of the LSS DDT&E, some of the refueling / depot DDT&E, and SpaceX is on its own dime to make Starship launch and land reusably.

⁴This would include retrofit of one of the existing D2 fleet.  If the changes are so big that it's not usable as a plain ol' D2, then add at least $500M for kludge #1.

[TomH]

Orion CM is reusable, SLS is not. And the latter of those is the one whose cost OMB has consistently called unsustainable.

I would begin by putting Orion atop SS/SH with the Starship stripped down and disposable. Also, 6 R-Vacs with an additional 7th raptor in the center for thrust vectoring; this one might have an intermediate sized nozzle depending upon geometry, no Raptor-SL. SH would remain reusable. You might even add landing legs and recover downrange on an ASDS. With no solids to outrun, the Orion LAS could be mass reduced. Following initial investment, costs should decrease and stabilize. This phase would still use SS-HLS. Even if you made SH disposable, it should still be cheaper than SLS.

A follow on would be to stretch the disposable SS US and tuck a National Team lander between the Orion and the US. With the US stretch &/or ASDS SH recovery, and possibly even discarding the SH, the transfer element of the lander may not even be needed. This would provide for a single launch architecture a la Apollo. This reduces costs further.

An upgraded deep space Dragon could be the final modification.

[OTV Booster]

What is it specifically that limits an uncrewed Dragon time on orbit? Could an enlarged trunk, or using trunk cargo space make it work?


If it needs more hypergolics for attitude control, things get harder.

[DanClemmensen]

What is it specifically that limits an uncrewed Dragon time on orbit? Could an enlarged trunk, or using trunk cargo space make it work?

If it needs more hypergolics for attitude control, things get harder.

There is an entire thread for that:
  Crew Dragon Mission Life Extension: Free-Flying, Uncrewed Duration
  https://forum.nasaspaceflight.com/index.php?topic=59657.0

Our thread here was created because we were dragging that thread off topic.

[DanClemmensen]

Orion CM is reusable, SLS is not. And the latter of those is the one whose cost OMB has consistently called unsustainable.

I would begin by putting Orion atop SS/SH with the Starship stripped down and disposable. Also, 6 R-Vacs with an additional 7th raptor in the center for thrust vectoring; this one might have an intermediate sized nozzle depending upon geometry, no Raptor-SL. SH would remain reusable. You might even add landing legs and recover downrange on an ASDS. With no solids to outrun, the Orion LAS could be mass reduced. Following initial investment, costs should decrease and stabilize. This phase would still use SS-HLS. Even if you made SH disposable, it should still be cheaper than SLS.

A follow on would be to stretch the disposable SS US and tuck a National Team lander between the Orion and the US. With the US stretch &/or ASDS SH recovery, and possibly even discarding the SH, the transfer element of the lander may not even be needed. This would provide for a single launch architecture a la Apollo. This reduces costs further.

An upgraded deep space Dragon could be the final modification.

Orion is only partially reusable. It's a 3-part spacecraft: Capsule, EUS, and LAS/fairing. Only the Capsule is reusable and it looks like refurbishment may be an expensive process.

In this thread, I was hoping we could explore the minimal solution to SLS/Orion replacement. The minimal solution requires little or no new hardware design.

[TomH]

Orion....Only the Capsule is reusable.

Fully aware. Dragon trunk is not reusable either.

[TheRadicalModerate]

Orion CM is reusable, SLS is not. And the latter of those is the one whose cost OMB has consistently called unsustainable.

I would begin by putting Orion atop SS/SH with the Starship stripped down and disposable. Also, 6 R-Vacs with an additional 7th raptor in the center for thrust vectoring; this one might have an intermediate sized nozzle depending upon geometry, no Raptor-SL. SH would remain reusable. You might even add landing legs and recover downrange on an ASDS. With no solids to outrun, the Orion LAS could be mass reduced. Following initial investment, costs should decrease and stabilize. This phase would still use SS-HLS. Even if you made SH disposable, it should still be cheaper than SLS.

A follow on would be to stretch the disposable SS US and tuck a National Team lander between the Orion and the US. With the US stretch &/or ASDS SH recovery, and possibly even discarding the SH, the transfer element of the lander may not even be needed. This would provide for a single launch architecture a la Apollo. This reduces costs further.

An upgraded deep space Dragon could be the final modification.

I strongly suggest that we restrict this thread to just the D2 / Starship HLS (aka LSS) kludge.  I believe you spun up this thread a while ago on this very topic, and several others merged content into it for a pretty robust (and surprisingly on-topic) discussion.  Let's keep it there.

SLS/Orion is so crazy-making for many of us--one way or the other--that it's hard to focus discussions on specific topics without wandering off into a food fight.  I've done it more times than I care to admit.  Sorry to sound like the annoying guy at the homeowner's association meeting, but Dan did us the favor of separating this topic from the even more specific thread about how to make D2 capable of multi-week uncrewed free-flying.  Seems like the least we can do is try to keep it clean.

[Robotbeat]

Orion....Only the Capsule is reusable.

Fully aware. Dragon trunk is not reusable either.

orion also has an unshielded docking port, so that also needs to be replaced.. dragon’s service module is in the capsule itself, so a lot more can be reused for Dragon than Orion. Orion’s LAS is actually pretty complicated and expensive. SpaceX’s Is recovered again.

[DanClemmensen]

Fully aware. Dragon trunk is not reusable either.

Dragon trunk is very simple and inexpensive compared to the Orion disposables (EUS and LAS), or to the Starliner Service Module. The low cost of the Dragon trunk is one reason that just flying two D2 may be cheaper in the short term than designing, qualifying, and manufacturing an extended-mission D2. In particular, the less new hardware, the sooner the kludge can replace SLS/Orion. Reducing the number of SLS/Orion flights by one would pay for several kludge missions.

[TomH]

Fully aware. Dragon trunk is not reusable either.

Dragon trunk is very simple and inexpensive compared to the Orion disposables (EUS and LAS), or to the Starliner Service Module. The low cost of the Dragon trunk is one reason that just flying two D2 may be cheaper in the short term than designing, qualifying, and manufacturing an extended-mission D2. In particular, the less new hardware, the sooner the kludge can replace SLS/Orion. Reducing the number of SLS/Orion flights by one would pay for several kludge missions.

I do not disagree in any way. Politics is as much of an issue as anything and my opinion is that due to costs, congress would let go of SLS first, but may not be willing to give up both. Again, just an opinion, but getting rid of one at a time may be easier than both in one go.

[TheRadicalModerate]

An issue to consider with the D2/LSS kludge:  Keeping an LSS in LEO for months or even years is very, very, very bad from an MMOD standpoint.¹

If you want to do refueling and crew transfer ops at the same altitude that you store the LSS (and the depot), then you need to operate above 1200km or below 375km to keep your MMOD risk low.  But 1200km (circular) is too high for D2 operations,² and VLEO requires massive amounts of station-keeping propellant.

I'm kinda forced to the conclusion that you'd have to store the OTV-LSS and depot at something like 1200-1300km circular, then have them descend into VLEO, the depot for the duration of its propellant aggregation campaign and the OTV-LSS for just long enough to take on the aggregated prop and do the RPOD with the D2.  Then they'd both have to have enough residual prop to get back to the high circular orbit, and store enough prop long-term to do the next descent to VLEO.

Storage that high is gonna be very hard on the crew-rated OTV-LSS's electronics.  But VLEO storage of ships with fairly low ballistic coefficients (they're empty) in a fairly dense region of the thermosphere, for months or years, could cost tens or even hundreds of tonnes of prop. This could be a real problem with the kludge conops.

_________________
¹The problem is even worse for the depot, because it's potentially a source of extremely large debris-generating events if it goes boom.  Going boom is a non-trivial possibility, because an energetic hunk of debris could penetrate an outer wall and continue on through the LOX/LCH4 bulkhead, generating plenty of heat for ignition as it went.  That's a lot of energy applied to a lot of stainless steel.

²Assume that Polaris Dawn is the most energetic D2 mission possible.  That's a 190 x 1400km orbit, which is energetically equivalent to a 795km circular orbit, which is at almost exactly the altitude with the highest density of debris and highest collision probability.  (Based on naive googling, see here, pp. 10-11.)

[Twark_Main]

If you want to do refueling and crew transfer ops at the same altitude that you store the LSS (and the depot), then you need to operate above 1200km or below 375km to keep your MMOD risk low.  But 1200km (circular) is too high for D2 operations,² and VLEO requires massive amounts of station-keeping propellant.

No need to go that far down. You can use a ~400-450 km orbit (similar to ISS) and the collisional probability is also "low."

I'm kinda forced to the conclusion that you'd have to store the OTV-LSS and depot at something like 1200-1300km circular, then have them descend into VLEO

Now this is just being silly. 

¹The problem is even worse for the depot, because it's potentially a source of extremely large debris-generating events if it goes boom.  Going boom is a non-trivial possibility, because an energetic hunk of debris could penetrate an outer wall and continue on through the LOX/LCH4 bulkhead, generating plenty of heat for ignition as it went.  That's a lot of energy applied to a lot of stainless steel.

All the more reason not to park it at 1300 km.

At that altitude the debris lifespan is.... not small. See attached.

I would guess that any dedicated depot will have thermal+MMOD blankets similar to Shuttle/Station. Not 100%, but a lot better than bare steel.

²Assume that Polaris Dawn is the most energetic D2 mission possible.  That's a 190 x 1400km orbit, which is energetically equivalent to a 795km circular orbit, which is at almost exactly the altitude with the highest density of debris and highest collision probability.  (Based on naive googling, see here, pp. 10-11.)

It's important to account for latitude too. Most of the collisional probability exists above 80° N/S (see Figure 12 on pp. 15), which exceeds the inclinations that would be used for this purpose.

[jarmumd]

Remember, IDSS only represents docking to the International Space Station.  GDSS is the standard for docking to the gateway, and they are not interchangeable for more than an emergency. 

Dragon, CST-100 = IDSS
Orion, HLS = GDSS

They cannot be made interchangeable.  and modifying one to be the other will come with a cost.

Just something to keep in mind as you combine options.

This is not quite correct.

Per GLS-RQMT-001 (the Gateway Logistics Services Requirements, attached below), the Gateway Docking System (GDS) is an IDSS-compatible design, with additional fluid (for refueling the Gateway), electrical, data, and possibly other connections, this compatibility implies that the rest of the docking system's IDSS required parts are not changed. Keep-out zones for such connections are reserved in the current revision (Rev F, July 2022) of the IDSS. Basically, GDSS is a specialized type of IDSS.

An IDSS compliant docking system should be able to dock with the Gateway, but it won't be able to use those other connections. A GDS should likewise be able to dock to the ISS.

The NASA Docking System Block 2 is the NASA developed GDSS-compatible docking system for Orion.

NASA's requirements for Gateway docking systems are specified in DSG-SPEC-MECH-017, Gateway Docking System Specification (GDSS), but unfortunately for us, this document is not publicly available.

I'm not wrong.  And I've explained this before.  My version of GDSS from 2021 (which is not publicly available to my knowledge), shows the umbilical connections.  The pin outs do not interchange between IDSS and GDSS.  So while you could do soft capture and hard capture, you could not connect the umbilicals to share power.  Futhermore, part of the connector change is tied to Time Tethered Ethernet which is the standard on GDSS, not IDSS/ISS (so the vehicles could not communicate either). 

I'm currently awaiting a copy of the CDSS standard to see which direction they go.

[DanClemmensen]

Remember, IDSS only represents docking to the International Space Station.  GDSS is the standard for docking to the gateway, and they are not interchangeable for more than an emergency. 

Dragon, CST-100 = IDSS
Orion, HLS = GDSS

They cannot be made interchangeable.  and modifying one to be the other will come with a cost.

Just something to keep in mind as you combine options.

This is not quite correct.

Per GLS-RQMT-001 (the Gateway Logistics Services Requirements, attached below), the Gateway Docking System (GDS) is an IDSS-compatible design, with additional fluid (for refueling the Gateway), electrical, data, and possibly other connections, this compatibility implies that the rest of the docking system's IDSS required parts are not changed. Keep-out zones for such connections are reserved in the current revision (Rev F, July 2022) of the IDSS. Basically, GDSS is a specialized type of IDSS.

An IDSS compliant docking system should be able to dock with the Gateway, but it won't be able to use those other connections. A GDS should likewise be able to dock to the ISS.

The NASA Docking System Block 2 is the NASA developed GDSS-compatible docking system for Orion.

NASA's requirements for Gateway docking systems are specified in DSG-SPEC-MECH-017, Gateway Docking System Specification (GDSS), but unfortunately for us, this document is not publicly available.

I'm not wrong.  And I've explained this before.  My version of GDSS from 2021 (which is not publicly available to my knowledge), shows the umbilical connections.  The pin outs do not interchange between IDSS and GDSS.  So while you could do soft capture and hard capture, you could not connect the umbilicals to share power.  Futhermore, part of the connector change is tied to Time Tethered Ethernet which is the standard on GDSS, not IDSS/ISS (so the vehicles could not communicate either). 

I'm currently awaiting a copy of the CDSS standard to see which direction they go.

What is "Time Tethered Ethernet"? A google search did not find this term. Are you referring to IEEE 1588? If so, it is electrically compatible with the IEEE 802.3 Ethernet standard.

Do you know how the docking port is specificed in the HLS Option A  and Option B requirements?

Note that  GDSS (as of 2019) specifies two separate power umbilical interfaces. Ports for visiting spacecraft only implement the one that is very similar to IDSS, the Module-to-module port interface adds the second interface, which is for a high-power connection and is outside of the main port circle.

[jarmumd]

I'm not wrong.  And I've explained this before.  My version of GDSS from 2021 (which is not publicly available to my knowledge), shows the umbilical connections.  The pin outs do not interchange between IDSS and GDSS.  So while you could do soft capture and hard capture, you could not connect the umbilicals to share power.  Futhermore, part of the connector change is tied to Time Tethered Ethernet which is the standard on GDSS, not IDSS/ISS (so the vehicles could not communicate either). 

I'm currently awaiting a copy of the CDSS standard to see which direction they go.

What is "Time Tethered Ethernet"? A google search did not find this term. Are you referring to IEEE 1588? If so, it is electrically compatible with the IEEE 802.3 Ethernet standard.

Do you know how the docking port is specificed in the HLS Option A  and Option B requirements?

Note that  GDSS (as of 2019) specifies two separate power umbilical interfaces. Ports for visiting spacecraft only implement the one that is very similar to IDSS, the Module-to-module port interface adds the second interface, which is for a high-power connection and is outside of the main port circle.

see this for more info on TTE:
https://arstechnica.com/information-technology/2022/11/researchers-break-security-guarantees-of-tte-networking-used-in-spacecraft/

HLS specified GDSS. 

I'm specifically talking the low power / data plugs and receptacles.  These are aligned along the axis of symmetry.  The high power plugs and gas/fluid transfer are every 30deg as needed.

[DanClemmensen]

I'm not wrong.  And I've explained this before.  My version of GDSS from 2021 (which is not publicly available to my knowledge), shows the umbilical connections.  The pin outs do not interchange between IDSS and GDSS.  So while you could do soft capture and hard capture, you could not connect the umbilicals to share power.  Futhermore, part of the connector change is tied to Time Tethered Ethernet which is the standard on GDSS, not IDSS/ISS (so the vehicles could not communicate either). 

I'm currently awaiting a copy of the CDSS standard to see which direction they go.

What is "Time Tethered Ethernet"? A google search did not find this term. Are you referring to IEEE 1588? If so, it is electrically compatible with the IEEE 802.3 Ethernet standard.

Do you know how the docking port is specificed in the HLS Option A  and Option B requirements?

Note that  GDSS (as of 2019) specifies two separate power umbilical interfaces. Ports for visiting spacecraft only implement the one that is very similar to IDSS, the Module-to-module port interface adds the second interface, which is for a high-power connection and is outside of the main port circle.

see this for more info on TTE:
https://arstechnica.com/information-technology/2022/11/researchers-break-security-guarantees-of-tte-networking-used-in-spacecraft/

HLS specified GDSS. 

I'm specifically talking the low power / data plugs and receptacles.  These are aligned along the axis of symmetry.  The high power plugs and gas/fluid transfer are every 30deg as needed.

Thanks. It's Time-Triggered Ethernet.

From your article reference:

While it’s 100 percent compatible with the Ethernet standard, TTE is also able to deliver messages that engineers normally reserve for special-purpose networks.

Thus if this were the only difference, then GDSS can intercommunicate using IEEE 803.2 ("Ethernet")  with IDSS across the interface.

[TheRadicalModerate]

I'm specifically talking the low power / data plugs and receptacles.  These are aligned along the axis of symmetry.  The high power plugs and gas/fluid transfer are every 30deg as needed.

I agree with Dan's response up-thread:  TTE is supposed to be backward-compatible with all Phy and MAC fine family of ethernet and switched ethernet standards.  Dumb 802.3 stuff goes into the TTE switches as best-effort traffic.  If the endpoints and switches support the TTE class-of-service extensions, they can get access to the better classes of service.

Did you see actual pin differences in your GDSS spec, or did you just note the TTE and assume the pin-outs were different?

For purposes of this discussion, nailing down whether active IDSS implementations can dock with passive GDSS is extremely important.  For the D2/LSS kludge to work, LSS has to be able to dock with Orion (active GDSS), D2 (active IDSS), and Gateway (passive GDSS).  If the D2 needs to cut over to GDSS and it's incompatible with IDSS, that's a pretty big change and makes the engineering case for the kludge less compelling.

Are you referring to IEEE 1588? If so, it is electrically compatible with the IEEE 802.3 Ethernet standard.

It's not 1588, although it does a lot of 1588-like stuff to make endpoints plesiochronous--if they want to be.  It's SAE AS6802.  But I'm pretty sure it's backward compatible with all the 802.3 and 802.1 stuff.

I mean, they (both SAE and NASA) would have to be insane not to be backward-compatible.

[DanClemmensen]

It's not 1588, although it does a lot of 1588-like stuff to make endpoints plesiochronous--if they want to be.  It's SAE AS6802.  But I'm pretty sure it's backward compatible with all the 802.3 and 802.1 stuff.

I mean, they (both SAE and NASA) would have to be insane not to be backward-compatible.

Yup. Now that I have the correct name, I found
    https://en.wikipedia.org/wiki/TTEthernet
It's absolutely backward-compatible. HLS can use a standard SAE AS6802 switch and plug in SAE AS6802 devices to talk to Orion or Gateway devices, and plug in IEEE 802.3 devices to talk to D2 devices, and most likely the devices on HLS will implement both protocols and use them as needed. The IDSS and GDSS specs do not appear to specify any devices or protocols. The specified pins can carry either protocol. It's up the the devices to agree on a anything above "layer 1".

The only remaining issue is whether or not the pinouts are physically compatible: what we informally referred to as "layer 0".

[TheRadicalModerate]

Yup. Now that I have the correct name...

I have to say that I like the idea of time-tethered ethernet.  The connector spec would require a tiny rotating black hole, and packets would get frame-dragged along with the rotation, until their information got plastered on the itty-bitty event horizon.

Kinda bursty, though.