The automobile industry is facing numerous challenges in developing, verifying, and validating the increasingly digital and connected components that will define the vehicle of the future. In addition to pure services, customers expect continuous further development during operation which, in addition to safety-related updates through new features, maintains the value of the vehicle throughout the entire product life cycle.
We are therefore seeing not only new E/E architectures, but also overlapping phases of the development process. The vehicle is no longer seen as a self-contained product, but as an open system that can change throughout its entire life cycle. Improvements to the vehicle cannot be made by replacing hardware, as this would result in a significant logistical and financial outlay for both the customer and the manufacturer. Instead of this, the functions need to be provided by means of software, just as everyone is familiar with from their smartphone, for example. Both the exchange of apps and security-critical updates can be completed conveniently with one click. The term ‘software-defined vehicle’ is therefore used in this context.
Definition of the Problem – Data-Driven Approach
Why does this paradigm shift pose a major challenge to the automotive industry?
We must not view the software-defined vehicle in isolation, but always in conjunction with its environment. The vehicle environment not only presents the vehicle with an almost infinite variety of situations, but also changes continuously. The resulting uncontrollability continues through to the test task, which calls for data-driven solutions. The data is not only used for function development but is also required for validation at a later stage. This leads to a new problem: Collecting a large amount of data is not sufficient on its own, but relevant data sets must be filtered out of the almost infinite variety.
A new comprehensively designed process is necessary to facilitate this. The process must reach from data ingestion, through data processing and AI training, to overall integration, while being built on continuously repeating processes that further increase the maturity of the system with each iteration.
In the current development process, data is recorded on hard disks in the vehicle and read out at regular intervals. This takes place either by exchanging the hard disks or by WLAN transmissions at defined locations. In addition to the hardware costs, this requires a considerable logistical effort. Although this process can still be used during development, it reaches its limits when the product is ready for series production, at the latest. In addition to the immense hardware costs, reading the data is then only possible in long servicing intervals and is therefore not a practical approach.
Solution – Data Recording in the Fleet with Selection
So how do we need to structure the data acquisition to generate the urgently required data for the development process effectively in terms of effort and cost?
Here, we have to move away from the idea of the individual test vehicle and look at the entire vehicle fleet. The fleet consists of a high number of vehicles that participate in traffic on a daily basis. Consequently, we do have sufficient data, but the selection of relevant components remains critical.
What is the solution? Selecting data already in the vehicle itself, at the moment when it is captured. At the end of the day, only a few seconds may remain, but these seconds then represent a particularly interesting or even critical situation. If we think one step further, about the increasing connectivity, this approach can be extended to the fleet. If multiple vehicles are involved in the same traffic situation, the data sets can be merged in order to further restrict the amount of data to be saved and to make the scenario more comprehensive at the same time.
As a result of the significantly reduced amount of data, transmission using mobile communications is possible – irrespective of whether the data is stored in the cloud back end for the long term or processed close to the point of collection for latency-critical applications. This means that the user can dispense with expensive hardware, and the logistics for manual exchange and the associated vehicle downtime are also eliminated.
Due to the situational data acquisition, the data was already subjected to initial analysis and annotation with metadata at the time of capture. Therefore, efficiency can also be improved in model training and the subsequent tests. Similar scenarios can be filtered out from a scenario database and additional synthetic scenarios can be simultaneously derived. Synthetic scenarios are a targeted variation of the scenario parameters, which can range from covering a broad spectrum to testing particularly interesting situations. A very clear example of this is the variation of the trajectories of other traffic participants or the subsequent introduction of critical environmental factors such as rain, or glare from the sun.
Ideally, the iterative development process by means of SIL testing will take place in the cloud, as this ensures the highest cost efficiency with the shortest lead time at the same time. Once a sufficient model maturity has been proven, verification and validation take place in the next highest test instance, for example, on the hardware-in-the-loop test bench, before the algorithms can be conclusively tested in the test drive in particularly critical situations.
Validation and Verification
Even once the problem of data acquisition and function development has been addressed, a central problem remains unsolved. How can the safety of a software-defined vehicle be proven in an open environment which is constantly changing?
As with data acquisition, it is no longer sufficient to focus on individual solutions. It is also crucial to bring the many different players involved in the validation process closely together in a common platform. Furthermore, there is further potential to accelerate the processes if the testing is not only performed using the real vehicle itself but extends into the simulation domain. It is worth taking this step as early as possible and performing practical testing in order to lay the foundation for future standardizations that facilitate the cooperation between developers and auditors.
Together with the companies TÜV Nord, T-Systems, and Detecon International GmbH, dSPACE has presented the ‘digital loop’ as a powerful concept which, in addition to the development process, addresses continuous further development in particular. You can find more detailed information about this in the whitepaper ‘Connected Car Challenges Digital Loop – Data-Driven Development of Driving Function’.
About the author:
Strategic Product Engineer, Automated Driving & Software Solutions, dSPACE GmbH