Automatic driving fault simulation method and device, electronic equipment and storage medium

Abstract

The embodiment of the invention discloses an automatic driving fault simulation method and device, electronic equipment and a storage medium, and relates to the technical field of automatic driving simulation tests.The method comprises the steps that a three-dimensional digital twin map supporting graphic rendering is constructed, and a sensor simulator, a vehicle dynamics model and a traffic flow simulator are integrated; and a digital twinborn simulator and a simulation environment are formed. An automatic driving system is connected to form a closed-loop test system, sensor data is generated in real time, and a simulation vehicle is driven to perform interaction test. Hardware faults such as noise, delay and loss of an injection sensor, bit flipping of calculation hardware and the like are simulated in real time, and the fault-tolerant capability of the system is comprehensively tested. The performance and behavior of the automatic driving system are monitored in real time, and when a failure condition is triggered, scene parameters, fault types and software states are automatically recorded, analyzed and evaluated. According to the invention, the problems of insufficient hardware fault coverage and lack of dynamic fault injection and real-time monitoring capability in the prior art are effectively solved.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving simulation testing technology, and in particular to an autonomous driving fault simulation method, device, electronic device, and storage medium. Background Technology

[0002] With the rapid development of autonomous driving technology, the testing scenarios faced by autonomous driving systems are becoming increasingly complex and diverse. Among these, the impact of hardware failures on the safety of autonomous driving cannot be ignored. In actual operation, autonomous driving systems rely on various sensors (such as LiDAR, cameras, millimeter-wave radar, etc.) to perceive the surrounding environment, while also relying on computing hardware for data processing and decision-making.

[0003] However, hardware malfunctions, such as sensor noise interference, data transmission delays, data loss, and bit flips in computing hardware, can all cause perception distortion or decision-making errors in autonomous driving systems, leading to serious safety accidents such as collisions and violations, posing a huge threat to passenger safety and road traffic order.

[0004] Traditional autonomous driving testing methods mostly focus on performance verification under normal operating conditions, which is insufficient in covering hardware failure scenarios and makes it difficult to simulate the randomness and complexity of hardware failures in real-world environments.

[0005] In addition, traditional testing methods lack the ability to dynamically inject and monitor hardware faults in real time, and cannot fully evaluate the fault tolerance and safety performance of autonomous driving systems under hardware faults.

[0006] Therefore, there is an urgent need for an efficient and reliable method for simulating autonomous driving faults that can comprehensively cover hardware failure scenarios, support dynamic fault injection and real-time monitoring. Summary of the Invention

[0007] The present invention provides an autonomous driving fault simulation method to address the problems of insufficient coverage of hardware fault scenarios, lack of dynamic fault injection and real-time monitoring capabilities, and difficulty in comprehensively evaluating the fault tolerance and safety performance of the system under hardware faults in existing technologies. The technical solution is as follows: According to one aspect of the present invention, an autonomous driving fault simulation method is provided, the method comprising: constructing a three-dimensional digital twin map supporting graphics rendering; constructing and integrating a sensor simulator, a vehicle dynamics model, and a traffic flow simulator to obtain a digital twin simulator and a simulation environment; the three-dimensional digital twin map includes three-dimensional road structure information and traffic element information; forming a closed-loop test system by connecting an autonomous driving system as the test object into the simulation environment; generating sensor data in real time through the digital twin simulator and outputting it to the autonomous driving system to obtain control commands to drive the simulated vehicle for interactive testing; simulating and injecting hardware faults into the sensor simulator and the autonomous driving system in the simulation environment in real time to test the fault tolerance capability of the autonomous driving system to hardware faults; the hardware faults include sensor noise, latency, loss, and computational hardware bit flipping; monitoring the performance and behavior of the autonomous driving system in real time; when a preset failure condition is triggered, recording and analyzing scene parameters, fault types, and software states to evaluate the safety and fault tolerance capability of the autonomous driving system under hardware faults; the failure conditions include collision and violation.

[0008] In one embodiment, constructing a 3D digital twin map supporting graphics rendering is achieved through the following steps: extracting road geometry, lane topology, and traffic sign locations based on real road data, and semantically annotating the data using GIS tools to obtain map data; the road data includes laser point clouds and high-precision map data; the geometry includes curvature and slope; the lane topology includes solid and dashed lines and the number of lanes; the traffic sign locations include speed limit signs and traffic light coordinates; the map data is converted into a 3D mesh model using the rendering pipeline of an engine, and dynamic lighting, texture mapping, and detailed elements are added; the engine includes Unreal Engine and Unity engine; the detailed elements include roadside trees and buildings.

[0009] In one embodiment, a digital twin simulator and simulation environment are obtained by constructing and integrating a sensor simulator, a vehicle dynamics model, and a traffic flow simulator through the following steps: A sensor simulator is constructed based on the internal and external parameters of the sensors; the sensors include cameras and lidar; the internal parameters include focal length and viewing angle; the external parameters include installation position and orientation; a vehicle dynamics model covering longitudinal, lateral, and vertical kinematic characteristics is constructed using vehicle dynamics simulation software, and interacts with the simulation environment through a real-time interface; the control commands include throttle opening and steering angle; vehicle behavior and pedestrian behavior are generated based on trajectory playback or deep reinforcement learning algorithms; the vehicle behavior includes simulated following, lane changing, and overtaking; the pedestrian behavior includes crossing the road and yielding.

[0010] In one embodiment, a closed-loop test system is formed by connecting the autonomous driving system as the test object to the simulation environment. The digital twin simulator generates sensor data in real time and outputs it to the autonomous driving system to obtain control commands, driving the simulated vehicle to perform interactive testing. This is achieved through the following steps: the autonomous driving system is connected to the simulation environment as the test object, and data interaction is performed through a standardized interface. The digital twin simulator generates sensor data in real time based on the vehicle dynamics model and the state of the traffic flow simulator. The sensor data is fused into a perception input through spatial and temporal alignment. The simulated vehicle updates its state according to the control commands of the autonomous driving system, while generating new sensor data to feed back to the autonomous driving system. The system state is recorded through a log. The system state includes sensor data, control commands, and vehicle trajectory.

