The emergence of SDVs, AVs and AI is changing the requirements for testing the vehicle and its functions. ASAM standards have provided a solid basis for specifying and executing tests for over 25 years, but existing methodologies need to evolve – virtual methods complement physical tests and coverage-based strategies involve data on a large scale.
In this interview ahead of his presentation at The Future of Automotive Testing Conference in Novi, Michigan, on October 22, 2025, ASAM CEO Marius Dupuis shares how the organization is adapting its standards to new testing requirements and how its holistic view on test specification can enable the same language across all stages of testing.
How are SDVs, AVs and AI changing the requirements for testing the vehicle and its functions?
SDVs change the architecture, AVs the scope of operation and AI the entire safety argumentation.
AI is a great tool that achieves functionality faster, but unknowns in reasoning mean we must test AI-based systems extensively, yet reasonably, across the operational design domain (ODD). AI can create test cases and virtual environments at scale, lowering entry barriers for engineers by giving natural-language input means.
SDVs, with their new architecture and zoning of functionality, shift the testing task from dedicated, independent and moderately integrated components to centralized, highly integrated hardware. Discussions in our standardization projects will likely focus on streamlining access to parts of a central compute device, rather than individual devices. This requires clear APIs and access mechanisms based on, for example, credentials. It will be interesting to see how testing zoned architecture changes at component and system levels.
Finally, AVs are evolving along constraints of (cheaper) sensor technology and regulation. They must be tested on a massive scale to achieve sufficient ODD and scenario coverage. The only thing missing is a universal, clear definition of “sufficient testing”.
ASAM is looking from a use-case perspective. We initiated the ASAM TestSpecification project to match test methods with environments, and our standards to artifacts from test definition, execution and the collection and management of test data and results, for better harmonization.
Why is deployment becoming a continuous process?
No software is ever finished. Today’s vehicles are equipped with many sensors and hardware whose use may evolve, even without a setup change. New functions may be deployed and existing ones optimized. This requires updates beyond typical (bi-)annual technical inspections. As vehicles become ‘computers on wheels’ – connected to other devices – security patches, similar to smartphones, will be necessary. During a presentation at CES 2024, an OEM was asked when the functionality they were showcasing would be available. The answer was, “That will be OTA’d”.
How are existing methodologies evolving in response?
For vehicle diagnostics, testing methodologies are evolving from an on-premises activity to a remotely executed option. This affects calibration tasks – the values of parameters; and diagnostics tasks, such as reading parameters and variables.
With continuous deployment, interaction possibilities are almost unlimited, so we must depart from fixed-signal specifications and “ask” the vehicle for its capabilities and what it is “willing” to reveal. The decision about what is available lies with the stakeholder that implemented the software or functionality, typically the OEM.
These principles and capabilities are included in ASAM SOVD (service-oriented vehicle diagnostics), soon to be published by ISO.
Why is it important to speak the same language across all stages of testing?
The entire functionality of a system is tested in different stages, environments and methods. Early testing will be mostly software-based, and then later hardware. If test artifacts cannot be reused, time is wasted and identical test content not guaranteed. In test scenarios, a cut-in maneuver remains whether in simulation, proving ground or on a real road. The execution is not necessarily identical, but the description must be. Without standards, there is no single language to describe tests identically across environments, risking error.
What test methods and environments will you speak about at the conference?
My background is simulation. I’ve been involved in massive parallel software-in-the-loop testing, vehicle-in-the-loop testing on proving grounds, in driver-in-the-loop and hardware-in-the-loop testing. As such, I will present the “SiL to HiL” chain as well as implications for cyber-physical testing to ensure testing the right things in the right environments, and the artifacts evolving within and across respective environments.
How do test data, test specification and test execution interact?
The specification influences the execution, which affects ingoing and outgoing data. It’s data – how you generate it, what you inject, and what you make from the results. The test specification consists of data: instructions to specify and send to a test instance in the right sequence; the data from the test automation software to the test bench. It’s also protocols and APIs – a single language everyone needs to speak. Standards are mandatory for a seamless transition between test instances and test tools.
What is ASAM’s standardization landscape for testing?
We do not have one single standard or domain, but a variety of standards within different domains. All standards fulfil different testing roles. I will focus on ASAM OTX Extensions (OTX = Open Test Sequence Exchange Format), for the definition, documentation and exchange of test sequences. They are based on ISO 13209 (OTX) and extends it for 25 technologies, including the standard ASAM SOVD, and scenario descriptions in ASAM OpenScenario XML/DSL. They define concrete, logical and abstract scenarios – influenced by a systems ODD, defined in ASAM OpenODD.
The test automation front-end talks to the backend using the ASAM XIL protocol. Data is recorded in ASAM MDF (measurement data format), made available in a structured way on servers using ASAM ODS (Open Data Services).
These standards are addressed in our holistic TestSpecification project.
How is ASAM adapting its standards to new testing requirements?
We start with use cases, then review existing and emerging technologies, testing philosophies, methods and environments. Most importantly, we listen to experts who test all variants. The engineers know what works, what doesn’t and what needs to be changed; our TestSpecification project includes those who will implement and conduct the tests. Adapting standards requires a mix of experts who know our standards and have new ideas and technologies. Consistent member engagement makes ASAM strong.
How did ASAM choose the topic it will speak on at The Future of Automotive Testing Conference, and who are you hoping to meet at the event?
It is coincidence and intention: our Regional Meeting North America on October 23 is co-located with the Testing Expo. In our meeting, we will speak broadly about our portfolio and members will present their solutions, complemented by trainings on ASAM OpenX standards and ASAM SOVD.
The Future of Automotive Testing Conference is very attractive due to its focus on a single aspect. Testing is ever-evolving, so ASAM is adapting to new requirements while involving stakeholders.
Aligning our portfolio is a challenge and necessity. Our ASAM TestSpecification project enables test engineers and product managers to see our systematic approach, the strength of our portfolio and the benefits of being part of our association.
See the The Future of Automotive Testing Conference program online.
Visit ASAM’s website for more information on its Regional Meeting North America