ASAM ODS and AI | Page: 2 of 5 | Previous: Page 1: What AI Changes About ASAM ODS Test Data Management | Next: Page 3: How AI Assistants Reach ASAM ODS Measurement Data

ASAM ODS data onboarding is two distinct jobs that project plans routinely treat as one. An application model has to exist, and source data has to map onto it. The first job is a modeling decision about what the organization's tests, measurements, units under test, and channels mean and how they relate. The second job is an engineering task that reads a source format, transforms its contents, and writes them into a repository. Conflating them is expensive, because a team budgets for "an importer" and then discovers halfway through that it is also making semantic decisions that will outlive the importer by a decade.

The application model is not invented from nothing. It derives from the ASAM ODS base model, currently base model version 6.2.1, which is formally specified and defines the entity types a measurement domain needs, including tests, subtests, measurements, submatrices, channels, units, quantities, units under test, and test equipment. Derivation passes two things down. It passes properties, meaning the attributes and relations an application element inherits from the base element it derives from. And it passes rules, because the base model states constraints to which the application-specific data must conform. That second inheritance is the one that matters for everything on this page, since it turns "is this model correct" from an opinion into a question a machine can answer.

The mapping job is where the physical work sits. Measurement sources arrive in ATFX, CSV, DIAdem, Excel, ISO-MME, JSON, MDF3 and MDF4, TDM and TDMS, XML, and via JDBC from existing databases, each with its own conventions for how a channel is named, how a unit is expressed, and where the campaign metadata hides. Every one of those has to land in the right application element with the right attribute values, written in an order that respects referential integrity, starting with catalogs and hierarchy before measurements, structure, parameters, and auxiliary data. Getting the order wrong produces integrity errors immediately. Getting the semantics wrong produces something worse, which the last section of this page returns to.

Not every source has to be physically imported. HighQSoft's Janus Platform virtualizes files, servers, and data lakes behind a single ASAM ODS interface, so federation is a legitimate answer when the goal is unified access rather than consolidated storage. That choice changes where the data lives. It does not remove the modeling job, because a federated view still has to declare what its elements and attributes mean. Whichever route an organization takes, an application model and a mapping onto it remain the two things that must exist.

HighQSoft's ModelMapper is the shipping ground this page stands on, a Java transformation engine that has run measurement data into ASAM ODS repositories in production for more than fifteen years. Its core abstraction is the rule, a small component that performs one atomic transform operation, composed with other rules into a job described in configuration rather than code.

ModelMapper ships with hundreds of built-in transformation rules covering format readers, data transformation, measurement processing, ODS write operations, and output generation, which means most of what a new importer needs already exists and the work is composition rather than programming. Rules exchange data as name, value, and unit triplets, so physical units travel with the values through every stage of the transformation instead of being reconstructed at the end. A job runs through a fixed lifecycle of initialization, rule execution, conclusion, teardown, and termination, which makes execution predictable and failures locatable.

Once an importer is configured, the automatic part is genuinely automatic. ModelMapper creates catalog entries idempotently, so rerunning an import does not duplicate reference data. It deduplicates within a run, normalizes units, caches identifier resolution so large imports stay fast, and enforces the entity write order that referential integrity requires. Catalog versioning uses a lock-on-use rule, meaning that once a mapping version has been applied to a measurement it becomes immutable, and the version actually used is recorded against that measurement. The result is that any measurement in the repository can be traced back to the exact mapping that produced it, which is the first appearance in this lifecycle of a property that pages 3 and 4 depend on as well.

What is not automatic is creating the importer in the first place, and this is where an honest account matters more than a comfortable one. Building a new importer for a new source requires one person to hold five things in their head at the same time.

• The source format, including its binary encodings and its undocumented local conventions.
• The customer's specific ASAM ODS application model, meaning its element names, attribute sets, and naming conventions rather than the base model in the abstract.
• The rule library and the composition patterns that experienced developers use to assemble jobs from it.
• The customer's business logic, which decides what counts as a test, a run, or a valid result.
• The write-time constraints of the target repository, including how mass data is encoded and registered.

A developer with that combination typically needs several days to several weeks for a new importer, depending on complexity. The pool of people who can do it independently is small, and at customer sites the split is sharper still, because domain experts understand their measurement data but not ASAM ODS, while IT staff understand systems but not measurement data. This is the real entry barrier to adopting the standard, and it is the bottleneck that any credible AI story in this space has to address rather than decorate.

AI reduces ASAM ODS onboarding effort by drafting the two artifacts that currently require that rare combination of expertise, and this is development direction rather than a shipping capability today. HighQSoft states that plainly because the distinction is the point of this hub. The mechanism has two halves. A model proposes a candidate application model, expressed as elements, attributes, and relations derived from the ODS base model. A model generates the importer configuration that maps a source onto that model. Neither half replaces the transformation engine, and both target the human configuration effort that sits in front of it.

