Ethiopian airliner down in Africa
Join Date: Apr 2019
Location: USA
Posts: 217
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Dani
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.
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
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.
Join Date: Oct 2008
Location: Melbourne, ɐıןɐɹʇsn∀
Age: 73
Posts: 79
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Bend alot
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.
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.
Join Date: Aug 2002
Location: Switzerland, Singapore
Posts: 1,306
Received 0 Likes
on
0 Posts
Originally Posted by 737 Driver
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.
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.
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
Join Date: Jan 2008
Location: Herts, UK
Posts: 748
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by LandIT
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?!
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
Originally Posted by Dani
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
This does not mean that the AOA is broken, but the AOA data.
Dani
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 61
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by robocoder
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?
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?
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.
Originally Posted by GordonR_Cape
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.
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.
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.
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 61
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Bend alot
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.
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.
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.
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.
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.
Originally Posted by GordonR_Cape
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
https://www.apnews.com/41d5aca3f27e4c97b6980b245af5c3fc
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!!!
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 61
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by Bend alot
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 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!!!
Boeing shares rose 2 percent after the news.
Join Date: Feb 2015
Location: The woods
Posts: 1
Likes: 0
Received 0 Likes
on
0 Posts
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.
A specific MCAS failure mode procedure would need thinking through.
Originally Posted by GordonR_Cape
The clue is in the target audience of the report (hint, its PR fluff, not aimed at the flying public).
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?
Psychophysiological entity
Join Date: Jun 2001
Location: Tweet Rob_Benham Famous author. Well, slightly famous.
Age: 83
Posts: 3,158
Likes: 0
Received 0 Likes
on
0 Posts
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.
Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
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.
Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed
Join Date: Dec 2002
Location: UK
Posts: 2,342
Likes: 0
Received 0 Likes
on
0 Posts
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 Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed and #703
https://www.faa.gov/aircraft/draft_d...ev17_draft.pdf
FAA update https://www.faa.gov/news/updates/?newsId=93206
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 Boeing 737 Max Software Fixes Due to Lion Air Crash Delayed and #703
https://www.faa.gov/aircraft/draft_d...ev17_draft.pdf
FAA update https://www.faa.gov/news/updates/?newsId=93206
Last edited by safetypee; 22nd Apr 2019 at 06:04.
Originally Posted by MemberBerry
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.
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.
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 ?...
Join Date: Oct 2017
Location: Vienna
Posts: 143
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by syseng68k
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...
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.
Join Date: May 2010
Location: Boston
Age: 71
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by derjodel
...
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.
...
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.
...
Not true,MCAS is disabled for 5 seconds after pilot trim so they could have used electric trim and -then- disabled. Alternating up/down blips at 3 second intervals would have kep MCAS disabled as long as needed.
Of course this is after the fact but should have been highlighted (not hinted at in a note) in the emergency AD following Lion Air.
The alternate method of briefly relaxing column inputs and cranking 'might' have been possible although nerve wracking at best given the altitude.
Last edited by MurphyWasRight; 21st Apr 2019 at 15:20. Reason: typo 'no > not'
Join Date: Mar 2019
Location: Bavaria
Posts: 17
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by syseng68k
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.
.
.
a) System engineering (writing system requirements and designing a 'system' before jumping on code and PCBs) is completely underestimated but failures at this stage have a huge impact.
b) People care about 'functional safety' (bugs) but completely underestimate the importance of 'safety of use', a clear and understandable user interface, also in automotive (https://en.wikipedia.org/wiki/Anton_Yelchin#Lawsuit)
c) Complexity, which everyone claimes. But: High complexity in most cases is just bad (or missing) architecture.
Sorry, but the longer I think about this MCAS, the more I get angry that such a system was able to make it's way into production.
Join Date: Jan 2008
Location: Hotel Sheets, Downtown Plunketville
Age: 75
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by syseng68k
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 ?...
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 ?...
Join Date: Jul 2011
Location: Canada
Posts: 55
Likes: 0
Received 0 Likes
on
0 Posts
Originally Posted by patplan
I'm confused had there been any US MCAS incidents?? Can you at least cite me one case?
I will just concentrate on Lion Air Flight JT610.
How do you know the CAPT on that flight didn't perform UAS NNC? Did you get a hold of the CVR's transcript? We know there wasn't any CVR's transcript on Lion Air JT610 Preliminary Crash Investigation because they still haven't recovered the JT610's CVR at that juncture. The CVR was buried beneath a thick mud of Java Sea for almost 60 days before they finally recovered it. And, no official transcript has been released by the officials thus far.
Furthermore, the crew had been briefed about the malfunctions and the fixes by the MX on the ground, plus there was a log left by the previous crews [Flight JT043] written as:
"Airspeed unreliable and ALT disagree shown after takeoff, STS also running to the
wrong direction, suspected because of speed difference, identified that CAPT instrument
was unreliable and handover control to FO. Continue NNC of Airspeed Unreliable and ALT
disagree. Decide to continue flying to CGK at FL280, landed safely runway 25L."
Wouldn't you think the first thing flashed on the CAPT's mind should there be trouble with the aircraft is to recall the previous flight's log entry which explained, among other things, the crews' execution of the Airspeed Unreliable NNC and also ALT disagree memory items?
I will just concentrate on Lion Air Flight JT610.
How do you know the CAPT on that flight didn't perform UAS NNC? Did you get a hold of the CVR's transcript? We know there wasn't any CVR's transcript on Lion Air JT610 Preliminary Crash Investigation because they still haven't recovered the JT610's CVR at that juncture. The CVR was buried beneath a thick mud of Java Sea for almost 60 days before they finally recovered it. And, no official transcript has been released by the officials thus far.
Furthermore, the crew had been briefed about the malfunctions and the fixes by the MX on the ground, plus there was a log left by the previous crews [Flight JT043] written as:
"Airspeed unreliable and ALT disagree shown after takeoff, STS also running to the
wrong direction, suspected because of speed difference, identified that CAPT instrument
was unreliable and handover control to FO. Continue NNC of Airspeed Unreliable and ALT
disagree. Decide to continue flying to CGK at FL280, landed safely runway 25L."
Wouldn't you think the first thing flashed on the CAPT's mind should there be trouble with the aircraft is to recall the previous flight's log entry which explained, among other things, the crews' execution of the Airspeed Unreliable NNC and also ALT disagree memory items?
You're correct about the CVR however the official, preliminary report page 2, the aircraft had a ground speed (from the radar controller) of 322 knots with an altitude somewhere between 2,000 and 5,000 ft ( 23:22:56 UTC) - there is no way the aircraft would be going that fast with 80% N1 per the NNC UAS with flaps extended or 70% clean. Also, if you look at the FDR printout at that time, there is no evidence of a thrust reduction from take-off power (N1, N2, fuel flow).
I would agree that given the previous flight log entry that one would have a greater than normal awareness of an unreliable airspeed potential but evidently that checklist was not executed, given the inordinately high ground speed and the absence of changes to the engine power.
