Accurate Technologies - Blog #ASAM

Inside an MDF4 File: Understanding the MDF4 Data Structure

Fri, 18 Sep 2026 09:34:37 -0400

Part 2 - ASAM MDF4 Explained

In the first part of our ASAM MDF4 Explained series, we looked at what MDF4 is, why the format exists, and how it helps engineers manage increasingly large and complex measurement datasets.

Now it’s time to look inside the file.

An MDF4 file may appear to be a single .mf4 file on your computer, but internally, the information is organized into a network of interconnected blocks. These blocks separate different types of information, such as file metadata, measurement channels, timing, conversions, and the recorded data itself.

Understanding this structure helps explain how MDF4 can efficiently organize everything from a handful of measurements to extremely large vehicle test recordings containing thousands of channels.

MDF4 Uses a Block-Based Structure

Unlike a simple format such as CSV, MDF4 does not organize an entire recording as one large table of rows and columns.

Instead, MDF4 uses specialized blocks. Each block has a particular purpose, and links between the blocks describe how the different pieces of the measurement relate to one another.

At a simplified level, an MDF4 file can be thought of as:

File → Data Groups → Channel Groups → Channels → Measurement Data

Additional blocks provide information such as conversions, units, source information, events, attachments, and metadata.

This structure is one of the reasons MDF4 can accommodate complex measurements with different sampling rates and data sources without forcing everything into a single uniform dataset.

The Identification and Header Blocks

Every MDF4 file needs a starting point.

The Identification Block (ID) identifies the file as an MDF file and provides basic information about the MDF version.[JK1.1]

From there, the Header Block (HD) acts as the primary entry point into the MDF4 structure.

The header can provide general information about the measurement and links to other important structures within the file. Think of it as the top level of the recording rather than the place where the measurement samples themselves are stored.

From the header, software reading the file can begin navigating through the blocks that describe the measurement.

Data Groups: Organizing Recorded Data

Below the header are Data Groups (DG).

A data group represents a collection of recorded data and provides links between the description of that data and the blocks containing the actual records.

An MDF4 file can contain multiple data groups.

This is important because a measurement session may contain information originating from different sources or organized in different ways. MDF4 does not require every piece of recorded information to fit into one universal structure.

Within each data group, the information is organized further using channel groups.

Channel Groups: Measurements That Belong Together

A Channel Group (CG) describes a group of channels whose values are stored together in records.

For example, imagine a test recording containing:

• Engine speed

• Throttle position

• Coolant temperature

If these signals are acquired together, they may belong to the same channel group.

Another set of measurements recorded differently could belong to another channel group.

This organization becomes particularly useful when measurements have different timing or acquisition characteristics.

Rather than forcing every signal in the file into the same sampling structure, MDF4 can preserve how the data was actually recorded.

Channels: Describing Individual Measurements

Within a channel group are Channel Blocks (CN).

Channels represent the individual pieces of information engineers ultimately want to work with.

Depending on the measurement, a channel might represent something such as:

EngineSpeed

CoolantTemperature

BatteryVoltage

VehicleSpeed

The channel definition provides the information necessary to locate and interpret that measurement within the recorded data.

However, a channel name alone is not enough.

To turn recorded bits and bytes into useful engineering information, MDF4 may need to describe the channel's data type, location within a record, timing relationship, conversion, unit, and other characteristics.

That information is connected through the MDF4 block structure.

Master Channels and Time

Measurement data becomes much more useful when you know when each value occurred.

MDF4 uses the concept of master channels to establish the relationship between recorded samples and an independent variable, most commonly time.

Consider two groups of measurements:

Group A: sampled every 1 ms

Group B: sampled every 100 ms

The two groups do not need identical timestamps or the same number of samples.

Each can maintain its appropriate relationship to time.

This is an important distinction from a simple spreadsheet-style representation, where it can be tempting to place every signal against one universal time column.

MDF4 can preserve the original timing characteristics of different measurements.

Channel Conversions: From Raw Values to Engineering Values

The number stored by a measurement system is not always the number an engineer wants to see.

Suppose a channel contains a raw value of:

2150

That value might need a conversion before it represents a meaningful engineering quantity.

After applying the appropriate conversion, the result could become:

21.5 °C

MDF4 can describe this relationship using Channel Conversion Blocks (CC).

Conversions can range from relatively simple mathematical relationships to more complex conversion methods.

Separating the recorded value from its physical interpretation allows MDF4 to preserve both the original measurement and the information required to understand it.

Where Is the Actual Measurement Data?

So far, most of the blocks we've discussed describe the measurement.

Eventually, we need the actual samples.

MDF4 uses data-related blocks to store the measurement records themselves. Depending on how the file was created, these records may be stored directly or through additional structures designed to organize or compress the data.

This separation is important.

A channel block might tell an application:

This channel represents engine speed, uses this conversion, and occupies this location in each record.

The associated data blocks contain the actual recorded values.

Software reading an MDF4 file uses the information from these interconnected blocks to locate the appropriate samples and interpret them correctly.

More Than Channels and Samples

MDF4's block architecture also allows a file to contain much more than conventional signal data.

Depending on the recording, an MDF4 file can include information associated with:

• Events

• Attachments

• Source information

• Comments and descriptions

• Conversion information

• Bus and network data

• File and measurement metadata

This allows an MDF4 recording to preserve context that might otherwise need to be stored separately.

For example, an engineer reviewing a measurement weeks or months later may need more than a graph of values. Information about the measurement source, events during the test, units, or channel definitions can be essential to understanding what happened.

How the Pieces Fit Together

A simplified MDF4 structure might look like this:

Identification Block (ID)

↓

Header Block (HD)

↓

Data Group (DG)

↓

Channel Group (CG)

↓

Channel (CN)

↓

Measurement Data

Other blocks branch from this basic structure to provide conversions, metadata, source information, events, attachments, and other details.

The real structure can be considerably more complex, particularly in large measurement files, but this simplified hierarchy provides a useful mental model.

Instead of thinking of an MDF4 file as a giant table, think of it as a structured map of the measurement.

Some blocks tell you what was measured. Others tell you how it was measured, how to interpret it, and where to find the recorded values.

Why Does This Structure Matter to Engineers?

Most engineers will never need to manually navigate from one MDF4 block to another. MDF4-compatible software handles that work behind the scenes.

Understanding the basic structure is still useful.

It explains why MDF4 can handle signals with different sampling rates, why measurement values can have conversions associated with them, why a single file can contain multiple types of measurement information, and why MDF4 files can preserve significantly more context than a simple exported table.

When an MDF4 analysis tool opens a recording, it is effectively following this map, identifying the available measurements and turning the underlying data structures into signals, timestamps, units, events, and other information that engineers can work with.

Tools such as ATI VISION Data Analyzer (VDA) handle this interpretation automatically, allowing engineers to open and analyze MDF4 data without needing to work directly with the underlying block structure.

The structure may be largely invisible to the end user, but it is what makes that workflow possible.

What's Next: From Raw Measurement to Engineering Signal

We've now looked at the major building blocks that give an MDF4 file its structure.

But how does a value actually travel from the measurement system to the signal an engineer sees on screen?

In the next article in our ASAM MDF4 Explained series, we'll follow that process more closely, exploring raw measurement values, physical values, conversions, timestamps, master channels, and different sampling rates.

Understanding that journey helps connect MDF4's underlying file structure to the measurement data engineers use every day.

What Is ASAM MDF4 and Why Is It Used?

Fri, 14 Aug 2026 13:07:33 -0400

Part 1 - ASAM MDF4 Explained

Modern vehicle development generates enormous amounts of measurement data. Whether engineers are calibrating an ECU, validating a control strategy, testing a powertrain, or recording data from a vehicle network, hundreds or even thousands of signals may need to be captured simultaneously.

Storing those measurements is only part of the challenge. The data also needs context: What does each signal represent? What are its units? How should a raw value be converted into a physical value? When was each sample recorded? How are signals with different sampling rates synchronized?

This is where ASAM MDF (Measurement Data Format) comes in.

MDF is a standardized binary file format designed for storing measurement data together with the information required to interpret it. MDF4, the fourth major generation of the standard, was designed to support the increasingly large and complex datasets produced by modern automotive development and testing.

What Is ASAM MDF?

MDF stands for Measurement Data Format. The standard is maintained by ASAM (Association for Standardization of Automation and Measuring Systems) and is widely used for measurement and test data, particularly in automotive development.

An MDF file is more than a collection of recorded values. It can contain both the measurement samples and metadata describing those measurements.

Depending on the recording, this can include information such as:

Signal and channel names
Raw measurement values
Physical units
Conversion information
Time information
Sampling information
Descriptions and other channel metadata
Events and attachments
Vehicle network data

Keeping this information together makes MDF useful for exchanging measurement data between acquisition, calibration, validation, and analysis tools.

Files based on MDF 4.x commonly use the .mf4 file extension.

Why Does a Standard Measurement Format Matter?

Consider a relatively simple test.

An engineer records engine speed, temperatures, pressures, pedal position, ECU parameters, and CAN traffic during a vehicle test. Some measurements may be sampled every millisecond, while others are recorded much less frequently.

