• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar
  • Skip to footer

Microcontroller Tips

Microcontroller engineering resources, new microcontroller products and electronics engineering news

  • Products
    • 8-bit
    • 16-bit
    • 32-bit
    • 64-bit
  • Applications
    • 5G
    • Automotive
    • Connectivity
    • Consumer Electronics
    • EV Engineering
    • Industrial
    • IoT
    • Medical
    • Security
    • Telecommunications
    • Wearables
    • Wireless
  • Learn
    • eBooks / Tech Tips
    • EE Training Days
    • FAQs
    • Learning Center
    • Tech Toolboxes
    • Webinars/Digital Events
  • Resources
    • Design Guide Library
    • DesignFast
    • LEAP Awards
    • Podcasts
    • White Papers
  • Videos
    • EE Videos & Interviews
    • Teardown Videos
  • EE Forums
    • EDABoard.com
    • Electro-Tech-Online.com
  • Engineering Training Days
  • Advertise
  • Subscribe

CAN for better autonomous vehicles

July 31, 2020 By Lee Teschler 2 Comments

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.

architectures
Many communication architectures for autonomous vehicles today limit CAN to a low-bandwidth role. Ethernet handles communications like video and lidar, while CAN takes care of sending control signals to vehicle systems or communicating with IMUs. A potentially more economical architecture distributes processing at the sensor nodes so much of the data-intensive processing happens locally, drastically reducing the bandwidth needed to transmit that information to the ECU. A CAN network can easily handle the resulting data streams. Click image to enlarge.

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.

You may also like:


  • Safety and cybersecurity for the connected car
  • dSpace
    The data-driven road to automated driving
  • acienna
    More accurate positioning for autonomous vehicles
  • network slicing
    Cybersecurity testing in 5G automotive designs
  • perrone auto car
    Image gallery: Cool autonomous vehicle tech at TU-Automotive Detroit

Filed Under: Applications, Automotive, Connectivity, FAQ, Featured Tagged With: kvaser

Reader Interactions

Comments

  1. maciej says

    January 26, 2022 at 8:39 am

    would be nice if you could put the bibliography of the articles you are using

    Reply
    • Aimee Kalnoskas says

      February 7, 2022 at 2:47 pm

      THanks for your feedback, macieg. We do encourage our contributing writers (from suppliers) to include references whenever possible.
      Cheers,
      Aimee Kalnoskas, editor

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Primary Sidebar

Featured Contributions

Five challenges for developing next-generation ADAS and autonomous vehicles

Securing IoT devices against quantum computing risks

RISC-V implementation strategies for certification of safety-critical systems

What’s new with Matter: how Matter 1.4 is reshaping interoperability and energy management

Edge AI: Revolutionizing real-time data processing and automation

More Featured Contributions

EE TECH TOOLBOX

“ee
Tech Toolbox: 5G Technology
This Tech Toolbox covers the basics of 5G technology plus a story about how engineers designed and built a prototype DSL router mostly from old cellphone parts. Download this first 5G/wired/wireless communications Tech Toolbox to learn more!

EE Learning Center

EE Learning Center

EE ENGINEERING TRAINING DAYS

engineering
“bills
“microcontroller
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for EE professionals.

DesignFast

Design Fast Logo
Component Selection Made Simple.

Try it Today
design fast globle

Footer

Microcontroller Tips

EE World Online Network

  • 5G Technology World
  • EE World Online
  • Engineers Garage
  • Analog IC Tips
  • Battery Power Tips
  • Connector Tips
  • DesignFast
  • EDA Board Forums
  • Electro Tech Online Forums
  • EV Engineering
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips

Microcontroller Tips

  • Subscribe to our newsletter
  • Advertise with us
  • Contact us
  • About us

Copyright © 2025 · WTWH Media LLC and its licensors. All rights reserved.
The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of WTWH Media.

Privacy Policy