Advanced driver assistance systems bring increasingly sophisticated software into vehicles. Functions such as lane keeping, adaptive cruise control, automated emergency braking and sensor fusion rely on complex algorithms operating under tight real-time constraints. Consequently, automotive development organizations invest substantial effort to ensure that application software and hardware platforms comply with functional safety standards such as ISO 26262.

Yet one critical layer of the software stack often receives far less attention: the compilers and libraries that silently transform our software code into reliable, high-performance executable behavior. These tools operate largely out of sight, but they play a decisive role in determining how ADAS software performs on the road. In fact, no ADAS function can exist without them.

The silent force behind ADAS software 

Compilers translate high-level source code into machine instructions, while standard libraries provide essential functionality for numerical computation, data handling and timing. Together, they form the foundation on which application software is built, and their correctness is often taken for granted throughout the development lifecycle.

In practice, this assumption can be risky. Even when application code complies with coding guidelines and the target hardware is safety-certified, deficiencies in the toolchain can still undermine system behavior. These issues typically do not originate in the application logic itself, but in lower layers that are difficult to observe directly.

Unseen risks in the toolchain 

Compiler optimization is a prominent example. Optimization is essential for meeting performance and power consumption requirements in automotive systems, but it also introduces significant complexity. Changes in optimization paths can alter control flow, numerical precision or timing in ways that are not apparent from source code inspection. As a result, a compiler update or a change in optimization options may introduce new behaviors (and even errors) while the application code remains unchanged.

Standard libraries present similar risks. Library functions are widely assumed to be robust and well tested, yet they are subject to implementation choices and corner cases like any other software. In ADAS, where libraries are statically or tightly linked into the final executable, subtle deviations from expected behavior can propagate directly into system-level effects.

Because these problems originate below the application layer, they are not easily detected using conventional testing approaches. Integration testing may expose symptoms, but it rarely provides systematic coverage of toolchain behavior. As a result, determining whether the root cause lies in the application logic, the compiler or a library implementation can require extensive investigation. When such issues surface late in development, the associated cost and disruption can be substantial. Even more concerning, if they remain undetected until deployment, they may manifest as safety-critical failures, with potentially severe consequences.

Ensuring reliability through verification 

Managing these risks requires systematic verification of compilers and libraries. This involves demonstrating conformance to relevant programming language standards and consistent behavior across configurations, optimization levels and target platforms.

Structured test suites are central to this effort. By exercising both front-end language features and back-end optimization paths, they can reveal defects that would otherwise remain latent. Problems are not confined to parsing or semantic analysis; changes deep within the optimization pipeline or the code generator can also introduce unintended effects. Comprehensive testing helps surface these issues early, before they impact product development.

Supporting qualification and long-term confidence 

Beyond identifying defects, verification provides the objective evidence needed to support tool qualification. The ISO 26262 safety standard for automotive software requires confidence in the correct operation of the compiler and evidence that the standard library meets the requirements on which the application relies. By testing the compiler against the programming language specification, it is possible to verify that source code is translated into machine code in a well-defined and predictable manner. Likewise, requirements-based testing of the standard library demonstrates that its functionality conforms to the requirements relied upon by the software. Together, these activities provide objective evidence that the generated object code faithfully represents the source code.

Furthermore, the goal of qualification is not to prove that the compiler or library is completely free of errors – an unrealistic expectation for any complex software tool. Instead, the objective is to understand their limitations and known deviations, and to manage them in a controlled way so that they do not compromise functional safety. This understanding is captured in a safety manual that complements the verification results and defines the constraints, assumptions and usage rules for the compiler and library, ensuring they can be applied safely within the software development process.

This approach also supports long-term maintainability. Automotive platforms often have lifecycles spanning decades, during which compilers and libraries inevitably evolve. Systematic validation of updates enables controlled transitions without the need to re-qualify entire systems from scratch.

This benefit has been demonstrated in practice, where early identification of compiler issues has significantly reduced the effort associated with toolchain updates. By understanding tool behavior upfront, organizations can make informed decisions about changes and avoid costly surprises later.

Standard libraries follow similar principles. When assessing a new library implementation, behavioral comparison against a known baseline helps ensure that replacements do not introduce unintended or system-relevant changes.

The role of collaboration 

ADAS development involves many stakeholders: software engineers, functional safety engineers, validation teams and certification bodies. Ensuring that compilers and libraries behave as expected requires collaboration across all these roles.

Verification cannot be treated as an isolated activity, it must be an integral part of a broader safety strategy. When toolchain behavior is well understood and documented, communication between teams becomes clearer, assumptions are explicit and decisions can be justified with evidence rather than intuition.

Strong partnerships between tool providers, system integrators and safety experts further support this process. By sharing knowledge and aligning on verification practices, organizations can reduce duplication of effort and improve overall confidence in their development environment.

Conclusion 

Compilers and libraries may operate invisibly, but their impact on ADAS safety is substantial. Treating them as implicit assumptions rather than explicit verification targets introduces avoidable risk. As ADAS functionality grows increasingly complex, this risk will only increase.

By recognizing the role of the toolchain early and subjecting it to the same rigor as application software, automotive developers can build a stronger foundation for safety. Verification and qualification of compilers and libraries are not optional extras; they are essential steps to ensure that software behaves as intended – from code to road.

A feature in the next issue of Automotive Testing Technology International will investigate the challenges of continuous testing for software, the stages of a typical DevOps pipeline, how companies are measuring software readiness, and more. Read the March 2026 edition here. 

Related news, Software test specialists Solid Sands and Plum Hall team up

Automotive development is evolving as software-defined vehicle programs introduce faster feature cycles and more complex system interactions while meeting strict requirements for safety, reliability and long-term maintainability. Gen AI is now part of engineering workflows. It can help increase development speed, but its non-deterministic behavior, lack of physics awareness and limited traceability make it difficult to apply directly to safety-critical systems. These characteristics make verification, certification and traceability challenging when outputs generated by Gen AI are introduced without constraints.

Model-based design addresses these issues through deterministic execution, executable specifications and physics-based simulation. MathWorks is bringing these strengths together by integrating Gen AI assistance directly into model-based design tooling, enabling engineers to benefit from accelerated workflows while preserving the rigor required for long-term reliability and certification of automotive software.

Simulation as the foundation of trust

Simulation is the foundation of trust in engineering workflows assisted by Gen AI. It provides a controlled environment where system behavior can be verified early and repeatedly. Model‑based design enables closed‑loop simulation within continuous development pipelines, enabling Gen AI‑assisted artifacts to be validated continuously in virtual environments long before software reaches hardware. Closed-loop simulation uncovers defects that emerge only from real‑time interaction between software, hardware and physical dynamics, such as instability, timing issues, saturation and integration errors. Unlike regular software tests that validate code logic in isolation, simulation validates system behavior against requirements under realistic operating conditions, catching safety‑ and performance‑critical issues much earlier.

In leading organizations, ‘shift left’ is not a one-time activity; virtual verification is embedded directly into continuous integration/continuous development (CI/CD) pipelines. Every change triggers automated builds and simulation runs, exercising models against representative scenarios and acceptance criteria. Verification becomes continuous, not episodic.

Scalable development for evolving E/E architectures

Automotive E/E architectures are transitioning from ECU-centric networks to zonal and centralized computing platforms. Software is no longer bound to specific hardware configurations but must now operate reliably across heterogeneous compute targets while remaining portable and scalable, from small controllers to high-performance vehicle computers.

Model-based design supports this requirement by separating system behavior and software intent from hardware implementation. Engineers develop executable models that serve as stable sources of truth. The models can generate production-ready code for a wide range of processors and operating systems, including platforms incorporating AI inference engines and hardware accelerators such as GPUs, DSPs and NPUs. This approach enables the development and validation of AI-enabled functions (e.g. virtual sensors) at the system level, reduces the need to reengineer algorithms for each target, and improves efficiency and consistency across platforms.

Improving collaboration through model-based design

Engineering organizations must transform their collaboration models to keep pace with increased complexity. Integrating simulation, virtualization and automated verification directly into CI/CD workflows supports rapid iteration across software, AI models and hardware acceleration strategies. This model-centric approach helps organizations operate more quickly while preserving robustness, safety and long-term maintainability in the era of software-defined and AI-driven vehicles.

Integrating AI into deterministic engineering workflows

AI is most effective in automotive development when embedded within a deterministic modeling framework. Within model-based design tools, GenAI-generated content is automatically tied to established interfaces, data definitions and architectural constraints. Model Context Protocol (MCP) capabilities empower engineers with AI assistance while preserving the rigor, repeatability and certification readiness.

Long-term maintainability and certification readiness require deterministic behavior, transparent audit trails and verification evidence that accumulates throughout the lifecycle. Model-based design naturally supports these goals by linking requirements, models, test suites and generated code. Continuous simulation produces verification data throughout development rather than only at the end of a program. When artifacts generated by Gen AI follow the same workflows, they inherit this structure. This ensures that productivity gains do not come at the cost of safety, quality or compliance, and that Gen AI can be adopted at scale.

Conclusion

Gen AI and model-based design offer a structured path to accelerate automotive software development while maintaining trust, safety and engineering rigor. Model-based design provides determinism, physics-based validation and traceability. Gen AI adds efficiency and supports faster iteration when integrated within these boundaries.

This combination enables earlier insight into system behavior and deployment across diverse hardware architectures. The model-centric approach ensures consistent collaboration across engineering teams, and promotes reuse and consistency across global programs. Gen AI-enabled model-based design provides a scalable and reliable foundation for developing robust and certifiable automotive systems.

In the September 2024 edition of ATTI, Secondmind’s chief product officer, Morgan Jenkins, discusses the power and limitations of AI

In related news, Agentic AI transforms McLaren Automotive’s entire engineering process

