Closing the Gap Between SIL and HIL for Software-Defined Vehicles

AUTOMOBIL-ELEKTRONIK: Mr. Hoff, how is business going?

Dr. Carsten Hoff: We had a positive year in 2024. The topic of testing and validation continues to be an area of focus. Everyone wants to become faster, and testing and validation always play a role in that. Because the complexity and proportion of software in vehicles is increasing, the effort involved in software validation is naturally also increasing. Strictly speaking, no new development has been possible without software and electronics validation for a long time already. The approaches are changing: fewer tests on the road, more HIL tests, and recently even more simulation. Software-in-the-loop, or SIL, was absolutely the main topic of 2024 for us, and SIL will become even more important in 2025. I've visited over 20 customers around the world in the last year, and I've spoken to all of them about software-in-the-loop.

What is the precise meaning of software-in-the-loop?

SIL means starting to test software functions without the target hardware being available, with this simulation running either on a PC or in the cloud. This shortens the time to market because we can start testing earlier and there are also additional scaling options. In China, OEMs have told me that they now develop a complete car within 18 months. That is already very impressive. If you want to implement this with the necessary quality, especially with regard to newer, complex vehicles, you can no longer avoid the targeted use of virtual testing.

Last year, we often still had delivery times of 9 to 12 months for our HIL systems. This simply no longer works in China, for example. The issue of time to market has also become a challenge for us in facilitating a good collaboration.

In addition, software-in-the-loop also enables a first time right for the designs, as errors can be found much earlier because a high level of software maturity can already be achieved before HIL validation. Our partner Stellantis announced a very interesting statistic at our User Conference. In their first project, Stellantis ran software-in-the-loop and hardware-in-the-loop completely in parallel to see when and with which method they would find errors. The result was clear: They were already able to find 80% of the errors in the software-in-the-loop phase. They were therefore able to progress to the hardware-in-the-loop tests and the test vehicles with a much higher level of maturity. Stellantis recorded these statistics working on one project, one vehicle, and one platform. Conversely, of course, we cannot say that every OEM will already find 80% of the faults in every vehicle project in the SIL phase: The figure is nevertheless still impressive to me, because this parallel work has now proven how valuable software-in-the-loop tests are.

What role does the SDV play?

The software-defined vehicle marks the transformation from hardware-focused to software-focused vehicle development. This transformation means that vehicle functions are increasingly controlled and calculated by software, regardless of where the function is physically required in the vehicle. We support this transformation with flexible XIL systems that allow our customers to test new functions independently and on a component-by-component basis on the one hand and in a way that is integrated in different software and electronics architectures on the other hand. In this way, we offer the flexibility required for this type of transformation.

However, skills also change with this. In the past, a vehicle often contained 100 or more electronic control units. Back then, the integration task consisted of integrating 100 electronic control units and getting them up and running, but now this takes place earlier and differently, because the new architectures mean that this task is carried out as software integration rather than as electronic control unit integration. In practice, this involves integrating many software blocks into software and getting them up and running in one electronic control unit. This is exactly what we support with software-in-the-loop, which is why many of our tools can also be used directly for SDVs.

However, consistency between hardware-in-the-loop (HIL) and software-in-the-loop (SIL) is crucial for the efficient development and validation of software-defined vehicles. HIL and SIL are complementary test methods that together form a seamless validation chain.

dSPACE has its roots in the areas of rapid control prototyping (RCP) and HIL. How has this increased demand for SIL changed the company?

Software developers already make up the largest part of our development team by far. Our RCP business is still relevant. But we started working on SIL simulation around ten years ago. Back then, it was more of a niche solution. Today, SIL solutions are becoming increasingly relevant. However, it is important to understand that HIL and SIL business will tend to coexist, because not everything can be mapped using software-in-the-loop simulation. Whenever we are dealing with the behavior of buses or CPU loads, we cannot avoid using hardware-in-the-loop. We therefore recommend that you always start with software-in-the-loop at an early stage of function development and concentrate on functionality there. When it comes to integration and physical behavior, it is advisable to switch to hardware-in-the-loop, albeit at a later stage than before. You can combine them in any way you like, and continuity plays an important role.

