This article is part of our comprehensive SAE J1939 online documentation.
SAE J1939 is a higher-layer protocol built on the Controller Area Network (CAN), enabling serial data communication between microprocessor-based Electronic Control Units (ECUs) in heavy-duty vehicles.
CAN’s Strength in Reliability and Performance
CAN is designed for maximum reliability and performance, ensuring:
- Robust electrical characteristics for harsh environments.
- High-speed serial communication for efficient data transfer.
While CAN is well-suited for automotive and small industrial applications, it has limitations in network management. To address these gaps, higher-layer protocols like J1939 extend CAN’s capabilities through software enhancements while retaining its physical layer.
J1939 Advantages and Key Features
J1939 builds upon CAN’s core strengths, including:
- Maximum reliability for mission-critical applications.
- Advanced error detection and fault confinement mechanisms.
- Collision-free bus arbitration to ensure seamless communication.
Speed and Real-Time Considerations
- CAN supports speeds up to 1 Mbit/sec for real-time applications.
- J1939 operates at a fixed 250 kbit/sec—a trade-off between speed and network stability, as real-time performance is not as critical for J1939 applications.
By leveraging CAN’s strengths while adding network management capabilities, J1939 has become the industry standard for heavy-duty vehicles, off-road machinery, and specialized transportation systems.
One of the notable concerns with the SAE J1939 standard is its approach to network management and message handling, which introduces potential conflicts with the foundational principles of the CAN protocol.
Unlike standard CAN implementations, SAE J1939 allows scenarios where two nodes with the same message ID may access the bus simultaneously. This situation contradicts CAN’s strict arbitration process, where each message ID should be unique to ensure predictable and conflict-free communication. The outcome of such collisions in J1939 is unpredictable, which could lead to network inconsistencies.
SAE J1939’s message structure does not fully utilize the built-in message filtering capabilities found in most CAN controllers. CAN controllers typically rely on hardware-level filtering to selectively process relevant messages, reducing CPU load. J1939’s deviation from this feature means higher software overhead, potentially impacting system efficiency.
While SAE J1939 expands CAN’s capabilities for heavy-duty vehicles, its approach to network management and message handling compromises some of CAN’s core reliability and efficiency features. These trade-offs should be carefully considered when designing or implementing a J1939-based system.
SAE J1939 Quick Reference
- Higher-Layer Protocol utilizing CAN as the physical layer
- Shielded twisted-pair wiring for communication
- Maximum network length of 40 meters (~120 ft.)
- Standard baud rate of 250 kbit/sec
- Maximum of 30 nodes (ECUs) per network
- Support for up to 253 Controller Applications (CAs), where one ECU can manage multiple CAs
- Peer-to-peer and broadcast communication supported
- Message length support up to 1785 bytes
- Predefined Parameter Groups to standardize vehicle parameters
- Network Management including the address claiming procedure
The 40-meter network length, 250 kbit/sec baud rate, and 30-node limit are self-imposed restrictions by SAE, likely intended to ensure high reliability and prevent potential runtime issues. However, according to ISO 11898, a 250 kbit/sec CAN network can extend up to 250 meters (~750 ft.).
There is no inherent limitation preventing J1939 from operating at 1 Mbit/sec, the maximum CAN baud rate. Naturally, increasing the baud rate would reduce network length, but the J1939 protocol itself does not impose any restrictions on baud rate.
The J1939 protocol uses an 8-bit device (ECU) address, theoretically allowing 256 nodes in the same network. However, SAE limits the network to 30 nodes, possibly to reduce bus traffic. Comments regarding these restrictions may be found within the standard documentation.
In practical implementation, ECU addresses function as Controller Application (CA) addresses, since a single ECU may accommodate multiple CAs. Out of the 256 possible addresses, address 254 is reserved for network management, while address 255 is used for global addressing (message broadcasting). The 253 available addresses are assigned to Controller Applications rather than the physical ECU itself.
The following image illustrates an example where ECU A hosts three distinct controller applications, demonstrating how multiple applications can be managed within a single ECU.
The image also illustrates that multiple ECUs with the same function (such as ECU A) can coexist within a J1939 network without address conflicts. This is made possible by the Address Claim procedure, an intelligent mechanism in J1939 that automatically assigns addresses to each Controller Application. In the event of an address conflict, the affected Controller Application can claim an alternative available address, ensuring seamless network operation.
A defining characteristic of J1939 is its use of Suspect Parameter Numbers (SPNs) and Parameter Group Numbers (PGNs), which reference a vast set of predefined vehicle data and control functions. The PGN and SPN definitions form a significant part of the SAE J1939 Standards Collection. SPNs specify the data type and function of each parameter within a parameter group, while PGNs are embedded in the 29-bit CAN message identifier, enabling efficient message handling and interpretation.
The following image provides a visual representation of Suspect Parameter Numbers (SPNs), Parameter Groups, and Parameter Group Numbers (PGNs) within the J1939 protocol.
The Suspect Parameter Numbers (SPNs) in this example correspond to vehicle data related to Engine Temperature. Each SPN is logically assigned to fit within the Engine Temperature Parameter Group, ensuring structured and meaningful data interpretation.
The Engine Temperature Parameter Group is identified by Parameter Group Number (PGN) 65262. Within the J1939 protocol, the PGN is embedded in the 29-bit CAN message identifier, while the actual sensor data is transmitted in the CAN data field. This structured approach enables efficient data communication across the network.
For seamless communication, all nodes that send or receive PGN 65262 must recognize the structure of the PGN and its associated SPNs. This ensures that data is interpreted correctly across all network participants, maintaining consistency and reliability in vehicle diagnostics and control.
SAE J1939 Message Format
CAN supports both 11-bit and 29-bit message identifiers. It is designed so that the sending node does not need to know which node(s) will receive the data, and conversely, the receiving node does not need to know or care about the sender’s identity. This enables a flexible and decentralized communication model.
In contrast, J1939 exclusively uses the 29-bit identifier. In fact, the CAN standard was extended from 11 to 29 bits at the request of SAE to accommodate J1939’s requirements. J1939 utilizes the 29-bit identifier not only for message prioritization but also to identify the source and, in some cases, the destination of the data transmitted on the bus. This structured addressing approach enhances network organization and data management within heavy-duty vehicle applications.
As shown in the image, J1939 extends the use of the 29-bit CAN identifier beyond standard CAN message identification. The CAN identifier is structured into multiple fields, including priority, Parameter Group Number (PGN) to define the content of the data field, and source address.
The message priority ranges from 0 (highest priority) to 7 (lowest priority). High-priority messages are typically used for time-critical data, such as torque control messages sent to the engine. Lower-priority messages handle less time-sensitive information, such as vehicle road speed.
Messages in J1939 are transmitted using either the producer/consumer model (broadcast) or destination-specific (peer-to-peer) communication.
One of the most critical aspects of J1939 is the Parameter Group Number (PGN), which categorizes Parameter Groups (PGs). For example, the Engine Temperature PG includes various Suspect Parameter Numbers (SPNs) such as coolant temperature, fuel temperature, and oil temperature. These Parameter Groups and PGNs are comprehensively documented in the SAE J1939 standard (approximately 300 pages) and further detailed in SAE J1939/71, an 800-page document containing parameter group definitions and SPNs. SPNs define the data structure of each entry within a Parameter Group, ensuring a standardized approach to vehicle diagnostics and control.
Network Management
The network management system in SAE J1939 (document J1939/81) facilitates the automatic allocation of node addresses, similar to the plug-and-play principle. However, J1939 does not define node monitoring, meaning that if monitoring is required, it must be implemented at the application level.
Under J1939, Network Management is primarily represented by the Address Claiming Process. Unlike other higher-layer protocols based on Controller Area Network (CAN), which typically do not support dynamic node address assignments, SAE J1939 introduces an intelligent solution for dynamically identifying ECUs and their primary functions. This adaptive addressing mechanism enhances flexibility and scalability in complex vehicle and machinery networks.
SAE J1939 does not inherently support a traditional Master/Slave or Client/Server network management model. Other SAE J1939 Based Protocols
SAE J1939 enables serial data communication between microprocessor-based systems, also known as Electronic Control Units (ECUs), in heavy-duty vehicles. The messages exchanged between these units include vehicle road speed, torque control signals from the transmission to the engine, oil temperature, and various other operational parameters.
SAE J1939 and its related standards have rapidly become the industry standard for off-highway machinery. Given its proven reliability and efficiency, manufacturers in agriculture, military, and marine industries adopted the J1939-based CAN communication structure instead of developing entirely new protocols. However, due to the specific requirements of these industries, minor modifications—including renaming—were necessary.
These J1939-derived protocols include:
- ISO 11783 (ISOBUS) – Standardized for the agricultural industry, ensuring seamless communication between tractors, implements, and other farming equipment.
- MilCAN – Adapted for military applications, providing enhanced robustness and reliability for defense-related vehicles and equipment.
- NMEA 2000 – Designed for marine applications, enabling standardized data exchange for navigation, engine monitoring, and onboard systems in boats and ships.
By leveraging J1939’s foundation, these protocols ensure interoperability, scalability, and efficient data exchange tailored to their respective industries.
ISO 11783 (ISOBUS)
ISO 11783, commonly known as ISOBUS, is a higher-layer protocol based on SAE J1939 and designed for agricultural and forestry vehicles. Developed collaboratively by manufacturers in these industries, ISOBUS addresses the growing demand for electronic control and data exchange in modern machinery.
The standard is structured under the general title “Tractors and machinery for agriculture and forestry – Serial control and communications data network” and consists of the following parts:
- Part 1: General standard for mobile data communication
- Part 2: Physical layer
- Part 3: Data link layer
- Part 4: Network layer
- Part 5: Network management
- Part 6: Virtual terminal
- Part 7: Implement messages applications layer
- Part 8: Power train messages
- Part 9: Tractor ECU
- Part 10: Task controller and management information system data interchange
- Part 11: Mobile data element dictionary
- Part 12: Diagnostics
- Part 13: File server
The ISO 11783 standard is available for purchase through the International Organization for Standardization (ISO). It is managed by the ISOBUS group within VDMA, with more information accessible at www.isobus.net.
MilCAN
According to the official website (www.milcan.org):
“MilCAN has been defined by a group of interested companies and government bodies associated with the specification, manufacture, and testing of military vehicles. The MilCAN working group was formed in 1999 as a sub-group of the International High Speed Data Bus – Users Group (IHSDB-UG) when a need was recognized to standardize the implementation of CANbus within the military vehicles community. The mission statement of this newly formed group was: ‘To develop, for various application classes in all military vehicles, a common interface implementation specification based on CANbus’.”
Describing the MilCAN standard is complex, and its inclusion in this discussion is due to its partial reliance on J1939. The protocol was developed to harmonize the requirements of multiple stakeholders, including European military organizations (particularly Germany and the UK) and American defense contractors. This balancing act resulted in a hybrid protocol that combines elements of:
- CUP (a protocol developed by the German Army – Bundeswehr)
- SAE J1939 (representing American standards)
- CANopen (widely used in European applications)
As a result, MilCAN exists in two distinct variants:
- MilCAN A – Based on the 29-bit CAN identifier from SAE J1939. The primary difference is that MilCAN A supports deterministic data transfer, accommodating both synchronous and asynchronous communication.
- MilCAN B – Uses the 11-bit CAN identifier and is designed to be compatible with CANopen-based systems. Officially, MilCAN A (J1939-based) devices should be able to coexist on the same network with MilCAN B (CANopen-based) devices, allowing for mixed implementations when needed.
While MilCAN provides a flexible and adaptable military-grade network protocol, its hybrid nature reflects the challenges of integrating competing international standards into a cohesive communication framework for defense applications.
NMEA 2000
Of all the SAE J1939 derivatives, NMEA 2000 seems to be the most consequent and straight-forward adaptation of J1939. While taking advantage of a proven and ingeniously designed protocol, NMEA 2000 defines only its own messages.
NMEA 2000 is used for marine data networks providing communication between marine specific electronic devices such as depth finders, chartplotters, navigation instruments, engines, tank level sensors, and GPS receivers.
It has been defined and is controlled by the US based National Marine Electronics Association (NMEA). Information on their official web site (http://www.nmea.org) is somewhat sparse. Another web site, http://www.jackrabbitmarine.com, however, provided more in-depth information, but, unfortunately, JackRabbit has closed and filed for bankruptcy.
NMEA 2000 is a modernized version and replacement of an older standard, NMEA 0183. It has a significantly higher data rate (250k bits/second vs. 4.8k bits/second for NMEA 0183). It also uses a binary message format as opposed to the ASCII serial communications protocol used by NMEA 0183. Another distinction between the two protocols is that NMEA 2000 is a multiple-talker, multiple-listener data network whereas NMEA 0183 is a single-talker, multiple-listener serial communications protocol.
SAE J1939 Starter Kit and Network Simulator
Our JCOM.J1939 Starter Kit and Network Simulator is designed to allow the experienced engineer and the beginner to experiment with SAE J1939 data communication without the need to connect to a real-world J1939 network, i.e., a diesel engine. It may sound obvious, but you need at least two nodes to establish a network. That fact applies especially to CAN/J1939, where the CAN controller shuts down after transmitting data without receiving a response. Therefore, our jCOM.J1939 Starter Kit and Network Simulator consists of two J1939 nodes, namely our jCOM.J1939.USB, an SAE J1939 ECU Simulator Board with USB Port.
The jCOM.J1939.USB gateway board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP).
Comments are closed.