CAN Bus Protocols Explained: Raw CAN, UDS, OBD-II, J1939, CANopen, NMEA 2000, and More

A CAN interface on a controller does not tell you which messages it should send. CAN defines how nodes arbitrate for the bus, frame data, detect errors, and recover from faults. The meaning of those data bytes comes from a higher-layer protocol, an application’s message specification, or both.

That distinction explains why a CAN trace can look like a list of hexadecimal identifiers and bytes while still being impossible to interpret without the correct protocol and configuration.

This guide shows how the main CAN-based protocols fit together, where each is used, and how to choose one for a product. Examples are illustrative: identifiers, scaling, addresses, and payloads must be checked against the relevant specification and device documentation before being used on equipment.

1. CAN in One Minute: Layers and Vocabulary

A CAN network needs compatible physical wiring and bit timing, but its nodes also need to agree on how messages are identified and interpreted. A useful simplified stack is:

Application meaning:     vehicle speed, engine temperature, command, diagnostic result
Application protocol:    UDS, J1939, CANopen, NMEA 2000, proprietary message map
Transport/network:       ISO-TP, J1939 transport protocol, CANopen SDO segmentation
Data link:               Classical CAN or CAN FD frame, arbitration, CRC, ACK, error handling
Physical layer:          transceiver, twisted pair, termination, voltage levels, wiring topology

CAN uses message identifiers, not destination addresses in the usual Ethernet sense. Nodes listen to frames and decide locally whether an identifier matters to them. The identifier also determines arbitration priority: a lower numerical identifier wins arbitration over a higher one when nodes start transmitting together.

A CAN identifier is not automatically a command or a device address. Its meaning depends on the protocol. Some protocols define the identifier as a priority plus source/destination or parameter-group information; others assign each identifier to a fixed data signal.

Classical CAN and CAN FD

Classical CAN carries up to 8 data bytes in a frame. CAN FD supports up to 64 data bytes and can optionally switch to a faster bit rate for the data phase. Both keep CAN-style arbitration, but the controller, transceiver, network design, and every participating node must support the selected mode. CAN FD is not simply a longer payload that can be sent onto any legacy CAN bus.

Frame notation used below

Examples use ID / DLC / DATA, where ID is shown in hexadecimal and DLC is the number of data bytes. Unless marked otherwise, examples use standard 11-bit identifiers and Classical CAN. Extended 29-bit identifiers are common in J1939 and NMEA 2000. Real systems also depend on bit rate, byte order, scaling, addressing, and configuration.

2. Raw CAN: The Frame Layer, Not a Complete Application Protocol

“Raw CAN” usually means an application sends or receives CAN frames directly, using an agreed message map. The CAN controller handles frame transmission and error management; application software defines what each identifier and payload means.

A small equipment controller might document:

For instance, a hypothetical frame 0x180 / 3 / E8 03 01 could mean a speed command of 1000 RPM and enable set to 1 if the project defines bytes 0–1 as unsigned little-endian RPM. CAN itself does not supply that interpretation.

Where and why raw CAN is used

Raw CAN is common in compact, controlled systems where one team owns the nodes and can maintain a clear message database: a robot, test rig, battery monitor, appliance, or custom machine. It avoids the implementation overhead of a larger standardized stack and can be highly efficient for periodic control and status data.

Pros and cons

A mature raw-CAN design usually specifies signal units, signedness, byte order, valid ranges, update rate, timeout behavior, startup state, rolling counters, and checksum strategy. A spreadsheet or DBC file can help describe signals, but it is not itself a wire protocol.

3. ISO-TP: Sending Larger Messages over CAN

ISO-TP (ISO 15765-2) is a transport protocol that carries payloads larger than a single CAN frame. It is widely used for automotive diagnostics. It defines such mechanisms as single frames, first frames, consecutive frames, and flow-control frames.

Here is a simplified Classical CAN example for a tester asking for a diagnostic response. The service bytes shown are UDS payload bytes; the first byte in each CAN data field is ISO-TP framing:

Tester -> ECU:  0x7E0 / 8 / 03 22 F1 90 00 00 00 00
ECU -> Tester:  0x7E8 / 8 / 10 0A 62 F1 90 31 32 33
ECU -> Tester:  0x7E8 / 8 / 21 34 35 36 37 00 00 00

