Originally Posted by
safetypee
Whilst all of you Tech ‘bit’ people provide valuable information and possible scenarios, could you please consider why ‘failures’ appear to be very rare and so far only relate to two aircraft / three vanes.
How something fails does not necessarily explain why (when) it failed.
Random, probabilistic, bit count, world clock ?
OK, having considered why the MCAC failures only appear on some flights, possible candidates (the holes in the cheese) that could trigger a software fault in the processing of an AoA correction table (bearing in mind that the ADIRU software was developed only to a “non -safety critical standard”) are:-
1) pin fault: How does an ADIRU recognise it is L or R? Similar sytems I’ve worked on in the past had a fixed pin in the harness connector of one box to designate it as L. If on the problem 737 Max flights the pin became a bad connection, or was bent/missing, the ADIRUs would think they are both L (or both R).
2) IAS fault: As pointed out by patplan in #2799 there was an “IAS & ALT Disagree shown after take off”. If the correction table is indexed by IAS (or has some dependency on it), the software could have used bad IAS data as an index and read garbage data for the correction items.
3) interrupt corruption: A problem that has bitten me hard on a few occasions over the years is with the software that handles interrupts. Typically, interrupt software has to save data held in registers, perform its actions, and then restore the registers to their entry values. A latent problem can exist (just waiting for the right holes to line up) that a piece of software uses another register that the spec writer of the interrupt routine was unaware was being used. Or, more likely, a software update was made (e.g. MCAS date preparation update) that used another register. So after 100s or 1000s of flight hours the holes line up, the interrupt pings off in the middle of the new software, something (could be a data value, a status flag, a jump address or ….) is corrupted. The consequential behaviour could be any of many surprises!
4) processor overload:
Originally Posted by
patplan
I have a suspicion that in Boeing 737 Max 8 [B38M] perhaps the LEFT/CAPT ADIRU is constantly being overwhelmed by new routines [i.e. MCAS/AOA related programmings] which may from time to time corrupt the system.
I agree, as the (old tech) processors become more and more loaded, there will reach a point where, given the right circumstance of several things needing to be computed in one cycle, a software routine will not complete. Just as an example, the start up stage will be quiet busy. I would expect the ADIRU to determine its L or R status (perhaps read a pin) and store the result for other software routines to use. So if this action does not complete the ADIRU L or R status will stay at the default value; ADIRUs would both stay as L (or R).
5) flap position: From the preliminary report (Fig. 5 on accident flight & Fig. 7 on previous flight) there is a difference in when the flap position changes. Fig 5 shows a change well after rotation, Fig 7 shows a change at the point of rotation. Could this difference have affected how MCAS subsequently behaved?