6 Keys to Navigating Connected Car's Software Quagmire

How is a car connected?The connected car differs from previous-generation cars in one aspect. It comes with multiple connectivity points. These include cellular modems such as LTE to connect the car to the cloud; Dedicated Short-Range Communication (DSRC-802.11p) for vehicle-to-vehicle and vehicle-to-infrastructure communication; WiFi, Bluetooth, and other wireless technologies offered by a smartphone or a tablet; and keyless RF or NFC to connect a key to a vehicle.

The embedded cellular equipment (an in-car LTE module, for example) is expected to enable not only off-board navigation and location-based services but also data plan and automotive apps.

The driver phone will be used for running smartphone apps -- beyond allowing Bluetooth-based hands-free calls.

driver interface (can you get into a rental car in a dark parking lot and drive it?)

software debugging (evidence of software gitches must be captured and acted upon; we experience glitches all the time on our personal computers and just have to live with them; they become intolerable in a car at 70 mph where we may die with them)

obsolescence (cars have longer lives than their connected devices)

Addressing these issues will be plenty to keep the engineers busy. I hope someone on their teams will look across domains and see the big patterns.

If the average car is operated for 8 years and the average Smartphone is operated for 2 years, then the car must survive 4 generations of telephone technology. This is a serious challenge. My 2005 Honda Civic Hybrid (115,000 miles at 48.4 MPG lifetime average) came without any AUX or USB input to the sound system. I had to replace the radio just to play music from my Smartphone. As devices become more specialized, I hate to think what issues will face drivers in 8 years on a 2015 model car with a current infotainment system.

The biggest problem I see is network security (like Target card readers being attacked through an entry from a refrigeration vendor). With lots of Android virsuses running loose, there needs to be isolation between systems to pass data without allowing the functionality to be attacked.

The Car Connectivity Consortium (CCC) is dedicated to developing global standards for phone-centric car connectivity solutions. Since its inception in February 28, 2011 the CCC has grown to 94 members. These members are among the world's leading automotive, mobile communications, and consumer electronics industry companies, representing more than 70% of the worldwide market share in vehicles and more than 60% of the worldwide market share in smartphones.

>> Getting different devices wirelessly connected inside a car is begnning to happen.

The biggest problem in the industry is that they are not collaborating in this. When you see the level of efforts they put in harmonizing the evolution of MEMS and its sensory functions in cars, one could expect better when it comes to connected cars. The interest is not there. If auto makers have unified standards, the three main suppliers - Conti, TRW, and Bosch will invest and make things to work seamlessly. There are few companies whose parts make it into any car.

tb100, you make a good argument. It's true that "open source" sounds good, but who will stay in charge and in control of updating the efforts for the group matters a great deal. It is important to note, though, in the automotive world, nobody is ignoring Genivi. Companies who are providing various layers of software are mindful of Genivi and they are trying to make their solutions pluggable to Genivi.

Smartphone development happens so fast, that implementing too many features into the car itself would make the car obsolete pretty quickly. The Android phone I had last year wouldn't run a lot of the new apps coming out today. Imagine a car becoming obsolete within a year.

I prefer what some of the car companies are doing now: QNX as the middleware, with an interface to work with Android and iOS apps. I can't imagine the car companies picking a system that is exclusive to Android or iOS, pushing a lot of customers away who prefer the one they didn't pick.

And I wouldn't trust an industry consortium solution (GENIVI) to be sole middleware, to have to reliably support Apple and Google and all the many car companies including the many changes that are constantly occuring, compared to a dedicated commercial company (QNX).

In fact, historically this has not worked, and Tizen is a perfect example of this.

There was once something called LiMo, which was an industry consortium to develop an open source Linux cell phone. There were a lot of members including Motorola, Panasonic, Arm, Samsung, Wind River, Marvell, NTT, and Verizon . They came out with phones about the same time as Android. Guess what happened? Android moved much faster, and sold phones.

All these years later, LiMo still manages to exist, as Tizen, and I think the only thing they've come out with recently is a Samsung watch, and Samsung's latest smartwatches no longer even use Tizen.

I know automtobile manufacturers have stringent requirements for quality in the individual systems/components/parts due to the long life span of automobiles. But what are they doing in regards to interoperability standards?

And carmakers can't keep just adding those features and functions forever. They need to be architected as a part of the overall system from day one -- otherwise, testing becomes a never-ending effort that will end up unmanageable.

Hi @Junko, it seems that one of the greatest challenges is figuring out how to sufficiently test the software in these systems. The expansion (some might say 'bloating') of code is a problem in many markets. And, while infotainment isn't "mission critical," I expect consumers will set a high bar for performance within their vehicle. Manufacturers will want to get it right.