PPRuNe Forums - View Single Post - MAX’s Return Delayed by FAA Reevaluation of 737 Safety Procedures
Old 27th Jun 2019, 11:33
  #731 (permalink)  
SteinarN
 
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.

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