I have heard diverse things about this. Some people claim that running Linux on safety-critical avionics systems is a very bad idea. On the other hand some people (who are rather unfamiliar with avionics) said this is not true.
So I would like to know, do aircraft nowadays run on a Linux distribution? Is it a good idea to incorporate Linux in aircraft? If not, why?
None of the avionics systems I've worked on have used Linux or any consumer-type operating system. There are a few main issues.
First is the practical. Most safety-critical avionics involve a control loop and thus have a real-time requirement. That means it's not just important to run a process and get an answer, you need to get the answer within a tightly-controlled time constraint. Every critical software process on an aircraft is scheduled to ensure that you have a stable control loop. To do that, you need a real-time OS and Linux isn't one.
Second is the need for certification. Software used on an aircraft has to be developed to meet the appropriate development assurance level (DAL) for the associated hazard level. Safety critical systems are required to meet DAL level "A". Any OS you use has to meet the same DAL as the function running on it. These requirements are defined in RTCA DO-178C. Linux wasn't developed to this standard. There are only a few OS/software development platforms that are capable of being certified. Green Hills, Wind River, and LynxOS are the few systems I'm familiar with that meet the requirements.
There is also one other constraint in that certification requires very stringent version control. Avionics will exist in the field for many years and any changes to it have to be certified as well. Generally, there's no valid reason to update the OS on an old unit, and in many cases you couldn't without upgrading hardware (which is a bigger expense no one wants). So in updating an old unit I have to build the 'new' software to run on the whatever version of OS currently exists in the product. That could be a 15 or 20 years old (or older) platform. A rapidly evolving OS such as Linux would have a negative impact on long term product support.
The short answer is that no safety-critical avionics systems that I'm aware of use Linux, and the highest criticality systems often don't use a commercial operating system at all. However, Linux is used in other safety-critical applicaitons like the Space X Falcon 9 and medical applications. A more detailed explanation is difficult to do without going into too much depth, since the question is kind of like asking "are modern airframes made with nanomaterials?", where a detailed explanation would have to cover the pros and cons of the material, places where its use makes the most and least sense, differences in manufacturers, and an overview of what's used instead, etc. I'll try to cover all those points succinctly with links to further information.
According to this FAA report from 2001, some of the major operating systems for certified avionics were VRTX, LynxOS, PSOS, VxWorks, and Enea's OSE, although non-critical avionics sometimes use other systems like Windows NT. (Yes, LynxOS is based on Unix and Linux is considered "Unix-like", but there are many differences between the two, just like how a Linux isn't similar to the BSD-based Mac OS X). However, the most critical systems don't use a commercial OS at all. They note "With the evidence available today, in general, it can be stated that COTS products typically do not meet the requirements for level A criticality software." In layman's terms, that means most avionics developed with third-party software, from VxWorks to Linux, weren't being tested and analyzed enough to be put in something critical like a landing system, TCAS unit, or critical display unit. That's likely changed in the 10+ years since the report was written, however. Here's a more recent article on real-time operating system usage in avionics.
An important concept here is a real-time operating system, or RTOS. A RTOS in a nutshell provides guarantees that software won't run out of scheduled computing time, messages between parts of the software are passed in a small amount of time, memory won't run out, and other important tasks are guaranteed instead of working well under normal conditions then breaking under unusual conditions. Normal operating systems can't make such guarantees. These guarantees, or acceptable substitutes, are required for certification of most avionics.
Another important concept is the difference between in-house and commerical off-the-shelf (COTS) systems. Commercial off-the-shelf systems are publicly available and are not customized much for each manufacturer. This article provides a good summary of pro's and cons of commercial and in-house operating systems. Many high-criticality avionics still have the core software developed in-house due to the advantages involved.
Yes, Linux is not "FAA certified" but actually no RTOS is "FAA certified" or "meets DO-178C". DO-178C provides objectives that the avionics system engineers have to fulfill in order to certify their whole avionics software (the objectives cover audits, testing, safety analysis, and requirement writing, among other things). So the best the OS supplier can do is provide "DO-178C ready" software or follow DO-178C guidelines. Note that DO-178C recognizes various safety levels, so what's certifiable under DO-178C for a maintenance system may not be certifiable under DO-178C for a critical display unit. The problem with Linux isn't that Linux isn't "certified under DO-178C", it's that it's difficult to certify due to challenges noted below. It's possible to certify a system using Linux, but doing so could be prohibitively difficult due to the extra analysis, safety measures, and documentation that would be needed, especially for the most critical avionics. Some of these challenges and alternate methods of compliance are outlined in this FAA report.
There are advantages to using Linux, which are partly shared with other commercial systems. More employees will already have expertise with Linux, and the OS was designed with more expertise and time than most organizations have available. Commercial systems also have a much lower sticker price than in-house software. Commercial systems are also more adaptable and allow changes to hardware and room for future growth without going back to the drawing board. Tooling to work with the software is more developed, and they may also have a longer service history that provides confidence in the software.
Here are some of the issues Linux faces in an avionics system when competing with a RTOS, from this FAA report:
partitioning: If two programs are supposed to be running independently, there needs to be evidence that one program can't interfere with another through shared memory structure, caches, board support and firmware, errors, interrupts, etc.
worst case execution time: In desktop computing it's ok if I bog down my PC with too many requests or unusual conditions at once and the system slows down or skips some program steps. In avionics this is not acceptable for obvious reasons. The supplier would need to verify this either through models of the CPU, memory, etc. or rigorous lab tests and timing analysis. Both are more difficult the more complex your hardware and software is.
MCDC coverage: Tests on the most critical avionics (Level A) requires running enough lines of code and decision conditions to reach the MCDC code coverage standard, which falls between "run every line of code" and exhaustive tests of every combination of conditions. Some operating systems like Linux can be extremely difficult to test thoroughly enough to meet this standard.
documentation: Rigorous analysis and stress test requires a lot of documentation on inner workings of the OS
security considerations: Because of its large size, Linux has more security problems than a lean, in-house application. These security issues are becoming increasingly important, especially in the military
dead and unreachable code: Carefully disabling the many unused functions of Linux and guaranteeing they can't interfere in your software is usually required for certification
What about similar safety-critical industries? The Space X Falcon does use Linux in some of its flight computers (sources). Based on this interview, Space X seems to prioritize future growth, availability, short cycle times, and expertise over the simplicity and robustness of in-house development in this area. Note that the flight control computers on the Space X Falcon aren't directly analogous to an LRU in typical modern avionics, so extra work or an unusual architecture would likely be required to get Linux to work for typical avionics applications.
Linux is also used in many safety-critical medical applications, but not without problems similar to those faced in aviation. I'd recommend reading Wind River's "Choosing Linux for Medical Devices", or this article on the disadvantages of Linux in safety-critical medical applications.
I'm assuming you're talking about the principal avionics like flight guidance, autopilot, fly-by-wire, or displays. Other airplane systems could loosely be considered to be safety-critical but aren't typical examples of safety-critical devices, like certified electronic flight bags, connectivity solutions, and maintenance software. These are sometimes better suited for a Linux application due to high complexity and less rigorous safety considerations.
Note that I'm not an expert in this field and my advice does not replace the advice of a certification specialist.
To clarify some misconceptions about Linux which run across many of the answers given.
Linux is NOT a "commercial" OS. It is free for anybody to download and hack about as they please. (Some companies package it up with a load of apps as a distribution or "distro" and do charge for supporting the package).
Linux is NOT a monolithic build with loads of extraneous functions. The Linux kernel core is lean and mean enough to be installed on smartwatches and many other embedded devices. The frills are supplied by a multitude of optional kernel modules. When you build your Linux kernel for installation, you choose which modules you want, and whether you want them rolled into a single blob with the core (fast) or hung around it as separate blobs (operationally flexible).
Linux is NOT a "userland" OS. For that you have to add an interface layer such as GNU or Android. It is used extensively in embedded applications, where the company engineers have done the stuff described above.
Linux is no more insecure than any other OS. Indeed, many regard it as among the most secure. It is the userland bit where distros like Android go horribly wrong, while another rash of recent exploits focused on hardware design flaws.
Linux can be as stable and supportable as you want it to be. An avionics OS company can happily support a given kernel build for twenty years and more, and simply ignore the relentless stream of advances unless and until they need to tap it for an upgrade or a new product. A given tweak may often be "backported" to your old build so you don't need to deal with the full upgrade.
Linux has various real-time tweaks available if you want to use them. Possibly none are fully satisfactory for core flight control, but the open licensing means there is nothing in principle to stop you rolling up your sleeves and tweaking it yourself. You can then feed your code back into the Linux source tree and others may then use and further improve it.
Having said all that, it is a lot of work to customise Linux for your given hardware/software regime and the open licensing makes it difficult to charge heavy royalties. Specialist software houses therefore find it equally difficult to build a living off that, so unless an avionics house wants the expense of customising its own OS, it will find only commercially licensed offerings available from the specialists.
This last is the main reason why Linux seldom if ever appears in avionics, and why all the other issues don't get addressed.
On the other hand, if you include consumer and low-end commercial drones, Linux is already popular if not dominant. There is no doubt that over the coming years it will be working its way steadily up the food chain.
Seems that pilots now at least sometimes use tablets for checklists.
If these tablets are Android devices (majority of them), then they run Linux kernel. Android uses less of standard Linux stack but it still uses Linux kernel. Checklists are safety critical, I think. Apple and Windows tablets use different kernels, not Linux.
There are many checklist apps for Android devices. I assume somebody uses them.
Kernel is the core of a computer's operating system that keeps complete control over all other parts. Like wiring for an airliner.
There really isn't a need to have a commercial OS on avionics.
Avionics software tends to be designed for specific hardware - there is no generic hardware platform made in a mass market by a lot of vendors.
Avionics don't interact with a lot of other systems or hardware.
Avionics usually run as one application, so no need for timesharing or in the case of RTOS a guaranteed clock cycle schedule.
Those are the main purposes of an operating system as opposed to a simple bootstrap loader that loads up and starts one application - the operating system facilitates multiple hardware platforms, multiple drivers and utilities for disc/flash storage, timesharing with other applications, and peripheral devices such as networking. What avionics need to do: interact with the display, external sensors, and control buttons - don't have to involve an operating system.
An embedded OS is nice to have for a dedicated device, especially if the embedded application is going to publish web services for external access and control. However, it is slower to load (could be a factor for avionics) and consumes more resources than a dedicated app that is fired up by a bootstrap loader.
Due to the extensive certification cycle, avionics don't tend to run the latest and greatest, nor do they have a short refresh cycle on the hardware.
none of the arguments exchanged in here is completely wrong, but i would wish some participants would apply a little more effort in balancing their arguments.
The real buzz-words for aviation are real time and safety.
Of cause, in aviation safety comes first and if you need something to happen, most of the time it has to happen immediately and something has to prove to the pilot that the job is done.
Before you can certify something, you have to verify and validate it - that can be a pain in the neck. And thats why most people dont like that.
Linux is not too complex to be tested and used in aviation - but the desktop flavour is. Linux in its software-design is quite well suited for use in aviation, like most Posix conforming software. Linux's beauty is that every component is designed to do exactly one job and this to its best (in contrast to Windows). For aviation you would never use a complex, bleeding edge software like for a desktop. You would only implement and test the elements you really need. And there are real-time implementations of POSIX-like systems like QNX for example - and there software architecture is very much like Linux.
The real time perspective: Once Microsoft lost a competion at a steel manufacturers site because they couldn't explain how to handle a 50ton steel bar, moving at 6m/s with a software which reacts with a latency of 500msec. At this point in time the bar might have punctured the next wall by 3m or so...
This simple fact is even more true for aviation.
Another argument is that aviation industry is conservative - most things which fly best are more then 10, often 40 years old.
And in this field it is often believed you cannot earn money with open source software - which is not true. So many proprietary (and reliable) instruments are running on software from the nineties, i.e. many cash machines are still running on Windows NT derivatives. Want to say: many instrument manufacturers are not willing to publish the source code of their well maintained software.
On the other hand: if Boeing had used open source software for their 737MAX, there is a certain probability, that the accidents wouldn't have happened.
And well, there you are: its all about testing in an acceptable amount of time.
No, more testing and even more testing.... And then you might end up with aviation-suitable software. And for this, a real-time derivative of a POSIX software, would be a good if not even the ideal choice.
Is Linux used for safety critical applications? No. Yes. Perhaps. Bear with me...
The USS Zumwalt uses Linux for its extensive data requirements, and LynxOS for embedded hard real-time applications, described in this article.
Standard laptop Linux is a user space Operating System: it waits until a user clicks a mouse, hits a key, or generates an output, and then takes action. There may or may not be many programs open. User input is a statistical event as far as the O/S is concerned: it may or may not happen in the next minute.
Contrast that with a digital control loop. It runs on a processor and uses memory, just standard computer hardware. But they differ from desktop software in that they:
The software needs to read inputs and generate outputs, every iteration, and an iteration frame runs for a fixed amount of time. A hard real time system is a system where timed responses must be deterministic: whatever it does must be finished within one software iteration. If the control loop runs at 100 Hz, an iteration cycle takes 10 msec, and the hardware needs to be fast enough to guarantee that the whole process can finish within time, every time.
These control loops are generally not huge, and generally don't have a number of windows open between 1 and 100. Small and fast programs and a limited number of windows, that is how O/Ses for safety critical programs and real-time loops are made for. Which is great, in the olden days there did not use to be an O/S for this and code had to be written in assembler or worse. I/O calls were hardware specific and therefore not portable from one chipset to another.
This is where the real-time O/Ses such as VxWorks, LynxOS and a few others come in. They are Unix based, POSIX compatible O/Ses. The hardware layer is made invisible for the programmer, who has a set of development tools for using high level computer languages with standard I/O calls and timing routines. They are scalable: you can start with an O/S that just boots and then immediately runs your cross-compiled binary at a rate set at the timer interface. Or you can re-configure the kernel and include a couple of user interrupts that look at keyboards or RS-232 data coming in, all up to the programmer, who also has an extensive tool kit for timing and I/O.
VxWorks can be expensive (but is well supported), and there are now some open source alternatives available based on the linux kernel such as Xenomai, RTLinux, and Xilinx. Some of these attempt to have all services available for desktop applications and only have an interrupt timer that does its best to keep the task running evenly, even if a word processor starts a spelling check. Others are scalable hard time, just like VxWorks, but are open source and support may be a challenge. As far as I know they have not been to Mars yet, VxWorks has.
Can it be used for safety critical avionics: yes, if scalable hard real time, and tested according to the standards applicable for all avionics. As far as I now there is nothing yet on board of aircraft, but that may just be a matter of time.
