Many cars already connect to iPods, cellphones, and other personal electronic devices. In the not- to-distant future, they will also connect to the Internet, other cars, and roadside systems. For automakers and automotive suppliers, this trend toward ubiquitous connectivity presents many opportunities, but also many challenges.
Take, for example, connectivity to personal electronics. Consumers today want to use their MP3 players and smartphones even when driving. They also expect to be constantly connected, using their portable devices to “Tweet,” “Facebook,” or geotag throughout the day. It is only a matter of time before consumers demand that the car becomes an extension of this plugged-in lifestyle. For automakers, the opportunity is clear: If they can help the consumer stay connected in a safe, reliable, and legal fashion, they can differentiate their brand and build customer loyalty.
The problem is, the automobile must always play catch-up. In the personal electronics industry, it takes from 6 to 18 months to bring a product to market. But in the auto industry, where a new product must be planned into the vehicle’s manufacturing process and undergo extensive testing and validation, the process often takes three or more years. As a further complication, an in-vehicle system that connects to personal electronics must stay relevant for at least 10 years. But how can it do that if the MP3 players of today become the 8-tracks of tomorrow?
To address some of these problems, automotive engineers can implement systems with modular, upgradeable software architectures. In other cases, they can keep content and applications up to date by moving functionality from embedded modules to the Internet. For example, navigation databases, music metadata sources, and speech recognition back-ends can run on a perpetually refreshed server, rather than be distributed through costly DVD updates or bay module reprogramming. A remote server provides a host of capabilities — such as streaming media, application downloading, and realtime traffic reports integrated into navigation services — that are difficult or impossible to implement using only on-board resources.
The economy is also driving the car towards greater connectivity. Pressure to reduce engineering costs and time to market has grown more intense than ever. Meanwhile, burgeoning complexity is driving up the cost of software development as a percentage of the car’s total cost. As a result, automakers must create new ways to reduce bill of materials costs and streamline the software development process. Increased connectivity can reduce time to market and the embedded engineer’s burden, by driving some of the complexity back into the cloud (Figure 1). In fact, by leveraging Internet services, an automotive OEM can even create new revenue streams.
Multiple flavors of connectivity
A car can be “connected” in several ways, as illustrated in Figure 2. The types of connections include the Cloud, portable devices, within the vehicle, and the surrounding environment.
Connected to the cloud. In this case, an in-vehicle system derives some or most of its functionality from Pandora, Netflix, Amazon, Hulu, Google, Twitter, or other Internet-based services. To achieve this goal, the system requires a network access device (NAD) and a wireless network with near-ubiquitous coverage. Depending on the application, network requirements range from 2.5G cellular to wireless broadband technologies such as 4G or Long Term Evolution (LTE).
Connected to portable devices. This category includes connectivity to iPods, Zunes, PlaysForSure/Media Transfer Protocol (MTP) devices, USB storage devices, portable navigation devices (PNDs), and Bluetooth headphones. It also includes connectivity to a phone (typically through Bluetooth), which can serve as a NAD for Internet access. The phone connection can stream media and provide GPS location data, phone book contacts, and calendar management.
Connected within the vehicle. This approach leverages the connection between the center-stack console, rear-seat entertainment unit, digital instrument cluster, and other in-car modules. For example, the modules can shuttle streaming multimedia around the vehicle. Such high-bandwidth traffic exceeds the capacity of the CAN bus and requires at least a high-speed MOST network or perhaps Ethernet audio/video bridging (AVB).
Connected to the environment. This form of connectivity includes vehicle-to-vehicle or vehicle-to-roadway communications for collision avoidance and traffic management. Lane departure warnings, driver drowsiness alerts, and other driver-assist technologies also fall into this category, as do parking assist and adaptive cruise control.
Addressing the challenges
Every automaker must deal with various combinations of these connectivity types, each of which poses a new set of challenges that can be overcome by implementing intelligent design strategies.
Device testing. Performing compatibility testing on a constant stream of new consumer devices is a major chore, as is updating an in-car system to work with those new devices. To keep pace, automakers can outsource to companies that specialize in compatibility testing. They also need an over-the-air facility to readily deploy the software updates.
Hardware redundancy. Multiple car configurations and model lines can result in redundant hardware, increasing cost. For example, a Bluetooth module deployed across an entire vehicle line can also be deployed in an optional add-in box that supports multiple vehicle lines, resulting in some vehicle configurations that have a duplicate Bluetooth module. Similar situations can occur with USB ports, SD card interfaces, and hard disks. Multiple instances of a software resource, such as a database, can also occur within the car, driving up total processor usage, flash and RAM size, and software royalties. To reduce such duplication, automakers need to take a holistic view of the vehicle’s software and hardware architecture. They can also reduce duplication by using technologies such as QNX transparent distributed processing, which allows systems to transparently leverage one another’s hardware resources in a peer-to-peer fashion.
Category blurring. The boundaries between hands-free, telematics, infotainment, and navigation systems are fluid and can promote a lot of confusion within companies developing these products. However, by using a standard software base as an application platform, automakers and automotive suppliers can reuse development across multiple departments and multiple projects. To achieve this goal, they must ensure that the software base is portable across a range of high- and low-cost hardware.
Maintaining safety. How can automakers add new features to the vehicle without also increasing the distraction factor for the driver ? Proper Human Machine Interface (HMI) design is key. For instance, audio prompts (text to speech) and speech recognition can keep the driver’s eyes on the road. Graphical touch screens with intuitively designed controls and layout also help.
Revalidation of software updates. Most software systems require validation on the final software load. However, allowing customers to download new applications can create a huge number of possible software states that can’t all be tested. Just two downloaded applications create four possible configurations, quadrupling the test and validation load. To address this problem, automakers can use a partitioning system to isolate the new components in a sand box, thereby preventing downloaded components from affecting the rest of the system. For instance, the system designer can create a time partition for downloaded applications to prevent them from consuming more than 10% of CPU power.
Reducing development time. Wherever feasible, OEMs should use a software platform that contains as many preintegrated building blocks as possible.
Differentiating the brand. Automakers and automotive suppliers need to focus on areas where the user will notice the greatest impact. Developing middleware blocks (multimedia, graphics, databases, etc.) inhouse when they can be purchased off the shelf doesn’t make fiscal sense, particularly when the engineering effort can be directed at value-added activities, such as differentiating the HMI.
Software cost. The temptation to go with open source is great, but automakers and automotive suppliers must be wary of false economies. Costs incurred by legal teams, licensing requirements, additional engineering resources, required non-open source components, front-end nonrefundable engineering, “pay for use” fees, mandated hardware selection, and higher-cost hardware (needed if the software wasn’t designed for embedded use) can easily negate advantages gained by using “free” software. Careful analysis of the total cost of ownership is a must.
Mechanism for delivering new applications. An online application store can help keep the in-vehicle system fresh with new applications and, not incidentally, provide automakers and their ecosystem partners with an ongoing source of revenue. Automakers and tier one suppliers can build their own application store from scratch or start with a customizable reference implementation, such as the one provided with the QNX CAR application platform.
Maintaining an ecosystem for generation of content. Having an application store is one thing; keeping it fresh with compelling new applications is another. A single organization cannot maintain the frenetic pace of development required to make an application store commercially viable. Participation from multiple companies and individuals is essential, and its success requires an application platform that has a broad enough base to attract developers.
For example, the ng Connect Program solves many of these problems by addressing connectivity to the cloud as one aspect of overall connectivity concerns. It is an ecosystem that comprises Atlantic Records, Alcatel-Lucent, BUZZMEDIA, Chumby, FISHLABS, GameStreamer, Hewlett-Packard, Kyocera, QNX Software Systems, Samsung, Total Immersion, TuneWiki, and others, who together can deliver services that give customers access across all devices and networks.
By using Long Term Evolution (LTE) technology to significantly increase the speed and capacity of mobile networks, the ng Connect ecosystem enables in-car applications that would have been previously impractical. For example:
- On-demand streamed or downloaded movies
- Access to personally recorded TV programs via cloud storage
- In-vehicle Internet radio and on-demand music stores
- Multi-player online gaming
- Social networking
- Dynamically updateable navigation and location-based services
- GPS augmented by Google Maps point-of-interest indicators
The in-vehicle software for ng Connect is based on the QNX CAR application platform, which provides a modular software architecture designed for simple integration of new applications. Because the QNX CAR platform is based on Adobe Flash, it also takes advantage of the large Adobe Flash development community for existing content.
Andy Gryc has been a software developer and designer for more than 20 years. Prior to joining QNX Software Systems, he worked as the lead embedded software architect for GM OnStar and served as a member of the Hewlett-Packard team that created the software for palmtops and the BIOS for the Omnibook notebooks. He currently works as an automotive product marketing manager at QNX.
QNX Software Systems
613 591-0931 or 800 676-0566
[email protected]
www.qnx.com