SpaceX Falcon 9: To Static Fire or not to Static Fire; that is the question

[ulm_atms]

If static fires are being done to “shake things up” and see what comes loose, I consider that to be a problem.
The only reason to intentionally cycle a system as a test is if you know there are infant mortality failure modes to get past.  After that cycles only add stress.

But expendable rockets aren’t allowed to have infant mortality, and reusable ones aren’t either.

You want it to shake loose on the way up?    Kidding slightly...

This is new reuse territory for them...let them test.  If something does break on a static test fire...it could easily break on the way up.  Let them test, if it breaks, figure it out and roll that change down the line so it doesn't happen again.  rinse/repeat.  I would be more worried if they started cowboying this and crossed their fingers each time it lights.  Although they are planning for 10 reuse...they haven't gotten there yet...1/2 way at this point.

[Coastal Ron]

If you are afraid that removing a single test will miss things, your system is not robust by any definition.

The N+1 fallacy works both ways.
But entropy only moves right.

Come on you know better. That's NOT a test. It was a WDR to shake things up for a 4 time flight old used rocket!

If static fires are being done to “shake things up” and see what comes loose, I consider that to be a problem.

Static fires are done to gather data, though we obviously have no idea what the specific type of data is, or what trend they are looking at.

The only reason to intentionally cycle a system as a test is if you know there are infant mortality failure modes to get past.

Infant mortality is for finding issues with something new. SpaceX routinely does static fires for not only new stages, but previously flown stages too, so that tells me that they are doing it for reasons OTHER THAN finding infant mortality.

After that cycles only add stress.

And provide data. Again, we have no idea what data they are gathering, or for what purpose, since they have only recently started attempting launches without static fires, that should tell us that the time and money it takes to do them have been worthwhile so far. Us in the public not understand it's value doesn't mean SpaceX is wrong... 

But expendable rockets aren’t allowed to have infant mortality, and reusable ones aren’t either.

Launch service providers can't provide their service unless their rockets do what they are supposed to do, so SpaceX must have a good reason why they have not eliminated static fires yet. And we know from Shotwell and Musk that they have been planning on reducing/eliminating static fires at some point in the future, so apparently we are seeing them working on doing that.

My $0.02

[thirtyone]

In many high end, lower volume product spaces, testing is often the difference between a poorly made product and a well made product. No matter what you do, yield is never 100% and rarely even close. Testing is what makes most products even decently acceptable. So I would *really* be careful before anyone insists that "less testing should be done." Sounds like a potential recipe for disaster.

However, it is very possible that testing causes more stress than detects issues. I doubt anyone other than SpaceX has the expertise or experience to answer the question of "how much testing do you need to do on a kerolox engine to refurb it for reflight without risking more damage from the test?"

I'm going to guess from my armchair anyway, because I guess that's the point of this forum. I think I heard this from a talk from Tom Mueller - kerosene is sooty, so they actually need to do pretty thorough cleaning after a launch if they want to maintain engine performance on subsequent launches. This is actually why they were pushing IPA through the system (the stuff that got trapped in a sensor dead leg and caused an engine-out on one of the recent launches). I can imagine that if some of the soot isn't cleaned evenly - say on a turbine blade - this could cause complex vibration issues that maybe wouldn't be detectable until a full firing of the engine in-place. I'm making this speculation based on a scene from a NatGeo SpaceX documentary ("MARS: Inside SpaceX") in the control room during a static fire, where one of the engineers says "Five hertz is where we're likely, just in bad territory" for the first FH launch, making me suspect that vibrational modes are at least one critical issue they're looking out for. Remember that the two side boosters were reused for the maiden launch.

[Coastal Ron]

In many high end, lower volume product spaces, testing is often the difference between a poorly made product and a well made product. No matter what you do, yield is never 100% and rarely even close. Testing is what makes most products even decently acceptable. So I would *really* be careful before anyone insists that "less testing should be done." Sounds like a potential recipe for disaster.

I have been in manufacturing operations for both low volume DoD products, and high volume consumer products. And in my role I've always worked with both Quality Control (QC) and Quality Assurance (QA), since I have needed to know when they found problems so that I would know if that was going to affect the product schedule (usually my area of responsibility). Just so you know my perspective here.

