CES has become an important event for automakers to showcase their cars and, especially, the electronics in these cars. Automotive was a top line item in 2012, and 2013 will be no different. This trend is not surprising, considering that since the 1930s, when the Galvin brothers and Blaupunkt introduced the radio into the automobile, consumer electronics have played an important role in automobile buying decisions.

The advent of smartphones and the cloud have complicated this long and complicated relationship between the automobile and consumer electronics. Consumers now expect their in-vehicle systems to keep pace with consumer devices.

In 2009, the Hansen Report quoted Ricky Hudi, Chief Executive Electrical Engineer, Electric/Electronics at Audi: “First tier suppliers of infotainment systems are really struggling because of the high cost of developing these complex systems.” Audi has received high marks for its MMI infotainment system, but for some automakers, such systems are increasingly the cause of post-sales consumer complaints. Jake Fisher, director of automotive testing for Consumer Reports notes that “issues with electronics, audio and touch-screen systems have increased while complaints about mechanical problems are down.”

Development cycles and computing resources
Meeting consumer expectations is particularly difficult because of the difference in the lifecycles of cars and consumer electronics. For a car, design to start of production (SOP) is three years or more, while consumer electronics may become obsolete in less than a year—to say nothing of applications.

The cloud is further changing expectations; consumers now expect near-infinite computing resources that are always current, and they want vehicle connectivity to support these expectations.

Table 1 lists the most common models for integrating smartphones and vehicle head units.

Table 1. Common head unit-smartphone integration models

The cloud
The cloud is widely used by navigation applications, and is gaining acceptance with online music services. With cloud services, a small application on the head unit runs the HMI, while the application itself runs on the service provider’s servers. See Figure 1. Benefits include:

• Increased computing resources can improve performance for non-essential services.
• Updates to applications are the responsibility of the service provider, so the user doesn’t need to worry about them.
• New services can be added at the back end without needing to touch the vehicle.
• Users maintain control of their systems, subscribing to services or unsubscribing from them as desired.
• Interoperability between the vehicle head unit and portable devices enables “drop-and-drive” implementations.
• Costs can be reduced because, with the almost limitless computing resources of the cloud available, cars need less powerful CPUs and less memory.

Cloud services also have some limitations:
• Connectivity—cloud services rely on a continuous, high-throughput connection. They are of little use in areas with poor coverage; for example, outside transportation corridors or in urban canyons.
• Limited uses—the possibility of a cloud service becoming temporarily unavailable restricts its usefulness to non-essential applications.
• Cost—cloud-based services may incur usage charges, making them impractical for low-cost options.

Which model?
There is no single “right” model for using smartphones and cloud services with an in-vehicle infotainment system. Considerations that should inform automakers’ strategies for their infotainment systems include:

Portability—“drop-and-drive” technologies can automatically hand over whatever is running on a smartphone or tablet to an in-vehicle system. Users will continue expecting this convenience, but automakers need to ensure that nothing can compromise vehicle safety.

Computing power—the shorter lifecycle of smartphones means that their computing power will quickly surpass the resources of many vehicle head units. Offloading non-critical tasks to the phone can help reduce the head unit bill of materials (BOM) and extend the life of the infotainment system. Applications and services that use on this model may not be as reliable as those that run exclusively in the head unit, however.

Connectivity—a car-mounted antenna can be larger and more powerful than a phone antenna, which may also suffer from shielding inside the car. It might be wise to use smartphones for running applications, but the car for connecting to the network.

Interoperability—automakers shouldn’t count on all users having an appropriate smartphone or remembering to bring their phone and having it charged. They must anticipate the performance expectations when no phone is available.

HMI—handing everything over to the phone may not be a good idea: the phone UI is not designed for a car. The user interface will likely require adaptation. See Figure 2. Plus, applications and services are likely to be built with a variety of technologies, which the head unit will need to support.

New applications and updates—the infotainment system will need to manage new applications and updates, providing a quarantine area for untrusted software and ensuring that updates don’t compromise essential services.

Power—automakers will need to provide power to phones to ensure that they are always accessible.

Unknowns—it is impossible to predict what consumers will want, or even what will be available in, say, five years. An infotainment system should be designed to easily integrate new technologies as these become available.

Technologies based on open standards hold great promise for automakers. HTML5, for instance, is a group of non-proprietary standards for delivering content and functionality. Strictly, HTML5 is the next standard for web page rendering. In the more common usage, , HTML5 includes the HTML5 standard itself, plus ancillary standards and technologies, such as CSS3 and JavaScript. Many assume that an HTML5 environment is “just a browser.” In fact, HTML5 provides the capabilities of a traditional HMI toolkit, but with more flexibility, a better programming model, and inherent support for connected applications.

Key to the HTML5 long-term strategy is that no one owns the standards, so there is no vendor lock-in and, hence, no single point of failure. Further, significant players, including Apple, Microsoft, and RIM, are building important stakes in the success of this standard.

Generally, the following can be said of HTML5 for in-vehicle systems:

• It is non-proprietary and will be here for a long time, so automakers don’t have to worry about locking in to a technology that will soon be rendered obsolete.
• It supports any combination of content and service delivery—web, on-device applications, cloud-based services, etc.—and is ideal both for keeping in-vehicle systems current and for integrating them with smartphones.
• It provides a rich application environment that supports virtually anything that other technologies can do; and it can be used with other technologies (OpenGL ES, Adobe Flash, native graphics, etc.). See Figure 3.
• It has a vast ecosystem, with a talent pool that is both deep and wide on which automakers can draw for their HTML5 projects.

Thus, with HTML5, automakers have standards that are becoming ubiquitous and will be around for a long time. They can bring anything in HTML5 froma smartphone or the cloud into their cars, using CSS3 to filter functionality, and ensure the in-vehicle HMI meets usability and safety requirements—all without changing underlying functionality or technology. In short, with HTML5, automakers can build the HMIs they want and keep their systems up to date. If something is newly available on a smartphone, with HTML5 it can be made available in a car built three years ago.