IVI system sandboxing: The next frontier for in-vehicle upgrades
April 01, 2014
With the rapid advancement of mobile, cloud, and embedded technologies, it may surprise most that In-Vehicle Infotainment (IVI) systems are typically...
Primarily, the bloated IVI development lifecycle can be linked to two factors: driver safety and vehicle longevity. Although most people associate IVI systems with just navigation and entertainment, these systems also interact with many critical vehicle safety components such as driver assistance, engine control, and vehicle sensors. This means that all IVI systems must go through significant testing, evaluation, security, and certification processes. In addition, vehicle manufacturers need to ensure that an IVI system will remain operational for the duration of a vehicle’s 10-15 year lifespan.
Unfortunately, even the sleekest of vehicles on the market today are equipped with IVI systems that contain old software and unattractive user interfaces. Furthermore, consumers do not currently have the option to upgrade their IVI systems through new software rollouts or third-party applications. And while some people do trade in their vehicles every two-to-three years, for most of us purchasing a car is a long-term investment. According to automobile information analysis firm R.L. Polk & Co., the average age of automobiles in the U.S. is rising. Assuming this trend continues, many consumers will be stuck with an outdated IVI system for the next nine-to-ten years.
Customizing the car
What if IVI systems could be customized and continuously upgraded like smartphones or tablets? What if drivers could listen to music through their Pandora account, share their location via Facebook, or take a call on Skype? What if online marketplaces like iTunes and Google Play started offering IVI-specific apps? With the rising demand for consumer device customization, it’s just a matter of time before these rhetorical scenarios become the new standard.
The Android platform is especially ripe for IVI customization efforts, as it is an open source wonderland for developers. Whereas iOS remains a proprietary Apple technology, Google has opened Android up to a wide variety of uses, which is why it is currently dominating in the mobile space.
However, Android does have some major drawbacks that must be addressed before it can be utilized for IVI applications. For example, from an automotive perspective, Android has a slow boot time and does not meet the industry’s strict security and stability standards. The average boot time on an Android-based device is 40 seconds. While this is an acceptable length of time for a mobile device that rarely gets shut off, it becomes a bigger problem in a vehicle. Since most people immediately begin driving after turning on the car, a long IVI system boot time would result in drivers pulling up a map or a play list while the vehicle is in motion – further adding to distractions while driving.
Furthermore, drivers cannot simply restart their vehicles if the IVI system crashes. An unstable Operating System (OS) is inconvenient in a mobile device, but it’s downright dangerous in a vehicle. And if a driver downloads a third-party IVI app whose settings override those of the vehicle’s operational components, it could seriously compromise the vehicle’s security and functionality, from altering diagnostics and sensor parameters to disabling emergency services.
While slow boot times and operating speeds can generally be resolved by modifying the Android OS distribution for an “automotive-grade” platform, the real challenge lies in balancing the innovation of Android with the stringent safety and reliability requirements of the automotive industry. How can a single system be flexible and modular for consumer customization while at the same time ensuring uncompromised security and reliability?
Hypervisor sandboxing splits safety-critical from software-upgradeable
The unfortunate truth is that there is no way to combine these two conflicting demands – nor should we try. Instead of managing one complex and potentially flawed OS, the goal should be to run two completely functional and sandboxed systems. By leveraging an open source, “bare metal” Xen hypervisor, developers could simultaneously run two different OSs on a single System-on-Chip (SoC) to provide:
- Highly reliable automotive-grade Linux or Real-Time Operating Systems (RTOSs) like Autosar and QNX for mission-critical vehicle software
- Highly customizable Android for infotainment software
A hybrid architecture that is based on a Type-1 hypervisor would allow developers to create an Android-based IVI system without compromising the functionality, security, or reliability of the vehicle’s operational software. Critical components such as vehicle sensors, diagnostics, and emergency services would never be impacted by third-party apps, as they would be completely enclosed within their own respective OSs (Figure 1). Sandboxed Linux and Android operating systems give developers the freedom to create truly customizable infotainment software without negatively impacting a vehicle’s security or reliability.
Although still a relatively untapped field, it’s only a matter of time before IVI systems become just as customizable as any other mobile device. While Android still has some issues around reliability, security, and speed to address before it can become truly “automotive grade,” it is an ideal OS for IVI customization. By modifying Android to accelerate operating and boot time speeds, and by leveraging a hybrid architecture to separate a vehicle’s mission-critical and infotainment components, developers can begin shaping a new and industry-changing market for automotive software.