If you’ve ever plugged a scan tool into a car and pulled live data or fault codes using a CAN-based protocol, you’ve likely used ISO 15765-4—the standard that defines how OBD-II diagnostics ride over the CAN bus. It specifies exactly how diagnostic requests and responses are framed, segmented, and reassembled so your tool and the vehicle’s ECUs can “speak the same language.”
Where It Fits in the Automotive Standards Stack
Think of the stack like layers of a sandwich:
- Physical/Data Link: CAN (ISO 11898) sets wiring and basic frame rules.
- Transport/Network: ISO-TP (ISO 15765-2) chops big payloads into frames and reassembles them.
- Application: OBD-II services (Modes/PIDs) or UDS (ISO 14229) define what the messages mean.
ISO 15765-4 sits across transport and application conventions specifically for OBD-II on CAN.
Why “-4” Matters
The “-4” indicates the OBD-II profile of ISO 15765. It standardizes message IDs, timing, and allowable bitrates for light-duty vehicles so generic tools can reliably read PIDs and DTCs across manufacturers.
Core Concepts You Must Know
CAN Bus Basics (11-bit vs 29-bit, 250/500 kbps)
- Identifier length: Many OBD-II CAN implementations use 11-bit IDs, but 29-bit (extended) is also common.
- Bitrates: Typical speeds are 500 kbps (fast) or 250 kbps (slower, often in heavier networks).
- Arbitration: Lower ID value = higher priority on the bus.
Functional vs Physical Addressing
- Functional (broadcast) requests target a type of ECU (e.g., any powertrain ECU that supports OBD), not a specific module.
- Physical requests target a specific ECU address. Some operations (like clearing codes) are often done via physical addressing.
Single vs Multi-Frame Messages (TP/ISO-TP)
- Single Frame (SF): Entire payload fits in one CAN frame (up to 7 bytes of data for classic ISO-TP).
- First Frame (FF) + Consecutive Frames (CF): Used when the payload is bigger; receiver sends Flow Control (FC) to manage pacing.
Supported Protocol Variants (The “Codes”)
People casually refer to “ISO 15765-4 codes” to mean the four common OBD-II CAN profiles:
- ISO 15765-4 (CAN 11/500) → 11-bit IDs, 500 kbps. Very common on modern light vehicles.
- ISO 15765-4 (CAN 29/500) → 29-bit IDs, 500 kbps. Used by many manufacturers.
- ISO 15765-4 (CAN 11/250) → 11-bit IDs, 250 kbps. Less common for OBD-II.
- ISO 15765-4 (CAN 29/250) → 29-bit IDs, 250 kbps. Often in networks where 250 kbps is standard.
How ISO-TP (Transport Layer) Works
Frame Types: SF, FF, CF, and FC
- SF (Single Frame): 0x0 nibble prefix; carries small payloads.
- FF (First Frame): 0x1 prefix; includes total length; kicks off a multi-frame sequence.
- CF (Consecutive Frame): 0x2 prefix; sequence number increments from 1–15, then wraps.
- FC (Flow Control): 0x3 prefix; receiver tells sender to Continue (CTS), Wait, or Overflow.
Key Timing Parameters (STmin, BS)
- STmin: Minimum separation time between CFs (how fast sender may stream frames).
- BS (Block Size): How many CFs may be sent before the sender must pause for the next FC.
OBD-II Modes Used with ISO 15765-4
- Mode 01: Current Powertrain Data (PIDs)
- Mode 02: Freeze Frame
- Mode 03: Stored DTCs
- Mode 04: Clear DTCs
- Mode 09: Vehicle Info (VIN, Calibration IDs)
UDS vs OBD-II on CAN (Quick Compare)
UDS is more comprehensive than OBD-II, used for advanced functions like flashing, security access, and proprietary data. OBD-II handles emissions-mandated diagnostics.
Message IDs and Addressing on OBD-II CAN
Functional request: Sent to a broadcast ID, any ECU replies. Physical request: Sent to a specific ECU, single response.
Real-World Examples (Hex Frames)
// Requesting Engine RPM (Mode 01 PID 0C)
Request payload: 01 0C
Typical positive response: 41 0C A B
RPM = ((A*256)+B)/4
// Reading DTCs (Mode 03)
Request payload: 03
Response example: 43 01 33 00 00 ...
// Pulling VIN (Mode 09 PID 02)
Request payload: 09 02
Response (multi-frame): 49 02 + VIN bytes across frames
Setting Up Your Tools (ELM327, J2534, USB-CAN)
ELM327 AT Commands for ISO 15765-4:
- ATZ — Reset the interface
- ATE0 — Echo off
- ATL0 — Linefeeds off (optional)
- ATS0 — Printing spaces off/on
- ATH1 — Headers on
- ATSP6 — Set protocol to ISO 15765-4 (CAN 11/500)
Troubleshooting and Common Pitfalls
- No Response / Timeouts → Wrong protocol, incorrect bitrate, poor connector, using functional instead of physical.
- Multi-Frame Assembly Errors → STmin/BS ignored, dropped frames, bus saturation.
- Incorrect Bitrate or ID Width → Garbage IDs, no valid Mode/PID, checksum errors.
Safety, Legal, and Warranty Notes
- Reading PIDs, VINs, DTCs is generally safe.
- Writing (clearing DTCs, coding, flashing) can affect readiness monitors; use caution.
- After Mode 04 clear, complete a proper drive cycle before emissions test.
Best Practices for Developers and Tinkerers
- Log raw frames, decoded data, timestamp everything.
- Record vehicle state to correlate responses.
- Maintain a reference of Modes/PIDs, expected units, and known exceptions.
Conclusion
ISO 15765-4 is the backbone of modern OBD-II diagnostics over CAN, defining how scan tools and ECUs exchange data reliably. Understand the four profile variants (11/29-bit × 250/500 kbps), ISO-TP segmentation, and key OBD-II Modes. With proper addressing, IDs, and timing, you can safely read live data, fetch DTCs, and pull VINs—whether using an ELM327 or integrating J2534.
Table of Contents