UDS (ISO 14229)

A request is a service identifier followed by parameters. Reading fault memory is service 0x19 (ReadDTCInformation) with a sub-function selecting which report you want. Reading a named value is 0x22 (ReadDataByIdentifier) followed by a two-byte data identifier. A positive response echoes the SID with bit 6 set — 0x22 becomes 0x62 — followed by the payload. A negative response is always 0x7F, the original SID, and a one-byte response code.

Those response codes carry more information than engineers often use. 0x33 (securityAccessDenied) means the request was understood but the session is not unlocked. 0x31 (requestOutOfRange) usually means the identifier does not exist on this ECU. 0x78 (responsePending) is not an error at all — it asks the tester to extend its timeout while the ECU works, and a tester that treats it as a failure will report phantom faults.

Most UDS services are only available in a particular session. An ECU boots in the default session, where a tester can read identification and fault memory but little else. An extended session unlocks manufacturer functions; a programming session is required before a flash sequence. Sessions time out, so a tester has to send a tester-present message (0x3E) to keep one alive — and a measurement that quietly stops is very often a session that expired.

Security access (0x27) is a seed-and-key exchange: the tester requests a seed, computes a key with an algorithm supplied by the manufacturer, and sends it back. Failed attempts are usually counted and followed by a lockout delay that survives a reset. This is deliberate, and it is why diagnostic work on a protected ECU cannot be done from the standard alone.

OBD-II is a regulated subset: a fixed set of services and standard PIDs that any compliant vehicle must answer, so that an independent workshop or a roadside inspection can read emissions-relevant data without manufacturer knowledge. UDS is the manufacturer protocol, far larger, and almost entirely manufacturer-defined above the service layer.

In practice both run on the same vehicle, often on the same bus, addressed differently. A diagnostic session that reads an emissions monitor through OBD-II mode 0x06 and reads the same underlying value through a UDS data identifier is reading two views of one ECU. The OBD figure is the one a regulator sees; the UDS figure is usually the one the calibration engineer trusts, because it is the internal quantity rather than the reported one.

A fault that only appears in a particular manoeuvre is a timing question, not a diagnostics question. The useful view puts the diagnostic exchange and the measured signals on one time base: the DTC set-event, the monitor input that triggered it, and the vehicle state at that moment.

DiagAI speaks UDS, OBD-II and J1939 and runs on-premise, so a protected diagnostic session stays inside the network it belongs to. MDX opens the MDF4 recording from the same test so the frame-level exchange and the signal trace can be read together. XHandbook resolves the ECU function behind the identifier when the question becomes why the threshold is what it is.