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

[MurphyWasRight]

Originally Posted by BDAttitude

I'm not sure
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.

True, except MCAS is enabled when AP is off, perhaps another overlooked failure mode/path?

[BDAttitude]

Originally Posted by MurphyWasRight

True, except MCAS is enabled when AP is off, perhaps another overlooked failure mode/path?

Just wanted to highlight that pre MCAS concurrent activation of manual and AP channel was software interlocked as well.

Another educated guess would be, that not AP has priority over manual, but one direction has priority over the other because it's likely to be implemented by a reversion switch both channels are connected to. So from this scenario ANU would be the "default" direction and AND the "reversed" direction activated by either manual or AP channel being switched AND.

[bill fly]

Originally Posted by fdr

This is an unfortunate development in the process, but two positives exist, 1; the new issue has been discovered before RTS, and 2; it has been acknowledged.
.

Yes indeed. Let us hope that an honest culture is taking hold - at B and at the FAA - then maybe something good will come from this catastrophe for the future

[OldnGrounded]

Originally Posted by BDAttitude

Doesn't make me wonder. MCAS wins if the the FCC fails to compute the Main Trim Interlock. Works as designed

Very disturbingly, it looks like that might well be the case. I hope it is not.

[robocoder]

Embedded real-time software design carefully budgets the available CPU for the worst case. It would be deeply disturbing if the problem came from that direction, so I'm going to go out on a limb and guess that that's not it. Those programs tend to be extremely static in the sense that tasks/data do not arrive ramdomly or with variable rates, but everything is done on preallocated resources. All the fancy features of scheduling are dispensed with in favor of extreme predictability.

Frankly, if this is the case, as a software engineer, I would be appalled. This is Real-time Systems 1.01.

​​​

[tdracer]

Originally Posted by Speed of Sound

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.

Agreed - this was SOP when doing FADEC software changes to the 1980's era engine controls where memory and throughput were at a premium, and making hardware changes to thousands of in-service units was simply not an option. There was often more focus on what they could get rid of to make room then there was on the planned changes.

BTW, while comparisons have been made to the 1201 and 1202 error codes during the Apollo 11 landing, the reason for that was Buzz left the rendezvous radar on during the landing - something that wasn't per the checklist and hence hadn't been checked. On some of the older FADECs, there was logic to drop 'unneeded' processes (usually condition monitoring stuff) if the processor became overloaded.

[jmelson]

Originally Posted by yoko1

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.

OK, not Boeing (although it is, now) and not commercial, but military flight control systems, but I did see how they did this at McDonnell Douglas some years ago. They had a big Honeywell computer that was interfaced to the FCC, and had some controls and instrument panel displays provided by another computer, like a Unix workstation (Sun, SGI or so). The Honeywell simulated the aircraft flight dynamics and all the sensor inputs (air data, gyros, feedback from flight control positions sensors, etc.) So, it was to mimic everything the FCC would sense while flying the aircraft. It also recorded all the inputs and outputs so they could be compared with what the FCC was supposed to do.

I'm guessing this is the sort of system Boeing is using to test the 737 Max FCC, and they've got the necessary flight controls rigged to it so the test pilots are doing the normal trim settings, etc. But, it is probably on a desktop with most of the indicators and controls just appearing on a couple screens.

And, from the VAGUE descriptions I've seen so far, it sounds like it could be a problem with priority of various tasks on the FCC. It seems these days an FCC really should NOT be running out of CPU cycles.

Jon

[Mike Flynn]

Originally Posted by Speed of Sound

FAA approval will come first because they are working very closely with Boeing and are the ‘home’ regulator. EASA will lift the grounding after a respectable period of time, mainly for political reasons. The FAA realises how important the MAX is to Boeing and will not let anything slide which may cause the huge embarrassment of the FAA lifting the grounding while other regulators say no, hence the latest ‘hardware issues’ delay. Boeing are smart enough to know that trying to bounce the FAA into an early decision will only serve to increase caution and suspicion in other regulators.

The MAX will only fly again when all parties, including Boeing, are convinced that it is completely safe to do so.

As the saying goes you can put lipstick on a pig but it is still a pig.

The 737 Max is a fifty year old design with a few lights bells and whistles.

All we are seeing with Boeing and the FAA is a method of selling this death trap to the worlds airlines.

They laughed at Airbus and their plastic and electric aeroplanes but sadly now discover they have missed the bus. (pun intended)

[yoko1]

