24
$\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$
12
  • 21
    $\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
  • 15
    $\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
  • 25
    $\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
43
$\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$
13
  • 4
    $\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
  • 11
    $\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
  • 8
    $\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
  • 4
    $\begingroup$ @traducerad I meant something like hard real time vs soft real time. If a system is performing, for instance, a real time audio processing task it can safely skip a few samples. If a system is managing the hydraulic actuators of a stabilyzer it can't skip a few input commands. :-) $\endgroup$ – Marco Sanfilippo Aug 26 '19 at 7:00
33
$\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
  • 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
  • 1
    $\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$ – user 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$
2
  • $\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
3
$\begingroup$

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.

$\endgroup$
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$
5
  • 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
  • 1
    $\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$ – user 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
  • 2
    $\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$
1
  • 1
    $\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
2
$\begingroup$

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.

$\endgroup$
3
  • $\begingroup$ Hey, thanks for answering this old question of mine! Which precise elements of QNX’ implementation of POSIX make it RT unlike a vanilla Linux? Also you state that their sw architecture is very much like Linux. This also implies there are differences. On which aspects do both operating systems (fundamentally) differ? (I haven’t had the chance to work with qnx) $\endgroup$ – traducerad May 2 at 17:25
  • 1
    $\begingroup$ "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." seems like a rather bold claim to make with no supporting evidence. Care to back that up? $\endgroup$ – FreeMan May 7 at 13:07
  • $\begingroup$ Agreed, I don't see how using open source software would have reduced or prevented the accidents from happening. $\endgroup$ – selectstriker2 May 7 at 14:02

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.