When engineers hear SAE J1939, they usually think of diesel engines, trucks, construction equipment, or agricultural machinery. That is understandable. J1939 was developed primarily for heavy-duty vehicle applications, and that remains its strongest market.
But I have often wondered whether we are putting J1939 into too small a box.
From a purely technical perspective, there is surprisingly little that prevents J1939 from being used as a general-purpose industrial CAN protocol. In fact, several characteristics of J1939 make it particularly attractive for embedded industrial networks: straightforward network management, automatic address handling, device discovery, efficient data exchange, relatively modest processor and memory requirements, and a protocol structure that is considerably easier to understand and implement than some alternatives.
And J1939 has already traveled well beyond the diesel engine.
J1939 Is Already More Than an Engine Protocol
The J1939 family and protocols derived from its concepts have found their way into a variety of applications. ISO 11783, better known as ISOBUS, applies J1939 concepts to agricultural and forestry equipment. NMEA 2000 uses a closely related approach for marine electronics. Other J1939-based profiles and adaptations have been developed for truck/trailer communication, commercial-vehicle body networks, fleet-management systems, tachographs, and even firefighting vehicles.
SAE itself describes J1939 as applicable not only to on- and off-highway vehicles but also to appropriate stationary applications using vehicle-derived components, such as generator sets.
That raises an interesting question: If the basic architecture works in trucks, tractors, construction equipment, marine systems, and stationary equipment, why couldn’t we use the same concepts for industrial embedded systems?
Technically, there is no compelling reason why not.
Network Management Comes with the Protocol
One of the strongest arguments in favor of J1939 is that it already provides the mechanisms needed to establish and manage a network.
Every ECU has a source address. The Address Claim procedure allows devices to announce themselves and resolve address conflicts. A node can request Address Claimed messages and effectively scan the network to determine which devices are present. The 64-bit NAME provides additional information for identifying and prioritizing devices.
J1939 also provides standardized request mechanisms, broadcast communication, peer-to-peer communication, diagnostic messaging, and transport protocols for data that exceeds the eight-byte payload of a Classical CAN frame.
In other words, an industrial developer does not have to start with CAN and then invent a network-management scheme on top of it. Much of that work has already been done.
That is an important distinction. CAN itself tells us how frames get from one node to another. J1939 adds the rules that allow those nodes to function as a network.
The Data Model Is Refreshingly Simple
J1939’s data exchange is also relatively straightforward.
Application data is organized into Parameter Groups and identified by Parameter Group Numbers, or PGNs. The receiving application knows the definition of a PGN and therefore knows how to interpret its data bytes.
There is no requirement for an elaborate object model between the application and the CAN network.
That simplicity has consequences.
A J1939 protocol stack can be remarkably small. It does not require extensive memory resources, which makes it attractive for smaller microcontrollers. The software architecture is relatively easy to understand, and implementing the basic protocol does not require mastering a large collection of services and abstractions.
For an engineer who already understands CAN, the learning curve for J1939 is quite manageable.
That matters in industrial products where the CAN interface may be only a small part of the overall application.
J1939 Versus CANopen
This is where I see an interesting comparison with CANopen.
CANopen has a major architectural advantage: its Object Dictionary. Device parameters, configuration values, process data, and other information are organized into a well-defined structure using indexes and sub-indexes. That creates an elegant and highly standardized interface to a device.
There is considerable value in that approach.
But there is a price.
CANopen requires more protocol machinery, more software resources, and considerably more knowledge on the part of the developer. The Object Dictionary, SDOs, PDOs, NMT, heartbeat mechanisms, and the associated configuration rules create a very capable system, but also a more complex one.
J1939 takes a different approach.
The PGN is transmitted, the data is inside it, and the receiving application knows what that PGN means.
That is essentially it.
From my perspective, this also gives J1939 a significant advantage in usable bandwidth for ordinary process-data exchange. If I need to continuously move measurements, states, commands, temperatures, pressures, speeds, positions, or similar process information between controllers, PGN-based communication is extremely efficient.
I don’t necessarily need an Object Dictionary to tell another controller that a pressure is 127.5 psi. I need both controllers to agree that a particular PGN contains that pressure at a particular location.
For many embedded industrial applications, that may be all that is required.
What About Speed?
Traditional J1939 is most strongly associated with 250 kbit/s, while SAE J1939/14 defines a 500 kbit/s physical layer.
But if we are designing a proprietary industrial network rather than trying to comply with a particular vehicle installation, there is nothing inherent in the J1939 application model that requires us to stop there.
Classical high-speed CAN can operate at 1 Mbit/s. An industrial implementation could therefore use the J1939 communication model at 1 Mbit/s, provided that all nodes, transceivers, wiring, topology, and timing are designed accordingly. I would call that a J1939-based proprietary network, rather than claiming compliance with a standard SAE J1939 physical layer.
And then there is CAN FD.
SAE has already taken J1939 in that direction with J1939-22, which defines a CAN FD data link layer. CAN FD provides larger payloads and a faster data phase, substantially increasing the amount of information that can be transferred. The J1939-17 physical layer used with CAN FD specifies 500 kbit/s arbitration with a 2 Mbit/s data phase.
That makes the bandwidth argument even more interesting for future industrial applications.
Perhaps We Should Stop Thinking of J1939 as a Truck Protocol
I am not suggesting that J1939 should replace CANopen.
CANopen has earned its place in industrial automation, and its Object Dictionary is a powerful concept, particularly where standardized device profiles, extensive configuration, and structured access to device parameters are important.
But not every industrial CAN network needs that level of abstraction.
Sometimes we simply need a collection of embedded controllers to identify themselves, establish addresses, discover other devices, exchange process data efficiently, respond to requests, transfer larger blocks of information when necessary, and provide diagnostic information.
J1939 already knows how to do all of that.
It is mature. It is well understood. Protocol stacks can be small. The network-management mechanisms already exist. Data exchange is efficient. The learning curve is comparatively gentle. And the architecture can be carried from Classical CAN into CAN FD when considerably more bandwidth is required.
Perhaps the more interesting question, therefore, isn’t whether J1939 can be used as an industrial protocol.
It is why we don’t consider it more often.