Zonal Architectures Play Key Role In Vehicle Security

The automotive ecosystem is starting to shift toward zonal architectures, making vehicle functionality less dependent on the underlying hardware and allowing more flexibility in what gets processed where.

The impact of that shift is both broad and significant. For carmakers, it could lead to hardware consolidation and more options for failovers in case something goes wrong with any system in the vehicle. Past designs required a dedicated electronic control unit (ECU) for every vehicle function, and offered few options other than redundancy, which is expensive and adds weight. But a zonal approach also changes how security is implemented, and whether that will make a vehicle more or less secure may take years before anyone has conclusive answers.

“In the past, there was no flexibility in the system,” said Robert Schweiger, director of automotive solutions at Cadence. “For each function, there was one hardware box dedicated to the anti-lock braking, or window lifting, for instance. It was dedicated, and there was no flexibility.”

Fig. 1: Functional safety electronics in action. Source: Cadence

In a zonal architecture, the central compute unit is surrounded by zonal controllers, which also have a lot of compute power. Certain functions running on the central compute are assigned to run on a particular zonal controller, to perform pre-processing on the zonal controller. That pre-processed data is then passed to a central compute unit to do something else.

“This gives the flexibility to leverage a very powerful hardware architecture for all kinds of things, and allows an additional aspect of consolidating hardware. Not only consolidating functions, but consolidating hardware to more powerful boxes, which leads to cost savings. Cost savings is always a key aspect in automotive that shouldn’t be neglected,” he explained.

Additional scalability in either direction comes by adding additional zonal controllers, or removing some, for entry level cars, while still having the flexibility to assign certain functions to the hardware.

Security concerns
In essence, moving to a zonal architecture means replacing various, loosely-coupled domain-specific data paths with a networking infrastructure that acts like a data superhighway, with access points in each zone, explained Roman Pallierer, director, automotive networks at Elektrobit. This means data packages now can be easily routed to any point in the network.

“While such seamless ‘anything-anywhere’ communication offers many benefits and helps to reduce costs, it adds the potential for new security breaches,” Pallierer said. “For security reasons, not every part of the network should be able to freely communicate with another part of the network. Communication to a functional unit dedicated to autonomous driving, for example, must be restricted by additional security mechanisms.”

The goal from a security standpoint is to wrap everything in layers of security, rather than just focusing on a subsystem, while allowing some flexibility in how to defeat an attack.

“It’s cybersecurity at the IP level, at the SoC level, at the board level, different levels within the different software modules,” said Kurt Shuler, vice president of marketing at Arteris IP. “It must be a real ‘belt-and-suspenders’ approach.”

The automotive industry is starting to leverage standards developed in conjunction with organizations like SAE, ISO, and IEEE, an indication this market is taking security very seriously.

“It’s like insurance,” Shuler said. “‘Nobody knows about it, nobody cares, nobody’s going to be able to tell if it’s there. I invested all this money in it, but nobody took my cars hostage or put ransomware on my PC, so I invested it for nothing.’ However, with something like this, when it gets coverage in the press that somebody is able to hack into something, that is going to kill the industry’s ability for a certain period of time to be able to bring these new technologies to market. People do have an incentive, if only for that reason, not the fact that ‘Hey, you’re going to get sued because you didn’t have cybersecurity.”

This is particularly important as a slew of new technologies are incorporated into new vehicles. “You only have one time to make a first impression,” he said. “You’re trying to change human behavior. If it’s really easy to hack into, say, an autonomous truck and turn it into a terrorist vehicle, or some kid just does something stupid with it for fun, that’s going to create press. And that’s going to stop these companies from wanting to deal with this technology.”

This doesn’t mean a zonal architecture solve all problems. But it does provide options for improving security over time as new vulnerabilities comes to light.

“If you look at the way zonal architectures are being developed today, by and large the idea is to re-use the ECUs for braking, steering, that sort of thing, as is, as much as possible,” said David Fritz, senior director for autonomous and ADAS at Siemens Digital Industries Software. “The central compute does all the additional compute that didn’t have to be done before. Then everything goes out to the zone, and the zone re-uses the hardware that exists. It’s an intermediate step. It is a practical step, because you can get the intelligence of Level 4 and Level 5 autonomous, but you don’t have to worry about the mechatronic aspects and redesigning that.”

