More On Evolving Automotive: Zonal Architecture - The Tech Between Us, Part 2

The Tech Between Us: Zonal Architecture, Part 2

Raymond Yin
Welcome back to The Tech Between Us. Let’s jump right back into the conversation with Christian Uebber, CTO of ETAS on Zonal Architecture and the Software Defined Vehicle. To catch up on part one of our discussion, visit our Empowering Innovation Together website.

There's been a lot of marketing talk, and I'm sure you've heard it, how cars are becoming literally computers on wheels. And obviously, there is some truth to that, but obviously that is once again a lot of marketing speak. How much of a transition has the actual automobile made to really becoming just a rolling compute platform? Obviously, there's the architectural side, but there's also, like you were saying, the development side and the people side of things. How is that transition going?
Christian Uebber 
Well, it depends on who you are on the OEM side currently, I think some have really shown us how it can be done and the benefits that can be gained, the customer passion that you can create by offering a more software-oriented vehicle.

On the other hand, it's a promise of these SVD technologies that our industry has been selling has not materialized for all companies yet. And there may be some cultural inertia, but there's also, we haven't delivered completely on that promise yet. There's a large landscape of partial solutions to problems. But if you really look at the core business like, hey, I have a working process to deliver safety critical systems to my customers ready for road release. And you tell me a lot of things of the Cloud is coming to the vehicle, everything is working like a computer, a data center on wheels and mobile phone and wheels.
Raymond Yin
Exactly.
Christian Uebber 
Not so many customers have really experienced, yes, I bought this and now I'm much faster and much more cost efficient. It's not so easy. And I think this has to do with a lot of these data center technologies are not one-to-one transferable to the car. I'll give you one example. So, in the Cloud ecosystems, we have very reliable systems say mission critical systems with downtimes of seconds per year and job of delivering high quality, highly available systems. But the architectural patterns that you use in the Cloud assume it's a very important feature that when there ever is a spike and load, you just scale out to more systems.
You cannot do that in the car. There is only the computer that you put into it. And if you hit the limits of that, you need other failure modes, other modes of degradation, other modes of how do you handle this course? You cannot just copy the patterns from the Cloud, which assume just take one more machine. I think our industry has been somewhat native to assume if we just like we are old school, take these new technologies, they think put them in a vehicle and everything will be better.

