Cobalt wrote:
(SR22 running out of electricity after alternator failure in Switzerland, for example),
If I remember the same case than you, that one was a gross example of a pilot out of his debth. He was on a flight from Geneva to Berlin and lost a generator. He decided to divert to Zürich. There was never and load reduction done as the checklist would have told him to do. During the approach he eventually lost the MFD and the GNS 2 as well as the flaps and manual electical trim. He still had the PFD, the autopilot fully functional including autotrim and GNS1. The pilot however did no longer trust the indications of the ILS as it was not set up properly and was unable to follow the ILS, even though he could even have flown the approach automatically he flew manually and very erratic. He somehow managed to get under the cloud cover but found that he was too much off the centerline of runway 14 to land. Consequently he overflew runway 16, turned sharply and flew back opposite on 34 at very low altitude. He could easily have landed on any of the 3 runways at that stage, but decided to fly visually up to the end of 34 and then do a sharp right turn to land on 14. The tower instructed an A340 on approach to 14 to go around. During the sharp turn, he lost control and crashed into the approach lights 14. One of my colleagues watched him fly from the direction of the airport past her window and saw them crash and rised the alarm.
This accident really happened due to a pilot totally incapable of dealing with a malfunction in his airplane. The emergency, if you can call it that, should have been over at latest when he had the airport clearly in sight. He had 3 huge runways to land on, yet he erratically flew over the airport to make his originally assigned runway but crashed doing so, killing himself and 2 passengers. A 3rd passenger survived badly hurt. Yes, there were other factors involved but the bottom line was that he had more than enough instrumentation to complete this flight.
This was not a problem of a failed EFIS, the aircraft retained more than enough to complete the flight safely. It was the result of sheer incompetence and panik.
any idea when Photo #3 might have been taken?
Photo 3 was Mali Losinj LDLO.
That was not quite his last ever flight – the crash was 2 days later.
Very sad. I better stop taking photos of planes!
Very sad indeed, but thanks for the info.
USFlyer wrote:
See what? An AHRS failure is not software, it’s hardware.
What do you mean? An AHRS is a computer with sensors. Of course it is both software and hardware!
The attitude and heading information on the PFD was replaced by red crosses. Perhaps 15-30 seconds later, the message “AHRS initializing” appeared and after about a minute both the attitude and heading was back.
The avionics shop found that this was a known error in the G1000 software version we had.
So how could it not be “Software fails in glass panels”, which you said you have never heard of. Well, you have now!
Software does fail in glass cockpits as the whole smack runs on software. The vendors have a bit of a better situation than Microsoft with the zillions of different interpretations by all the hardware vendors of the specs because they control the hardware themselves. It’s similar with Apple making their own hardware to have better a better software experience for the users. It has some merit but doesn’t prevent you from shipping bugs completely. But then, if you do ship bugs, you can also fix them. In the other case there may be nothing you can do as the software buy because of out of spec hardware components.
The more integrated your glass cockpit is, the more important it may be to have backups from a different vendor with different hardware and different software.
However, “different” may not be different at all. For example, all software may use the same open source library or bought closed source library. The issue may originate there and might show up in all systems.
It is very, very hard to get to five 9s in reliability. In the end it seems smarter to be able to deal with failures and focus on that instead of making THE one and only system “perfect”.
I’m perfectly happy to fly manually on radar vectors or to navigate to the next waypoint with the help of iPad or GPS equipped phone. As long as there is fuel left, there is likely a positive solution to most avionics issues.
Speaking about that: when my Avidyne R9 packed up due to the EGNOS issue and I also lost the fuel totalizer, I simply asked ATC for vectors to the nearest field. My biggest worry was the unclear fuel status. So I landed and 30 minutes continued – mostly in IMC – to my destination. I do expect the stuff to fail and since that keep a paper log of my fuel status with every tank switch. Now that I learned more I’m pretty calm about it.
In a typical Cirrus even if the whole glasscockpit fails you will have at least one or two GNS430s for navigation. In most cases you will also have the autopilot.
If you don’t have that, for example after a total electrical failure (both alternators and batteries) … you have three backup instruments, AI, Altimeter and Speed. Any pilot should be able to fly on those.
You can easily navigate with your iPad or iPhone (even an Android phone should do :-))
That’s much more than any previous generation of IFR pilots had.
And finally, in the Cirrus, you’d still have CAPS. (no discussion of the parachute necessary here :-))
AHRS consist of magnetometers, microelectromechanical systems (MEMS) accelerometers, and MEMS gyroscopes on all three axes. They are no CPU based, have no RAM or disk…they are not software driven.
The G1000 panels are CPU base but the firmware in them is a decade old. When you do your monthly updates you are not changing the basic operating system or the firmware you are updating sectionals, plates and other reference material than changes on a monthly basis.
These systems are not IOS or Windows based systems. They are embedded…they do not get a ‘software crash.’
Are you implying embedded software, aka firmware, never contains bugs?
And BTW we DID hear of certain avionics basing on embedded Windows, didn’t we? I’ll bet you a good deal more are based on embedded Linux.
USFlyer wrote:
These systems are not IOS or Windows based systems. They are embedded…they do not get a ‘software crash.’
… there is a lot of off-the-shelf embedded operating systems and real-time operating systems.
Manufactures don’t write their basic OS from scratch anymore – at least that’s what I assume by looking at what is available.
I know that my Avidyne R9 is based on Windows NT Embedded and I don’t have an issue with that. NT on good hardware has always been quite reliable.
Aren’t we getting a bit off-topic for this thread with all that software talk …
USFlyer wrote:
AHRS consist of magnetometers, microelectromechanical systems (MEMS) accelerometers, and MEMS gyroscopes on all three axes. They are no CPU based, have no RAM or disk…they are not software driven.
The G1000 panels are CPU base but the firmware in them is a decade old. When you do your monthly updates you are not changing the basic operating system or the firmware you are updating sectionals, plates and other reference material than changes on a monthly basis.
I am very aware of that. How is that relevant to the discussion?
These systems are not IOS or Windows based systems. They are embedded…they do not get a ‘software crash.’
Are you saying that embedded systems can not get software crashes? I think any further discussion is pointless.
