rv8ch said:
John, That is a good article. As someone who has been working with computers and writing
software since the 70's I am very aware of the issues of software development. That's why I
said above that anything can break or fail, and you need to be able to handle that failure.

If I were outfitting my RV8 for IFR (I may upgrade at a later date) I'd be sure to have redundancy.

This is not a difficult thing to do in experimental aviation. You can install a nifty EFIS that may or
may not work, enjoy it's clear advantages when it is working, and fall back to another system if the
computer fails. Mike's story above shows that this is possible, not hard to do, and can even be
done with two different computer systems.

Assuming a really conservative 99% uptime for each EFIS, 99% uptime on two different systems is 99.99% uptime.
That's 0.01% downtime. Over a 2000 hour period, that's about 12 minutes. Add a third system, and
you're down to about 7 seconds of downtime in 2000 hours of flying. It may not be good enough for everyone,
but it's good enough for me.


Mickey,

I guess that's where you and I are different. I would never install a system in an aircraft that "may or may not work". I certainly wouldn't pay 10-15K for that kind of reliability expectation. Besides, Kahuna is talking about no less that 5 re-boots in 250 hours, and I'll bet there have been many more just like his. Your "uptime" analysis is flawed. If that failure happens at an inopportune time, say at night or in the traffic pattern, or in low vis, your risk assessment might be a little different (like Kahuna).

I suspect glass failures are like fat chicks.......nobody likes to brag about them!

If you are going to fly only VFR, enjoy your glass cockpit!
 
Last edited:
I seem to recall a certain Senator from Missouri who perished along with his son in a plane that crashed due to a failed vacuum driven gyro. No high tech gadget failure there. Just your run of the mill good old fashion standard gyro that failed. Ultimately causing pilot disorrientation and a fatal plane crash. Why do these kind of fatal accidents not cause people to stand up and demand the removal of all vacuum driven gyros from IFR airplanes? Why should using EFIS systems that have the potential for failures be any more dangerous than using existing systems that have the potential for failures?

It seems to me that mitigating the risk will always involve redundancy. It doesn't matter whether the airplane has new technology or old, making sure you have a backup method for your systems will be much more important than whether you use computer driven systems or vacuum driven systems.
 
Last edited:
John:

Although I agree with you somewhat, you are aware that any system may or may not work, right (e.g. Lycoming cranks)?

Just peruse the NTSB archives for how many people bought the farm when they should have simply bought a new vacuum pump instead.

Software is no different from the physical world, in my opinion. Any system whether mechanical or physical can and will fail. The problem is that most software systems are more complex than physical systems. The more complex the system...the more chances of failure.
 
RVbySDI said:
I seem to recall a certain Senator from Missouri who perished along with his son in a plane that crashed due to a failed vacuum driven gyro. No high tech gadget failure there. Just your run of the mill good old fashion standard gyro that failed. Ultimately causing pilot disorrientation and a fatal plane crash. Why do these kind of fatal accidents not cause people to stand up and demand the removal of all vacuum driven gyros from IFR airplanes? Why should using EFIS systems that have the potential for failures be any more dangerous than using existing systems that have the potential for failures?

It seems to me that mitigating the risk will always involve redundancy. It doesn't matter whether the airplane has new technology or old, making sure you have a backup method for your systems will be much more important than whether you use computer driven systems or vacuum driven systems.


Vacuum system failure was more prevalent before TBO limits were issued for the pumps. When dry vacuum pumps were certified, like so many GA components, they had no life limit. Now that they are a life-limited component, I think failures are rare. People used to run them until they failed, but not anymore. Feds say you have to change them at 500-1000hrs.

For about $450, an engine induction backup vacuum source makes this system nearly 100% reliable.

As far as redundancy goes, the turn coordinator, or better yet 3 axis autopilot gyro works well.
 
Failure Modes are Different

When my DG, AI or TC fails, it often fails in a sneaky way. Even in a simulator, these failures are hard to deal with because they are hard to detect. After crashing an airplane in the simulator because I did not detect the vacuum failure in time, I had a low vacuum alarm light installed in my Cessna ($100 + labor). This was not long after the death of the Missouri governor and his son.

If/when my GRT fails, I expect to know it more easily. The most likely mode would be a freeze or a blank. I also plan to use the dual AHRS version driving my two screens. That's so much better than my Cessna I have a hard time quantifying it. When you have a steam guage failure you are partial panel. If a GRT screen quits or even one of the AHRS units, you are not partial panel, you are alternate panel. And I also will have the two axis TruTrack for get-out-of-jail.

Also, as I understand it, the GRT has a lot of programming devoted to cross checking itself when overlapping data is available. Example: VOR's vs. GPS or Dual GPS inputs, for which it provides. Another example, if you pay for it, is airspeed and altitude options in their EIS to back up their AHRS.

