787 and lightning strikes
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.
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.
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.
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.
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
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
Last edited by Watson1963; 2nd May 2018 at 20:24.
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes
on
0 Posts
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.
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.