PPRuNe Forums

PPRuNe Forums (https://www.pprune.org/)
-   Rumours & News (https://www.pprune.org/rumours-news-13/)
-   -   Ethiopian airliner down in Africa (https://www.pprune.org/rumours-news/619272-ethiopian-airliner-down-africa.html)

TryingToLearn 20th Apr 2019 21:48


Originally Posted by 737 Driver (Post 10452209)
The difference this time was the system response was more than an annoyance - it was, sadly in hindsight, an existential threat.

In case of an important 'warning' function you may want something fail-operational, your safe state is 'warn'. So you place an 'OR' logic within your redundancy.
In case of a -maybe dangerous- reaction and a fail-safe ('better do nothing') system, AND is the only solution.

Next question, where is MCAS?
a) Do you need fail-operational performance? Is this 'feel' in case of being close to stall very important? ->OR
b) Do you need to be fail-safe? Is a wrong activation critical? -> AND
c) Both? -> 3 Sensors, 2oo3 reaction, 3oo3 maintainance message
d) nice feature, doesn't do any harm? -> single sensor
There's no rocked science behind such systems.

But even if this system would rely on a single sensor. Range checks are also a valid method.
Close to stall at 75°AoA? Oh, we may need to adjust the feel a bit?!?
Even a 'no-brain' range plausibilization within the 1 sensor would have rescued one of 2 planes (fun fact: Such a range check is considered a 'low-coverage' method in automotive, estimated to catch 60% of all errors (ISO26262 part 5 annex D sensors...)).

robocoder 20th Apr 2019 21:53


Originally Posted by 737 Driver (Post 10452209)
I've pondered this question myself quite a bit. I'm not sure we will ever know the correct answer, but let me offer an observation. While the 737 has a lot of redundancy, that redundancy does not generally extend to two sensors coming to an agreement before one of them causes a system response.

The most obvious example is that if one stall computer (SMYD) senses an approach to stall condition, it will turn on one stick shaker and activate the Elevator Feel Shift Module (EFSM). I believe one SMYD can also activate the Speed Trim Stall ID function and the autoslats (I'm actually trying to confirm these last two. The aircraft maintenance manual (AMM) suggests this is the case, but I haven't found anyone at my company who can say for sure). If the left and right inputs disagree, you will get some kind of message, but the system response still occurs.

I could envision a scenario in which someone on the MCAS design team looked at how previous 737 models treated these system inputs and simply followed suit. The difference this time was the system response was more than an annoyance - it was, sadly in hindsight, an existential threat.

I remember someone explaining that if they went with two sensors, the system would have to notify on disagreement and generate a warning, and that would need extra training and/or somehow impact the constraints under which the MAX was being designed.

I don't remember who said that and how accurate that is. Because if true, that raises the question: if the modified MCAS now accepts two inputs and self-disables on disagreement, is the no-training card already lost? With the penalty millions of certain airlines?

Dani 20th Apr 2019 22:17

I repeat my post again gladly, where I wrote that it's not the MCAS which was the main problem but the data gathering unit (I'm not a B guy) from the AOA probe to the flight control computer. People insist that it was a probe failure, but this is highly inprobable. 2 probe failure on a new plane within months, on top of all the MCAS incidents on US airliners. I have never heard of a AOA probe failure, it happens very rarely.
It must have been the AOA data that was corrupted, not the AOA probe itself.
Only then MCAS made the mixup with the data (rubish in, rubish out). MCAS reacted as programmed, it received the wrong data.

737 Driver 20th Apr 2019 22:23


Originally Posted by TryingToLearn (Post 10452219)
In case of an important 'warning' function you may want something fail-operational, your safe state is 'warn'. So you place an 'OR' logic within your redundancy. In case of a -maybe dangerous- reaction and a fail-safe ('better do nothing') system, AND is the only solution.

Next question, where is MCAS?

Again, just speculating. According to initial reports, MCAS was only supposed to make a 0.6 nose down input. That is entirely manageable and wouldn't pose a threat, particularly if it occurred only once. Multiple 2.5 degree nose down inputs is an altogether different story. We don't why this change to MCAS authority was made, but apparently someone didn't connect the dots.

737 Driver 20th Apr 2019 22:54


Originally Posted by Dani (Post 10452234)
I repeat my post again gladly, where I wrote that it's not the MCAS which was the main problem but the data gathering unit (I'm not a B guy) from the AOA probe to the flight control computer.

I would have to look at the system architecture to be sure, but I'm almost positive that the AOA output does NOT go direct to the FCC. AOA is an input to both the Stall Management Yaw Damper (SMYD) computers and the Air Data Inertial Reference Units (ADIRU's). AOA is just one input into the SMYD's and ADIRU's. A bad pitot tube input could also have generated a false stall signal.

