An open source, open architecture operating system, Real Time Linux (RT Linux), was used to develop a controls implementation platform, denoted in this work as Real-Time Controls Laboratory (RTiC-Lab). The core component of the RTLinux architecture is a simple real time executive that is inserted between the original Linux kernel and the underlying hardware [BY97].
Figure 1.4 shows the basic Linux kernel without hard real time support. In this figure, the Linux kernel is seen to separate both the hardware and user-level tasks. The Linux kernel has the ability to suspend any user-level task once that task has outrun the ``slice of time'' allotted to it in the CPU. Assuming that any one of the user tasks could be an AMB controller, then the kernel could potentially be preempting this task and giving the CPU to a less critical task, such as Netscape. Consequently, the AMB controller will not meet its strict timing requirements.
Figure 1.5 shows the modified Linux kernel which supports hard real time. An additional layer of abstraction - termed a virtual machine in the literature - has been added between the original Linux kernel and the computer hardware. This new layer appears as actual hardware to the original Linux kernel. More importantly, it introduces its very own fixed priority scheduler and assigns the lowest priority to the original Linux kernel, which runs as an independent task. Then, it allows the user to both introduce and set priorities for any number of real time tasks. Consequently, it is possible to assign priorities as specified by the Liu and Layland RMA.
The rationale for the RTLinux design is that it was not feasible to attempt to identify and eliminate all aspects of the kernel operation that lead to unpredictability. These sources of unpredictability include the Linux scheduling algorithm (optimized to maximize throughput), device drivers, atomic system calls, the use of interrupt disabling, and virtual memory operations. Prior to the development of RTLinux, every time a new device driver or other enhancements of Linux were needed, a study would have to be performed to determine that the change does not introduce unpredictability. The best approach was to construct a small, predictable kernel outside of the Linux kernel and make it sufficiently simple that operations could be measured and shown to have predictable execution.
RTLinux works by intercepting all hardware interrupts. Interrupts not corresponding to real-time activities are held and then passed into the Linux kernel as a software interrupt when the original Linux kernel runs. Otherwise, the appropriate real time interrupt service routine is run. The RTLinux executive is itself non-preemptable. Unpredictable delays within the RTLinux executive are eliminated due to its small size and limited operations. Real-time tasks are both privileged tasks (they are not user-level tasks) in order to gain direct access to the hardware, and do not use virtual memory. Real-time tasks are not expected to execute Linux system calls. Real-time tasks are written as special Linux modules that can be dynamically loaded into memory. The initialization code for a real-time task will initialize the real-time task structure and inform RTLinux of its deadline, period, and release-time constraints. Non-periodic tasks are supported through the use of interrupts.
Thus, in essence, RTLinux has managed to not compete directly with Linux development. In other words, it does not attempt to create a brand new operating system with brand new development and application tools as has been done with QNX and VxWorks. Rather, via a set of ``simple'' modifications, managed to convert the existing Linux kernel into a hard real time environment without hindering future Linux development and is thus able to continue using all the tools and applications that work with Linux.