Virtual Open Systems Scientific Publications
13th International Conference on Systems (ICONS-2018), Athens, Greece.
Graphics, split-display, mixed-criticality, real-time, VOSYSmonitor.
This research work has been supported by the H2020 NGPaaS project under the Grant Agreement number 761557. The work presented in this paper reflects only authors' view and the European Commission is not responsible for any use that may be made of the information it contains.
New breakthroughs in the automotive domain, such as Advanced Driver Assistance Systems (ADAS), 5G Vehicle to Everything (V2X) connections and In-Vehicle Infotainment (IVI) systems have made a significant impact on the automotive industry. Virtualization plays a key role in this trend, since it provides the ability to consolidate services with different levels of criticality, such as for instance ADAS functions and IVI or 5G connectivity services.
Today, one scenario that arises with this new trend is the consolidation of a safety critical digital instrument cluster which displays safety metrics, e.g., speed, torque, etc. along with an IVI system. In such an architecture, the Graphical Processing Unit (GPU) is of central importance to ensure an efficient implementation. However, utilizing the GPU in both compartments raises safety concerns, and poses the question whether the strict isolation implemented by the virtualization layer can be upheld.
Therefore, in this paper, we investigate this issue, and address it, by proposing a solution that consolidates a safety critical digital cluster along with an IVI system. We present the design of a safety mechanism to isolate the GPU rendering in both compartments, called “split-display”, leveraging the ARM TrustZone technology. In our design, the secure world hosts a Real-Time Operating System (RTOS), which handles the GPU rendering in order to protect mission-critical tasks (e.g., speedometer and warning icons) from potential failures occurring in the IVI system. The mechanism provides safety guarantees for the GPU rendering of the RTOS. Our prototype “split-display” solution for mixed-criticality systems is implemented on the Renesas R-Car H3 platform.
To validate our prototype implementation, we performed a number of experiments and evaluate the performance impact that occurs due to the consolidation. The results show that our implementation ensures at least 30 frames per second (fps) which is in line with the ISO 15005 safety standards. This number can even be achieved if a failure occurs in the IVI system.
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.
Access the full content of this publication
Login or register to access full information