I have been working with Controller Area Network for roughly three decades, and I should state my position at the beginning: I love Classical CAN.
It is one of the most ingenious communication technologies developed for embedded systems. It is robust, inexpensive, deterministic, relatively easy to implement, and remarkably tolerant of the electrically hostile environments in which embedded systems often operate.
But CAN is not a complete network architecture.
That distinction is important, because it leads directly to higher-layer protocols such as CANopen, SAE J1939, NMEA 2000, ISOBUS, DeviceNet, and others.
It also leads to a question that I have increasingly asked myself as CAN has evolved into CAN FD and now CAN XL:
Are we improving CAN, or are we trying to turn CAN into something it was never intended to be?
What follows is very much a personal view. It is based on roughly three decades of working with CAN, developing CAN-based products and software, writing about the technology, and at one time teaching seminars on CAN and CANopen.
Others in the industry will certainly disagree with some of my conclusions. That is perfectly fine. My purpose here is not to declare winners and losers, but to question some of the directions CAN development has taken.
Why Do We Need Higher-Layer Protocols?
Classical CAN provides an excellent data-link layer, but deliberately leaves many important questions unanswered.
CAN does not tell us what a message identifier means. It does not provide a standardized device-addressing system. It does not define how a device joins a network, how devices identify themselves, how parameters are represented, how diagnostic information is exchanged, or how application data larger than a CAN frame should be transported.
In other words, CAN provides the communication mechanism, but not the complete network-management infrastructure.
Higher-layer protocols fill that gap.
CANopen, SAE J1939, DeviceNet, NMEA 2000, ISOBUS, and other protocols approached the problem differently. Some developed extensive device models and configuration mechanisms. Others concentrated more heavily on message definitions, addressing, network management, and interoperability within particular industries.
The existence of these protocols is not the problem. We need higher-layer protocols.
The more interesting question is how much protocol we actually need.
CANopen: Powerful, but at What Cost?
I should probably make another personal bias clear.
Despite having taught CANopen seminars myself and having once been quite familiar with the protocol, I have never become an admirer of CANopen.
That is not because I fail to understand what CANopen attempts to accomplish. There are aspects of it that I genuinely appreciate.
The Object Dictionary provides a standardized representation of device data. Device profiles can provide genuine interoperability between products from different manufacturers. The idea that an encoder, drive, I/O module, or other device can conform to a defined profile has obvious advantages.
But in my view, CANopen achieves these advantages with a considerable amount of complexity.
Object Dictionaries, PDOs, SDOs, NMT, synchronization, emergency messages, communication profiles, device profiles, configuration mechanisms, and numerous associated specifications create a substantial learning curve.
CANopen is certainly powerful.
I simply question whether many embedded applications need that much machinery.
There is another issue that should not be overlooked: bandwidth.
Classical CANopen inherited the fundamental restrictions of Classical CAN: a maximum data field of 8 bytes and a maximum nominal bit rate of 1 Mbit/s. CiA itself describes these as the speed and payload limitations of Classical CANopen. CANopen FD increases the payload to as much as 64 bytes and permits higher data-phase bit rates. Interestingly, CiA has also acknowledged that migration to CANopen FD has been relatively slow because many existing CANopen applications can continue operating within the Classical CAN limitations.
The bandwidth limitation becomes particularly relevant when CANopen’s more elaborate communication mechanisms are considered. An 8-byte CAN data field does not leave much room when larger blocks of application or configuration data must be transferred.
CANopen FD addresses that problem.
But to me, that raises a more fundamental question:
If the application increasingly requires substantially more bandwidth and larger packets, should our first response always be to make CAN faster?
J1939 Took a Different Approach
This is one reason I have always appreciated SAE J1939.
J1939 provides a surprisingly capable network architecture without requiring an equally large conceptual framework.
The 29-bit CAN identifier provides priority information, a Parameter Group Number, source addressing, and—in appropriate cases—destination information. J1939 defines address claiming, request mechanisms, standardized parameters, diagnostics, and transport mechanisms for messages that exceed the capacity of a single CAN frame.
From an implementation perspective, the basic concepts are relatively easy to understand.
A device can announce itself. It can claim an address. Messages identify both their purpose and their source. Parameter Groups organize related information. Larger messages can be transported when necessary.
There is certainly complexity within the complete J1939 ecosystem, especially when considering the enormous number of standardized parameters and application-specific documents. But the underlying network-management architecture remains comparatively elegant.
For years I have wondered why that basic approach did not spread much further into general-purpose embedded networking.
Here I need to make a qualification.
J1939 actually has spread far beyond diesel-engine control. SAE identifies applications including on- and off-highway trucks, construction equipment, agricultural equipment and implements, and stationary applications such as generator sets.
Its influence extends even further.
NMEA 2000 adopted concepts from J1939 for marine networking, while ISO 11783—better known as ISOBUS—uses a J1939-based architecture for agricultural machinery.
So it would be incorrect to describe J1939 as merely an engine protocol.
Nevertheless, I remain surprised that its relatively straightforward network-management concepts did not become more widely adopted as a general-purpose approach to embedded CAN networking.
Then the Automobile Industry Needed More
Eventually, Classical CAN’s limitations became increasingly troublesome, particularly in automotive applications.
CAN FD was the response.
This history is worth remembering. CiA states quite explicitly that CAN FD was developed because of the automotive industry’s increasing bandwidth requirements. Bosch began development in 2011 in cooperation with automobile manufacturers and other CAN experts.
CAN FD addressed two obvious limitations of Classical CAN.
The maximum payload increased from 8 bytes to 64 bytes, and the data portion of a frame could be transmitted at a higher bit rate than the arbitration portion.
Technically, it is an impressive evolution of CAN.
But I see it primarily as exactly that: an evolution, not a revolution.
It moves the bandwidth boundary.
It does not eliminate it.
This is not a criticism of the engineers who developed CAN FD. They solved the problem they were given while preserving many of the characteristics that made CAN attractive in the first place.
My concern is with the underlying strategy.
If increasing application demands caused 1 Mbit/s and 8-byte messages to become insufficient, increasing those limits gives us additional breathing room.
But what happens when those new limits are no longer sufficient?
We already know the answer.
Enter CAN XL
CAN XL takes the same progression considerably further.
CiA currently describes the three generations as Classical CAN with up to 8-byte data fields and 1 Mbit/s, CAN FD with up to 64-byte data fields and higher data-phase rates, and CAN XL with data fields up to 2048 bytes and data rates reaching approximately 20 Mbit/s.
Those are enormous improvements compared with Classical CAN.
But again, I find myself asking whether this is the direction we should be taking.
CAN XL development began at the end of 2018 following a request from Volkswagen. CiA credits Volkswagen engineers with supplying many of the initial ideas, followed by significant contributions from Bosch, Fraunhofer, NXP, and other participants. CAN XL has since been incorporated into ISO 11898.
Consequently, it would be unfair to characterize CAN XL simply as a proprietary German automotive project. It isn’t.
But its automotive origins are difficult to ignore.
And meanwhile, the automotive industry itself is increasingly using Ethernet.
That brings me to what may be my biggest disagreement with the continuing expansion of CAN.
You Can’t Squeeze Blood Out of a Stone
I am not opposed to new technology.
Nor am I suggesting that we should continue using Classical CAN simply because it has worked well for decades.
Quite the opposite.
When the requirements change sufficiently, perhaps the technology should change as well.
Classical CAN was designed for relatively small amounts of control and status information exchanged reliably among distributed electronic control units.
For that job, it remains exceptionally good.
A temperature value does not require a megabit Ethernet connection. Neither does an engine speed, switch position, pressure value, actuator command, alarm condition, or hundreds of other signals routinely exchanged in embedded systems.
CAN handles those jobs beautifully.
But cameras, radar, large software downloads, high-resolution sensors, audio/video streams, and other data-intensive applications represent a different class of communication problem.
If those applications require tens, hundreds, or eventually thousands of megabits per second, continually expanding CAN begins to look less attractive to me.
There comes a point where, as the saying goes, you can’t squeeze blood out of a stone.
We Already Have Ethernet
Ethernet is hardly an experimental alternative.
It is one of the most established networking technologies in existence.
Automotive Ethernet and industrial Ethernet technologies have adapted Ethernet to environments that differ considerably from the office networks with which most people associate the term.
Ethernet provides something else that CAN FD and CAN XL cannot permanently provide:
room to grow.
That does not mean I want Ethernet to replace CAN.
Quite the opposite.
I believe the more sensible architecture for many future embedded systems is a mixed network.
Use CAN where CAN makes sense.
Use Ethernet where Ethernet makes sense.
And provide gateways between them.
CAN can continue handling distributed sensors, actuators, controllers, and other devices for which modest message sizes, deterministic arbitration, low cost, and robustness are more important than massive bandwidth.
Ethernet can provide the high-speed backbone and handle applications involving large amounts of data.
There is no requirement that an embedded system must choose one or the other.
NMEA Took an Interesting Course
The marine industry provides an excellent example.
NMEA 2000 uses CAN and concepts derived from J1939. It has been enormously useful for connecting marine electronics and exchanging information such as engine data, navigation information, heading, tank levels, environmental information, and countless other relatively small pieces of data.
But modern vessels also contain radar, sonar, chart systems, cameras, audio/video equipment, and other devices capable of producing vastly larger amounts of information.
NMEA could have attempted to stretch NMEA 2000 progressively further to accommodate those applications.
Instead, it developed OneNet.
OneNet uses IPv6 and IEEE 802.3 Ethernet and was specifically designed to support high-bandwidth applications while maintaining interoperability with NMEA 2000 through gateways. Interestingly, it can continue transporting NMEA network messages and PGNs over the IP infrastructure.
I find that approach compelling.
NMEA did not need to abandon NMEA 2000.
It also did not need to turn NMEA 2000 into something fundamentally different simply because some marine applications needed much more bandwidth.
Use the appropriate network for the appropriate job and connect the two.
That is very close to how I believe embedded networking should evolve.
What About J1939 FD?
SAE has naturally responded to the availability of CAN FD as well. J1939-22 defines the CAN FD data-link layer for J1939, with goals including extended transport capability, functional safety, cybersecurity, and backward compatibility with existing J1939 definitions.
I understand the reasoning.
I am simply not convinced that continually increasing CAN’s bandwidth represents the best long-term architecture.
CAN FD solves today’s problem.
CAN XL attempts to solve tomorrow’s.
What happens after that?
At some point, an application that continually demands more bandwidth may simply no longer be a CAN application.
Perhaps CAN Does Not Need to Become Ethernet
This brings me back to why I like Classical CAN so much.
CAN succeeds because it is exceptionally good at a particular job.
It does not need to be everything.
The industry has spent decades developing CAN controllers, transceivers, software stacks, diagnostic tools, higher-layer protocols, engineering knowledge, and manufacturing infrastructure. There are very good economic reasons to preserve that investment.
But technological familiarity can also tempt us to keep extending a technology because we know it rather than because it remains the best architecture for the problem.
I remain skeptical about the long-term prospects for CAN XL for precisely that reason.
I may be wrong.
CAN XL is standardized, technically sophisticated, and backed by significant companies and industry organizations. It may find important applications, particularly in automotive architectures.
But I question whether there is a sufficiently large and durable space between CAN FD and Ethernet to justify yet another generation of CAN.
And as Ethernet technology continues moving closer to sensors and actuators, that question becomes even more interesting.
Keep CAN What It Does Best
After roughly three decades of working with CAN, my conclusion is not that CAN is obsolete.
It is almost the opposite.
I believe CAN is too good at what it does to burden it with the expectation that it must do everything.
Higher-layer protocols are necessary because CAN itself intentionally leaves network management and application semantics to us.
Some higher-layer approaches, in my opinion, accomplish that more elegantly than others. I have never been particularly fond of CANopen despite understanding its capabilities and having taught it myself. I continue to admire the relative simplicity and efficiency of the basic J1939 architecture.
Likewise, I appreciate what CAN FD accomplishes technically while questioning whether continuously increasing CAN bandwidth is the right long-term strategy.
And I remain skeptical that CAN XL is the inevitable future of CAN networking.
Perhaps we should stop asking how much more data we can force through CAN and ask a different question:
What communication technology is appropriate for the data we actually need to move?
Sometimes the answer will be Ethernet.
Sometimes it will be CAN.
Increasingly, the answer may be both.
And there is absolutely nothing wrong with that.