ASAM ODS and AI | Page: 1 of 5 | Next: Page 2: How Measurement Data Sources Reach an ASAM ODS Application Model

AI changes how engineers interact with ASAM ODS test data, and it changes almost nothing about why that data has to be structured in the first place. This hub is about engineering measurement data, the signals and metadata that test benches, vehicles, battery cells, and laboratory rigs produce, managed in repositories that implement the ASAM ODS standard. It is not about synthetic test data generation, the separate software quality assurance discipline in which teams fabricate records to exercise an application under test. Both fields collide under the phrase "AI test data", and most of what search returns there belongs to the QA world. If the question in front of you is what artificial intelligence does to a governed measurement data landscape, this hub answers it from the standardization side rather than the tooling side.

The misconception worth correcting first is that a sufficiently capable language model makes the structured layer redundant. That argument surfaces in customer conversations and on industry panels in roughly this form, that a model good enough to read raw files removes the need to model the data at all. It does not survive contact with a test department. A model can read an MDF4 file and describe its channels, but it cannot tell you which unit under test produced them, which calibration was active, which campaign the run belonged to, or whether the run you are looking at is the one your colleague already signed off. That information is not in the bytes. It is in the descriptive layer that ASAM ODS exists to define, and a model that guesses at it produces confident answers that nobody can check.

Three things are genuinely new. Engineers can now ask questions of measurement data in ordinary language instead of composing a query, which changes who in a test organization can get an answer without help. Generative models can now draft configuration artifacts, mappings, and analysis code that previously required a specialist, which changes how quickly new data sources and new evaluations reach production. And agents can now run unattended, issuing requests against systems overnight without anyone reading each response, which changes the volume of machine-initiated traffic a data platform has to survive. Each of these is a real shift, and each of them raises rather than lowers the value of a data layer whose contents mean something specific.

What has not changed is the contract. A data standard is an agreement about what data means, and it usually spans more than one party, a supplier producing artifacts, an OEM operating a programme, a service provider delivering results. Test data outlives the tools that produced it by decades, and the organizations reading it in fifteen years will not be running today's models. The rest of this hub follows one architectural pattern through three points in the ASAM ODS test data lifecycle, and shows what the standard does for AI rather than what AI does for the data.

The pattern that makes AI usable on ASAM ODS test data is straightforward. AI proposes at the edges, and deterministic, validated machinery decides and executes at the core. A model drafts a candidate, a mapping, a query, a pipeline, and something formal and checkable then either accepts that candidate, corrects it, or rejects it before anything is written, executed, or believed. The model contributes language, pattern recognition, and speed. The core contributes the properties that engineering work requires, which are determinism, reproducibility, and a record of what actually happened.

The load-bearing element is not the model and not the interface. It is the existence of something to check against. A candidate application model can be conformance-checked only if there is a published base model it must derive from. A generated query can be resolved against real element and attribute names only if a machine-readable application model declares them. A composed analysis run can be trusted only if its parts already passed review and the orchestrator records what it executed. Remove the standard from underneath and every one of those checks becomes a bespoke engineering project that each organization has to build, own, and maintain alone.

This is why the architecture divides cleanly into three layers, and why the middle one matters most right now. The consumption layer, where questions get asked and results get read, is the layer AI most plausibly takes over, through agents, chat interfaces, and generated dashboards replacing the classic rich client. The data layer, where the bytes physically live, is becoming a commodity, whether that is a database, an object store, or a data lake.

The interface layer between them, the contract that defines what may be asked and what the answer means, is where a standard grows more valuable rather than less, because whatever the AI talks to still has to honor that contract. ASAM ODS is that contract for measurement data, and its role shifts from the thing engineers query directly to the thing that guarantees the answer is consistent regardless of whether a human or an agent is asking.

AI meets the ASAM ODS test data lifecycle at three points, and the same proposes-and-decides pattern appears at each of them. The three points are onboarding a new measurement source, answering an engineer's question, and running analysis unattended. They differ in who initiates the work and in what gets written, but they share the property that a model's output only becomes trustworthy once a deterministic mechanism has checked it against the standard.

Onboarding is where AI writes the most and where the stakes are highest. Getting a new source into an ASAM ODS repository means two distinct jobs, creating or extending an application model and mapping source data onto it, and both currently depend on people who understand the source format, the standard, and the customer's own conventions at the same time. Generative assistance can draft both artifacts. What makes the drafts safe to use is a conformance check against the current ODS base version, which decides what ships.

Import and validation is the highest-risk step in the whole lifecycle. Everything downstream inherits whatever happens here, so an error introduced at onboarding is never a local error. It propagates into every query, every evaluation, and every report drawn from that data, and it usually surfaces long after the person who caused it has moved on. That risk does not shrink as volume grows, it compounds, which is why deterministic automation at this step is not a convenience but the thing that makes the step survivable at all. The consequence is that AI assistance and deterministic automation have to co-exist here rather than compete for the same job. Generative drafting on its own produces artifacts nobody can vouch for once the volume is real, and automation on its own leaves the configuration bottleneck exactly where it has always been. Page 2 covers what standardized mapping delivers today with ModelMapper, where expert judgment is still genuinely required, and why a conformance gate is what makes a generated model trustworthy.

Access is where AI reads, and it runs in two modes rather than one. The first mode retrieves typed artifacts with stable contracts. A test programme does not only produce measurements, it produces the analysis jobs that evaluate them, the results those jobs write, and the lineage records that say what produced what, and HighQSoft is extending the typed-result mechanism its analysis server already uses into MIME types of its own across all three of those classes. An artifact with a declared type and a stable contract can be requested by type, so a client receives it without composing a query and without inferring anything. The second mode is HQL, HighQSoft's SQL-like query language for ASAM ODS, the versatile language for everything not yet typed, meaning arbitrary filtering, joins across entities, and the questions nobody anticipated when the repository was designed. Both modes are automatable, and that is the point of splitting them. An AI can adapt and update the pipeline that uses them when the question changes, while the catalogs and the lineage records keep the whole arrangement organised and reconstructible afterwards. Page 4 defines the three entity classes in the place where they are produced, and separates what runs today from what is direction.

Automation is where AI writes again, this time into production. HighQSoft's Merlin Analysis Server already runs thousands of analysis jobs daily at major OEMs, recording inputs, script version, and parameters on every run. Page 3 covers the access mechanism and hands off to the companion series on querying test data in plain English, and page 4 shows what an analysis run actually contains and why composing one from stages that already passed review is a fundamentally different proposition from letting a model generate and execute code.

None of this is automotive-only. The same lifecycle runs in battery testing organizations, in maritime and marine engineering test programmes, and at independent test service providers, wherever measurement data has to outlive the campaign that produced it. HighQSoft is an active member of ASAM e.V. and has implemented the ODS standard through every platform shift the industry has thrown at it, from object-oriented APIs to HTTP and containers. The standard survived those. It will survive this one, and page 2 starts where every deployment starts, with getting data into it.