Go Back  PPRuNe Forums > Flight Deck Forums > Rumours & News
Reload this Page >

MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures

Rumours & News Reporting Points that may affect our jobs or lives as professional pilots. Also, items that may be of interest to professional pilots.

MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures

Old 3rd Aug 2019, 09:57
  #1721 (permalink)  
 
Join Date: Apr 2009
Location: Wherever it is this month
Posts: 1,784
Received 75 Likes on 34 Posts
Originally Posted by Notanatp
I've read one account of the test that said all three test pilots recovered the airplane if it was assumed they recognized the problem within 3 seconds (the time to respond to an autopilot runaway pitch trim). The FAA wasn't satisfied with that so it ran additional tests were it allowed the failure to go longer before being recognized, and one of the three pilots either couldn't recover or didn't recovery fast enough. My understanding is that it was on the basis of this addition test where it was assumed that only an exceptional pilot would have recovered, therefore, the catastrophic classification. Has anyone else seen this account, and if it is correct, then doesn't it sound like this is rigged against Boeing?
Further to GordonR’s reply, I would add that the regulatory assumption of a 3-second response time to trim runaway is highly questionable. The operating data manual for my (military) type assumes a 3.5-second pilot response time for loss of thrust during takeoff, and that’s a readily-diagnosed failure where the pilot can reasonably be assumed to be in a state of optimum vigilance with hand on throttle, ready to cut. Contrast that with trim runaway on a 737, where the first second or two could easily be rationalised away as speed trim, leaving only another second to complete the diagnosis and instruct PNF to cutout the trim. Then add more time for PNF to process this startling instruction and find, unguard and flip the switches. Then maybe add more time for CRM SOPs (“state the malfunction”... “memory items”...), depending on company culture and crew experience. The Mentour Pilot video from months ago may have exaggerated this grossly (10:10 to 11:25 at the link below), but whichever way you look at it, an allowance of only 3 seconds to isolate the trim implies an exceptionally optimistic assessment of human startle response.


Last edited by Easy Street; 3rd Aug 2019 at 10:49.
Easy Street is offline  
Old 3rd Aug 2019, 10:25
  #1722 (permalink)  
 
Join Date: Jul 2010
Location: Asia
Posts: 1,534
Received 47 Likes on 29 Posts
When Sulley’s landing in the Hudson River was replicated by Airbus test pilots in the simulator, they managed to get to an airport and land safely. However they knew what was going to happen, when it was going to happen and the exact position of each possible airport.

On the second attempt, with a time penalty to allow for startle effect and diagnosis, they crashed short of the runway.

Three seconds may be enough time to recognise that something is going wrong, such as an engine failure before V1 which means stop. It’s nowhere near long enough to diagnose a fault which could have a number of different causes and come up with the correct response from a myriad of checklists.
krismiler is offline  
Old 3rd Aug 2019, 10:54
  #1723 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by mrdeux
Some years ago, I discovered a way to reliably, and repeatedly, ...
Fast forward ten years...
The point is that the software fix itself was not permanent.
Originally Posted by Water pilot
That is a very important point, and something that I have unfortunately noticed in navigation systems recently. A lot of software these days is done with temporary contractors, so there is no institutional memory about why the code is done the way that it is
This problem can be solved with continuous integration, including automatic testing.
When an issue is detected, it is important to ad an test case for this.
The problem with this is if the outsourced temporary contractors remove a test case instead of fixing a problem they have created..
HighWind is offline  
Old 3rd Aug 2019, 11:11
  #1724 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Easy Street
Further to GordonR’s reply, I would add that the regulatory assumption of a 3-second response time to trim runaway is highly questionable. The operating data manual for my (military) type assumes a 3.5-second pilot response time for loss of thrust during takeoff, and that’s a readily-diagnosed failure where the pilot can reasonably be assumed to be in a state of optimum vigilance with hand on the throttle, ready to cut. Contrast that with trim runaway on a 737, where the first second or two could easily be rationalised away as speed trim, leaving only another second to complete the diagnosis and instruct PNF to cutout the trim. Then add more time for PNF to process this startling instruction and find, unguard and flip the switches. Then maybe add more time for CRM SOPs (“state the malfunction”... “memory items”...), depending on company culture and crew experience. The Mentour Pilot video from months ago may have exaggerated this grossly (10:10 to 11:25 at the link below), but whichever way you look at it, an allowance of only 3 seconds to isolate the trim implies an exceptionally optimistic assessment of human startle response.

