Automotive Bandwidth Issues Grow As Data Skyrockets

Bandwidth requirements for future vehicles are set to explode as the amount of data moving within vehicles, between vehicles, and between vehicles and infrastructure, continues to grow rapidly.

That data will be necessary for a variety of functions, some of which are here today and many of which are still in development. On the safety side, that includes everything from early warning systems for road hazards, passed from vehicle to vehicle, or increasingly autonomous driving where autos will be interacting with infrastructure, other cars, and crunching data from sensors in real time.

Fully autonomous driving — where a driver can tell a vehicle where to go and the vehicle does the rest — is still years away. But the auto industry continues to head in that direction, even if initial promises were overstated. To make that work, sensor data needs to be accurately and instantaneously processed to identify objects in the road, and both predict and react to unexpected behavior of other drivers, pedestrians, and animals. That requires a lot of data, and in turn a lot of bandwidth.

“How much more bandwidth do we need to get to the next 1% or 0.5% percent better safety or prediction accuracy? That’s going to drive hardware requirements in the future,” said Steven Woo, fellow and distinguished inventor at Rambus. “If it’s just on the entertainment side, looking to simple things like video, bandwidth requirements are well understood. These are small compared to what is needed for self-driving capabilities. Another question is what’s going to get enabled? What we saw when the internet came was that people didn’t envision the kind of pervasive streaming media, and the kinds of business models that people have opened up today, and the pervasiveness of AI on the platforms. The question now is, is the same thing going to happen inside the car?”

Much of this is still being worked out. “How much AI do we need? Maybe we’re going to end up needing a lot more than just the self-driving aspect of it,” Woo said. “I’m sure it will be larger than what people are thinking today because it’s always that way. There are a lot of clever people in the world who are going to figure out really neat things you can do to use up the bandwidth. We’ve never built a system where people say, ‘Sorry you’ve given us too much bandwidth.’ That’s never happened. It’s always the bet within the engineering team about whether it will be a week or two weeks before people complain that we didn’t give them enough capability.”

Security concerns
More data being passed around also increases the attack surface for hackers, because it provides additional ways into a vehicle, and between different components within a vehicle.

“Bandwidth within vehicles is going through the roof,” observed Mike Borza, Synopsys scientist. “We’re now looking at 10 to 20 gigabits per second between cameras. And people now have how many cameras in a car? You can have 10 cameras, easily. If you start counting radar sources, lidar sources, and so on, these are drawing essentially 3D images in a different part of the spectrum. With that, there’s an absolute ton of data flying around in the car, and that’s only going to go up over time as more driver aids are added, and with the move toward autonomous vehicles.”

That adds new concerns for security experts, because while hacking into data in a server can cause significant financial harm, hacking into a car can cause significant liability issues. “A huge amount of this — even liability concerns — turn back into security concerns, because if you can interfere with somebody’s backup camera that’s replacing their rearview mirror, you’ve now got a way to cause accidents or to increase liability for manufacturers,” Borza said. “That’s all a concern inside the car. Then, as more intelligent roadways are created, and more vehicles talk with each other to communicate information about traffic conditions or proximity, now there are serious amounts of asymmetric cryptography, meaning there’s a lot of identification and authorization for vehicles and infrastructure to talk to each other. While those are not very high bandwidth by comparison to what’s going on inside the car, they have significant latency concerns because vehicles are moving at each other very quickly. You have milliseconds, or sometimes microseconds, in which to do negotiations where these things identify each other, exchange whatever small amount of information they need to exchange, and then move on. These are the kinds of things that we see being issues to address in the three- to five-year range for vehicles that are going to emerge in the market in the next 10 years.”

These kinds of issues will continue to evolve, and automotive architectures are changing to minimize the risk. “If you have one central location and you are able to attack that central location, then you are vulnerable for the entire system,” said Jean-Marie Brunet, vice president of product management and product engineering at Siemens Digital Industries Software. “In a zonal architecture, there are different zones identified to perform different functionalities. Some could be are related to AV or ADAS, everything that is very raw-fusion, sensor-type of computation and allows different levels of certification of autonomous driving. That’s one type of zone. Other zones will be related to applications like infotainment that are very bandwidth-hungry.”

