Abort options for Starship and Starship/SuperHeavy

[InterestedEngineer]

But that might cause the engine controller to be considered to be part of the AFSS and add another couple of 9's to the reliability requirement.  Probably easier to hardwire a relay in series with a valve solenoid or hardwire explosives to the inlet manifold or hardwire something.  I really don't want to have to discuss byzantine errors in a bus controller with a regulator.

No it would not. The AFSS/AFTS specs are pretty clear. It's job is to tell everyone to shut down (or whatever) when it detects an anomolous condition; it is a simple binary signal. If it does that reliably, then done.

Go and read them again. There's no requirement to shut down engines with a direct command for liquid fueled engines.  None.  Nada

In the case of IFT-1 the direct command would have failed, the entire engine compartment was on fire and all network connections severed to the engines.  So the regulations correspond with good engineering practices, which isn't a huge surprise.

Dropping the fuel tanks below minimum pressure required for the engines, that's the method Starship is using and a perfectly reasonable method as long as the pressure loss rate exceeds that of the pressure gain from autogeneous pressurization. Which it didn't in IFT-1, which is now fixed.

I've designed byzantine fault tolerant systems.  I'm glad the regulations are written with that in mind, it's one less regulatory battle for SpaceX to fight.

[Barley]

2) There's nothing to say that the individual engine controllers can't do a safe shutdown if they lose contact with the primary flight computers.  It's not a great solution, but odds are that things have already gone pear-shaped, and the shutdown is probably the least bad solution, or close to it.

But that might cause the engine controller to be considered to be part of the AFSS and add another couple of 9's to the reliability requirement.  Probably easier to hardwire a relay in series with a valve solenoid or hardwire explosives to the inlet manifold or hardwire something.  I really don't want to have to discuss byzantine errors in a bus controller with a regulator.

What regulator?  All the FAA cares about is that the thing goes boom when told to.  Thrust termination has nothing to do with that.  But thrust termination is incredibly important for any kind of launch escape, especially full Starship escape, which has pretty wimpy acceleration. The FAA doesn't care about that, at least until the human spaceflight moratorium expires (which could be next month, I guess).

I'm quoting you, if you've changed your mind just say so and we can move on.

[TheRadicalModerate]

2) There's nothing to say that the individual engine controllers can't do a safe shutdown if they lose contact with the primary flight computers.  It's not a great solution, but odds are that things have already gone pear-shaped, and the shutdown is probably the least bad solution, or close to it.

But that might cause the engine controller to be considered to be part of the AFSS and add another couple of 9's to the reliability requirement.  Probably easier to hardwire a relay in series with a valve solenoid or hardwire explosives to the inlet manifold or hardwire something.  I really don't want to have to discuss byzantine errors in a bus controller with a regulator.

What regulator?  All the FAA cares about is that the thing goes boom when told to.  Thrust termination has nothing to do with that.  But thrust termination is incredibly important for any kind of launch escape, especially full Starship escape, which has pretty wimpy acceleration. The FAA doesn't care about that, at least until the human spaceflight moratorium expires (which could be next month, I guess).

I'm quoting you, if you've changed your mind just say so and we can move on.

Ah, I see the problem.  From a risk-to-public standpoint, which is all the FAA cares about, you don't really care if the engines shut down or not, as long as the AFTS/AFSS destroys the vehicle before it wanders outside its safety corridor.  For a crewed flight, somebody (not the FAA) cares a lot about how the crew would escape a failure.  And that's the subject of this thread.  But, at least for now, there's no regulatory impact, unless you're building a NASA mission, which is sorta-kinda regulatory, but not really.

Let's think this through.  If the main flight computers lose contact with the engines, that's an abort condition.  I don't know how many one minus nines that takes you into the failure tree, but now you're on the node that says, "Don't let the SuperHeavy hit you in the butt on the way out."  So now the question is how you get as reliable a thrust termination as possible. 

If the main computers have lost connectivity to the engines, you've hopefully already begun the abort process.  Also hopefully, you detected something catastrophically bad was developing and issued thrust termination before connectivity was lost, but that may be too much to hope.  So the important thing is for the controllers to rapidly and reliably detect a loss of connectivity.  The protocol for that could be a tad on the byzantine side (e.g., you could be the process of a switch failover and you wouldn't want to abort a mission for that, but the switch can probably tell you that), but it's certainly manageable.

It's important not to begin an escape separation until thrust is terminated, if at all possible.  But failure to terminate thrust is a reasonable contingency.  Note that this isn't really a problem with a high thrust escape system, but could be a big problem if the Starship itself is your escape system.

[InterestedEngineer]

The F-9 shut down its engines for the Dragon escape test.



so yes for human-rated setups, the SH booster has to shutdown.  Even in the case of an engine compartment fire burning up all the control runs to the engines. (like IFT-1).

I wonder if F-9 has the same failure mode as IFT-1.

The byzantine issues of each individual engine deciding to shut down on its own are scary, I'm gonna sleep on that.

[Barley]

Let's think this through.  If the main flight computers lose contact with the engines, that's an abort condition.  I don't know how many one minus nines that takes you into the failure tree, but now you're on the node that says, "Don't let the SuperHeavy hit you in the butt on the way out."  So now the question is how you get as reliable a thrust termination as possible. 

If the main computers have lost connectivity to the engines, you've hopefully already begun the abort process.  Also hopefully, you detected something catastrophically bad was developing and issued thrust termination before connectivity was lost, but that may be too much to hope.  So the important thing is for the controllers to rapidly and reliably detect a loss of connectivity.  The protocol for that could be a tad on the byzantine side (e.g., you could be the process of a switch failover and you wouldn't want to abort a mission for that, but the switch can probably tell you that), but it's certainly manageable.

