This thread picks up from here
AdamFrisch wrote:
They know they have a problem and that the onerous certification process has killed development.
… and I would like to add that certification for avionics based on software has shown to even be a safety hazard. I rather prefer frequent software updates instead of not getting a fix for a year due to the certification process that let a bug slip through in the first place.
It’s not a perfect process however.
Loads of updates break something. I would never upgrade any critical program which works, without extensive testing.
And how do you test avionics software? Not by flying 50hrs a year. Not even by flying 1000hrs a year. One needs a very complete test process.
The only practical way (for me) is to update everything asap – Macs, iPhones, iPad, Avionics, … and very rarely there’s a problem. And if, then the next update will fix it. The most critical bug i had was that my BT GPS wouldn’t work for two weeks after an iOS update … so what. I just used the interna GPS (and found out that it’s good enough anyway …)
That’s fine for consumer electronics and flying in VMC.
I guess the trick is simply redundancy and knowing how to use it. Over all devices I carry about 6 GPS receivers, for example.
Peter wrote:
One needs a very complete test process.
That might be possible for a 1980s printer spooler, for todays complexity of products it’s not possible to come up with a test plan that has (close to) 100% coverage.
So the key is to design the systems in a way that a piece of software can occasionally fail, just like any piece of hardware can occasionally fail.
In your cockpit, that doesn’t seem to be an issue at all. If the KLN94 fails, tough cookies, you still have VOR, DME, radar vectors (on the continent, at least).
If the Sandel fails, you still have all indications elsewhere.
It’s a bigger issue in fully integrated avionics, where, if the PFD/MFD firmware acts up, it’s very likely down to handflying with the backup instruments with no (certified) navigation and no way to change the radio frequency… You better have a phone with GNSS receiver with you, then 
Stephan_Schwab wrote:
I guess the trick is simply redundancy and knowing how to use it.
Exactly.
Redundancy and auto updates at the same time? 
Anyway, you have worked out why I have the avionics I have…
You must develop a test suite – same as chip makers develop test vectors. This cannot test everything but helps to ensure that an update doesn’t break something else.
@ Peter ;-)
That’s actually not what i mean. I mean that i always update all my IFR avionics, iPads etc. and that i fly IFR and in IMC with it. And that i never have serious problems with it
tomjnx wrote:
It’s a bigger issue in fully integrated avionics, where, if the PFD/MFD firmware acts up,
Exactly right! That is why I prefer the Aspen solution (or any one which leaves enough backup) over a G1000 any time, especcially if there are two full AHARS involved. Makes the failure of one a non event.
For night flying I did get myself a Dynon ADI, which could well work as a backup ADI and is better visible in case of total darkness than the old vaccum one. They sit next to each other and can be seen well.
In a Avidyne Entegra glass cockpit the PFD and the MFD do not work on “one firmware”, they are two systems that are also updated individually.
