Author Topic: Replacing SLS/Orion using Starship HLS and Crew Dragon  (Read 30348 times)

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4316
  • Tampa, FL
  • Liked: 3237
  • Likes Given: 634
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #40 on: 10/10/2023 10:23 pm »
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.

Fair point.  Serves me right for not reading my own reference.

OK, let's crank this a bit and make some assumptions:

5-year mission life for depot
0.25-year mission life for D2 in free-flight
Mission probability of collision less than 0.4% (1:250)
Depot surface area:  roughly 1400m (approximating as an open cylinder)
D2 surface area:  roughly 165m (approximating as a closed cone)

That graph has probability in p/m/yr, which we'll call P.  So:

0.004 > 1 - (1 - 1400Pdepot)⁵
Pdepot < 5.7E-7

0.004 > (1 - 165Pd2)0.25
Pd2 < 9.6E-5

(Math check appreciated.)

Referring to the graph and using 25 inclination, looks like that restricts the depot to VLEO pretty definitively, and even there things aren't exactly perfect.  The D2 looks good at pretty much any altitude.

So my strategy of boosting the depot up to a high orbit for storage is indeed silly.  I think this condemns all refueling and depot storage, not just for an OTV-LSS, to VLEO.  That's gonna be expensive in station-keeping prop.

Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2268
  • Seattle
  • Liked: 1774
  • Likes Given: 2867
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #41 on: 10/10/2023 10:27 pm »
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".

Just read the spec. It's good they kept it to 4 traffic classes or less.  Modern switches *claim* they handle 8, but their buffer space is so tiny that dividing that tiny by 8 is simply not usable.  Even dividing by 4 is a bit iffy.   2 works really well.

(I used two traffic classes when we had "keep cluster alive" type of messages in a large ethernet based chassis system).

The only real addition is the time triggered messages.  Seems a bit odd for switches to implement time triggered messages, as I can't imagine a highest traffic class having any more jitter than a time triggered message.  For a distributed clock it's useful for endpoints to have this though.  In my work we managed to work around such critical real time issues, though we were tempted a couple of times.  (FPGAs for endpoints allows you to be tempted by such things)

Offline DanClemmensen

  • Senior Member
  • *****
  • Posts: 5345
  • Earth (currently)
  • Liked: 4186
  • Likes Given: 1685
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #42 on: 10/10/2023 10:42 pm »
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".

Just read the spec. It's good they kept it to 4 traffic classes or less.  Modern switches *claim* they handle 8, but their buffer space is so tiny that dividing that tiny by 8 is simply not usable.  Even dividing by 4 is a bit iffy.   2 works really well.

(I used two traffic classes when we had "keep cluster alive" type of messages in a large ethernet based chassis system).

The only real addition is the time triggered messages.  Seems a bit odd for switches to implement time triggered messages, as I can't imagine a highest traffic class having any more jitter than a time triggered message.  For a distributed clock it's useful for endpoints to have this though.  In my work we managed to work around such critical real time issues, though we were tempted a couple of times.  (FPGAs for endpoints allows you to be tempted by such things)
Apparently, so far the standard has been implemented on a total of one network: the Orion spacecraft LAN. I suspect it's all super-high-price custom electronics, which is one reason they intend to move the electronics from Artemis I Orion onto the Artemis III Orion capsule to save(!) money. (NOTE: I'm guessing here).  A modern implementation would use off-the-shelf FPGAs in a triple-redundant configuration to achieve better performance and better reliability for maybe one percent of the cost.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4316
  • Tampa, FL
  • Liked: 3237
  • Likes Given: 634
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #43 on: 10/10/2023 10:53 pm »
jarmumd, do we now have you convinced that IDSS is backward-compatible with GDSS?  Do you see actual connector differences?  Is TTE the only problem you see?
« Last Edit: 10/10/2023 10:54 pm by TheRadicalModerate »

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4316
  • Tampa, FL
  • Liked: 3237
  • Likes Given: 634
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #44 on: 10/10/2023 11:01 pm »
Seems a bit odd for switches to implement time triggered messages, as I can't imagine a highest traffic class having any more jitter than a time triggered message.

Plesiochronous multicast delivery might be handy for some kinds of events.  For example, "blow the explosive bolts 5ms from now" would be kinda nice.  Not sure if TTE supports plesiochronous multicast, though.  And I agree that this appears to be swatting a fly with a nuclear weapon.