The primary responsibility of generating an approach to stall signal belongs to the SMYD which then activates various other aircraft systems (including the FCC) in response to the impending stall. I believe MCAS is a subroutine within the FCC. As I posted earlier, in many respects the two SMYD's act independently requiring only one "vote" to activate various systems, though there will be some other alerts to indicate the disagreement.



People insist that it was a probe failure, but this is highly inprobable. 2 probe failure on a new plane within months
Not sure if you are talking about the two AOA failures at Lion Air, or the two failures at two different airlines. At Lion Air, the accident aircraft had a defective AOA on a previous flight which was then replaced. We don't yet know why the first AOA was defective. Perhaps a ground worker bumped a piece of equipment into it. We do have evidence that the replacement AOA was 20 degrees out of calibration. Its DFDR readout exactly paralleled the good AOA, just 20 degrees higher. How this came to be is one of the subjects of the investigation. At Ethiopian, the DFDR data suggests that the AOA was working during the takeoff run, but was disabled shortly after liftoff, possibly by a bird strike.



I have never heard of a AOA probe failure, it happens very rarely. It must have been the AOA data that was corrupted, not the AOA probe itself. Only then MCAS made the mixup with the data (rubish in, rubish out). MCAS reacted as programmed, it received the wrong data.
AOA failures do happen, but until recently they did not result in a major accident. The DFDR records the AOA output, so we really do know that it was a faulty AOA, though the reason for the failure was different in the two accidents. Again, it wasn't MCAS's job to determine the stall condition. That responsibility belongs to the SMYD's. The problem was that it only took one SMYD to activate MCAS.

LandIT 20th Apr 2019 23:13


Originally Posted by Bend alot (Post 10451157)
Automation generally will not trip/cut out when the flowers are in bloom, it trips out on during the hurricane/cyclone cat 5+

So say the autopilot - it will hold a wing out of balance until it can hold it no longer, then disengage from wings level. You will get a hard and fast roll.

I think this is a very good point. Don't suppose a warning would be possible? Status screen showing any difficulties being handled? Option to return control surfaces to neutral?!

Dani 20th Apr 2019 23:43


Originally Posted by 737 Driver (Post 10452249)
At Ethiopian, the DFDR data suggests that the AOA was working during the takeoff run, but was disabled shortly after liftoff, possibly by a bird strike.

Thanks for taking your time taking me with you on the matter.
Still, who tells us that it was a bird strike? It could be very well that the flight computer software delivers correct AOA data to the stall computer on ground and then starts to mix them up in the air. I read nothing of a bird strike in the preliminary.

Avherald says:

A false AoA value, probably produced by the Air Data Reference unit rather than a mechanical fault, which activated the stick shaker and MCAS.
This does not mean that the AOA is broken, but the AOA data.

That's why it is not wise to critisize the MCAS (alone), but the data handling of the whole system. I think Boeing and FAA know very well that it's not an isolated MCAS problem, but a flight control computer software problem on a wider scale.

Dani

HarryMann 20th Apr 2019 23:44


Originally Posted by LandIT (Post 10452261)
I think this is a very good point. Don't suppose a warning would be possible? Status screen showing any difficulties being handled? Option to return control surfaces to neutral?!

whilst it may well be or have been the long standing protocol /default behaviour of autopliot and other automatic flight functions

Seems incredibly naive not to fully inform what any automation is actually up to... if that's right, a whole sysyem function is missing... comumucation

AAKEE 21st Apr 2019 00:01


Originally Posted by Dani (Post 10452269)
Still, who tells us that it was a bird strike? It could be very well that the flight computer software delivers correct AOA data to the stall computer on ground and then starts to mix them up in the air. I read nothing of a bird strike in the preliminary.

This does not mean that the AOA is broken, but the AOA data.

Dani

Bird strike theory isnt in the preliminary but in this thread a logical solution for the AoA values was presented earlier. If the AoA vane detaches due to for example a bird strike, the heating failure warning is explained. Also, the counterweight would case it to turn to 90 degree, exept for acceleration forces. It seems to reach 75 degree(measuring limit?) and stay there until A/C enters negative G, then the reading seems to follow the minus G. It seems to be affected by negative G-forces as a free turning counterweight would.

GordonR_Cape 21st Apr 2019 06:20


Originally Posted by robocoder (Post 10452222)
I remember someone explaining that if they went with two sensors, the system would have to notify on disagreement and generate a warning, and that would need extra training and/or somehow impact the constraints under which the MAX was being designed.

