787 and lightning strikes

[EEngr]

Originally Posted by tdracer

Hence if they'd used aluminum they would have needed so much more to get the same conductivity that I doubt it would have saved any weight as copper is much more conductive (i.e. lower resistance) than aluminum. I believe titanium is even worse than aluminum.

Aluminum isn't too much worse than copper as far as conductivity goes. Copper has about 2/3 the resistivity of aluminum (the inverse of conductivity). And it is frequently used for larger electrical conductors due to weight advantages offsetting the larger conductor size needed (just not in home branch circuits). An aluminum aircraft skin will do just fine to attenuate lightning strikes. Titanium, on the other hand, is a pretty poor conductor (about 25x the resistivity of copper). What it will do is withstand higher temperatures. But the maximum temperature tolerable when dissipating a lightning strike is limited by the composite structure the mesh is embedded in.

[EEngr]

Originally Posted by tdracer

The problem is, those smaller spikes can mimic a the wave form of a valid digital electrical input - and the LRU can't tell the difference. The fix was to change the software so it could differentiate between actual digital inputs and the lighting induced inputs.

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.

[tdracer]

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.

[Watson1963]

The NTSB report referred to in Conso's first post from the WSJ is here:
https://dms.ntsb.gov/pubdms/search/hitlist.cfm?docketID=61058&CFID=1912245&CFTOKEN=e4a5dc5da8bc 3d4a-57D34E20-C4D7-2F93-2662B97B7EFD9C92

Summary of the incident: https://app.ntsb.gov/pdfgenerator/ReportGeneratorFile.ashx?EventID=20141011X20926&AKey=1&RType =HTML&IType=IA

[infrequentflyer789]

Originally Posted by tdracer

I didn't go into details since I figured most of the people reading it would just be bored

Most people probably were, still leaves some of us that weren't :-)

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.

787, as with several other recent types, is AFDX / ARINC 664 - basically full duplex ethernet with added determinism. As you say, the error checking on that should make it pretty much impossible for spurious transients to generate "valid" signals. There are, however, a lot of off-the-shelf ARINC 429 LRUs around, which will require an adaptor and a (probably short) ARINC 429 path - I don't know how many of those the 787 uses but I would be mildly surprised if it was none. Still, my gut feeling says that that is very unlikely to be lightning affected. A lightning-induced transient overload of AFDX (not electrically, but too much false data) breaking the determinism guarantees would be more interesting (to some of us) - that being the main worry going to an ethernet-type bus for safety critical stuff - but the actual cause turns out to be much more, umm, boring.

According to the NTSB reports, the lightning transient caused a spark-gap device (crude form of surge protector - somewhat renowned for generating power supply problems in downstream devices...) in the window-heat system to fire, and that (possibly in combination with the lightning) caused a transient on the screen unit power supply large enough for it to shut itself down (x3 displays). So, boring in that it's power supply, mildly interesting in that a MIL-SPEC screen would have been unaffected.

The software fix is a watchdog so that if it happens again, software will effectively power-cycle the display unit which should restore function. Mildly interesting that there was no software reset procedure, and no documented wetware procedure either (I hope there are _both_ now) - suggests that this was a "can't happen" that did happen, and next time we'll know how to handle it.