Vehicle expected function safety verification method, device, equipment and storage medium

Abstract

This application provides a method, apparatus, device, and storage medium for verifying the expected functional safety of a vehicle. The method includes: constructing a simulation test scenario library corresponding to the expected functional safety of the vehicle based on existing map data and multi-scenario driving data; performing in-loop testing on the expected functional safety of the vehicle within each simulation test scenario in the simulation test scenario library to obtain a corresponding accident scenario library and a non-accident scenario library; and determining the verification result of the expected functional safety of the vehicle based on a preset expected functional safety acceptance criterion, the accident scenario library, and the non-accident scenario library. This application can utilize a rich and highly realistic simulation test scenario library to achieve comprehensive and effective verification of the expected functional safety of the vehicle, ensuring sufficient and accurate verification of the expected functional safety of the vehicle, enhancing the practicality and observability of the verification, and improving the safety of vehicle operation.

Description

Technical Field

[0001] This application relates to the field of vehicle data processing technology, specifically to a method, apparatus, device, and storage medium for verifying the expected functional safety of a vehicle. Background Technology

[0002] With the rapid development of autonomous driving technology, vehicles equipped with autonomous driving systems are becoming increasingly common in people's daily lives, leading to widespread concern about the safety of autonomous vehicles. The safety issues of autonomous vehicles are mainly due to the limitations of autonomous driving systems and the resulting lack of expected functional safety (SOTIF).

[0003] Currently, there is no authoritative and universally accepted solution for verifying the expected functional safety of autonomous vehicles in the industry. Expected functional safety verification is typically achieved through long-term real-vehicle testing. This involves testing the vehicle on various real-world roads for a certain distance and confirming that no accidents occur during this period, thereby verifying the expected functional safety of the autonomous vehicle.

[0004] However, the above-mentioned expected functional safety verification scheme needs to cover most real road conditions, but is limited by real vehicle testing in various real road scenarios, and the real vehicle testing cycle is too long, so it cannot guarantee the comprehensive and effective verification of the expected functional safety of the vehicle. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for verifying the expected functional safety of a vehicle. It utilizes a rich and highly realistic simulation test scenario library to achieve comprehensive and effective verification of the expected functional safety of a vehicle, ensuring sufficient accuracy in the verification and improving the safety of vehicle operation.

[0006] In a first aspect, embodiments of this application provide a method for verifying the expected functional safety of a vehicle, the method comprising: Based on existing map data and multi-scenario driving data, a simulation test scenario library corresponding to the expected functional safety of vehicles is constructed. In each simulation test scenario in the simulation test scenario library, the expected functional safety of the vehicle is tested in the loop to obtain the corresponding accident scenario library and non-accident scenario library; The verification results of the vehicle's expected functional safety are determined based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library.

[0007] Secondly, embodiments of this application provide a verification device for the expected functional safety of a vehicle, the device comprising: The scenario library construction module is used to build a simulation test scenario library corresponding to the expected functional safety of vehicles based on existing map data and multi-scenario driving data; The in-loop testing module is used to perform in-loop testing on the expected functional safety of the vehicle in each simulation test scenario in the simulation test scenario library, so as to obtain the corresponding accident scenario library and non-accident scenario library. The expected functional safety verification module is used to determine the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library.

[0008] Thirdly, embodiments of this application provide an electronic device, which includes: A processor and a memory, the memory being used to store a computer program, and the processor being used to call and run the computer program stored in the memory to perform the vehicle expected functional safety verification method provided in the first aspect of this application.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium for storing a computer program that causes a computer to perform a verification method for the expected functional safety of a vehicle as provided in the first aspect of this application.

[0010] Fifthly, embodiments of this application provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the vehicle expected functional safety verification method provided in the first aspect of this application.

[0011] The technical solution provided in this application first constructs a simulation test scenario library corresponding to the expected functional safety of a vehicle based on existing map data and multi-scenario driving data, ensuring the richness and high realism of the simulation test scenario library. Then, within each simulation test scenario in the simulation test scenario library, in-loop testing of the expected functional safety of the vehicle is performed to obtain corresponding accident scenario libraries and non-accident scenario libraries. These are then combined with preset expected functional safety acceptance criteria to determine the verification results of the expected functional safety of the vehicle. This allows for comprehensive and effective verification of the expected functional safety of the vehicle using a rich and highly realistic simulation test scenario library, significantly shortening the verification cycle and reducing costs, ensuring sufficient and accurate verification of the expected functional safety of the vehicle, and providing quantified expected functional safety verification indicators using expected functional safety acceptance criteria, thereby enhancing the practicality and observability of the expected functional safety verification and improving vehicle driving safety. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 A flowchart illustrating a method for verifying the intended functional safety of a vehicle, as provided in this application embodiment; Figure 2 A flowchart illustrating another method for verifying the intended functional safety of a vehicle, provided in an embodiment of this application; Figure 3 This is a structural block diagram of the HIL test bench provided in an embodiment of this application; Figure 4 A schematic block diagram of a vehicle expected functional safety verification device provided in this application embodiment; Figure 5 A schematic block diagram of a vehicle provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0015] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices.

