What Is ASAM MDF? The Definitive Guide | Page: 2 of 4 | Previous: Page 1: The ASAM MDF Standard: A Definitive Guide for Test Engineers and Data Architects | Next: Page 3: What is new in ASAM MDF 4.3 for ADAS Data (September 2025)
Engineers evaluating measurement data formats apply the same criteria regardless of the testing domain. Can I read files without the original recording tool? Can I store multiple signal rates in one file? Does the format compress data without losing random access to individual channels? Is the format governed by an industry consortium or controlled by a single vendor? Is the tool ecosystem broad enough that I am not locked into one supplier's stack?
These questions separate formats designed for interoperability and longevity from formats optimized for a single vendor's workflow. ASAM MDF was designed to meet all five criteria, and the MDF4 file structure decisions that enable this are what make it suitable as a primary recording and archival format for test data.
ASAM MDF meets the evaluation criteria above through three architectural capabilities: self-describing files, multi-rate recording, and built-in compression. Each capability is a consequence of the MDF4 file structure's binary block architecture, and each directly affects how engineers record, share, and archive measurement data.
are the reason an ASAM MDF file remains interpretable years after it was recorded, even when the original tool is no longer available. Page 1 of this guide introduced self-description as a defining characteristic of the ASAM MDF standard. For format evaluation, the depth of that self-description matters. ASAM MDF stores conversion rules (linear, rational, algebraic, tabular) that transform raw binary values into physical quantities with units. ASAM MDF stores source information identifying which equipment and software produced each signal. ASAM MDF stores event markers that document what happened during the recording.
All of this metadata lives inside the file as linked binary blocks alongside the measurement data, connected by direct byte-position references. Unlike formats that separate data from its description, the MDF4 file structure keeps data and metadata together so the file is always complete. This architecture is what makes ASAM MDF practical both as a data exchange format between organizations, where the receiving engineer may have no context about the recording, and as a long-term archival format that must survive decades of tool evolution.
is a defining capability of the MDF4 file format structure. One ASAM MDF file can hold ECU data sampled at 1 kHz, temperature sensors at 1 Hz, and CAN bus traffic as events, all synchronized through their respective master channels. This eliminates the need to manage separate files for each data stream or worry about timestamp alignment across files.
ASAM MDF achieves multi-rate recording through its three-level data hierarchy. Channels represent individual signals. Channel groups collect channels that were acquired simultaneously, sharing the same master channel and record layout. Data groups contain one or more channel groups along with their recorded data. A single ASAM MDF file can contain multiple data groups, each at a different sample rate or from a different data source.
ASAM MDF goes further than simple time-based recording by supporting four synchronization domains: time (seconds), angle (degrees of crankshaft rotation), distance (meters), and index (sample count). Engine testing often synchronizes to crankshaft angle rather than wall-clock time. Vehicle dynamics testing may synchronize to distance traveled. ASAM MDF also supports non-equidistant sampling, meaning the intervals between samples need not be constant. This flexibility reflects how measurement data is actually acquired in production testing environments.
Accommodating multiple data rates and synchronization domains addresses the recording challenge. The storage challenge is equally important, particularly as ADAS sensors push data volumes into the terabyte range.
The MDF4 file structure applies compression at the block level, allowing tools to compress large data blocks while leaving small metadata blocks uncompressed for fast access. This granularity is a practical advantage over formats that require compressing the entire file (losing random access) or that offer no compression at all (wasting storage). ASAM MDF compression is transparent to reading tools; a compliant reader handles compressed and uncompressed blocks identically.
ASAM MDF has supported data compression since MDF 4.1, which introduced DEFLATE as the first built-in compression option. MDF 4.3 significantly expanded the available algorithms to address the growing data volumes from ADAS sensor recordings and high-channel-count test campaigns.
MDF also supports an optional data transposition step before compression. Transposition rearranges data from record-oriented layout (all signals for one timestamp together) to column-oriented layout (all values of one signal together). Since measurement signals often change slowly between consecutive samples, column-oriented data compresses significantly better because adjacent values are similar. The combination of transposition and compression can reduce file sizes by factors of five to ten or more, depending on the data characteristics.
The addition of ZStandard and LZ4 in ASAM MDF 4.3 addresses a real industry need. ADAS sensor recordings (camera, radar, LiDAR) generate gigabytes of data per minute. Engineers need compression that is fast enough to keep up with recording rates while still providing meaningful size reduction. ZStandard offers an excellent balance between ratio and speed, comparable to DEFLATE in compression ratio but significantly faster in both compression and decompression. LZ4 trades some compression ratio for extreme speed, making it suitable for real-time logging where the bottleneck is disk throughput.
Both ETAS (MDA V8.7.7) and Vector (CANape) have already shipped support for ASAM MDF 4.3 with ZStandard and LZ4, confirming that the industry is adopting these new compression algorithms quickly. Page 3 covers how these new algorithms fit into the broader MDF 4.3 update for ADAS data.
ASAM MDF and NI TDMS (Technical Data Management Streaming) are the two most common binary measurement data formats in test engineering. Both use a hierarchical data model (channels grouped into collections within a file), but they differ significantly in scope and governance.
For organizations choosing between MDF and TDMS, the decision often follows the tool ecosystem. Teams deeply invested in NI hardware and LabVIEW may prefer TDMS for its native integration and proven streaming performance. Teams working across multiple tool vendors, recording bus traffic, or managing ADAS sensor data will find MDF more capable due to its associated standards and broader tool support.
These formats are not mutually exclusive in practice. HighQSoft's Janus Platform can federate data from MDF files imported into ASAM ODS, TDMS sources, and other repositories, providing unified access regardless of the original recording format.
ASAM MDF and NI TDMS are the primary binary formats for measurement data, but engineers encounter other formats at different stages of the data lifecycle. CSV appears when tools need a universal exchange fallback. HDF5 appears when data crosses into scientific computing. Parquet appears when data moves to cloud analytics. Each serves a specific role in the measurement data landscape, and understanding where they fit clarifies what the MDF4 file structure is designed for and what it is not.
(Comma-Separated Values) remains the most common data exchange format in engineering, but CSV is poorly suited as a primary measurement format. CSV files are plain text with no embedded metadata, no compression, no multi-rate support, and no self-description. An engineer receiving a CSV file must know externally which columns represent which signals, what units apply, what conversion rules were used, and at what rate the data was sampled. None of this information travels with the file.
CSV files are also five to ten times larger than equivalent binary formats for the same data. In practice, CSV serves as the universal fallback when proprietary formats conflict; battery cycler vendors, for instance, typically export to CSV because no standard binary format has achieved universal adoption in that niche. For test data that needs to be archived, shared across organizations, or processed at scale, CSV's lack of metadata and compression makes it a poor choice compared to ASAM MDF.
(Hierarchical Data Format version 5) is a flexible scientific data format developed by The HDF Group that supports hierarchical grouping, compression (gzip, szip, custom filters), and chunked storage for large datasets. HDF5 is widely used in scientific computing, including NASA Earthdata, physics simulations, and bioinformatics. It can technically store any data type and provides a self-describing structure with embedded metadata.
However, HDF5 is a general-purpose format with no automotive-specific conventions. HDF5 has no associated standards for bus logging, ADAS sensor data, classification results, or GNSS storage. It has no standardized conversion formulas for transforming raw measurements to physical quantities. HDF5 supports only time-based synchronization, not the angle, distance, or index domains that automotive testing requires. The automotive tool ecosystem for HDF5 is significantly smaller than for ASAM MDF; MATLAB reads HDF5 natively, and the asammdf Python library can export MDF data to HDF5, but automotive recording tools (Vector CANape, ETAS INCA, dSPACE) write ASAM MDF, not HDF5. For organizations in adjacent scientific domains where HDF5 is established, the format remains a strong choice within that context.
is a columnar storage format designed for analytical query performance on large datasets. Parquet is the standard format in cloud data platforms (Databricks, Snowflake, AWS Athena) and is native to Apache Spark, Arrow, and pandas. Engineers increasingly encounter Parquet when measurement data moves from test labs into data lakes or large-scale analytics pipelines.
Parquet and ASAM MDF serve different phases of the data lifecycle. ASAM MDF is optimized for writing during acquisition: sequential block appends, real-time recording, and self-describing signal metadata. Parquet is optimized for reading during analytics: columnar layout for fast aggregation queries, predicate pushdown for filtering, and efficient compression of homogeneous columns. Parquet has no concept of channels, channel groups, conversion formulas, or synchronization domains.
The practical pattern for organizations with both needs is to record in ASAM MDF, import into ASAM ODS for governance and structured access, and export to Parquet when data moves to cloud analytics or machine learning pipelines. HighQSoft's Merlin Analysis Server supports Spark workflows that can read and produce Parquet files alongside ASAM ODS queries. The formats are complementary, not competing.
The MDF4 file structure capabilities and format comparisons on this page apply to ASAM MDF as a mature standard. The next page covers what changed in September 2025 with MDF 4.3, which extends ASAM MDF into autonomous driving, ADAS sensor data, and dynamic recording.
HighQSoft provides test data management solutions for automotive OEMs with over 25 years of production deployments at BMW, Ford, Volkswagen, Bosch, Cummins, and Honda. As a contributor to ASAM MDF 4.3, HighQSoft bridges the gap between measurement data acquisition and enterprise data management.
HighQSoft GmbH
Black-und-Decker-Straße 17b
D-65510 Idstein
