Evolving Automative: Zonal Architecture (Part 2) | The Tech Between Us s4 e3

Evolving Automative: Zonal Architecture (Part 2) | The Tech Between Us s4 e3

Show Video

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

Show Video

Other news