Embedded systems
Embedded systems are designed for specific functions, at the opposite of a personal general computing device, such as smartphone, personal computer.
Embedded systems are designed to run a dedicated and specific software.
General-Purpose Operating System (GPOS)
General-purpose Operating Systems (GPOS) are operating systems that can manage a high number of processes and complete an execution per unit time. Hence, in order to achieve the necessary high throughput (number of processes completed per unit time), a GPOS would serve multiple low priority tasks, rather than execute one high priority process. This policy allows the GPOS to give the overall high output the desktop and server applications require to work efficiently.
Hence, in these systems, scheduling isn’t always prioritized. A lower-priority process can be executed first. The task scheduler uses a fairness policy, allowing the overall throughput to be high, but not ensuring that high-priority jobs or time-critical threads will be executed first.
Real-Time Operating System (RTOS)
A real-time system is a system where each service request, or task, should be guaranteed to be done within a specified timing constraint.
The timing constraint of a task is the duration required to execute this task completely.
Hard real-time system is defined where any task execution is completely achieved before the deadline time constraints. The time constraint is hard because missing the deadline is disastrous. The late completion of the task is not acceptable is this case. A Hard real-time system returns response within tens of milliseconds or less.
Soft real-time system is defined where a task can be achieved after the deadline time constraint. Missing the deadline have no disastrous consequences. Missing the deadline is undesirable but acceptable in this case. Soft real-time systems return response within a few hundred milliseconds.
A real-time operating system (RTOS), like FreeRTOS or Zephyr OS, is an operating system where achievement of each task is done in a predictive and determinist way. It is said predictive because it will be always achieved in a tight time boundary. A RTOS is also qualified as determinist because, repeating a task will produce the same result. At the opposite, in a general-purpose operating system, like Linux, execution of task is not predictive.
Real-time operating systems should stick to the following requirements at least:
-
Deterministic Scheduling
RTOS uses deterministic scheduling algorithms to ensure that tasks are executed with predictable timing. This means that tasks have well-defined priorities, and the scheduler guarantees that high-priority tasks are executed before lower-priority ones.
-
Interrupt Handling (Preemption)
RTOS efficiently manages interrupts and context switches. It can preempt currently running tasks to respond to high-priority interrupts promptly. This is required to design applications with low latency real-time responses.
-
Resource Management
RTOS provides mechanisms for managing shared resources such as memory, CPU time, and hardware peripherals. It helps prevent resource conflicts and deadlocks among tasks.
-
Low Latency
RTOS minimizes the time between an event occurrence and the corresponding task’s response. Such low latency is crucial in applications such as robotics, automotive control systems, and industrial automation
-
Safety and Reliability
RTOS is often used in safety-critical systems, where failure can have severe consequences. Therefore, it is designed to be reliable and robust, with mechanisms for error handling and fault tolerance.
-
Scalability
Many RTOS kernels are designed to be scalable, allowing developers to configure the operating system to meet the specific requirements of their application. This helps minimize the system’s footprint and optimize performance.
Type of real-time system
There are many types of real-time systems
Bare-metal system
Bare-metal firmware is software designed without kernel and task scheduler. Bare-metal firmware is used when only one task, or few simple tasks are needed. It is the case for Application Specific Integrated Component (ASIC), Programmable Logic Devices (PLDs), Complex Programmable Logic Devices (CPLDs), and Field Programmable Gate Arrays (FPGAs), Micro Controller Unit (MCU). Signe core MCU, at the opposite of the other hardware, is not executing task in parallel, but in a slot of time.
RTOS based firmware
RTOS based firmware is software designed using a kernel and a task scheduler. It runs on a MCU.
RTOS based software
RTOS based software is software running on an Operating System (OS) that contains a Memory Management Unit (MMU) and Central Processing Unit (CPU).
RTOS Safety critical
A RTOS is safety critical when a failure could harm people or significant damage. Such a system requires to be determinist and predictable. Some software certification standard DO-178B, DO-178C, IEC 61508 SIL (Safety Integrity Level)
Real-Time and Linux
Linux kernel in fact has been developed to mainly target general purpose systems.
The Linux kernel uses a task scheduler which shares resource (MEMORY, device …) in some CPU time to various processes. However, this scheduling mechanism can lead to unpredictable latencies, making it unsuitable for real-time tasks.
There are two types of solution to provide Real-time on embedded Linux system:
PREEMPT_RT
The PREEMPT_RT is a set of patches applied on the Linux kernel. PREEMPT_RT allows the real-time tasks to preempt the kernel, even in critical sections. However, some regions can still be made non preemptible, like the top half of interrupt handlers and the regions protected by raw spinlocks.
The PREEMPT_RT patch allows the developers to reuse most of the existent libraries and tools, including all the sets of functions specified by the POSIX standard. However, PREEMPT_RT provides less tight real-time guarantees.
Cokernel approach
Another way to provide real time features to Linux is to use a dedicated co-kernel, among side to the Linux kernel. Xenomai is such a solution. The baseline idea here is to have the co-kernel working as a layer between the hardware and the general-purpose Linux kernel. This co-kernel manages the real-time threads. This layer catches interrupts coming from the hardware and forwards it to real-time tasks or to Linux tasks.
The co-kernel provides a scheduler to process real-time tasks in the deadline. Residual CPU time can be allocated to general-purpose Linux if needed.
PREEMPT_RT versus Co-kernel
Developing real-time application for PREEMPT_RT system is similar to general purpose Linux kernel, but using a specific scheduling and priority. PREEMPT_RT patch can be considered if the hard real-time requirements are not so strict and also if there are no safety-critical constraints.
Developing real-time application for co-kernel real time system requires using specific API. In addition, cokernel approaches are generally less stable and safe due to the complex interaction between the two kernels, which requires extra effort for real-time developers. Xenomai provides less latency and shorter response time than PREEMPT_RT path, but is much more difficult to design and develop application with a co-kernel approach.
Usually, systems requiring high hard real-time constraints require also critical-safety requirements, so neither of the two solutions can be considered.
Real-Time Linux versus RTOS
Systems implemented with a traditional OS are going to have much less deterministic behavior (and none that can be truly counted on in a safety critical situation). If there is a strict real-time requirement, or a safety critical requirement, a bare meatal firmware or a RTOS based firmware should be considered. In other case, PREEMPT_RT patch should be considered, because developing with co-kernel implies much more developments efforts.
According to the recent hardware architecture provides MPU with several cores and at least one MCU core, solution can be considered as following:
- General Purpose OS running on the MPU.
- Real-time application running on MCU
SOC (System on Chip) like NXP imx8mp (4x A53 mpu core mixed with a 1x Cortex M7 mcu core), TI AM64 (2x A53 mpu core , 2x Cortex R5 mcu core, 1x Cortex M4 mcu core), STM stm32p2 (2x A53 mpu core, 1x Cortex M-33 mcu core) provide hardware hybrid architecture.
This hybrid approach separates the Real-time system needs and the General Purpose needs. This approach is better to get Systems stability and maintainability, and separating real-time problematic without interfering with no real-time features.