Video

I only mentioned the most basic issue, and there are plenty of others, some mentioned in the Seattle Times, and others earlier in this thread:
The first is that the FAA seem to have emphasized that it is not acceptable for pilots to be constantly monitoring the FCC, and relying on them as the last resort to promptly diagnose and catch a catastrophic single point of failure, which can and should be detected by software. BTW, this is a very different approach from the "just-fly-the-aircraft" mantra, raised repeatedly several months ago.

Secondly the video and associated discussion assumes there are always two pilots in the cockpit. This would certainly be true during takeoff, but not necessarily during the cruise. If there is only one pilot at the controls, and a runaway stabiliser trim occurs, the chances of recovery are significantly less. (See AF447 et-al). Take that same video, and imagine a single pilot trying to pull back on the yoke, and flip switches at the same time...

Thirdly it has been widely discussed that once the stabiliser trim goes beyond a certain point, the situation may be unrecoverable except via extreme measures, such as the roller-coaster maneuver. This modification on the MAX (in light of runaway MCAS) actually goes some way to fixing an issue which has been present on the NG model for decades, though there seems to be no pressing need to retrospectively fix all of those aircraft.

The B737 is designed and certified to be flown manually, and removing scenarios that interfere with that should be welcome. IMO a good fix is one that removes a whole class of potential errors, rather than applying a band-aid on top of another band-aid.

Originally Posted by Bend alot
So is the correct response "cut out" or trim to "neutral feel" as per the info given to ET302?

Given a 3.5 second reaction time, after STS seems excessive?
Edit: The check-list for runaway trim is likely to change in view of the proposed changes to the MAX, and probably pilot training too.
GordonR_Cape is offline  
Old 3rd Aug 2019, 11:13
  #1725 (permalink)  
 
Join Date: Dec 2001
Location: Leeds, UK
Posts: 281
Likes: 0
Received 0 Likes on 0 Posts
just to go back to FAA and EASA not being critical of each other's certifications. Lets not forget the elephant in the room, which is aerospace manufacturing has a lot of well paid stable prestigious manufacturing jobs and fly the flag for the country. It's also a hard industry to break into requiring huge capital and knowledge. So EASA has Airbus to protect, FAA Boeing. With the politicians that control their budgets and top jobs all giving them a lot of wink wink nod nod to give the home team all the advantages possible. Think of the Russians at the 1980 Olympics opening the huge doors at each end of the stadium whenever the Russian javelin/shot put team were up.

I posit the ground troops at the FAA and EASA came to a detente position decades ago that one side wouldn't piddle in the others bathwater so long as the other side showed the same restraint.

G
groundbum is offline  
Old 3rd Aug 2019, 11:20
  #1726 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Zeffy
Lemme said the proposed software architecture switch to a “fail-safe,” two-channel system, with each of the computers operating from an independent set of sensors, will not only address the new microprocessor issue but will also make the flawed Maneuvering Characteristics Augmentation System (MCAS) that went haywire on the two crash flights more reliable and safe.
Originally Posted by groundbum
as an IT engineer this changing from flip-flop to dual reduandancy is massive, and unless work started years ago will NOT be ready for September. And if it has been rushed then it needs full end to end testing as it's such a fundamental change. There's a philosophy in coding that for every 2 things you fix, you break something else. It's the nature of the beast.
This is a huge task to design from scratch.
Even moving hardware from a more modern aircraft like B787 to B737, and then adapt the software to handle all the differences in hardware interfaces (protocols etc), user interface, difference in control laws etc.
Do Boeing have a military variant of the B737 with a more modern flight control system, that can be reused on the MAX?
HighWind is offline  
Old 3rd Aug 2019, 12:13
  #1727 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by HighWind
This is a huge task to design from scratch.
Even moving hardware from a more modern aircraft like B787 to B737, and then adapt the software to handle all the differences in hardware interfaces (protocols etc), user interface, difference in control laws etc.
Do Boeing have a military variant of the B737 with a more modern flight control system, that can be reused on the MAX?
The Seattle Times article (from which the quote by Zeffy comes) does not give many details. Indeed, designing a dual-channel system would be a huge task, but the B737 already has two FCCs running in parallel, and proving independent displays to each of the two pilots. AFAIK only one of these is operational at a time, but they can be flight-switched by the pilots, so they must both be active.