[0011] In one embodiment, hardware fault simulation and injection are performed in real time on the sensor simulator and autonomous driving system in the simulation environment to test the fault tolerance capability of the autonomous driving system to hardware faults. This is achieved through the following steps: adding Gaussian noise or salt-and-pepper noise to the camera image to simulate sensor electronic interference; adding random points to the radar point cloud to simulate multipath reflection; modifying the timestamp of the sensor data to simulate data transmission or processing delay; discarding sensor data frames in a probabilistic manner to simulate communication interruption or hardware fault; and modifying the sensor intrinsic and extrinsic parameters to simulate parameter changes caused by mechanical vibration or thermal stress. The intrinsic and extrinsic parameters include the camera focal length and the radar installation angle. Radiation effects are simulated for the key computing modules of the autonomous driving system. The memory or register access of the autonomous driving system is monitored, key data structures are located, and target bits are flipped at a preset probability at a specified time point to simulate memory errors. The processing of the autonomous driving system for erroneous data is observed. The processing includes error detection and fault-tolerant recovery.

[0012] In one embodiment, real-time monitoring of the performance and behavior of the autonomous driving system is achieved through the following steps: determining whether the autonomous vehicle has come into contact with other objects through collision detection in the simulation environment, monitoring whether the vehicle crosses the line, speeds, or violates traffic signals, and calculating error indicators. If the error indicators exceed a threshold, a failure is triggered. The error indicators include path tracking error and response delay. The system status is acquired in real time through the API or ROS node of the simulation environment, time-series data is recorded, and the system is judged in real time whether it is abnormal based on the failure conditions. The monitoring results are displayed through a visual interface. The time-series data includes sensor data, control commands, and vehicle trajectory.

[0013] In one embodiment, recording and analyzing scene parameters, fault types, and software states to evaluate the safety and fault tolerance of the autonomous driving system under hardware failures is achieved through the following steps: automatically recording relevant data; the relevant data includes scene parameters, fault types, and software states; the scene parameters include traffic flow density, road curvature, and weather conditions; the fault types include sensor noise intensity, bit flip positions, and delay times; the software states include decision logs and error handling mechanisms; statistically analyzing fault indicators using data analysis tools and generating test reports to evaluate the safety and fault tolerance of the autonomous driving system under hardware failures, providing a basis for system optimization; the fault indicators include fault trigger frequency, time from fault occurrence to system recovery, and the proportion of hardware failure modes covered by the test scenario.

[0014] According to one aspect of the present invention, an autonomous driving fault simulation device is provided, the device comprising: a twin map construction module, used to construct a three-dimensional digital twin map supporting graphics rendering, by constructing and integrating a sensor simulator, a vehicle dynamics model and a traffic flow simulator to obtain a digital twin simulator and a simulation environment; the three-dimensional digital twin map includes three-dimensional road structure information and traffic element information; a closed-loop test formation module, used to form a closed-loop test system by connecting the autonomous driving system as the test object into the simulation environment, by generating sensor data in real time through the digital twin simulator and outputting it to the autonomous driving system to obtain control commands, driving the simulated vehicle to perform interactive testing; a fault simulation injection module, used to simulate and inject hardware faults into the sensor simulator and the autonomous driving system in the simulation environment in real time, and test the fault tolerance capability of the autonomous driving system to hardware faults; the hardware faults include sensor noise, latency, loss and computational hardware bit flipping; and a performance detection and evaluation module, used to monitor the performance and behavior of the autonomous driving system in real time, and when a preset failure condition is triggered, record and analyze the scene parameters, fault type and software status, and evaluate the safety and fault tolerance capability of the autonomous driving system under hardware faults; the failure conditions include collision and violation.

[0015] According to one aspect of the present invention, an electronic device includes at least one processor and at least one memory, wherein computer-readable instructions are stored on the memory; the computer-readable instructions are executed by one or more of the processors to cause the electronic device to implement the autonomous driving fault simulation method as described above.

[0016] According to one aspect of the invention, a storage medium stores computer-readable instructions thereon, which are executed by one or more processors to implement the autonomous driving fault simulation method as described above.

[0017] The beneficial effects of the technical solution provided by this invention are: In the above technical solution, this invention first constructs a 3D digital twin map supporting graphics rendering, integrating a sensor simulator, vehicle dynamics model, and traffic flow simulator to form a digital twin simulator and simulation environment. The autonomous driving system is then connected to this environment to form a closed-loop test system, generating sensor data in real time and driving interactive testing of the simulated vehicle. During testing, hardware faults such as injected sensor noise, latency, data loss, and bit flipping in computing hardware are simulated in real time to comprehensively test the fault tolerance of the autonomous driving system. Simultaneously, the performance and behavior of the autonomous driving system are monitored in real time. When preset failure conditions such as collisions or violations are triggered, scene parameters, fault types, and software states are automatically recorded and analyzed. This method not only achieves a comprehensive evaluation of the safety and fault tolerance of the autonomous driving system under hardware faults but also provides a strong basis for system optimization. It effectively solves the problems of insufficient hardware fault coverage and lack of dynamic fault injection and real-time monitoring capabilities in existing testing methods, significantly improving the reliability and safety of the autonomous driving system. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating an autonomous driving fault simulation method according to an exemplary embodiment; Figure 2 This is a schematic diagram of a hardware closed-loop simulation system that uses an autonomous driving fault simulation method in an application scenario. Figure 3 yes Figure 2 A flowchart for hardware fault injection in the corresponding application scenario; Figure 4 This is a block diagram of an autonomous driving fault simulation device according to an exemplary embodiment; Figure 5 This is a hardware structure diagram of an electronic device according to an exemplary embodiment; Figure 6 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0020] Embodiments of the present invention are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0021] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this disclosure means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0022] This invention provides a method for simulating autonomous driving faults. By constructing a three-dimensional digital twin simulation environment and connecting it to the autonomous driving system to form a closed-loop test, it simulates injected hardware faults in real time and monitors and evaluates system performance. This achieves comprehensive testing of the hardware fault tolerance capability of the autonomous driving system, solving the problems of insufficient coverage and lack of dynamic monitoring in existing testing methods. This autonomous driving fault simulation method is applicable to autonomous driving fault simulation devices, which can be electronic devices. The autonomous driving fault simulation method in this invention can be applied to various scenarios, such as simulating hardware faults in autonomous vehicles.

