Surviving the changing economics of automotive engineering

The European automotive landscape is dominated by some of the oldest and most prestigious manufacturers in the world. Institutions built on style and performance, but whose legacy is under threat from the demands of AI, EVs and autonomous vehicles. Announcements from JLR and VW in the last week have sent shockwaves through the industry and reflect a seemingly bleak outlook.

It would be easy for European OEMs to feel sorry for themselves. Even today, wages in places like Germany and the UK remain up to four times higher than in China. Net zero targets and increasing government regulation pose a set of challenges that are driving costs up. And European productivity is shockingly low compared to both China and the US: McKinsey estimates an alarming 33% deficit.

However, to simply admit defeat and accept circumstances out of our control would be an astonishing failure on the part of European industry. Its brands still capture the imagination, it has access to world-class research and development facilities, and a pool of exceptionally talented engineers. However, they must redesign themselves operationally to exploit these inherent advantages.

The V-Model in the Era of Software Defined Vehicles

Clearly, software defined vehicles are a different beast to those that are characterised purely by mechanical systems, combustion and fuel. Both in terms of how they are operated, and in how they are manufactured: ECUs that run on a modern vehicle run up to 100 million lines of code and are more complex than many modern apps. The shape and skillset of the team designed to produce it differs drastically to that of a traditional systems engineering organisation focussed purely on produced hardware.

However, revenue is hardware based, meaning that R&D manufacturing and supply chain still live in a world of parts and components. The OEMs are sprawling organisations that include a vast number of brands, departments, systems and processes that are deeply embedded. At their heart is the V-model, which maps the entire product lifecycle, from requirements gathering through defined build stages with corresponding testing/validation. 

Once produced, hardware is immutable, so following a structured linear process of component and subsystem production makes logical sense. But software requires continuous iteration and updates, even post-deployment. If software is pinned to the hardware development lifecycle it cannot iterate quickly, and developers might not learn until very late that something is incompatible with a given piece of hardware. Integrating feedback or fixing bugs can add a further 40 to 50 months of development time once physical vehicle production is complete!

The development programme for a modern vehicle runs up to 7 years. In China, the same programme can be delivered in 18months.

MathWorks Fellow Jim Tung has gone so far as to say that the V-model is not currently fit for purpose in the modern environment. At least not in the way it's currently embedded within engineering processes. Too often the diagram is read as a calendar or a process workflow, with an implied gate at each step. Engineers might add arrows or small Vs to show iteration, but the core framework remains waterfall in nature. 

The entire programme is at odds with best practice software development, where requirements gathering, testing, production and validation run continuously and in parallel. And software engineers are allergic to waterfall and despite the allure of working for a big prestigious automotive brand, poor operational processes hinder the ability to hire best in class talent compounding the challenge in delivering truly innovative and fast pace machinery. The perception of slow, fragmented and repetitive bug fixing is simply not an exciting proposition for someone who could be working at the AI frontier.

Building an integrated engineering model

Modernisation means keeping the V as a traceability structure, while making the development process iterative. Each stage should be verified, validated and iterated rather than treated as a fixed step in a linear workflow. This also means shifting testing and validation left. Simulation, virtual testing and digital twins allow engineers to validate designs earlier and across a much wider range of configurations, reducing reliance on physical prototypes and catching problems before they reach later stages of development.

Challengers to the established order have already ripped up traditional architectures and blurred the lines between hardware and software. In this model, the right and left hand sides of the V are increasingly interconnected, with requirements, designs, configurations, tests and results forming part of the same development process. It provides an interesting blueprint for the established OEMs.

However, faster iteration creates significantly more engineering evidence. 

Data engineering in the context of a data explosion

Every software change, simulation, physical test and validation cycle produces data that needs to be understood in the context of the requirement, hardware configuration, software version and test conditions. For large programmes this creates a huge amount of data. And as development cycles shorten, engineers need to be able to find and interrogate that evidence just as quickly. If test results remain scattered across files, spreadsheets and one-off scripts, time saved through faster development is lost to the work required to find, compare and interpret previous results.

It requires more than simply putting engineering data in one place. The organisation needs a common way of describing and relating that data. A semantic layer can provide this by defining how requirements, measurements, configurations, test results and other engineering concepts relate to one another. It gives engineers and software a consistent interpretation of the underlying data, so that the same metric or engineering concept means the same thing wherever it is used.

With this layer in place, evidence can be connected across the V. A requirement can be traced to the tests that validate it. Results can be compared across vehicle configurations and software versions. Data from vehicles in the field can feed back into future development. Teams responsible for defining requirements can remain connected to the testing and validation of those requirements, creating greater visibility across functional boundaries.

This changes the role of the V-model. Rather than acting as a sequence of handoffs between engineering functions, it becomes a connected system in which evidence can move continuously between requirements, development and validation.

Applying AI across the V

Once this foundation exists, AI agents can operate across the engineering process rather than being limited to individual tools or datasets. They can connect requirements to relevant test evidence, investigate anomalies across multiple runs and configurations, compare results, and identify patterns that would otherwise require engineers to search across multiple systems.

Several automotive sector leaders have already deployed generative AI in software development, reporting improvements in coding speed, software quality and employee productivity. 

The larger opportunity is to extend these capabilities beyond software development and into the wider engineering lifecycle. This enables businesses to prioritise:

• Short development cycles and rapid iteration
• Parallel engineering and early supplier integration
• High software intensity and redeployment at the platform level
• Tight ecosystem integration, rapid prototyping and fast feedback loops

Conclusions

Labour costs, government regulation and regional incentives might be disadvantages, but Europe also has many inherent advantages including its engineering pedigree, world-class R&D facilities and some of the most prestigious brands on the planet. The fundamental challenge is creating an operating model that can tap into them.

The V-model still provides a useful backbone for the requisite structure, traceability and control needed to develop complex systems. But it cannot remain a sequence of slow handoffs between engineering functions. Development needs to become iterative, hardware and software need to be developed together, and the evidence generated throughout the process needs to remain connected and accessible.

A connected engineering data foundation, built around a semantic layer and AI agents, can provide that infrastructure. It can connect requirements, configurations, tests and results across the V, while giving engineers the ability to interrogate that evidence and learn from it at a much greater speed.