I'm not commenting on Blue Mountain because all the comments I have heard lead to my personal opinion that BM is not the same level of quality for either physical construction or logical workings.

I'm not trying to persuade the guys with carbs and window cranks, just to contribute some more thinking to a valuable dialogue.
 
off topic apologies

hevansrv7a said:
When my DG, AI or TC fails, it often fails in a sneaky way. Even in a simulator, these failures are hard to deal with because they are hard to detect. After crashing an airplane in the simulator because I did not detect the vacuum failure in time, I had a low vacuum alarm light installed in my Cessna ($100 + labor). This was not long after the death of the Missouri governor and his son.

This seems to imply a loss of vacuum as responsible for that crash. The investigation showed no vacuum failure at all but a failure of one of the instruments!
Of course, the family still won a judgement against Parker (and Parker subsequently dropped vacuum pump manufacturing). Idiot jurors anxious to stick it to big business was the problem!
-mike
 
Yukon has decided that:
I would never install a system in an aircraft that "may or may not work"

Wow.....what kind of engine('s???) are you planning on using in your RV???

Matter of fact, I am afraid the pilot of my airplane falls into the catagory of "may or may not work"......... ;)
 
Planning for the inevitable

Which of course brings the real issue to the fore.

What am I going to do if...................

Pete.
 
Failure Mode again

mlw450802 said:
This seems to imply a loss of vacuum as responsible for that crash. The investigation showed no vacuum failure at all but a failure of one of the instruments!
Of course, the family still won a judgement against Parker (and Parker subsequently dropped vacuum pump manufacturing). Idiot jurors anxious to stick it to big business was the problem!
-mike
At the time I put in the vacuum alarm the buzz was that the crash was due to vacuum failure. My simulator crash was a "failed" vacuum pump. I have also had individual mechanical instruments go bad and am aware of others, both electrical and vacuum. My purpose is not to condemn steam guages - they are what they are - but to point out the difference in failure modes. All devices can fail.

I agree about jury decisions/awards in aviation cases (Cessna Aerobat, Quickie, etc.). But that's politics, so don't get me started.

I also don't think it's realistic to use airliners as a measure of what is prudent in an RV. Just one of their instruments can easily cost as much as my whole -7A. Look at what they spend on their backup steam guages. And they cannot land in a few hundred feet, let alone at 65 mph.
 
No Steam

Modern Airliners don't use backup steam guages......... or vacuum pumps.

Back up Instruments are all electirc, LED displays.

But they have a miriad of electrical power suplies. Generators, Batteries and RATs.
Pete.
 
Weakest Link

Sam Buchanan said:
Yukon has decided that:


Wow.....what kind of engine('s???) are you planning on using in your RV???

Matter of fact, I am afraid the pilot of my airplane falls into the catagory of "may or may not work"......... ;)


That's a fact Sam, I am definitely the weak link in the machine!

I'm using the engine that brother Van tells me to use. You guess which one.......Never heard anyone describe it as "might work, might not"
 
What are the odds of this happening?

Hello Everyone:

First, some background:

1) Do not have my certificate ... yet
2) Have not started an RV ... yet
3) This is my first non-test post on this forum.

From Kahuna's provided failure data:

BMA has had 4 freezes in 250 flight hours
GRT has had 1 freeze in 250 flight hours

My understanding is that these failures were prior to his dual failure described in his post.

Admittedly, these calculations are crude and based on very limited data, but I have been trying to convince myself that this dual failure was somehow just bad luck. Assuming his average flight is 2 hours long ...

Probability of Failure for his BMA is 4/250/2 = 0.032 per 2-hr flight
Probabiliy of Failure for his GRT is 1/250/2 = 0.008 per 2-hr flight

Based on this data, the chances of both units failing on the same 2 hour flight is (0.032)*(0.008) ~ 0.000256 or about 1 in 4000.

I agree, it is possible that the two units just independantly failed due to "bad luck", but 4000 2-hour flights is a lot of stick time (8000 hrs!) I guess it gets me thinking about a common assignable cause ...

Are the re-boot numbers that Kahuna listed typical for others with EFIS equipment? If they are significantly higher, perhaps they are indicative of another potential issue?

Regards,
Tim
 
FiveNinerTIM said:
I agree, it is possible that the two units just independantly failed due to "bad luck", but 4000 2-hour flights is a lot of stick time (8000 hrs!) I guess it gets me thinking about a common assignable cause ...
In the case of the GRT there is a definate and known assignable cause. It's a bug in the code that is repeatable. I believe the jury's still out on the BMT.
 
FiveNinerTIM said:
...


Based on this data, the chances of both units failing on the same 2 hour flight is (0.032)*(0.008) ~ 0.000256 or about 1 in 4000.

A crash rate of 1/250 hrs is pretty bad, 4/250 is really bad on my arbitrary scale...