A simple tabular format can represent some of this information, but it quickly becomes inefficient as recordings become larger and more complex.

There are several questions the file format needs to answer.

How do signals with different sampling rates coexist? How are timestamps represented? How is a raw ECU value converted into an engineering unit? How can very large recordings be stored efficiently? How can another application interpret the recording without knowing the details of the original acquisition system?

MDF was created to provide a standardized way of representing this type of measurement data.

That standardization is important because the application recording the data does not necessarily have to be the application analyzing it.

Why MDF4?

Earlier versions of MDF had already established the format within automotive measurement and calibration workflows. However, measurement systems continued to evolve.

ECUs became more complex. The number of measurable parameters increased. Vehicle networks generated more data. Sampling rates increased. Test durations became longer.

As a result, measurement files could become extremely large.

MDF4 introduced an architecture better suited to these requirements while retaining the core idea behind MDF: store measurement data together with enough information to correctly interpret it.

One of the key characteristics of MDF4 is its block-oriented structure.

Instead of treating a measurement file as one large table, MDF4 organizes information into interconnected blocks. Different blocks can describe the file, data groups, channel groups, individual channels, conversions, actual measurement data, events, attachments, and other information.

This architecture gives MDF4 considerable flexibility.

For example, a recording can contain multiple groups of measurements with different structures and timing characteristics rather than forcing every measurement into one universal sample rate.

We'll look much more closely at this block structure in the next article in this series.

MDF4 Is More Than Signal Values

When engineers first encounter an MF4 file, it is easy to think of it as simply a container for signal-versus-time data.

There is considerably more happening underneath.

Imagine that a measurement system records an ECU parameter as the integer value: 2150

That number alone may not tell an engineer very much.

The MDF4 file can also describe the channel, its unit, and the conversion needed to turn the stored value into a meaningful physical value.

The result might be something such as: 21.5 °C

This distinction between stored/raw values and physical engineering values is fundamental to working with measurement data.

MDF4 can preserve the information needed to make that interpretation part of the dataset rather than relying entirely on external knowledge.

Handling Different Sampling Rates

Another important measurement challenge is time.

Not every signal in a vehicle or test system is acquired at the same rate.

For example:

One group of signals might be sampled every 1 ms.
Another might be sampled every 10 ms.
A slower temperature measurement might update every 100 ms.
Network messages may arrive according to their own timing.

Trying to force all of this information into one large table can result in duplicated timestamps, empty values, interpolation, or unnecessarily large files.

MDF4 provides structures that allow related channels and their timing information to be organized efficiently.

This is one reason understanding concepts such as data groups, channel groups, channels, and master channels becomes important when working with MDF4.

Designed for Large Measurement Files

Measurement files can grow quickly.

Recording 1,000 channels at high sampling rates for an extended test can generate millions (or billions) of individual samples.

MDF4 includes mechanisms intended to make storing and accessing these datasets practical. Among them are support for compressed data blocks and structures that allow measurement data to be organized according to how it was acquired.

These features also introduce an important distinction between MDF4 and simpler formats such as CSV.

CSV is extremely useful when data needs to be human-readable or easily exchanged with general-purpose applications. But representing a large, complex measurement recording as rows and columns can significantly increase file size and lose some of the richer structure associated with the original measurement.

MDF4 was designed specifically around measurement data.

Where Is MDF4 Used?

MDF4 is particularly common in automotive engineering, although its underlying concepts apply to other measurement environments as well.

Typical applications include:

ECU calibration
Vehicle testing
Powertrain development
Electrified powertrain and battery testing
Controls development
Validation and verification
Data acquisition
Vehicle network recording
Test bench measurements
Measurement data exchange and post-processing

A common workflow might look like:

Measurement → MDF4 recording → Analysis → Engineering decision

The recording application captures the test in MDF4, and engineers can then use an MDF4-compatible analysis application to inspect signals, compare tests, calculate derived quantities, or investigate events.

For example, ATI VISION Data Analyzer (VDA) can work with MDF4 measurement files for post-processing and analysis, including MDF4 files generated by third-party measurement systems. This illustrates one of the practical advantages of using a standardized measurement format: acquisition and analysis do not necessarily need to happen in the same software environment.

MDF4 vs. MDF3

MDF3 files are still encountered in existing measurement environments, so it is useful to understand that MDF4 is not simply MDF3 with a new file extension.

MDF4 introduced substantial changes to the underlying file architecture to better accommodate modern measurement requirements, including increasingly large and diverse datasets.

For users, both formats may ultimately present familiar concepts, channels, timestamps, values, and units.

