[Part 1 discusses next-generation infotainment system architectural approaches that address automotive networking security issues from the ground up.]
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:
- Type-2 hypervisor
- Type-1 hypervisor
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.
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 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).
Figure 4 - Type-2 hypervisor: application on top of a general-purpose operating system
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.
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.