[0023] Please see Figure 1 This invention provides an autonomous driving fault simulation method, which is applicable to electronic devices.

[0024] In the following method embodiments, for ease of description, the execution subject of each step of the method is an electronic device, but this does not constitute a specific limitation.

[0025] like Figure 1 As shown, the method may include the following steps: Step 110: Construct a 3D digital twin map that supports graphics rendering. This is achieved by building and integrating a sensor simulator, a vehicle dynamics model, and a traffic flow simulator to obtain a digital twin simulator and simulation environment.

[0026] In one possible implementation, road geometry, lane topology, and traffic sign locations are extracted from real road data, and then semantically labeled using Geographic Information System (GIS) tools to obtain map data.

[0027] The three-dimensional digital twin map includes three-dimensional road structure information, traffic element information, etc.; road data includes laser point cloud, high-precision map data, etc.; geometric structure includes curvature, slope, etc.; lane line topology includes dashed and solid lines, number of lanes, etc.; traffic sign locations include speed limit signs, traffic light coordinates, etc., none of which are specified here.

[0028] One possible implementation involves using the engine's rendering pipeline to convert map data into a 3D mesh model, adding dynamic lighting, texture mapping, and detailed elements.

[0029] The engine includes Unreal Engine, Unity Engine, etc.; the details include roadside trees, buildings, etc., which are not specified here.

[0030] In one possible implementation, a sensor simulator is built based on the sensor's internal and external parameters. A vehicle dynamics simulation software is used to construct a vehicle dynamics model that covers longitudinal, lateral, and vertical kinematic characteristics. The model interacts with the simulation environment through a real-time interface and generates vehicle and pedestrian behaviors based on trajectory playback or deep reinforcement learning algorithms.

[0031] The sensors include cameras, lidar, etc.; internal parameters include focal length, angle of view, etc.; external parameters include installation position, orientation, etc.; control commands include throttle opening, steering angle, etc.; vehicle behavior includes simulated following, lane changing, overtaking, etc.; pedestrian behavior includes crossing the road, yielding, etc., none of which are specified here.

[0032] Specifically, based on real road data, such as laser point clouds and high-precision map data, the road geometry (including curvature and slope), lane topology (including dashed and solid lines and the number of lanes) and traffic sign locations (including speed limit signs and traffic light coordinates) are extracted, and semantic annotation is performed using geographic information system (GIS) tools to obtain accurate map data.

[0033] Furthermore, by utilizing the rendering pipeline of game engines such as Unreal Engine or Unity, map data is converted into a 3D mesh model, and dynamic lighting, material maps, and detailed elements (such as roadside trees and buildings) are added. Rendering performance is optimized through Level of Detail (LOD) technology to ensure the visual realism and operational efficiency of the simulation environment.

[0034] Furthermore, based on the sensor's internal parameters (such as focal length and viewing angle) and external parameters (such as installation location and orientation), data rendering models for sensors such as cameras and LiDAR are constructed to simulate the sensor's output data under different environments.

[0035] Furthermore, vehicle dynamics simulation software is used to construct a vehicle dynamics model that covers longitudinal, lateral, and vertical kinematic characteristics, ensuring that the vehicle's motion behavior in the simulation environment is consistent with that in the real world.

[0036] Furthermore, based on trajectory playback or deep reinforcement learning algorithms, vehicle and pedestrian behaviors are generated to simulate real-world traffic flow, including vehicle decisions such as following, changing lanes, and overtaking, as well as pedestrian behaviors such as crossing the road and yielding.

[0037] In the above process, the embodiments of the present invention construct a high-fidelity three-dimensional digital twin simulation environment by accurately collecting and processing real road data, providing a visual and physical experience that is highly consistent with the real world, realizing a realistic simulation of the operating environment of the autonomous driving system, and laying the foundation for subsequent closed-loop testing and hardware fault simulation.

[0038] Step 120: By connecting the autonomous driving system as the test object to the simulation environment to form a closed-loop test system, the digital twin simulator generates sensor data in real time and outputs it to the autonomous driving system to obtain control commands, driving the simulated vehicle to conduct interactive tests.

[0039] In one possible implementation, the autonomous driving system is connected to the simulation environment as the object under test, and data is exchanged through a standardized interface. A digital twin simulator generates sensor data in real time based on the vehicle dynamics model and the state of the traffic flow simulator, and a global clock ensures that the timestamp of the sensor data is consistent with the simulation environment.

[0040] In one possible implementation, sensor data is fused into a perception input through spatial and temporal alignment. The simulated vehicle updates its state according to the control commands of the autonomous driving system, while generating new sensor data to feed back to the autonomous driving system, and the system state is recorded through logs.

[0041] The system status includes sensor data, control commands, vehicle trajectory, etc., which are not specified here.

[0042] Specifically, the autonomous driving system is connected to the simulation environment as the object under test, and data interaction is carried out through standardized interfaces to ensure a seamless connection between the simulation environment and the autonomous driving system. The digital twin simulator generates sensor data in real time based on the vehicle dynamics model and the state of the traffic flow simulator, and ensures that the timestamp of the sensor data is consistent with the simulation environment through a global clock, simulating the sensor output in the real world.

[0043] Furthermore, the autonomous driving system generates control commands based on the received sensor data, and the simulated vehicle updates its state according to the control commands, while simultaneously generating new sensor data to feed back to the autonomous driving system, forming a closed-loop test system. The system state, including sensor data, control commands, and vehicle trajectory, is recorded in logs, providing data support for subsequent fault analysis and performance evaluation.

[0044] In the above process, the embodiments of the present invention realize real-time data interaction and feedback between the simulation environment and the autonomous driving system by forming a closed-loop test system, providing a comprehensive test environment for the performance of the autonomous driving system, enabling real-time evaluation of the performance of the autonomous driving system in different scenarios, and providing a reliable platform for subsequent hardware fault simulation and performance evaluation.

[0045] Step 130: Simulate and inject hardware faults in the sensor simulator and autonomous driving system in the simulation environment in real time to test the fault tolerance capability of the autonomous driving system to hardware faults.

