For decades, the automotive industry has relied on the V-model as its preferred blueprint for engineering discipline. Conceived in an era when vehicle systems were largely mechanical and development cycles stretched comfortably over several years, the model offered manufacturers a reassuringly linear logic: requirements flowed downward through design and implementation before climbing back upward through validation and verification. Each stage mirrored another, and every requirement could, in principle, be traced to a corresponding test. In safety-critical industries, few frameworks proved more enduring.

Yet the rise of electrification, software-defined vehicles (SDVs) and over-the-air (OTA) updates has exposed the limitations of a methodology designed for comparatively static products. Modern powertrain programs increasingly resemble living software ecosystems rather than fixed engineering artefacts, and battery-management systems, e-motor controls and advanced hybrid architectures demand continuous integration, rapid iteration and constant recalibration. Traditional development gates, once prized for ensuring robustness, can appear cumbersome in an environment shaped by agile software practices and compressed timelines.

Still, reports of the V-model’s demise are premature; automotive engineering remains constrained by safety, regulation and traceability in ways unfamiliar to much of the software world. Standards such as ASPICE (Automotive Software Process Improvement and Capability dEtermination) and ISO 26262 continue to reinforce structured development and rigorous verification, even as companies adapt the model into more flexible, hybrid forms. Increasingly, the question is not whether the V-model will survive, but how it will evolve.

To explore that transition, and the changing relationship between systems engineering, simulation and software development, we spoke with Mike Linehan of MAHLE Powertrain.

The following is an edited transcript of the conversation.

S&P Global Mobility: The V-Model has long underpinned automotive development. Where do you see it breaking down most clearly in today’s electrified and software-intensive powertrain programs, and what elements — if any — remain indispensable?

Mike Linehan: As systems get more complex, it is important to have a development framework and corresponding processes that are understood by the teams, and which provide the required process controls.

All steps in the traditional V-model are still relevant, and the model is still helpful for representing and visualizing a number of important good practices, relationships, interactions and timelines. The V-model works well for simple, single-function or unit developments. However, things can get complicated very quickly when considering a complex system. Such systems may contain hundreds of functions, which could be new, carryover and/or adapted, and you have to manage all of these related but disparate system elements through their individual lifecycles all the way to system delivery.  

The chosen framework to develop complex control systems will be specific to each organization, and can, for example, look like a V lifecycle or an agile cycle. This depends on the project, the customer, software quality targets, disposition towards risk, requirements management tools, software architectures, the software development environment, the testing environment, related toolchains, process quality check points, preferred ways of working, team skills, experience and more. Having a clear framework is often more important than the nature of the actual model employed.

Historically, embedded controls had to be robust at launch — any changes after launch could only be achieved at great expense. Over-the-air updates are an important feature of the modern SDV, providing the mechanisms and opportunity for software updates and bug fixes, if and when problems are found. It also provides for improvements, refinements or enhancements to the SDV functionality. On the other hand, this can also mean never-ending developments, potentially on legacy systems.

With the development of software becoming more widespread and multiple new players, there are a wide range of capabilities in this sector. Some organizations don’t fully understand or possess the processes and the culture to develop quality production systems and software, or adequately assess the risks. A culture prioritizing speed over quality can drive shortcuts. System and software developers won’t automatically do things that they aren’t required to do. Organizations should consider where they sit in the spectrum, from well-managed developments utilizing helpful shortcuts, through collaboration and risk management, to uninformed acceptance of indeterminate quality software.

Any project can run into trouble. The hope is that the well-managed project will be able to recover the situation quickly. In a ‘shortcut’ culture, if a complex development falls over it can be much harder to regain control and recover the situation.

The software development standards (e.g. ASPICE & FuSa [functional safety]) tend to consider a V lifecycle. It should be possible to align any bespoke company development framework with one of the recognized models to achieve compliance. From a practical point of view, overlaying a V-model on to preferred processes and established workflows can work well. The imposition of new/rigid V-model process workflows purely aimed at compliance with standards, which do not comprehend your organization’s challenges, processes and preferred ways of working, is less likely to be successful.

How is MAHLE Powertrain adapting the V-Model to support more iterative, software-centric development cycles across hybrid and electric propulsion systems, without compromising traceability and compliance?

MAHLE Powertrain’s approach for multi-disciplinary system developments and controls projects revolves around a systems engineering V, leading up to a proof of concept and then an implementation V. Through the system engineering phase, we aim to answer as many questions as we can to de-risk the main production development phase.

In terms of identifying and tracking system requirements, we adopt a flexible and scalable approach to requirements management, so that we can efficiently handle any projects, from research up to safety-critical and/or production developments.   

In our software developments, we adapt our approach depending upon the project and customer requirements. We support developments across the spectrum from very formal programs to faster, model-based and/or agile developments.

With simulation and digital twins becoming central to powertrain development, are we moving toward a “simulation-first” validation paradigm — and could this eventually reduce reliance on physical testing, particularly for calibration and system integration?

The state of the art is already here! We have been at the forefront of simulation and modeling for powertrain and associated systems for many years. Increasingly, we are proving out ever more complex aspects of our controls concepts against representative plant models, through the concept phase, balancing the resolution of our controls and plant models to meet our objectives within reasonable run times. We aim to minimize our reliance on rapid prototyped hardware for both controls and the calibration of those controls. For sure, there is still a role for physical systems to verify characterizations and real-world performance, but our upfront controls development and virtual calibration enable us to hit the ground running when we integrate with the physical systems.

