Real-Time OS Technology
In the world of standard computing, performance is measured by throughput - how much data can be processed in a given time. However, in the realms of industrial automation, robotics, and mission-critical systems, speed is secondary to Determinism.
A Real-Time Operating System is not necessarily a "fast" system; rather, it is a system that guarantees a response within a strictly defined time constraint. In a real-time environment, the correctness of a computation depends not only on its logical result but also on the time at which the result is delivered. A correct command delivered micro-seconds too late is considered a system failure.
Characteristics of General-Purpose Linux
Standard Linux (General-Purpose OS) is designed with throughput and fairness as its primary goals - not determinism. For industrial control and robotics, occasional latency equals system risk.
| Issue | Limitation |
|---|---|
| Non-deterministic scheduling | Tasks may execute quickly, but not necessarily on time |
| Interrupt latency and jitter | Interrupt and scheduling latency have no guaranteed upper bound |
| Undefined worst-case latency | The system cannot define or guarantee the worst-case response time |
Benefits of Real-Time OS
The core value of Real-Time OS is predictability:
- Bounded latency
- Predictable scheduling
- Industrial and robotic control readiness
In industrial control, robotics, and edge AI systems, the biggest risk is not insufficient performance - it is unpredictability. Our Real-Time OS services focus on reducing latency, eliminating jitter, and establishing deterministic system behavior, ensuring workloads complete within defined time boundaries. From Kernel Porting to deterministic system engineering, we provide deterministic, low-latency Linux for industrial, robotics, and edge AI platforms.
Metrics of Real-Time Performance
The value of Real-Time OS is realized through its improvements to two critical real-time metrics: Latency and Jitter. Improvement goal of realtime OS is reducing Worst-Case Latency (Max Latency) and narrowing the Response Time Variation (Max Jitter).
- Latency is the time elapsed from when an event occurs (e.g., a high-priority task becomes ready) to when the system actually starts responding to that event (e.g., the CPU begins executing the task).
In the standard kernel, low-priority tasks can hold kernel locks for long durations, forcing high-priority tasks to wait, and some critical interrupt processing can be delayed for too long. the Worst-Case Latency is often high and unpredictable.
- Jitter refers to the variation or fluctuation range in the response time or execution time of successive tasks. In a real-time system, not only must the average response time be fast, but the variation in response time must also be small.
In the standard kernel, Jitter is high; a task might respond very quickly at one moment and very slowly at another (e.g., when the kernel is executing a resource-intensive operation).
Typical Real-Time OS applications customers can relate to Industrial motion control systems (EtherCAT), AMR/AGV platforms, Humanoid robots and robotic arms, Industrial AI edge computing and TSN-based industrial control networks. Below table is the acceptance criteria in some different scensrios.
| Matrix | General Automation or Medical | AMR / Robot Control | Advanced Motion Control | |
|---|---|---|---|---|
| Precision | Low | Medium | High | |
| Max Latency | < 500 µs | 125 ~ 500 µs | 10 µs ~ 125 µs | |
| Solution | Preempt-RT | Preempt-RT | Xenomai ( < 100 µs ) or Preempt-RT ( Strictly Tuned / Hardware ) | |
| Application | I/O, Packaging Lines, Non-Life-Support Equipment | Joint Control, Motion Control | Multi-Axis Servo, CNC Pick&Place | |
Categories of Real-Time OS
Preemot-RT
Preempt-RT (Real-Time Preemption) is a set of modifications applied to the standard Linux Kernel. Its primary goal is to transform the Linux Kernel from a General Purpose Operating System into an operating system capable of near Hard Real-Time performance.
It significantly reduces system latency, enabling it to meet the demands of applications with strict time constraints, such as robotics control, industrial automation, and high-frequency trading systems.
-
Latency (Delay) - Reducing Worst-Case Latency (WCL)
By making kernel locks and most interrupt handling preemptible, the maximum time a high-priority task has to wait for a kernel resource or interrupt processing is drastically reduced, it significantly lowers the Worst-Case Latency (WCL), making the upper bound of delay controllable and predictable. This allows the system to meet the strict timing requirements of hard real-time applications. -
Jitter (Variation) - Narrowing the Response Time Variation
Eliminates Major Blocking Sources, Preempt-RT removes the prolonged, non-preemptible blocking points within the kernel. This means the time a high-priority task is blocked at any given moment is short and consistent, it greatly reduces the fluctuation range (Jitter) of task response times. The execution of high-priority tasks becomes highly predictable, without the occasional spikes of massive delay.
Xenomai
Xenomai employs a dual-kernel architecture, introducing a Real-Time Core (also known as a co-kernel) that runs in parallel with Linux within the system. All tasks with real-time requirements are handled by this co-kernel with higher priority, completely bypassing the standard Linux scheduler.
The co-kernel intercepts IRQs (Interrupt Requests) with a priority level superior to Linux and executes its own real-time scheduling, ensuring that Linux cannot preempt or interfere with the execution of real-time tasks.
-
Latency (Delay)
Prioritized handling of IRQs by Xenomai, System interrupts are processed by Xenomai before Linux’s interrupt handler, allowing immediate dispatch into the real-time handling path and significantly reducing the delay between a hardware event and its corresponding handler execution.
Real-time tasks bypass the Linux CFS scheduler, Xenomai employs its own real-time scheduler, ensuring that high-priority real-time threads run immediately when they become ready, without being blocked by any Linux background jobs. -
Jitter (Variation)
Core Task Isolation, Xenomai employs a Dual-Kernel architecture, which completely isolates the scheduling and execution of all real-time tasks, it ensures that real-time tasks run on a dedicated real-time core, shielded from the non-real-time operations of the standard Linux kernel (e.g., memory management, file I/O, lengthy network protocol processing).
Prioritized and Decoupled Interrupt Handling (I-Pipe)
Xenomai ensures that high-priority real-time tasks can immediately respond to hardware events. Real-time tasks don't waste time waiting for Linux to process an irrelevant interrupt, making the task response time consistent and predictable, which significantly minimizes Jitter.
Use Cases of Real-Time OS
In highly precise and safety-critical domains, the primary limitation of general-purpose operating systems lies in their unpredictability. Real-time capabilities on Linux are achieved through real-time technologies such as PREEMPT_RT and Xenomai, which extend Ubuntu’s general-purpose kernel deterministically, ensuring that tasks are executed and completed within defined time constraints.
Below is a detailed explanation of the benefits and problems addressed by real-time systems, organized around the six key points scenario:
