Boeing pilot involved in Max testing is indicted in Texas
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.
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.
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.
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.
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.
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."
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."
Join Date: May 2008
Location: denmark
Posts: 9
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Dec 2019
Location: OnScreen
Posts: 415
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.
- 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.
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!
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?
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?
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?
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?
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.
Join Date: May 2008
Location: denmark
Posts: 9
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: Dec 2019
Location: OnScreen
Posts: 415
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
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.
Join Date: Dec 2019
Location: OnScreen
Posts: 415
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
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.
Join Date: Dec 2019
Location: OnScreen
Posts: 415
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
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).
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.
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.
Join Date: Dec 2019
Location: OnScreen
Posts: 415
Likes: 0
Received 0 Likes
on
0 Posts
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).
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.
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).
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" .....).
Join Date: Jul 2013
Location: Within AM radio broadcast range of downtown Chicago
Age: 71
Posts: 842
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).
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).
