What Is Test Data Management? | Page: 2 of 5 | Previous: Page 1: What Is Test Data Management? | Next: Page 3: What Is the ASAM ODS Standard?

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.

Engineering test data consists of physical measurements recorded by instruments during the testing of products and components. Voltage curves from battery cycling, vibration signals from NVH analysis, temperature profiles from engine durability runs, pressure readings from hydraulic testing, and force measurements from crash tests are all examples of engineering test data. Engineering test data is distinct from simulation results or software test outputs because it originates in the physical world. Real sensors on real test objects produce recordings that carry meaning only when accompanied by their context. That context records which test object was measured, on which test bench, under which conditions, with which calibration, and as part of which test campaign.

Metadata transforms raw signals into usable engineering knowledge. A temperature curve without the identity of the test object, the ambient conditions, and the test procedure is a meaningless sequence of numbers. A temperature curve linked to a specific battery cell, tested at a specific state of charge, on a specific cycler, following a specific IEC protocol, becomes a building block for engineering decisions. Test data management exists because this metadata context must be captured, preserved, and made searchable at scale.

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.

Engineering test data falls into four categories, each with distinct storage, access, and management requirements in a test data management system.

Time-series data form the core of most engineering measurements. Continuous sensor recordings captured over time include temperature, pressure, vibration, voltage, current, force, and displacement signals. Time-series data drives the volume challenge in test data management because a single test run can produce gigabytes of signal data across hundreds of channels sampled at rates ranging from one sample per second for battery cycling to millions of samples per second for crash events.

Scalar and summary data capture single-value results and key performance indicators derived from time-series measurements. Pass/fail verdicts, peak force values, mean temperatures, efficiency ratings, and cycle life counts are typical examples. Scalar results must link back to the source measurements from which they were derived, because a KPI without traceability to its source data is unverifiable.

Video and image data from high-speed cameras, thermal imaging, and optical inspection systems add another dimension to engineering test data. Crash testing, for example, produces synchronized video alongside sensor data, and both must be stored and retrieved together to reconstruct the full picture of what happened during the test.

Context and metadata form the most important category in test data management, because without metadata, time-series, scalar, and video data become unfindable. Metadata describes the test object (which component, which prototype revision), the test environment (which bench, which facility, what ambient conditions), the test procedure (which protocol, which parameters), and the organizational context (which project, which engineer, which campaign). Metadata is what makes test data searchable, comparable, and reusable across an organization.

Automotive OEMs, suppliers, test service providers, and equipment vendors all produce engineering test data. The test data management challenge intensifies when measurement data crosses organizational boundaries.

Automotive OEMs with in-house test laboratories operate the largest testing infrastructures. BMW, Ford, Honda, and Volkswagen, among their peers, run hundreds of test facilities across powertrain, NVH, crash, durability, battery, and ADAS domains. Each facility generates terabytes of measurement data per month, and this data is a permanent corporate asset that must remain accessible throughout the 10- to 30-year product lifecycle.

Tier 1 and Tier 2 suppliers like Bosch, Continental, and Cummins operate their own testing programs for components and subsystems. Supplier test data must often be shared with OEM customers as part of delivery, creating data exchange requirements that complicate the test data management challenge.

Test service providers like APL Landau and TÜV SÜD Battery Testing perform testing on behalf of multiple clients. Test service provider test data management is compounded by the need to manage data from multiple clients with varying requirements, retention periods, and access permissions, all on the same infrastructure.

Test equipment vendors like HORIBA, Keysight, and MTS build the instruments that generate engineering test data. Equipment vendor customers need test data produced by these instruments to flow into a managed repository, creating integration requirements between test equipment and test data management systems.

Every automotive and industrial test domain produces engineering test data with distinct characteristics. The following domains represent the breadth of measurement data that a test data management system must handle.

Format diversity is the norm in engineering testing, not the exception. A typical OEM test infrastructure produces data in half a dozen formats, each reflecting the tools and instruments used in a particular test domain.

MDF4 (ASAM Measurement Data Format, current version 4.3) is the dominant standard in automotive testing, supporting time-series signals, ADAS sensor data, bus logging, and embedded metadata. TDMS (Technical Data Measurement Streaming) is prevalent wherever National Instruments hardware is deployed. CSV remains universal as a lowest-common-denominator exchange format, though CSV lacks structure and metadata. ATFx (ASAM Transport Format in XML) serves as the ASAM standard for exchanging ODS data between systems. Parquet is gaining adoption for analytics and cloud-based processing, offering columnar storage optimized for large-scale queries.

The practical consequence for test data management is that any test data management system must handle all these formats, as well as proprietary logger formats, MATLAB MAT files, and domain-specific formats such as WAV for acoustics or HDF5 for scientific computing. A test data management system that requires all data to be converted to a single format before ingestion creates a bottleneck that engineers will route around. A system that accepts data in its native format and normalizes it into a searchable, governed repository removes that friction. HighQSoft's ModelMapper (MoMa) handles this normalization with hundreds of built-in transformation rules, automatically importing data from CSV, MDF4, ATFX, and other formats into the ASAM ODS repository. Format diversity and the central role of metadata both point to the same conclusion. Managing engineering test data at scale requires more than storage. It requires a discipline that unifies data, naming, and analysis across the enterprise.

Test data management unifies the data types, producers, domains, and formats described on this page through three practices that turn scattered measurements into one governed enterprise asset.

Catalog management ensures that signal names, units, and test procedures are consistent across every lab and department. When a powertrain team in Munich and a durability team in Detroit both label engine speed as "n_engine" in RPM, their measurements become directly comparable. HighQSoft's Catalog Editor enforces these naming standards organization-wide.

Data lifecycle governance defines retention periods, access permissions, and archival rules. Battery test data for a vehicle program may require 15 years of retention for regulatory compliance, while prototype screening data can be archived after 3 years. Test data management assigns these policies centrally, at the data model level, not per folder or file share.

Analysis automation transforms raw measurements into engineering insights at scale. Instead of an engineer manually running a MATLAB script on each test run, HighQSoft's Merlin Analysis Server provides production-scale automation, triggered automatically when new data arrives. Every result links back to its source data and analysis parameters, making the entire chain reproducible.

Unification at this scale needs a common foundation that every tool, team, and site can rely on. That foundation is an industry standard, ASAM ODS, introduced on the next page.