Within the zones, security is handled differently by different carmakers but the zone architectures intrinsically are better for security, Brunet noted. “If you have a vulnerable point or point that is attacked, if it’s a zone within one zone, you have multiple gateways and the ability to isolate a zone versus the other. This means it is possible to not propagate a potential security problem to other zones. So just the fact that the OEMs are implementing zonal architectures is very helpful for security.”

That provides a base for protecting critical functions, but it needs to be updated and adjusted as the amount of data moving in and out of the vehicle increases and changes.

“The more connectivity you have, and the more streams you have coming in — and especially the more diverse sets of things you have to rely on coming in and out of the car — the greater the security requirements,” said Rambus’ Woo. “Then, the fact that it will be a software-defined vehicle where you can do software over-the-air updates and things like that also increase the need for security.”

Building a secure network
Tied in with security is the fact that the most widely used communication bus protocol within vehicles, the CAN bus, is historically quite old. While robust operationally, it is far from secure today.

That has opened the door to technologies that might have been unthinkable five years ago, such as Automotive Ethernet. But the need for an autonomous vehicle system to make accurate predictions requires a high level of precision in the data, and that in turn requires a lot of data. The problem is that Ethernet is not typically known as a low-power networking technology, and pushing around gigabytes of data requires a significant amount of energy.

Bandwidth speed plays into the power. “How fast are you running these lines? As you start hitting speeds of 10 and 25 Gbps, you start dissipating more power on the copper lines, which means the copper dissipation or the insertion loss increases,” said Rishi Chugh, vice president of product marketing, IP group at Cadence. “In the automotive industry as of right now they have not gone to optics. Because of the reliability constraints, optics is not as reliable. It’s not as sturdy compared to copper. All the wiring in vehicles is copper, and that makes it a bit more power-hungry, but you’re not going large distances. Today, Ethernet within the car is barely hitting 1 Gbps. It’s not even at 10Gbps. It will get there, but right now that’s not the state-of-the-art in connectivity for automotive. Once they change the media of connectivity as they come up with more solutions for optics on the car, which is going to happen because they use that in aircraft today, you will see a lot of power being there in the Ethernet side of things.”

In automotive, the ability to make accurate decisions quickly is not optional. It requires large amounts of precise data collected from various types of sensors, and some very fast pipes to deliver that data. “As these cameras are getting into HD, and more cameras are put into cars, that system becomes more intelligent, and the bandwidth is increasing,” Chugh said. “At that point, 1 Gbps is inadequate. Just look at home surveillance cameras. There may be multiple cameras in the house, and we will reach the point where there will be more cameras in your car than in your house. You’ll need a lot of bandwidth for interacting with adjacent vehicles. A lot of bandwidth is also needed for processing the data which you’re getting in the car. When we reach a state where there are 10 cameras in a car, we’ll need 10Gbps of connectivity for these cameras to process and get more precise. With the precision, the accuracy improves a lot.”

Designing for safety, but more quickly
For the system architects trying to take all of these issues into consideration, the biggest struggle is time to market, Chugh said. “If you’re designing for aerospace and defense for NASA, where everything has to be monitored through a microscopic lens, there is always a Plan B. Here, you are facing two challenges. One is on the testability side and the other pertains to high temperature coverage. In terms of the testability, in terms of monitoring features, those are basically going faster forward than a normal design. There is fault tolerance coverage by itself. In addition to that, these particular devices are running at very high temperatures, which means simulations, component testing, and circuit testing must be done very rigorously at high PVT.”

Time-to-market pressures are something of a new phenomenon in the automotive world, where five-to-seven year design cycles used to be the norm. But as carmakers increasingly digitalize their designs, those design windows are shrinking.