My understanding is that the proposed changes only affect the output to the horizontal stabiliser, not all of the other flight controls, which would be a huge task. Since both FCCs are running at the same time, the required task is to fetch those few parameters that control the horizontal stabiliser, and share them between the FCCs. I appreciate that there may be issues of timing and protocols, but it is not impossible to imagine that this can be done, given the many months Boeing has spent analysing every detail of the MAX.

Changing the hardware or FCC protocols is a complete no-no, since this would involve fresh certification and training, and IMO may not be necessary if only a single flight control is being monitored. The whole point is that it should fail-safe, and revert to the pilots, not try to fly the aircraft autonomously.

Leaving the horizontal stabiliser in the last known good position would seem to be a sensible choice, and the aircraft should be controllable in this state. Flipping the trim cutout switches, and reverting to manual trim would remain an option (as before), though a lot less likely to be needed.
GordonR_Cape is offline  
Old 3rd Aug 2019, 12:43
  #1728 (permalink)  
 
Join Date: Apr 2013
Location: Neither here or there
Posts: 316
Likes: 0
Received 0 Likes on 0 Posts
CW247 is offline  
Old 3rd Aug 2019, 12:45
  #1729 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 916
Received 19 Likes on 12 Posts
Originally Posted by GordonR_Cape
.

Leaving the horizontal stabiliser in the last known good position would seem to be a sensible choice, and the aircraft should be controllable in this state. Flipping the trim cutout switches, and reverting to manual trim would remain an option (as before), though a lot less likely to be needed.

1 in 10 or 1 in 1,000,000 in "should be controllable? - in the last known "good position"
Bend alot is offline  
Old 3rd Aug 2019, 12:47
  #1730 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by GordonR_Cape
Edit: The check-list for runaway trim is likely to change in view of the proposed changes to the MAX, and probably pilot training too.
Since the responsibility for preventing a runaway is moved from the pilots to a more reliable flight control system (more reliable than the old system), the checklist might disappear?
The question is if the ‘relay logic’ is going to be removed, and implemented in the flight control system?
E.g. if the 3 phase contractor today controlled by the trim cutout switches, is to be controlled by software?, this might be needed to prevent a classic runaway originating from a fault in the trim motor unit.
And if the yoke trim, and cutout switches is changed to software inputs?
I know many of you don’t like the HAL to have the final authority.
HighWind is offline  
Old 3rd Aug 2019, 13:18
  #1731 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by GordonR_Cape
The Seattle Times article (from which the quote by @Zeffy comes) does not give many details. Indeed, designing a dual-channel system would be a huge task, but the B737 already has two FCCs running in parallel, and proving independent displays to each of the two pilots. AFAIK only one of these is operational at a time, but they can be flight-switched by the pilots, so they must both be active.
I might completely have misunderstood the description in the Seattle Times.
To me there is a big difference between having two independent systems, not sharing the same ‘state space’, where only one at a time is controlling the hardware.
And having two systems operating in unison, sharing ‘state space’, where one is able to takeover bump-less in case the other fails-safe/silent.
The last system requires some degree of byzantine fault tolerance.
HighWind is offline  
Old 3rd Aug 2019, 13:57
  #1732 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 2,451
Likes: 0
Received 9 Likes on 5 Posts
Since the responsibility for preventing a runaway is moved from the pilots to a more reliable flight control system …”
As currently described / discussed, the modified preventative system appears only to be concerned with erroneous trim operation due to MCAS.
If so then the likelihood of a trim runaway in the Max would still be similar to the NG.
Are the risks associated with this still acceptable given the difficulty / impossibility of moving the trim as demonstrated by the accidents and elsewhere.

safetypee is offline  
Old 3rd Aug 2019, 14:22
  #1733 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by Bend alot
1 in 10 or 1 in 1,000,000 in "should be controllable? - in the last known "good position"
Originally Posted by safetypee
As currently described / discussed, the modified preventative system appears only to be concerned with erroneous trim operation due to MCAS.
If so then the likelihood of a trim runaway in the Max would still be similar to the NG.
Are the risks associated with this still acceptable given the difficulty / impossibility of moving the trim as demonstrated by the accidents and elsewhere.
We are in uncharted territory, but my understanding of the Seattle Times article is that the "fail-safe" option is to do nothing to the horizontal stabiliser, in the event of contradictory inputs. This applies to both the old MCAS V1.0, and the newly tested fault configuration.

