CAN or Controller Area Networking was probably one of the first technologies that I learned as a young engineer. In the days of 8-bit, 4 MHz microprocessors, CAN was king. It was an easy way to move data and an easy step up from RS232 serial communications. It’s an important technology to us in automation networking as it has a rather prolific set of offspring that includes DeviceNet, CanOpen, Can Kingdom, and several hundred other offspring all over the world.
CAN is a serial communications standard for intelligent devices to communicate with each other. Unlike many other communication standards that provide fast data rates with thousands or millions of data bytes in a single frame, CAN has a bit rate that maxes out at 1 mega baud. Most industrial applications don’t even need that speed. Most use the lowly 125 Kbaud. And where other standards move thousands of bytes in a single frame, CAN only moves 8 bytes of data.
But where speed and capacity are strengths for many of the other standards, CAN’s strength is its low overhead and simple physical interface. With its small packet size, a frame transmitted at 500 Kbaud with 8 bytes of data is only on the network wire for a quarter of a millisecond. For many control applications, this is plenty fast. Additionally, the microcontroller only needs as little as 4K of program memory and 256 bytes of RAM to support a CAN application. And an underpowered 8-bit micro can do that very easily.
CAN was the brain child of Bosch in Germany way back in March of 1985. The Bosch Company designed it to replace automotive wiring. In the early days of specification version 1.2, CAN messages contained an eleven-bit identifier word providing the capability to address 2047 identifiers. In 1992 CAN Specification 2.0 extended the identifier word size to 29 bits providing up to 56 million unique identifiers. As both specifications are still in use (sometimes on the same wire), the original 1.2 specification is called Part A and the new 2.0 specification is termed part B.
A unique attribute of CAN is that only two of the OSI Reference Model layers are defined, the Data Link Layer and the Physical Layer. The CAN Data Link layer is normally further split into two sub layers, the Physical Signaling sub-layer and the Media Access Control (MAC) sub-layer.
The most important use of CAN to us in manufacturing is DeviceNet. Allen–Bradley (Rockwell Automation) created DeviceNet as an application layer protocol on top of CAN in the 1990s. AB selected CAN as the DeviceNet Physical Layer for a number of reasons including:
CAN has an extremely robust physical layer
CAN is completely open technology and embedded in almost all microprocessors
It uses inexpensive physical components with multiple sources
One of the most extraordinary features of CAN (and DeviceNet) is bitwise arbitration. Bitwise arbitration is the process that CAN uses to prioritize messages without losing any network bandwidth. On a CAN network, “zero” bits dominate “one” bits. CAN devices are synchronized, and each device with a message to send starts transmitting with the first bit of the next CAN frame. As each device transmits a bit, it listens to the bit actually on the network. If a device transmits a one and hears a zero, it knows that there are one or more higher priority devices transmitting a zero and it discontinues transmitting. Nodes with higher priority messages (more leading zeros) never know of any conflicts with lower priority messages. Eventually, the highest priority message – the one with the most leading zeros – is able to fill the frame with its message. All the lower priority devices begin again with the next frame. Using this mechanism, CAN can achieve 100% bus utilization.
If you’re thinking that this is ancient, no longer needed technology, you’d be wrong. Bosch is still actively extending the standard. A few years ago, Bosch released a specification with a flexible data-rate. The new specification is completely compatible with existing CAN.0 networks so new CAN devices can coexist on the same network with existing CAN devices.
CAN bus is also one of five protocols used in the on-board diagnostics (OBD)-II vehicle diagnostics standard. This standard is mandatory for all cars and light trucks sold in the United States and has been since 1996.
Even though we live with data in the Cloud, technologies like CAN continue to be important and will be for a long time to come.