achimha wrote:
It’s all software and there can be thousands of bugs lurking around.
If guys from my company were programming G1000 I would be extremely causious 
you should notice “frozen screen” immediately.
Actually I am absolutely staggered that avionics don’t seem to contain a watchdog.
My hobby has been electronics and my business is industrial electronics and we would never get away with a product which just froze when it crashed.
Yet for some reason the designers feel that a frozen screen is better than one which reboots itself, with the temporary loss of a GPS fix, etc.
Peter wrote:
Actually I am absolutely staggered that avionics don’t seem to contain a watchdog.
What makes you think so? I am sure they all do. A watchdog checks for a certain condition (reaction of some kind) and then pulls the virtual CAPS if the condition is not met. It doesn’t mean that it’s the only condition that can cause erroneous indications.
A fully frozen screen (hung CPU) is only one possible scenario. A pointer/needle on the LCD could be frozen or show incorrectly for many reasons. It’s a much more complex system than an analoge voltage and a coil pushing against a spring with a needle running over a scale.
I wonder, and have to research, if a typical glass cockpit (Aspen, G1000, Avidyne) can freeze WITHOUT a warning?
You think so? It would no surprise me … OTOH i think that the programming of that stuff is pretty solid and that the hardware is so simle and basic that it it is very unlikeyl to happen. OTOH yet I occasionally have an “error” when uploading new data to the MFD …
With a glass cockpit there is a very dangerous failure mode in such situations. The display of the HSI/CDI could freeze.
While anything can happen, this is not a know failure mode on the G1000 which must be the most prevalent glass cockpit in GA. A screen can fail, I guess a processor can hang but I think that would be obvious from everything stopping moving. If the LOC/GS receiver failed you would get alerted. Otherwise it is all just pixels.
achimha wrote:
I feel much more comfortable with a glass cockpit and a second independent CDI or a 2 PFD Garmin setup.
But how does a second piece of hardware help against a software bug? Given both PFDs run the same software, why shouldn’t the second PFD freeze at the same time given it has the same input data?
Peter wrote:
Actually I am absolutely staggered that avionics don’t seem to contain a watchdog.
Well, watchdogs usually ensure that the interrupt handler clearing the watchdog still runs, not that the display update process hasn’t crashed 
Flyer59 wrote:
that the hardware is so simle
Haha, you wish… According to this, the G1000 uses an XScale processor, likely designed by Intel (“Intel inside, can’t divide”) and then sold to Marvell. I don’t know which exact device is used in the G1000, but one common XScale device is the PXA270, which has an errata sheet [sorry, ‘specification update’ in Intel speak] with 100 entries. And that is just a part of the hardware.
Exactly my objections (been there and done it many times) plus if you have two Ipads displaying some approach chart, they will both crash together if the PDF is suitably corrupted.
tomjnx wrote:
But how does a second piece of hardware help against a software bug? Given both PFDs run the same software, why shouldn’t the second PFD freeze at the same time given it has the same input data?
I was comparing it to a NAV1 and NAV2 with independent receivers and displays. Like a G500 and an old CDI next to it. If you have 2 PFDs, then there is a strong argument for having different software versions.
Flyer59 wrote:
I wonder, and have to research, if a typical glass cockpit (Aspen, G1000, Avidyne) can freeze WITHOUT a warning?
A million ways for this to happen. It’s all software after all. However, the mechanical systems aren’t bulletproof either, just their failure modes are more limited in number and simpler in nature.
achimha wrote:
If you have 2 PFDs, then there is a strong argument for having different software versions.
Unfortunately, bugs in different software versions are more correlated than one might hope, even if developed by different teams. Those teams use a common specification, are probably trained by the same people, read the same books, use the same software development techniques, etc.
Oh, well :-)
My understanding is that a PFD failure is not very likely to happen. In the 6000 + fleet of Cirrus SR2xs this has happened only a couple of times. In almost (have to chek) cases it was only the backlight of the PFD that went south, meaning that the ADHRS and the autopilot would still work. And I have not heard of a case where the PFD “froze”.
Personally I have experienced these failures:
- vaccuum pump failure in IMC, low AGL after T.O. and AI turning upside down (Cessna 172 RG)
- complete electrical failure in IMC, … low AGL, just after T.O. (Cessna 172RG)
- Mechanical AI, failure in VMC (Piper Warrior)
- Mechanical TC, failure in VMC (Cirrus), CAS message but A/P stayed online (which is a feature)
