What Is ASAM MDF? The Definitive Guide | Page: 3 of 4 | Previous: Page 2: How ASAM MDF works. | Next: Page 4: Who Uses ASAM MDF in Production Today

ASAM MDF 4.3 is the largest update to the ASAM MDF standard since MDF 4.0 introduced 64-bit addressing. Released on September 23, 2025, ASAM MDF 4.3 extends the format into autonomous driving, service-oriented communication, and dynamic data recording. The update adds eight new block types, three new associated standards (Raw Sensor Logging, SOC Data Logging, and GNSS Data Storage), new compression algorithms (ZStandard and LZ4), and a guard block mechanism for forward compatibility.

ASAM MDF 4.3 is backward compatible with MDF 4.2 at the file level, meaning existing MDF 4.x readers can still open MDF 4.3 files and access pre-4.3 content they understand while safely skipping new constructs via guard blocks. However, reading MDF 4.3 ADAS features (dynamic data, Raw Sensor Logging, new compression) requires updated tool support, which is still rolling out across the ecosystem (see Page 4 for current tool status).

The motivation behind MDF 4.3 ADAS support is the automotive industry's rapid shift toward Advanced Driver Assistance Systems and autonomous driving. Previous MDF versions excelled at recording traditional measurement data: ECU signals, bus traffic, sensor voltages, and calibration parameters. These are fixed-layout recordings where the number and type of signals are known before the test begins.

Autonomous driving data is fundamentally different. Radar returns a variable number of detected objects per scan cycle. LiDAR produces point clouds that change in density with every frame. Camera frames carry raw image data at video rates. Service-oriented communication protocols such as SOME/IP transmit dynamically structured messages over Ethernet. Before MDF 4.3, organizations recording ADAS data had to use proprietary solutions, workarounds within MDF's existing capabilities, or alternative formats such as ros2bag. ASAM MDF 4.3 provides standardized, interoperable solutions for all of these data types.

HighQSoft contributed to ASAM MDF 4.3 as a member of the ASAM MDF working group. This involvement gives HighQSoft direct insight into the standard's design decisions and ensures that HighQSoft's products, particularly ModelMapper (MoMa) for MDF import into ASAM ODS, align with the latest MDF capabilities. As MDF 4.3 tool support rolls out across the industry, the data that reaches ASAM ODS systems will increasingly contain ADAS sensor recordings, dynamic data, and data compressed with ZStandard or LZ4.

ASAM MDF 4.3 stores radar, LiDAR, and camera sensor data through the Raw Sensor Logging associated standard (v1.0.0), which defines tool-interchangeable conventions for ADAS data in MDF files. Before this standard, each tool vendor stored ADAS sensor data using its own conventions. A radar recording from one tool could not be read by another without vendor-specific knowledge. The Raw Sensor Logging standard eliminates this fragmentation by specifying standardized channel names, metadata structures, and data organization for each sensor type.

Sensor events are modeled as compact structure channels. Each sensor event type (camera frame, radar scan, LiDAR sweep) gets its own channel group, allowing different sensors to record at different rates within the same MDF file. The standard defines three source information types that identify the sensor class: VIDEO (type 6) for camera data, RADAR (type 7), and LIDAR (type 8). Writers store raw data as received from the sensor module, without reassembly or reinterpretation. Readers interpret the data using the standardized channel names and metadata, without needing any sensor-specific or vendor-specific knowledge.

Camera data properties include frame height, width, pixel format (using the GenICam PFNC naming convention for uncompressed video), checksum algorithm, and frame identifiers. For compressed video streams, FFmpeg codec naming conventions apply, providing a widely understood vocabulary for video codecs. Radar data supports both angular coordinate representation (range, azimuth, elevation, radial velocity) and point cloud representation (Cartesian coordinates with intensity). LiDAR data similarly supports both angular coordinates and point clouds. The dual representation options accommodate different radar and LiDAR sensor architectures without forcing a single data model.

