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

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"

On 1 Oct 2006 06:47:05 -0700, "Jay Honeck" wrote
in om:

http://www.alexisparkinn.com/nwpilot's_tranatlantic_flight.htm

Man, if the new details of his story doesn't chill ya, nothing will!

A more experienced pilot who had studied the aux tank system may have
been able to mentally diagnose the cause of the fuel venting. But
Garmin's role in this incident is unforgivable.

A more experienced pilot who had studied the aux tank system may have
been able to mentally diagnose the cause of the fuel venting. But
Garmin's role in this incident is unforgivable.

Garmin needs to wake up! To have out-of-bounds sensor inputs reboot the
system continuously, especially something as unreliable as fuel sensors, is
horrible system design.

Even Microsoft has awakened to this. They now have fewer browser bugs per
year than Firefox.
What do you want to bet that there is a bunch of other safety critical,
software driven devices that are prone to this?

Think about this for a second. What if there was some unexpected
transmission from a GPS satellite due to an incorrect software load to the
satellite that caused the G1000 to reboot continuously. Now extend that.
Take your Garmin portable GPS out to save your butt and it ALSO includes the
deficient algorithm and continuously reboots. Scary. I would bet the
portables share quite a bit of logic and decision trees with the panel
mounts.

Ron A. writes:

Garmin needs to wake up! To have out-of-bounds sensor inputs reboot the
system continuously, especially something as unreliable as fuel sensors, is
horrible system design.

It implies that the system was designed by desktop programmers,
instead of people with experience building mission-critical computer
systems. I guess people will have to die to get bugs fixed.

There is never any excuse for a safety-of-life computer to reboot,
short of a power interruption.

What do you want to bet that there is a bunch of other safety critical,
software driven devices that are prone to this?

Unfortunately, there are probably a great many of them, including
anything built by Garmin.

Think about this for a second. What if there was some unexpected
transmission from a GPS satellite due to an incorrect software load to the
satellite that caused the G1000 to reboot continuously. Now extend that.
Take your Garmin portable GPS out to save your butt and it ALSO includes the
deficient algorithm and continuously reboots. Scary. I would bet the
portables share quite a bit of logic and decision trees with the panel
mounts.

Probably. And you can bet that nobody is verifying the generated
binaries bit by bit, the way people used to verify safety-of-life
software in the old days. If it compiles without errors, it's ready
to ship!

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

Ron A. wrote:
A more experienced pilot who had studied the aux tank system may have
been able to mentally diagnose the cause of the fuel venting. But
Garmin's role in this incident is unforgivable.

Garmin needs to wake up! To have out-of-bounds sensor inputs reboot the
system continuously, especially something as unreliable as fuel sensors,
is horrible system design.

I agree that continuous rebooting is a bad idea. Rebooting _once_ might
help, but the screen and/or manual should present it along the lines of:

"One of my inputs is flaky. I can ignore that input and keep going with
reduced capabilities, OR I can try rebooting to see if that clears up
the problem. There is no guarantee that rebooting will help, and there
is no guarantee that I will be able to keep going with reduced
capabilities after the reboot. What do you want to do?"

The idea of rebooting to fix an embedded safety system is not that great -
it shouldn't get into that state in the first place. But I think the
option should be there. If you want to work under the assumption that
you might get into an odd state, probably a better plan is to somehow
announce "I'm confused, but I'll keep going" and give the pilot the
option of rebooting by cycling power, rather than going into a reboot
loop on your own.

At work, I sometimes help engineering students who are trying to design
a (road) vehicle control system. If they are new to the subject, they
tend to want lots of lockouts and "clearly, this is always an illegal
condition" cases. I have had to give examples like "so, what if the
computer control of the 5-speed transmission decides it knows best and
cuts your thrust, right when all you can see in the rear-view mirror is
a huge chrome RENILTHGIERF"? The idea I try to get across is that a
large percentage of the time, the driver will have more information
about the situation than the computer will. Whether the driver acts
appropriately based on this extra information is a whole other
discussion, but at least the possiblity of doing the right thing is
there.

Sometime before early 1989, one Cal Keegan summed this up quite
succinctly: "It's not just a computer -- it's your ass."

Even Microsoft has awakened to this. They now have fewer browser bugs
per year than Firefox.

Hooray! Let's run airplane computers on Internet Explorer.

Matt Roberds

wrote:
I agree that continuous rebooting is a bad idea.

Just FYI, NASA's Mars Spirit rover got itself into a continuous reboot
cycle too:

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

I've been involved in a couple of projects where we considered adding an
external hardware watchdog reboot system. (These are simple systems that
must be sent a heartbeat pulse periodically by the application, otherwise
the watchdog assumes the app died and does a hard reset of the application
system.)

Automatic reboot is of course a last resort, but given a choice between a
distant system that freezes up entirely and all hope of recovery is lost
and one that reboots into a state long enough to allow a small chance to
salvage the situation, I think the latter is preferred.

but given a choice between a
distant system that freezes up entirely...

Different application. Here we have a live pilot who can make a
decision and push the button, but the computer decides to push it for
him. There, it's completely on its own, and a last resort is
worthwhile. One just make sure the last resort doesn't get too
impatient.

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.

In a previous article, Jim Logajan said:
wrote:
I agree that continuous rebooting is a bad idea.

Just FYI, NASA's Mars Spirit rover got itself into a continuous reboot
cycle too:

And even then they only way they fixed it was to figure out a way to stop
it rebooting long enough to listen to some commands.


--
Paul Tomblin http://xcski.com/blogs/pt/
Pity stayed his hand. "It's a pity I've run out of bullets", he thought.
-- Bored of the Rings

"Larry Dighera" wrote in message

A more experienced pilot who had studied the aux tank system may have

Do you have a machine to pick those nits, or do you do it all by hand?

"John Gaquin" wrote in message
. ..

"Larry Dighera" wrote in message

A more experienced pilot who had studied the aux tank system may have

Do you have a machine to pick those nits, or do you do it all by hand?



Consider the source...




---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0639-4, 09/29/2006
Tested on: 10/1/2006 7:06:48 PM
avast! - copyright (c) 1988-2006 ALWIL Software.
http://www.avast.com