NW_Pilot's Trans-Atlantic Flight -- All the scary details...

I just went back and re-read the story and realized that this was not truly a garmin problem. The modified fuel system caused the problem and those additions are outside the design envelop of the garmin system.

I most strenuously disagree. Systems should be designed NOT to fail
catastrophically when outside their "intended use". The problem was
=not= caused by the modified fuel system, rather, the problem was caused
by unexpected sensor input. In this case the unexpected sensor input
was caused by the modified fuel system, but it could have come from any
number of reasons, and the whole point of aviation systems is that they
be robust.

Jose
--
"Never trust anything that can think for itself, if you can't see where
it keeps its brain." (chapter 10 of book 3 - Harry Potter).
for Email, make the obvious change in the address.

John Theune writes:

I'm a software engineer and I've dabbled a little in real time systems
and there are many things that can cause a system to reboot. It might
be a **** poor design or it might be something else.

It's always poor design, unless power is cut to the system. This is
something that many software engineers don't understand.

The aircraft does not freeze in suspended animation while the system
reboots.

I just went back and
re-read the story and realized that this was not truly a garmin problem.

If the G1000 rebooted, it's a Garmin problem (although there may be
others).

The modified fuel system caused the problem and those additions are
outside the design envelop of the garmin system.

Rebooting is not an appropriate response to excursions outside the
envelope.

Bottom line is
that this was a modified system and to hold garmin responsible and use
that are a reason not to have advanced avionics is not good idea.

Why not? Does somebody have to die first?

--
Transpose mxsmanic and gmail to reach me by e-mail.

John Theune wrote:
Bottom line is
that this was a modified system and to hold garmin responsible and use
that are a reason not to have advanced avionics is not good idea.

John

To the contrary.. ferry tanks are are NOT UNCOMMON and this is a
foreseable modification. This is something that should have been
contemplated.. if not by the manufacturer then by the ferry tank
installer/STC holder.

Bottom line is.. a faulty fuel gauge for whatever reason should never
ever cause your whole damn flight instrumentation and display to crash
and reboot. This is a simple, fundamental idea

Dave

On 2006-10-02, John Theune wrote:
The modified fuel system caused the problem and those additions are
outside the design envelop of the garmin system.

But a fuel sensor out of range SHOULD NOT CAUSE THE SYSTEM TO BOOT LOOP.
Why should a fuel sensor out of range deprive you of your EHSI and
attitude indicator? The read outs for the instruments out of range
should be flagged and a suitable warning message generated - not the
loss of your entire IFR panel.

--
Yes, the Reply-To email address is valid.
Oolite-Linux: an Elite tribute: http://oolite-linux.berlios.de

John Theune wrote in news:wI6Ug.876$Pk2.497@trnddc08:

Just as people will plead to let the NTSB give a report before you
decide what caused a crash, I think the same thing should be done here.
I'm a software engineer and I've dabbled a little in real time systems
and there are many things that can cause a system to reboot. It might
be a **** poor design or it might be something else. NW_pilot has not
given us enough data to know ( because he did not have the data either )
The biggest problem is Garmin does not issue final reports but in this
cause it may be possible to find out why. I agree that a out of range
fuel sensor should not cause a system reboot. I just went back and
re-read the story and realized that this was not truly a garmin problem.
The modified fuel system caused the problem and those additions are
outside the design envelop of the garmin system. It would appear at
first glance that the condition that caused the problem ( over pressure
in the fuel tank due to excess fuel could not happen in a standard
system and so it was not forseen in the system design) Bottom line is
that this was a modified system and to hold garmin responsible and use
that are a reason not to have advanced avionics is not good idea.

John,
I work in Real Time systems on packaging equipment. It's certainly not
life-or-death equipment as is the control panel of an airplane, but I can
tell you unequivocably that a robust system will not reboot just because a
sensor behaves inconsistently with specification. Sensors fail all the
time. They even fail "high".

The description of the incident demonstrates evidence that not only is the
G1000 not robust, but it also ties many or all of the subsystems together
where a single sensor failure leads to catastrophic results. After all,
sensors can fail even if they are not attached to long range tanks.

