Accurate Technologies - Blog #ADAS

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.

Automotive Ethernet Explained Pt. 7

Wed, 15 Jul 2026 11:22:51 -0400

Automotive Ethernet Myths: Separating Fact from Fiction

Automotive Ethernet has become one of the most important technologies shaping modern vehicle development. Yet despite its growing adoption, there are still plenty of misconceptions surrounding what it is, what it can do, and how it fits into today's vehicle architectures.

Let's separate some of the most common myths from reality.

Myth #1: Automotive Ethernet Will Replace CAN

Reality: Automotive Ethernet complements CAN. It does not replace it.

One of the biggest misconceptions is that Ethernet is replacing every in-vehicle network. In reality, modern vehicles rely on a combination of communication technologies.

Each serves a different purpose:

LIN connects simple sensors and actuators.
CAN handles reliable, real-time control communication.
CAN FD provides increased bandwidth for larger control messages.
Automotive Ethernet acts as the high-speed backbone for data-intensive systems.

Each network has strengths, and modern vehicle architectures are designed to take advantage of all of them.

Myth #2: Ethernet Is Just Faster CAN

Reality: Ethernet is an entirely different communication architecture.

CAN is message-based. Automotive Ethernet is packet-based.

Ethernet supports:

IP-based communication
Service-oriented architectures
High-bandwidth data streams
Centralized computing
Modern diagnostics

It is not simply a faster version of CAN. It enables capabilities that traditional vehicle networks were never designed to support.

Myth #3: Standard IT Ethernet Tools Are Good Enough

Reality: Automotive Ethernet has unique requirements.

Although Automotive Ethernet is based on Ethernet standards, vehicles introduce additional technologies and protocols, including:

Single-Pair Ethernet
SOME/IP
DoIP
AVB and TSN

Engineers also need visibility across CAN, CAN FD, LIN, gateways, and Ethernet simultaneously.

General-purpose networking tools can provide packet captures, but they typically lack the automotive-specific decoding and mixed-network visibility needed for efficient development and validation.

Myth #4: More Bandwidth Solves Everything

Reality: High bandwidth introduces new challenges.

Moving more data is only part of the equation.

Engineers must also manage:

Latency
Jitter
Synchronization
Gateway routing
Service discovery
Network loading

ADAS systems, for example, depend on camera, radar, and lidar data arriving at predictable times. High bandwidth without proper timing can still result in poor system performance.

Myth #5: Diagnostics Work the Same as They Always Have

Reality: Diagnostics are evolving alongside vehicle architectures.

CAN-based diagnostics remain important, but Ethernet has introduced Diagnostics over IP (DoIP), enabling faster communication and more efficient software updates.

As vehicles become increasingly centralized, diagnostics span multiple networks and often pass through gateways before reaching their destination.

Testing diagnostic communication now involves validating routing, network behavior, and interactions across the complete vehicle architecture.

Myth #6: Ethernet Makes Vehicle Networks Simpler

Reality: Ethernet simplifies architecture, not development.

Zonal architectures reduce wiring, improve scalability, and support centralized computing.

However, they also introduce new engineering challenges.

Development teams must understand:

Mixed-network communication
Service-oriented software
Time synchronization
High-speed packet analysis
Gateway behavior
Multi-network diagnostics

The physical architecture may become simpler, but the software and communication layers become more sophisticated.

Myth #7: One Tool Can Solve Every Problem

Reality: Modern development requires an integrated toolchain.

Developing and validating today's vehicles involves multiple activities, including:

Network analysis
ECU interaction
Diagnostics
Gateway testing
Simulation
Data logging
Validation

Rather than relying on a single tool, engineers benefit from solutions that work together throughout the development lifecycle.

For example, CANLab provides visibility into communication across CAN, CAN FD, LIN networks. VISION supports ECU interaction and development workflows, while ATI's Vehicle Communication Gateway helps engineers bridge and validate communication between mixed-network architectures.

The Real Story

Automotive Ethernet is not replacing every existing technology.

It is enabling a new generation of vehicle architectures built around centralized computing, zonal networking, software-defined functionality, and advanced driver assistance systems.

CAN, CAN FD, LIN, and Automotive Ethernet each have a role to play. Understanding how they work together, along with the right tools to develop and validate them, is what allows engineers to build reliable, scalable vehicle networks.

Series Recap

Throughout this series, we've explored:

Why Automotive Ethernet became necessary
How it works alongside CAN and CAN FD
The protocols that power modern vehicle communication
The rise of zonal architectures
Development and validation challenges
The tools engineers use to build and test modern vehicle networks

As vehicles continue to evolve, Automotive Ethernet will play an increasingly important role. But success won't come from adopting a single technology. It will come from understanding how the entire vehicle network works together.

Continue Exploring ATI Solutions

