Handing data-intensive lidar and radar processing at the sensor itself can let CAN connections make autonomous vehicle networking more economical.
KENT LENNARTSSON | Kvaser AB
There’s no question that as the autonomous driving capabilities advance, so do the requirements for transmitting large amounts of data. A 2017 paper by Stephan Heinrich, currently a systems architect at Waymo, estimated the bandwidth requirements for an autonomous vehicle. Heinrich figured the four-to-six radar sensors in a car would need 0.1 to 15 Mbit/sec; for the one-to-five lidar sensors, it is 20 to 100 Mbit/sec. The six-to-12 cameras need another 500 to 3,500 Mbit/sec, while the less data-intensive eight-to-16 ultrasonic sensors need less than 0.01 Mbit/sec. The GNSS and inertial measurement unit (IMU) motion sensors need less than 0.1 Mbit/sec. The total sensor bandwidth works out to between 3 and 40 Gbit/sec.
The rapid pace of development in autonomous vehicles, has certainly pushed those numbers up since 2017. In response, autonomous vehicle manufacturers are embracing automotive Ethernet standards that can deliver speeds of 1 GB/sec, and IEEE working groups are developing standards to allow for in-vehicle communication at bandwidths of up to 50 Gbit/sec.
Compared to these high-bandwidth protocols and applications, there’s no question that CAN bus bandwidths can seem limited. The maximum bandwidth for the High-Speed CAN/CAN-FD (ISO 11898-2) bus is 5 Mbit/sec. For low-speed, fault-tolerant CAN (ISO 11898-3) it is 125 kpbs, and for CAN-XL now under development, it is 10 Mbit/sec. These figures bring up an important question: Does the CAN protocol have a place in autonomous vehicles when it doesn’t even have the bandwidth to carry the data from a single 4K camera to a vehicle’s ECU?
Perhaps surprisingly, the short answer to that question is, “Absolutely.” Though CAN’s key limitation is a limited bandwidth, it also has benefits that include built-in reliability and real-time performance, a software/hardware ecosystem that is robust, low power consumption, and good economics.
The CAN bus is built from the ground up for real-time control of essential automotive systems. It’s been used in production vehicles for more than 25 years, and it was developed with that application in mind. In automotive systems, 99.99% reliability isn’t sufficient. If the CAN system controlling a brake pedal failed one out of every 10,000 times a driver braked, CAN would never have seen the widespread adoption it has today.
When the pioneers of CAN first developed the protocol in the early 1980s, they understood this. The thousands of automotive engineers who have contributed to the CAN protocol’s development since then have always kept mission-critical reliability as a core goal of the protocol.
Anecdotally, I often say that the beauty of the CAN system is that it’s almost impossible to crash. In many cases, you can violate the CAN bus and it will still work. While robust operation should never be an excuse for sloppiness, it illustrates the fault-tolerant capabilities at the core of the CAN bus.
In many automotive applications, a delay is just as disastrous as a failure. Going back to the brake example, even a half-second delay between the driver’s input and actuating the brakes from a CAN-controlled pedal could cause an accident.
One of the special things about the CAN protocol is how it resolves data collisions. Like Ethernet and many other protocols, CAN is packet-based. It’s possible that two packets could be sent at the same time and collide. When two Ethernet packets collide, the sending process restarts with a random amount of delay. In the event of a second collision, the random delay time is increased.
In contrast to Ethernet, every CAN packet has a priority level, and the protocol supports up to 53 million priority levels. To understand how this works on a simple level, imagine the CAN network simultaneously sends both a packet to activate the brake pedal and a packet to turn on the windshield wipers. The packets collide, but the brake pedal packet has a higher priority. It goes through without delay or corruption, and the windshield wiper packet comes through shortly after.
There are rules that can be added to the Ethernet protocol that can resolve issues with the protocol’s standard handling of packet collisions. But automotive Ethernet systems with time-sensitive networking tend to be about six times more expensive than equivalent CAN systems. In CAN, those rules are built into the protocol’s foundation.
Tailor-made communications?
It’s tempting to look at intra-vehicle communication and conclude we should start from the ground up to develop a new communications protocol. In my experience, this approach often makes sense only by ignoring the true cost of implementing new communication standards. For example, what about documentation? Software tools, APIs and hardware tools all must be created. And once the vehicle launches, will dealers and mechanics need to buy new hardware for repairs and updates? Ditto for new software and training.
In contrast, the CAN protocol is mature. It has a robust ecosystem of hardware and software tools with wide support in the automotive world. Development of autonomous vehicles using the CAN protocol will resolve many challenges surrounding the use of a more exotic communications protocol.
There are several possible models for implementing CAN communications in autonomous vehicles. Perhaps the most obvious it to limit CAN to low-bandwidth communications. This approach is simple and intuitive. While autonomous vehicles entail transmitting large amounts of data, some systems within even the most advanced autonomous vehicles don’t.
Here, Ethernet handles high-bandwidth communications, like video and lidar, while CAN carries low-bandwidth communications like sending signals to vehicle systems or communicating with IMUs.
The model of dividing tasks between CAN and Ethernet based on bandwidth certainly works. CAN and Ethernet can be easily integrated, and both protocols can perform reliably in this scheme. However, other models for using CAN in autonomous vehicles improve reliability even further.
One is to use distributed processing. Transmission of uncompressed 4K video at 60 fps can require upwards of 2 GB/sec bandwidth. But that video need only go from a 4K camera to a centralized ECU if the ECU does the video processing. With a distributed architecture, some or all of the processing of that video happens at the camera and can drastically reduce the bandwidth necessary to transmit that information to the ECU.
An automated vehicle ECU making critical decisions about piloting the vehicle doesn’t really need all 2.99 GB of data in a single second of 4K video. What it needs to know are things like, “There’s a car merging from the right; it’s currently 23 ft away and moving at 48 mph.” Processing the 4K data in or near the camera makes it possible to just send the results to the ECU for decision-making. A CAN network can easily handle such a data stream. Additionally, proponents of distributed vehicle networks argue that such a scheme brings fault tolerance, reliability and redundancy.
CAN and Ethernet in parallel
It’s easy to see CAN and automotive Ethernet as competing standards. An alternative model for autonomous vehicle communications is one where CAN and automotive Ethernet run in parallel. Under this model, a single 4K camera might connect to a central ECU via both CAN and Ethernet. The Ethernet connection would carry raw or compressed 4K video, while the CAN connection would carry essential timing, error checking and processed data. Each communications protocol does what it does best, and the vehicle benefits from increased redundancy, error checking and a more robust communications network.
As autonomous vehicles mature, so will their needs for higher-bandwidth data transmission capabilities. The CAN protocol will still hold an important role in future autonomous vehicles. Utilization of CAN in appropriate autonomous vehicle communication applications will speed development, reduce costs and improve safety and reliability for decades to come.