[0016] To address the limitations of existing vehicle expected functional safety (EVS) verification schemes, which require coverage of most real-world road conditions and are constrained by extensive real-world vehicle testing and lengthy testing cycles, this application proposes a novel EVS verification scheme. Based on existing map data and multi-scenario driving data, a simulation test scenario library corresponding to vehicle expected functional safety is constructed. Within each simulation test scenario in this library, in-loop testing of vehicle expected functional safety is performed, resulting in corresponding accident scenario libraries and non-accident scenario libraries. These, combined with pre-defined EVS acceptance criteria, determine the verification results of vehicle expected functional safety. This comprehensive and effective verification of vehicle expected functional safety is achieved using a rich and highly realistic simulation test scenario library, ensuring accurate and sufficient verification and improving vehicle driving safety.

[0017] Figure 1 This is a flowchart illustrating a method for verifying the safety of expected vehicle functions according to an embodiment of this application. This method can be executed by the vehicle expected function safety verification device provided in this application. The vehicle expected function safety verification device can be implemented in any software and / or hardware manner. Exemplarily, this vehicle expected function safety verification device can be applied to any electronic device, including but not limited to tablets, mobile phones (such as foldable phones, large-screen phones, etc.), wearable devices, in-vehicle devices, laptops, ultra-mobile personal computers (UMPCs), servers, netbooks, personal digital assistants (PDAs), smart TVs, smart screens, high-definition TVs, 4K TVs, smart speakers, smart projectors, and other various computing devices. This application does not impose any restrictions on the specific type of electronic device.

[0018] Specifically, such as Figure 1 As shown, the method may include the following steps: S110, based on existing map data and multi-scenario driving data, constructs a simulation test scenario library corresponding to the expected functional safety of the vehicle.

[0019] In this application, the vehicle is typically an autonomous vehicle. To ensure comprehensive verification of the vehicle's intended functional safety, it is usually necessary to cover most real-world road environments and specific driving conditions under which the vehicle operates with an autonomous driving system to verify the vehicle's intended functional safety.

[0020] Therefore, this application can collect the corresponding full high-precision map data from the background databases of various existing map software as the existing map data in this application. This existing map data may include multiple road elements that make up the base map roads. Each road element is used to describe various road-related descriptive information such as the road itself, functional facilities, lanes, roadbed, pavement, bridges, tunnels, protective facilities, traffic signs, and markings.

[0021] Furthermore, this application can collect a large amount of real-world driving data from vehicles under various driving environments, and perform corresponding road condition scenario analysis and vehicle state analysis on the collected raw driving data to extract scene elements and driving states under various real-world driving scenarios, thereby merging the multi-scenario driving data in this application. This multi-scenario driving data can include multiple scene elements and real-world driving states for each real-world driving scenario. Scene elements are used to describe various scene-related descriptive information such as entity objects, events, and actions in each real-world driving scenario. Real-world driving states are used to describe the actual driving state of the vehicle monitored by various vehicle sensors in each real-world driving scenario, such as whether the vehicle has experienced a collision, sudden braking, or stalling.

[0022] Then, by comprehensively analyzing the existing map data and the multi-scenario driving data, the relevant road elements and relevant scene elements at the same location are determined. The relevant road elements and relevant scene elements at the same location are merged together and combined with the actual driving status corresponding to the relevant scene elements to construct multiple simulation test scenarios for the expected functional safety of the vehicle, forming the simulation test scenario library in this application.

[0023] Therefore, each simulation test scenario in the above simulation test scenario library is composed of multiple road elements and multiple scene elements in the corresponding location area under real road conditions, combined with various driving states of the vehicle in this location area, making the simulation test scenario library rich in variety and highly realistic.

[0024] S120, in each simulation test scenario in the simulation test scenario library, performs in-loop testing on the expected functional safety of the vehicle to obtain the corresponding accident scenario library and non-accident scenario library.

[0025] After constructing the simulation test scenario library, this application can traverse each simulation test scenario in the library to analyze various driving states in each simulation test scenario. Then, based on the various driving states in each simulation test scenario, it controls the constructed vehicle model to simulate driving in that simulation test scenario and records whether the vehicle model experiences driving failures in each simulation test scenario, thereby completing the in-loop test of the vehicle's expected functional safety in each simulation test scenario.

[0026] Furthermore, after completing in-loop testing within all simulation test scenarios in the simulation test scenario library, this application analyzes whether the vehicle model experiences a driving malfunction in each simulation test scenario. This allows for the aggregation of the corresponding simulation test scenarios in the simulation test scenario library where the vehicle experiences a driving malfunction, forming the accident scenario library of this application. Moreover, by aggregating other simulation test scenarios in the simulation test scenario library where the vehicle does not experience a driving malfunction, this forms the non-accident scenario library of this application.

[0027] S130, determine the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library.

[0028] The expected functional safety acceptance criteria may include pre-defined expected functional safety verification indicators and the indicator conditions that the expected functional safety verification indicators need to meet to confirm expected functional safety.

