Book a demo

Reference

Know-how

The standards an ECU engineer actually has to work with, explained by people who read the files for a living.

By , Founder & Lead Engineer

In short

Vehicle calibration, measurement and diagnostics run on a small set of standards. UDS (ISO 14229) carries diagnostic services and fault memory. XCP (ASAM MCD-1) carries measurement and calibration traffic between a tool and an ECU. DoIP (ISO 13400) moves diagnostics over Ethernet. SAE J1939 is the CAN-based application layer for heavy-duty vehicles. CAN FD extends classical CAN with a faster data phase and longer frames. A DBC file describes how to decode CAN frames into named signals. Each page here explains one of them, what it does not cover, and which file you need alongside it.

01

Why these, and not a glossary

A glossary tells you what an acronym stands for. It does not tell you why a measurement stops when the ECU changes session, why a DBC decodes a frame into nonsense after a bus redesign, or why a DoIP tester finds nothing on a vehicle that answers perfectly on CAN. Those are the questions engineers actually search for, usually in the middle of a problem.

Each page below opens with a direct answer, then explains the mechanism, then says plainly what the standard does not do. Where one of our tools is relevant we say which and why; where none is, we say nothing.

02

How they fit together

These standards occupy different layers and different jobs, and most confusion comes from mixing them up. UDS and J1939 are application layers — they define what a request means. CAN, CAN FD and DoIP are transports — they define how bytes travel. XCP is a measurement and calibration protocol that can ride on several transports. A DBC is not a protocol at all; it is a description file, the CAN equivalent of what an A2L does for calibration objects.

A measurement session typically involves several at once: raw frames on CAN FD, decoded by a DBC, alongside XCP traffic carrying internal ECU variables, with UDS used to read fault memory before and after. The recording that comes out is an MDF4 file.

  • Application layerUDS (ISO 14229), SAE J1939, OBD-II services.
  • TransportCAN, CAN FD, DoIP (ISO 13400), ISO-TP (ISO 15765-2).
  • Measurement and calibrationXCP (ASAM MCD-1), and its predecessor CCP.
  • Description filesDBC for bus signals, A2L (ASAP2) for calibration objects.

Questions

Frequently asked.

Is UDS the same as OBD?

No. OBD-II defines a legally mandated set of emissions-related diagnostic services and data. UDS (ISO 14229) is a much larger manufacturer diagnostic protocol covering sessions, security access, routine control, memory access and programming. A single ECU usually supports both, on the same bus.

Do I need a DBC file to record CAN?

No, you can record raw frames without one. You need a DBC — or an equivalent description — to turn those frames into named, scaled signals you can plot and reason about.

Is CAN FD a different bus from CAN?

It is the same two-wire physical bus with an extended frame format and a faster data phase. Classical CAN controllers cannot interpret CAN FD frames, which is why a mixed network needs care.

Where does MDF4 fit?

MDF4 (ASAM MDF) is the recording format, not a protocol. It is what the measurement is stored in after it comes off the bus, whatever combination of CAN, CAN FD, XCP or diagnostics produced it.

Next step

Open one of your own files with us.

Send a measurement, an A2L or an EHANDBOOK container. We will open it in the instruments on a call, with your engineers in the room.

Book a technical demo Read the docs

Read next