This article is part of our comprehensive SAE J1939 online documentation.
The standard CAN message frame (CAN 2.0A) uses an 11-bit message identifier, which is sufficient for automobiles and industrial applications. However, off-road vehicles and heavy-duty applications require a more extensive identifier range.
To meet these demands, the Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee developed the SAE J1939 higher-layer protocol, based on CAN. J1939 also needed backward compatibility with older RS485-based protocols (SAE J1708/J1587), necessitating an enhanced CAN standard.
Introduction of the 29-bit Extended Frame Format
In response, the ISO 11898 amendment introduced the CAN 2.0B extended frame format in 1995, expanding the message identifier to 29 bits.
Standard vs. Extended Frame Format
The 29-bit identifier consists of:
- The 11-bit base identifier (from CAN 2.0A)
- An 18-bit identifier extension
The IDE bit (Identifier Extension) inside the Control Field distinguishes between formats:
- Low (dominant) IDE bit → 11-bit standard format
- High (recessive) IDE bit → 29-bit extended format
| Frame Format | Message Identifier Size | Total Possible Messages |
|---|---|---|
| Standard (CAN 2.0A) | 11-bit | 2,048 (2¹¹) |
| Extended (CAN 2.0B) | 29-bit | 536+ million (2²⁹) |
The 29-bit extended format provides the necessary flexibility for off-road, heavy-duty, and specialized vehicle networks, ensuring scalability and compatibility with SAE J1939.
The image above illustrates a comparison between a standard CAN data frame with an 11-bit identifier and an extended CAN data frame with a 29-bit identifier. Both frames include an Identifier Extension Bit (IDE), which is set to a low level in the standard frame and a high level in the extended frame. CAN controllers must be designed to check the IDE bit to accurately differentiate between the two frame formats.
Both formats, standard (11-bit message ID) and extended (29-bit message ID), can coexist on the same CAN bus. During bus arbitration, a standard 11-bit message ID frame always takes priority over an extended 29-bit message ID frame if they share the same 11-bit base identifier, ensuring that the standard frame gains bus access first.
The extended format comes with certain trade-offs: it introduces a longer bus latency time (at least 20 bit-times), increases bandwidth usage by approximately 20%, and slightly reduces error detection performance. This reduction occurs because the 15-bit checksum polynomial used for error detection is optimized for frame lengths up to 112 bits.
CAN Characteristics
CAN is designed with maximum reliability and performance in mind. Originally developed for automobiles—a highly demanding environment for microprocessors—CAN ensures both electrical robustness and high-speed serial communication.
Due to its stringent safety and reliability standards, CAN has also been widely adopted in medical engineering, where strict safety requirements must be met. Manufacturers of robots, lifts, and transportation systems have faced similar challenges, making CAN a preferred choice for their applications.
Key Properties of CAN:
- Multi-master priority-based bus access
- Non-destructive contention-based arbitration
- Multicast message transfer with message acceptance filtering
- Remote data request capability
- Flexible system configuration
- System-wide data consistency
- Advanced error detection and signaling
- Automatic retransmission of messages that lose arbitration
- Automatic retransmission of messages corrupted by errors
- Differentiation between temporary errors and permanent node failures
- Autonomous deactivation of defective nodes
These properties make CAN an ideal solution for mission-critical applications, where reliability and efficiency are paramount.
CAN Message Frames
In the CAN standard, all messages are referred to as frames, including data frames, remote frames, error frames, and overload frames. Any message sent on the CAN bus must follow a predefined frame format with a specific, limited length.
Any node connected to the network can transmit a new frame as soon as the bus is idle. However, for a transmission to be valid, all nodes in the network must simultaneously accept the frame’s consistency.
Types of CAN Message Frames:
-
Data Frame – Transmits Data
- Used for data transfer from one sender to one or multiple receivers.
-
Remote Frame – Requests Data
- A node can request data from another source.
- The remote frame is followed by a corresponding data frame containing the requested information.
-
Error Frame – Reports Errors
- Any bus participant (sender or receiver) can signal an error condition at any time during data or remote frame transmission.
-
Overload Frame – Indicates Node Overload
- A node can request a delay between two frames if it is temporarily overloaded.
- Overload frames should not occur in well-functioning networks.
- Many modern CAN controllers no longer support overload frames due to technological advancements.
By using these standardized message frames, CAN ensures reliable, efficient, and synchronized communication across all nodes in a network.
The Remote Transmission Request (RTR) is not used in SAE J1939, as the protocol relies on Acknowledgement messages instead.
Additionally, in August 2005, CAN-in-Automation (CiA) released Application Note 802 – “CAN Remote Frame – Avoiding of Usage”, which discourages the use of Remote Frames, citing potential inefficiencies and compatibility concerns. However, this recommendation has not been widely promoted.
CAN Data Frame Architecture
According to the CAN standard, a data frame consists of the following components:
- SOF (Start of Frame) – Indicates the beginning of a data or remote frame.
- Arbitration Field – Contains the message ID and the RTR (Remote Transmission Request) bit, which differentiates data frames from remote frames.
- Control Field – Defines the data length and specifies whether the frame uses an 11-bit or 29-bit message ID.
- Data Field – Holds the actual payload data (applicable only to data frames, not remote frames).
- CRC Field – Provides a checksum for error detection.
- EOF (End of Frame) – Marks the conclusion of the data or remote frame.
The image below illustrates a detailed view of the CAN data frame architecture.
Multi-Master Bus Access
To ensure direct communication between nodes while maximizing speed and reliability, CAN does not rely on the traditional client/master network configuration. Instead, all nodes in a CAN network operate with equal rights, and any node transmitting a data or remote frame becomes the bus master during that transmission.
Efficient Bus Access and Arbitration
- CAN manages bus access through non-destructive bit-wise arbitration, ensuring effective message collision avoidance when multiple nodes attempt to transmit simultaneously.
- Contention-based arbitration resolves bus access conflicts using the message identifier, guaranteeing that no information is lost.
- The node with the highest-priority frame (lowest message ID) wins the arbitration and gains bus access.
Automatic Retransmission
- Frames that lose arbitration or are interrupted due to errors are automatically retransmitted once the bus becomes idle again.
- This mechanism ensures seamless data integrity without delays or manual intervention.
By following these principles, CAN achieves a highly efficient, reliable, and collision-free communication process.
Message Broadcasting and Error Handling
The broadcasting of messages in CAN follows a producer-consumer model, where the transmitting node acts as the producer and all other nodes function as consumers. Every node in the CAN network receives the transmitted message simultaneously.
Multi-Master Network and Message Filtering
- In a multi-master network, any node can transmit data at any time.
- Each node continuously “listens” to the network and receives every transmitted message.
- CAN includes message filtering, allowing nodes to process only the relevant data, reducing unnecessary processing.
Message Acknowledgment and Error Handling
- CAN does not require message acknowledgments, as this would increase bus traffic unnecessarily.
- It assumes all messages conform to the defined standard; otherwise, the network will respond accordingly.
- Each receiving node verifies the consistency of a frame:
- If valid, nodes acknowledge the consistency.
- If not acknowledged, the transmitting node detects the error and flags it on the bus.
- If one or more nodes fail to decode a message due to an error or internal malfunction, the entire bus is notified of the error condition.
- Faulty nodes that persistently send incorrect data or fail to receive messages correctly will remove themselves from the network, ensuring proper bus operation.
Remote Frame Transmission
- CAN allows one node to request data from another using a remote frame.
- A remote frame and its corresponding data frame share the same message identifier.
- They are distinguished during arbitration by the RTR bit (Remote Transmission Request).
This robust error-handling mechanism ensures high reliability and efficient communication in CAN-based networks.
CAN Message Transmission and Prioritization
By design, CAN nodes do not rely on system configuration details, such as node addresses. Instead, CAN does not support node IDs. Instead of addressing individual nodes, messages are processed through an acceptance filtering mechanism, determining whether the received data is relevant to a node’s application layer. The transmitter and receiver do not need to know each other’s identities, enhancing network flexibility.
Message Identification and Priority Handling
- CAN messages are identified by a unique 11-bit or 29-bit message ID, which also determines message priority.
- A lower message ID value corresponds to a higher priority.
- A single CAN node can send or receive multiple messages, allowing for maximum network flexibility.
Efficient Bus Access and Event-Driven Communication
- High-priority messages gain bus access faster, even under heavy traffic conditions.
- Event-driven message transmission helps reduce bus load and ensures low latency, making CAN ideal for real-time applications.
This design guarantees reliable, fast, and efficient communication, even in demanding applications with multiple competing data streams.
CAN Message Length and Its Advantages
CAN supports message lengths between 0 and 8 bytes. While this may initially seem like a limitation compared to other communication technologies, the short data length ensures low latency for high-priority messages. Additionally, the limited payload size enhances reliability, making CAN more resistant to harsh electrical environments.
Applicability of 8-Byte Message Length
- A maximum of 8 bytes per message is sufficient for:
- Automotive data communication
- Smaller machines, such as household appliances
- Lower-level industrial automation
Handling Larger Data Transfers with CANopen
- Higher-layer protocols like CANopen allow segmented transmission of data beyond 8 bytes, making them ideal for complex automation tasks like motion control.
- CANopen retains support for limited 8-byte messages known as Process Data Objects (PDOs).
- PDOs (high-priority messages) can interrupt lower-priority, segmented data transfers (Service Data Objects = SDOs) after every 8-byte segment.
- Once the high-priority message is sent, the lower-priority transfer resumes automatically.
This structure ensures efficient real-time communication, balancing high-priority message delivery with the ability to handle larger data transmissions when necessary.
CAN Bus Arbitration and Collision Avoidance
In a serial communication system like CAN, all nodes share the same two-wire communication bus, making message collision avoidance essential for safe and efficient data transfer. Without proper arbitration, simultaneous bus access attempts by multiple nodes could lead to delays, message corruption, or bus errors.
Handling Message Collisions
- A collision occurs when two or more nodes attempt to transmit at the same time.
- This could lead to bus access delays or potential message conflicts.
Non-Destructive Bus Arbitration
- CAN uses a non-destructive arbitration method, ensuring that no message is lost during bus access contention.
- Higher-priority messages (lower message IDs) win arbitration and gain immediate bus access.
- Lower-priority messages automatically wait and are retransmitted once the bus is free.
Efficiency of Arbitration
- At a baud rate of 1 Mbit/sec, with an 11-bit message identifier, the arbitration process completes in just 12 microseconds.
- This ensures rapid message prioritization without compromising real-time communication.
By implementing this efficient arbitration process, CAN guarantees low latency, reliable data transfer, and seamless communication across all network nodes.
CAN Error Detection and Fault Handling
Instead of requiring message confirmation, which would increase bus traffic, CAN assumes that all messages must comply with the defined standard. Any deviation from this standard is immediately detected and reported, effectively replacing the need for explicit confirmations. Since confirmed messages would occur far more frequently than errors, this approach optimizes network efficiency.
Message Reception and Filtering
- All nodes receive every transmitted message.
- A message filter determines whether a node should process or ignore a message.
- Regardless of relevance, each node checks the received frame for compliance with the CAN standard.
- If the message is valid, receiving nodes acknowledge its consistency.
- If any or all nodes fail to acknowledge consistency, the transmitting node issues an error frame.
Possible Causes of an Error Frame
- The transmitted data frame is faulty.
- The data frame was correct, but a node erroneously reported an error due to a local reception issue.
Temporary vs. Permanent Node Failures
- CAN controllers use two separate error counters:
- One for transmit errors.
- One for receive errors.
- If either counter exceeds a predefined threshold, the node is considered faulty.
- If a node continuously generates errors and overloads the bus, CAN can remove the node from the network to restore stability.
Fast Error Recovery
- CAN features short error recovery times—up to 23 bit times.
- At a baud rate of 1 Mbit/sec, this equates to a maximum recovery time of just 23 microseconds.
This robust error detection and recovery mechanism ensures high reliability and efficient communication, even in demanding environments.
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.