Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

Boeing pilot involved in Max testing is indicted in Texas

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

Boeing pilot involved in Max testing is indicted in Texas

Old 28th Mar 2023, 03:52
  #241 (permalink)  
 
Join Date: Oct 2018
Location: Oka
Posts: 43
Received 10 Likes on 3 Posts
Originally Posted by tdracer
The people who create the software are not the ones who define the requirements - in aviation they seldom are even in the same company.
That's why it's so critically important to get the s/w requirements correct.
The requirements did not consider what would happen if MCAS kept trimming the nose down, because it was assumed early in the design process that if the stab trim was doing something the pilots didn't want or understand, they'd turn it off. Hence the classification of inappropriate MCAS activation as only Major - that's what a stab trim malfunction was classified as.
As I noted previously - the entire MCAS mess grew from that flawed assumption that an issue with MCAS was no worse than Major.

I will stop after this but Iím not having it.

Requirements always come from somewhere else. Thatís not special.

You donít take a stupid requirement.

You donít expect a civil engineer to take a stupid design from an architect. Seldom the same company.

You donít expect the engine manufacturer to take a dangerous design from the airframe manufacturer. Not the same company.

The fact that it comes from a different place does not relieve your responsibility to understand and interpret it.

There is no universe, regardless ALL the things you said, in which commanding AND indefinitely forever makes sense. Itís fundamentally stupid.

No.
Bbtengineer is offline  
Old 28th Mar 2023, 10:24
  #242 (permalink)  
 
Join Date: Aug 2005
Location: EDLB
Posts: 353
Received 1 Like on 1 Post
You can use the same cheese hole analogy here. When you figure out as software or test engineer, that assumptions do not hold water, you don't wait for two passenger planes to spear in. Unless the companies quality philosophy is completely broken. And that fish starts stinking always from the head too.
EDLB is offline  
Old 28th Mar 2023, 11:33
  #243 (permalink)  
 
Join Date: Oct 2019
Location: USA
Posts: 731
Received 112 Likes on 56 Posts
One document that seems not to have escaped and may not have appeared at the Congressional show trial was the one that specified MCAS behavior. From what I can tell that document would have been sent to Collins Aviation to develop the FCC software for the computer they supply to Boeing.

Others are certain Collins refused the "bad" specification and forced Boeing to develop in-house.

The truly deranged think Boeing outsourced to $9 an hour developers in India. Sigh.

There should not be anything competition-critical in that document and it should have been made, unredacted, a matter of public record. There should also be a documentation trail for acceptance testing and, of course, a comparison between what was required and what MCAS actually did.

This thread has drifted away into the Certification thread territory and has left the indictment of the pilot topic.
MechEngr is online now  
Old 28th Mar 2023, 17:47
  #244 (permalink)  
 
Join Date: Jul 2003
Location: An Island Province
Posts: 1,252
Likes: 0
Received 0 Likes on 0 Posts
The biggest assumption about communication is to assume its taken place

Many discussions use acronyms, but not everyone has the same understanding in their use.
MCAS - refers to a system (S), but the extent of that system may not be given explicitly.

Normally a system is bounded by input, activity (computation) and output, together with monitoring / verification of input(s) and feedback.
Thus a failure of an input sensor could cause the 'system' to malfunction, without reason, if the the design of the activities, output, and feedback are weak. A more robust system might identify internal errors and provide external alerting (MCAS FAIL), reduced the need for human reasoning.

A core issue relating to this thread is the human involvement;

- The assumptions about the operator's ability to detect a system malfunction and act; which relates to the hazard level in certification - which drives the design.

- The defined the piloting task when assessing the assumptions in certification is critical.
Does the design simulator represent the final design.
Is the task constrained to the specific system (MCAS), or the wider context involving other aircraft systems and alerts associated with an input failure; realistic operational context.
Who assesses the task, are the findings widely communicated.

Endless prior discussion suggests weaknesses in all of these areas, and those of other human checks and oversight.

