Evolving Automotive: Zonal Architecture - The Tech Between Us, Part 1

The Tech Between Us: Zonal Architecture, Part 1

Raymond Yin
As I’ve watched cars advance in technology over the last several years, I’m often reminded of a story that has circulated since the 1990's. According to urban legend, then Microsoft CEO, Bill Gates said that if General Motors kept up with technology like the computer industry, we’d all be driving cars that cost $25 and got 1000 miles to the gallon... to which GM shot back, If GM developed technology like Microsoft, we’d all be driving cars with the following characteristics:

1. For no reason whatsoever, your car would crash twice a day.

2. Occasionally your car would spontaneously die on the freeway. You would have to pull over to the side of the road, close all of the windows, shut off the car, restart it, and reopen the windows before you could continue. And you would simply accept this as normal.

3. The airbag system would ask “Are you sure?” before deploying… and the list goes on.

In all honesty, Bill Gates never said that specifically and his remarks at the Comdex trade show have been taken out of context, but thirty plus years later, the average car is now a rolling computational platform.  

According to AutoPi, modern cars can have 30 to over 100 electronic control units (ECUs for short) each with one or more microcontroller units... making them advanced computers on wheels, running tens if not hundreds of millions of lines of code. With the continuing push towards electrification and autonomous driving, cars are evolving even more rapidly. So where are we on the development path as these two technologies merge closer together? 

Buckle up as we navigate the advancements ahead in automotive. I have with me today, Christian Uebber, Chief Technology Officer from ETAS, a wholly owned subsidiary of the Robert Bosch company in Germany.
 