As vehicles become more defined by code and software, the nature of their vulnerabilities is changing. While perimeter security protecting external interfaces, network communications and over-the-air updates have seen significant progress, embedded storage remains a less scrutinized yet highly exposed attack surface.

SDVs process and retain massive volumes of sensitive data from event logs, AI models, vehicle identities, credentials and firmware. This data is typically stored on flash memory within embedded systems, and often its security slips through the cracks. Embedded data is a rising source of risk, particularly when data management is left to legacy file systems that are not designed for these next-generation vehicles.

A new role for flash memory

Historically, automotive storage was used for logging or basic configuration. Today, storage systems are expected to withstand high-frequency data logging, real-time analytics and frequent write/erase cycles often under constrained power and thermal conditions.

Without a robust design, storage becomes vulnerable to security threats. A sudden power loss during a write operation can corrupt entire datasets or firmware. In addition, flash wear or incomplete writes can lead to system instability and contribute to safety risks, which in turn lead to costly in-field interventions.

Insecure storage paths open doors for cyberattackers to tamper with update packages or extract valuable system data. Interestingly, even compliance-grade data encryption alone is not sufficient; it must be paired with integrity verification, secure boot/signed updates and secure key handling.

The importance of embedded resilience 

To counter these risks, automotive engineers need to adopt a new standard for embedded storage that treats reliability and data integrity as central design parameters. Storage architecture must be built from the ground up with resilience at the core to ensure it is capable of handling the operational requirements of automotive environments.

Equally critical is the ability to ensure atomic write operations. In an embedded context, even a single failed write can leave a log incomplete or a configuration file partially updated, leading to inconsistencies that undermine system behavior. Ensuring that every operation either completes fully or not at all is essential to maintaining coherence.

Security must also be native to the file system. Cryptographic safeguards, including encryption for embedded data and secure key handling, help prevent unauthorized access, even in the event of physical tampering or side-channel attacks. While standards such as UN R155 and ISO/SAE 21434 do not mandate specific technical controls, these measures are increasingly expected by OEM security, audit and assurance programs as part of demonstrating effective risk management. This also includes secure erase capabilities. Simply deleting data does not guarantee it is unrecoverable from flash memory. If not properly managed, residual data may remain accessible to attackers, introducing vulnerabilities that persist beyond expected lifecycles.

Finally, any storage solution intended for mission-critical automotive applications must support functional safety requirements, such as those defined by ISO 26262. From a safety perspective, this means demonstrating predictable behavior under fault conditions, including power loss, memory corruption or unexpected system resets, and ensuring the system can transition to or maintain a safe state.

Importantly, these are not theoretical considerations. Testing in automotive-grade environments has shown that purpose-built file systems can maintain 100% data integrity after more than 15,000 hard shutdowns. Such results provide concrete evidence that storage software can contribute to system robustness in environments where reliability and determinism are mandatory.

While compliance with functional safety standards does not in itself address cybersecurity threats, safety and security cannot be treated as independent concerns in modern vehicles. A system that is resilient to faults but vulnerable to malicious manipulation is not ultimately safe. Secure systems must also behave predictably under failure conditions. As vehicles become increasingly software-defined, achieving both safety and security requires coordinated design across storage, software and system architecture.

Ensuring compliance 

New regulatory frameworks such as ISO/SAE 21434, the NHTSA Cybersecurity Best Practices for Modern Vehicles and UN R155 are forcing a deeper rethink of in-vehicle system design. Rather than prescribing specific technical measures such as encryption, these frameworks require manufacturers to demonstrate that systems are secure by design, with traceability, risk management and evidence of integrity maintained throughout the vehicle’s lifecycle. The responsibility for how security is achieved and how it is proven remains with the system designer.

Even when open-source implementations are commercially supported, in many cases, the engineers responsible for integrating or modifying the code do not have deep expertise in embedded storage or file systems. This means that achieving a secure and efficient implementation that holds up under regulatory scrutiny or long-term performance demands, particularly in safety-critical environments, becomes challenging.

Engineers must now validate not just how the system performs, but how it fails and whether it fails safely. This has direct implications for the selection of storage technologies and file systems.

Why embedded storage is a strategic decision

The case for modernizing embedded storage goes beyond risk reduction. It’s also a driver for cost control, performance consistency and long-term product differentiation.

For instance, avoiding flash overprovisioning through better write management can drive significant cost reductions for manufacturers. When scaled across high-volume platforms, this can translate into lifecycle savings in the millions. Factor in reduced maintenance, extended warranties and higher reliability metrics and the ROI becomes even more compelling.

Moreover, embedded storage resilience supports more agile development. Secure file systems with predictable behavior enable faster testing, smoother OTA deployment and better root cause analysis when faults do occur. These are critical advantages, especially in an industry where time-to-market and regulatory agility matter.

Validating storage 

Given these stakes, embedded storage must be fully integrated into the testing pipeline. This means validating storage performance across temperature extremes, power cycling and high-write workloads. It also means simulating fault conditions, including mid-write power loss, unexpected resets or firmware anomalies and observing recovery behavior.