Considering the Big System - specification, technical and commercial, the design, engineering, testing, certification oversight, documentation, training, all involved weaknesses, which independently could have been identified, but when together, the system complexity defied the process which existed.

Neither an individual nor team, group, organisation should be cited. This was a systemic failure, a failure of the aviation process.
Responsibilities can be attributed, but more often these involve a legal viewpoint.

Dr. David Woods discussing automation surprise, learning from incidents and complexity surrounding the Boeing 737 Max.

“...The industry has to stop rationalising away the lessons from accidents - the difficulties of learning after accidents have occurred are profound. It is easier to look at each event in isolation seeing only the specific details that define a narrow set of changes needed to facilitate a return to normal. But this narrow focus on one accident at a time makes it easy to discount the fundamental common vulnerability that needs to be addressed as an industry-wide priority. Neither the regulators nor the safety organisations have been able to recognise this critical vulnerability nor have they been able to energise a coherent, fundamental approach to overcome this vulnerability.”

i.e. we, the industry, are still at risk of an accident from design and certification processes; the continuing task is to minimise this risk.

"Attempts to prevent pilot error by additional regulation, both federal and corporate, have increased the complexity of the environment and increased pilot (design, engineering, test, certification) workload."
alf5071h is offline  
Old 28th Mar 2023, 18:05
  #245 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Bbtengineer
I will stop after this but I’m not having it.
Requirements always come from somewhere else. That’s not special.
You don’t take a stupid requirement.
I see this problem as related to computer architecture, how the computers are connected, and the lack of an EICAS display unit.

The problem is that the B737 was designed at a time when there was no computers in the aircraft.
Problems was indicated by lamps. if you want to indicate a new issue, you need to install a new lamp, and hard-wire it into the master caution.
The instruments and autopilot for left and right side was intentionally separated.

The fault insulation is manual, you disconnect whatever is needed to be disconnected (AP, AT, Trim switches) and then compare instruments to locate the problem.

If you start comparing values in software, you run into the problem of how to display the fault information.
The PFD can display some information, but it will newer be a real EICAS, it will be difficult to indicate multiple issues at the same time.

If the software performs fault insulation, then you need to be able to se from what side it is using data from, and you might need to be able to override this.

You can mount a lamps to indicate this, but how many indicators do you need?
And what if the software for this is upgraded, do you then need to drill new holes for new indicators ?