Still waiting for more details, but I found a trim electrical schematic with a slightly different layout, but may add some clarity to the schematic BDAttitude posted above at post #735, in particular the function of the Main Electric Trim Interlock. I'm not claiming to be an expert in reading wiring diagrams, but here's what I see. Flight deck inputs come from the left. The right side represents the trim motor and associated electronic controls. All the FCC inputs (MCAS, STS, Mach Trim, MCAS) appear to come in (off another schematic) into the trim motor box from the right. Various control and limit relays are in the middle.
.





.
If I am reading this correctly the "Main Trim Arm" relay is activated by one of the pilot yoke switches which, among other things, sends a signal to and opens the interlock relay contained in the trim motor box on the right side:
.


.

The interlock relay appears to be a basic relay and not a function of any IC processors. This relay appears to be spring-loaded closed allowing automated trim inputs by default (which makes sense because the STS and Mach Trim systems need to be active full time). When a Main Electric Trim switch is actuated, the interlock opens, and this "open" signal goes off the right hand side of the page presumably into the FCC logic which should stop any automated inputs. There is no way to tell from this diagram how the FCC handles that input.

If for some reason the FCC logic does not process the "stop" signal, then I presume that both the Main Electric Trim and the FCC could attempt to send trim signals to the box marked "Controller" located just above the box labeled "Brushless DC Motor." We can't really tell from this schematic if that could happen, or what the Controller would do if it received conflicting signals.

So sorry, no definitive answer, but perhaps narrows the focus some.

All of this should be qualified by the fact that this so far appears to be an issue with the updated FCC software/firmware. Not sure if it could be extended to the original software.

[armchairpilot94116]

https://www.sfgate.com/business/arti...o-14054004.php

Apologies if it has been posted before, but the FAA finds a new problem with the microprocessor that can induce a dive. Not related to the two crashes they say but....are we sure?

Nevermind, posted already

[edmundronald]

Originally Posted by Mike Flynn

As the saying goes you can put lipstick on a pig but it is still a pig.

The 737 Max is a fifty year old design with a few lights bells and whistles.

All we are seeing with Boeing and the FAA is a method of selling this death trap to the worlds airlines.

They laughed at Airbus and their plastic and electric aeroplanes but sadly now discover they have missed the bus. (pun intended)

The 737 is a very safe 50 year old design. The problem lies with the politicians de-fanging the FAA and the defanged agency and Boeing agreeing on a "nudge nudge wink wink" way of certifying its successor without due diligence. The FAA should have the budget to certify properly, as it used to.

If Boeing had known they faced a full check by an independent agency they would have made a good new plane rather than sneak through a pig in a skirt with lipstick.
Edmund

[krismiler]

Basically, the accidents have opened a can of worms with the B737, the deeper they go the more they find wrong. Issues which have sat quietly under the radar because they hadn't yet caused problems are coming out into the open. The aircraft is going to be taken apart to the last rivet and evaluated against modern safety standards, 50 year old bicycle chain and cable technology won't cut it in the era of fly by wire.

Every aspect will be looked into from technical to the certification process and no one is going to put his head on the block by signing off unless numerous experts and committees give it the OK.

Universities will be using Boeing's response to the accidents as a case study in future years.

[billybone]

Originally Posted by fizz57

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 )

Seems to me that the ' slow" reaction may be due to either a G limit on rate change on the stabilizer or a speed input limiting the rate of change.
Based on the assumption thst MCAS only needed at cruise altitude and speed parameters. But when they later changed the max nose down to 2.5 degrees, they did NOT follow thru with the effects on all other parameters.

Ethopia was at high speed- low AGL and wound up with the worst of both worlds..

[MathFox]

Originally Posted by krismiler

Basically, the accidents have opened a can of worms with the B737, the deeper they go the more they find wrong. Issues which have sat quietly under the radar because they hadn't yet caused problems are coming out into the open. The aircraft is going to be taken apart to the last rivet and evaluated against modern safety standards, 50 year old bicycle chain and cable technology won't cut it in the era of fly by wire.

Every aspect will be looked into from technical to the certification process and no one is going to put his head on the block by signing off unless numerous experts and committees give it the OK.

Universities will be using Boeing's response to the accidents as a case study in future years.

I see the MAX as a hurried response to the Airbus Neo. Boeing skipped some sanity checks in the MAX "adaptations"; the FAA blessed the design with less oversight than appropriate.
MCAS was the culprit for two fatal crashes... it could have been another system if the dice rolled another way, Anyway both the FAA and Boeing have some trust to regain.

[Loose rivets]

PiggyBack #728

more than a bug fix is neededWe 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.

A prime example is the jackscrew power, with a lot of logic and hardware upstream. Posters have mentioned, motors, but should it not be motor, singular? One brushless motor with a control and clutches. Okay, so this is probably the finest build quality there is, but there is just one motor and associated systems. This leads me to believe we are absolutely reliant on the steel cable backup - and its ability to be cranked in any scenario.