Offline DanClemmensen

  • Senior Member
  • *****
  • Posts: 5345
  • Earth (currently)
  • Liked: 4186
  • Likes Given: 1685
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #45 on: 10/10/2023 11:17 pm »
jarmumd, do we now have you convinced that IDSS is backward-compatible with GDSS?  Do you see actual connector differences?  Is TTE the only problem you see?
We don't even have ME convinced, until I see a copy of the actual current non-draft GDSS spec.

Offline jarmumd

  • Full Member
  • ***
  • Posts: 352
  • Liked: 134
  • Likes Given: 32
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #46 on: 10/11/2023 06:37 pm »
jarmumd, do we now have you convinced that IDSS is backward-compatible with GDSS?  Do you see actual connector differences?  Is TTE the only problem you see?

Nope, using what's publicly available, I've made a diagram so you can see the connector pin out differences.  Sorry being lazy for not embedding.

Also very sorry for using the wrong word, tethered vs triggered.  I should have been more careful.

And look, they may go back and change the connector again.  But this was a big issue when I worked HLS docking, where we were looking to use a similar system for CLD (commercial LEO stations).  It presented a big headache now having to develop two versions.


Offline InterestedEngineer

  • Senior Member
  • *****
  • Posts: 2268
  • Seattle
  • Liked: 1774
  • Likes Given: 2867
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #47 on: 10/11/2023 07:07 pm »
jarmumd, do we now have you convinced that IDSS is backward-compatible with GDSS?  Do you see actual connector differences?  Is TTE the only problem you see?

Nope, using what's publicly available, I've made a diagram so you can see the connector pin out differences.  Sorry being lazy for not embedding.

Also very sorry for using the wrong word, tethered vs triggered.  I should have been more careful.

And look, they may go back and change the connector again.  But this was a big issue when I worked HLS docking, where we were looking to use a similar system for CLD (commercial LEO stations).  It presented a big headache now having to develop two versions.

Since I see 4 pairs of Ethernet I'm assuming the redundancy is achieved by having multiple connectors.  Right?

Offline DanClemmensen

  • Senior Member
  • *****
  • Posts: 5345
  • Earth (currently)
  • Liked: 4186
  • Likes Given: 1685
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #48 on: 10/11/2023 07:32 pm »
jarmumd, do we now have you convinced that IDSS is backward-compatible with GDSS?  Do you see actual connector differences?  Is TTE the only problem you see?

Nope, using what's publicly available, I've made a diagram so you can see the connector pin out differences.  Sorry being lazy for not embedding.

Also very sorry for using the wrong word, tethered vs triggered.  I should have been more careful.

And look, they may go back and change the connector again.  But this was a big issue when I worked HLS docking, where we were looking to use a similar system for CLD (commercial LEO stations).  It presented a big headache now having to develop two versions.

Since I see 4 pairs of Ethernet I'm assuming the redundancy is achieved by having multiple connectors.  Right?
There are two connectors, because the IDSS (or GDSS) are "androgynous". They are actually hermaphroditic, each side having two separate connectors, one with pins and the other with sockets. The connectors themselves are not separately androgynous. The dock as a whole is androgynous.  When the two spacecraft come together, the pins on side A mate to the sockets on side B, and the pins on side B mate to the sockets on side A. The spec makes a virtue of this necessity by declaring that it's a redundant connection.

Offline DanClemmensen

  • Senior Member
  • *****
  • Posts: 5345
  • Earth (currently)
  • Liked: 4186
  • Likes Given: 1685
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #49 on: 10/11/2023 07:54 pm »

Nope, using what's publicly available, I've made a diagram so you can see the connector pin out differences.  Sorry being lazy for not embedding.

Well that's truly horrible. Both of those graphics are in the 2019 GDSS draft. Yep, the draft is not consistent with itself, much less with the IDSS spec. Both graphics are labeled "Figure Requires Update" The figures appear on pages 15 and 32 respectively. The red "es" in your graphic corresponds to the end of the word "requires" on page 19 in the 2019 GDSS draft.

AGAIN: I do not disbelieve you. You have worked on this professionally while I am just sitting here surfing the net.

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4316
  • Tampa, FL
  • Liked: 3237
  • Likes Given: 634
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #50 on: 10/11/2023 09:24 pm »
jarmumd, do we now have you convinced that IDSS is backward-compatible with GDSS?  Do you see actual connector differences?  Is TTE the only problem you see?

Nope, using what's publicly available, I've made a diagram so you can see the connector pin out differences.  Sorry being lazy for not embedding.

Also very sorry for using the wrong word, tethered vs triggered.  I should have been more careful.