It's important not to begin an escape separation until thrust is terminated, if at all possible.  But failure to terminate thrust is a reasonable contingency.  Note that this isn't really a problem with a high thrust escape system, but could be a big problem if the Starship itself is your escape system.

Sorry for being a bit snippy last night.  I probably shouldn't post after dark.

The problem with the engine controller shutting down the engines for the abort is that the engine controller could go haywire.  A software "stuck throttle" in the engine controller could both require an abort and make the abort more difficult.  You want to be able to say:

P( Loss of crew ) = P( Loss of Booster ) x P( Failure of Escape system )

But it gets more involved when the two right hand terms are not independent.  There are several ways to deal with this.

A high-performance escape system that works (well enough) if the engines don't shut down.  This adds weight and high acceleration is itself a risk.

A more reliable engine controller.  This is hard.  Even if it's possible it's usually so hard that it effectively freezes the design, preventing obvious improvements.

A separate path to shut the engine down.  This doesn't have to be fully hardwired, a bus snooper that shuts the engine down if it detects that the engine controller is no longer receiving or responding to commands can work.  But hardwired relays are simple, light enough to not be a big problem, and the safety people like them.

---
As for engine shutdown only being needed for crew escape and not for normal flight termination, I'm not so sure.  There was definitely chatter about the termination of the StarShip flight being delayed.

AIUI the flight termination system tracks the instantaneous point of impact and terminates if it strays either too far from the proper course or too close to lots of people on the ground.  If you can't rely on termination of thrust then possible uncontrolled thrust after termination turns the instantaneous point of impact into an ellipse.  If the impact ellipse is too big it cannot thread the Straits of Florida between Miami and Havana.  You could almost certainly solve this by terminating with a bigger bang, or a smaller bang at a critical point.

[edzieba]

Whether preburner-produced pressure in the bell is even a factor depends on startup timing. At the 65km staging altitude Mach 1 is ~300 m/s. Injector face to bell lip is ~2m. That means if the time from preburner spinup to MCC ignition is less than ~6.7ms, the combustion gasses from the ignited main chamber will overtake (3.6km/s exhaust velocity by the bell lip) any dumped preburner gas before it can even exit the bell, let along start having effects like pressurising the environment within the hot staging ring.

[joek]

Go and read them again. There's no requirement to shut down engines with a direct command for liquid fueled engines.  None.  Nada

"Them" is rather generic. Are you referring to the AFSS/AFTS system (for which my statement was correct), or the system encompassing the vehicle as a whole (for which you are correct)? As I said, "It's job is to tell everyone to shut down (or whatever)"; that's why the "whatever", as it can encompass many other factors and downstream systems. If you want to interpret that as a "requirement to shut down engines with a direct command", that is your choice and an incorrect interpretation of what I stated.

[TheRadicalModerate]

Sorry for being a bit snippy last night.  I probably shouldn't post after dark.

No problem.  But if you think that was snippy, you haven't been hanging out on disqus recently.

The problem with the engine controller shutting down the engines for the abort is that the engine controller could go haywire.  A software "stuck throttle" in the engine controller could both require an abort and make the abort more difficult.  You want to be able to say:

P( Loss of crew ) = P( Loss of Booster ) x P( Failure of Escape system )

First, if there's a "software 'stuck throttle'", then that's a plain ol' garden-variety bug.  A software stuck throttle will cause missions to fail in any number of ways that have nothing to do with flight termination.

Yes, there are some dependencies between the two terms.  But you can also parse the problem as "stuff that happens leading up to loss of booster" and "stuff that happens after all elements agree that the booster will be lost."  If we take this latter approach, then what we're really concentrating on is ensuring that thrust termination happens one way or another, and in as precise a window as possible.

In an uncrewed flight, AFTS would simply blow the tanks, possibly with an extra few turns of detcord wrapped around the inlets to the prop manifolds.  A few fractions of a second later, all the engines will cavitate, and a few fractions after that, they'll tear themselves to pieces.  Problem solved.  Yes, there's a slight widening of the IIP ellipse incurred by those few fractions of a second.

(BTW, I'm pretty sure that booster IIPs end before you get to Key West.  That would be good to verify.)

For the crewed flight, it's obviously a different story, at least if you want to use Starship as your escape system.  (Again, I'm still convinced that whole-Starship escape isn't gonna work, but let's roll with it.)  But if you need thrust termination, what are your options?

1) Blow the booster with the Starship still attached.  I wouldn't rule this out, but it seems more fraught than just trying to escape with the engines running.

2) Go to any number of additional suspenders-and-belt methods to ensure that the flight system and the engine controllers never, ever lose contact.  Maybe a high power radio signal that allows the flight system to shout, "SHUT DOWN NOW!"?  Lots more redundant 100BaseT cables?  Whatever it is, it is indeed byzantine.

3) Implement a "lost contact" protocol for the controllers.  These are indeed tricky and, worse, asynchronous, unless you take steps to make them plesiochronous.

3a) Your "bus snooper" method seems to be a hardware implementation of a lost contact protocol, but it still has the same synchronizing difficulties.  It also has to be implemented in such a way that all controllers get the word, which will be difficult if things are getting all flamey.

But I'd guess that 99.9% of the failure cases that lead to lost contact have abundant precursors that would trigger launch escape long before things got to the the point of losing contact.  In those cases, the flight system orders thrust termination and things are... not good, but better than they would be.

Bottom line:  If you're counting on flight thrust termination for launch escape, you have to do failure mode analysis on the thrust termination system itself, and plan for it not working in some >3σ cases--or accept that, at some point, stuff happens.