By Kerry Johnson, QNX Software Systems

Already, vehicle telematics services have been deployed in tens of millions of automobiles. Nonetheless, mobile services offered on smart phones and other consumer devices are growing at a far greater pace. A quick survey of these mobile services reveals that many offer significant utility to drivers or passengers; in fact, some are designed specifically for in-vehicle use. These services include maps with local search capabilities that find restaurants and other points of interest, applications such as Google Latitude that locate nearby friends, and services that can find the closest parking spot or the lowest nearby gas price.

Cars, Clouds and Pockets:
click to enlarge

Figure 1. The remote terminal approach.
These mobile services fill a need poorly served by the embedded telematics offerings currently available from automakers. This situation is unlikely to change, for the simple reason that the development cycles for automotive systems are, and will remain, longer than those for mobile devices and services.

Recognizing this problem, automakers are finding new ways to leverage the consumer mobile service infrastructure and to bring internet-based services into the vehicle. To achieve this goal, they must not only enhance connectivity between the head unit and the mobile phone, but also implement techniques that minimize driver distraction and enable safe, reliable upgrades.

Leveraging “Pocket Apps”
Until recently, in-vehicle systems that connect to consumer devices have focused on providing hands-free voice communications and music playback. Typically, hands-free systems use the Bluetooth Hands Free Profile (HFP) to connect with mobile phones, while infotainment systems use a combination of USB and Bluetooth profiles. These Bluetooth profiles include the Audio/Video Remote Control Profile (AVRCP) to control media playback and the Advanced Audio Distribution Profile (A2DP) to stream audio from the consumer device.

Cars, Clouds and Pockets:
click to enlarge

Figure 2. The remote skin approach.
In addition to voice and music, smart phones now offer a number of navigation and location-based services intended for in-vehicle use. To help with the task of driving and to prevent fumbling with controls, the phone is often mounted on the dashboard or windshield. But even so, the small screen, vehicle mounting options, and input mechanisms often force drivers to take their eyes off the road and hands off the wheel.

Nevertheless, automakers have a strong desire, fueled by customer demand, to leverage the “pocket applications” and Internet services available on consumer devices. To do so, they must safely integrate these services into the driving experience and employ new connectivity options that allow arbitrary data exchange between the infotainment system and the consumer device. Building on Bluetooth as the foundation, they can choose from a range of connectivity options that typically use the Bluetooth Serial Port Profile (SPP) and application-specific protocols over TCP/IP.

Remote Terminal Access
For years, enterprise users have employed remote terminal technologies such as VNC and Windows remote desktop to access remote computers and perform remote troubleshooting. More recently, remote terminal access has found a role in smart phones, where a terminal client on the phone lets the user see and control a remote application.

In the automotive environment, the roles reverse: the smart phone becomes the server and the vehicle infotainment system becomes the client. Using VNC as a base technology, the client software displays the graphical user interface implemented on the smart phone. The client software also converts user inputs from the car — such as haptic controls, steering wheel buttons, and the touch screen — to the corresponding controls for the mobile phone application.

The problem is, simple screen and input translation cannot, on its own, provide a user interface appropriate for driving. To be useful, a pocket application needs to present a different user interface — or a “car mode” user interface. To maintain driver safety, the infotainment system and the smart phone must work in conjunction to block applications that don’t present a car mode interface while the vehicle is moving.

Remote Skin
To address the driver distraction problem, the car’s infotainment system can provide a lightweight user interface application — a “remote skin” — that controls the application on the smart phone. This approach significantly improves the user experience by allowing the driver to use the infotainment system’s screen and input controls, which are larger and better designed for in-vehicle interaction than those of a phone. The automaker can also “brand” this approach and integrate it into the look and feel of the infotainment system. To keep pace with the rapid evolution in mobile services, the remote skin in the infotainment system needs to support dynamic upgrades while maintaining reliability and security.

Which Approach is Most Suitable?
Cars, Clouds and Pockets:
click to enlarge

Figure 3. An application platform in which remote skins and other add-on applications can co-exist with core applications in a safe execution environment.
Ultimately, automakers will decide which approach (or combination of approaches) to use, based on customers’ needs and wants and on an evaluation of the benefits and drawbacks of each approach. Table 1 summarizes the key tradeoffs.

The Need for an Application Platform
Staying current with the latest mobile content and services requires a new approach to upgrading infotainment systems. To leverage the pace of mobile development, automakers need an application platform that quickly supports new applications and content. At the highest level, the platform should:

* Provide an HMI framework based on standards such as Adobe Flash, HTML 5, and OpenGL ES to simplify application development, enable remote skinning, and offer a visually engaging user experience

* Support safe, in-field updates to take advantage of new capabilities in consumer devices

* Embrace industry standards to support a large ecosystem and a broad developer base

* Allow for easy, brand-differentiating customizations by automakers and their suppliers

* Use resource partitioning and memory protection to cleanly separate applications and to keep core functions operational in any condition

* Scale across low-, mid-, and high-end systems.

Kerry Johnson is director of product management for QNX Software Systems.