"A change in software architecture" is not a 100% rewrite. Shall we say 70%?
Without seeing the code or documentation, my educated guess is 10-20% code addition/modification worst case.
Again, in many cases architecture changes are made to preserve the core logic, and this is almost certainly one of those cases.
From the ST link:
One standard way to fix such a problem is to have the second independent microprocessor inside the same flight-control computer check the output of the first. If the second processor output disagrees with that of the first processor for some specific function, then that function is shut down.
“Now it takes two processors to fail to get the bad result,” the person familiar with the tests said. “You are no longer in the realm of a single point failure.”
This change means the flight-control system will take input from both of the airplane’s flight computers and compare their outputs. This goes beyond what Boeing had previously decided to do, which is to adjust the MCAS software so that it took input from two angle of attack sensors instead of one.
The problem with that earlier approach is that if something serious goes wrong with the single flight computer receiving this input — whether it’s the bit flipping issue, or a memory corruption or a chip failure of any kind — then the computer output to the flight controls could be wrong even if both angle of attack sensors are working correctly.
But with the dual channel configuration, each of the computers will take input from a whole independent set of sensors (air speed, angle of attack, altitude, and so on) and compare outputs. If the outputs disagree, indicating a computer fault, no action that could produce a bad outcome will be initiated.
In other words, the new system will detect not only any disagreement between the sensors but also check for any processing error in interpreting the information from the sensors.
Basically you are adding the comparisons in the data i/o paths, and the code to shut things down when there are disagreements.
I can't say for sure, but given this is flight control software, it is likely most of the key modules will have shutdown paths already.
There may be some things that need to be hardened to deal with the shut down scenarios, but again, you aren't rewriting core logic such as autopilot, CATIII landing, etc.
You will be doing a lot of testing, but given we are seeing all these controlled leaks showing up, the code must be written, the core tests must be passing and now they're doing hardening and cleaning up the edge conditions.
I doubt we'd be getting such a deep dive on the problem and the fix, and even an estimated completion date, if they were in the early days of brainstorming the solution.
Just as a point of order, I'm fully on your page of FAA not going alone. Those words ("What you or anyone else thinks") were not my words; they were from the poster I reacted to. I merely quoted his/her words, hence my italics and quotation marks.
Sorry for any misquoting. I did write I could not figure out where the narrative was coming from. I'm glad I could quote a reference saying FAA is already coordinating with other agencies and is hoping for a coordinated release.
Last edited by Revelation
on Thu Aug 01, 2019 9:59 pm, edited 1 time in total.