Driver Assistance Software Validation Using Recorded Configuration Data
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The validation of software updates for driver assistance systems in vehicles is complex and expensive, requiring extensive real test drives to ensure compliance with predefined criteria, especially when significant changes occur, making it difficult to isolate and validate individual components within the complex network of system components.
Innovation Solution
A method that records input data and configuration information in a predefined data object, allowing for the conversion of data formats and enabling the validation of system components in isolation, even with radical software changes, by using an emulation container that includes input from other components, facilitating targeted troubleshooting and efficient validation processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If real test drives are used to validate software updates, then validation reliability is improved, but validation time and cost increase significantly
Solution Approach 1:
The patent creates virtual copies of test drive scenarios by recording sensor data, configuration data, and system response data during actual test drives. These recorded data sets are then used to emulate test conditions in a virtual environment, allowing multiple validation iterations without requiring additional physical test drives. This copying approach maintains validation reliability while dramatically reducing time and cost.
Solution Approach 2:
The patent performs preliminary recording of sensor data, configuration data, and system responses during initial test drives before software updates are applied. This preliminary action creates a baseline data set that can be used for comparison after updates, enabling validation without requiring new physical test drives for each software version.
2Reliability
If the entire system software is validated, then validation completeness is improved, but validation complexity increases
Solution Approach 1:
The patent segments the system software into individual components or modules, each with its own configuration data and system group identifiers. This allows the validation process to focus on specific software components rather than requiring complete system validation, reducing complexity while maintaining completeness for the updated portions.
Solution Approach 2:
The patent applies different validation approaches to different software components based on their specific characteristics and the nature of updates. Configuration data includes system group identifiers that allow tailored validation strategies for different parts of the system, applying local quality principles to optimize validation efficiency.
3Adaptability or versatility
If data format conversion is implemented, then adaptability to software changes is improved, but data processing complexity increases
Solution Approach 1:
The patent introduces configuration data as an intermediary layer between recorded sensor data and the updated software system. This configuration data contains metadata about data formats, system configurations, and conversion rules, enabling automatic format adaptation without requiring complex direct conversion logic. The intermediary approach simplifies the overall data processing architecture.
4Measurement precision
If extensive real test drives are conducted, then statistical significance is improved, but cost and resource consumption increase
Solution Approach 1:
The patent enables continuous validation by recording and storing test data for later reuse. Instead of conducting discrete, resource-intensive test drives for each validation cycle, the system continuously accumulates and reuses recorded data sets, maintaining statistical significance through repeated analysis of the same high-quality data with different software versions.
Data Source
AI summary
A method for validating software functions in a driver assistance system for motor vehicles. The method includes: a) recording input data of at least one system group to be tested, the input data being adapted to a first configuration of the system group to be tested; b) supplying the recorded data to the software of the system group to be tested in a second configuration and simulating the function of this system group in this second configuration; and c) comparing the system responses occurring during the simulation using predefined setpoint criteria. The input data recorded in step a) are combined in a data object, which has a predefined data structure, with configuration data, which describe the first configuration, and during the validation of the functions of the system group in the second configuration, the data supplied in step b) are generated from the contents of this data object.