Understanding CAN Bus

If nobody has said this before, then let me be the first. Industrial communication is NEVER a clear-cut subject. Competing standards must often be merged together into a single system, and sometimes one standard or protocol can be simplified and turned into yet another system with a different name. One term that arises occasionally is CAN bus, a control system standard that appears in various industries with specific applications.

There seems to be no end to the protocols and standards used within the scope of industrial systems. Just to name a few: Modbus, RS-232, RS-485, PROFIBUS, PROFINET, DeviceNet, ControlNet, Ethernet, Industrial Ethernet, Internet, EtherCAT, Fiber Optic, USB ... you get the picture.

The history of digital communications is complex since many standards appeared from various brands for specific equipment. Then, over time, that equipment had to be networked with other competing standards. In some cases, a third standard may have appeared as a blend of two others, or as a simplification of one standard. 

In still other cases, an older communication channel is configured in a special way to transmit the data over a different type of cable. This last example appears quite often when a device-level standard, such as Modbus, is attached to an internet protocol packet so it can be shared between modern TCP/IP devices.

 

The CAN Bus Standard

One of the less common (yet still present) standards is one called CAN bus. This stands for “controller area network” with bus referring to the physical wires allowing the interface.

Since it’s a ‘standard’, the rules of CAN bus dictate a few elements: the voltage of the signals, the speed of data transmission, the direction and coordination of the signals between devices, and the structure of data and device ID sent down the wires.

The final purpose of the signals is absolutely not defined by the standard, so it makes a good platform to connect various sensors and devices which are sharing totally different kinds of data. The CPU must figure out what to do with the data it receives from each device.

 

Figure 1. CAN-Frame in base format with electrical levels without stuffed bits. Image courtesy of Endres [CC BY-SA 3.0]

 

A Brief History of CAN Bus

This standard is actually quite familiar to auto mechanics, perhaps more so than any industrial electrician. For the most part, an industrial electrician does not really need to understand the rules behind the standard. General knowledge of the CAN bus is usually sufficient.

The standard was initially developed by the Bosch company, and it was designed exactly for the challenge of networking many sensors in a vehicle system. Since all the sensors are on the same set of wires and the processor figures out what to do with the data, this is an excellent future-proofed system. Perhaps at the beginning, it was not meant to handle automatic lane change or parallel-parking assist, but it has lived up to the task because of its versatility.

In the terms of an automated industrial facility, CAN bus is the platform used to construct the DeviceNet standard by Allen-Bradley. DeviceNet is a very common standard in modern facilities, but the CAN bus itself is rarely seen in its original form. But the similarity is immediately recognizable as they share the same names and purposes of the set of physical wires, although connectors may be different between systems.

 

How Does CAN Bus Work?

An auto mechanic will readily recognize the common four-wire connections that are used in many vehicle sensor applications. O2, thermal, crankshaft sensors, and many others will contain those four wires. These consist of power and ground, as well as wires that will be named high and low, sometimes CAN high and CAN low.

In comparison, DeviceNet also has a power, ground, and high/low set. In addition, they may contain a shield ground for noise immunity, which is always a legitimate goal. 

The two wires are referred to in this case as a differential pair. This provides greater immunity against noise. A terminating resistor is usually located in each node (device) or at each end of the wired network — again, similar to the terminators at the end of a DeviceNet trunk line. This resistance prevents signal reflection which can distort the signal and slow down communication since a re-send of the data is necessary.

 

Figure 2. A diagram of a CAN bus node. Image courtesy of EE JRW [CC BY-SA 4.0]

 

In a CAN bus network, each device is monitoring the line and sending data in a sequence. Every device has a built-in ID which is not only contained in the data transmission but also contained in the CPU of the device so that each device does not "talk over" the others. Imagine a group of radio operators conducting a check-in. One person can conduct the roll-call. This is called polling. In the case of data like in a CAN system, each radio operator has a number “Person 1, checking in”, then “Person 2, checking in”. This is called sequential arbitration.

When the complete string (frame) of data arrives at the main controller CPU, only part of it actually provides sensor information. For a thermal sensor, the data might be a variable value. For a switch, on the other hand, it may be just a single on/off discrete bit. For a standard vehicle OBD system, anyone can find a complete list of parameter IDs (PIDs) on the internet. Most lists provide a formula for translating the basic string of bits into an actual real-world value.

 

CAN Bus as a System Building Block

CAN bus may not be the most common industrial networking standard, for sure. However, the background of this standard provides the basis for other more common systems. A simple understanding of differential voltage systems and data frames can help no matter what system of communication is used in your workplace.