Originally Posted by
DaveReidUK
Could I suggest that if you have any evidence to the contrary, you post it for all to see ?
Otherwise, give the innuendo a rest.
Yoko1 wrote the following 1,551 grammatically perfect words just a short while ago. 1,200 of them were posted within a span of just slightly more than 30 minutes. I write fast, in fact faster than anyone I know. For damn sure faster than any airline pilot I know, of which there are a few. Yoko1 beats both me and any airline pilot by a wide margin. He/she also parsed my somewhat complex offerings to a high degree, finding arguementative weakness where there was any to find. In fact they parsed it so cleanly and exactly it sort of reads like... Well you get the idea.
Perhaps you write this fast, and you know other airline pilots who do as well. In which case these observations are meaningless. But for most of the folks reading this (I think) spooling off 1,551 grammatically perfect (and legally perfect too!) words in the span of a half hour is a feat they have never either attempted or accomplished.
Here you go- and remember, you asked for it!!:
"While I don't disagree in theory, this approach has two distinct problems.
First, as I have mentioned, there has been a very definite shift in philosophy regarding non-normal (formerly known as emergency) procedures industry wide. I don't know if the change was driven by manufacturers, regulators, operators, or some combination of the three, but it has been in place for awhile and unlikely to change. There is a very great reluctance to conduct any action that may be seen as troubleshooting a malfunction which very much includes restoring power to a system, or part thereof, that has malfunctioned. There is probably some historical safety data to back up this philosophy, but there are times when I believe it is overly constraining. Nevertheless, the intent behind most of the significant non-normals nowadays is to shut down and/or contain the malfunction and land the aircraft with what you have left.
Second, let's just say that the switchology was changed back to the NG configuration and we inserted this new step into the existing Runaway Stab Trim procedure. For the sake of discussion we will call it Step 6 since Step 5 is where the cutout switches are used. In order to get to Step 6, the pilots must first correctly navigate Steps 1 thru 5. Since neither accident crew chose to utilize the existing Runaway Stab procedure, much less work through it step by step (and particularly that very critical Step 2), then a new switch with a new step really would not have solved their problem.
As I mentioned above, new tools don't help much if they are not used or used ineffectively. The accident crews had several tools available to them that they either did not use or did not use effectively. I think a bit more time and energy should be directed to figuring out why that was the case before we go down the path of creating new tools.
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.
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-certifiedFCC 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:
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.
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.
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."
************************************************************ ************
If you would like a comprehensive list of another User ID that appeared and then disappeared here you go:
https://www.pprune.org/search.php?se...0&pp=25&page=2
I don't have it in me to copy and past the tens of thousands of words that the individual(s) offered before being banned by mods, but it is not a short read if you choose to parse through it. 209 posts over just slightly more than 30 days.
Over and out-
dce