When you are developing a product, of any type, you do testing to validate your design and to see what the failure envelope is. Knowing what has the potential to fail informs what you will need to test in the production process, both during assembly and when the product is fully assembled and functional.

Back in the 70's American car companies would use their QC department to find problems at the end of the assembly process so that they could route the cars to a rework process. At the same time, in Japan their car companies had embraced the teachings of W. Edwards Deming, who gave talks on "Statistical Product Quality Administration". Their production processes relied on the production line workers finding problems, and when they did they stopped the production line to fix the problem. That has now become the way that most manufacturers make product.

The bottom line is that manufacturing organizations today know that you can't inspect quality into a product, you have to build it in. So testing is the validation of everything that you have done, and it is part of your validation process.

However, it is very possible that testing causes more stress than detects issues. I doubt anyone other than SpaceX has the expertise or experience to answer the question of "how much testing do you need to do on a kerolox engine to refurb it for reflight without risking more damage from the test?"

For electronics it is usually not an issue. Normally for rocket engines there would be a finite number of test firings you could do on an engine that was built to be expendable, but the Merlin engine is built to be reusable.

Elon Musk had talked in the past about SpaceX wanting to reduce the turnaround time for a reusable Falcon 9 to 24 hours. They may not have a business reason for doing that today, but static fires do cost money (and time), so it would behoove them to evaluate if static fires are really necessary before every launch. And since we know they gather lots of data about engine performance with each launch, they are in a good position to test out the need for static fires on their own launches (i.e. Starlink).

My $0.02

[intelati]

The way I see it in this case:

1. You're launching your own product. You're not going to affect anyone else for messing up the launch. (in cases <3 previous launches) You already have 10*10 data points to know what's going to happen.
2. For the life leaders, continue testing until you are comfortable with the sample size (This is literally the second time a rocket has been launched five times)

Pretty simple to me.

For other customers, the logic may vary.

I see them continuing to static fire for new boosters until the demise of the Falcon program.

[Lars-J]

The way I see it in this case:

1. You're launching your own product. You're not going to affect anyone else for messing up the launch. (in cases <3 previous launches) You already have 10*10 data points to know what's going to happen.

That is objectively wrong. NASA is relying on F9 to fly humans, and the DoD is relying on it for national security payloads. They will definitely care if a F9 fails during reuse. (As will other customers)

All this while you are trying to convince the industry that reused stages are as good as new. So it is not that simple. SpaceX will never launch a reused F9 if it is not VERY confident it will succeed. So testing continue to be important.
(But then again static fires are just one of the ways they test... so they may eventually go away...)

[zubenelgenubi]

OK, it's that time again...Static Fire or no Static Fire for the Falcon 9 launching Starlink v1.0 Flight 10?
It is the first time a first stage will be launched for a sixth time.

EDIT: See L2.

[intelati]

OK, it's that time again...Static Fire or no Static Fire for the Falcon 9 launching Starlink v1.0 Flight 10?
It is the first time a first stage will be launched for a sixth time.

EDIT: See L2.

I don't see how they don't SF. It's the first time ever someone has attempted to reuse the booster for the sixth time.

Easy money on a SF

[mulp]

The static fire is not just about the engine firing.

It cycles through the entire launch including abort for any reason, eg weather, sensor error, mechanical failure, engine start error, ....

For the crew launch, they rehearsed how many times, with and without fuel load?

While the crew at the pad and the control room are fairly constant, they are not launching frequently enough to not need a full crew rehearsal just before launch. Checklists are critical when doing the same thing over and over, ie taking off and landing planes. That makes up for not doing practice specifically for the activity.

To not rehearse a launch is like not rehearsing for the Superbowl.

[ZachS09]

Even though the first launch attempt of Demo-2 was scrubbed, there were some out there who compared it to a Wet Dress Rehearsal with crew onboard.

It was something SpaceX didn't have to do before the real deal.

[Nomadd]

 All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

[wannamoonbase]

We don't know what problems they find testing the boosters in McGregor.  Perhaps they are finding and correcting things all the time that we never hear about.