I don't remember who said that and how accurate that is. Because if true, that raises the question: if the modified MCAS now accepts two inputs and self-disables on disagreement, is the no-training card already lost? With the penalty millions of certain airlines?

There is still much to discuss about the failure of the "initial" MCAS design, particularly the points made by TryingToLearn. The whole story is a very complex chain of decisions, most of which have been described in detail earlier in this thread, and sure to be covered by the accident investigation and FAA review.

The "revised" MCAS tries to satisfy both requirements, by having a complex series of validations to reduce false activation, while still maintaining the same 2.5 degree increment of nose-down trim (rather than reverting to the original 0.6 degrees). News reports suggest that expensive additional training will not be mandated by the FAA, though some airlines will choose to do so voluntarily.

By now the costs to Boeing (direct losses and share price reduction) are in the billions, not millions, so that penalty card is somewhat irrelevant.

Bend alot 21st Apr 2019 06:33


Originally Posted by GordonR_Cape (Post 10452359)
There is still much to discuss about the failure of the "initial" MCAS design, particularly the points made by TryingToLearn. The whole story is a very complex chain of decisions, most of which have been described in detail earlier in this thread, and sure to be covered by the accident investigation and FAA review.

The "revised" MCAS tries to satisfy both requirements, by having a complex series of validations to reduce false activation, while still maintaining the same 2.5 degree increment of nose-down trim (rather than reverting to the original 0.6 degrees). News reports suggest that expensive additional training will not be mandated by the FAA, though some airlines will choose to do so voluntarily.

By now the costs to Boeing (direct losses and share price reduction) are in the billions, not millions, so that penalty card is somewhat irrelevant.

But Gordon the problem is there are things NOT up for discussion (seems under any and all circumstances - even before final reports) by Boeing and the FAA.

Training clearly being one of them - there will be no compromise it seems, there will be no required sim training or "detailed" training for the MAX.

That spells corruption to me.

GordonR_Cape 21st Apr 2019 06:41


Originally Posted by Bend alot (Post 10452364)
But Gordon the problem is there are things NOT up for discussion (seems under any and all circumstances - even before final reports) by Boeing and the FAA.

Training clearly being one of them - there will be no compromise it seems, there will be no required sim training or "detailed" training for the MAX.

That spells corruption to me.

I am not privy to any of the details, but it seems the joint investigation has not come to any conclusions, so the decisions by Boeing and the FAA are merely the first steps: https://en.businesstimes.cn/articles...d-agencies.htm

The initial certification of Boeing's now infamous 737 Max models has been questioned by multiple countries and American agencies rallying to investigate the issue. The investigation of a joint international panel is expected to run for three months.
https://www.apnews.com/41d5aca3f27e4c97b6980b245af5c3fc

A global team of experts next week will begin reviewing how the Boeing 737 Max’s flight control system was approved by the U.S. Federal Aviation Administration.

The FAA says experts from nine international civil aviation authorities have confirmed participation in a technical review promised by the agency.

Former National Transportation Safety Board Chairman Chris Hart will lead the group, which also will have experts from the FAA and NASA. They will look at the plane’s automated system including the way it interacts with pilots. The group will meet Tuesday and is expected to finish in 90 days.

Bend alot 21st Apr 2019 06:50


Originally Posted by GordonR_Cape (Post 10452366)
I am not privy to any of the details, but it seems the joint investigation has not come to any conclusions, so the decisions by Boeing and the FAA are merely the first steps: https://en.businesstimes.cn/articles...d-agencies.htm


https://www.apnews.com/41d5aca3f27e4c97b6980b245af5c3fc

A few days ago.

The draft report from the FAA Flight Standardization Board (FSB) said additional training was needed for MCAS, but not required to be done in a simulator.

https://www.businessinsider.com/faa-...9-4/?r=AU&IR=T

Then why all ready, state the exclusion of a simulator training being or not being a requirement? At this point I do not think the FAA have been given the submission of the fix!!!

GordonR_Cape 21st Apr 2019 07:00


Originally Posted by Bend alot (Post 10452368)
A few days ago.

The draft report from the FAA Flight Standardization Board (FSB) said additional training was needed for MCAS, but not required to be done in a simulator.

https://www.businessinsider.com/faa-calls-boeing-737-max-software-fix-operationally-suitable-2019-4/?r=AU&IR=T

Then why all ready, state the exclusion of a simulator training being or not being a requirement? At this point I do not think the FAA have been given the submission of the fix!!!

The clue is in the target audience of the report (hint, its PR fluff, not aimed at the flying public).

