Accurate Technologies - Blog #ASAM

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.