Real-time Linux in embedded systems: When is Linux suitable?

• Real-time does not mean ‘fast’, but rather predictable. The crucial factor is that defined response times are consistently met, even under load.
• Standard Linux is not automatically real-time capable. Jitter arises, amongst other things, from interrupt behaviour, kernel sections, drivers and competing loads.
• PREEMPT_RT significantly improves timing, but is no substitute for a clean architecture. Real-time behaviour arises only from the kernel, thread prioritisation, CPU allocation and controlled runtime paths.
• In practice, drivers, scheduling and interrupts are decisive for success. Many timing problems arise not in the application, but in the deeper system layers.
• Linux is often a sensible choice when determinism needs to be combined with connectivity, updatability and maintainability. For very stringent timing requirements, a separate real-time domain may be the more robust solution.

Real-time does not mean ‘as quickly as possible’. What is crucial, rather, is that a system responds to an event within a defined time frame and that this behaviour remains reproducible even under load. It is therefore not the average response time that is decisive, but the predictability of the latency.

In embedded systems, real-time requirements can typically be classified into three categories:

• Soft real-time: Occasional time-out violations are tolerable.
• Hard real-time: Deadline violations significantly impair quality or stability.
• Hard real-time: Failing to meet a time specification is functionally unacceptable.

This distinction is central to the choice of software architecture. Many applications do not require hard real-time in the strictest sense, but they do require deterministic behaviour in communication paths, sensor processing, control tasks or actuator control. It is precisely in this area that Linux can be a technically and economically viable platform.

A standard Linux kernel is primarily designed for high throughput, fairness and overall system performance. Whilst these characteristics are desirable in many embedded systems, they do not automatically result in minimal and reproducible latencies.

Typical causes of timing jitter in standard Linux are:

• non-deterministic interrupt handling times
• longer, non-interruptible kernel sections
• competing background processes
• load spikes during memory and I/O accesses
• drivers with unfavourable runtime behaviour

Even high-performance hardware alone does not solve this problem. A fast processor can improve average performance, but does not guarantee deterministic timing. For real-time embedded systems, therefore, it is not only absolute performance that is crucial, but above all the worst-case behaviour.

When Linux is used in embedded systems with stringent timing requirements, a standard kernel is often insufficient. A key approach to improving real-time behaviour is the use of a PREEMPT_RT-enabled kernel.

PREEMPT_RT reduces non-preemptible kernel sections, improves the prioritisation of tasks and ensures that interrupt and scheduling behaviour can be better controlled. As a result, latencies and jitter can typically be significantly reduced compared to standard Linux.

However, kernel configuration alone is not sufficient to achieve a reliable result. In practice, further measures are crucial:

• proper prioritisation of time-critical threads
• CPU affinity for relevant tasks
• reduction of competing background load
• targeted allocation of interrupts
• avoidance of unnecessary context switches
• controlled memory strategies at runtime
• optimised driver paths

In many embedded projects, the biggest problems lie not in the application logic, but in the lower system layers. Three areas are particularly relevant: interrupt handling, scheduling and driver design.

There is no one-size-fits-all answer to the question of whether Linux is suitable for a particular application. The specific system architecture is the decisive factor. The following questions should therefore be clarified as early as the initial stages of a project:

To conclude, it is worth taking a look at three common misconceptions that regularly lead to problems in projects:

Is a fast processor automatically sufficient?

No. Higher computing power improves average performance, but does not automatically improve worst-case behaviour.

Is PREEMPT_RT sufficient on its own?

No. Without appropriate prioritisation, thread allocation, driver quality and load isolation, the result is often inadequate.

Does real-time capability only emerge during implementation?

No. The crucial decisions are already made at the architectural stage.

Whether Linux is suitable for an application depends on the technical depth of its architecture: kernel configuration, scheduling, interrupt handling, driver quality and load balancing are more important for this than raw computing power.

For many embedded products, Linux provides a particularly strong foundation when, in addition to time-critical functions, connectivity, maintainability, the ability to update and long-term platform support are also required. Where the demands for determinism increase, the system must be consistently designed with this in mind. And where hard limits are reached, a clear separation between the Linux environment and the real-time domain is often the right approach.

By precisely defining real-time requirements at an early stage, one can avoid costly architectural errors and lay the foundations for an embedded system that operates reliably not only in terms of functionality but also in terms of timing behaviour.