Recently, J. Severyn posted:

"Neil Gould" wrote in message
et...
Yesterday, I attended a 4-hour seminar on the G1000 presented by
Charlie Masters (Cessna/FITS & Sporty's @ Clermont County). The
focus was on providing an overview of transitioning from steam
gauges to glass panels as implemented in new Cessna single-engine
aircraft. Charlie did a great job, and has good general knowledge of
the system. Overall, I am quite impressed with the thought behind
this unit, and think it will be the way of things to come.

Of course, in addition to the general information, I was curious
about the possible causes for NW_Pilot's experience during the
ferrying of a 172, and asked a couple of questions that might have
provided some insights. I believe that I have some clues, but I'm
still at a loss to explain some of what he went through.

There are many things to understand about the G1000 installation,
perhaps foremost is that this is not a single box that is located in
the panel. There are more than a half dozen modules (not including
the sensors), some located in the tail of the plane, some located
behind the panel. These have specific functions, for example the
Attitude/Heading Reference System (AHRS) provides attitude and
directional information to the virtual AI & HSI separately from the
Integrated Avionics (GIA) that provides GPS/NAV & Comm functions.
Other modules include the Engine/Airframe (GEA) unit, Data Link
(GDL), and audio panel. The modules are on separate breakers in the
panel.

The significance of this kind of modularity is that the failure of
any of these modules will not cause an overall system failure. I
also asked Charlie about the connections between these modules and
the monitor. There is a single multi-conductor cable connection to
the back of the monitor panels. The entire system is fed power from
a connection to the master switch (there is also a backup battery
that can operate the unit separately from master power). So, the
total failure is unlikely to have been caused by sensors, monitors
or modules, as all of those would have to not only fail
simultaneously, but would have to reinstate themselves to "come up"
after a reboot, which is highly unlikely. Even a problem with the
multi-conductor cable would only affect one of the two monitor
panels.

All of this confirms my original suspicion that for the entire
system to periodically spontaneously reboot, the cause is likely to
be an intermittent power connection. In such a case, all of the
modules would go down, and the process would emulate the POH
procedure for intentionally rebooting the system.

Neil


Neil,
You could be correct. A bad power connection or poorly regulated
power could cause big problems. But the G1000 has an internal battery
pack that is supposed to provide graceful transition with bad power
inputs. Accordingly, I would not rule out a latent software problem.
After reading NW_Pilot's postings, I was thinking that the original
fuel quantity display problems might have caused some sort of over or
under-range internal calculation error.

Originally, I thought that this might be a possible scenario. However, the
fuel information is provided by the GEA, and even if that unit fails
completely, it would only result in red "X" over the fuel readout. There
are a couple of scenarios that can produce failure indications in the fuel
readouts, but from what I understand, nothing that can trigger a complete
system failure.

Since my day job involves
integrating hardware and software in large million-line control
systems, this is one of the first things that came to mind. It is
exceedingly difficult to test hardware and software in complex
systems at the possible extremes to guarantee proper operation.

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.

Simply put, out of range data would just fail that particular function.
For example, in the case of his fuel level reading failures, it seems
reasonable that the *increasing* fuel level readings as engine overflow
was fed from the aux tank to the main tanks didn't agree with the fuel
consumption computer, and as a result, the G1000 "X'd" it out, in essence
saying "don't depend on this info"; that is an intended behavior of the
G1000.

I sure hope that Garmin reads these types of newsgroup postings and
investigates. Invalid or over inputs on one or more sensors should
not have radical effects on unrelated operational modes of the G1000.
But it certainly looked like it was happening to NW_Pilot.

What I took away from the seminar is that about the only scenario that
could produce the effects that NW_Pilot reported is a main power failure.
All of the modules would have to fail simultaneously, and even then, the
system wouldn't reboot, but would show a screen full of red Xs. In fact,
the POH method of rebooting the G1000 in-flight is to shut off the main
power switch. The backup battery is only good for 1/2 hour, so it seems
possible that the spontaneous rebooting behavior started after the backup
battery was dry.

Neil