PPRuNe Forums - View Single Post - 787 and lightning strikes
View Single Post
Old 3rd May 2018, 10:55
  #25 (permalink)  
infrequentflyer789
 
Join Date: Jan 2008
Location: uk
Posts: 857
Likes: 0
Received 0 Likes on 0 Posts
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.
infrequentflyer789 is offline