Skip to content

Protocol Layers (OSI Model)

The studio speaks three protocol families over the same pair of wires: plain CAN, CANopen and OBD-II. They are not alternatives to one another. They share the bottom two layers entirely and differ only in what they put on top — which is why one adapter, one capture and one decoder stack can serve all three.

This page maps each of them onto the OSI reference model, and names the standard that governs every box.

The two stacks side by side

CAN, CANopen and OBD-II in the OSI model OSI model CANopen stack industrial automation, CiA 301 OBD-II over CAN stack vehicle diagnostics, ISO 15765-4 7 · Application 6 · Presentation 5 · Session 4 · Transport 3 · Network 2 · Data link 1 · Physical CiA 301: CANopen application layer Object dictionary, NMT, SDO, PDO, SYNC, EMCY Profiles: CiA 401 (I/O), CiA 402 (drives), ... Layers 3 to 6 not used The application sits directly on the CAN data link layer (SDO handles its own segmentation) SAE J1979 / ISO 15031-5: OBD services Services 01 to 0A, PIDs (RPM, speed, coolant temp...) Trouble codes (DTC): SAE J2012 / ISO 15031-6 Layers 5 and 6 not used ISO 15765-2 (ISO-TP) Segmentation: SF, FF, CF frames + FC flow control Messages up to 4095 bytes Normal (11-bit) or normal fixed (29-bit) addressing CAN · ISO 11898-1: classic CAN (2.0A 11-bit / 2.0B 29-bit) and CAN FD Non-destructive bit-wise arbitration (CSMA/CR), CRC, ACK acknowledgement, bit stuffing, error handling ISO 11898-2: high-speed CAN, CAN_H / CAN_L differential pair 120 Ω termination at each end of the bus CiA 303-1: connectors SUB-D9, M12, ... SUB-D9: CAN_L pin 2, CAN_H pin 7 Bit rate: 10 kbit/s to 1 Mbit/s SAE J1962: 16-pin OBD connector CAN_H pin 6, CAN_L pin 14 Bit rate: 250 or 500 kbit/s (ISO 15765-4) CAN identifiers CANopen: 11-bit COB-ID = function code (4 bits) + Node-ID (7 bits) e.g. NMT 0x000, TPDO1 0x180 + ID, SDO 0x600 / 0x580 + ID, Heartbeat 0x700 + ID OBD-II: functional request 0x7DF, ECU responses 0x7E8 to 0x7EF (29-bit: request 0x18DB33F1, responses 0x18DAF1xx)

Reading the diagram

The bottom two layers are common ground. A CANopen drive and a car's engine ECU put electrically indistinguishable frames on the wire. Everything the studio does below the application layer — capture, timestamping, the trace, the bit-level view, the PCAP-NG export — therefore works the same for both.

Layers 3 to 6 are mostly empty, and that is the interesting part. A classic CAN frame carries at most eight bytes and there is nowhere to put a longer message, so any protocol needing more has to invent its own segmentation: CANopen does it with segmented and block SDO transfers, OBD-II with ISO-TP. They solve the same problem in incompatible ways, which is why reading a VIN and reading an object dictionary entry share no code above the data link layer.

Layer 7 is where the two part company, and plain CAN has nothing there at all: outside a higher-layer protocol an identifier means whatever the designer decided, which is why the studio ships decoders for specific devices rather than a universal one.

CAN FD does not add a layer

CAN FD changes layers 1 and 2 only — a second bit rate for the data phase, payloads to 64 bytes, different CRCs. Everything above is unchanged, which is why a protocol written for classic CAN keeps working over it.

Where an adapter cuts the stack

Which layers the adapter implements, and which are left to the studio, decides what an adapter can be used for. This is the distinction behind the two diagnostic backends described in OBD-II Vehicle Diagnostics.

flowchart TB
    S["<b>Native CAN adapter</b><br/>SLCAN · PCAN · SocketCAN · UDP"]
    E["<b>ELM327 adapter</b>"]

    S7["<b>L7</b> · J1979 or CANopen<br/><i>in the studio</i>"]
    S34["<b>L3–4</b> · ISO-TP or SDO<br/><i>in the studio</i>"]
    S12["<b>L1–2</b> · CAN frames<br/><i>on the adapter</i>"]

    E7["<b>L7</b> · J1979<br/><i>in the studio</i>"]
    E14["<b>L1–4</b> · physical, framing,<br/>protocol autodetection, ISO-TP<br/><i>on the adapter, in its firmware</i>"]

    S --- S7 --- S34 --- S12
    E --- E7 --- E14

    classDef head fill:#0b7285,stroke:#0b7285,color:#fff
    classDef studio fill:#e3fafc,stroke:#0b7285
    classDef adapter fill:#f1f3f5,stroke:#868e96,color:#495057

    class S,E head
    class S7,S34,E7 studio
    class S12,E14 adapter

A native CAN adapter is transparent: it hands over raw frames and the studio owns everything from ISO-TP upwards. That is why the same adapter serves CANopen, OBD-II and the raw trace at once.

An ELM327 is not transparent. It runs protocol autodetection and ISO-TP inside its own firmware and answers in ASCII hexadecimal, so it can only ever be a diagnostic endpoint — never a source of raw frames for the trace, the plotter or the bridge. That is the reason DiagnosticInterface is a separate abstraction from the CAN adapter catalogue rather than another entry in it.

Standards referenced here

Standard Layer What it defines
ISO 11898-1 2 CAN data link layer; CAN FD since the 2015 edition
ISO 11898-2 1 High-speed CAN physical layer
ISO 11898-3 1 Low-speed, fault-tolerant CAN physical layer
ISO 15765-2 3–4 ISO-TP: segmentation and flow control over CAN
ISO 15765-4 1–2 Constrains CAN for road-vehicle diagnostics
ISO 15031-5 / SAE J1979 7 Emissions-related diagnostic services
ISO 14229 7 UDS, manufacturer diagnostic services
CiA 301 3–4, 7 CANopen application layer and communication profile
CiA 306 — EDS file format describing a device's object dictionary
CiA 402 7 CANopen device profile for drives and motion control

K-line and J1850 are out of scope

OBD-II predates CAN and permits other physical layers. The studio implements the CAN protocols of ISO 15765-4 only. A session that autodetects ISO 9141-2, ISO 14230-4 or J1850 reports which protocol it found and stops, rather than mis-parsing a differently framed reply.