[AR] Re: looks like a bad day

  • From: Bill Claybaugh <wclaybaugh2@xxxxxxxxxx>
  • To: "arocket@xxxxxxxxxxxxx" <arocket@xxxxxxxxxxxxx>
  • Date: Thu, 23 Jul 2015 07:14:36 -0400

A larger problem with ISO is that it simply embeds whatever practices happen to
be in practice at the time it is adopted; far to many aerospace organizations
fail to seek out and adapt best practices in part because ISO offers the
appearance of order.

Bill

Sent from my Commodore 64

On Jul 22, 2015, at 8:09 PM, Paul <paul.britton@xxxxxxxxxxxx> wrote:

Basically, that is the flaw in the ISO 9001 quality system.... you are
relying on your suppliers QA/QC systems, to deliver you components that
conform to specification with a C of C (Certificate of Compliance)..... but
the liability for failure is usually limited to cost of the supplied
components.... not the incidental loss.
Most if not all European companies are now using ISO9001, and have largely
dropped Goods In inspection and test...

Paul

On 20/07/2015 22:11, Nels Anderson wrote:
So SpaceX will no longer rely on the manufacturer's certification for
these struts and will test each.

For a few struts, that's probably not a big deal. But might SpaceX be
relying on certifications of many other components too?


On 07/20/2015 09:09 PM, Henry Vanderbilt wrote:
Further detail: One steel holddown strut per He bottle, QC via
material cert from external vendor, visual inspection, and ~3x design
margin, thousands of such struts flown previously. Strut design limit
is ~10Klbf pull, max expected load ~3-3.5Klbf, actual failure at
~2Klbf. Testing of on-hand inventory went through very large number
before finding one that failed at <2Klbf; check on that revealed bad
metallurgy. Immediate fix is a new-design strut, to be individually
pull-tested.

To emphasize, this is a preliminary conclusion. Final results will
need signoff from all interested parties and won't be for a while.

Gotta go do some less hasty writing now...

Henry

On 7/20/2015 1:02 PM, Henry Vanderbilt wrote:
And the (probable, not final) winner is, a failure in a support strut
holding an He bottle *down* against buoyancy in the LOX. Bottle then
apparently shot to top of tank, releasing enough He to overpressure the
tank and cause the failure.

On 6/29/2015 7:36 AM, Henry Vanderbilt wrote:
This strongly implies there was no clear cause in the data before the
final milliseconds, which rules out a whole class of things that might
gradually overpressure the second stage LOX tank: Frozen
pressure-relief
valves, a stuck-on helium regulator, a heat source boiling the LOX.
(Come to think of it, the latter two would also require stuck-closed
pressure-relief valves.)

As for overpressure sources that split a tank within milliseconds of
onset, the first thing that comes to mind is a failure under flight
loads in the high-pressure helium storage bottles-plus-plumbing
submerged in the LOX tank.

A second possibility is some sort of ignition inside the tank - EG,
something breaking loose and scraping an aluminum surface, or a
brace or
baffle cracking, so a significant area of unoxidized aluminum is
suddenly exposed to LOX.

A distant third would be detonation of just that tank's segment of a
flight-termination linear shaped charge. (That assumes the charges are
in separate segments; I couldn't find a detailed description of the
system.) (Note that any such detonation would not likely have been
commanded - I can think of no reason to design in the ability to
separately command local charge segments in such a system.)

A secondary implication of "final milliseconds" is that whatever
happened was violent enough to stop data transmission from the
stage, or
at least from the relevant parts of the stage.

Mind, a crack developing in the tank outer skin under flight loads then
unzipping rapidly would also explain the results - it just wouldn't
explain the statement about an "overpressure event".

On 6/29/2015 6:12 AM, Ian Woollard wrote:
*Elon Musk* ‏@*elonmusk* <https://twitter.com/elonmusk> 5h5 hours ago
<https://twitter.com/elonmusk/status/615431934345216001>

"Cause still unknown after several thousand engineering-hours of
review.
Now parsing data with a hex editor to recover final milliseconds."






Other related posts: