Automotive development programs are executing more tests than ever – across SIL, HIL and full-vehicle levels. Regression suites are expanding, automation rates are increasing and coverage metrics continue to improve. Yet confidence in system behavior is not increasing at the same rate. In many programs, the opposite is observed: testing effort grows but release decisions remain difficult, late defects persist and uncertainty in safety-critical functions remains high. This raises a fundamental question: what if the limitation is not test execution but the way testing is defined?

With the transition toward software-defined vehicles, many organizations have adopted testing approaches from IT environments: CI/CD pipelines, large-scale automation and coverage-driven validation. These approaches are effective in domains where failures are recoverable and can be addressed post-release. Automotive systems, however, operate under fundamentally different constraints. As such, functional safety (ISO 26262), SOTIF considerations and increasing cybersecurity and homologation requirements demand a different level of assurance.

But this distinction is increasingly blurred. Modern vehicle architectures combine IT-based systems, such as infotainment, with safety-critical domains on shared platforms. Testing must therefore reconcile both worlds: coverage-driven validation and risk-driven validation. In IT environments, increasing test coverage is often a reliable proxy for confidence. In automotive systems, this assumption breaks down.

It is entirely possible to achieve high traceability, extensive regression coverage and broad validation across SIL, HIL and vehicle levels – and still miss critical scenarios. Based on patterns observed across multiple large-scale integration programs, regression suites can grow by 30-40% within a single release cycle, while defect detection shifts toward later vehicle-level validation phases.

The issue is not a lack of testing. It is a lack of risk relevance. Specification is not reality. Many automotive systems behave correctly under specification, yet still fail in real-world conditions due to timing dependencies, sensor ambiguity or unforeseen combinations of valid system states. This is particularly evident in SOTIF-related scenarios, where systems operate as designed but still produce unsafe outcomes.

However, not all critical scenarios can be derived up front. Hazardous behavior often emerges from previously unknown combinations, requiring large-scale simulation, data-driven scenario discovery and long-tail validation.

Testing confirms expected behavior, but not necessarily that expectations are complete. It is still widely treated as an execution function. In safety-critical systems, this reaches

its limits. A more effective model shifts testing toward risk ownership – prioritizing system-relevant scenarios, focusing on interactions and integrating safety, SOTIF and cybersecurity early. In practice, however, regulatory constraints remain.

Test cases linked to safety requirements cannot simply be removed without affecting traceability and safety cases. As a result, extensive regression suites persist – not by choice, but by necessity. What changes, therefore, is not the volume of testing but the way its value is defined. In practice, this requires a structured approach to identifying system-relevant scenarios – something traditional requirement-based methods cannot provide.

The real shift is not in tools but in thinking: from coverage to risk relevance, from execution to system understanding, and from compliance to assurance.

Automotive systems are becoming more complex, connected and safety critical. Testing must evolve accordingly, not by doing more but by redefining its purpose. Risk-based prioritization, scenario-driven validation and large-scale simulation must work together, because in practice, organizations do not struggle with too much testing, they struggle with identifying which scenarios truly define system behavior. Until this problem is addressed, increasing test volume will remain the most defensible – but not necessarily the most effective – strategy. And those who solve this problem will define the next generation of automotive testing.

For all the talk of digital twins transforming engineering, we still seem to be caught in a loop, treating digital twins as oversized simulations rather than the living, evolving systems they are meant to be. I’ve seen this pattern repeat itself across teams and companies: someone unveils a ‘digital twin,’ and what we’re really looking at is a static 3D model with a few data points layered on top. It might be a useful tool but it is not a twin. A twin reacts. It learns. It contradicts when your assumptions are wrong. And most importantly, it gives you uncomfortable truths about a system while it is still being designed.

Most digital twins fail not because of weak models but because the real world refuses to behave as neatly as the data layers assume. That’s the part the slide decks usually skip. The real world is noisy. Signals drift. Components change. A tiny inconsistency in one dataset ripples through hundreds of processes. The problem is not creating a beautiful model; it’s keeping that model honest as thousands of micro-events unfold across the vehicle lifecycle.

The evolution from simulation to true digital twins is often misunderstood. A simulation is static – you feed it assumptions and see what happens. A digital model adds structure but still doesn’t care about the world. A digital shadow listens to the physical system, but only in one direction. A real twin, however, fights back. It learns from physical behavior, updates its internal state and tells you when your process or design has drifted.

That bidirectional loop is the part that requires real discipline – and real humility – because it forces organizations to confront data inconsistencies they previously managed by ignoring. In practice, this means building systems capable of reconciling data from dozens of sources, not just within engineering but across logistics, testing, suppliers, aftersales, compliance and even market regulations. When done correctly, a digital twin becomes a kind of cognitive engine for the entire lifecycle. When done halfway, it becomes another isolated tool that looks impressive until you ask it a simple question it can’t answer.

The industry’s pivot toward electrification has only magnified this. High-voltage batteries, for example, have their own data realities: cell provenance, CO2 accounting, traceability, regional regulations, safety rules and thermal behavior models that must all agree. A twin that cannot integrate these layers is simply not useful – yet many OEMs still treat them as separate IT tasks rather than components of a unified digital backbone.

And then there’s the human factor. Engineers worry about adding complexity; IT teams worry about scalability; management worries about cost; suppliers worry about sharing data. Everyone is right, and yet the result is predictable: fragmented systems, duplicated data and an unfortunate illusion of control.

When we talk about digital twins as enablers of AI or automation, this fragmentation becomes the biggest barrier. AI amplifies the quality of the data it receives, whether good or bad. A clever anomaly-detection model is useless if half the anomalies originate from inconsistent data definitions rather than real physical behavior.

So perhaps the most vital lesson learned is that digital twins are not software projects. They are organizational projects. They force departments to agree on definitions, interfaces, quality standards and responsibilities. They expose process gaps that were previously hidden by manual workarounds. They require not only good engineers but aligned incentives. This is uncomfortable work. But it is also where the competitive edge lies.

Looking ahead, the future of digital twins is not just more data or more sensors. It’s greater honesty. It’s tighter feedback loops between the virtual and physical worlds. It’s twins that diagnose themselves, adapt to new conditions and understand the impact of a design change before a single component is manufactured. It’s cross-company twins that speak a shared language rather than proprietary dialects.

The promise of digital twins is not perfection. It is awareness. It is transparency. And if we can accept that the real world will always surprise us, maybe we can finally build digital twins that are capable of surprising us too – in a good way.

Vehicles today are continuously evolving software platforms, which puts new pressure on how testing is structured across the lifecycle. To keep up with frequent releases and OTA updates, the optimal use of SIL, HIL and vehicle integration (VI), also called vehicle-in-the-loop, becomes a strategic element rather than a tooling detail.

In SDVs, functions are updated long after SOP, so relying on late-stage vehicle tests alone is no longer viable for safety or schedule. There is considerable pressure to maintain a rapid, continuous release cadence. Testing must be pushed earlier into development while still providing defensible evidence for safety cases and regulatory expectations over multiple software generations.

A layered approach – SIL, HIL and VI combined with on-road testing – provides a progression from fast, scalable virtual (model) checks to highly realistic, driver-in-the-loop evaluations. When those layers are integrated into a coherent architecture, they enable continuous regression across every release and OTA campaign. From my experience, I place great value on regression testing.

If you have read any of my work, you will know my penchant for a common lexicon. SIL enables feature exploration before production on a virtual ECU (subsystem) or host, connected to simulated components, sensors and communication networks (models). It is optimized for early virtual system integration testing, enabling rapid execution of thousands of scenarios before hardware and full production software are available.

HIL adds realism by connecting real ECUs or domain controllers to real-time components and network models on a test bench – a vehicle in the lab. This enables verification of timing behavior, network load, diagnostics and safety mechanisms under controlled yet representative conditions, well before full vehicles are built. From experience, securing time on the vehicle is not trivial, and we need to have some confidence in the product and system before VI.

VI testing takes place in a real vehicle on a proving ground, with its perception and control systems interacting with a controlled virtual environment. VI bridges the gap between lab rigs and road tests, enabling safe, repeatable execution of complex, hazardous scenarios that would be difficult to stage in the real world, in real time.

SIL, HIL and VI deliver the most value when they are treated as a progression rather than as competing options. SIL is ideal for early, rapid fault discovery, software refactoring and large-scale scenario sweeps during early development, when interfaces are still fluid and hardware is not yet fixed.

Once software stabilizes and hardware is available, HIL becomes the workhorse for ECU and domain-level integration, confirming that real electronics and networks behave as expected under realistic loads, failures and transients. VI and structured on-road campaigns then take over for full system behavior, human-machine interaction and vehicle dynamics in complex traffic, while reusing core scenarios defined earlier in SIL and HIL.

In an optimized SDV strategy, scenarios and requirements are progressively elaborated through learning enabled by SIL, HIL and VI. A lane change with a cut-in vehicle, for example, is first debugged in SIL, then checked for timing and network behavior in HIL, and finally executed in VIL on a controlled track and then on-road tests to confirm full-system performance.

