Evolving Automative: Zonal Architecture (Part 2) | The Tech Between Us s4 e3
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 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? And, 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, the promise of these SDV technologies that our industry has been selling has not materialized for all companies yet. And there may be some cultural inertia,
but they 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, as 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 a mobile phone on wheels. Raymond Yin Exactly. Christian Uebber Not so many customers have really experienced this. 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 they do an amazing 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 in 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 naïve to assume if we just like we are old school, take these new technologies, say our new kids on the block, put them in a vehicle, and everything will be better. Raymond Yin Right, in a perfect world, right? Christian Uebber Yes. And another thing is in the physical actuator space. First, you have really safety demands where life is at risk which is really another type of release to sign really by a 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 the domain we're operating in 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 every 10 milliseconds, you're activated. You’re working maybe on a vehicle dynamic function, And, your algorithm assumes that this is exactly 10 milliseconds as it becomes unstable otherwise. 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 and assume everything will just work. So, it's not working like that. Raymond Yin Okay. Being an old microcontroller engineer, 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. 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 it will behave like that. Microprocessors are optimized for maximum throughput for every general purpose, broad use cases. So, an example is a microcontroller has a very short, so-called
pipeline. So, this is just a set of stages 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 them efficiently. And because this is quite a challenge, microprocessors do a lot of dynamic optimizations to fill that pipeline. They, like, try to look ahead in the future to what might happen next. Let’s say 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 pipelines filled 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 opaque reasons that you really understand if you start up the debugger and it's really complicated to find out. Sometimes not finding out 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 efficient as possible and does a lot of optimizations on the fly that you cannot predict really good. And this is a really bad fit for classical control loop problems where you assume, hey, if I activate you like every 10 milliseconds, it must be 10 milliseconds plus/minus maybe 5%. And, my algorithm is really relying onto that. You cannot then start jittering 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 is 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. Put it like that. Many real time operating system developers, which grew up knowing every register, every bit. And
they knew the system, they did a hardware–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 kernel with a billion 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, 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, 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. And so, we're right now stuck in a very interesting technological transition. Raymond Yin Yeah, I mean obviously the overall automotive industry, the vehicle itself is in a huge transition between connectedness and autonomy and electrification. This whole thing has
been changing and it's going to continue to change for the foreseeable future, I think. Christian Uebber Yes. So sometimes, we have the technological challenges we have just talked about with regard to safety, jitter latency, and so on. And then you have all these influences and pulls coming in. And, like, infotainment demands are totally different often from maybe chassis demands. Or, a very hot thing right now is how can you integrate the powertrain actuators, the electrical motors in 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 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 Because it’s basically 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 isn’t 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 both worlds but the worst of both worlds because you had to pay extra for the safety certification to your SOC (system-on-chip) supplier to have it usable for actual ADAS (Advanced Driver Assistance Systems) function. And so, you didn't get the cost benefit. <And o>n the other hand, you had a lot of additional impediments on your architecture because you had to safeguard the 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 that I have to take care of. I just deploy my Android or whatever. And 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 merged architecture, but I don't want to rule out that we can’t realize it in the future. Raymond Yin Okay, interesting.
Christian Uebber But the demands are 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. And this is a very different need from many other needs customers have. Raymond Yin Right? Yeah. At that time, 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-critical type of systems. Christian Uebber Yes, totally agree.
Raymond Yin So we've been talking about transitioning from a microcontroller space to 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 nomadic functions that are functions that are currently tightly coupled to a piece of hardware in our portfolio, and we have the assumption it should be very easily movable anywhere where we need it. Raymond Yin Right. Christian Uebber For example, in the case of— the safety case of a closed window, the actuator is quite simple. Current increases immediately stop the actuator. And this was identified as very trivial. The function is so trivial it should be able to run
anywhere. But if you look at the cost calculation of actually doing this, you pull this very simple function. This is really-- The function itself is trivial. You put it on a central device and suddenly 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 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, 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 kinds of analysis. So what
can we migrate? What would be possible? And so on. And we found much less where this makes economic sense than we initially thought– 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 discussed, the best fit for some classes for control functions. And so, 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. Traditionally in a department, you had a set of
people responsible for a function. And they had one device where they deployed this to. And if this was a microcontroller, everything they did was like in a microcontroller logic. Like, what is my rest of 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 necessarily requires a periodic activation, so, like clockwork. There are a lot of things that are— maybe parts of that communicate with other functions of the vehicle comfort 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 zonal controller close to the actuator. And this is the stuff you 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 a 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 let’s split our functions. Let’s have the stuff that really needs benefits from a microcontroller like execution platform, have that run on a microcontroller and have the stuff that is not like that run where we think the best match of what the hardware offers versus what the software needs.
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. 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 a different set of technologies. And so, 10 years is long. My bet would be that microcontrollers are here to stay. They're a very good fit for a subset of the problems we have
in the vehicle, especially safety critical and control field, kind of stuff. Close to 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. So, if 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 will have either really large, specialized AI or GPU accelerators, which constantly monitor what is happening around the vehicle. I think this is a lot of untapped value, which is not realized by OEMs right now that you have these high-definition sensors constantly facing the outside world. And you could have
AI functions create value out of these sensor inputs continuously over millions of vehicles all the time. 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 realtime view of what's actually happening there, and it's synthetically 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 which are on the same package. We have high bandwidth backbones
in a zonal style where we connect the different sensor areas in the vehicle with 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 worlds, 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 actuation 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 just deployed there. And then there's a more premium maybe way with a large infotainment system like you get from premium OEMs nowadays. And this could also include 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 coupling to the specific hardware you're using. You only find this on the microcontrollers. 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.
2024-06-10 16:10
