Boeing new issue with 777X engine support

[Bev D]

To address Sydney’s point: good they are being transparent. But that isn’t proof they ahve fundamentally changed. Just a few months ago in May they were transparent about a leak on the Stalingrad and postponed the launched. And then they fell back one of the oldest rationalizations ever: it was an isolated incident. Of course when they got the starliner up into space it wasn’t an isolated incident at all. Now they are saying that they replaced the part and continued with testing. Maybe this is just a time saver to wring out other defects while they investigate the cracked strut. Maybe it’s a path to yet another ‘isolated incident’. Boing didn’t do a good job either the causal investigation of the starliner leak, why should we think this one will be different? Yes here are enormous cost consequences to gettign wrong but that ‘maybe’ hasn’t stopped them before. It’s like your husband saying really I’m not going to do it again for 20th time. I want it to different but until they demonstrate that why have actually changed it’s all just words.

 

[Wes Bucey]

To address Sydney’s point: good they are being transparent. But that isn’t proof they ahve fundamentally changed. Just a few months ago in May they were transparent about a leak on the Stalingrad and postponed the launched. And then they fell back one of the oldest rationalizations ever: it was an isolated incident. Of course when they got the starliner up into space it wasn’t an isolated incident at all. Now they are saying that they replaced the part and continued with testing. Maybe this is just a time saver to wring out other defects while they investigate the cracked strut. Maybe it’s a path to yet another ‘isolated incident’. Boing didn’t do a good job either the causal investigation of the starliner leak, why should we think this one will be different? Yes here are enormous cost consequences to gettign wrong but that ‘maybe’ hasn’t stopped them before. It’s like your husband saying really I’m not going to do it again for 20th time. I want it to different but until they demonstrate that why have actually changed it’s all just words.

Yep, Bev, Bouing is infamous for "exaggerating its rigor" in performing root cause investigations. We hear about it because it's a giant company with disastrous mistakes which make world-wide headlines, BUT its mentality of "stop investigating once we have a plausible cause" is echoed in hundreds, maybe thousands of organizations around the world. If I hear Occam's Razor raised in a Quality meeting, I know the ensuing investigation will be perfunctory and fail to be rigorous enough to arrive at a true "root cause," only an intermediate one.

.How many of you would accept "isolated incident," as a root cause if your own life, health, safety were on the line?

 

[Randy]

How many of you would accept "isolated incident," as a root cause if your own life, health, safety were on the line?

It can happen, been there done that.

 

[Ed Panek]

“Boeing.” The sound made by airplane parts falling off of its aircraft

 

[Ronen E]

Presumably... this part already went through the review as described by @Ronen E ... and since the question was "how to investigate", not "how to implement design controls", I don't think my response is "hair-splitting".

Good discussion.
By "hair splitting" I wasn't referring to the recommendation itself, but to the description (using other words) that to me amounted to a recommendation to replace the design team whilst saying that "this is not replacement". I apologize it you got offended.

To the point - Yes, "how to investigate", not "who will investigate". This reminds me a half-joke saying that the definition of "politics" is "when it matters not what is being said, but who says it."

With reference to design controls - from the outside (and I assume we are all outsiders in this case) it looks like not much has gone / is going wrong with the design control process here. It's perfectly normal to have a healthy design control process and still end up with technical failures in validation testing. It doesn't attest to a breakdown in the process or to lack of talent, diligence, rigor or else on the the participants' part. This is a (very) high end, demanding application, and this is exactly why validation testing is needed (without making design reviews etc. not needed - both are necessary). It's just the way it is. So from the fact that such a tech failure occurred I would not hurry to draw any conclusions regarding the competence or attitude of the design team, or take any operational action. I would simply go for the next iteration in the cycle. If a pattern started to emerge (repeated failures), I might; but not on the first instance and possibly also not on the second. Designers should work free from fear and undermining. It's exactly that state of mind that "everything has to work right the first time" that kills good design (and a healthy design process) and usually ends up in overkill (which is not always safer). I know it sounds counter-intuitive, but I found it to be true.

I'm not going to apologize for suggesting that the design team responsible for a design which has failed be directed towards investigating the non-design issues (e.g. supplier controls) while a fresh pair of eyes is directed towards the design output. It's not as if stresses in metal parts are black magic. Perhaps others' experiences are different, but my experience with many engineers (and business unit managers) is that the default opinion is "someone else did something to my perfectly specified part that caused it to fail", so direct those people in a method aligned with their instincts.