Whether you're developing, testing, or validating mixed-network vehicle architectures, ATI provides an ecosystem of software and hardware solutions designed to support every stage of the workflow. From CANLab for network analysis to VISION for development and validation, and the Vehicle Communication Gateway for protocol translation and mixed-network communication, ATI helps engineers simplify the complexity of modern vehicle networks.

Automotive Ethernet Explained Pt. 5

Wed, 20 May 2026 09:44:34 -0400

Testing Automotive Ethernet: Development vs Validation Challenges

Automotive Ethernet changes more than vehicle architecture. It also changes how engineers develop, debug, and validate vehicle networks.

For years, CAN-based testing focused primarily on message timing, arbitration, and signal-level behavior. Ethernet introduces an entirely different layer of complexity:

Packet-based communication
Higher bandwidth data streams
Service-oriented communication
Network synchronization
Multi-network coexistence

As vehicles become more software-defined and Ethernet adoption grows, testing moves from isolated ECU validation to full system-level network validation.

Why Automotive Ethernet Testing Is More Complex Than CAN

CAN networks are relatively predictable.

Messages are small, deterministic, and transmitted over shared buses with well-understood behavior. Ethernet networks operate differently.

Automotive Ethernet introduces:

Switched network architectures
Large packetized data streams
Dynamic service discovery
IP-based diagnostics
Time-sensitive communication

This means engineers are no longer validating only:

Signal values
Message timing
Bus utilization

They must also validate:

Latency
Packet loss
Synchronization
Service availability
Network routing behavior

The testing problem becomes significantly larger.

Development vs Validation: Different Goals

One of the biggest shifts with Automotive Ethernet is that development and validation teams often need different types of visibility and tooling.

Development Testing

Development testing focuses on making systems work.

Typical activities include:

ECU bring-up
Protocol debugging
SOME/IP service validation
Gateway configuration
DoIP diagnostics verification

Engineers often need:

Real-time packet visibility
Traffic generation and stimulation
Protocol decoding
Service discovery monitoring

At this stage, flexibility and fast debugging are critical.

Validation Testing

Validation testing focuses on proving the system works reliably under real-world conditions.

This includes:

Network load testing
Latency and jitter analysis
Synchronization validation
Fault injection
Regression testing
Multi-network interaction testing

Validation teams must verify behavior across:

CAN
CAN FD
Ethernet
LIN
Gateways and domain controllers

As architectures become more centralized, failures in one network can impact multiple vehicle functions simultaneously.

Timing and Synchronization Challenges

ADAS systems depend heavily on timing.

Camera, radar, and lidar data must arrive:

In sequence
Within expected timing windows
Without excessive jitter or packet loss

Even small synchronization issues can affect:

Sensor fusion
Object detection
Vehicle decision-making

Technologies like TSN help manage deterministic communication, but they also increase testing complexity.

Validation teams must verify:

Clock synchronization
End-to-end latency
Stream prioritization
Deterministic delivery under load

Gateways Become Critical Test Points

Modern vehicles rely heavily on gateways to connect CAN, CAN FD, and Ethernet networks.

This creates several challenges:

Message translation accuracy
Diagnostic routing correctness
Timing alignment between networks
Security filtering behavior

In many cases, gateway issues only appear during system-level testing when multiple networks interact simultaneously.

Development and validation teams increasingly use dedicated communication gateways and network simulation platforms to:

Emulate vehicle traffic
Verify mixed-network behavior
Reproduce edge-case failures
Validate diagnostic communication paths

Diagnostics Over Ethernet Changes Validation

DoIP introduces major advantages, including:

Faster diagnostics
Faster ECU flashing
Better scalability

But it also changes the testing environment.

Teams must now validate:

IP addressing and routing
Ethernet session management
Multi-ECU diagnostic traffic
Gateway behavior during diagnostics

Testing diagnostics is no longer limited to verifying CAN messages. It now involves validating complete IP-based communication flows.

Network Visibility Is More Important Than Ever

As vehicles adopt zonal architectures and centralized compute, visibility across the full network becomes essential.

Engineers need to understand:

How traffic moves across domains and zones
Which systems are generating load
Where bottlenecks occur
How failures propagate through the architecture

Testing individual ECUs in isolation is no longer enough.

The focus shifts toward:

System-level validation
Network-wide analysis
Cross-domain debugging

Automotive Ethernet Requires New Testing Strategies

Traditional CAN workflows still matter, but they are no longer sufficient on their own.

Modern validation strategies increasingly combine:

Ethernet packet analysis
CAN and LIN monitoring
Gateway simulation
Fault injection
Time synchronization analysis
Automated regression testing

The goal is no longer just validating a bus. It is validating the behavior of an interconnected vehicle system.

Looking Ahead

Automotive Ethernet adoption continues to grow alongside:

Zonal architectures
Centralized compute
Software-defined vehicles
Advanced ADAS systems

As these systems scale, development and validation workflows will continue evolving toward more integrated and network-aware testing approaches.

