In-vehicle infotainment software architecture: Genivi and beyond – Part 2
Sandbox
Open source operating systems such as MeeGo or Ubuntu are well regarded for their adherence to the latest and greatest multimedia standards and availability of third party applications. However, we cannot necessarily depend on the multimedia OS to control all aspects of next-generation consolidated infotainment systems. General-purpose operating systems cannot boot fast enough, cannot guarantee real-time response for protocols such as CAN, and are not reliable and secure enough for safety-critical functions such as rear-view camera and integrated clusters. Therefore we need a system architecture in which multimedia operating systems and their applications can peacefully coexist with real-time, high assurance applications, hosted on a real-time, safety-rated operating system.
One potential solution is to have multiple processors dedicated to the differing tasks. However, this results in the same issues as today’s multiple ECUs, lowering the speed of communication between applications and increasing boundary complexity.
The need to contain these functions on a single processor is very real, enabling optimisation of cost, processing cycles, data availability, and complexity. We need sandboxes for these mixed-criticality workloads. One can think of each sandbox as an isolated persona.
The following four approaches to multiple personas have been commercialised in one form or another:
- Multi-boot
- Webtop
- Type-2 hypervisor
- Type-1 hypervisor
Multi-boot
The multi-boot concept was attempted on a handful of laptops and netbooks over the past few years. In a dual boot laptop scenario, a secondary operating system, typically a scaled down Linux, can be launched in lieu of the main platform operating system. The scaled down system is typically only used for web browsing, and the primary goal is to enable the user to be browsing within a handful of seconds from cold boot. The secondary operating system resides in separate storage and is never running at the same time as the primary platform operating system. In some cases, the lightweight environment executes on a secondary microprocessor (e.g. an ARM SoC independent of the netbook’s main Intel processor).
The secondary operating system has good isolation from a safety perspective; however, the inconvenience of rebooting and inability to seamlessly switch between personas has severely limited adoption. The multi-boot option is also impractical in a consolidated infotainment environment that requires concurrent execution of the personas, for example the multimedia infotainment subsystem along with the cluster and real-time network communications.
Webtop
The webtop concept provides a limited browsing environment (the webtop) independent from the primary operating system environment. However, instead of a dual boot, the webtop runs as an application on top of the primary operating system. As long as the webtop runs the non-safety critical portions of the system, and the primary operating system is capable of hosting critical applications, isolated from the webtop, then this approach may provide the requisite sandboxing. However, a browser-based environment may not meet the rich functional requirements of modern infotainment systems.
A related approach is to launch the webtop or replicated display from a docked smartphone. This too would provide the requisite sandboxing (the smartphone’s processor is used for the multimedia applications instead of the in-car infotainment computer). This smartphone remoting technique has been test marketed on some vehicles and remains an interesting option. One of its challenges is ensuring that the smartphone can deliver an automotive-tailored experience.
Type-2 Hypervisor
Type-2 hypervisors are similar to webtops in that the secondary persona runs as an application on top of the primary operating system. However, instead of hosting only a browser, the secondary persona is a full-fledged guest operating system running within a virtual machine created by the hypervisor application (Figure 4). This guest operating system could be a real-time operating system suitable for hosting critical applications such as rear-view camera or cluster. The hypervisor uses the primary operating system to handle I/O. The virtualisation approach meets the requirement of providing complete functional environments for both critical and non-critical personas.
Figure 4 – Type-2 hypervisor: application on top of a general-purpose operating system
However, the Type-2 model fails to provide strong isolation. Faults or security vulnerabilities in the primary general-purpose operating system will impact the real-time, critical functions running in the virtual machine. Furthermore Type-2 hypervisor applications deployed in the enterprise space have themselves been found to contain vulnerabilities that break the sandbox.
Type-1 Hypervisor
Type-1 hypervisors also provide functional completeness and concurrent execution of the multiple personas. However, because the hypervisor runs on the bare metal, persona isolation cannot be violated by weaknesses in the persona operating systems. Thus, a Type-1 hypervisor represents a promising approach from both a functionality and safety perspective. However, the hypervisor vulnerability threat still exists, and not all Type-1 hypervisors are designed to meet high levels of safety and security.
One particular variant, the microkernel-based Type-1 hypervisor, is specifically designed to meet the demanding real-time, fast-boot, safety requirements of modern infotainment environments. Microkernels provide a superior architecture for safety and security than large, general-purpose operating systems such as Linux, MeeGo, Android, and Windows. A microkernel runs only a minimal set of critical system services, such as process management, exception handling, and inter-process communication, in supervisor mode and provides an architecture that enables complex systems software to run in user mode where they are permitted access only to the resources deemed appropriate by the system designer. A vulnerability or fault in one component cannot cause damage to a critical component because the infected subsystem simply does not have access to that resource. Because the microkernel is relatively simple, it can be formally verified and certified by independent regulators to the highest levels of safety and security.
In a microkernel Type-1 hypervisor, system virtualisation is built as a service on the microkernel. Thus, in addition to isolated virtual machines, the microkernel provides an open standard interface for lightweight critical applications, such as driver information clusters, cryptographic subsystems, and CAN bus drivers, which cannot be entrusted to a general-purpose guest. The microkernel Type-1 architecture is shown in Figure 5.
Figure 5 – Microkernel Type-1 hypervisor architecture
One example of microkernel Type-1 hypervisor is Green Hills Software’s INTEGRITY Multivisor, built upon the INTEGRITY microkernel, used extensively in automotive infotainment and other real-time, safety-critical applications.
Applying the microkernel Type-1 hypervisor architecture to the aforementioned mixed criticality infotainment system, consisting of the main infotainment OS and safety-critical applications for rear-view camera and driver information cluster, results in the architecture shown in Figure 6.
Figure 6 –Microkernel Type-1 architecture for next-generation infotainment systems
Secure Network Transactions
Figure 6 also shows a manageability application. Another useful application of the microkernel Type-1 architecture is to host secure remote communication subsystems natively on the microkernel. Examples of next-generation secure network transactions in infotainment systems include protected multimedia content and digital rights conveyance and remote system management (e.g. firmware upgrades and remote diagnostic commands) by technicians and OEMs.
A key idea here is that this solution creates a protected connection, logically out-of-band from the main system. Because encryption keys, server certificates, and protocol software are managed within native lightweight processes, these critical data cannot be stolen or corrupted by the guest operating system, regardless of malware infiltration. Furthermore, the native security subsystem is able to take advantage of TPM (or equivalent) capabilities, if present, for hardware-based storage of keys and for platform attestation. The secure connection defeats man-in-the-middle attacks as well as malware attacks that would attempt to commandeer the cryptographic keys used for secure communications.
Genivi
Genivi is an industry alliance promulgating in-vehicle infotainment reference platforms, with the goal of reducing time-to-market and development cost. These reference platforms include the pre-competitive features that every system is deemed to need, allowing individual organisations to concentrate on innovative features that drive competitive advantage. A core principle towards meeting these goals is a focus on open standards and associated compliance certification. With the traditional infotainment system role fulfilled by powerful general-purpose operating systems, it should come as no surprise that Genivi’s initial reference platforms are focused on Linux distributions that meet the requirements of the Genivi compliance statement.
Looking forward, automotive infotainment stakeholders, including OEMs and their suppliers, government regulators, and passengers, must look beyond the multimedia system to a new world of mixed criticality requirements. Next-generation systems software architectures are required in order to ensure that future complex, feature-rich infotainment systems are delivered with the reliability, security, real-time performance, and controlled footprint that the automotive industry and consumers alike demand. Future in-car systems will see a convergence of safety-critical functionality with traditional telematics and digital entertainment applications. Bringing these capabilities onto a single compute platform is critical in order to minimise size, weight, power, production cost, and electronics complexity. However, doing this safely requires a new systems architectural approach.
One promising sandboxing approach is Type-1 system virtualisation that can isolate and manage real-time, safety, and security-critical applications alongside powerful open source multimedia operating systems. In addition, the availability of virtualisation technology across a wide range of computing platforms provides developers and technologists with the ultimate open platform: the ability to run any flavour of operating system in any combination, creating an unprecedented flexibility for deployment and usage. This flexibility is as welcome in the automobile as it is in desktops and servers.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