Christian, welcome to the Tech Between Us!
Christian Uebber
Hi Raymond. Nice to see you again.
Raymond Yin
Can you tell us a little bit about yourself and what ETAS does?
Christian Uebber
Well, ETAS was spun off out of Bosch over 30 years ago as a startup. This was a time when automotive developers needed software access to the electronic control unit so that you could change parameter inside the control unit while the car was running. And this was an emerging business back then and something that we didn't only need for our own ECUs but also for competitors and a big company grew from there. So nowadays we are offering automotive operating systems middleware with over 2 billion deployments from some of the stuff you might have never heard. My personal theory is it's because it's so good, there's no drama, it just works.
Beyond that. We offer development tools, verification, validation solutions, special hardware for high performance recording deep inside the vehicle. Anything you need, if you want to make a weaker actually load ready for release.
Raymond Yin 
Sounds great. Yeah, and I completely agree with you. Once technology gets to the point where it's good enough and ubiquitous, it disappears. And nobody's aware of it, but everybody uses it whether they know it or not.
Christian Uebber
Exactly.
Raymond Yin
So, Christian, current cars - electronically anyway - are set up in a way that essentially each function or feature is controlled by one of your electronic control units and it seems to be working. At least it seems nice and neat that way. Why is this no longer working moving forward, and what sorts of new features and technologies are driving all these changes in the way the cars are electrically designed?
Christian Uebber
Interesting question. So, as you say, from the perspective of a local function, the current model seems to work quite well. Take, for example, a very simple function, an actuator for a car window, you can measure the current flowing through the actuator, and if the current goes up, something is obviously stuck, and you immediately stop the actuator. Very simple logic, very easy to safeguard, long, long experience, cost optimized and so on. And why change that?
Raymond Yin
Yeah, exactly.
Christian Uebber
At the vehicle, from an overall perspective, there come additional drivers into play. For example, there has been this perception that the amount of compute capacity that you get per dollar is increasing much faster in the consumer electronics and newer technologies than it is increasing in the microcontroller space. But the perception is like this is a kind of performance we get over time and consumer electronics that went parabolic. There are some arguments to this, this is certainly true, but there's also another driver. So if you look at the amount of pure compute capacity that you get nowadays per dollar, if you look at the total cost of developing such a system, so if the available space of compute capacity that you fill with software relative to other costs, the cost of software and software, all that you need to release software to the road becomes bigger and bigger compared to the hardware cost. And coming from that angle, there's a lot of strategic imperatives to change the model that has been working for us quite well towards more centralized or other topologies in the vehicle where you bring more stuff together on the same hardware and then try to get the best out of both worlds.
Raymond Yin
So, you're really trying to optimize compute the cost of actually putting additional compute power within the automobile itself. That's one of the key drivers.
Christian Uebber 
Yes, I would say that. So, one of drivers is really cost. How much feature can you deliver per investor dollar? Another driver, certainly depending on the domain, especially in infotainment time to market,
Deliver a much higher number of features, even post site of production to the vehicle. There's a change in what customers expect from their car. Do they expect just electromechanical objects that just works? Or do they expect it to be updated like a mobile phone? And they do drive us, and this is certainly in some of the new architecture types easier to accomplish than with the fully distributed model we have had in the past.
Raymond Yin 
Yep. You’ve got to keep those kids entertained in the backseat for sure. So what alternatives are being considered right now? I mean, clearly the architecture is changing. Are there certain ones that are being looked at more seriously? The auto manufacturers?
Christian Uebber 
Yes. I think that's a whole range. So certainly, we know from Tesla and some new Chinese players, fully centralized model where you basically have one large vehicle computer with all the sensor connected to that. Then there are on the other hand says something that is more closely to the traditional OEM and also how the OEMs are organized is the, so-called domain architecture where you have all the stuff from the driver assistance or ad domain coupled together in one integrated device where you have, for example, the challenge, you have some sensors in the front, some sensors in the back, and you need to connect them with dedicated wiring to that special domain. But this is really close to the domain. You often, you have a powertrain domain and an organization, you have a chassis, a body, a domain, large organizations that work together and we still find these architectural patterns in the vehicle. Then there's something in between, this is called the zone architecture where you rather connect, you optimize the wiring. You have maybe the front sensors which are connected with owner controller in the front, right front, left, back, left and so on. And you have these systems connected via a backbone. Very often technologies like ethernet, and this is a more varying optimized or modern architecture pattern with many benefits, but also many additional challenges.
Raymond Yin 
So, the subtle architecture, you said the right front, left, front, rear left or architecture, a single compute platform would not only measure your right rear tire pressure, but also actuate the right rear window as well as any other electronic equipment in that particular area. So, all the functions in that one area are going to be controlled by a single platform?
Christian Uebber 
It really depends. So, one benefit is we still have a lot of close control loops in the vehicle with low latency requirements, safety requirements, just to a sensor. That's certainly the benefit. And there's also architectural benefit of having the actual control loops running on these zone controllers very close to the actuators and the sensors. There are certain architecture benefits, especially with regard to legacy and safety, but that doesn't mean, and that is really a change to the current pattern that all of that functionality has to run exactly on that zonal controller at the point where you have all these systems are connected with a capital backbone to achieve much more freedom to let the function run where it's deployed best and you just run really the real-time stuff, the safety critical stuff, very close to the actuators.
Raymond Yin 
Okay. So, like you said, a little bit more of a hybrid or kind of a compromise sort of architecture where you have an area high level controller, but still the real time, the safety critical stuff is still kind of running on its own.
Christian Uebber 
Yes, this is actually some experience I've made. Before being CTO at ETAS, I was working as a chief software architect for automated driving at Bosch, and we had one of the first migrations from really fully embedded the function that the driver systems function was embedded on the camera and every phone responding there from migrating this to a separate computer and you had to sensor simple sensors combined with a function running on a weekly computer. And it was 10 times more challenging than we expected really. Because you suddenly, so many things you took for granted in the password are not rented anymore because you have all these interconnects which raise new challenges with regard to safety. For example, you don't have peer to peer connections for every function. Everything is sharing like the communication buses and so on.
You have to protect things from each other that you never had to protect from each other before from a freedom of interference perspective. And you had to talk to a lot more people. So, we expected everything becomes more easy when we have it centralized, but people you had to talk to and coordinate with exploded bearing the same resources. And we had to coordinate who gets how much of this shared resource and the efficiency gains that we initially projected onto these new architectures in a lot of cases actually didn't turn out to be as simple and easy as we initially thought.
Raymond Yin 
Right, yeah, and like you say, not only what resources, but also more importantly, what priority does each particular system get? When you say people, you're talking, the engine people and the infotainment people and all these different groups within the automotive companies, right?
Christian Uebber 
Yes, exactly. So, we very often underestimate the real cost of this. So, it's very easy to draw a new fancy architecture diagram, but to bring these systems onto the road to really harm the safety, the security to make it work, make it ready for production, there are a lot of people involved and if it is really cheaper, faster as you envision, really you can only get to this point if you somehow align people to this new architecture paradigms and the output is actually better than what you had before. And this is more often underestimated than the technological change.