[0029] After obtaining accident scenario libraries and non-accident scenario libraries for the expected functional safety of the vehicle after in-loop testing, this application can calculate the specific index values ​​of the above-mentioned expected functional safety verification indicators under this in-loop test by analyzing the relevant accident information in each accident scenario library and each non-accident scenario library.

[0030] Then, by determining whether the specific index values ​​of the above-mentioned expected functional safety verification indicators under this loop test meet the index conditions set in the expected functional safety acceptance criteria, it is determined whether the vehicle's expected functional safety has passed the verification. Thus, the expected functional safety acceptance criteria are used to provide quantitative expected functional safety verification indicators to determine the verification results of the vehicle's expected functional safety, thereby achieving comprehensive and effective verification of the vehicle's expected functional safety.

[0031] The technical solution provided in this application first constructs a simulation test scenario library corresponding to the expected functional safety of a vehicle based on existing map data and multi-scenario driving data, ensuring the richness and high realism of the simulation test scenario library. Then, within each simulation test scenario in the simulation test scenario library, in-loop testing of the expected functional safety of the vehicle is performed to obtain corresponding accident scenario libraries and non-accident scenario libraries. These are then combined with preset expected functional safety acceptance criteria to determine the verification results of the expected functional safety of the vehicle. This allows for comprehensive and effective verification of the expected functional safety of the vehicle using a rich and highly realistic simulation test scenario library, significantly shortening the verification cycle and reducing costs, ensuring sufficient and accurate verification of the expected functional safety of the vehicle, and providing quantified expected functional safety verification indicators using expected functional safety acceptance criteria, thereby enhancing the practicality and observability of the expected functional safety verification and improving vehicle driving safety.

[0032] As an optional implementation scheme in this application, in order to ensure the comprehensive and effective verification of the expected functional safety of the vehicle, this application can provide a detailed explanation of the specific construction process of the simulation test scenario library, as well as the in-loop testing process and safety verification process for the expected functional safety of the vehicle.

[0033] Figure 2 A flowchart of another method for verifying the expected functional safety of a vehicle provided in this application embodiment is shown below. Figure 2 As shown, the method may specifically include the following steps: S210 generates a corresponding standardized simulation map file based on road elements in existing map data.

[0034] In this application, full high-precision map data is collected from the backend databases of various existing map software as the existing map data. This existing map data may include multiple road elements that make up the base map roads. Each road element describes various road-related descriptive information such as the road itself, functional facilities, lanes, roadbed, pavement, bridges, tunnels, protective facilities, traffic signs, and markings.

[0035] Considering that existing map data typically uses conventional map description formats, which are not suitable for subsequent simulation test scenarios during autonomous driving, this application, after acquiring existing map data, will parse the existing map data to extract each road element. Then, using a standardized data format applicable to simulation test scenarios during autonomous driving (such as the OpenDRIVE standard format), each road element will be mapped one-to-one under the standardized data format, thereby generating corresponding standardized simulation map files.

[0036] S220 generates corresponding standardized simulation scenario files based on the probability distribution of each scenario element in the multi-scenario driving data and the operational design domain of the vehicle's expected functional safety.

[0037] In this application, a large amount of real driving data of vehicles under various driving environments can be collected, and the collected raw driving data can be analyzed in accordance with the corresponding road condition scenario analysis and vehicle status analysis to convert it into a database-analyzable format, thereby merging the multi-scenario driving data in this application.

[0038] For example, multi-scenario driving data can be N real driving data points obtained by a driver driving a vehicle on a real road, after road condition scenario analysis, vehicle state analysis, and data format conversion. Multi-scenario driving data X = {X1, X2, ..., X...} n , ..., X N}, and X n={s n1 s n2 , ..., s nm , ..., s nM}. Among them, X n s represents the vehicle's actual driving data in the nth real-world driving scenario. nm Represents the nth real-world driving scenario X n The information of the m-th scene element, where M represents the number of scene elements.

[0039] After obtaining multi-scenario driving data, the data is analyzed to determine the specific values ​​of each scenario element in each real-world driving scenario, thereby establishing the probability distribution of each scenario element. The probability distribution of each scenario element describes the probability of each scenario element for each value.

[0040] Considering that for the expected functional safety of a vehicle, the corresponding controllable range is usually pre-designed for various expected functional safety features, the Operational Design Domain (ODD) of the expected functional safety of the vehicle in this application is used to represent the expected operating range of the autonomous vehicle, including factors such as traffic conditions, road type, and weather.

[0041] Therefore, after obtaining the probability distribution of each scenario element, this application can, according to the probability distribution of each scenario element, adopt a standardized data format (such as the OpenSCENARIO standard format) applicable to the simulation test scenario of vehicle autonomous driving within the operational design domain of the vehicle's expected functional safety, and assign appropriate values ​​to each scenario element, thereby generating standardized files under multiple simulation test scenarios, which serve as the standardized simulation scenario files in this application.

[0042] In some embodiments, in order to ensure the accurate generation of standardized simulation scenario files, this application can determine the probability distribution of each scenario element based on the distribution characteristics of scenario elements in multi-scenario driving data; based on the probability distribution of each scenario element and the operational design domain of the vehicle's expected functional safety, the scenario element is generalized to generate the corresponding standardized simulation scenario file.

