What will it take to realise the software-defined car?

The software-defined vehicle has become a buzzword in today’s industry and a monumental challenge for incumbent automakers. The features and functions of vehicles are increasingly enabled through software, moving the average new car from a predominately static, hardware-based machine to an evolving software-centric electronic device. SBD Automotive, a CASE (connected, autonomous, shared and electronic) technology and security consultant to the automotive industry, dubs this the journey from Vehicle 1.0 to Vehicle 4.0.

The evolution

Under this internal terminology, Vehicle 1.0 would be a basic functional vehicle without any form of connectivity. Digitisation enters with Vehicle 2.0, which introduces infotainment systems and a highly capable digital cockpit, offering high-speed connectivity and the ability to connect personal devices for features like music streaming and limited software updates.

The bulk of activity right now is around the Vehicle 3.0 space: the updateable vehicle. “These are vehicles that have really undergone a pretty significant change in the guts of the platform, especially when it comes to autonomous driving or advanced driver assistance system (ADAS) capabilities, digital cockpit and connectivity,” says Alex Oyler, SBD Automotive’s software domain principal with overall responsibility for end-to-end software and information technology projects. “The core outcome is that many of the in-vehicle experiences, the features that the customer uses and the services that are available to them, are much more updateable.” He expects automakers with Vehicle 3.0-capable platforms to start deploying software updates to their vehicles on a regularl basis—anywhere from every one to three months, depending on the brand.

“The majority of the activity today is largely towards treating the vehicle as a product that continues to improve over time, rather than something that’s sold once. That—plus parts and maintenance—is where the profit is made,” Oyler emphasises.

Beyond that, some automakers have begun targeting Vehicle 4.0, SBD’s term for the true software-defined vehicle. The key characteristic of this is that the vehicle is almost an extension of the cloud. Specifically, the software running on the car can be predominately controlled by a central runtime environment in the cloud. As Oyler adds: “There are many different use cases where you’re going to be using the high-performance computing in the car in conjunction with other vehicles that may be nearby or in the cloud itself to enable more edge-driven use cases such as localised autonomous driving and infrastructure or smart city applications.”

The technology stack

This is clearly the direction in which the industry is moving, but reaching the end goal requires some very specific technology. SBD has broken down the constituent parts of the software-defined vehicle into six main layers, each with its own set of technical requirements, interfaces, patterns, and vendors. The bottom layer consists of the hardware and the electronic/electrical (E/E) architecture. “In this domain you have the actual configuration of the E/E architecture: how the components are networked to each other, their responsibilities and the criticality they support,” he explains. “Is it a safety critical environment, or can it do less safety critical workloads, or both?”

The competition for new revenue growth will be predicated entirely on Vehicle 3.0 and 4.0

The other part of this is ECU consolidation into high-performance computers (HPCs). While the term HPC conventionally refers to very powerful cloud computing infrastructure, the automotive industry co-opted the term to refer to consolidated computing platforms in the vehicle that are significantly more capable than traditional ECUs. Instead of having two or three networks of several smaller microcontrollers, a core backbone of HPCs are increasingly responsible for entire domains of computing. Other ECUs may be plugged in for specific functions but the bulk of the software that drives the most important elements of the user experience all lives on HPCs.

The next two layers in SBD’s breakdown come within the vehicle platform and are Platforms & Middleware, and Operating System & Virtualisation. Some automakers are branding their versions of these two layers, as seen with Volkswagen’s vw.os and VolvoCars.OS. Essentially, this layer refers to the range of device operating systems as well as any virtualisation. “These HPCs could have multiple device operating systems running on them, doing different things,” he notes. “You could have a real-time operating system right next to a virtualised Linux OS that’s providing sensor and camera data processing via Adaptive AUTOSAR.”

