VESBA – A Middleware Oriented Architecture for Virtualized Embedded Systems Artur Schiefer
Volker Gruhn
Ruslan Hrushchak
Leipzig University Klostergasse 3 04109 Leipzig Germany
Leipzig University Klostergasse 3 04109 Leipzig Germany
Leipzig University Klostergasse 3 04109 Leipzig Germany
[email protected]
[email protected]
[email protected] -leipzig.de
provider or others. This is not true for automotive platforms. Available platforms like `Sync` from Ford and Microsoft offer only limited extensibility and are not open to the public. Another major setback for third party developers is the very restricted access to car sensor information for further use in their applications including the access to buttons or the (touch) screen. A main cause for the lack of publicly available platform SDKs for vehicles is the high integration level of embedded systems in a very safety sensitive distributed system. Therefore all new functionality which is added to these systems has to be tested thoroughly to not interfere with safety functions. This includes the use of resources, may it be processing time, network and sensor access or head unit display space. Another challenge of these in vehicle systems face is the lifelong upgradeability needed for the introduction of Car2X and Car2Car communication and the integration of internet based services into the vehicle.
ABSTRACT
Designing robust and safe systems is hard. Extending and maintaining such a system is even harder. The increasing demand to integrate consumer electronics and custom applications based on a broad range of platforms into vehicles is intensifying this problem. In the following paper we present an architecture which allows designing a safe and robust system core that can share its resources in a safe way with other applications. The main focus is to make the car processing and information resources available to 3rd party applications without compromising the safety and robustness of any critical system in the vehicle. Recent advances in virtualization technology allow us to propose a virtualized embedded system architecture incorporating middleware and distributed finite state machine technology. The 4-layer architecture allows for the emulation of an almost arbitrary consumer electronics platform on standard car hardware architectures which encapsulates all safety critical system resources. The middleware handles the event routing and transformation and provides services like encryption, routing and transformation. We also show how distributed finite state machines can handle the resource access policies in and between the several virtualization layers in a flexible yet safe way.
On the other hand the IT world was revolutionized by virtualization. Virtualization allows for reducing a variety of hardware to a standardized virtual platform or for emulation of alien platforms on otherwise incompatible hardware. This is achieved by special software the so called hypervisor which traps all system calls to the actual hardware (including processor, network, memory, etc.) and decides based on its configuration whether to allow, modify, delay or forbid the access to the resource requested by the so called virtual machine (VM) running on the virtual platform exposed by the hypervisor. Virtualization is divided into two subcategories. The first category is pure software virtualization which needs operating system support and is often referred to as para-virtualization. The second category is virtualization with support of the hardware where the OS is not necessarily aware that it runs on virtual platform. ParaVirtualization software is beginning to be available for typical embedded platforms like ARM, MIPS and also Intel. Hardware virtualization is only available for some special derivates of ARM and Intel processors.
1. INTRODUCTION
Embedded systems are nowadays in almost every western household and have been there for quite a while already. The last 10 years were characterized by the mobilization and increased visibility and importance of those embedded systems to the consumers in form of smart phones, multimedia players, in car entertainment systems and the like. The latter part of the decade has shown that a widening amount of those customers want to extend the functionality of these devices by installing additional software to those systems. For many platforms this software is mainly provided by a large number of 3rd party vendors, which can develop applications for the respective platforms using public software development kits (SDKs) offered by the platform
Additionally middleware techniques have shown to be of great value when mastering integration of ever growing function points is the challenge. Concepts like Service Oriented Architectures (SOA) and Enterprise Service Busses (ESB) have shown ways to integrate services of a heterogeneous IT landscape into complex distributed applications.
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. CARS '2010, April 27, Valencia, Spain Copyright © 2010 ACM 978-1-60558-915-2/10/04... $10.00.
This position paper proposes the virtual embedded service bus architecture (VESBA) which combines the introduced techniques of virtualization [1] and enterprise service busses with additional
47
features to create a safely extensible and evolvable platform for complex distributed embedded systems like vehicles. The VESBA architecture focuses on safe integration of 3rd party software and updates into in vehicle entertainment functions and consumer electronics integration with full configurable access to the cars Human Machine Interface (HMI). Using such a virtualized architecture would allow executing safety critical software on the same hardware resources as non critical software by any other vendor.
The first thing we wanted to achieve is a safe integration of native, thoroughly tested safety critical software on the one hand and on the other possibly malfunctioning or even malicious software - on the same hardware. Research has shown that virtualization is a valid technology to achieve this and the technology also passed its large scale real life test (e.g. it took the world hacker community over 4 years to find an exploit for the virtualized OS of the Sony® Playstation 3[6]). In addition to that we wanted to allow for running these applications in parallel. This needs a system where the resources are managed in way that high priority safety critical applications are guaranteed to have the necessary resources to fulfill their tasks. This also points to virtualization as a solution since the virtualization software (here called hypervisor) controls the access to all resources and provides them to the guest OSs and thereby to the applications. For real life applications the challenge is to implement a hypervisor that meets the regulations for the car domain.
The following chapter shows current research in this field and where VESBA can ease some limitations of these works. The next chapter describes the proposed architecture in detail. Finally we sum up the major contributions of this paper and give an outlook what is next on our agenda.
2. Related Work
The lack of standards and extensibility in automotive applications has been in the discussion for some years now and has already produced some solutions.
Since integration of consumer electronics devices and consumer applications is becoming more and more important, we also wanted to allow to able to allow emulation of almost arbitrary platforms on the hardware. This would allow running systems like Android or Windows Mobile as guest OSs. The next goal was to provide a flexible way to interconnect independent systems or system parts. The architecture should allow the use of resources like sensors, buttons, displays etc. for all applications in a transparent and safe way. To make the system more stable against changes or updates of system parts also a mechanism to transform messages transparently is needed. Therefore we adopted the idea of a message oriented middleware in form a service bus, which is used for connecting the different system parts logically and which also manages the administration of all connected system parts and their services.
On the body, powertrain and engine level these issues have been addressed by for example AUTOSAR (AUTomotive Open System ARchitecture) [2]. This architectural approach has the so called Virtual Function Bus (VFB) as its key element. All data is transferred over this logical bus regardless of its underlying hardware (so called Microcontroller Unit MCU). While it allows for legacy system integration only applications especially developed for AUTOSAR can run on this platform. Also the system has to be fully tested if changes are applied. Another The past rather monolithic view of vehicle system architecture was overcome by concepts like System Oriented Automotive Engineering (SOAE) [3] which major principles are adhered by VESBA.
The analysis of requirements above convinced us that the most promising approach is a combination of virtualization and a middleware. The middleware provides service abstraction for the underlying car hardware systems (ECU), networks, etc. which then can be used by all other layers. This greatly increases the flexibility of the whole platform and eases the integration of new or legacy systems.
The network safety level and the integration of vehicles into an internet protocol based landscape are also within the scope of recent research initiatives like SEIS (Safety in Embedded IPbased Systems) [4] intending to extend or replace vehicular bus architectures like CAN and MOST. For the in vehicle entertainment area many initiatives and vendors provide platforms like Microsoft Auto (and the already mentioned derivative Ford Sync) or GENIVI[5]/MOBLIN. In our view these platforms take the right direction in providing middleware functionality and hardware abstraction to the software developers. But they do not offer real public 3rd party access to the platform. Also they do not solve the problem of integration of probably malfunctioning software. So far only Ford has released a publicly available software development kit for their platform. But even this software is very limited when comes to access to car functionality.
A robust, safe, easily and safely expandable architecture is assembled on this foundation. We call it Virtual Embedded Service Bus Architecture (VESBA).
3. VESBA
Our solution is based on a multilayer virtualization approach which is supported by a message oriented middleware in form of an Enterprise Service Bus named Virtual Embedded Service Bus (VESB). The architecture is tailored for use in embedded system environments such as automobiles especially in the infotainment section. Safety and robustness are important issues here since the driver should not be diverted. Before we describe this architecture in detail we will describe the major design goals and what patterns or techniques we use to achieve those.
Figure 1 Logical Architecture of VESBA The logical architecture is derived from the XEN architecture [8] and is itself divided into 5 major software domains (see Figure 1 Logical Architecture). The hypervisor running directly on the hardware and is responsible for management of all safety relevant system resources. Every access to those is granted, delayed or
48
dismissed by it. On the level above in the DOM-BASE all real time and critical processes are bundled. These first two layers must meet the same criteria like any other safety critical system. The next layer DOM-CE handles all non safety critical applications which are not customizable. The DOM-3rd domain is used by all other applications which can be provided by the system manufacturer or third parties. There may be existing more than one DOM-3rd domains but only one is active at given time. The data flow and resource management between these layers is provided by the Virtual Embedded Service Bus. It routes the resource requests and resources answers of the DOM-CE and DOM-3rd domains and their applications to the DOM-BASE. The actual resource requests processing is based on a hierarchical Distributed Finite State Machine (DFSM).
finite state machine of the DOM with the highest priority has no rule against it. Figure 3 Full DFSM Exampleshows a more complex example which involves all DOM layers. Here the DOM-BASE layer is for some reason in the state ‘emergency’. That means that it denies all access to all not emergency state relevant resources (e.g. the rear in seat entertainment game processors or the MP3 player). But it allows the access of a customized DOM-3rd phone application to the handsfree system of the car (in-built microphone and speakers) to call for help. Combined with virtualization such an architecture is also able to delay resource requests up to the point where it puts a lower priority level DOM into sleep and start it again transparently. With relatively low effort it can also made to be able to emulate an almost arbitrary platform in the non-real time relevant low priority DOM layers. Therefore one can think of allowing the driver to choose between running e.g. an iPhone or Android based application directly on the cars resources. The middleware could be able to provide information like touch screen coordinates and key presses to those apps in a standardized or even transparent way (by the use of built in protocol transformers)..
Figure 2 Simplified States of DOM-BASE Each state on every DOM level is connected to a set of access rules. Figure 2 Simplified States of DOM-BASEshows the simplified states of a DOM-BASE. The rule set for the state ‘Startup’ could for example define that no other DOM than DOMBASE has access to power supply relevant functions. For DOMBASE the states are derived of the states of real life car software.
Figure 4 Logical architecture of an instance of the Virtual Embedded Service Bus An overview of the VESB functionality is depicted in Figure 4 Logical architecture of an instance of the Virtual Embedded Service Bus
Figure 5 Technical Architecture of VESBA Figure 5 Technical Architecture of VESBA shows how we intend to put the logical concept VESBA into practice. As stated in the introduction we will use para-virtualization techniques based on XEN and the free all purpose platform emulator QEMU to implement a four layer software architecture with 3 layers of
Figure 3 Full DFSM Example The transition of the states is triggered by the same signals as nowadays (e.g. gear change, crash sensor). The general rule is that the access to a certain resources or service is only allowed if the
49
virtualization. In addition to that we will integrate a finite state machine based access control mechanism on each DOM-layer that controls resource access thereby guaranteeing the non-interference of non- safety critical applications.
5. REFERENCES
[1] Baun C., Kunze M., Ludwig T. 2009 Servervirtualisierung. Informatik Spektrum Jun. 2006. Springer. ISSN 0170-6012. 197-205
4. Summary and Outlook
[2] AUTOSAR 2009, AUTOSAR, Main Requirements V2.1.0 R4.0 Rev 1, http://www.autosar.org/download/R4.0/AUTOSAR_RS_Mai n.pdf
In this position paper we presented our view on how an easily extendable, resource saving architecture for embedded systems can be implemented based on commonly used in vehicle hardware. The approach is based on three key technologies namely virtualization, service bus type middleware and distributed finite state machines for resource access control. If combined in our way to an architecture they allow to run almost arbitrary software on the same hardware as safety critical applications. While the architecture itself does not reduce the testing effort of safety critical system parts it safely encapsulates them from non critical applications on the same hardware. Supported by a flexible middleware this allows for system and service abstraction. A way for 3rd party developers is opened to offer their applications on common platforms like iPhone OS, Android, Windows Mobile, S60 etc. without compromising the safety of the car.
[3]
Weber, H., Broy, M. 2009 Systemorientiertes Automotive Engineering. Informatik Spektrum Jun. 2006. Springer. ISSN 0170-6012. 206-213
[4] Innovationsallianz Automotive 2009. SEIS http://www.eenova.de/projekte/seis/ [5] GenIVI Alliance 2008, Genivi Factsheet http://www.genivi.org/portals/9/documents/GeniviFactSheet. pdf [6] Buttari A., Luszczek P. , Kurzak J., Dongarra J., Bosilca G . SCOP3: A rough guide to scientific computing on the PlayStation 3. version 0.1. Technical Report UT-CS-07-595, Innovative Computing Laboratory, University of Tennessee Knoxville, April 2007. [7] Chisnall D. 2008 The Definitive Guide On The Xen Hypervisor. Prentice Hall
We currently working on implementing this architecture and will publish results in another paper soon.
50
