Different paths & respective processes of vehicle intelligence
Excerpt from the presentation at the 45. “Internationales Wiener Motorensymposium”, April 2024
The debate about the ‘right’ powertrain technology is not yet over, and yet we are already facing the next big challenge. There are many indications that the business models in the ‘mobility’ ecosystem need more intelligent vehicles than currently available. The way we think about and build cars is changing.
Software-defined vehicles (SDV)
The software-defined vehicle is now the terminus technicus for what we were discussing in 2023 as the ‘intelligent vehicle’. It has therefore manifested itself and has arrived in the industry as the ‘next big thing’ and is subsequently an enabler for new business models. In terms of structure, it is also a necessity to evolve, since the way we develop and build vehicles today, can fulfil neither the necessary functional nor regulatory requirements.
However, it places high demands on the organization. And not only in the way departments are reorganised, but above all in the importance given to software architecture in the company and the people, who work there.
Hardware becomes disposable – software is decisive.
We have asymptotically approached perfection in a technical sense with what we have – mischievously – labelled ‘ECU carrier’. We are of the opinion that the effort to think further in this direction can no longer be justified by the achievable effects.
The technical advantage gained by superior internal combustion engines was in many cases a cornerstone of the ‘established vehicle industry’. This supremacy has been neutralized by the advancement of electromobility. As a result, there is a renewed imperative to uncover this advantage in new, emerging areas. In other words, classic automotive engineering has attained a level of maturity that is deemed more than “sufficiently” adequate on a global scale. However, this maturity alone no longer dictates competitiveness within the industry. The USPs of tomorrow lie – among other things – in the intelligence of the vehicle and the associated business models of tomorrow.
The vehicle of tomorrow is more of a regularly self-updating, improving and growing system especially compared to the vehicle models we have seen every 6-7 years at automotive trade fairs like IAA etc. The vehicle of tomorrow is a smartphone on wheels. The differentiation no longer lies in the excellent design and beauty of the aluminium rims, but within its functionality and multi-purpose.
As-is architectures have reached their limitations.
The way we have developed vehicles has reached a crossroads. Start-up OEMs show what a vehicle looks like that is primarily defined by the software architecture. It is not possible to get there with the established structures, partnerships, or processes.
The smartphone therefore is the perfect analogy, even if it is much less complex in relation to Functional Safety (FUSA) & Co. It shows a new way how it can be done.
Start of Production (SoP) is not the end of the Product Development Process (PDP) – vehicles evolve in the lifecycle.
The software is created from a single mould and is developed collaboratively instead of in isolation and function by function. This requires collaboration models that have long been established in the software industry.
Requirements are the starting point, and change management runs from day one via consistent ticketing, feedback loops from trialling, the market, aftersales etc. – all in one language.
Software: unify code-base & tools
The technical possibilities offered by high-performance computers (HPCs) are fuelling constant development. The software architecture of tomorrow will significantly reduce the number of electronic control units (ECUs). Functional linking from control unit to feature is also no longer up to date and creates dependencies that ultimately cost flexibility.
The standardisation of code and message transfer in the overall system also harbours more opportunities than risks. On the one hand, it enables over-the-air (OTA) updates, which simultaneously fix bugs, deploy production-ready features, test prototype features in shadow mode as well as provide important data for after-sales, but also allow the direct utilisation of field data in the continuous further development of the code.
The hardware abstraction layer is the key to ensuring that not only test vehicles but also customer vehicles in the field remain in the loop, deliver data, and receive updates. Even with the 2nd and 3rd customer and even when the warranty has long since expired.
Hardware: over-shoot the requirements by 20%
The decoupling and subsequent re-synchronisation of hardware and software development loops is the key to success.
This is also the reason why the hardware must always be designed +20% compared to the currently nominally required resources according to the software.
People: Train Software experts on cars – not the other way round
What does all this mean for the industry as we know it today?
The start of production is a milestone, not the end of the product development process. We need agile software developers who are constantly working on tickets instead of sequentially cancelling construction stages. We need hardware that serves as a playground for the software. The vehicles in the field generate data which is not only used to develop the next generation, but rather to offer the customer a future feature.
Main reasons why hardware must always be generously designed as the foundation:
- The end result cannot be finally anticipated at the start
- The iterations of hardware development are – obviously – longer than the frequency of software releases
The electric-electronic architecture (E/E) becomes the firmware department and the C-Level with corresponding responsibility is elevated to the rest of the R&D organisation. The software architecture under his/her jurisdiction functions as a living organism, evolving across series, derivatives and, above all, successive generations. Facilitating this evolution is a hardware infrastructure consisting of a limited number of HPCs within a compact and functionally decoupled zone architecture.
The current product development process and the development organisations involved are unable to provide this. And this is the main problem that is causing significant pressure within the established automotive industry. Despite the implementation of agile training initiatives, the recruitment of tech managers and the establishment of software units from the ground up, tangible success remains elusive.
Where are we today?
Good indicators for SDV maturity are simple but concrete KPIs. And anyone who recognizes the “Agile Manifesto” behind them has a good chance of already being a step on the way.