The model-generation half runs on three inputs together, not on a prompt. A weighted guideline states the modeling conventions that apply, covering which base elements to derive from, how naming should work, which attributes this organization treats as mandatory, and which choice is preferred where more than one is legal. A corpus of reference decisions supplies worked precedent, meaning application models that already exist together with the reasoning that produced them, so a new case is resolved the way comparable cases were resolved rather than from first principles. And the deterministic checker results feed back into the loop, so a candidate that fails the model check returns with the failure attached and the next candidate is a correction rather than a fresh guess. Those three inputs together already reach a usable level on real source material, which is the honest state of it. What usable turns into as the guideline sharpens and the corpus grows is not settled, and claiming otherwise would be the same overclaim this hub argues against everywhere else.

The importer-generation half runs on the same three inputs and is less stable. The guideline covers rule selection and composition patterns, the corpus is the body of importer configurations already running in production, and the checker is the transformation engine itself, which fails loudly on a malformed job and validates what it writes on the way into the repository. The difference sits on the input side. An application model is a finite structure in a formally specified space, so a candidate can be judged against a published definition. A source format arrives with undocumented local conventions, and a sample file that looks representative frequently is not, so results here vary more and the review a person has to do is correspondingly heavier.

What generative assistance does not do is make the semantic decisions. Whether a particular sensor reading belongs to the unit under test or to the test equipment, whether two campaigns share a hierarchy, and what an organization means by a valid run all remain judgments a person owns. A guideline can encode a preference and a corpus can show what was decided last time, but neither is an authority on what this organization means. The draft shortens the path to a reviewable proposal. It does not decide what the data means, and the next section explains what does the deciding.

A conformance gate makes a generated application model trustworthy because the ASAM ODS HTTP API defines a model check as a first-class operation, so a candidate model can be validated for consistency without being committed. That single fact changes the character of the whole exercise. A generated application model is not something an organization has to accept on faith or review line by line before finding out whether it works. It is a proposal submitted to a deterministic check that either passes it or does not, against the same base model version every other conformant implementation is checked against. The model that survives the gate is the model that ships.

The model that fails comes back with a reason, before anything is written and before a single measurement has been imported against it.

This is the difference between generating against a standard and generating against a bespoke schema, and it is the strongest argument on this page. When an organization designs its own internal measurement schema, correctness is defined by the team that designed it and by nothing else. There is no published base model to derive from, no shared notion of what a valid derivation looks like, and therefore no check that a generated artifact can be submitted to. Every validation has to be built in-house, maintained in-house, and rewritten whenever the schema evolves. The AI proposal is just as easy to produce. What is missing is anything to hold it to.

The clearest evidence for that argument comes from a platform vendor's own flagship reference. Databricks publishes a Mercedes-Benz customer story as proof that its platform handles car measurement data at scale. Read for what the account documents rather than for what it markets, the same story records a top-tier OEM, with a large in-house engineering team, building a custom hierarchical data model and then engineering a discovery layer above it by hand, with multi-level filtering and signal-level metadata so that a given measurement could be found again later. They used ASAM MDF, the file-format standard, to represent the raw measurement. What they built on top of it does the job that an ASAM ODS application model does out of the box.

Volume was never the gap. A lake stores and serves measurement data at scale perfectly well, and how much data an organization holds says nothing about whether anyone can find the right measurement inside it. Storing a signal does not record what that signal means, which unit it is expressed in, which calibration produced it, or which run it belongs to. That meaning has to come from somewhere. In this case it came from an engineering team constructing it by hand, on a platform that supplied the storage and the generic governance but not the test-domain model.

The lesson is not that the platform failed at anything. It is that nobody gets to skip the step. A new technology changes what the intake and modeling work costs, and it does not remove the work, because somebody still has to decide what a signal means before anything can reliably find it again. An organization with that engineering budget can absorb the rebuild and ends up with a private model that only its own stack can read. Most OEMs, and essentially every test service provider and equipment vendor, cannot absorb it at all. Since the modeling has to happen either way, the useful question is not whether to do it but whether to do it against something that already exists, is maintained by a consortium rather than by one team, and comes with a check on the result.

The stakes behind that table are concrete rather than architectural. Attributes such as sequence representation, generation parameters, and value type govern how mass data is physically encoded, and getting one of them wrong can produce binary data that is silently unreadable. Silently is the operative word. The import succeeds, the measurement appears in the repository, and the problem surfaces years later when somebody tries to plot a channel from an archived campaign. A conformance gate does not eliminate that class of error, but a standardized target makes the failure mode detectable in a way a private schema does not, because the check knows what a valid encoding declaration looks like.

That is the first instance of this hub's pattern, and it sets the shape of the other two. A model proposes an artifact, a deterministic mechanism defined by the standard decides whether the artifact is acceptable, and only the accepted version reaches production. Page 3 shows the same pattern on the read path, where the artifact is a query rather than a model and the check runs against the application model this page just described.