[0046] In one possible implementation, Gaussian noise or salt-and-pepper noise is added to the camera image to simulate sensor electronic interference; random points are added to the radar point cloud to simulate multipath reflection; timestamps of sensor data are modified to simulate data transmission or processing delays; sensor data frames are dropped probabilistically to simulate communication interruptions or hardware failures; sensor intrinsic and extrinsic parameters are modified to simulate parameter changes caused by mechanical vibration or thermal stress; radiation effects are simulated for key computing modules of the autonomous driving system; memory or register accesses of the autonomous driving system are monitored; key data structures are located; target bits are flipped at a predetermined probability at a specified time point to simulate memory errors; and the autonomous driving system's handling of erroneous data is observed.

[0047] The internal and external parameters include camera focal length, radar installation angle, etc.; the processing includes error detection, fault tolerance and recovery, etc.; hardware faults include sensor noise, latency, loss and computing hardware bit flipping, etc., none of which are specified here.

[0048] Specifically, Gaussian noise or salt-and-pepper noise is added to camera images to simulate sensor electronic interference, random points are added to radar point clouds to simulate multipath reflection, timestamps of sensor data are modified to simulate data transmission or processing delays, sensor data frames are dropped probabilistically to simulate communication interruptions or hardware failures, and sensor intrinsic and extrinsic parameters are modified to simulate parameter changes caused by mechanical vibration or thermal stress.

[0049] Furthermore, for key computing modules of the autonomous driving system (such as perception, prediction, planning, and control modules), data bit errors in memory or registers caused by radiation effects are simulated. By monitoring memory or register access, key data structures are located, and target bits are flipped at specified time points with a preset probability to simulate memory errors. The autonomous driving system's handling of erroneous data is then observed. Through parameterized fault models, faults are injected into the critical data streams of the autonomous driving system in real time and controllably at the software level, simulating real hardware failure scenarios.

[0050] In the above process, the embodiments of the present invention provide a comprehensive test of the fault tolerance capability of the autonomous driving system by simulating and injecting hardware faults in real time. This enables the evaluation of the autonomous driving system's performance under hardware faults and verifies the effectiveness of its error detection, error recovery and fault tolerance mechanisms, thus providing an important guarantee for the safety and reliability of the autonomous driving system.

[0051] Step 140: Monitor the performance and behavior of the autonomous driving system in real time. When the preset failure conditions are triggered, record and analyze the scene parameters, fault type and software status to evaluate the safety and fault tolerance of the autonomous driving system under hardware failure.

[0052] The failure conditions include collisions, violations, etc., but are not specified here.

[0053] In one possible implementation, collision detection in the simulation environment is used to determine whether the autonomous vehicle comes into contact with other objects, monitor whether the vehicle crosses the line, speeds, or violates traffic signals, and statistically analyze error indicators. If the error indicators exceed the threshold, a failure is triggered. The system status is obtained in real time through the API or ROS node of the simulation environment, time series data is recorded, and the system is judged in real time whether it is abnormal based on the failure conditions. The monitoring results are displayed through a visual interface.

[0054] Error metrics include path tracking error, response delay, etc.; time series data includes sensor data, control commands, vehicle trajectory, etc., which are not specified here.

[0055] In one possible implementation, when a preset failure condition is triggered, relevant data is automatically recorded, and fault indicators are statistically analyzed using data analysis tools to generate a test report. This assesses the safety and fault tolerance of the autonomous driving system under hardware failure, providing a basis for system optimization.

[0056] The relevant data includes scenario parameters, fault types, software status, etc.; scenario parameters include traffic flow density, road curvature, weather conditions, etc.; fault types include sensor noise intensity, bit flip position, delay time, etc.; software status includes decision logs, error handling mechanisms, etc.; fault indicators include fault trigger frequency, time from fault occurrence to system recovery, percentage of hardware fault modes covered by the test scenario, etc., none of which are specified here.

[0057] Specifically, collision detection in the simulation environment determines whether the autonomous vehicle comes into contact with other objects, monitors whether the vehicle crosses the line, speeds, or violates traffic signals, and counts error indicators such as path tracking error and response delay. If the error indicators exceed the threshold, a failure condition is triggered.

[0058] Furthermore, the system status, including time-series data such as sensor data, control commands, and vehicle trajectories, is acquired in real time through the API or ROS node of the simulation environment. The system is judged in real time whether it is abnormal based on the failure conditions, and the monitoring results are displayed through a visual interface.

[0059] Furthermore, the system automatically records relevant data such as scene parameters (e.g., traffic flow density, road curvature, weather conditions), fault types (e.g., sensor noise intensity, bit flip position, delay time), and software status (e.g., decision logs, error handling mechanisms). Through data analysis tools, it statistically analyzes fault indicators and generates test reports to evaluate the safety and fault tolerance of the autonomous driving system under hardware failures.

[0060] In the above process, the embodiments of the present invention provide a comprehensive assessment of the safety and fault tolerance of the autonomous driving system under hardware failure through real-time monitoring and evaluation, which enables timely detection and correction of problems in the autonomous driving system, provides a basis for system optimization, and achieves continuous improvement of the performance and safety of the autonomous driving system.

[0061] Through the above process, this invention, by constructing a high-fidelity three-dimensional digital twin simulation environment, forming a closed-loop test system, simulating and injecting hardware faults in real time, and monitoring and evaluating in real time, achieves comprehensive testing and evaluation of the hardware fault tolerance capability of autonomous driving systems. This method provides a test environment highly consistent with the real world, capable of simulating real hardware failure scenarios, evaluating the performance of autonomous driving systems under hardware faults, and providing important assurance for the safety and reliability of autonomous driving systems.

[0062] In one application scenario, the autonomous driving fault simulation method proposed in this invention is used to simulate and test faults in the context of verifying hardware faults in autonomous driving on urban expressways.

[0063] Figure 2This demonstrates a digital twin hardware closed-loop simulation system with hardware fault injection capabilities. Figure 3 The core architecture and data interaction mechanism of the autonomous driving digital twin simulator were demonstrated from the perspective of hardware-software collaboration.

[0064] like Figure 2 As shown, the autonomous driving digital twin simulator with hardware fault injection capability includes the following modules: Autonomous driving system: Receives virtual sensor data (such as camera images and LiDAR point clouds) from the digital twin simulator, processes it through the internal perception, decision-making, and control modules, and outputs control commands such as steering and acceleration to form a test closed loop.