As for the Platforms & Middleware layer, the main function is to abstract the hardware from the software. Developers will want to make sure all the interfaces of a new feature are not directly tied to a specific hardware implementation or operating context. “The more this matures, the more capable the vehicle will be to do the Vehicle 4.0-type workloads because developers can write and test software completely independently of the vehicle,” says Oyler. “Middleware also solves the legacy fragmentation issue for OEMs by ensuring any software written for the platform can be deployed to fragmented hardware platforms—a major cost driver today for automakers that manage multiple brands and segments.”

The next three layers all fall within the dynamic software stack, where much of the brand differentiation happens. “This covers the infotainment and digital cockpit system, or what’s happening in the background, working with vehicle data to achieve specific business use cases, or even in the ADAS system,” he explains. “This software should all be implemented on top of the vehicle platform, and this makes it a much more updateable runtime.”

Often these applications are tied in with supporting cloud services, which is the very top layer in the SBD vision of the software-defined vehicle tech stack. It includes ADAS services and over-the-air (OTA) services. Just below the cloud services layer is a layer SBD calls shared services, referring to the supporting infrastructure such as 5G, V2X and OTA infrastructure, both in the cloud and in the car.

Beyond the technical

As well as technical requirements, companies in pursuit of Vehicle 4.0 face institutional and bureaucratic challenges. Most of the incumbent automakers have been around for decades and have grown into huge organisations, often spanning numerous brands. A large portion of their workforce has been trained to work in a specific way with specific tools. However, this shift to software-defined vehicles requires a fresh approach to the vehicle development lifecycle, as well as new skillsets. “The first part of that is reorganising yourself and establishing new processes to support more iterative product development, as well as the new business models that support new revenue streams across the full lifecycle of the vehicle,” advises Oyler. “The other part is finding or training people with the skills to build the infrastructure you need to do this.”

Volkswagen, for example, launched a hiring spree for software developers for the Cariad division, and Toyota recently announced it aims to have more than 18,000 people working on software and connected initiatives. “This is not a simple task,” emphasises Oyler. “Much of what they’ll be working on has traditionally been done by Tier 1 suppliers or done with completely different toolsets in-house.”

Notably, this is an inherent advantages of some of the electric mobility focussed start-ups appearing on the scene. Oyler specifically flags Tesla and Rivian as companies “that have been able to start from tabula rasa.”

Change is also in store for suppliers, and some of the bigger Tier 1s are repositioning themselves. “It used to be that an OEM would come to them with requirements for something like an infotainment system or an ADAS controller. The supplier would then handle software development and testing and deliver it to the OEM,” says Oyler. Now automakers are developing most of the software required and only need the supplier to manufacture the part. “You have automakers saying, ‘We’re going to do all the software development. We have our own platform. We have a specific set of software partners. All they want the Tier 1 to do is take this package, flash it onto the component and then deliver the component to our factory’.”

In response, SBD has seen a shift to what it now calls Tier 0.5. Here, the Tier 1s are putting forward experts to work as part of the automaker’s development team, co-developing software and helping maintain it over time. “In a way, the supplier becomes almost part of the OEM, realising the revenues for system integration but also the manufacturing business that goes along with it.”

Bosch’s Cross-Domain Computing Solutions Group is one example of this evolution, which can also be seen in other forms at a handful of leading Tier 1s. Moving forward, such transformations will inevitably be required in both technology and strategy from all players seeking to realise Vehicle 4.0.

While the long-term future of mobility requires Vehicle 4.0 as its foundation, short-term growth will require a mix of evolutionary platforms to properly balance investment, risk, and growth opportunities. Over the next decade, revenue growth for automakers will be driven by the addition of value-add services, features and experiences over the lifetime of the vehicle, further reinforcing consumer loyalty to the OEM brand. While automakers must continue to build and distribute legacy vehicle types to maintain their business across different markets and segments, the competition for new revenue growth will be predicated entirely on Vehicle 3.0 and 4.0. The automakers that can effectively invest in new platforms while continuously optimising and consolidating their existing portfolio will be the biggest winners in the world of Vehicle 4.0.