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. Compare that to the various Industrial Ethernet solutions (such as Ethernet I/P, EtherCAT, ProfiNet, Ethernet Powerlink, Modbus-TCP, and Sercos III) with its 100 Mbit/sec (and even up to 1000 Mbit/sec) transmission rate, unlimited data packages, and a (virtually) unlimited physical network length.
Given the raw performance data, there appears to be no contest at all. There is nothing better than Industrial Ethernet, one may say. However, that assessment will change, given two easily neglected parameters: 1. The type of application and 2. the budget. These two parameters are closely intertwined and should be taken as one.
For the record, this is not an attempt to boost the image of an older but "inferior" technology (CAN Bus) or denying the strength of Industrial Ethernet. The point is that both come with their strengths and weaknesses, depending on the type of application. CAN Bus is a suitable choice for small-sized controls, i.e., embedded solutions requiring multi-processor communication. Industrial Ethernet's vast performance unfolds specifically in the larger networks for automation and control of production machinery, including production monitoring. These are two different automation worlds, but it is, nevertheless, worthwhile having a closer look at the two "competitors."
What happened to CANopen And DeviceNet?
Are we missing something here? What happened to higher layer protocols such as CANopen and DeviceNet? Aren't they supposed to close the gap between mere embedded solutions and factory automation?
It is fair to say that CAN higher layer protocols such as CANopen and DeviceNet, whose fields of expertise are in larger automation systems, have been overpowered by Industrial Ethernet. Quite frankly, in my very personal opinion, CANopen and DeviceNet are dead-in-the-water technologies when it comes to new developments. Yes, there is a significant number of legacy applications that provide some life-support, but the days for CANopen and DeviceNet are clearly numbered. These two protocols are, in terms of performance for distributed control, devoured by Industrial Ethernet.
CANopen and DeviceNet were designed to overcome the disadvantages of CAN, specifically implementing network management (for instance, mere CAN does not support node IDs) and extending the available data size. They still can't overcome the limited physical network length, and they have a tremendous impact on the bandwidth. In fact, in the worst-case scenario, the effective bandwidth can be as low as 25%, meaning only 25% of the information transmitted is actual data. Combine that with a maximum baud rate of 1 Mbit/sec...
As a consequence, it requires tremendous software development and design efforts to squeeze a suitable performance out of CANopen and DeviceNet. While Industrial Ethernet does have its own challenges in regard to careful network design (specifically the prudent implementation of routers or hubs), it does not come with the headache of network length and bandwidth considerations and, per default, saves a great deal of investment during the design and implementation phase. Industrial Ethernet also offers new perspectives for the manufacturing process that were not possible with CANopen and DeviceNet, specifically the access and transmission of production information.
The only higher-layer protocol that will survive the attack of Industrial Ethernet is the SAE J1939 protocol, which performs happily and productively with a standard baud rate of 250/500 kBit/sec. But, after all, SAE J1939 was designed for heavy-duty-vehicle networks, not for industrial automation (and its design is much more effective than that of CANopen and DeviceNet).
For the Beginner: What is CAN?
CAN is a two-wire, half-duplex, high-speed network system that is far superior to conventional serial technologies such as RS232 in regard to functionality and reliability because it prevents message collisions and provides excellent error detection and recovery.
For the longest time, the major misconception about Controller Area Network (CAN Bus) was that it is merely used in automobiles. The truth is, CAN, since its introduction in 1986, proved to be a robust, versatile and straightforward technology and, consequently, CAN found its way into all areas of applications where microprocessors need to communicate with each other.
Along with its undeniable use in automobiles, CAN Bus applications do not only include industrial automation tasks, but any application where distributed control is advantageous and/or a serial bus system will eliminate excessive wiring. CAN proved to be superior to any other field-bus system in regard to low cost, the ability to function in a challenging electrical environment, a high degree of real-time capability, excellent error detection and fault confinement capabilities and, almost contradictory to the previously mentioned features, ease of use.
CAN was designed with real-time requirements in mind, and even with its low 1 MBit/sec baud rate and a maximum data length of 8 bytes, it can easily beat a 100 MBit/sec TCP/IP connection when it comes to reaction times, error detection, error recovery, and error repair. However, CAN is limited to a physical network length of roughly 40 meters (~120 feet) at 1 Mbit/sec.
For the Beginner: What is Industrial Ethernet?
The term “Industrial Ethernet” needs further clarification as it may be interpreted as mere “Industrial-Strength” Ethernet. I use the term in reference to “Real-Time Industrial Ethernet” (For many engineers in the automation industry, “Industrial-Strength” is not possible without “Real-Time”).
To explain Industrial Ethernet, we need to compare it to Standard Ethernet, a.k.a. Ethernet TCP/IP:
The simple and effective design of the standard Ethernet TCP/IP protocol has made it the most popular networking solution at the physical and data link level, especially for general-purpose office networks. With high-speed options and a variety of available media types, Ethernet TCP/IP is efficient and flexible.
These factors, and the lowering cost of Ethernet hardware, have made Ethernet an increasingly attractive option for industrial networking applications. Also, Ethernet offers the possibility of a level of standardization and interoperability that has, until recently, remained elusive in the industrial field.
However, the unpredictable nature of Ethernet TCP/IP’s timing has long been a drawback for many industrial network applications, specifically those with real-time capability requirements. Yet, as the overall cost vs. performance has improved over time, industrial users have developed methods to overcome the apparent shortcomings.
The implementation of additional Real-Time Data Exchange protocol layers (i.e., add-on software) incorporated features such as prioritization, synchronization, and other techniques to ensure the timely delivery of messages. Also, the segmentation of networks through intelligent Ethernet Switches resolves the problem of bus congestion and message collisions. Some protocols, such as EtherCAT®, ProfiNet V3, and Sercos III, go even further by modifying the physical layer.
Like Ethernet TCP/IP, Industrial Ethernet supports a 100 Mbit/sec (and even up to 1000 Mbit/sec) transmission rate, unlimited data packages, and a (virtually) unlimited physical network length. However, unlike CAN, Industrial Ethernet requires increased hardware and software resources.
The OSI Reference Model
The OSI Reference Model is at the heart of all serial networking technologies, including Controller Area Network and Industrial Ethernet. The reference to the model is helpful when it comes to a comparison of networking technologies, especially the degree of the OSI Model implementation.
The Open Systems Interconnection Reference Model, or OSI Model for short, is a layered, abstract description for communications and computer network protocol design. The model describes and standardizes the data transfer between networked devices in an open architecture.
In layman’s terms, the OSI Reference Model describes how data from a transmitting application is processed before it reaches the receiving application.
Layers 1 through 4, also called the lower layers, are network-oriented. Layers 5 through 7, also called the upper layers, are application-oriented.
Next, let's have a look at how standard Ethernet TCP/IP refers to the OSI 7-Layer Model:
Without going into all details of TCP/IP, the above image effectively demonstrates the implementation of the OSI Model into TCP/IP. The downside to standard Ethernet TCP/IP is that it does not support the real-time requirements as demanded by most industrial applications. Notably, the CSMA/CD and UDP components are a drag in terms of real-time performance (i.e., the lack of determinacy).
In simple terms, Industrial Ethernet is Ethernet TCP/IP enhanced by add-on software, so-called Real-Time Data Exchange modules, to address the non-deterministic features of Ethernet TCP/IP and hence accomplish real-time control.
There are two different approaches, one with mere addition of real-time data exchange software modules; others even go so far as to modify the physical layer.
In stark contrast, a CAN Bus implementation is far more straightforward than Industrial Ethernet, meaning that, despite its technological shortcomings, it is effortless and inexpensive to implement.
The standard CAN Bus implementation bypasses the connection between the Data Link Layer and the Application Layer to save on valuable memory resources by minimizing the overhead and, as a result, gaining performance as needed for embedded solutions with limited resources. While this concept may appear inferior to other protocols, including Industrial Ethernet, Controller Area Network is an ingenious solution for implementing real-time capabilities on a serial bus designed for embedded solutions.
Layers 3 through 6, i.e., all layers above the Data Link Layer, require additional software resources, which are provided by higher layer protocols such as CANopen, DeviceNet, and J1939.
What About CAN FD And CAN XL?
As of this day, CAN FD and CAN XL have no impact on industrial automation, and the conclusion of this post does not change. Both CAN technologies were suggested by German automakers due to the challenges that come with the design of electric and autonomous vehicles.
CAN FD was created to provide increases in bandwidth within automotive networks. The CAN FD protocol has taken application software closer to "real time" through the minimization of delays between instruction and transfer of data (latency) and higher bandwidth. CAN FD provides more storage capacity in the CAN Bus data frame. While classic CAN can hold 8 bytes of data within the CAN frame, CAN FD can hold up to 64.
CAN XL supports 10Mbit/s on CAN and packet sizes of up to 2048 bytes, and thus can transport Ethernet packets over CAN.
CAN FD is still in the process of being integrated into CANopen (I still consider CANopen a dead-end for new developments). To worsen matters, CAN FD is not backward-compatible to "Classical" CAN, preventing implementation into existing system designs.
CAN XL, at the time of this writing, is still far from being released. By the time, CAN XL effectively reaches the automation market, it will be considered obsolete compared to improved and thus much more powerful Ethernet technologies. In the meantime, I will be waiting for CAN-SCFE (Supercalifragilisticexpialidocious).
Controller Area Network (CAN) and Industrial Ethernet (such as Ethernet I/P, EtherCAT, ProfiNet, Ethernet Powerlink, Modbus-TCP, and Sercos III) are two very different networking technologies, and each one is very suitable for their respective niche in the automation world.
CAN Bus is a suitable choice for small-sized controls, i.e., embedded solutions requiring multi-processor communication. CAN requires only small resources in terms of CPU power. Even a simple 8-bit microprocessor can handle the CAN Bus communication without problems. If your application is budget-sensitive, there is no better choice than Controller Area Network. Even a low-cost RS-232/RS-422/RS-485 solution will not be as cost-effective. On top of that, CAN provides excellent features such as error detection, error recovery, and prevention of message collision. In compact multi-processor systems, CAN will reduce the amount of wiring significantly (compared to, for instance, a dual-ported RAM), thus increasing reliability and reducing maintenance and troubleshooting efforts.
Industrial Ethernet's vast performance unfolds specifically in the more extensive networks for automation and control of production machinery, including production monitoring. Its performance and decreasing hardware costs make it a fierce competitor (if not a killer) of other established networking protocols, including (but not limited to) CANopen and DeviceNet. It requires significantly larger hardware resources than Controller Area Network, but the result is well worth the expense.
Industrial Ethernet will reduce development and design costs compared to CANopen and DeviceNet because it does not require any time-consuming performance tweaks.
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 [...]
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 [...]