Storage systems that pass compliance tests in isolation may still introduce fragility in multi-component environments. Engineers must test for system-level interactions and confirm that the storage layer does not become the weakest link in real-world conditions.

Securing the future of SDVs 

As the cybersecurity landscape shifts from connectivity to persistence, the importance of secure, resilient data storage grows. The data that remains in the vehicle after the engine shuts off, for instance, logs, credentials and system images, can either support safe operations or become a target for exploitation.

For the automotive engineering community, this is a call to action. Embedded storage must be validated, reinforced and architected for long-term resilience. Not only because regulators demand it, but also because future vehicle safety, reliability and performance depend on it.

In the June 2025 edition of ATTI, industry experts discuss how their cybersecurity strategies are evolving to ensure resiliency 

Testing is an information-gathering activity that reveals how well processes, assumptions and designs hold up to reality. Yet, far too often, the outcomes of testing are obscured behind corporate politics, smiley-face dashboards that hide truth, a lack of metrics, or selective reporting that masks more than it reveals. Without transparency, decisions are based on incomplete or misleading information, and risk is managed by hope rather than evidence.

Testing connects requirements, design and implementation in a continuous loop of learning and correction. When viewed as a separate phase, it becomes an afterthought gatekeeper function at the end of the process. When viewed as a system, however, it becomes a feedback loop for the entire project, identifying defects and performance maladies early, and informing improvement.

Transparency enables this systemic view that allows input from all perspectives. A transparent testing process shows how requirements are verified, what coverage exists, where defects cluster, emerging risks and what impact these have. When test artifacts, results and methods are visible, everyone understands not only what was tested and why, but also that the veracity of those results is open for review. This transforms testing from a reactive activity to a proactive one, enabling adjustments to designs and project plans, and informed trade-offs.

Despite the clear benefits, transparency in testing is often resisted – sometimes unintentionally. Executives and managers prize success, and it is challenging to share uncomfortable status reports. Cultural resistance also plays a role. In some organizations, testing is viewed as a cost center or a necessary evil rather
than an integral part of value creation. That mindset encourages concealment: problems are downplayed to avoid blame, and test reports are sanitized to appear favorable. Another barrier is the misuse of metrics.
A 100% pass rate or a high coverage percentage may create the illusion of completeness, even when critical risks remain untested. Transparency requires metrics that illuminate, not decorate.

Transparent testing depends on process discipline and traceability. Every test case should be traceable to a specific requirement, risk or customer expectation. This traceability matrix not only shows coverage but also highlights gaps – requirements without tests or tests without a clear purpose.

Testing transparency is a human endeavor. It depends on a culture of open communication, respect and shared accountability. Testers should not merely report defects; they should interpret what those defects mean in terms of system behavior and project risk. Developers, in turn, should engage with testers early
in the process, reviewing test plans and understanding how their work will be evaluated.

Leadership plays a vital role here. When leaders encourage openness – rewarding honesty over appearance – they create an environment where issues can be raised early, without fear. Transparency thrives where curiosity and problem-solving replace blame.

Transparent testing metrics tell a story. They show trends, not just totals. For example, defect density by module or test coverage by risk level reveals where attention is needed most. Metrics should guide conversation, not end it.

Qualitative insights are also important. Understanding the why behind a failure often provides more value than knowing how many failures occurred. Transparent teams combine numbers with narratives – quantitative data contextualized by expert judgment.

When teams make their testing and results visible, they make their learning visible. Transparency builds not only better products but also better organizations that value facts over assumptions, collaboration over concealment and continuous improvement over static compliance. In the end, transparent testing is more than good engineering – it is good ethics. It is the practice of honesty, discipline and shared accountability in the service of building something that genuinely works, and works as promised.

The September 2025 edition of ATTI carries a feature exploring how to foster transparency in automotive testing

Physical tests at any level introduce risks. These include logistical and planning challenges, as well as additional program costs.  Despite this, the demand for focused testing to support model correlation is increasing. Robust design verification (DV) and product validation (PV) programs remain non‑negotiable, underpinning confidence in product safety and performance.

The purpose of physical testing

Testing has always been a necessary way to quantify and assess many aspects of a product’s performance and characteristics.

Physical test results have long been the benchmark against which computer-aided engineering (CAE) models are correlated – a necessary step to ensure simulations represent reality for the full range of operating conditions.

Recent trends

With ever-improving computational power, product development programs are increasingly starting with the creation of digital twins, which are high‑fidelity, virtual representations of physical systems or components. Rather than acting solely as a pass/fail assessment, early test cycles are now tailored to strengthen model accuracy – deliberately selected load cases, boundary conditions and sensor arrays feed the virtual model with targeted data.

Test phases often mirror elements of conventional DV plans, but with a different emphasis, focusing on correlation points and characterization boundaries that make the digital twin trustworthy across the design space. That can mean smaller, more impactful tests executed quickly and iterated frequently.

