787 and lightning strikes
 

from WSJLightning Hazards Prompt Boeing to Fix 787 Jets

Manufacturer aims to eliminate chances of cockpit displays failing due to lightning events

https://www.wsj.com/articles/lightni...s&page=1&pos=2

"Boeing Co. BA -0.02% is enhancing software on current and future 787 jetliners to prevent electrical spikes generated by lightning storms from potentially disabling cockpit instruments.

Oh Dear
We had a few lightning strikes on the Dornier 328 TurboProp , and one took out 3 screens:
This was old TV style CatodeRay tube , not flat screens.

I had some fantastic St Elmoes Fire the other day over some buildup and was sure I was going to get hit. Turned out it was Calima dust that caused the St Elmo in cloud.
Anyone have any screens lost in lightning strike?

I wonder exactly what sort of software enhancement they are installing to mitigate a problem that interferes with systems at a hardware level. The solution in the United case appears to have been rebooting the affected systems. So it appears that there was no (evident) permanent hardware damage. But since susceptibility to electrical transients usually involves stopping a system from running it's software, the only fix I can see them implementing is a better watchdog system. Essentially, a routine that once stopped (by a software crash, for example) forces a restart or reboot by a hardware timer. The displays will still go down. But barring any hardware damage by the lightning, they will come back up.

This is just my guess. But if anyone close to the systems knows, It would be interesting to hear.

Engr - no first hand knowledge here, but s/w can indeed protect a system from a lightning transient, depending on the nature of the lightning transient. The example I saw was for something called "multiple burst" - as it was explained to me lightning strikes are often made up a very rapid series of smaller electrical pulses as the strike finds it's way to the big strike (this would probably make more sense if I could draw it for you, but think of a series of small sparks connecting into one massive spark). 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.

In a way, it's ironic - as an industry we've spent decades convincing everyone that lightning wasn't a big threat - we design for it. Except that isn't entirely true - we can't always protect from the most severe lightning effects. For example, we protect the engine control from the electrical transient, but if the lightning attaches to the inlet the shock wave into the inlet can cause the engine to surge and flameout (yes, it's happened). There was an event roughly fifteen years ago (memory says it was a 767, but don't hold me to that) where the lightning attached to the aircraft nose - the resultant electrical field around the flight deck incapacitated one pilot (the other pilot was 'affected' but fortunately was still able function). The bottom line is we can design for the lightning effects, but we can't completely protect for the worst case strike. We still need flight crews to do their best to avoid it...
BTW, shortly before I retired, I was on a 747-8 flight test when we took a major lightning strike - I was in the flight deck at the time and it was quite a shock (emotionally, not physically). No adverse affects to the aircraft systems, but it did significant airframe damage. But what I really recall is the flight crew's reaction to ATC - basically ATC had put us into a spiraling decent right in the middle of a cell until we finally got hit - and the flight crew didn't appreciate it...

Three of the five could potentially be a GPU/CCR problem, which would also imply a software fix.

IN the mid 1960's- on a 707 flight from frankfurt toVancouver BC, as we were near/less than 10K feet approaching vancouver we took a lightning hit_ It was like being in a large tin can with someone hitting it once with a large hammer. it was LOUD and startling- I was near the tail and had the impression that that was what/where we were hit. After a minute or so- capt made an announcement that we had been hit by lightning- no problem. I recall a few cabin lights may have blinked- but no other issues apparent.

I remember reading about lightning protection on the 787...IIRC there is a copper mesh embedded in carbon fiber

Disclaimer - I'm not a lightning/EMI expert, but I did have to deal with it for my engine systems - I know just enough to be dangerous :p
Yes, there is a copper mesh imbedded in the carbon fiber on the 787. While carbon has reasonable electrical conductivity, it's still considerably worse than aluminum (order of magnitude). That higher resistance means that the electrical current/voltages induced by a lightning strike are much higher than for aluminum structure. The copper mesh dramatically improves the conductivity of the carbon, but it's still a bit worse than aluminum. As a result, the lightning transient requirements for the 787 systems are somewhat higher than for aircraft with aluminum primary structure (I don't recall specifics, but IIRC the voltage requirements were about twice as high for carbon fiber aircraft).

Clear? Pop quiz in the morning :}

Loud and clear Tdracer!:)

There certainly is on the A350XWB

Right on tdracer. in the 1980s, Boeing did a LOT of work on lightning strike on carbon composites - for example A-6 rewing and B2. A major problem was to handle how to handle pass-throughs in wing tanks as in front and rear spars- while being sure there would be NO sparks. So methods were developed to be able to copper plate inner and outer carbon composite surfaces and provide connectivity to the internal ' mesh' or its equivalent. at about the same time the aborning 777 was considering using some fuel tankage in the empennage section-( horiz stab ) Some of the ensuing discussions within the constraints of military v commercial issues were quite interesting to say the least.

For but one example - the commercial boys wanted to use aluminum mesh for weight savings over copper. Thenit was pointed out that aluminum v carbon and a bit of moisture made a almost useable battery :)

I remember reading about lightning protection on the 787...IIRC there is a copper mesh embedded in carbon fiber

I thought it was titanium due to the weight of the copper? I know they could use aluminum, but would have to thicken the composite for galvanic protection..

And a little bit more as to lightning vs EMP

Go to page 69-70

http://www.northropgrumman.com/Capab...Innovation.pdf

benthere

Thanks CONSO

Again, no first hand knowledge, but I was 'told' the 787 used copper mesh - never even heard of them wanting to use titanium. It's all about the electrical conductivity - adding copper to the composite matrix makes it more conductive - which due to electrical laws that I'd need to refer you to a text book to explain, the induced current due to an external current is a function of the electrical resistance - the lower the resistance, the lower the induced current. 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.

FWIW The most common form of titanium alloys used in aerospace is 6AL4V - eg 6 aluminum 4 vanadium . .. with the remainder alloy being titanium . .

https://www.azom.com/article.aspx?ArticleID=1298Specific electrical resistance
(µOhm-cm)
55
72
2.7
4.3
9.5
1724





note the 1724 for copper is a misprint s/b 1.724 so look at the ti and aluminum ratios by comparison

In the ' early ' days of composites for structural use on airplanes ( other than feathers- flaperons, etc ) there was significant discussion as to conductivity of carbon " dust " from machining and cutting of composite structure. A lot of trimming and cutting was done with abrasive ( brazed industrial diamonds on high speed cutters ) really a grinding process. Abrasive high pressure water jets were /are also used.

Anyhow to settle the question- a simple test method was used . A half/pound or so of ' carbon composite grindings' was put into a small plastic box over 90 percent full. As I recall, the box was an inch or so deep and about and size of a binder. On opposite sides an simple wire probe was inserted and sealed. resistance between the two probes was measured as the box was shaken - no reading indicating no conductivity. My very ancient recollection seems to be that low to moderate voltages ( dc ? ) were also applied. Results indicated zip current.. IMO not to surprising when one considers the fact that tdo establish a conductive path with carbon ' strings' covered with some epoxy- several thousand would have to line up end to end in close contact to pass any current. So much for composite ' dust ' conductivity.

Maxwell's equations of electrodynamics...well I can still do some of it :8

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:eek:). 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.

I didn't go into details since I figured most of the people reading it would just be bored :hmm:
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

Most people probably were, still leaves some of us that weren't :-)
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.