“Our underlying systems are still struggling a little bit to cope, because some of the underlying systems were not designed for this,” said Michal Siwinski, chief marketing officer at Arteris IP. “If we look at the ISO 26262 standard, the starting point was different. It will evolve now that people are exploring what is possible, and we’re seeing that in some of the systems. There are very interesting systems being created, and all of them are absolutely pushing the underlying compute requirements. For the network-on-chip, this includes the underlying connectivity requirements. It’s absolutely getting more complicated, and it’s both the high-end stuff and the underlying application. It’s great to have the right vision information flowing, or the right compute from the multiple microprocessors, but you still need to deal with power networks — especially with clock networks if you have interruptions to your safety islands. Just the underlying complexity of that is increasing, and everybody wants things faster. Nobody wants to have a three-year design cycle. So for that underlying connectivity, anything else that can be done in an optimized fashion out of the box, be it IP or software for integration, automation is huge because time to market is huge.”

Managing the pieces
In some ways, the evolution of technologies in the automotive world are similar to the path taken by IP companies in the chip world. Instead of separate components on a board, those components were fused together into a much smaller system-on-a-chip.

“In the 1994-1995 timeframe in Silicon Valley, people started talking about system-on-chip,” said Siemens’ Brunet. “Until then, there were processors, there were memories, and everything was a standalone component on the board. Then, suddenly, we started to talk about SoCs, and we had IP, we had processors, and we were integrating this system-on-a-chip. It’s similar to the approach in automotive. The automotive OEMs are moving to a system view, and moving as much as they can from certain systems or classes of zones, as much as possible, into a single die or multiple die. It’s very good, because it runs much faster than in and out of multiple components on a PCB. Because of that trajectory to have much more silicon and system validation, simulation and hardware-assisted are needed because the size of what they’re dealing with now on cars is a non-trivial exercise to get right. So that notion of what happened 20 or 30 years ago in the semiconductor industry is very similar. We are talking about system-on-chip, combining as many ECUs as possible by zone and creating chips that communicate at the die level. It doesn’t have to be a single die. It could be a 3D or 2.5D package, but much more elegant. It’s much smaller in footprint, and it still has to sit in the car.”

Others agree. Frank Schirrmeister, senior group director of Solutions & Ecosystem at Cadence, said these system-level aspects of automotive design start to resemble a layered edge device. “The discussions are about how many cameras, and at which precision? How do I transfer the data? And then, where do I process the data? How much processing do I do outside the car? Within the car, there is a layer of edge processing considerations to work through. There’s a hierarchy. The system-level aspects of this development, and the test scenarios for this, definitely are complex enough to do these assessments. You can run those in an emulator to get the proper throughput, because these test cases are complex at the core level. A lot comes down to the analysis and the test generation. Emulation does play a role when you want to accelerate the execution of the tests, but it’s equally important to generate the right test, to ask the right questions to the emulator, and then do the right analysis on top of it and see where system-level VIP fits into that.”

More work ahead
One drawback at the system level in all of this is the fact that the more that data is secured, the slower it moves, Borza noted. “At the same time, we’re coming into a time where we’re starting to switch over from asymmetric cryptography, so a lot of the things that we know and love from the ’70s on — the RSAs, and elliptic curve cryptography — that becomes obsolete as we move into the post quantum era.”

Borza said NIST is in the process of standardizing next-generation cryptography right now. “We’re just moving to post-quantum cryptography, and in the next two to three years, we’ll have that available. It’s going to take a while before it is fully adopted, as that’s a significant groundswell to replace those things. But if you look at something like a car that has a design life of at least 10 years, realistically it’s 20 to 25 years. The OEMs need to be thinking, ‘What am I going to do to adapt to that post-quantum world when the cryptography has evolved to that?’ As such, crypto agility, i.e., the ability to update algorithms, becomes much more important.”

How security, bandwidth, precision, accuracy and system-level issues get resolved within zonal architectures, on the road to fully-autonomous vehicles, has yet to be resolved. But the combination of factors occurring concurrently is expected to keep the whole automotive design world very busy for years to come.