23
$\begingroup$

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?

$\endgroup$
  • 19
    $\begingroup$ They likely run on propriety real time operating systems. Linux is a pretty unlikely choice, as it is complex, not real-time, and quite likely to have flaws due to complexity. $\endgroup$ – user9394 Apr 4 '17 at 1:15
  • 13
    $\begingroup$ Safety critical avionics are usually single purpose. They probably don't even run an OS in the normal sense. $\endgroup$ – DJClayworth Apr 4 '17 at 1:27
  • 21
    $\begingroup$ Ex-avionics engineer. The only place you will find off-the-shelf operating systems is in some in-flight-entertainment systems (e.g. some use Android or Windows CE). Even then, most of the big suppliers use their own custom platforms. The safety critical stuff only runs on proprietary, single purpose OSes. Linux, Windows and so on are not designed for purpose and just too buggy for avionics use. The people saying it's a bad idea are not pretending, it's true. $\endgroup$ – Simon Apr 4 '17 at 11:18
  • 28
    $\begingroup$ you don't prove that is too buggy, you assume everything is buggy, and if you really really want to use something, you prove it is NOT buggy. $\endgroup$ – Federico Apr 4 '17 at 13:31
  • 9
    $\begingroup$ @traducerad Certifying a Linux kernel for use in avionics would be an incredibly complex task that would cost more than simply using an RTOS that is specifically designed, documented, and tested with DO-178 in mind. $\endgroup$ – selectstriker2 Apr 4 '17 at 13:52
40
$\begingroup$

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.

$\endgroup$
  • 3
    $\begingroup$ This might be stupid but... Linux has a real-time patch. What do you think about that? Would that make your first point invalid? $\endgroup$ – traducerad Apr 4 '17 at 13:15
  • 9
    $\begingroup$ @traducerad, As far as I know, the RTLinux patch/project is aimed at a different target, like audio processing or some high performance computing: you don't get a truly real-time operating system (like Integrity, for instance). $\endgroup$ – Marco Sanfilippo Apr 4 '17 at 13:30
  • 2
    $\begingroup$ The reason Linux wouldn't be used is because of the certification burden placed on any software running safety critical functions on a type certified aircraft. Now not all software has to meet DAL A, the software has to meet the highest criticality level for the function that it performs. $\endgroup$ – selectstriker2 Apr 4 '17 at 13:48
  • 6
    $\begingroup$ Also, Linux would be brutal overkill for that kind of systems. Each component only runs a rather narrowly defined function, so the operating system can be much simpler (which makes it easier to certify too). $\endgroup$ – Jan Hudec Apr 4 '17 at 19:43
  • 3
    $\begingroup$ Wind River makes VxWorks. $\endgroup$ – Koyovis Aug 29 '17 at 21:01
29
$\begingroup$

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.

What do RTOS and COTS mean?

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.

Does Linux meet certification requirements?

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.

Advantages and disadvantages of Linux

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: Linux by design 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

Other safety-critical industries

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.

$\endgroup$
  • 3
    $\begingroup$ Very good and thorough answer. I'd also point out that a majority of avionics dont use an RTOS at all, preferring to execute on the processor directly. $\endgroup$ – selectstriker2 Apr 9 '17 at 4:07
  • $\begingroup$ I have to take issue with your statement that "LynxOS is based on Unix, just like Linux". Linux is "based on Unix" in much the same way that Windows 8 is "based on CP/M", in that they do share a little common history, but are completely separate implementations. (That Unix systems proper have taken on some of the userland software typically seen on Linux systems, particularly GNU, is another matter.) It would be better to say that Linux implements the POSIX standard, to which most Unixes (I don't know about LynxOS) also conform; that doesn't, however, make Linux "based on Unix". $\endgroup$ – a CVn Aug 30 '17 at 8:51
  • 1
    $\begingroup$ @MichaelKjörling I clarified that Linux is "Unix like" and that there are many differences between the two. My main point here is to clarify that LynxOS is not just another flavor of Linux. I don't think we should get into the nuances like how Linux distros is only mostly POSIX-compliant and uncertified for POSIX. $\endgroup$ – Cody P Aug 30 '17 at 16:26
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ As well as the mapping programs. $\endgroup$ – jwzumwalt Mar 11 '18 at 20:11
  • 1
    $\begingroup$ Checklists are important, but they aren't safety critical in the same way that, say, a FBW system is, so they wouldn't be subject to the same development assurance level for safety critical equipment as other avionics. $\endgroup$ – Zach Lipton Mar 12 '18 at 3:09
2
$\begingroup$

Is Linux used for safety critical applications? No. Yes. Perhaps. Bear with me...

enter image description here

The USS Umwalt 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:

  • Are embedded;
  • Have a set of pre-defined tasks;
  • Have strict timing constraints;
  • Run in an endless loop. At the end of the program it jumps back to the start and goes through the routine again, this would be one iteration frame.

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.

$\endgroup$
  • 1
    $\begingroup$ "The hardware needs to be fast enough to guarantee that the process can finish within one cycle." I think you are mixing up clock cycles and time slices. Single instructions, such as fetches and jumps may take multiple clock cycles to complete, just a context switch in and out of an interrupt is more than one clock cycle. A "process" cannot physically complete in a single clock cycle. $\endgroup$ – Ron Beyer Aug 30 '17 at 16:28
  • $\begingroup$ Yes, if we aim for technical correctness, @RonBeyer is correct. While you're editing, you may also want to change "user space operating system" to "user-oriented operating system". In low-level software development, such as that you'd be involved in if you're working on an operating system, "userspace" typically means unprivileged code executing under the supervision of the operating system; the opposite is often referred to as "kernel space" which, as you may have guessed, is how the OS kernel executes, without supervision. Note that this is different from admin/regular user account privs. $\endgroup$ – a CVn Aug 30 '17 at 17:30
  • $\begingroup$ @RonBeyer Indeed, not the processor clock of course. $\endgroup$ – Koyovis Aug 30 '17 at 21:22
  • $\begingroup$ @MichaelKjörling There is no unprivileged code in a hard real-time O/S. $\endgroup$ – Koyovis Aug 30 '17 at 21:26
  • $\begingroup$ That is NOT the "USS Umwalt", it is the "USS ZUMWALT"; note the spelling of my last name. And yes I am related to the now deceased Admiral Elmo Zumwalt which this ship and class of ships is named after. $\endgroup$ – jwzumwalt Mar 11 '18 at 20:03
2
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ There is no databus running on an aircraft, Arimc or Milbus, with multiple instruments running at different update rates, which need to receive and output their data at determined rates? Your imstrument runs entirely on its own, and the application is never ported to new hardware? $\endgroup$ – Koyovis Sep 1 '17 at 0:29

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.