For some companies, even that is too onerous. “There’s no reason why the logic for handling the brake calipers can’t be done in central compute, and then you’re connected directly up to the actuator itself,” Fritz said. “So they’re looking at sensors and actuators, with Automotive Ethernet connections. In the case of how they’re done today, the vulnerability of an intermediate-step zonal architecture is exactly the same kind of vulnerabilities that you have in conventional automobiles, so there’s not really a benefit there. On the other hand, once they get all the way to Automotive Ethernet, all the way to the actuator itself, then the only way to invade the system is through the equivalent of firewalls and things like that, which you put in the central compute system. In the end, you will have a much more secure system than you have now, even though it’s zonal, because the zone itself uses that same kind of interface. All that’s being done in hardware, but not software, because you can’t really crack the hardware but you can crack software. So it’s a mixed bag.”

There is no consistent approach to security, in part because new threats are constantly popping up and in part because automotive architectures have been in such flux.

“Security means something different for each company, and everyone has their own idea how to realize a super secure system that goes along with safety because there is no security without safety, and vice versa,” said Cadence’s Schweiger. “If a system is unsecure, and I can manipulate the braking system, then it’s longer safe. If you listen to security specialists, they always talk about the surface of attack. The more connectivity provided to the outside, the more options attackers have to the system. If there is vehicle-to-vehicle communications or vehicle-to-infrastructure communications, or if there is cloud access, or Ethernet in the car and the Ethernet wires can be accessed, that could also potentially lead to a path to sneak into the system. If it is a very configurable, highly-connected system, of course there must be more potential to break into the system.”

What carmakers do agree on, though, is the need to build in security as part of the architecture, rather than trying to layer it on top of an existing design. “Security is not one of those things that you can add on later,” said Chris Clark, automotive solutions architect at Synopsys. “So even if I have a traditional model today, or I go to a zonal model in the future, I have to build in that security. And therefore, I do inherently get the safe features of a good cybersecurity practice and the well-developed infrastructure.”

Security extends beyond passenger cars. Trucking is getting its share of attention, as well, and in that segment, the considerations are different.

“When we think about our consumer vehicles, they’re really standalone,” Clark said. “We have an over-the-air update capability where we get information updates to the car and address cybersecurity issues. Heavy trucking is going to be the same way. There will be those exact same capabilities and solutions. The difference is, we always think about the truck, we don’t think about the trailer. In order to reach the level of efficiency that will be necessary, trailers are going to start getting some smarts along with them, as well. They’re going to have to participate in the overall braking plan, whether it’s a refrigerated unit or a regular unit, along with advanced features like weight load balancing and management. There are electronics in all of those components, and it’s much easier to tamper with a trailer that’s going to get connected to a heavy truck, and have physical access to that heavy truck’s internal network.”

It will remain the OEM’s responsibility to ensure the robustness of the heavy truck, and that doesn’t change. “What does change and is still up for debate and discussion, is who is now responsible for the overall cybersecurity posture of the entire vehicle, and that’s not been answered yet,” Clark said.

This also means that from an industry perspective, there are still unanswered questions about how to roll out zonal architectures on an ecosystem level. Dave Priscak, vice president of applications engineering at onsemi, said a zonal architecture may make sense for one OEM, but this is very difficult to discern from an industry perspective.

“There are a lot of advantages to looking at your sensors in a zonal way,” Priscak said. “By having grouping, which we talk about a lot because we have both the imaging as well as lidar, there are advantages to having these types of sensors more tightly coupled, and also a little more autonomous in their zone, to try to take some of the heavy lifting off the central brain.”