The first request is a single-frame transport packet (03 says three payload bytes follow): UDS 22 F1 90, commonly a request to read a data identifier. The response begins with first-frame PCI 10 0A: the full UDS response is 10 bytes long. The ECU then sends consecutive frames (21 sequence number 1, then 22, and so on). This abbreviated illustration omits any additional consecutive frames needed to complete a 10-byte payload; actual segmentation must match the exact payload length. In practice a flow-control frame from the receiver regulates how quickly the sender continues.

For clarity, the displayed response above is only a partial illustration and is not a complete valid transfer: it shows two response fragments to demonstrate framing. A real 10-byte payload requires the receiver to collect enough consecutive-frame data bytes after the first frame to reach the declared total length.

When to use ISO-TP

Use ISO-TP when an application protocol, typically UDS, needs messages that exceed one CAN frame or requires standardized diagnostic transport. It does not define diagnostic services, signal meanings, or ECU behavior by itself. It is a transport layer, not a complete vehicle protocol.

4. UDS: Unified Diagnostic Services

UDS (ISO 14229) is a diagnostic application protocol used to communicate with electronic control units (ECUs). It commonly runs over ISO-TP on CAN, although UDS can also use other transports. UDS defines services such as reading data, clearing diagnostic trouble codes, running routines, and downloading software. OEMs define many data identifiers, routines, and access rules for a specific vehicle or ECU.

Common UDS service identifiers include:

A positive response generally sets the service identifier’s high bit. For example, a 22 request may receive 62 plus the requested DID and its value. A negative response uses 7F, the original service, and a negative-response code, for example 7F 22 31 (“request out of range”). Exact response behavior depends on the service and ECU.

Practical use case: service a vehicle ECU

A workshop tool identifies an ECU, requests stored fault information, reads live or stored data, and may run an authorized test routine. At a factory, a programming tool may enter a programming session, authenticate, erase or prepare memory, transfer software blocks, and verify completion. These actions are often restricted by security access, vehicle state, and OEM procedures.

Pros and cons

UDS is not the same as OBD-II. OBD-II standardizes a set of emissions-related diagnostic functions and connector/access expectations in applicable markets. UDS is a broader diagnostic protocol with many vehicle- and manufacturer-specific services.

5. OBD-II over CAN: Standard Emissions Diagnostics

OBD-II is the familiar name for legislated on-board diagnostics in applicable vehicle markets. CAN is one of its supported physical/data-link choices; ISO 15765-4 specifies CAN-related requirements for OBD communications. OBD-II defines standardized emissions-related modes and parameter identifiers (PIDs), along with trouble-code access. Not every PID is supported by every vehicle.

A common 11-bit CAN example requests engine coolant temperature (PID 05) using OBD service/mode 01:

Tester -> vehicle: 0x7DF / 8 / 02 01 05 00 00 00 00 00
Vehicle -> tester: 0x7E8 / 8 / 03 41 05 7B 00 00 00 00

0x7DF is commonly used as a functional request identifier, while 0x7E8 is a typical ECU response identifier in this addressing scheme. In the reply, 41 is the positive response for mode 01, 05 is the PID, and 7B is the returned byte. The standard conversion for coolant temperature is A - 40, so 0x7B (123) represents 83 °C. These IDs and payloads illustrate a common scheme; vehicles and supported transports can differ.

Where, when, and why

OBD-II is useful for a generic scan tool, emissions inspection, basic fleet data collection, or a consumer adapter that needs standardized data across many vehicles. It is deliberately less vehicle-specific than full UDS access. For proprietary body, chassis, battery, or programming information, an OEM diagnostic definition or authorized UDS workflow may be required.

Pros and cons

6. SAE J1939: Heavy-Duty Vehicle and Equipment Networks

J1939 is a higher-layer protocol family used in many heavy-duty vehicles, engines, agricultural machines, construction equipment, and other mobile machinery. It commonly uses 29-bit extended CAN identifiers and defines parameter groups (PGs), source addresses, priority, transport, network management, and diagnostic conventions.

A J1939 29-bit identifier is structured from fields including priority, data page, PDU format, PDU specific, and source address. The interpretation of the PDU-specific field differs between PDU1 and PDU2 formats: it can represent a destination address in PDU1 or contribute to the parameter-group number in PDU2. The data bytes are then interpreted according to the parameter group’s definition.

