Zonal Power: 48V Architectures for the Software Defined Vehicle

Today's episode is brought to you by Monolithic Power Systems. Our guest today is Elmehdi Haras. He's a senior technical marketing engineer at MPS, specializing in automotive power architectures and semiconductor product definition. Holding engineering degrees in electrical engineering and a master's in strategic management and innovation from the Toulouse School of Management, he bridges technical design with market strategy. At MPS, his work drives the advancement of 12-volt and 48-volt systems, zonal EE architectures, and smart protection solutions, supported by his active contributions to ISO and IEC standardization for automotive power. Elmechti, thanks so much for being with us today. Thank you so much, Eric, for having me with you. It's really great to be here. I'm very excited to talk about this. It's such a topical subject right now because the auto industry, along with many other verticals, is undergoing a pretty big E.E. transition. From your perspective as a power and E.E. architect, what is it that's really driving this change? It's a pretty good question, honestly, to start with. It can really allow us to, let's say, lay down the basics. But my opinion is that today we are basically having three main drivers. So the first one is we have much more compute growth. We need to process lots of information into a vehicle. And when we need to process this lots of information into a vehicle, it also comes at a cost, which is mainly the power. So we need to have much more power to process that whatever information. And the third one is customers are asking for much more features into a vehicle. And those really basically are the train main drivers as I am seeing it today as an E-architect. As a matter of fact, if we have a look at the modern vehicles, we are integrating dozens of cameras, radars, lidars. We have also very high resolution infotainment, which are basically really processing lots of bandwidth. it, if you take a robot taxi today, you would like a robot taxi to be able to process that data in real time because you would like to get from your point A to your point B safely. And that's really a lot of processing power. But also at the same time, you would like to go in a vehicle and to have some comfort and convenience. If it is too cold outside, you would like to have some heated seats. If it is too warm, you would like to have some coolant seats. And that's coming with power. So So you need some power to get those convenient features activated. And the current, let's say, 12-volt network or legacy network is not able to deliver that power. And that's a huge challenge. It is. And you mentioned two things there that I want to follow up on later in our conversation. That's the different power needs of robotaxis and luxury EVs. We'll come back to that. Before we talk about zonal architecture, can you briefly contrast the classic domain architecture with a more modern zonal architecture? Sure, of course. But let's take it step by step on this one. If we take a traditional domain architecture, UCUs are basically grouped by function. You will have body domain, powertrain domain, and so on. And each of those domains, they control a cluster and associated wiring are branching basically different sensors to different actuators, but it's basically going all over the car. The issue with this is that over the time, the vehicles really evolve. And that leads to hundreds of UCUs, many point-to-point current link links. And that's a very long, heavy wiring harness, to be honest, and I've seen ones laying out into the lab. So that sees an issue today. The Zonal architecture flips that organization principle. So basically, instead of grouping by function, now we are more talking about a physical location. And I really insist on this physical location. So basically, each zonal controller would aggregate some sensors, actuators, power distribution, but more in a geographical area. Today, we are more talking about front rear or left rear or east zonal or left zonal. It's really more physics instead of more talking function. So basically saying it's a physical location when I'm going to be dealing with all of those functions on that region, on the right region or on the front right regions. And this is really, let's say, a genuine idea that we are having when we are talking about the zonet instead of a domain architecture. So the general idea is we are trying to shorten and simplify the harness. we are trying to reduce the copper usage. And today we are talking about reducing 30% or more. And there are a lot of studies there who are backing this up. But also some vehicles today that we see where they have, let's say, some knowledge on the 48 volts. And then they say 48 volts on it is a good, let's say, match. And that creates a clean separation between whatever local I.U. we have and also the aggregation and the central software execution. I would love to hear more from you about what that looks like electrically and functionally inside the vehicle. Let's start with electric and then we can go to the functional side. So from the electrically side, a Zona controller is basically a highly integrated model that is sitting in a specific region, like I just said. So, for example, we're talking about a front left, front right, rear cabin. We some others talk about east, about west a lot. But the idea is there is really it's something that is sitting physically somewhere. And that zone is going also to be defined locally, all the wiring to previous domain. That was the lights, the switches, the actuators, the sensors, and even the audio today. In fact, we can find into this zonal a power distribution using mainly EF uses. We will also find some local DCDCs conversion or some point of load DCDC. And all of these on this zonal, it's going to be concentrating all of the local signals on the input and output series coming from the different sensor to the different actuators through a high speed link. And in this case, we're most likely talking about Ethernet. And why Ethernet? It's because we need to have a time-sensitive deterministic communication. And those two words are very important. So time-sensitive and time-deterministic communication. But this is only on the electrical side. We didn't even touch the functional side. So on the functional, this zonal needs to behave as an input-output hub or what I really like to call a regional gateway. I was talking about the physical side. Where it physically sits, I can also talk about a region. So that zonal is basically my hub on the regional gateway on some places. So it will basically handle all the low-level diagnostic and protection. But it will try to abstract all of those information through, of course, that deterministic networking internet to a central compute platform that can run all of the high level software functions. I have a specific metaphor that I always like to say is I'm seeing it as labor work. I am in a factory and each labor is doing something. So my zonal is basically a labor worker who's doing the local labor in some place. And then it's going to be feeding back all of the information to the central compute. It is also going to be taking decision and doing some work on its own. And this means that I can be very scalable on the architecture point of view from different vehicle variants. So I can have an entry level vehicle that is today does not need that level of information that level of actuators And then I can on the same platform since it is physically sitting there I can get to another high level premium vehicle on the same platform So it very scalable And that's very important for today, but also for tomorrow, because if we're talking about the central compute, a certain moment, we need to talk about the software defined vehicle. I want to get back to something that you've touched on a little bit here, which is how exactly a zonal layout can reduce the wiring complexity and the weight compared to the legacy approach. In fact, you are really asking me two questions in the same question. I need to split that to two parts. So the first part is the wiring complexity. And the second one is the weight. because those are really different depending on the topology, the architecture, and what we are really trying to do. And I think it's good to take an example and to compare. If we take a domain architecture, we know that each functional UCU often really rounds on its own harness legs across the car. So if we have, as an example, lighting, I can have a body control module that is sitting in the front and where I need to have all my cable back to somewhere in my relighting. And that's a lot of wire harness. But at the same time, the same wire is running through in the center of the car. We can also have some powertrain UCU. And then we have two cables that is also coming from the powertrain U and going somewhere else. So I may have some redundancy of the harness going through the same place and on the same voltage or doing really basically the same thing. So why do I really need that? And that's basically the domain architecture. Basically, that's the weakness of the domain architecture. When we're talking about the zonal layout, the different loads are mainly terminated near to the closest zonal they have. That's important, let's say, concept into the zonal. If we take really this zonal and we try really just to look a little bit more deeper, This zone is going to be having one backbone that is basically our power that is coming from a battery, 12 or 48 volt. It's not really the subject, but we are still in the zone. And then we will basically be replacing that redundant runs and those many long cables by many short branches. And if we are thinking about complexity point of view, or if I would like to link this complexity point of view to the weight point of view, we may say I am reducing the number of my long cables to the short branches, which means I am also reducing the size. Because instead of distributing high power, I may really just distribute very low power. Let me draw you a little bit more deeper picture. If we stay on the Zorval and this time we choose to have a higher voltage, for example, we move from the 12 volt to the 48 volt. If I'm comparing at ease of power, the current at a given power is going to be lower from 12 volt to 48 volt. That's physics, which is basically in our favor in this case. and that's going to be allowing us to have a smaller gauge copper, a fewer parallel runs, and then several kilograms of copper saving per vehicle that has already been proven in some studies. So we have a proof of concept, but we have also proof of concept that is running on the roads. So if I am comparing the complexity and the weight, the zonal is reducing drastically or basically is playing in our favor in this case. And that means that I can reduce the mass, I can reduce the cost, I can have a simply complexity that is drastically improving, but also I can improve my voltage stability over the backbone. I can really basically improve the vehicle itself and I can also improve availability for my customer. So my customer who is basically who I would like to please, I can get a very nice car for him while keeping everything simple and while giving him something efficient. Now, let's get back to what you touched on very early in the conversation, and that is premium EVs and robo-taxis. And the demands that these types of vehicles have on their power consumption as well as their processing power makes zonal particularly attractive for premium EVs and robotaxis. What are some of the other things that make zonal such a logical solution for those categories? If we take any premium EV or even the robotaxis, they are all concentrating a very high, large number of sensors. And we have also a very high level of power loads. We have many cameras. We have ladars. We need to have a seating who need to be moving with power now. So we need different motors everywhere. They basically all can benefit from a centralized compute and the clean power zone backbone. Basically, all the data of all the sensors can be effectively shared across all domains, across the ADAS, the body, the infotainment. in fact if we take those vehicles and let's say that's eric i don't know what car you drive the nissan leaf so a very entry-level ev yeah but you also have a pretty high expectation if you would like to have premium ev over your side you say i have an ev and i would like to have some premium expectation so i would like to be treated also as premium so on your side you would say if my car today is able to do this, I don't want to change my car in two years just to get a new update. I would like it to be updated automatically. And there is where it's really all of this zonal with the central compute came is that those cars will require a robust OTA updates. And by OTA, over-the-air updates. We're also going to be needing to have a strong diagnostic on my car. Also, I would like to have a service availability on my car. And seriously, with all the zonal controllers, we are able to integrate a lot of e-fuse in the solid state switches that give a lot of rich monitoring. But we will talk about that in a moment. But also they offer a lot of functionalities to isolate a fault, to keep the functionality, to keep the availability. And also the service need to always to be there. It's very important. Another example I also like to give is I'm living in Paris, Eric, and I like to go skiing in the Alps and it's pretty long ride. So I would like to have also premium car that can be versatile. So for example, I would like to be able to install a LiDAR only for a weekend and activate the self-driving functionality only for the weekend. And that's something that the Zonal is enabling on those premium EVs or just entry-level EV. You can make an entry-level EV So your Nissan LEAF, you can make it premium in the future if it is able to do that. And I think we can treat that in a moment if we can also talk about the scalability, if we can talk about the versatility of the EVs or of the zonal in general. And so let's start that by talking about why is the industry moving from a 12-volt only world to 48-volt backbones, especially in zonal architectures. So the key relationship is that current is power divided by volts. So if you quadruple the voltage from 12 volts to 48 volts for the same power, the current drops by a factor of four, which basically reduces your I squared R losses in the harness by a factor of 16. And that is huge. The lower current means smaller conductor cross-section, which also means lighter cables, lower copper cost, which is basically critical for vehicles as we are adding more kilowatts on the different functions. The HVAC blower the pump we have the steering we have the braking we have also the chassis actuators But also there something that we always forget to mention 48 volts remains within the low voltage safety range So we are basically avoiding all of those insulation creepage that is basically associated with traction voltage, 400 volts, 800 volts. But we are enabling much power distribution than the legacy 12 volts with this 48 volts. So for zonal architecture, a 48-volt backbone feeding local DC-DC converters in each zone is a natural way to deliver power nose-to-tail with good efficiency and manageable harness size. Let's dig a little bit deeper into 48-volt topologies that you see emerging for zonal power distribution. So for the common pattern, at least I'm really seeing, is a high voltage traction battery. So basically 400 volts or 800 volts. That's going to be stepping down to a 48 volt to generally an isolated DC-DC. With that 48 volt volts, it's going to be our backbone that's going to be distributed to the different zonal, ADAS, central compute, anything that really needs to be supplied. And on each zonal, we may have some local kilowatt DC-DC for any legacy 12V. Because we can't just move everything to 48V. And we can't stay on 12V. So those are two power voltages that need to continue surviving with each other. And then on the same zonal, we will have some e-fuses that's going to be played as a local power distribution unit. and different IOs that's going to be taking all the information from the sensors and delivering them again through that internet link to our sensor compute. There is also another pattern. And this pattern is more a hybrid one, when we can have a 12 volt, 48 volt, but the 12 volt this time is more a battery. And this battery, 12 volt can be used for the legacy and the safety critical functions. We keep the 48-volt delivered and everything else. So in all cases, the 48-volt network is tightly coupled to zonal controller for both power and data distribution as the zonal are aligned geographically on the vehicle. What are the main technical issues that our listeners, who are mostly engineers, need to be thinking about handling in 48-volt zonal modules? There is the protection side. 48 volt rails will see a higher fault energy. So we need really basically to deal with that. We can just remove it. So the short circuit event can develop fairly quickly and must be interrupted within microseconds because otherwise our harness may get damaged. The welding of the connector may be gone. And we also may have some very high localized heating. This is the first side of it. But there is a second side of it that we still have all the transients. I promise this is another challenge in the 48V. We will still be exposed to the load down, to the jumpstart, to some continuous over-voltage testing. And we have some ISO standards who are defining this, the ISO 21780. But now we're also developing a new ISO called the ISO 25769. And this one is going to be covering all of those, let's say, new transient voltage robustness that we need to be withstanding within an EV vehicle. May I ask how far away you think we are from having that standard officially adopted? The 25769 plan is to be available for public by the end of this year. We are very close to that. Basically, MPS is also part of that standard. One point that everyone really forgets about is the EMI, the electrical magnetic interference. It's also became much more demanding because we have higher power. We have faster switching DC-DC converter. We have DI over DT. We have higher DV over DT. And that's maybe a little challenge. So careful layout filtering, slow rate of the gate drivers. They need really to be managed correctly to meet all of the EMC or all the EMI and the CSPR25 that is requested out there. Another trend that needs to be addressed is the functional safety architecture, which is absolutely not trivial for the 48-volt. would have some safety relevant on the 48-volt path, and others need to be staying on 12-volt, and everything needs to be developed following the ISO 26262 concept, including all the easel decomposition, the monitoring, the safe state in mind. So that MPS, we know how to tackle those challenges for sure. Let's talk about the term software-defined vehicle, SDVs. This is everywhere these days. So I'd like to know how you would define an SDV and what does it imply for the EE architecture? So if you are looking to different textbooks, you would find they're all really defining the same thing, but just with different words, depending on your vocabulary. So the software-defined vehicle is where the majority of the functionality, differentiation, and lifecycle evolution is delivered through software. So the differentiation is going to be between one OEM and another one. That's very important because each one can develop his own software-defined vehicle platform. And then there is delivering through software rather than fixed hardware. And on the software, features can be added, updated, reconfigured over the air long after the vehicle leaves the factory. You can only make that possible, as a matter of fact, if your EE architecture allows it. And that's very important because what usually happens is that your hardware, it will become stable platform. And then the software is more moving. So each time you add the layers of the software through years of whatever you would like to be doing. And all the legacy architectures with dozens of hundreds of tighted couplet UCUs are simply not well suited to this model. So how does centralized compute play with zonal architectures and 48V come together to enable SDVs of today and in the future? So basically, the central compute platform, which are also called HPCs or central vehicle computers, they're basically consolidating the processing that was previously living in many UCUs. That was the domain or the legacy architectures. And the zone architecture relationship, central compute, is basically sitting off the edge of this compute fabric. So the Sona is going to be abstracting all of those inputs, outputs into logical services and by the different sensors, of course. And then it's going to be routing all of that data back to my central compute, which is the HPC. And it's going to be happening through the internet. And then the HPC is going to be running all the high-level control and perhaps even AI algorithm and also taking some decisions in the future. So the zone itself is going to be playing that sub-original work of taking all of the data and bringing it back to the HPC. And the HPC is going to be doing all of those high-level software work or tasks. And this combination drastically simplifies the software lifecycle management. Over the end, updates can target centralized software images rather than each small UCU. So where does power distribution and specifically 48 volt solid state protection intersect with this SDV story So if we would go to start with the SDV if I have eFuse in a 48 volt and I talking about SDV then I would like also to see my power distribution as a living organ. I don't want it to be static because everything now is software. And that's very important because my power distribution through my eFuse, it will become an active software visible resource because then the vehicle is able to monitor, reconfigure, and sometimes even reschedule power depending on load dynamics. So let's talk about the enabling technologies. How are you at MPS positioning yourselves to support the transition to 48-volt zonal, SDV-ready architectures? I will talk from my experience. So I have been with MPS now four years and I did see how MPS operates from inside. And our main idea is we are innovators. We try to fix problems. Also, we have another perspective of fixing those problems. We are more designing our IC from system perspective. We are basically making building blocks that can go within any system to fix whatever pinpoint you may have, but also on the system level. We don't only give you an IC, say, hey, this is an IC, and then you leave with it. No, no, we tell you, this is an IC as a building block fixing all your flow issues. And this is a key differentiator for MPS. Like, example, we have just released a new family of eFuses that everyone can find on our website. It's called MPQ 5884. And this is the first integrated e-fuse worldwide for the 48 volts. And we're putting inside everything I just said. Oh, the power switch is inside, the current sensing, the thermal sensing, the thermal protection, communicating all of this information, using them as data points, changing all of these dynamically. So we're really fixing all of those issues I just said. And that's what the software defines we can use, what the Zonan needs, and really enabling, let's say, tomorrow's vehicles. Can you walk through a typical 48-volt zonal power module architecture using one of those integrated E-fuses as you would explain it to our audience, other hardware engineers? Yeah, but NPS does not only do E-fuses. We have a huge volume of DCDC's conversion of gate drivers, of course, of PMICs, of also voltage monitoring that are coming and fixing all of those issues for the 48-volt. It's really the MPS DNA to fix those whatever issues we have on the system level. The first element is typically a primary e-fuse. That's exactly what we're talking about. 5884 is a good example. It's a 48-volt e-fuse, 15 amp, that is already integrated everything we need. So this e-fuse did to provide the inrush current, the overcurrent protection, the isolation of the zone itself, of the zone itself, from the rest of the vehicle in case of a serious fault. Then from there, we can have a downstream with the high efficiency DCDC that can convert to 48V to 12V for all the local legacy 12V loads. And we can also have another point of load from 48V to another voltage, 12V, 5V, to deliver all the power for our MCUs and our communication. Also, we need to have some other e-fuses for other loads on the 48-volt, but also other e-fuses or high-fist switches on the 12-volt that we have just prepared through that efficient DC-DC for all the basically subgroups like lighting, body actuators, or some other sensors. For my hardware follows, I would say you need to choose carefully what you are using because there's all of those small parameters that we will need to be taking care, like the tripping curve, the current limit, the timing, and all of these need to be configurable through the software. For the majority of engineers who are probably still designing with classic 12-volt domain architectures, how do you recommend that they mentally reframe the problem and start thinking about how they work on zonal in a 48-volt context? And we're thinking about this in three layers. power backbone, zoner boundary, and software boundary. Instead of asking, how do I route the 12 volt to this load from a central box? I more ask questions, how do I distribute the 48 volt efficiently to zones and then locally generate and protect the rails? On the architecture level, the functions that use it to be mapped directly to UCUs need now to be decomposed into services that's going to be consuming some input and output from the zones. And that's going to be executing whatever information on the center compute, which means that designing the zone of hardware to be generic and reasonable as possible. And from the software diagnostic level, as engineers, we really need to plan for day one for rich telemetry from power devices such as E-fuses and the DCDCs. Because the data is really necessary for our software-defined vehicle side and all our next year's OTA updates that we need to be having. What are the key safety and diagnostics considerations specific to 48 volt zonal power that you would highlight for a design team? These treat the 48 volts as a high energy, low voltage system. The voltage itself is within extra low voltage limits, but the available current, especially in EV, is very high. So the safety concepts must be each time addressed at the worst case short circuit arcane, thermal railway, in the harness or in the connectors. The second thing is you need to explore the capabilities of the EVE users or the smart switches. What is the current measurement accuracy? How programmable it is? How the fast fault detection can be done and use it for protecting, but also for the continuous diagnostic. For example, over the years, everything's going to be aging. So how can you really detect that? And that's pretty necessary, let's say, the tech center to do. And finally, integrating all of those devices within the IAIDO 26262 in the safety analysis. We are going to be supplying many safety-relevant on the power path, and that's going to be needing some appropriate redundancy monitoring and also very well-defined safe states. Would you please share with me what you expect mainstream production architectures to look like in the next, let's say, five to 10 years? I would say that the central compute plus the zonal are going to become the dominant topology in the future. But then the question would be how the 48-volt adoption is going to be happening. And seriously, when I'm looking to all the advantages of moving to 48 volts, Zonal, SDV, 48 volts are forming a love story. And if they're used all together, you can have a very nice vehicle. I could not agree more. I think consumers, manufacturers, and even designers and engineers. This is a win all around for everyone. And we also see that the old SDV concepts are maturing more and more. They're really heading there. Now, what I'm really seeing is that those three are going to be the predominant in the five to ten years. I believe in that. And I also think that MPS is going to be playing a huge role in enabling this future. Amitri, thank you so much for joining us. And thanks again to our sponsor, Monolithic Power Systems. Thank you so much, Eric, for having me and looking forward for next time.