JasonC wrote:
G3000 G5000
Yep, Garmin’s been very busy ’Up Selling into the JetA1 Market .
Peter wrote:
but what does certification achieve when a €10k box ships with serious bugs which the customers discover?
As pointed out earlier, the G5 did NOT follow the “normal” certification route and is NOT TSO’d .
It was brought to the “Certified” Market via ASTM 3153-15 Standard Specification for Verification of Avionics Systems
This new & improved certification process is promising to bring a whole slew of solid-state avionics to certified acft.
Let’s just hope that the G5s teathing problems will be quickly sorted and does NOT jeopardize the “new” crt process .
Michael wrote:
Let’s just hope that the G5s teathing problems will be quickly sorted and does NOT jeopardize the “new” crt process .
It wouldn’t surprise me if they already are fixed. The “certified” software is on version 2.40, from version 2.20 apparently. The non-certified version is already on version 2.50.
The fixes from 2.20 to 2.40 include Improved attitude sensor processing
The fixes from 2.40 to 2.50 include Improved attitude data calculation
alioth wrote:
There is a difference: there are certain features only available on the non-certified version.
What exactly? They look identical to me. The software versions appear identical with the exact same fixes.
Michael wrote:
It was brought to the “Certified” Market via ASTM 3153-15 Standard Specification for Verification of Avionics SystemsThis new & improved certification process is promising to bring a whole slew of solid-state avionics to certified acft.
As usual you have to pay to read the standards, but the first few paragraphs are quoted on the ASTM web site.
1. Scope
1.1 This specification provides a process by which the intended function and compliance with safety objectives of avionics systems may be verified by system-level testing.
1.2 Software and hardware development assurance are not in the scope of this specification and this specification should not be used if a development assurance process is required
Speaking as a computer scientist, I become rather worried when reading this. It is an accepted fact in Software Engineering that you can not achieve high reliability of complex software by testing alone. You must have a software development process which addresses this from the very beginning. If you don’t have that the best you can hope for is that the system-level testing will show that the software isn’t good enough, but strong economic pressure can push a product on the market anyway. I’ve seen this happen myself at close range with bespoke software as part of the customer’s risk analysis team.
As @wigglyamp writes Garmin is sure to rapidly fix the problem exhibited by Lucius’ G5, but such a product should never have been released to the marked in the first place. What will the next bug be? Because there will be a next one, and another, and another…
You must have a software development process which addresses this from the very beginning
Well, a better alternative is to employ somebody with a beard who has been writing code for many years and who knows where the skeletons (in a piece of code) are likely to be buried, but that is not a fashionable concept anymore, especially as the normal process in bigger companies is that to get a decent pay rise you need to move to “management” and then you aren’t doing any “real work” anymore.
The complicated software QA systems which we have were developed primarily to enable teams of contractors to come up with stuff that actually does something useful, despite having been written by people with little experience and possibly zero experience of the task in hand.
Just my opinion 
But my qualification for saying this is that no customer ever found a software bug in one of my products (1978-present) despite most of the code having been written in assembler.
LeSving wrote:
What exactly? They look identical to me. The software versions appear identical with the exact same fixes.
IIRC the certified one has certain features disabled, for example, the certified G5 cannot drive an autopilot.
Peter wrote:
Well, a better alternative is to employ somebody with a beard who has been writing code for many yearsThat would be me.
and who knows where the skeletons (in a piece of code) are likely to be buried, but that is not a fashionable concept anymore, especially as the normal process in bigger companies is that to get a decent pay rise you need to move to “management” and then you aren’t doing any “real work” anymore.Obviously things are easier with few (preferably one) very talented programmer(s). But you will find that there are not that many talented programmers but lots of competent ones. Very much of the software these days are simply to large for a single person anyway.The complicated software QA systems which we have were developed primarily to enable teams of contractors to come up with stuff that actually does something useful, despite having been written by people with little experience and possibly zero experience of the task in hand.
Also, I’m not advocating “complicated software QA systems”. Far from it. My views on quality control systems are quite similar to yours. (Btw: a “software process” is not a QA system, although it may include a QA system.)
Just my opinion. But my qualification for saying this is that no customer ever found a software bug in one of my products (1978-present) despite most of the code having been written in assembler.
I take it that you wrote the code yourself? That means that you would also have made the requirements specifications and design yourself (or you could just have it all in your head). In that case it is not that difficult to get things right then but most software isn’t (and, for practical reasons, can’t be) written that way. And what was the code size for a typical product?
32k-64k bytes, and maybe on average 1 line of code per 2 bytes.
I don’t think that the majority of today’s avionics boxes are that complicated. For example the G5 could easily be a one-man job, and of course one will be “leveraging” all of one’s previous code, and Garmin will be sitting on tons of previous code.
The biggest issue in that sort of company, in the US “silicon valley” type environment where people have a high standard of living no matter what job they do, is keeping the people who wrote the previous code. Once that person leaves, fixing subtle bugs can be really hard, and for King (e.g. the subtle KFC225 issues) it is easier to pretend there is nothing wrong, especially if you sell ~ 10k replacement servos at ~2k each as a result.
Garmin support is actually very responsive on my technical issue with the G5, and my installer is working with Garmin support to fix my G5 issue.
The consensus believe is that it is an install/calibration issue, not a software issue. I believe this is to be true, unless proven wrong. Irrespective of this, Garmin support confirmed that the G5 does not monitor sensor integrity (like the G1000). They do say that the G5 does not use sensors that follow a Gauss distribution w.r.t. inaccuracies, hence Kalman filters (which assume a Gaussian distribution) are not employed to error correct sensor inaccuracies. Garmin also said that they do not use hall effect sensors, which apparently would be needed to monitor and detect impossible flight attitudes. I am not clear why a hall effect sensors (or a flux magnetometer) would be needed for monitoring.
The lack of monitoring is really the issue I don’t understand and the one possible gripe I have with the G5, not that my specific installation may not have been done exactly according to instructions.
I am interested how the G5 does work, how it works differently compared to G500, and G3X, what type of sensors it uses, what it uses to error correct the inaccuracies of the sensors. Garmin won’t tell, since requiring a Non Disclosure Agreement.
How would Hall effect sensors work? They measure magnetic field, and the earth’s magnetic field has a declination which varies all over the place. In fact, as an amusing story, I once uncovered a bug in a fluxgate/gyro related product which was made in the USA and would intermittently fail over Kent, UK. Eventually it was traced to the earth’s magnetic field declination exactly matching the aircraft bank angle and the two fluxgate voltages both fell to zero
The only way to do integrity detection in an AHRS product is to feed in GPS data or airdata and make assumptions e.g.
Garmin do the former, Avidyne (and Aspen AFAIK) do the latter which is why a bunged-up pitot on an EFD1000 equipped aircraft wipes out the box pretty well, AF447-style. Actually more than AF447 because they still had INS-derived attitude on the PFD (but didn’t know how their plane worked). We have multiple threads on this e.g. here.
These systems also sense the gravity vector (as goes my SG102 AHRS) but obviously you can’t use that for the erection (except at power-up) because in e.g. a coordinated turn it is impossible to detect where “upright” is. Sensing just the gravity vector results in an uncertified AI (so e.g. my SG102’s AI mode – described here – is uncertified) though funnily enough the 40 year old KI256 (and other vacuum AIs) is certified despite doing only that (using the pendulous vanes).
Any means of measuring the earth’s magnetic field (a fluxgate is the normal way, in a slaved compass system) would not help either because it detects only the horizontal portion of the field. It also jitters a fair bit and needs a gyro to stabilise it. Hence the traditional KG102A and KMT112.