A commonly cited engine-speed parameter is SPN 190 in PGN 61444 (EEC1). In the standard definition, engine speed uses bytes 4–5 with a 0.125 rpm/bit resolution and zero offset. The precise on-wire identifier is derived from priority, PGN, and source address, so the source address and priority determine the full 29-bit CAN ID. Do not copy an ID from a trace without decoding its fields.

For an illustration, if the engine-speed raw value were 0x1F40 (8000 decimal), the decoded value would be 1000 rpm at 0.125 rpm/bit. Byte order and the parameter group’s defined byte positions matter; verify the current applicable J1939 definition before implementation.

J1939 diagnostic messages include DM1 for active diagnostic trouble codes and DM2 for previously active codes. Some PGs fit in one CAN frame; larger messages use J1939 transport mechanisms.

Practical use case: fleet engine monitoring

A telematics gateway listens to engine and vehicle parameter groups, decodes speed, coolant temperature, fuel use, and fault information, and forwards selected data to a fleet platform. A service tool can also request parameter groups or diagnostics. The gateway must respect bus loading, manufacturer configuration, addressing rules, and vehicle privacy/security requirements.

Pros and cons

7. CANopen: Industrial Control with Objects and Profiles

CANopen is an application-layer protocol based on CAN, standardized in the CiA 301 communication profile. It is common in industrial automation, motion control, medical equipment, and embedded machinery. Devices expose an object dictionary: a structured set of configuration and process values addressed by index and sub-index.

CANopen communication includes:

• Process Data Objects (PDOs) for low-overhead cyclic or event-driven process data.
• Service Data Objects (SDOs) for configuration and less time-critical object access.
• Network management (NMT) for node states and control.
• Heartbeat or node-guarding mechanisms for node monitoring.
• Device and application profiles such as CiA 402 for drives.

A default CANopen node with node ID 0x05 commonly uses SDO client-to-server COB-ID 0x605 and server-to-client COB-ID 0x585. A simplified expedited SDO read request for object 0x6041, sub-index 0, can look like:

0x605 / 8 / 40 41 60 00 00 00 00 00

The index bytes appear low byte first (41 60), as CANopen defines for this SDO encoding. A real response depends on the object, node state, and device profile. PDO identifiers and mappings can be configured, so a generic trace decoder needs the device configuration or electronic data sheet (EDS).

Practical use case: configure and run a servo drive

An engineering tool uses SDOs to set drive parameters, then maps fast-changing target and feedback values into PDOs for cyclic exchange. NMT starts the node, and heartbeat monitoring lets the controller detect a disconnected or failed drive.

Pros and cons

8. DeviceNet: Industrial I/O and Device Networking

DeviceNet is an industrial network built on CAN, historically associated with Rockwell Automation and ODVA. It defines more than application data: physical-layer choices, connector and power conventions, device identity, connection services, and I/O messaging. It is found in installed factory automation systems connecting controllers to sensors, actuators, motor starters, and other devices.

A scanner typically establishes connections with devices and exchanges I/O data according to the configured connection and assembly definitions. Explicit messaging is used for configuration and less time-critical access. A raw frame dump alone is often insufficient to decode a DeviceNet exchange because connection state and device profiles provide context.

Pros and cons

Choose DeviceNet when it is required by an existing plant architecture, controller, or installed device base. For a new product, compare current support, lifecycle, interoperability, and maintenance needs before selecting it.

9. NMEA 2000: Marine Electronics Networking

NMEA 2000 is a marine electronics network based on CAN, with standardized messaging, network management, device addressing, and marine-specific installation rules. It is used to connect equipment such as GPS receivers, chartplotters, engine displays, depth sounders, heading sensors, and autopilots.

NMEA 2000 uses 29-bit CAN identifiers. The identifier encodes priority, a parameter group number (PGN), and source/destination-related information. The payload is interpreted using the PGN definition. A device generally announces itself and claims an address; multiple devices may produce the same type of data under different source addresses.

For example, a chartplotter may consume a position-related PGN from a GPS receiver and an engine-parameter PGN from an engine gateway. The identifier alone is not the whole message: the PGN’s field definitions, data validity indicators, units, and the source device identity are needed to decode it correctly.

Practical use case: integrated boat display

