Towards an Architecture for an UI-Compositor for ...

Towards an Architecture for an UI-Compositor for Multi-OS Environments Tobias Holstein1,2 and Joachim Wietzke3 1 2

Dep. of Computer Science,University of Applied Sciences, Darmstadt, Germany School of Innovation, Design & Engineering, M¨ alardalen Univ., V¨ aster˚ as, Sweden 3 Faculty of MMT, University of Applied Sciences, Karlsruhe, Germany

Abstract. Separation through hardware/software virtualization on operating system (OS) layer reduces complexity in automotive software. Automotive software is categorized into domains (e.g. comfort, safety related features, driver assistance) and each domain is handled by a separate OS, which contains domain-specific applications. A common user interface (UI) for all applications from all domains is created through an UI-Compositor, which composites and manages the different input/output modalities. While interactions with a single OS with multiple applications and input/output modalities are well known, we find that a composition of applications from different OSs or a composition of multiple OSs into a single UI is challenging. In this paper we investigate architectural patterns for an UI-Compositor for Multi-OS environments and suggest a new architecture that supports the concept of separation.

1

Introduction

Automotive UIs have changed a lot over the last decades. Comparing car dashboards from 30 years ago to today’s dashboards leaves no doubt about the significance and impact of modern UIs. The complexity of automotive software rises with every new generation [3]. Up to 70% of newly introduced features are software related [1] and categorized into domains: safety related features (e.g. ASP, ESP), driver assistance (e.g. distance checking, lane assist) and comfort (e.g. entertainment, navigation). The increasing amount of features hence influences the dashboards of current and future cars, which is possible through advances in technology (e.g. freely programmable instrument clusters (FPKs), touch-screens, etc.). System and software architectures have to cope with the correlated complexity and increasing dependencies. A current approach is the separation through hardware/software virtualization to reduce complexity and dependencies and to mitigate the risks of interferences by separating safety critical and non-safety critical applications. A domain represents an OS, which encapsulates domain-specific applications and services. This is also known as Multi-OS environment. When applications from different domains share resources, such as a common UI, a component called UI-Compositor handles the actual composition. As an example, when multiple

applications share a single screen, the screen is the shared resource and the UICompositor handles the interaction with those applications and e.g. places the graphical user interfaces (GUIs) on the screen. This central component allows to unify interactions and provide a homogeneous user experience towards all applications. However, there are problems with compositing UIs from different OSs, such as different interaction styles, different input (e.g. multi-touch instead of mouse) or output devices (e.g. different display resolution). An UI-Compositor has to solve those problems. Current approaches propose software architectures that require applications to be developed for a certain target environment and set strict rules about how applications are connected with and composed into a unified UI. Therefore specialized frameworks or software development kits (SDKs) are used for the development of applications for Multi-OS environments, which support various ways of inter-VM-communication. This provides high flexibility and rich UIs, but breaks previously intended separation concepts [7]. Considering the previous effort in the development of Multi-OS environments, which is the separation into domains to increase security and to decrease complexity and dependencies, we find that current approaches actually introduce new issues by raising the complexity and dependencies in the overall UI. Our contributions in this paper are: (1) a universal description of an UICompositor; (2) an investigation into the tasks and problems of an UI-Compositor; (3) a comparison of current approaches and (4) the proposal of a new software architecture for an UI-Compositor, that complies with the concept of separation.

2

Related Work

One of the strongest motivations for virtualization in embedded systems is probably security [4]. Embedded systems are highly integrated and their subsystems have to cooperate to contribute to the overall function of the system. Heiser [4] states that “isolating them from each other interferes with the functional requirements of the system”. While isolation, i.e. the separation through virtualization, increases security, it is still necessary to control or interact with subsystems. Multi-OS environments use a type one hypervisor to run different OS types concurrently on a multi-core hardware [10, p.167]. If OSs of mixed criticality are used it is categorized as a mixed-criticality system. A Hypervisor assigns hardware resources, such as peripheral devices or hardware components, to a certain OS. Accessing resources of other OSs is therefore only possible via interVM-communication. Multi-OS environments aim to improve the software architecture attributes modifiability, security, availability and testability. Interoperability is required to some extent, but every interconnection might mitigate the encapsulation of an OS and lead to a security risk [9]. Compositing can take place in different layers, such as Hardware, OS, Application or UI layer. Higher layers depend on lower layers and lower layers define

constraints to higher layers, which causes a variety of challenges, especially when a homogeneous UI has to be created [6]. The compositing of GUIs of a partitioned in-vehicle infotainment system (IVIS) is shown in [8]. Each partition, i.e. domain, provides multiple applications, which are combined in a GUI using a compositor. Applications and compositor communicate via inter-VM-communication and exchange pixel data and touch events via shared memory (SHM). Plain pixel data “obviates the need to interpret information and hence mitigate security issues such as code injection” [8]. A homogeneous UI is integrating applications, all with their respective UI, from different domains. These applications combined form the actual homogeneous UI. In order to differentiate between the overall UI and the UI provided by an application, we call the latter UI-Artefact (cmp. [8]).

3

UI-Compositor

An UI-Compositor assembles, i.e. blends, scales or places, and provides user interaction with the different UI-Artefacts. This includes the redirection of input events to one or more designated applications and the composition of different types of output. If multiple applications use the same type of UI, the UI-Compositor has to decide how the composition is done. Fig. 1 depicts a composition of multiple UI-Artefacts based on an example of three UIs. The UI-Compositor is also responsible to provide the primary UI-Logic, which includes for example the mapping of input events to a certain application. When a GUI is displayed and a user clicks inside one of many displayed GUIs, the UI-Compositor has to calculate/map the actual position of the mouse click to an relative coordinate of the GUI. The application does not know, whether its GUI is displayed in an UI-Compositor or not. 'h/ ƵĚŝŽ KƵƚƉƵƚ͗

h/ϭ

/ŶƉƵƚ͗