Boeing changing Max software to use two computers
news.yahoo.com
news.yahoo.com
Yeah, I have a real problem with that.
A priori of a computer failure, you may have statistical reliability. But once it actually fails, the failure rate is 100% and a backup computer is needed.
Also, external AoA sensors fail all the time (like when a bird hits them), so the failure probability is very high. So we're not just talking about solid-state computer reliability here.
What also concerns me is that airliners fly at transsonic speeds. How would the AoA calculations be affected when the airplane is in a slip for some reason, and the AoA sensors are reading different values? What happens when MCAS goes berserk at high speeds (ie. near Mach 1.)
If MCAS wasn't even tested on takeoff, it sure as hell wasn't tested at Mach 0.8.
If the stakes are not clear ... besides the loss of life, an airliner crash often results in the bankruptcy of the entire carrier.
Source: commercially-rated airplane pilot who's studied high-speed aerodynamics.
In the case of MCAS, from what we have read so far, it seems this analysis was biased toward a non-catastrophic outcome (e.g. manageable through pilot action). This may explain why the statistical failure of a single computer was deemed sufficient. Now, assessors have upped the stakes, and the stats do not work anymore.
This indeed reveals a very serious problem in the RAMS process at Boeing, and exceed the scope of a « simple » software fix.
But sorry, just can't seriously take it on faith that your product is going to last 11 centuries at 20C.
By the time it gets to the marketplace nobody knows anything and we're all acting like the monkeys in the story with banana and the ice-water spray.
I reported the issue and the systems architect waved it off arguing that his analysis of the supplier data had proven that the MTBF for this component was over 500 thousand hours.
Few months later, a task force was established by the project management to look for an alternate supplier for this component after it became obvious that its failure rate was significantly higher than advertised.
It is entirely possible that this is a success story of a lower-level engineer raising an issue that the higher levels then addressed.
Just because no one immediately jumps and say "by golly, we have to get rid of component X right now!" doesn't mean that the issue didn't begin percolating vertically and horizontally, ultimately resulting in a large-scale corrective effort.
Then I did not take the high road. The guy was very obnoxious and I had other issues to address. So I let it slide to maintain my "this is important" quota for other matters.
And a couple of months later, when some units failed on the test aircrafts (I insist on the fact that this was not a critical system), I had an issue report showing that the issue was observed during supplier-side tests and then ignored.
Take a regular ceramic resistor. I'd bet that if you kept it in a temperature controlled sealed box, it would last 2000 years.
I would possibly even reckon it might last 200,000 years.
Ceramics are so so so inert, and as are metals as long as they're away from oxygen.
>“Only one computer was used in the past, because Boeing was able to prove statistically that its system was reliable, the person said.”
Years back, my father co-wrote a paper on the Space Shuttle Challenger showing issues with the statistical thinking at NASA:
http://www.math.montana.edu/shancock/courses/stat401/Dalal_e...
I wonder what statistical techniques Boeing used, and how defensible those techniques were.
I suspect they're using that sense of the word "proven", as opposed to a formal software proof.
I can understand a backup if the first fails, but why two identical systems contemporaneously computing?
But if there's a human in the loop and a manual alternate control pathway, detecting a disagreement allows you to cue the manual operator and transfer control to them. Or fall back to a much simpler system of computer aid.
With 1, hardware failures are extremely hard to detect at all, as even your computational checks for internal consistency are subject to mutation.
Unless all 3 different give different results, two failures and one correct.
IIRC the shuttle had a 3+1 system 3 as a cohort with voting and if they couldn't reach consensus the 1 was a minimal system that could keep the lights on.
They said it's common now in critical systems to use three computers and ignore any single computer that disagrees with the other two.
Boeing probably has a similar thing for the fly by wire fighter jets they are involved in but there passenger planes are still mainly directly controlled by the pilot.
Some material: https://www.researchgate.net/publication/26587285_Challenges... https://www.researchgate.net/publication/220845884_Approache...
I spent several years doing stats/BI in the medical manufacturing industry and have on many occasions done analyses that showed what my employer wanted and would stand up to scrutiny, but if my employer wanted the opposite outcome of that analysis, that would also be possible and also stand up to scrutiny.
The best way to address this is to remove any financial/business incentives form the analysis, but that's not really feasible most of the time and also requires larger/more expensive teams that are capable of internally challenging their own work.
https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statist...
Despite the title, it's mostly an essay on why visualization and presentation are critical to any statistical treatment.
I think it's one of those difficult skill combinations. You want someone extremely well-versed in statistics, plus someone capable of giving a damn about accurate presentation, plus someone with the UX intuition to make the correct choices to make something readable without sacrificing accuracy and important nuances. And if that "someone" is actually two people, you run the risk of telephone misunderstandings as work passes between them.
Which is a tall order.
Made taller by the (as you note) different kinds of audiences: simply ignorant, aggressively biased, rushed, etc.
I can't even imagine designing aerial vehicle autopilot without redundency. The stakes are too high...
I would be interested in having a look at the statistical model they used to prove 'the system was reliable with zero-redundancy'. While designing these systems for ships the only way we were able to get an error probability near zero was when we used triple redundancy.
Were you able in some cases to maintain isolation all the way through from sensors to actuators and design such that a single failed one (in a worst case failure mode) could be overcome by the rest?
The way this is done is that 2 of 3 computers need to 'agree' on the final decision in order for it to be considered the correct one - there isn't a single point of assessment, but rather a consensus that must be formed from the results of all 3 computers. Ideal case, all 3 produce the same results.
This has worked successfully for decades. What's changing now, is that those 3 computers are now no longer the same architecture - you'll have a PPC and an x86 and an ARM-based CPU all attempting to agree to the same data, in order to prevent systemic failure throughout.
> What's changing now, is that those 3 computers are now no longer the same architecture
I think / hope this idea will die a well deserved death. Rail systems must face 25 years lifetime and with such design obsolescence headaches are multiplied by 3. In addition this creates bugs and integration nightmares.
And on top of all that, we have known for decades that CPUs can be protected against systemic failures using the vital coded processor technique [1].
Note to the curious: this is one of the most fascinating piece of software I have ever encountered. Make the software resilient to any hardware fault through the power of arithmetic...
[1] https://www.semanticscholar.org/paper/Vital-software%3A-Form...
There are track-side systems still running on 80386's, and a maintenance infrastructure in place to keep these systems running for at least a few more years, before they are replaced with the newer, Pentium-based systems.
Design obsolescence is not built-in for these systems. Long-term ability to support is more important. Also, burn-in period. Many bullets (SPECTRE, etc.) have been dodged by relying on older, more proven, more tested technologies ..
Actually, it’s one of the required extension to ISO 9002 by IRIS, the quality framework for rail engineers.
Components are chosen not only for their function but also for their supply availability in the long run. One of the things we look at is « multisourcing »: how many different folks can provide this stuff. The more the better.
Going back to this great idea about hardware diversity (that is absolutely not a general rule in railway): with an architecture requiring 3 different hardwares, you essentially shoot yourself in the foot. Instead of having 3 suppliers for one component, now you need to find at least 6 for 3 components. And the probability to face an obsolescence issue has basically tripled...
And for what? It’s proven useless by science... :b
And as far as dodging bullets, railway is no better than SCADA. Older tech means older vulnerabilities stay in place, and there are countless people on HN that will tell you it’s /not/ a good thing. I don’t think we dodged, I think we were just lucky. There is a reason why now cybersecurity is making its way inside the last revision of standards.
I don't know where you're working in the industry, but in my company (THALES) its definitely a thing, and we are absolutely working on diversifying the 3-of-3 and 3-of-5 configurations away from Intel.
And maybe we're talking about design obsolescence in different terms, but yeah .. 30-year old CPU's are still being shipped to customers, yo. They WANT it, so.
It’s a different thing than saying you need hardware diversity in a majority vote system to achieve better safety. That is demonstrably false. For example, Siemens VCP is /proven/ to be safe and it does not even use a majority vote (see my previous comment for a reference to the VCP)
I prefer not to involve my employers on HN. What I write here is my opinion only.
As for your last remark, let’s be careful in assuming what customers want. The fact that they have to live with obsolete stuff does not necessarily mean they are super happy about it.
Diverse voting node architecture requirements are designed to prevent hardware bugs from crashing trains, not software bugs.
>Siemens VCP /proven/
.. and yet, it still crashed trains.
>What customers want
Its not obsolete if a customer wants it.
Customers want older CPU platforms because the tooling and industry required to support them in the field is long-entrenched, and costs of upgrading to "newer, sexier CPU's", not really worth it if the lesser platforms are capable of doing the job...
Do you have evidence for that claim?
Rail control systems run untrusted code? Why not dodge Spectre by not running random code in the control system?
« Analysis of Faults in an N-Version Software Experiment." Susan S. Brilliant, John C. Knight, Nancy G. Leveson (1990)
And I found a PDF version here: http://sunnyday.mit.edu/papers/nver2.pdf
>student programmers
>toy problem
To me, this proves very little about how independent development teams would perform with experienced engineers working with present day design tools. It's possible that the results would be the same, worse, or better, but I hope this isn't the most recent research that's been done on this.
The main issue with this approach is of course - cost. So the question is whether having two systems with uncorrelated fault paths is worth doubling the development expense.
I find all the different domains of programming endlessly facinating.
Safety Critical Systems Handbook:
https://www.elsevier.com/books/the-safety-critical-systems-h...
IEC 61508 Compliance Guide:
https://www.perforce.com/resources/qac/how-comply-iec-61508-...
ISA Safety Series:
https://www.isa.org/standards-and-publications/isa-publicati...
There is no system 100% efficient. Even a small error rate over the standard ~20yr service life isn’t a guarantee a failure won’t occur. Considering the max are refurbished 737s, wouldn’t more precaution be taken?
Compare to a Tesla autopilot: it can work 99% of the time, if at 1% of the time it slows down and gives up. It can’t crash into oncoming traffic 1% of the time. The failure mode matters.
Correction needed: every part in a 737-MAX is new; they are not refurbished older 737s. The MAX are supposed to be brand new “fly-alike” planes that makes replacing older 737 models with something more efficient easier for the airline.
Still boggles my mind how utterly incompetent and borderline malicious everybody involved in designing and implementing this system are. I wish we’d see some people jailed and Boeing hit with billions of dollars fines but chances are slim.
I'm sure each decision seemed logical to the person making it. But from a bird's eye view, it gives the impression of poor coordination - Team A [hardware] thinks "clearly we need multiple AOA sensors for redundancy". Team B [software] thinks "AOA isn't all that important, we barely use it and failure is non-critical. Sensor fusion is hard, let's go shopping!".
Was there actually an a-priori specification that AOA sensors must always be on the pilot's side? If there is such a specification, I can't find it - Google searches for stuff like 'AOA sensors pilots side' return mostly articles about the MAX. Nor can I see a good reason for it that is concordant with the existence of paid extra feature of a disagreement light - no particular significance or weight is given to the pilot's side sensor.
It sure feels like this is a post-hoc rationalization for only writing software to handle one AOA vane at a time despite being equipped with two.
There are always hardware errata. But they're patched and papered over with firmware.
Essentially, I'm operating a system, and if you can guarantee the system functions as documented -- I don't really care how the sausage gets made.
What I would care about is if a pilot (in this metaphor, my compiler, I guess?) doesn't feel comfortable operating the system.
And I think the pilots' unions have been interesting in this. Because they don't really want to slag their employers (the airlines), but they're willing to push back hard on Boeing for essentially the same issue.
A lack of transparency about and sufficient training in differences.
> Essentially, I'm operating a system, and if you can
> guarantee the system functions as documented -- I
> don't really care how the sausage gets made.
The thing about the incentive, though, is that a software fix ticks the "we did something" box, as long as it improves the issue to any degree. That it does any good at all, combined with the lower cost, can give management (or ass-covering employees) enough substance to rationalize the decision away.
I doubt anyone at Boeing would willingly risk customer lives. But if they are working under pressure, and can say "well, we did do something to address the issue," that can lead to bad decisions.
I believe that's been changed too (see: AOA sensor).
This article is about flight computers, which are the machines that consume sensor input.
There are already two sensors. There are also already two computers. Each computer is already connected to one (and only one) of the sensors. Therefore, making the software use both computers at the same time allows using both sensors at the same time, with no hardware changes.
It includes e.g. a description of FAA bit-flip testing to induce incorrect system behavior that Boeing intends to solve by using two computers.
This is called Single Event Upset. For all those of you that aren't in the industry, essentially the problem is that any bit inside the flight computer (RAM, cache, NVM, registers - ANY bit) can change state randomly at ANY time. It's rare, but when you get into millions of flight hours, it WILL happen. The software and hardware have to be designed to mitigate problems caused by this behavior.
How are we sure there aren't local bursts of cosmic rays that would make suddenly a few of those Single Event Upset, for example when there are some high likelihood of seeing northern lights ?
How do you test your hardware and software to show that you are indeed cosmic-ray proof ?
Online software tests check for cosmic ray bit flips about 1000 times a second, in addition to whatever hardware mechanisms are in place to detect this (ECC, etc.) This is a standard module in most SIL-4 applications, where 2 of 3 consensus model is being used.
What I don't understand is why Boeing aren't using 2-of-3 computer architecture in this application - or maybe they are, and the '3 voting units' are considered to be 'one computer' and they've just added another one to be sure.
In rail transportation systems, this is taken even further by using 2-of-3 configurations where each computer is a different architecture completely ..
Does that mean we will find the MCAS in the 737 MAX 8 MMEL (Master Minimum Equipment List)? (Used to be here but right now it's not loading: http://fsims.faa.gov/wdocs/mmel/b-737-8_rev%200.pdf)
Isn't this the single biggest failure point of the whole affair? Adding a critical component which can bring the plane down (as it has happened twice) but not making it redundant?
One can perhaps argue (pardon the roughness of my analogy) that if pilots aren't trained to not open the door during the flight, and then do open the door during the flight, then it's a training issue.
But this analogy doesn't apply, because while the door is not motorized and cannot open by itself, the MCAS is a computer system which can fail (not just because of a faulty AoA sensor, but e.g. because of a chip failure or a software bug) and then actuate the trim into a dive where the pilots aren't able to fix the issue manually anymore due to high wind pressure.
So I would not expect MCAS to be listed in the MEL since it's required for safe flight.
We'll see.
It’s realistic to build aircraft where software is required to fly said aircraft depending on the flight dynamics, and the pilot(s) are fully aware of what’s running. But that changes the type rating and blows Boeing’s regulatory sidestep out of the sky.
Flight computers are a fundamental part of normal aeronautical design.
Asking Boeing to fly a Max without MCAS would be like asking you to write a bug free C++ program... with a compiler with no error messages or validation.
https://en.wikipedia.org/wiki/Air_France_Flight_296
https://www.telegraph.co.uk/technology/9231855/Air-France-Fl...
The following planes (among others) all translate flight inputs. Airbus A320, A330, A340, A350, A380; Boeing 777. https://en.m.wikipedia.org/wiki/Flight_control_modes
A non-Max 737 doesn't need MCAS because it already behaves like a 737.
Essentially, most replies on this boil down to people being shocked (shocked!) that computers are currently helping all planes fly. I'm not sure how they thought AEs were getting efficiency gains while physics stayed the same...
Hundreds of people were killed due to a bad implementation of a deeply irresponsible and insensible approach to make money by skirting flight safety regulation. The bad implementation was in part software, but nobody is confusing that aspect with the whole picture.
The 737 MAX does not need MCAS. Nothing needs MCAS. Boeing executives wanted the money that MCAS made them.
If that were the case, then you'd see people debating the relative merits of SDLC approaches and organizational blinders to letting bugs slip through.
In reality, that's only about 20% of any Boeing discussion.
80% is outrage about how Boeing could have released such an "obviously flawed" airplane that required flight computer adjustments. And misunderstanding that Boeing pivoted from a clean sheet design to instead build exactly what the carriers asked them to.
Generally, HN comments are pretty good, but the amount of kneejerking in Boeing threads in lieu of informed discussion is terrible.
Edit: Although reading through new replies this morning, it's nice to see voting mostly sorted the technical wheat from the chaff.
If I read this correctly you're implying a 737 Max doesn't behave, aerodynamically, as that a non-Max 737 does? And if we follow that line of thinking since non-Max 737 don't require MCAS to behave appropriately then the 737 Max is not a 737 airframe and it should be recertified as something else, no?
I'm in no way "shocked" computers fly and/or help fly airplanes. I am shocked so many comments defend the gross negligence by Boeing, however.
Remember that in all of the needless death the 737 Max is attributed with absolutely zero deaths were because of a flight computer. The real root cause of the 737 Max crashes are Boeing executives and FAA personnel making cognizant choices to allow process to be skipped in the vain of profits and loss avoidance. I believe we'll see this, at some point, no different than the commonly referenced Challenger failure [0].
[0] https://www.breakingthewheel.com/root-cause-analysis-five-wh...
Sophisticated flight computers are only necessary for aircrafts that are inheritenly unstable (fighter jets) that require special flight characteristics.
Safe commercial, and private aircraft are built to be inheritenly stable. It's less complexity.
Sure we've added fly by wire, or dynamic power controls. But those are relatively straight forward.
Changing the center of gravity of the plane and therefore introducing different (dangerous, risky, and unsafe) flight charectierstics is a major issue.
Depending on how exactly you define it, pilot error is either the #1 or #2 cause of commercial plane crashes. FBW systems seek to reduce or eliminate that.
Auto-trim has been around for years, and failures are usually more annoying than serious. But the 737 MAX's auto-trim had far too much control authority, and was being used to compensate for bad handling characteristics, making it a flight critical system.
Google the 'Murray Gell-Mann Amnesia effect'.
Edit: https://en.m.wikipedia.org/wiki/Gell-Mann_amnesia_effect
https://qph.fs.quoracdn.net/main-qimg-0f650e809408f3962a1ed0...
How do you argue what they did and are continuing to do is just in this situation?
The problem is now the lack of public trust in their work. They might fix the software, but how to prove they're not lying again?
You may find that OK, if you wish. You may choose to do nothing.
We don’t, and won’t.
Is the MCAS the only place they messed up? Will this fix truly be 100%? Remember that their first attempt at a fix was rejected.
When you see one bug, that’s often an indication that more are nearby.
If, hypothetically, an Airbus had a problem in the same region of flight would it even be detected in flight testing? As far as I'm aware it wouldn't be as direct mode is a reversionary mode intended to get the aircraft safely on the ground.
They cannot be greater than a set level (essentially, an average strength pilot), particularly when performing critical manuevers.
This was actually the whole reason MCAS was engineered in the first place: to lower the effective stick force required to within the acceptable limits in certain scenarios.
So presumably Airbus in direct mode could still have similar issues flagged in direct mode, if the plane behaved in such a way as to require unacceptably high stick force to move control elements (even if it was a 1:1 mapping).
One thing I'm not sure about is whether Airbus would have to demonstrate proper controllability (i.e. adherence to control force regulations) in all phases of flight and corner conditions.
You could have a scenario where by they have a complete control reversal on the approach to stall but under normal law the pilot would be oblivious. This would obviously show up in direct law.
I'd hope they would have to demonstrate both things: (1) that a given mode can or cannot be active in a certain scenario, and (2) how the plane behaves in all tested scenarios under all modes potentially active.
Is there a reason this necessarily wouldn't be the case?
But that's not commerical aviation - that's combat aviation. That's "you fly faster or the missile catches you and you die anyway" aviation.
Building intentionally unstable airframes for civilian aviation is a very different proposition. And unrelated to the use of fly-by-wire.
> Airbus jets carry passengers and have been fly-by-wire for decades
a response to
> instability of high performance jets
?
Nice strawman. We are talking about the MAX not the 737 in general.
Why don't you explain why previous variants of the 737 didn't require MCAS?
The trim equivalent of MCAS would be some elevator trim that ensures the excess AOA potential of the MAX could not occur, if set correctly. That is how a stable aircraft behaves. MCAS is a computer override to compensate for a condition that should not really occur in the first place.
I agree, so where is your comparison of 737 Max and non-Max airframe? Because we have real data, including death toll, that shows one airframe is not like the other.
> Boeing's mistake was in underestimating the burden placed on the pilots in a runaway trim situation, and assuming that pilots could execute a recovery procedure correctly that remained unchanged from prior iterations but that had also been rarely needed on prior iterations (vs. the MAX, where MCAS failures were common enough that an average pilot might actually need to execute the procedure).
This is not the whole truth as we know in this situation MCAS 1.0 was a critical flight system with a non-redundant data source. The "burden" placed on pilots was that the system did not have sufficient and trustworthy information to prevent a faulty and inadequately designed system (MCAS) from crashing the airplane. Furthermore since MCAS is not required, again, on non-Max airframe it seems your assertion that you have background in aerospace engineering is egregious because you should understand all 737 Max are currently grounded because the 737 Max is not a 737 airframe and should be recertified as such.
Balloons, paper jets...
Since both crashes were caused by malfunctioning software, this doesn't tell you anything about the fundamental soundness of the airframe.
> We know the MCAS was a workaround to an aerodynamics problem
MCAS was a workaround to make the plane handle more like a 737. The existing handling was fine by itself (not 'fundamentally flawed'), it just didn't match the 737.
> How do you argue what they did and are continuing to do is just in this situation?
I don't see where I did that. I just don't think there is any evidence that the airframe is actually fundamentally unsafe.
It's pretty clear that the author of the comment I originally responded to was not considering software.
See: https://en.wikipedia.org/wiki/Air_France_Flight_447
https://aviation.stackexchange.com/questions/62338/why-did-a...
And that pilot crashed a perfectly fine airliner after he lost situational awareness and then did the one thing you should never do - pull the steering column back in a mad panic until the plane stalls.
Regardless, this still seems like the right path (recertification). It seems the FAA is still being strong armed by Boeing. Why? Put these people in prison. Shut the 737 Max down. Make Boeing face the music. They need to fail to get the point, apparently.
Boeing have essentially painted themselves into a very costly corner. The FAA or congress could do a "certify it just for Boeing" action and the plane might even, maybe be safe then. But how many airline customers would want to fly in it?
Yes, a replacement of the 737 is more than overdue, but it is also 10 years away. A rushed new design could be way more dangerous than the known design of the 737.
I do hope Ralph Nader sues the pants off Boeing for killing his goddaughter due to their cheapness and shoddy products.
Yaw dampers are workload mitigation devices; not compensatory for design flaws. Dutch roll is inherent to any controllable aircraft. Violation of 25.173 in the form of decreasing stick force response curves on approach to stall is absolutely not the same beast.
Design criteria are prescriptive, and I'm not aware of any line of regulation that says an uncertifiable airframe can be made certifiable by the addition of a computer. These handling characteristics are not undesirable, they are uncertifiable according to regulations as written, and intended.
Even Airbus meets these minimum design criteria at their minimum automation threshold. Boeing for some daft reason seems to be being written a pass to selectively ignore regulations around Civil Transport Aircraft certification based on some serious levels of sunk-cost fallacy.
I don't believe in supporting limp-wristed minimal compliance when it comes to safety critical engineering. Not going the route of designing out the behavior requires the implementation of system after system, after system to compensate, with each link in the chain adding additional risk for failure over and above what doing it right in the first place would have created.
Whitewashing wins no one but Boeing anything. Please remember that. We entrust these people to design and manufacture safer, more efficient, machines. Instead of living up to that mission, they jeopardized it in the name of optimizing the revenue/profit generating characteristics of the company.
I get the reluctance to throw away a potentially recoverable airframe, but I'm dead against letting anyone whitewash over the fact the plane is more dangerous than it needed to be because someone wanted better numbers on their held stock, and was willing to put a more dangerous product on the market in able to do it.
There has never been been an accident due to the airframe's pitch instability and MCAS not accomplishing its intended function. Both of the accidents happened because the MCAS system itself failed and activated when it shouldn't have.
If they had made a reliable MCAS (by which I mean the whole system from sensors to controls to actuation and pilot interface), there would have been no problem.
Please stop perpetuating evening time TV show fearmongering bullshit.
The eli5 explanation of the MAX 8 MCAS incident is as follows:
* Boeing wanted MAX 8 to have the 737 type rating. This means it must handle and fly just like other 737. This would allow existing 737 pilots to fly the MAX 8 with no additional training. This was part of Boeing's financial advantage.
* To achieve the efficiency it has, the MAX 8 has pretty large engines. Because they wanted to keep the airframe like other 737, they couldn't lift the wings to accommodate. Instead they moved the engines closer to the body.
* Moving the engines closer to the body increased the pitch-up characteristic at high AOA. Not so much as to make the plane unsafe (the 757 has a more aggressive pitch-up characteristic). But enough to make it sufficiently different from other 737 to invalidate the type rating.
* Boeing adds MCAS to augment the pitch-up and make it handle like other 737. They get their type rating.
* MCAS software validation happens with the assumptions that it's not a flight critical system, so constraints are relaxed. It passes.
* Flight testing reveals that MCAS needs significantly more pitch authority to do its job. It's updated to get that pitch authority. MCAS now becomes a flight critical system after these changes, but is not re-evaluated as one.
The airframe is fine. If Boeing gives up the 737 type rating and drops MCAS, they could have the fleet back in the air within a few weeks after pilots train for it. It just would cost their clients a lot more than originally promised and be a financial disaster.
https://www.youtube.com/watch?v=CD0JabYjF3A&t=
https://www.quora.com/Is-the-737-Max-supercritical-that-is-i...
The 737 MAX was designed so as to keep the type rating. The design would be different, and very likely fundamentally safer if keeping the 737 type rating were not a goal. A perverse incentive from the start. So I would not dismiss the claim that the 737 is "fundamentally flawed."
There's a million things that went wrong with the MAX 8 debacle, serious things that need to be addressed after the industry takes a hard look at itself. But there being something wrong with the airframe isn't amongst them. That meme has no grounds, isn't supported by anyone at all in the industry, and originated from clickbait spamblogs and late night tv shows that feed off FUD.
> The design would be different, and very likely fundamentally safer if keeping the 737 type rating were not a goal
Errrr. The design is may not be maximally optimal (what does that even mean?) because of type rating pressure, therefore the design is fundamentally flawed? Please stop. You're perpetuating clickspam driven fake news and distracting from the real problems.
Really?
Would you like to supply some names, or provide some whitepaper for that?
https://www.seattletimes.com/seattle-news/times-watchdog/the...
Btw, the entire cause for MCAS being implemented is a desperate attempt to comply with FAR 25.173. If the non-certifiable behavior hadn't been there, there would not have been an issue.
But wait, there's more!
https://www.nytimes.com/2019/07/27/business/boeing-737-max-f...
So we even have severe concerns over whether Boeing overstepped bounds in the safety process by approving their control line setup in spite of FAA concerns anyway.
Some gems from that.
>F.A.A. managers conceded that the Max “does not meet” agency guidelines “for protecting flight controls,” according to an agency document. But in another document, they added that they had to consider whether any requested changes would interfere with Boeing’s timeline. The managers wrote that it would be “impractical at this late point in the program,” for the company to resolve the issue. Mr. Duven at the F.A.A. also said the decision was based on the safety record of the plane.
>Engineers at the agency were demoralized, the two agency employees said. One engineer submitted an anonymous complaint to an internal F.A.A. safety board, which was reviewed by The Times.
>“During meetings regarding this issue the cost to Boeing to upgrade the design was discussed,” the engineer wrote. “The comment was made that there may be better places for Boeing to spend their safety dollars.”
>An F.A.A. panel investigated the complaint. It found managers siding with Boeing had created “an environment of mistrust that hampers the ability of the agency to work effectively,” the panel said in a 2017 report, which was reviewed by The Times. The panel cautioned against allowing Boeing to handle this kind of approval, saying “the company has a vested interest in minimizing costs and schedule impact.”
>By then, the panel’s findings were moot. Managers at the agency had already given Boeing the right to approve the cables, and they were installed on the Max.
So, forgive me if I question the veracity of "most in the industry have figured it isn't a big deal", and even if they have, I question whether or not that decision comes from some level of just wanting to return to business as usual with minimum interruption or action/further regulation based on the coming to light of the scale of regulatory capture that has been uncovered by this debacle.
The physics and presence of MCAS at all don't lie. The plane could not be certified without it. Personally, I deem an airframe to only encompass the physical structure without automation, and that assumption seems to be well received by those I know who have worked in aviation circles previously.
Given that when I raise concerns with them, I universally get some variation of "what the hell were they thinking?," I'm not terribly willing to accept that a large portion of the active industry is necessarily making the most impartial judgement given that their livelihoods may very well be adversely effected by the fiscal failure of this plane.
My sources include a former safety investigator/tech, and someone who worked with a maintenance squadron. So make of that what you will.
Furthermore, I'm willing to tolerate some leniency with stretching regulations a bit, but not to the extent of normalizing deviance for the sake of expediency. Down that road lies too much catastrophe.
Now I'll admit, I was one of the early central repeaters of the artificial feel system theory; I didn't have access to good technical docs, but apparently someone at the Seattle Times was able to find some corroboration, but I've done my damnedest to keep my reasoning constrained to my enthusiast level understanding of aerospace engineering and aviation, which has been rapidly expanding in my efforts to understand how something like this could happen in an industrial vertical famous for it's capacity to generate some of the safest machines on the planet. Just that reasoning alone is enough to at least get me questioning the sanity of the design decisions that have transpired w.r.t the MAX.
This isn't FUD. People need to pay attention.
https://news.ycombinator.com/threads?id=salawat&next=2043595...
Also, it’s the ‘airframe is fundamentally flawed’ meme. That’s an important difference.
1) The 737 MAX is a perfectly viable airplane without the MCAS, whose sole purpose is to not invalidate the type rating;
2) The 737 MAX has dangerous, uncertifiable flight characteristics without the MCAS; namely, the stick force gradient inverts at high angles of attack. One comment[1] in this thread has even linked the relevant legislation[2].
So, which is it?
[1] https://news.ycombinator.com/item?id=20607242 [2] https://www.law.cornell.edu/cfr/text/14/25.173
1: The 737 family, including the 737 MAX, still use manual/hydraulic controls, not fly-by-wire. A computer failure isn't supposed to be as catastrophic as it would in a fully fly-by-wire system. 737 pilots are already trained on other automatic system failures, such as a pitch trim motor runaway.
2: The original design of MCAS had a limited scope - stop pitch instabilities from causing an uncontrolled pitch-up into a stall in high AoA and high power regimes, such as just after takeoff. It read from both a G-sensor and the AoA vane and both sensors had to be reading excessive values for the system to trigger. This was probably the justification for not requiring higher levels of reliability.
3: The plane was found to have handling issues in slow flight regimes. In order to improve the handling, Boeing engineers modified MCAS to be active in more of the flight regime, removing one of the sensor readings. Now it would trigger if it detected the plane was near a stall, even in level flight without a high G loading. It is unclear whether MCAS was recertified within Boeing for continuous use. Wikipedia states "The FAA did not conduct a safety analysis on the changes. It had already approved the previous version of MCAS, and the agency's rules did not require it to take a second look because the changes did not affect how the plane operated in extreme situations."
4: Pilots could not disable MCAS without disabling electric trim control. In at least the LionAir case, the pilots did disable the electric trim, but were unable to re-trim the plane manually against the aerodynamic forces of their dive. They re-enabled the electric trim to re-trim the aircraft, and MCAS re-triggered and put them back in the same situation. Remember, these aircraft use manual controls. The pilots need to put a serious amount of force into the control column when the plane is out of trim and at a high airspeed. This greatly diminishes their ability to do anything else.
5: Both accident aircraft were missing an optional safety feature - the AoA disagree warning. Both aircraft experienced a failure of one of their AoA vanes. I don't recall whether these failures happened in flight or before the flight, but such a warning would have likely stopped the pilots from taking off.
6: The single computer issue was not uncovered until simulator testing after the crashes. It is not directly related to the MCAS problems.
Wikipedia is your friend, as usual. https://en.wikipedia.org/wiki/Maneuvering_Characteristics_Au...
Here's even more detailed information: http://www.b737.org.uk/mcas.htm
Interestingly, Airbus as a consequence of the events reviewed their flight software and also found an issue they are quickly correcting, but it seems that no planes are grounded as a consequence.
#6, combined with all the institutional issues people are aware of, makes it quite likely that the 737 Max has a bunch of issues hidden away. The MCAS issue was only the most obvious and easiest to trigger, which is why it led to 2 crashes. If those planes had been around longer, and if they hadn’t been grounded because of the MCAS issue, it’s likely some of the other issues may have also caused a crash.
I have second thoughts about many of the companies I’ve invested in over the years, but Boeing right now takes the cake. I’ve dumped my shares. Hopefully there are some criminal investigations at some point if our leaders in Washington could stop dancing to the tune of whichever company throws them a bone like the dogs they really are.
Guess what? They don't care because it doesn't matter.
You really can't avoid their airplanes without avoiding air travel.
My guess is there are others. My guess is that orders will be cancelled and there'll be a shift towards airbus (oh!there's one!)
I'm tempted to apply my first ever downvote to this apparently witless comment, but perhaps you meant something more subtle?
I read that as ”statically” (thought it meant formally) and was really impressed by how advanced that sounded! Then I read it again and saw statistically. Less impressive.
The American way is using statistics to argue that something is not dangerous in a meaningful way (for example several magnitudes less likely than being hit by lightning). There is even a white paper by ABB arguing that safety controllers should be allowed to be purely one-channel architectures, because reliability is so good. Most people in the field would take that as humorous.
And so the "modern" standard 61508 is a bit of a hybrid. There are still architectural elements (hardware fault tolerance numbers etc), but front and center is also statistics, namely the SIL levels.
This is more of a "if it stops working the pilots have to fly more conservatively until it is fixed" thing. It apparently is generally considered acceptable for such things to not have triple redundancy, as long as a failure will be detected so the pilots can deal with it. Two computers is good enough for that.
Which still doesn't make sense from a redundancy perspective: What do you do when 2 systems disagree? Which one is right?
I guess you could shut it down, but would be better to have an odd number of systems and take a majority result while displaying an error light.
I thought it was the wings.