[0065] Sensor fault injection module: Adds anomalies such as noise, delay, and frame loss to the sensor data layer.

[0066] Hardware fault injection module: simulates faults such as bit flips and parameter deviations in the computing hardware (such as GPU and memory) of autonomous driving systems.

[0067] Sensor simulator: Generates virtual sensor data (images, point clouds) based on input sensor parameters (camera focal length, lidar installation angle).

[0068] Traffic flow simulation and vehicle dynamics model: Complex traffic scenarios are generated by trajectory playback, and high-precision motion simulation is achieved by combining vehicle dynamics model.

[0069] Digital twin map: As a simulation environment base, it constructs a 3D scene based on real road laser point cloud and high-precision map, including accurate road curvature, lane topology and traffic sign coordinates. It renders dynamic lighting and roadside details (such as trees and buildings) through Unreal Engine, and uses LOD technology to optimize real-time rendering efficiency, providing high-fidelity geospatial support for sensor simulation and traffic flow simulation.

[0070] Evaluation and verification module: Real-time monitoring of whether vehicles collide, cross the line, or speed, statistical analysis of path tracking error and response delay, automatic recording of scene parameters (such as traffic density, weather), fault type (such as sensor noise intensity) and system processing logs when failure conditions are triggered, and generation of fault tolerance report through data analysis.

[0071] Specifically, sensor parameters drive the simulator to generate data, which is then perturbed by the fault injection module and input into the autonomous driving system. System control commands drive the vehicle dynamics model to update, and synchronously feed back to the traffic flow simulation, forming a dynamic closed-loop interaction to ensure the real-time performance and authenticity of the test scenario. The collaboration of these modules enables full-chain verification from fault injection to performance evaluation.

[0072] like Figure 3As shown, the autonomous driving system, as an upper-layer application, has a hardware layer containing three levels of computing resources: memory, GPU, and CPU. Memory is responsible for caching raw sensor data (such as images and point clouds), GPU undertakes high-load perception tasks (object detection, semantic segmentation), and CPU executes logical tasks such as localization, decision-making, and path planning.

[0073] The sensing module generates virtual data based on the input sensor parameters (focal length, mounting pose), which is then buffered in memory and transmitted to the perception module for processing.

[0074] In the digital twin simulator, the sensor fault injection module directly intervenes in the data generation chain, injecting salt-and-pepper noise into the image to simulate electromagnetic interference, or modifying the point cloud timestamp to introduce transmission delay. The hardware fault injection module targets the underlying design of the computing hardware, such as monitoring memory access and flipping specific bits to simulate single-event effects, or injecting bias interference into GPU registers for parallel computation. Control commands are fed back from the CPU decision module to the simulator, driving vehicle dynamics models and traffic flow updates, forming a closed-loop verification chain of "data generation - fault injection - control feedback". This architecture achieves full-stack fault simulation capabilities from sensor data distortion to computing hardware anomalies.

[0075] use Figure 2 and Figure 3 The simulation system and interaction mechanism used in the simulation of autonomous driving faults can specifically include the following steps: The first step is to build a high-fidelity digital twin simulation environment.

[0076] Specifically, the construction of the digital twin map involves extracting lane-level geometric structures (radius of curvature ≥ 200m, slope ≤ 5%) and topological relationships (changes in the number of lanes at the connection between the main road and the ramp) based on urban expressway laser point cloud data, and marking traffic signs (coordinates of speed limit 100km / h signs and tidal lane indicator lights).

[0077] Furthermore, Unreal Engine was used to render road surface materials (asphalt reflectivity) and dynamic lighting (simulation of midday sunlight angle), and roadside details (guardrail and green belt models) were added. The real-time rendering frame rate was optimized (≥60FPS) through LOD technology.

[0078] Specifically, the sensor simulator is constructed as follows: Camera simulation: setting intrinsic parameters (focal length 35mm, viewing angle 60°) and extrinsic parameters (installation height 1.8m, orientation angle 0°) to generate an RGB image with HDR lighting variations. LiDAR simulation: configuring 16 beams and a rotation frequency of 10Hz to simulate point cloud attenuation in rainy and foggy weather (achieved by randomly discarding 20% ​​of distant point clouds).

[0079] Specifically, traffic flow and vehicle dynamics modeling: traffic flow simulation: deep reinforcement learning models are used to generate vehicle behavior and simulate typical expressway scenarios (such as continuous lane changes by vehicles merging into ramps and low-speed lane occupation by high-speed trucks).

[0080] Vehicle dynamics model: Construct a nonlinear model that includes engine torque response and suspension damping characteristics, and receive control commands (steering ratio, braking pressure) and feedback vehicle status (yaw rate, wheel speed) through a real-time interface.

[0081] The second step is to establish a closed-loop testing system.

[0082] Specifically, the data interaction design is as follows: the autonomous driving system subscribes to virtual sensor data (images; point clouds) through the ROS interface, processes the data, and then issues control commands (steering angle; throttle); the simulator synchronizes the sensor data timestamps (accuracy ±1ms) through a global clock to ensure consistency with the vehicle dynamics model state update.

[0083] Closed-loop verification scenario: Simulating "ramp merging conflict": Vehicles on the main road are traveling at 80 km / h, and simulated vehicles are merging from the ramp at 40 km / h. The autonomous driving system needs to complete the lane change and avoidance decision within 3 seconds.

[0084] The third step is real-time hardware fault simulation and injection.

[0085] Specifically, sensor-level fault injection includes: Camera fault: Adding salt-and-pepper noise (10% density) to the image to simulate EMC interference; modifying the timestamp at 0.5-second intervals to simulate data transmission delay. LiDAR fault: Randomly discarding 30% of point cloud frames to simulate communication interruption; adding random points (15% of the normal point cloud) to the point cloud to simulate multipath reflection interference. Sensor parameter deviation: Gradually shifting the camera focal length parameter (from 35mm to 38mm) to simulate installation loosening caused by thermal expansion.