A display subscribes to position, heading, depth, wind, and engine data and presents them together. A gateway may translate selected information to another marine network or log it. Marine backbone power, drop lengths, termination, connectors, and device compatibility must follow the applicable NMEA 2000 installation guidance; CAN wiring should not be improvised from automotive assumptions.

Pros and cons

10. Other Relevant CAN-Based Approaches

Proprietary CAN application protocols

Many products use CAN with a private message specification rather than a public higher-layer standard. This is a reasonable choice when one organization controls every node, the product needs a small and carefully timed message set, or an established OEM network already exists. Treat the message database, versioning, diagnostic strategy, and access control as product-critical documentation.

CAN FD

CAN FD changes the data-link frame capacity and can increase throughput, while leaving application meaning to protocols such as a product-specific message map or a supported higher-layer profile. It is useful for new designs that need more data per frame, faster diagnostics, or reduced segmentation overhead. Validate ECU/controller/transceiver support, bit timing, network topology, and interoperability with every node; Classical CAN nodes generally cannot participate transparently on a CAN FD network.

TTCAN

Time-Triggered CAN (ISO 11898-4) adds time-triggered scheduling concepts to CAN, supporting more predictable communication windows in suitable systems. It is used where a coordinated schedule and bounded timing are important, but requires compatible controllers and careful system design. It does not replace application-level definitions of payload meaning.

Safety-related CAN profiles

Protocols such as CANopen Safety and other safety communication profiles add safety mechanisms at a higher layer, such as end-to-end checks, sequence information, and defined safety state behavior. They do not make an ordinary CAN network “safety-rated” by themselves. The full system, components, development process, and applicable safety standard must be assessed for the intended application.

CAN-based battery and energy systems

Battery management systems, chargers, and inverters often exchange data over CAN using manufacturer-defined maps or ecosystem-specific profiles. A message might carry pack voltage, current, state of charge, contactor state, or a fault code. Never infer units or sign conventions from the bytes alone; verify the vendor protocol and ensure commands are appropriately authorized and bounded.

11. How These Protocols Fit Together

The layers can be combined. A diagnostic request can use UDS as the application protocol, ISO-TP as the transport, CAN as the data link, and a CAN transceiver plus twisted-pair wiring at the physical layer. By contrast, many J1939 parameters fit directly into a single CAN frame and use J1939’s own identifier and transport conventions.

12. Practical Design and Troubleshooting Checklist

Before connecting or decoding a CAN network, confirm:

1. Physical layer: transceiver type, wiring, grounding strategy, connector, topology, and termination. A conventional high-speed CAN bus commonly has termination at both physical ends; verify the applicable network specification.
2. Bit timing: nominal bitrate and, for CAN FD, data-phase bitrate and sample-point configuration.
3. Identifier format: 11-bit or 29-bit identifiers, and whether identifiers have protocol-defined fields.
4. Protocol and version: raw message database, ISO-TP addressing mode, UDS profile, J1939 edition, CANopen device profile, or NMEA 2000 guidance as applicable.
5. Signal decoding: byte order, bit position, signedness, scale, offset, units, invalid values, and update rate.
6. Transport behavior: segmentation, flow control, timeouts, block size, and separation time where applicable.
7. Network management: node IDs, source addresses, address claiming, startup order, heartbeat, or device discovery.
8. Fault behavior: bus-off recovery, missing-message timeout, stale data handling, counter/checksum validation, and safe output state.
9. Bus load and priority: worst-case traffic, arbitration delays, periodic bursts, and diagnostic traffic under peak load.
10. Security and safety: who can send commands, how privileged diagnostics are protected, and what safe state the system enters after faults.
11. Interoperability: test against real target devices and protocol conformance requirements; a plausible trace is not proof of compatibility.
12. Documentation: keep the DBC/EDS/device configuration, protocol revision, test traces, and decoding assumptions under version control.

For initial debugging, check termination and bit rate first, then confirm that the controller sees valid frames and acknowledges are present. Next inspect identifiers and payloads with the correct protocol decoder. A CAN analyzer showing no error frames does not prove that the application-layer data is valid.

13. Common Mistakes and Misconceptions

“CAN is the protocol.”

CAN is the data-link technology and part of the physical communication system. The application protocol determines what messages mean and how nodes behave.

“The CAN ID is the destination.”

Usually it is an arbitration identifier and message label. Some higher-layer protocols encode source or destination information within identifier fields, but that is protocol-specific.

