RTOS and Linux Are Defining In-Vehicle Computing – Together
As the industry moves from function-specific hardware and software to centralized in-vehicle computing and software-defined vehicles, it is clear that Linux will play a significant role in future vehicle platforms. Linux has a long and proven history in other industries and is extremely flexible, which makes it a natural choice for automotive applications.
But as OEMs introduce applications with specialized requirements — especially around functional safety for fully or partially automated driving — there is a need for a real-time operating system (RTOS) that is optimized for deterministic latency in safety-critical use cases.
In evaluations of potential future in-vehicle software architectures, it is important to understand the relative strengths of Linux and RTOSes and how they complement each other in this changing landscape.
As a general-purpose operating system, without modifications, Linux is suitable only for applications where delays can be tolerated. Linux has proliferated across enterprises and industries partly due to its low cost and vast ecosystem of open-source developers and tools. OEMs have adopted or evaluated Linux for a wide range of vehicle applications, and it has already proven ideal for some.
In contrast, an RTOS is designed exclusively for real-time applications, with features that guarantee that a given input will produce the same outcome on time, every time. The RTOS enables RT applications to reserve OS resources at specific times and use them to complete tasks by strict deadlines. It ensures that events take place at the correct time, not just as soon as possible. These characteristics are indispensable for hard RT applications.
In addition, RTOSes have fewer lines of code compared with general-purpose OSes. This gives OEMs several benefits. From a security perspective, less source code translates into less surface area for attackers to target, reducing risk and the work required to mitigate it. That said, it is still important to use an RTOS designed with a secure development lifecycle. In terms of safety, a smaller, less complex OS takes less effort to certify for functional safety standards. These advantages can help OEMs bring a vehicle to market faster.
Running RT workloads on an RTOS can also reduce costs. With less source code, an RTOS has lower CPU and memory requirements, which can translate into a lower hardware bill of materials. If an RTOS has been precertified for safety, this saves OEMs the considerable cost of certifying it themselves. In addition, RTOSes — especially their source code and APIs — change more slowly, reducing maintenance and security costs, preserving an OEM’s investment, and reducing the need to re-certify the operating system due to changes.
For a full comparison of Linux and RTOSes in automotive applications, read our white paper.
