Lack of redundancies on Boeing 737 MAX baffles some involved in developing it
seattletimes.com
seattletimes.com
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.
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.
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.
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.
Their poor decisions led to this. Single sensor as input to autopilot to augment the nose!?
Any reason to not just use at least 9 of them, pick the median value and forget about it?
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.
[0] https://en.m.wikipedia.org/wiki/British_Airways_Flight_9
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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?
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).
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.
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.
Incodentally on the A380 and A350 Airbus have changed to combined AoA-pitot sensors of which there are now four.
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).
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.
So if they can’t hold that promise anyway, why not provide a better interface?
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.
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.
Good luck finding paying customers to board such a plane.
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.
> 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.
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.
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.
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).
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.
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.
... "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.
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...