3 ms·

Some counter-points: 1) The failures themselves aren't all too complex (relatively speaking), and by the time the design made it to a flight vehicle it has bee

Some counter-points: 1) The failures themselves aren't all too complex (relatively speaking), and by the time the design made it to a flight vehicle it has been vetted for all immediately knowable risks. The rest you discover during flight. And even then the actual nature of the problems rarely (if at all) are esoteric or present breakthrough scientific discoveries. 2) Failure in rocket launches are catastrophic leaving behind very little evidence. There could be a limit to how much you can learn. But... 3) ...SpaceX is a business serving customers, and if a pivot means going away from a complex cloud of possible failures (known and discovered) to more robust, more deterministic, more reliable, you should do it. 4) At what level do you stop and go "this is fundamental enough"?

bumby 3y ago
I think I disagree on many points here in this specific case. >The failures themselves aren't all too complex The COPV failure mechanisms may not be terribly complex (e.g., voids or delamination), but managing the processes to mitigate them isn't. >by the time the design made it to a flight vehicle it has been vetted for all immediately knowable risks. SpaceX has already shown some bad processes that disprove this statement. E.g., the strut failure was due to poor supplier quality control, which is a relatively mature process in the industry. I'd give them the benefit of the doubt and say they've gotten better as they've matured as a company. Failure in rocket launches are catastrophic leaving behind very little evidence. The difference, I think, is that you are constraining this to launch failures. I'm talking about knowledge and data about individual component failures, from which you can derive the overall reliability of the design. if a pivot means going away from a complex cloud of possible failures (known and discovered) to more robust, more deterministic, more reliable, you should do it. I don't disagree that more simple tends to be more reliable. However, the point was that iteration doesn't necessarily advance knowledge of failure. I think these two points are not mutually exclusive. A good business case doesn't mean it makes for good engineering or good science. At what level do you stop and go "this is fundamental enough"? It's a tough question. But if you can't characterize why a failure mode occurred reasonably well, that's probably not good enough. So if they say, "We know voids in the COPV manufacturing process contributed to the failure" they should probably make sure they have a good understanding of why they occurred. (And maybe they have at this point)

bumby 3y ago

I think I disagree on many points here in this specific case. >The failures themselves aren't all too complex The COPV failure mechanisms may not be terribly complex (e.g., voids or delamination), but managing the processes to mitigate them isn't. >by the time the design made it to a flight vehicle it has been vetted for all immediately knowable risks. SpaceX has already shown some bad processes that disprove this statement. E.g., the strut failure was due to poor supplier quality control, which is a relatively mature process in the industry. I'd give them the benefit of the doubt and say they've gotten better as they've matured as a company. Failure in rocket launches are catastrophic leaving behind very little evidence. The difference, I think, is that you are constraining this to launch failures. I'm talking about knowledge and data about individual component failures, from which you can derive the overall reliability of the design. if a pivot means going away from a complex cloud of possible failures (known and discovered) to more robust, more deterministic, more reliable, you should do it. I don't disagree that more simple tends to be more reliable. However, the point was that iteration doesn't necessarily advance knowledge of failure. I think these two points are not mutually exclusive. A good business case doesn't mean it makes for good engineering or good science. At what level do you stop and go "this is fundamental enough"? It's a tough question. But if you can't characterize why a failure mode occurred reasonably well, that's probably not good enough. So if they say, "We know voids in the COPV manufacturing process contributed to the failure" they should probably make sure they have a good understanding of why they occurred. (And maybe they have at this point)