Even so you came up with 1 in 4000 flights. What percentage of those flights are in hard/approach IMC? 1 in 200? Add to that the fact that an autopilot or other redundancies add another factor of safety.

It seems to me that the 2*efis + autopilot + redundant power takes a lot of problems before you are out of options. I would bet that the number of people who are saved by efis/gps/autopilot provided situational awareness exceeds the number lost by multiple failures.

I compare Kahuna's setup to the 172 with a single vacuum pump, no GPS that I got my instrument ticket in and have to laugh...
 
IF A=B, THEN ACTIVATE, ELSE (do something else).

joe gremlin said:
In the case of the GRT there is a definate and known assignable cause. It's a bug in the code that is repeatable. I believe the jury's still out on the BMT.

Exactly Joe. You are exactly correct. The programmer created a set of instructions that said IF the synthetic approach function (SAP) is armed and destination runway data is not available, try to activate the localizer arm function (LOC in the ARM menu). When it failed to activate that arm, that froze the display. There was no logic offered to tell the program what do to if the localizer arm function failed to respond.

All conditional programming logic SHOULD be coded IF (some condition exists), THEN ACTIVATE LOCALIZER ARM, ELSE (do something else).

Every attempt to activate a device should have a timeout routine if it cannot activate the device rather than just sit there and hang.

It?s no different than the A&P who uses a common steel bolt with a tensile strength of 50,000 psi instead of using an aircraft bolt made from corrosion resistant steel and heat treated to a strength in excess of 125,000 psi explaining, ?GEE, that?s all I had on hand?.

Comparisons to 777's are about as valid as comparisons to my 150 or Wilbur & Orville's airplane. If people are going to bet their lives on these devices, programming should be examined for details as basic and obvious as this.
 
Reliability

"Comparisons to 777's are about as valid as comparisons to my 150 or Wilbur & Orville's airplane. If people are going to bet their lives on these devices, programming should be examined for details as basic and obvious as this."

No, sir, comparisons with transport aircraft are completely valid because they illustrate the difficulty of writing reliable software, even with an unlimited budget.

As far as your Cessna 150 goes, I wouldn't be bragging about that!
 
MrNomad said:
All conditional programming logic SHOULD be coded IF (some condition exists), THEN ACTIVATE LOCALIZER ARM, ELSE (do something else).

Every attempt to activate a device should have a timeout routine if it cannot activate the device rather than just sit there and hang.

This reminds me of my first manager. He would lecture us on how the software should never crash, and whenever something failed he would lecture us on the "proper" behavior...as if we intended for it to fail or crash. LOL. Worst guy I ever worked for. I ended up leaving after 9 months. I manage a team of engineers now, and everytime I'm about to ask someone "What the heck were you thinking when you did that?", I think of him and bite my tongue.

Here's the fact of the day: No program will ever be 100% reliable and bug free. Here's another one: no mechanical or electro/mechanical device will ever be 100% reliable and bug free. So now what? Do you lock yourself in a cave? Are unreliable mechanical components better than unreliable (usually MORE reliable, BTW) software?

We already know that the version in question was out for BETA testing. The bug report came in, was fixed the same day and a fix was on their website. I just simply fail to see where all the rants against these engineers is coming from. The whole process from beginning to end worked precisely as intended.

Only a fool would "bet" their lives on an EFIS, or any other device. I would certainly trust my life, however, to a panel designed for reliability through a reasonable amount of redundance and backup.

The fact that 2 completely different EFIS failed at the same time in this case is just fantanstic and something that I'd never heard of before (that 1 in 4000 number is bogus. You can't do statistics with 1 data point running BETA software). Okay, fine...sometimes engines throw rods. What do you do now, fly gliders instead? Careful...gliders have been known to crash because of system failures too!
 
Last edited:
Beta Testing

"We already know that the version in question was out for BETA testing. The bug report came in, was fixed the same day and a fix was on their website. I just simply fail to see where all the rants against these engineers is coming from. The whole process from beginning to end worked precisely as intended."

So I guess the question now is why anyone would enter the IFR environment with Beta software?????
 
Trapping programming errors

GRT Version 28 is/was indeed a beta and their website warns of this. Yes, it's true there has never been an OS or an application that cannot fail. Yes, you should try to trap all errors. However, IF-THEN-ELSE logic is generally not effective at that. By definition, you have to think of all the ELSE conditions. Some languages are better than others at error trapping. Java comes to mind as does C++. If you write everything [what I like to call] backwards, it does help. For example "if (perform-X != 0) invoke error-handler". This is not perfect but it helps. Of course, using any Windows product means you accept the weaknesses MS built into the OS. That's true for any OS, but infamously true for MS. BTW:I note that GRT uses only a two-fingered salute.;). Even if we had perfect programs, the electronic hardware could fail, as could the connectors. What about lightning?

