Re: What was the biggest problem for each of the 2 destroyed US space shuttles?

From: rk (stellare_at_nospamplease.comcast.net)
Date: 09/14/04 

Date: Tue, 14 Sep 2004 01:49:12 -0500

Jay Windley wrote:

>
> "rk" <stellare@NOSPAMPLEASE.erols.com> wrote in message
> news:Xns9562E9CE4AB01rk@216.196.97.136...
>| Jay Windley wrote:
>|
>| > In terms of engineering you have the normalization of deviance...

<restoring context>

> In terms of engineering you have the normalization of deviance, which is
> the buzzword for progressively accepting a broken situation as normal and
> safe. If you hear your car making a knocking noise, but it continues to
> work, you know abstractly that there must be something wrong with it.
> But it continues to run so you don't think much of it and you gradually
> come to believe it's okay to operate it in that condition. It's only
> when it quits working that you equate that failure back to the early
> warnings.

</restoring context>

>| Perhaps that's the way you make judgements. I don't and many others
>| don't. And that's not a standard policy in aerospace where root cause
>| analysis and worst-case analyses are standard policy.
>
> Yes, I agree.

Now you're contradicting yourself.

> In the case of SRB failure analysis, I don't believe the
> root cause analysis and worst-case analysis went far enough.
>
> The root cause for erosion and blowby was never traced back to the
> unexpected joint rotation. That is, it was never considered serious
> enough to stop flying while the rotation was corrected in order to make
> the joints behave as expected.

   It is my honest and very real fear that if we do not take immediate
   action to dedicate a team to solve the problem, with the field joint
   having the number one priority, then we stand in jeopardy of losing
   a flight along with all the launch pad facilities.

Roger Boisjoly, July 31, 1985, in a memo to the MTI Vice President of
Engineering.

    < snip -- paste back in if you feel it is real important >

> Thiokol went to their O-ring subcontractors and asked whether joint
> rotation and O-ring extrusion would still work. The subcontractor said,
> basically, you guys go out and test it and make sure you know how the
> O-rings behave in your specific application -- we can't help you.
> Thiokol went to conventions with seal experts and asked the same
> questions and got the same basic answers: test it yourselves and rely on
> your developed in-house knowledge.

What they saw was a configuration an order of magnitude worse than anything
that they saw before. It was most certainly not a ringing endorsement.

> We do this at my company too. We have all the data sheets for all the
> components that we use. We also do our own testing to see how these
> components behave in our specific applications. The original
> manufacturers don't necessarily care about our application and don't
> necessarily provide appropriate testing. We have three engineers whose
> sole job is to accumulate in-house expertise on stuff we get from
> vendors.

Most vendors who sell components into aerospace will state quite strongly that
if you attempt to test and characterize the components outside of the data
*** limits and outside of their test conditions then it's "son, you're on
your own." And that's not just a CYA, it's based on sound engineering
principles, data, and analysis.. Your strategy of characterization by
symptoms is a dangerous one, as we recently saw on February 1, 2003. What you
are describing as standard practice is very scary to me.

>| I would expect that the Shuttle is designed to requirements
>| and specifications. Not that the requirements and specifications are
>| written based on observed behavior.
>
> That is my expectation too, but it's more accurate to summarize my belief
> by saying that the day-to-day operation of a complex technology is
> governed more by information gleaned through experience than by the
> original specifications and pre-established rules. Yes, I'll provide a
> citation for this too. It's essentially the whole basis for the system
> of launch constraints and waivers at NASA. These mechanisms are designed
> to make problems visible so that they can receive the proper attention.

This is one that I most certainly would like to see. Violating requirements
and specifications is an action that must be done with *much* care. Your
discussion shows repeatedly a pattern of seeing what happens and going with
it, operating on the symptoms. This is also consistent with your test and go
strategy described above. It's also what led to the recent Shuttle loss. So,
I'd like to see your documentation on this for how NASA engineering is
supposed to work.

Note that when things do not operate per the specifications, requirements, and
analyses, then changes are to be made. A change may be in any one of a number
of forms.

>| And I'll for a cite for this theory of yours that there is no
>| pre-existing sense of right, wrong, safe, or broken for anomalies for
>| the Shuttle.
>
> I think you're asking me for a citation here as well, and I'll provide it
> when I have my library handy. But I think you're going a bit farther
> with the statement than I perhaps intended, or perhaps I'm going too far.

I think you're going too far, in my opinion.

> You still have the original requirements and expectations, and they
> still have value, but they are examined and perhaps modified as new
> information about safety and behavior becomes available.

That's different then what you stated above. You're diffusing again.

                    < snip a bunch of words >

>| Here's an interesting example and perhaps make this post worth
>| reading, from Ken Iliff's _From Runway to Orbit_:

where did it go? context????

 
> Fascinating reading; thank you. I don't mean to suggest that all
> deviance is or ought to be ignored. But I believe that in some cases it
> is, and the rationales given for re-evaluating expectations is often
> spot-on, and often short-sighted. If something goes contrary to
> expectations, you seek to understand that anomaly -- characterize and
> quantify it.

You're diffusing again. I'm totally lost.

 
>| > Institutionally you also have the complacence of some who rely on that
>| > past experience as if it were some sort of Bible. The managers around
>| > Challenger were complacent because the engineers had assured them
>| > everything was under control.
>|
>| No, the engineers and SRB manager were telling them not to launch.
> Period.
>
> I think we're talking about two different time frames. From 1978-1985,
> when the SRB joint was exhibiting various forms of improper operation,
> everyone involved with the joint was assuring those in charge that
> although anomalous, the joint behavior was well enough understood that it
> did not pose a flight safety issue and that a sufficient safety margin
> still existed even in the face of blow-by and erosion.
>
> Then the eve of the launch, the recommendation was not to launch based on
> an argument that turned out not to be supported by the data Thiokol
> presented. I sense that the difference in perception was less about the
> fact that Thiokol had reversed their opinion and more about the fact that
> Thiokol had shifted from a long-standing and carefully rationalized
> position to one that was purely emotional and was actually
> counter-indicated by the data.

No. It was not purely emotional. It was not counter-indicated by the data.
And it was not thrust on NASA as a new mechanism at the last second.

And even if it was, when you have the head engineers of the project along with
the manager for the solid rocket motor telling you emphatically not to launch
in record cold temperatures, you don't ignore them. Period.

> Something seriously broke the eve of the launch. I can't deny that. But
> I think it *began* breaking years before that night, as launch after
> launch was approved in the face of a joint that was clearly not behaving
> as it should. I want to examine those elements of the decision too
> because I think they tell a more useful story about how to make space
> travel safer.

But that is not what this discussion is about, it's just a diffusing class or
argument.

Everyone knows that the problems began at the very first test, many, many
years ago, nothing new and nothing very profound there. 

-- 
rk, Just an OldEngineer
"Engineers abhor extrapolation"
-- Ken Iliff, from _Runway to Orbit_, 2004
Quantcast