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

Ethiopian airliner down in Africa

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

Ethiopian airliner down in Africa

Old 20th Apr 2019, 23:44
  #4181 (permalink)  
 
Join Date: Jan 2008
Location: Herts, UK
Posts: 733
Originally Posted by LandIT View Post
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
HarryMann is offline  
Old 21st Apr 2019, 00:01
  #4182 (permalink)  
 
Join Date: Jan 2009
Location: Sweden
Age: 52
Posts: 151
Originally Posted by Dani View Post
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.
AAKEE is online now  
Old 21st Apr 2019, 06:20
  #4183 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 57
Posts: 381
Originally Posted by robocoder View Post
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.
GordonR_Cape is online now  
Old 21st Apr 2019, 06:33
  #4184 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 346
Originally Posted by GordonR_Cape View Post
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.
Bend alot is offline  
Old 21st Apr 2019, 06:41
  #4185 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 57
Posts: 381
Originally Posted by Bend alot View Post
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.
GordonR_Cape is online now  
Old 21st Apr 2019, 06:50
  #4186 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 346
Originally Posted by GordonR_Cape View Post
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!!!
Bend alot is offline  
Old 21st Apr 2019, 07:00
  #4187 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 57
Posts: 381
Originally Posted by Bend alot View Post
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.
GordonR_Cape is online now  
Old 21st Apr 2019, 07:14
  #4188 (permalink)  
 
Join Date: Feb 2015
Location: The woods
Posts: 1
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.
bill fly is offline  
Old 21st Apr 2019, 07:28
  #4189 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 346
Originally Posted by GordonR_Cape View Post
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?
Bend alot is offline  
Old 21st Apr 2019, 11:10
  #4190 (permalink)  
Psychophysiological entity
 
Join Date: Jun 2001
Location: Tweet Rob_Benham Famous author. Well, slightly famous.
Age: 80
Posts: 4,697
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
Loose rivets is offline  
Old 21st Apr 2019, 11:34
  #4191 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 1,847
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

Last edited by safetypee; 22nd Apr 2019 at 06:04.
safetypee is offline  
Old 21st Apr 2019, 14:06
  #4192 (permalink)  
 
Join Date: Jun 2009
Location: Oxford, England
Posts: 297
Originally Posted by MemberBerry View Post
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 ?...
syseng68k is offline  
Old 21st Apr 2019, 14:31
  #4193 (permalink)  
 
Join Date: Oct 2017
Location: Vienna
Posts: 86
Originally Posted by syseng68k View Post
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.
derjodel is offline  
Old 21st Apr 2019, 14:42
  #4194 (permalink)  
 
Join Date: May 2010
Location: Boston
Age: 68
Posts: 413
Originally Posted by derjodel View Post
...

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'
MurphyWasRight is online now  
Old 21st Apr 2019, 17:19
  #4195 (permalink)  
 
Join Date: Mar 2019
Location: Bavaria
Posts: 17
Originally Posted by syseng68k View Post
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.
.
It's always the same story:
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.
TryingToLearn is offline  
Old 21st Apr 2019, 18:00
  #4196 (permalink)  
 
