Accurate Technologies - Blog #VDA

From Raw Measurement to Engineering Signal: How MDF4 Turns Recorded Data into Useful Information

Mon, 19 Oct 2026 14:48:08 -0400

Part 3 - ASAM MDF4 Explained

In Part 2 of our ASAM MDF4 Explained series, we looked inside an MDF4 file and explored the blocks used to organize channels, channel groups, conversions, metadata, and measurement data. But storing a measurement is only half the story.

When an engineer opens an MDF4 file and sees a graph showing engine speed in rpm, temperature in °C, or pressure in bar, the values on screen may not be identical to the values originally stored in the measurement record.

MDF4 provides the information needed to transform recorded data into meaningful engineering signals and place those signals in the correct relationship to time. Let's follow that journey.

It Starts with a Recorded Value

Measurement systems often acquire data from several sources, including ECUs, sensors, and vehicle networks.

What gets recorded may be a raw value, meaning the value is stored in the form provided by the measurement source rather than as the final engineering value an engineer expects to see.

For example, imagine a temperature measurement stored as: 2150

On its own, 2150 does not tell us whether the measurement represents degrees Celsius, degrees Fahrenheit, voltage, resistance, or something else.

The MDF4 channel description provides context about the signal and can associate the stored value with a conversion rule. That rule tells compatible analysis software how to turn the raw value into its physical, human-readable form. ASAM MDF supports raw values and corresponding conversion rules specifically so the original representation can be stored efficiently and interpreted later.

Raw Values and Physical Values

MDF4 distinguishes between the value stored in the measurement record and the physical value produced after a conversion is applied.

The raw value is the encoded value stored in the record.

The physical value is the meaningful result after any required conversion has been performed.

The relationship does not always need to be complicated. A common example is a linear conversion:

Physical Value = Factor × Raw Value + Offset

But MDF4 supports considerably more than simple scaling. Conversion rules can include linear and algebraic formulas, rational conversions, lookup tables, ranges, and conversions between numeric values and text.

That last capability is useful when a recorded numeric value actually represents a state.

For example:

0 → Off

1 → On

2 → Error

Instead of requiring the analysis application to already know what those numbers mean, that interpretation can travel with the measurement data.

Why Store Raw Data at All?

If engineers ultimately want physical values, why not convert everything before it is recorded?

There are several advantages to preserving raw values.

Raw data can be stored in compact data types, potentially reducing the amount of storage required. It can also allow a measurement system to record incoming data without spending additional processing time converting every value during acquisition.

The conversion can then be applied during offline analysis.

ASAM also notes that this approach can allow chunks of data received from an ECU or bus message to be stored without first extracting and converting every individual signal.

In other words, MDF4 can separate two jobs:

Recording what happened and Interpreting what it means

That can be particularly valuable when dealing with high channel counts and high data rates. A Signal Also Needs Time

Knowing that a temperature was 21.5 °C is useful.

Knowing when it was 21.5 °C is much more useful.

Measurement analysis depends on the relationship between values and their position within a measurement sequence. In most vehicle testing applications, that means time.

MDF4 uses master channels to establish this relationship.

A master channel provides the synchronization reference for the other channels associated with it. Time is the most common reference, but MDF4 can also use synchronization domains such as angle, distance, or index depending on the measurement.

For a time-based measurement, the result can be thought of simply as:

Time + Value

For example:

Time	Engine Speed
0.000 s	1,502 rpm
0.001 s	1,507 rpm
0.002 s	1,515 rpm
0.003 s	1,521 rpm

Those timestamps give the samples their position within the test.

Not Everything Is Measured at the Same Rate

Real-world measurement systems rarely collect every signal at exactly the same frequency.

An ECU parameter might be acquired every millisecond, while a temperature sensor might only need to be sampled every 100 milliseconds. Other measurements may arrive irregularly rather than at a fixed interval.

MDF4 supports both multiple sampling rates and non-periodic sampling within the same file.

This is important because MDF4 does not need to artificially duplicate slower measurements simply to make them fit the fastest signal in the recording.

Consider two signals recorded during the same test:

Engine Speed: every 1 ms

|•|•|•|•|•|•|•|•|•|•|

Battery Voltage: every 10 ms

|•| |•|

Both describe the same test period, but they do not contain the same number of samples.

Synchronizing Different Signals

Different sampling rates create an obvious analysis question:

How can signals recorded at different rates be compared?

This is where synchronization becomes important.

Master channels establish the reference that allows samples and events to be ordered according to when they occurred. Signals do not have to contain matching sample counts to belong to the same overall measurement timeline.

Imagine an engineer investigating an unexpected engine event.

Engine speed may have been sampled rapidly. Temperature may have been sampled more slowly. CAN messages may have arrived according to their own transmission timing.

The samples are different, but their timing information allows analysis software to present them in the proper temporal relationship.

That lets an engineer ask useful questions such as:

What happened to throttle position immediately before engine speed changed?

Did temperature begin increasing before or after the event?

Which network message occurred at the same point in the test?

The value tells you what happened. The synchronization information helps tell you when it happened relative to everything else.

From MDF4 File to the Graph on Screen

Putting everything together, there is more happening behind a graph than may initially appear.

A simplified process looks like:

1. Locate the channel

The MDF4 structure describes the signal and where its values are stored.

2. Read the recorded values

The appropriate samples are retrieved from the measurement data.

3. Apply the conversion

If required, the raw values are converted into physical engineering values.

4. Associate the samples with the master channel

The values are placed against their synchronization reference, typically time.

5. Present the engineering signal

The analysis application can now display the measurement using its appropriate values, units, and timing.

Most of this happens automatically when engineers open an MDF4 recording in compatible analysis software.

Where VISION Data Analyzer Fits

This is also where the distinction between the MDF4 standard and an MDF4 analysis tool becomes useful.

MDF4 defines how the measurement and the information required to interpret it can be stored. Analysis software uses that information to present the data in a form engineers can actually work with.

For example, ATI VISION Data Analyzer (VDA) provides native support for ASAM MDF4 files, including files generated by third-party systems. Engineers can visualize signal data using graphs and tables, inspect individual values with cursors, and work with multiple recordings during analysis.

The important point is that the useful engineering signal does not exist independently of its context. The value, conversion, unit, and timing information all contribute to what an engineer ultimately sees.

Why This Matters

It can be easy to think of an MDF4 recording as a collection of signal names and values.

Underneath, MDF4 is preserving the information necessary to turn recorded data into something meaningful.

A stored number can become a physical measurement.

Samples collected at different rates can remain synchronized.

Values from different measurement sources can be placed into the context of the same test.

And because the information needed to interpret those measurements can travel with the file, the data can remain useful long after the original test has ended. That is a major part of what makes MDF4 valuable as a measurement data format.

What's Next: Why MDF4 Works for Large and Complex Measurement Data

As channel counts, sampling rates, and test durations increase, measurement files can become extremely large.

So how does MDF4 handle all that data without turning every recording into an unmanageable file?

In Part 4 of our ASAM MDF4 Explained series, we'll look at how MDF4 approaches large datasets, including data organization, compression, and some of the considerations involved in efficiently reading and analyzing large measurement files.

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.