Reducing risk through early virtual correlation

While physical testing is still a necessary part of any development program, early correlation with virtual models and simulations minimizes technical, fiscal, logistical and schedule risks. Issues discovered late in a program or close to production are far more expensive to fix and can jeopardize launch timelines. In extreme cases, they can even damage consumer confidence and brand reputation.

Equally important is the less quantifiable but critical return on investment – confidence. Confidence to scale production, to pass certification cycles with fewer surprises, and to stand behind a product in service. Well-executed test programs reduce uncertainty. They give engineering, manufacturing and business stakeholders the evidence to make faster, bolder decisions.

Will digital twins replace the need for physical tests?

Digital twins are powerful accelerants. They let engineers explore options, run virtual what‑if scenarios and optimize systems faster than physical prototypes allow. But regardless of how well correlated they are, digital twins cannot capture every real‑world uncertainty.

There are factors that can only arise during physical testing, such as manufacturing variability, material property deviations or defects, and subtle system‑to‑system interactions. These can defeat even the best virtual model. Some sectors – aerospace is a notable example – have tightly controlled material processes that reduce this uncertainty, but that control comes at the expense of longer development cycles and higher cost.

Physical testing is the data source that validates and calibrates digital twins. It supplies ground truth for material behaviors, component interactions and environmental influences. In turn, validated digital twins enable predictive maintenance strategies, support virtual certification scenarios and let teams explore failure modes that would be destructive or impractical to test physically. The sooner a manufacturer can build and trust a digital twin, the more effective and efficient the subsequent development cycles become.

What can we expect in the future of testing?

The pace of testing progress will be driven by two technical shifts: increased modeling capability and faster, higher‑quality test data.

Modeling is becoming more accessible. Computational power and improved numerical methods now make it commercially viable to model fluid systems and thermal‑mechanical interactions that were once prohibitively expensive. Improved simulation of splash lubrication, transient cooling and multi‑physics coupling is already narrowing gaps to physical testing.

Real‑time processing and near‑continuous model updates will become standard practice. This places new demands on instrumentation, automation and test engineers. To capitalize on shorter development cycles, test systems must deliver reliable data at much higher rates and with faster post‑processing.

An example from development practice is a highly automated maximum torque per amp (MTPA) optimization routine. By combining machine learning, advanced test equipment and in‑house control and automation systems, it is possible to iterate tens of thousands of operating points in a matter of days. This delivers processed results ready for immediate analysis, which can be fed back into digital twins quickly, shortening the loop between hypothesis, test and update.

We should also expect innovation in measurement techniques and sensors. Telemetry solutions for rotor temperature, non‑intrusive torque measurements, and compact, high‑accuracy speed sensors are examples that will enable new test regimes. Treating test capability as strategic infrastructure by investing in well‑designed assets, integrating them into early design phases and using their data to feed both physical and virtual models will be essential.

Testing as a strategic enabler

Testing is often seen as a validation chore at the end of development. In a world of digital twins and rapid iteration, testing should be reframed as an enabler. It can be the provider of trusted data that lets virtual engineering unlock value.

The future will not see physical testing disappear. It will see testing become faster, more expansive in terms of data acquired, and more deeply integrated with simulation. This shift will reduce program risk, speed up time-to-market and, ultimately, enable the kind of propulsion innovation the industry continues to demand.

For engineers and program leads, the practical takeaway is simple: treat physical development testing as strategic. Build virtual model correlation into early test plans, invest in the right instrumentation and test equipment, and use those test results to mature digital twins as early as possible. Do that, and testing will shift from a necessary overhead into a competitive advantage.

Explore: Electroformed contacts set to redefine high-end electronics testing

Why car updates are harder than phone updates

Chokepoints in the supply chain

Virtual testing: a game changer 

Looking forward

Large utility vehicles significantly trail their passenger car counterparts when it comes to aerodynamic development. There are many reasons for this, including less stringent regulation, longer product cycles, poorly adapted resources and different customer priorities, but the winds of change have finally arrived.

Euro 6 regulations began pushing many larger vans into the category affected by the CAFE standards, and another significant step will be made with Euro 7 regulations set to take effect in 2027. Fierce competition is forcing OEMs to reduce their development cycles to stay competitive, while customers are being bombarded with information about the potential for operational cost reduction thanks to aerodynamically optimized vehicles.

Finally, with the December 2024 inauguration of the Automotive Test Section (ATS) at DNW’s Large Low-Speed Facility in the Netherlands, the large utility vehicle industry has a turnkey solution for precise aerodynamic measurement. In fact, the ATS is in complete accordance with the Worldwide Harmonized Light Commercial Vehicle Test Procedure requirements. This perfect storm of events will inevitably accelerate the shift toward more aerodynamically efficient utility vehicles.

When I was assigned as chief aerodynamic engineer on the new Renault Master project (XDD) in early 2018 – during the business strategy phase and just before the preconcept engineering kick-off – aerodynamic optimization for large vans was close to non-existent at the company. However, a competitor that had just won a coveted award was making a significant marketing effort to promote its world-class aerodynamic performance, which caught the attention of top management.

