Fault simulation test method and device of vehicle and electronic equipment
The behavior tree technology generates fault injection configuration information, and realizes dynamic triggering and precise control of multiple types of faults in vehicle simulation tests, solving the problem of insufficient testing flexibility and refined simulation in the existing technology, and improving the flexibility and accuracy of testing.
Patent Information
- Application Number
- CN202510846765.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-06-24
- Publication Date
- 2025-07-22
- Estimated Expiration
- 2045-06-24
AI Technical Summary
The prior art lacks dynamic triggering and flexible control capabilities in vehicle simulation testing, making it difficult to cope with complex and changeable test needs, and the degree of refinement of communication and perceived fault simulations leads to a deviation between the test results and the real fault performance.
The behavior tree technology is used to generate fault injection configuration information, and the fault injection behavior is controlled by combining nodes and action nodes, supporting the coordinated injection of multiple types of faults, including communication failures and sensor failures. The parameterized configuration is used to achieve diversified fault effects, and the trigger conditions are associated with the simulation running time and vehicle status to achieve accurate timing control and condition determination.
It improves the flexible control ability of the simulation test process, reduces the professional requirements for testers, significantly improves the flexibility of fault injection and the accuracy of test evaluation, and reduces the deviation between test results and real fault performance.
Smart Images

Figure CN120354634A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the technical field of vehicles, especially the technical field of vehicle simulation testing, and specifically relates to a method, device, and electronic device for fault simulation testing of vehicles. Background Art
[0002] With the rapid development of intelligent driving technology, virtual twin vehicle simulation testing has become a key means to verify the reliability and safety of vehicle systems. In this process, fault injection technology can simulate abnormal situations that a vehicle may encounter in a real environment, thereby evaluating the system's response ability under fault conditions. However, the application of existing technologies in this field still has significant limitations, restricting the comprehensiveness and efficiency of testing. Summary of the Invention
[0003] This application provides a method, device, and electronic device for fault simulation testing of vehicles to improve the flexible control ability during the simulation testing process and help meet complex and changing testing requirements.
[0004] According to the first aspect provided by this application, a method for fault simulation testing of vehicles is provided. The method includes: Generating a behavior tree based on fault injection configuration information; the behavior tree is used to guide the fault injection behavior for the vehicle under test during the simulation testing process; the behavior tree includes composite nodes and action nodes; the composite nodes are used to control the execution logic of the action nodes; the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior; In response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, adding the fault information corresponding to the target fault injection behavior to the simulation testing scenario of the vehicle under test and testing the vehicle under test to obtain a test result.
[0005] By adopting the solution of the embodiment of this application, a behavior tree for guiding the fault injection behavior for the vehicle under test during the simulation testing process can be generated according to the fault injection configuration information written by the user. Among them, the composite nodes are used to control the execution logic of the action nodes, the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior. Guiding the fault injection during the simulation testing process through the behavior tree can achieve precise timing control and condition determination, improve the flexible control ability during the simulation testing process, and help meet complex and changing testing requirements.
[0006] In addition, different from scripts or test cases, the fault injection configuration information does not require professional testers to write, reducing the requirements for testers.
[0007] In a possible way, in response to determining that the vehicle under test meets the triggering conditions for the target fault injection behavior, fault information corresponding to the target fault injection behavior is added to the simulation test scenario of the vehicle under test, including: Sequentially execute each composite node included in the behavior tree; during the execution of any composite node, detect whether the vehicle under test meets the triggering conditions represented by the triggering condition nodes associated with the action nodes under the composite node; if so, execute the fault injection behavior represented by the action node.
[0008] By adopting the solution of the embodiment of the present application, during the simulation test of the vehicle under test, the fault injection behavior for the vehicle under test is guided by the behavior tree. According to the structure of the behavior tree, each composite node is sequentially executed. During the execution of the composite node, when it is detected that the triggering conditions represented by the triggering condition nodes associated with the action nodes under the composite node are met, the fault injection behavior represented by the action node is executed. Through the planning of the behavior tree, fault simulation can be more flexibly performed according to the user's needs, and the authenticity and controllability of the simulation process can be ensured.
[0009] In a possible way, the fault injection behavior includes: a first fault injection behavior and a second fault injection behavior; the first fault injection behavior represents the injection behavior for communication faults, and the second fault injection behavior represents the injection behavior for sensor faults.
[0010] By adopting the solution of the embodiment of the present application, it supports the collaborative injection of multiple types of faults, covering the injection behavior for communication faults and the injection behavior for sensor faults, and has high flexibility.
[0011] In a possible way, in response to determining that the vehicle under test meets the triggering conditions for the target fault injection behavior, fault information corresponding to the target fault injection behavior is added to the simulation test scenario of the vehicle under test, including: In response to determining that the vehicle under test meets the triggering conditions for the first fault injection behavior, communication fault parameters are added to the target data transmission channel of the simulation test scenario of the vehicle under test.
[0012] By adopting the solution of the embodiment of the present application, according to the event determination during the operation of the simulation scenario, corresponding fault injection actions are performed on the key data channels to effectively simulate the vehicle's response in the case of data faults and meet the requirements of diverse simulation technologies.
[0013] In a possible way, the communication fault parameters include at least one of: a data delay parameter, a data freeze parameter, and a data loss parameter.
[0014] Adopting the solution of the embodiment of the present application, during the operation of the simulation scenario, corresponding fault injection actions are performed on the key data channels according to event determination, so as to effectively simulate the response of the vehicle in the case of data faults and meet the requirements of diverse simulation technologies.
[0015] Compared with the fault injection that only supports a single mode in the related art, it can significantly improve the flexibility of fault injection. At the same time, the injection of diverse fault parameters can reduce the deviation between the test results and the real fault performance, and improve the accuracy of test evaluation.
[0016] In a possible way, in response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, fault information corresponding to the target fault injection behavior is added to the simulation test scenario of the vehicle under test, including: In response to determining that the vehicle under test meets the trigger condition of the second fault injection behavior, sensor fault parameters are added to the sensors of the vehicle under test.
[0017] In a possible way, the sensor fault parameters include: camera fault parameters and radar fault parameters; The camera fault parameters include noise parameters and / or lens distortion parameters; The radar fault parameters include at least one of a perspective failure parameter, a detection distance degradation parameter, a laser failure parameter, a performance degradation parameter, a loss ratio parameter, and a noise parameter.
[0018] For the communication faults and sensor faults, the solution of the embodiment of the present application can achieve diverse fault effects through parametric configuration. Compared with the method of using a preset static model to simulate faults in the related art, it can cover more camera fault situations and lidar fault situations, covering various fault situations such as lidar perspective failure, detection distance degradation, laser failure, performance degradation, and increasing loss ratio, better simulating the real faults that occur in the real scenario, reducing the deviation between the test results and the real fault performance, and improving the accuracy of evaluation.
[0019] In a possible way, the trigger conditions include: The simulation running time reaches the corresponding time trigger value and / or the running state of the vehicle under test reaches the corresponding running state trigger value; the running state includes any one of running speed, running acceleration, and driving distance.
[0020] In the solution of the embodiment of the present application, the trigger condition is associated with the simulation running time and the running state of the vehicle to be tested, so as to realize dynamic trigger of fault injection and highly precise control of fault injection. Moreover, a behavior tree is adopted to ensure precise timing control and condition determination, thereby supporting flexible setting of when to start fault injection, when to end fault injection, where to inject, and what type of fault to inject. Compared with the method in the related art that cannot dynamically trigger fault injection, it can better meet the complex and changeable test requirements and improve the test coverage.
[0021] According to the second aspect provided by the present application, a fault simulation test device for a vehicle is provided. The device includes: A generation module, configured to generate a behavior tree based on fault injection configuration information; the behavior tree is used to guide the fault injection behavior for the vehicle to be tested during the simulation test process; the behavior tree includes combination nodes and action nodes; the combination nodes are used to control the execution logic of the action nodes; the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior; A fault injection module, configured to, in response to determining that the vehicle to be tested meets the trigger condition of the target fault injection behavior, add the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle to be tested, and test the vehicle to be tested to obtain a test result.
[0022] In a possible way, the fault injection module is specifically configured to: sequentially execute each combination node included in the behavior tree; during the execution of any combination node, detect whether the vehicle to be tested meets the trigger condition represented by the trigger condition node associated with the action node under the combination node; if so, execute the fault injection behavior represented by the action node.
[0023] In a possible way, the fault injection behavior includes: a first fault injection behavior and a second fault injection behavior; the first fault injection behavior represents the injection behavior for communication faults, and the second fault injection behavior represents the injection behavior for sensor faults.
[0024] In a possible way, the fault injection module is specifically configured to: In response to determining that the vehicle to be tested meets the trigger condition of the first fault injection behavior, add communication fault parameters to the target data transmission channel of the simulation test scenario of the vehicle to be tested.
[0025] In a possible way, the communication fault parameters include at least one of a data delay parameter, a data freeze parameter, and a data loss parameter.
[0026] In a possible way, the fault injection module is specifically configured to: In response to determining that the vehicle under test meets the trigger condition for the second fault injection behavior, sensor fault parameters are added to the sensors of the vehicle under test.
[0027] In one possible way, the sensor fault parameters include: camera fault parameters and radar fault parameters; The camera fault parameters include noise parameters and / or lens distortion parameters; The radar fault parameters include at least one of a perspective failure parameter, a detection distance degradation parameter, a laser failure parameter, a performance degradation parameter, a loss ratio parameter, and a noise parameter.
[0028] In one possible way, the trigger conditions include: The simulation running time reaches the corresponding time trigger value and / or the running state of the vehicle under test reaches the corresponding running state trigger value; the running state includes any one of running speed, running acceleration, and driving distance.
[0029] According to a third aspect provided by the present application, an electronic device is provided, including: a processor; a memory for storing processor-executable instructions; wherein, the processor is configured to execute the instructions to implement the method according to the first aspect and any possible implementation manner thereof.
[0030] According to a fourth aspect provided by the present application, a computer-readable storage medium is provided. When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device can execute the method according to the first aspect and any possible implementation manner thereof.
[0031] According to a fifth aspect provided by the present application, a computer program product is provided. The computer program product includes computer instructions. When the computer instructions run on the electronic device, the electronic device executes the method according to the first aspect and any possible implementation manner thereof.
[0032] It should be noted that the technical effects brought by any implementation manner in the second aspect to the fifth aspect can be referred to the technical effects brought by the corresponding implementation manner in the first aspect, and will not be elaborated here.
[0033] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. Description of the Drawings
[0034] The drawings here are incorporated into the specification and constitute a part of this specification, showing the embodiments consistent with the present application, and are used together with the specification to explain the principles of the present application, and do not constitute an improper limitation to the present application.
[0035] Figure 1It is a schematic flow chart of a fault simulation test method for a vehicle shown according to an exemplary embodiment; Figure 2 It is a schematic diagram of the configuration of a simulation test environment in a fault simulation test for a vehicle shown according to an exemplary embodiment; Figure 3 It is a schematic diagram of a fault simulation test platform for a vehicle shown according to an exemplary embodiment; Figure 4 It is a schematic diagram of fault injection in a fault simulation test for a vehicle shown according to an exemplary embodiment; Figure 5 It is a schematic flow chart of another fault simulation test method for a vehicle shown according to an exemplary embodiment; Figure 6 It is a block diagram of a fault simulation test device for a vehicle shown according to an exemplary embodiment; Figure 7 It is a block diagram of an electronic device shown according to an exemplary embodiment. Detailed implementation manners
[0036] In order to enable those of ordinary skill in the art to better understand the technical solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
[0037] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily need to describe a specific order or sequence. It should be understood that such used data can be interchanged under appropriate circumstances so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.
[0038] In the embodiments of the present application, words such as "exemplary", "for example" or "such as" are used to indicate examples, illustrations or explanations. Any embodiment or design solution described as "exemplary", "for example" or "such as" in the embodiments of the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Exactly speaking, using words such as "exemplary", "for example" or "such as" aims to present relevant concepts in a specific manner.
[0039] Traditional fault injection methods mostly rely on predefined scripts or test cases, such as simulating fault behaviors based on a finite state machine model. Scripts and test cases need to be written by professional test engineers, which are difficult for non-professionals to understand and thus difficult to participate in the test process.
[0040] Although such simulation test methods can reproduce basic fault scenarios, they lack dynamic triggering and flexible control capabilities and are difficult to meet complex and changing test requirements. For example, in scenarios where multiple types of faults need to be injected simultaneously or faults need to be triggered according to real-time conditions (such as vehicle speed, acceleration), existing technologies often cannot achieve precise timing control or condition determination, resulting in limited test coverage.
[0041] In addition, existing systems have deficiencies in the refinement of communication and perception fault simulation. The simulation of communication faults (such as data delay, freeze, loss) usually only supports a single mode or fixed parameters and lacks dynamic adjustment of variables such as delay time and omission probability. The simulation of sensor faults (such as camera distortion) mostly uses preset static models and it is difficult to achieve diverse fault effects (such as gradual change in snowflake density, dynamic adjustment of laser failure ratio) through parametric configuration. This results in a deviation between the test results and the actual fault performance, affecting the accuracy of the evaluation.
[0042] At the system architecture level, traditional solutions often tightly couple the fault injection logic with the simulation engine, resulting in poor scalability and high maintenance costs. For example, although hardware-in-the-loop test systems can achieve high-precision fault injection, they rely on dedicated hardware devices and are difficult to quickly adapt to new fault scenarios or sensor types. Software simulation-based solutions mostly lack modular design, with fault management, behavior logic, and configuration parsing functions mixed together, making it difficult to support user customization requirements.
[0043] In summary, there is an urgent need in the current virtual vehicle simulation test field for a fault injection system that can support dynamic triggering, parametric configuration, multi-type fault collaborative injection, and has high flexibility and scalability.
[0044] In view of this, the present application provides a fault simulation test method, device, and electronic device for a vehicle to solve the above pain points and improve the authenticity and efficiency of virtual vehicle simulation tests.
[0045] Next, the technical solutions in the embodiments of the present application will be described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments.
[0046] Embodiments of the present application relate to a vehicle to be tested. Here, the vehicle can also be referred to as a means of transportation (vehicle), a mobile carrier, an electric vehicle (EV), a hybrid electric vehicle (HEV), a plug-in hybrid electric vehicle (PHEV), a fuel cell vehicle (FCV), an autonomous vehicle, an intelligent and connected vehicle (ICV), a driverless vehicle, etc.
[0047] In embodiments of the present application, the vehicle can be a sedan, a sport utility vehicle (SUV), a truck, an electric vehicle, a motorcycle, a tricycle, a special vehicle (such as an ambulance, a fire truck, a police car, etc.), a driverless taxi, an intelligent and connected bus, an autonomous logistics vehicle, an electric truck, etc. In addition, the method is also applicable to various special vehicles, such as agricultural vehicles, mining vehicles, forestry vehicles, airport vehicles, port vehicles, etc. The present application does not make specific restrictions on this.
[0048] For ease of understanding, the following specifically introduces the vehicle fault simulation test method provided by the present application in conjunction with the accompanying drawings. Refer to Figure 1 , the method may include the following steps: S101: Generate a behavior tree based on the fault injection configuration information; the behavior tree is used to guide the fault injection behavior for the vehicle to be tested during the simulation test; the behavior tree includes composite nodes and action nodes; the composite nodes are used to control the execution logic of the action nodes; the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior.
[0049] To improve the safety of advanced autonomous driving functions, faults can be artificially introduced during the simulation of autonomous driving scenarios to verify the robustness of the autonomous driving system in specific scenarios, and then verify whether the current development results meet the designed functional safety specifications.
[0050] The vehicle fault simulation test method provided by the embodiments of the present application can be applied to a virtual twin vehicle simulation test scenario, and specifically can be applied to a virtual twin vehicle simulation test platform.
[0051] Specifically, virtual twin technology emphasizes the real-time mapping and interaction between physical entities and virtual models. In automotive simulation testing, this technology collects real-time status data of the actual vehicle (such as position, speed, acceleration, etc.) through sensors and constructs corresponding digital twins in the virtual space. During the testing process, various complex scenarios (such as extreme weather, traffic congestion, etc.) can be simulated. The actual vehicle adjusts its driving behavior according to the feedback of the virtual scenario, and its actual performance will be updated to the digital twin in real time. This way of combining the virtual and the real not only ensures the authenticity of the testing but also improves the testing efficiency through the flexibility of the virtual scenario.
[0052] From a technical implementation perspective, the core of virtual twin automotive simulation testing lies in data synchronization and model verification. The actual vehicle, as the object under test, has its dynamic characteristics and control system existing in physical form, while the virtual model predicts and evaluates vehicle behavior through high-precision simulation algorithms. For example, in autonomous driving testing, the actual vehicle receives sensor signals generated in the virtual scenario (such as simulated obstacles, traffic signals, etc.) and makes decisions based on these signals. At this time, the digital twin not only records the actual response of the vehicle but also verifies the accuracy and robustness of the vehicle algorithm by comparing the prediction results of the virtual model.
[0053] In virtual twin automotive simulation testing, fault injection is a verification technology that introduces specific faults during system operation through controlled experiments to verify its reliability and fault tolerance. The purpose of fault injection is to accelerate system failure by artificially introducing faults and observe the system's behavioral responses after the faults occur, so as to evaluate the system's reliability, fault tolerance, and safety. This is particularly important for complex systems such as autonomous driving, as these systems need to operate stably under various abnormal conditions.
[0054] In the embodiments of this application, before the simulation testing, the user can configure relevant information about fault injection. For example, configure the trigger conditions for fault injection, the end conditions for fault injection, the types of fault injection, and specific fault parameters.
[0055] According to the information related to fault injection configured by the user, a behavior tree can be generated. A behavior tree is a decision tree used to represent the hierarchical structure of tasks and subtasks, organizing and controlling complex behavioral logic with a tree-like hierarchical structure. Its core idea is to decompose complex tasks into a series of simple subtasks and determine which subtask to execute and when to execute through specific rules. Thus, through hierarchical behavior nodes and condition nodes, it provides a clear and intuitive task execution logic.
[0056] In the embodiments of the present application, during the simulation test for a vehicle under test, a behavior tree is used to guide the fault injection behavior for the vehicle under test. Specifically, the behavior tree decomposes tasks into subtasks through a tree structure, supports logical operations such as conditional judgment, loop, and parallelism, and is suitable for describing the process of fault injection.
[0057] It can be understood that before executing each composite node in the behavior tree, it is necessary to build a simulation scenario. Specifically, the simulation test process may include: virtual vehicle configuration, simulation settings, and simulation operation.
[0058] See Figure 2 , the virtual vehicle configuration may include the configuration of the virtual domain controller, the configuration of the virtual network, and the configuration of the virtual sensors. Among them, the application is deployed in the virtual domain controller, and the application can represent the application programs carried by the virtual vehicle, such as an autonomous driving application program, etc. For the configuration of the simulation scenario, an OpenDrive map can be built based on the relevant simulation test platform, and environmental information can be created in the map, which can specifically include environmental vehicles (also known as NPC vehicles), traffic lights, pedestrians, etc. Subsequently, the simulation operation can be carried out. In the simulation operation stage, the virtual sensors sense the surrounding environment data of the virtual vehicle, such as road, traffic light, pedestrian, etc. information, and transfer the sensed data to the virtual domain controller. The virtual domain controller generates an execution command, and when the execution command is transferred to the virtual actuator, the virtual actuator controls the operation of the virtual vehicle according to the execution command, such as accelerating, decelerating, or steering, etc.
[0059] In some embodiments of the present application, during the simulation test, a behavior tree is used to guide the fault injection behavior for the vehicle under test. The behavior tree may include composite nodes and action nodes to achieve logical control of fault injection.
[0060] The core advantage of the behavior tree is that it decomposes complex behaviors into reusable subtasks through composite nodes. The composite nodes are responsible for controlling the execution logic of the action nodes, including serial, parallel, and selection.
[0061] According to the type, the composite nodes can be divided into sequence (sequence node), selector (selection node), and parallel (parallel node). Among them, the function of the sequence node is: execute the child nodes in sequence, return success when all child nodes are successful, and return failure immediately when any child node fails; the function of the selection node is: execute the child nodes in sequence, return success immediately when any child node is successful, and return failure when all child nodes fail; the function of the parallel node is: execute all child nodes simultaneously, and return success or failure according to the policy (for example, return success only when all child nodes are successful, or return failure when any child node fails).
[0062] In the embodiments of the present application, the action nodes included in the behavior tree can be regarded as the child nodes under the composite nodes, and the action nodes are used to represent the fault injection behavior. Exemplarily, the fault injection behavior represented by action node A is: injecting a radar signal delay fault; the fault injection behavior represented by action node B is: injecting a communication link packet loss fault.
[0063] In addition, the behavior tree may further include a trigger condition node. The trigger condition node is associated with the action node, and the trigger condition node can also be understood as the node information of the action node associated with it. The trigger condition node is used to represent the trigger condition of the fault injection behavior. Once the condition is met, the execution of the action node associated with it will be activated. Specifically, when executing to a certain composite node, it is judged whether the trigger condition corresponding to the trigger condition node is met. If it is met, the fault injection behavior represented by the action node associated with the trigger condition node is executed.
[0064] S102: In response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, add the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test, and test the vehicle under test to obtain a test result.
[0065] In the embodiments of the present application, during the simulation test of the vehicle under test, the composite nodes are sequentially executed in the order defined by the behavior tree. The composite node determines the execution manner of its own child nodes (trigger condition nodes and action nodes) according to its own type, such as sequential execution, parallel execution, etc. When it is detected that the vehicle under test meets the trigger condition of the trigger condition node, the corresponding fault injection behavior is executed. For example, injecting a communication link packet loss fault, etc.
[0066] After executing the corresponding fault injection behavior, obtain the running state of the vehicle under test and test the functions of the vehicle under test.
[0067] The following combines Figure 3 to further introduce the fault injection during the simulation operation. As Figure 3 shown, during the simulation test process, the backend service and the scenario running service can be run. Among them, the fault injection module and the OpenSsenario engine are jointly deployed in the image of the scenario running service to provide a complete simulation scenario running service. This deployment method helps to effectively integrate the two key components of fault injection and scenario description simulation, so as to realize the unified management and scheduling of the entire simulation process.
[0068] The OpenSsenario engine is an open standard for describing dynamic scenarios in autonomous driving simulations. Specifically, the OpenSsenario engine is responsible for implementing the operation of the simulation scenario, including the description of the scenario, the motion trajectory planning of the vehicle, etc. At the same time, the fault injection module is responsible for injecting various faults into the virtual vehicle during the simulation operation of the virtual vehicle. Specifically, fault data can be injected into the virtual vehicle through the virtual vehicle docking module to simulate various abnormal situations that the vehicle may encounter in the real environment. The fault injection module may specifically include a behavior tree module and a fault management module.
[0069] Throughout the process, the fault data is transmitted to the virtual vehicle in real time through the virtual vehicle docking module to ensure the timeliness and accuracy of fault injection. This deployment method provides an integrated simulation scenario operation service for the virtual twin vehicle project, enabling the system to better simulate the vehicle driving situation and fault occurrence scenarios in the real world.
[0070] By adopting the solution of the embodiment of the present application, a behavior tree for guiding the fault injection behavior of the vehicle under test during the simulation test process can be generated according to the fault injection configuration information written by the user. Among them, the composite node is used to control the execution logic of the action node, the action node is used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior. Guiding the fault injection during the simulation test process through the behavior tree can achieve precise timing control and condition determination, improve the flexible control ability of the simulation test process, and help to cope with complex and changeable test requirements.
[0071] In addition, the fault injection configuration information is different from scripts or test cases and does not require professional testers to write, reducing the requirements for testers.
[0072] In some embodiments of the present application, each composite node included in the behavior tree is executed sequentially; during the execution of any composite node, it is detected whether the vehicle under test meets the trigger condition represented by the trigger condition node associated with the action node under the composite node; if so, the fault injection behavior represented by the action node is executed.
[0073] It can be understood that the behavior tree contains multiple composite nodes. The execution order of the composite nodes in the behavior tree is related to the structure of the behavior tree. Each composite node may include multiple action nodes and trigger condition nodes associated with the action nodes.
[0074] Executing a certain composite node in the behavior tree actually means executing the action represented by this composite node, such as a test action for testing a specific function. During the execution of a certain composite node, it is judged whether the trigger condition represented by the trigger condition node associated with the action node under this composite node is satisfied according to the running state of the vehicle under test or other information. If it is satisfied, the fault injection action represented by this action node is executed.
[0075] Adopting the solution of the embodiment of the present application, during the simulation test of the vehicle under test, the fault injection behavior for the vehicle under test is guided by the behavior tree. According to the structure of the behavior tree, each composite node is executed in sequence. During the execution of the composite node, when it is detected that the trigger condition represented by the trigger condition node associated with the action node under this composite node is satisfied, the fault injection behavior represented by the action node is executed. Through the planning of the behavior tree, it is possible to more flexibly perform fault simulation according to the user's needs and ensure the authenticity and controllability of the simulation process.
[0076] In some embodiments of the present application, the fault injection behavior includes: a first fault injection behavior and a second fault injection behavior; the first fault injection behavior represents the injection behavior for communication faults, and the second fault injection behavior represents the injection behavior for sensor faults.
[0077] Specifically, the embodiment of the present application supports fault injection for communication faults and fault injection for sensor faults.
[0078] Among them, the fault injection for communication faults is used to simulate the interruption, delay, etc. of the communication link inside the vehicle or the communication link between the vehicle and external devices, and mainly tests the behavior of the system under abnormal communication.
[0079] In some embodiments of the present application, in response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, fault information corresponding to the target fault injection behavior is added to the simulation test scenario of the vehicle under test, including: in response to determining that the vehicle under test meets the trigger condition of the first fault injection behavior, communication fault parameters are added to the target data transmission channel of the simulation test scenario of the vehicle under test.
[0080] Specifically, when the trigger condition corresponding to the communication fault injection behavior is reached, communication fault parameters are added to the target data transmission channel condition. Among them, the target data transmission channel may include the communication link inside the vehicle and the communication link between the vehicle and external devices. Exemplarily, the target data transmission channel may be the communication link between the vehicle and the cloud, or the communication link for transmitting autonomous driving instructions, etc.
[0081] In the embodiments of the present application, communication failures may include data latency, data freezing, and data loss. Correspondingly, the communication failure parameters added to the target data transmission channel may include at least one of a data latency parameter, a data freezing parameter, and a data loss parameter.
[0082] Exemplarily, the data latency parameter may be represented by delay_time, which represents the latency time of data transmission, and the unit may be milliseconds. Data freezing means that the data does not change within a certain period of time, and the data freezing parameter may represent the time when the data is frozen. The data loss parameter may represent the probability of missing data transmission during the data transmission process.
[0083] Based on the above solution, during the operation of the simulation scenario, according to event determination, corresponding fault injection actions are performed on the critical data channels to effectively simulate the vehicle's response in the case of data failures and meet the requirements of diverse simulation technologies.
[0084] In some embodiments of the present application, in response to determining that the vehicle under test meets the trigger condition for the target fault injection behavior, fault information corresponding to the target fault injection behavior is added to the simulation test scenario of the vehicle under test, including: in response to determining that the vehicle under test meets the trigger condition for the second fault injection behavior, a sensor fault parameter is added to the sensor of the vehicle under test.
[0085] Specifically, during the simulation process, the faulty sensor is controlled by the fault parameter to inject a sensor fault into the virtual vehicle, simulating the occurrence of a sensor fault in a real vehicle.
[0086] In some embodiments of the present application, the sensor fault parameter may include: a camera fault parameter and a radar fault parameter; the camera fault parameter includes a noise parameter and / or a lens distortion parameter; the radar fault parameter includes at least one of a viewing angle failure parameter, a detection distance degradation parameter, a laser failure parameter, a performance degradation parameter, a loss ratio parameter, and a noise parameter.
[0087] For a camera, the addable fault parameters may include a noise parameter and a lens distortion parameter. Among them, noise can also be understood as snowflake, and the corresponding parameter can be used to represent the snowflake density. For example, the snowflake density can be set in the range of [0,1].
[0088] Lens distortion refers to the phenomenon that due to factors such as the design, manufacturing defects of the lens optical system, or imaging principle, the captured image deviates from the real scene in terms of geometric shape.
[0089] For a radar, the addable fault parameters may include field of view failure (fovfault), detection range degradation (rangefault), laser failure (laser_failure), performance degradation, increase in dropout rate, and noise.
[0090] Among them, the field of view failure indicates the state where the lidar cannot effectively detect, identify, or measure target objects within its designed or expected detection field of view. Correspondingly, the field of view failure parameter can be used to represent the horizontal field of view loss angle.
[0091] The detection range degradation indicates the phenomenon that the maximum detection range that the lidar can reach under ideal conditions is shortened due to various factors during actual use. Correspondingly, the detection range degradation parameter can be used to represent the lost distance.
[0092] The laser failure refers to the state where the core component (laser diode) serving as the light source in the lidar system completely stops working or its performance severely degrades so that it cannot meet the basic functional requirements. Correspondingly, the laser failure parameter can be used to represent the failure ratio, for example, it can be set in the range of [0, 1].
[0093] The performance degradation refers to the phenomenon that the comprehensive detection ability of the lidar gradually or periodically drops below the initial design or expected level due to the influence of usage time, environmental pressure, or sudden factors. It is not a complete failure but the attenuation of key performance parameters. Correspondingly, the performance degradation parameter can be used to represent the performance degradation ratio, for example, it can be set in the range of [0, 1].
[0094] The increase in dropout rate refers to the phenomenon that the point cloud of the target objects that the lidar should detect in the environment is frequently missing or interrupted in consecutive scan frames. Correspondingly, the increase in dropout rate parameter can be used to represent the dropout rate, for example, it can be set in the range of [0, 1].
[0095] The following further introduces the fault injection during the simulation run in combination with Figure 4 As shown in Figure 4 The simulation engine can activate / turn off faults according to the instructions of the behavior tree, including communication faults and sensor faults. The communication faults can be targeted at the data transmission channel, and the data transmission channel can be the transmission channel between the virtual vehicle and the simulation scenario. The sensor faults can be targeted at the virtual camera of the virtual vehicle. By activating / turning off the faults, fault information is injected into the vehicle under test, and the running state of the vehicle under test is obtained, and the running state can be displayed on the front-end page.
[0096] It can be understood that for sensor faults, Figure 4Taking the virtual camera as an example for illustrative purposes only, fault injection can also be performed on other virtual sensors, such as lidar, etc. The embodiments of the present application do not limit this.
[0097] In the solution of the embodiments of the present application, for communication faults and sensor faults, diverse fault effects can be achieved through parametric configuration. Compared with the method of using a preset static model to simulate faults in the related art, it can cover more camera fault situations and lidar fault situations, covering various fault situations such as lidar view failure, detection distance degradation, laser failure, performance degradation, and increasing loss ratio, better simulating the faults that actually occur in the real scenario, reducing the deviation between the test results and the real fault performance, and improving the accuracy of evaluation.
[0098] In the embodiments of the present application, the trigger condition for triggering the fault injection behavior can be associated with the simulation running time and the running state of the vehicle under test. For example, when the simulation running time reaches the corresponding time trigger value and / or the running state of the vehicle under test reaches the corresponding running state trigger value. Among them, the running state can include running speed, running acceleration, and driving distance.
[0099] Exemplarily, the trigger condition a can be set such that the running speed of the vehicle under test is greater than 60 km / h. During the simulation test process, it is executed in the order of the composite nodes in the behavior tree. When executing to a certain composite node, it is judged whether the trigger condition corresponding to the trigger condition node (the running speed of the vehicle under test is greater than 60 km / h) is satisfied. If satisfied, the fault injection behavior represented by the action node associated with the trigger condition node is executed. For example, if the fault injection behavior associated with the trigger condition a is to add the visual failure parameter of the radar, then the radar fault parameter is injected into the vehicle under test.
[0100] By setting the trigger condition in the above manner, associating the trigger condition with the simulation running time and the running state of the vehicle under test, dynamic triggering of fault injection is realized, and highly accurate control of fault injection is achieved. Moreover, the behavior tree is used to ensure precise timing control and condition determination, thereby supporting the flexible setting of when to start fault injection, when to end fault injection, where to inject, and what type of fault to inject. Compared with the method in the related art that cannot dynamically trigger fault injection, it can better meet the complex and changeable test requirements and improve the test coverage.
[0101] For ease of understanding, the vehicle fault simulation test method provided by the embodiments of the present application will be further introduced below with reference to the accompanying drawings.
[0102] As Figure 5 shown, on the one hand, for the scenario file, perform scenario file parsing to generate a simulation map.
[0103] On the other hand, according to the virtual vehicle configuration information, create a virtual vehicle owner, create NPC vehicles in the simulation map, and create pedestrians in sequence. Subsequently, configure the virtual sensors and configure the virtual vehicle.
[0104] For fault injection, first obtain the fault injection configuration information, perform fault injection configuration parsing, sensor fault configuration, import the configuration information of the sensor fault into the virtual sensor, and generate a fault injection behavior tree according to the fault configuration information.
[0105] Subsequently, the simulation engine can create an NPC vehicle behavior control node, create a pedestrian behavior control node, and generate a scene behavior tree. The simulation engine conducts a simulation test by running the scene behavior tree. During the simulation test, determine whether the scene ends. If not, perform the simulation engine tick, the scene behavior tree tick, and the virtual vehicle tick in sequence, where tick represents advancing one simulation time step. If so, end, that is, complete the simulation test.
[0106] Adopting the solution of the embodiment of the present application, a behavior tree for guiding the fault injection behavior of the vehicle under test during the simulation test can be generated according to the fault injection configuration information written by the user. Among them, the combination node is used to control the execution logic of the action node, the action node is used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior. Guiding the fault injection during the simulation test through the behavior tree can achieve precise timing control and condition determination, improve the flexible control ability of the simulation test process, and help to cope with complex and changeable test requirements.
[0107] In addition, the fault injection configuration information is different from scripts or test cases and does not require professional testers to write, reducing the requirements for testers.
[0108] The above mainly introduces the solution provided by the embodiment of the present application from the perspective of the method. To implement the above functions, the parking monitoring device or electronic device of the vehicle includes the corresponding hardware structure and / or software module for executing each function. Those skilled in the art should easily realize that, combining the units and algorithm steps of each example described in the embodiments disclosed in this article, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a certain function is executed in the way of hardware or computer software driving the hardware depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.
[0109] Embodiments of the present application can divide functional modules according to the above method, for example, a fault simulation test device or an electronic device of a vehicle. For example, a fault simulation test device or an electronic device of a vehicle can include various functional modules corresponding to each functional division, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of a software functional module. It should be noted that the division of modules in the embodiments of the present application is illustrative, only a logical function division, and there can be other division methods in actual implementation.
[0110] Figure 6 is a block diagram of a fault simulation test device of a vehicle shown according to an exemplary embodiment. Refer to Figure 6 This fault simulation test device of the vehicle includes a generation module 601 and a fault injection module 602.
[0111] The generation module 601 is configured to generate a behavior tree based on the fault injection configuration information; the behavior tree is used to guide the fault injection behavior for the vehicle under test during the simulation test process; the behavior tree includes combination nodes and action nodes; the combination nodes are used to control the execution logic of the action nodes; the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior.
[0112] The fault injection module 602 is configured to, in response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, add the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test, and test the vehicle under test to obtain a test result.
[0113] In a possible way, in response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, adding the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test includes: Sequentially execute each combination node included in the behavior tree; during the execution of any combination node, detect whether the vehicle under test meets the trigger condition represented by the trigger condition node associated with the action node under the combination node; if so, execute the fault injection behavior represented by the action node.
[0114] Adopting the solution of the embodiments of the present application, during the simulation test process for the vehicle under test, the fault injection behavior for the vehicle under test is guided by the behavior tree. According to the structure of the behavior tree, each combination node is sequentially executed. During the execution of the combination node, when it is detected that the trigger condition represented by the trigger condition node associated with the action node under the combination node is met, the fault injection behavior represented by the action node is executed. Through the planning of the behavior tree, it is possible to more flexibly perform fault simulation according to the user's needs and ensure the authenticity and controllability of the simulation process.
[0115] In a possible way, the fault injection behavior includes: a first fault injection behavior and a second fault injection behavior; the first fault injection behavior represents the injection behavior for communication faults, and the second fault injection behavior represents the injection behavior for sensor faults.
[0116] Adopting the solution of the embodiment of the present application supports the collaborative injection of multiple types of faults, covering the injection behavior for communication faults and the injection behavior for sensor faults, and has high flexibility.
[0117] In a possible way, the fault injection module is specifically used for: In response to determining that the vehicle to be tested meets the trigger condition of the first fault injection behavior, add communication fault parameters to the target data transmission channel of the simulation test scenario of the vehicle to be tested.
[0118] Adopting the solution of the embodiment of the present application, according to event determination during the operation of the simulation scenario, perform corresponding fault injection actions on the key data channels, so as to effectively simulate the response of the vehicle in the case of data faults and meet the requirements of diverse simulation technologies.
[0119] In a possible way, the communication fault parameters include at least one of: data delay parameters, data freeze parameters, and data loss parameters.
[0120] Adopting the solution of the embodiment of the present application, according to event determination during the operation of the simulation scenario, perform corresponding fault injection actions on the key data channels, so as to effectively simulate the response of the vehicle in the case of data faults and meet the requirements of diverse simulation technologies.
[0121] Compared with the related art that only supports single-mode fault injection, it can significantly improve the flexibility of fault injection. At the same time, the injection of diverse fault parameters can reduce the deviation between the test results and the real fault performance, and improve the accuracy of test evaluation.
[0122] In a possible way, the fault injection module is specifically used for: In response to determining that the vehicle to be tested meets the trigger condition of the second fault injection behavior, add sensor fault parameters to the sensors of the vehicle to be tested.
[0123] In a possible way, the sensor fault parameters include: camera fault parameters and radar fault parameters; The camera fault parameters include noise parameters and / or lens distortion parameters; The radar fault parameters include at least one of: perspective failure parameters, detection distance degradation parameters, laser failure parameters, performance degradation parameters, loss ratio parameters, and noise parameters.
[0124] In the solution of the embodiment of the present application, for communication failures and sensor failures, diverse failure effects can be achieved through parametric configuration. Compared with the method of using a preset static model to simulate failures in the related art, it can cover more camera failure situations and lidar failure situations, including various failure situations such as lidar view failure, detection distance degradation, laser failure, performance degradation, and increasing loss ratio, better simulating the failures that actually occur in the real scenario, reducing the deviation between the test results and the real failure performance, and improving the accuracy of evaluation.
[0125] In a possible way, the trigger conditions include: The simulation running time reaches the corresponding time trigger value and / or the running state of the vehicle to be tested reaches the corresponding running state trigger value; the running state includes any one of running speed, running acceleration, and driving distance.
[0126] In the solution of the embodiment of the present application, the trigger conditions are associated with the simulation running time and the running state of the vehicle to be tested, realizing dynamic trigger of fault injection and highly precise control of fault injection. Moreover, a behavior tree is used to ensure precise timing control and condition determination, thus supporting flexible setting of when to start fault injection, when to end fault injection, where to inject, and what type of fault to inject. Compared with the method in the related art that cannot dynamically trigger fault injection, it can better cope with complex and changeable test requirements and improve the test coverage.
[0127] Figure 7 It is a block diagram of an electronic device shown according to an exemplary embodiment. As Figure 7 shown, the electronic device includes but is not limited to: a processor 701 and a memory 702.
[0128] Among them, the above-mentioned memory 702 is used to store the executable instructions of the above-mentioned processor 701. It can be understood that the above-mentioned processor 701 is configured to execute instructions to implement the vehicle fault simulation test method in the above embodiment.
[0129] It should be noted that those skilled in the art can understand that Figure 7 the structure of the electronic device shown in Figure 7 does not constitute a limitation on the electronic device. The electronic device may include more or fewer components than
[0130] The processor 701 is the control center of the electronic device, connecting various parts of the entire electronic device through various interfaces and circuits. By running or executing software programs and / or modules stored in the memory 702, and by invoking the data stored in the memory 702, it executes various functions of the electronic device and processes data, thereby monitoring the electronic device as a whole. The processor 701 may include one or more processing units. Optionally, the processor 701 may integrate an application processor and a modem processor. Among them, the application processor mainly processes the operating system, user interface, application programs, etc., and the modem processor mainly processes wireless communication. It can be understood that the above-mentioned modem processor may not be integrated into the processor 701 either.
[0131] The memory 702 can be used to store software programs and various data. The memory 702 mainly includes a program storage area and a data storage area. Among them, the program storage area can store the operating system, application programs required by at least one functional module (such as a determination unit, a processing unit, etc.). In addition, the memory 702 may include high-speed random access memory, and may also include non-volatile memory, such as at least one magnetic disk storage device, a flash memory device, or other non-volatile solid-state storage devices.
[0132] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as the memory 702 including instructions. The above instructions can be executed by the processor 701 of the electronic device to implement the method in the above embodiment.
[0133] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium. For example, the non-transitory computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, and an optical data storage device, etc.
[0134] In an exemplary embodiment, the embodiment of the present application also provides a computer program product including one or more instructions. The one or more instructions can be executed by the processor of the electronic device to complete the method in the above embodiment.
[0135] It should be noted that when the instructions in the above computer-readable storage medium or the one or more instructions in the computer program product are executed by the processor of the electronic device, they implement each process of the above method embodiment and can achieve the same technical effects as the above method. To avoid repetition, it will not be elaborated here.
[0136] Through the description of the above embodiments, those skilled in the art can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be allocated to different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.
[0137] In several embodiments provided in the present application, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of modules or units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical or other form.
[0138] The unit described as a separated component may or may not be physically separated. The component displayed as a unit may be a physical unit or multiple physical units, that is, it can be located in one place, or it can be distributed to multiple different places. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.
[0139] In addition, each functional unit in various embodiments of the present application can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.
[0140] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solution of the embodiments of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The software product is stored in a storage medium and includes several instructions to enable a device (which can be a single-chip microcomputer, a chip, etc.) or a processor to execute all or part of the steps of the methods in various embodiments of the present application. The foregoing storage medium includes: USB flash drives, mobile hard disks, ROM, RAM, magnetic disks or optical discs and other media that can store program codes.
[0141] The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application shall be covered by the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims
1. A fault simulation test method for a vehicle, characterized in that, The method includes: Generating a behavior tree based on fault injection configuration information; the behavior tree is used to guide the fault injection behavior for the vehicle under test during the simulation test; the behavior tree includes composite nodes and action nodes; the composite nodes are used to control the execution logic of the action nodes; the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior; In response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, adding the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test, and testing the vehicle under test to obtain a test result.
2. The method according to claim 1, characterized in that In response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, adding the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test includes: Sequentially executing each of the composite nodes included in the behavior tree; During the execution of any one of the composite nodes, detecting whether the vehicle under test meets the trigger condition represented by the trigger condition node associated with the action node under the composite node; If so, executing the fault injection behavior represented by the action node.
3. The method according to claim 1 or 2, characterized in that, The fault injection behavior includes: a first fault injection behavior and a second fault injection behavior; the first fault injection behavior represents the injection behavior for communication faults, and the second fault injection behavior represents the injection behavior for sensor faults.
4. The method according to claim 3, characterized in that, In response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, adding the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test includes: In response to determining that the vehicle under test meets the trigger condition of the first fault injection behavior, adding communication fault parameters to the target data transmission channel of the simulation test scenario of the vehicle under test.
5. The method according to claim 4, wherein The communication fault parameters include at least one of: a data delay parameter, a data freeze parameter, and a data loss parameter.
6. The method according to claim 3, characterized in that, In response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, adding the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test includes: In response to determining that the vehicle under test meets the trigger condition of the second fault injection behavior, adding sensor fault parameters to the sensors of the vehicle under test.
7. The method according to claim 6, characterized in that The sensor fault parameters include: camera fault parameters and radar fault parameters; The camera fault parameters include noise parameters and / or lens distortion parameters; The radar fault parameters include at least one of: a view failure parameter, a detection range degradation parameter, a laser failure parameter, a performance degradation parameter, a loss ratio parameter, and a noise parameter.
8. The method according to claim 1, characterized in that, The trigger condition includes: The simulation running time reaches the corresponding time trigger value and / or the running state of the vehicle under test reaches the corresponding running state trigger value; the running state includes any one of: running speed, running acceleration, and driving distance.
9. A fault simulation test device for a vehicle, characterized in that, The device includes: A generation module, configured to generate a behavior tree based on fault injection configuration information; the behavior tree is used to guide the fault injection behavior for the vehicle under test during the simulation test; the behavior tree includes composite nodes and action nodes; the composite nodes are used to control the execution logic of the action nodes; the action nodes are used to represent the fault injection behavior, and the node information of each action node is used to represent the trigger condition of the fault injection behavior. A fault injection module, configured to, in response to determining that the vehicle under test meets the trigger condition of the target fault injection behavior, add the fault information corresponding to the target fault injection behavior to the simulation test scenario of the vehicle under test, and test the vehicle under test to obtain a test result.
10. The device according to claim 9, characterized in that, The fault injection module is specifically configured to: Sequentially execute each of the composite nodes included in the behavior tree; During the execution of any one of the composite nodes, detect whether the vehicle under test meets the trigger condition represented by the trigger condition node associated with the action node under the composite node; If so, execute the fault injection behavior represented by the action node.
11. The device according to claim 9, characterized in that, The fault injection behavior includes: a first fault injection behavior and a second fault injection behavior; the first fault injection behavior represents the injection behavior for communication faults, and the second fault injection behavior represents the injection behavior for sensor faults.
12. An electronic device, characterized in that, Including: A processor; A memory for storing executable instructions of the processor; Wherein, the processor is configured to execute the instructions to implement the method according to any one of claims 1-8.
Citation Information
Patent Citations
Generation method, apparatus and device for AI behavior tree of test robot
CN107526682A
Methods and systems for fault injection testing of integrated circuit hardware design
CN114065677A
Behavior tree operation method and device, electronic equipment and storage medium
CN115934261A
Fault injection method and device for automatic driving test and computer equipment
CN116466687A
Controlling process of robots having a behavior tree architecture
US20190086894A1