Some insights into the G1000

"Neil Gould" wrote in message
news
Recently, J. Severyn posted:

"Neil Gould" wrote in message
et...
Yesterday, I attended a 4-hour seminar on the G1000 presented by

snip

I understand, and it appears that this was done. On the one hand, this
system isn't all that complex; rather than feed numerous inputs into a
single interpreter module, which might result in the kind of event you're
anticipating, each module is a physically separate piece of hardware that
feeds its results to the integraged display. There is also redundancy
built into some modules (multiple components doing the same job), and any
ambiguities are either resolved by a "vote of the majority" or failed, but
won't result in a system-wide reboot.

I understand. But the integrated display might be the culprit. The
individual LRUs might be acting properly and feeding data to the display
system. If the display system (hardware or software) does not properly
handle the exceptions, then lots of unintended things can happen. Software
patches, compiler errors etc. only make the testing combinations all the
more difficult.

In any case, a pilot has got to be able to keep the dirty side down using
the backup steam guages.

snip
Neil


Regards,
John Severyn

Recently, J. Severyn posted:

"Neil Gould" wrote:
Recently, J. Severyn posted:

"Neil Gould" wrote in message
et...
Yesterday, I attended a 4-hour seminar on the G1000 presented by

snip

I understand, and it appears that this was done. On the one hand,
this system isn't all that complex; rather than feed numerous inputs
into a single interpreter module, which might result in the kind of
event you're anticipating, each module is a physically separate
piece of hardware that feeds its results to the integraged display.
There is also redundancy built into some modules (multiple
components doing the same job), and any ambiguities are either
resolved by a "vote of the majority" or failed, but won't result in
a system-wide reboot.

I understand. But the integrated display might be the culprit.

I don't think that's possible. There is no provision for the display
system to reboot the hardware; that just isn't done via software, or even
by physical switches located on the display unit(s). The display unit(s)
can't turn on or off the individual modules either, so a software glitch
of any kind -- or even total failure of the display -- isn't able to be
the cause of a system-wide reboot.

The
individual LRUs might be acting properly and feeding data to the
display system. If the display system (hardware or software) does
not properly handle the exceptions, then lots of unintended things
can happen. Software patches, compiler errors etc. only make the
testing combinations all the more difficult.

I understand, and in a type of arrangement where sensor outputs are being
interpreted by centralized CPU, what you describe might be an area of
concern. But, the G1000 is not that kind of system. Each module is its own
complete computing system, the integrated display merely reports the data
provided by the modules. When the data from modules conflicts and can't be
resolved, the centralized display can disable that module's content *on
the screen*, it can't shut the module down.

In any case, a pilot has got to be able to keep the dirty side down
using the backup steam guages.

The backup steam gauges are completely separate from the G1000, as is the
autopilot and the comm (another reason that I suspect NW_Pilot's problems
are related to the loss of power). In fact, the 2-axis autopilot has its
own turn coordinator mounted behind(!) the panel, and will fly the plane
even if the G1000 is turned off.

Neil

Neil Gould writes:

I don't think that's possible. There is no provision for the display
system to reboot the hardware; that just isn't done via software, or even
by physical switches located on the display unit(s). The display unit(s)
can't turn on or off the individual modules either, so a software glitch
of any kind -- or even total failure of the display -- isn't able to be
the cause of a system-wide reboot.

Virtually any bug can cause a reboot. Anything that produces a
hardware exception can cause a reboot if it is unexpected,
particularly if the system is doing privileged work at the time. A
reboot is the typical response to any unhandled exception. The
alternative is to let the system run hither and yon uncontrolled
through the code, which is even worse than a reboot in most cases.

Of course, in safety-of-life applications, there must not be any
unexpected exceptions; if there are, it's a flaw in the design.
Unfortunately, people from PC-land tend to take the system down
whenever there's a spot in the code that they don't want to design or
analyze in detail.

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

On Jan 28, 5:14 pm, Mxsmanic wrote:
Neil Gould writes:
I don't think that's possible. There is no provision for the display
system to reboot the hardware; that just isn't done via software, or even
by physical switches located on the display unit(s). The display unit(s)
can't turn on or off the individual modules either, so a software glitch
of any kind -- or even total failure of the display -- isn't able to be
the cause of a system-wide reboot.Virtually any bug can cause a reboot. Anything that produces a
hardware exception can cause a reboot if it is unexpected,
particularly if the system is doing privileged work at the time. A
reboot is the typical response to any unhandled exception. The
alternative is to let the system run hither and yon uncontrolled
through the code, which is even worse than a reboot in most cases.

Of course, in safety-of-life applications, there must not be any
unexpected exceptions; if there are, it's a flaw in the design.
Unfortunately, people from PC-land tend to take the system down
whenever there's a spot in the code that they don't want to design or
analyze in detail.

A reboot of an individual display would not surprise me (although I've
never seen it happen). A reboot of both would surprise me. However,
NW_pilot's issue was a software bug associated with the long range
tanks that were installed. I guess the computer failed working out the
fuel calculations. Since both sides run the same software, both sides
probably had the same fault.

-Robert, CFII, FITS TAA instructor.

Recently, Robert M. Gary posted:

Neil Gould writes:
I don't think that's possible. There is no provision for the display
system to reboot the hardware; that just isn't done via software,
or even by physical switches located on the display unit(s). The
display
unit(s) can't turn on or off the individual modules either, so a
software
glitch of any kind -- or even total failure of the display -- isn't
able
to be the cause of a system-wide reboot.

