.png)
The initial thought behind this article was to outlay a comparison between the CAN bus and
Automotive Ethernet. But with some research, study and a bit of digging, one can clearly understand these technologies belong to completely different domains, in terms of almost every functionality, except a few.
So, comparing both might not be wise? Instead, this article will give you an overview of both the technologies and try to conclude that these are better used together to achieve more incredible technological advancements in the automotive industry.
Let's discuss both technologies separately, and we will plot a complete feature detail in the end.
CAN: Robert BOSH GmbH originally invented Controller Area Network or more popularly known as CAN Bus, in 1983, and about ten years later it was fully functional and was being used in various automobiles.
CAN bus was optimized for real-time control systems to support up to 53million+ priority levels. It is a multi-master message broadcast system that supports speeds up to 1 Mbps (CAN) to 10Mpbs (CAN FD). Which can somewhat be considered low, but that was the whole point behind designing CAN. CAN does not send large data blocks between the nodes, unlike USB and Ethernet. Or does not support point-to-point communications under a master node's control, whereas it broadcasts its messages to the entire network.
It can easily house multiple nodes, communicating on the same bus where collision is resolved in real-time, making it possible for CAN to support 100% bus load without delays, resulting in data consistency throughout the network.
The above image clearly explains how data transfers and collisions are processed in a CAN network. If two or more nodes transmit data simultaneously, the one that wins the arbitration gets to complete the transmission, whereas the node that looses drops it and waits for its turn. For more explanation on arbitration and CAN bus/CAN FD, please visit our previous blogs:
Ethernet: Ethernet came into existence way before CAN; developed at Xerox PARC between 1973 and 1974, it was already supporting 3Mps of bus load by then, which has now increased multi-folds, i.e. up to 400 Gbps. Ethernet is a communication protocol for a local area network, a wired technology for connecting devices to communicate.
Ethernet uses multiple wired technologies like co-axial cable to twisted pair to fibre-optics cable. This only offers point-to-point communication, where stations communicate by sending data packets to each other. Each station is distinguished based on its unique address. A link-level communication is established using the address of the source and destination. The receiver only accepts the packet addressed to it, and the rest is ignored. But to make multiple nodes functional using Ethernet involves installing repeaters/routers/ switches etc., which usually increases the cost of the infrastructure more.
But, even if we ignore the cost aspect, still Ethernet does not work in real-time, and there is no provision to take care of the collisions between the transmitted data. As the below figure explains, the nodes are timed randomly to send their data onto the Ethernet, and if in case a collision occurs, the transmission stops, and that data is lost.
The moment collision occurs, both the nodes involved in the collision drop the transmission and then all the nodes increase their wait time (randomly) and try to send the data again. This might again result in a collision and cause further delay. The major disadvantage is that this waiting time is random, and there is almost nothing to rectify the collision in real-time, until or unless you use switches, as each port on a switch represents a separate collision domain.
Hence, Ethernet is efficient without switches only if there is no collision; otherwise, if the bus load is high, multiple collisions might occur, leading to increased wait time and the delay can increase significantly due to these collisions. Ethernet most necessarily requires switches to route traffic and it is not possible to add or remove nodes unless the switch has a spare port. The nodes can not be directly connected to the bus.
And talking about Automotive Ethernet, it is already in use, and in the coming future, one can not ignore the fact that it is a must requirement. As the bandwidth requirements increase, with the increase in the amount of data needed to be transmitted, Automotive Ethernet will find itself implemented for more and more applications inside automotive circuitry. The systems such as ADAS (Advanced Driver Assistance Systems), which uses multiple cameras for proper functionality, and numerous LIDAR and RADAR sensors, hi-tech infotainment systems generate incredibly huge data, up to Gbps and Tbps. To process this data with high speed in real-time and with minimum latency Automotive Ethernet is best suited.
Also, the automation that the vehicles of the future aim to achieve may well use Automotive Ethernet as a backbone. But Ethernet has drawbacks, including a more expensive physical-layer interface, the costs associated with required switches, controllers and complications surrounding EMI and EMC issues with two-wire unshielded twisted-pair (UTP) Ethernet. Moreover, Ethernet communication is non-real-time and non-deterministic. And this is majorly the reason why Automotive Ethernet will not be able to replace CAN entirely.
Regardless of many advantages, Automotive Ethernet falls short compared to the CAN bus, and here is why?
It is evident from the above table that both the technologies have some outstanding features to offer, but both do have shortcomings as well. CAN, on one side, has become an integral part of the automotive industry. Its high tolerance for noise, support for native multicast and broadcast, built-in frame priorities, non-destructive collision resolution and efficient traffic handling have made it quite popular. It is easy to use and cost-effective. On the other hand, Ethernet tends to be a more expensive physical-layer interface, requires costly technology for functioning like routers and switches, and has EMI and EMC issues. Moreover, communication is non-real-time and non-deterministic.
CAN/CAN FD can only support up to 1 Mbps-10Mbps of bus load, and the bandwidth support is very low. In contrast, Ethernet supports GBs and Tbs of busloads and higher bandwidths. But, CAN has negligible latency, and Ethernet lags in that.
So, it will be wise not to see these two technologies competing with each other but those that complement each other. It is already evident that the automotive industry can benefit tremendously from both of them if used together. Vehicles are evolving to become more hi-tech and advanced and these advancements will sure increase the load of data from the sensors, cameras, infotainment systems etc. Both CAN and Ethernet as technologies can complement each other to handle the high-end electronic control units (ECUs)