At the kick-off event a few weeks later, it was announced that the XDD Master would be the world’s most aerodynamic large van at launch. It was an incredible challenge. It took more than three years of focused teamwork to achieve the goal. Using a combination of competitor deep-dive analysis, hundreds of CFD calculations, around 200 hours of reduced-scale wind tunnel testing and regular intensive taskforce brainstorming, the general shape, engine cooling and exterior features were optimized. The achievement was confirmed during WLTP certification testing at DNW.

The result is a new Master large van family with 20% less drag and considerably reduced energy consumption. This means lower operating costs but also increased range and crosswind stability and, most importantly, without a negative impact on the vehicle’s utility, access, ergonomics or payload. The ‘advanced aerodynamics’ were specifically cited by the 25 international journalists that voted the new Renault Master IVOTY 2025.

While the XDD aero project can be considered a success at this point, the story continues with prep for Euro 7 certification. This month we will perform the first Master pre-Euro 7 certification testing using the wide-belt system for dual-wheeled utility vehicles. It’ll be a chance to test and perfect the Euro 7 aero package while also making our first use of the rolling resistance system in the ATS.

As I look back on my experience with this project, one subject particularly stands out: the issue of computer simulation versus physical testing. Clearly CFD will continue to gain importance and use as it is constantly improving. However, several large hurdles remain, which prevent an extremely accurate correlation with physical testing. The main limitation of CFD simulation is that it does not take into account model deformation.

At the 140km/h measurement speed of WLTP testing, things move a lot. Rubber air dams bend back, doors and hoods move outward, wheel arch liners and underbody panels vibrate, and the flexible air guides for engine cooling deform considerably. In addition, the tires and chassis change shape and position under the weight of the vehicle. None of this is taken into account by CFD, as the calculation burden would increase enormously.

In addition, utility vehicles have a huge wake compared with passenger vehicles, which accounts for a majority of the drag. A slight miscalculation in wake balance can have a large impact on the CdA result calculated by the software. Having compared a large number of wind tunnel tomography images and CFD wake calculations, I know that they are very similar but never identical. I believe a large part of the error in correlation I witnessed was caused by this discrepancy.

Therefore, I learned to use CFD for what it’s great at: visualizing the airflow. With CFD you can quickly detect early detachment at the rear, areas of localized turbulence and leaks in the air guides. There’s no better tool to explain to the architectural or design department why a change is needed. But when you need the precise drag value for a project milestone, or when it’s time to tweak the air dam or rear roof drop to balance the wake, you have to spend some time in the wind tunnel.

This thought leadership piece was published in the September edition of ATTI. Read the magazine online for free – it’s packed full of news, interviews and features, including how to maintain transparency in testing, the story behind the new Nissan Leaf, and the latest in battery testing and simulation

At Mahle Powertrain, we already work to EU standards while maintaining comprehensive UK certification capabilities. This gives us clear visibility into what’s coming. We’re seeing PHEVs that would achieve 10g/km CO₂ ratings under current UK protocols potentially jumping to 30g/km or higher under Euro 6e-bis utility factor calculations. This is a fundamental change that demands immediate attention from pre-production testing teams.

The challenge is particularly acute because the new standards don’t just change the final compliance testing; they alter the calculation of the OEM fleet average CO₂, causing PHEVs to contribute more to this fleet average CO₂. This means OEMs have to sell more EV vehicles in a period of low consumer demand or improve the efficiency of the ICE and EV systems in PHEV and hybrid applications. OEMs continuing to develop PHEVs using current UK testing methodologies risk discovering compliance issues too late in the development cycle to implement cost-effective solutions.

Understanding utility factor calculations               

The core of Euro 6e-bis lies in utility factor calculations, which alter how plug-in hybrid vehicles are assessed during type approval. Under current UK regulations, PHEVs undertake straightforward charge-depleting and charge-sustaining test cycles that produce CO₂ figures that are not representative of all use cases. Euro 6e-bis introduces an updated calculation that biases the calculation toward the ICE operation of the vehicle, therefore placing increased relevance on ICE efficiency.

From our technology-agnostic testing experience, the utility factor methodology considers how frequently drivers actually charge their PHEVs, applying statistical weighting to different driving scenarios. This means that a PHEV designed and validated under current UK protocols could see its official CO₂ rating triple when subjected to Euro 6e-bis testing, even without any changes to the vehicle itself.

For pre-production testing teams, this focus on ICE and EV efficiency creates immediate challenges. At Mahle, we’re addressing this through our range extender (REx) and advanced battery systems technology, which allows us to optimize both electric range and charge-sustaining performance to meet the new requirements.

Validation timelines and fleet average impact

The transition to Euro 6e-bis creates significant challenges around OEM fleet average CO₂ compliance, particularly given consumer apathy toward private EV purchases. The issue for OEMs is the fast implementation of the UK regulation, which needs careful planning to ensure there are no fleet average CO₂ exceedances – a significant risk when considering what consumers currently want to purchase.

