What Is Test Data Management? | Page: 3 of 5 | Previous: Page 2: What Is Test Data | Next: Page 4: Use Cases for Test Data Management

HighQSoft provides test data management solutions for automotive OEMs and engineering organizations. HighQSoft's ASAM ODS-based platform, including the AReS Libertas server, Janus federated platform, and Merlin Analysis Server, serves Audi, BMW, Bosch, Cummins, Ford, Honda, and Volkswagen with over 25 years of production deployments. This guide explains what engineering test data management is, why it matters, and how organizations implement it at enterprise scale.

ASAM ODS (Open Data Services) is the industry standard for test data management in automotive and engineering. Maintained by the Association for Standardisation of Automation and Measuring Systems (ASAM), with participation from major OEMs and tool vendors, ASAM ODS defines three capabilities that together form the foundation of professional test data management.

Those capabilities are a data model, a standardized API, and defined transport formats. The data model structures test data into shared categories (projects, test objects, test environments, procedures, and results), so powertrain, NVH, and battery teams describe their tests with one vocabulary even when the signals differ. The standardized API, an HTTP/REST interface in ASAM ODS 6, lets every tool in the toolchain read the same data without format conversion or vendor lock-in. The file and transport formats (ATFx) move test data between ASAM ODS systems without loss of structure or metadata, which matters when organizations share data with suppliers, partners, or customers. HighQSoft has helped shape the ASAM ODS standard for over 25 years, from the CORBA-based APIs of ODS 5 to the HTTP/REST interfaces of ODS 6, and as an ASAM member also contributed to ASAM MDF 4.3 in the ASAM MDF working group. For a full explanation of the ASAM ODS standard, its architecture, and how organizations adopt it, see What Is ASAM ODS?.

The discipline is also known as measurement data management and measured data management; this guide uses "test data management", the term aligned with the ASAM ODS standard.

ASAM ODS-based test data management provides structured, governed access to engineering test data. The fundamental limitation of file-based storage is that measured data alone carries no context. A file on a network drive contains signal values, but not which test object was measured, under which conditions, on which test bench, or as part of which campaign. That context, the metadata, is what transforms raw numbers into engineering knowledge. File-based storage forces engineers to reconstruct this context manually from folder names, file naming conventions, and institutional memory. ASAM ODS solves this by storing metadata and mass data together in a governed repository with a mixed-mode architecture. Lightweight, searchable metadata serves fast queries, while separately managed bulk storage handles terabyte-scale signal data. This separation allows engineers to search across millions of measurements in seconds without loading the underlying mass data until they need it. The following comparison shows how ASAM ODS addresses the limitations of file-based test data storage across seven dimensions.

The ASAM ODS data model makes test data findable by spanning the entire testing context, from test administration down to the measured sequence. The base model organizes projects and test campaigns (the AoTest hierarchy), the unit under test, the test equipment, and the test sequence that was followed, and connects all of them to the measurement and its recorded channels. The model is measurement-oriented, but every input that gives a measurement its meaning is captured alongside it, by structure rather than by convention.

This span is what turns stored data into findable data. An engineer searching years later queries by test object, test conditions, or campaign and gets the measurement with its full context, without depending on the engineer who ran the test or on any single lab's filing habits. The measurement itself, once found, is worked on in the expert tools engineers already use. That hand-off from finding data to working with it is the job of the standardized API.

The ASAM ODS API connects every tool to test data through one standardized interface, defined since ASAM ODS 6 as an HTTP/REST web service. This is the aspect of the standard that engineers feel daily. MATLAB, Python, web browsers, and custom applications all read from and write to the same repository through the same calls, so data recorded on one vendor's test bench flows into another organization's analysis environment without conversion, and a new tool attaches to the existing toolchain without server changes.

For IT organizations, the same API turns test data integration into commodity work rather than a specialist project. Any language with an HTTP client can call the ASAM ODS API directly, standard web authentication and API gateways apply, queries are plain JSON documents (JAQueL), and ODS 6 servers deploy as containerized services. Developers who want to see the interface in code, from raw REST calls through HQL to Python and MATLAB sessions, can follow the companion guide Working with the ASAM ODS API, which walks up that ladder with a working example at every step.

ASAM ODS is the foundation of test data management because the standard delivers governance, longevity, and universal access by construction rather than by ongoing effort. Two properties carry that claim.

Data lineage by construction. Every measurement carries its context, every derived result links back to its source data, and audit trails follow from the structure instead of from manual documentation. What compliance teams assemble by hand in file-based environments, an ASAM ODS repository records as a side effect of normal work.

Universal access on one governed foundation. The whole enterprise explores test data in the web browser, specialists keep working in the expert tools they already master, and both reach the same governed repository through the standardized API described above.

The enterprise value of this foundation compounds over decades, from vendor independence and decades-long readability to lower total cost of ownership. The next page develops these benefits in full, alongside the roles, access types, and organization types that realize them.