Raymond Yin 
Right? Yeah. Like you said, it's easy to draw a new architecture on the whiteboard and it says, hey, that's going to be perfect, and once you get into actual implementation, it tends to kind of not be so quite as efficient, like you said. So, from looking at some of these new architectures outside of these types of efficiencies, I mean are there other efficiency gains with these new architectures? You had mentioned that there's less wiring and whatnot, and I don’t know, wiring harnesses are actually now in a modern car, a considerable amount of weight trying to wire from end to end and everything in between.
Christian Uebber 
So, this is really a very important factor. And also, it's a cost factor from the pure material, but also if you look at gain flexibility of these new topologies. So, if you have everything connected by a really efficient backbone, it gives you a lot of flexibility. You need maybe one cable instead of a lot of them, you get much easier architecture topologies. So, I think this is an important factor, but I am coming from software development and software development, especially in very large organizations, I have seen or experienced really in my direct environment explosion of complexity. And I would even say that if you just compare the size of the problem, you could save maybe a euro per vehicle maybe in copper costs versus really big champions of the industry, really large companies. And you see them failing versus new competitors and their ability to deliver working software to their customers compared to the problem of material cost. I'm somewhat biased. So, I think that's a real cost benefit to gain. There's a real architectural benefit flexibility to gain with these new architectures, but I'm a little biased towards how can we really enable these large organizations, makes a transition towards becoming more of operating like software company and delivering many, many high-quality safe increments to their customers and what do we need to change architecturally to actually make that happen?
Raymond Yin
Let’s pause here for a brief look at one of our articles on the software-defined vehicle. In the article, An Intro to the Software-Defined Car, we dig a little deeper into how centralized and zonal ECU architectures are promising next-generation alternatives to traditional designs. Read the full article and other pieces by visiting mouser.com/empowering-innovation. Now let’s get back to the conversation as we discuss the future of zonal architecture.

You've been in the automotive industry for decades. What is your favorite car of all time? It could be any make, any model, any year.
Christian Uebber 
Oh, I am really looking forward to my next electric BMW.
Raymond Yin 
Think back to your first computer, what was it? What were the specs on the first computer that you owned?

Christian Uebber 
It was Schneider Euro PC, a German model. It was a predecessor of 286. It had 640 kilobytes of RAM and a 3 ½ inch disc drive. And it was one of my friends who had a PC. Everyone else had a C64 and they were all trading games with each other. And I had no one to trade with.
Raymond Yin
You've obviously been all over the world giving talks, being parts of conferences. What's been your favorite place to visit? Either for business or just on a vacation?
Christian Uebber 
I really have a passion for Japan. Because the food is religiously good. Just amazing what kind of food I had in Japan, and I love that.

Raymond Yin
That’s it for today’s episode. Be sure to catch part 2 with Christian Uebber as we discuss the interface between hardware and software in vehicles and whether a total rewrite of millions of lines of code is even necessary. Experience the full Empowering Innovation Together series at mouser.com/empowering-innovation and see all the articles, use cases, and more.