We’re working with several OEMs to understand how the new testing protocols will affect their ability to meet fleet targets while satisfying market demand. The emphasis on improving ICE efficiency and implementing improved battery technology becomes critical when PHEVs contribute more heavily to fleet averages under the new calculation methods.

OEMs with PHEVs planned for launch in late 2026 or early 2027 face strategic decisions about powertrain development priorities. Euro 6e-bis requires different approaches to ICE optimization and battery system integration.

Progressive OEMs are implementing strategies that account for regulatory compliance and market realities; powertrain configurations that can achieve acceptable fleet average contributions while meeting consumer expectations for PHEV performance.

Changing PHEV development processes

Forward-thinking OEMs are implementing Euro 6e-bis validation throughout development processes, with Mahle’s ICE efficiency and REx/PHEV technology providing crucial capabilities for customers navigating this transition. Our range extender technology and advanced battery systems allow OEMs to achieve the balance between electric efficiency and ICE performance that Euro 6e-bis demands.

The process changes extend beyond testing protocols to encompass fundamental powertrain architecture decisions. PHEV concepts that work well under current UK regulations may be fundamentally unsuited to Euro 6e-bis requirements, making early validation crucial for avoiding costly late-stage changes.

We’re seeing OEMs revisit their PHEV portfolio strategies in light of both Euro 6e-bis requirements and market demand patterns. Our REx and battery technology solutions help OEMs develop powertrains that can meet the new utility factor calculations while delivering the performance characteristics consumers expect.

For Mahle Powertrain, our early adoption of Euro 6e-bis testing protocols positions us to support OEMs through this transition. Our dual UK-EU testing capabilities allow us to provide comparative analysis that helps OEMs understand the specific implications of EU6e and beyond, along with global regulations, for their vehicle programs.

To ensure that OEMs have the correct fleet mix to achieve customer requirements and type approval legislation requirements, Euro 6e-bis represents a current development reality that demands immediate attention. Since EU6e is already established in Europe, those adapting advanced ICE efficiency will navigate the transition successfully while meeting regulatory requirements and market demands.

In related news, UK’s Faraday Institution pledges £9m for advanced battery research and commercial scale-up

The development of vehicles is complicated. In the past, we built prototype versions to learn the scope of the system and gather details on its functionality and performance. Hardware-in-the-loop testing is a vital enabler for safe, reliable and cost-effective development. Besides helping to define systems, it is used to test a system long before all the constituent components have been made.

HIL testing is an essential component within the broader framework of model-based development, particularly for engineering complex control systems, embedded software and safety-critical applications. It integrates physical hardware components (such as ECUs or sensors) with simulated components in a real-time simulated environment. Unlike pure software simulation or physical road tests, HIL provides a hybrid, highly controlled setting. We can simulate missing components under development and exercise a hybrid of actual and simulated components under simulated operation. 

Vehicles are increasingly loaded with ECUs, ADAS and intricate software. Developing multiple ECUs takes time, often starting with prototype parts that represent some of the attributes of the specific system. Although prototype creation is much faster than it used to be, it still takes time to lay out boards and write software for features. HIL provides the ability to explore multiple system designs and functional apportionment early in the development effort.

Systems include ECUs, electrical components and sensors that are part of the entire system. A system may also include models of other elements or simulated components. The design of the hardware portions of the system that emulate other components will require low latency – that is, propagation of signals and component broadcasts via communication. This will include an emulation of the system environment, where high-fidelity component models emulate ECU responses, vehicle dynamics, road conditions, sensor inputs and fault conditions. Real-time computers and interfaces connect hardware and simulation for instantaneous interaction.

Designing and managing high-fidelity simulation environments requires specialized expertise. There is a need for expertise in electronics and electrical hardware, software and real-time simulation, which is not often found in one person.

Setting up HIL systems requires specialized, often expensive, hardware and simulation tools. This can limit adoption, especially for smaller teams or startups. The initial HIL setup, for example, will need to be on a platform that does not introduce undue latency beyond the expectations of the vehicle system. Hardware that can coordinate multiple ECUs and communication protocols while avoiding timing mismatches is critical. Even minor latency issues or signal desynchronization can skew test results and mask actual faults. 

Simulation of modern vehicle systems requires high-fidelity models for subsystems such as motors, sensors and ECUs. The models are only as good as the hardware they mimic, which is reflected in the initial setup costs. Capturing second- and third-order effects or dynamic behaviors makes models complex and demands powerful simulation hardware. Inaccurate or incomplete models lead to misleading test outcomes, undermining the value of HIL validation.

Sensors, actuators and other hardware used in HIL may have physical or signal constraints, meaning some aspects of real-world behavior can’t be fully replicated in the lab without investing in engineering time to uncover and adequately address them. This requires engineering talent to understand the gap, work to close it where possible, and note the limitations in simulating the system. This is but one level of specialized skill required for success.

