Listening to the Vehicle:
UDS, DTC & the EV diagnostic stack.

§ IWhy diagnostics exist at all

Imagine a doctor with a stethoscope. Now imagine fifty patients in one room, each with its own heartbeat, each capable of failing silently. That is, more or less, the situation inside a modern car. The diagnostic system is the stethoscope — and more importantly, the language each patient agrees to answer in.

A modern vehicle contains anywhere from 30 to 150 ECUs (Electronic Control Units) — each a small computer with its own firmware, memory, sensors and faults. When something goes wrong, the technician needs to ask, in a uniform way:

• Who are you? What software version?
• What faults have you seen? When? Under what conditions?
• What does your world look like right now — temperatures, voltages, currents?
• Can I reflash you? Reset you? Run a routine on you?

To make this possible, the industry standardized one common diagnostic protocol that runs on top of whatever bus the ECU happens to be on. That protocol is UDS — Unified Diagnostic Services, defined in ISO 14229. core idea One language, fifty ECUs, every workshop on Earth.

§ IIThe diagnostic stack

UDS doesn't run alone. It sits on top of a transport, which sits on a network, which sits on a wire. Think of it as a letter: UDS is the language inside the envelope, the transport is how the envelope is sealed and segmented, the network decides how envelopes get routed.

For most of the last twenty years, the wire was a classical CAN bus at 500 kbps, the transport was ISO-TP, and CAN identifiers were assigned in pairs (one for request, one for response) per ECU. EVs and modern domain controllers increasingly use CAN-FD (up to 8 Mbps payload) and, for high-bandwidth or zonal architectures, DoIP (Diagnostics over IP) — the same UDS payload, just inside Ethernet/TCP frames.

§ IIIUDS in one breath

Every UDS conversation has the same skeleton: tester sends a request, ECU sends back either a positive response or a negative response. That's it. The shape is brutally simple:

Three patterns to memorize and you can read most UDS traces:

• SID (Service Identifier): one byte, says what the tester wants. 0x22 = read, 0x2E = write, 0x19 = read DTCs, 0x31 = run a routine.
• Positive response: ECU echoes the request, but with SID + 0x40. So 0x22 becomes 0x62, 0x10 becomes 0x50, etc.
• Negative response: always starts with 0x7F, then the original SID, then a one-byte NRC (Negative Response Code) explaining why.

Common NRCs you'll see in the wild: 0x11 service not supported, 0x12 sub-function not supported, 0x13 incorrect message length, 0x22 conditions not correct (often: ECU is not in the right session or the high-voltage system is interlocked), 0x31 request out of range, 0x33 security access denied, 0x7E sub-function not supported in active session, 0x7F service not supported in active session, and the famous 0x78 — "requestCorrectlyReceived, responsePending" — the ECU's way of saying hold on, I'm working on it.

§ IVOBD — the regulated subset

If UDS is a private conversation between the OEM and its workshop, OBD is a public broadcast in a language every emissions inspector on Earth has to speak. It predates UDS by a decade — but today it's best understood as a fixed, legally-mandated subset of UDS, exposing only what the regulator needs to see.

OBD stands for On-Board Diagnostics. It is the part of a vehicle's diagnostic system that is required by law to be present, accessible without special tools, and answer in a standardized way regardless of manufacturer. The 16-pin connector under your dashboard is its physical face. Every $20 scanner from a hardware store talks to it. So does your state's emissions inspection station.

A two-minute history

• OBD-I (1988–1995) — California Air Resources Board. Manufacturer-specific connectors, codes, and protocols. The "check engine light" exists but technicians need a brand-specific tool.
• OBD-II (1996+ US, 2001+ EU as EOBD, 2008+ Japan as JOBD) — universal 16-pin connector, standardized DTC format, standardized PIDs and modes. A consumer with a $20 scanner can read codes from any car.
• CAN-only mandate (2008+ US model year) — the legacy protocols are phased out; ISO 15765-4 (CAN-based OBD) becomes the only permitted physical layer.
• WWH-OBD (ISO 27145, "World-Wide Harmonized OBD") — the modern unification. Built on top of UDS rather than alongside it. Mandated for heavy-duty diesels in the EU and increasingly extending to light-duty and BEVs.