“UDS and OBD-II are interchangeable.”

They overlap in diagnostic use but have different scope. OBD-II standardizes emissions-related access; UDS supplies a broader diagnostic service framework, often with OEM-specific definitions and security policies.

“ISO-TP defines diagnostic commands.”

ISO-TP transports payloads across CAN frames. UDS or another application protocol defines the commands and their meaning.

“A CAN trace can be decoded from hex alone.”

A decoder needs the correct identifier format, protocol, message definitions, byte order, scaling, and often network state or configuration.

“Any CAN node can join any CAN bus.”

Nodes must agree on physical layer, bit timing, frame format, and protocol behavior. CAN FD, DeviceNet, marine networks, and vehicle networks can impose additional compatibility and installation requirements.

14. FAQ: Quick Answers Engineers Ask

Which CAN protocol should I use for a new embedded product?

Use the standard already required by your ecosystem or customer. For a small closed network, a carefully specified raw-CAN message map may be sufficient. For industrial drives, marine systems, heavy-duty vehicles, or automotive diagnostics, choose the relevant established protocol and profile.

Is raw CAN faster than CANopen or J1939?

Raw CAN has less protocol overhead in some designs, but practical performance depends on frame rates, identifier priorities, transport, and implementation. Standardized protocols can reduce integration cost and mistakes even if they add some overhead.

Can UDS run on CAN FD?

Yes, when the diagnostic stack, ECU, tester, and transport configuration support the applicable UDS transport over CAN FD. Confirm the exact standard/profile and addressing setup; do not assume a Classical CAN configuration will work unchanged.

Can I use a generic OBD-II adapter to program an ECU?

A generic adapter may support basic OBD-II access, but ECU programming usually requires manufacturer-specific procedures, suitable hardware/software, security access, and strict power and vehicle-state controls. Follow the vehicle maker’s authorized process.

What is the difference between CANopen and DeviceNet?

Both use CAN, but they define different application and network services, configuration models, and ecosystems. CANopen centers on an object dictionary and PDO/SDO communication; DeviceNet includes industrial device identity, connection behavior, and I/O messaging. They are not wire-compatible application protocols.

Does NMEA 2000 use ordinary CAN messages?

It uses CAN framing underneath, but a compliant NMEA 2000 network also follows marine-specific PGN, addressing, device, physical installation, and interoperability rules. Treating it as arbitrary raw CAN can cause decoding or installation problems.

What is the best way to decode an unknown CAN bus?

First identify the equipment, transceiver/bit rate, identifier format, and likely standard. Capture traffic passively with suitable isolated equipment, look for documented PGNs or message databases, and verify hypotheses against known signals and controlled changes. Do not inject guessed commands into a live control network.

15. Conclusion: Choose the Protocol That Matches the Job

CAN gives embedded systems a robust, prioritized way to exchange frames. It does not decide whether a payload represents wheel speed, a diagnostic request, engine load, a drive parameter, or boat position. Higher-layer protocols provide that shared meaning and behavior.

Use raw CAN for a controlled network with a well-maintained message definition. Use OBD-II for standardized emissions diagnostics, UDS for richer ECU diagnostics, and ISO-TP when larger diagnostic payloads need transport. Use J1939 for many heavy-duty vehicle and mobile-equipment networks, CANopen for industrial control and drives, DeviceNet for compatible installed factory systems, and NMEA 2000 for marine electronics. Consider CAN FD when a new system needs larger payloads and all components support it.

The best choice is the one that meets the product’s interoperability, timing, safety, security, lifecycle, and maintenance requirements—and that your team can implement and validate correctly.

Final Checklist: Planning a CAN Network

• Identify whether the requirement is raw messaging, diagnostics, industrial control, heavy-duty vehicle data, or marine networking.
• Select the required application protocol and revision before assigning identifiers.
• Confirm physical layer, bitrate, topology, termination, and connector requirements.
• Define payload layouts, units, scaling, byte order, validity rules, and timeouts.
• Plan transport and segmentation for payloads larger than one CAN frame.
• Define startup, addressing, heartbeat, fault recovery, and safe-state behavior.
• Calculate bus load and arbitration delays for worst-case traffic.
• Restrict privileged commands and validate safety and security requirements.
• Test interoperability with actual target devices and preserve representative traces.
• Version-control protocol definitions and decoding tools alongside firmware.