[0043] In other words, for multi-scenario driving data, the process involves parsing the data to extract various scene elements from each real-world driving scenario, and then extracting the distribution features of each scene element to determine its specific value within that real-world driving scenario. By summarizing all scene elements across all real-world driving scenarios and analyzing the frequency of each scene element's multiple specific values ​​across various real-world driving scenarios, the probability distribution of each scene element is determined.

[0044] For example, the probability distribution of each scene element can be P m (X=x) mi =P mi , where x mi P represents the i-th value of the m-th scene element. mi This represents the probability that the m-th scene element takes the i-th value.

[0045] Then, this application can generalize the values ​​of each scene element according to the probability distribution of each value, using a standardized data format (such as the OpenSCENARIO standard format) applicable to simulation test scenarios during vehicle autonomous driving. Furthermore, it optimizes the generalized values ​​of each scene element by determining whether they exceed the expected operational range represented by the vehicle's expected functional safety operating design domain. That is, when the generalized value of a scene element exceeds the expected operational range represented by the vehicle's expected functional safety operating design domain, the scene element is re-generalized using a standardized data format (such as the OpenSCENARIO standard format) applicable to simulation test scenarios during vehicle autonomous driving. Furthermore, by combining different values ​​of each scene element under different scenarios, multiple standardized simulation scene files can be generated.

[0046] S230 constructs a simulation test scenario library corresponding to the expected functional safety of vehicles based on standardized simulation map files and standardized simulation scenario files.

[0047] After obtaining standardized simulation map files and standardized simulation scenario files, this application can comprehensively analyze each road element in the standardized simulation map file and each scenario element in each standardized simulation scenario file to merge multiple related road elements and scenario elements at the same location. Combined with the actual driving conditions corresponding to the relevant scenario elements, corresponding simulation test scenarios are constructed to build corresponding simulation test scenarios for the expected functional safety of the vehicle. Therefore, by performing the above process on multiple standardized simulation scenario files, multiple simulation test scenarios can be obtained, thus forming the simulation test scenario library in this application.

[0048] S240 inputs the simulation test scenario library into the hardware-in-the-loop (HIL) test bench, which integrates multiple vehicle-in-the-loop controllers.

[0049] To achieve accurate in-the-loop testing of vehicle expected functional safety across multiple simulation scenarios, this application constructs a Hardware-in-the-Loop (HIL) test bench. Furthermore, considering that vehicles typically employ multiple functional hardware controllers to comprehensively control the vehicle and execute corresponding autonomous driving operations, this application analyzes the various upstream and downstream hardware controllers configured in the vehicle and configures multiple in-the-loop controllers within the HIL test bench to ensure accurate verification of vehicle expected functional safety. This makes the simulated hardware environment during vehicle expected functional safety verification more closely resemble the hardware environment of a real vehicle, thereby improving the accuracy of vehicle expected functional safety verification.

[0050] It should be noted that the multiple in-the-loop controllers integrated in the HIL test bench may include, but are not limited to, automatic driving controllers, power controllers, steering controllers, and braking controllers.

[0051] Therefore, after obtaining the simulation test scenario library corresponding to the expected functional safety of the vehicle, the simulation test scenario library can be directly input into the HIL test bench so that the expected functional safety of the vehicle can be simulated and tested in each simulation test scenario through the HIL test bench.

[0052] The S250 constructs each simulation test scenario in the simulation test scenario library through the HIL test bench and outputs vehicle control data under each simulation test scenario.

[0053] The simulation software in the HIL test bench is used to present each simulation test scenario in the simulation test scenario library. Moreover, by comprehensively analyzing each scenario element and driving state in each simulation test scenario, the vehicle control data under each simulation test scenario is determined and output to each in-loop controller, so that subsequent simulation tests of various expected vehicle functional safety during autonomous driving can be carried out through multiple in-loop controllers.

[0054] S260, based on vehicle control data in each simulation test scenario, uses multiple in-loop controllers to perform in-loop testing on the expected functional safety of the vehicle within that simulation test scenario, resulting in a corresponding accident scenario library and a non-accident scenario library.

[0055] After obtaining the vehicle control data for each simulation test scenario, this application can construct a vehicle model. Then, by traversing each simulation test scenario, multiple in-loop controllers are used to control the vehicle model to perform corresponding simulated driving in that simulation test scenario based on the vehicle control data for that simulation test scenario, and the system records whether the vehicle model experiences a driving malfunction in each simulation test scenario, thereby completing the in-loop test of the vehicle's expected functional safety in each simulation test scenario.

[0056] Furthermore, after completing in-loop testing in all simulation test scenarios in the simulation test scenario library, this application analyzes whether the vehicle model experiences a driving malfunction in each simulation test scenario. This allows for the aggregation of the corresponding simulation test scenarios in the simulation test scenario library where the vehicle experiences a driving malfunction, forming the accident scenario library of this application. Moreover, by aggregating other simulation test scenarios in the simulation test scenario library where the vehicle does not experience a driving malfunction, this forms the non-accident scenario library of this application.