OBD vs UDS in one table

The ten modes of OBD-II (SAE J1979)

So a complete OBD-II read of engine RPM looks like this on the wire:

Mode 01 PID 01 — the "MIL byte" (interactive)

The single most-read piece of OBD-II data is PID 0x01: a 4-byte status word that tells you whether the Check Engine Light is on, how many emissions DTCs are stored, and how many readiness monitors have run. The very first byte ("Byte A") is the part everyone cares about.

Bytes B, C, D of the PID 01 response encode readiness monitor status — 11 emissions monitors that must each run to completion before an emissions inspection station will pass the vehicle. The monitors split into:

• Continuous (3): Misfire detection, Fuel system, Comprehensive components — these run every drive.
• Non-continuous (8): Catalyst, Heated catalyst, Evaporative system, Secondary air, A/C refrigerant, Oxygen sensor, Oxygen sensor heater, EGR/VVT — each only runs when conditions are favorable.

OBD-II on EVs — what's actually required

Until very recently, "OBD for BEVs" was almost a contradiction. With no engine, no catalyst, no evaporative emissions, the entire J1979 framework barely applied. The regulatory situation is changing fast:

• CARB OBD-II battery durability (effective 2026 MY) — California requires BEVs to monitor and report State-of-Health (SOH) via standardized OBD-II PIDs. Excessive capacity loss must illuminate an MIL-equivalent indicator. This brings high-voltage battery diagnostics into the public OBD layer for the first time.
• EU type-approval (Regulation 2018/858 + UNECE R-100/R-154) — standardized OBD data access for EVs, including battery degradation reporting and high-voltage system diagnostics.
• ISO 27145 (WWH-OBD) — the long-term destination. WWH-OBD is essentially UDS-with-a-mandatory-emissions-profile. Service IDs are the UDS ones (0x22 to read, 0x19 to read DTCs, etc.) and the "OBD subset" is just an agreed list of which DIDs and DTCs an inspector is entitled to read. This collapses the OBD/UDS split.

EV-relevant PIDs added to SAE J1979 (and J1979-DA / J1979-2 amendments) include:

• 0x5B — Hybrid/EV battery pack remaining life (a single-byte percentage)
• 0x8E — engine-friction-percentage (irrelevant for BEV but reported as "not supported")
• The 0x9X block — block of multi-byte PIDs for hybrid/EV system data, including HV bus voltage and current
• WWH-OBD adds extensive battery telemetry through DIDs in the F4xx and F5xx range

Practical & reverse-engineering notes for EVs

• The MIL is not the warning system you care about on an EV. A traction battery isolation fault, an inverter overcurrent, a contactor weld — none of these are emissions DTCs. They are powertrain/HV DTCs in OEM-specific DID space. The cluster warning that the driver sees comes from a separate body-controller logic path, not from Mode 01 PID 01.
• Cheap dongles only speak CAN OBD-II. ELM327-based scanners ($10–$30) implement ISO 15765-4 only and access the public OBD-II subset. For richer telemetry — cell voltages, motor temperatures, inverter junction temps — apps like LeafSpy, Torque Pro EV plugins, Car Scanner, and EV Notify send 0x22 <DID> requests to OEM-specific DIDs reverse-engineered by the community.
• Newer EV architectures may not be OBD-CAN at all. A vehicle with a fully Ethernet/DoIP-based diagnostic backbone exposes OBD through a gateway: the OBD-II port still has CAN-H/CAN-L pins, but only the gateway is on that bus, and it translates Mode 01/03/etc. requests into DoIP UDS requests to the actual ECUs. From the scanner's side it looks identical; internally it's a translation layer.
• "Permanent DTCs" (Mode 0x0A) close the obvious loophole. Pre-emissions-inspection "clear codes" with Mode 04 won't help — Mode 0A holds a separate, ECU-controlled DTC list that only clears when the ECU has independently verified the underlying fault is gone (typically 3 consecutive monitor cycles without recurrence).

§ VThe service catalog (interactive)

UDS defines ~25 services, but in practice you'll touch maybe a dozen. Click any tile to see its request shape, an example, and where it shows up in EV work.