[0086] Furthermore, computational hardware fault injection includes: memory bit flipping: monitoring memory access in the autonomous driving system, identifying the Kalman coefficient storage address of the target tracking algorithm in the localization perception module, and flipping the target bit at the 120th second of the simulation (e.g., changing the 5th bit of the floating-point exponent from 0 to 1) to simulate a single-event upset effect. GPU computational errors: injecting register bit errors into the CUDA kernel function of the path planning module, causing local distortion of the planned trajectory.

[0087] The fourth step is real-time monitoring and evaluation verification.

[0088] Specifically, fault trigger monitoring includes: Collision detection: Detecting contact between the autonomous vehicle and merging vehicles using a capsule-shaped collision model in a simulation environment (failure to trigger when collision intensity exceeds a threshold). Violation monitoring: Monitoring behaviors such as vehicle crossing lane lines (wheels exceeding lane lines by 0.5m for 2 seconds) and speeding (vehicle speed ≥ 110km / h).

[0089] Furthermore, performance evaluation metrics include: Error statistics: calculating path tracking error (root mean square deviation of actual trajectory from planned trajectory ≤ 0.3m) and decision response delay (from fault occurrence to obstacle avoidance initiation ≤ 1.2 seconds). Fault coverage: injecting fault types covering 4 major categories and 12 subcategories, including sensor noise, delay, frame loss, and bit flipping, conforming to standard test specification requirements.

[0090] Finally, data recording and analysis: Record the scene parameters when the fault occurred (traffic flow density 30 vehicles / km, visibility 200m in rainy weather), software status (the decision module log shows a "target lost" alarm), and fault handling process (the system switched to the redundant camera and restarted the target tracking algorithm in 1.5 seconds).

[0091] Through the above process, this embodiment of the invention uses an urban expressway autonomous driving system as the verification object, and integrates... Figure 2 Functional modules and Figure 3 This paper constructs a full-stack simulation environment covering sensor data generation, hardware fault injection, closed-loop control, and real-time monitoring by utilizing a hardware-software collaborative data flow. During implementation, complex traffic conflict scenarios are simulated based on high-precision maps and vehicle dynamics models. Typical hardware failure modes such as electromagnetic interference, communication interruption, and single-event effects are reproduced by injecting faults such as sensor noise, data frame loss, and memory bit flips. The monitoring system captures abnormal events such as collisions and violations in real time, and the system's fault tolerance is evaluated based on indicators such as path tracking error and decision delay. Results show that the autonomous driving system can activate a multi-source fusion redundancy mechanism under abnormal sensor data conditions, but when memory bit flips cause algorithm parameter corruption, a hardware watchdog restart is required. This method achieves efficient reproduction and safe verification of hardware faults through digital twin technology, significantly reducing the cost and risk of real-vehicle testing and providing a quantifiable evaluation method for improving the reliability of autonomous driving systems.

[0092] The following are embodiments of the apparatus of the present invention, which can be used to execute the autonomous driving fault simulation method involved in the present invention. For details not disclosed in the embodiments of the apparatus of the present invention, please refer to the method embodiments of the autonomous driving fault simulation method involved in the present invention.

[0093] Please see Figure 4 This invention provides an autonomous driving fault simulation device 800.

[0094] The autonomous driving fault simulation device 800 includes, but is not limited to: a twin map construction module 810, a closed-loop test formation module 830, a fault simulation injection module 850, and a performance detection and evaluation module 870.

[0095] Among them, the twin map construction module 810 is used to construct a three-dimensional digital twin map that supports graphics rendering. It obtains a digital twin simulator and simulation environment by constructing a sensor simulator, a vehicle dynamics model and a traffic flow simulator and integrating them. The three-dimensional digital twin map includes three-dimensional road structure information and traffic element information.

[0096] The closed-loop test formation module 830 is used to form a closed-loop test system by connecting the autonomous driving system as the test object to the simulation environment. The digital twin simulator generates sensor data in real time and outputs it to the autonomous driving system to obtain control commands, driving the simulated vehicle to conduct interactive tests.

[0097] The fault simulation injection module 850 is used to simulate and inject hardware faults in the sensor simulator and autonomous driving system in the simulation environment in real time, and to test the fault tolerance capability of the autonomous driving system to hardware faults; hardware faults include sensor noise, delay, loss, and computational hardware bit flipping.

[0098] The performance detection and evaluation module 870 is used to monitor the performance and behavior of the autonomous driving system in real time. When preset failure conditions are triggered, it records and analyzes the scene parameters, fault types and software status to evaluate the safety and fault tolerance of the autonomous driving system under hardware failure. Failure conditions include collision and violation.

[0099] It should be noted that the autonomous driving fault simulation provided in the above embodiments is only an example of the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed. That is, the internal structure of the autonomous driving fault simulation device will be divided into different functional modules to complete all or part of the functions described above.

[0100] Furthermore, the embodiments of the autonomous driving fault simulation device and the autonomous driving fault simulation method provided in the above embodiments belong to the same concept, and the specific way in which each module performs its operation has been described in detail in the method embodiments, and will not be repeated here.

[0101] Figure 5 A schematic diagram of the structure of an electronic device according to an exemplary embodiment is shown.

[0102] It should be noted that this electronic device is merely an example adapted to the present invention and should not be construed as providing any limitation on the scope of use of the present invention. Furthermore, this electronic device should not be interpreted as requiring or depending on any particular feature. Figure 5One or more components of the exemplary electronic device 2000 shown.

[0103] The hardware structure of electronic devices 2000 can vary significantly due to differences in configuration or performance, such as... Figure 5 As shown, the electronic device 2000 includes: a power supply 210, an interface 230, at least one memory 250, and at least one central processing unit (CPU) 270.

[0104] Specifically, power supply 210 is used to provide operating voltage for various hardware devices on electronic device 2000.

[0105] Interface 230 includes at least one wired or wireless network interface 231 for interacting with external devices. Of course, in other examples adapted to this invention, interface 230 may further include at least one serial-to-parallel conversion interface 233, at least one input / output interface 235, and at least one USB interface 237, etc. Figure 5 As shown, this does not constitute a specific limitation.

[0106] The memory 250 serves as a carrier for resource storage and can be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored on it include the operating system 251, application programs 253, and data 255, etc., and the storage method can be temporary storage or permanent storage.