Many OEMs have told us that they had planned HIL tests, but then a supplier was unable to deliver the corresponding electronic control unit on time. Because one component is missing, the entire integration test would then not be possible. This again demonstrates the need for continuity. It is therefore our clear objective to enable continuity from SIL to HIL for various areas of application so that the same tools and the same artifacts can be used and then also changed in any way desired as much as possible. For example, if I find an error in the HIL simulation that I can debug better using SIL, then I bring everything back into the SIL environment for debugging. In my view, this is a huge advantage.

In the field of autonomous driving, every single software change has to be validated. What does that mean in practice?

In practice, there is only one sensible consequence: We need to move from classic homologation on the road toward digital homologation. This means that I have to rely on the simulation results, which I use for homologation. In order to move from conventional homologation on the road to digital homologation, it is crucial that the simulation results are reliable and precise. The reliability of the simulations depends on the quality of the models used and the accuracy of the data. Professional tools and advanced simulation platforms from an experienced supplier are essential for ensuring that the simulations are realistic and reproducible.

By using such professional tools, developers can ensure that the simulation results correspond to the actual conditions and can therefore be used for digital homologation. These tools then make it possible, for example, to model and analyze complex scenarios that are required for the homologation of vehicles.

This is where the cloud comes into play to test scenarios in parallel on a massive scale.

dSPACE has been generating scenarios for driver assistance systems and autonomous driving for a very long time. It is also possible to artificially generate scenarios that have not been seen on the road. Combinations of real and artificial scenarios are also possible. A good example of this is a car with a bicycle falling off the bike rack on the highway or the typical example from driving school where a ball rolls onto the road in a residential area and is quickly followed by a child running onto the road. We will probably never see this scenario when driving with the data logger, so we will not be able to record it. However, the industry wants to validate such scenarios, and this is precisely where digital validation comes into play. This means we no longer have to drive a million kilometers to test a certain scenario purely statistically, because we do part of this validation digitally.

How high is the percentage of digital validation?

In the end, the test planning lies with our customers and not with us, but I am sure that a large part will have to be validated digitally, not leaset because otherwise there simply won't be enough time. In addition, I can't manage to see all relevant scenarios in the real world. The exact proportion depends heavily on the methods used and, above all, the software and electronic architectures. For example, we also carry out precise planning with our customers by providing them with experienced consultants who draw up these plans and test strategies with them. It is clear that the proportion of digital validation is always significant and must become even greater in the future.

You mentioned digital homologation. How do OEMs manage to continuously add new software versions to vehicles via over-the-air (OTA) updates?

A software update must be intensively validated. From our point of view, it is important to have automated tests. If vehicle manufacturers offer updates every four weeks, this can only work if a very large proportion of the tests is fully automated and only a small proportion is carried out manually or on the road. It is therefore important to integrate the software pipeline, which usually builds new software overnight for almost all OEMs, directly into the simulation. This means running SIL tests immediately after code generation and then carrying out HIL tests. When the employees come back the next morning, they see the results and can continue working accordingly.

What role does artificial intelligence play in this context?

Artificial intelligence plays a role in many areas of development. We now use AI in the development departments, even in the area of software generation, to support developers. We also generate some test cases using artificial intelligence. However, the AI only ever generates small blocks for us, which we then have to look at in a targeted way and rework manually. We still have to process topics such as architectures, etc., completely manually. However, we also expect massive progress in these areas over the next few years.

Various artificial intelligence methods are used in the scenario generation process. The start-up understand.ai has been a wholly owned subsidiary of dSPACE for several years, and understand.ai generates ground truth by labeling images and video sequences, for which AI algorithms are already being used today. The labeling tool only runs in the cloud, but we can also process many other AI algorithms on PCs. And that's a good thing, because many customers are still used to using local installations, especially in combination with hardware-in-the-loop. For security reasons, many of the classic HIL labs are not connected to the Internet at all. With cloud applications, we are completely independent of the cloud provider.

We are also currently working intensively on generating test cases with the help of AI. Writing test cases is sometimes rather boring work. It is a rather repetitive activity, particularly for module and unit tests. The AI can do simple tasks for us here and might also discover a gap in the test that was overlooked when specifying the test. The AI might generate additional test cases here. We are deliberately not involved in the actual execution of the tests, as we are not an engineering service provider or a test house.

How can security tests be carried out efficiently?

Users can also carry out classic penetration and fuzzing tests on our HIL and SIL systems. We made a conscious decision not to develop our own cybersecurity solution in order to rely on proven solutions from a partner, just like our customers. We work closely with PlaxidityX for this. This means that the cybersecurity tests only require additional testing time on the existing systems.

