The SAE J1939-22 standard addresses the issue of limited bandwidth for future data-demanding applications when using Classical CAN as the hardware layer. The proposed solution is CAN FD, which enables larger data frames and higher transmission speeds. However, the originally envisioned backward compatibility has not been achieved.
The Bandwidth Issue
The demand for more bandwidth is the primary motivation for upgrading the SAE J1939 Standard from Classical CAN (J1939-21) to CAN FD (J1939-22). Improved bandwidth is essential to accommodate the growing complexity and number of ECUs in a diesel engine network. Modern ECUs can handle increased communication addressing issues such as functional safety and security, which require additional payload for signature and encryption.
The expectation is that traditional methods based on existing components will not provide the desired increase in bandwidth, neither in the short nor long term. Alternative solutions may involve increasing the CAN baud rate to over 500 kbps, but this would restrict the physical network length. Optimizing the efficiency of the current data transfer would necessitate new protocol features, potentially compromising backward compatibility.
While Automotive Ethernet may offer optimal bandwidth, it fails to address backward compatibility and conflicts with the goal of evolution over revolution.
On the other hand, CAN FD is less complex regarding the physical layer and protocol features and provides a more straightforward migration path, making it more cost-efficient.
What is CAN FD?
CAN FD was developed to enhance bandwidth in automotive and industrial networks. The protocol has reduced delays between instruction and data transfer (latency), bringing application software closer to “real-time” and offering higher bandwidth. Additionally, CAN FD provides greater storage capacity within a CAN Bus data frame.
Classical CAN holds up to 8 bytes of data within the CAN frame, while CAN FD can hold up to 64. This is achieved through a reduction in relative overhead and improvements to software simplicity and efficiency when transmitting large data objects.
CAN FD reduces the number of undetected errors by improving the performance of the CRC algorithm. It is estimated to transmit data up to 30 times faster than Classical CAN.
However, it is incompatible with existing CAN 2.0 networks, preventing the new protocol from operating on the same network as Classical CAN.
CAN FD J1939 at a Glance
The above headline promises more than I can deliver. Online information on the SAE J1939-22 Standard is scarce due to the protocol’s complexity, making it challenging to explain in a few paragraphs.
In general:
- J1939-22 utilizes CAN FD bandwidth through higher data rates and extended payload capacity.
- J1939-22 achieves four to six times the bandwidth compared to J1939-21 at 250 kbps.
- There is an option to use 29-bit or 11-bit CAN message identifiers to shorten the network arbitration time. A subset of 11-bit CAN IDs can be used for proprietary communication.
- Usage of existing Parameter Groups (PG), Parameter Group Numbers (PGN), and Suspect Parameter Numbers (SPN).
- Maintenance of Controller Application (CA) address structure and network management (253 CAs).
- The Transport Protocol (BAM TP) allows the transfer of up to 15,300 bytes with up to four concurrent sessions per SA (Source Address).
- The RTS/CTS TP supports up to ~16.3 Mbytes.
For more information, refer to J1939-22 and CAN FD by Vector – J1939 technology day 2021, which I found helpful but not easy to digest.
The same applies to J1939 Development: Fundamentals, the new ‘J1939 FD’, & Protocol Stacks. This webinar covers a broad overview of J1939, so it is quite lengthy. Move forward to 9:20 for some brief information on J1939 FD. As the presenter states, “J1939-22 is a very complicated and well-written document. You really need to study it to fully understand the concept.”
Consequently, to obtain detailed information, you will need to purchase the official SAE documents:
J1939-17_202012: CAN FD Physical Layer, 500 kbps/2 Mbps – SAE International
US$92.00*
J1939-22_202103: CAN FD Data Link Layer – SAE International
US$159.00*
* Pricing at the time of this writing.
On a Personal Note: What Happened to Backward Compatibility?
Let’s be blunt: The demand for backward compatibility went down the drain.
As mentioned in a previous paragraph, you cannot run Classical CAN and CAN FD on the same network. See also my post, CAN FD on a Legacy CAN Bus Network is Not a Good Idea Due to Compatibility Issues. Furthermore, SAE J1939-22 requires some profound additional protocol features, which were initially considered as compromising backward compatibility.
The proposed solution is for new ECU designs to maintain a single interface for Classical CAN and CAN FD (CAN FD controllers support both modes). This also requires the ECUs to operate both versions of the J1939 protocol and implement automatic detection of the physical layer.
However, this approach does not address implementing existing products into a CAN FD network. All of these products would need a significant overhaul in both hardware and software.
One proposed solution involves supporting multiple networks on the vehicle, some using Classical CAN (J1939-21) and others using CAN FD (J1939-22). However, communication between these networks may require a gateway with complex firmware and added propagation time.
Another aspect is the 2 Mbps data rate, which might lead to issues with existing network wiring or necessitate new wiring concepts. The higher bit rate (from 250/500 kbps to 2 Mbps) may result in significantly increased electromagnetic compatibility (EMC) and electromagnetic interference (EMI) issues. While it may work (superficially) on an existing network, it could also cause data transfer delays due to Controller Area Network (CAN) error detection and recovery.
CAN FD in automobiles is a much smaller, more compact network with higher implementation costs to meet these EMC/EMI requirements. Additionally, the EMC requirements for automotive and construction/agriculture are vastly different. This is one of the main reasons why 250 kbps was initially chosen for J1939 over the higher 500 kbps/1 Mbps used in automotive.
To clarify, I recognize the advantages of using CAN FD over Classical CAN. It is a good concept. However, we must not solely rely on promotional presentations but consider all technical and economic implications.
I also question its advantage over Automotive Ethernet. CAN FD (and its improvement, CAN XL) was developed in response to requests by German automotive manufacturers without any sympathy for the (American) SAE J1939 Standard or Automotive Ethernet.
Also, if one of the suggested solutions is to operate several networks, why not use Ethernet for data-demanding tasks on a separate network and keep backward compatibility alive? The National Marine Electronics Association (NMEA) declined to extend its NMEA 2000 protocol (derived from J1939) by CAN-FD. Instead, it introduced its OneNet Marine Ethernet Networking Standard.
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. To establish a network, you need at least two nodes. That fact applies especially to CAN/J1939, where the CAN controller will shut 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.