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

Jose wrote:
To clarify my earlier post: Go ahead and blame Garmin ( which may or
may not be right ) but don't use this failure as a reason not to have
advanced avionics in aircraft.

Software that reboots the entire instrumentation panel because of a
single bad input is not "advanced".

Jose
and as had been pointed out by a number of people, there is no solid
evidence that make it clear that the reboots where caused by the out of
range sensor. Even the original story said the fuel displayed displayed
red x before other system failed and eventually rebooted the overall
system. Even it the G1000 is a bad design/system, it's still no reason
to say that we must stay with steam gauges.

John

Even it the G1000 is a bad design/system, it's still no reason to say that we must stay with steam gauges.

No, it is not.

It would however mean that the G1000 is a bad design/system.

More to the point, it is an =attractive= bad design/system. That's the
nub. Glass is really sexy, and because of this, can be marketed =even=
if it's a bad design/system. One should be suspicious of glass =for=
that reason.

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 wrote:

Jose wrote:

To clarify my earlier post: Go ahead and blame Garmin ( which may or
may not be right ) but don't use this failure as a reason not to have
advanced avionics in aircraft.


Software that reboots the entire instrumentation panel because of a
single bad input is not "advanced".

Jose

and as had been pointed out by a number of people, there is no solid
evidence that make it clear that the reboots where caused by the out of
range sensor. Even the original story said the fuel displayed displayed
red x before other system failed and eventually rebooted the overall
system. Even it the G1000 is a bad design/system, it's still no reason
to say that we must stay with steam gauges.

I believe that there are many reasons for redundancy and the potential
for a poorly designed system is one of them.

Matt

On Wed, 04 Oct 2006 01:16:08 +0000, Matt Whiting wrote:

I believe that there are many reasons for redundancy and the potential for
a poorly designed system is one of them.

If we assume a bug that causes a G1000 to fail due to bad data coming from
a sensor, for example, then it doesn't matter if we've a dozen G1000s in
the airplane. Dealing with bad design requires diversity as well as
redundancy.

- Andrew

Andrew Gideon wrote:

On Wed, 04 Oct 2006 01:16:08 +0000, Matt Whiting wrote:


I believe that there are many reasons for redundancy and the potential for
a poorly designed system is one of them.


If we assume a bug that causes a G1000 to fail due to bad data coming from
a sensor, for example, then it doesn't matter if we've a dozen G1000s in
the airplane. Dealing with bad design requires diversity as well as
redundancy.

I'd prefer redundancy at both the sensor and instrument level if I was
flying IFR across the pond.

Matt

On Wed, 04 Oct 2006 22:22:21 +0000, Matt Whiting wrote:

If we assume a bug that causes a G1000 to fail due to bad data coming
from a sensor, for example, then it doesn't matter if we've a dozen
G1000s in the airplane. Dealing with bad design requires diversity as
well as redundancy.

I'd prefer redundancy at both the sensor and instrument level if I was
flying IFR across the pond.

Good point. But diversity still helps, lest a design flaw in the one
sensor design triggers a design flaw in the one instrument design.

- Andrew

Andrew Gideon writes:

Good point. But diversity still helps, lest a design flaw in the one
sensor design triggers a design flaw in the one instrument design.

Software requires diversity rather than redundancy. In practice this
means having two or three or more software packages that perform
exactly the same functions, but are written in different ways by
different development teams. It's unlikely that they will all fail in
the same way at the same time, because they are completely different
internally. This helps make the system more robust.

Something tells me that this concept never even crossed anyone's mind
at Garmin for the G1000.

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

"Mxsmanic" wrote in message
news
Andrew Gideon writes:

Good point. But diversity still helps, lest a design flaw in the one
sensor design triggers a design flaw in the one instrument design.

Software requires diversity rather than redundancy. In practice this
means having two or three or more software packages that perform
exactly the same functions, but are written in different ways by
different development teams. It's unlikely that they will all fail in
the same way at the same time, because they are completely different
internally. This helps make the system more robust.


A Man with one watch knows what time it is,
a man with two is never sure...

Al G

Matt Whiting schrieb:

I'd prefer redundancy at both the sensor and instrument level if I was
flying IFR across the pond.

It was a *ferry flight* in an airplane which was not supposed to ever
fly over water again. You want full redundancy installed for one ferry
flight? Ok, just don't ferry fly then.

Stefan

"Stefan" wrote in message
...
Matt Whiting schrieb:

I'd prefer redundancy at both the sensor and instrument level if I was
flying IFR across the pond.

It was a *ferry flight* in an airplane which was not supposed to ever fly
over water again. You want full redundancy installed for one ferry flight?
Ok, just don't ferry fly then.

Stefan


Look where the plane went! I assure you that it is going to over fly water
again in IMC conditions!