Architecturally speaking, there are a lot of challenges to this. “We haven’t seen much change in the space because what you’re really asking for is all the companies that make products into the space to change their interface,” he said. “So even if you get an OEM that says, ‘This is how we want to architect the car,’ you have to get all the Tier 1s on board. Everybody has to agree that is how they’re going to develop the interfaces for these products so they fit together. I can see it occurring from a micro level, but it’s going to take a force of nature for one of the OEMs to say, ‘This is what we’re going to do,’ because it’s not natural. Currently, most cameras speak low-voltage differential signaling (LVDS), or maybe coaxial cable. And if we’re going to zonal architecture, it may go to Ethernet, which means now everything that’s on the Ethernet drop has to change interfaces. These big challenges take an awful lot of effort to change.”

Case in point: “We’ve been talking about going from CAN to Ethernet for, what, five years now? There hasn’t been a lot of movement because it takes both halves to agree,” Priscak said. “Things are changing but in automotive, it’s a really slow change. We don’t make it any easier because it gets more and more complicated every year we add more and more technology, more and more semiconductors. That makes it harder to get to a standard.”

When the advantages outweigh the cost of making changes, then those changes will be implemented more widely. “To make autonomous vehicles a reality, we have to cut down on the computing required to make this practical,” he said. “Zonal architectures have to occur at some point in order to offload some of the deep thinking of the central host computer, and have more autonomy on the zones to be able to detect objects and other things so that you just send a warning to the big brain versus having to send all the raw data to the big brain for it to make one decision based on all the streams of data. Right now things are okay because we’re not in autonomous mode. So we’re able to look at things independently, such as lane guidance as its own thing, IP protection as its own thing. But when you start putting this all together, that’s where you end up with the giant Cray computer in the trunk.”

Securing a complex system by design is the key here.

“If you are using a secure-by-design approach, you can use a domain controller approach, or a zonal architecture approach,” said Moshe Shlisel, CEO of GuardKnox. “As long as you don’t have an architecture where the subnet that contains the brakes ECU has a connection to the internet, as long as you don’t have such weird architectures, and you take into account those issues, then you have a secured architecture. However, a zonal architecture is much more efficient, normally from the architecture itself, but also from the lifecycle cost perspective because if you don’t need to have a recall, or if you are using predictive maintenance, because there is a connectivity and monitoring, and you understand what’s going on in the vehicle, you gather the data, you’re able to predict, and take care of those issues before it becomes a mass problem, there you go. Put aside the fact that we know that trucks for sure will be connecting to infrastructure, which is another area. If you’re building it correctly, then it will not only be cost effective, it will not be only doing its job, it will be secured, as well.”

Fig. 2: Zonal architecture diagram using a tree topology. Source: GuardKnox

Elektrobit’s Pallierer agreed. “I would not say a zonal architecture allows better security, but rather it enforces a better level of security concepts. The (bad) design approach, ‘security by obscurity,’ does not work in zonal architectures. There is a significant need to explicitly plan the routing paths and determine what security measures should be applied to these. Ethernet switches play a key role in doing so, and therefore, they need to be smart. They require software-hardware integration to achieve the necessary performance while being flexible to incorporate ever-increasing functionality including security. The good news is these security concepts are not limited to zonal architectures, but also can be applied on older automotive architectures that do not enforce them, but allow them.”

Conclusion
OEMs and Tier 1s must have solid security strategies to protect vehicles, and that requires the ability to make changes even to vehicles in the field to keep them secure throughout their lifetimes.

“We talk about autonomous driving cars, but imagine if somebody can hack the car and take over the control,” Schweiger said. “This is probably the horror scenario of all the OEMs. Security is definitely something that needs to be addressed right in the beginning of your architecture, as well as safety. It doesn’t work if you have it as an afterthought. ‘Now I have done my chips. Let’s think about how I can protect it.’ That doesn’t work.”

Related
Shifting Auto Architectures
What changes when cars are designed around the movement of data.
Data Centers On Wheels
Automakers shifting to HPC chips for improved performance and lower system cost.
Will Automotive Ethernet Win?
Why it’s so hard to provide a definitive answer, and what are the other contenders.
Competing Auto Sensor Fusion Approaches
Cost, data volume, and complexity drive multiple solutions.
Automotive Knowledge Center
Top stories, videos, blogs, white papers and special reports on automotive electronics