AUTONOMOUS & CONNECTED VEHICLES
CAN for better autonomous vehicles 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 1GB/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
44
DESIGN WORLD — EE NETWORK
8 • 2020
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 CANcontrolled 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 packetbased. 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.
eeworldonline.com | designworldonline.com
