ASAM ODS and AI | Page: 3 of 5 | Previous: Page 2: How Measurement Data Sources Reach an ASAM ODS Application Model | Next: Page 4: What Automated ASAM ODS Analysis Looks Like Without a Human Prompt

AI access to ASAM ODS data works by turning a question into a structured request against a declared application model, executing it inside the repository, and returning a typed result the assistant then renders in conversation. HighQSoft's MCP Server for ASAM ODS implements that path, connecting assistants such as Claude or ChatGPT to a governed ODS repository through the Model Context Protocol. The assistant never browses storage and never holds a database connection. It calls tools, and the server does the work.

The mechanism is worth stating precisely, because the precision is the differentiator and an overstatement here would undo the argument the rest of this hub makes. The server exposes structured tools for the operations engineers actually perform, listing servers, connecting, discovering the model, filtering measurements, retrieving instance detail, and comparing channel values. On that structured path, the server resolves element names, attribute names, and value datatypes against the loaded application model before it composes or executes anything at all. A name that does not exist in the model, or a value that does not fit the declared datatype, comes back as a correction suggestion rather than as a cryptic server error, which means the assistant can retry with the right name instead of confidently reporting an empty result. A raw HQL path also exists, for engineers who want to send a query directly. That path is checked by the HQL parser and by the ODS server itself rather than being pre-checked against the application model, and the server says so in its error text rather than pretending otherwise.

The reason the structured path can resolve anything at all is that the application model declares element names, attribute names, and datatypes in machine-readable form, which is exactly the artifact page 2 was about. Element and attribute names are customer-defined and vary between deployments, so the server discovers them rather than assuming them. A folder of raw measurement files offers nothing equivalent to resolve against, which is why the same assistant pointed at a file share can only guess.

The generated HQL query is the audit artifact because it is a durable, human-readable object that outlives the conversation that produced it. HQL is HighQSoft's SQL-like query language for ASAM ODS, and a query written in it can be read by an engineer, pasted into a review, rerun unchanged next quarter, and compared against the query somebody else used to reach a different conclusion. That is a different kind of object from a chat transcript. A conversation records what was said. A query records what was asked of the data.

Its portability is what makes it useful beyond the conversation. The same HQL runs from the command line, from Java, over the REST web service, from Python through pyHQL, and from MATLAB through the ASAM ODS Toolbox, so a query that started as a plain-English question can move straight into an engineer's existing analysis environment without translation. Nothing about the assistant's involvement is baked into the artifact. The query is just a query, and the fact that a model drafted it changes nothing about how it executes or who is allowed to run it, because access control applies inside the repository exactly as it does for any other client.

This is also the boundary of what AI access means on this page. Here, AI reads. The pattern from page 1 holds in its lightest form, with a model proposing a request, the server resolving that request against the application model on the structured tool path and executing it deterministically, and a legible artifact left behind. Pages 2 and 4 are the cases where AI writes, into an application model and into a production analysis run, and those are the cases where the deterministic core has to do considerably more work than resolving a name.

The larger change is not the syntax, it is who can reach the data at all. Retrieval from an ASAM ODS repository runs in two modes, and both of them are automatable. The first mode reaches typed artifacts with stable contracts, meaning the analysis jobs a test programme runs, the results those jobs write, and the lineage records that say what produced what. HighQSoft is widening the typed-result classification its analysis server already applies today into MIME types of its own across all three of those classes, so that each becomes an addressable entity a client can request by type instead of a payload somebody has to parse. Page 4 sets out which part of that runs in production now and which part is direction. The second mode is HQL, the versatile language for everything not yet typed, covering arbitrary filtering, joins across entities, and the questions nobody anticipated when the model was designed. Splitting the two matters because it lets an AI adapt and update the pipeline that uses them when a question changes, while the catalogs and the lineage records keep the arrangement organised and reconstructible afterwards.

pyHQL puts ASAM ODS data where data scientists already work. It is a Python library over the HQL web service, which means an ODS repository becomes reachable from a Jupyter notebook, a dashboard, or a scheduled pipeline without anyone installing an ODS client or learning the ODS API. That is an audience change rather than a convenience. The people who build models, run statistics, and produce the charts a programme actually decides on live in notebooks and Python pipelines, and historically they either received measurement data as exported files from somebody else or did not use it. Reaching the governed repository directly, with the units, the calibration context, and the test hierarchy still attached, is a different working position from receiving a CSV that has lost all of it.

The MCP Server for ASAM ODS widens the audience again, in the other direction. It puts the same repository behind any client that speaks the protocol, which means the person reaching the data does not have to write code at all. A test manager asking which campaigns are still missing results, a quality engineer checking what changed between two runs, and a new team member who does not yet know the application model can all reach the same governed data through the assistant they already use. The protocol is also the natural surface for the typed artifacts described above, because a protocol client asks what is available before it asks for anything specific, which is precisely what an entity with a declared type and a stable contract can answer. Neither route changes what the data means or who is permitted to see it, because access control stays in the repository and the application model stays the definition of what is there. What changes is that the number of people who can ask a question of the measurement archive stops being limited to the number of people who know how to query it.

The companion series "Query Test Data in Plain English" covers the read path in the detail this page deliberately skips. It carries worked examples of what an engineer can actually ask, the setup path for connecting an assistant to a repository, the enterprise controls that govern who may query what, and the disambiguation between engineering measurement query and the synthetic test data generation that dominates search results for similar phrases. If the reader in front of this page is a test engineer wanting to try it rather than an architect wanting to evaluate it, that series is the better starting point.

Two published guides support it. Working with the ASAM ODS API is the code-level reference for queries, Python, MATLAB, and REST. HQL, the Query Language for ASAM ODS explains why a dedicated query language exists for measurement data and what it does that generic SQL over an ODS schema does not. Both are worth reading before evaluating any natural-language layer, from any vendor, because they describe the thing the natural language has to resolve into.

Page 4 takes the pattern to the point where it matters most, which is analysis that runs without anyone present to sanity-check the output.