What are the biggest technical and organizational challenges in scaling digital twin environments across complex powertrain architectures, including battery systems, e-motors and advanced combustion engines?

Small, flexible teams of specialists help us to coordinate modeling approaches; to share system, plant and control models and to ensure we reach a common understanding. Where possible, we look to develop standardized modeling methodologies along with scalable requirements management approaches.

Standards such as ISO 26262 were not originally designed with AI-enabled systems in mind. How is MAHLE Powertrain approaching the verification and validation of AI-driven functions within — or alongside — these frameworks?

At the moment, we’re not doing anything in the FuSa space with AI. There are potential benefits in using AI to support less critical developments, but we see a number of problems relying on AI to assist in safety-critical areas. We are following developments in this area with an open mind but are not expecting rapid progress.   

AI-assisted engineering tools are increasingly used in calibration, controls and system design. How do you ensure that outputs from these tools meet automotive-grade safety, reliability and auditability requirements?

We are using AI assistance in a number of other areas, and we have seen that AI tools can offer significant productivity benefits, but only when integrated into controlled engineering frameworks and processes, whereby the benefits and limitations of competing approaches [are] fully understood. We subject AI-assisted tools to the same level of control, governance and scrutiny as any engineering tool.

Contrary to the hype, AI is not a universal panacea. It does not guarantee quick wins or even correct solutions. AI requires investment in time, learning and resource. The key phrasing, as in the question, is AI-assist. We see that the human-in-the-loop is still essential. Accountability sits with the engineer, not the tools. 

Working with AI, it is critical to ensure that outputs are verifiable, traceable and governed to the same standards, as with any other safety-relevant or critical artefact. AI presents challenges for repeatability and traceability. We need to have confidence that any AI tools are providing consistent answers and our ability to replicate AI decisions is essential. In this respect, recording and tracking input parameters, prompts and models is critical. 

In areas such as electrification and advanced propulsion, development cycles are accelerating. Do you see elements of the traditional V-cycle being compressed — and if so, how can this be done without compromising robustness in safety-critical systems?

The key considerations for compressing timescales, in whichever model is being followed, are:

1. Everyone involved understands the framework, plan, deliverables, risk management and criteria for success at each step.
2. The early involvement of systems experts.
3. Having an accurate and realistic plan.  
4. Getting the systems engineering and concept prove-out right for all the system targets — especially safety and FuSa.

As OEMs vertically integrate and suppliers expand their engineering capabilities, how do you see the role of specialist engineering partners like MAHLE Powertrain evolving in the SDV era?

A key aspect of the SDV era is OEMs taking complete control over the delivery of software functionality that was once the domain of suppliers and catered for by multiple supplier modules.

Vertical integration at the OEM impacts suppliers as system and function deliveries become integrated into OEM development toolchains and the knowledge is embedded in the OEM domain, especially in terms of requirements, testing and release management.

The opportunities for suppliers are changing.

Typically, our focus is on developments which are outside or on the fringes of SDV and OEM control:

1. Complex systems with specialist platform requirements (e.g. engine control).
2. Small volume system control solutions (e.g. FuSa engine controller).
3. Rapid control solutions and capabilities to assist OEMs to prove out new ideas (e.g. flexible controllers/interfaces).
4. Opportunities for ‘smart’ sensors and actuators (e.g. motor controllers). 

There are, of course, growing opportunities for development and integration tools and support services for platform and application developments.

How do you see the role of software platforms and standards (such as AUTOSAR [AUTomotive Open System Architecture]) evolving within powertrain systems? Will they remain foundational, or give way to more bespoke or OEM-specific solutions?

Typically, platform developments fly under the radar and don’t necessarily get the attention they need. Model-based application software tends to get the focus and is the easier access point into the software.

Ideally, platform developments should get more recognition. Developments are often a more specialist field, managing the interactions between the hardware, application and wider low-level services. For example, a large part of the FuSa software will often reside within the platform code.

So far, our platform software has been developed outside of AUTOSAR, as we are able to do everything that we need without it.

Standardization, AUTOSAR and the associated supporting tools and licenses attempt to provide simple approaches to manage critical platform developments and interfaces, but they come with significant costs and reliance on third parties.

Currently, AUTOSAR tool developers seem to be in a strong position, with OEMs requiring AUTOSAR implementations. Going forward, it will be interesting to see the extent to which OEMs look to take more control of their platform developments, and if an open-source equivalent will break through.

With the proliferation of simulation tools, control strategies, AI frameworks and DevOps pipelines, how is MAHLE Powertrain managing toolchain complexity while maintaining end-to-end consistency across development, calibration and validation?

Our approach is based on proceeding with caution — the benefits, the investment and the risks all need to be considered carefully.

The key for us has been to integrate AI tools into controlled engineering frameworks and processes, and to subject the AI-assisted tools to the same level of control, scrutiny and governance as any engineering tool.

A further dimension not considered in previous answers is cybersecurity. Typically, these tools present risks, in terms of access to services or functions which could be exploited and/or access to — or transmission of — critical data off-grid, setting us a number of challenges. We must protect our business networks from attack, manage the storage of our data and our customers’ carefully (TISAX), and ensure we get our solutions right.

Steady and cautious is a conscious business decision. Being clever, fast and prepared to take risks may not be the smart approach with AI.