Task · diagnostics
Vehicle diagnostics
A fault code names a symptom. The work is getting from that symptom to a cause you can defend, using the measurement that was recorded at the time.
In short
Vehicle diagnostics is the work of moving from a symptom — a fault code, a customer complaint, an anomaly in a recording — to a cause supported by evidence. It combines fault memory read over UDS (ISO 14229), OBD-II or J1939 with the measurement data recorded around the event, and the documentation of the function that set the code. VehicleLab does this locally: DiagAI runs specialist agents over fault memory and MDF4 recordings together and ranks likely causes with their evidence, MDX provides the measurement view, and XHandbook resolves the documented function behind the label.
- Enable condition never satisfied in this drive68%evidence — IUPR · DFC
- Sensor drift inside the plausibility window21%evidence — DFC · plausibility
- Wiring intermittence at the connector11%evidence — freeze frame
01
A code is a starting point, not an answer
A diagnostic trouble code records that a detection path fired: a measured quantity crossed a threshold for long enough while the enable conditions held. It does not say whether the sensor, the actuator, the wiring, the plausibility model or the calibration was at fault. That distinction lives in the data recorded around the event.
Working it properly means reading three things together: the fault memory and its freeze frame, the measurement channels around the moment, and the documentation of the function that set it. Most tools give you one of the three.
- Fault memoryDTCs with freeze frames, read over UDS, OBD-II or J1939.
- Measurement contextThe channels around the event at their own rasters, not resampled.
- Function documentationWhat the detection path actually does, resolved to the A2L objects that parametrise it.
- Ranked causesCandidate causes ordered by the evidence behind them, not a single guess.
- Plausibility versus hardwareWhether a signal left its plausibility window because the sensor drifted, because the model it is checked against was wrong, or because something upstream moved.
02
Specialist agents instead of one general model
Diagnosis is domain work. DiagAI runs specialist agents — misfire, DFC, IUPR, gear, drivability, start and warm-up, WLTP, fuel and CAN bus-off — over the same measurement data, each looking for the patterns in its own area, and presents ranked causes with the evidence each one used.
It runs with multi-model routing, including local models, so a programme that cannot send data to an external service can still use it. Deployment can be fully on-premise with per-OEM knowledge isolation.
The value of specialisation shows in the cross-checks. A misfire count means one thing on a smooth road and another with rough-road detection active. A lambda correction that drifts is a different fault when the purge valve is commanded to a high duty cycle than when it is closed. Those are the correlations a domain agent is built to make, and they are the ones a general-purpose model asked to "look at this log" reliably misses.
03
From diagnosis to the change
A diagnosis often ends in a calibration change: a threshold that was too tight, an enable condition that never held, a plausibility limit that did not survive cold weather. XHandbook resolves the label to its A2L object, Hexx edits it in engineering units with checksums recomputed, and HELIX carries it through validation into a traceable release.
The instruments
What does what.
- NEURAL DIAGNOSTIC GRAPHDiagAISpecialist agents over fault memory and measurement data, ranked causes with evidence, on-premise if required.→
- OSCILLOSCOPE LAB & MCPMDXThe measurement view around the event, at each channel's own raster.→
- DOCUMENTATION & MODEL GRAPHXHandbookThe documented function behind the code, resolved to its A2L objects.→
- BYTE-TO-MAP MATRIXHexxEdits the threshold or condition in the calibration image, checksums recomputed.→
Standards & references
Check the source.
These primary sources define the formats and regulatory context discussed above. They do not certify or endorse VehicleLab products.
Questions
Frequently asked.
What is automotive diagnostics software used for in an OEM team?
It is used to move from a symptom — a fault code, a complaint or an anomaly — to a cause supported by evidence, by reading fault memory together with the measurement data recorded around the event and the documentation of the function that set the code.
Which diagnostic protocols and standards are supported?
UDS (ISO 14229), OBD-II and J1939, with CAN and LIN bus data, alongside ASAM MDF4 measurement files and A2L calibration descriptions.
Can AI-assisted diagnostics run without a cloud service?
Yes. DiagAI supports local model routing and on-premise deployment with per-OEM knowledge isolation, so warranty and prototype data can stay inside your network.
How is this different from a workshop scan tool?
A scan tool reads codes and live values. This is engineering diagnostics: the fault memory is read together with high-rate recordings and the ECU function documentation, and candidate causes are ranked with the evidence behind them.
Can a general-purpose AI model do this instead?
Not reliably. The useful conclusions come from cross-checks that need domain structure — a misfire count read against rough-road detection, a mixture drift read against commanded purge duty, a monitor result read against its enable conditions. That is why the work is split across specialist agents rather than handed to one model with a log attached.
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.