[0107] The operating system 251 is used to manage and control the various hardware devices and application programs 253 on the electronic device 2000, so as to enable the central processing unit 270 to perform calculations and processing on the massive data 255 in the memory 250. It can be Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0108] Application 253 is a computer-readable instruction based on operating system 251 that performs at least one specific task, and may include at least one module ( Figure 5 (Not shown), each module may contain computer-readable instructions for electronic device 2000. For example, an autonomous driving fault simulation device may be considered as application 253 deployed on electronic device 2000.

[0109] Data 255 may be signal information, etc., and is stored in memory 250.

[0110] The central processing unit 270 may include one or more processors and is configured to communicate with the memory 250 via at least one communication bus to read computer-readable instructions stored in the memory 250, thereby performing operations and processing on massive amounts of data 255 stored in the memory 250. For example, an autonomous driving fault simulation method can be implemented by having the central processing unit 270 read a series of computer-readable instructions stored in the memory 250.

[0111] Furthermore, the present invention can also be implemented through hardware circuits or a combination of hardware circuits and software. Therefore, the implementation of the present invention is not limited to any specific hardware circuit, software, or combination thereof.

[0112] Please see Figure 6 This invention provides an electronic device 4000, which may include: a desktop computer, a laptop computer, a server, etc., with sensor recognition capabilities.

[0113] exist Figure 6 In this context, the electronic device 4000 includes at least one processor 4001 and at least one memory 4003.

[0114] The data interaction between the processor 4001 and the memory 4003 can be achieved through at least one communication bus 4002. This communication bus 4002 may include a path for transmitting data between the processor 4001 and the memory 4003. The communication bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 4002 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0115] Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0116] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0117] The memory 4003 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program instructions or code in the form of instructions or data structures and accessible by the electronic device 4000, but not limited thereto.

[0118] The memory 4003 stores computer-readable instructions, and the processor 4001 can read the computer-readable instructions stored in the memory 4003 through the communication bus 4002.

[0119] The computer-readable instructions are executed by one or more processors 4001 to implement the autonomous driving fault simulation method in the above embodiments.

[0120] Furthermore, this embodiment of the invention provides a storage medium storing computer-readable instructions, which are executed by one or more processors to implement the autonomous driving fault simulation method described above.

[0121] This invention provides a computer program product including computer-readable instructions stored in a storage medium. One or more processors of an electronic device read the computer-readable instructions from the storage medium, load and execute the computer-readable instructions, thereby enabling the electronic device to implement the autonomous driving fault simulation method as described above.

[0122] Compared with related technologies, the beneficial effects of the present invention are: 1. This invention can significantly improve the efficiency and safety of hardware fault verification for autonomous driving systems; by constructing a high-fidelity digital twin simulation environment to simulate real road scenarios and sensor data, it avoids the need for physical reproduction of high-risk hardware faults in real vehicle testing, thereby reducing testing costs and safety hazards.

[0123] 2. This invention has comprehensive hardware fault coverage capabilities; through the synergistic effect of sensor fault injection modules (such as noise, delay, and frame drop simulation) and hardware fault injection modules (such as memory bit flipping and GPU computation error simulation), typical hardware failure modes such as electromagnetic interference, communication interruption, and single-event effects can be reproduced, ensuring that the test covers the entire abnormal scenario from the sensor to the computing unit.

[0124] 3. This invention realizes closed-loop dynamic verification and real-time response analysis; by connecting the autonomous driving system to the simulation environment to form a data closed loop, the system control commands directly drive the simulated vehicle to interact with traffic flow, which can verify the dynamic response capability of the perception-decision-control link under hardware failure in real time, and accurately evaluate key indicators such as decision delay and trajectory tracking error.

[0125] 4. This invention supports highly controllable fault reproduction and parameterized debugging; through the modular design of the digital twin simulator, fault types (such as sensor noise intensity, bit flip position) and scene parameters (such as traffic density, weather conditions) can be flexibly adjusted to quickly locate the failure boundary of the system's fault tolerance mechanism and accelerate algorithm iteration and optimization.

[0126] 5. This invention has automated evaluation and data traceability capabilities; by monitoring failure conditions such as collisions and violations in real time, it automatically records failure scenarios, system status and processing logs, and generates fault tolerance reports by combining data analysis, providing quantitative basis for system optimization and improving development efficiency.

[0127] 6. This invention enhances the depth of system reliability verification in complex scenarios; through high-precision rendering of 3D digital twin maps (dynamic lighting, LOD optimization) and traffic flow simulation (deep reinforcement learning-driven vehicle / pedestrian behavior), it simulates extreme conditions such as rain, fog, and high-density traffic to verify the system robustness under the coupling of hardware failure and complex environment.

[0128] 7. This invention achieves an innovative architecture for hardware-software collaborative verification; by separating sensor fault injection and computational hardware fault injection paths, the fault tolerance performance of software and hardware modules can be verified independently or in combination, the scope of fault impact can be accurately located, and the redundancy design strategy can be optimized.

[0129] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0130] The above description is only a partial embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for simulating autonomous driving faults, characterized in that, The method includes: A 3D digital twin map supporting graphics rendering is constructed by building and integrating a sensor simulator, a vehicle dynamics model, and a traffic flow simulator to obtain a digital twin simulator and simulation environment; the 3D digital twin map includes 3D road structure information and traffic element information; By connecting the autonomous driving system as the test object to the simulation environment to form a closed-loop test system, the digital twin simulator generates sensor data in real time and outputs it to the autonomous driving system to obtain control commands, driving the simulated vehicle to conduct interactive tests. Hardware faults are simulated and injected in real time on the sensor simulator and autonomous driving system in the simulation environment to test the fault tolerance capability of the autonomous driving system to hardware faults; the hardware faults include sensor noise, delay, loss, and computational hardware bit flipping. The system monitors the performance and behavior of the autonomous driving system in real time. When preset failure conditions are triggered, it records and analyzes the scene parameters, failure types, and software status to evaluate the safety and fault tolerance of the autonomous driving system under hardware failure. The failure conditions include collision and violation.

