M

mcencula

Well Known Member
Howdy,

I was talking with a friend and fellow builder this evening about panel options when he mentioned something I had thought about, but not seriously considered. He's planning on two EFIS, but wants a backup instrument from a different vendor. I asked why he wants an additional backup...wouldn't the second EFIS be the backup? He expressed concern that a software or system bug could affect both EFIS systems simultaneously leaving him with no flight instruments.

This got me wondering...has anyone ever experienced this situation? Simultaneous failure of two identical, but independent EFIS systems due to some type of bug?

Thanks!
 
Mike, my personal opinion....

...is that the likelyhood of that happening is kinda akin to my chances of winning the lottery:)

That said, it can depend on whether or not they 'talk' to each other, like my D-100 and D-120. If they don't communicate, I'd be very happy to go into IMC with dual EFIS's even from the same vendor, with no steam backup either....then again, that's just my .02, worth what you paid for it:)

Best,
 
Pierre is correct, in that the chances that you'll get a simo bug in two independent units are pretty small, and if they talk to each other, it is more likely (and still small). But......I HAVE experienced simultaneous failures in multiple avionics boxes with the same software running in some very sophisticated aerospace vehicles. Will it happen in our GA boxes? Not sure - but the consequences of it happening at the wrong time can be catastrophic.

"Remote/Catastrophic" is something that I try to address by design. If I am going all-electronic, I am much more comfortable with an independent backup - and fortunately, a D10A or Tru Trak ADI (I am excited about the new stuff TT - can't wait to see it!) is a pretty inexpensive option....and an autopilot with the ability to fly independent of the EFIS also fills the bill, if you have one (which is why I like a separate but integrated autopilot).

Paul
 
pierre smith said:
...is that the likelyhood of that happening is kinda akin to my chances of winning the lottery:)

Best,
Click to expand...

Well, according to my e-mail inbox I win anything up to 1/2 dozen lotteries every day - amazingly without entering even one of them.
How lucky is that ? :D

You are refering to relatively simple EFIS systems with very limited functionality and (no surprise) these would (should) be about as bullet proof as you can get so on this account I completely agree with you.

However, looking at the more complex EFIS systems, those that include a lot of navigation and typically a huge amount of auxiliary functions and interfaces to many external systems, the answer is less obvious.

Complexity of software grows on average by the square of its code size (at least !) and with this, inevitably, comes the dark spectre of "bugs". I am using the term "bug" very loosly - as mostly software malfunctions in these systems are not due to bugs as such but simply a result of several things coming together that cause a condition not handled correctly by some or other routine (perhaps the programmer did not anticipate this condition).
Other "bugs" like the famous "non-initialized pointer" - every C programmers nightmare, can strike far more randomly and would not normnally freeze two identical systems at the same time.
Of course, I could write a book about all of this - but the above should suffice.

So, lets do a real world example, a silly one - but one that could very well happen:

You have two identical EFIS systems (of the "complex" type).
You are flying along and suddenly you find both systems crash or freeze. You restart the systems but after a few seconds it happens again.

What gives ? Easy - one explanation could be that the programmer uses a caching scheme to keep close waypoints in memory. He made generous provision for 1000 close waypoints and added some scheme to handle the unexpected case where there are more than this limit to handle.
As things turn out - just the area where you happen to be flying there are more than 1000 close waypoints and it turns out that the code responsible for handling this never properly managed to handle a "VOR" waypoint and gets stuck because a simple counter that needed to be incremented - did not.

OK, so now we have a perfect example of two identical systems hanging at the same time (and in this case, until you leave the critical area, you do not have any EFIS). Some systems of course will continue running - perhaps just your moving map freezes or the waypoints go away.

This now brings us perfectly to real World failure modes - assuming modern software principles for mission critical applications are followed, only the affected part of the system fails - the rest merily continues working.
This is what happens most of the time.

Where does this leave us and the original question ?

The question is perfectly valid and it is quite possible for a serious issue to freeze both systems. We can also state that this would be very rare to happen - but we cannot exclude this.
So - as usual, it depends on your aircraft's mission: What would happen if you loose your EFIS ? What would you need at minimum to continue safe flight ? Answer that and you have your answer.

Having written all of the above, I assume you are flying a single engined aircraft ? Perhaps a good idea to have two engines, one from Continental and the other a Lycoming....

Rainier
CEO MGL Avionics
 
When backups fail

The problem he is trying to avoid is that a systematic flaw common to both causes simultaneous failure. This is what caused the Ariane 5 rocket failure. The primary and backup flight computers shared exactly the same code, and when the rocket exceeded the bounds of that code (floating point overflow) both systems failed simultaneously. You can ready the hair-scary details here:

http://en.wikipedia.org/wiki/Ariane_5_Flight_501

This is, obviously, a possibility. It is not realistic for an end-user to independently estimate the complexity of the underlying code and come up with a probability of this simultaneous failure. The best way to eliminate this type of failure is to use two different systems or technologies. For ours, we're using an EFIS for primary, but a Falcon AI and a Taskem altimeter for backup instrumentation, effectively eliminating this failure mode. Then again, the likely MTBF of the Falcon AI is probably much less than and EFIS.
 
Good points made in this thread so far.

It's called a tie breaker and is the reason we still see peanut gyros (or digital ones) in the heavy iron (even with multitudes of redundant flight computers, there have still been some horrific crashes based on errant Primary Flight information). If your EFISes die or freeze, that is the best case because you know they failed. What is bad is a system that gets sick, doesn't know it and worse yet doesn't tell you....kind of like the old gyros slowly spinning down and you not knowing it. Say you have two EFISes. One starts leaning left and the other shows level or something different...you are in the clouds so how do you know which one is correct? If the EFIS is of fairly high quality, it should throw up a big red 'X' over the system or function that is indeterminate. The worst thing you can have is an EFIS that doesn't know if it's sick and doesn't tell you if it's feeling ill. If it freezes or re-boots or goes black, at least you know rather definitively what is going on. I don't want to turn this into a which EFIS is better (each mfgr will do that on their own)! :)

This is where the independent A/P comes in. It's a good tie breaker because it doesn't care what the EFIS is doing for it's attitude display. Most of the good A/P's will work beautifully even if you shut the EFIS off. The A/P should be considered an essential "backup" in a serious IFR airplane. It's also the reason you see a 3rd EFIS along with an independent A/P in many of the heavy IFR panels we do - and in certified / heavy iron airplanes. Excellent examples are the small Dynon's (and forthcoming EFISes from MGL and TruTrak) are all cheaper than steam gauges and are arguably more reliable than their analog counterparts. Even the Aspen units have become more popular as backups to some high end EFISes. Flying VFR this is a moot point, flying IFR this is something that should be carefully considered/studied outside the marketing rhetoric from various mgrs.

In the end though, I also have to point out to a few builders that no matter how many backups, batteries, alternators, etc.. that you have in the plane, you still only have one fan in front. I don't have a good/solid answer on this one other than to say a good handheld GPS can probably keep you alive, and a good proven A/P will likely do the same. Neither will care what your EFIS is doing!

My 2 cents as usual!

Cheers,
Stein
 
You must log in or register to reply here.