In the current architecture air data is only connected to one flight control computer, if one flight control computer fails, then the remaining one also looses air data from that side (As I understand it, please correct me if I'm wrong).
With all those issues, it might be tempting to keep tings as is, in order not to wake up the type certification goods, by changing something.
'As is' is to document that the faults is manageable by the pilots.
HighWind is offline  
Old 28th Mar 2023, 18:23
  #246 (permalink)  
 
Join Date: Dec 2019
Location: OnScreen
Posts: 414
Likes: 0
Received 0 Likes on 0 Posts
This discussion goes at 2 levels:

- The technical characteristics of the MCAS "box", IE the electronics and the software.
- The functional characteristics of the needed MCAS feature to overcome the prehistoric design limitations of the B737 airframe.

The MCAS tech worked as build.

The MCAS feature as a system, to overcome the prepped up prehistoric B737 airframe limitations, failed.

Why did this MCAS feature fail: Simply because Boeing intentionally compartmented the development groups working on the B737 MAX, where the communication between the compartments was under management control, preventing all items, that could screw up with the Boeing commercial goals/promises, getting (technically) investigated (investigated as a proper engineering company should do).

And the management control of the technical interactions (between the compartments as well as with the FAA) gave Boeing the opportunity to lie towards the FAA about everything that might screw up with the Boeing commercial goals/promises.

Preventing technical development groups to communicate with each other, saves a lot of money, though also creates suboptimal solutions. The individual tech systems worked OK, the collaboration of these tech systems failed, because the overall design was not valued on feasibility (at least not for the MCAS area).

Or so to say, the road to disaster was simply built into the Boeing organization, explicitly designed this way to avoid exceptional costs (B787/B777). Exceptional costs which rise, when engineers step out of their own compartment, to take care of a proper system level integration.

Oh, there are other ways to tackle these exceptional costs: Just take care for a proper overall design right from the start, with sub-system interactions recognized/defined in an early stage. But hey, that doesn't match with the idea to El Cheapo prep-up a prehistoric design airframe with Botox.
WideScreen is offline  
Old 29th Mar 2023, 12:10
  #247 (permalink)  
fdr
 
Join Date: Jun 2001
Location: 3rd Rock, #29B
Posts: 2,931
Received 833 Likes on 247 Posts
Talking

Originally Posted by alf5071h

Dr. David Woods discussing automation surprise, learning from incidents and complexity surrounding the Boeing 737 Max.

ď...The industry has to stop rationalising away the lessons from accidents - the difficulties of learning after accidents have occurred are profound. It is easier to look at each event in isolation seeing only the specific details that define a narrow set of changes needed to facilitate a return to normal. But this narrow focus on one accident at a time makes it easy to discount the fundamental common vulnerability that needs to be addressed as an industry-wide priority. Neither the regulators nor the safety organisations have been able to recognise this critical vulnerability nor have they been able to energise a coherent, fundamental approach to overcome this vulnerability.Ē

i.e. we, the industry, are still at risk of an accident from design and certification processes; the continuing task is to minimise this risk.

"Attempts to prevent pilot error by additional regulation, both federal and corporate, have increased the complexity of the environment and increased pilot (design, engineering, test, certification) workload."

Finally!
fdr is offline  
Old 13th Apr 2023, 15:59
  #248 (permalink)  
 
Join Date: Apr 2007
Location: Bristol
Age: 77
Posts: 124
Received 5 Likes on 3 Posts
Sorry for entering this discussion rather late, but just a question about the four failure categories described by tdracer. The suggestion is that a higher categorisation would have been appropriate, eg Hazardous.

Assuming the probability number was increased from 10-5 to 10-7, what additional steps typically would have been expected for MCAS to meet certification requirements?
SRMman is offline  
Old 13th Apr 2023, 19:17
  #249 (permalink)  
 
Join Date: Jul 2013
Location: Everett, WA
Age: 68
Posts: 4,295
Received 135 Likes on 66 Posts
Originally Posted by SRMman
Sorry for entering this discussion rather late, but just a question about the four failure categories described by tdracer. The suggestion is that a higher categorisation would have been appropriate, eg Hazardous.

Assuming the probability number was increased from 10-5 to 10-7, what additional steps typically would have been expected for MCAS to meet certification requirements?
The short answer is that some level of redundancy would probably have been required to meet the 10-7 requirement - there is sometimes a case for a single thread "Hazardous" system, but you need reems of historical data to back up the reliability claims - the AoA sensor simply doesn't have the level of reliability. Catastrophic must have redundancy - both the FAA and EASA are on record as not accepting probability arguments for single failures for systems with catastrophic consequences.
In addition, if the system had been judged to be Hazardous or Catastrophic, it would have received far more scrutiny from the feds - since 'Major' is considered to be a big deal, they don't tend to look at them very closely.
tdracer is offline  
Old 13th Apr 2023, 20:44
  #250 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by tdracer
- the AoA sensor simply doesn't have the level of reliability. Catastrophic must have redundancy -.
But then I would assume you also would need a competently different flight control computer architecture. On B737 each AoA sensor is afaik connected to each own FCC, if a FCC in one side fails, then the FCC in the other side can't access AoA data from the failed side. If an AoA sensor fails, then it need algorithms for identifying the faulted sensor, isolate it, and and likely also an EICAS display to convey this information to the pilots.

HighWind is offline  
Old 14th Apr 2023, 07:44
  #251 (permalink)  
 
Join Date: Dec 2019
Location: OnScreen
Posts: 414
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by HighWind
But then I would assume you also would need a competently different flight control computer architecture. On B737 each AoA sensor is afaik connected to each own FCC, if a FCC in one side fails, then the FCC in the other side can't access AoA data from the failed side. If an AoA sensor fails, then it need algorithms for identifying the faulted sensor, isolate it, and and likely also an EICAS display to convey this information to the pilots.
Ehhh, yes, it is not without reason, many people here write that the MAX should never have been designed and a clean-sheet restart should have been taken by Boeing. But, alas, that takes retraining, time, money and a loss of market share, due to being far too late with new developments at Boeing (in favor of shareholder pay-outs).
WideScreen is offline  
Old 14th Apr 2023, 21:40
  #252 (permalink)  
 
Join Date: Aug 2013
Location: Washington.
Age: 73
Posts: 1,041
Received 142 Likes on 48 Posts
Originally Posted by tdracer
The short answer is that some level of redundancy would probably have been required to meet the 10-7 requirement - there is sometimes a case for a single thread "Hazardous" system, but you need reems of historical data to back up the reliability claims - the AoA sensor simply doesn't have the level of reliability. Catastrophic must have redundancy - both the FAA and EASA are on record as not accepting probability arguments for single failures for systems with catastrophic consequences.
In addition, if the system had been judged to be Hazardous or Catastrophic, it would have received far more scrutiny from the feds - since 'Major' is considered to be a big deal, they don't tend to look at them very closely.
Precisely!
GlobalNav is offline  
Old 14th Apr 2023, 22:04
  #253 (permalink)  
 
Join Date: Jul 2013
Location: Everett, WA
Age: 68
Posts: 4,295
Received 135 Likes on 66 Posts
Originally Posted by HighWind
But then I would assume you also would need a competently different flight control computer architecture. On B737 each AoA sensor is afaik connected to each own FCC, if a FCC in one side fails, then the FCC in the other side can't access AoA data from the failed side. If an AoA sensor fails, then it need algorithms for identifying the faulted sensor, isolate it, and and likely also an EICAS display to convey this information to the pilots.
Why? The revised MCAS logic uses both AoA inputs (and IIRC, will be updated with a synthetic AoA calculation at some future point) and they didn't need change the basic architecture for the update.
tdracer is offline  
Old 15th Apr 2023, 07:18
  #254 (permalink)  
 
Join Date: Dec 2019
Location: OnScreen
Posts: 414
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by tdracer
Why? The revised MCAS logic uses both AoA inputs (and IIRC, will be updated with a synthetic AoA calculation at some future point) and they didn't need change the basic architecture for the update.
Actually, my understanding is, MCAS-1 were 2 independent systems L/R, which did not communicate, but with only some kind of logic to switch-over on airplane boot-up. With MCAS-2, these systems now communicate with each-other to interact about (at least) the presumed health of the AoA input values. With one AoA input out of action, the AoA issue handling is returned to the pilot, according Boeing philosophy.

Regarding the synthetic AoA, this has been "agreed", though also tied to the MAX -10 (maybe also the -7) appearance. No -10 and the synthetic AoA might end up with a premature death. The FAA will be having weak knees, due to Congressional pressure, though It has to be seen, what EASA and China think about this. It was EASA, which was firmly after the 3rd AoA sensor, with the degrade compromise, it might be synthetic.
WideScreen is offline  
Old 15th Apr 2023, 12:17
  #255 (permalink)  
 
Join Date: Nov 1999
Location: UK
Posts: 2,442
Received 73 Likes on 40 Posts
Originally Posted by Bbtengineer
I will stop after this but I’m not having it.

Requirements always come from somewhere else. That’s not special.

You don’t take a stupid requirement.

You don’t expect a civil engineer to take a stupid design from an architect. Seldom the same company.

You don’t expect the engine manufacturer to take a dangerous design from the airframe manufacturer. Not the same company.

The fact that it comes from a different place does not relieve your responsibility to understand and interpret it.

There is no universe, regardless ALL the things you said, in which commanding AND indefinitely forever makes sense. It’s fundamentally stupid.

No.
In other areas of industry, there are arms manufacturers, who make machines and devices specifically designed to kill people. With your logic, nobody would manufacture arms, because that would be "stupid", but sadly, here we are.

Architects have also made mistakes, and civil engineers have built them; Quite a few bridge and building collapses in history show that. And most recently in my recollection; the Grenfell Tower fire in London UK, where the insulation used in the construction of that tower-block was highly flammable. One day, a fire broke out and because of the flammable insulation, it rapidly spread and there was significant loss of life.

A software programmer might not have any idea about how aircraft fly, or what a pilot might or might not do with an aircraft. They might just be given a brief that, (in very simple terms); in situation X; if Y happens, the result needs to be Z.

A staff programmer with aviation experience and knowledge of aircraft failure modes etc, might possibly raise concerns or even objections, but they would be told by their bosses that this is what we want. Or maybe they were convinced by the competent pilot argument. But even then; they would not necessarily know that MCAS was not going to be even mentioned in the FCOM.
Uplinker is offline  
Old 15th Apr 2023, 18:27
  #256 (permalink)  
 
Join Date: Dec 2019
Location: OnScreen
Posts: 414
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Uplinker
In other areas of industry, there are arms manufacturers, who make machines and devices specifically designed to kill people. With your logic, nobody would manufacture arms, because that would be "stupid", but sadly, here we are.
Actually, arms serve a "higher" goal, even for the dictators, who want to expand their territory (Hitler, Putin, Xi).

Originally Posted by Uplinker
.....
A software programmer might not have any idea about how aircraft fly, or what a pilot might or might not do with an aircraft. They might just be given a brief that, (in very simple terms); in situation X; if Y happens, the result needs to be Z.
That's not really how it works with software development. A proper software development gradually goes in steps from application experts to the factual coders. All guided/driven by a huge amount of documents in stepwise refinement/detailing, with continuous backtracking to correct on errors at the more abstract levels.

Originally Posted by Uplinker
A staff programmer with aviation experience and knowledge of aircraft failure modes etc, might possibly raise concerns or even objections, but they would be told by their bosses that this is what we want. Or maybe they were convinced by the competent pilot argument. But even then; they would not necessarily know that MCAS was not going to be even mentioned in the FCOM.
What Boeing did was compartmentalize the whole MAX development, where the software got spec'd and subcontracted to India, implemented (probably some "easy" updates on the original version) by engineers without suitable aviation knowledge, "just a programming job", black box programming, paid the absolute minimum, etc. The less interaction there is in the whole development chain, the cheaper it is, though also the fewer chances there are, fundamental functional issues are detected along the way. Which happened.
WideScreen is offline  
Old 16th Apr 2023, 02:19
  #257 (permalink)  
 
Join Date: Jul 2013
Location: Everett, WA
Age: 68
Posts: 4,295
Received 135 Likes on 66 Posts
Originally Posted by WideScreen
Actually, my understanding is, MCAS-1 were 2 independent systems L/R, which did not communicate, but with only some kind of logic to switch-over on airplane boot-up. With MCAS-2, these systems now communicate with each-other to interact about (at least) the presumed health of the AoA input values. With one AoA input out of action, the AoA issue handling is returned to the pilot, according Boeing philosophy.

Regarding the synthetic AoA, this has been "agreed", though also tied to the MAX -10 (maybe also the -7) appearance. No -10 and the synthetic AoA might end up with a premature death. The FAA will be having weak knees, due to Congressional pressure, though It has to be seen, what EASA and China think about this. It was EASA, which was firmly after the 3rd AoA sensor, with the degrade compromise, it might be synthetic.
But my point is they did all that without a major change to the avionic architecture - had the MCAS hazard category been properly identified during the original development, they could have fixed it within the existing avionic architecture.
My understanding is that the third AoA is a hard agreement with EASA - so Boeing needs to come up with something if they expect to keep delivering MAX aircraft in the EASA world. Congress has already approved an extension for the MAX-10, so I'm pretty sure that program will stay intact. As for China, with the current state of relations between the US and China, I think Boeing has pretty much given up on future China deliveries of the MAX (my understanding is that China still hasn't approved the MCAS fix and lifted the MAX grounding).
tdracer is offline  
Old 16th Apr 2023, 02:32
  #258 (permalink)  
 