Raymond Yin
Right? In a perfect world?
Christian Uebber 
Yes. And another thing is in the physical actuator space, first you have really safety demands where life is at risk with really another type of release to sign really by responsible person, then maybe an IT system release where you also have big threats. And also, we have other processes, other culture, how do we get to that point that we actually say, hey, I signed this, I'm responsible, this is safe for road release.
And this implies certain things. For example, we have, especially in the microcontroller space, we have very robust approaches how we can assure this, how we can assure that we really understand domain we're operating in with very good that we have guaranteed freedom of interference between different functions. And also, we use a class of algorithms that very often assume a very clockwork like periodic activation, like you're running 10 times every 10 milliseconds, you're activated working maybe on a dyna function and your algorithm assumes that this is exactly 10 milliseconds as it becomes unstable. If you cannot assure that, and it's very hard to assure that with a higher guarantee on more modern architectures, you really have a problem and the whole system becomes oscillating, and you get more trouble than you save. And I think this was underestimated, especially in the algorithmic domain where we have a rich heritage of really great understanding of vehicle dynamics and so on. And this was built for microcontrollers. We have solutions for microcontrollers, and you cannot just copy them as is to a much more dynamic hardware architecture, assume everything will just work. So, it's not working like that.
Raymond Yin
Okay. Yeah, being, like I said, I'm an old microcontroller engineer. I mean the microcontrollers in that environment, they're very tightly coupled to the actual whatever it is, whether it be a sensor, an actuator or something that is very tightly coupled like you said. I mean sometimes we're even counting cycles between events as opposed to moving up into a larger, more capable platform like A CPU or a GPU platform where you're running operating systems, what are Linux or whatever operating system and things like that. And so, it just really doesn't translate really well, does it?
Christian Uebber 
Not at all. I fully agree with you this new, let's look at the example of a medium class CPU, the microcontroller. It really runs like a clockwork. Every cycle is like the last cycle. You can really rely on this. We have a very good understanding about the conditions that need to be fulfilled so that we behave like that microprocessors are optimized for maximum throughput for very general purpose, broad use cases. So, an example is a microcontroller has a very short, so-called pipeline. So, this is just substages that do a set of calculations and produce an output.
Raymond Yin
Sure, yep.
Christian Uebber 
For efficiency reasons or throughput reasons on microprocessors, they're very long, often like three times, four times as long as a microcontroller and you need to fill them up to use some efficiently. And because this is quite a challenge, microprocessors do a lot of dynamic optimizations to fill that pipeline, try to look ahead in the future. What might cap net said they already do the calculation and especially they have so-called multi-level caches. Caches are much faster versions of your main memory by orders of magnitude faster. And you put data that you either have been using just recently or might be using in the next calculation, you put them into the very fast caches to always have these pipeline split with meaningful work.
And this is great for throughput, but this is very bad for predictable clockwork like behavior because these systems tend to oscillate a lot in their dynamic runtime behavior. So, things are sometimes really fast and sometimes for fully ballpark reasons that you understand if you start up the debugger and it's really complicated to find out sometimes not because they're dynamically optimizing all the time. And the same is true and even worse for GPUs. So, there's a lot of stuff where the CPU or the accelerator tries to be as sufficiently as possible and does a lot of optimizations on the fly that you cannot predict good. And this is a really bad fit for classical control, control loop problems where you assume, hey, if I activate you like every 10 milliseconds, it must be 10 milliseconds plus minus maybe 5%. Algorithm is really relying onto that. You cannot then start chittering because it increases the throughput. Then you are optimizing a problem that your control algorithm engineer doesn't have what the engineer needs from you. It's very predictable activation. And then this engineer can do his or her job.
Raymond Yin
Right. Okay. Now when you start introducing things like operating systems within vehicles and whatnot, does that help or does that actually hurt the problem of this latency or this unpredictability?
Christian Uebber 
It depends on perspective. Many real time operating system developers, which grew up knowing every register, every bit and they knew the system, they did a hyper of software co design based on it. And if they gave a signature this is going to work, they had a very high pride and confidence this is going to work.
They look at something like the Linux Kerner was a million lights of code written by someone they don't know, have never heard of. And it's all running the same process kernel space together where anything that can go wrong can crash the whole other 10 million lines of code. And for them it's total crazy talk. To assume that you can release a reliable system based on such a monolithic, super large architecture, it's really a crazy talk for them. On the other hand, and this is if we look at how Linux has performed in the data center space, what kind of problems they have solved, what kind of patterns they used, if we compare the complexity of the challenges, they came quite far. Even with this architecture, there's also, if you understand Linux architecture so on, there's a lot of things you can do to actually build safe systems with that approach that we haven't tapped into yet. It just works, it needs to, and many people are working on this while improve on that side, but there's a mix of cultural heritage that people have just not had positive experiences with releasing safety critical systems, which are based on such an architecture. And on the other hand, there are also many concrete automotive problems not solved yet, not certified yet and so on. So, we're right now stuck in a very interesting technologically transition.

Raymond Yin
Right? Yeah, I mean obviously the overall automotive industry, the vehicle itself is in a huge transition between connectedness and autonomy and electrification. I mean this whole thing is going to change. It has been changing and it's going to continue to change for the foreseeable future, I think.
Christian Uebber 
Yes. So sometimes, so we have the technological challenges we have just talked about with regard to safety, Jetta latency and so on. And then you have all these new kinds of influencers and pools coming in and infotainment demands are different often from maybe CHAS demands or a very hot thing right now is how can you integrate the powertrain actuators, the electrical motors and an expensive car, one per wheel with braking vehicle dynamics and so on. And then you have a very tight control problem that you can optimize over the whole vehicle, which crosses traditional domains between braking and powertrain, and you bring them together. So, there's a lot of interesting things happening, but they're also very, the challenges are unique. For example, we had the initial assumption, isn't it a great idea to share the GPU for infotainment and drive assistance or even automated driving?
Raymond Yin
Sure,
Christian Uebber 
The same type of resource and wouldn't it be much more cost efficient if we share it? And I don't want to rule out that this is going to come. So, we have found some promising approaches to this, but if you look at the overall state of the market right now, for many customers it was not the best, of course was because, but the worst of both was because you had to pay for the safety certification to your SOC supplier to have it usable for actual ADAS function. And so, you didn't get the cost benefit. On the other hand, you had a lot of additional impediments on your architecture because you had to safeguard ad system from the infotainment system. And for a lot of customers, especially cost sensitive customers, it made sense to say, hey, this is for infotainment, this is dedicated, there's no complicated stuff in between. I have to take care of, I just deploy my Android or whatever. If the customer purchases driver assistance function, this is a separate SOC or separate core. And so, the state of the art right now is that we haven't realized the cost benefits today of such a merch architecture, but I don't want to rule out that we can realize the,
Raymond Yin
Okay, interesting.
Christian Uebber 
Really quite different. So, in infotainment, your biggest demand is I want to keep pace with technological progress, I want to update my systems, I want to offer apps that are maybe not even released and tested by the OEM, but I provide a robust framework where people can upload and sell apps into, and this is a very different need from many other needs customer set,