However, I think there could be a case made for having boosters skip the tests in McGregor and go straight to the launch pad.  Use the static fire to indicate vehicle health before launching.

Then of course you could use starting the engines for the actual launch as a computer controlled static fire.

SpaceX collects a ton of data, so I'm sure their decisions will be data driven.  They will drop, or test dropping, some of these activities, when the data tells them.

As an aside, I use to work in electronics manufacturing, our products got good enough at one point where the testing of the product caused more problems than it was finding. 

[Tulse]

However, I think there could be a case made for having boosters skip the tests in McGregor and go straight to the launch pad.  Use the static fire to indicate vehicle health before launching.

I think it would make more sense the other way around -- do the testing at McGregor and skip the static fires. If one detected a problem at McGregor one could potentially swap out engines or roll out another booster with minimal launch delay, whereas if a problem is found when everything is stacked and on the launch pad, rectifying things could take far more time.

[Lars-J]

All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

Would you rather find out about engine issues at the scheduled launch time, or a few days earlier? Doing the extra (scheduled) test helps improve overall launch schedule assurance. SpaceX has had remarkably few countdown/liftoff aborts for technical reasons in the last few years, and I believe the static fires are a significant factor in that.

Also running the engines for a few seconds (vs just starting them) will give the entire rocket a good shake. In case anything is loose... 

[whitelancer64]

All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

It isn't impossible. The computers on-board the Falcon 9 fully control the launch from T-60 or so, IIRC. There have been a few aborts after engine start-up.

[meekGee]

All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

I think some of the data may not be black and white but result in a desire to inspect something..  so you'd rather do it before the launch window.

The assumption is that if you got through that, the odds of another issue cropping up at launch are lower.

I think what will allow them to eventually drop SFs is when they can use data from the previous flight as a proxy for the SF.  For this to become the norm requires that they be comfortable with very used boosters, and this will happen, I predict, exactly when SS starts flying and taking over.

[ChrML]

All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

Most likely, however range availability and weather are pretty significant constraints these days. Probably costs a lot of money too to book the range.

It'd be bad to waste a launch opportunity because a sensor has issues, and you could've found that issue a few days before, fixed it and launched on time.

[dondar]

All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

they do it actually (Shuttle, Delta IV, Electron all had at least one such abort). That is why all other companies don't do static fire.
I believe the main reason of SpaceX static fires is rehearsal. Banal training and getting into "the mood".
The static fire is not that expensive (all other companies do pref-light testing anyway and time-money costs are of a similar value).

To TL/DR this and many/many other questions: by all accounts SpaceX is designed and managed by engineer fanatics with engineer fanatics in mind. Everything they do fit this paradigm very tightly.

[jrhan48]

All these arguments for static fires, and I don't see an answer to the one thing that confuses me. Why is it impossible for all the factors they look at to be automatically evaluated by computer in the second between ignition and liftoff? To paraphrase Data, a second is a very long time for a computer.

they do it actually (Shuttle, Delta IV, Electron all had at least one such abort). That is why all other companies don't do static fire.
I believe the main reason of SpaceX static fires is rehearsal. Banal training and getting into "the mood".
The static fire is not that expensive (all other companies do pref-light testing anyway and time-money costs are of a similar value).

To TL/DR this and many/many other questions: by all accounts SpaceX is designed and managed by engineer fanatics with engineer fanatics in mind. Everything they do fit this paradigm very tightly.

IMHO with respect to Static Firing, in systems there is something called "emergent behavior" where the sum is greater than the parts. One needs to run the system as a system, fully to exercise these behaviors, and the interesting part is that emergent behaviors are not all good, failures can be "emergent" as well.  Others have cited vibration and I am sure they look at the mechanical spectrum, but also a critical issue that can only be evaluated during a static fire is acoustic signatures.  SpaceX will have very good data on the acoustic signature of a good rocket, and any deviation from that signature will signify a potential problem. The sound turns out to be one of the best predictors of good health and one of the earliest indicators of a pending failure.  Certainly, with Raptor's we heard bad things sometimes before one sees bad things.   So getting an acoustic signature would be one of the things I as a systems engineer would be looking for.

[mulp]

Why isn't it everything before and after lighting and shutting down the engines?