ECU data analysis

Test campaigns produce files measured in gigabytes, with channels at very different rates in the same recording. The wrong tool answers by resampling everything to one rate, which quietly removes the moment you are investigating. The right one keeps each channel at its own raster and resolves the cursor independently for each.

Where a display cannot draw every sample, downsampling should select real samples rather than average them, so every point a cursor lands on is a value the ECU actually reported. Held values — carried forward because the signal had not updated — should be marked as such.

The failures that cost the most time are not crashes. They are analyses that run cleanly and return the wrong sign, and they come from a short list of causes that repeat across programmes.

Resampling everything to one rate is the first: it removes the transient under investigation and replaces it with an average. Dropouts are the second — a channel that reports a zero-coded value while it is invalid will drag any mean, threshold or counter computed over it, so those samples have to be excluded before the arithmetic. The third is naming: the same physical quantity can be labelled differently between two software versions, and an analysis that matches on the label alone will silently report a channel as missing rather than comparing it.

A channel name is only half the story. The calibration object behind it has a type, an address, a record layout, a conversion rule and a unit, and the function that uses it is described in the ECU documentation. XHandbook opens EHANDBOOK containers offline and follows a label from the topic that documents it, through the model block that uses it, to the A2L object itself — and back again.

That link is what turns a measurement session into an explanation: not only what the value was, but which function produced it and which calibration object would change it.

Most of what people mean by CAN data analysis or vehicle data analysis is this: a recording of bus traffic, decoded into named signals, read alongside the internal ECU variables that explain it. The frames carry no meaning on their own — a DBC or ARXML description is what turns identifier 0x0C9 into engine speed in rpm, and a mismatched description still decodes and still returns plausible numbers.

The recording itself arrives as MDF4, as Vector BLF or ASC, or as CSV, depending on the logger. Converting between those formats to reach a tool that only reads one of them is where timestamp resolution, error frames and CAN FD attributes get quietly dropped, so it is better to open the original than to convert it.

Repeated analysis belongs in a script, not in a person. MDX exposes a local REST API and a Python SDK for batch processing across campaigns, and ships an MCP server so AI assistants — Claude, ChatGPT, Codex, Cursor, Gemini — can open files, extract channels and run analyses directly, with the data staying on your machine.

DiagAI adds domain agents over the same files: misfire, DFC, IUPR, gear, drivability, start and warm-up, WLTP, fuel and CAN bus-off, each answering with the evidence it used.