Examining Zonal Architecture

 (Limitless Visions/stock.adobe.com)

Zonal architecture is pivotal for software-defined vehicles (SDVs), optimizing communication, enhancing safety, and accommodating software evolution. However, it has many complexities. We spoke to Florian Rohde, Managing Partner at iProcess Consulting and an SDV thought leader, about the challenges of decoupling software from hardware and the intricacies of configuration validation and release management. Read on for his expert view on the nuances of zonal architecture and how it will drive future innovations for SDVs.

Florian Rohde is an SDV expert, speaker, and consultant with over two decades of experience and a deep knowledge of the automotive industry. After working at Tesla and NIO, he is currently a Managing Partner at iProcess Consulting, where he advises both established OEMs and startups aiming to revolutionize the automotive landscape. ofexperience and a deep knowledge of the automotive industry. After working at Tesla and NIO, he is currently a Managing Partner at iProcess Consulting, where he advises both established OEMs and startups aiming to revolutionize the automotive landscape.

Mouser: SDVs are really revolutionizing the automotive industry.
Florian Rohde: Yeah, vehicles have never been packed with so many features. It’s an exciting time for both users and manufacturers.

Especially from the manufacturer’s perspective, vehicles are becoming increasingly complex. How are manufacturers managing to organize so many functions into SDV systems yet maintain their versatility?
Good question. SDVs use zonal architecture, where functions are physically isolated into independent modules or zones with dedicated hardware and software. This segregation enables swift swaps of zonal hardware, dynamic software-driven feature changes, and rapid granular software updates. The modularity introduced by this approach not only sparks innovation but also enhances overall efficiency and adaptability.

Being able to segregate functions and their hardware and software into different zones is a game-changer. But this decoupling must bring about some design challenges.
Absolutely. A key challenge is that hardware must be generic to accommodate diverse software.

How do manufacturers deal with it?
Basically, what happens is that hardware abstraction layers allow varied software on distinct hardware and foster resource sharing.

Are there other significant challenges?
Yeah, a big one for traditional car makers is that industry norms to optimize hardware usage clash with the need for a 20 percent overdesign that is crucial for future software upgrades. Overcoming this requires top-down directives to increase budget allocations to hardware.

And I guess the choice of specific hardware components will influence the software design?
Yes, a definite interplay exists between hardware and software. Modern hardware is more generic than it used to be and accommodates varied software functionalities.

So, this must be where the abstraction layers come into play.
Exactly. The abstraction layers mediate this interaction. It’s like running Windows on diverse computers; automotive software is increasingly abstracted from the underlying hardware. This enables the sharing of resources within the car and flexibility in software deployment.

The sharing of resources sounds really beneficial, but does it introduce latency or performance constraints?
Well, decoupling isn’t perfect and may slow things down a bit due to the extra steps caused by the abstraction layers. The good news is that technological advancements, especially in generic hardware, are better at handling the extra work. Though, I’d say that the pros outweigh the cons. The flexibility and resource sharing you get from decoupling outweigh the slight latency that’s introduced.

How about the 20 percent overdesign you mentioned? Does that have an impact?
Absolutely, that was going to be my next point. The strategic hardware overdesign ensures optimized performance for evolving software demands and addresses potential constraints in latency and system responsiveness.

It’s still pretty complex though, decoupling hardware from software, especially when it comes to communication within the vehicle. Are there any new protocols to help with that?
You’d be surprised, actually. Communication protocols in SDVs still rely heavily on the CAN bus, which dates back to the 1980s.

Are there changes on the horizon?
Yes. Emerging protocols like automotive Ethernet and cellular vehicle-to-everything (CV2X) indicate a shift toward modernization. Future advancements might witness a broader adoption of Ethernet, aligning automotive systems with computer communication standards. Innovations like CV2X, on the other hand, are paving the way for enhanced connectivity, real-time data exchange, and improved safety features.

And what about establishing SDV configurations? Does everyone use the same coding languages or rules?
Mostly, yes. For the software itself, you might be surprised to hear that C code is still king.

Really? I’d have thought a newer language would have superseded C code in automotive.
Well, Python is used extensively now for validation and testing, while languages like Golang and Rust are gaining traction. That said, while the embedded controllers might see changes, distributed systems will likely continue using embedded C due to resource availability and cost-effectiveness.