Generating realistic sensor data and simulating all relevant physical phenomena (including edge cases and faults) is challenging. Advanced use cases such as ADAS require vast, high-quality scenario libraries, which are time-consuming to build.

As vehicle features grow in complexity and new standards emerge, HIL test benches need frequent updates to remain relevant and support continuous integration and version control. Scalability to accommodate new hardware or test scenarios can be a logistical challenge. The tool itself will need to fall under configuration management for two reasons. First, there will be a need to address specific system incarnations if the HIL rig is used to model more than one vehicle platform or a variety of vehicle incarnations. Second, we will need to be able to go back to previous versions of the test tool. 

Automating scenario generation, software reflashing and repeated validation while maintaining reproducible and valid ‘golden’ test data is challenging, especially across development cycles. The test and verification of the test fixture becomes more difficult with the complexity of the HIL. Ultimately, we must be able to make tangible statements of the quality of any test fixture, but it takes time and effort to understand the veracity and limits of the HIL.

Some aspects may not be testable with HIL, so human-in-the-loop or vehicle-in-the-loop stages are still necessary.

Hardware-in-the-loop testing has been a vital pillar of auto engineering for probably a decade, and with increasing complexity, its value has increased. With HIL rigs, we can explore design incarnations and test them in a simulated environment – well in advance of material availability.

FEA is historically tricky and expensive, leading many companies to skip pre-analysis steps or the process altogether. Software tools are emerging that enable design and material engineers to take back control of the pre-design process. The role of the typical design engineer has thus rapidly transformed in recent years. Self-enabling software is reducing lead time, enabling removal of waste from the creation process and improving communication barriers.

The manufacturing industry is experiencing a significant shift toward digital transformation, which is altering traditional engineering roles. Design engineers, once heavily reliant on manual processes, are now at the forefront of adopting smart manufacturing tools.

These advancements empower engineers to work faster, smarter and with enhanced precision. But how exactly will these transformations shape the role of the design engineer in 2025 and beyond? 

A demanding connective world

Manufacturers must now be more agile and adaptive in 2025, quickly anticipating the changing market demands and customer needs.

In the 2025 Smart Manufacturing and Operations Survey by Deloitte, 85% of respondents said they believe smart manufacturing initiatives will transform the way products are made, created and improved, and 49% said they believe operational benefits are the most sought-after value offered by smart manufacturing, with improved efficiency and reduced production costs.

The NIST (National Institute of Standards and Technology) describes smart manufacturing as being “fully integrated” and “collaborative” and that it responds in real time across all supply chain functions. Forward-thinking companies are already adopting this to stay relevant and competitive in their industry.

But businesses will not be the only ones that need to adapt. The role of the modern engineer is also quickly changing. Less hierarchical engineering job roles, like the mechanical design engineer, can now leverage automation and self-enabling design tools to perform historically complex analysis.

Once discarded due to its time-consuming nature and technical skill requirements, pre-design analysis can now be performed by mid-level engineers, enabling design flaws to be identified and addressed earlier in the production process.

Three changes in the design role

The role of the mechanical design engineer is evolving to become more digitally integrated and collaborative, with a strong focus on sustainability (reducing waste).

I see this transformation as beneficial in three areas.

1. Saving time on production

The pre-analysis step has historically been skipped, resulting in more prototype waste and project costs. According to a McKinsey & Company report, digital and automated design technologies can reduce product development cycles by up to 30%, significantly cutting lead times and enhancing productivity (McKinsey, 2023).

With the development of new technologies, mechanical design engineers can now relieve pressure on lead engineers. Ultimately, these software tools are transforming mid-senior engineer roles, enabling traditional pre-production steps to be eliminated or allocated to a lower-cost employee, overall increasing project speed. Specifically, these tools have reduced long lead times in creating prototypes, which typically took two months or more.

2. Removing prototype waste

Traditionally, engineers created several prototypes for testing before sending the final design to production. Although this was important to reduce problems down the line, it would result in excessive prototype waste and the use of materials. It was necessary to 3D print several models for testing – this can now be avoided with self-enabling pre- and post-FEA analysis software.

3. Reducing communication barriers

Modern analysis software helps to reduce friction from cultural, time and language barriers. Engineers often work across time zones and languages, delivering projects at tight deadlines. Information can be ‘lost in translation’, which causes delays and more prototype waste. Self-enabling software with a two-dimensional cross-section and a smart GUI enables application design engineers to work on projects quickly and own the pre- and post-design in their local team. This also reduces language and time barriers.

Manufacturing is modernizing, and so too is the role of the typical mechanical design engineer. It’s already underway. Dedicated software built with a two-dimensional cross-section and a smart GUI is already transforming the mid-level engineer’s role, eliminating time-consuming tasks and speeding up processes.

Overall, the increase in efficiency will save companies on large project costs and lead to better customer satisfaction.

RELATED: Testing for recall: Why OEMs need QA that anticipates failures, by Pete Gillett, founder of Marketpoint Recall