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 27th Jun 2019, 08:14
  #721 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 122
Originally Posted by patplan View Post
The poor old processor got overloaded by data came from various sources? I think I posted somewhere that the new routine(s) associated with the MCAS data could overwhelm the control system from time to time, especially during the failure mode [i.e. vane's malfunction].
New flaw discovered on Boeing 737 Max, sources say
...A new flaw has been discovered in the computer system for the Boeing 737 Max that could push the plane downward, according to two sources familiar with the testing, an issue that is expected to further delay the aircraft's return to service.

A series of simulator flights to test new software developed by Boeing revealed the flaw, according to one of the sources...

...In simulator tests, government pilots discovered that a microprocessor failure could push the nose of the plane toward the ground. It is not known whether the microprocessor played a role in either crash.
When testing the potential failure of the microprocessor in the simulators, "it was difficult for the test pilots to recover in a matter of seconds," one of the sources said. "And if you can't recover in a matter of seconds, that's an unreasonable risk.".

Boeing engineers are now trying to address the issue, which has led to another delay in recertifying the 737 Max...

===========



- https://edition.cnn.com/2019/06/26/p...law/index.html
Seems we need another Band-Aid!

They have not even got in a real MAX yet, so what are we now looking at for flight testing 6 -12 months after the fix of the fix is presented?
Bend alot is offline  
Old 27th Jun 2019, 08:18
  #722 (permalink)  
 
Join Date: Oct 2017
Location: Tent
Posts: 122
Double post sorry.

Last edited by Bend alot; 27th Jun 2019 at 13:07.
Bend alot is offline  
Old 27th Jun 2019, 08:47
  #723 (permalink)  
 
Join Date: Oct 2018
Location: uk
Posts: 3
If an unidentified failure - cpu overload due to MCAS operations - leads to an unidentified fail state - uncontrollable operation of controls - is this a system operating as expectable since the designers havent designed the system properly?
Systems analysis requires identification of all reasonably foreseeable events, and 'computer operation overload', and the resultant fail state condition must surely be one of them.
peteturbo is offline  
Old 27th Jun 2019, 09:34
  #724 (permalink)  
 
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 57
Posts: 325
Originally Posted by patplan View Post
The poor old processor got overloaded by data came from various sources? I think I posted somewhere that the new routine(s) associated with the MCAS data could overwhelm the control system from time to time, especially during the failure mode [i.e. vane's malfunction].

https://edition.cnn.com/2019/06/26/p...law/index.html
Not many details in the articles, so read between the lines: The nose-up trim commands from the yoke have to be processed in software, in order for the pilot to override MCAS. Many people on this thread assume this is instantaneous. If MCAS is busy (10 second countdown), or something else is running in the background, this may overload the processor. Just speculating, but this is exactly the kind of unanticipated scenario that may trigger an malfunction.
GordonR_Cape is offline  
Old 27th Jun 2019, 10:12
  #725 (permalink)  
 
Join Date: Jun 2008
Location: Cambridge UK
Posts: 107
Originally Posted by fox niner View Post
Very often, as I placed the stab trim full nose down with the trim wheel, the following would regularly happen.
It regularly was VERY hard to return the stab trim. INCLUDING using the trim wheels. You had to yank and pull the trim wheels quite a few times so that they would snap free, and the it was usable again and trimmable.
And this was at the gate/de-icing platform. Airspeed was zero.
If this “snap free” hardware problem turns out to be the issue here, than...Boeing is in for a hardware modification. That requires a totally new certification.
I suspect the MCAS is capable of driving the trim wheels all the way forward and capable of causing this same “snap free” lockup as I experinced regularly at the gate.
[SLF & retired s/w engineer]
Sounds like an "interesting" failure mode. However it wouldn't show up in the current-simulator based testing unless Boeing have modelled it, which I really doubt.

PS As this failure-mode might occur whenever the trim end-stops are reached it would be comforting to know that a "responsible adult" in the FAA has investigated
the likelihood and consequences.

PPS As the problem happened regularly during de-icing it should be easy to recreate on ground tests of the linkage. Do the maintenance engineers know about it?
Peter H is online now  
Old 27th Jun 2019, 10:33
  #726 (permalink)  
 
Join Date: Apr 2014
Location: YARM
Age: 69
Posts: 93
Newspaper reports understating what went down during latest sim tests.

Last edited by unworry; 27th Jun 2019 at 10:36. Reason: edit: waiting till a reputable source reports on the extent of the failures
unworry is offline  
Old 27th Jun 2019, 10:42
  #727 (permalink)  
 
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Originally Posted by Maninthebar View Post
In the event that MCAS (or another system) is active the design is that trim signal from the yoke switches overrides* the system-derived input. The decision on which takes priority must be 'processed'. Ergo SOME processing power is involved and a processor, somewhere, is in line.

* I have used the word 'override' but I think 'cancel' might be better in the case of MCAS, or even postpone!
A simple relay (well, simple in an aviation context) is all that it takes to remove MCAS from the trim circuit to allow the main electric trim to override and function normally. There was a circuit diagram of the trim logic posted on one of these threads, and I could probably dig one up with a little time if you really need to see it. Again, a reminder that all manner of complex tasks used to be managed in aviation systems before the advent of IC processors.

That being said, the 5-second pause that MCAS is supposed to take after a main electric trim input is likely incorporated in the circuit logic (which resides within the Flight Control Computer or FCC), so it is possible that this aspect of the MCAS side of the system may be affected by processor issues.

Last edited by yoko1; 27th Jun 2019 at 11:03.
yoko1 is offline  
Old 27th Jun 2019, 10:51
  #728 (permalink)  
 
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Originally Posted by fox niner View Post
About 15 years ago, when I was still flying PG and NG 737’s, we had a de-icing procedure that required us to place the stabilizer full nose down.
Including using the trim wheels, all the way to the stop.
It was said that this was necessary, so that the de-icing fluid could run down the aft end of the horizontal tail structure.
This procedure was abandoned later, and repaced by a neutral stab trim setting. So that fluid would not accumulate between the stabilizer and elevator, and subsequently freeze up during flight, impairing elevator authority.
Why am I telling you guys this? Well...
Very often, as I placed the stab trim full nose down with the trim wheel, the following would regularly happen.
It regularly was VERY hard to return the stab trim. INCLUDING using the trim wheels. You had to yank and pull the trim wheels quite a few times so that they would snap free, and the it was usable again and trimmable.
And this was at the gate/de-icing platform. Airspeed was zero.
Yep, I remember this. In fact, I'm pretty sure that one of the reasons that the stab trim is even capable of being positioned so far in the nose down direction was to accommodate ground related procedures such as this as I've never seen the stab go much more forward than about 4.0 units in flight. As I recall, the problem was that moisture was getting inside the tailcone area and the stab and/or the limit relay was getting frozen against the stop. This is one of the reasons the procedure was ultimately changed.
yoko1 is offline  
Old 27th Jun 2019, 10:59
  #729 (permalink)  
 
Join Date: Jan 2013
Location: UK
Age: 58
Posts: 24
more than a bug fix is needed

We are all speculating based on incomplete information but it has been apparent that current concept is flawed and this could not be resolved by a software fix even if it successfully addressed whatever issues had caused the two crashes. We know that a single fault could cause the stabiliser to be driven to a position where it is hard or impossible to recover. Addressing specific fault scenarios without addressing this wider concern is not a full solution. We have partial information and those involved are competent people so we must assume that this is beng addressed however the timescales for the solution always seemed over optimistic.
PiggyBack is offline  
Old 27th Jun 2019, 11:06
  #730 (permalink)  
 
Join Date: Jul 2002
Location: Ireland
Posts: 472
Do we have anyone on here who designs/maintains flight simulators?

The Reuters report says that the ‘additional issues’ were discovered in the sim. Is the hardware in a flight sim identical to the actual hardware in the aircraft? As a flight simulator is primarily a training aid and not a test bed for hardware I would assume that the simulator system hardware emulates, and software models what is in the aircraft, rather than being identical to the actual circuits and microprocessors found on the aircraft.

If this is the case then great care should be taken in drawing any hardware deficiency conclusions away from an actual flying aircraft.
Speed of Sound is offline  
Old 27th Jun 2019, 11:12
  #731 (permalink)  
 
Join Date: Apr 2014
Location: YARM
Age: 69
Posts: 93
Originally Posted by Speed of Sound View Post
The Reuters report says that the ‘additional issues’ were discovered in the sim.
They were referring to incidents in test flights conducted in the sim ... not issues with the sim platform itself.

Apologies if I'm misreading the jist of your question

Last edited by unworry; 27th Jun 2019 at 11:42.
unworry is offline  
Old 27th Jun 2019, 11:14
  #732 (permalink)  
 
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Originally Posted by Speed of Sound View Post
Do we have anyone on here who designs/maintains flight simulators?

The Reuters report says that the ‘additional issues’ were discovered in the sim. Is the hardware in a flight sim identical to the actual hardware in the aircraft? As a flight simulator is primarily a training aid and not a test bed for hardware I would assume that the simulator system hardware emulates, and software models what is in the aircraft, rather than being identical to the actual circuits and microprocessors found on the aircraft.

If this is the case then great care should be taken in drawing any hardware deficiency conclusions away from an actual flying aircraft.
Aviation Week reports that the tests were conducted in Boeing's engineering flight simulator (i.e. a testing platform, not a training device), so I suspect that from a system standpoint they were emulating the aircraft hardware and software as much as feasible.
yoko1 is offline  
Old 27th Jun 2019, 11:23
  #733 (permalink)  
 
Join Date: Jul 2002
Location: Ireland
Posts: 472
Originally Posted by yoko1 View Post
Aviation Week reports that the tests were conducted in Boeing's engineering flight simulator (i.e. a testing platform, not a training device), so I suspect that from a system standpoint they were emulating the aircraft hardware and software as much as feasible.
Thanks.

That makes a lot more sense if they are drawing actual hardware performance conclusions from the test ‘flights’. If I was building a commercial flight simulator I would stick all the processing in a modern quad core based computer with a shed load of RAM with a very accurately written programme to model what happens in the actual aircraft (much like a high end gaming flight sim).
Speed of Sound is offline  
Old 27th Jun 2019, 11:33
  #734 (permalink)  
 
Join Date: Jul 2013
Location: Norway
Age: 52
Posts: 111
From Aviation Week

It seems in fact like the latest problem is related to FCC overload. The article says the THS is slow to react to manual trim inputs from the thumb switches when simulating a trim runaway. Thereby forcing the aircraft into a steep dive before the THS finally starts reacting to the thumb switches. It is not clear if this problem can be fixed by a software update or if it requires time consuming hardware changes.

WASHINGTON—FAA test pilots have flagged a new issue in the Boeing 737 MAX flight control system that must be addressed as part of changes being made to get the aircraft back into service, Aviation Week has learned.The issue came to light within the last week during tests in Boeing’s MAX engineering flight simulator, or e-cab, a source with knowledge of the situation confirmed.

The pilots were simulating a runaway stabilizer scenario and running through the requisite emergency-response checklist. A key early step is to use control column-mounted electric-trim switches to command horizontal stabilizer movement to counter the runaway. A subsequent step, if needed, is to toggle cutout switches that disable the trim motors. According to the source, the FAA pilots found response to the electric-trim inputs took too long. “They had a difficult time quickly resolving the situation,” the source explained. The issue has been traced to how quickly a specific flight control computer chip is processing data, the source said. What is not clear: whether the chip itself needs to be changed, or if a software update will address the issue. A second industry source said that a software fix is possible—and certainly would be preferable for Boeing, which suggested in a statement that a software modification will be sufficient.

Changing chips could further delay the MAX’s return to service, as it would likely require new chip architecture as well as changing chips on nearly more than 500 MAXs in airline fleets or ready to be delivered.“The FAA is following a thorough process, not a prescribed timeline, for returning the Boeing 737 MAX to passenger service,” the agency said in a statement. “The FAA recently found a potential risk that Boeing must mitigate. ”Boeing said the issue is “an additional requirement” that the FAA “has asked the company to address through the software changes that the company has been developing” for the MAX. “Boeing agrees with the FAA’s decision and request and is working on the required software to address the FAA’s request. Addressing this condition will reduce pilot workload by accounting for a potential source of uncommanded stabilizer motion,” it added.

The MAX has been grounded since mid-March following two fatal accidents in five months. Boeing has been working on changes to the MAX’s flight control system, specifically the maneuvering characteristics augmentation system (MCAS) flight control law. MCAS commands automatic horizontal stabilizer inputs in certain flight scenarios, and it activated erroneously in both accident sequences. Its failure can result in a runaway stabilizer scenario, which pilots are supposed to mitigate by following the “stabilizer runaway” checklist. Trimming the aircraft using the control-column switches is a key first step meant to stabilize the aircraft and enable the pilots to safely de-power horizontal stabilizer trim motors using cutout switches mounted on the aircraft’s center console. In both accident sequences—the October 2018 crash of Lion Air Flight 610 and Mar. 10 crash of Ethiopian Airlines Flight 302—the crews used the column-mounted switches to counter MCAS. Neither followed the runaway stabilizer checklist step-by-step, and were overcome by MCAS’s repeated inputs that forced the aircraft’s nose down due to erroneous angle-of-attack data being fed to the flight control computer. Both accident sequences ended with uncontrollable dives. The newly discovered issue came up during a very specific failure scenario, and it is not clear whether it has any link to either MAX accident sequence, the first source emphasized.
SteinarN is offline  
Old 27th Jun 2019, 11:42
  #735 (permalink)  
 
Join Date: Apr 2018
Location: Sudbury, Suffolk
Posts: 74
Originally Posted by yoko1 View Post
A simple relay (well, simple in an aviation context) is all that it takes to remove MCAS from the trim circuit to allow the main electric trim to override and function normally. There was a circuit diagram of the trim logic posted on one of these threads, and I could probably dig one up with a little time if you really need to see it. Again, a reminder that all manner of complex tasks used to be managed in aviation systems before the advent of IC processors.
APPEARS to be contradicted by post 730

?
Maninthebar is offline  
Old 27th Jun 2019, 11:52
  #736 (permalink)  
 
Join Date: Apr 2008
Location: back of beyond
Posts: 93
Originally Posted by SteinarN View Post
From Aviation Week
The article says the THS is slow to react to manual trim inputs from the thumb switches when simulating a trim runaway.
One wonders what the FDR would record while the pilots were mashing the thumb switches but only getting a "slow response". Short pulses, perhaps?
(I know, pure speculation on my part )


fizz57 is offline  
Old 27th Jun 2019, 11:53
  #737 (permalink)  
 
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Originally Posted by Maninthebar View Post
APPEARS to be contradicted by post 730

?
Waiting for the detail on this one. Does not jive with the circuit diagrams I've looked at nor with the previously reported behavior. Another undocumented feature?
yoko1 is offline  
Old 27th Jun 2019, 12:13
  #738 (permalink)  
 
Join Date: Apr 2018
Location: Sudbury, Suffolk
Posts: 74
Originally Posted by yoko1 View Post
Waiting for the detail on this one. Does not jive with the circuit diagrams I've looked at nor with the previously reported behavior. Another undocumented feature?
Maybe the documentation thus far disclosed is 'incomplete'.

That could be described as consistent with other material
Maninthebar is offline  
Old 27th Jun 2019, 12:29
  #739 (permalink)  
 
Join Date: Apr 2019
Location: EDSP
Posts: 68
Doesn't make me wonder. MCAS wins if the the FCC fails to compute the Main Trim Interlock. Works as designed
BDAttitude is offline  
Old 27th Jun 2019, 13:26
  #740 (permalink)  
 
Join Date: Jul 2002
Location: Ireland
Posts: 472
Originally Posted by SteinarN View Post

It is not clear if this problem can be fixed by a software update or if it requires time consuming hardware changes.
Presumably before even thinking about a hardware solution, software engineers will look at a ‘load shedding’ solution which gives priority to trim instructions if the processing is getting close to ‘maxing’ out. This of course will depend on not creating conflict with another simultaneous safety critical instruction.
Speed of Sound is offline  

Thread Tools
Search this Thread

Contact Us Archive Advertising Cookie Policy Privacy Statement Terms of Service

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