That makes a lot of sense, but what if you need to make runtime configuration changes? How do SDV systems handle that?
It comes down to automation. Vehicles automatically recognize their own specific configurations. This streamlines software management and facilitates practical advantages, such as the rapid NIO Power swap station for battery replacements. The ability to alter configurations dynamically is great for testing practices; cars can transition between setups on the fly for comprehensive testing, cost-effectiveness, and adaptability to regional requirements.

How many different configurations could you have? Is there a limit?
Probably not. Take Tesla’s approach, for example. They had more than 12,000 Model S variants globally in 2018 and no doubt many more by now, and each recognizes its specific configuration automatically.

Wow, that level of freedom to make configurability changes is incredible. Are there any risks or limitations, though?
Yeah, as with most things, I’m afraid so. Imagine someone messing with the settings to get more power illegally. It’s not just bad for the manufacturer’s wallet; it’s also extremely dangerous.

How so?
If hackers introduce untested configurations, it can lead to significant safety threats. As far as limitations go, I’d say that all of this flexibility requires bigger hardware and higher costs. However, while the OEM might not get full revenue at the point of sale, they can sell additional features later, so the initial overinvestment pays out over time.

Exactly. It’s an investment. Before we move on, I’d like to dig a little deeper into validating updates. What kinds of tools are needed here? And does that add further cost or complications?
Actually, validating SDV updates isn’t so much about needing tools; it’s more about making sure SDV updates integrate seamlessly into the development workflow. The key is running highly integrated and frequent validations.

Ah, I see, but how do you do that?
It comes down to automation again. The system notifies the test environment about new software, changes, and configurations, which streamlines the validation process without human intervention.

So, how do you handle systems with diverse configurations and potentially heterogeneous hardware platforms? Are updates still automated, or does that add more complexity?
Tesla is great at tackling this one. With three cars and a large fleet of component Hardware-in-the-Loop (HiL) simulation test systems, they can handle over 12,000 Model S versions. Plus, they get real-time feedback from customer cars and have a shadow mode for inactive feature observation. Basically, Tesla mixes simulations, diverse hardware testing, and real-world data to make sure everything works smoothly across all those setups.

Got it. This requires more of a multi-pronged approach to validation. Let’s switch gears a little bit and talk about what the future might look like. Do you find any emerging trends or techniques in SDV validation particularly promising?
Definitely. Integrated end-to-end automation is one of the most promising trends in SDV validation. We’re talking about continuous testing, from software development to real-world vehicle testing.

And how would that work?
The key lies in maintaining a high testing baseline rather than starting from zero, which ensures constant validation and quicker feedback loops. Another exciting trend is the integration of over-the-air services and continuous feedback loops, which can enhance the adaptability and efficiency of the validation process.

So, it’s no longer a case of every feature having to be there before production begins?
That’s it. Effective management involves a shift away from the notion of finality at the start of production. Instead, a fixed-cost software team addresses priorities across platforms. And when something needs to be modified, the team moves fast, focusing on fixing what users experience in real time rather than just relying on old plans. Effective management is all about keeping things flexible and adapting to what’s actually happening.

This sounds great in theory, but how can you ensure updates are secure and reliable when there’s so much flexibility in the process?
Good question. Safety has to come first. Above all, the over-the-air update process must be smart and integral. When the server initiates an update, the car actively receives, checks, and enforces safety measures. And if something goes wrong, the car knows what to do: adjust the power or even communicate with the driver directly.

Are there other exciting things you see on the horizon for SDVs?
Some amazing advancements are coming our way, particularly the imminent integration of artificial intelligence on the edge of natural language models.

Are we talking about SDVs that can make their own decisions independently?
Probably, but it might still be five to ten years away due to compute power and trust issues. But V2X communication—cars talking to each other and their surroundings—is just around the corner. In the meantime, SDVs present opportunities for non-owned mobility.

What would that mean for the average car driver?
Imagine having personalized settings that transfer seamlessly between different vehicles through your cloud profile.

What’s standing in the way of it happening?
Before it becomes a reality, we need to find the right balance between tech and regulations, which takes us back to the need to balance hardware abstraction with software capabilities.

Right, it comes back to the decoupling of hardware and software and how that’s managed.
Exactly. Zonal architecture is going to be fundamental to all these future innovations. Watch this space.