Like many relays, that INTERLOCK unit has a solid state device crowbaring the back EMF. It's one tiny solid state surface, which if shorted would leave the interlock signal continuous. The point is, the use of good old clonking relays can be rendered worthless with little more than a speck of semiconductor material. One example amidst hundreds, just on the area we're focussing on.


Just as an aside, I recall some 30 - 40 years ago a guy from the British simulator maker saying 'There is no operating system. There's no time.' A different world back then, but I know what he means. HAL mediating every step of the logic can be a terrible burden. Sometimes, knowing what's going to happen when you press a switch is worth its weight in gold.

[billybone]

From SEATTLE TIMES

https://www.seattletimes.com/busines...oeing-737-max/

=start

By

DAVID KOENIGThe Associated Press

=start

Boeing says it expects to finish work on updated flight-control software for the 737 Max in September, a sign that the troubled jet likely won’t be flying until late this year.





The latest delay in fixing the Max came a day after the disclosure that government test pilots found a new technology flaw in the plane during a test on a flight simulator.





The plane has been grounded since mid-March after two crashes that killed 346 people. Preliminary accident reports pointed to software that erroneously pointed the planes’ noses down and overpowered pilots’ efforts to regain control...

Goes on .

IMHO - MAX not RTF until Novemeber at earliest- and maybe NG may need ' updates "

[Smythe]

Has Transport Canada found something else, the wording is a bit vague?

Certification experts with Transport Canada know of an “unacceptable failure” in the updated flight control computer on the Boeing 737 MAX 8, and they’re looking into how this will affect the ministry’s “ongoing validation efforts,” a statement said Thursday.

The statement came one day after reports emerged that the Federal Aviation Administration (FAA) had found a new risk in the grounded planes that has to be addressed before they can fly again.

What happened to the trim wheel issue? (required strength to move, MAX and NG)

[LandIT]

Originally Posted by WHBM

American Airlines CEO Douglas Parker says the Max grounding is now down to politics

https://www.cnbc.com/2019/06/23/amer...s-737-max.html

Extraordinary ...

At least finally it looks like the FAA are doing their job instead of rubber stamping and it looks like the MAX won't be flying this Summer. I wonder what Mr Parker's next statement or implied criticism will be.

[FlightCosting]

Originally Posted by RobertP

JSP 553 is not the only definitive statement regarding aeronautical products and reflects the USA Military and CFR14 FAR interpretations. This is a good definition, however Nations signatory to the ICAO Convention and in particular Annex 8 have jurisdiction concerning the interpretation and this is reflected in the National Regulatory Organisational standards. Whilst acceptance of Aeronautical Product certification standards between many but not all nations is to date convention this MAX 8 situation indicates that this may not hold true for the future. EASA have made it quite clear that automatic acceptance of FAA MAX 8 changes will not happen. This may have implications wrt the ICAO Convention not least as it also may affect Annex 13 and its interpretation.

from my experience in obtaining aircraft certification there is a big difference between FAA and EASA attitudes. In the US Boeing and politicians hold much greater influence over the certification process ( Boeing self certification) than in Europe where the authorities always take a much harder stance in front of the manufacturer.

[BDAttitude]

Originally Posted by yoko1

If I am reading this correctly the "Main Trim Arm" relay is activated by one of the pilot yoke switches which, among other things, sends a signal to and opens the interlock relay contained in the trim motor box on the right side:
.


.

The interlock relay appears to be a basic relay and not a function of any IC processors. This relay appears to be spring-loaded closed allowing automated trim inputs by default (which makes sense because the STS and Mach Trim systems need to be active full time). When a Main Electric Trim switch is actuated, the interlock opens, and this "open" signal goes off the right hand side of the page presumably into the FCC logic which should stop any automated inputs. There is no way to tell from this diagram how the FCC handles that input.

I think not correct.
INTLK coming from the right side is a sensing channel activated upon switching K2 by applying 14V+ to A/P TRIM SPEED HIGH.

You can probably clarify this by posting wiring diagram 22-13-11.

Originally Posted by yoko1

Not sure if it could be extended to the original software

Indeed ... it could explain some weird things however.

On April 5th, I posted below Björn Leehams analysis of the preliminary report a question that still haunts me today:
What electrical signal does the DFDR actually record as manual trim input at which rate. By which device is it digitized? At which rate? And then transferred by which bus at which rate to the DFDR?
Let's not hope there was a trapping FCC in the line of communication. Blip blip.