What is Test Data Management? | Page: 2 of 5 | What is Test Data?
Previous: Page 1: What Is Test Data Management? | Next: Page 3: 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 are the most important categories 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, Volkswagen, and 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 TUV SUD Battery Testing and APL Landau 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, MTS, and Keysight 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 using approximately 455 built-in transformation rules and automatically imports data from CSV, MDF4, ATFX, and other formats into the ASAM ODS repository.

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 BMW, Ford, Volkswagen, Bosch, Cummins, and Honda 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.