And look, they may go back and change the connector again.  But this was a big issue when I worked HLS docking, where we were looking to use a similar system for CLD (commercial LEO stations).  It presented a big headache now having to develop two versions.

Hmm.

Is the GDSS spec you're using the DSG-SPEC-MECH-17 document, dated July 26, 2019 [bad link converted to a less-bad auto-download from somewhere in NSF]?  If so, I'm about 95% sure that they simply pulled the wrong picture for the draft.

The Visiting Vehicle Rectangular Umbilical Connector (VV RUC) shown in the picture doesn't appear to correspond with any of the SSQ-22680 Flight Releasable Attachment Mechanism (FRAM) arrangements.  But the text in Table 3.4.1.1-1, on the page after the connector pictures, specifies Arrangement K--which is exactly what IDSS IDD Rev. E specifies, although IDSS calls it a PDTU instead of a VV-RUC.

Note also that Fig. 3.4.1.9-1A shows an Arrangement K FRAM, and the diagram pinouts themselves are identical to the one in the IDSS IDD.

Still further confirmation that the VV RUC is in fact an SSQ-22680 FRAM is in section 3.4.1.9:

Quote
Each VV RUC is a SSQ 22680 connector that contains both power and data in the same connector shell. The HP RUCs are also SSQ 22680 connectors and carry only power in the connector shell.

What's new--at least mechanically--is the High Power RUC (HP RUC), which uses Arrangement A, per Table 3.4.1.1-1. I'm pretty sure that this is new to the GDSS because Gateway modules have to be docked, instead of berthed, as was the case for the ISS.  So the HP RUCs will be what provides a high-power bus between different modules.

But I can't find a diagram showing where the HP-RUCs are in relation to the VV-RUCs.  I suppose it's possible that the HP's simply replace the VV's in intermodule docking adapters, but then there's no inter-module data bus, which doesn't make any sense.  I suspect that the lack of the diagram is simply one of those many, many "Figure Requires Update" things.

I searched for "TTE" in the GDSS doc and couldn't find it.  Is there a separate document for this?  (Note that, per the up-thread discussion, TTE and vanilla ethernet should be connector-compatible, so there shouldn't be an issue here.)



So here's the best evidence that there actually is an incompatibility:

There was the following language in the HLS BAA:

Quote
In its FFP proposal, the Offeror shall propose a design that enables HLS docking to transport the crew from either Gateway or Orion. For docking with the Gateway, Offerors shall include development of an International Docking System Standard (IDSS) and Gateway Docking System Standard (GDSS)-compliant Active-Active docking adapter or equivalent approach for successful docking, as well as delivery and attachment of the adapter to Gateway. For docking with Orion, Offerors shall include development of a passive docking system or equivalent approach for successful docking, as well as delivery and attachment of the system on HLS.

At the time, I thought the use of an AADA was just a way of telling bidders that they didn't have to implement native active/passive IDSS on the HLS.  But maybe something bad happens if the HP-RUCs are depopulated?  If you had dumb software that couldn't interrogate the other side with a "did you actually implement an HP-RUC?" transaction, this could cause a hard-dock failure.  But specifying such a transaction would be vastly easier than forcing people to haul an IDSS-to-GDSS AADA up to NRHO.

Say more about HLS vs. CLD incompatibilities.  Is it just that one is GDSS and one is IDSS, or is there something more subtle going on?
« Last Edit: 10/11/2023 09:32 pm by TheRadicalModerate »

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 37428
  • Cape Canaveral Spaceport
  • Liked: 21411
  • Likes Given: 428
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #51 on: 10/11/2023 09:30 pm »
docking specs/systems are the least concern of this idea

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4316
  • Tampa, FL
  • Liked: 3237
  • Likes Given: 634
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #52 on: 10/11/2023 09:35 pm »
docking specs/systems are the least concern of this idea

Outside of the obvious political problem, what would be your greatest technical concern?

Offline Jim

  • Night Gator
  • Senior Member
  • *****
  • Posts: 37428
  • Cape Canaveral Spaceport
  • Liked: 21411
  • Likes Given: 428
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #53 on: 10/11/2023 09:37 pm »
docking specs/systems are the least concern of this idea

Outside of the obvious political problem, what would be your greatest technical concern?

There aren't any really.

Offline jarmumd

  • Full Member
  • ***
  • Posts: 352
  • Liked: 134
  • Likes Given: 32
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #54 on: 10/11/2023 09:47 pm »
docking specs/systems are the least concern of this idea

It was a rare moment to try and inject reality.

Offline jarmumd

  • Full Member
  • ***
  • Posts: 352
  • Liked: 134
  • Likes Given: 32
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #55 on: 10/11/2023 09:54 pm »
...

