Some insights into the G1000

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 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. 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 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.

Regards,
John Severyn

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

"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.

"Neil Gould" wrote in message
news
By the way, Garmin is not unique to similar problems. It has happened to
the big iron too.
http://www.ntsb.gov/recs/letters/1998/A98_3_5.pdf notes intended reboots in
the EFIS in an A300 back in 1997.
Regards,
John Severyn

J. Severyn writes:

By the way, Garmin is not unique to similar problems. It has happened to
the big iron too.
http://www.ntsb.gov/recs/letters/1998/A98_3_5.pdf notes intended reboots in
the EFIS in an A300 back in 1997.

Airbus and Garmin have some things in common.

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

J. Severyn writes:

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.

Many companies in this domain for the first time, especially those
with PC backgrounds, never read anything and reinvent the wheel the
hard way, sometimes only after a string of very bad things happen.

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

Although many of the components of the G1000 have backups, many do
not. There are a lot of failures you can have that don't effect the
operation, but some do. Part of the transition training (especially
for IFR pilots) is to understand the failure mode of the different
components. Sadly, we're finding that we are only able to sign off
most of our instrument pilots for VFR in the G1000. The biggest
problem is getting behind the plane and not getting the approach set
up in the system soon enough. This is mostly the older guys though. I
dont' think anyone under 40 has had a problem.

-Robert, CFII, FITS trained TAA instructor


On Jan 28, 8:23 am, "Neil Gould" wrote:
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