The error in thinking about the software-defined vehicle

Everyone is talking about the software-defined vehicle. Do we really need that? And if so, is a software platform the right way forward? At least that's what McKinsey claims in a report published in 2020.

In principle, the ideas are going in the right direction. But one crucial point is often overlooked.

The software-defined vehicle

Tesla has shown how important software can be in a vehicle, with corresponding effects on the business model. Many manufacturers have now copied the concept and offer already installed features via software activation for subsequent purchase or rental.

For this to work (safely), the vehicle architecture must support this accordingly. While Tesla, for example, enabled over-the-air updates (OTA updates) right from the start, traditional manufacturers had to realize that OTA cannot be retrofitted so easily.

A "software-defined vehicle" refers to a concept in which a car's key functions, features and performance are controlled and enhanced by software, rather than being primarily dependent on physical hardware. This approach allows vehicles to be improved or equipped with new features after production through updates and upgrades to the software.

Already In 2019, Mercedes announced that the Group would become a software company. A few years later, the project Eclipse Software Defined Vehicle which includes several German OEMs and suppliers.

Problems with conventional architectures

A few years ago, the consulting firm McKinsey published the report The case for an end-to-end automotive software platform and thus took a clear stance on this issue. In particular, according to McKinsey, the many problems can only be solved sustainably with a software-defined vehicle.

Many problems arise due to the high Complexity of the overall "vehicle" system, or the "system of systems" consisting of many vehicles. The architecture consists of hundreds of functional components in the vehicle and in the cloud. Even today, 30 to 50 percent of resources are used for integration. And software complexity is expected to triple in the next ten years.

No single software platform on the market can fulfill all cross-system requirements. Instead, the development of automotive software modules often takes place in isolation: Both through acquisitions, but also through insufficiently integrated teams from the manufacturer. As a result, changes to a software module often require extensive revisions. These systems are not always backwards compatible and therefore require extensive redevelopment every few years to keep pace with new functions and services.

McKinsey calls for a software platform

McKinsey sees the solution in an operating system that is robust and flexible enough to cover the main systems in the entire vehicle. Software modules must be developed on a common code base to enable clean integration and further development. Standardized interfaces would also reduce complexity.

McKinsey hopes that simplifying the interfaces will reduce complexity. I take a skeptical view of this, as the overall complexity of a system cannot be reduced at will (Law of complexity).

But even without a significant reduction in overall complexity, a clever architecture could drastically reduce integration costs, for example. This could also increase reuse.

It remains to be seen whether such a platform will be developed by the established manufacturers or whether new market players will do so.

The flaw in thinking: where is the systems thinking?

The problem is that although software is moving to the forefront, we still have hardware. The McKinsey report remains vague in this respect, dismissing the hardware platform for deployment as a minor matter. Instead, the report refers to other domains. For example, drone manufacturers have found ways to reuse a single software architecture for many device types. Specifically, McKinsey refers to the standardization of the operating system for flight control, radio communication and camera software.

Standardized interfaces between these systems are certainly important and relevant. After all, accessing information from the flight control system helps to stabilize the camera. In the automotive environment, it is often cited how difficult it is to use the infotainment system to display vehicle information while at the same time maintaining a high level of safety.

But a vehicle will always be a combination of hardware and software. Or to be more precise, a combination of mechanical, electrical and software components. A software platform cannot do justice to this, only a system platform can.

We need a system platform - a software platform is not enough!

MBSE in particular requires at least three levels of abstraction: The problem level, the logical level and the physical solution level. On the physical level, we have components such as brake lights, indicators or the operating system. On the middle level, we have subsystems that combine the various elements of the physical level to solve problems on the problem level. By the way, Sodius-Willert described this very well in the white paper Systems and software architecture recorded.

Some advocates of the software-defined vehicle now hope that the middle level can be completely mapped via software. But I doubt exactly that. McKinsey calls this "software modules". Certainly, some efficiency can be gained in the short term this way. But a software platform is not enough to be able to develop scalable vehicles in the long term. We need a system platform for that.

Image source: FreePik