Because SIL and HIL rely on virtual elements, sensors and environments, the credibility of their results depends on model veracity. Model veracity includes fidelity (the extent to which the model details represent the actual system), validity range (the range of applicability) and quantified error relative to physical measurements.

A practical approach is to treat model correlation as a formal activity. Engineering, rig, dyno and track tests are used to calibrate models; error bounds are computed for key outputs, such as forces, temperatures, signal delays and sensor artifacts; and these bounds are documented as part of the test environment definition. This makes it clear which requirements can be verified with confidence in SIL or HIL, and which still require VI or real-world testing due to model limitations.

When SIL, HIL and VI are used as a coherent stack, with clear definitions, effort to obtain strong model veracity and disciplined configuration management, they become an enabler for continuous delivery in SDVs. High-risk, safety-critical scenarios can be re-executed selectively in SIL and HIL for each code change. At the same time, VI and on-road checks provide final confirmation before wide OTA deployment. The result is a test strategy that aligns with the SDV business model: rapid, frequent software evolution, anchored in a reusable body
of trustworthy test evidence spanning virtual benches, real hardware and real vehicles.

GM president Mark Reuss reflects on a lifetime working at the Global Technical Center as the facility celebrates its 70th anniversary

It was 70 years ago last month that General Motors unveiled perhaps our biggest launch ever: the General Motors Global Technical Center campus in Warren, Michigan. The Tech Center was celebrated back then as “where today meets tomorrow,” and that’s even more accurate in 2026 as it was in 1956.

My passion for the place where today meets tomorrow goes back thousands of yesterdays to my childhood, when my dad would routinely bring me to work with him on weekends. No matter where we went, my eyes were wide, my heart beat fast and my brain worked overtime to soak up as much as it could.

Coincidentally, my dad’s dream to work at the Tech Center stemmed from a road trip to see it with his parents. Soon after, he and my mom moved up here from the farms of Illinois with US$100 to their name, and the adventure was on.

Fast-forward to the present. This place is still creating the future, and I still find myself amazed at what goes on here on a daily basis. It’s not difficult to summon that childlike wonder I used to feel – one of the many reasons I love my job and I love coming here. I feel blessed to drive in the Mound Road entrance every day, especially when I imagine the thrill of driving up to it for the first time. That hooked dad and me, and it still helps to attract new employees and refuel the talent pool today.

A decade ago, we committed US$2bn to the renovation and refurbishment of the campus, and we did it the right way, as close to Eero Saarinen’s original vision for it as possible. The investment included nearly US$900m for the Wallace Battery Cell Innovation Center and Ancker-Johnson Battery Cell Development Center, which together give us a world-class battery R&D hub, bringing today that much closer to tomorrow.

We also built the beautiful new Design West center, which absolutely looks like it belongs here, as well as our pre-production facility to hand build the ultra-luxury Cadillac Celestiq. We renovated the Vanderbilt House, which had previously been used for everything from an executive cafeteria to furniture storage to a Quizno’s Subs. We revamped all the R&D labs, software and quality labs, advanced manufacturing areas – in short, everything everywhere. Every workspace is someplace I’d be happy to work in, no matter what. I’m very proud of what we accomplished here, and also very glad it’s done. Happy to see the pylons picked up and the port-a-potties loaded back onto trucks.

As a result, I think the campus is better than it’s ever been. It covers 710 acres, with 25,000 people working in this ‘city of innovation’, more than ever before, all changing the auto industry for the better, and creating tomorrow, today.

For 70 years, the Tech Center has helped shape the modern automotive industry, driving the US economy, contributing to the national GDP, and supporting families across America and here in Michigan. Our investments here and in other Michigan facilities support thousands of highly skilled roles in engineering, design, software and advanced manufacturing.

And our investments in Michigan don’t stop there. Today we announced a US$50m commitment to support communities in the state through 2030, expanding our long-standing investments in education, workforce development and community partnerships across the state. We have a long history of giving back in Detroit and Michigan, and this reflects our focus on generating opportunities for students, educators and families.

Just as we have taken the time and resources to invest in our people and facilities, we are helping ensure the vehicles, skills and industrial capabilities needed to create the future are found in Michigan. Giving back has always been very important to me and my family, so I’m proud to connect celebrating our Tech Center’s 70^th anniversary to helping our community build a better tomorrow. I know my dad would be proud, too.

This article was original published on the GM media site.

The March 2015 edition of ATTI carries a site visit of GM’s global powertrain engineering hub in Pontiac. Email the editor, Rachel Evans, for a copy

GM’s executive director for compute and connectivity hardware, Aaron Leiba discusses the OEM’s modernized approach to vehicle connectivity engineering

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