Join Date: Oct 2019
Location: USA
Posts: 731
Received 112 Likes on 56 Posts
Had the AoA subsystem been identified as unacceptably producing the incorrect information 30+ years ago MCAS would have not been the discussion point it is today. But everyone thought that passing along false data and even creating false stall warnings was OK. Every pundit has said that the cacophony from the false stall warning distracted the pilots from noticing the MCAS activity - however if the false AoA data was properly identified then that data would have been marked invalid and not passed to MCAS to work with.

No one in India worked on flight software for Boeing. That was subcontracted to an American company.

China is apparently building their own copies of the 737. No need to buy them anymore.
MechEngr is online now  
Old 16th Apr 2023, 06:37
  #259 (permalink)  
 
Join Date: Dec 2019
Location: OnScreen
Posts: 414
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by tdracer
But my point is they did all that without a major change to the avionic architecture - had the MCAS hazard category been properly identified during the original development, they could have fixed it within the existing avionic architecture.
Yes, I think, you are 100% right about that.

The issue is, why did this happen ? Were the engineers "just dumb", or were the engineers creating the spec just not allow to "discuss" these items with the ones asking for the spec ? Given the way Boeing did compartmentalize the engineers into their own small area of attention, all communication between the areas going through "management", it just kills the human ingenuity to find out "something is missing". In this case, the implicit transition to a higher hazard category was missed / prevented to spread out further.

