Why We Built HQL, the ASAM ODS Query Language | Page: 1 of 4 | Next: Page 2: HQL, the Query Language for ASAM ODS

Every organization running an ASAM ODS test data management system eventually confronts the same practical question. How will the team actually query ASAM ODS data day to day, and who has to write the code to make it happen? Querying ASAM ODS data starts, legitimately, with the ASAM ODS API. The standard defines a complete, well-governed interface for reading and writing measurement data, and scripts, applications, and integrations all reach the data through it. What the standard deliberately does not hand you is an ergonomic way to ask a question. It defines the interfaces and the data structures, then leaves the composing of a query to tooling built on top. This page follows that reality outward from the API. It explains why API access is the right foundation, why the standard's generality makes raw access demanding to develop, why the two common escapes make matters worse rather than better, and why HighQSoft built its own query language, HQL, to collapse the cost.

The ASAM ODS API is verbose not because it is badly designed but because it is generic by design, and that generality is the standard's greatest strength. One API has to serve every organization's application model, and no two organizations model their tests, measurements, channels, and units the same way. A carmaker, a battery lab, and a test service provider each name and structure their data differently, so the standard cannot bake any of those names into the interface. Instead it exposes a base model of generic types, and each deployment derives its own application model from that base. The price of that flexibility is that the API cannot know what your elements are called, so your code has to tell it, every time, by resolving names against the live model before it can ask a single question. This reframes the difficulty accurately. Raw ODS access is not hard because of a flaw in the standard to be fixed, but because of a structural property to be managed, and the way to manage it is a layer on top that loads the application model once and lets people query in their own vocabulary. The same reasoning is why multiple vendors, HighQSoft included, have independently built abstraction tooling over the identical generic API. The standard did its job; the ergonomics were always going to live one level up. For a fuller account of the base model, the application model, and how ODS separates metadata from mass data, see HighQSoft's What Is ASAM ODS? guide.

Because the ASAM ODS API is generic, developing against it is demanding in ways that compound over a project's life, not just at the first query. The abstraction distance is the first cost. The API speaks in base-model types and numeric identifiers, while engineers think in the domain vocabulary of their application model, so every piece of code has to bridge that gap by hand, translating between what the data means and how the API refers to it.

The second cost is expertise placement. Whoever writes and maintains this code has to understand both the ODS API and the specific deployment's application model at the same time, and that combined fluency is scarce, which is why it tends to live with one or two developers rather than with the engineers who actually need the data.

The third cost is training. Bringing a new developer up to productive speed against the generic API and a particular model takes real time, and that onboarding repeats with every hire and every model change.

Transaction handling makes the burden concrete. Writing to an ASAM ODS server means managing a transaction by hand. The HTTP API exposes it as three separate calls a developer has to sequence correctly around every mutation, an explicit start before any change, an explicit commit to persist it, and an explicit abort path if anything goes wrong, each with its own error handling. Every insert, update, or delete carries that lifecycle. None of these costs is a defect in the standard; they are the natural consequence of a generic interface that has to serve everyone. They are also exactly the costs that tempt teams onto two shortcuts that look easier and are not.

Running SQL directly against the database behind an ASAM ODS server looks like an escape from the API's development cost, but it bypasses ODS security and semantics and couples your queries to a private schema that was never meant to be an interface. The physical storage layer is a generated, customer-specific mapping. ASAM ODS defines a generic pattern for mapping application elements, attributes, and relations onto database tables, yet the actual table and column names in a live deployment are derived from each organization's own application model, so there is no guarantee they look the same across two customers or stay stable when a model changes. Worse, much of the interesting data is often not in the relational tables at all. In the mixed-mode architecture that dominates production, mass data such as time series and waveforms lives in a separate optimized repository, on a filesystem, network storage, or a cloud object store, connected to the metadata only through pointer elements, so a SQL query against the database simply never sees it. Security compounds the problem, because ODS enforces element, instance, and attribute level access rights in the server layer, and a raw database connection with table-wide grants steps around all of it. This is not a hypothetical concern. In a public support forum, an engineer asking how to run raw SQL against an ODS-backed database was told plainly by a vendor support engineer not to do it, on the structural grounds that ODS data is a linked graph inside the database rather than plain relational tables, so raw SQL forces you to rebuild by hand the relationships the ODS layer resolves automatically. The shortcut feels familiar precisely because SQL is familiar, and that familiarity is exactly what makes it a trap.

Exporting files instead of querying the live system is the quieter escape, and it is exactly the outcome a well-integrated ASAM ODS workflow is meant to prevent. An engineer pulls the data they need into a local file, copies it into their analysis tool, and works offline, which feels productive until the copies multiply and no one can say which extract produced which result. The link back to the governed repository, the metadata, the access rights, and the lineage is severed the moment the file leaves the system, and every export is another replica to track, reconcile, and eventually mistrust. Export has a legitimate place in an analysis workflow, and the trade-offs of file-based versus governed access are covered fully in HighQSoft's MATLAB and ASAM ODS integration guide. As a default query strategy, though, it means the organization stops treating its test data as a queryable asset and starts treating it as a pile of files, which is the outcome a test data management system was bought to prevent. The better answer is not to copy the data out but to integrate the analysis tools directly against the governed system, which is what a query language built for ODS makes possible.

A query language that speaks the ASAM ODS model natively collapses the cost of writing code to query ASAM ODS data and closes off the need for either shortcut, and that is exactly why HighQSoft built HQL. Instead of a page of API code, a single readable line asks the question. Instead of a database backdoor that bypasses security, the query runs against the ODS server, so access rights and model constraints stay enforced. Instead of an export that severs lineage, the query hits the live, governed repository and returns current data. HQL loads the application model, so engineers query using their own organization's element names rather than generic API terms, and because it reads like SQL, anyone who can write a SELECT statement is productive quickly. Even the transaction burden falls away, because HQL manages transactions automatically for ordinary writes and only asks for an explicit transaction when several statements must succeed or fail together. HighQSoft did not set out to build a product here. After two decades of building ODS servers, clients, and integrations, it needed a faster way to work with ODS data in its own software, and no such language existed, so it built one. That origin, what HQL is exactly, and the before-and-after against API code are the subject of the next page. This is the Accessible principle in practice, a standards-based query layer that lets any tool reach the data without vendor lock-in, and it is where the story turns from the problem to the answer.

HighQSoft's HQL turns the demanding ASAM ODS API described here into one readable query language for ASAM ODS. Continue to what HQL is and why it exists, or explore the HQL query language product page to see the capabilities in detail.