Raymond Yin
Right? Yeah. At that time, it is more, I mean your infotainment system is much more like almost like a consumer device like your handhelds or wearables and whatnot, whereas the rest of the car is still in that automotive space of safety, safety critical type of systems.
Christian Uebber 
Yes, totally agree.
Raymond Yin
As we've been talking, transitioning from a microcontroller space to a more of a higher-level compute or even a GPU type of platform, we've talked about that you just can't pick it up and drop it. So are engineers going to have to rewrite, I mean literally it sounds like probably billions of lines of automotive code to be able to go to these new types of architectures and these new platforms. I mean is that even possible?
Christian Uebber 
Well, the short answer is no, it's not.
Nevertheless, a very interesting question and I would like to come back to the example of the window actuator. We once did the exercise at Bosch to identify what we call it nomadic functions that are functions that are currently tightly coupled to a piece of hardware in our portfolio, and we have some assumptions it should be very easily movable anywhere where we need it.
Raymond Yin
Right. 
Christian Uebber 
And for example, in the case of the safety case of a closed window, the actuator is quite simply current increases, immediately stops the actuator. And this was identified very trivial. The function is so trivial it should be able to run anywhere. And if you look at the cost calculation of actually doing this, you pull this very simple function. This is really the function itself is trivia. You pull it on a central device and suddenly you have to, your life is at risk if the connecting bus in between is maybe sometimes not responsive and anything you do on the system, you have to really to prevent blood on your hands, you have to really certify is this possible that this can be blocked when I need it? And the total cost of this migration of this function is depending on how you calculate, there is no cost benefit at all.
So, the function is trivial, but migrating it to another device with all the non-functional requirements attached is not a cost benefit. And we did a lot of these kind of analysis, so what can be migrate, what would be possible and so on. And we found much less where this makes economic sense that we initially thought, and especially for the aspects of safety, mostly safety. 
I would say on the other hand, if you start centralizing a lot of stuff on a central device and the central device has much more CPU like and GPU like resources, this is not as we the best fit for some classes for control functions. And so, it wouldn’t make sense. It would neither make sense to rewrite the function nor to migrate it to a new platform because technologically hardware software is just not a good fit without anything else. Then we had the idea, okay, we need abstraction layers where we can make migration of this function much easier.
But an abstraction layer, if you want to execute control like functions efficiently on A CPU, you’re using the CPU in a mode of operation it wasn’t built for. So, this is not a good fit and especially as an architect, I’ve come rather to the more nuanced view that we really should do a separation of concerns from a non-functional requirements perspective. And that if you look then at a function, the function is not one thing. You have traditionally in a department, you had a set of people responsible for a function and they had one device where they, and if this was a microcontroller, everything they did was like a microcontroller logic, what is my wrap up activation? Like 20 milliseconds, 60 milliseconds and so on. And everything they did, they did in that kind of mindset and integration framework. If you look at the function itself, you find, okay, not everything a function does is necessarily requires a periodic activation.
So, like a clockwork, there are a lot of things that are maybe parts of that communicate with other functions of the vehicle com for stuff and so on. And you could take that stuff out, put it on the vehicle computer in another part of the function. For example, the part of the function that is responsible for always maintaining a safe state, high precision actuator control. You keep that maybe on your Z controller close to the actuator and this is the stuff run there. And so, the key is not to make everything movable anywhere, but that you actually look at the problem from a non-function perspective, you see, okay, what part of this really needs to run on a microcontroller? What part of the workload is a better fit, for example, for GPU or CPU? And if we look at newer use cases like involving perception stuff that really benefits from running on A GPU or on an AI accelerator, developing and deploying that to a microcontroller would really be a bad fit. And so, this stuff is already happening, and the key seems to be that split our functions that have the stuff that really needs benefits from a microcontroller like execution platform, have that run on a microcontroller that is not that run where we think the best match of what the hardware offers versus what the software needs and keep that.
Raymond Yin
Before we move on to the rest of our discussion, let’s dip our toes into one of our articles on zonal architecture. In the article, Virtualization and the Software-Defined Car, we highlight the trade-offs between zonal architecture versus centralizing control into a single or small number of CPUs. How best should you handle the projected 500M lines of code in fully autonomous and connected, software-defined vehicles? Read the full article by visiting mouser.com/empowering-innovation.
Alright, so Christian, I'm now going to ask you to get out your crystal ball and help us predict the future. 
Here we are, 2024 and I know that the car manufacturers work years in advance to, they're probably working on the 2027 - 28-year models right now from a technology standpoint, but let's even look even further out than that, let's say 2034, 10 years from now. How much of the changes that we've been talking about today do you think will be implemented in that 2034-year model across the industry? 
Christian Uebber 
That's a tough one because 10 years is a lot. I think many have heard of Docker, the company and technology disrupted everything in the data center space. And it was only six years from the invention of, and the company itself becoming more or less meaningless in the market because everyone was using something like that, but different set of,
And so, 10 years is long, so my bet would be that microcontrollers are here to stay. They're very good fit for a subset of the problems we have in the vehicle, especially safety critical and control field, weak kind of stuff. Those two actuators we will have, I think zone architectures will be very widespread with also almost fully centralized options of that. Also running around, we will have much better separation of hardware and software for a much larger part of the system. We do our job well. We move on from a functional architecture where we try to find a host for a function in the vehicle, either on the microcontroller or on the pc, but we better separate them. And then we have will have either really large, specialized AI or GQ accelerators, which constantly monitor what is happening around the vehicle. I think this is a lot of untapped value, which is not really realized by OMS right now that you have these high-definition 10 source constant facing the outside world, and you could have AI functions create value out of these sensors input continuously over millions of peoples all the time. So, something like Google Street view Live, you go somewhere, and you don't see the picture from two months ago or one year ago, but you mostly get a quite real time view of what's actually happening there, and it's generated out of vehicles, which on demand, just start uploading what's happening here.

