November 10th, 2026
Does Your Real-Time Application Really Need a Different Operating System?
Why architecture often matters more than the choice between
Linux and Windows in demanding machine control applications.
By Uwe Jesgarz, Managing Director, Kithara Software
A new machine function must respond every 500 microseconds. The existing control software runs on Windows, but the new task has hard real-time requirements. So the obvious idea is to move the application to Linux.
But does that really mean the entire operating system needs to be replaced?
For complex industrial applications in particular, this is far from a trivial question. Changing platforms may require adapting existing software, replacing drivers, revising interfaces, and modifying established development workflows. Yet perhaps only a small part of the application actually requires hard real-time performance.
Before deciding to change operating systems, it is therefore worth taking a closer look: Which functions really need to operate within defined time limits, and which architecture is best suited to meeting those requirements?
Not Everything Needs to Be Equally Fast
A modern machine control system combines numerous tasks with significantly different timing requirements.
The user interface should respond smoothly, measurement data must be stored, and information needs to be exchanged with other systems. All of these functions require reliable processing, but they generally do not need to meet deadlines measured in microseconds.
Fast motion control is a different matter. If, for example, several axes need new position commands every 500 microseconds, the necessary processing must be completed on time. Demanding applications may also involve coordinate transformations, motion calculations, and synchronization between multiple drives.
Meanwhile, the same computer may be running a complex user interface, measurement data analysis, and other background processes. These must not interfere with time-critical processing to an unacceptable degree.
However, this does not mean that every function needs to operate under the same real-time conditions. Instead, there are good reasons to deliberately separate time-critical tasks from less time-critical ones.
When 500 Microseconds Are No Longer Enough
In particularly demanding applications, timing requirements can become considerably more stringent. A control system operating at 10 kHz, for example, must complete a cycle every 100 microseconds.
Such frequencies are relevant in applications such as active magnetic bearings, high-speed precision control, and certain power electronics systems. Comparable or significantly higher frequencies may also occur when processing highly dynamic measurement signals.
However, a high operating frequency within a machine does not necessarily mean that the central control computer must operate at the same frequency.
In an electric drive, fast current control is often performed directly in the drive amplifier, while the higher-level controller operates with longer cycle times. The same applies to many laser scanners, where fast internal control is handled by specialized electronics.
In other cases, however, it may make sense to execute fast control algorithms directly on a powerful industrial PC. This is particularly relevant for custom control systems, computationally intensive algorithms, or applications requiring close interaction between multiple measured and controlled variables.
The crucial question is therefore not simply which cycle frequency needs to be achieved. Equally important is where each function is executed and how it interacts with the other components.
The Real Challenge Often Lies in Between
Consider a test bench used to investigate the dynamic behavior of a mechanical system. Forces and movements are measured, a mathematical model is calculated, and new control outputs are then generated.
Even if the calculation itself requires only a fraction of the available cycle time, the timing requirement may still be missed. After all, measurement data must also be available on time, data must be transferred, and the calculated results must be output at the specified moment.
Furthermore, several timing sequences may coexist within such a system. A fast controller might operate at 2 kHz, while other functions run at 1 kHz or significantly lower frequencies. Individual sensor events may need to be captured with high timing precision without requiring the entire application to execute at an equally short cycle interval.
Similar requirements arise in machines where image processing, drive control, and sensor systems work together. Image analysis may require considerable computing time, while certain reactions to detected events must occur with very precise timing.
This illustrates why an application's real-time capability cannot be assessed solely by the shortest achievable cycle time. What also matters is whether the different processing stages are reliably coordinated.
What Linux Improves – and What It Does Not
Linux is a suitable platform for many industrial real-time applications. PREEMPT_RT can improve kernel response times and reduce numerous sources of unpredictable delays. With careful configuration, even demanding time-critical applications can be implemented.
However, a real-time-capable kernel does not automatically turn an application into a reliably functioning real-time system.
Drivers, hardware access, communication, and the application's actual processing must still be taken into account. Particularly with short cycle times, any of these factors can determine whether a deadline is met.
Nor does the choice of operating system automatically answer the question of how time-critical and less time-critical software components should work together.
When an existing application is migrated from Windows to Linux, this challenge remains. The migration may even introduce additional development effort if existing user interfaces, device integrations, or other functions need to be adapted.
This is not an argument against Linux. For many new applications, as well as the modernization of existing systems, Linux can be an excellent choice. However, changing operating systems should not be equated with solving every real-time challenge.
Why Not Execute Only the Time-Critical Part Differently?
In many industrial applications, only a limited portion of the software requires hard real-time performance.
It may therefore make sense to execute precisely this portion in a dedicated environment while keeping the remaining functions on the existing platform.
On Windows, for example, this can be achieved with a specialized real-time extension that executes time-critical tasks independently of the standard Windows scheduler. Existing applications can retain their user interfaces, data management, and other functions, while control algorithms, data acquisition, or motion control operate under defined real-time conditions.
For machine manufacturers, this creates an opportunity to develop additional real-time functions without having to migrate their entire software to another platform solely for that reason.
However, the underlying principle is not limited to Windows. Linux also allows time-critical and non-time-critical functions to be deliberately separated. Depending on the application, different real-time mechanisms or specialized system architectures can be used.
What matters is that this separation is genuinely effective: Real-time processing must have access to the necessary computing resources, and communication with other software components must not jeopardize compliance with its timing requirements.
A Decision with Long-Term Consequences
Choosing an industrial control platform usually affects far more than the timing behavior of individual functions. It also influences development effort, hardware support, maintenance, and future expansion.
Migrating a complex existing application to another operating system solely because of additional real-time requirements may involve substantial changes, even though a targeted extension of the architecture might have been sufficient.
Conversely, for a new development project, it may well make sense to choose a Linux-based solution from the outset. The deciding factors are the technical requirements, available resources, and long-term product strategy.
In a multi-axis control system operating at 2 kHz, synchronization between different drives may be the primary concern. In a 10 kHz application, the division between central and local control may be the decisive factor. And in a complex test bench, precise coordination between multiple functions operating at different frequencies may matter more than the maximum cycle frequency.
These differences cannot be addressed by a blanket recommendation for any particular operating system.
Understand the Requirements First, Then Choose the Platform
Whether Linux or Windows provides the better foundation for an industrial application cannot be determined from its real-time requirements alone.
The first step should be to identify which functions actually need to meet strict timing constraints, which processing stages are involved, and how the various components interact. It is equally important to determine which tasks should run on the central computer and which would be better handled by specialized hardware.
Only then does it become clear which architecture makes sense from both a technical and an economic perspective.
This might be a control system running entirely on Linux, a specialized real-time environment on Windows, or a combination of central real-time processing and local controllers.
The best real-time solution is not automatically the one with the supposedly best real-time operating system. It is the architecture that reliably meets the application's timing requirements without introducing unnecessary complexity.
Sometimes that means changing operating systems. Sometimes, choosing not to change is the better decision.