Why We Built HQL, the ASAM ODS Query Language | Page: 2 of 4 | Previous: Page 1: How to Query ASAM ODS Data | Next: Page 3: ASAM ODS Access from Python, MATLAB, and REST

HQL, the HighQSoft Query Language, is a SQL-like query language purpose-built for ASAM ODS data, and it is the answer to the development cost described on the previous page. Where raw API code turns every request into a program and a database backdoor bypasses the standard's safeguards, the HQL query language lets an engineer ask a question in one readable line that runs safely against the ODS server. This page defines exactly what HQL is, shows the difference between one line of HQL and a page of API code, walks through the features that make it purpose-built for test data rather than generic tables, and tells the origin story, because HQL was HighQSoft's internal answer to its own daily pain long before it was a product.

HQL is a SQL-like query language designed specifically for ASAM ODS data models, and it runs against the ASAM ODS server rather than the underlying database. That single design choice is what keeps it safe. Because HQL operates through the server, all of the standard's security features, access rights, and data-model constraints stay enforced, unlike a raw SQL connection that steps around them. HQL provides a unified access layer, and the same HQL syntax works across ODS 5, ODS 6, and ATFx files, so one query language covers a mixed server landscape and reads archived measurement files directly. The general form reads much like SQL, selecting columns from an element with optional conditions, joins, ordering, and grouping.

One point of honesty belongs here. HQL is HighQSoft's own language, not an ASAM standard, and it should not be confused with Hibernate Query Language, the well-known Java ORM language that happens to share the acronym. What makes a vendor query language acceptable rather than a lock-in risk is that HQL is readable, inspectable, and translates directly into standard ASAM ODS API operations. The data itself stays in a standard ODS repository, reachable through the standard API at any time, so adopting HQL adds a convenience layer without closing any doors. That combination, a private language over a standard repository, is the balance the rest of this page defends.

The clearest way to understand the value of the HQL query language is to compare one line of it against the API code that returns the same result. Selecting the name of every unit in a repository is a single HQL query.

The equivalent through the raw ASAM ODS API is not one call but a sequence of them. The client first resolves the application element identifier for the base type and then resolves each attribute name against the live model, because none of those names are known at compile time. It builds a query structure as a set of parallel typed arrays, one describing the selected columns, another describing the condition tree, where each condition carries an attribute reference, an operator, and a typed value union, with logical operators interleaved as separate array entries rather than written inline. It executes the query, receives a nested result set, and then decodes it by looping over the returned elements, matching each against the identifiers it resolved earlier, and casting each cell's typed union to the correct accessor based on the attribute's data type. The official ASAM example that performs roughly this query runs to around 150 lines. This is not a caricature of a bad API; it is the honest cost of a generic one, and the worked version is laid out in full in HighQSoft's reference on working with the ASAM ODS API. HQL does all of the same work underneath, against the same server, and hands the engineer the one line instead. This is the section a Lead Test Engineer forwards to a developer, because it makes the time-and-money argument concrete. One short line is faster to write, faster to debug, and cheaper to maintain than a page of construction and decoding code, and that saved developer time is the whole point.

HQL is purpose-built for measurement data, which is what separates it from a generic SQL layer or a REST wrapper that only knows rows and columns. A test data query is rarely just a filtered table. It follows relationships across the ODS model, converts physical units, reasons about time, and reaches into mass data such as time series and waveforms. HQL treats all of these as first-class parts of the query rather than problems the engineer has to solve in surrounding code. The snippets below use ASAM ODS base-model element names, so they imply no particular customer model and read the same on any compliant server. Each one shows a capability that a plain SQL SELECT or a JSON filter cannot express on its own.

HQL follows the ASAM ODS relationship graph, so an engineer names the elements to connect and lets the language resolve the path rather than reconstructing joins by hand. The following query returns the distinct submatrices belonging to a set of measurements by joining the measurement element to the submatrix element along their defined relation.

The value here is not the syntax but what the syntax removes. In raw API code, traversing from a measurement to its submatrices means resolving relation names, building join definitions, and matching returned elements by identifier, all of which HQL resolves from the model. Because the join is expressed against the relationship the model already defines, the query keeps working as the application model grows, instead of breaking the moment a column name changes. Relationship navigation is one half of what "purpose-built" means; units, time, and mass data are the other half.

HQL puts unit conversion, date arithmetic, and mass-data access directly inside the query, so measurement semantics that would otherwise live in downstream code become part of the question itself. Unit conversion is requested by naming the target unit in square brackets after a channel, and HQL performs the conversion as it returns the data.

Here the channel is read from a submatrix and converted to hours on the way out; the channel name is always the organization's own, while the unit conversion is built into the language. Date arithmetic works the same way as an inline capability. HQL provides functions such as now()-days(7) that compute relative times inside a where clause, so a query can ask for everything created in the last seven days without the caller precomputing timestamps. Mass data, the actual channel values behind a measurement, is read with the hqlvm command, which returns the value matrix of a submatrix rather than metadata.

This single line pulls the full channel set of a submatrix, the same bulk measurement data the raw API exposes only through a separate value-matrix call with its own decoding. Unit conversion, relative dates, and mass-data access are exactly the test-data-native features that make "purpose-built" a description rather than a slogan, and they are the same everywhere HQL runs.

HighQSoft built HQL because it hit the API wall first and needed a way through it for its own work. Two decades of building ODS servers, clients, and integrations made the cost of raw API access visible every single day, and HQL was the internal answer long before it became a product. Comfortable custom access was one of the main design targets HQL was built to deliver, not a side effect. The explicit goal was that self-made and custom analysis against ODS data would stop being a development project and become something an engineer could simply do, which is exactly the kind of self-directed use HighQSoft's own product catalog files under Individual Access. That intent is why HQL was designed to load the application model, read like SQL, and run the same way everywhere, rather than to be one more low-level API binding. That origin is also the strongest proof of the argument this series makes, because HighQSoft does not just sell HQL, it runs on it. For instance, the Navigator module of the ASAMCommander Web application builds its navigation and its filter queries on HQL underneath, one illustration among several of HighQSoft's own software consuming the same language it offers customers. A query language a vendor uses to build its own products is held to a higher standard than one it only ships.

The most demanding test of HQL's readability is HighQSoft's MCP Server for ASAM ODS, which lets engineers query test data in plain English. The MCP Server translates a plain-English question into HQL, validates that HQL against the application model, executes it, and returns structured results, and it can translate an HQL query back into natural language to explain what it will do. This works precisely because HQL is readable and inspectable enough to generate, validate, and check, which a tangle of API construction code would not be. The plain-English layer is covered fully in HighQSoft's natural-language ASAM ODS query guide; the point here is only that HQL is the trustworthy substrate underneath it. HQL has been the query layer behind HighQSoft's products for years, used daily inside production ASAM ODS deployments, which is the kind of track record no demo can substitute for. Having established what HQL is and why it can be trusted, the next page shows how the same language reaches every tool a team already uses.

HQL gives engineers one readable query language for ASAM ODS data, safe by design and built for measurement data. See the full capabilities on the HQL query language product page, or continue to HQL from Python, MATLAB, and every other tool.