Originally Posted by
wonkazoo
Can anyone please tell me why heads didn't explode with the headline last Thursday??
If someone's head is exploding, then that person doesn't really understand what was reported. Frankly, I'm a little surprised that you are bringing this up again. You quoted a post of mine a few days back which explained exactly why this is not the smoking gun that everyone wants it to be, but you have apparently chosen to ignore that response and slap this red herring back on the table.
Let's go through it again, with a little more detail. First of all, this is not a smoking gun because it is not even the same gun. The problem was discovered when the
new, yet to be flight-certified FCC software was being stress-tested in a Boeing engineering simulator. This simulator can be used to plug in different components of flight control hardware and software during both development and test phases and is part of the certification process of any new aircraft or related subsystems. The tests that were being conducted
intentionally introduced faults into the FCC in order to see how it would respond. Normally, a fault on a single FCC should attempt to hand off the process to a different processor on the same FCC, or failing that, to a different FCC (there are two on the 737). The test did not involve the MCAS subroutines of the new FCC software.
This news was reported through several outlets, but Leeham New's seems to have the best detail:
Bjorn’s Corner: New pitch trim issue forces further changes to 737 MAX software
Quoting the article:
.
The flaw is not related to MCAS but to how the revised software affects the aircraft’s processors in the Flight Control computers when these have simulated fault conditions.
During a check on how different faults (in this case a fault in one of the microprocessors in the Flight Control computer) can cause Trim Runaway conditions the FAA found the 737 MAX Flight Control computer got overwhelmed by the data flows the simulated fault caused and it delayed the actions the FAA pilot could take to stop the trim runaway.
and:
The discovery is not done in the part of the code which handles MCAS. It’s found as a wider verification the software changes haven’t produced any secondary hazards in the 737 MAX flight control system.
Software changes in a flight control system are always verified with an exhaustive FMEA analysis (Failure Mode and Effects Analysis) and it’s during such verifications the new condition was discovered.
As currently understood, the MCAS software on the accident aircraft did not input nose down trim because of a fault, but simply because it performed a task exactly how it was programmed to do so. Yes, it was ill-conceived program, but there is no indication that it created a fault condition.
All the test above tells us is that the
new software has either a coding issue (which may involve just reprogramming work) or it is demanding more than the processor can handle (which may involve a change in processors). There was extensive discussion previously in this thread by individuals with background in this kind of work who explained all the ways in which errors could have been introduced into the new software.
Also important to understand is that this type of testing was performed on the original Flight Control components (hardware/firmware/software) that were part of the originally certified aircraft. Certainly one might suggest that this testing missed something. Possible, but this is where the accident investigation process steps in.
In order to determine the cause(s) of an accident, to include an attempt to replicate all the physical and electronic evidence left behind, the accident investigators will run every suspect component through a battery of tests. Since the actual components were destroyed, it is almost certain that the investigation teams pulled similar components from the field and then used the same (or similar) Boeing engineering simulator to test these components for all manner of possible failures, including the exact tests run by the FAA as described above. Ideally, these components would have been produced in the same lots as the those in the accident aircraft. Since there hasn't been much reticence in reporting all the other existing flaws with the MCAS and related software, it doesn't seem likely that an issue that caused a fault like the one reported for the new software would be selectively concealed from the public. Another item for the "Dog that did not bark" file.
Back to the Leeham article which first quotes from a so-called 8-K public filing:
“The Federal Aviation Administration has asked The Boeing Company to address, through the software changes to the 737 MAX that the company has been developing for the past eight months, a specific condition of flight, which the planned software changes do not presently address.”
Here is what Wiki says about an 8K filing: Form 8-K is a very broad form used to notify investors in United States public companies of specified events that may be important to shareholders or the United States Securities and Exchange Commission.
The filing means FAA has found a flaw in the software Boeing has developed to fix to the MCAS problem. The find and its consequences are significant enough so Boeing’s shareholders should be informed about it. It can affect the value of Boeing on the stock market.
That last point is very important. If Boeing was aware of an issue that might further delay the re-certification of the MAX, then it must provide some kind of disclosure since it is material information that would effect the stock price. Any issues with components of the Main Electric Trim system would likely require significant rework (redesign and/or replacement of switches, wires, relays, motors, controller, etc.) and add to the already known delay. By SEC rules, this type of delay would require a similar 8-K report by Boeing. One more dog that isn't barking.
Lots and lots of dogs not barking, and there is a very good reason for it.