MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Join Date: Dec 2015
Location: Cape Town, ZA
Age: 62
Posts: 424
Likes: 0
Received 0 Likes
on
0 Posts
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
https://edition.cnn.com/2019/06/26/p...law/index.html
Join Date: Jun 2008
Location: Cambridge UK
Posts: 192
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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?
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
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
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!
* I have used the word 'override' but I think 'cancel' might be better in the case of MCAS, or even postpone!
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.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jan 2013
Location: UK
Age: 63
Posts: 37
Likes: 0
Received 0 Likes
on
0 Posts
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.
Join Date: Jul 2002
Location: Ireland
Posts: 596
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Apologies if I'm misreading the jist of your question
Last edited by unworry; 27th Jun 2019 at 11:42.
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
Join Date: Jul 2002
Location: Ireland
Posts: 596
Likes: 0
Received 0 Likes
on
0 Posts
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).
Join Date: Jul 2013
Location: Norway
Age: 57
Posts: 140
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.
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.
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.
?
Join Date: Apr 2008
Location: back of beyond
Posts: 116
Likes: 0
Received 0 Likes
on
0 Posts
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.
The article says the THS is slow to react to manual trim inputs from the thumb switches when simulating a trim runaway.
(I know, pure speculation on my part
)
Join Date: May 2019
Location: Somewhere over the rainbow...
Posts: 0
Likes: 0
Received 0 Likes
on
0 Posts
That could be described as consistent with other material
Join Date: Jul 2002
Location: Ireland
Posts: 596
Likes: 0
Received 0 Likes
on
0 Posts
Join Date: May 2010
Location: Boston
Age: 73
Posts: 443
Likes: 0
Received 0 Likes
on
0 Posts
That is where an absolute override of all automatic trim inputs by pilot inputs "should" be, very simple no computer required.
It the reports are correct it appears it may not be present and the issue is fcc slowness in recognising pilot inputs and disabling auto inputs.
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes
on
0 Posts
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.
Last edited by BDAttitude; 27th Jun 2019 at 14:14.
Join Date: Apr 2019
Location: EDSP
Posts: 334
Likes: 0
Received 0 Likes
on
0 Posts
The diagram is missing detail of the electric stab trim motor block.
That is where an absolute override of all automatic trim inputs by pilot inputs "should", very simple no computer required.
It the reports are correct it appears it may not be present.and the issue is fcc slowness in recognising pilot inputs and dibling auto inputs.
That is where an absolute override of all automatic trim inputs by pilot inputs "should", very simple no computer required.
It the reports are correct it appears it may not be present.and the issue is fcc slowness in recognising pilot inputs and dibling auto inputs.
1) If it was, the Interlock in FCC would not be neccessary. So the educated guess is, that it is not.
2) Operating the trim switches in AP on leads to disengagement. Another relay to priorize manual input woud be superfuous.