Originally Posted by
EEngr
That sounds like a data integrity problem. And it should have been considered in any FMEA long before the lightning struck. Lots of things can produce waveforms resembling an input, but with invalid data. Could be a sending LRU going brain-dead, some idiot who forgot to put a phone in airplane mode or other electrical interference including lightning. All communication buses should have checksums or parity bits. And a failure of one system (or injected bad signals) should not result in the failure of others. Having to land and reboot (or even cycle a breaker) should be considered to be a failure of the second system, the displays in this case.
I didn't go into details since I figured most of the people reading it would just be bored
The case in question was a major hardware change (parts obsolescence) to a FADEC - back around year 2000. When the original FADEC was certified in the 1980s, the test for multiple burst was done using something called "chattering relay" (which is apparently pretty much what it sounds like) to create the waveform. By the time the new FADEC was tested in 2000, the technology had improved enough that they could create the wave form directly and no longer used the chattering relay technique. When they did the multiple burst test, the new FADEC failed around 150 volts (the requirement being 200 volts) - when they repeated the test using the chattering relay, it passed at the full 200 volts. So they went back and tested the original FADEC - same result - passed chattering relay at the full 200 volt threat but failed at about 150 volts using the new technique. The engine company tried to sell it as 'just as good' as the original, but the FAA said no-way - fix it...
However I think I did miss-speak in the original post. The digital interface the FADEC used was low speed ARINC 429 - which uses a simple parity check that is less than robust and could conceivably have been fooled by the transient, but now that I think about it I believe the interface in question was analog, not digital. However I stand by the rest - the problem was the interface accepted the lightning induced transient as a valid input which affected the control of the engine. The fix was to upgrade the input processing logic such that it could detect and disregard the lighting induced transient.
All of which may not be particularly relevant to the 787 issue (the digital interfaces on the 787 are quite robust - using things like CRC to detect invalid inputs) - I just wanted to point out that software can indeed correct for lighting induced upsets.