The practical impact of this standard is significant for ADAS development teams. A data logger in a test vehicle can record camera, radar, and LiDAR data into a single MDF file using standardized conventions. As tools adopt MDF 4.3 support, any compliant reader will be able to interpret that sensor data without a proprietary plugin. This interoperability, once the ecosystem matures, will accelerate development cycles because engineers can choose their preferred analysis tools without worrying about format compatibility. It also simplifies data archival because the same MDF file format used for traditional measurement data now covers ADAS sensor data, keeping the entire data pipeline on a single standard.

The GNSS Data Storage associated standard (v1.0.0) provides standardized channel identification for positional, navigational, and timing data from Global Navigation Satellite Systems including GPS, GLONASS, Galileo, and BeiDou. Before this standard, MDF files could contain GNSS data, but tools had no reliable way to identify which channels represented latitude, longitude, altitude, speed, or heading without vendor-specific knowledge. This made it difficult to plot routes on maps or combine GNSS data with other signals automatically.

The standard defines identifiers for latitude, longitude, altitude, speed, track angle, fix status, dilution of precision values (HDOP, VDOP, PDOP), accuracy metrics, and satellite count. These identifiers are stored as metadata tags in the channel block comment, making the approach fully backward compatible with MDF 4.0 and all later versions. Any existing MDF 4.x reader can open a file with GNSS data; readers that understand the standard can additionally identify and interpret the GNSS channels correctly.

An important practical consideration drove this standard: privacy protection. GNSS data is personal information under regulations such as the EU's General Data Protection Regulation (GDPR). By standardizing how location channels are identified, the GNSS Data Storage standard makes it straightforward for post-processing tools to find and strip location data when required for privacy compliance. The standardized identification also enables GPX (GPS Exchange Format) export interoperability, allowing GNSS tracks from MDF files to be used in mapping and fleet management tools. For fleet testing and validation campaigns where hundreds of drives are recorded daily, automated location stripping based on the standardized GNSS channel identifiers makes privacy compliance scalable rather than manual.

The SOC Data Logging associated standard (v1.0.0) addresses the growing importance of service-oriented communication in modern vehicles. As vehicle architectures transition from traditional CAN buses to Ethernet-based networks, SOME/IP (Scalable service-Oriented MiddlewarE over IP) has become central to AUTOSAR Adaptive platforms. The SOC standard defines how to log SOME/IP communication in MDF files with standardized channel names, tags, and structures.

The standard covers logging of SOME/IP events, method requests, method responses, error responses, and SOME/IP Service Discovery messages (including Find Service, Offer Service, and Subscribe Eventgroup operations). Signal description uses two approaches. The basic approach adds signal channels as members of the protocol structure, suitable for simple SOME/IP services. The data stream approach uses the new DSBLOCK (Data Stream Block) for complex or dynamic structures, supporting AUTOSAR ARXML database references, TLV (Tag-Length-Value) tagged structures, dynamic arrays, and variants.

This standard matters because the vehicle networking landscape is changing. CAN, LIN, and FlexRay dominated vehicle communication for decades, and MDF's existing Bus Logging associated standard handles those protocols well. Ethernet and SOME/IP represent the next generation, carrying larger payloads, supporting service-oriented architectures, and enabling the high-bandwidth data exchange that autonomous driving systems require. MDF 4.3's SOC Data Logging standard ensures that the same MDF file format that records traditional bus traffic can also record Ethernet-based service communication, maintaining a single standard across the transition.

Dynamic data is perhaps the most technically significant addition in MDF 4.3, driven by two real-world problems that previous MDF versions could not solve cleanly. Radar sensors return a variable number of detected objects per scan cycle. LiDAR point clouds change in density with every frame. SOME/IP and protobuf messages carry structures that vary at runtime. Engineers using previous MDF versions had to choose between decomposing these messages into fixed channels (losing the native protocol structure) or storing them as opaque binary blobs (losing interpretability). Variable-length sensor data required similar workarounds, padding fixed-layout records to accommodate changing signal counts, which made files harder to interpret and process.