[0057] In some embodiments, to ensure accurate verification of the vehicle's intended functional safety, such as Figure 3 As shown, this application integrates multiple in-the-loop controllers, a host computer, and a real-time machine in the HIL test bench. The host computer can deploy vehicle autonomous driving simulation software, such as a Virtual Test Drive (VTD) simulation tool, to provide various simulation test scenarios from a simulation test scenario library. Each simulation test scenario approximates the actual test conditions of the vehicle. The real-time machine deploys vehicle modeling software, such as the CarSim tool, to build corresponding vehicle models, such as vehicle dynamics models and whole-vehicle parameter models.

[0058] Therefore, for the in-loop testing of the expected functional safety of the vehicle in various simulation test scenarios, based on the vehicle control data in each simulation test scenario, multiple in-loop controllers generate vehicle control commands for each simulation test scenario; based on the vehicle control commands in each simulation test scenario, the overall vehicle driving state of the vehicle model in that simulation test scenario is determined to complete the in-loop testing of the expected functional safety of the vehicle; and based on the overall vehicle driving state of the vehicle model in each simulation test scenario, the corresponding accident scenario library and non-accident scenario library are determined.

[0059] Specifically, such as Figure 3 As shown, after running the vehicle autonomous driving simulation software deployed on the host computer, various simulation test scenarios in the simulation test scenario library can be continuously provided in the human-machine interface of the host computer. The sensor information obtained after simulation of each sensor model in the simulation test scenario is used to output the vehicle control data under each simulation test scenario.

[0060] At this point, the host computer can output vehicle control data for each simulation test scenario to the autonomous driving controller within the in-loop controller. Then, through autonomous driving control, corresponding autonomous driving algorithms are used to analyze the aforementioned vehicle control data to simulate the specific driving state in each simulation test scenario, thereby generating vehicle control commands for that simulation test scenario. These vehicle control commands may include acceleration / deceleration commands, steering commands, and braking commands, etc. For example, such as... Figure 3 As shown, the automatic driving controller can send acceleration / deceleration commands, steering commands, and braking commands to the power controller, steering controller, and braking controller respectively via the Controller Area Network (CAN) bus.

[0061] Then, in response to the vehicle control commands in each simulation test scenario, the vehicle model can be controlled to perform the corresponding control response actions, thereby determining the overall vehicle driving state of the vehicle model in the simulation test scenario, and thus completing the in-loop test of the vehicle's expected functional safety.

[0062] For example, such as Figure 3 As shown, the power controller, steering controller, and braking controller can synchronously send acceleration / deceleration commands, steering commands, and braking commands to the real-time machine, respectively. This allows the real-time machine to run the CarSim tool to control the vehicle dynamics model and the vehicle parameter model to make corresponding control responses, thereby obtaining the vehicle's driving state after the responses of the vehicle dynamics model and the vehicle parameter model.

[0063] Then, this application controls the vehicle model to perform corresponding simulated driving in each simulation test scenario by performing driving analysis on the overall vehicle driving state of the vehicle model in each simulation test scenario, and records whether the vehicle model experiences a driving failure in each simulation test scenario, thereby completing the in-loop test of the vehicle's expected functional safety in each simulation test scenario. In this way, the corresponding simulation test scenarios in the simulation test scenario library where the vehicle experiences a driving failure are summarized as the accident scenario library in this application, and other simulation test scenarios in the simulation test scenario library where the vehicle does not experience a driving failure are summarized as the non-accident scenario library in this application.

[0064] For example, such as Figure 3 As shown, after the real-time machine obtains the vehicle driving state after the vehicle dynamics model and the vehicle parameter model response by running the CarSim tool, it can output the vehicle driving state in each simulation test scenario to the simulation tool deployed on the host computer to control the vehicle model to perform corresponding simulation driving in each simulation test scenario.

[0065] S270. Determine the corresponding average accident occurrence mileage based on the number of scenarios in the accident scenario database and the sum of the scenario mileage in the accident scenario database and the non-accident scenario database.

[0066] Understandably, to enhance the practicality and observability of vehicle expected functional safety verification, this application can pre-establish expected functional safety acceptance criteria for autonomous driving functions. These criteria provide quantifiable expected functional safety verification indicators and the conditional requirements that these indicators must meet to confirm expected functional safety. In this application, the expected functional safety verification indicator can be the average accident mileage.

[0067] Therefore, after obtaining the accident scenario library and the non-accident scenario library, this application can determine the number of simulation test scenarios in the accident scenario library, which is then used as the number of scenarios in the accident scenario library. Furthermore, by analyzing the specific vehicle driving distance for each simulation test scenario in both the accident scenario library and the non-accident scenario library, the total mileage of the corresponding scenarios can be determined.

[0068] Then, by calculating the ratio between the sum of the above scenario mileages and the number of scenarios in the accident scenario library, the specific value of the corresponding average accident occurrence mileage is determined. This average accident occurrence mileage can describe how many miles an accident will occur on average when the vehicle is driving autonomously.

