To say it upfront, the difference between SAE J1939 and CAN Bus (Classical CAN and CAN FD) has all to do with so-called "Higher Later Protocols (HLP)," and SAE J1939 is one of them. I have written a post about HLPs (see: Guide to SAE J1939 - CAN Bus Higher Layer Protocols), but I would like to take a different angle here.
In terms of applications, Classical CAN and CAN FD apply to passenger cars (including OBD-II diagnostics) and small embedded systems.
SAE J1939 applies to diesel engines, primarily for trucks and offroad vehicles, including agricultural equipment using ISOBUS, a derivative of SAE J1939. However, diesel engines apply also to trains, ships, tanks, etc. Another derivative of SAE J1939 is NMEA 2000 for maritime applications.
From a technical standpoint, I will start with the ISO/OSI 7-Layer Model, as demonstrated in the following image. Without going into all details, it is apparent that the CAN Bus technology bypasses several layers that are mandatory for network management.
However, that is not necessarily a disadvantage since this circumstance allows the CAN Bus to operate at a low cost and with minimum software resources at high performance as required for numerous embedded applications. Nevertheless, bypassing these layers results in a few restrictions.
The CAN Bus technology does not support node IDs. Instead, CAN focuses on message IDs, meaning each node in the network must know exactly which message ID it needs to read or transmit without caring where it came from or where it goes. It may appear restrictive, but it saves plenty of software resources. On the other hand, it requires good housekeeping of message IDs. Consequently, the CAN Standard does not allow two or more nodes to transmit the same message ID because a message collision could result in unforeseen consequences. However, while the CAN Standard ISO 11898 strictly forbids the use of identical message IDs, it does not address how it handles a violation of the rule.
Classical CAN is limited to eight bytes per data frame, while CAN FD can hold up to 64 bytes. However, the use of CAN FD for SAE J1939 is questionable, specifically for legacy applications, since Classical CAN and CAN FD cannot share the same bus. There are activities to incorporate CAN FD into SAE J1939, but I wouldn't hold my breath at this time.
SAE J1939 represents a very ingeniously designed protocol, which uses Classical CAN as its hardware layer. SAE J1939 adds software resources on top of Classical CAN to implement network management, including node IDs, address claim procedure, message lengths of up to 1785 bytes, and more.
Note: The SAE J1939 Standard comes in the form of several documents indexed from SAE J1939-1x to SAE J1939-7x in reference to the ISO/OSI 7-Layer Model.
SAE J1939 is a prime example of good American engineering according to the KISS principle (KISS = Keep It Simple, Stupid!). Consequently, SAE J1939 is more effective (higher bandwidth) than other higher layer protocols such as CANopen or DeviceNet.
SAE J1939 Gateway Module With USB Port, RTC, MicroSD Memory Card
The JCOM.J1939.USB processor board is a high-performance, low-latency vehicle network adapter for SAE J1939 applications. It allows any host device with a USB COM port to monitor SAE J1939 data traffic and communicate with the SAE J1939 vehicle network.
The board supports the full SAE J1939 protocol according to J1939/81 Network Management (Address Claiming) and J1939/21 Transport Protocol (TP). In addition, an extensive programming interface supports Windows and Linux/Ubuntu applications, including complete C/C++/C# source code for short time-to-market developments.
The board's strength lies in the fact that the entire SAE J1939 protocol, including all timing requirements, is stored on-chip, thus taking the burden off the central system (PC). The board uses a USB COM port to communicate with the main system, i.e., all data transfer is handled through a standard COM port access. The communication protocol between the board and the primary system is well documented and thus allows a porting to any computer system with a USB connection. Working source code libraries exist for Windows (C# under Visual Studio 2102/2013), Linux and its derivatives (C++ using Code::Blocks), and Raspberry Pi (C using the standard gcc compiler).
CAN FD Data Logger For CAN Bus Monitoring, DBC Logging, Message Filtering, SAE J1939 Logging, And Trigger Events
Influx Big Data Solutions introduces their ReXgen 2 CAN Bus logger, one of the smallest, compact, robust, and powerful handheld CAN Bus data recorder available in the market today. The device is targeted at applications requiring CAN 2.0 and CAN FD data recording capabilities. The data logger comes with a freely distributable ReXgen data logger configuration [...]
The Telematics Gateway from iWave represents a vehicle diagnostics system for monitoring critical vehicle parameters from any place. The device supports four CAN Bus interfaces, including CAN FD, and is suitable for heavy-duty trucks, off-road vehicles, emergency vehicles, and vessels.The gateway utilizes parameters such as location, working duration, engine performance, and engine parameters that require continuous [...]
Multi-Functional Telematics Gateway Processes SAE J1939, ISOBUS Parameters For Predictive Maintenance
The CANUp telematics gateway by Technoton represents a multi-functional telematics unit for use in advanced machinery telematics systems. Advanced machinery includes mobile and stationary objects, which have many operation monitoring parameters for engines, power generators, boilers, various additional equipment, and other assemblies. The core features of the CANUp telematics gateway include: Reading over 10,000 machine operation parameters, thus the [...]
The ESP32 Series of modules by Espressif supports the integration of WiFi, Bluetooth, and Bluetooth LE for a wide range of applications, most prominently for IoT (Internet of Things). For instance, using WiFi ensures connectivity within a large radius. Using Bluetooth allows the user to easily detect (with low-energy beacons) a module and connect it to [...]
The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss. Certain parameter groups may require more than the eight data bytes supported by the CAN standard. The SAE J1939 standard, namely the Transport Protocol Function, supports message lengths up to 1785 bytes. If a program group requires more than eight data bytes (9…1785 bytes) and [...]
The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss. For internal purposes, the parameter group number is extended to 24 bits = 3 bytes, where the most significant 6 bits are always set to zero. Each ECU must accomplish this process individually; this procedure is not part of the CAN standard. To compile [...]
The CANUp telematics gateway by Technoton couples the functionality of two vehicle data interfaces, a digital-to-analog converter and an online GPS tracking device. The gateway scans and automatically parses 10 000 SAE J1939/71 and ISOBUS parameters and transmits selected data to a web-based telematics server or by email/SMS to a user. It applies edge computing algorithms for onboard [...]
HMS Networks introduced its Anybus Wireless Bolt CAN gateway, providing CAN Bus communication via WiFi or Bluetooth. The device builds on the success of Anybus Wireless Bolt, which is applied to wireless Ethernet access. Like its predecessor, the gateway for bolt-on-machine mounting is suitable for heavy-duty machinery and demanding industrial applications. Applications include warehouse installations and AGVs (Automated [...]
Axiomatic Technologies introduced their AX184200 20 PT1000 RTD scanner with CAN Bus (SAE J1939) connection. It features rugged packaging and watertight Deutsch IPD connectors for an IP67 rating. The system does not require additional programming or configuration. The scanner monitors 20 2-wire PT1000 inputs from a diesel engine and forwards the temperature information to the engine control [...]