Say more about HLS vs. CLD incompatibilities.  Is it just that one is GDSS and one is IDSS, or is there something more subtle going on?

It's just always more complex behind the scenes than it seems.  I loved to laugh at commercial space station graphics, where it was obvious that a graphic designer made the image, not an engineer.  Certain designs didn't have adequate clearances to nosecones, and no where close to the distance from docking ports to solar panels and radiators.  None of that is in the IDSS spec (although it is in the NDS spec - NDS can refer to either the docking system by Boeing or the Nasa spec).  And someone probably has an answer, but I haven't heard of one to replace C2V2, which is the comm system between Visiting Vehicle and the Space Station.  C2V2 tells the spacecraft where the docking port is, the markers on the docking port are backup.

Offline Steve G

  • Regular
  • Full Member
  • ****
  • Posts: 574
  • Ottawa, ON
    • Stephen H Garrity
  • Liked: 612
  • Likes Given: 56
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #56 on: 10/11/2023 09:58 pm »
Dragon is specifically designed for LEO. It's thrusters point forward from the nose and has no service module. The trunk only provides power and aerodynamic stability during a launch abort.

Orion is specifically designed for beyond LEO. Therefor, Dragon would have to have significant modifications to replace Orion.

Starliner might be an easier swap.

Offline DanClemmensen

  • Senior Member
  • *****
  • Posts: 5345
  • Earth (currently)
  • Liked: 4186
  • Likes Given: 1685
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #57 on: 10/11/2023 10:06 pm »
Dragon is specifically designed for LEO. It's thrusters point forward from the nose and has no service module. The trunk only provides power and aerodynamic stability during a launch abort.

Orion is specifically designed for beyond LEO. Therefor, Dragon would have to have significant modifications to replace Orion.

Starliner might be an easier swap.
Please read the OP. This kludge does not replace Orion with Dragon. Dragon never leaves LEO. A separate vehicle (an HLS acting as a transfer vehicle) conveys the crew from LEO to NRHO and back.

Offline Twark_Main

  • Senior Member
  • *****
  • Posts: 3574
  • Technically we ALL live in space
  • Liked: 1856
  • Likes Given: 1179
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #58 on: 10/11/2023 11:22 pm »
[snip]

OK, let's crank this a bit and make some assumptions:

5-year mission life for depot
0.25-year mission life for D2 in free-flight
Mission probability of collision less than 0.4% (1:250)
Depot surface area:  roughly 1400m (approximating as an open cylinder)
D2 surface area:  roughly 165m (approximating as a closed cone)

That graph has probability in p/m/yr, which we'll call P.  So:

0.004 > 1 - (1 - 1400Pdepot)⁵
Pdepot < 5.7E-7

0.004 > (1 - 165Pd2)0.25
Pd2 < 9.6E-5

(Math check appreciated.)



In general, the formula should be  P < (1 - log(1 - Rmission)/log(T)) / A, where Rmission is the total allowable risk (ie 0.004), T is the mission duration in years, and A is the assumed spacecraft area.

I believe when they say "area" they mean projected area, not wetted area. If that were true, then the numbers above would overstate the debris risk by a factor of ~3.5x or so. Not sure.

« Last Edit: 10/13/2023 03:04 am by Twark_Main »
"The search for a universal design which suits all sites, people, and situations is obviously impossible. What is possible is well designed examples of the application of universal principles." ~~ David Holmgren

Online TheRadicalModerate

  • Senior Member
  • *****
  • Posts: 4316
  • Tampa, FL
  • Liked: 3237
  • Likes Given: 634
Re: Replacing SLS/Orion using Starship HLS and Crew Dragon
« Reply #59 on: 10/12/2023 03:31 am »
I believe when they say "area" they mean projected area, not wetted area. If that were true, then the numbers above would overstate the debris risk by a factor of ~3.5x or so. Not sure.

From the report, p. 17:

Quote
The model uses mathematical techniques to determine impact flux information (number of impacts per square metre of satellite area per year), and predicts the space debris environment up to the year 2050.

Pretty sure it's absolute area, or close enough to not to matter.  Impact flux can come from any direction, although some directions have higher flux than others.  I'm betting they just weight the model using absolute area as an input.

Tags:
 

Advertisement NovaTech
Advertisement Northrop Grumman
Advertisement
Advertisement Margaritaville Beach Resort South Padre Island
Advertisement Brady Kenniston
Advertisement NextSpaceflight
Advertisement Nathan Barker Photography
0