PPRuNe Forums - View Single Post - MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Old 2nd Jul 2019, 19:45
  #952 (permalink)  
yoko1
 
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Smythe
One thing I would note about the wiring diagram...the stab trim cutout switches...the way this is wired, it will not be a software fix to get back to the NG configuration. Most unfortunate.
It might surprise you, but I really wish Boeing had left both the cutoff switch wiring logic and the Runaway Stab checklist alone. That being said, I want to make sure that you understand the implications that go with changing things back to the way they were.

Commercial airline pilots generally don’t flip switches for the hell of it just to see what will happen or maybe because they thought it was a good idea at the time. Absent a specific procedure, we cannot even pull and/or reset circuit breakers if we think it would help. Case in point - remember that very distracting stick shaker that activated on both accident aircraft? The CB is right behind the Captain’s left shoulder, and pulling it would immediately silence the stick shaker. There is no authorized procedure to do so. Yes, the Captain always has emergency authority to do what he/she thinks is necessary, but the emphasis nowadays on sticking to the written procedures, and only the written procedures, is so prevalent that many Captains would be reluctant to go out on that limb.

It wasn’t always this way. There was a time when there was a much greater emphasis on systems knowledge. Not only were we expected to know a procedure, but we were expected to know why we were doing each step and what the implications were of every switch we threw and every control we actuated. We were give greater latitude to diverge from a procedure if, based on our knowledge of the underlying system, a different course of action was deemed more prudent. Those days are long gone.

Starting around the early 2000’s, if I recall correctly, our airline in concert with the manufacturers, started a process of “simplifying” a lot of our procedures, removing information regarding underling systems from our manuals, and largely discouraging any independent initiative or trouble-shooting that diverged from the written procedure. The rationale expressed at the time was 1) the concern that pilots could potentially create more problems than solve by troubleshooting, and 2) the desire to quickly contain any malfunction and get the aircraft on the ground. The change to how we handled Runaway Stab Trim was just one of the procedures caught up in this sea change. Part and parcel of the change in this procedure was also a change in the underlying level of system knowledge given to and expected from the pilots.

So you and a few other folks thinks the cutout switch logic should be returned to the NG configuration. I agree! However, that change does absolutely no good unless you go back to something like the earlier procedure. By its very nature, that procedure had more steps (and thus was harder to memorize), potentially took longer to execute because of the extra steps, and required a greater degree of knowledge of what was going on with the system.

Now you are entering my wheelhouse. As I’ve said repeatedly, these accidents not only revealed a design problem, they also revealed a training problem. Sure, give the pilots another tool to fight the malfunction, but that tool does absolutely no good if they don’t know how to use it. We have less detail about what went on in the cockpit of JT610, but we have a much better picture of ET302. Those pilots had, in theory, a specific set of tools available to them to help prevent the loss of control and a subsequent crash - foreknowledge (such as it was at the time) of MCAS, a working Main Electric Stab trim system, an Airspeed Unreliable procedure, and a Runaway Stab Trim procedure. None of these tools were used effectively.

Given this, my suggestion would be that rather than working on new tools, it might be more useful to determine why the existing tools were not properly employed.

Last edited by yoko1; 2nd Jul 2019 at 21:25.
yoko1 is offline