When You’re Building the Car of Tomorrow, You Need to Start with a Service Oriented Architecture
June 17, 2022
Blog
What will drivers expect from their vehicles in the not too distant future? A better driving experience, naturally. This might mean assistance or automation technology taking over some or most driving tasks. Which might leave room for a richer infotainment experience. For many, efficiency and sustainability will become increasingly important. This will all have to be underpinned by unimpeachable safety and security.
And all of this will be dynamic. Drivers will expect the freedom to add and consume new capabilities or content at will, just as they do with their mobile phone or tablet today. And automakers will increasingly fix vehicle defects, optimize performance, and even add new features and functions - that the vehicle’s original designers might never have envisioned – throughout vehicles’ lives.
This will all add up to a simpler, more frictionless driving experience. But none of that is achievable without tackling a tremendous amount of underlying complexity in the software and electronics tying modern vehicles together. Today, a low-end vehicle might have 30 or more electronic control units (ECUs), while luxury vehicles can pack up to 150 ECUs and over 100 million lines of code.
The problem is most of these ECUs are bespoke hardware, running custom code. In-vehicle software stacks have grown with little emphasis on openness, upgradability, security, or data sharing.
This means the need for software upgrades and fixes is inevitable throughout the life of the vehicle. And while the industry is making progress on Over the Air (OTA) software updates, for most vehicles in production, fixing software problems still typically means an expensive and slow detour to a dealership. Stout’s 2020 Automotive Defect and Recall Report showed that over half of recalls were related to software defects, with the proportion increasing further in 2021.
Meanwhile, the current supply chain crisis in the silicon industry means vehicle manufacturers are being forced to consider different chips – but this leaves them in a bind when their existing software stack is tightly tied to a specific hardware platform.
This all contributes to a growing technical debt that doesn’t just weigh down vehicle OEMs’ ability to innovate. It leaves them struggling to complete vehicles built on existing designs.
In our view, the answer to these problems has already been developed in the enterprise technology industry. And it is to make the vehicle “Software Defined”.
What is "Software Defined"?
Being Software Defined means the vehicle’s functionality and features are largely implemented in software. This software is abstracted from specific hardware or ECUs, and so becomes “portable” and reusable across different underlying components, vehicles and even manufacturers. And because the vehicle is almost always connected to the cloud, updates can be performed reliably Over the Air. This not only removes the friction users feel when having to visit dealerships for updates, but it also opens the way for the rapid delivery of new features and applications, and crucially for the security patches and updates which are inevitable with any complex software system.
This delivers clear advantages for users, manufacturers, and third parties. Not least of which is the liberation of data, which can be shared between applications and services both within the vehicle, and with the OEM’s backend or cloud, giving manufacturers vital up to date information on vehicle performance and health. This free flow of data can guide development and updates in the longer term, inform preventative maintenance in the short term, and enable AI-powered assistance technologies in real time.
Being Software Defined also means vehicles become dynamically configurable and programatically controllable. The ability to remotely configure and orchestrate functionality and features in the vehicle software in real time allows OEMs to optimize performance and address issues quickly – without requiring software updates.
This “Software Defined” approach might sound familiar to those with an enterprise technology background. It’s the same approach that evolved in the enterprise and cloud compute infrastructure over the last three decades.
And central to Software Defined is the concept of a Service Oriented Architecture (SOA). This approach requires software to be broken down into distinct modules, or services, which perform specific functions, and which communicate with each other using common protocols and APIs.
Service Oriented Architecture (SOA)
Overtime, SOA software development has evolved towards microservices, discrete services that perform highly specific functions, which can be combined dynamically to create sophisticated applications.
Upgrades or patches can be applied to the individual service, or microservice, without the need to update the entire codebase. New services – or features and applications – can be developed more easily and quickly distributed to vehicles over the air, and these protocols and APIs can be leveraged by “control layer” services to orchestrate and automate software already in the vehicle. This can all be informed by up to the second intelligence gleaned from vehicles in the field, putting user experience – and safety – at the forefront.
Moreover, this approach enables a more dynamic, agile development workflow for the auto industry’s rapidly expanding developer workforce, with highly-focused teams working on specific features and functions, which can be developed more rapidly, and subjected to more intensive testing before deployment.
SOAFEE Project
This is why Sonatus recently joined the Scalable Open Architecture for Embedded Edge (SOAFEE) project – which brings together automakers, silicon vendors, software developers and cloud leaders, with the objective of developing a cloud-native architecture, and development and deployment framework, for automotive applications.
Why are we at Sonatus so sure that the SOA-based approach is the right model to follow for the Software-Defined Vehicle?
Because that is the engineering philosophy that my fellow founders and I used to transform enterprise IT and cloud solutions from rigid and siloed designs to the dynamic, scalable, cloud native platforms powering so much of today’s innovation.
It’s that journey that has delivered the cloud-based systems that enable consumer services such as Netflix, Uber, and countless others, and the B2B services that have enabled digital transformation in the enterprise. It has also made the underlying data infrastructure far more resilient, much more automated and manageable, and much more secure.
So just imagine where a similar journey will take us when the same principles are applied to Software-Defined Vehicles.
