The thing being missed is the sensor fault _causing_ runaway trim
The CAUSE of the runaway trim is completely irrelevant until you've stabilized the airplane and have time to debug the problem. The PROCEDURE to follow is the same no matter what the cause is, and the procedure will result in an aircraft that flies just fine and can be trimmed manually. And nobody dies.
and disabling auto trim not being part of the 'inconsistent sensor' emergency checklist.
If you have a runaway stabilizer and a failed sensor the proper checklist to follow is the one that will keep the aircraft from crashing or stalling, and THEN you deal with any "inconsistent sensor" you think might exist. Once you've completed the runaway stabilizer checklist, the failed sensor is irrelevant.
That should have been recognized as a potential killer and documented to hell and back the first time it was noticed and averted.
Yes, a runaway stabilizer has been recognized as a potential killer for decades and documented to hell and back. The AOA sensor isn't what was trimming the aircraft and isn't a "potential killer" when it fails. There are other stall warning systems and other performance indicators, which is, in effect, what the AOA sensor does. "You're getting close to a predicted stall." "You're flying at the correct AOA for optimum climb performance." Losing either or both functions doesn't cause horrible crashes and fireballs in farmer's fields.
I don't know how fair it is to say that Boeing hid it wrt to the second crash, since Boeing sent messages to every customer back in November, and the FAA issued an emergency AD at the same time. That's several months prior to the second crash, and plenty of time for a corporate operator to disseminate the information.
Given that the emergency AD outlines a mandatory action, and that the emergency procedure for handling a runaway stabilizer caused by MCAS is exactly the same procedure as handling a runaway stabilizer for any other cause, then yes, I think the operator bears a lot of blame for ignorance on the part of their pilots. If they couldn't handle an MCAS-created trim problem, then it is unlikely they'd know what to do if the electric trim system failed in "go nose-down" mode for any other reason. And yet, this is taught to every private pilot when they first move into an airplane with an autopilot -- at least my CFI did that.
Making the failure 'a double', which can overload the pilots.
I have no idea what you think you mean about the failure being "a double." To the pilots, it will appear just like every other runaway trim situation, which they've gone through in the simulator many times. It's one checklist.
Which means that the emergency checklist for inconsistent AOA/airspeed sensor
The failed sensor has nothing to do with airspeed. The immediate problem was not a failed AoA sensor. The first checklist that should have been processed is the runaway stabilizer, which would have stopped the problem.
they tried the same thing they did on the old 737 models and it didn't work
And when the first try at stopping a problem doesn't work, do you just give up and wait for the crash? Do you do the same thing 21 times hoping something different happens? Or do you proceed through the checklists for that kind of malfunction and disable the things that it tells you to disable?
I don't know how many the big iron autopilots have, but there are at least six ways of disabling the autopilot in a small Cessna. There are six ways of disabling it because depending on the specific failure mode the easiest/most convenient method might not work. Then you try the next one... and included in the list is pulling the breaker so the effectors no longer have power.
Would help with California's drought problems also.
Would help with population problems, too. When the only crops available are GMO, then all the GMO-haters will starve. Thus the population gets smaller, and is made up of a higher percentage of people who think science means something.
But first, we should see of Professor Malthus, I mean Bevan, is right.
If MCAS is not the thing causing the runaway trim situation, then why is everyone yapping about MCAS causing a runaway trim and killing people?
Because the automatic trim command stops when pilots pull back on the yoke.
The MCAS stops trying to trim while you are temporarily overriding it, but then it starts again -- creating a runaway trim situation. Maybe you don't understand the words "runaway trim"? It means that the trim changes and keeps going unless you do something to stop it. If you don't pull back on the yoke, the trim keeps going nose-down. When you let go of the yoke the trim keeps going nose-down. Runaway.
So they think they've fixed it.
And when it starts happening again they know they haven't. It shouldn't take TWENTY ONE cycles to realize that something isn't working right and to initiate the emergency procedure to keep it from happening.
So it sneaks up on the pilots.
Utter nonsense. Nothing is sneaking up on anyone.
I can imaging the flight crew pulling back on the yoke and then checking the trim wheel.
Which will show a nose-down trim condition. That they didn't enter. That shouldn't be there. So they adjust the trim until it is right. And see what the indicator says.
Which, at that moment will not be turning.
So? As soon as they let go it will. And someone will pull up on the yoke to correct the descent, and someone will look at the trim wheel and see that it isn't where it was, and they'll know that something is changing the trim.
So they go back to flying and it starts all over again after a short interval.
Yeah, and it is at that point, not twenty times later, that they will know there is a problem of some kind, that it has to do with something running the trim nose-down, and they should kill the electric trim circuit until they figure out what is happening.
It's really not rocket science. Really. The breakers are there specifically for that purpose.
Daft? You are the one who brought up breakers, for that matter you were the one who brought specifics into a general thread.
Yes, I pointed out how easy it is to defeat the errant software by pulling the circuit breaker. YOU were talking about fixing a software problem, which is daft. You don't fix a software problem by pulling a circuit breaker. You solve a flight control problem, whether that's software or hardware or whatever it is. And then, long after the aircraft has landed and the engineers diagnose the cause, THEY fix the software problem that caused the flight control issue.
I commented on a general case of designers potentially failing to include a way to disable a system
The designers of MCAS didn't need to include a way to stop MCAS when it had faulty sensor data it didn't detect. The disable method is and was in the aircraft and in the operating handbook and in regular training for a very long time. It was reiterated in the FAA emergency AD issued last November. Please stop hypothesizing about how bad the design was because it couldn't be stopped.
a case of multiple temporary overrides and the system not automatically switching off.
A temporary override is just that: a temporary override. It's like autopilot. Say you're flying along on auto and you see a big airplane in your windshield and/or your TCAS announces "climb" or "descend". You pull or push the yoke to do that. Then when the danger is over you let go and George takes over. A Temporary Override. Or you want to go around a bit of cloud so you turn a few degrees.
There are things you can do with the autopilot that will disengage, and too many people have died because they have done what they thought was a temporary override and then assumed George was going to take over again, and he didn't.
In this case, there is no "turn off MCAS" because there's no "turn on MCAS". There IS a way to solve the problem of MCAS doing the wrong thing, and it isn't entering a temporary override 21 times without bothering to actually stopping the problem. But all this hypothesizing that it can't be overridden permanently is just poppycock. Please stop.
While I can not comment on the specifics here (since it was both software AND a sensor) the thing about software problems is they are not easily fixed by pulling a breaker.
Nobody is trying to solve a software problem by pulling a breaker. Don't be daft. They needed to solve a flight problem by pulling a breaker. They can't change the software in-flight. But they can fly the plane instead of allowing it to fly them.
but if it was not such an easily isolated module and was instead more integrated into the plane's control software
The electric trim system is an easily isolated module with a specific breaker to pull that disables it. Doing this is well documented in the emergency procedure for runaway trim, from whatever source the runaway trim comes. (It could be as complicated as a FMS/autopilot failure. It could be as simple as a broken trim control switch on the yoke. Same solution.) It isn't software, it's hardware. Disabling the hardware is how you ignore whatever is causing the problem until the base problem can be solved -- later.
I guess not everyone can be as calm, collected, and infallible as you are in emergency situations.
Pilots train for exactly this kind of situation. They aren't going to go into a panic when they've handled this kind of problem literally hundreds of times before. You may panic, but that's your problem.
I'm sure we would all feel better of Slashdot reader Obfuscant were our pilot.
Even I have had the training on how to handle a runaway trim, and I'm only a PP ASEL. Do you really think that ATPs are less trained and less experienced?
That basically means pulling the little black button out of the dashboard, which cuts power to the component, thereby forcibly disabling it.
And if you look closely, you'll see that some circuit breakers are flush with the panel when "on", and some have a knob sticking out. The difference is that the flush ones control circuits that also have an on/off switch somewhere that would duplicate the breaker interruption of power, while the knobby ones are powering systems that don't, or might need to be pulled when the "off" switch doesn't work.
The avionics master is an example of the former. There's a switch. The autopilot is an example of the latter. The breaker is the last line of defense against an autopilot "off" switch that is a soft control.
Then you continue to fly the airplane. Just like you've been trained to do. What do you think would happen?
why would you turn off an accident-preventing system?
Because it has failed. Let's say your fancy new fully AV is stuck on the freeway at a dead stop because a failed obstacle detector says you're about to hit someone. Do you A) find a way to turn off the failed "accident-preventing system" and drive to the shop to get it fixed, or B) sit helpless in the middle of rush-hour traffic because you won't turn off an "accident-prevention" system that has failed?
You'd most likely just swap accidents caused by this system by accidents caused by pilots flying this unwieldy machine.
You do realize, I hope, that unless the pilots were actually in a too-high AoA situation the MCAS would never activate and they'd be flying the airplane the same way they would without it at all?
Perhaps because the MCAS and means of disabling it is undocumented.
You don't need to know what an MCAS is when you've correctly diagnosed runaway trim, because you've already been trained on the well-documented way of disabling the trim system. Will you PLEASE stop spouting this garbage?
Either the last crew failed to log it correctly or that country's failure laws are absolutely insane.
I believe that the final report on the first crash actually says that it was reported as an AOA sensor failure, ground maintenance replaced it, and the assumption was that the problem had been solved by replacing it.
Please, stop spreading this ignorance. The switch to disable the electric trim system is well documented and pilots are trained how to use it. If you can't disable a runaway trim then you are not going to pass your ATP checkride, nor will you pass your recurring airline checkrides and sim evaluations. Hell, if you're a PP ASEL who shows up at an FAA checkride in an airplane with an autopilot you will almost certainly be tested on your ability to disable the trim. And I am almost sure that it will be a topic in any flight review. It's THAT COMMON a problem.
It's the thing that is causing a runaway trim, which you already have enourmous amounts of training in what to do to prevent it. And it's described in the November 2018 notice from Boeing, and the November 2018 emergency AD that FAA issued. Why haven't you read either one, or, assuming you cannot read, why didn't your airline management read them to you?
Boeing felt they could take their sweet time fixing it and not issue advisories,
By "take their sweet time" you mean last November, right, before the final report on that crash came out? That's when they sent a notification of the MCAS system to every customer, as a result of the first crash. And the FAA issued an emergency airworthiness directive at almost the same time advising the proper corrective action for this problem.
So, who took their own sweet time here? Yeah, the airlines who didn't honor the AD and train their pilots on the system.
but when the pilot only has a few seconds to respond
He had a lot more than "a few seconds". He had time to go through 21 cycles of "trim up manually, let go, watch the trim go back nose-down..." rinse lather repeat. Twenty one times. And then the copilot had time to do it a couple of times. That's plenty of time to identify runaway trim and disable it.
This is not an unknown problem. It's part of the emergency procedures for any autopilot failure, and the pilots get plenty of training and sim time for those. Even lowly PP ASEL get training on the multitude of ways to turn off the autopilot, including pulling the circuit breaker.
As for the FAA, I never have high expectations of any government agency to look out for public safety
The FAA issued an emergency airworthiness directive last November for just this problem. What do you want them to do, make personal visits to every Boeing customer to make the changes called for in the AD? At what point does the airline become responsible for following mandatory instructions?
You can't disable a primary flight control system suddenly.
Neither MCAS nor electric trim control are primary flight control systems. So yes, you can disable MCAS and/or electric trim controls "suddenly".
There's no way to know with 2.
Buy an aeronautics book and spend a weekend reading about angle of attack and stalls. If one AOA sensor says that a stall is imminent and the other shows normal AOA, then you look at airspeed and rate of climb and thrust. If the airspeed is normal for the amount of thrust being applied and there is a positive rate of climb YOU ARE NOT STALLING. Unless you are in a fighter that has more thrust than weight, you cannot climb without lift, and a stall is loss of lift.
you can't just assume the other is infallible and trust 250 lives on 1 sensor.
Nobody is trusting 250 lives to an AOA sensor. They're trusting their lives to the pilot, who in these crashes failed to execute the emergency procedure that is spelled out for runaway trim. That's his job.
you might hesitate to turn off the system that's letting you do so quickly.
Oh, please. When the trim is trying to run full nose-down, you don't care how fast you can normally adjust the trim using the electric trim control on the yoke, you turn off the thing that is failing to operate properly. It's not a case of "gee, when I need to I can adjust the trim faster with this button, so I'll ignore that the electric trim system that is controlled by this button isn't working right."
Now explain why the pilot of the second crash didn't heed the emergency AD from the FAA or the notice from Boeing that came out last November telling him about MCAS and HOW TO DEAL WITH MCAS PROBLEMS. Which was, in short, to do exactly what they have been trained to do all along for runaway stabilizer -- disable the electric stabilizer system.
I guess it depends if they bothered to include a 'shut off the system' button.
Of course they included a way to shut off the system. Have you never looked into a modern aircraft cockpit? Have you failed to notice the hundreds of circuit breakers, each controlling power to specific bits of the aircraft systems? Or do you believe that when a circuit breaker is pulled, cutting power to a system, that the system will magically keep operating?
In the systems you design, typically how many times is the user expected to press the Stop Trying To Kill Us button
The yoke-mounted electric trim control is not a Stop Trying To Kill Us button. It is a manual control to adjust elevator trim. It is a temporary override to the automation. That's all.
When the autopilot is engaged then pilots should expect that transient trim inputs will return to autopilot control, unless the autopilot is also told to change the flight parameters. The MCAS is no different. If it is detecting a potential unsafe AOA it should keep trying to solve it until it is told to stop. Pressing the electric trim control isn't that command.
What's pathetic about this report is that the pilot went through TWENTY ONE CYCLES of manual trim adjustment followed by MCAS returning to control. Twenty one. And then he handed the problem to the copilot. THIS is why the airplane crashed -- the PILOT abdicated his responsibility for flying and dealing with problems.
At any time in those 21 cycles he could have simply pulled the breakers for the electric trim system (after a manual adjustment back to normal) and that would have ended the problem.
This solution is spelled out in the operating handbook for "Runaway Stabilizer". For ANY runaway stabilizer.
For the latest crash, there is no excuse for the pilot not to know, because both Boeing and the FAA issued notices (the FAA's was an emergency AD -- mandatory implementation) about the problem to all known customers. They did that in November of last year. At least four months before.
However, if the request is being made from kernel mode, the permissions checks should be skipped. That's because the kernel in general needs free and unfettered access to every file.
That's moronic. Even the kernel should respect file permissions. It should always be able to CHANGE the permissions (because the permissions are not part of the file but of the file system), but if a file is not 'x' the kernel should not treat it as executable, and if it is not 'r' it should not be readable.
Active on the network does not mean pinging the towers. It means transmitting non-protocol information, such as texts or voice data.
And like I said, my phone is active on the network all the time it is on and in range of a tower. It's not just "pinging" the tower, it is sending and receiving data. Background updates and background data. My email app polls for new email. The cellular provider can say "yes, it was active on the network", but that means absolutely NOTHING about whether I was using the phone, or if I was using it in handsfree mode.
They already record that those packets were transmitted.
Oh, be real. They don't record every packet. That's tinfoil hat talk.
TL;DR, the phone company is a more reliable measure of a device being active at a set time than your phone itself...
That's not what you said. The claim was that the cell provider could be subpoenaed to determine if the phone was active on the network, as if being active on the network was somehow relevant to any of the distracted driving laws. That's simply nonsense.
unless you are watching the phone live, in which case, there is no need to find out if the phone was in use as it was observed to be in use.
You have no clue, do you? Do you really imagine that when a cop shows up at an accident scene he has been observing the drivers prior to the accident? Of course not. Even were he right there, unless the phone is where he can see it he has no idea what I'm looking at or that I'm using it.
Give up. Asking the cell operator if the phone was "active on the network" at the time of an accident means nothing with respect to the law. Nothing at all. The cell company can't tell what you are doing, especially if you are using a VPN, and they can't tell at all if "handsfree" was in use or not.
Slashdot Mirror
The thing being missed is the sensor fault _causing_ runaway trim
The CAUSE of the runaway trim is completely irrelevant until you've stabilized the airplane and have time to debug the problem. The PROCEDURE to follow is the same no matter what the cause is, and the procedure will result in an aircraft that flies just fine and can be trimmed manually. And nobody dies.
and disabling auto trim not being part of the 'inconsistent sensor' emergency checklist.
If you have a runaway stabilizer and a failed sensor the proper checklist to follow is the one that will keep the aircraft from crashing or stalling, and THEN you deal with any "inconsistent sensor" you think might exist. Once you've completed the runaway stabilizer checklist, the failed sensor is irrelevant.
That should have been recognized as a potential killer and documented to hell and back the first time it was noticed and averted.
Yes, a runaway stabilizer has been recognized as a potential killer for decades and documented to hell and back. The AOA sensor isn't what was trimming the aircraft and isn't a "potential killer" when it fails. There are other stall warning systems and other performance indicators, which is, in effect, what the AOA sensor does. "You're getting close to a predicted stall." "You're flying at the correct AOA for optimum climb performance." Losing either or both functions doesn't cause horrible crashes and fireballs in farmer's fields.
if Boeing 'hid' it, how did they know about it?
I don't know how fair it is to say that Boeing hid it wrt to the second crash, since Boeing sent messages to every customer back in November, and the FAA issued an emergency AD at the same time. That's several months prior to the second crash, and plenty of time for a corporate operator to disseminate the information.
Given that the emergency AD outlines a mandatory action, and that the emergency procedure for handling a runaway stabilizer caused by MCAS is exactly the same procedure as handling a runaway stabilizer for any other cause, then yes, I think the operator bears a lot of blame for ignorance on the part of their pilots. If they couldn't handle an MCAS-created trim problem, then it is unlikely they'd know what to do if the electric trim system failed in "go nose-down" mode for any other reason. And yet, this is taught to every private pilot when they first move into an airplane with an autopilot -- at least my CFI did that.
Making the failure 'a double', which can overload the pilots.
I have no idea what you think you mean about the failure being "a double." To the pilots, it will appear just like every other runaway trim situation, which they've gone through in the simulator many times. It's one checklist.
Which means that the emergency checklist for inconsistent AOA/airspeed sensor
The failed sensor has nothing to do with airspeed. The immediate problem was not a failed AoA sensor. The first checklist that should have been processed is the runaway stabilizer, which would have stopped the problem.
they tried the same thing they did on the old 737 models and it didn't work
And when the first try at stopping a problem doesn't work, do you just give up and wait for the crash? Do you do the same thing 21 times hoping something different happens? Or do you proceed through the checklists for that kind of malfunction and disable the things that it tells you to disable?
I don't know how many the big iron autopilots have, but there are at least six ways of disabling the autopilot in a small Cessna. There are six ways of disabling it because depending on the specific failure mode the easiest/most convenient method might not work. Then you try the next one ... and included in the list is pulling the breaker so the effectors no longer have power.
Would help with California's drought problems also.
Would help with population problems, too. When the only crops available are GMO, then all the GMO-haters will starve. Thus the population gets smaller, and is made up of a higher percentage of people who think science means something.
But first, we should see of Professor Malthus, I mean Bevan, is right.
No.
If MCAS is not the thing causing the runaway trim situation, then why is everyone yapping about MCAS causing a runaway trim and killing people?
Because the automatic trim command stops when pilots pull back on the yoke.
The MCAS stops trying to trim while you are temporarily overriding it, but then it starts again -- creating a runaway trim situation. Maybe you don't understand the words "runaway trim"? It means that the trim changes and keeps going unless you do something to stop it. If you don't pull back on the yoke, the trim keeps going nose-down. When you let go of the yoke the trim keeps going nose-down. Runaway.
So they think they've fixed it.
And when it starts happening again they know they haven't. It shouldn't take TWENTY ONE cycles to realize that something isn't working right and to initiate the emergency procedure to keep it from happening.
So it sneaks up on the pilots.
Utter nonsense. Nothing is sneaking up on anyone.
I can imaging the flight crew pulling back on the yoke and then checking the trim wheel.
Which will show a nose-down trim condition. That they didn't enter. That shouldn't be there. So they adjust the trim until it is right. And see what the indicator says.
Which, at that moment will not be turning.
So? As soon as they let go it will. And someone will pull up on the yoke to correct the descent, and someone will look at the trim wheel and see that it isn't where it was, and they'll know that something is changing the trim.
So they go back to flying and it starts all over again after a short interval.
Yeah, and it is at that point, not twenty times later, that they will know there is a problem of some kind, that it has to do with something running the trim nose-down, and they should kill the electric trim circuit until they figure out what is happening.
It's really not rocket science. Really. The breakers are there specifically for that purpose.
Daft? You are the one who brought up breakers, for that matter you were the one who brought specifics into a general thread.
Yes, I pointed out how easy it is to defeat the errant software by pulling the circuit breaker. YOU were talking about fixing a software problem, which is daft. You don't fix a software problem by pulling a circuit breaker. You solve a flight control problem, whether that's software or hardware or whatever it is. And then, long after the aircraft has landed and the engineers diagnose the cause, THEY fix the software problem that caused the flight control issue.
I commented on a general case of designers potentially failing to include a way to disable a system
The designers of MCAS didn't need to include a way to stop MCAS when it had faulty sensor data it didn't detect. The disable method is and was in the aircraft and in the operating handbook and in regular training for a very long time. It was reiterated in the FAA emergency AD issued last November. Please stop hypothesizing about how bad the design was because it couldn't be stopped.
a case of multiple temporary overrides and the system not automatically switching off.
A temporary override is just that: a temporary override. It's like autopilot. Say you're flying along on auto and you see a big airplane in your windshield and/or your TCAS announces "climb" or "descend". You pull or push the yoke to do that. Then when the danger is over you let go and George takes over. A Temporary Override. Or you want to go around a bit of cloud so you turn a few degrees.
There are things you can do with the autopilot that will disengage, and too many people have died because they have done what they thought was a temporary override and then assumed George was going to take over again, and he didn't.
In this case, there is no "turn off MCAS" because there's no "turn on MCAS". There IS a way to solve the problem of MCAS doing the wrong thing, and it isn't entering a temporary override 21 times without bothering to actually stopping the problem. But all this hypothesizing that it can't be overridden permanently is just poppycock. Please stop.
While I can not comment on the specifics here (since it was both software AND a sensor) the thing about software problems is they are not easily fixed by pulling a breaker.
Nobody is trying to solve a software problem by pulling a breaker. Don't be daft. They needed to solve a flight problem by pulling a breaker. They can't change the software in-flight. But they can fly the plane instead of allowing it to fly them.
but if it was not such an easily isolated module and was instead more integrated into the plane's control software
The electric trim system is an easily isolated module with a specific breaker to pull that disables it. Doing this is well documented in the emergency procedure for runaway trim, from whatever source the runaway trim comes. (It could be as complicated as a FMS/autopilot failure. It could be as simple as a broken trim control switch on the yoke. Same solution.) It isn't software, it's hardware. Disabling the hardware is how you ignore whatever is causing the problem until the base problem can be solved -- later.
The EU now requires US citizens to get visas,
Regulation 2018/1806 says something quite different.
I guess not everyone can be as calm, collected, and infallible as you are in emergency situations.
Pilots train for exactly this kind of situation. They aren't going to go into a panic when they've handled this kind of problem literally hundreds of times before. You may panic, but that's your problem.
I'm sure we would all feel better of Slashdot reader Obfuscant were our pilot.
Even I have had the training on how to handle a runaway trim, and I'm only a PP ASEL. Do you really think that ATPs are less trained and less experienced?
That basically means pulling the little black button out of the dashboard, which cuts power to the component, thereby forcibly disabling it.
And if you look closely, you'll see that some circuit breakers are flush with the panel when "on", and some have a knob sticking out. The difference is that the flush ones control circuits that also have an on/off switch somewhere that would duplicate the breaker interruption of power, while the knobby ones are powering systems that don't, or might need to be pulled when the "off" switch doesn't work.
The avionics master is an example of the former. There's a switch. The autopilot is an example of the latter. The breaker is the last line of defense against an autopilot "off" switch that is a soft control.
If you deactivate it, what then?
Then you continue to fly the airplane. Just like you've been trained to do. What do you think would happen?
why would you turn off an accident-preventing system?
Because it has failed. Let's say your fancy new fully AV is stuck on the freeway at a dead stop because a failed obstacle detector says you're about to hit someone. Do you A) find a way to turn off the failed "accident-preventing system" and drive to the shop to get it fixed, or B) sit helpless in the middle of rush-hour traffic because you won't turn off an "accident-prevention" system that has failed?
You'd most likely just swap accidents caused by this system by accidents caused by pilots flying this unwieldy machine.
You do realize, I hope, that unless the pilots were actually in a too-high AoA situation the MCAS would never activate and they'd be flying the airplane the same way they would without it at all?
Perhaps because the MCAS and means of disabling it is undocumented.
You don't need to know what an MCAS is when you've correctly diagnosed runaway trim, because you've already been trained on the well-documented way of disabling the trim system. Will you PLEASE stop spouting this garbage?
Either the last crew failed to log it correctly or that country's failure laws are absolutely insane.
I believe that the final report on the first crash actually says that it was reported as an AOA sensor failure, ground maintenance replaced it, and the assumption was that the problem had been solved by replacing it.
An undocumented switch.
Please, stop spreading this ignorance. The switch to disable the electric trim system is well documented and pilots are trained how to use it. If you can't disable a runaway trim then you are not going to pass your ATP checkride, nor will you pass your recurring airline checkrides and sim evaluations. Hell, if you're a PP ASEL who shows up at an FAA checkride in an airplane with an autopilot you will almost certainly be tested on your ability to disable the trim. And I am almost sure that it will be a topic in any flight review. It's THAT COMMON a problem.
But no pilot training. So "What's an MCAS?"
It's the thing that is causing a runaway trim, which you already have enourmous amounts of training in what to do to prevent it. And it's described in the November 2018 notice from Boeing, and the November 2018 emergency AD that FAA issued. Why haven't you read either one, or, assuming you cannot read, why didn't your airline management read them to you?
This, this, 1000 times this. And the FAA emergency AD even spelled this out. Specifically. "Use THIS procedure..."
Boeing felt they could take their sweet time fixing it and not issue advisories,
By "take their sweet time" you mean last November, right, before the final report on that crash came out? That's when they sent a notification of the MCAS system to every customer, as a result of the first crash. And the FAA issued an emergency airworthiness directive at almost the same time advising the proper corrective action for this problem.
So, who took their own sweet time here? Yeah, the airlines who didn't honor the AD and train their pilots on the system.
but when the pilot only has a few seconds to respond
He had a lot more than "a few seconds". He had time to go through 21 cycles of "trim up manually, let go, watch the trim go back nose-down ..." rinse lather repeat. Twenty one times. And then the copilot had time to do it a couple of times. That's plenty of time to identify runaway trim and disable it.
This is not an unknown problem. It's part of the emergency procedures for any autopilot failure, and the pilots get plenty of training and sim time for those. Even lowly PP ASEL get training on the multitude of ways to turn off the autopilot, including pulling the circuit breaker.
As for the FAA, I never have high expectations of any government agency to look out for public safety
The FAA issued an emergency airworthiness directive last November for just this problem. What do you want them to do, make personal visits to every Boeing customer to make the changes called for in the AD? At what point does the airline become responsible for following mandatory instructions?
You can't disable a primary flight control system suddenly.
Neither MCAS nor electric trim control are primary flight control systems. So yes, you can disable MCAS and/or electric trim controls "suddenly".
There's no way to know with 2.
Buy an aeronautics book and spend a weekend reading about angle of attack and stalls. If one AOA sensor says that a stall is imminent and the other shows normal AOA, then you look at airspeed and rate of climb and thrust. If the airspeed is normal for the amount of thrust being applied and there is a positive rate of climb YOU ARE NOT STALLING. Unless you are in a fighter that has more thrust than weight, you cannot climb without lift, and a stall is loss of lift.
you can't just assume the other is infallible and trust 250 lives on 1 sensor.
Nobody is trusting 250 lives to an AOA sensor. They're trusting their lives to the pilot, who in these crashes failed to execute the emergency procedure that is spelled out for runaway trim. That's his job.
you might hesitate to turn off the system that's letting you do so quickly.
Oh, please. When the trim is trying to run full nose-down, you don't care how fast you can normally adjust the trim using the electric trim control on the yoke, you turn off the thing that is failing to operate properly. It's not a case of "gee, when I need to I can adjust the trim faster with this button, so I'll ignore that the electric trim system that is controlled by this button isn't working right."
Now explain why the pilot of the second crash didn't heed the emergency AD from the FAA or the notice from Boeing that came out last November telling him about MCAS and HOW TO DEAL WITH MCAS PROBLEMS. Which was, in short, to do exactly what they have been trained to do all along for runaway stabilizer -- disable the electric stabilizer system.
I guess it depends if they bothered to include a 'shut off the system' button.
Of course they included a way to shut off the system. Have you never looked into a modern aircraft cockpit? Have you failed to notice the hundreds of circuit breakers, each controlling power to specific bits of the aircraft systems? Or do you believe that when a circuit breaker is pulled, cutting power to a system, that the system will magically keep operating?
In the systems you design, typically how many times is the user expected to press the Stop Trying To Kill Us button
The yoke-mounted electric trim control is not a Stop Trying To Kill Us button. It is a manual control to adjust elevator trim. It is a temporary override to the automation. That's all.
When the autopilot is engaged then pilots should expect that transient trim inputs will return to autopilot control, unless the autopilot is also told to change the flight parameters. The MCAS is no different. If it is detecting a potential unsafe AOA it should keep trying to solve it until it is told to stop. Pressing the electric trim control isn't that command.
What's pathetic about this report is that the pilot went through TWENTY ONE CYCLES of manual trim adjustment followed by MCAS returning to control. Twenty one. And then he handed the problem to the copilot. THIS is why the airplane crashed -- the PILOT abdicated his responsibility for flying and dealing with problems.
At any time in those 21 cycles he could have simply pulled the breakers for the electric trim system (after a manual adjustment back to normal) and that would have ended the problem.
This solution is spelled out in the operating handbook for "Runaway Stabilizer". For ANY runaway stabilizer.
For the latest crash, there is no excuse for the pilot not to know, because both Boeing and the FAA issued notices (the FAA's was an emergency AD -- mandatory implementation) about the problem to all known customers. They did that in November of last year. At least four months before.
However, if the request is being made from kernel mode, the permissions checks should be skipped. That's because the kernel in general needs free and unfettered access to every file.
That's moronic. Even the kernel should respect file permissions. It should always be able to CHANGE the permissions (because the permissions are not part of the file but of the file system), but if a file is not 'x' the kernel should not treat it as executable, and if it is not 'r' it should not be readable.
Active on the network does not mean pinging the towers. It means transmitting non-protocol information, such as texts or voice data.
And like I said, my phone is active on the network all the time it is on and in range of a tower. It's not just "pinging" the tower, it is sending and receiving data. Background updates and background data. My email app polls for new email. The cellular provider can say "yes, it was active on the network", but that means absolutely NOTHING about whether I was using the phone, or if I was using it in handsfree mode.
They already record that those packets were transmitted.
Oh, be real. They don't record every packet. That's tinfoil hat talk.
TL;DR, the phone company is a more reliable measure of a device being active at a set time than your phone itself...
That's not what you said. The claim was that the cell provider could be subpoenaed to determine if the phone was active on the network, as if being active on the network was somehow relevant to any of the distracted driving laws. That's simply nonsense.
unless you are watching the phone live, in which case, there is no need to find out if the phone was in use as it was observed to be in use.
You have no clue, do you? Do you really imagine that when a cop shows up at an accident scene he has been observing the drivers prior to the accident? Of course not. Even were he right there, unless the phone is where he can see it he has no idea what I'm looking at or that I'm using it.
Give up. Asking the cell operator if the phone was "active on the network" at the time of an accident means nothing with respect to the law. Nothing at all. The cell company can't tell what you are doing, especially if you are using a VPN, and they can't tell at all if "handsfree" was in use or not.