Boeing shares rose 2 percent after the news.

bill fly 21st Apr 2019 07:14

If the revised MCAS software (with a one time AND stab input up to 2.5deg) gets certified, then Boeing will have to publish a new failure mode procedure, because the runaway stab procedure would apply even less.

A specific MCAS failure mode procedure would need thinking through.

Bend alot 21st Apr 2019 07:28


Originally Posted by GordonR_Cape (Post 10452373)
The clue is in the target audience of the report (hint, its PR fluff, not aimed at the flying public).

Target audience?

Simulator required training will hurt Boeing in the USA and outside- the fact there simply is not enough MAX simulators is a secondary factor - the target audience is the airlines and the launch customer has a bet each way on training!

Why would you bet each way?

Loose rivets 21st Apr 2019 11:10

And the Million $ per aircraft promised payment, though I think that might be AA specific.


I'm still reeling from the shock of watching the subcontracting issues on the parallel thread. I was totally unaware of this. The gist I got was that the problem is so serious that no one seems able to face addressing it.

Current crews and engineers will no doubt be au fait with the issue. Just what is going on?

Rather drawn out, but so bewildering it took my mind off MCAS.

https://www.pprune.org/rumours-news/...l#post10450972

safetypee 21st Apr 2019 11:34

Some discussions and media articles risk confusing complementary but different processes in certification.
Aircraft certification - CS 25 requirements, essentially relates to design aspects, but including crew activities (HF).
Flight Standards reviews are more focussed on operational implementation, guided by Ops requirements (121) and Advisory materials; this includes the level / extent of training and judgement of same type rating.

Aircraft type certification is initiated and led by the host nation (Boeing / FAA); other certification authorities can validate / accept the basis of certification Part 25 ~ CS 25, add special requirements, or apply specific interpretations.
Operational approval is less well defined; the lead authority’s position can be used as a basis, but more often reinterpreted and adjusted by others to meet national requirements.
Thus aircraft certification by the lead authority is widely agreed, but operational approval less so.

In this instance, the certification aspect of the MCAS modifications have to meet FAA Part 25; each national authority considers acceptance, validation, or applies special conditions. It would be surprising if there was not an agreed positon, even if not as the initial Boeing / FAA proposal (normally closed doors meetings).

The FAA Flight Standards (re) review, could agree that their initial position is still valid after modification; i.e. the intention and effect of MCAS is unchanged even though its initial mechanisation and notification were flawed (Fight Ops didn’t know) - a public view, link below.
A weakness in this process is that local viewpoints (operators) can sway operational decisions, such that there could be significant differences with other authorities who represent more worldly views. In this instance the latter is very important due to the nature and location of the accidents (Boeing / FAA should build and certificate aircraft for the world; not just local operators).

Having an independent international group consider ’certification’ issues is very unusual, even more so with ex NTSB chairmanship. Its task is reported as “… evaluate the automated flight control design and determine whether it complies with regulations. It also will decide if changes need to be made in the FAA’s approval process.” (90 days!)
It would be surprising if ‘aircraft certification’ (part 25) of MCAS modification were to be reviewed; this would question the FAAs fundamental right (ability) for approval (a US issue not international). Thus probably not an international public review of the failings in certification (Boeing / FAA); but a US investigation is still required.

However, a wider review of technical certification aspects based on what has been learnt from the accidents would be most valuable, even if not helpful to Boeing /FAA. Link to discussions below.
More likely the task is to agree a common operational view, or sufficiently similar so that the FAA is not isolated, and restores credibility. The timescales for this might not restrict a return to operations, even though some authorities could differ from the FAAs position.

Some of the technical issues, overlapping both certification and operational aspects are discussed in #696 https://www.pprune.org/showpost.php?...&postcount=696 and #703

https://www.faa.gov/aircraft/draft_d...ev17_draft.pdf

FAA update https://www.faa.gov/news/updates/?newsId=93206

syseng68k 21st Apr 2019 14:06


Originally Posted by MemberBerry (Post 10451986)
Good point. I also read this thread from the beginning and, to add another data point to the tendency you noticed, I'm a software engineer and I tend to blame Boeing more than the pilots. Boeing's attitude after the Lion Air accident contributed to that. If they didn't try to downplay the gravity of experiencing an incorrect MCAS activation, I would have probably been more sympathetic towards them.

Just like there seems to be a deficit of pilots in the aviation world, I think that generally there is a deficit of good software developers, and it's getting worse. I think the quality of software took a nosedive during the last decade. Software from a decade ago was way more polished than what I see today, and this is very frustrating.

