Part 8: Higher-Layer Protocols: CANopen, J1939, and UDS

Understanding Structured Data and Application-Layer Standards on CAN Bus

As we’ve seen throughout this series, a CAN frame is intentionally simple: 11 or 29 bits of identifier, data  payload. This minimalism makes CAN fast, deterministic, and flexible—but it also means that different industries needed ways to define what those bytes represent.

This is where higher-layer protocols come in. They standardize data structures, communication flows, and device behaviors on top of the basic CAN transport. Whether you're working on heavy-duty vehicles, industrial automation, robotics, or medical equipment, chances are you're interacting with one of these application-layer standards.

In this post, we’ll explore three of the most widely used: CANopen, SAE J1939, and UDS (Unified Diagnostic Services)—what they solve, how they structure data, and where you’re likely to encounter them.

CANopen: Modular Control for Industrial and Robotics Systems

Originally defined by CAN in Automation (CiA), CANopen is popular in automation, robotics, and medical devices where multiple intelligent nodes must coordinate.

Why CANopen Exists

CANopen provides:

• A standardized Object Dictionary for device parameters

• Real-time messaging for control loops

• A predictable set of device behaviors (profiles for drives, sensors, I/O modules)

Key Concepts

• PDOs (Process Data Objects)

  Real-time data messages—position, velocity, force, sensor values—sent without request.

• SDOs (Service Data Objects)

  Request/response messages for configuration and parameter access.

• NMT (Network Management)

  Controlling device states (pre-operational, operational, reset).

Typical Use Cases

• Servo drives in robotics

• Infusion pumps and imaging systems

• Modular I/O in factories

How Tools Like CANLab Fit In

Even without a full protocol stack, being able to capture traffic, decode identifiers, and interpret payloads using dictionaries or EDS files helps engineers inspect PDOs and monitor device interactions.

SAE J1939: Structured Messaging for Heavy-Duty Vehicles

J1939 is built around 29-bit identifiers and a standardized way of grouping signals. It’s the backbone of communication in agriculture, trucking, construction, and marine applications.

Why J1939 Exists

Heavy-duty environments must ensure that ECUs from multiple vendors can cooperate—engine, transmission, brakes, telematics, hydraulic controllers, etc.

Key Concepts 

• PGNs (Parameter Group Numbers)

  Message “types” defined by the identifier.

• SPNs (Suspect Parameter Numbers) Named, scaled signals within a PGN—engine speed, fuel rate, boost pressure.

This structured approach means engineers can decode data consistently as long as they know the PGN and SPN definitions.

Typical Use Cases

• Engine and emissions monitoring

• Tractor implement communication

• Fleet telematics and diagnostics

• Hydraulic equipment control

How Tools Like CANLab Fit In

Tools can decode PGNs or SPNs from raw CAN frames when given the definitions, making it easier to validate equipment behavior or inspect network traffic during testing.

UDS (Unified Diagnostic Services): The Standard Diagnostic Protocol

UDS (ISO 14229) is the diagnostic framework used in modern passenger cars, many commercial vehicles, and increasingly in specialized equipment.

Why UDS Exists

Manufacturers needed a unified system to:

• Read diagnostic trouble codes (DTCs)

• Request data

• Perform ECU programming

• Control routines and tests

Key Concepts

• Service IDs (SIDs)

  Each UDS operation corresponds to a numeric command (e.g., 0x22 for Read Data By Identifier).

• DIDs (Data Identifiers)

  Structured identifiers for parameters—VIN, temperature sensors, calibration values.

• Security Levels

  Seed/key mechanisms for unlocking sensitive functions.

Typical Use Cases

• Dealer-level diagnostics

• Field service for specialized machinery

• ECU flashing and reprogramming

• Advanced testing and validation

How Tools Like CANLab Fit In

Even without UDS automation, engineers can observe and analyze diagnostic exchanges directly on the CAN network, which is valuable during integration and troubleshooting. While UDS has a well-defined command/response structure, the in-vehicle implementation can be very OEM specific. The integrated scripting available in CANLab can be used to create custom UDS command sequences.

Where These Protocols Are Use

Heavy-Duty & Off-Highway

• J1939 for engine, transmission, and vehicle systems

• UDS for diagnostics and firmware updates

• CANopen for implement controls (ISO 11783 based on J1939/CANopen concepts)

Medical Devices

• CANopen in pumps, imaging, patient monitoring

• UDS occasionally for maintenance diagnostics

• Emphasis on deterministic control and safe parameter access

Robotics & Automation

• CANopen for drives and real-time control

• Custom higher-layer protocols for proprietary robots

• UDS in some robotic platforms for service diagnostic

Conclusion: Higher-Layer Protocols Bring Meaning to CAN

Higher-layer protocols such as CANopen, J1939, and UDS give structure and meaning to raw CAN traffic, enabling interoperability across industries from heavy-duty vehicles to robotics and medical systems. Understanding how these protocols package data; whether through PGNs, SPNs, PDOs, or diagnostic services, helps engineers work more confidently across diverse applications.

In our next article, we’ll shift focus from protocols to practice by exploring how engineers choose the right CAN tools as they move from hobby-level experimentation to professional workflows.