Menu Sign In Contact FAQ
Banner
Welcome to our forums

Avionics certification

This reminds me the new instruments from Mid-Continent. They have certified a general hardware platform. The idea is to easily create “any” kind of instrument using software. The only thing to certify is the software, which is a much faster and cheaper than hardware. They think this will be particularly useful for upgrading old panels.



The elephant is the circulation
ENVA ENOP ENMO, Norway

LeSving wrote:

[certification of software] which is a much faster and cheaper than hardware

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.

Andreas IOM

He talks about 90 days. Hardware is typically 1-2 years. As far as I understood from the interview it was mostly about understanding how to be efficient in software development when the aim is certification. They also mentioned this was unheard of 2 years ago. I have no idea what he means in detail, but it looks like designing an aircraft and later on going for certification vs designing an aircraft from the start with certification as the main aim.

The elephant is the circulation
ENVA ENOP ENMO, Norway

alioth wrote:

LeSving wrote: [certification of software] which is a much faster and cheaper than hardware

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.

alioth, I think the challenge here is that if you have a new hardware product, then you design & certify hardware, PLUS you design and certify software.
If you have a universal platform that can be feed with different sensors (some of them could have already been certified by the 3rd party), and
you have a system software designed and certified, including all the basic input/output functions, then you just design a new type of container, so to speak,
which should be much quicker. You know, at least the RTOS & the h/w (with all the environmentals) are already there.

EGTR

arj1 wrote:

alioth, I think the challenge here is that if you have a new hardware product, then you design & certify hardware, PLUS you design and certify software.

Oh for sure, if you have one platform you can re-use over and over again, I see how it saves time. But LeSving was saying it was 2 years to certify a piece of hardware but only 6 months for the software…but the software is actually likely to be the more complex (and problematic!) part. 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! (Perhaps they are hardware people who go over the hardware with a fine tooth comb because they understand it, but think the software is the “easy, reliable” bit? :-))

Andreas IOM

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.

Last Edited by Airborne_Again at 05 Apr 14:43
ESKC (Uppsala/Sundbro), Sweden

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.

Administrator
Shoreham EGKA, United Kingdom

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?

Germany

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…

Administrator
Shoreham EGKA, United Kingdom

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.

Last Edited by alioth at 07 Apr 10:34
Andreas IOM
15 Posts
Sign in to add your message

Back to Top