Sure, just as the safety of air travel is getting better and better, a lot of lessons have been learned from the past in the software industry, and some types of bugs and quality issues are becoming less and less frequent. But there seems to be a lot less attention to detail, and I find it unbelievable that large software companies repeatedly release software products with significant bugs, that should are obvious to anyone after only a few minutes of using the product.

And I don't think it's just the deficit of good software developers causing this. I see a variety of other factors contributing to the decline in the quality of software, for example a tendency to spend less on quality assurance, and relying more and more on the end users to find and report quality issues with the software products. I hoped this trend would affect mostly regular consumer products, and not software that is critical for safety, but unfortunately that doesn't seem to be the case, some recent examples being the Tesla self driving car software, and possibly MCAS.

Anyway, back to the MCAS topic, I watched Mentour's recent video about being unable to trim manually at high speeds when the aircraft is severely out of trim. One thing that surprised me is that the simulator, which Mentour described as: "this is a level D FFS. That’s as real as it gets", is not able to replicate a stabilizer runaway similar to an incorrect MCAS activation, the runaway stabilizer failure is not able to bring the trim to full AND.

I guess the reason the simulated failure is not able to apply more AND trim is that it simulates something similar to stuck yoke trim switches. In such a situation, after reaching about 4 units with the flaps retracted, the trim limit switches would activate. That would prevent the trim from going lower than 4 units. I think that's why they have to trim manually the wrong way in the video, to try to simulate a worse mistrim, similar to that experienced by the Lion Air and Ethiopian pilots, because the simulator doesn't seem to be able do that.

If that's the case, I'm even more annoyed by Boeing's initial response that the pilots they should have just applied the runway stabilizer procedure. If the simulators are not able to replicate a mistrim as severe as one caused by a malfunctioning MCAS, clearly the existing simulator training for a stabilizer runaway failure is not entirely adequate for dealing with an MCAS induced trim runaway.

Haven’t posted here for a while and semi retired now, but also electronics / software engineer, three decades plus including avionics systems exposure. Have read this thread and amazed that such a system with a single point of failure could ever have passed certification, either internally or regulatory. Although the circumstances differ, am reminded of the AF447 episode, where the crew were completely disoriented by the system going awol and dumping the a/c in an unknown state, misleading signals, onto an overloaded crew, who really did not stand a chance. Seems to me yet another example of the gap in the man / machine interface. Ideally, such systems should be designed to provide an unambiguous view of the machine state at all times, but seems far from it. Should be a basic design requirement that no crew should be expected to “guess” the state of the system at any time.

What is clear is a gross failure of systems engineering. Design, attention to detail and oversight. The big picture view of how the overall system works and how the individual parts interact and communicate. I don’t think you can blame software engineers or the software for any of this, as faults vs spec at that level would have been found during rigorous testing, but if the fundamental design is wrong, or full of uncovered corner cases, no software can compensate for that. The problem is that modern systems are now so complex that it may in fact be nigh impossible to test for every possible situation, or component failure. However, that is no excuse for not trying.

Reminded of another company: Hewlett Packard, who built a reputation over decades for building the most innovative and highest quality test equipment in the business. They spent a fortune on R&D and were widely diversified into science, healthcare and more. Then, bean counters and “shareholder value”, gross mismanagement and greed turned a hard won reputation and pursuit of excellence into a laughing stock. Fortunately, the test gear division was spun off, but now a pale shadow of their former selves and not sure how much r&d they do now. Really, does anyone care anymore, or is it already too late ?...

derjodel 21st Apr 2019 14:31


Originally Posted by syseng68k (Post 10452573)
Haven’t posted here for a while and semi retired now, but also electronics / software engineer, three decades plus including avionics systems exposure. Have read this thread and amazed that such a system with a single point of failure could ever have passed certification, either internally or regulatory. Although the circumstances differ, am reminded of the AF447 episode, where the crew were completely disoriented by the system going awol and dumping the a/c in an unknown state, misleading signals, onto an overloaded crew, who really did not stand a chance. Seems to me yet another example of the gap in the man / machine interface...

AF447 was perfefectly flyable - it was the PF who keept pulling up, making the fatal error. Perhaps the underlying issue is that the frame, when on full thrust and full elevator up, will not drop the nose which would make it clear it was stalled.

Anyways, the MAXes which crashed were not flyable, period. The trim could not have been changed - too much resistance to do it manually and another mcas event if you try electric trim.

Quite different situation, IMO. AF447 had much more time to react (but they burned it and who knows how much altitude they needed to recover). They had lots of energy and flyable plane.


All times are GMT. The time now is 01:57.


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