For software reading the files, however, their internal structures are significantly different.

This becomes especially important when developing data-processing tools or troubleshooting why a particular application handles one MDF generation differently from another.

Why Engineers Should Understand MDF4

Most engineers working with MF4 files will never need to implement an MDF4 parser.

But understanding the basic structure of the format can still make everyday data analysis easier.

It helps explain why two signals may have different time bases, why extracting a channel from a very large recording can involve more work than expected, why raw and physical values can differ, why file compression affects analysis performance, and why converting an MDF4 recording to a simpler format may discard useful information.

Understanding what is inside the file makes it easier to understand what your analysis software is doing with it.

What's Next: Inside an MDF4 File

So far, we've treated MDF4 largely from the outside: what it is, why it exists, and the types of problems it solves.

The next step is to look inside.

In the next article in this series, Inside an MDF4 File: Understanding the MDF4 Data Structure, we'll explore the block-based architecture behind MDF4 and introduce the relationships between file headers, data groups, channel groups, channels, conversions, and the blocks containing the actual measurement data.

Once those relationships are clear, an MF4 file stops looking like a mysterious binary file and starts looking like a structured representation of the measurement system that created it.

Non-MDF to MDF(4) Import Conversion into VDA

Fri, 03 May 2024 09:40:00 -0400

Converting different file extensions to MF4

The file extensions Measurement Data Format version 4 (MDF4), or in short, MF4 are used interchangeably in the context of data files. Principally MDF4 is an ASAM standard file format specifically designed for the automotive industry to handle a diverse range of data efficiently. As a compact binary format, MDF offers efficient and high-performance storage of huge amounts of measurement data.

The MDF file format allows storage of raw measurement values and corresponding conversion formulas; therefore, raw data can still be interpreted correctly and evaluated by post-processing tools, while the compressed file sizes facilitate easy sharing and collaboration.

MF4 is simply a file that follows the MDF4 standard, containing measurement data stored in accordance with the structure and conventions defined by the MDF4 format. This makes it fully compatible with software and tools that support this standard.

In the realm of data analysis and visualization, the ability to seamlessly convert various file formats into a standardized, easily accessible format is paramount. ATI’s VISION Data Analyzer (VDA) software, - part of the firm’s renowned VISION ecosystem - comprehensively supports MF4 files, plus offers a streamlined process for converting non-MDF files into the universally compatible MF4 format.

VDA easily facilitates the conversion or import of file types into the MF4 file format, enabling users to harness the power of their data without being constrained by incompatible files. This is accomplished by the ASCII Import Wizard which automatically starts when opening a TXT, CSV, or TSV file via the VDA "Open" command. The wizard initially displays data differently based on the file type. File types use different delimiters to separate fields, text, columns, etc.... The ASCII Import Wizard walks the user through setting the rows and columns to distinguish what data is the trace name, measurement units, timestamp, and recorded data points. Each step in the wizard asks for a specific row or column to be selected except for the first step of the import process.

For example, opening a 'TXT' file displays all information in the first column (below image).

Defining a separator in the "Field Separator" drop-down separates data based on the defined separator character. The "" separator is used in this example to yield an idea of how the wizard works (below image).

Files (MF4, REC, TXT, CSV, and TSV) may be extremely large and can be loaded into the VDA via multiple methods. MF4 files import directly, REC files import and convert to MF4, with TXT, CSV, and TSV files starting the ASCII Wizard in any of the following methods.

· Go to "File -> Open" and within the "Open" browser, locate and select a file.

· Double-click on a file in a browser window.

· Drag and drop a file from a browser window onto a VDA tab.

The process remains intuitive and accessible.

For VISION recorder (REC) files, VDA Software employs a sophisticated approach. Upon opening a REC file, VDA initiates a background process utilizing VISION to export the REC file into an MDF4 format. The resulting file is named according to the original REC file, ensuring seamless continuity in data management. For instance, opening a file named "Test.rec" would result in an MDF4 file named "Test-rec.mf4".

In scenarios where a related MDF file already exists for a REC file, VDA Software offers a seamless reimport process. Users are prompted for confirmation, enabling them to effortlessly overwrite existing MDF files or proceed with opening the existing MDF file, depending on their preferences.

In the ever-evolving landscape of data analysis, the ability to seamlessly convert non-MDF files into the standardized MF4 format is indispensable. VDA's intuitive file conversion process not only streamlines data management but also unlocks a world of possibilities for users, enabling them to delve deeper into their data with unparalleled ease and efficiency.

VISION 7.0

Mon, 26 Feb 2024 13:00:00 -0500

ATI Launches VISION 7.0

