By Roger Lanctot, Director, Strategy Analytics

Casual observers of the automobile industry are quick to compare connected cars to “smartphones on wheels.” It’s a simple way of looking at things that makes some sense now that half of all cars produced in the world are made with a built-in cellular modem…or two. It belies the complexity of connecting cars, but maybe it’s an accurate way to look at things now that Google’s Android operating system is on its way to dominating in-dash infotainment systems.

Strategy Analytics estimates Android’s share of the global smartphone market at 86  per  cent . Android is a long way from that kind of dominance in the world of the connected car, but the die is cast. Android is steadily muscling aside Blackberry’s QNX operating system, legacy Microsoft offerings, various Linux distributions, and a handful of other bespoke systems.

Cars are different. Winning the infotainment system OS race is not a zero sum game. Unlike smartphones, cars have multiple operating systems, multiple networks, and multiple microprocessors. Still, Android’s arrival and impending hegemony in the automotive industry has massive implications.

The automaker attraction to Android

Car makers are attracted to Android because it promises lower development costs. There are many more app developers working in Android, thanks in large part to that smartphone market dominance, which means they are both readily available and less expensive to hire.

Just like those smartphones, though, cars will require frequent software updates – and that’s a trick that is relatively foreign to the average auto maker. Only Tesla Motors has managed to make automotive software updates look easy – and Tesla isn’t even using Android…yet.

Android arrives at a point in time when creating and managing millions of lines of code is beginning to dominate the design process at most auto makers. The emerging and growing mountain of software code is driving massive hiring and pushing auto makers to seek out sources of savings.

In shifting to Android the industry is looking for development savings of 30 per  cent-40 per cent, but there’s a catch. Not only will all that “relatively” inexpensive code require updates – it is also likely to demand greater processing power, memory, and storage capacity – in anticipation of dozens of software updates likely to occur over the estimated decade-long life of any given vehicle.

That’s a pretty big fly in the ointment. Under-resourced infotainment systems are a sore point that continues to plague the automotive industry. Cars are being sold and driven today that lack sufficient processing or memory resources to support their Android and, yes, non-Android systems.

The challenges of the connected car

In essence, the onset of Android is opening the automotive industry to a veritable ocean of clever code and related applications. It is also contributing to the auto industry’s pivot toward the rapid adoption of over-the-air (OTA) software update technology. That, in turn, is broadening the deployment of cloud-based services and applications including everything from hybrid navigation to digital assistants and edge computing.

It’s also introducing a wider range of failure points, cyber security vulnerabilities, and plain old software bugs. But a properly configured system, equipped with OTA update capability, can enable a car maker to maintain or extend the value of a vehicle or even avoid expensive in-person recalls.

Software-related recalls are a growing challenge for auto makers. An over-the-air software update capability may allow some auto makers to avoid expensive recalls. Recalls are a major inconvenience and, in most cases, a safety threat. Even auto makers hate recalls, which cost US$300 per dealer recall visit on average.

Co-founder of Third Law autotech marketing, Andy Gryc was kind enough to compile recall statistics from the National Highway Traffic Safety Administration. Gryc’s recall analysis shows software-related issues have grown in number creating an increased financial exposure for auto makers and driving the adoption of over-the-air (OTA) updating technology.

Multiple suppliers such as Harman International, Wind River, and Aurora Labs have stepped in with OTA solutions as has the eSync Alliance. The 10-member eSync Alliance has rolled out a software developer kits to accelerate the adoption of OTA updates across the industry.

Cars are increasingly defined by software

There’s just one problem. No OTA system, no matter how clever, can make up for insufficient processing capacity or memory. In their rush to pinch pennies, auto makers are putting themselves in a bind.

Google’s Android operating system is a resource hog. Nevertheless, many auto makers are tacking in Google’s direction, adding the Android Auto smartphone mirroring solution. Renault, Volvo, and General Motors are preparing to launch GAS – Google Automotive Services.

It appears that the auto industry is coming to terms with its FOG – Fear of Google. Resistance remains – as some auto makers worry they will lose control of their customers in a whole-hearted embrace of Google – but resistance need not be futile.

Not all auto makers are adopting Android. Tesla is perhaps the most notable exception, but there are many others. Most auto makers are seeking ways to collaborate with Google without surrendering control of their own platforms.

The bottom line is that Android does not travel light. It’s an OS with a lot of baggage. Auto makers can get to their destination, achieve their objectives, without Android. The growing volume of software code, though, calls for providing adequate hardware resources and OTA capabilities.

Cars need OTA update capability for map updates, cyber security patches and updates, and, perhaps most essentially, to add features, functions, and value to cars after the sale. Cars are increasingly defined by software, and cars defined by software will need connectivity and updates. Make sure your next car is connected and updatable. That’s a solid takeaway.

DISCLAIMER: This article has been republished with permission from the author. The original can be found here. Any views expressed in this article do not necessarily reflect those of ITU.