Additional Information

Site Information

 Loading... Please wait...

Blog

Controller Area Network (CAN Bus) Tutorial - Higher Layer Protocols

Posted by Wilfried Voss on

The following is an excerpt from  A Comprehensible Controller Area Network by Wilfried Voss.

A Comprehensible Guide to Controller Area Network

Even though highly influential in automobiles and small applications, the CAN Bus technology alone is not suitable for machine automation since its communication between devices is limited to only 8 bytes.

Consequently, higher layer protocols such as CANopen for machine control, DeviceNet for factory automation, and SAE J1939 for offroad vehicles (specifically diesel engines) were designed to provide a full networking technology supporting messages of unlimited length and allowing a master/slave configuration.

To explain higher layer protocols, we must refer again to the ISO/OSI Reference Model as shown in the following image.

The standard CAN Bus implementation circumvents the connection between the Data Link Layer and the Application Layer. The layers above the Data Link Layer are accomplished by adding software, representing a higher layer protocol per definition.

For more information on the OSI Reference Model refer to:

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

To put it in a nutshell, 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.).

To emphasize the point, whenever you attempt to add software functions between the CAN Data Link Layer and the Application Layer, you will be adding functionalities already covered by off-the-shelf available higher layer protocols such as CANopen, DeviceNet, SAE J1939, or NMEA 2000.

CANopen

  • Is suited for embedded applications
  • Was originally designed for motion control
  • Was developed and is maintained by the CAN-in-Automation User Group

Like CAN, the CANopen standard is the responsibility of CiA (CAN-in-Automation). For further information, refer to http://www.can-cia.org.

DeviceNet

  • Is suited for industrial applications (floor automation)
  • Was developed by Allen Bradley/Rockwell
  • Is maintained by Open DeviceNet Vendor Association (ODVA)

The DeviceNet Specification, consisting of two volumes: Volume One - Common Industrial Protocol (CIP) and Volume Three- DeviceNet Adaptation of CIP, is available only for ODVA (Open DeviceNet Vendor Association) members.

For further information, refer to http://www.odva.org.

SAE J1939

  • Defines communication for vehicle networks (trucks, buses, agricultural equipment, etc.)
  • Is a standard developed by the Society of Automotive Engineers (SAE)

The SAE J1939 Standards Collection can be found exclusively on the Web at http://www.sae.org.

The Society of Automotive Engineers (SAE) Truck and Bus Control and Communications Subcommittee has developed a family of standards concerning the design and use of devices that transmit electronic signals and control information among vehicle components. SAE J1939 and its companion documents have quickly become the accepted industry standard and the Controller Area Network (CAN) of choice for off-highway machines in applications such as construction, material handling, and forestry machines.

NMEA 2000

NMEA 2000 is a marine networking standard designed and managed by the National Marine Electronics Association (NMEA). The NMEA is an association of marine electronics manufacturers, dealers, and technicians. NMEA 2000 is a derivative of SAE J1939, i.e., its functionality is identical to SAE J1939 but has some added features and it uses different data definitions (PGNs).

For more information, see https://www.nmea.org.


PiCAN 2 - CAN Bus Interface for Raspberry Pi

PiCAN 2 - CAN Bus Interface for Raspberry Pi

This PiCAN2 board provides Controller Area Network (CAN) Bus capabilities for the Raspberry Pi. It uses the Microchip MCP2515 CAN controller with MCP2551 CAN transceiver. Connection are made via DB9 or 3-way screw terminal.

There is an easy-to-install SocketCAN driver, and programming can be accomplished in C or Python.

The PiCAN board is fully compatible with the new Raspberry Pi 4 Model B.

More Information...

Quick Reference: Controller Area Network - CAN Bus - Versus Industrial Ethernet

At first glance, a comparison of the two networking technologies, Controller Area Network (CAN Bus) and Industrial Ethernet may appear as a battle between David and Goliath. On one side, you have the clear underdog, CAN Bus with its 1 Mbit/sec baud rate, its limited network length, and a maximum data length of 8 bytes per message. [...]

Read More »


Industrial Ethernet Evaluation Board Supports Ethernet/IP, EtherCAT, Profinet, Profibus, Modbus, And More

Renesas announced their RX72M networking solutions, which reduce the development efforts while using the RX72M for slave equipment for industrial networks; they are available for motor drives at robot terminals, small programmable logic controllers (PLCs) and remote I/O, and more.The RX72M solution comprises of an evaluation board with operating system, middleware, and sample software supporting around [...]

Read More »


Guide To SAE J1939 - CAN Bus Higher Layer Protocols

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 [...]

Read More »