What is your business model for testing?

We use the ASAM test matrix as a guide and work in partnership with our customers on this basis right from the start. We therefore have very little product business in the sense of catalog items, because around 80% of our systems are customer-specific. These systems always require partnership-based collaboration and intensive discussion. What is the best system for the problem I want to solve? That is why we are very closely connected with many customers and have formal partnerships with some of them. We can talk about some of these, but not others. Our partnership with Stellantis is a flagship in this respect. The company is one of the first really large customers to consistently rely on software-in-the-loop; it has built a virtual workbench in which all engineers work – with SIL as an integral component. This allows them to test and run functional simulations 18 months earlier than with the classic method, for which the target hardware must always be available.

In what sectors is dSPACE active?

We are also active in the aerospace, agricultural machinery, medical technology, and mining sectors. The energy market also offers us promising opportunities, particularly through the digitalization of power grids and the use of inverter-based feeder systems. However, our core business is the automobile. When I was recently invited to Brussels with other representatives of the automotive industry for a dialog on technological and digital innovation, I was able to bring all of our experience to the table. I highlighted a pragmatic approach to AI, the intensification of cooperation within the sector, and the strengthening of start-up initiatives as important aspects in order to promote both the speed of innovation and innovation expertise. The action plan to promote innovation, sustainability, and competitiveness that the EU Commission published in March will help our automotive industry to maintain its global leadership. Everyone is aware that dSPACE's strengths in simulation and tools are of great importance for the speed of innovation and must therefore be expanded.

What is happening in the field of electromobility?

We see three main areas of focus in e-mobility and are primarily active in the areas of batteries, charging, and inverters. When it comes to batteries, simulations of the battery management system are a major topic. When it comes to charging, on the other hand, we still see a number of combinations that do not work, i.e., that certain vehicles cannot charge at certain charging stations. Compliance tests are necessary in that area to ensure interoperability so that every vehicle works at every charging station. We have built a system for this that can be used to test all global standards, including AC and DC energy flow, in one place.

In the field of inverters, in addition to the need for extremely fast signal level test systems which validate the controller parts of the control units, we are also seeing increasing interest in moving the validation of the power electronics upstream. To close the gap between the signal level test system and dynamometers, we have built a test system so that the motor inverter and its power electronics can be tested without any mechanically rotating parts. This enables the test engineers to run through all driving scenarios without the need for large engine test benches.

How do we ensure that an SDV actually remains safe over the lifetime of the vehicle and what does this mean for the annual inspection?

If we stimulate all of the vehicle's sensors from the outside, the vehicle becomes 100% reproducible. We call this vehicle-in-the-loop, or VIL for short. In Korea, the authorities are considering whether such VIL tests should be carried out as part of the main inspection by companies comparable to TÜV, DEKRA, etc. Special test benches are then required to check, for example, whether the ACC brakes correctly after a corresponding stimulation of the radar sensors.

Such checks are very important, because if a new layer of paint is applied to the bumper after a small scratch, this can have a decisive effect on the radar performance due to the change in the thickness of the paint layer. Regular checks are therefore also required in this area. Even if the bumper has been repaired with filler, the behavior of the ACC usually even changes so that there is a risk of both false-positive and false-negative triggers. I therefore believe that we will also see regular inspections and tests in the area of assistance systems in the future, because looking at the fault memory will no longer be enough.

What is the significance of the Automotive Electronics Congress in Ludwigsburg for you?

For me, the AEC is still the most important event. I always go to two or three events a year, and Ludwigsburg and the CES are always on my agenda. The Automotive Electronics Congress is simply the top event for management contacts. The discussions with the management level and the level below it are also very good there.

How does dSPACE manage to always get enough employees?

We have and we need excellent people. Most of them not only want a challenging job, but also an excellent team and a good work-life balance – that's what dSPACE offers. Word is getting around that we are a deliberately family-friendly company. Our daycare center with its excellent staff-to-child ratio and outstanding educational offerings is just one part of this. However, we also give our employees some flexibility in order to balance family and career. Our corporate culture of a family business is really an asset, and I have the feeling that we have more women working for us as a technology company with over 90% academics than I have seen in other companies. But we are also well represented worldwide. Of our 2,800 employees at 30 locations, 1,600 work in Paderborn.

The interview was conducted by Alfred Vollmer, freelance specialist journalist, author and moderator.