MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Join Date: Dec 2014
Location: Somerset
Posts: 40
Likes: 0
Received 0 Likes
on
0 Posts
Cutout Switches
Yeah, the fact that the cutout switches are not wired identically in series is a bit strange. It's almost like somebody told the person responsible for the design "you have 5 minute to finish the damn thing, stop messing around with it and let's make it final, we have a deadline.". Anyway, about what the connections through the cutout switches seem to do:
1. connections 2 - 3 are wired in series between the two cutout switches, and are connected to the rest of the circuit in such a way that either of the cutout switches would do two things when used:
- interrupt the power between the circuit breakers and the thumb switches, making the thumb switches inoperable;
- de-energize the relay that connects the 3 phase 115V AC power to the trim motor, basically disconnecting the motor from AC power.
This means just cutting connection 2 - 3 on any of the two switches is enough to disable both manual and automatic electric trim.
2. connections 5 - 6 are wired in series as well between the two switches, and it seems that, if any of the two cutout switches are used, it would interrupt a 28V signal to the FCC, probably indicating to the FCC that the cutout switches have been used. No idea what the FCC will do based on that information.
3. connections 8 - 9 are wired only on the primary cutout switch, and as you said they seem to connect the FCC to the trim motor in some way. No idea why they don't go through the backup cutout switch as well, and exactly what signal they carry between the FCC and the motor. It almost looks like somebody forgot to route that connection through the second cutout switch. I don't see any reason for that.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
I do disagree though that had step6 (re-enable manual electric trim only) been available it would not have helped ET:
Once they realized that manual mechanical trim was not available, due lack of training on use of flip out handles and/or aero loads alone, step 6 would have allowed them to re-trim the aircraft, even though they had not followed the memory items perfectly.
The Boeing trim system found on the 707, 727, and 737 has evolved over time. Initially, there was a fast motor for the pilots use, and a slower motor for the autopilot (back when the autopilot was the only other source of electric stab trim). That logic continued even as systems were added and more things could move the stabilizer (Mach Trim, Speed Trim). The thumb switch moved the trim quickly, the automatics moved it slowly. I don't know about the 737 classics, but on the 737NG the logic also included flap position. Flaps down trim was always faster than flaps up trim, and pilot trim was always faster than automatic trim. However, this logic now created four distinct trim speeds (0.4/0.2/0.27/0.09 deg/sec)
Part of the old procedure in isolating the malfunctioning trim system was a subjective evaluation of whether it was moving fast or slow. If if was moving fast, then the Main Electric Trim was suspect. If it was moving slow, then one of the automatic systems. However, with the existence of four distinct speeds and the fact that the "fast" automatic was now faster than the "slow" Main Electric, there was some concern that pilots might misidentify the malfunctioning system, use the wrong cutout, and aggravate the problem. Keep in mind that a runaway stab is not anything you want to dally with - prompt and correct action are critical. This was one of the drivers for simplifying the procedure in the first place.
One of the issues that has been highlighted with the original MCAS design is that it operated at a higher speed than the Main Electric Trim in the flaps up configuration. Thus, it is entirely possible that this faster movement could have been interpreted as a problem with the Main Electric Trim, and not one of the automatic sources. Logically, then the crew would attempt to restore the automatic trim thus 1) reintroducing the runaway while 2) taking away the most effective tool to stop it - namely the Main Electric Trim.
In fact, this is effectively what happened with ET302. They did not properly run the Runaway Stab procedure, they cutout the trim in a significant out-of-trim conditions, and in an act of desperation they restored the malfunctioning system which promptly drove the stab to the stop. It should be noted this crew also had the opportunity to reactivate the cutout switch, but did not, probably because the MCAS movement at the excessive speed they were flying created such a strong negative g force that they were startled or thrown off balance.
Last edited by yoko1; 3rd Jul 2019 at 20:59.
Join Date: Jul 2014
Location: Harbour Master Place
Posts: 662
Likes: 0
Received 0 Likes
on
0 Posts
I have posted this ad nauseam and will continue to do so. All three crews were faced with this for the entire duration of their flights causing a significant reduction in cognitive capacity and ability to communicate.
I believe a significant number of crews globally, regardless of background, training or experience would have found themselves in very similar circumstances to these two fatal flights because of the interaction between the airspeed unreliable checklist & the inability to manual trim once the MCAS had fired and continued to maintained the stab grossly out of trim. We cannot look at just one of the problems in isolation, what were the crews facing "on the day".
Last edited by CurtainTwitcher; 3rd Jul 2019 at 20:53.
Join Date: Dec 2018
Location: 8th floor
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
Now, about those blips towards the end of the Ethiopian flight, now that we know that using either of the cutout switches disables recording the thumb switch trim commands on the FDR, that could be one possible explanation for the blips. It could be that, while trimming with the thumb switches at the end, they were also playing with the cutout switches and intermittently disabling trim as a result. For example they could have been experimenting with the backup cutout switch, thinking it might be analogous to the autopilot cutout switch on the NG.
Join Date: Apr 2008
Location: Paris
Age: 74
Posts: 275
Likes: 0
Received 0 Likes
on
0 Posts
You are falling into the cognitive trap of believing that this must be an either/or proposition. Problems with design and problems with training are not mutually exclusive. In fact, I'm willing to bet that the final reports are going to have a long list of primary and contributory causes. It would be quite a shame to fix just one of them.
So according to this proposition Boeing needs to fix BOTH the design failure(s) , and the training failure(s).
And on the one side there seems to be an insistence that the hardware be fixed by software only with one AoA sensor input to MCAS, and on the other side that the training not require Max sim time. Somehow BOTH of these "economic requirements" seem problematic.
So it might be useful -as this is not forbidden by the rules- for people who sit in the front seats to make their desire for BOTH a solid fix for MCAS, AS WELL as for the provision of simulator training for runaway stab trim on the MAX, noisily known to Boeing, the FAA, their unions and their employers, and dare I say it, to the press.
Edmund
Join Date: May 2010
Location: Boston
Age: 73
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
Possibly, but let me throw out one more thought that relates to both why the procedure was changed and why the crew might not have made the decision you think they would.
...
...
One of the issues that has been highlighted with the original MCAS design is that it operated at a higher speed than the Main Electric Trim in the flaps up configuration. Thus, it is entirely possible that this faster movement could have been interpreted as a problem with the Main Electric Trim, and not one of the automatic sources. Logically, then the crew would attempt to restore the automatic trim thus 1) reintroducing the runaway while 2) taking away the most effective tool to stop it - namely the Main Electric Trim. In fact, this is effectively what happened with ET302. They did not properly run the Runaway Stab procedure, they cutout the trim in a significant out-of-trim conditions, and in an act of desperation they restored the malfunctioning system which promptly drove the stab to the stop.
...
...
One of the issues that has been highlighted with the original MCAS design is that it operated at a higher speed than the Main Electric Trim in the flaps up configuration. Thus, it is entirely possible that this faster movement could have been interpreted as a problem with the Main Electric Trim, and not one of the automatic sources. Logically, then the crew would attempt to restore the automatic trim thus 1) reintroducing the runaway while 2) taking away the most effective tool to stop it - namely the Main Electric Trim. In fact, this is effectively what happened with ET302. They did not properly run the Runaway Stab procedure, they cutout the trim in a significant out-of-trim conditions, and in an act of desperation they restored the malfunctioning system which promptly drove the stab to the stop.
To restore manual electric trim set the [corect switch name] to enabled, be prepared to immediately disable if runaway trim re-occurs. Do not re-enable should this happen.
Could add a "in event mechanical trim is difficult/impossible " prolog to it.
It does not require crew to determine probable fault cause while performing the memory items, since they remain unchanged.
All of this would be a moot point if mechanical trim as a backup was reliable over the certified range, which it strongly appears not to be.
Speed Typing
If someone's head is exploding, then that person doesn't really understand what was reported. Frankly, I'm a little surprised that you are bringing this up again. You quoted a post of mine a few days back which explained exactly why this is not the smoking gun that everyone wants it to be, but you have apparently chosen to ignore that response and slap this red herring back on the table.
Let's go through it again, with a little more detail. First of all, this is not a smoking gun because it is not even the same gun. The problem was discovered when the new, yet to be flight-certified FCC software was being stress-tested in a Boeing engineering simulator. This simulator can be used to plug in different components of flight control hardware and software during both development and test phases and is part of the certification process of any new aircraft or related subsystems. The tests that were being conducted intentionally introduced faults into the FCC in order to see how it would respond. Normally, a fault on a single FCC should attempt to hand off the process to a different processor on the same FCC, or failing that, to a different FCC (there are two on the 737). The test did not involve the MCAS subroutines of the new FCC software.
This news was reported through several outlets, but Leeham New's seems to have the best detail:
Bjorn’s Corner: New pitch trim issue forces further changes to 737 MAX software
Quoting the article:
.
and:
As currently understood, the MCAS software on the accident aircraft did not input nose down trim because of a fault, but simply because it performed a task exactly how it was programmed to do so. Yes, it was ill-conceived program, but there is no indication that it created a fault condition.
All the test above tells us is that the new software has either a coding issue (which may involve just reprogramming work) or it is demanding more than the processor can handle (which may involve a change in processors). There was extensive discussion previously in this thread by individuals with background in this kind of work who explained all the ways in which errors could have been introduced into the new software.
Also important to understand is that this type of testing was performed on the original Flight Control components (hardware/firmware/software) that were part of the originally certified aircraft. Certainly one might suggest that this testing missed something. Possible, but this is where the accident investigation process steps in.
In order to determine the cause(s) of an accident, to include an attempt to replicate all the physical and electronic evidence left behind, the accident investigators will run every suspect component through a battery of tests. Since the actual components were destroyed, it is almost certain that the investigation teams pulled similar components from the field and then used the same (or similar) Boeing engineering simulator to test these components for all manner of possible failures, including the exact tests run by the FAA as described above. Ideally, these components would have been produced in the same lots as the those in the accident aircraft. Since there hasn't been much reticence in reporting all the other existing flaws with the MCAS and related software, it doesn't seem likely that an issue that caused a fault like the one reported for the new software would be selectively concealed from the public. Another item for the "Dog that did not bark" file.
Back to the Leeham article which first quotes from a so-called 8-K public filing:
That last point is very important. If Boeing was aware of an issue that might further delay the re-certification of the MAX, then it must provide some kind of disclosure since it is material information that would effect the stock price. Any issues with components of the Main Electric Trim system would likely require significant rework (redesign and/or replacement of switches, wires, relays, motors, controller, etc.) and add to the already known delay. By SEC rules, this type of delay would require a similar 8-K report by Boeing. One more dog that isn't barking.
Lots and lots of dogs not barking, and there is a very good reason for it.
Let's go through it again, with a little more detail. First of all, this is not a smoking gun because it is not even the same gun. The problem was discovered when the new, yet to be flight-certified FCC software was being stress-tested in a Boeing engineering simulator. This simulator can be used to plug in different components of flight control hardware and software during both development and test phases and is part of the certification process of any new aircraft or related subsystems. The tests that were being conducted intentionally introduced faults into the FCC in order to see how it would respond. Normally, a fault on a single FCC should attempt to hand off the process to a different processor on the same FCC, or failing that, to a different FCC (there are two on the 737). The test did not involve the MCAS subroutines of the new FCC software.
This news was reported through several outlets, but Leeham New's seems to have the best detail:
Bjorn’s Corner: New pitch trim issue forces further changes to 737 MAX software
Quoting the article:
.
and:
As currently understood, the MCAS software on the accident aircraft did not input nose down trim because of a fault, but simply because it performed a task exactly how it was programmed to do so. Yes, it was ill-conceived program, but there is no indication that it created a fault condition.
All the test above tells us is that the new software has either a coding issue (which may involve just reprogramming work) or it is demanding more than the processor can handle (which may involve a change in processors). There was extensive discussion previously in this thread by individuals with background in this kind of work who explained all the ways in which errors could have been introduced into the new software.
Also important to understand is that this type of testing was performed on the original Flight Control components (hardware/firmware/software) that were part of the originally certified aircraft. Certainly one might suggest that this testing missed something. Possible, but this is where the accident investigation process steps in.
In order to determine the cause(s) of an accident, to include an attempt to replicate all the physical and electronic evidence left behind, the accident investigators will run every suspect component through a battery of tests. Since the actual components were destroyed, it is almost certain that the investigation teams pulled similar components from the field and then used the same (or similar) Boeing engineering simulator to test these components for all manner of possible failures, including the exact tests run by the FAA as described above. Ideally, these components would have been produced in the same lots as the those in the accident aircraft. Since there hasn't been much reticence in reporting all the other existing flaws with the MCAS and related software, it doesn't seem likely that an issue that caused a fault like the one reported for the new software would be selectively concealed from the public. Another item for the "Dog that did not bark" file.
Back to the Leeham article which first quotes from a so-called 8-K public filing:
That last point is very important. If Boeing was aware of an issue that might further delay the re-certification of the MAX, then it must provide some kind of disclosure since it is material information that would effect the stock price. Any issues with components of the Main Electric Trim system would likely require significant rework (redesign and/or replacement of switches, wires, relays, motors, controller, etc.) and add to the already known delay. By SEC rules, this type of delay would require a similar 8-K report by Boeing. One more dog that isn't barking.
Lots and lots of dogs not barking, and there is a very good reason for it.
Have to give you credit for one thing, your speed of typing and ability to compose an arguement has me very impressed. A mere 8 minutes after replying to my post, your respond to Wonkazoos post in a very well drafted piece including a number of quotes from other articles. For a self confessed 737 pilot you missed an alternative career in journalism.
Alchad
Join Date: Mar 2015
Location: antipodies
Posts: 75
Likes: 0
Received 0 Likes
on
0 Posts
My personal view and this applies to both B and A is that they are remiss in allowing ANY alarms, flight director, stickpusher, or any other flight display other than Gyro , heading, thrust in any case of "does not compute", "input out of range" or any other case where the software self check sanity check throws an error. If the computer is not 100% SURE then turn it all off
what this comes down to is that there needs to be a CLEARLY DEFINED REVERSION STATE that is REGULARLY TRAINED AND FLOWN and that in all case of unreliable input the aircraft should revert to this defined and trained for state (without spurious alarms!)
what this comes down to is that there needs to be a CLEARLY DEFINED REVERSION STATE that is REGULARLY TRAINED AND FLOWN and that in all case of unreliable input the aircraft should revert to this defined and trained for state (without spurious alarms!)
Join Date: Dec 2014
Location: Somerset
Posts: 40
Likes: 0
Received 0 Likes
on
0 Posts
Point taken - I was trying to point out that a description that is essentially Eaton advertising blurb may be overplaying the 'microprocessor' aspect of something that isn't quite so spangly. My guess (and that's all it is) is that you are correct and that the IGBTs are processor driven. I'd just suggest that the software is probably embedded and not particularly complex given the nature of that task so it may be doing digitally what was previously done by analogue means.
One of the reasons that seem to me to point away from the stab motor is that as far as I understand it the stab 'motor' did as we think it was told by MCAS (happy to be challenged on that)
One of the reasons that seem to me to point away from the stab motor is that as far as I understand it the stab 'motor' did as we think it was told by MCAS (happy to be challenged on that)
Join Date: Jul 2014
Location: Harbour Master Place
Posts: 662
Likes: 0
Received 0 Likes
on
0 Posts
Psychophysiological entity
re the chip overload.
I hope that doesn't include the basic use of the thumb switches.
Again I feel my old bones needing there to be reversion to an aircraft with nothing but the electric trim thumb switches. And then, nothing but a crank and cables which won't fight back.
There has to be the potential for this aircraft to become a basic flying machine.
Member Berry #988
What a good point. A last ditch try of that B/U switch by itself?
and it delayed the actions the FAA pilot could take to stop the trim runaway.
Again I feel my old bones needing there to be reversion to an aircraft with nothing but the electric trim thumb switches. And then, nothing but a crank and cables which won't fight back.
There has to be the potential for this aircraft to become a basic flying machine.
Member Berry #988
For example they could have been experimenting with the backup cutout switch, thinking it might be analogous to the autopilot cutout switch on the NG.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
My personal view and this applies to both B and A is that they are remiss in allowing ANY alarms, flight director, stickpusher, or any other flight display other than Gyro , heading, thrust in any case of "does not compute", "input out of range" or any other case where the software self check sanity check throws an error. If the computer is not 100% SURE then turn it all off
what this comes down to is that there needs to be a CLEARLY DEFINED REVERSION STATE that is REGULARLY TRAINED AND FLOWN and that in all case of unreliable input the aircraft should revert to this defined and trained for state (without spurious alarms!)
what this comes down to is that there needs to be a CLEARLY DEFINED REVERSION STATE that is REGULARLY TRAINED AND FLOWN and that in all case of unreliable input the aircraft should revert to this defined and trained for state (without spurious alarms!)
And yes, these alarms are very, very annoying and very, very much a source of distraction. If someone were to make me King of Boeing, one of my first commands would be to install a master button in the cockpit of every airliner that enabled me to silence any alarm, even if only temporarily, and effectively tell the plane to shut the flock up and let me do my job. I seriously hope that one of the recommendations out of these accidents is to provide some relief and/or mechanisms that will allow pilots to silence these kind of alarms when it is obvious that they are erroneous.
What is particularly troubling is that some alarms can be silenced by the simple act of pulling an associated circuit breaker that is within easy reach (the left stick shaker CB is behind the Captain's left shoulder), but we are procedurally not allowed to do so. Once upon a time, it was allowed at the Captain's discretion, but no longer. A Captain can always take a chance and play the "Captain's Emergency Authority" card and do what he/she thinks is needed to save the ship, but he/she would then be counting on a sympathetic Fed/Supervisor/Chief Pilot to agree with his reasoning at the subsequent hearing. I'm pretty sure the penultimate Lion Air 610 crew flew the aircraft the rest of the way to landing with the stick shaker going off, and I am aware of other similar events in which the crew did not feel justified in pulling the CB because the lack of any procedure or policy authorizing such an action. This is the environment we operate in. This is the job we signed up for.
Back to my wheelhouse - are we looking adequately at the training, certification, and operating environment that these crews were immersed in? If the airlines/regulators/manufacturers expect pilots to aviate, navigate, communicate and work an active malfunction while there is an ongoing, distracting alarm that cannot be silenced, then they can damn well train pilots to that standard. I can assure you that is not how we currently train.
Last edited by yoko1; 4th Jul 2019 at 01:32.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
Have to give you credit for one thing, your speed of typing and ability to compose an arguement has me very impressed. A mere 8 minutes after replying to my post, your respond to Wonkazoos post in a very well drafted piece including a number of quotes from other articles. For a self confessed 737 pilot you missed an alternative career in journalism.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
Lifting a comment from the thread Loss of Control In-Flight-Flight Crew Training because it so germane:
Could not have said it better myself.
.
UK CAA Safety Notice 2019/005 landed in my inbox just now.
It is a devastating indictment of regulators and operators who have allowed a situation to develop where this SN is necessary.
Stripped of the dreadful jargon-ridden, ungrammatical verbiage it is telling everyone to get back to teaching and practising basic flying skills.
UK CAA Safety Notice 2019/005 landed in my inbox just now.
It is a devastating indictment of regulators and operators who have allowed a situation to develop where this SN is necessary.
Stripped of the dreadful jargon-ridden, ungrammatical verbiage it is telling everyone to get back to teaching and practising basic flying skills.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
This is one of my biggest pet peeves about the 737 (can't speak for other aircraft, but maybe other operators can chime in). There are quite a few noise-makers that activate when certain parameters are exceeded. Some of them can be silenced, but many cannot. Unfortunately, erroneous alarms can be also triggered by underlying malfunctions (as demonstrated by the stick shaker in the MAX accidents), and pilots are expected to just deal with them.
And yes, these alarms are very, very annoying and very, very much a source of distraction. If someone were to make me King of Boeing, one of my first commands would be to install a master button in the cockpit of every airliner that enabled me to silence any alarm, even if only temporarily, and effectively tell the plane to shut the flock up and let me do my job. I seriously hope that one of the recommendations out of these accidents is to provide some relief and/or mechanisms that will allow pilots to silence these kind of alarms when it is obvious that they are erroneous.
What is particularly troubling is that some alarms can be silenced by the simple act of pulling an associated circuit breaker that is within easy reach (the left stick shaker CB is behind the Captain's left shoulder), but we are procedurally not allowed to do so. Once upon a time, it was allowed at the Captain's discretion, but no longer. A Captain can always take a chance and play the "Captain's Emergency Authority" card and do what he/she thinks is needed to save the ship, but he/she would then be counting on a sympathetic Fed/Supervisor/Chief Pilot to agree with his reasoning at the subsequent hearing. I'm pretty sure the penultimate Lion Air 610 crew flew the aircraft the rest of the way to landing with the stick shaker going off, and I am aware of other similar events in which the crew did not feel justified in pulling the CB because the lack of any procedure or policy authorizing such an action. This is the environment we operate in. This is the job we signed up for.
Back to my wheelhouse - are we looking adequately at the training, certification, and operating environment that these crews were immersed in? If the airlines/regulators/manufacturers expect pilots to aviate, navigate, communicate and work an active malfunction while there is an ongoing, distracting alarm that cannot be silenced, then they can damn well train pilots to that standard. I can tell you now that they do not.
And yes, these alarms are very, very annoying and very, very much a source of distraction. If someone were to make me King of Boeing, one of my first commands would be to install a master button in the cockpit of every airliner that enabled me to silence any alarm, even if only temporarily, and effectively tell the plane to shut the flock up and let me do my job. I seriously hope that one of the recommendations out of these accidents is to provide some relief and/or mechanisms that will allow pilots to silence these kind of alarms when it is obvious that they are erroneous.
What is particularly troubling is that some alarms can be silenced by the simple act of pulling an associated circuit breaker that is within easy reach (the left stick shaker CB is behind the Captain's left shoulder), but we are procedurally not allowed to do so. Once upon a time, it was allowed at the Captain's discretion, but no longer. A Captain can always take a chance and play the "Captain's Emergency Authority" card and do what he/she thinks is needed to save the ship, but he/she would then be counting on a sympathetic Fed/Supervisor/Chief Pilot to agree with his reasoning at the subsequent hearing. I'm pretty sure the penultimate Lion Air 610 crew flew the aircraft the rest of the way to landing with the stick shaker going off, and I am aware of other similar events in which the crew did not feel justified in pulling the CB because the lack of any procedure or policy authorizing such an action. This is the environment we operate in. This is the job we signed up for.
Back to my wheelhouse - are we looking adequately at the training, certification, and operating environment that these crews were immersed in? If the airlines/regulators/manufacturers expect pilots to aviate, navigate, communicate and work an active malfunction while there is an ongoing, distracting alarm that cannot be silenced, then they can damn well train pilots to that standard. I can tell you now that they do not.
Technically there are already as many parked as have been delivered. And a few more!! (Because they are all parked...)
This useless post brought to you by Light Always Airways. (LAA) "We spend lesser so you can go higher!!"
On an unrelated note: Who builds an airplane with two switches ostensibly in series, but in reality not so for one channel, to do the job of just one previously?? Who states that these are both "redundant??" when clearly they do different things?? What does that open channel between the FCC and God knows actually do, and since it didn't exist before can we safely accept that it is an artifact of MCAS??
I could go on for hours. The one thing our favorite expert and everyone else has right is this: We don't know squat. We know a lot, and from that we may draw inferences, but as to actual facts: We got stinko.
Here's the thing I do not understand (This will be the end of this lumbering and highly lubricated post I promise): Boeing creates a **** system that kills north of 300 people. OK,
Because I treasure all my fellow travelers, YokoDriver I'll help you out here: Boeing killed 300+ with the help of some less than stellar piloting.
OK, that's not good by any measure.
But then...
A few months go by...
And, according to YokoDriver Boeing gives the FAA some software to play with. (Now let's be clear here. By play with we mean molest completely and bend any way you can to try to make it break. Because that's what you do when your previous offering killed 300+ right??)
Anyway, and the point of the entire sad story is this: No matter how they got here, when the simulation was run:
THE FAA TEST PILOTS BARELY RECOVERED THE AIRPLANE AFTER IT TRIED TO SCREW ITSELF INTO THE GROUND.
Key phrase there: "THE AIRPLANE TRIED TO SCREW ITSELF INTO THE GROUND."
Only one of two possible things happened here.
a) The software tested was Boeing's original brew. Meaning not only is the now known MCAS AOA failure mode present, there was ANOTHER ONE, a failure mode that would try to screw the airplane into the ground.
or
b) Boeing sent over a "NEW" software package, and it had a failure mode that would try to screw the airplane into the ground.
Previous posters have argued indignantly using some of the points above, but seeing them in full is illuminating to say the least.
Can anyone please tell me why heads didn't explode with the headline last Thursday??
Either Boeing software had TWO flaws that would try to make a smoking hole in the ground, or they sent a new updated version to the FAA for a test-run with a flaw that would try to make a smoking hole in the ground.
Sorry for the lugubrious rant-
dce
This useless post brought to you by Light Always Airways. (LAA) "We spend lesser so you can go higher!!"
On an unrelated note: Who builds an airplane with two switches ostensibly in series, but in reality not so for one channel, to do the job of just one previously?? Who states that these are both "redundant??" when clearly they do different things?? What does that open channel between the FCC and God knows actually do, and since it didn't exist before can we safely accept that it is an artifact of MCAS??
I could go on for hours. The one thing our favorite expert and everyone else has right is this: We don't know squat. We know a lot, and from that we may draw inferences, but as to actual facts: We got stinko.
Here's the thing I do not understand (This will be the end of this lumbering and highly lubricated post I promise): Boeing creates a **** system that kills north of 300 people. OK,
Because I treasure all my fellow travelers, YokoDriver I'll help you out here: Boeing killed 300+ with the help of some less than stellar piloting.
OK, that's not good by any measure.
But then...
A few months go by...
And, according to YokoDriver Boeing gives the FAA some software to play with. (Now let's be clear here. By play with we mean molest completely and bend any way you can to try to make it break. Because that's what you do when your previous offering killed 300+ right??)
Anyway, and the point of the entire sad story is this: No matter how they got here, when the simulation was run:
THE FAA TEST PILOTS BARELY RECOVERED THE AIRPLANE AFTER IT TRIED TO SCREW ITSELF INTO THE GROUND.
Key phrase there: "THE AIRPLANE TRIED TO SCREW ITSELF INTO THE GROUND."
Only one of two possible things happened here.
a) The software tested was Boeing's original brew. Meaning not only is the now known MCAS AOA failure mode present, there was ANOTHER ONE, a failure mode that would try to screw the airplane into the ground.
or
b) Boeing sent over a "NEW" software package, and it had a failure mode that would try to screw the airplane into the ground.
Previous posters have argued indignantly using some of the points above, but seeing them in full is illuminating to say the least.
Can anyone please tell me why heads didn't explode with the headline last Thursday??
Either Boeing software had TWO flaws that would try to make a smoking hole in the ground, or they sent a new updated version to the FAA for a test-run with a flaw that would try to make a smoking hole in the ground.
Sorry for the lugubrious rant-
dce
This system has twice demonstrated that its malfunction (even with software acting as intended) must be classified as Catastrophic. This means that proper compliance requires DAL A. Question is, what is the current DAL of this software? While coding changes might be proposed and completed with relative simplicity, an upgrade of the DAL requires a complete reaccomplishment of the software development.
Not a trivial task at all, and one I fear the FAA would not choose to impose. Hopefully, other CAA, including EASA, will not be so accommodating. We’ll see. Well maybe they won’t let us see.