While Bluetooth is a step in the right direction toward device integration, it is still a flawed technology that often cannot keep up with the devices it's trying to connect. Even Doron Elliott, Ford's Bluetooth global lead, admits, "Automotive works at one cycle and mobile devices work at another cycle."[1] While most new smartphones are developed within a year, a new vehicle's electronics were probably developed 4-5 years ago due to stringent certification processes. It's simply not cost-efficient for automotive manufacturers to be continuously re-testing and re-certifying their systems in order to introduce frequent software updates.

In addition to extended development lifecycles, the very infrastructure of a vehicle prevents automotive manufacturers from attaining the levels of innovation seen in other technology industries. Since all of a vehicle's functions are managed by computers that are physically located within the vehicle, there is a limit to how many features can be implemented. Each vehicle computer must also be rigorously tested, making it very difficult to reuse software across multiple machines. Furthermore, a vehicle's computers must be manually accessed in order to analyze or repair software issues. Can you imagine bringing your iPhone to the Apple store every time you needed to update your operating system (OS) or install a software patch?

As the Internet of Things (IoT) becomes the new norm, with all of a consumer's devices connecting and integrating with each other, the automotive industry needs to take a page from the Apple and Google playbooks. Consumers are no longer satisfied with solo-functioning devices, whether it's a phone or a tablet or even a car. Of course, the million-dollar question is, "how does the automotive industry boost its innovation potential while remaining compliant with stringent regulations?" The answer is actually fairly simple: virtualization.

Why virtualization?

For those unfamiliar with the technology, virtualization leverages computer software, such as a hypervisor, to run multiple virtual computers (even those with different OSs) on a single piece of hardware. From Amazon's Infrastructure-as-a-Service (IaaS) offering to the U.S. Department of Defense's operational infrastructure, virtualization has become the go-to solution for secure, scalable computing.[2, 3] Furthermore, today's vehicle hardware finally has the capacity to support virtualization with minimal impact to performance or security.

As you can imagine, virtualization would open up a new realm of possibilities for automotive manufacturers and software developers alike. As mentioned earlier, vehicles are currently limited to a finite set of features based on the physical footprint of its multiple computers. Even with recent improvements in vehicle CPU processing power, there are only so many programs these computers can run. Creating virtual machines (VMs) that run off a single computer would enable manufacturers to offer an infinite number of features and passenger customization opportunities. For example, each seat in a vehicle could have its own unique VM, enabling passengers to customize their vehicle environments, from chair settings to radio stations. Backseat passengers could even watch separate movies on their LCD screens (a boon to family road trips everywhere).

Beyond passenger convenience, virtualization offers many time and cost benefits to stakeholders across the automotive landscape. Maintenance becomes more efficient since software repairs and upgrades can be done remotely rather than having to manually access the vehicle. Similarly, a virtualized environment significantly accelerates software development since everything runs on the same piece of hardware and therefore only needs to be tested once. Furthermore, since each VM is completely sandboxed, manufacturers can leverage different operating systems within a single vehicle (for example, QNX or AUTOSAR to manage mission-critical features and Android, Tizen, or Linux to manage in-vehicle infotainment (IVI) and introduce cutting-edge features).

Implementing a high-level OS (HLOS) like Android in a virtualized environment would also enable consumers to customize and "connect" with their vehicles through downloadable automotive apps. Imagine if your vehicle could send you a text message whenever its oil level or tire pressure was low. Imagine if you could start or even track your vehicle directly from your phone. Imagine if your garage door automatically opened when you pulled into the driveway.

In fact, some of these options are already available in the market today. The problem is that these services require consumers to buy third-party hardware that either they or their vehicle dealership must install. With virtualization, consumers would be able to simply download an app from an automotive-grade market. Just as you currently download apps to make your smartphone a more powerful tool for your lifestyle, so too could automotive apps expand the utility of your vehicle (Figure 1).

Integration challenges (and solutions)

