This article is part of CAN Bus Embedded Development, my growing online book about practical CAN Bus hardware, software, and embedded system development.
View the complete Table of Contents →
CAN Bus is remarkably good at what it was designed to do. It provides a reliable, efficient, and robust method for electronic devices to exchange relatively small amounts of data over a shared network.
But CAN deliberately stops there.
CAN defines how messages are transmitted, how they compete for access to the bus, and how transmission errors are detected and handled. It does not define how an entire network of devices should be organized and managed.
This is where higher-layer protocols come in.
There are many CAN-based higher-layer protocols, but three are particularly important in embedded, vehicle, industrial, and marine applications:
SAE J1939
NMEA 2000
CANopen
Other protocols exist as well. ISOBUS, for example, is widely used in agricultural machinery and builds on concepts closely related to J1939. For this overview, however, I will concentrate on J1939, NMEA 2000, and CANopen.
CAN Provides the Foundation
At its core, CAN is a message-based communication system.
A CAN controller knows about identifiers, data bytes, arbitration, acknowledgments, error detection, and retransmission. What it does not know is what those messages actually mean.
CAN does not know whether a message contains engine speed, vessel position, motor temperature, or the status of an industrial drive.
That flexibility is one of CAN’s greatest strengths. The same basic technology can be used in a truck, a yacht, a factory machine, or an agricultural vehicle.
But once several intelligent devices must operate together as a system, exchanging CAN messages is only part of the problem.
The Bigger Issue: Network Management
One of the most important reasons for using a higher-layer protocol is network management.
CAN itself does not define how a device identifies itself to other devices. It does not assign network addresses, define what happens when two devices attempt to use the same address, specify device operating states, or establish procedures for bringing nodes into or out of operation.
Those questions become increasingly important as a CAN network grows.
A system containing two or three controllers designed by the same engineering team can easily use a proprietary message scheme. Every identifier and every byte can simply be documented internally.
But consider a network containing dozens of devices, possibly supplied by several manufacturers.
Now we need answers to questions such as:
How does a device identify itself? How are addresses assigned or claimed? How does the rest of the network know which devices are present? How are devices configured? How are network states controlled? How are diagnostic conditions reported?
CAN does not answer these questions.
Higher-layer protocols do.
They may also define standardized data formats, diagnostics, large-message transfers, device profiles, and other application-specific services. But network management is one of the fundamental reasons why we need something above the CAN data-link layer.
Different higher-layer protocols solve these problems in different ways.
SAE J1939
SAE J1939 is widely used in heavy-duty trucks, buses, construction equipment, agricultural machinery, diesel engines, generators, and other mobile equipment.
It uses the 29-bit extended CAN identifier and introduces concepts such as Parameter Group Numbers (PGNs), source addresses, address claiming, standardized parameters, diagnostics, and transport protocols for messages that exceed the capacity of a single CAN frame.
J1939 essentially provides the rules that allow multiple electronic control units to form and operate as a coordinated vehicle or machine network.
We will examine those mechanisms in considerably more detail in a later post.
NMEA 2000
NMEA 2000 applies CAN networking to the marine environment and is commonly found in chartplotters, GPS receivers, engine interfaces, depth sounders, wind sensors, autopilots, and many other marine devices.
Its relationship with J1939 is immediately apparent. NMEA 2000 uses 29-bit CAN identifiers, PGNs, source addresses, address claiming, and other concepts derived from J1939.
However, NMEA 2000 defines its own marine-specific messages, network requirements, device conventions, and certification rules. Understanding J1939 provides a useful foundation, but the two protocols are not interchangeable.
CANopen
CANopen takes a different approach and is widely used in industrial automation, machinery, motion control, and embedded systems.
One of its central concepts is the Object Dictionary, which provides a standardized structure for the data and parameters within a device. CANopen also defines communication mechanisms such as Process Data Objects (PDOs), Service Data Objects (SDOs), and Network Management (NMT).
The underlying communication is still CAN, but the organization of the network is quite different from J1939 and NMEA 2000.
Same CAN, Different Rules
This distinction is important.
SAE J1939, NMEA 2000, and CANopen all use CAN, but they build very different systems on top of it.
CAN provides the mechanism for getting a message from one node onto the network.
The higher-layer protocol determines how devices identify themselves, how the network is managed, what the messages mean, and how devices are expected to interact.
That is why knowing CAN does not automatically mean knowing J1939, NMEA 2000, or CANopen.
At the same time, a solid understanding of CAN makes learning any of these protocols considerably easier.
Why Not Simply Create Your Own Protocol?
For small embedded systems, that can be a perfectly reasonable approach.
You might decide that CAN identifier 0x123 represents a particular message, that bytes 0 and 1 contain motor speed, byte 2 contains temperature, and byte 3 contains status flags.
Nothing is inherently wrong with that.
But as the network grows, you will eventually have to solve many of the same problems addressed by established higher-layer protocols.
You will need some form of network management. You may need device identification, configuration, diagnostics, message definitions, and a method for transferring information that does not fit into a single CAN frame.
At that point, you are effectively designing your own higher-layer protocol.
For a closed system, that may still be the correct engineering decision. For systems requiring interoperability between devices from different manufacturers, established protocols become far more important.
Choosing a Higher-Layer Protocol
In many applications, the industry makes the choice for you.
Heavy-duty vehicles and mobile machinery frequently point toward SAE J1939. Marine electronics point toward NMEA 2000. Industrial automation and motion-control applications often use CANopen. Agricultural equipment may involve ISOBUS and related standards.
Despite their differences, all of these protocols demonstrate the same fundamental idea:
CAN provides an excellent communication foundation, but a functioning network needs more than the ability to transmit CAN frames.
It needs rules for managing the network and for giving those messages meaning.
In the following posts, I will look more closely at SAE J1939, NMEA 2000, and CANopen individually, including their network-management approaches, message structures, and practical implementation in embedded systems.
Follow CAN Bus Embedded Development
New chapters and technical material are added regularly. Subscribe to receive new additions as the online book continues to grow.