We do have the Forkner chat messages, which in itself not only give factual information, though also reveal a huge amount of personal frustration. Frustration, that, to my judgement, is highly related to the lack of opportunities he has to "report" issues and when reported, nothing is done with it, he is ignored (and sent on a mission towards customers to lie further about these items).
Originally Posted by tdracer
My understanding is that the third AoA is a hard agreement with EASA - so Boeing needs to come up with something if they expect to keep delivering MAX aircraft in the EASA world. Congress has already approved an extension for the MAX-10, so I'm pretty sure that program will stay intact.
Yep, the MAX-10 certification period extension is active and then "officially" the synthetic AoA is to be implemented.

However, whenever possible, Boeing will quite likely try to wiggle out of that. It costs money to create, they don't consider it necessary (try raising a teenager), etc. with their revised mission, finding the (US) airlines on their side, since the third/synthetic AoA will change the cockpit GUI and as such, will require training across the board (with the additional risk, the B737 family commonality might be degraded/influenced).

Originally Posted by tdracer
As for China, with the current state of relations between the US and China, I think Boeing has pretty much given up on future China deliveries of the MAX (my understanding is that China still hasn't approved the MCAS fix and lifted the MAX grounding).
The resurrection of the B737 MAX in China seems to have started, just a few days ago:

Reuters: Boeing says 11 Chinese airlines have resumed operating B737 MAX.

Though one Taiwan "mishap" and China may miraculously find something else to ground the B737 MAX again. In the end, it's a dictatorial state, where these instruments are being used to steer their international geopolitics. (Anybody did read the ridiculous Lula statements around Ukraine ? Guess how he would proclaim, when Argentina would capture just one square mile of the Brazilian territory, with an argument like "it would be better for the local population" .....).
WideScreen is offline  
Old 16th Apr 2023, 15:29
  #260 (permalink)  
 
Join Date: Jul 2013
Location: Within AM radio broadcast range of downtown Chicago
Age: 71
Posts: 767
Received 0 Likes on 0 Posts
WideScreen, it's very heartening to read that there are others who saw the facts of Forkner's situation, or at least some major elements of those facts (as you've noted), as not deserving prosecution, let alone conviction.

Especially after the unseemly - and unlawful (imho) - manipulation of the Deferred Prosecution Agreement process to exclude the crash victims' families in the Texas criminal case against Boeing, the efforts to hoist Mr. Forkner to twist in the wind look even more outrageous. As if the deliberate deceit after Lion Air wasn't bad enough....(and all the other things on all the other levels in which the company acted wrongly).
WillowRun 6-3 is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.