Understanding the architecture is important. Validating that it performs reliably under real-world conditions is what ultimately brings these systems into production.

Up Next

In the next post, we will look at practical Automotive Ethernet tooling and what engineers need to get started with development, diagnostics, monitoring, and validation in mixed-network vehicle environments.

Automotive Ethernet Explained Pt. 3

Tue, 31 Mar 2026 14:25:42 -0400

Automotive Ethernet Protocols in Practice: From SOME/IP to ADAS Data Streams

Automotive Ethernet provides the bandwidth modern vehicles need. But bandwidth alone does not solve the communication challenges inside a vehicle.

Once Ethernet became part of the vehicle architecture, the industry needed protocols designed specifically for automotive systems. These protocols define how services are discovered, how diagnostics operate, and how large data streams move between ECUs.

Three of the most common are SOME/IP, DoIP, and AVB/TSN. Each solves a different problem in the vehicle network.

Why Automotive Ethernet Protocols Exist

Traditional automotive networks like CAN are message-based. Every ECU knows exactly which message IDs to listen for.

Ethernet networks operate differently. They are packet-based, and communication is typically organized around services and endpoints rather than fixed message IDs.

Modern vehicles also require capabilities that earlier networks were never designed to support, including:
High-bandwidth sensor data
Service-oriented software architectures
Large-scale diagnostics and software updates
Precise timing and synchronization

Automotive Ethernet protocols address these needs while maintaining the reliability required for vehicle systems.

SOME/IP: Service-Oriented Communication

SOME/IP (Scalable Service-Oriented Middleware over IP) is one of the most widely used protocols on Automotive Ethernet networks due to it’s compatibility with AUTOSAR standards.

Instead of fixed messages, SOME/IP allows ECUs to offer services. Other ECUs can discover and request those services dynamically.

For example:

A camera ECU may offer a video processing service
A domain controller may offer vehicle state information
An ADAS system may request sensor data from multiple sources

SOME/IP enables this type of communication through:

Service discovery
Request and response messaging
Event notifications

This architecture supports the move toward software-defined vehicles, where software components interact more like distributed applications than isolated ECUs.

DoIP: Diagnostics Over Ethernet

Diagnostics have traditionally run over CAN using UDS (Unified Diagnostic Services).

As Ethernet networks became common in vehicles, the industry introduced Diagnostics over IP (DoIP) to carry diagnostic messages over Ethernet.

DoIP allows engineers and service tools to:

Access ECUs over Ethernet
Perform diagnostics more quickly
Transfer large data sets efficiently
Support faster software updates

Because Ethernet supports significantly higher bandwidth than CAN, operations like flashing firmware or retrieving large diagnostic logs can be completed much faster.

In mixed-network vehicles, gateways often route diagnostics between CAN-based ECUs and Ethernet-based ECUs so diagnostic tools can communicate across the entire vehicle.

AVB and TSN: Managing Time-Sensitive Data

High-bandwidth data streams introduce another challenge: timing.

ADAS systems often depend on synchronized data from multiple sensors. Cameras, radar, and lidar must deliver data with predictable timing so the vehicle can build an accurate model of its surroundings.

This is where AVB (Audio Video Bridging) and TSN (Time-Sensitive Networking) come into play.

These technologies extend Ethernet with capabilities that support:

Time synchronization across ECUs
Guaranteed bandwidth allocation
Predictable latency
Deterministic communication

TSN, in particular, is becoming increasingly important as vehicles rely more heavily on synchronized sensor data.

ADAS Systems Drive the Need for Bandwidth

ADAS and automated driving systems generate enormous amounts of data.

Consider a modern vehicle equipped with multiple cameras, radar sensors, and other perception systems. Each sensor produces continuous streams of information that must be processed, combined, and analyzed in real time.

These systems require:

High bandwidth
Reliable data delivery
Precise synchronization

Automotive Ethernet provides the physical network for this data, while protocols like SOME/IP and TSN help ensure the data moves efficiently and arrives when it is needed.

Without these protocols, managing this level of communication would be extremely difficult.

How Data Flows Between ECUs

In a modern Ethernet-enabled vehicle, data often flows through multiple layers of the network.

A simplified example might look like this:

Sensors capture raw data such as camera frames or radar measurements.
Sensor ECUs transmit data over Automotive Ethernet.
Domain or zonal controllers aggregate and process information from multiple sensors.
Processed data is shared with other vehicle systems through service-based communication such as SOME/IP.
Diagnostic and maintenance functions operate over DoIP when needed.

This architecture allows high-bandwidth data to move efficiently between key computing nodes while maintaining compatibility with other vehicle networks such as CAN and LIN.

Up Next

Understanding the protocols is only part of the picture. The way vehicles are architected around these networks is evolving as well.

In the next post, we will explore zonal architectures and how Automotive Ethernet is reshaping vehicle network design.