sgrow787 wrote:LOL, but sadly true to some extend. Well, there did a lot of others engineering, but there should not have do that one.In fact it looks like the only engineering Boeing did was to reverse engineer the certification process starting with how do we get a MAX certified under a 737 type certificate.
sgrow787 wrote:The raw processor capability issue is still a speculation a this time, there are so many way to overload a processor and there no real detail available. Fact is that Boeing say there expect to fix this by software (no hardware). Time will tell if it's possible or not.Chemist wrote:It's not unstable and MCAS is not a stability system. Cut the ridiculous hyperbole.
MCAS my ass. It's a stall prevention system given an alternative innocent sounding name so they could assign it a lower safety classification, so the FAA wouldn't ask questions.
In fact I'm going to go ahead and say it. Because everyone I've listened to in the aerospace industry agrees it's ludicrous for a one-sensor design to have ended up in the Max.
The recent FCC processor "data flow" issue may have been the real reason Boeing went forward with a Max with a one-sensor MCAS system. Everything else that happened follows logically from there.
- the lowering of the safety classification
- the deletion of MCAS information from pilots' FCOM
- the (intentional) failure to notify the FAA of the increased MCAS authority
I'm thinking the G + AOA worked because both sensors are onside. But two AOAs means the offside AOA may have to come from the offside FCC, and that would be through something like a SPI bus or other FCC-to-FCC communication, which would be more resource intensive.
You could call a babysitter an MCASer. All they do is maneuver the baby's sleeping position so they don't cry all night.
I don't think that the raw processor capability can be the reason Boeing went forward with a Max with a one-sensor MCAS system. The same type rating and same training was already critical goals when the project was started for evaluation, long long before there have identified the non-compliance while doing a test flight and consequently modified the MCAS to use a single sensor.
Each FCCs are already exchanging data together as shows the two figures in the middle of this blog: https://www.satcom.guru/2018/11/737-fcc ... mmand.html The same article say:
"While engaged, even single channel, the FCC uses inputs from both ADIRUs to avoid a potential issue if one ADIRU produces false data." The resources to exchange the extra AoA value, if not already done, should be just one byte or two in each directions. What worry me in the schematic is that the FCC, contrary to the SMYD, don't seem to have each independent input of the two ADIRU. It look like there need to pass trough the other side FCC to get the other side ADIRU data. I see this fragile principle as more likely a source of issue. For example, there could need the SDP-185 processor running to copy the ADIRU values from the ADIRU link input buffer to the other FCC link output buffer. If that processor fail, the other FCC no longer get the updated ADIRU values of that side, including the AoA value.