I think there's a lot of untapped potential in that regard. And a good scenario for 10 years from now on is we do a very good separation of concerns. We learn to deploy the stuff that really should be deployed to microcontrollers there. We have maybe centralized vehicle microcontroller farms where we have a lot of calls available for microcontrollers, but on the same package we have high bandwidth backbones in a zone style where we connect the different sensor areas and vehicle robust freedom of interference and latency guarantees we have for the edge stack and infotainment. I have two scenarios. So, low-cost scenario is the SDV, it's just going to be infotainment. So, you just have two words, very simple, infotainment plus rest of the vehicle. Rest of the vehicle is classical platform style; platform increments and so on. You have anything else where you need fast action just happens in the infotainment domain, either on Android Auto or even cheaper with a connected mobile phone. And this is where SDV happens, this is where you have your updated charge controller, and a lot of stuff is justified there. And then there's a more premium maybe way with a large infotainment system like you get from premium or S nowadays. And this an SDV like edge stack where it's very easy to deploy. Also, vehicle functions in addition, but it will become anywhere outside the microcontroller domain. It will become very uncommon to have a strong company to the specific hardware you're using. You only find control.
Raymond Yin
It sounds like a lot of the things we've been talking about hopefully will be deployed. Like you said, 10 years in the technology world is a long time.

Well, that brings us to the end of today’s episode. Join us next time as we finish up our conversation with Christian Uebber of ETAS and explore the changes necessary for writing, updating, and even thinking about code for software-defined vehicles. We will also touch on the cultural shifts between developers of application codes vs. the developers of microcontroller codes. All this plus the entirety of the Empowering Innovation Together series can be found at mouser.com/empowering-innovation.