Untangling the challenges of the connected car
Ubiquitous connectivity will allow automakers to differentiate their vehicles and create a more compelling driving experience. But this connectivity introduces several challenges, including software complexity, hardware redundancy, and driver safety, which automotive OEMs can overcome with cost-effective software development processes.
Many cars already connect to iPods, cell phones, and other personal electronic devices. In the not-so-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 smart phones 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 in conjunction with 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 eight-tracks of tomorrow?
To address these problems, automotive engineers can implement systems with modular, upgradable software architectures. In some 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 capabilities such as streaming media, application downloading, and real-time traffic reports integrated into navigation services, all of which are difficult or impossible to implement using only onboard resources.
The economy is also driving the car toward greater connectivity. Pressure to reduce engineering costs and time to market has grown more intense than ever. Meanwhile, burgeoning complexity is multiplying 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 shifting some of the complexity back into the cloud. 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 1. 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.
Connected to portable devices
This category includes connectivity to iPods, Zunes, PlaysForSure/Media Transfer Protocol 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 CANbus and requires at least a high-speed MOST network or perhaps Ethernet audio/video bridging.
Connected to the environment
This form of connectivity encompasses 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 vehicle configurations and lines can result in redundant hardware, thus 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 using technologies such as QNX transparent distributed processing, which allows systems to transparently access one another’s hardware resources in a peer-to-peer fashion.
Category blurring
The boundaries that separate hands-free, telematics, infotainment, and navigation systems are fluid and can promote a great deal of confusion in product ownership and development. However, using a standard software base as an application platform, automakers and automotive suppliers can reuse development across multiple departments and 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 driver distraction? 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 numerous possible software states that can’t all be tested. Just two downloaded applications can 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 sandbox, 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 those applications from consuming more than 10 percent of the CPU.
Reducing development time
Wherever feasible, OEMs should use a software platform that contains as many preintegrated building blocks as possible.
Differentiating the brand
Vehicle makers and suppliers need to focus on areas where the user will notice the greatest impact. Developing middleware blocks such as multimedia, graphics, and databases in-house 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 isn’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.
The companies that can solve the majority of these problems quickly and cost-effectively will be well positioned to reap the benefits of ubiquitous connectivity. As shown in Figure 2, integrating the cloud of Internet-based services with the functionality of portable devices in a vehicle infotainment system renders clean metadata that satisfies consumers’ demand for always-on wireless systems.
QNX Software Systems info@qnx.com 613-591-0931 www.qnx.com