Had the Fuel System display simply shown red X's and shut down because of
the invalid input, I would have said that to be acceptable (although not
ideal). The pilot would have immediately recognized a problem with the fuel
system, recognized that the red Xs were not consistent with a total
instantaneous loss of fuel, and known where to look to diagnose the
problem. But he would still have his GPS, and other instruments, and been
able to easily navigate to the nearest safe point to diagnose the problem
on the ground. Perhaps he would have even initiated a reboot or two on his
own.

However, in this case, the fuel sensor failure caused a total system
failure, including misleading readings such as CO in the cabin, lost
airspeed and lost GPS. The bad fuel sensor reading not only "bricked" the
system, but from the description, it caused the system to put forth false
information about the cause of the failure, making diagnosis extremely
difficult even after the fact.

That certainly brings to light some very interesting questions about the
safety of the G1000 system. I wouldn't want to put my life into the hands
of a system that bricks when a single sensor fails.

On Mon, 02 Oct 2006 10:18:13 GMT, Matt Whiting
wrote in :

... , it isn't a good idea to have all of your
eggs in one basket, especially when that basket is made of software! :-)

It would seem that Airbus has successfully grappled with this issue.
Perhaps Cessna and Garmin should get a clue from them.

Larry Dighera writes:

It would seem that Airbus has successfully grappled with this issue.

On the contrary, Airbus has shown just what a serious problem it is.

Perhaps Cessna and Garmin should get a clue from them.

Perhaps installing a video game in place of standard avionics isn't a
good idea.

--
Transpose mxsmanic and gmail to reach me by e-mail.

A few years ago, I remember reading an excellent book on general design of
modern avionics. In particular, one thing that I believe is different between
Garmin's baby and what they have in B-s and A-s is redundancy. The whole thing
there is doubled, and some critical components are tripled. And then there's
a whole body of software that takes care of voting-elimination among inputs.
By design, the event of the computer reboot (i.e. all three redundant computers
reboot) is perhaps as likely as the event of all four engines quitting at the
same time. What surprises me is that Garmin got FAA approval for such a system,
whereas it doesn't even come close to what "normal" glass cockpit is supposed
to be like in terms of robustness of system design. I understand it's all done
in the name of affordability, but this is clearly a dangerous game to play.

If you think about it, just to be able to claim any kind of "robustness",
you should be reasonably sure that there's no single failure that will take
the whole system out, right? And there we go: excessive fuel venting took
airspeed indicator out completely, and CO indication out completely. And this
is aside from any software bugs; this is the way G1000 is supposed to work
by design!

So, I guess my point is: you can't just take a steam-gauge-type airplane,
replace all the individual *independent* instrument systems with one
electronic box, and claim you've got an equally reliable plane. No way. By
tying everything together and establishing inter-system dependencies that
never existed before, you increase your likelihood of a catastrophic failure
by orders of magnitude. If you want to use an all-in-one instrument system,
you need to redesign the airplane and fit it with redundant systems to
compensate for that loss of overall reliability.

That's the book, btw:
http://www.amazon.com/Avionics-Handb...e=UTF8&s=books


Andrey


Larry Dighera wrote:
On Mon, 02 Oct 2006 10:18:13 GMT, Matt Whiting
wrote in :

... , it isn't a good idea to have all of your
eggs in one basket, especially when that basket is made of software! :-)

It would seem that Airbus has successfully grappled with this issue.
Perhaps Cessna and Garmin should get a clue from them.

congrats on a successful flight NW... half of me is really jealous and
the other half thinks it'd be too scared to try that even if given the
chance. loved the story though...

i was curious about cessna's explanation of the airspeed problems - you
said "the loss of the airspeed indicator was caused by fuel vapors
entering the pitot tube". how did it get in there? the wing vent is
well behind the pitot, right? i see the picture with fuel on the
nosewheel, did that come ouf of one of the drains under the fuselage?
did you lose both the G1000 and steam gauge indications or did one keep
working (accurately?)

thanks,

todd.

"Jay Honeck" wrote in message ps.com...
: http://www.alexisparkinn.com/nwpilot's_tranatlantic_flight.htm
:
: Man, if the new details of his story doesn't chill ya, nothing will!
: --
: Jay Honeck
: Iowa City, IA
: Pathfinder N56993
: www.AlexisParkInn.com
: "Your Aviation Destination"
:

See Jay, another reason to get the instrument rating!