Originally Posted by
safetypee
VicMel, thanks,
With that info and previous analysis, how might the correction routine ‘reset’, if it did, between flights?
How or why would this corruption occur on the particular accident flights apparently at random, or reoccur after the first Lion incident; conversely why were there not more instances of inaccurate AoA.
Before I address your specific points, I’ve had a re-think on some aspects:-
1) I had noticed on ET302’s FDR that the pilot, just after take-off, seemed to stop pulling the Control Column back a few seconds before the Stick Shaker started! I had suggested that perhaps it was just a latency due to ARINC 429 different data rates; however, I cannot find the same effect on the 2 Lion Air FDRs, so I now think I was wrong. Instead, I think it is plausible that the pilot realised that the nose was coming up too quickly and so backed off. When the Stick Shaker kicked in he could have thought it was due to his over-enthusiastic take-off (perhaps because of shortish runway and heavy load) and that a real stall was threatened. The idea that it was an ‘AoA Disagree’ would not occur to him, it might have taken several vital seconds later, after working to resolve a problem that did not exist, before the crew realised that something other than the pilot’s action was the problem. We know Boeing introduced MCAS because the new MAX engines, being more powerful and lower slung, together with the effect of a larger cowling, would have a larger coupling moment. So without MCAS cutting in, a significantly larger Pitch Rate than on a 737NG is fairly easy to achieve.
2) The larger Pitch Rate might be significant because the AoA Pitch Rate correction software would have had to be modified because the big new engine would have had an effect on Wing AoA. The original software in the ADIRU would have been written several decades ago and now someone who is unfamiliar with it is going to patch that software, they are told the software is not safety critical, and it is a rush job! Recipe for a huge hole in the cheese!
3) The software in the ADIRU has to deal differently with L AoA than with R AoA. There is a sign difference as a positive increase in real world AoA will result in a clockwise motion of the L AoA sensor shaft, but anticlockwise on the R one. Fairly obviously, the Sideslip correction has to be different for L & R AoA sensors.
4) Considering how long ago it was written, I suspect that the original software used fixed point calculations, in which case the original scaling for Pitch Rate may well not be sufficient to cope with the new larger value and so an overflow will occur. I doubt that the person who wrote the patch would be aware of such subtleties.
5) Overflows in software are a bit unpredictable, it all depends what action the hardware and software take when one is detected. The result could be a smallish offset, say 22 deg on AoA, with any lower level noise retained. It could be huge, say 1000 deg, in which case AoA could be any value from 0 to 360, and as a flat line. Any sudden large value could take several seconds to be smoothed out.
So, to go back to your original queries,:-
How might the routines reset? A restart of the computers would do that, just like with Windows.
How would the corruption occur on particular flights? Any flight with a high Pitch Rate could be a trigger. Or anything that has been patched for MAX could be a problem, patched software is notorious as a source of failure. Far more likely than a failure of a piece of hardware that has proved in-service to be very reliable.
Why not more instances? Good question, perhaps in the developed world we have fewer shortish runways and “high and hot conditions”, which according to Boeing, MAX is not suited to.
Vic