ATI is thrilled to announce the launch of VISION 7.0, the latest iteration of its software suite. Engineered to meet the evolving needs of automotive professionals, VISION 7.0 introduces features and enhancements that improve the calibration and diagnostic experience to unprecedented levels of sophistication and efficiency.

Key Highlights of VISION 7.0:

64-Bit Application

Increased addressable memory of a 64-bit architecture theoretically addresses 18.4 million terabytes (TB) of RAM, compared to the previous 32-bit system which is limited to just 4 GB. This is crucial for applications that require extensive memory, such as video editing, 3D rendering, and large databases.

Advanced Device Memory (ADM) viewer

The Device Memory Tab features enhanced capabilities for memory display, region usage visualization, and editing. Users benefit from improved memory management with convenient copy/paste and undo/redo functionalities, along with a powerful data item search feature. ECU code decoding is seamlessly integrated with appropriate RP toolkits for comprehensive diagnostics.

Custom Screen Controls (CSC)

VISION with user created CSC are linked via scripts written in languages such as C#, Python, VBScript (Excel), or MATLAB M-scripts. VISION 7.0 includes several CSC demos to inspire creativity and customization.

GPS Location Recording and Visualizer

Virtual location data items that can be mapped to various location sources, including Windows Location Services, GPS units, CAN GPS units, and vehicle network GPS information. Users can effortlessly map GPS coordinates post-recording and leverage the Map Visualizer with trigger and cursor markers for precise analysis.

Improved Flash Support/Scripting

With an updated 64-bit Flash interface, VISION 7.0 delivers seamless compatibility and enhanced performance. The software supports both 32-bit and 64-bit Seed&Key DLLs and introduces API support for controlling automated flashing, streamlining workflows, and boosting productivity.

VISION 7.0 represents a significant milestone in ATI's ongoing commitment to delivering innovative solutions that empower engineers to achieve exceptional results. With its comprehensive suite of features and unparalleled performance, VISION 7.0 sets a new standard for measurement, calibration, and diagnostics software.

Website:

https://www.accuratetechnologies.com/Products/VISIONSoftware

Datasheet:

https://www.accuratetechnologies.com/PDFs/VISION%20Software%20EN.pdf

ASAP 3

Mon, 12 Feb 2024 15:17:33 -0500

ASAP 3 and VISION

Through ATI’s VISION ECU Calibration, Data Acquisition and Diagnostics software, an ASAP 3 host can be set up to remotely control devices for automated tests using the ASAP 3 communication protocol. This remote-control capability is advantageous for engineers who need to access specific items during acquisition.

Created by ASAM (the Association for Standardization of Automation and Measuring Systems) ASAP 3 defines an RS232 communication protocol between a test automation system and a measurement and calibration system connected to an ECU.

Several reasons drive the extensive use of ASAP 3. Primarily ASAP 3 provides a standardized protocol for communication between calibration tools and ECUs, ensuring seamless interoperability between tools and ECUs from various manufacturers.

Efficiency is crucial during the development and calibration phases of automotive electronic systems. The protocol is designed for high-speed communication, enabling faster data exchange between calibration tools and ECUs.

Flexibility makes ASAP 3 suitable for a wide range of applications in the automotive industry, supporting various automated measurement and calibration tasks such as adjusting parameters, measuring data, and flashing ECUs.

Compatibility, as a widely adopted standard, ensures high levels of interoperability between various calibration tools and ECUs from different vendors. This is particularly important in the automotive industry, where multiple suppliers frequently contribute difference components to a single development vehicle or powertrain.

ASAP 3 enhances the reliability of the calibration process. Engineers can trust that the communication between tools and ECUs follow a well-defined and tested standard, reducing the risk of errors or inconsistencies.

The benchmark of the ASAP 3 standard contributes to cost saving in the development process by minimizing the need for custom interfaces and special adaptations for each tool-ECU pair.

Now developed as ASAP 3 V3.0, the latest iteration maintains backward compatibility with previous versions (V2.0, V2.1, and V2.1.1). Notably, previous V2.1 versions lacked documentation or implementation of Diagnostics functionality. In the context of ATI’s VISION software, the ASAM ASAP 3 interface actively listens for commands transmitted by the Automation System (AuSy) through a serial link (RS232) or Ethernet port. Although Ethernet connection is not officially part of the standard, it can be utilized for test implementations.

ASAP 3’s core features within VISION cover online analysis, offline analysis, data management, printer functions and ECU flashing. ATI’s VISION includes comprehensive documentation, demonstrating the interpretation of ASAP 3 requests alongside proprietary commands, ensuring clarity and ease of use.