In a recent webinar presented on Automotive News, representatives from Amazon Web Services and software engineering firm Luxoft spoke about the digital architectures that will soon support “software defined vehicles.” This is a layman’s guide to the ideas presented.

For years, we’ve heard how 5G would revolutionize our roads, and that’s coming – but first, say the speakers, will come an extension of our digital lives from our homes, offices and mobile devices into our cars.

That’s already happening in infotainment centers, but as end-to-end data communications between cars and OEM servers mature, more business and consumer services will launch. They’ll add value to our vehicles, like over-the-air updates that extend battery life or change performance settings; they’ll simplify services like insurance, and may allow new pricing models; and they’ll empower OEMs to launch more robust mobility programs.

As we think about today’s connected cars transformation into software-defined vehicles, a helpful framing device might be separating the edge (vehicles, and potentially a distributed network of servers) from the cloud (the ‘mainframe’ servers maintained by OEMs and other businesses delivering digital services to drivers.

The Edge

The common term for endpoints in any cloud-based software architecture, the edge in future connected car ecosystems are the vehicles themselves. Will they continue to look like today’s cars? Will they function like today’s cars? While AWS’ speakers presented that the industry is today challenged to “decouple the software from the vehicle hardware,” there will always be differentiations among brands and, to some extent, models.

However, the push to build out software development workforces at major OEMs foreshadows a new “model” system, wherein the function of a vehicle is maybe not determined so much by the chassis on which it’s built but the software package to which it’s best suited.

Consider the mail truck. It doesn’t need to look different from other vehicles, but it does have different uses aided by, say, a right-hand driving position, automated low-speed navigation, hazard awareness systems, etc.

The challenge for automakers now, the speakers explained, is engineering vehicles that can handle multiple use cases, then using software to equip the vehicle for those different jobs. Perhaps a mail truck has sliding controls (a tiller, maybe, as Road & Track recently suggested was the future), and software restricts the driver from right-hand driving operation unless the vehicle is in “mail mode.” Once the mail is delivered, the controls can slide back to a standard driving position, and maybe software can be initiated to reassign the vehicle to a different government fleet duty. 

 

That’s simply one example of how software can define a car – and one slightly more complicated than the example of software capabilities presented in the webinar (locking and unlocking vehicles remotely) that the audience suggested was “not exciting.”

A photo of a mail truck driving down a city street

The point, however, is that when connected vehicles meet expectations for “edge computing,” delivering function-changing commands to vehicles via remote software will be standard practice. Whether vehicles change functions daily, hourly, or only after several years remains to be seen, and that’s up to the strategies built in the cloud.

The Cloud

Back at home base, the transition to software-defined vehicles starts, really, with over-the-air communications. The webinar speakers said that OEMs are seeking new ways to connect with their customers and build new business models, and achieving those goals requires a channel by which the OEMs can deploy new features through vehicles.

To connect with customers, you need to deploy features like simple remote lock and unlock functions from smartphones. Or, as was discussed during our recent INSPIRE Session on API strategies, automakers could deploy features that integrate a car with smart home features – when you walk out the door in the morning, the podcast you were listening to on your home speaker automatically picks up where you left off when you get in the car. 

Simply providing drivers with an app to monitor vehicle health data, receive prompts for preventative maintenance or automate roadside assistance calls are all good examples of ways software can redefine how drivers interact with their car and connect with its manufacturer. Many of those services might also require smart software – artificial intelligence or machine learning – to deliver reliably. That’s where much of the development work is being done today, to ingest the massive amount of data each car produces and quickly identify patterns. 

As the data-crunching improves, the other facet of future cloud computing around connected cars can become more robust too. This is when OEMs and their lessees can grant an insurer access to vehicle data for dynamic pricing, or how rental programs might automate availability, digitize scheduling and booking, and grant renters access when they arrive to pick up a vehicle. 

The software-as-a-service approaches that OEMs take in the future may ultimately come to differentiate their brand as much as crossover and sport-coupe offerings do today.

A diagram of the cloud technology, software and hardware involved in a connected car service architecture
Luxor's depiction of all the pieces needed to deliver mature connected car services.

Though the concepts of modular software architecture and agile development are somewhat new to the auto industry, the explanations offered in AWS’ recent AutoNews webinar are ultimately simple to grasp when you think of your car not as a machine you operate, but as a vehicle for delivering services to you (meta, I know). Today, that service is primarily “point A to point B.” But in the near future, it might just deliver an “automated commute, with a stop for breakfast tacos because it’s Friday.”

Give AWS a listen and tell us on LinkedIn what future services would excite you!