CANbus - all you need to know | Controller Area Network | DesignSpark

What is CAN bus?

Controller Area Network (CAN bus) is an internal communications network initially developed by Bosch as a standard for communication between microcontrollers and devices inside automobiles. In 1993, the International Organization for Standardization adopted CAN bus as an international standard, and CAN bus has since become an increasingly popular standard in the automotive industry and beyond. “Bus” is a term that refers to any communications system that can move data between one component and another.

What does it do?

CAN is message-based and is a protocol that allows microcontrollers to communicate without the need of a host computer. The signal is sent through a single twisted wire that connects to various devices within the application. CAN bus is widely used not only in automation but aviation, automation and the embedded industry. Think of large automated systems such as factories that run hundreds of automated machines that need a simple effective way of communicating with each other but without the need for a computer in every single device. A CAN bus network allows this to happen.

Identifiers within each message are used to determine the intended recipient(s) of messages transmitted through the CAN bus. The result is an efficient system that requires little wiring, no central host computer, and that can handle a vast number of connected devices.

CAN bus uses two dedicated wires for communications, CAN high and CAN low and is not sensitive to spikes, electrical fields or other noise, making the CAN bus a highly reliable choice for network communications or mobile equipment. In fact, CAN bus is so reliable and secure it is being adopted increasingly more across many platforms despite the technology being around since the 1980s.

The Hardware

Hardware with CAN bus comes in all shapes and sizes and different purposes for many industries. But what if you want something for a proof of concept or one-off design and no MOQ? Taiwanese manufacturer Innodisk may just have the solution you are looking for. Innodisk has a range of embedded peripherals with CAN bus for communication, storage and testing. Embedded peripherals are designed to be a cost-effective solution without the need for a huge motherboard, more of a plugin a play, add on option.

Embedded Peripherals have many different types of expansion slots such as LAN, CAN, PoE, Serial, USB and RAID enabling the connection of a multitude of different devices.

CAN - the next level

There is a wide range of CAN-based higher-level protocols, many of which are specialized for specific industries or even for use by a single manufacturer. Some of the most common standardized higher-level protocols are CANopen and SAE J1939.

CANopen

While CAN bus started as a standard for in-vehicle communications systems, it has since grown to become a popular standard for use in automation. CANopen is developed and supported by CAN in Automation (CiA)—an international non-profit organization for CAN users and manufacturers—through its CANopen Interest Group

CANopen devices, usually referred to as nodes, are all required to have an object dictionary— a standardized table that stores data pertinent to the node and its operation. For instance, each CANopen node’s object dictionary contains an entry for its device type used for identification purposes. Other object dictionary indices may contain information such as sensor readings or process states, e.g., whether or not a signal is currently being transmitted or if a device operation is currently active.

CANopen nodes can communicate with each other according to three different architectures or communication models, namely master/slave, client/server, and producer/consumer, which in turn determine the relationship between the nodes.

In a master/slave communication model, one of the CANopen nodes sends and requests data from the "slave" nodes, which essentially just follow the instructions from their "master." In a client/server model, meanwhile, "clients" read or write data from "servers." Lastly, in a consumer/producer communication model, "producers" broadcast data to all other nodes, i.e., "consumers" of the producer's data.

Additionally, CANopen nodes communicate through different communication services, with each communication service suitable for communicating particular commands. For example, the Network Management communication service is used to communicate the desired state of CANopen nodes (e.g., turning all motors off or starting a sensor) Another critical communication service is Heartbeat, which nodes use to regularly transmit a “heartbeat” to other nodes, thereby indicating that they are still active

Messages transmitted by CANopen nodes follow a standardized message format that makes it clear to receiving nodes which node is transmitting the message, how long the message is, as well as the actual data transmission (message). This standardization applies to all CANopen messages, no matter what communication models or communication services are used.

Figure 1: CANopen messages follow a standardized format that identifies the source of the transmission and relays up to 64 bits of data per transmission.

The first part of a CANopen message contains an 11-bit long CAN-ID, which identifies the transmitting device, followed by a control bit. This part of the message is generally referred to as the communication object identifier or COB-ID. The next four bits tell receiving devices how long the message is (i.e., the data length) so that they can determine at which point in a transmission the message ends. The last part of the CANopen message is the actual data, which can be up to 8 bytes (or 64 bits) long. The actual length of the message depends on what type of data is transmitted.

CANopen is designed for use in motion-oriented machine control systems and is now widely used within automation, such as robotics, factory conveyor belts, and industrial machinery. However, CANopen is not limited to automation; it is also used within sectors such as healthcare and the automotive industry. With the growing trend of smart factories with a high degree of automation, CAN bus and the CANopen protocol are likely to only play a more significant role in the future.

J1939 protocol

The other popular higher-level protocol is SAE J1939. J1939 is a vehicle standard for communication that is based on the CANbus automotive protocol, which is defined by the Society of Automotive Engineers (SAE). The J1939 standard is based on the CAN 2.0B specifications with a baud rate of 250Kb/s. A J1939 standard system will deliver reliable and high-speed communication and is designed for use in harsh environments.

J1939 expands on the CANbus protocol by establishing a standard for the higher-level layers in the communication network. The J1939 system allows for up to 30 nodes or Electronic Control Units (Refer to the picture below for the breakdown of the J1939 message format). The message identifier is designed to be able to differentiate between destination-specific and broadcast formats. This is done by predefining ranges for each format. In other words, the message sent from one ECU can either be broadcasted to all other ECUs (a request for information, etc.) or will be sent to a specific ECU connected to the system.

The J1939 standard is based on the CAN 2.0B specifications with a baud rate of 250Kb/s. Other than the message identifier, the message structure is the same, however, the CAN specification only supports up to eight bytes of data per message. J1939 solves this by allowing for larger data amounts through higher-level transport protocols. The message is sent in multiple packets, for a maximum size of 1785 bytes.

Due to the robust and stable nature of the J1939 protocols, it is suited for a wide variety of applications: Heavy-duty vehicles (in-vehicle network), Truck-Trailer Connection, Fleet Management Systems, Marine Navigation Systems, etc.