§ VISessions & the seed/key dance

An ECU is not a single piece of cooperative software — it has modes. By default, in defaultSession, it will answer basic identification questions and report DTCs but refuse to change anything important. To unlock dangerous operations, the tester escalates the ECU into a different session, and for the truly dangerous ones, also passes a security check.

The three sessions every ECU has

Sessions matter because UDS services are session-gated. You can't write a DID in default session. You can't erase flash unless you're in programming session. The ECU will return NRC 0x7F if you try.

Security access — the seed and the key

For services that touch real state (writing calibration DIDs, erasing flash, unlocking developer routines), UDS layers in service 0x27: a challenge-response handshake.

1. Tester asks for a seed: 27 01 → ECU replies 67 01 <seed>.
2. Tester computes a key by running the seed through a secret algorithm (a polynomial, a CMAC, a HSM-backed signature — depends on the OEM and the ECU's ASIL/SecOC level).
3. Tester sends 27 02 <key>. If the key matches what the ECU computed independently, it replies 67 02 and you're unlocked.

§ VIIThe shape of a DTC

A DTC — Diagnostic Trouble Code — is the receipt the ECU prints when a monitored condition fails. The familiar form P0420 on a scanner screen is a human gloss; on the wire it is three bytes.

Decode any DTC

Every five-character DTC encodes into two bytes (plus a third byte for the failure type byte, see below). The mapping:

• Character 1 — system letter: P powertrain, C chassis, B body, U network/communication. (Bits 15..14 of the 2-byte code.)
• Character 2 — 0 = generic / SAE-defined, 1 = manufacturer-specific, 2/3 = reserved or generic depending on system. (Bits 13..12.)
• Characters 3–5 — the actual fault number, hex.

On the bus, a DTC is always reported as 3 bytes: the 2-byte code above, then a failure type byte (FTB) — an SAE J2012 sub-classification telling you what kind of fault it was (open circuit, short to ground, signal out of range high, signal stuck, performance, etc.). So a complete DTC reference is e.g. C0 5C 12 = "C05C-12" = "HV Battery Cell 12 Voltage — circuit short to battery".

§ VIIIThe DTC status byte — a one-byte history

A DTC alone is not very informative — has it just happened? Is it confirmed? Is it intermittent? UDS attaches an 8-bit status byte to every DTC report, where each bit is a flag from ISO 14229-1 Annex D. The status byte is how an ECU compresses an entire diagnostic history into 8 bits.

Reading DTCs with 0x19

Service 0x19 has many sub-functions — they all ask "tell me about your DTCs" but slice the set differently. The five you'll use most:

• 19 01 <mask> — reportNumberOfDTCByStatusMask. "How many DTCs match this status pattern?" Mask 0x09 = "test failed + confirmed".
• 19 02 <mask> — reportDTCByStatusMask. The same, but actually list them.
• 19 04 <dtc> <snapshot#> — reportDTCSnapshotRecordByDTCNumber. Returns the freeze frame: the snapshot of operating conditions when the fault first occurred.
• 19 06 <dtc> <ext#> — reportDTCExtDataRecordByDTCNumber. Aging counter, occurrence counter, fault detection counter.
• 19 0A — reportSupportedDTC. "What DTCs do you support?" — useful to validate a CDD file against the actual ECU.

And of course 14 FF FF FF — clearDiagnosticInformation with the wildcard group "everything". After a fault is repaired, this is how you reset the DTC memory.

§ IXEV subsystem fault atlas

This is where EVs diverge from ICE diagnostics. Click each subsystem to see what kinds of faults it reports — and what's actually happening physically when those DTCs fire.

§ XFlashing an ECU — the bootloader handshake

Software updates over UDS are not a single command — they are a choreographed sequence. The basic shape, used by virtually every OEM (with variations), is:

1. Enter extended session. 10 03 — needed before you can elevate further.
2. Disable communication. 28 03 01 — stop non-diagnostic CAN traffic so the ECU isn't getting hammered with periodic messages during the flash.
3. Disable DTC setting. 85 02 — flashing causes legitimate DTCs to fire all over the network; suppress them.
4. Enter programming session. 10 02 — this typically reboots the ECU into the bootloader. You'll lose the link briefly.
5. Security access. 27 01 → seed; 27 02 <key> → key. Bootloader has its own seed/key, often stronger than the application's.
6. Write the fingerprint. 2E F1 5A <tester ID, date> — leaves a forensic record of who flashed this part.
7. Erase memory. 31 01 FF 00 <addr> <len> — routine 0xFF00, eraseMemory. The ECU returns 0x78 (pending) for several seconds while it actually erases the flash sectors.
8. Request download. 34 <format> <addr> <len> — ECU answers with the max block size it can accept.
9. Transfer data. Repeated 36 <blockSeq> <data…> until the whole image is sent. The block sequence counter wraps 01→FF→00→01…
10. Exit transfer. 37 — "I'm done sending."
11. Check programming dependencies. 31 01 FF 01 — routine 0xFF01, checkProgrammingDependencies. The ECU verifies the new image's CRC/signature.
12. ECU reset. 11 01 — hardReset. The ECU reboots into the new application.
13. Re-enable everything. 85 01 to allow DTCs again, 28 00 01 to re-enable communication.

§ XITools, files & field notes

The file formats you'll meet

• CDD (CANdela Diagnostic Description) — Vector's authoring format. What most OEMs hand to suppliers. Defines DIDs, DTCs, services, sessions, security levels for a given ECU.
• ODX / PDX — ASAM open standard. ODX-D for diagnostics, ODX-F for flash. PDX is just a zipped package of ODX files. Used by the tester at the dealer.
• OTX — ISO 13209 sequence/test language. Describes diagnostic sequences (e.g. an end-of-line test, a guided fault tree).
• A2L — measurement & calibration metadata. Not strictly UDS, but you'll see it next to it in any ECU's deliverables (used by XCP/CCP and Vector CANape, ETAS INCA).

The benches you'll see

• Vector CANoe / CANalyzer — the workhorse. With the Diagnostic Feature Set + a CDD, you have a UDS tester.
• ETAS INCA — calibration-focused but speaks UDS.
• VCI hardware: Vector VN1640/VN5640, Intrepid neoVI, ETAS ES59x, PEAK PCAN, plus J2534 pass-thru devices for compliance with US EPA OBD regulations.
• Open source: python-udsoncan, can-isotp, scapy-automotive, CaringCaribou — perfectly capable for prototyping and fuzzing.

EV field notes

• HV interlock matters. Many EV diagnostic services that look ordinary (e.g. running an inverter self-test routine) will be NRC'd with 0x22 (conditions not correct) unless the HV system is in a permitted state — typically HV+ contactor open, vehicle stationary, ignition in a specific mode. The CDD will list these as preconditions per service.
• Phantom DTCs at boot. During power-on, the BMS may report communication-lost DTCs against the inverter for the few hundred milliseconds before all ECUs have completed their wakeup. Modern stacks suppress these via the "operation cycle" concept (ISO 14229-1 §10.2), but legacy stacks didn't, and the result was customer-facing fault counts that were really just startup race conditions. Always check that an active DTC has its confirmedDTC bit (bit 3) set before treating it as real.
• Snapshot data is sacred. For an EV, a useful snapshot includes: vehicle speed, motor electrical speed (ωₑ), id/iq commands and measurements, DC-link voltage, inverter and motor temperatures, pack SOC, contactor states. If you're spec'ing a new DTC, ask: could a field engineer reconstruct the failure from this freeze frame? If not, expand the snapshot.
• Aging counters lie if you let them. A DTC's "aging counter" decrements every driving cycle the fault doesn't recur, eventually clearing the DTC automatically. For an EV, the relevant cycle isn't "engine start" — it's "key-on with HV up", or sometimes "complete charge session". Pick the wrong cycle definition in the CDD and DTCs will either never age out or age out after one trip to the grocery store.
• UDS over DoIP at the workshop. If the vehicle is Ethernet-zonal, the tester is talking UDS over DoIP over Activation Line over BroadR-Reach. The application payload is identical; what changes is that the gateway routes the message to the right zonal controller using the logical address in the DoIP header. Each ECU still has an address; it's just no longer a CAN ID.

§ XIIReferences & further reading