Safety and Multimedia Collide in Next-Generation Automobiles
As experience-rich functionality proliferates in today’s automobiles so does complexity
and the likelihood that it could conflict with operation- and safety-critical software
systems. A sure means must be found to maintain secure separation and hypervisors offer
a solution.
David Kleidermacher, Green Hills Software
At last year’s CES trade show, I saw a snazzy car demo in which each rear-seat passenger
had a different high-definition movie playing on the two screens mounted on seat backs.
Neither display device had a connector – the movies were being received wirelessly.
Moreover, the movies were being streamed simultaneously from a 4G wireless
connection to the car’s internal ad-hoc wireless network. Cool stuff, especially if we
neglect the data plan bill!
Smartphones are being integrated into the car, not only for multimedia content, but also
for automotive-targeted application and services delivery and remote control. Yes, these
next-generation automotive multimedia applications are mind blowing. But they are not
limited to entertainment. Let’s have a look at what is new in the area of informatics and
safety.
My brother just bought a car with Surround View, which provides a virtual aerial display
of the car and its surroundings to aid in backing up and parking. A couple months ago,
BMW announced a new iDrive system that includes 3D mapping navigation. BMW also
recently introduced a heads-up display (HUD) with 3D augmented reality right on your
windshield.
Other Advanced Driver Assistance Systems (ADAS) include lane departure and blind
spot warnings, predictive forward sensing (a Nissan automobile looks two cars ahead for
collision avoidance), autonomous parking (after the car has dropped you off) – just to
name a few.
In a nutshell, multimedia sophistication is growing rapidly in cars, providing enhanced
user experiences - for entertainment, informatics, and safety. These electronic systems
run incredibly sophisticated software stacks, including GENIVI Linux, Android, and
Windows Car. While tremendously capable, we also know these environments represent
a world of rootkits, blue screens of death, and Patch Tuesdays.
Indeed, automotive safety applications have traditionally consisted of carefully coded
real-time software, developed to stringent quality standards and executed on simple, realtime kernels such as OSEK and AUTOSAR.
So how do automotive OEMs reconcile the need for safety with the desire for bells,
whistles, and app stores – where innovation is ultimately driven by consumer electronics
grade, rather than automotive grade, technology?
For years, automotive OEMs have sought to stovepipe and isolate the safety systems
from multimedia components and other non-safety related systems. In fact, the supply
chain in the automotive world encourages this: the OEM hires different Tier-1 suppliers
to build boxes for each individual function in the car and relies on in-car automotive
networks, such as CAN, to provide limited interactions between them. With high-end
cars reaching 100 such boxes, 200 discrete CPUs across all these boxes, and numerous
intra-vehicular networks connecting them all up, this trend has begun to reach the limit in
what can be practically developed and deployed. Electronics growth poses a significant
production cost, physical footprint, and time- to-market challenge for automotive
manufacturers.
There is another, perhaps less obvious, problem with the traditional stovepipe approach:
ultimately, it stifles the passenger experience. The cluster can only display navigation
information if the OEM’s RFPs for the cluster and navigation boxes included a specific
requirement for such an information flow. Once the boxes are deployed, other
interactions, potentially integrating and improving the overall experience of both
components, become difficult or impossible, both technically and financially.
The response to these efficiency challenges is to reverse the electronics growth trend and
instead merge disparate functions into a fewer number of electronic components. If
multiple functions can run on a single box, the physical wires become virtual wires;
software improvements affect only a single box instead of multiple boxes. The
performance and flexibility of communication within a single computer is far better than
across a vehicular network. The consolidation trend is aided by next-generation powerefficient multicore SoCs – based on ARM’s Cortex A9 and A15 - with gobs of integrated
I/O such as wireless networking and multicore GPU. Examples of these monsters include
the TI OMAP5, Freescale i.MX 6Quad, and Nvidia Tegra 3.
Processor consolidation is pushing the automotive world inexorably towards mixed
criticality systems in which safety, security, or real-time critical components must coexist
with less critical components. For example, consolidating the infotainment head-unit with
the real-time, safety-critical rear-view camera and/or driver information cluster
components can result in a mixed-criticality system, as shown in Figure 1. Nextgeneration infotainment system architecture must ensure that consolidated components
do not interact in unforeseen ways, posing a reliability risk to critical systems.
Solution: Hybrid Architecture
Open source operating systems such as GENIVI and Android are well regarded for their
adherence to the latest and greatest multimedia standards and availability of third party
applications. However, we cannot depend on the multimedia OS to control all aspects of
next-generation consolidated automotive systems. General-purpose operating systems
cannot boot fast enough, cannot guarantee real-time response, and are not reliable enough
for safety-critical functions. Therefore we need a hybrid architecture in which multimedia
operating systems and their applications can peacefully coexist with real-time, safetycritical applications. Virtualization is the obvious answer to this challenge.
Computer system virtualization was first introduced in mainframes during the 60s and
70s. Although virtualization remained a largely untapped facility during the 80s and 90s,
computer scientists have long understood many of the applications of virtualization,
including the ability to run distinct and legacy operating systems on a single hardware
platform.
At the start of the millennium, full system virtualization, hosting unmodified, general
purpose, “guest” operating systems such as Linux and Windows, was proven practical on
common PC platforms. Subsequently, hardware virtualization acceleration technologies
have become common in most major microprocessor architectures. While virtualization
may be best known for its application in data center server consolidation and
provisioning, the technology has proliferated across desktop and laptop-class systems,
and has most recently found its way into mobile and embedded environments.
The availability of virtualization technology across such a wide range of computing
platforms provides developers and technologists with the ultimate open platform: the
ability to run any flavor of operating system in any combination, creating an
unprecedented flexibility for deployment and usage.
Hypervisor Architectures
Hypervisors are found in a variety of flavors. Some are open source; others are
proprietary. Some use thin hypervisors augmented with specialized guest operating
systems. The goals of robust isolation between mixed criticality components within nextgeneration infotainment systems are achievable in Type-1 hypervisors that run on bare
metal. Type-2 hypervisors run atop a general-purpose operating system, such as
Windows or Linux, which provide I/O and other services on behalf of the hypervisor.
Because Type-2 hypervisors, fundamentally, can be no more robust than their underlying
host operating systems, which are well known to be vulnerable, they are not suitable for
safety-critical deployments and have historically been avoided in such environments.
Thus, Type-2 technology is omitted from this discussion.
Microkernels provide a superior architecture for safety than large, general-purpose
operating systems such as Linux, Android, and Windows. A microkernel runs only a
minimal set of critical system services, such as process management, exception handling,
and interprocess communication, in supervisor mode and provides an architecture that
enables complex system software to run in user mode where it is 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. Microkernels can therefore be used to implement system virtualization.
The microkernel-based Type-1 hypervisor architecture is shown in Figure 2. Green Hills
Software’s INTEGRITY Multivisor is an example of this technology.
CPU hardware virtualization assistance has been a key factor in the growing adoption of
full virtualization throughout the computing world. Typical features include a true
hypervisor mode that enables unmodified guest operating systems to execute with
reduced privilege. For example, the CPU will prevent a guest operating system from
referencing physical memory beyond what has been allocated to the guest’s virtual
machine. In addition, hardware virtualization enables selective exception injection, so
that hypervisor-defined classes of exceptions can be handled directly by the guest
operating system without incurring the overhead of hypervisor software interposing. The
TI OMAP5 and its automotive derivatives are an example of multicore ARM processor
that includes hardware support for virtualization known as ARM VE—ARM
Virtualization Extensions .
The microkernel also provides an applications programming interface (API) and software
development kit (SDK), enabling the creation and deployment of safety-critical
applications (including those that follow automotive standards such as OSEK) that must
meet hard real-time, safety-critical, or other stringent requirements that cannot be
relegated to a general-purpose guest.
In many of the aforementioned next-generation multimedia-rich safety systems, the
microkernel must be capable of hosting its own sophisticated graphics environment,
distinct from the general purpose OS used for head unit activities. For example, 3D
graphics are required to implement high-end safety-critical applications in clusters and
heads-up displays. Therefore, the microkernel provides an OpenGL subsystem optimized
for the on-chip GPUs found in common multicore application processors.
The microkernel is the only software that runs in the microprocessor’s most privileged
mode (e.g. hypervisor mode). Guest operating systems and their constituent applications
execute in a de-privileged mode, untrusted from microkernel’s perspective.
Applying the microkernel Type-1 hypervisor architecture to the aforementioned mixed
criticality infotainment system consisting of the main infotainment OS, MeeGo, and
safety-critical applications for rear-view camera and driver information cluster results in
the architecture shown in Figure 3:
Next-generation system software architectures are required in order to ensure that future
multimedia-rich automotive systems are delivered with the reliability, safety, 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 minimize size, weight, power and
production cost and, ultimately, to deliver the best possible user experience. However,
doing this safely requires a new systems architectural approach, at the base of which is a
microkernel-based hypervisor that can isolate and manage real-time, safety, and securitycritical applications alongside powerful open source multimedia operating systems.
Green Hills Software, Santa Barbara, CA. (805) 965.6044. [www.ghs.com]