[0069] For example, suppose the number of scenarios in the simulation test scenario library is Z, and the number of scenarios in the accident scenario library is K. Then, the average accident mileage can be... .

[0070] S280 determines the verification results of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria and average accident mileage.

[0071] Understandably, to ensure the intended functional safety of a vehicle, it is generally desirable to minimize the probability of accidents during autonomous driving. Therefore, this application can establish an intended functional safety acceptance criterion for average accident mileage, which requires that the average accident mileage be greater than or equal to a preset mileage threshold. This preset mileage threshold can be... . This indicates the pre-defined confidence level related to autonomous driving. This represents the pre-set probability threshold for an accident to occur when the vehicle is operating autonomously.

[0072] Therefore, after calculating the specific value of the above-mentioned average accident mileage under this loop test, this application can determine whether the specific value of the above-mentioned average accident mileage meets the specific conditions set in the expected functional safety acceptance criteria, thereby determining whether the above-mentioned average accident mileage meets the expected functional safety acceptance criteria, and thus determining whether the vehicle's expected functional safety has passed the verification, thereby determining the verification result of the vehicle's expected functional safety, and thus achieving a comprehensive and effective verification of the vehicle's expected functional safety.

[0073] In some embodiments, whether the specific value of the above-mentioned average accident mileage meets the expected functional safety acceptance criteria may fall into two categories. This application can obtain verification results of the vehicle's expected functional safety in the following two categories respectively.

[0074] Scenario 1: If the average accident mileage meets the expected functional safety acceptance criteria, then the vehicle's expected functional safety is deemed to have passed the verification.

[0075] If the average accident mileage meets the expected functional safety acceptance criteria, the expected functional safety of the vehicle can be confirmed. In this case, the expected functional safety of the vehicle is directly verified, thus ending the on-loop testing of the expected functional safety of the vehicle in each simulation test scenario.

[0076] Scenario 2: If the average accident mileage does not meet the expected functional safety acceptance criteria, then the expected functional safety of the vehicle is determined to have failed verification, and the expected functional safety of the vehicle is optimized or the operational design domain of the expected functional safety of the vehicle is modified.

[0077] If the average accident mileage does not meet the expected functional safety acceptance criteria, the expected functional safety of the vehicle cannot be confirmed, and thus the expected functional safety of the vehicle has failed verification. In this case, to ensure the safety of autonomous driving, this application can further optimize the expected functional safety of the vehicle, or modify the ODD range represented by the operational design domain of the expected functional safety of the vehicle, to support successful testing of the expected functional safety of the vehicle in various simulation test scenarios.

[0078] The technical solution provided in this application first constructs a simulation test scenario library corresponding to the expected functional safety of a vehicle based on existing map data and multi-scenario driving data, ensuring the richness and high realism of the simulation test scenario library. Then, within each simulation test scenario in the simulation test scenario library, in-loop testing of the expected functional safety of the vehicle is performed to obtain corresponding accident scenario libraries and non-accident scenario libraries. These are then combined with preset expected functional safety acceptance criteria to determine the verification results of the expected functional safety of the vehicle. This allows for comprehensive and effective verification of the expected functional safety of the vehicle using a rich and highly realistic simulation test scenario library, significantly shortening the verification cycle and reducing costs, ensuring sufficient and accurate verification of the expected functional safety of the vehicle, and providing quantified expected functional safety verification indicators using expected functional safety acceptance criteria, thereby enhancing the practicality and observability of the expected functional safety verification and improving vehicle driving safety.

[0079] Figure 4 This is a schematic block diagram of a vehicle expected functional safety verification device provided in an embodiment of this application. Figure 4 As shown, the device 400 may include: The scenario library construction module 410 is used to construct a simulation test scenario library corresponding to the expected functional safety of the vehicle based on existing map data and multi-scenario driving data. The loop testing module 420 is used to perform loop testing on the expected functional safety of the vehicle in each simulation test scenario in the simulation test scenario library to obtain the corresponding accident scenario library and non-accident scenario library. The expected functional safety verification module 430 is used to determine the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library.

[0080] In some implementations, the scene library building module 410 may include: The map file generation unit is used to generate corresponding standardized simulation map files based on road elements in existing map data. The scenario file generation unit is used to generate a corresponding standardized simulation scenario file based on the probability distribution of each scenario element in the multi-scenario driving data and the expected functional safety operation design domain of the vehicle. The scenario construction unit is used to construct a simulation test scenario library corresponding to the expected functional safety of the vehicle based on the standardized simulation map file and the standardized simulation scenario file.

[0081] In some implementations, the scene file generation unit can be specifically used for: Based on the distribution characteristics of scene elements in multi-scenario driving data, determine the probability distribution of each scene element; Based on the probability distribution of each scenario element and the operational design domain of the vehicle's expected functional safety, the scenario elements are generalized to generate corresponding standardized simulation scenario files.

