Virtual Open Systems Scientific Publications

Introduction

Road vehicles nowadays are host to a huge number of embedded processors, executing millions of lines of code. However, the maintenance of these large code bases is tedious and error-prone for the vehicle manufacturers. Therefore, the manufacturers try to use off-the-shelf software wherever possible to facilitate and streamline their development process. The availability of existing Real Time Operating System (RTOS) solutions proves itself useful in this respect. Especially, since the OSEK/VDX consortium certified some of these RTOSs as suitable for the use in vehicular embedded control units. Such OSEK/VDX-conforming RTOSs address the needs of the vehicle manufacturers in almost all concerns. They only fall short in a small but critical number of domains such as In-Vehicle Infotainment (IVI), security and safety. To address these shortcomings alternative RTOSs for the high-end automotive domain are available today.

But not only leveraging off-the-shelf software helps to streamline the development process of the vehicle manufacturers, also the integration of multiple components of different criticality (forming a so called Mixed Criticality System (MCS) lowers the number of embedded controllers in the car and consequently reduces cost, space, weight, heat generation and power consumption. By leveraging virtualization, the vehicle manufacturers can now run multiple systems on a single embedded controller, from a highly reliable RTOS for mission-critical functions to a highly customizable Linux-based system for IVI services.

Although, virtualization enables numerous new applications, the trend also poses new challenges on the software stack. One such challenge is the proper sharing of hardware resources. Since all software components access the same hardware components of the embedded controller, special care must be taken when integrating such an architecture. In the past, researchers have already shown how to undermine the isolation enforced by the OS using shared hardware resources (e.g., caches, DMA devices, etc). Thus, a resilient software architecture needs to be in place.

In this context we investigate the sharing of a common display among two components with different levels of criticality. This is not only challenging because the involved components (e.g., Video Signal Processor) are powerful embedded devices in itself, which have to be handled with care, to not jeopardise the system integrity. But the task is also urgent because a rich automotive user interface calls for the integration of an IVI along the instrument cluster.

In this paper we present a solution, integrated into an open source RTOS which composes multiple visual elements and renders them to a common display to meet the needs of future automotive applications in areas like IVI or security/safety. The system relies on the isolation properties enforced by a highly privileged software component called VOSYSmonitor, which guarantees isolation between peripherals and memory of both OSes using ARM TrustZone.

In particular, we make the following new contributions:

• We design a mixed criticality “split-display” solution to allow a mission critical instrument cluster to run side-by-side with an IVI system.
• we evaluate existing solutions, depict their advantages and drawbacks and position our novel approach among them.
• We implement a full prototype of our architecture and evaluate its performance on an automotive grade evaluation board (Renesas R-Car H3).

The rest of this paper is structured as follows. In Section II, we give background on virtualization, ARM processor extensions and hypervisors in general. Then, in Section III we present related work and emphasize the advantages and drawbacks of existing solutions compared to our design. Our system architecture is described Section IV. Section V outlines our design. We focus on the peculiarities of our driver and automotive application in Section VI. We evaluate our design in Section VII. We conclude our work and present future work in Section VIII.