Multi-OS hybrid deployment framework

Background: Mixed Criticality Systems

In embedded scenarios, although Linux has been widely used, it cannot cover all requirements, such as high real-time, high reliability, and high security scenarios. These situations are often where real-time operating systems come into play. Some application scenarios require the management capabilities and rich ecosystem of Linux as well as the high real-time, high reliability, and high security of a real-time operating system. A typical design is to use a processor with strong performance to run Linux to handle rich functions. A microcontroller/DSP/real-time processor runs a real-time operating system and is responsible for real-time control or signal processing. The two communicate through I/O, network or off-chip bus. The problems with this approach are that the hardware requires two systems, the integration level is not high, the communication is limited and the limitations of off-chip physical mechanisms such as speed, delay, etc., and the software is separated between Linux and the real-time operating system. Yes, there is room for improvement in flexibility and maintainability.

Benefiting from the rapid development of hardware technology, the hardware capabilities of embedded systems are becoming more and more powerful, such as the continuous improvement of single-core capabilities, the evolution from single-core to multi-core, heterogeneous multi-core and even many-core, virtualization technology and Trusted Execution Environment (TEE). ) technology development and application, advanced packaging technology in the future will bring higher integration, etc., giving a solid physical foundation for deploying multiple OSs in a system on a chip (SoC).

At the same time, driven by application requirements, such as the Internet of Things, intelligence, functional safety, and information security, the entire embedded software system is becoming more and more complex, and the challenge of using a single OS to carry all functions is increasing. One of the solutions is that different systems are responsible for the functions they are good at, such as the UI of Windows, the network communication and management of Linux, the high real-time and high reliability of real-time operating systems, etc., and they must be easy to develop, deploy, expand, and implement. It can be containers, virtualization, etc.

Faced with the above-mentioned changes in hardware and applications, combined with its own original characteristics, one of the future evolution directions of embedded systems is "Mixed Criticality System (MCS)" , which can be summarized from typical embedded systems - The recent development trends of automotive electronics are briefly seen.

"Figure 1" The general architecture of the mixed-criticality system in openEuler Embedded

From the perspective of openEuler Embedded, the general architecture of the mixed-criticality system is shown in Figure 1. The hardware targeted is a system-on-chip with homogeneous or heterogeneous multi-cores. From an application perspective, multiple OS/runtimes will be deployed simultaneously. For example, Linux is responsible for system management and services, a real-time operating system is responsible for real-time control, a real-time operating system is responsible for system reliability, and a bare metal runtime runs dedicated algorithms. The functions of the entire system are completed collaboratively by each OS/runtime. The “hybrid deployment framework” and “embedded virtualization” in the middle are specific supporting technologies. In a narrow sense, criticality mainly refers to the functional safety level. Referring to the pan-functional safety standard IEC-61508, Linux can reach the SIL1 or SIL2 level, and the real-time operating system can reach the highest level SIL3; in a broad sense, criticality can be extended to the real-time level. , power consumption level, information security level and other goals.

In such a system, the following problems need to be solved:

• "Efficient hybrid deployment issues" : How to efficiently achieve multi-OS collaborative development, integrated construction, independent deployment, and independent upgrades.
• "Efficient communication and collaboration issues" : The overall function of the system is completed by various domains, so how to effectively achieve efficient, scalable, real-time, and secure communication between different domains.
• "Efficient isolation and protection issues" : How to efficiently achieve strong isolation and protection between multiple domains so that they do not affect each other when failures occur, and a smaller Trust Compute Base (Trust Compute Base).
• "Efficient resource sharing and scheduling problem" : How to efficiently manage scheduling resources while meeting different target constraints (real-time, functional safety, performance, power consumption), thereby improving hardware resource utilization.

Regarding the above problems, the current thinking of openEuler Embedded is "mixed criticality system = deployment + isolation + scheduling" , that is, first to achieve mixed deployment of multiple OSs, then to achieve isolation and protection between multiple OSs, and finally to improve through hybrid criticality scheduling Resource utilization can be mapped to "hybrid deployment framework" and "embedded virtualization" . The hybrid deployment framework solves "efficient hybrid deployment problems" and "efficient communication and collaboration problems" , and embedded virtualization solves "efficient isolation and protection problems" and "efficient resource sharing and scheduling problems . "

Multi-OS hybrid deployment framework

The architecture diagram of the multi-OS hybrid deployment framework in openEuler Embedded is shown below. The open source framework OpenAMP[1] is introduced as the foundation and further innovated based on its own needs.

"Figure 2" Infrastructure of multi-OS hybrid deployment framework

In the above architecture, libmetal provides a unified abstraction that shields the details of different system implementations. virtio queue is equivalent to the MAC layer in the network protocol and provides an efficient underlying communication mechanism. rpmsg is equivalent to the transport layer in the network protocol and provides endpoint-based communication. (endpoint) and channel (channel) abstract communication mechanism, remoteproc provides life cycle management functions including initialization, startup, pause, end, etc.

In openEuler Embedded 22.03, OpenAMP related support is integrated, and the hybrid deployment of openEuler Embedded and the real-time operating system Zephyr[3] is implemented on the QEMU platform in cooperation with openEuler's SIG Zephyr[2]. For details, please refer to

Multi-OS hybrid deployment Demo[4]

On this basis, the hybrid deployment framework of openEuler Embedded will continue to evolve, including docking with more real-time operating systems, such as the domestic open source real-time operating system RT-Thread [5], to achieve multi-OS service-oriented deployment as shown in Figure 3 And timely introduction of embedded elastic base based on virtualization technology.

"Figure 3" Multi-OS service-based deployment architecture

In the above-mentioned multi-OS service-based deployment architecture, openEuler Embedded is the center, mainly providing general services such as management, network, and file systems to other OSs. Other OSs can focus on their areas of expertise and use shell, log, debug and other channels to Connect with Linux's rich and powerful dimensional measurement bodies to simplify development work.