Are there any requirements for avionics sold to the non-certified airframe market – assuming the item doesn’t fall under any of these
So much depends on the detail of what the product does. I don’t know anybody who knows the details but it may well be, for example, that a fuel totaliser needs no software QA at all.
That instrument in the OP is either a toy or a demo, or (cabin differential pressure!) is really critical.
I personally think MCI’s is the wrong approach.
They should have pre-certified, pre-priced base configurations that only need field-configuration of parameter labelling, warning and thresholds levels upon installation.
Everything else is an unsurmountable barrier for anything other than airframe OEM or multiple-SN’s approval.
The typical customer will want it configured for his single aircraft not for his fleet of 20 aircraft, and he will want a clear price and timeline.
Do not underestimate the complexity of software compliance demonstration: there are too many process uncertainties (mostly human+organizational interface) in such approval, hence the “buying UPS-SAT” was going for a known path rather than reinventing the wheel…sensible!
the Garmin transponder (GTX345) which would crash when it got 0 degrees for tracking north (exactly as the ARINC specification says it should – heading is 0 – 359, but the GTX345 wanted 1-360).
Label 320 is actually 0 to (just under) +180 and 0 to (just under) -180, with the LSB being 0.00549316 of a degree. A conversion has to be done between this and 0 to 360 and having spent some time on this it is easy to get it wrong if one is not careful. I am actually limiting the value emitted on ARINC429 to 1 LSB below 180, so label 320 will only ever get within 0.00549316 degree of 180, and pretty obviously nobody will tell the difference, but it may well prevent something downstream blowing up due to a bug. Zero itself should work fine – unless they did it totally wrong.
It took months for Garmin to even acknowledge the problem, which was easily demostrated, let alone issue a fix! And the certification authorities basically ignored it instead of withdrawing the transponder’s certification.
Garmin have in-house certification. They bought UPSAT for their ODA. I don’t know how much the FAA gets involved. But for sure nobody checks anybody’s code.
alioth wrote:
It took months for Garmin to even acknowledge the problem, which was easily demostrated, let alone issue a fix! And the certification authorities basically ignored it instead of withdrawing the transponder’s certification.
This shows it’s not that hard to get software certified. Besides, why should certification of software be such a big deal? It’s only about documenting adherence to a standard. 99% of such documentation can be re-used, and just about everything can be handled in-house, once the core development platform, procedures and testing is set. For hardware it’s a very different concept, since there is no way of producing something without additional suppliers.
Peter wrote:
You cannot completely eliminate the possibility of duff data coming out of one instrument crashing another instrument
Let’s not forget about the Garmin transponder (GTX345) which would crash when it got 0 degrees for tracking north (exactly as the ARINC specification says it should – heading is 0 – 359, but the GTX345 wanted 1-360). It took months for Garmin to even acknowledge the problem, which was easily demostrated, let alone issue a fix! And the certification authorities basically ignored it instead of withdrawing the transponder’s certification.
You cannot completely eliminate the possibility of duff data coming out of one instrument crashing another instrument – certified or not.
Even more so if you can’t get hold of the other item physically for bench testing. One example here. And funnily enough, I am building something which uses a widely used GPS module whose firmware was also tested only with WAAS SBAS, not EGNOS, and found some funny stuff…
alioth wrote:
Which is odd, because the software is often a lot more complex (and error-prone!). As a software developer I’m extremely surprised that software gets an easy ride in certification
If the “hardware” (and the platform the “software” runs on) is defined in the right way, it is extremely unlikely (don’t like to use the word impossible) to create a faulty software that has negative impact on other devices – therefore one very important part of certification only has to be done in certification of the “hardware” (using """ as I’d assume that technically spoken MC did not only certify the actual hardware3 but also some kind of software platform that has the actual applications then run I some type of sandbox).
If this MC platform is designed and certified that way, for all non essential instrument they would actually hardly need any additional software certification at all because the worst thing that can happen is that the device fails but does not negatively influence other (essential) instruments.
For which essential instruments is the software actually already certified?
I have heard all kinds of funny stories from this line of work.
One of them, from an ex Honeywell/King autopilot guy, is that they used just one function per file – because the FAA would require a lot of work each time a file was edited, so obviously by doing this otherwise rather inconvenient stunt they made their lives easier. It made the code hard to read…
The certification process also forces the manufacturer to conceal problems and generally lie through their teeth about bugs. They tend to admit to bugs only when they have been revealed elsewhere in a way which cannot be suppressed. If possible, they fix bugs under the cover of an innocuous-sounding fix for something else (all software companies do that).
Re the OP, it must be somewhat easier to certify a new product if it uses identical hardware to an existing certified one, but the extent must depend on the details, and on the function which the instrument is performing. So e.g. an autopilot certified down to 200ft is going to be tougher than a CO2 detector. Actually the CO2 detector TSO may be just environmental compliance, no software QA.
alioth wrote:
I have to wonder wether certification involves the certifyers doing a full source code review – if it’s only 6 months compared to 2 years for hardware, then I suspect not!
AFAIU, software certification does not concern itself the with the actual software, but with the software development process. Actually, there’s some sense in that as high reliability software is impossible to achieve after the fact by debugging. You have to use the right design process from the start.