[0082] In some implementations, the loop test module 420 may include: The scenario library input unit is used to input the simulation test scenario library into the hardware-in-the-loop (HIL) test bench, which integrates multiple in-the-loop controllers of the vehicle. The vehicle control analysis unit is used to construct each simulation test scenario in the simulation test scenario library through the HIL test bench and output vehicle control data under each simulation test scenario. The in-loop testing unit is used to perform in-loop testing on the expected functional safety of the vehicle within each simulation test scenario using multiple in-loop controllers based on the vehicle handling data in that simulation test scenario, thereby obtaining the corresponding accident scenario library and non-accident scenario library.

[0083] In some implementations, the loop test unit can be specifically used for: Based on the vehicle control data in each simulation test scenario, vehicle control commands for each simulation test scenario are generated through multiple in-loop controllers. Based on the vehicle control commands in each simulation test scenario, the overall vehicle driving state of the vehicle model in that simulation test scenario is determined in order to complete the in-loop test of the expected functional safety of the vehicle. Based on the vehicle model's overall driving state in each simulation test scenario, the corresponding accident scenario library and non-accident scenario library are determined.

[0084] In some possible implementations, the functional safety verification module 430 is expected to include: The average mileage determination unit is used to determine the corresponding average accident occurrence mileage based on the number of scenarios in the accident scenario database and the sum of the scenario mileage in the accident scenario database and the non-accident scenario database. The expected functional safety verification unit is used to determine the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria and the average accident mileage.

[0085] In some possible implementations, the functional safety verification unit is expected to be specifically used for: If the average accident mileage meets the expected functional safety acceptance criteria, then the expected functional safety of the vehicle is determined to have passed the verification. If the average accident mileage does not meet the expected functional safety acceptance criteria, then the expected functional safety of the vehicle is determined to have failed verification, and the expected functional safety of the vehicle is optimized or the operational design domain of the expected functional safety of the vehicle is modified.

[0086] In this embodiment, a simulation test scenario library corresponding to the expected functional safety of the vehicle is first constructed based on existing map data and multi-scenario driving data, ensuring the richness and high realism of the simulation test scenario library. Then, in-loop testing of the vehicle's expected functional safety is performed within each simulation test scenario in the library, resulting in corresponding accident scenario libraries and non-accident scenario libraries. These, combined with preset expected functional safety acceptance criteria, determine the verification results of the vehicle's expected functional safety. This utilizes a rich and highly realistic simulation test scenario library to achieve comprehensive and effective verification of the vehicle's expected functional safety, significantly shortening the verification cycle and reducing costs, ensuring sufficient and accurate verification of the vehicle's expected functional safety, and providing quantified expected functional safety verification indicators using the expected functional safety acceptance criteria, enhancing the practicality and observability of the vehicle's expected functional safety verification and improving vehicle driving safety.

[0087] It should be understood that the device embodiments and method embodiments can correspond to each other, and similar descriptions can be referred to the method embodiments. To avoid repetition, further details will not be provided here. Specifically, Figure 4 The apparatus 400 shown can execute any of the method embodiments provided in this application, and the foregoing and other operations and / or functions of each module in the apparatus 400 are respectively for implementing the corresponding processes in the various methods of the embodiments of this application. For the sake of brevity, they will not be described in detail here.

[0088] The apparatus 400 of this application embodiment has been described above from the perspective of functional modules in conjunction with the accompanying drawings. It should be understood that this functional module can be implemented in hardware, in software instructions, or in a combination of hardware and software modules. Specifically, the steps of the method embodiments in this application can be completed by integrated logic circuits in the processor's hardware and / or by software instructions. The steps of the method disclosed in this application embodiment can be directly embodied as being executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. Optionally, the software module can be located in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps in the above method embodiments.

[0089] Figure 5 A schematic block diagram of an electronic device provided in an embodiment of this application.

[0090] like Figure 5 As shown, the electronic device 500 may include: The system includes a memory 510 and a processor 520. The memory 510 stores computer programs and transfers the program code to the processor 520. In other words, the processor 520 can retrieve and run the computer program from the memory 510 to implement the methods described in the embodiments of this application.

[0091] For example, the processor 520 can be used to execute the above-described method embodiments according to instructions in the computer program.

[0092] In some embodiments of this application, the processor 520 may include, but is not limited to: General-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.

[0093] In some embodiments of this application, the memory 510 includes, but is not limited to: Volatile memory and / or non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static RAM (SRAM), Dynamic RAM (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced SDRAM (ESDRAM), Synchronous Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0094] In some embodiments of this application, the computer program may be divided into one or more modules, which are stored in the memory 510 and executed by the processor 520 to perform the method provided in this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the electronic device.

[0095] like Figure 5 As shown, the electronic device may also include: Transceiver 530, which can be connected to processor 520 or memory 510.

[0096] The processor 520 can control the transceiver 530 to communicate with other devices; specifically, it can send information or data to other devices or receive information or data sent by other devices. The transceiver 530 may include a transmitter and a receiver. The transceiver 530 may further include antennas, and the number of antennas may be one or more.

[0097] It should be understood that the various components in the electronic device are connected through a bus system, which includes a data bus, a power bus, a control bus, and a status signal bus.

