Advantages of using a RTOS such as QNX or VxWorks instead of Linux?

Question

When developing a solution that requires a real-time operating system, what advantages would an operating system such an QNX or VxWorks have over Linux?

Or to put it another way, since these operating system are designed specifically for real-time, embedded use - as opposed to Linux which is a more general system that can be tailored to real-time use - when would you need to use one of these operating systems instead of Linux?

Solution 1

Some embedded systems (a) need to meet difficult real-time requirements, and yet (b) have very limited hardware (which makes it even more difficult to meet those requirements).

If you can't change the hardware, then there are several situations where you are forced to rule out Linux and use something else instead:

• Perhaps the CPU doesn't even have a MMU, which makes it impossible to run Linux (except uClinux, and as far as I know uClinux is not real-time).
• Perhaps the CPU is relatively slow, and the worst-case interrupt latency in Linux fails to meet some hard requirement, and some other RTOS tuned for extremely low worst-case interrupt latency can meet the requirement.
• Perhaps the system has very little RAM. A few years ago, a minimal Linux setup required around 2 MB of RAM; a minimal eCos setup (with a compatibility layer letting it run some applications originally designed to run on Linux) required around 20 kB of RAM.
• Perhaps there is no port of Linux to your hardware, and there isn't enough time to port Linux before you need to launch (pun!) your system. Many of the simpler RTOSes take much less time to port to new hardware than Linux.

Solution 2

I've not done any real-time work at all so take this with a grain of salt...

I'm told there's two categories of "real-time": hard real-time and soft real-time.

"Soft real-time" informally means "get it done as fast as possible". I think that Linux on a modern CPU is good for this sort of thing.

"Hard real-time" informally means "get it done within a required time window". The window can be quite small, milliseconds or something. Flight control systems for cruise missiles or satellite launch vehicles seem like the canonical example. Industrial process control systems might also need this. The Stuxnet worm appears to have interferred with systems that do this sort of controlling.

You'd use RTOS in the latter situation. RTOS often guarantee delivering an interrupt in less than so many instructions or clock ticks or whatever.

Another consideration might be that an RTOS is designed, tested and/or "proved" to not consume stack space without bound. It can live inside a certain minimum amount of memory, and things like an "OOM Killer" don't exist because they are provably never needed. Some of the goofier features of early FORTRAN come from this type of requirement. When you compiled a FORTRAN II program, you knew exactly how much stack and how much heap it needed, since you couldn't recurse, and you couldn't dynamically allocate anything.

Realistically, the second consideration (guaranteed max memory consumption) may be more important in some safety-critical applications than "guaranteed interrupt latency of 0.001 seconds".

I would also imagine that stripping the selection process of the fig-leaf of supporting verbiage, you'd find that engineers choose an RTOS because "the requirements say to".

Comments

[CMCDragonkai]

What kind of code is portable between the different RTOS? I also heard that some solutions are top-down (using RTOS) while others are built bottom-up (adding OS features to bare metal incrementally as you need them).

[David Cary]

@CMCDragonkai: Perhaps the programmers.stackexchange.com would be more appropriate place to ask questions about the different RTOS?