As with most things, virtualizing a vehicle's software system is easier said than done. Part of the reason the automotive industry is so slow to innovate is its incredibly stringent safety and certification standards. Although HLOSs like Android, Tizen, and Linux would provide automobile manufacturers with innovative new machine-to-machine (M2M) and customization opportunities, they are inherently less stable than the QNX and AUTOSAR OSs that are used in vehicles today. This is why an intelligent system architecture is crucial to successful virtualization.

A sample diagram that illustrates how virtualization could be implemented in the automotive industry is shown in Figure 2. As you can see, a Xen Type 1 (in other words, baremetal) hypervisor sits on top of the vehicle's physical computer and manages various VMs. Related software systems are grouped together in function-specific machines that are completely sandboxed from each other. This means that even if your Android-operated IVI system crashes, your mission-critical drivers – which are sitting in a separate machine and running on the ultra-reliable QNX or AUTOSAR OS – will not be affected.

Although a hypervisor like Xen offers the greatest functionality (and reliability) for running multiple VMs, it's difficult to certify because it's open source software. With a global community of developers continuously developing and improving the hypervisor (and using different processes and technologies to do so), it cannot pass ISO 26262 certification. While one solution is to use a private hypervisor, it cannot offer the same level of innovation (nor time-to-market) that stems from tapping into a global community of developers. Private hypervisors also typically come with hefty per-unit royalties. The challenge, then, is to align the dynamism of the open source community with the stability of the automotive industry's standards.

To address this challenge, GlobalLogic, Inc. is currently developing a unique procedure for certifying an open source hypervisor. After performing a detailed risk and gap analysis for a specific version of the Xen hypervisor, the hypervisor is then modified and verified to meet ISO 26262 standards. With a certified hypervisor in-hand, automotive-grade software can be successfully developed for customers. Over time, the Xen version can also be re-analyzed and re-certified as the open source community adds new features.

Of course, the industry will soon need to create a whole new set of standards to screen potential automotive-grade applications. The whole point of implementing a HLOS within a virtualized environment is to enable consumers to customize their vehicles the way they do with their other smart devices. This means creating an app market like iTunes or Google Play that is specifically focused on the automotive industry. Although it's possible that some manufacturers may opt to develop all their customization apps in-house, this approach would be very time-consuming and cost-prohibitive – not to mention a major roadblock to innovation.

On the other hand, adopting a free market approach to automotive apps poses some inherent risks, such as bugs hitching a ride into a vehicle's IVI or instrumental cluster system. Although mission-critical drivers would not be harmed due to the sandboxed architecture, a virus could still wreak havoc on the affected module. To this extent, a major challenge to automotive manufacturers in the future is to create a strong system for screening app submissions. Manufacturers must also architect their virtualized systems in such a way that consumers cannot "jailbreak" their vehicles. While jailbreaking a smartphone rarely results in more than potentially lost revenue for service providers, jailbreaking an automotive system could result in user safety concerns.

A truly "connected" car

Although reliability, security, and certification issues may deter the automotive industry from being completely in-sync with faster-paced industries like mobile, a virtualized approach to automotive software systems can get it remarkably close. By leveraging an ISO 26262 certified hypervisor to run a system of sandboxed VMs on both industry-standard and HLOSs, automotive manufacturers can design vehicles that are both safe and cutting-edge. Because in an age where a phone is more than just a phone, shouldn't a car be more than just a car?

Alex Agizim is Chief Technology Officer of Embedded, GlobalLogic Inc.

GlobalLogic, Inc. www.globallogic.com @GlobalLogic linkedin.com/company/globallogic

References:

1. http://www.edmunds.com/car-technology/bluetooth-in-your-car-still-indispensable-still-imperfect.html
2. http://openfoo.org/blog/amazon_ec2_underlying_architecture.html
3. http://www.vmware.com/files/pdf/vmw-DHDW-desktop-solution-DoD-case-study.pdf