Are the new systems of today built with the same CPUs and programming languages and development software as those of 20 or more years ago?

By new I mean that these systems are currently being designed for future airliners, or have seen service for the first time recently.

Any specific examples of new designs as used in a major latest-generation airliner (the A350 and 787 be the most obvious examples) would be better than general answers.

I'm interested in examples from any flight-essential systems (but not, for example, on-board entertainment).

As part of this question: does the industry tend to update its products through incremental updates to the microprocessors and programming languages it adopts, or does it tend to make once-in-a-generation shifts to new technologies? And, are there significant differences in the way airline manufacturers (as opposed to military/general aviation industries) approach this?


2 Answers 2


Note: I focused more on changes in aviation hardware and software than what's currently used since the question linked about programming languages is still current for "new" aircraft. I do not wish to duplicate that question or its answers. In my opinion C++, C#, and Ada will probably be the dominant programming languages for avionics for the next decade at least.

First, you've got to understand the life cycle of aircraft. Many aircraft are in service for more than 30 years. The avionics do get updates (whether adding new features, fixing bugs, or adding in compliance to meet mandates). However, the bulk of the work is done during initial development of the software and hardware. The configuration is then mostly fixed until that generation of avionics is replaced by the manufacturer or retrofitted by another manufacturer.

So What's Changed in Practice?

If the avionics goes through a generational update (like CRT's to LCD screens), anything changed has to be worth the cost, so usually not much is changed. Maybe the CPU, but definitely not the programming language. For example, the G1000 was out for 12 years before releasing another generation of hardware (although in the meantime they published numerous software updates for hardware compatibility and synthetic vision and such).

Similarly, Avidyne Entegra was out for five years and continuously adding major features like data link weather and LPV approach before it finally upgraded the hardware in release 9 in 2009. Falcon jets like the Falcon 900 had a software and hardware update to their avionics in 2011, but that upgrade was based on Primus Epic family of hardware and software, whose first generation was already 9 years old. I believe all the 900's were still running the old 1996 hardware before the 2011 upgrade. On the other end of the spectrum from these slow upgrades, the military's JSF system is designed to be upgraded easily every few years (but they don't say just how often).

Why Not Make More Frequent Upgrades?

What drives value in avionics isn't usually exotic new features and definitely not computing performance. Value is driven by reliability, compliance to mandates, and safety-compliance. This requires features that are simple enough for the engineer and the pilot to understand and are robust enough to have hundreds of lives depend on it. So the new features being added generally require little extra performance, and there's little incentive for cutting-edge technology or the latest programming paradigms like cloud computing, machine learning, or object orientation.

An engineer at Rockwell Collins stated something that applies to all avionics "In the past, we struggled to fit everything we needed to do into the size of processor and speeds we had and how to get all those bits over the interfaces we had. With the processors we have now and fiber interfaces, that is no longer a concern... Now the problem is how to manage and design good, trouble-free software and test all the lines of code involved. So now that we have all the processing and bandwidth we need, we have to make sure we can use it and not design ourselves into a corner."

Verification is one of the biggest driving factors (and costs) in processor and programming language usage. All hardware and software must have a safety level attached to it, with the most critical functions (like avionics for autoland) considered "Level A" meaning such a failure of the avionics could be catastrophic. In order to achieve the stringent safety requirements for Level A software (which is often one such failure per 10^9 flight hours), the software and hardware need to be exhaustively tested to ensure nothing will ever go wrong. That includes covering every condition on every line of code. Most tools developed to work with your programming language and software architecture needs to be formally verified (usually called "qualified") as well. On top of that all, costly flight testing needs to be done to evaluate any changes. This creates a lot of inertia and means a complete overhaul of an existing product or starting from scratch for a new product just to get a "faster system" is often not cost-effective.

What about support for new CPU features?

Virtualization (allowing different OS's to act like they're running by themselves but are actually running with a layer between themselves and the bare hardware) and multi-core processing is now supported by some real-time OS's for commercial off-the-shelf processors. These have to follow the standards in DO-332 and other materials. According to my 2013 text, this is still in the investigatory phase and no avionics with these features have been certified. The main issue is that multi-core processors don't just have more features, but they have more features that are not comprehensively documented or testable. For more information on issues with use of multi-core see the FAA's CAST 32 and this presentation.

  • 4
    $\begingroup$ "Virtualization (where different processes each act like they're running by themselves but are actually running on a virtual machine)"... hum, the definition I have for virtualization is: CPU, memory, storage, I/O, and network seem to be exclusively owned and used by an OS, while actually multiple OS instances run on the same resources that a virtualizer is sharing between them. The virtualization can be by hardware, or by software. $\endgroup$
    – mins
    Jun 9, 2016 at 20:37
  • $\begingroup$ Thanks @CodyP for this detailed and informative reply to the question. There are many matters here that deserve closer scrutiny, but two that stand out: 1) multi-core processors [have] features that are not comprehensively documented or testable - in other words future generations of CPU may turn out to be essentially unsuitable for critical aerospace applications! 2) there may come a time when the microprocessing hardware that these very conservative systems are built around simply becomes unavailable - will that perhaps be a trigger for from-scratch software/hardware redevelopment? $\endgroup$ Jun 9, 2016 at 21:29
  • $\begingroup$ @mins Thanks for the catch! $\endgroup$
    – Cody P
    Jun 9, 2016 at 21:34
  • $\begingroup$ Comprehensively documented or testable means there are internal hidden variables, and features that aren't fully described. It will probably eventually be worth the extra verification difficulty to use multi-core CPU's. Worst case scenario you can turn a core off. However don't forget that 1) We're talking about embedded processors, not desktop or mobile processors, so it's a different market and so you'll see different processors being used 2)Even the consumer electronics market alone is very diverse. After all, Apple is still putting Apple dual-core processors in iPads. $\endgroup$
    – Cody P
    Jun 9, 2016 at 22:05
  • 2
    $\begingroup$ For virtualization, a major concern is that the more things you run on one machine, the more you're giving yourself a "Single point of failure". When something breaks on an airplane, we like redundancy and system independence: the fewer things that break when something else breaks, the better! $\endgroup$
    – Jon Story
    Jun 9, 2016 at 23:26

Many factors go into selecting the programming language and the processor for each product, some of which are:

  • General purpose of the software system
  • Selected Design Assurance Level (A-E)
  • Hardware constraints of the product
  • Company experience with a language
  • Available development tools
  • Available verification tools

I believe the most common languages used in aviation safety critical systems are C and Ada, with C++ gaining more usage in the last 10 or 15 years.

Processors can range from simple 8 bit SO8 micros to PowerPC to multicore x86 or ARM System on Chips. Electronic Hardware such as PLDs and FPGAs are also becoming popular for certain work loads.

  • 1
    $\begingroup$ Welcome to Aviation.SE! Your answer could do with a bit more detail on what has changed to fully answer the question but is a good start. Many answers are edited and built up / improved over a period of time to add more detail. $\endgroup$ Oct 26, 2016 at 15:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.