That triple-sensor system isn’t foolproof, however.
In 2008, on a customer-acceptance flight of an Airbus A320, two of the angle-of-attack sensors froze and those two sensors then outvoted the third. When the pilots went to demonstrate the stall-prevention system, they were not aware of the malfunctioning sensors. The plane crashed, killing the seven people on board.
The same problem arose again on a 2014 Airbus A321 Lufthansa flight leaving Spain. Eight minutes after takeoff, two of the angle-of-attack sensors froze at the same pitch. This time, after a drop in altitude, the pilots were able to regain control and complete the flight.
Any automation system can fail, and when that happens, hope that through some combination of luck, skill, experience, and training, the pilot will get the plane safely to the destination.
Sounds like Airbus airplanes are much, much safer to fly on than Boeings. Why would anyone trust a company which thinks it's OK to have a flight control system that only uses input from a single sensor that's known to fail?
That's what AoA is though. It's the relative wind angle over the wing. The wind matters. You can't calculate AoA simply from pitch or vertical speed or something like that.
Another way would be to stick a tab in the slipstream, and measure the pressure on its leading edge and both sides. Or just put a strain gauge on the mount of the tab and measure the bending forces (and this would have no ports to freeze or moving parts to jam). I bet there are lots of ways.
P.S. I bet you could even put a strain gauge on the wing spar to measure the bending force on the wing, couple that with other inputs like airspeed, and come up with a reasonable AoA value.
The problem with such approaches is that you have to model all the environmental and performance factors that could cause an identical pseudo-AoA to be calculated, in all flight modes. And to do that you need a range of sensors, all redundant... so now you need additional input validation and sanitisation.
For example, measuring slipstream over the wing is not sufficient. You need to known the pressure ratio between above and below, so there's two sensors. But airflow over a wing is not contiguous or straight, so you need more spanwise sensors to start averaging. And the inboard wing will stall first and give erroneous data, so you need to detect that and disregard it...
Rather than just measuring the raw value at source.
No need to measure pressure at the top and the bottom if you use a strain gauge on a wing spar to measure the net force bending the wing.
I'm sure a function can be constructed that takes that input, along with the airspeed, and produces AoA. It can be used as a crosscheck with the AoA sensors. Since it takes airspeed as another parameter, it can also crosscheck the pitot tubes.
I've had to do a bit of functional safety stuff recently and one of the things they focus on are "common cause failures" (of which this is a perfect example - if one of the sensors freezes, the others are likely to do so as well). If you want to be sure something works, it's not enough to just have two or three copies of the same system. You have to have redundancy in manner of operation as well.
To be specific, I'd call that functional redundancy, versus hardware redundancy. Be able to get the same thing done in different ways.
NASA's Genesis mission was bit by this a while back. It had redundant parachute sequencers for a sample return capsule, but they were all assembled identically and with the G-sensors backwards. Consequently, they all failed in exactly the same way.
If there are three of the same type (make/model?) of sensor teaming to vote on the status being measured I'm not suprised that they can suffer the same failure (iceing) at the same time causing an incorrect state to be upvoted.
I would have thought that for any condition there would be more than one mechanism available to sense it. You could get different devices to vote on what is the real condition.
This has been done for years in visual cockpits with regards to an artifical horizon. The pilot only has to look out the window (assuming visibliity) to confirm what the instrument is reporting. Of course when the pilot loses visibility and starts to rely on their inner ear for "level" bad things can happen.
Many more simple planes, especially things like gliders, have a simple ball bearing in a curved tube to indicate "down" as well as the more convential artifical horizon.
Are you talking about a turn coordinator? That doesn't show "down." The sum of forces acting in a coordinated turn will keep the ball centered even though the airplane is banked.
Also I'm not sure what you're talking about with using the real horizon as a backup to the artificial horizon. It's not meant to be a redundant setup. Artificial horizons aren't required for visual (looking outside) flight, and relying primarily on the instruments in visual flight is an error.
In clouds/poor visibility, the cross-check for the artificial horizon is provided by the other flight instruments: airspeed, altimeter, turn coordinator, vertical speed indicator, and directional gyro (or their equivalents on an electronic display).
The point is that you are using a different type of device to cross check the reading from the first. In the case of the faulty sensor, it sounds like they are using the same type of device therefore conditions that impact the effectiveness of that device will likely impact more than one of them.
Triple-redundancy isn't 100% foolproof, but it is a lot better than two potentially-faulty sensors.
I know this isn't a great example, but triple redundancy is enough of a design cornerstone that Arthur C. Clarke made it one of the defining features of Rendezvous With Rama, a classic sci-fi story about an Oumuamua-like object that people manage to land on:
>It was now strikingly apparent that the "city", like so much of Rama, was triplicated. It consisted of three identical, circular complexes or superstructures, rising from a long, oval foundation. Photographs taken from the hub had also indicated that each complex was itself divided into three equal components, like a pie sliced into 120-degree portions. This would greatly simplify the task of exploration; presumably they had to examine only one-ninth of [the city] to see the whole of it.
It doesn't exactly sound like a new or controversial idea, you know?
The problem with this idea is the "identical" aspect of each redundancy. If it's identical, then it will likely suffer from the same failure mode at the same time as the others. In the case of the AoA freezing, that's exactly what happened.
A more robust idea is to have three redundant subsystems, each different.
Yeah, but I get the feeling that it's more of a way to ensure that you probably get at least two components that will 'burn in' well and hopefully not fail too early:
I don't think it's so much about the lifetime of the component, or whether it eventually fails due to faulty manufacturing or gradual wear and tear. (What the bathtub curve gets at.)
It's that if you do make parts that are identical, and you expose them to identical unanticipated circumstances, they're likely to behave identically, and fail identically.
I've seen this w/ distributed databases. I overloaded a Cassandra instance once, causing it to OOM. That node failed, but it's distributed, so another node automatically took over, ran the same query, and OOMed, and then the last guy took the query, and very quickly I had 3 dead nodes.
I once had a discussion with a scifi author about how to design a starship to last a long time. I suggested that it being repairable would be of paramount importance. To that end, the various systems should use interchangeable parts. Starting with the obvious like nuts&bolts should be standardized, extend that to things like computer boards and components, motors, etc.
For example, if you had a linux machine running the fusion drive, and a mac machine running the entertainment arcade, and the linux machine shorted out, it would sure suck if you couldn't cannibalize the entertainment arcade computer to fix it.
It goes back to Apollo 13, where the CO2 scrubbers on the command module were a different design than the ones on the lunar module, which inhibited them being able to refresh the ones on the lem, and nearly caused loss of the crew.
It's the same for software. Software that's supposed to be used "forever" should be written such that parts of it can be easily replaced. Highly flexible designs often lose against simpler designs because it's easier to rewrite the latter and very hard to change something when you bump against the limits of flexibility in the former.
I had a similar discussion once, and the result was very biology cells inspired. Any subsystem must be able to repair itself, and must state its defunct state on repair needed state. If that times out the subsystem must destroy itself "deactivation". Dependant on importance other subsystems must pick up the load and create a replacement under strain over time.
In a plane, the aoa could be replaced by sensor fusion of gyroscopic sensors and air density sensors distributed over the hull.
Selfrepairing could be a achieved via a reservoir of peeble like standardized spare parts traveling through a conduit and applied via vibration and standardized interfaces. Final fallback, a simulation of expected circumstances, suggesting a half way accurate fallback model.
That's science fiction, not science. Clarke used three to push your brain past our sense of left/right symmetry not because of some idea related to redundancy.
These sensors exist to solve a problem with the MAX design. Changing and moving the engines increased the likelihood of a stall when the engines could push the nose up (as I understand it). Fine.
But here's the kicker: this should be something that pilots should be trained on. They should be aware of how the MAX is different to the previous 737s and know what to do to disable this system if it causes problems.
But that might be the end of a common type rating, which is something the airlines (and apparently Boeing) didn't want.
The whole 737 MAX situation just looks like a giant clusterf--- that was a kneejerk reaction to the unexpected success of the A320neo to which Boeing had no answer and to avoid years-long development delays and losing more customers to Airbus, it really looks like they made shortcuts. And that's so damaging to their brand it really defies belief.
Or more likely it doesn't really matter, and in a couple years nobody will really remember this about Boeing. They'll go back to being a big airplane producer that has a stunning safety record, which they are despite this issue.
The airline industry is growing and there are only two manufacturers who can build hundreds of planes on time.
Airbus is already near full capacity. It would be impossible NOT to buy Boeing if you want planes.
Which is also the correct thing to do. Despite our president and some NYTimes columnists being scared of automation (apparently they only agree when they're wrong), automation has saved so many lives that a failure like this doesn't affect the big picture.
Yes, mistakes were made, yes, we should find ways to avoid this happening in the future, no, automation isn't the enemy. Without automation in flying at the current number of airplanes in the sky we'd probably have one or two crashes a day. The fact that 2 crashes in half a year make the news is thanks to the amazing safety of modern airplanes.
However, automation that is designed in a criminally negligent manner is. People who create such designs should be put in prison, and we should not be using products from them ever again.
Have fun using any product. If your company gets big enough the probability that one of its products was faulty because of negligence slowly approaches 100%.
Any big company has a scandal, learns from it, the people that learned the lesson leave at some point, a new generation of employees makes a similar mistake again, wash rinse, repeat.
You probably can't fly any airplanes if you will not use any airplanes from a company that had a scandal like this.
AFAIK the automation had no good reason to be there first place, unless you consider racing Airbus for contracts a good reason. I mean, the simpler the better especially when lives are at stake, right?
The MCAS is designed to prevent an aerodynamic stall; a situation where the plane is pointed too far up and as a result starts heading straight for the ground. It does do by detecting the plane pointing too far up, and pushing it back down. If it did not function when the plane was descending rapidly it would not be fit for its designed purpose.
> The MCAS is designed to prevent an aerodynamic stall [...]
This has become a trope and is flatly incorrect.
MCAS was cooked up to maintain the handling characteristics required by the certification specifications.
The standard requires stick resistance to increase as the critical (stall) angle of attack is approached. The MAX violated that requirement due to the aerodynamics of the new engine cowls, so MCAS was Boeing's (?crap) implementation of "artificial feel" to meet the spec.
Yes, while the spec exists presumably to prevent the pilots from themselves taking the ship into a stall, MCAS doesn't change wing or aircraft performance in a material way that would be meant by "prevent a stall."
I believe the critical passage is here in CFR 14 §25.175¹
(2) With the landing gear retracted at low speed, the stick force curve must have a stable slope at all speeds within a range which is the greater of 15 percent of the trim speed plus the resulting free return speed range, or 50 knots plus the resulting free return speed range, above and below the trim speed (except that the speed range need not include speeds less than 1.3 VSR1, nor speeds greater than the minimum speed of the applicable speed range prescribed in paragraph (b)(1), nor speeds that require a stick force of more than 50 pounds)[...]
The crucial phrase is "stick force curve", which is the characteristic MCAS was created to tweak.
As far as 'authoritative sources' go, I'll just mention the Gell-Mann amnesia effect.²
When speaking to the uninitiated, anti-stall system gets the point across.
When speaking reguspeak, and actual aerodynamics, MCAS is a compensatory system that is meant to allow the plane to be certified airworthy. It is the same class of system as a mechanical stick-pusher (though even less effective since all it does is changes the yoke pressure required to bring the plane to a stall).
It's not a meme sadly, which makes this all the more tragic in hindsight. Sibling poster has quoted the CFR.
> MCAS is a compensatory system that is meant to allow the plane to be certified airworthy
Where did you get this information? My understanding is the airframe has the potential to nose up due to extra lift provided by engine placement (eg, lift not commanded by stick pull). MCAS is used to prevent this stall condition during high AoA.
One of the most important things to get right with a control system is to maintain some level of consistency throughout the entire range of the system you're actuating.
Get on your computer, and move your mouse around. Now go into the settings and muck with your mouse sensitivity/acceleration curves, and try to drop your cursor on a particular file.
Odds are, you'll have some degree of difficulty until your brain adjusts to the new settings.
Same thing is relevant with airplane yokes. The force required to deflect a control surface (and therefore the plane) in an airstream is a result of the forces imparted on the surface + plane while by the impinged airstream.
Now, a force response curve should be smooth and predictable. Some distance of deflection on the yoke at one position should yield approximately the same level of deflection from the yoke at another position. If there is a sudden change in the number of degrees of AoA you get per degree of deflection, this is a highly undesirable flight characteristic.
For a pilot's perspective, I recommend the D.P. Davies Interview Podcast from the Royal Aeronautics Society, specifically the Boeing episode where he describes his certification flights of the Boeing 727-300.
That plane had a similar interaction with high lift devices at high AoA, making the plane more eager to pitch into a stall when you got to a certain point AoA-wise. This was in direct violation of this CFR. As Davies puts it, "You can't certify a plane that wants to stall itself!"
The 727 was eventually certified though when they added a mechanical stick pusher which would shove the stick forward when the pilot was getting close to that flight regime to make sure they didn't stall.
MCAS, by all indications, serves a similar purpose, it detects current AoA and trims the plane to counter the extra lift so that the deflection of the elevator at the top of the AoA curve has to fight the nose-down trim, which to a pilot would feel like the plane takes the same amount of force to deflect for those last few degrees. Basically, to use the mouse analogy, it's bumping down the sensitivity of the yoke to compensate for the extra sensitivity created by the lift at high angles of attack.
All of this is fine and dandy at 17 or so degrees AoA. Not so much though in attempted level flight with a busted AoA sensor.
Much of the art behind control systems comes from translating technological activity into humanly processable control schemes. That CFR is a common sense guideline basically specifying that a transport plane must have a predictable response curve.
It reminds me of the way nuclear reactors work, which kinda made it click. There they make criticality dependent on neutrons donated by fission byproduct decay, allowing for control rod situations, and thereby criticality level changes to take place over minutes instead of seconds.
Plus, look at the name
Maneuvering Characteristics Augmentation System.
The important takeaway is it doesn't really do squat to make stalls not happen beyond making it increasingly impossible for the pilot to get enough oomph out of the control surfaces to get the plane in stall and stay there. I don't know if there is also a stick pusher for MAX aircraft to help recover from a stall.
Given that the MCAS operates in intervals and does not provide constant input, it doesn't really stand that it's similar to a stick pusher as far as maintaining constant response. It seems as though it will make an evaluation and push the nose down regardless of how much stick input there is.
If the MCAS was constantly variable, like a mechanical stick pusher, then what you're saying would make sense. IMO, as reported, it seems like an 'anti-stall device' that automatically adjusts the plane's pitch regardless of stick input. Depending on conditions, this presumably could be little to no stick input.
That's what is so insane about this system. It was put in to make the thing act like a 737 within a very small part of the flight envelope. It never should have kicked in in normal flight.
But AoA sensors freezing is apparently common enough where this system is frequently kicking in when the plane isn't in the situation it was designed for.
If there were specific steps that the pilots could have taken to avert disaster, why not just incorporate them into the flight software? Why resorting instead to "reprogramming" the pilot? That's what training is: programming of the human brain.
One can't teach others without having first learned the lesson oneself. I'm not convinced Boeing has. I'm not convinced the company had adequately consider all possible scenarios and how pilots would react in them based on their intuition.
Even if it has enough sensprs, the flight software has no situational awareness.
This is by design. The flight software is deliberately kept simple enough that the pilots can be trained to understand the full workings of the flight software and what it will do in any situation.
The entire flight control algorithm is probably only a few hundred lines of psudocode.
It's a catch 22:
We are fully capable of designing a plane that safely flys itself from airport to airport without any pilots, to handle most emergency situations. We have been able to do so since the 80s.
But we are not able to put a pilot in the loop on such a plane without massive safety implications. To have a pilot in the loop, the software has to be kept super simple so the pilot can diagnose it in an emergency and take the correct action.
Either we have the flight software that is situational aware and authorised to take any action, or we have a super simple software and a pilot in the loop. There is no safe middle ground.
Not sure about the "able to do so since the 80s" part, but generally, I agree.
It's the same problem we see with Tesla, Uber, etc and autonomous cars. If it's to be truly autonomous, it needs to do so without ANY human intervention. As soon as a human is added to the loop, the system needs to be understandable by any human operator.
In the case of the MAX, even with Redundancy sensors, there is the possibility enough of them fail that the plane doesn't "know" how to resolve the problem. So, control must be returned to the pilot with enough time and enough information to avert disaster.
The USSR were flying their Buran space shuttle in the 80s with full autonomous capabilities.
It could launch into space, orbit, de-orbit, fly though re-entry and land at a runway without any external control (it was designed to complete it's mission under signal jamming conditions).
It had full situational awareness and could autonomously make decisions like redirecting to a different runway or airport depending on weather and other factors.
Maybe it's a bit of a stretch to say Buran was safe enough to fly passengers autonomously, but it was in the right direction.
Compared to a self driving car where you have to detect respond to other cars and solid objects, the amount of processing power to maintain a dynamic aerodynamic flight model and fly under instrument conditions is actually pretty low.
The pilots were trained on how to deal with a runaway trim stabiliser. The procedure hasn't changed from the old 737, the only thing that has changed is that it is that the failure mode is more likely to occurr on the 737 MAX.
From the article:
“A properly trained pilot should be able to solve an MCAS anomaly or any uncommanded flight-control input through procedures that are taught to all 737 pilots,” said Menza, noting that the emergency information Boeing distributed in December reiterated those procedures.
It doesn't present as runaway trim, though. It's a small change in the trim, repeated every few seconds, which can be counteracted on the control column but will eventually add up. Small trim changes are usually happening all the time.
In a typical run-away trim, the trim wheel will move a great distance. It's very noticeable, both audibly (the wheel makes a clack-clack-clack noise) and visibly (there are white paint flashes on the wheel). And, obviously, the plane nose goes up or down by more than expected. The correct remedy is to disable the auto trim control via switches on the panel (located near the trim wheels).
The MCAS will adjust the trim in small increments every 10 (or is it 20?) seconds. Yes, a pilot should notice this, but because it's intermittent, it's more likely they don't "see" it as run-away trim, and just a slightly abnormal trim (EDIT - problem made worse because pilots were not informed MCAS existed - it's not a failure more they have trained on). They may attempt to remedy this with the manual trim control (a rocker switch on the control yoke). This does NOT disable MCAS, it only re-trim the plane. MCAS will re-engage due to faulty AoA sensors repeatedly until either the pilot disables all auto-trim with the switch on the panel OR the plane runs into the ground.
Yeah. I'm also not clear on the practicality of retrimming the aircraft at low altitude (Ethiopian was never >1000ft above ground) before impacting terrain after you disable the trim motor. You have to use a hand crank, because you just killed the trim motor altogether, and I think it takes several minutes (!) of cranking to get the jackscrew from one end to the other.
I wonder if they killed the trim motor and then failed to reach level flight before the ground got in the way.
Fatigue as well. Looking at the flight track after the last and final nose down, it's they were overcome. Nose down -> more speed -> more stabilizer nose down force -> more nose down attitude even without a change in stabilizer -> more speed -> more stabilizer force -> more nose down attitude.
Per initial reports the black box data suggests that the procedure was followed, but the MCAS was re-engaged, looks like investigations are ongoing if the MCAS can re-engage automatically or if the trim was too hard to manually override and re-engaged by the pilots to be able to use the electric trim to level the plane.
If all three AoA sensors are mounted to the side, they're likely to freeze at the same pitch if they do freeze. So unless you have multiple different ways to measuring AoA three sensors do not protect against this failure mode better than two does.
Although a stuck AoA sensor is also going to have a very characteristic signature - no change in reported AoA. A working AoA sensor will always have some noise in the signal as the air buffets the plane. Similarly, if you maneuver the plane and the indicated AoA doesn't change at all, you can deduce the sensor is stuck and reject it (or turn on the heater, or maybe have a mechanical way to force the AoA sensor through its range of motion, etc).
I'm admittedly ignorant of aircraft design but years ago when I first found out what those little AoA fins do, I was like, why the heck aren't there more of them plastered all over the place? Like, more than 3.
Couldn't one detect the frozen ones by simply noticing the loss of noise in the readings? I imagine an AoA sensor functioning normally to have a small amount of variation between readings due to turbulent air etc.
Alternatively, couldn't one correlate the AoA sensor output with the accelerometer output (or some other pitch sensor)? A frozen AoA would have identical readings as the plane changes pitch, a functioning one shouldn't, no?
> Eight minutes after takeoff, two of the angle-of-attack sensors froze at the same pitch.
If it's typical for the sensor's data to vary from 30.00 to 30.99 degrees as the wind passes over the wings and two sensors are permanently frozen at 10.42, after 8 minutes I think that there might be a high enough probability for the computer's software to decide that two sensors are broken and one is working.
The only way to be 100% safe and 100% fool proof is to not fly. For a mechanical system as complex as an airplane, triple redundancy with a good pilot is pretty much the best you can hope for.
Triple redundancy makes planes extremely safe to fly. Airbus has triple redundancy, and Boeing doesn't believe in it because they care more about profits. So the simple answer is to avoid flying on Boeing aircraft, and stick to Airbus ones.
To elaborate, I'm pointing out that redundancy has been an integral part of aeronautical engineering for ages so to ignore it in any situation, never mind in one where the pilots are kept out of the decision making loop, is criminally negligent.
What I fail to understand is why do they not design an overriding scheme to MCAS, such as an "above-threshold" pull on the stick by the pilot. I can recall that this was a classic design by Boeing. Whatever the number of AoA sensors, the system should be easy and straightforward to disable.
Those logics of "let's guess automatically if that sensor is failing" are just pushing the problem further. The real problem is too much reliance on automatic systems and top little human integration in the overall system (the human-machine system, that is to say).
The problem isn't too much reliance on automatic systems, it's that the systems are a half baked combination of the two.
The MCAS system is an example of that. As you say that overriding design is typical in Boeing planes, but MCAS purposefully overrides it, that is, pushing the controls hard, which overrides other automatic functions, has no effect on MCAS.
I'd say this is why they are half-baked : human integration was not thouroughly thought of in the design. When I speak of overriding, I mean human overriding.
This is something I think Boeing had got right with its manual overrides : when you design critical systems, you need human backup schemes, but you can go further and make these backup tightly integrated with the rest of the (highly automated) system.
I'd say this is why they are half-baked : human integration was not thouroughly thought of in the design. When I speak of overriding, I mean human overriding.
That's pretty obvious, given by the fact that the system was initially not even documented nor was the scenario allegedly available for training in the brand spanking new 787-MAX simulator.
The airline manufacturers have to push for automatic systems as they are the one of the features that sells.
One of a close friend of mine who works at Airbus said that the company believes the next gen aircrafts would only require a single person in the cockpit, and everything will be handled through automations.
Airbus aircrafts are more automated than Boeing. If Boeing does not work on the automation part, it could loose to Airbus. Airbus faced AoA problem back in 2009, when Quantas flight suddenly dropped from the air. But they were able to patch it up within a month and no reported case has come up since then.
So I believe Boeing working on Automation is a good thing, and they should be able to fix it up.
He may be right for the state of what has actually been wired up in today’s cockpits, but conceptually I don’t see why you couldn’t fully automate a plane. Even in emergency situations, pilots are required to follow established procedures and check lists, not become creative. The pilot mentions the example of an aborted take off, I can’t think of any reason an auto pilot wouldn’t be able to perform one. And of course you will need even more redundancy than there is today as you won’t have pilots who can look out at the window and come up with their own opinion of what is going on, and challenge improbable readings. Plus you can always have the option to have remote manual control if you really need to.
Of course there are parts of today’s aviation that are incompatible with automation. ATC over radio is one of them. Visual landing only at many airports is another one. There would be large costs to upgrading the infrastructures to be computer friendly, so I am not saying the switch is trivial, but it is bound to happen nevertheless.
He may be right for the state of what has actually been wired up in today’s cockpits, but conceptually I don’t see why you couldn’t fully automate a plane.
Good luck finding paying customers to board such a plane.
They will probably have lower operating costs. That will be a reason. And when they demonstrated their reliability over time people will stop thinking about it. Pilot error is still the number 1 cause of plane crashes.
IMO pilots are there in case shit really hits the fan, or birds hit the turbofans: I doubt computers would be creative enough like Sullenberger and decide to land on a river.
And 2 pilots means 2 brains that can divide the workload...
If the remote ground-based pilot has the capability to take total control authority of the aircraft (which, after the GermanWings incident would seem to be a necessity), then the security implications are massive. Imagine a remote-control attack on an aircraft carrying 800+ passengers...
> I don’t see why you couldn’t fully automate a plane.
every nut and bolt can and will break. every component load increase battery size and generator load, carrying a greater risk for fires.
if you go down the path "automate with manual backup" then you introduce even more fault-prone systems: the circuitry that disable automation might be faulty and can be another fire risk all of itself and the conflict between faulty automation and manual overrides could be itself an aggravating issue in an emergency.
and even if your plane is perfect, you have to live in an imperfect environment (same argument as car autopilots really): other plane around you might have an emergency, forcing your to delay landing. the airport might have an emergency, forcing a detour, the ils could break down, even on final.
it's exceedingly hard to write software that handles the common cases well enough, imagine having to write software to handle also the unforeseeable faults.
> remote control
and this introduces a whole new topic: systems rarely used are the ones with the more reliability issues. both manual and remote override, on top of being more stuff with their own failure modes, would be rarely tested in practice until the moment they'd be needed the most.
Combinatorial complextity. It's impossible to foresee every possible combination of failures. There are checklists for the ones that can be foreseen (and these have often been written in the blood of those who discovered them) and maybe in theory most of those could be automated. But they cannot be exhaustive. So when all else fails, you rely on human intelligence guided by experience and training as the last line of defense. It doesn't always work, but until we have an AI that performs better, it's the best option we have.
Automation is not bad per se. What I mean is that there must be an opportunity for human override at all levels of automation (and as seamless as possible) in case of machine failure. It does not deny that it could be done by one pilot only, or half a pilot or even somehow a remote human intervention.
When designing a critical system such as an aircraft, you must include human authority into it. No technology will ever be 100% foolproof. This is not a stance against technology, automation or innovation, it's a matter of concept : most of systems (and aircraft in particular) are human-machine systems.
You cannot design an unoverrideable automatic mechanism. Think of how you can appreciate the capacity of full control over your computer and your OS (happy OpenBSD user here, for the record).
>When designing a critical system such as an aircraft, you must include human authority into it
This is where Boeing messed up big time. According to the article they only had 2 AoA sensor, completely missing the fact that what happens if one sensor fails and which is correct. Airbus has 3, but IMO a critical component like an AoA sensor there should be 5 + additional inputs from the artificial horizon should be considered.
>You cannot design an unoverrideable automatic mechanism.
Yes, it makes sense. Even a complete automatic mechanism would need functionality to override in case things go completely haywire.
>This is where Boeing messed up big time. According to the article they only had 2 AoA sensor, completely missing the fact that what happens if one sensor fails and which is correct.
No, you missed something really critical in all this. There are 2 AoA sensors, however only 1 of them is used as input for the MCAS system. There was no redundancy whatsoever!
The proposed software patch will use both AoA sensors, and light an indicator light if they disagree. They don't want to retrofit the planes with 3 sensors like Airbus, because obviously Boeing cares more about profits than safety and good engineering.
Because if they didn't pretend that it was the same to fly a 737 and a 737 max, then they would be required to have pilots get a separate type certification for the max, which is costly for airlines and makes the airlines very reluctant to order the max.
I can't stop thinking whether similar "compromises" had been made when redesigning the airframe. It's engineering after all. The engineers could be pressed by the management to make certain changes for the sake of profit.
But management also relies on customers to tell them which compromise is vital to selling a product. And in a market with such huge price-pressure as aeronautics, I can easily see how this is going to override engineer's concerns.
They certainly voted with their wallets for a plane that doesn't require additional training. But they sure as hell did not vote with their wallets for a plane that does that on expense of crashing. And, to reiterate my point, I think that managers who pushed for trade-offs between different objectives did not push for this particular trade-off either.
Well, that's the law of unintended consequences. Customers wanted so not pay for retraining, Boeing wanted to get to the market faster and not wait for re-certification, managers wanted a physical problem fixed in software - and in the end the envelope got pushed too far.
I am sure the company operating the Titanic didn't exactly strive to have a shipwreck either.
This is true, but it is a statement about causality and the thread was about responsibility. Those are two different things. The fact that your actions lead to a certain outcome does not automatically mean that you're morally responsible for this outcome (that's the fallacy that leads to victim blaming, among other things).
It is always engineer's responsibility to clearly explain the trade-offs to the managers. Only a manager who's making the decision with accurate information can be responsible for it.
Of course they didn't; the damage to the airline's reputation would be terrible. The customers didn't make this choice; they were deceived by Boeing, who sold them on the idea that they didn't need any significant new training for this disaster of an aircraft. The customers didn't design this thing, they just bought it after listening to Boeing's promises.
It's worth watching Al Jazeera's series on the production of the 787 Dreamliner, and related cultural issues at Boeing after their merger with McDonnell Douglas [1].
Personally, I think it's worth taking with a grain of salt as it appears quite one-sided, but the interviews with Boeing ex-employees and head engineers are enlightening, and could go some way to explaining the lack of redundant systems (i.e. cost and time).
I am a designer and implementor of vital speed and distance measurement systems, with triply modular redundancy, used in mass transit application.
I cannot even imagine what the designers of this thing are going through now. It must be terrible.
To make it worse, it's a confusing topic. There are two pillars to the design of such system.
1. Faulty sensor must be detected with a very high probability. The typical way to achieve that is redundancy and diversification. The exact amount of redundancy depends on the reliability of the sensor considered. In most cases, it is sufficient to have 2 sensors, but of different models, in order to avoid common mode of failure.
2. In case of a failure, the system must have a graceful degradation, and in aeronautics, this means a clean handover to the pilot.
So, in the case of this MCAS thing, having two sensors is not necessarily a bad thing, and what M. Kornecki reports is 100% correct. What looks strange is the way a single failure was managed by the software, and how the procedure to recover was quite complicated and, even worse, not exported to the training material of the pilots. In my world, we called this "exported safety requirement application conditions" - SRACs, and verification of their proper allocation is a big chunk of the safety case. More than discussing architecture, in my view, the investigation must explain why the organisation failed to perform this activity.
The case for a third sensor can be made to decrease the likelihood of having to bypass the system ("belt and suspenders", as says M. Kornacki), but based on my experience, it will not be sufficient. As other correctly report here, it's not a silver bullet.
Ultimately, the degradation scenario and pilot handover is part of the overall system safety.
It's incredibly unlikely, but not entirely unforseeable that enough sensors would fail at the same time for the same reason. All four engines on the 747 BA9 failed at the same time due to volcanic ash [0]. If you just take the median of nine, it's possible that a mere five failed sensors could break MCAS. And then you are back to the issue of handing over to the pilots.
Yes there is. If you put too many sensors then there is always one in need of repair. And then it becomes dangerous: the pilot and maintainer ignores the alarm, delay replacement, leading slowly to a failure.
This is why the redundancy choices and availability calculations should always be made pondering the maintenance burden.
Well, I've been working in mass mobility and they had 4x redundancy with different sensor types. The more sensors went bad, the more restricted the operation regime became as it went through degraded modes. And the on-board systems were of course aware of the status of the sensors.
I think that created the right incentives: you could ignore a faulty sensor or two, but the results were increased travel times, so costs to the operator.
I always wonder why we don't have massive arrays of micro-sensors on planes spread out over the plane. If a handful your 65k sensors start to fail, you can delay repair for quite some time - otoh, if sensors start to fail all over the plane, you know you have to wake up the pilot hard, since it's a systemic problem like icing.
Wiring harnesses are a major weight savings. If you wired them all in serial, then that wire is a single point of failure. Otherwise you’d have 65k wires going to each one.
No, you put them on a bus like so many other things in modern vehicles today. They don't need their own separate wires or even their own bus. With lots of sensors, you're going to have several independent buses anyway, so a failure on that bus would only make you lose a fraction of your sensors.
> even worse, not exported to the training material of the pilots
According to this article (https://www.vox.com/business-and-finance/2019/3/29/18281270/...), this was a requirement of the 737-MAX while it was being developed. It needed to be sold as pretty much the same as it's predecessors, therefore requiring minimal retraining.
> The training piece is important because a key selling feature of the 737 Max was the idea that since it wasn’t really a new plane, pilots didn’t really need to be retrained for the new equipment. As the New York Times reported, “For many new airplane models, pilots train for hours on giant, multimillion-dollar machines, on-the-ground versions of cockpits that mimic the flying experience and teach them new features” while the experienced 737 Max pilots were allowed light refresher courses that you could do on an iPad.
> That let Boeing get the planes into customers’ hands quickly and cheaply, but evidently at the cost of increasing the possibility of pilots not really knowing how to handle the planes, with dire consequences for everyone involved.
>at the cost of increasing the possibility of pilots not really knowing how to handle the planes
not excusing Boeing here, just extrapolating the situation to where there are so many automated systems doing so much and such complicated stuff that handover to pilot is just not an option (especially if plane is designed to fully utilize the automated systems capabilities). Like F-16 which just can't flown manually, or autonomous vehicles (Uber/Tesla/ect.) where handover to human driver in reality is absolutely not option. I mean, look how we completely lost the ability to stick-shift the cars.
I find it surprising when a system is considered "redundant" when the _pilot_ is part of redundancy!? If this is an accepted solution then it is very easy to be abused: sensors fail, never mind, pilot has eyes and can deactivate a malfunctioning _whatever_.
Depending on the mode of operation, the pilot will or will not be part of the redundancy. The trick in this type of application is the management of mode transitions.
When sensors fail, the system will transition to degraded modes of operations where the pilot will have more responsibility.
The safety case will rely on demonstrating that transition to such degraded modes is low enough to be compatible with the human rate of errors.
A modern system should not be declared safe if it relies on pilot _whatever_.
Not sayin’ it did not happen in the past. Unfortunately.
I'm questioning whether a system as the one I described can be abused to the point where redundancy is offloaded to pilot flying the plane even when it shouldn't be?
It can be abused, but it should not be possible if the process driving certification of such system is followed properly.
The standards define checks and balances designed precisely to detect such abuse. In particular, the pilot’s rate of error is quantified and it should not be possible to abuse it without going unnoticed.
My car is only five years old but already has two sensors that have gone bad in the engine. Neither of them are vital and everything works great despite the occasional check engine light. Redundancy. It's a time intensive process to pop the head off and replace sensors. Nobody wants to pay their mechanic $100 an hour if they can avoid it.
I can't even imagine a sensor failure having zero redundancy, much less changing control inputs to a complicated system like a multi-engine jet. This is completely against everything I know about engineering and I find even discussion of this being possible to be deeply offensive. The fact that it happened twice and hundreds of people are dead is just mind boggling.
"...everything works great despite the occasional check engine light..." that may make you feel better but it's not true. The life and efficiency of your engine is being reduced. What year, make, model are you driving? When you sell it do you plan on telling the next owner that you drove it religiously with the check engine light on?
The engine isn't magic, you can read the codes yourself, figure out what they mean, look up the replacement guidelines yourself, etc. It's really simple actually, anyone can do it.
The turn-over of employees in aerospace is often quite quick. It's very likely that most of the people that designed this system are long gone, and the current design team are the ones picking up the pieces.
My understanding is that the recovery scenario wasn’t supposed to be complicated at all, because in the event of a MCAS failure, it would always manifest as a runaway trim scenario, and that pilots are trained heavily on recognizing as correcting for that scenario, and that by following the standard runaway trim solution/checklist/process that this would necessarily involve disabling MCAS whether the pilots were aware of it or not. So the question is, did they, and if so did this fail, and if not, why didn’t they? Is this actually a direct problem with MCAS or is it closer to an issue of basic pilot training that only happened to involve MCAS? I suspect as the investigations unfold that our understanding of the accidents is only going to get more complex and nuanced.
One significant problem as I understand it was the assumption that a failing MCAS would present as runaway stabilizer trim.
When, in actuality, it may not have looked much like runaway stabilizer trim to the pilots.
My understanding is in a runaway stabilizer trim situation the trim wheel (a medium sized wheel near the pilot and co-pilots knees) spins continuously and makes a loud clacking noise as part of the spinning.
This makes runaway stabilizer trim easy to identify. The wheel is spinning (for no identifiable reason) and making noise.
The MCAS failure, however applies trim discretely with intervals of 10-20s. This means it might be very hard to spot the adjustments to the trim wheel if you glance down briefly.
A pilot might notice the control column is heavy, glance down to see if it's runaway trim see the wheel not moving, rule out that scenario and move on to other diagnostic steps.
Well, it sounds like they turned off the autopilot but then turned it back on, which is not part of the checklist. It’s not clear from the reporting exactly what happened and I would hesitate to jump to conclusions. Accidents like this are almost always hugely complicated and are the result of many things going wrong in a specific order at a specific time, rather than a single factor.
In fact we don’t even know what the cause of the crash was, and we won’t actually know for several months—there have been a number of crashes where everyone “knew” what the cause was early on, only for it later to come to light that is was something completely unrelated.
Like all sensors out there in the atmosphere, icing is an issue. So not only are they error prone, but failures are sometimes not independent. Airbus planes from the A320 family have three such sensors, but it so happened that on November 5th, 2014, an A321 had two sensors freeze in the wrong position during flight. Two sensors against one win, so the flight envelope protection system kicked in and the aircraft started to nose dive. It lost 4000 feet in altitude before the crew regained control...
Details of the flight if you want to do some research: Lufthansa Airbus A321-200, registration D-AIDP, performing flight LH-1829 from Bilbao, SP (Spain) to Munich (Germany) on November 5th, 2014.
Normally no, from what I have read they are very reliable. And the sensors are the same ones used on all 737s. So it seems that there is some other problem with the MAX that is leading to the a false "nose high" indication.
I wouldn't think so. My personal theory is AoA is sending valid data to one of the flight computers, that flight computer is sending invalid data to the MCAS, or the MCAS has a software problem.
I suspect AoA is sending signed data, computer expects unsigned data, or possibly LSB/MSB conversion problem. Or it could just be faulty logic somewhere.
I enjoyed your comment because I’m particularly interested in Tesla’s Autopilot system and your mention of “graceful degradation and clean handover” sounds like it should apply to driving autonomy levels as well.
In the way we use cars there seems no time for graceful handover. You're about the same time interval away from the next car as the time to gain situational awareness, probably less. A plane is usually quite some minutes away from the ground and other planes, or f.e. when landing on autopilot the pilots are not distracted. If you'd apply this standard, the bar for autopilot in cars would be very high indeed. (That might be warranted, although in a risk / reward perspective humans are terrible drivers too.)
I'm gonna take a punt on the root cause of this mess: cost cutting / bonus seeking managerialisim. In my experience people high up in the decision chain with no technical expertise often have blind faith in what "technology" can accomplish.
Oh, thanks for the info! Rare to see a phrase with antonymic regional differences ("I'll try it / I won't try it") survive in today's globalized world etc etc.
From the information that keeps leaking out it appears the 737 MAX has some serious design faults.
What is going to interesting is to see how quickly the FAA certifies the new software changes this second time around.
The current perception would be the FAA was too quick to certifying the original MCAS as being safe.
I suspect the second time around that certification process is going to take a lot more time and effort and is going to be much harder to achieve.
And the final nail in the 737 MAX coffin might be that even when that certification arrives, Boeing then needs to convince paying passenger that is now safe to climb on board the aircraft.
>What is going to interesting is to see how quickly the FAA certifies the new software changes this second time around.
With a Trump lackey running the FAA, I'm sure they'll rubber-stamp whatever Boeing puts out there.
What I want to see is if any of the foreign regulators refuse to certify it. I'd love to see a show-down in international aviation between the Trump administration and better-run nations.
I have a question since many years that I am afraid to ask so straight. There is the AF447 and those 2 Boeing MAX that I remember where people will always talk about redundancy of the sensors, or their maintenance.
But really, I want to know why the software and hardware of the aircraft fails to understand that whatever actions it has performed automatically or inputs/actions by the pilots, or any other important event, are making the damn aircraft loose altitude really really fast. In the case of these Boeings, how can your software keep pointing the nose of the aircraft down WHILE it is CONSISTENTLY loosing altitude? How is this not a huge design flaw? I understand that for stall recovery you actually have to loose some altitude to regain speed/lift and recover from the stall. But if you STILL KEEP loosing altitude and there is no turning point, then damnit, whatever caused the loosing altitude should be stopped at least at 500m AGL, no? Switch on a huge yellow light to the pilots „you are 100% on your own now, the computer is out of luck and is shutting down“ and the pilot jumps on the gas pedal, 200% power to the engines, and starts to figure out how to gain altitude. Both Boeing flights were in daylight, no? Pilots should be able to see the ground/water and be able to pull the thing back up just by visibility without any sensors? It‘s a bit of a different case with the AF447, though.
How did the AoA sensors and MCAS won the authority here over the only important data: altitude change. Who cares if the AoA shows 30 degrees or -271 degrees, as long as the plane is climbing we are good! No need to point the nose down or do any other stall protection stuff? And that seems to be really what happened with these 2 Boeings. They were climbing but some stupid AoA sensor failed and some even more stupid MCAS decided to dive. And they kept diving until they reached the ocean and MCAS was still confident it was a good idea to dive?
In some planes my iPhone is able to get the GPS reading and some free app I got 5 years ago will actually show me ground speed and altitude. Which I always find very exciting. It usually matches with what the entertainment system is showing on the pax screens. Give or take <1%. So reliable altitude reading is solved, no? You have 300 phones on your plane (though only the window seats have a chance for it to work, but still...). Not sure if the GPS is gonna work if the plane is rolling and spinning like crazy, which I dont think happened in any of these cases.
I hope I don‘t make it sound stupid or even i-know-it-better, but I really just want to understand.
I only know a little bit about aerospace programming, but from what I do know complicated chains-of-reasoning are avoided like the plague. With every additional step of program reasoning the probability that you got it right decays exponentially. As a result, simple controllers with clearly defined areas of responsibility are elevated above all else. It is the pilot's job to integrate the information coming to them from all areas of the plane. Yes, a computer could do it, but once you get past three or so sensors the programmer's ability to reason about what might happen shrinks to nothing in comparison to the pilot's ability to see what is happening.
> “Our proposed software update incorporates additional limits and safeguards to the system and reduces crew workload,” Boeing said in a statement.
... "reduces crew workload" so that they have a chance to figure it out in time and survive. Nice move.
EDIT to add: I guess I find it a bit annoying that, instead of admitting that they're fixing a terrible bug, they're cloaking it in some corporate "we're adding even more cool new features" speak.
> if the group had built the MCAS in a way that would depend on two sensors, and would shut the system off if one fails, he thinks the company would have needed to install an alert in the cockpit to make the pilots aware that the safety system was off.
> And if that happens, Ludtke said, the pilots would potentially need training on the new alert and the underlying system. That could mean simulator time, which was off the table.
It seems like we are determined to live in a Gilded Age Fantasy Camp. It's like the Titanic not having enough lifeboats.
I've been around the block. I know Big Corp will always place value on profits over safety, but we seem to be entering an age where they feel unconstrained.
even before that: the plane is a bad design because making a new plane that works properly with the bigger engines was also off the table. so hundreds of people die.
I have no idea of the facts in this case, but based on how organizations function in general, one possibility is that the redundancy issues of MCAS were raised internally by some engineers without result.
In that case, the engineers were probably not thanked internally back then and are probably not thanked now either.
If their potential concerns would had led to changes on the MCAS design they would probably not have been thanked either, but rather seen as the people who unnecessarily made the project more expensive or less profitable.
In conclusion, people who avert or try to avert risk are seldom proportionally thanked in organizations in general.
I think it's quite generous to Boeing to imply the MCAS system was developed in house. I'm leaning towards 3rd party contract, built to Boeing's spec. Whoever wrote the spec might be 3rd party as well, with Boeing's 'engineers' just performing as project managers.
> "A properly trained pilot should be able to solve an MCAS anomaly or any uncommanded flight-control input through procedures that are taught to all 737 pilots"
It blows my mind that anyone still talks like this.
My first job was writing (non-life-critical) scientific software for detail-obsessed university researchers working in a lab with notebooks and procedures. If "just solve it with training" could work for anyone in the world, it would have been these people. Yet it was immediately and abundantly clear that designing usability into the system would have far more impact on their success rate at any task than documentation or training or even the reliability of the software itself.
The movie "Apollo 13" showed astronauts working in a simulator, and engineers giving them faulty sensor inputs to try to trick them. They had to train to be able to identify this possibility, and react correctly to it. This isn't the sort of thing you can figure out on the fly (so to speak). If the solution to flying an aircraft with a faulty MCAS sensor was "the pilot should have read it in a book last month", it's no wonder they were in trouble.
The software industry does make some programs with random inputs and hidden internal state, and require users to figure out what's going on and solve it anyway. We call them "games". Perhaps the defining characteristic of a game is that, even if you've read the manual, you won't succeed on the first try.
> "But, he said, if he were designing the system from scratch, he would emphasize the training while also building the plane with three sensors."
Is even three enough? From an earlier version of the "2001" Wikipedia page [1]:
> "In the story HAL features a design with triple redundancy, so that if one of the three modules fails the other two can outvote it. However, there is a [[theorem]] in [[computer science]] that proves that for such [[distributed systems]] a vote-based [[sanity check]] only works if ''less than'' one third of the modules fail. Thus the failure of a single one of HAL's redundant modules would be sufficient to compromise the system, as apparently happened in the movie."
I don't know what theorem this is referring to. Help?
162 comments
[ 4.8 ms ] story [ 237 ms ] threadThat triple-sensor system isn’t foolproof, however.
In 2008, on a customer-acceptance flight of an Airbus A320, two of the angle-of-attack sensors froze and those two sensors then outvoted the third. When the pilots went to demonstrate the stall-prevention system, they were not aware of the malfunctioning sensors. The plane crashed, killing the seven people on board.
The same problem arose again on a 2014 Airbus A321 Lufthansa flight leaving Spain. Eight minutes after takeoff, two of the angle-of-attack sensors froze at the same pitch. This time, after a drop in altitude, the pilots were able to regain control and complete the flight.
Any automation system can fail, and when that happens, hope that through some combination of luck, skill, experience, and training, the pilot will get the plane safely to the destination.
Incodentally on the A380 and A350 Airbus have changed to combined AoA-pitot sensors of which there are now four.
Update: AoA not AoT
P.S. I bet you could even put a strain gauge on the wing spar to measure the bending force on the wing, couple that with other inputs like airspeed, and come up with a reasonable AoA value.
For example, measuring slipstream over the wing is not sufficient. You need to known the pressure ratio between above and below, so there's two sensors. But airflow over a wing is not contiguous or straight, so you need more spanwise sensors to start averaging. And the inboard wing will stall first and give erroneous data, so you need to detect that and disregard it...
Rather than just measuring the raw value at source.
I'm sure a function can be constructed that takes that input, along with the airspeed, and produces AoA. It can be used as a crosscheck with the AoA sensors. Since it takes airspeed as another parameter, it can also crosscheck the pitot tubes.
NASA's Genesis mission was bit by this a while back. It had redundant parachute sequencers for a sample return capsule, but they were all assembled identically and with the G-sensors backwards. Consequently, they all failed in exactly the same way.
I would have thought that for any condition there would be more than one mechanism available to sense it. You could get different devices to vote on what is the real condition.
This has been done for years in visual cockpits with regards to an artifical horizon. The pilot only has to look out the window (assuming visibliity) to confirm what the instrument is reporting. Of course when the pilot loses visibility and starts to rely on their inner ear for "level" bad things can happen.
Many more simple planes, especially things like gliders, have a simple ball bearing in a curved tube to indicate "down" as well as the more convential artifical horizon.
Also I'm not sure what you're talking about with using the real horizon as a backup to the artificial horizon. It's not meant to be a redundant setup. Artificial horizons aren't required for visual (looking outside) flight, and relying primarily on the instruments in visual flight is an error.
In clouds/poor visibility, the cross-check for the artificial horizon is provided by the other flight instruments: airspeed, altimeter, turn coordinator, vertical speed indicator, and directional gyro (or their equivalents on an electronic display).
I know this isn't a great example, but triple redundancy is enough of a design cornerstone that Arthur C. Clarke made it one of the defining features of Rendezvous With Rama, a classic sci-fi story about an Oumuamua-like object that people manage to land on:
>It was now strikingly apparent that the "city", like so much of Rama, was triplicated. It consisted of three identical, circular complexes or superstructures, rising from a long, oval foundation. Photographs taken from the hub had also indicated that each complex was itself divided into three equal components, like a pie sliced into 120-degree portions. This would greatly simplify the task of exploration; presumably they had to examine only one-ninth of [the city] to see the whole of it.
It doesn't exactly sound like a new or controversial idea, you know?
A more robust idea is to have three redundant subsystems, each different.
https://en.wikipedia.org/wiki/Bathtub_curve
Like, you don't expect them to last forever, but you do expect at least 2/3 to meet their lifetime estimates.
It's that if you do make parts that are identical, and you expose them to identical unanticipated circumstances, they're likely to behave identically, and fail identically.
I've seen this w/ distributed databases. I overloaded a Cassandra instance once, causing it to OOM. That node failed, but it's distributed, so another node automatically took over, ran the same query, and OOMed, and then the last guy took the query, and very quickly I had 3 dead nodes.
For example, if you had a linux machine running the fusion drive, and a mac machine running the entertainment arcade, and the linux machine shorted out, it would sure suck if you couldn't cannibalize the entertainment arcade computer to fix it.
It goes back to Apollo 13, where the CO2 scrubbers on the command module were a different design than the ones on the lunar module, which inhibited them being able to refresh the ones on the lem, and nearly caused loss of the crew.
In a plane, the aoa could be replaced by sensor fusion of gyroscopic sensors and air density sensors distributed over the hull.
Selfrepairing could be a achieved via a reservoir of peeble like standardized spare parts traveling through a conduit and applied via vibration and standardized interfaces. Final fallback, a simulation of expected circumstances, suggesting a half way accurate fallback model.
These sensors exist to solve a problem with the MAX design. Changing and moving the engines increased the likelihood of a stall when the engines could push the nose up (as I understand it). Fine.
But here's the kicker: this should be something that pilots should be trained on. They should be aware of how the MAX is different to the previous 737s and know what to do to disable this system if it causes problems.
But that might be the end of a common type rating, which is something the airlines (and apparently Boeing) didn't want.
The whole 737 MAX situation just looks like a giant clusterf--- that was a kneejerk reaction to the unexpected success of the A320neo to which Boeing had no answer and to avoid years-long development delays and losing more customers to Airbus, it really looks like they made shortcuts. And that's so damaging to their brand it really defies belief.
Yes, mistakes were made, yes, we should find ways to avoid this happening in the future, no, automation isn't the enemy. Without automation in flying at the current number of airplanes in the sky we'd probably have one or two crashes a day. The fact that 2 crashes in half a year make the news is thanks to the amazing safety of modern airplanes.
However, automation that is designed in a criminally negligent manner is. People who create such designs should be put in prison, and we should not be using products from them ever again.
Any big company has a scandal, learns from it, the people that learned the lesson leave at some point, a new generation of employees makes a similar mistake again, wash rinse, repeat.
You probably can't fly any airplanes if you will not use any airplanes from a company that had a scandal like this.
This has become a trope and is flatly incorrect.
MCAS was cooked up to maintain the handling characteristics required by the certification specifications.
The standard requires stick resistance to increase as the critical (stall) angle of attack is approached. The MAX violated that requirement due to the aerodynamics of the new engine cowls, so MCAS was Boeing's (?crap) implementation of "artificial feel" to meet the spec.
Yes, while the spec exists presumably to prevent the pilots from themselves taking the ship into a stall, MCAS doesn't change wing or aircraft performance in a material way that would be meant by "prevent a stall."
(2) With the landing gear retracted at low speed, the stick force curve must have a stable slope at all speeds within a range which is the greater of 15 percent of the trim speed plus the resulting free return speed range, or 50 knots plus the resulting free return speed range, above and below the trim speed (except that the speed range need not include speeds less than 1.3 VSR1, nor speeds greater than the minimum speed of the applicable speed range prescribed in paragraph (b)(1), nor speeds that require a stick force of more than 50 pounds)[...]
The crucial phrase is "stick force curve", which is the characteristic MCAS was created to tweak.
As far as 'authoritative sources' go, I'll just mention the Gell-Mann amnesia effect.²
(me: non-active aircraft dispatcher)
¹—https://www.ecfr.gov/cgi-bin/text-idx?node=14:1.0.1.3.11#se1... ²—https://en.wikipedia.org/wiki/Gell-Mann_amnesia_effect?wprov...
How do you know this? Haven't seen that reported anywhere but in user comments here.
When speaking to the uninitiated, anti-stall system gets the point across.
When speaking reguspeak, and actual aerodynamics, MCAS is a compensatory system that is meant to allow the plane to be certified airworthy. It is the same class of system as a mechanical stick-pusher (though even less effective since all it does is changes the yoke pressure required to bring the plane to a stall).
It's not a meme sadly, which makes this all the more tragic in hindsight. Sibling poster has quoted the CFR.
Where did you get this information? My understanding is the airframe has the potential to nose up due to extra lift provided by engine placement (eg, lift not commanded by stick pull). MCAS is used to prevent this stall condition during high AoA.
One of the most important things to get right with a control system is to maintain some level of consistency throughout the entire range of the system you're actuating.
Get on your computer, and move your mouse around. Now go into the settings and muck with your mouse sensitivity/acceleration curves, and try to drop your cursor on a particular file.
Odds are, you'll have some degree of difficulty until your brain adjusts to the new settings.
Same thing is relevant with airplane yokes. The force required to deflect a control surface (and therefore the plane) in an airstream is a result of the forces imparted on the surface + plane while by the impinged airstream.
Now, a force response curve should be smooth and predictable. Some distance of deflection on the yoke at one position should yield approximately the same level of deflection from the yoke at another position. If there is a sudden change in the number of degrees of AoA you get per degree of deflection, this is a highly undesirable flight characteristic.
For a pilot's perspective, I recommend the D.P. Davies Interview Podcast from the Royal Aeronautics Society, specifically the Boeing episode where he describes his certification flights of the Boeing 727-300.
That plane had a similar interaction with high lift devices at high AoA, making the plane more eager to pitch into a stall when you got to a certain point AoA-wise. This was in direct violation of this CFR. As Davies puts it, "You can't certify a plane that wants to stall itself!"
The 727 was eventually certified though when they added a mechanical stick pusher which would shove the stick forward when the pilot was getting close to that flight regime to make sure they didn't stall.
MCAS, by all indications, serves a similar purpose, it detects current AoA and trims the plane to counter the extra lift so that the deflection of the elevator at the top of the AoA curve has to fight the nose-down trim, which to a pilot would feel like the plane takes the same amount of force to deflect for those last few degrees. Basically, to use the mouse analogy, it's bumping down the sensitivity of the yoke to compensate for the extra sensitivity created by the lift at high angles of attack.
All of this is fine and dandy at 17 or so degrees AoA. Not so much though in attempted level flight with a busted AoA sensor.
Much of the art behind control systems comes from translating technological activity into humanly processable control schemes. That CFR is a common sense guideline basically specifying that a transport plane must have a predictable response curve.
It reminds me of the way nuclear reactors work, which kinda made it click. There they make criticality dependent on neutrons donated by fission byproduct decay, allowing for control rod situations, and thereby criticality level changes to take place over minutes instead of seconds.
Plus, look at the name
Maneuvering Characteristics Augmentation System.
The important takeaway is it doesn't really do squat to make stalls not happen beyond making it increasingly impossible for the pilot to get enough oomph out of the control surfaces to get the plane in stall and stay there. I don't know if there is also a stick pusher for MAX aircraft to help recover from a stall.
If the MCAS was constantly variable, like a mechanical stick pusher, then what you're saying would make sense. IMO, as reported, it seems like an 'anti-stall device' that automatically adjusts the plane's pitch regardless of stick input. Depending on conditions, this presumably could be little to no stick input.
But AoA sensors freezing is apparently common enough where this system is frequently kicking in when the plane isn't in the situation it was designed for.
One can't teach others without having first learned the lesson oneself. I'm not convinced Boeing has. I'm not convinced the company had adequately consider all possible scenarios and how pilots would react in them based on their intuition.
This is by design. The flight software is deliberately kept simple enough that the pilots can be trained to understand the full workings of the flight software and what it will do in any situation.
The entire flight control algorithm is probably only a few hundred lines of psudocode.
It's a catch 22:
We are fully capable of designing a plane that safely flys itself from airport to airport without any pilots, to handle most emergency situations. We have been able to do so since the 80s.
But we are not able to put a pilot in the loop on such a plane without massive safety implications. To have a pilot in the loop, the software has to be kept super simple so the pilot can diagnose it in an emergency and take the correct action.
Either we have the flight software that is situational aware and authorised to take any action, or we have a super simple software and a pilot in the loop. There is no safe middle ground.
It's the same problem we see with Tesla, Uber, etc and autonomous cars. If it's to be truly autonomous, it needs to do so without ANY human intervention. As soon as a human is added to the loop, the system needs to be understandable by any human operator.
In the case of the MAX, even with Redundancy sensors, there is the possibility enough of them fail that the plane doesn't "know" how to resolve the problem. So, control must be returned to the pilot with enough time and enough information to avert disaster.
It could launch into space, orbit, de-orbit, fly though re-entry and land at a runway without any external control (it was designed to complete it's mission under signal jamming conditions).
It had full situational awareness and could autonomously make decisions like redirecting to a different runway or airport depending on weather and other factors.
Maybe it's a bit of a stretch to say Buran was safe enough to fly passengers autonomously, but it was in the right direction.
Compared to a self driving car where you have to detect respond to other cars and solid objects, the amount of processing power to maintain a dynamic aerodynamic flight model and fly under instrument conditions is actually pretty low.
From the article: “A properly trained pilot should be able to solve an MCAS anomaly or any uncommanded flight-control input through procedures that are taught to all 737 pilots,” said Menza, noting that the emergency information Boeing distributed in December reiterated those procedures.
Here's a video of a competent 737 pilot showing those exact procedures: https://www.youtube.com/watch?v=xixM_cwSLcQ
Obviously the MCAS system is badly designed, but any automation system can fail and pilots need to know how to deal with it.
In a typical run-away trim, the trim wheel will move a great distance. It's very noticeable, both audibly (the wheel makes a clack-clack-clack noise) and visibly (there are white paint flashes on the wheel). And, obviously, the plane nose goes up or down by more than expected. The correct remedy is to disable the auto trim control via switches on the panel (located near the trim wheels).
The MCAS will adjust the trim in small increments every 10 (or is it 20?) seconds. Yes, a pilot should notice this, but because it's intermittent, it's more likely they don't "see" it as run-away trim, and just a slightly abnormal trim (EDIT - problem made worse because pilots were not informed MCAS existed - it's not a failure more they have trained on). They may attempt to remedy this with the manual trim control (a rocker switch on the control yoke). This does NOT disable MCAS, it only re-trim the plane. MCAS will re-engage due to faulty AoA sensors repeatedly until either the pilot disables all auto-trim with the switch on the panel OR the plane runs into the ground.
I wonder if they killed the trim motor and then failed to reach level flight before the ground got in the way.
And then the ground got in the way.
https://www.wsj.com/articles/ethiopian-airlines-pilots-initi...
Did the pilots fail to notice the MCAS problem before it put the plane too far out of trim?
Could they have saved the plane if they stuck to the procedure and kept adjusting the trim by hand?
Why does MCAS override even direct pilot trim up commands?
Is the runway trim procedure even viable on older 737s once the trim goes past a certain point? Or are we just lucky that it never happens?
No, the sensors existed before the MAX they are used by the autopilot system. With the MAX they are now also used by the MCAS system.
Alternatively, couldn't one correlate the AoA sensor output with the accelerometer output (or some other pitch sensor)? A frozen AoA would have identical readings as the plane changes pitch, a functioning one shouldn't, no?
If it's typical for the sensor's data to vary from 30.00 to 30.99 degrees as the wind passes over the wings and two sensors are permanently frozen at 10.42, after 8 minutes I think that there might be a high enough probability for the computer's software to decide that two sensors are broken and one is working.
That's pretty much been aeronautical gospel since dinosaurs strapped cardboard to their stubby arms and dreamed of soaring.
But not, by corollary, that two is none.
Those logics of "let's guess automatically if that sensor is failing" are just pushing the problem further. The real problem is too much reliance on automatic systems and top little human integration in the overall system (the human-machine system, that is to say).
The MCAS system is an example of that. As you say that overriding design is typical in Boeing planes, but MCAS purposefully overrides it, that is, pushing the controls hard, which overrides other automatic functions, has no effect on MCAS.
This is something I think Boeing had got right with its manual overrides : when you design critical systems, you need human backup schemes, but you can go further and make these backup tightly integrated with the rest of the (highly automated) system.
That's pretty obvious, given by the fact that the system was initially not even documented nor was the scenario allegedly available for training in the brand spanking new 787-MAX simulator.
One of a close friend of mine who works at Airbus said that the company believes the next gen aircrafts would only require a single person in the cockpit, and everything will be handled through automations.
Airbus aircrafts are more automated than Boeing. If Boeing does not work on the automation part, it could loose to Airbus. Airbus faced AoA problem back in 2009, when Quantas flight suddenly dropped from the air. But they were able to patch it up within a month and no reported case has come up since then.
So I believe Boeing working on Automation is a good thing, and they should be able to fix it up.
Hasn't that myth been around for years, along with "Planes can take off and land by themselves?"
https://www.askthepilot.com/questionanswers/automation-myths...
Of course there are parts of today’s aviation that are incompatible with automation. ATC over radio is one of them. Visual landing only at many airports is another one. There would be large costs to upgrading the infrastructures to be computer friendly, so I am not saying the switch is trivial, but it is bound to happen nevertheless.
Good luck finding paying customers to board such a plane.
And 2 pilots means 2 brains that can divide the workload...
https://en.wikipedia.org/wiki/Iran%E2%80%93U.S._RQ-170_incid...
every nut and bolt can and will break. every component load increase battery size and generator load, carrying a greater risk for fires.
if you go down the path "automate with manual backup" then you introduce even more fault-prone systems: the circuitry that disable automation might be faulty and can be another fire risk all of itself and the conflict between faulty automation and manual overrides could be itself an aggravating issue in an emergency.
and even if your plane is perfect, you have to live in an imperfect environment (same argument as car autopilots really): other plane around you might have an emergency, forcing your to delay landing. the airport might have an emergency, forcing a detour, the ils could break down, even on final.
it's exceedingly hard to write software that handles the common cases well enough, imagine having to write software to handle also the unforeseeable faults.
> remote control
and this introduces a whole new topic: systems rarely used are the ones with the more reliability issues. both manual and remote override, on top of being more stuff with their own failure modes, would be rarely tested in practice until the moment they'd be needed the most.
When designing a critical system such as an aircraft, you must include human authority into it. No technology will ever be 100% foolproof. This is not a stance against technology, automation or innovation, it's a matter of concept : most of systems (and aircraft in particular) are human-machine systems.
You cannot design an unoverrideable automatic mechanism. Think of how you can appreciate the capacity of full control over your computer and your OS (happy OpenBSD user here, for the record).
This is where Boeing messed up big time. According to the article they only had 2 AoA sensor, completely missing the fact that what happens if one sensor fails and which is correct. Airbus has 3, but IMO a critical component like an AoA sensor there should be 5 + additional inputs from the artificial horizon should be considered.
>You cannot design an unoverrideable automatic mechanism.
Yes, it makes sense. Even a complete automatic mechanism would need functionality to override in case things go completely haywire.
No, you missed something really critical in all this. There are 2 AoA sensors, however only 1 of them is used as input for the MCAS system. There was no redundancy whatsoever!
The proposed software patch will use both AoA sensors, and light an indicator light if they disagree. They don't want to retrofit the planes with 3 sensors like Airbus, because obviously Boeing cares more about profits than safety and good engineering.
So if they can’t hold that promise anyway, why not provide a better interface?
Anyway, for the sake of selling, they went into the biggest failure of modern aerospace engineering. This should just not have happened.
I am sure the company operating the Titanic didn't exactly strive to have a shipwreck either.
It is always engineer's responsibility to clearly explain the trade-offs to the managers. Only a manager who's making the decision with accurate information can be responsible for it.
Personally, I think it's worth taking with a grain of salt as it appears quite one-sided, but the interviews with Boeing ex-employees and head engineers are enlightening, and could go some way to explaining the lack of redundant systems (i.e. cost and time).
[1] https://www.youtube.com/watch?v=rvkEpstd9os
I cannot even imagine what the designers of this thing are going through now. It must be terrible.
To make it worse, it's a confusing topic. There are two pillars to the design of such system.
1. Faulty sensor must be detected with a very high probability. The typical way to achieve that is redundancy and diversification. The exact amount of redundancy depends on the reliability of the sensor considered. In most cases, it is sufficient to have 2 sensors, but of different models, in order to avoid common mode of failure.
2. In case of a failure, the system must have a graceful degradation, and in aeronautics, this means a clean handover to the pilot.
So, in the case of this MCAS thing, having two sensors is not necessarily a bad thing, and what M. Kornecki reports is 100% correct. What looks strange is the way a single failure was managed by the software, and how the procedure to recover was quite complicated and, even worse, not exported to the training material of the pilots. In my world, we called this "exported safety requirement application conditions" - SRACs, and verification of their proper allocation is a big chunk of the safety case. More than discussing architecture, in my view, the investigation must explain why the organisation failed to perform this activity.
The case for a third sensor can be made to decrease the likelihood of having to bypass the system ("belt and suspenders", as says M. Kornacki), but based on my experience, it will not be sufficient. As other correctly report here, it's not a silver bullet.
Ultimately, the degradation scenario and pilot handover is part of the overall system safety.
Any reason to not just use at least 9 of them, pick the median value and forget about it?
[0] https://en.m.wikipedia.org/wiki/British_Airways_Flight_9
This is why the redundancy choices and availability calculations should always be made pondering the maintenance burden.
I think that created the right incentives: you could ignore a faulty sensor or two, but the results were increased travel times, so costs to the operator.
I always wonder why we don't have massive arrays of micro-sensors on planes spread out over the plane. If a handful your 65k sensors start to fail, you can delay repair for quite some time - otoh, if sensors start to fail all over the plane, you know you have to wake up the pilot hard, since it's a systemic problem like icing.
According to this article (https://www.vox.com/business-and-finance/2019/3/29/18281270/...), this was a requirement of the 737-MAX while it was being developed. It needed to be sold as pretty much the same as it's predecessors, therefore requiring minimal retraining.
> The training piece is important because a key selling feature of the 737 Max was the idea that since it wasn’t really a new plane, pilots didn’t really need to be retrained for the new equipment. As the New York Times reported, “For many new airplane models, pilots train for hours on giant, multimillion-dollar machines, on-the-ground versions of cockpits that mimic the flying experience and teach them new features” while the experienced 737 Max pilots were allowed light refresher courses that you could do on an iPad.
> That let Boeing get the planes into customers’ hands quickly and cheaply, but evidently at the cost of increasing the possibility of pilots not really knowing how to handle the planes, with dire consequences for everyone involved.
not excusing Boeing here, just extrapolating the situation to where there are so many automated systems doing so much and such complicated stuff that handover to pilot is just not an option (especially if plane is designed to fully utilize the automated systems capabilities). Like F-16 which just can't flown manually, or autonomous vehicles (Uber/Tesla/ect.) where handover to human driver in reality is absolutely not option. I mean, look how we completely lost the ability to stick-shift the cars.
When sensors fail, the system will transition to degraded modes of operations where the pilot will have more responsibility.
The safety case will rely on demonstrating that transition to such degraded modes is low enough to be compatible with the human rate of errors.
A modern system should not be declared safe if it relies on pilot _whatever_.
Not sayin’ it did not happen in the past. Unfortunately.
I'm questioning whether a system as the one I described can be abused to the point where redundancy is offloaded to pilot flying the plane even when it shouldn't be?
The standards define checks and balances designed precisely to detect such abuse. In particular, the pilot’s rate of error is quantified and it should not be possible to abuse it without going unnoticed.
I can't even imagine a sensor failure having zero redundancy, much less changing control inputs to a complicated system like a multi-engine jet. This is completely against everything I know about engineering and I find even discussion of this being possible to be deeply offensive. The fact that it happened twice and hundreds of people are dead is just mind boggling.
Don't put off a $150 job and cost yourself a $2k job. Most sensor replacements don't require removing the cylinder heads.
Their poor decisions led to this. Single sensor as input to autopilot to augment the nose!?
When, in actuality, it may not have looked much like runaway stabilizer trim to the pilots.
My understanding is in a runaway stabilizer trim situation the trim wheel (a medium sized wheel near the pilot and co-pilots knees) spins continuously and makes a loud clacking noise as part of the spinning.
This makes runaway stabilizer trim easy to identify. The wheel is spinning (for no identifiable reason) and making noise.
The MCAS failure, however applies trim discretely with intervals of 10-20s. This means it might be very hard to spot the adjustments to the trim wheel if you glance down briefly.
A pilot might notice the control column is heavy, glance down to see if it's runaway trim see the wheel not moving, rule out that scenario and move on to other diagnostic steps.
This is getting worse for Boeing at every turn.
In fact we don’t even know what the cause of the crash was, and we won’t actually know for several months—there have been a number of crashes where everyone “knew” what the cause was early on, only for it later to come to light that is was something completely unrelated.
Details of the flight if you want to do some research: Lufthansa Airbus A321-200, registration D-AIDP, performing flight LH-1829 from Bilbao, SP (Spain) to Munich (Germany) on November 5th, 2014.
I suspect AoA is sending signed data, computer expects unsigned data, or possibly LSB/MSB conversion problem. Or it could just be faulty logic somewhere.
Critical AoA is somewhere in the realm of 17 to 20 degrees.
That doesn't leave much room for where MCAS wouldn't be a problem.
Also, AoA sensors are not normally safety critical. The MAX is the first 737 airframe for which this is the case.
https://english.stackexchange.com/questions/20742/why-did-th...
Thanks for the heads up tho, I will retire it from my rhetorical toolkit in favor of something more universally understood.
What is going to interesting is to see how quickly the FAA certifies the new software changes this second time around.
The current perception would be the FAA was too quick to certifying the original MCAS as being safe.
I suspect the second time around that certification process is going to take a lot more time and effort and is going to be much harder to achieve.
And the final nail in the 737 MAX coffin might be that even when that certification arrives, Boeing then needs to convince paying passenger that is now safe to climb on board the aircraft.
With a Trump lackey running the FAA, I'm sure they'll rubber-stamp whatever Boeing puts out there.
What I want to see is if any of the foreign regulators refuse to certify it. I'd love to see a show-down in international aviation between the Trump administration and better-run nations.
But really, I want to know why the software and hardware of the aircraft fails to understand that whatever actions it has performed automatically or inputs/actions by the pilots, or any other important event, are making the damn aircraft loose altitude really really fast. In the case of these Boeings, how can your software keep pointing the nose of the aircraft down WHILE it is CONSISTENTLY loosing altitude? How is this not a huge design flaw? I understand that for stall recovery you actually have to loose some altitude to regain speed/lift and recover from the stall. But if you STILL KEEP loosing altitude and there is no turning point, then damnit, whatever caused the loosing altitude should be stopped at least at 500m AGL, no? Switch on a huge yellow light to the pilots „you are 100% on your own now, the computer is out of luck and is shutting down“ and the pilot jumps on the gas pedal, 200% power to the engines, and starts to figure out how to gain altitude. Both Boeing flights were in daylight, no? Pilots should be able to see the ground/water and be able to pull the thing back up just by visibility without any sensors? It‘s a bit of a different case with the AF447, though.
How did the AoA sensors and MCAS won the authority here over the only important data: altitude change. Who cares if the AoA shows 30 degrees or -271 degrees, as long as the plane is climbing we are good! No need to point the nose down or do any other stall protection stuff? And that seems to be really what happened with these 2 Boeings. They were climbing but some stupid AoA sensor failed and some even more stupid MCAS decided to dive. And they kept diving until they reached the ocean and MCAS was still confident it was a good idea to dive?
In some planes my iPhone is able to get the GPS reading and some free app I got 5 years ago will actually show me ground speed and altitude. Which I always find very exciting. It usually matches with what the entertainment system is showing on the pax screens. Give or take <1%. So reliable altitude reading is solved, no? You have 300 phones on your plane (though only the window seats have a chance for it to work, but still...). Not sure if the GPS is gonna work if the plane is rolling and spinning like crazy, which I dont think happened in any of these cases.
I hope I don‘t make it sound stupid or even i-know-it-better, but I really just want to understand.
... "reduces crew workload" so that they have a chance to figure it out in time and survive. Nice move.
EDIT to add: I guess I find it a bit annoying that, instead of admitting that they're fixing a terrible bug, they're cloaking it in some corporate "we're adding even more cool new features" speak.
> if the group had built the MCAS in a way that would depend on two sensors, and would shut the system off if one fails, he thinks the company would have needed to install an alert in the cockpit to make the pilots aware that the safety system was off.
> And if that happens, Ludtke said, the pilots would potentially need training on the new alert and the underlying system. That could mean simulator time, which was off the table.
I've been around the block. I know Big Corp will always place value on profits over safety, but we seem to be entering an age where they feel unconstrained.
In that case, the engineers were probably not thanked internally back then and are probably not thanked now either.
If their potential concerns would had led to changes on the MCAS design they would probably not have been thanked either, but rather seen as the people who unnecessarily made the project more expensive or less profitable.
In conclusion, people who avert or try to avert risk are seldom proportionally thanked in organizations in general.
I think it's quite generous to Boeing to imply the MCAS system was developed in house. I'm leaning towards 3rd party contract, built to Boeing's spec. Whoever wrote the spec might be 3rd party as well, with Boeing's 'engineers' just performing as project managers.
It blows my mind that anyone still talks like this.
My first job was writing (non-life-critical) scientific software for detail-obsessed university researchers working in a lab with notebooks and procedures. If "just solve it with training" could work for anyone in the world, it would have been these people. Yet it was immediately and abundantly clear that designing usability into the system would have far more impact on their success rate at any task than documentation or training or even the reliability of the software itself.
The movie "Apollo 13" showed astronauts working in a simulator, and engineers giving them faulty sensor inputs to try to trick them. They had to train to be able to identify this possibility, and react correctly to it. This isn't the sort of thing you can figure out on the fly (so to speak). If the solution to flying an aircraft with a faulty MCAS sensor was "the pilot should have read it in a book last month", it's no wonder they were in trouble.
The software industry does make some programs with random inputs and hidden internal state, and require users to figure out what's going on and solve it anyway. We call them "games". Perhaps the defining characteristic of a game is that, even if you've read the manual, you won't succeed on the first try.
> "But, he said, if he were designing the system from scratch, he would emphasize the training while also building the plane with three sensors."
Is even three enough? From an earlier version of the "2001" Wikipedia page [1]:
> "In the story HAL features a design with triple redundancy, so that if one of the three modules fails the other two can outvote it. However, there is a [[theorem]] in [[computer science]] that proves that for such [[distributed systems]] a vote-based [[sanity check]] only works if ''less than'' one third of the modules fail. Thus the failure of a single one of HAL's redundant modules would be sufficient to compromise the system, as apparently happened in the movie."
I don't know what theorem this is referring to. Help?
See also: Segal's Law.
[1]: https://en.wikipedia.org/w/index.php?title=2001:_A_Space_Ody...