A reboot of an individual display would not surprise me (although I've
never seen it happen). A reboot of both would surprise me.

Do you mean a display failure rather than a reboot? Anyway, as I
understand it, there is no facility for the display to reboot the
individual computers

However,
NW_pilot's issue was a software bug associated with the long range
tanks that were installed. I guess the computer failed working out the
fuel calculations. Since both sides run the same software, both sides
probably had the same fault.

That is my guess as well, based on the information from the seminar. As I
understand it, the G1000 would disable (red "X") the readout of any
component with an unresolvable conflict. Since the aux tank was
"refilling" the main fuel tanks via the overflow return, it wouldn't be
long before the flight computer data would be in conflict with the fuel
level sensor and therefore generate an unresolvable error. It should be
expected that both displays would show the same error condition.

Neil

On Mon, 29 Jan 2007 21:17:47 GMT, "Neil Gould"
wrote:

That is my guess as well, based on the information from the seminar. As I
understand it, the G1000 would disable (red "X") the readout of any
component with an unresolvable conflict. Since the aux tank was
"refilling" the main fuel tanks via the overflow return, it wouldn't be
long before the flight computer data would be in conflict with the fuel
level sensor and therefore generate an unresolvable error. It should be
expected that both displays would show the same error condition.

I guess that would be based on the invalid presumption that the fuel
computer, time to empty, fuel flow, etc have any interaction with the
fuel level indicators. They don't. You tell the time-to-empty
computer how much fuel is onboard and it deducts based on current fuel
flow. If you don't refresh it's fuel on board at the beginning of a
flight you can get 0:00 minutes to empty with hours worth of fuel left
in the tanks.

Recently, Peter Clark posted:

On Mon, 29 Jan 2007 21:17:47 GMT, "Neil Gould"
wrote:

That is my guess as well, based on the information from the seminar.
As I understand it, the G1000 would disable (red "X") the readout of
any component with an unresolvable conflict. Since the aux tank was
"refilling" the main fuel tanks via the overflow return, it wouldn't
be long before the flight computer data would be in conflict with
the fuel level sensor and therefore generate an unresolvable error.
It should be expected that both displays would show the same error
condition.

I guess that would be based on the invalid presumption that the fuel
computer, time to empty, fuel flow, etc have any interaction with the
fuel level indicators.

Yes, that would be it. ;-)

They don't.

Thanks for the clarification, as it is not the answer that I got to the
question I asked about it. But, as you apparently own one and have
observed this condition, your knowledge resolves the conflict. ;-)

So, what happens if the fuel level indicators report "full" after a few of
hours of flying, which could be the case in NW_Pilot's ferrying scenario?
Might the GEA presume that they weren't working, and "X" it out on the
display?

Neil

On Jan 29, 1:53 pm, Peter Clark
wrote:
On Mon, 29 Jan 2007 21:17:47 GMT, "Neil Gould"

wrote:
That is my guess as well, based on the information from the seminar. As I
understand it, the G1000 would disable (red "X") the readout of any
component with an unresolvable conflict. Since the aux tank was
"refilling" the main fuel tanks via the overflow return, it wouldn't be
long before the flight computer data would be in conflict with the fuel
level sensor and therefore generate an unresolvable error. It should be
expected that both displays would show the same error condition.

I guess that would be based on the invalid presumption that the fuel
computer, time to empty, fuel flow, etc have any interaction with the
fuel level indicators. They don't. You tell the time-to-empty
computer how much fuel is onboard and it deducts based on current fuel
flow. If you don't refresh it's fuel on board at the beginning of a
flight you can get 0:00 minutes to empty with hours worth of fuel left
in the tanks.

From the pilot's point of view that's true. However, a fault in the
GEA 71 system could cause the entire thing to get sick. Your argument
is a bit like saying Word could never hang because of a fault in IE.
Ideally, yea, practically, maybe not.

-Robert, CFII G1000 instructor

On 29 Jan 2007 10:23:49 -0800, "Robert M. Gary"
wrote:

A reboot of an individual display would not surprise me (although I've
never seen it happen). A reboot of both would surprise me. However,
NW_pilot's issue was a software bug associated with the long range
tanks that were installed. I guess the computer failed working out the
fuel calculations. Since both sides run the same software, both sides
probably had the same fault.

-Robert, CFII, FITS TAA instructor.

If it was a software problem with handling the long range tank, don't
you think it would have shown up in some other flight than his? It's
not like he's the first to take ferry tanks and a G1000 equipped
aircraft across the pond.

The fuel indication system in the Cessna 172 G1000 is a plastic float
attached to an arm which controls a rheostat and produces a variable
resistance. The resistance is measured, from a high-ohm to a low-ohm
limit (+-5ohm if I remember correctly) by the GEA and translated into
a pointer on the display. It's not computed, it's not analyzed, it's
not even compared with time-to-empty, fuel-flow, etc etc etc. In
fact, the standard full-tanks is about 1hr flight above where the
float starts generating something other than the signal "full" and the
system doesn't reboot due to it. We've replaced many floats in my
aircraft (they have a tendency to red X when the tanks are full until
a couple of gallons are burned down) and not once was a red X for
extended periods of time responsible for a system rebooting. In fact,
I've never seen or heard of a system rebooting to "initializing
system" outside of the one sample. The three shops I deal with for
avionics, who are Cessna service centers and Garmin dealers, haven't
seen this either.