No apology is required... we are having a discussion.
Again, my point it that this seems to be very normal. The original designers usually have a huge head start on anyone that will try to jump in, so it doesn't make business sense to "gently push them aside" at the first bump in the road. If it becomes a pattern, yes. But such tech failures are not a breakdown of the system, and the right thing (IMO) is to let it pan out. They probably already know how to fix it. Someone else will need to reinvent the wheel.

Now, categorizing this as "stresses in metal parts" is oversimplification and is not doing justice with the designers. This is not run of the mill (literally) carbon steel. Heck, I don't even know what material it is. Do you? Second, this is a dynamic, non-linear for sure application. This is the stuff that people get PhD in mech eng about. This is the stuff that is simulated on a super computer for a week per design iteration. It's not like some arrogant engineer jotted it down in 15 minutes and is now playing politics to defend their hurt ego. Yes, there is a political/psychological aspect in every business venture, but in this case I would not hurry to give it centre stage. Proper design control has the tools for dealing with personal pride. Keyword is proper; if that's not the case no amount of personnel shuffling will help.

 

[Ronen E]

How many of you would accept "isolated incident," as a root cause if your own life, health, safety were on the line?

Sorry, but I don't understand. "Isolated incident" is a qualifier (which may or may not be true), but how is it a root cause?

 

[Randy]

Sorry, but I don't understand. "Isolated incident" is a qualifier (which may or may not be true), but how is it a root cause?

It's not, it's a deflector, smoke & mirrors.

 

[Wes Bucey]

Yes, Ronan, Randy understood. GM used it after the first few Corsair incidents while they scrambled and maneuvered for a political and economic solution behind closed doors until Nader's "Unsafe At Any Speed" caught them with their pants down. Like it or not, the bean counters get a say in root cause investigations, if not physically present, they certainly are psychologically present.

Sorry to say, most business consultants recognize their influence and the fears they provoke which give night terrors to the suits in the executive suite.

 

[Tidge]

Now, categorizing this as "stresses in metal parts" is oversimplification and is not doing justice with the designers.

Oversimplification of this (earlier in the thread) post?

Contrary to common belief, cracks are usually not the result of insufficient strength for an ordinary applied load. If that was the case, it would have been a ductile failure (deformed part). Rather, they are typically the result of a material flaw or irregularity at the microscopic level, and can be promoted by environmental conditions. The main problem with cracks is that their behaviour is unpredictable (despite our best science and research) and they will typically propagte sooner or later, until they reach a critical length, then quickly lead to macroscopic failure.

If my "stresses..." is too simplistic to begin the most rudimentary FMEA, I apologize. I'm not in a position to armchair the design, but I do feel qualified to offer suggestions for paths of investigation. My original suggestion was to find out from the original engineers why they thought this sort of commonly anticipated failure mode would not happen.

It is IMO a huge, and likely very wasteful, exercise to build a fleet of airplanes or orbital modules to test if the fundamental design doesn't work (e.g. engines/thrusters fail). A well-functioning design controls process should result in an airplane that both flies and meets minimal reliability goals. I'm getting the feels that the Boeing Engineers are somehow allowed to not know if (or have confidence that) the planes will fly (safely or not) until after some sort of testing of a completed airplane/spaceship.

 

[Sidney Vianna]

It is IMO a huge, and likely very wasteful, exercise to build a fleet of airplanes or orbital modules to test if the fundamental design doesn't work (e.g. engines/thrusters fail). A well-functioning design controls process should result in an airplane that both flies and meets minimal reliability goals. I'm getting the feels that the Boeing Engineers are somehow allowed to not know if (or have confidence that) the planes will fly (safely or not) until after some sort of testing of a completed airplane/spaceship.

So, basically you are advocating that ANY design that is not 100% perfect is a bad design, ignoring the fact that many of the envelope conditions a design engineering team are not always perfectly defined. Have you ever heard that saying perfect is the enemy of good? Have you ever thought that, according to your mind set, SpaceX would not have achieved hundreds of successful reuses of booster rockets? Simply because the initial attempts failed badly?

I think you need to rethink an approach the design and development of highly complex systems as a last generation commercial widebody aircraft. If we were to follow your approach we would think that the whole program of test flights for regulatory approval is a wasted effort. Had the 737 Max test flight program been more comprehensive we might had avoided the two crashes.