An interview with Dr. Daniel Ulmer, managing director of Steinbeis Interagierende Systeme GmbH
Innovative testing platforms for modern driver assistance systems: Dr. Daniel Ulmer spoke to TRANSFER magazine about the requirements these solutions have to address, the importance of sustainability in software development, and a number of other key issues.
Hello Dr. Ulmer. In 2015, your Steinbeis Enterprise and Daimler won the Steinbeis Foundation Transfer Award – the Lohn Award – for the development of an innovative testing environment and the development of software instruments for use in advanced driver assistance systems. What was the biggest challenge for you and your colleagues with this project, and how is the collaboration working for you?
The solution we developed and continue to redevelop with Daimler is based on creating a simulation for environment-aware assistance systems which are put into serial production by Daimler. These systems survey their surroundings and partially operate the vehicle automatically. The challenge lies in making the simulation efficient, not just in terms of developing the simulation software but also when it is actually in use by test engineers. Hence the test engineers should be able to achieve their simulation goals with the least possible time and effort. We support a steadily increasing number of increasingly complex vehicle functions. Our aim here is to implement the simulation software in such a way that it can be run efficiently on different platforms, can be used worldwide, and users can be supported efficiently by our service team. Regarding the current collaboration with Daimler, we are continuing to develop the technology together so that we are able to efficiently test future vehicle functions.
Driver assistance systems are becoming more and more complex. How do you make sure they work properly, and how important are the right testing instruments?
The importance of testing platforms is rising rapidly – especially for high-end simulations. There are reports which say that the more complex an assistance system becomes, the more kilometers of driving will be needed in development. One example is an article in the Frankfurter Allgemeine newspaper on Nov 4, 2018, which says that a robot vehicle would have to be tested for over 240 million kilometers to ascertain whether it’s safer than a human being. This is the distance that’s required for a robot vehicle to be twice as good as a car driven by a human being with assistance technology. So 1,000 robot vehicles would have to be driven for the entire life of a vehicle. When you see numbers like these it’s obvious that such large distances can’t actually be driven – we can only simulate the highest possible proportion of this. Another factor is that lots of real and simulated kilometers generate massive volumes of data. We have tools and do research to look at different ways to cope with this deluge of data.
But by implication, simulations will have to meet certain quality standards. Yet there are no clear criteria for defining what these standards should be. Also there’s the fact that a simulation might do an outstanding job for the purpose for which it’s intended, but it might have to be used in different situations. Here’s a fictitious example to show what I mean: We’ve used our simulations to focus on what might happen with two simulated vehicles in certain situations and look at whether there would be an accident. But these simulations don’t allow to predict how badly one of the cars would be damaged after an accident. What I’m trying to highlight is that we can create simulations that meet high quality standards, but there’s no absolute quality endorsement. Or expressed more simply: Every question needs a simulation tool to match.
More and more customers place value in an intelligent driver assistance system when buying a new car. What does this trend mean for the work of your Steinbeis Enterprise?
We’re only indirectly affected by this trend at our Steinbeis Enterprise. Customers expect more and more functions when driving and want to know that they can trust the vehicle to take over certain tasks without being overwhelmed by warnings and having to take over themselves, especially on longer drives. This is raising their expectations of software and with that their expectations regarding our simulations. So we’re indirectly facing this issue. This means for us that driving scenarios have to be depicted more and more realistically. The simulation quality has to meet high standards and has to be evaluated over extended periods. So, our task is to capture more and more situations in extra detail over longer time frames. For example, older assistance systems didn’t recognize traffic lights but in the future they’ll have cameras that do that. As a result, until now we didn’t have traffic lights in our simulations, but now we integrate this functionality. That’s not as simple as it sounds, because there are lots of different types of traffic lights: turn left lights, pedestrian lights, lights on the left, lights on the right, lights on the top, different lights in the United States or Germany, and lots of different variations on how to tell a driver what to do. The implication for us is that we have to include a solution in our simulation to model different traffic light scenarios.
A priority for you is sustainable solutions. Why is sustainability so important and in what ways do your customers benefit from it?
When I hear the world “sustainable” in the context of software development, I immediately associate it with “front loading.” This means it’s better for our software architects to invest more time up front to understand the challenge and work out the first steps that will be needed to make the architecture viable in the long term. If I put myself in the shoes of the customer, I’d actually like to use a solution tomorrow. This is why our development experts approach things step by step to construct complex software incrementally with the customer. Our aim is to provide customers with a simulation that’s capable of working right away with functionality that expands incrementally. In concrete terms this first involves understanding the nature of a problem faced within the application scenario of a simulation. We use this to work out technology architecture, which we then implement step by step using different prototypes. This is an agile approach that lots of people are talking about these days. It’s sometimes a bit of a challenge making it central to what you do and who you are. We are driven by a desire to get this approach to work with the customer. This usually allows us to use iterative prototyping to develop the functionality that’s required by the software in the long term and thereby introducing it into the simulation environment. At the same time, these new functionalities are quicker and step by step available for the test engineers.