I have no idea what the relative risks might be, but this seems safer than allowing an uncommanded stabiliser trim runaway. Presumably the FCC software will still try to allow pilot-yoke electrical stabiliser trim, but there may be circumstances in which this also fails, in which case the trim wheels are the last option.

The impossibility of moving the stabiliser, have only been demonstrated when the aircraft is significantly out of trim. If there has been no uncommanded movement of the stabiliser, it is hard to see how this could happen. Perhaps some combination of flaps-up and changes in engine power?

As earlier comments have suggested, we only seem to have half of the story.
GordonR_Cape is offline  
Old 3rd Aug 2019, 14:54
  #1734 (permalink)  
Thread Starter
 
Join Date: Apr 2015
Location: Under the radar, over the rainbow
Posts: 788
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by HighWind
I might completely have misunderstood the description in the Seattle Times.
To me there is a big difference between having two independent systems, not sharing the same ‘state space’, where only one at a time is controlling the hardware.
And having two systems operating in unison, sharing ‘state space’, where one is able to takeover bump-less in case the other fails-safe/silent.
The last system requires some degree of byzantine fault tolerance.
Yes, there's a very big difference. From the Seattle Times article:

With the proposed dual-channel configuration, both computers will be used to activate the automated flight controls. They will each take input from a wholly independent set of sensors (air speed, angle of attack, altitude and so on) and compare outputs. If the outputs disagree, indicating a computer fault, the computers will initiate no action and just let the pilot fly manually.
That is, logically and in terms of system architecture and coding, much more complex than, e.g., a system that merely compares and votes on outputs from multiple sensors. At least conceptually, it appears to be an excellent and long-overdue change, as Lemme says. I can't imagine how it could be implemented, tested and certified for an October return to service -- or any date close to that.
OldnGrounded is offline  
Old 3rd Aug 2019, 14:58
  #1735 (permalink)  
 
Join Date: Dec 2002
Location: UK
Posts: 2,451
Likes: 0
Received 9 Likes on 5 Posts
Gordon,
Fail-safe aspects; agreed - MCAS operation, where output involves trim.

The trim runaway scenario is part of a systems safety assessment applicable to all models of 737, this has to consider failures such as a short circuit, etc, anywhere in the trim electrical system.
The ‘master’ cutout switches inhibit the power supply, but still depend on pilot detection of errant trim movement.
This situation could involve the autopilot, assumed in some circumstances to automatically disengage, or with manual electric trim, or just at random. Each alternative, and the overall situational context, workload, speed, … would affect the crew’s ability to sufficiently understand the situation as a trim runaway.

Yes, only half a story, but if trim runaway is to be considered then how might an improvement be found.


safetypee is offline  
Old 3rd Aug 2019, 18:27
  #1736 (permalink)  
 
Join Date: Feb 2015
Location: The woods
Posts: 5
Likes: 0
Received 3 Likes on 2 Posts
Why Software

Many words have been written about software on this thread and the other Max threads.
How much software should it take to send a signal from an AoA vane to a trim motor?

I don't like the trim solution at all but if you go that route, a couple of relays and a timer
would do.

Going through the computer and writing software to it only complicates the procedure - as we see...
bill fly is offline  
Old 3rd Aug 2019, 18:52
  #1737 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by safetypee
As currently described / discussed, the modified preventative system appears only to be concerned with erroneous trim operation due to MCAS.
If so then the likelihood of a trim runaway in the Max would still be similar to the NG.
Are the risks associated with this still acceptable given the difficulty / impossibility of moving the trim as demonstrated by the accidents and elsewhere.
Implementing a flight control system able to catch all types of runaway will bring B737 in compliance with CS 25.671/25.672.
This will most likely require that the trim ‘relay logic' is implemented in the ‘HAL’.
HighWind is offline  
Old 3rd Aug 2019, 20:39
  #1738 (permalink)  
 