2. The autonomous driving fault simulation method as described in claim 1, characterized in that, The construction of a 3D digital twin map that supports graphics rendering includes: The road geometry, lane topology, and traffic sign locations are extracted from real road data, and semantic annotation is performed using GIS tools to obtain map data. The road data includes laser point clouds and high-precision map data. The geometric structure includes curvature and slope. The lane topology includes solid and dashed lines and the number of lanes. The traffic sign locations include speed limit signs and traffic light coordinates. The map data is converted into a 3D mesh model using the engine's rendering pipeline, and dynamic lighting, material maps, and detailed elements are added; the engine includes Unreal Engine and Unity engine; the detailed elements include roadside trees and buildings.

3. The autonomous driving fault simulation method as described in claim 1, characterized in that, The process of constructing and integrating a sensor simulator, a vehicle dynamics model, and a traffic flow simulator to obtain a digital twin simulator and simulation environment includes: A sensor simulator is constructed based on the internal and external parameters of the sensors; the sensors include cameras and lidar; the internal parameters include focal length and viewing angle; the external parameters include installation location and orientation. A vehicle dynamics model covering longitudinal, lateral, and vertical kinematic characteristics is constructed using vehicle dynamics simulation software, and interacts with the simulation environment through a real-time interface; the control commands include throttle opening and steering angle; Based on trajectory playback or deep reinforcement learning algorithms, vehicle behavior and pedestrian behavior are generated; the vehicle behavior includes simulated following, lane changing, and overtaking; the pedestrian behavior includes crossing the road and avoiding obstacles.

4. The autonomous driving fault simulation method as described in claim 1, characterized in that, The method involves connecting the autonomous driving system as the test object to the simulation environment to form a closed-loop test system. The digital twin simulator generates sensor data in real time and outputs it to the autonomous driving system to obtain control commands, driving the simulated vehicle to perform interactive testing. This includes: The autonomous driving system is connected to the simulation environment as the test object, and data interaction is carried out through a standardized interface. The digital twin simulator generates sensor data in real time based on the vehicle dynamics model and the state of the traffic flow simulator. The sensor data is fused into a perception input through spatial and temporal alignment. The simulated vehicle updates its state according to the control commands of the autonomous driving system, while generating new sensor data to feed back to the autonomous driving system and recording the system state through logs. The system state includes sensor data, control commands, and vehicle trajectory.

5. The autonomous driving fault simulation method as described in claim 1, characterized in that, The real-time simulation and injection of hardware faults into the sensor simulator and autonomous driving system in the simulation environment, and the testing of the autonomous driving system's fault tolerance capability to hardware faults, include: Gaussian noise or salt-and-pepper noise is added to the camera image to simulate sensor electronic interference; random points are added to the radar point cloud to simulate multipath reflection; the timestamp of the sensor data is modified to simulate data transmission or processing delay; sensor data frames are dropped in a probabilistic manner to simulate communication interruption or hardware failure; and sensor intrinsic and extrinsic parameters are modified to simulate parameter changes caused by mechanical vibration or thermal stress. The intrinsic and extrinsic parameters include the camera focal length and the radar installation angle. The system simulates radiation effects on key computing modules of the autonomous driving system, monitors memory or register access of the autonomous driving system, locates key data structures, simulates memory errors by flipping target bits at a preset probability at a specified time point, and observes the autonomous driving system's handling of erroneous data; the handling includes error detection and fault-tolerant recovery.

6. The autonomous driving fault simulation method as described in claim 1, characterized in that, The real-time monitoring of the performance and behavior of the autonomous driving system includes: The simulation environment is used to detect collisions to determine whether the autonomous vehicle comes into contact with other objects, monitor whether the vehicle crosses the line, speeds, or violates traffic signals, and calculate error indicators. If the error indicators exceed the threshold, the system will fail. The error indicators include path tracking error and response delay. The system status is acquired in real time through the API or ROS node of the simulation environment, time series data is recorded, the system is judged in real time according to the failure conditions, and the monitoring results are displayed through a visual interface; the time series data includes sensor data, control commands, and vehicle trajectory.

7. The autonomous driving fault simulation method as described in claim 1, characterized in that, The process of recording and analyzing scenario parameters, fault types, and software states to evaluate the safety and fault tolerance of the autonomous driving system under hardware failures includes: Automatically record relevant data; the relevant data includes scene parameters, fault types, and software status; the scene parameters include traffic flow density, road curvature, and weather conditions; the fault types include sensor noise intensity, bit flip position, and delay time; the software status includes decision logs and error handling mechanisms. By using data analysis tools to statistically analyze fault indicators and generate test reports, the safety and fault tolerance of the autonomous driving system under hardware failures are evaluated, providing a basis for system optimization. The fault indicators include fault trigger frequency, time from fault occurrence to system recovery, and the proportion of hardware failure modes covered by the test scenario.

8. An autonomous driving fault simulation device, characterized in that, The device includes: The twin map construction module is used to build a three-dimensional digital twin map that supports graphics rendering. It obtains a digital twin simulator and simulation environment by building a sensor simulator, a vehicle dynamics model, and a traffic flow simulator and integrating them. The three-dimensional digital twin map includes three-dimensional road structure information and traffic element information. The closed-loop test formation module is used to form a closed-loop test system by connecting the autonomous driving system as the test object to the simulation environment. The digital twin simulator generates sensor data in real time and outputs it to the autonomous driving system to obtain control commands, driving the simulated vehicle to perform interactive tests. The fault simulation injection module is used to simulate and inject hardware faults into the sensor simulator and autonomous driving system in the simulation environment in real time, and to test the fault tolerance capability of the autonomous driving system to hardware faults; the hardware faults include sensor noise, delay, loss, and computational hardware bit flipping. The performance detection and evaluation module is used to monitor the performance and behavior of the autonomous driving system in real time. When a preset failure condition is triggered, it records and analyzes the scene parameters, fault type and software status to evaluate the safety and fault tolerance of the autonomous driving system under hardware failure. The failure conditions include collision and violation.

9. An electronic device, characterized in that, include: At least one processor and at least one memory, wherein, The memory stores computer-readable instructions; The computer-readable instructions are executed by one or more of the processors, causing the electronic device to implement the autonomous driving fault simulation method as described in any one of claims 1 to 7.

10. A storage medium having computer-readable instructions stored thereon, characterized in that, The computer-readable instructions are executed by one or more processors to implement the autonomous driving fault simulation method as described in any one of claims 1 to 7.

Images