MDF 4.3 solves this with dynamic data support through two description modes. In attachment description mode, the raw protocol data is stored as-is (for example, a protobuf message), with the format description (the protobuf schema file) attached to the MDF file. MDF channels annotate parts of the data for general readers, but the full interpretation requires understanding the external protocol. In data stream mode, MDF channels faithfully represent all the streamed data. Any MDF reader can interpret the content without understanding the external protocol, because the channel definitions fully describe the data structure.

Five new block types enable dynamic data. DSBLOCK (Data Stream Block) marks a channel group as containing dynamic data. CLBLOCK (Channel List) stores variable-length one-dimensional signal collections, handling cases where the number of signals changes per record. CVBLOCK (Channel Variant) selects among multiple channel descriptions based on a discriminator value, implementing tagged union semantics. CUBLOCK (Channel Union) allows multiple descriptions to be valid simultaneously for the same data region. VDBLOCK (Variable-Length Data Storage) provides efficient storage for variable-length data associated with the new VLSC (Variable Length Signal Data with Size Channel) channel type. Together, these blocks give MDF the flexibility to represent virtually any data structure, from simple variable-length arrays to complex protocol messages with nested variants and unions.

Standardized serialization format identifiers complete the dynamic data picture. The standard defines identifiers for protobuf, JSON, XML, FlatBuffers, SOME/IP, ROS V1, and CDR (DDS/ROS V2). When an MDF file contains serialized data, the format identifier tells readers which deserializer to apply. The inclusion of ROS V1 and CDR (the serialization format used by ROS 2 via DDS) is particularly notable, as it creates a formal bridge between the MDF and ROS ecosystems.

ASAM MDF and ros2bag (the recording format of the ROS 2 robotics framework) are the two primary choices for vehicle data recording in autonomous driving development. Both formats record sensor data, object lists, and vehicle state information. The choice between them reflects different engineering traditions, tool ecosystems, and deployment contexts.

MDF's advantages center on maturity, standardization, and ecosystem breadth. MDF has more than thirty years of development history, formal governance under the ASAM consortium, and support from every major automotive measurement tool vendor including Vector CANape, ETAS INCA, dSPACE, IPETRONIK, Kistler, NI DIAdem, and MathWorks MATLAB. MDF files are self-describing, carrying conversion formulas and signal metadata within the file. Compression is built into the format with multiple algorithm choices. The seven associated standards provide domain-specific conventions for bus logging, sensor data, GNSS, SOME/IP, classification results, measurement environment, and channel naming. MDF is designed for production use at automotive OEMs where data governance, long-term archival, and regulatory compliance are requirements, not optional features.

ros2bag's advantages center on ROS 2 integration, open-source tooling, and a simpler recording model. ros2bag is the native recording format for data exchanged within the ROS 2 framework, which has become a standard platform for robotics and autonomous driving research. The format records ROS 2 topic messages directly, preserving the native message types and communication patterns. An extensive ecosystem of open-source tools on GitHub supports ros2bag conversion, analysis, and replay. For teams whose development stack is built entirely on ROS 2, ros2bag provides the lowest friction path from development to data analysis.

MDF 4.3 narrows the gap between these two worlds significantly. With native ADAS data types (camera, radar, LiDAR via Raw Sensor Logging), dynamic data structures (variable signal counts per record via DSBLOCK), and serialization format identifiers that include ROS V1 and CDR (DDS/ROS V2), MDF 4.3 can represent the same data types that previously drove ros2bag adoption. The key difference that remains is context. ros2bag records messages as they flow through ROS 2 middleware, preserving the ROS topic structure. MDF records signals as they arrive from measurement hardware, preserving the measurement context. For organizations that need to produce data usable by both ROS 2 tools and traditional automotive analysis tools, MDF 4.3's ROS-compatible serialization identifiers provide a bridge.

The practical recommendation depends on the workflow. For research and prototyping within a ROS 2 environment, ros2bag remains the natural choice due to native ROS integration. For production testing, regulatory archival, and cross-tool analysis in automotive organizations, MDF provides the governance, tool support, and long-term stability that production workflows require. For organizations transitioning ADAS projects from research prototyping to production validation, MDF 4.3 makes the migration from ros2bag to MDF feasible because the sensor data types and serialization formats are now natively supported.

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.