[0098] This application also provides a computer storage medium storing a computer program thereon, which, when executed by a computer, enables the computer to perform the methods of the above-described method embodiments. Alternatively, this application also provides a computer program product containing instructions that, when executed by a computer, cause the computer to perform the methods of the above-described method embodiments.

[0099] When implemented using software, it can be implemented entirely or partially as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., digital video disc (DVD)), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0100] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0102] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. For example, the functional modules in the various embodiments of this application may be integrated into one processing module, or each module may exist physically separately, or two or more modules may be integrated into one module.

[0103] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for verifying the intended functional safety of a vehicle, characterized in that, include: Based on existing map data and multi-scenario driving data, a simulation test scenario library corresponding to the expected functional safety of vehicles is constructed. In each simulation test scenario in the simulation test scenario library, the expected functional safety of the vehicle is tested in the loop to obtain the corresponding accident scenario library and non-accident scenario library; The verification results of the vehicle's expected functional safety are determined based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library.

2. The method according to claim 1, characterized in that, The step of constructing a simulation test scenario library corresponding to the expected functional safety of vehicles based on existing map data and multi-scenario driving data includes: Generate corresponding standardized simulation map files based on road elements in existing map data; Based on the probability distribution of each scenario element in the multi-scenario driving data and the operational design domain of the vehicle's expected functional safety, a corresponding standardized simulation scenario file is generated. Based on the standardized simulation map file and the standardized simulation scenario file, a simulation test scenario library corresponding to the expected functional safety of the vehicle is constructed.

3. The method according to claim 2, characterized in that, The step of generating a corresponding standardized simulation scenario file based on the probability distribution of each scenario element in the multi-scenario driving data and the operational design domain of the vehicle's expected functional safety includes: Based on the distribution characteristics of scene elements in multi-scenario driving data, determine the probability distribution of each scene element; Based on the probability distribution of each scenario element and the operational design domain of the vehicle's expected functional safety, the scenario elements are generalized to generate corresponding standardized simulation scenario files.

4. The method according to claim 1, characterized in that, Within each simulation test scenario in the simulation test scenario library, the expected functional safety of the vehicle is tested in a loop to obtain a corresponding accident scenario library and a non-accident scenario library, including: The simulation test scenario library is input into the hardware-in-the-loop (HIL) test bench, which integrates multiple in-the-loop controllers of the vehicle. Each simulation test scenario in the simulation test scenario library is constructed using the HIL test bench, and vehicle control data under each simulation test scenario is output. Based on the vehicle handling data in each simulation test scenario, the expected functional safety of the vehicle is tested in the simulation test scenario by multiple in-loop controllers, resulting in a corresponding accident scenario library and a non-accident scenario library.

5. The method according to claim 4, characterized in that, Based on vehicle handling data in each simulation test scenario, multiple in-loop controllers are used to perform in-loop testing on the expected functional safety of the vehicle within that simulation test scenario, resulting in a corresponding accident scenario library and a non-accident scenario library, including: Based on the vehicle control data in each simulation test scenario, vehicle control commands for each simulation test scenario are generated through multiple in-loop controllers. Based on the vehicle control commands in each simulation test scenario, the overall vehicle driving state of the vehicle model in that simulation test scenario is determined in order to complete the in-loop test of the expected functional safety of the vehicle. Based on the vehicle model's overall driving state in each simulation test scenario, the corresponding accident scenario library and non-accident scenario library are determined.

6. The method according to claim 1, characterized in that, The step of determining the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library includes: The average accident occurrence mileage is determined based on the number of scenarios in the accident scenario database and the total mileage of scenarios in the accident scenario database and the non-accident scenario database. The verification results of the vehicle's expected functional safety are determined based on the preset expected functional safety acceptance criteria and the average accident mileage.

7. The method according to claim 6, characterized in that, The step of determining the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria and the average accident mileage includes: If the average accident mileage meets the expected functional safety acceptance criteria, then the expected functional safety of the vehicle is determined to have passed the verification. If the average accident mileage does not meet the expected functional safety acceptance criteria, then the expected functional safety of the vehicle is determined to have failed verification, and the expected functional safety of the vehicle is optimized or the operational design domain of the expected functional safety of the vehicle is modified.

8. A verification device for the intended functional safety of a vehicle, characterized in that, include: The scenario library construction module is used to build a simulation test scenario library corresponding to the expected functional safety of vehicles based on existing map data and multi-scenario driving data; The in-loop testing module is used to perform in-loop testing on the expected functional safety of the vehicle in each simulation test scenario in the simulation test scenario library, so as to obtain the corresponding accident scenario library and non-accident scenario library. The expected functional safety verification module is used to determine the verification result of the vehicle's expected functional safety based on the preset expected functional safety acceptance criteria, the accident scenario library, and the non-accident scenario library.

9. An electronic device, characterized in that, include: A processor and a memory, the memory for storing a computer program, the processor for calling and running the computer program stored in the memory to perform the verification method for the intended functional safety of the vehicle as claimed in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program that causes a computer to perform a verification method for the intended functional safety of a vehicle as described in any one of claims 1-7.

Images