Navigating the Shift to Centralized E/E Architectures in SDVs - MATLAB
Video Player is loading.
Current Time 0:00
Duration 24:19
Loaded: 0.67%
Stream Type LIVE
Remaining Time 24:19
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 24:19

    Navigating the Shift to Centralized E/E Architectures in SDVs

    Dr. Thomas Hülshorst, Group Vice President of Intelligent Mobility and Software, FEV Group

    The automotive industry's move toward software-defined vehicles (SDVs) prompts a reevaluation of conventional E/E architectures. This presentation analyzes the transition to SDVs, focusing on the impact on the development and integration of advanced features on cross-domain target platforms. The discussion centers on the shift from distributed to centralized E/E architectures, which is essential for supporting ongoing feature enhancements and updates.

    The FEV demonstrator project serves as a case study illustrating the application of a cross-domain central controller within a software-centric architecture. This project demonstrates the utility of service-oriented architectures and Model-Based Design workflows in creating scalable, adaptable vehicle systems that accommodate software updates post-production.

    Participants will hear a technical perspective on current trends in SDV architecture, offering insights into how these developments are managed to maintain a competitive edge in the industry.

    Published: 3 Jun 2024

    Very welcome to my part of the session, of the plenary session. Honestly, it's not that easy to talk about already such excellent, excellent presentations in the morning. So, already all set.

    But please allow me to share my humble perspective of a global engineering company working for a wide range of different kind of customers. Some of them, we work really in a greenfield approach, start-up companies. Some of them are more established OEMs, more the fast follower, which have also still the challenge to navigate the shift towards more centralized EE architectures.

    Yeah, to start with, with the first slide, it's the industry is transforming towards software-centric products. Well, it's not really breaking news. So we already have some experience with that.

    So maybe some of you still remember that phones originally were designed to talk to people. So in between, something happened. So still, you can do that.

    Nevertheless, will we experience something similar in the vehicle area? Probably not. So still, we will mainly use the vehicles to get from one location to the other. But in between, we are already spoiled.

    We are spoiled from the smart devices we use every day. We are spoiled mainly, and that's bringing the market demand to have adaptability, upgradeability. When you want the new, latest and greatest advanced features, it should be there even after you purchase the car.

    And that's the biggest difference. And honestly, that's the killer feature about the whole SDV story, if you ask me. So to get into this is a main driver from the market.

    Of course, at the same time, there's a cost reduction needed to also support this. We need to have more simplified, modular hardware which enables also to have more reuse, which is not that much customized. So today, if you go for a new development, a new feature over the last decades, it was always more or less a nightmare to handle the complexity of already the EE architecture who was used to grow over decades. Of course, also the software platform is another part of the cost driver, and by reusing even IT standards like, for example, Linux, it's a big benefit also to bring down the cost.

    Finally, there is a competition, and it's a growing competition. I heard about some OEMs developing in Chinese speed coming up with killer features even much earlier. And of course, to handle that also, we need to improve, and we will need to develop more efficiently with more virtualization, of course, and at the same time reduce time to market. So it's really a big challenge, I need to say.

    First of all, value for customer, that is clear. There's a nice statement coming from Jensen who more or less stated with a software defined car, the day you buy it is the worst it ever will be because there's so much more to come. So all the nice features which will be maybe even not invented when you buy the car, you will still have the opportunity to use it maybe four or five years later.

    And there's some magic needed to support this. And yes, we already learned a lot about that this morning. And yes, we are coming from, let's say, the black presence, and we need to go to the white future.

    And there is a step by step approach which probably is a shade of gray. And yes, it's not maybe-- it was a vision. It was a vision.

    So still, we see a lot of these already on public roads. Nevertheless, it remains a challenge to continue because the full potential of the whole story is not there. So we just started the journey.

    And that's a little bit also what I want to share with you. Again, being an engineering company, we were used to do a lot of controls, automotive controls. So we are a lot of activities we have in the powertrain controls if this is a hybrid car, if this is an electric vehicle, including the components management, the MCU, the battery management.

    And over the years, we also more and more went into other domains. So today, we have really IP in really different domains, including also ADAS/AD, including also intelligent chassis controls. Right now, just to give you an idea of what Christian already mentioned, we are also merging now the chassis electronics with the powertrain electronics to make it the vehicle motion.

    And the good thing is we did all of that using the same toolchain. And when we talk about legacy. We need not only to talk about functions-- we also need to talk about the toolchain, the processes, established, mature, reliable, automotive grade.

    Exactly that's where we started. And again, when we today merge functions together, it's not that difficult because they're coming from the same environment. And guess what? Yes, we are, of course, since decades, also using MATLAB Simulink as a partner.

    In the original phase, we used it together with Targetlink today with embedded coders. So there is, again, this reliable setup. We want, of course, also to bring for the next decade to come and working together with MathWorks as a partner to fix whatever is needed to be fixed to continue with this as part of our legacy as well.

    First of all, what changes we see coming, and honestly, which already came? So it's a mixture of the presence and, of course, the future. So we were used to have functions on dedicated embedded controllers.

    New functions? OK, here is another controller, or you add it to an existing one, whatever. But there was always this relationship function equal controller. Now in the new architectures, we have a degree of freedom, which is amazing, which gives us, of course a lot of potential for benefits.

    So we could put our function still on an embedded controller, maybe on a zonal controller, on an HPC, or maybe even in the cloud. So there are different targets we could go for. The other one, of course, we come from the signal orientation.

    So personally, I'm a controls engineer from the region. So I grew up thinking in signals and how to handle signals. But what we now need to go more and more towards the service orientation and, of course, to find the best way how to get from the one setup to the next.

    Finally also, when we think about the VNV, so we thought also today, so the classical mill, vill, hill, yes, that's the standard. And of course, still, we also want to have it. But with the virtualized platforms, we also need to have virtualized validation and verification. So that's also part of the story.

    There are benefits. Are these benefits important for all of the features we have? So of course, the benefits going from an on-board ECU, our classical embedded solutions we love since decades, to the next step, yeah, of course, we will have improved performance. That's great.

    We would also at the same time have better access to data. If we even go the next step to a cloud environment, performance is unlimited. Wow, that's great. At the same time, we have also much more data access.

    So yeah, it's cool. So there is nearly no disadvantage, it seems to be. Maybe the availability, which still is not, at least in Germany, not perfect when we think about the net connection. But of course, if it would be that clear, we would have been much faster in the past to go this journey.

    Of course, on the other side, we need to remain automotive grade. It's a difference. If I have a consumer electronics, a blue screen is not a big deal. In a car, no way.

    I need to bring my family home safely. And there's no excuse by any means. Whatever happens in the car, it needs to be safe. So that's the other side of the medal.

    So if we want to go more towards cloud environment or onboard HPC, at least there are some challenges. So hard real time functional safety, we solved it. For the HPC, yes, we can solve it. But it's more effort.

    So it does not mean that it's not doable. It's doable. That's clear. But it's more effort, simply more effort.

    And of course, we need to have one eye on the cost as well. But finally, the cloud environment, of course, there are some limitations which also are very clear. So can we handle a functional safe function in the cloud today? Probably not.

    Just two very simple examples to a little bit illustrate what I have in mind in this regard. So I mentioned we have some features off the shelf. So one, for example, is a field oriented control for the vehicle motion for the electric motor control.

    So what are the boundary conditions? I have very strict real time requirements. I have very strict functional safety requirements. I have a clear requirement to adapt to the controller hardware.

    And the function is pretty much fixed. When it works, it works. So no need for updatability, no need for upgradability, no need for data-driven whatever. So, what's the decision?

    Yeah, keep it on a local ECU So, why we should change it? There is no benefit but some drawbacks. Oh, sorry.

    On the other side, when we talk about a range estimation of an EV, so I don't have real time requirements, at least not strict, hard real time requirements. The functional safety requirements? No, but I have a lot of benefit.

    I can use more computational power, but also, I can use improved data access. I have access to even fleet data, which then can also be applied to have a simply better accuracy of my function for the range estimation. So this is just to give you two examples. So here, yeah, it might be recommended. So let's go, at least on an HPC, get the benefits in place, or maybe let's even go to the cloud.

    So one of the remaining challenges is the complexity. It's also in particular when you want to reuse legacy, if you don't want to have the pure greenfield approach? How to handle this in the best way?

    So we have an approach which is model-based systems engineering. We call it CUBE. It's a 360 degree philosophy, which is mainly a kind of a combination of systems engineering but also bringing it into all the disciplines.

    So it is one of the biggest challenges to change the mindset. So if you have a team which was used to work in a special mode since years, it's not easy to change this mindset. For example, starting with systems requirements, and this is the starting point, it's not-- guess what?

    It's not the standard. So at least for our global customers we have, still, we need to convince in each and every project the customer, yes, let's please first fix the systems requirements, and then we go into the features of the different domains. OK, however, so this is also a clear responsibility share which needed to be in place.

    And then, of course, doing the technical job, using this approach to break down the decomposition from the ecosystem to the product to the domain, sub-domain, components, the different abstractions from the system design down to the system integration, and all the processes behind. So the big benefit here is it's a consistent systematic approach which also enables reuse, which enables quality, and which at the end of the day also includes automatization-- for example, test case generation.

    There's another focus also on non-functional requirements, which are also very important, in particular when you need to design a new architecture. And it's a very efficient management of legacy and off the shelf as well. So combining legacy and off the shelf products, you can buy from customer-- from partners. And to handle this together is supported. And finally, it's a seamless handover to the software architecture design.

    In detail, it looks, of course, a bit more complicated. And I was asked to save some time. And also, this is pretty much to our engineering daily business. You prepared everything, and then last minute, you need to save 30% of the time. So I will try to do my best.

    So to make it short, so it's a very systematic approach. Where you start with the feature analysis, the requirements, then you go to the system architecture, the functional behavior, then to the topology mapping, the decomposition. And of course, you do all of these steps with regard on the domain, the performance, the functional safety, cyber security, the network, the hardware requirements, whatever.

    So you can already do a lot even before you take the final decision of your target platform. And that also is what brings you the high reusability and the benefits I just mentioned. Then, of course, the final step needs, then, to fix the protocols, the EE architecture. But if you then go for the next project, you can start here maybe, and you don't need to go through all of that again.

    OK, another question is, again, how to get control on the costs. So when we did the first teardown of a Tesla-- 2015, if I remember well-- so we went through the BOM, and we said, oh, we missed something. There is a page missing.

    Where are the controllers? So there were literally two controllers, which was the head unit and the inverter, the inverter probably also hosting the powertrain control, the head unit taking care about all the rest. So that was impressive.

    Nevertheless, when you have a closer look to, for example, the model three, that was the first time Tesla really needed to earn money. So they had a stronger requirement to have a cost-driven approach. You will find a very nice hybrid architecture.

    And exactly that's what I want also to mention here. We have some legacy. So we come from the traditional EE architecture, which, in the best case, was already domain-centralized. So we could continue here, of course, and replacing single controllers by domain controllers.

    Another approach, of course, which is very popular, I would say, is to have a central compute plus two, three, four zonal controllers depending on your vehicle architecture. Still, it could be even more simplified. But what I just want to mention, and again, switching back also to the reference of Tesla model three, which is a combination-- so for example, they decided to have an HPC for the ADAS/AD, which is the most challenging.

    They combined it with the infotainment, which has the biggest demand on upgradability, updatability. So the driver of the car will have a direct visible impact with this feature. So they decided to have the ADAS/AD and the infotainment merged in one.

    That still called it central compute. They combine it with three zonal controller, but still, there's a lot of legacy. The BMS, the inverters, all of that-- so still off the shelf because again, there was no benefit to change it.

    It was the more affordable way to reuse it. There's still one very central thing in the whole architecture, which is the vehicle brain. The vehicle brain really brings the biggest benefit in the new architectures.

    And here also again, we have several options how to organize it. For example, we could go for a virtual machine architecture, which is the easiest way to go for your legacy, to migrate your legacy code you already have, to put it in a virtual machine, to connect the virtual machine with the virtual bus. So more or less it's doable without big effort.

    On the other side, it's also the best for safety reasons. So you have a little bit more protection. It's more encapsulated. You have memory protection.

    So there are good reasons to go for a virtual machine. On the other side, the containerized architecture gives you more opportunities for over the updates. Even single features can be supported by this.

    It's the leaner design. It's an improvement regarding performance. It's an easier way also to communicate between the different containers. It's overall a leaner approach. And finally, if we really want to get the full usage out of this architecture to have a lot of central services, I put my applications on top of it. Yes, it's even the best way to even improve further my reusability of the software.

    So which is the best architecture? Any opinion on that? Yes, exactly, the combination, depending on the specific features.

    So I have, again to go for the shades of gray to find out what is the best setup for my specific situation I'm in. So then finally, what we did as a company, engineering company, we wanted to show that we handle all of this complexity. So we started with our own SDV core platform roughly 2 and 1/2 years ago. So at that time, we decided to go for a renaissance R-CAR together with NXP, IMX8.

    So the next generation we're working on right now is more going to the NXPS32 family and Qualcomm because we need to have some flexibility. So we use here a QNX type one hypervisor on top of it. And we put the virtual machine approach.

    We wanted to show in just three months, that was the original time schedule for the first demonstration, to migrate out powertrain functions, torque management, ADAS functions, adaptive cruise control, cluster functions, and infotainment functions to also showcase a mixed criticality use case, so to bring together safety relevant features and non-safety relevant features on the same application. So that's what we did here. We used for the virtual bus both and DDS.

    Why? Because we want to just to learn about it, to learn about the differences, the challenges, how to handle it. Again, it's a kind of a sandbox example. We just wanted to have something to play around with.

    But in the meantime, we used this already in two projects as a starting point. And all of that was designed also to be integrated to the car. Nevertheless, we started with a more mobile setup, so a kind of a small lab car using the simulation instead the real car just to demonstrate that it simply working.

    So this is together with what I already mentioned, where we started with 2 and 1/2 years ago. Maybe we were already a bit late. But I would say what in the meantime already was achieved is pretty impressive and shows it's doable. You can be fast, but you need to be very much focused on where is the biggest benefit and how to handle it by reusing as much as possible you already have, yes, so to do the modifications was necessary.

    So for example, the development workbench, so talking about collaboration, essential, was already mentioned this morning twice but also the processes, the whole software management, CICD, setting up the whole cloud data center infrastructure. And finally, the full benefit you only get when you really set up also the virtual engineering framework. And this is exactly where it is so hard to cover this as an engineering company. You need to work together with partners.

    And this is one of my two final slides. So it's just illustrate. So it's also a journey we started last year together with partners.

    So it's called Digiloop. It's heading what Christian already mentioned in his presentation also towards even virtual homologation. So not stopping with doing the testing, shadow mode, whatever activate, but also, for example, there is a use case, ALKS-- so, Automated Lane Keep Assist, for example. There is a new whatever, regulation coming, allowing a wider ODD.

    The cars are already in the field, how to handle it. So here, the idea is really to start with the new requirements, the new rules and regulations where our partner control is supporting this. will then take over to do the requirement engineering, the design, and implementation, working together with dSPACE for the whole simulation validation, and then for the final homologation.

    So again, it's just started. It's nothing you can get tomorrow, but it just shows again that it's a challenge, and you need to have different players working together very closely to come up with something which is applicable at the end of the day to the reality. Finally, and that's a kind of a summary. It's just, again, showing there are three levels, at least from our point of view, which are important.

    So to have the system and the component excellence at the same time to take the right decisions about the EE consolidation, to establish agile and also cooperation schemes-- so, agile cooperation. So, two things together-- to do the cooperation, working together with partners by doing this agile, and of course, at the end of the day, to bring together all the added value off the shelf to increase the features. But finally again, we need to have the proven software development framework in place to have the automotive grade requirements met.

    And also, what was just mentioned, if I remember well, it was Juergen mentioning. So the AI still is, of course, a little bit of a must have, at least for the higher degrees of automation. But still, it's not trusted.

    So you need to have another level controlling more or less what the AI part is doing. And also, this is again a part of the whole thing, not only thinking about the technology, again, hardware software, but also the processes behind, which is essential. So that's more or less what I wanted to share with you. Thank you for your attention, and I would be more than happy to answer questions.

    View more related videos