I've been impressed with how much thought GRT gives to failure modes, cross checking within the unit and isolating the components within the unit. For me, their stuff with appropriate backup is as good or better than steam gages in the same price level (total panel). For you, well that's a personal decision.

I think that taking shots at GRT's programmers is probably not the most effective way to analyse the situation, even when they screw up. Do you fly IFR over fog or hostile terrain? On one engine? Without a parachute? without a hand-held radio? When a little fatigued? Is anyone innocent of all these risks all the time?
 
Informed

This Forum comes into its' own when the informed, qualified boys chime in; as in the last handful of post on this topic.
Thanks for the input. I'm learning a lot here.
Pete.
 
Software advantages

One advantage of software over mechanical devices that can't be overstated is the ease with which SB's and AD's (in the certified world) can be carried out. With software it's just a matter of updating software...with mechanical gizmo's you're going to be switching something out.
 
Are we bashing the vendor?

jcoloccia said:
This reminds me of my first manager. He would lecture us on how the software should never crash, and whenever something failed he would lecture us on the "proper" behavior...as if we intended for it to fail or crash. LOL. Worst guy I ever worked for. I ended up leaving after 9 months. I manage a team of engineers now, and everytime I'm about to ask someone "What the heck were you thinking when you did that?", I think of him and bite my tongue.

We already know that the version in question was out for BETA testing. The bug report came in, was fixed the same day and a fix was on their website. I just simply fail to see where all the rants against these engineers is coming from. The whole process from beginning to end worked precisely as intended.

Great dialogue, question is, are we bashing the vendor or are folks trying to protect this fantastic hobby from government intervention and a feeding frenzy from the legal community?

Those who proffer tolerance for the ?innocent? programmer seem to forget is that the sport known as HOMEBUILT may have more airplanes in the sky than the big boys, and we?re growing by leaps and bounds. You can entitle the software beta, call it experimental, get waivers, sign releases, etc., etc., but sooner or later someone won?t be as cool as KAHUNA and the outcome not so pleasant.

All it takes is one fatal episode for some local politician seeking reelection to clamor for the feds to ?protect the public? with more expensive (and probably useless) regulation. But long before regulation, some savvy lawyer will determine the following:

1) Liability is based on ?proximate cause?. In other words, what did the vendor do, or fail to do, that caused the accident?
2) What are the damages? Did the widow lose her lawyer/pilot husband who was capable of many more years of fat paychecks? How about the innocent folks on the ground?
3) But most importantly the big law firms ask: ?Does the vendor have lots of insurance??

Right and wrong simply doesn't matter. If it ?looks good?, twelve jurors will then receive a college education in the word ?negligence? in an effort to ?adequately compensate? the poor widow and the unfortunate folks on the ground (sic). Government will be forced to ?step in? (at the behest of the certificated manufacturers who are losing sales to homebuilt aircraft & folks on the ground who dislike the noise anyway) and our ability to build, fix, and innovate will suddenly suffer new regulation & expense.

Posting changes on a website is great but it?s also known as Conspicuous Notice (aka: CYA). Whether that?s enough to defeat an ambulance chaser seeking a windfall is unknown but just the defense could cost several hundred thousand dollars which is then passed onto the consumer (us).

Guns don?t kill people, people kill people but if there is something to be learned from those of us who support the NRA it?s how many gun manufacturers have been sued and put out of business due to frivolous lawsuits. Ditto for my favorite food KFC, McDonalds (hot coffee anyone??), etc., the insanity goes on and on.

In my not-so-humble opinion, suggesting ?reboot? by holding down two buttons for five seconds as a solution is a million dollar gift to the plaintiff and the lawyer who will get 50%. Oh, by the way, this girl has small hands which means I'd have to let go of the stick to hold down two buttons.
 
Lawsuits...yuck

Did you read about that pilot that got sued for distracting the controller and supposedly causing a mid-air....and lost. :confused:

When it comes to juries, I'm reminded of this wonderful passage I saw on a calendar from www.despair.com

"None of us is as dumb as all of us"
 
YOU ROCK LEGALEAGLE!

Excellent post, LegalEagle. Exactly what I've been trying to say for months. Not only should we be pursuing protection of the sport, but the individuals buying suspect products. Thanks again!

PS What are you building????

John
 
Liability is based on ?proximate cause?. In other words, what did the vendor do, or fail to do, that caused the accident?

Actually, Liability is based on wrongdoing, either negligence or design/manufacturing defect.

You only get to cause after that first step is met, and if there is nothing like an assumption of risk, or other defenses.

Of course free legal advice is usually worth what you pay for it, but I would caution anyone that it is not that simple, and that most experienced trial lawyers, on both sides of the fence, would tell you that juries, properly instructed, do a pretty good job. Of course you only ever hear about the big cases where mistakes seem obvious.