The CAN (Controller Area Network) protocol defines how devices communicate using short messages, but it doesn't specify how to interpret those messages. That’s where higher-layer protocols (HLPs) come in. In this Q&A, based loosely on a Grid Connect webinar with emotas' Torsten Gedenk, we’re answering key questions about CANopen, J1939, and UDS (Unified Diagnostic Services), including deeper context, best practices, and tools for integrating CAN-based communication in industrial and heavy-duty environments.
PHYSICAL LAYER & BASICS
Q: CANbus is often shown as a 2-wire network. Is this strictly true?
A: Not strictly. CAN is often described as a 2-wire differential network (CAN_H and CAN_L), but it's important to note that a common ground is also essential. While CAN transceivers interpret the voltage difference between the two signal lines, standard receivers are not fully isolated and rely on a shared electrical reference to ensure accurate communication.
Q: How does CRC (Cyclic Redundancy Check) detect errors in CAN messages?
A: CRC error checking is handled entirely by the CAN controller hardware. When a message is sent, the transmitting node calculates a CRC value based on the message content and appends it to the frame. On the receiving end, the hardware does the same calculation and compares its result to the CRC value in the frame. If the values don’t match, the message is discarded and an error frame is generated. If they do match, the message is considered valid and passed on to the microcontroller. It all happens under the hood, so you won’t see it in the message data or software layer, but it’s a big part of what keeps CAN communication so reliable.
Q: Is the CRC check part of the 8 data bytes in a CAN message?
A: No, the CRC isn’t included in the 8 data bytes that carry your payload. It’s a separate field in the CAN frame, handled automatically by the hardware.
Q: Does the message identifier also identify the device to which the data is sent?
A: Not directly. In standard CAN, the identifier describes the message type or its content, not the destination device. CAN is a broadcast-based protocol, so every node on the network receives every message. It’s up to each node to decide whether to process the message based on the identifier. That’s why higher-layer protocols like CANopen and J1939 build in additional logic, like node IDs or source addresses, to give context and enable more targeted communication.
Q: Can CANopen and J1939 coexist on the same CAN bus?
A: They can, but you have to be a little cautious. You’ll need to make sure each protocol uses a different format for its CAN identifiers. Since J1939 uses 29-bit identifiers and CANopen typically uses 11-bit, there's less risk of overlap, which helps. But both need to be running at the same bitrate, and you'll want to watch your overall bus load. Keep it under 40% for safety, though if most of your traffic is cyclic and predictable, 80% can be manageable. It’s all about making sure the timing and traffic don’t collide.
Q: What’s the biggest concern when mixing protocols like CANopen and J1939 on the same bus?
A: The number one concern is message identifier collisions and how they affect arbitration. The fact that J1939 and CANopen use different identifiers by default is helpful because it means they occupy different parts of the identifier space. But you still need to make sure that IDs don’t unintentionally overlap if you're using extended IDs in CANopen or have manufacturer-specific messages. Also, if J1939 messages are prioritized too low compared to frequent CANopen PDOs (Process Data Objects), timing-sensitive J1939 messages might get delayed. Bus load and arbitration priority really matter in mixed-protocol setups.
b Quite a bit, actually. If your network is event-driven, meaning messages pop up unpredictably, then a heavy bus load can delay or even block important traffic. In that case, 40-50% load is your comfort zone. But if you’re running more regular, scheduled transmissions, you can push that closer to 80%. Still, it’s good practice to monitor traffic with tools like Emotas CANexplorer or CANAnalyser to get a real feel for your network health.
CANOPEN: OBJECT DICTIONARIES, SDOs & PDOs
Q: Is CANopen a differential protocol?
A: Not exactly - CANopen is a higher-layer protocol that operates on top of CAN. It defines how devices communicate and interpret data, but it doesn't deal directly with physical signaling. The underlying CAN protocol, which CANopen relies on for transmission, uses a differential signaling method across two wires. So, at the physical layer, yes, it’s differential, but that’s a property of CAN itself, not CANopen.
Q: Are all CANopen IDs 11-bit?
A: By default, yes. CANopen is designed around 11-bit identifiers, and that’s what most implementations use. But, the protocol can be configured to use 29-bit extended identifiers as well. That kind of setup is less common, and if you go that route, you’ll need to configure the communication services properly. CANopen still works just fine in the 11-bit space alone, and staying there ensures easier compatibility with most existing tools and devices.
Q: What is the CANopen Object Dictionary?
A: Think of it like a big catalog inside the device. Every setting, parameter, and signal you might want to interact with is listed in there. Each one has an address made up of an index and sub-index. Some are defined by the standard profiles (like CiA 418 for batteries), while others are totally up to the device manufacturer. If you want your system to be plug-and-play with other devices, sticking to the standard areas helps.
Q: What are SDO and PDO?
A: SDOs - Service Data Objects - are used when a tool or master wants to read or write something specific on a device, kind of like a command. It’s one-on-one and pretty flexible.
PDOs - Process Data Objects - are different. They’re faster and meant for broadcasting real-time values, like voltage or temperature, on a schedule or when something changes. Other devices can just listen in. It’s a publish-and-subscribe model that’s really efficient for control loops.
Q: What tools help develop or debug CANopen?
A: Emotas has a great one called DeviceExplorer. It’s easy to use and lets you work directly with the Object Dictionary. Peak’s PCAN-View is also pretty handy, and if you’re doing deep diagnostics or logging, Vector’s CANalyzer is powerful, though it’s on the pricier side.
J1939: VEHICLE-GRADE MESSAGING & ADDRESSES
Q: How are messages structured in J1939?
A: They’re built around a 29-bit identifier that includes a few things: priority, a parameter group number (PGN), and the source address. The PGN defines what kind of data you're looking at, and each one contains SPNs (Suspect Parameter Numbers) which are the actual signals. For example, engine coolant temp is SPN 110 inside PGN 61444. It’s very structured and predictable.
Q: What happens if two devices use the same address?
A: They work it out using something called the NAME field - a 64-bit unique identifier. When two devices want the same address, the one with the higher priority (lower value) gets to keep it, and the other one has to find a new address. It’s all part of J1939’s dynamic address-claiming process, and it works pretty well even in busy systems.
Q: Can J1939 send messages longer than 8 bytes?
A: It can, yes. There are two protocols for that. BAM (Broadcast Announce Message) is used when you just want to blast out a long message to everyone without worrying about confirmation. CMDT (Connection Mode Data Transfer) is for more careful, one-to-one messaging - you’ll receive acknowledgements back, so you know the message was received. That’s useful for things like calibration data or larger diagnostics.
Q: Why do trucks use J1939 instead of ISO 15765 (UDS on CAN)?
A: J1939 was designed from the ground up for commercial and heavy-duty vehicles. It provides a broadcast-friendly, highly structured communication system with predefined signals and flexible addressing, making it ideal for real-time coordination among many ECUs (Electronic Control Units).
ISO 15765-2, also known as ISO-TP (Transport Protocol), is only concerned with how to segment and reassemble large messages over CAN. It does not define what the data actually means - just how it's transported. That’s why ISO-TP is often used with UDS, where another layer handles the interpretation. In contrast, J1939 includes both the transport mechanism and the definition of the data content through PGNs (Parameter Group Numbers) and SPNs (Suspect Parameter Numbers).
So for operational communication across a vehicle's network, especially in trucks and buses, J1939 is a better fit, while ISO 15765-2 is more commonly used for diagnostic communication in passenger vehicles.
Q: If I have a list of PGNs / SPNs but cannot identify them, what source would you recommend?
A: The best place to start is the J1939 Digital Annex from SAE (Society of Automotive Engineers). It’s a searchable electronic reference of officially defined PGNs and SPNs, and it’s kept more up to date than printed standards like J1939-71. While it’s not free, it’s the most authoritative and complete source. If you’re just trying to explore or identify a few PGNs, some online tools or community forums may help, but for production-level work, the Digital Annex is the go-to.
Q: Is the J1939 Digital Annex only available from SAE?
A: Yes, the Digital Annex is published and maintained by SAE International. For ongoing development or diagnostics, many engineers find it worth the cost.
Q: Are J1939 PGNs controlled by SAE, or can vendors define their own?
A: Most PGNs are predefined by SAE and listed in the Digital Annex, which helps ensure compatibility and plug-and-play functionality across devices. That said, it’s technically open. Vendors can define proprietary PGNs if they stay within the reserved ranges. Just keep in mind, when you go off-spec, you lose the automatic interoperability J1939 is known for. So while registration isn’t required, following the standard gives you much better integration out of the box.
UDS: DIAGNOSTICS OVER ISO-TP
Q: What is UDS and where is it used?
A: UDS stands for Unified Diagnostic Services. It’s a standard way of doing advanced diagnostics, like reading sensor values, updating firmware, or getting error codes. You’ll find it mostly in automotive, but it’s creeping into other industries too. It runs over ISO-TP (transport protocol), which sits on top of CAN and handles larger data transfers.
Q: How does ISO-TP work with CAN?
A: CAN frames are limited to 8 bytes, but ISO-TP lets you send up to 4 KB by splitting the data into chunks. It uses a first frame to say what’s coming, then a flow control to check if the receiver is ready, and finally sends a bunch of consecutive frames. It’s all automatic once it kicks off.
Q: How does UDS compare to J1939?
A: J1939 is like a giant blueprint - tons of predefined parameters that tell you exactly what the values mean.
UDS is more like a toolkit. It gives you the services, but it’s up to the manufacturer to decide what data lives where. That gives you flexibility but requires more coordination if you’re working across vendors.
COMMON Qs FROM THE WEBINAR
Q: What protocol do Komatsu machines use?
A: Both CANopen and J1939 can be used, depending on the subsystem. Engines or powertrains tend to use J1939; while sensors, pumps, and accessory controls typically use CANopen. It really depends on the module.
Q: Can multiple higher-layer protocols be mixed on the same CAN bus?
A: Yes, but you need to manage it carefully. Be sure to avoid ID collisions, keep everything at the same bitrate, and control bus load. If those are handled well, mixed networks can be stable and efficient. We see this all the time in hybrid or transitional systems.
Q: What is the best way to get pricing on emotas software tools like CANopen DeviceExplorer?
A: For North America, contact Grid Connect. For everywhere else, please contact emotas directly.
Whether you’re integrating CAN into a new product or troubleshooting a mixed-protocol network in the field, understanding how higher-layer protocols build on the foundation of CAN is key. Each of the covered protocols - CANopen, J1939, and UDS - brings its own strengths and conventions. If you’re facing implementation challenges or just want expert guidance, don’t hesitate to reach out. Grid Connect is here to help with tools, training, and support to get your CAN-based systems running smoothly.
Discuss on X
Discuss on Reddit
Discuss on LinkedIn
