Understanding Structured Data and Application-Layer Standards on CAN Bus
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
- 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
- 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.
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
- 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 Used
- J1939 for engine, transmission, and vehicle systems
- UDS for diagnostics and firmware updates
- CANopen for implement controls (ISO 11783 based on J1939/CANopen concepts)
- CANopen in pumps, imaging, patient monitoring
- UDS occasionally for maintenance diagnostics
- Emphasis on deterministic control and safe parameter access
- CANopen for drives and real-time control
- Custom higher-layer protocols for proprietary robots
- UDS in some robotic platforms for service diagnostics