Join Date: May 2008
Location: denmark
Posts: 8
Likes: 0
Received 0 Likes on 0 Posts
Originally Posted by bill fly
Many words have been written about software on this thread and the other Max threads.
How much software should it take to send a signal from an AoA vane to a trim motor?
The software that decide to activate the trim motors based on AoA might be trivial when analyzed alone.
But a large part of the software is about being able to detect faults, in communication interfaces, power supplies, lock stepping, voting between sensors, and many other things.
The system also have to select between: MCAS, Speed/MACH Trim, Two set of trim switches, Two set of yoke cutout switches, end stops, different speeds with flaps up/down etc.

Originally Posted by bill fly
I don't like the trim solution at all but if you go that route, a couple of relays and a timer would do.
No…
If you need a system where a runaway are “extremely improbable” then you need to look at failure modes at each component.
You need to look at each contact set and analyze what happens when it fails open or short.
You also need to look at wires running parallel to each other, where a double insulation fault could supply 28V to a wire after the two cut-out switches.
If you have redundancy, e.g. two relays in series, then you need diagnostic coverage to ensure the first fault is detected before the second fault occur.
If you have an analogue RC timer (like a 555) then you need to detect a capacitor changing value (E.g. electrolyte dryout). In my field of engineering the reliability have increased when mechanical safety relays, was replaced with SIL3 software.

Originally Posted by bill fly
IGoing through the computer and writing software to it only complicates the procedure - as we see...
Designing safety related software, with full certification evidence is hard work.
The root-course of this ordeal is that the computers was designed to a lower reliability specification, on the condition a full trim runaway was manageable by the pilots. I.e. a runaway once in a while was not not an issue.
The reliability have to be increased many orders of magnitude when the responsibility for preventing a runaway is moved from the pilots, to the flight control system.
HighWind is offline  
Old 4th Aug 2019, 01:19
  #1739 (permalink)  
fdr
 
Join Date: Jun 2001
Location: 3rd Rock, #29B
Posts: 2,951
Received 856 Likes on 256 Posts
Originally Posted by CW247


musings...

The response time on briefed and prepared, readily identifiable events is short, and history is littered with examples that flight crew often do not meet these response times. That is for simple events, such as, engine failure or fire warning on a takeoff, GPWS, TCAS RA's. In the MCAS events the crews were given multiple critical cues and no clear indication of the underlying fault. It is not surprising that the limited expected time to respond to the event was longer than the assumptions of response time in the runaway/unscheduled stabiliser motion.

It is also interesting that the human factor training and resource management practices that has become core to current policy comes with a built in response lag while the crew run through their learned processes with dealing with an unusual problem. From the mid 80's, the panacea to some lousy accidents has become the cornerstone of the training of the crews, and along the way, economics have led to a diminishing of the core training in fundamental flying skills, predicated by the belief that CRM trumps handling skills. The regulatory response over the last 10 years to problems from lousy CRM events has been to increase such training, not to take any substantive action on curing the underlying diminishment in flying skills. This is not a complaint on the pilotage skills of the pilots, it merely suggests that the cure to future safety management is not going to be more administrative requirements like MCC, it may be to place additional emphasis on the basic flight skills.

Automation places the crew outside of the control loop, into the monitoring role, and that is one that humans tend to be less than stellar in. Training to ensure effective monitoring is appropriate, NDM is always worth while enhancing, but all of these are related to SA, recognition and recovery. The fundamental flight skills if left to atrophy lead to increased response time and the dynamics of flight usually has a limited time to respond and rectify issues.

Flight crew response time to an event is dependent on skills as well as training, and the skills that underpin the response have become secondary to general management skills.



fdr is offline  
Old 4th Aug 2019, 02:06
  #1740 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 916
Received 19 Likes on 12 Posts
31 July 2018 - FAA indicate the NTSB want the serious issues of MCAS not be released, so that is why the FAA AD is vague on MCAS.

So if it were not for the second crash, MCAS would still be a brief mention in the FAA AD.

I say still because the promised fix was due last April, and the final report for Lion Air not released (Still under NTSB investigation - do not release details).

FAA still saying everything on the MAX certification process was correct and our system has evolved to be the best in the world - we have had only the one death in the last decade, again and again!

That record is simply one flight away from being a triple digit number on any given day/hour, for any number of reasons.
Bend alot is offline  

Thread Tools
Search this Thread

Contact Us - Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service

Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Use of this site indicates your consent to the Terms of Use.