The following is an excerpt from A Comprehensible Guide To J1939 by Wilfried Voss.

Even though extremely effective in automobiles and small applications, CAN alone is not suitable for machine automation, since its communication between devices is limited to only 8 bytes per message. 

As a consequence, higher layer protocols such as CANopen for machine control, DeviceNet for factory automation and J1939 for vehicles were designed to provide a real networking technology that support messages of unlimited length and allow a master/slave configuration.

In order to explain higher layer protocol we must refer to the ISO/OSI 7-Layer Reference Model[1] as shown in the picture below.

The standard CAN implementation bypasses the connection between the Data Link Layer and the Application Layer. 

The layers above the Data Link Layer are covered by additional software, which represents per definition a higher layer protocol.

Note: Be aware, whenever you attempt to add software functions between the CAN Data Link Layer and the Application Layer, you will be adding functionalities that are already covered by off-the-shelf available higher layer protocols such as CANopen, DeviceNet and J1939.

To put it in a nut shell, higher layer protocols are necessary, because

• They enable data transport of more than 8 bytes per message
• Embedded Systems may require an appropriate communication model based on Master/Slave configuration
• They provide Network Management (Network Start-Up, Node Monitoring, Node Synchronization, etc.)

The most popular higher layer protocols based on Controller Area Network are:

• CANopen
• DeviceNet
• SAE J1939[2]

CANopen and DeviceNet are mainly used in industrial control applications. CANopen, however, is to a certain degree also suitable for vehicle applications. Both protocols provide powerful and complete protocol features, but it is also safe to say that they are over-engineered, which makes it very difficult to understand them in their entirety.

SAE J1939 is a very ingeniously designed protocol that takes a resourceful advantage of the CAN 29-Bit message identifier. Rather than relying on a myriad of protocol functions, SAE J1939 uses predefined parameter tables, which keeps the actual protocol on a comprehensible level. SAE J1939 is a prime example of good American engineering according to the KISS principle (KISS = Keep It Simple, Stupid!), but it is nevertheless at least as effective as CANopen or DeviceNet.

[1] For more information on the OSI Reference Model refer to:

CertificationZone.com OSI Reference Model Pocket Guideby Howard C. Berkowitz - ISBN: 1890911143

[2] Per standard J1939 does not support a Master/Slave network configuration or Network Management features at the same level of CANopen and DeviceNet, which does, nevertheless, not mean that such functions cannot be implemented at the application level.

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. 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). It is also supported by an extensive programming interface for Windows and Linux/Ubuntu applications, including full C/C++/C# source code for short time-to-market developments.

The strength of the board lies in the fact that the entire SAE J1939 protocol, including all timing requirements, is stored on-chip, thus taking the burden off the main system. 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 main 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 2012/2013), Linux and its derivatives (C++ using Code::Blocks), and Raspberry Pi (C using the standard gcc compiler).

More Information...