SpaceX Loses Rocket Engine During Qualification Test
Merlin 1D test firing (Credit: SpaceX)
Some news out of the SpaceX engine test center in McGregor, Texas.
SpaceX is investigating why one of its rocket engines exploded during a test fire earlier this week at the company’s facility in Texas, the company confirmed Wednesday.
The explosion of the Merlin engine occurred Sunday during what the company called a “qualification test.” No one was injured, but now the company founded by tech entrepreneur Elon Musk once again has to figure out what went wrong with its hardware, as it suspends engine testing during the investigation.
The company said Tuesday in response to questions that it is “now conducting a thorough and fully transparent investigation of the root cause” of the explosion. “SpaceX is committed to our current manifest, and we do not expect this to have any impact on our launch cadence.”
SpaceX has conducted 16 successful launches of the Falcon 9 this year. There are five more flights on the manifest for the rest of 2017.
Remaining SpaceX Launches for 2017
11/15/17: Falcon 9 — Zuma — KSC
12/04/17: Falcon 9 — CRS-13 — CCAFS
December 22: Falcon 9 — Iridum Next 31-40 — Vandenberg
December: Falcon 9 — Hispasat 30W-6 — CCAFS
December: Falcon Heavy Demo Flight — KSC
46 responses to “SpaceX Loses Rocket Engine During Qualification Test”
Leave a Reply
You must be logged in to post a comment.
A.K.A qualification program value demonstration event.
There was an engine loss in flight once–but engine out saved it.
Yes
I’m kinda thinkin’ that an event that generates a month or two of repair work to a test stand (not exactly a delicate environment) is probably one that would be sufficiently uncontained to take out multiple engines, if not just tear the ass end of the vehicle off.
This happened during a “LOX drop” test where LOX is sent through the engine to look for leaks. This is quite unlike an actual engine firing, so I would think comparing the violence of this event to an in-flight event is an apples to oranges comparison at best.
A LOX drop sounds an awful lot like an engine chill-in, which is exactly like an actual engine firing.
It’s not at all clear yet whether this was truly a failure of the engine, or a failure of the test which resulted in the destruction of an engine. If some sort of mechanical failure of the test stand equipment or human error botched the test, that’s not the fault of the engine.
That’s obviously true. And if you insist on whistling past the graveyard, feel free.
Actually the problem was with the test stand, not the engine. Since the engine was in no way at fault, “whistling past the graveyard” doesn’t seem to apply here.
https://www.nasaspaceflight…
Good to know. Thanks.
“qualification program value demonstration event”
Definition, please?
My understanding is that “qualification testing” = “doing design verification work”. “Acceptance testing” = “verifying that a production engine is ready to be put on a vehicle”.
If they’re having problems with a Block V uprating feature, that’s at least a medium deal, and will likely have an impact on CCtCap schedules.
It means that if we never saw problems there would be no value to qualification program in the first place. Qualifying the new design should be rigorous, exposure to all the corners. If that leads to a failure on the stand, that shows value in the qual program. I agree, depending on the failure, it may impact block 5 schedule.
Apparently, it was a Block 5 engine.
OK, a learning experience! And in the best place possible, on a test stand.
My thought exactly. Better on the test stand than on a launch. The fact that SpaceX tests their engines before putting them on the stages, and then they test fire the entire first stage is a good thing. Reusable engines are a good thing because they enable this sort of routine testing.
Slightly more info here:
That’s a bit odd. If they’re qualifying an up-rated design, then presumably it’s for Block V, and that definitely would have an impact on the CCtCap launches. They can probably juggle some existing Block IV’s to keep non-crew payloads on schedule, but they absolutely can’t do that for the crewed stuff or the pre-crew test articles, which mandate Block V.
Actually all the F9 FTs are designed to be able to be human rated, however the Block 5 is scheduled for April, if they figure out what went wrong and fix it in 5 months they are fine
At this point, there’s a big difference between being able to be human rated and actually being human rated. Try to imagine NASA’s reaction to SpaceX proposing, “Hey, you remember those block V engines? Never mind about them–how ’bout we just swap in some block IV’s?” Remember: we’re talking about a hugely risk-averse organization, whose funding depends in no small part on a bunch of congresscritters who’d like nothing more than to see SpaceX get hobbled for a while.
Other outlets are now reporting that the accident occurred during a leak test where they dropped LOX through the engine, not an actual firing. I don’t know if that’s better or worse. If they were doing something funky that would never occur operationally, the amount of paperwork on the critical path might only amount to a couple of weeks. But if the test uncovered some kind of vulnerability with the Block V’s, NASA’s not going to let them put crew on until they’ve seen a complete mitigation plan for the risk.
its probably a “someone goofed during the leak test” issue,
Yes, but was the goof something that cuts into a failure tree that could originate in a real launch-ops event?
Doubtful and we test so that we can find and correct any problems, the block 5 is scheduled for April, so they have plenty of time to make sure it doesn’t happen in a real launch, hence why they are doing these tests now so they don’t have to delay their launch schedule, they already figured out what happened, it isn’t like in September of last year where it took them a while to figure it out, and the F9 returned to flight after that in 3 and a half months roughly
Now that the problem is surfaced, it’ll have to be addressed through whatever defect management system NASA is in place, until it’s closed out. Given that SpaceX has already decided to suspend qual testing until they understand the failure tree, and engine qual has to be, if not the critical path, at least close to the critical path, there’s some point at which the close-out of this defect will start to cause a one-for-one schedule slip.
I can think of a couple of serious operational failure trees that could root off of a problem like this. The first is that a LOX drop can’t be a whole lot different from an operational engine chill-in, which is something that must occur with crew on the vehicle. The second is that oxygen doesn’t cause fires: oxidation does, which means that some oxidizable substance was present in the oxidizer path. That’s something that NASA’s going to want to know aaaalllll about.
For comparison, the SSMEs were a lot more “sketchy” when STS-1 was launched than Merlin is today, IMHO. It took many more years and a lot of tweaking to the design to get the SSMEs to be as reusable as Merlin has been on the Falcon 9 first stage reflights. I’m pretty sure Merlin isn’t torn apart completely after each flight like the SSMEs were during the early part of the shuttle program.
Yes, and SSMEs are also one of the reasons why NASA instituted substantially more stringent requirements on probability of loss of crew.
Agreed, but only after the Challenger disaster. Until then, NASA management was quite content with the “business as usual” attitude that kept the shuttle flying despite the mounting evidence that several systems weren’t as safe as they were originally indented.
No. PLOC for CCtCap is much more stringent than any of the requirements placed on any phase of the Shuttle program.
The fact in the matter is, this was a test, the best time for failures to happen and it’s an environment designed and set up to gather as much data on such “failures” as possible, as such the only true failure conditions in a test environment are someone getting hurt and if something goes wrong and relevant data is not collected, relevant data was collected, data that likely would not have been collected if nothing went wrong and no one was hurt so in rocket testing that is a huge success.
You’re completely missing the point. Yes, it’s good to find stuff in testing–obviously! But the fact remains: qualification testing surfaced a problem that resulted in an uncontained engine failure. That’s a critical defect. It has to be resolved and closed out before qualification is complete.
It is entirely possible that the resolution to this defect is “operator error of a type that could only occur as a result of weird testing”. It’s possible that the resolution to this defect is “manufacturing problem that will always be caught in acceptance (not qualification) testing”. But it’s also possible that the resolution will require some kind of re-engineering of the the Block V engine. I’d put the probabilities of those three categories at about equal right now.
Four and a half months.
Miscalculated but that was also a very different issue no one had seen before
That’s assuming Block V is the gating item for CCtCAP schedule, which is probably not the case. Current rumor is Block V is less than 5 cores away, which means the CCtCAP schedule is mainly determined by progress in Dragon 2, not Falcon 9.
That pretty much changes by definition if there’s a critical fault in the engines, don’t you think? It doesn’t matter how many cores you make if the engines aren’t NASA-certifiable for crewed flight.
This could easily be nothing more than test operator error. It could also be a large amount of operator error that aggravated a real but low-probability fault. NASA doesn’t like the latter.
So long as the engines don’t RUD, with the F9s engine out capability, it should still be certifiable
First, if there was a month or two of damage to the test bay, then the engine had an uncontained failure, which pretty much qualifies as a RUD. Second, if the probability of an engine failing is high enough, NASA doesn’t give a damn about being OK on 8 engines–it’ll exceed their PLOC requirements and they’ll demand a fix.
On the test stand you push the equipment to it’s limits and beyond, you don’t shut down because it is the one environment where you want to expose all possible faults, as such even if the engine control computers could have stopped it, they could have been intentionally instructed not to, just like how when you pressure test any sort of pressure vessel like a fuel tank you push it past it’s expected limits to find out where it’s limits and potential failures are
But a LOX drop isn’t “pushing the equipment to its limits”. It’s merely a basic leak test.
True but rather find the problems now than later
Of course. But that has nothing to do with the fact that a critical defect is now in the system and will need to be resolved before qualification is complete.
Not the first time they have gone through this process, they probably planned in the event that they would have something to fix in this qualification test when scheduling it and the in flight abort for dragon 2
Probably just means that they have to pull people off BFR development for a little bit
If you look at the Block 5 as an upgraded FT, which is what it is, and consider the FT has the structural and engine out requirements for human rating it makes little sense for each iteration of the same vehicle to need retesting, the main concern is that the crew survives if something goes wrong which comes down to the Dragon 2 spacecraft
NASA doesn’t look at a Block V as an upgraded anything. They look at it as a vehicle configuration that needs qualification for human flight. Currently, that vehicle has a known critical defect. End of story, full stop. If the resolution of that defect requires reconfiguring with Block IV engines, then it’ll have to be qualified in that configuration, which will likely be a bigger hit to the schedule than closing out the defect by identifying the problem on the Block V engines and fixing it.
Also consider, most of the near future launches can be satisfied with flight proven hardware due to the industry’s acceptance of recovered F9s and they may already have a good idea of what went wrong and how to fix it, really meaning that they planned for the event of something going wrong. Also consider if you take all the remaining block 3s from the standard f9 launch lineup, all the landed block 4s realistically have at least 1 relaunch in them, the 4 remaining new block 4 cores have a realistic total of 8 launches outside of the crew launches and in flight abort test, that covers about 20 f9 launches, back of the envelope estimate, before needing another new core,
My concern is only directed towards the CCtCap flights.
http://spacenews.com/spacex…
“The incident, according to the source, took place not during an
actual engine firing but during a troubleshooting activity called a “LOX
drop” where liquid oxygen is flowed through the engine to look for
leaks. It wasn’t clear how this test led to the anomaly that damaged the
engine and its test bay.”
Sounds a lot less dramatic than the WaPo article’s “one of its rocket engines exploded during a test fire”.
All you need to know: WaPo = Bezos News Network. Anti-SpaceX “consultant” op-eds in 5, 4, 3….
After reading a series of articles it sounds like a LOX fire. Which with my limited experience comes from cleaning or handling issues. Unless there are design changes and something like angle changes in the plumbing are too sharp and causing ignition of the pipe material during initial flow of the LOX.