Join Date: Jan 2008
Location: Hotel Sheets, Downtown Plunketville
Age: 72
Posts: 687
Originally Posted by syseng68k View Post
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 ?...
Design and manufacture concepts are the result of mass market demands. Aviation is now a mass market form of transportation, seeking to satisfy a demand for ever cheaper fares for every destination against the ever increasing costs of every resource on the planet. Automation is therefore the way forward and that involves a cost for knowledge and learning from many mistakes. It was so in the past, where the process involved the misfortunes of many, so it will be in the future. This particular incident shows that until such time when machines are free from mistake, human fallibility shall remain. For reason that their fallibility is replicated in any machine they design and manufacture. Perhaps AI will resolve this weakness and we shall have machines designed by machines. Then we shall have fulfilled our pursuit for excellence. Don`t you remember when you were first instructed in Instrument Flying, I do. I was told trust your instruments.
Chronus is offline  
Old 21st Apr 2019, 18:01
  #4197 (permalink)  
 
Join Date: Jul 2011
Location: Canada
Posts: 55
Originally Posted by patplan View Post
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?
About 4,000 posts ago on this thread others cited previous MCAS incidents from NASA's ASRS. More recently, others backed me up on that from a previous post of mine.

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.
L39 Guy is offline  
Old 21st Apr 2019, 18:49
  #4198 (permalink)  
 
Join Date: Jan 2008
Location: Reading, UK
Posts: 10,665
Originally Posted by L39 Guy View Post
About 4,000 posts ago on this thread others cited previous MCAS incidents from NASA's ASRS. More recently, others backed me up on that from a previous post of mine.
To clarify, there are no MCAS-related events in NASA's SRS system.

DaveReidUK is online now  
Old 21st Apr 2019, 19:17
  #4199 (permalink)  
 
Join Date: Mar 2019
Location: Bavaria
Posts: 17
[QUOTE=Chronus;10452687Automation is therefore the way forward and that involves a cost for knowledge and learning from many mistakes. It was so in the past, where the process involved the misfortunes of many, so it will be in the future. This particular incident shows that until such time when machines are free from mistake, human fallibility shall remain. For reason that their fallibility is replicated in any machine they design and manufacture. Perhaps AI will resolve this weakness and we shall have machines designed by machines. Then we shall have fulfilled our pursuit for excellence. Don`t you remember when you were first instructed in Instrument Flying, I do. I was told trust your instruments.[/QUOTE]

Do we also need to learn again how tires are manufactured? Millions of cars are driving perfectly safe but still cheap chinese wheels crack because they are manufactured cheap and without x-ray check.
Hundreds of millions of cars have ESP, a system which could easily block single tires on the highway without a chance to react before hitting a tree. Still I have not heard of a single accident. Cost pressure on such systems (ESP, engine ECU, gearbox ECU...) is by orders of magnitude higher than in aviation. You're not counting fractions of cents in aviation. On the other hand lines of code are not considered cost-relevant within automotive, a programmer more or less does not really matter. It should be the same in aviation.

Almost every function within a car is single-point-fault tolerant if a defect would stop the car. Single point fault tolerance is not restricted to safety, but also extended to 'limp-home' to the garage and any other function which would be more than annoying in case of an error. So why the heck didn't they just compare 2 (already existing) sensors? Every system engineer would (if allowed to). Emission standards require such a 2oo2 to avoid abnormal emission (..of a single car in case of random HW defects).
In addition, EVERY sensor is usually range-checked. Why would you activate a 'stall-avoidance feel' if the AoA is at its mechanical limit which would mean the aircraft is flying backwards or is in free-fall?
Designing such a system in a safe way is nothing new, it is state of the art for >20 years. SW is controlling your car's engine and acceleration, brake (ESP), airbag, gearbox, there are fly-by-wire systems, trains, signals and so on. If you want to see state of the art safety:
This robot could break their necks or dump them into the ground with a fraction of it's available force. Instead it' perfectly safe.

But the process is costly and takes time. And it requires qualified engineers and a safety culture and a certain independence & priority between commercial interest and safety requirements.

To me it looks like Boeing was putting the priority on sales, not on safety.

Open any ISO/IEC on safety, you will probably find a list of sensor plausibilisation methods and how safe they are considered to be. The simple ones (range check, considered 60%) would have saved 1 aircraft, the better ones (2oo2, linearity... (90%/99%)) both.
TryingToLearn is offline  
Old 21st Apr 2019, 19:42
  #4200 (permalink)  
 
Join Date: May 2011
Location: NEW YORK
Posts: 540
Originally Posted by DaveReidUK View Post
To clarify, there are no MCAS-related events in NASA's SRS system.
Seen that the existence of MCAS was unknown even to the SW Airline pilots until the Lion Air crash, how would pilots report an MCAS related event?
etudiant is offline  

Thread Tools
Search this Thread

Contact Us Archive Advertising Cookie Policy Privacy Statement Terms of Service

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