Can AI redefine Software-in-the-Loop (SIL) testing for automotive software?
Key points
dSPACE utilizes FMI 3.0 and layered standards to enable standardized, highly compatible virtual ECU development.
Creating virtual ECUs manually is a complex, time-consuming process that often takes several weeks.
To overcome these bottlenecks, dSPACE is releasing an AI-driven V-ECU agent to automate virtualization.
Can AI redefine Software-in-the-Loop (SIL) testing for automotive software? Kevin Reim, Business Development Manager at dSPACE Germany discusses how AI-driven virtualization and standardized V-ECUs push SIL workflows beyond traditional limits.
- Reduce hardware dependency by up to 80%
- Automate testing while enhancing accuracy
- Achieve scalable, future-ready ECU development SIL, combined with AI, isn’t just an idea, it’s a practical approach to faster, more efficient automotive software development.
Transcript
00:00:01 I want to talk today a little bit about standardization. So standardized ECUs and the topic, which is everywhere around. So AI and how AI could help us in the virtualization challenge. Basically, I want to start with a introduction of where we are here with Software-in-the-loop. So many of you are already doing it, and especially if you are here in my breakout session. But for locating software in the loop topic itself, it is the case that we are in the V cycle very, very in the beginning on the right side, it could also be used on the left side. And when you have these CI/CD workflow for homologation and so on,
00:00:48 we are basically in this code phase where we have software in the loop as a, as a topic and as an environment, which can helps you to validate your, um, Yeah. Artifacts at the end. And when we are talking about software in the loop, the main thing is or the main difference to the HIL system, you do not have these hardware boxes anymore. So we have these virtual system under test, which we call as a V-ECU. So virtual ECU. And basically from here we will start into this challenge I would say. So what does software in the loop means for today and basically why so
00:01:33 many OEMs and also suppliers are looking to this topic, is that the complexity of software was increased in the last few years, uh, in a lot. And I think the Sangeeta from Stellantis has mentioned that yesterday and also from Nimmy from Nexteer has mentioned that from supplier point of view, why it’s important to overcome this challenge of software complexity with new approaches for validation. And obviously, there’s always the motivation behind there to reduce cost and also to gain time to market time more or less. And when you think about that, you also think about pipelining, how to do that. And that’s basically the motivation behind Software-in-the-loop as
00:02:25 well to have these automated testing in pipelining. And uh, yeah, that’s more or less the goals and the situation where the suppliers and also the OEM are in there is that, yeah, they want to get virtual artifacts either way. So the supplier needs to support it to bring it to the OEM side. But on the other hand, the supplier also should have it for their own processes. And when we have a deeper look to how these situation between OEM and supplier. dSPACE is experience. We talk like a triangle situation. So we have the supplier side which is delivering V-ECUs,
00:03:10 creating the ECUs and um have to deliver now virtual artifacts. And on the other hand, the OEM side, he wants to reach the validation goals in their system and also to get to digital twins. And there are these requirements now delivered from the OEM to, to the tier one side, so to the supplier side. So there’s a demand of that. And dSPACE is now helping both sides. So we are in close contact with the OEM about how to overcome these challenges. To get to the V-ECU, we are providing our experience with multiple OEMs worldwide, which we can incorporate here,
00:03:52 and also to answer the requests from the supplier side. So because the OEM is only successful if he can get in his supplier relationship here, and also to bring them in the shape to to deliver these artifacts, to get to this digital twin, which is on the horizon for, for all of these companies. So dSPACE role is not only to be the provider for the tools. We are also the experience we want to share with you, with our engineering service, to kick start your projects and also our consultancy. We want to bring in here. And that’s the situation where we as dSPACE bring value into this solution.
00:04:39 Okay. But there are often questions about when it comes to this triangle situation. Um, if it’s not fixed between the parties, what’s the format? What’s the effort? And also what’s the cost? So, um, first of all, let’s talk today about the format, and I think it was mentioned in multiple presentations in the last two days. It’s called the FMI, the functional mock up interface. And basically we want to talk about what it is exactly. So from the beginning, first of all, FMI is a part of the Modelica Association.
00:05:21 So a subproject inside a broader audience and a broader community where, for example, dSPACE and other OEMs or suppliers or tool vendors are in there and dSPACE understand themselves as the driving force of the FMI standardization. And we also put a lot of resources into it. But to understand what the FMI really is, um, it is at the end some kind of interface specification and also a container. So it combines some implementation and also an exchange format. And it comes with basically two main versions which are heavily used. One of them is the FMI two standard. It’s more basic functionality with signal based and stepwise simulation.
00:06:16 So signal based means only primitive data will be delivered from one artifact to another. And we have these fixed step size approach in the FMI standard. When we look about that and look to virtual artifacts and ECUs, we know there needs to be more to it. So that means we need another standard. And that’s now with the FMI three standard. It’s out there in the world. And it defines the features which were missing for addressing the needs for virtual artifacts at the end. And also to, to give you an insight about how many tools are on the market which
00:06:57 already supports FMI. They are close to 300 now, and we as dSPACE also providing 5 or 6 tools which are supporting FMI. But let’s talk a little bit more about the differences of FMI three and FMI two. So like I said, FMI two was not sufficient for virtual artifacts. And that’s why the motivation for FMI 3.0 was that we want to address virtual artifacts and also to advance the co-simulation capabilities. So put in multiple artifacts to one simulation. And um, yeah, we know that this step by support also comes with a bottleneck of
00:07:46 performance. So we need something more capable of having a performance, uh, simulation. And there was the need for having intermediate steps, having event modes and so on. So that came everything with, uh, FMI 3.0. And now that is the, the basis for what we as a V-ECU standard would say what it is. And okay, that’s the situation with FMI 3.0. We have everything on the plate, what’s needed. But that’s not enough. If we want to talk about compatibility when we say okay to deliver an artifact to
00:08:29 to another party based on FMI three, it could be interpreted in some way. So there need to be some kind of convention. And now we have a look into what that means. We come to this kind of layered standard. Maybe some of you already heard about that. And the layered standard is some kind of convention which Defines how the new features of FMI 3.0 needs to be utilized to realize bus functionality to realize XCP access. So that’s basically the main two standards which are missing to address V-ECUs. And there are additional ones like structural and reference layered standards, which are not that important for the specific use case of virtual
00:09:20 virtual ECUs. But for other domains it’s very valuable. So that’s why inside the FMI project, they are defining groups for this as well. But we stick to today a little bit to the XCP and also to the bus. So because that’s the essential parts we we need for the virtual ECUs at the end. So what was defined in the last 2 or 3 years for these layered standards is that there was a layered standard for RCP released, and that means you could utilize now your calibration tools, which you are using for the real target that can be utilized with these standardized FMUs as well. So you can access with these standardized tools,
00:10:14 tools, your real hardware, and also your plant models or your virtual artifacts. So that was the advantage from from here. And that’s already released. And we as dSPACE also support this in all of our products right now. So even for SCALEXIO and for our VEOS simulation. The next big layered standard, which is on track now is the layered standard for network communication. So it is called LS-Bus. And what this brings in is basically a specification. How binary? Um, yeah.
00:10:57 Binary transmission of signals can be done with event mode and event features. And this cluster to a so-called terminal. And based on that, you can now realize the standards for, for CAN, LIN, Flexray and Ethernet. And for everything of this is already a version available on the FMI open standard, but we come to that. Um, another point I want to do to, to make here is that the, uh, layered standard is also, um, distinguished in two parts. So there could be something like it’s called high cut where the abstraction is inside the or above the communication stacks and gives you the capability of
00:11:50 simulating busses without having the basic software to it. And the other approach is the so-called low cut, where we talk a little bit more about level three. V-ECUs maybe some of you are already familiar with that. And, um, yeah, we as dSPACE sticking and focusing on this low cut approach because we believe that’s the, the sweet spot of the simulation at the end. And there also comes some flexibility in the simulation with the layered standard. So it could be realized in three different ways. One way could be that you have two artifacts which talk needs to talk to each other based on CAN, for example, and you can directly connect them.
00:12:35 So a 1 to 1 connection that could be the most common way for connecting two artifacts. But then we are talking about idolized us because we have no behavior behind the bus. So for example, for timing, for bandwidth and so on. So there’s a second one. A second approach, which you can go here, is to bring in a so-called FMU for bus simulation, which is then the connection bridge between two artifacts. And this can also be something which simulates the behavior. So timing delays and also bus load that could be done with these extra container or extra artifact at the end.
00:13:23 And there could be the last option to implement this bus simulation inside the importing tool. And that’s basically what dSPACE is doing with VEOS. So we as dSPACE have developed the bus simulation behavior inside our importing tool, and there is no need to having direct like the first option to, to directly connect them. So you just connect it to, to the importing tool to the simulator and have the full bus communication like it’s in, in the real target or like it’s in the real world. So with bandwidth simulation, with connections for end to end connections and dynamic configurations at the end.
00:14:12 Okay. Maybe that’s an important part if you are interested into the roadmap. So I already said that there’s something out in the world for about every of these autonomous automotive busses, but maybe what’s important here is there are different kind of versions out of there. First of all, we have available these 1.0 release, the final release for the layered standard bus out there, which came with the capabilities of CAN. So that’s a very established, very mature version, which is out and already available and is supported by multiple tools. So for multiple vendors.
00:14:56 So there’s already something to, to cross check your FM use inside dSPACE tools or even with other tools possible. Then there’s the version 1.1, which implements the Flexray standard. And you can see there it’s a beta phase here. So it is officially released. But there could be some changes in the future. We do not believe as dSPACE that there’s much to do anymore. But we’re in the beta phase here and we with our tools have already implemented it. That’s also valid for the other two versions there. So the 1.2 and the 1.3, both in the alpha version.
00:15:39 And what they bring is basically Ethernet connection and LIN connection. So you can simulate basically all of the common automotive bus. Um, yeah, networks with our toolings inside a virtual world for software in the loop. And in the future, there could also come other busses, like for industry busses like Profinet and so on. That’s something for the future. But for the automotive world, we are in a good shape here. And we as dSPACE have realized and implemented all of these versions. Now, even if they are not released as a mature standard like you can see here, we have an exporting tool with SystemDesk,
00:16:26 and we have an importing tool with VEOS. And the main message I want to bring here is that dSPACE not only is the driving force of the standard, we are also the first and only provider of exporting and importing tool here. So there are a few tools already available which can import or can export, but it’s not from a single vendor here. But nevertheless, the end result should be that every other tool vendor should support it because we want to have these interoperability in there. So that’s why we are investing a lot. Okay. That’s basically for the standard itself.
00:17:07 Um, when we now have a look into the dSPACE portfolio, I already mentioned some, some parts of it where it plays a role here, but to give you more insights about what SystemDesk and also what this means is that for virtualization. So when you want to start with the development of virtual artifacts, then SystemDesk as you go, go to tool. So where you can basically exchange the parts which are hardware dependent, and the system is helping you to do this with, um, yeah, with this UI tool and also for automated tools. And it comes also with the capability of creating level one to level two and also
00:17:57 level three V-ECUs. And we have also solutions for, for the non AUTOSAR part, because we know there are also under other industries than automotive where AUTOSAR is not that important or for legacy ECUs where the AUTOSAR was wasn’t implemented. So dSPACE also provides solutions for this. And on the other side we have the implementation and integration. If you believe to get these artifacts. Now as a OEM, you want to have something which can import it and without any issues of compatibility. And that’s why also our importing tool VEOS is supporting with the next release, all of these features of the FMI 3.0 and also the layered standards.
00:18:48 So we are prepared for getting artifacts from different tools to consume them in our simulation. And our simulation capabilities comes with a time synchronization and also with some ISO standards. I don’t want to dig too deep into this topic, but to give you a feeling how it could look like and what at the end, it means to bring in artifacts from different vendors to, to one to our platform at the end. And like I said before, it’s good to have the tools. It’s also good to have both tools for virtualization and also for simulation. But at the end, it’s a crucial point to have the knowledge and to get the
00:19:31 knowledge when you are starting these kind of projects. Um, and there we provide these kind of services to you. So we could imagine to give you the engineering capabilities. So we have a lot of experienced guys here who can help you in the engineering phase and in the ramp up phase for, for getting to these virtual artifacts. But we also can have a look into your processes when you think about your validation process. And you now want to establish the new goal of the new testing goal, a new testing environment in software in the loop, we have services to, to give to, to your hand,
00:20:11 to analyze, make an analysis of where it makes sense to have software-in-the-loop and where it makes the most sense to have test cases and which test case needs to be run in which of the environments. So just for giving you a feeling what dSPACE can provide in this area, let’s come back to the virtualization. So I haven’t talked about a lot about virtualization itself. But now I also want to give you some technical, deeper look into this. So when we talk about level of V-ECU, we also talk about the cut where we say the upper part is the system under test.
00:20:55 So the real productive code you want to test and everything underneath is what you want to add as a vehicle for creating an artifact at the end. And in this picture, you can see everything. What’s blue is what we as dSPACE bring in, in, in an automated way mostly. And the red part is what comes from the OEM or from the developer itself. So that’s the productive code you want to validate at the end. And with these standardized way of doing it, we as dSPACE provide these FMI layer at the at the bottom. So we have the Inter-operability with the other platforms where FMI can run in,
00:21:43 and also the other way around. Or a simulator can speak to the FMI layer here. Um, that’s the difference to what we have done before with our system as tooling where we had our proprietary format. So that’s why we believe that’s the way to do it. And with this change in architecture of our FMUs, they come also some advantages and new features. I don’t think we need to touch all of them. But just for giving you a hint what that means. For example, we can now run FMUs on SCALEXIO in some of the some of them
00:22:18 already. We can also implement ECU reset functionality because we implemented it based on the FMI layer. So there comes some advantages. But the main message also here is that we are now capable of doing all the busses, so previously dSPACE wasn’t supporting Flexray. Now with the FMI standard, we can do that. Okay. Virtualization again, virtualization is something for somebody who hasn’t done it before. It’s maybe just a buzzword. And to give you a feeling what that means,
00:22:59 virtualization at the end means to, to create these virtual artifacts for a different environment, for a different kind of target. And I know from my experience with the customer, when I introduce these kind of topics to them that they are saying, yeah, I have some uncertainties with these processes. How do they look like? Is it really something where I need to invest to. So it’s, it depends at the end. Even if they see the value behind it, They are hesitant to invest into it because the the value is not always directly on track.
00:23:40 So that’s also why this picture is showing you the more it could be a tough way. And also the question of effort, how much effort is it for creating V-ECUs? Maybe some of you are already experienced it. It could be a day, it could be months. Don’t know. So I want to have a look into the process itself first. When you start with virtualization, you start with some kind of code files already. Maybe you are in the face. You have already your existing ECU and you want to start with virtualization now. So with a legacy program, for example, and you have these basic software layer, you have your complex device drivers,
00:24:26 you have your application layers, and maybe you have also some description files for hardware dependencies and so on. So that could be a starting point. And now you have to consider what needs to be done next. And first of all it could be if we are heading for level three V-ECUs. How do I implement this hardware dependent layer with the layer? So microcontroller abstraction layer, how could I implement these parts? And this needs to be done at first. Maybe another step is I have this application layer. Now my software components where the real functionality is in there.
00:25:09 Hopefully they do not have something in there which is hardware dependent, but it could be. So we need to analyze and identify this first. So that could be a task for it. Another task is when you have a look into the basic software layer. Of course it is based on the driver level. So on the MCAL layer, but there are definitely some parts in there from my experience that are still accessing some kind of registers or some hardware dependencies there. So that needs to be adapted to exchange that. And another thing is the complex device driver because they always access something. Um, what realized in hardware and how do I handle this.
00:25:57 Is it something where I can say, okay, I can leave it out. Is it something? Oh, I definitely need it for the functionality of the application layer. I need to implement something. I would say a mock or a stub at the end. So I need to decide how to solve this and maybe to, to have, uh, to close the interfaces here. And last but not least, how do I handle hardware acceleration or something like that? So something that’s really realized in hardware and now I need an implementation for this.
00:26:31 So that’s basically the task. What you need to consider when you think about virtualization. And I think you get the impression there’s a lot of things to do and to, to consider here. Um, we as dSPACE want, want also to share with you what’s our experience is with these kind of projects. And, uh, I have three examples for it. So a simple project where we have, for example, one software component, one functionality in there, maybe this thing has multiple interfaces, let’s say around about 100. And from our perspective, these kind of functionalities and features
00:27:12 could be realized as a virtual artifact within a week. So sometimes less, sometimes more. It depends at the end on how complex it is, but that’s basically our experience in the past. When we have a look at an, we call it average project. We see that typically there’s AUTOSAR components in there. So multiple artifacts. We have maybe also these kind of diodes or digital inputs and outputs there 100 of them. And we also provide some kind of CAN stack or something like that. So we have a first communication over over a bus network here.
00:27:55 And our experience is in this situation that’s we call it more or less an edge ECU is to have this up and running in 2 to 3 weeks. Every of these estimations is done when we as dSPACE also support you as a customer. So just for giving you an impression here, and then there could be the kind of complex projects. So when you think about zonal architecture, so MCU with the with multiple, so maybe 100 application software components on there with hardware dependencies with multiple bus stacks. So there’s Ethernet and CAN on it and a complete basic software for diagnostic, for memory management, for cyber security whatsoever,
00:28:44 everything is included. Then we as dSPACE experienced that it takes more than four weeks. So it could be done in four weeks. We have already done this. So it’s not a number here out of the sky. It’s really realistic. But at the end it could be last longer. And on the bottom you can see what influence this complexity and also the time for it. So the number of parts is a is a part. How many CDDs do you have there?
00:29:15 How much support do you get from dSPACE? Or how much experience do you have with virtualization already? Is it your first project? Is it maybe a. The 20th project already. So everything influence how much effort, how much time you have to do here. And the estimations are based on a single engineer who needs to work full time on this. Okay, that sounds like a lot even if you have this kind of complex projects. So. Everybody is maybe thinking about what could this process be accelerated by AI? Our answer is yes, it is. And that was our idea when we because we had this experience with multiple
00:30:03 customers now. And we know that that’s a bottleneck and we know this needs to be addressed. And our answer on this is called V-ECU agent. And that’s something what is now in a prototype state. From now, I will come to the roadmap. I will touch that point as well. But to give you an impression, yeah, we think about this because we know this challenge is something which yeah, brings SIL in a state where, yeah, it’s a bottleneck at the end where it blocks the success of SIL and also on your side as well as on our side. But to consider where AI helps, maybe let’s start,
00:30:51 start again. So okay, virtualization is a problem, but where could such an AI helps you in the process? So first of all, when you are somebody less experienced and do not know to do here, for example, like I showed in this manual process, if you do not know these steps to do these V-ECU agent could help you to create a plan. What is the process behind it? How to virtualize? That’s the first point. Another point is okay, I have prepared everything. Now I have an idea how to do it. I have the add effects available.
00:31:30 Now I need to analyze these kind of software I have here. And based on that, it gives suggestions about where these parts cannot run in a real in a virtual environment. So it can help to analyze the existing project or the existing ECU code, even if we are not experienced in or totally oversee the full, full stack of the ECU code here. And it could help you by generating these exchangeable things where you can see, okay, there’s hardware dependency in there, and I need to exchange them with some kind of stubbing so it could generate stubs for it and directly change this.
00:32:19 Okay. Now after these three steps, I could imagine maybe I have a V-ECU available and the next thing I want to think about is, okay, I don’t want to do this on my own again. So V-ECU is available and I want to automate this. So V-ECU agent, why don’t you help me here to generate automation for it, to run it in pipelines? So that’s the next step where you can think of another thing is, okay, I have automation, I have a pipeline, I have a V-ECU, and I now want to run it in a closed loop because we are talking about software in the loop, not open loop.
00:32:59 So it could generate a counterpart plant model for it. So some kind of test harness that could be easy for should be easy for such an AI. And the last part is when I imagine for virtualization, okay, I have something on the other side. I have a model, I have a V-ECU. I want to run this and after I want have started the simulation. Am I aware of every cause for bugs, for example, maybe the AI agent can also help me here to identify the source of the problem, to identify the bugs at the end. So that could be all kinds of use cases where an AI could help you in the
00:33:45 virtualization phase. And basically that’s what we want to address with the V-ECU agent. And as a value proposition, it should accelerate this creation process and overcome the bottleneck at the end of V-ECU creation. And we as dSPACE, are also interested in making your processes efficient. Let’s summarize what we know about our V-ECU agent at dSPACE. So basically it utilizes the Agentic AI as a platform and it. Yeah, transform the process of how you virtualize your artifacts. But based on what dSPACE experience is. So it is shaped for the dSPACE toolchain. It utilizes how we believe is the right way to do it.
00:34:39 And from our experience with, I would say, nearly 100 customers now, how it should do should be done. And it addresses the level of level three V-ECUs now, from now. So that’s from our perspective, the sweet spot of it. And it gives the user at the end also the flexibility to customize it. So for example, for, for prompting it, how, how the prompt files could look like maybe it could, could be enhanced from the, from the customer side as well, or from the user point of view. So that’s the flexibility.
00:35:15 And it even can be integrated into pipelining and provides the MCP interface for being integrated to other accessing sources for it. So that’s what the V-ECU agent stands for. And like I said, the first version of it will be officially released end of the year. And Carsten Hoff yesterday also had it on his agenda or on his roadmap for, for this. Um, but that’s not the only possibility to get it because we believe an early access is something we also want to provide. So nearly mid of the year there will be available to, uh, selected customer. I would say everybody who’s interested in and talk to us could have the possibility
00:36:05 to have early access to it, to give us feedback about it. And also, uh, give us the chance to enhance this. That’s for the part of AI used for virtualization. Now I want to summarize a little bit. We have touched basically two main pillars of the characteristic of dSPACE SIL solutions. One of them is we really believe in open standards, and we try to prove it for you in the way of driving these standards. The FMI standard especially, and we believe we need that for exporting and importing tools. So we believe that artifacts from other vendors needs to be consumed and the other way around, our artifacts could be consumed in other
00:37:03 environments. And we touched on the topic of virtualization with support of AI, but there are more to it. So one of the main things we didn’t touch today was also we call it the agnostic thing. So when you are in this situation of a supplier, you want to fit to multiple OEMs. So if you have to deliver the V-ECU to a specific OEM, then you also want to use the same artifact for maybe the other OEM. B so that’s what we believe is the right approach and what we provide here. And with even without having some kind of licenses in there, because we know there are tools on the market where these runtime license check
00:37:48 are in there. And we believe that’s just a hurdle for exchanging these kind of artifacts. And we also have these basic software agnostic, we call it that we can basically integrate any kind of basic software vendor. So if there’s a Vector, if there’s ETAS, if there is KPIT or Elektrobit, We can create V-ECUs out of this basic software. And last but not least, our tools and our artifacts can run in multiple environments. So it can run in the VEOS environment. It can run on our hill system. So this reusability is a very important point from our point of view,
00:38:38 which are characteristic of the dSPACE toolchain. To come back to what I’ve presented today is we touched on the FMI standard. I hopefully you understand now a little bit better now what it is and why dSPACE believes it is. It’s the standard for the virtual artifacts at the end. And we touched on the topic of virtualization and how it can be improved with the V-ECU agent. So like I said, there will be the release end of the year, but if you are interested, feel free to contact me and my colleagues and we can talk about this early access possibility. And last but not least.
00:39:26 That’s only two pillars of our portfolio in the regards of Software-in-the-loop. And dSPACE provides a lot of more things to the portfolio for models, for tools of calibration, for measuring. We can provide demos how to do SIL right. And we have these services for engineering and consulting. So I can just say, please feel free to reach out to me or my colleagues. And I think I hit the time quite good here for starting a discussion. dSPACE your partner in simulation and validation.
