A hardware-in-the-loop automatic driving model vulnerability mining method and system

Abstract

The present application relates to the technical field of automatic driving model test verification, and is a hardware-in-the-loop automatic driving model vulnerability mining method and system, specifically comprising: in the hardware-in-the-loop closed loop operation, through the non-invasive probe deployed in the tested chip, the neuron activation features of the model hidden layer are extracted, and the cognitive uncertainty index is calculated; when the uncertainty exceeds the threshold value, the physical parameters such as illumination, weather, shielding and target geometric shape are dynamically adjusted, and the targeted adversarial negative sample scene is generated; in the scene evolution process, the algorithm output, the model internal state and the chip hardware state are monitored synchronously, the failure reason is determined through multidimensional comparison, and the vulnerability is classified into algorithm logic weakness, quantization precision weakness or hardware performance weakness. The present application carries out active exploration based on cognitive driving, realizes efficient and accurate mining of model vulnerability and finding of software and hardware coupling failure, and is especially suitable for algorithm robustness evaluation of domestic heterogeneous computing platforms.

Description

Technical Field

[0001] This invention relates to the field of autonomous driving model testing and verification technology, and is a hardware-in-the-loop method and system for identifying vulnerabilities in autonomous driving models. Background Technology

[0002] As autonomous driving technology evolves to higher levels, end-to-end models integrating perception, decision-making, and control are gradually becoming mainstream. These models are typically deployed on heterogeneous computing platforms such as GPUs and NPUs, and their internal decision-making logic is highly opaque, exhibiting black-box characteristics. Ensuring their safety in edge computing scenarios is a core challenge facing the industry.

[0003] Hardware-in-the-loop (HIL) simulation testing is currently the mainstream method for verifying autonomous vehicle controllers, but existing solutions have the following drawbacks: First, the test scenarios are static and passive, heavily reliant on pre-recorded data playback or static scripts. They cannot adjust test strategies based on the model's real-time internal operating state, making it difficult to systematically reach edge failure conditions within the black box, resulting in low efficiency and insufficient coverage in uncovering long-tail problems. Second, there is a lack of feedback mechanisms at the model's cognitive level. Existing technologies only observe deviations in the final output, such as trajectory tracking accuracy, completely lacking the logical dimension of actively testing using the model's inherent cognitive characteristics, such as neuron activation anomalies and information entropy fluctuations. Third, locating hardware-software coupling vulnerabilities is difficult. Coupling vulnerabilities introduced during model deployment due to compiler optimization, operator quantization, memory bandwidth limitations, and power management make it impossible to distinguish between algorithmic logic weaknesses and hardware implementation weaknesses, especially lacking targeted verification methods for the adaptability to the unique architecture of domestically produced chips. Summary of the Invention

[0004] The purpose of this section is to outline some aspects of embodiments of the present invention and to briefly describe some preferred embodiments. Simplifications or omissions may be made in this section, as well as in the abstract and title of this application, to avoid obscuring the purpose of these documents; however, such simplifications or omissions should not be construed as limiting the scope of the invention.

[0005] To overcome the technical problems existing in the prior art as pointed out in the background art, the present invention provides a hardware-in-the-loop vulnerability mining system for autonomous driving models, comprising the following modules: The hardware-in-the-loop simulation unit is used to run the vehicle dynamics model and virtual environment in real time and provide sensor simulation data to the computing chip under test; A non-invasive neuron probe unit is deployed in the computing chip under test. It is used to extract the neuron activation feature vectors of the autonomous driving model under test in at least one hidden layer in real time during the hardware-in-loop closed-loop operation. The extraction is performed by direct memory access mirror output without changing the main computing path of the model. An uncertainty assessment unit is used to receive the neuron activation feature vector and calculate an index reflecting the cognitive uncertainty of the model based on the feature vector. A digital twin engine, connected to the uncertainty assessment unit, is used to dynamically adjust the physical parameters of the virtual scene according to the cognitive uncertainty index, generate adversarial negative sample scenes, and provide the updated scenes to the hardware-in-the-loop simulation unit. The vulnerability analysis and diagnosis module is used to simultaneously monitor the algorithm output, the internal state of the model, and the hardware state of the tested computing chip during the adversarial negative sample injection process. By comparison, the cause of failure is determined, and the vulnerability is classified into at least one of the following: algorithm logic weakness, quantization accuracy weakness, and hardware performance weakness.

[0006] In addition, the technical solution of the hardware-in-the-loop autonomous driving model vulnerability mining method of the present invention includes the following steps: S1. State perception: The non-invasive neuron probe unit is used to extract the neuron activation feature vector of the tested model in the target hidden layer in real time. S2. Uncertainty assessment: Based on the neuron activation feature vector, calculate the cognitive uncertainty index that reflects the uncertainty of the model's current semantic understanding. When the index meets the preset triggering conditions, proceed to step S3. S3. Environmental Evolution: Input the cognitive uncertainty index into the digital twin engine, query the preset mapping rule base, dynamically adjust the physical environment parameters in the virtual scene, generate targeted adversarial negative sample scenarios in real time, and update the hardware-in-the-loop simulation environment. S4. Vulnerability Identification and Diagnosis: Under the adversarial scenario, algorithm output data, model internal cognitive state data, and chip hardware state data are collected simultaneously. When a failure event is detected, the failure cause is determined by comprehensively comparing the three types of data to be due to weaknesses in algorithm logic, quantization accuracy, or hardware performance.

[0007] Preferably, in step S2, the calculation of the cognitive uncertainty index includes: The attention weight matrix is ​​extracted from the neuron activation feature vector, and the attention divergence index is calculated based on the query dimension information entropy of each attention head in the matrix. Feature maps are extracted from the neuron activation feature vectors, the feature maps are flattened in the spatial dimension, and the trace of the covariance matrix between feature vectors of different channels is calculated to obtain the feature disorder index. The attention divergence index and the feature confusion index are weighted and fused to obtain a comprehensive cognitive uncertainty index.

[0008] Preferably, in step S3, the mapping rule base stores multiple rules, and each rule specifies the type and adjustment range of physical parameters to be adjusted based on the numerical range and trend of the cognitive uncertainty index; the type of physical parameter includes one or more of the following: light intensity and angle, meteorological particle concentration, target object occlusion ratio, and target object geometric deformation.

[0009] Preferably, in step S4, the vulnerability determination and diagnosis further includes: If the chip hardware is in normal condition at the time of failure, but the cognitive uncertainty inside the model spikes and this spike is related to the geometric configuration or texture pattern of a specific scene, then it is determined to be a weakness in the algorithm logic. If, under the same input, the full-precision reference model outputs normally while the quantization model outputs incorrectly, and the feature map weight values ​​at the time of failure are concentrated in the range of values ​​below the quantization step size, then it is determined to be a weakness in quantization precision. If, at the moment of failure, the chip power consumption increases, triggering frequency reduction and causing the inference delay to exceed the hardware-in-the-loop simulation step size, then it is determined to be a hardware performance weakness.

[0010] Preferably, the non-invasive neuron probe unit is implemented as follows: during the offline compilation stage of the autonomous driving model under test, a monitoring operator is inserted after each target hidden layer. The monitoring operator is configured to use the chip's direct memory access channel to transmit the output activation tensor image of the hidden layer to the main control computer.

[0011] Preferably, in step S1, the target hidden layer includes a BEV feature fusion layer and a trajectory prediction multi-head attention layer; the output of the BEV feature fusion layer is used to calculate feature disorder, and the output of the trajectory prediction multi-head attention layer is used to calculate attention divergence.

[0012] Preferably, in step S4, the synchronously acquired algorithm output data includes target trajectory prediction, vehicle control commands, and attitude information fed back by the vehicle dynamics model; the model's internal cognitive state data includes attention divergence, feature confusion, and comprehensive cognitive uncertainty index; and the chip hardware state data includes chip real-time power consumption, core clock frequency, junction temperature, inference frame rate, and single-frame inference latency.

[0013] Preferably, in step S4, the detection conditions for the failure event include: the vehicle control command exceeds the preset safety boundary, the cumulative error of the target trajectory prediction exceeds the threshold and continues for a preset duration, or the end-to-end inference delay exceeds the hardware-in-the-loop simulation step size.

[0014] Preferably, in step S4, the detection conditions for the failure event include: the vehicle control command exceeds the preset safety boundary, the cumulative error of the target trajectory prediction exceeds the threshold and continues for a preset duration, or the end-to-end inference delay exceeds the hardware-in-the-loop simulation step size.

[0015] Preferably, the hardware-in-the-loop autonomous driving model vulnerability mining method of the present invention further includes: according to the vulnerability classification results, counting the number of each type of vulnerability and sorting them by severity, and generating a graded diagnostic report including failure timestamp, failure type, triggering scenario parameters and diagnostic suggestions.

[0016] Compared with the prior art, the technical effects of the present invention are as follows: 1) Improved testing efficiency: By directly guiding the generation of long-tail scenarios through internal cognitive feedback of the algorithm, vulnerability mining is realized, which can improve the mining efficiency of high-risk edge conditions.

[0017] 2) Enhanced model interpretability: In chip-level hardware-in-the-loop testing, the model's cognitive boundaries and moments of confusion are accurately located and quantitatively described by using the observable physical quantity of neuron states.

[0018] 3) Enhance the stability of domestic hardware adaptation: Design hardware probes and diagnostic logic specifically for non-standard operators, unique quantization strategies and dynamic frequency modulation mechanisms of domestic heterogeneous computing platforms (such as NPU, DSP, etc.), which can effectively expose and distinguish systemic security risks caused by software and hardware coupling, and provide guidance for the algorithm adaptation and optimization of domestic chips in the field of autonomous driving. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a schematic diagram of the structure and signal flow of a hardware-in-the-loop autonomous driving model vulnerability mining system according to the present invention. Figure 2 This is a schematic diagram of the logic flow of a hardware-in-the-loop vulnerability mining method for autonomous driving models according to the present invention. Detailed Implementation

[0020] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0021] Many specific details are set forth in the following description in order to provide a full understanding of the invention. However, the invention may also be practiced in other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of the invention. Therefore, the invention is not limited to the specific embodiments disclosed below.

[0022] Secondly, the term "one embodiment" or "example" as used herein refers to a specific feature, structure, or characteristic that may be included in at least one implementation of the invention. An embodiment appearing in different places in this specification does not necessarily refer to the same embodiment, nor is it a single or selective embodiment that mutually excludes other embodiments.

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0024] It should be noted that the terms "first," "second," etc., in the specification and claims of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0025] In this invention, hardware-in-the-loop refers to connecting the autonomous driving computing platform under test (i.e., the computing chip under test and the autonomous driving model running on it) to a real-time simulation system, whereby the real-time simulation system provides a virtual vehicle dynamics model and an environment model, forming a closed-loop testing system of real controller, virtual vehicle and environment.

[0026] Digital twins refer to the construction of a highly consistent and interactive digital scene model in virtual space that is identical to the real physical world. It can dynamically adjust parameters such as lighting, weather, roads, and target objects according to instructions.

[0027] Cognitive uncertainty refers to an indicator quantified from the internal activation patterns of a neural network model, reflecting the degree of uncertainty of the model's semantic understanding of the current input scene. It is different from apparent uncertainty, which is characterized only by the deviation of the final output trajectory.

[0028] This invention non-invasively acquires the internal neuron-level activation features of a model deployed in the computing chip under test during the inference process, quantifies its cognitive uncertainty in real time, and feeds this uncertainty back to the digital twin engine, driving it to generate an adversarial scenario that maximizes this uncertainty. During the continuous evolution of this scenario, the algorithm output, the internal state of the model, and the chip hardware state are monitored simultaneously. Finally, through multi-dimensional data comparison, the failure cause is determined and classified as a weakness in the algorithm logic, a weakness in quantization accuracy, or a weakness in hardware performance.

[0029] Example 1: like Figure 1 As shown in the figure, a hardware-in-the-loop vulnerability mining system for autonomous driving models according to an embodiment of the present invention includes: The hardware-in-the-loop simulation unit is used to run the vehicle dynamics model and virtual environment in real time; the computing chip under test (in this example, a domestic NPU chip) is deployed with the integrated BEV perception and decision-making model under test; the neuron probe unit is embedded in the firmware of the computing chip under test and is used to non-invasively collect hidden layer activation features; the uncertainty assessment unit is deployed on the main control computer and is used to calculate cognitive uncertainty indicators; the digital twin engine is used to render and generate virtual scenes in a highly dynamic manner according to mapping instructions; and the vulnerability analysis and diagnosis module is used to perform vulnerability analysis and generate a graded diagnostic report.

[0030] Example 2: This embodiment of a hardware-in-the-loop autonomous driving model vulnerability discovery method includes four main steps: S1, state perception; S2, uncertainty assessment; S3, environmental evolution; and S4, vulnerability identification and diagnosis. These four steps are not executed all at once, but rather form a continuous closed-loop iteration until the test termination conditions are met (such as reaching a preset test duration, covering a specified number of vulnerability categories, or termination by an external command). The specific implementation of each step is described in detail below.

[0031] S1. During the closed-loop operation of the hardware, non-invasive hardware probes deployed in the computing chip under test are used to extract the neuron activation feature vectors in the hidden layer of the neural network model under test in real time. The input for this step is the intermediate tensor data generated by the target hidden layer during the model inference process. The intermediate tensor data is mirrored and output without changing the execution path of the original computation graph using the direct memory access mechanism. The output is a feature data package that can represent the internal cognitive state of the model and has layer identifiers and timestamps.

[0032] For example, in this embodiment, the object under test is a BEV perception and decision-making integrated model based on the Transformer architecture. This model is deployed on a domestic NPU chip, and its compiled computation graph is executed on the dedicated computing unit of the NPU.

[0033] To achieve non-intrusive feature extraction, monitoring operators need to be embedded during the computational graph compilation phase of the model. Specifically, this step further includes the following sub-steps: S11. Based on the structural characteristics of the model under test and the analysis of the model's cognitive process, select one or more hidden layers that can reflect the intermediate state of the model's understanding of the semantics of the environment as the target layer for feature extraction.

[0034] In this embodiment, two key layers are selected: the first is the BEV feature fusion layer, which converts multi-view image features into unified spatial features from a bird's-eye view, and its output feature map size is [size missing]. The first layer reflects the model's comprehensive understanding of the global scene layout and static road elements; the second layer is the trajectory prediction multi-head attention layer, located in the model's decision output section. Its output contains attention weight matrices for multiple attention heads, with a size of [missing information]. This can reflect the degree of attention the model pays to spatial relationships when making future trajectory predictions.

[0035] It should be noted that the reason for choosing these two layers is that the disorder in the BEV feature fusion layer usually corresponds to uncertainty at the perceptual level, while the divergence of the attention weight matrix corresponds to uncertainty at the decision-making level. The combination of the two can comprehensively characterize the cognitive state of the model. It should be understood that, depending on the specific structure of the model being tested, other layers can also be selected, such as the self-attention layer in the encoder, the output of a certain level of the feature pyramid, or the pulse firing layer based on a spiking neural network. Any layer that can reflect the intermediate expression state of the model can be used as the target hidden layer.

[0036] S12. During the offline compilation stage of the model, a DataMirror operator that only performs data copying and DMA transfer configuration is inserted after each target hidden layer. The activation values ​​are mirrored and output using the chip's DMA channel, aiming to achieve the technical effect of occupying main computing resources without changing the original data flow.

[0037] During the offline compilation phase of the model, a custom DataMirror operator is inserted after each target hidden layer determined in S11, using the compiler plugin interface or debugging tool interface provided by the NPU vendor. This operator exists as an independent operator node in the compiled computation graph, but its operation does not participate in tensor arithmetic operations on the main computation path of the model; it is only responsible for configuring data copying and DMA transfer.

[0038] Specifically, the monitoring operator works as follows: after the upstream hidden layer completes its computation, the output tensor data is simultaneously transmitted along two paths. One is the original main computation path, which sends the tensor to the next layer operator. The other is a bypass path, where the DataMirror operator receives a read-only reference to the tensor and triggers the DMA controller integrated within the NPU. The DMA controller is responsible for directly moving the complete data block of the tensor from the NPU's computational memory area to a shared buffer that communicates with the host computer, without occupying the computational resources of the NPU's main computational units (such as matrix multiply-accumulate units or vector processing units), nor changing the data flow timing and values ​​of the main computational path.

[0039] After a single DMA transfer is completed, the monitoring operator releases the reference and waits for the next inference cycle to be triggered.

[0040] It's important to note that the key to this non-intrusive implementation lies in utilizing the chip's existing DMA channels and hardware probe capabilities without introducing additional computational latency. The method of implanting the monitoring operator can be adaptively adjusted for different types of computing chips under test: for example, if the chip under test is a GPU, an asynchronous memory copy operation can be inserted after the target layer using CUDA streams or OpenCL user events, such as by calling the cudaMemcpyAsync function to copy the feature map to a pageable, lockable memory region; if the chip under test is a neuromorphic chip or a spiking neural network chip, the spiking count of a specified neuron group within a unit time window can be directly read through the chip's provided monitoring interface, such as the ARMCoreSight debug interface or the chip's custom monitoring bus.

[0041] Regardless of the hardware platform, the common requirement is that the extraction operation must not change the computational results of the model inference, and the impact on the real-time performance of inference should be controlled within the allowable range of the hardware-in-the-loop simulation step size. In this embodiment, by setting the priority of DMA transfer slightly lower than the priority of the computation task and appropriately increasing the depth of the shared buffer (e.g., using a multi-buffering mechanism), it is ensured that even with a large amount of feature tensor data, real-time feature image extraction can be stably performed at a frame rate of 25 FPS without causing frame rate jitter in the main inference task.

[0042] S13. The original tensor data mirrored to the shared buffer by DMA is added with timestamps and layer identifiers according to the inference cycle, organized into a feature data packet with a unified format, and transmitted to the host computer through the PCIe high-speed interface.

[0043] Specifically, when configuring DMA transfer, the DataMirror operator mirrors the output tensor of the target hidden layer according to the original data format (such as the integer form after float16 or int8 quantization).

[0044] Since DMA transfers typically require contiguous physical addresses, when tensor data is stored non-contiguously in memory, the NPU will automatically reassemble the data or transfer it in blocks during runtime.

[0045] After the image data enters the shared buffer, it is polled by the host computer or read via interrupt through the PCIe high-speed interface.

[0046] After receiving the original feature tensor of each frame, the main control computer timestamps and identifies the data from different target layers, organizes them into a unified feature data packet, and passes it to S2 as the final output of this step S1 for uncertainty assessment.

[0047] In this feature data package, the BEV feature map retains its original four-dimensional tensor form. The attention weight matrix maintains a three-dimensional tensor form. .

[0048] The processes S11 to S13 above correspond to Figure 2 The initial step S1 of the process extracts the feature vector, which is obtained from the domestically produced chip under test via... Figure 1 The signal is transmitted from the chip on the left side to the central hardware-in-the-loop simulation unit and the main control computer.

[0049] It should be noted that feature extraction can be triggered based on the synchronous clock of the hardware-in-the-loop simulation, i.e., extraction is triggered once per simulation step, or an event-driven approach can be adopted, such as triggering high-frequency extraction when the target detection confidence is lower than a threshold, in order to reduce the data transmission load in normal scenarios. In this embodiment, the synchronous clock approach is used, and a complete feature vector of one frame is extracted every 40ms (corresponding to 25FPS).

[0050] S2. Process the neuron activation feature vector extracted in step S1, quantify the high-dimensional activation pattern into a scalar index that reflects the degree of cognitive uncertainty of the model, and compare it with a preset trigger threshold to determine whether to enter the scene evolution stage. Specifically, in step S21, the attention weight matrix of the trajectory prediction multi-head attention layer is extracted from the feature data packet. The information entropy of each attention head in the query sequence dimension is calculated and averaged to obtain the attention divergence index, which reflects the degree of attention focus in the model's decision-making. .

[0051] The attention weight matrix of the trajectory prediction multi-head attention layer is extracted from the feature data packets received from S1, and its size is... These correspond to 12 attention heads, each receiving one. The attention weight matrix represents the distribution of attention weights of each position in the query sequence to all other positions.

[0052] For any attention head Its attention weight matrix is ​​defined as follows ,in Indicates position Position Attention weights, satisfying .

[0053] Calculate the information entropy of this attention head for each row (i.e., each query position): ; in For the sequence length, in this example... ; For a very small positive number (such as ), to prevent taking the logarithm of zero.

[0054] The higher the information entropy, the more uniform the weight distribution of the attention head, meaning that the focus of attention is more scattered when the model is making trajectory predictions, and no clear key attention area is formed.

[0055] Conversely, the lower the entropy value, the more attention is focused on a few key locations, and the more confident the model is in understanding the semantics of the environment.

[0056] After obtaining the information entropy of the 12 attention heads, their arithmetic mean is calculated to obtain the attention divergence index. : This metric reflects the overall level of attention the model focuses when making future trajectory decisions.

[0057] For example, based on actual tests in a typical urban straight road scenario, when there are no distractions in front of the vehicle and the lane lines are clear, Usually between arrive Between; and when multiple irregularly moving targets, mutual obstruction, or abnormal traffic participants (such as non-motorized vehicles traveling in the wrong direction) appear, It will rise sharply to The above indicates that the internal state of the model has shifted from deterministic to highly uncertain.

[0058] As an alternative, the maximum or median of the information entropy of each head can be used as an indicator of attention divergence. For example, the attention divergence index can be... Defined as the maximum value of the information entropy of all attention heads, i.e. To more sensitively capture the extreme divergence state of individual attention heads, or to further introduce a weighting mechanism to assign higher weights to attention heads that are closer to the final output in the model structure.

[0059] S22. Flatten the output feature map of the BEV feature fusion layer in spatial dimension, and calculate the trace of the covariance matrix between the feature vectors of different channels as an indicator of the degree of disorder in the intermediate feature representation of the model. Or its logarithmic form.

[0060] Extract the output feature map of the BEV feature fusion layer from the feature data packet received from S1, with a size of [size missing]. That is, 256 channels, each channel has Spatial characteristics.

[0061] Transform the four-dimensional tensor into a two-dimensional matrix Its shape is That is, 256 feature vectors of length 40,000, each vector describing the activation mode of the corresponding channel in the entire BEV space.

[0062] Calculate the covariance matrix among these 256 eigenvectors. , dimension Covariance matrix This reflects the linear correlation between different channel activation modes.

[0063] When the model has a clear and confident semantic segmentation of the scene, only a few channels specifically used to represent the current road element categories (such as lane lines, road surface, and vehicles) are strongly activated, while most channels unrelated to the current scene maintain low activation values. Therefore, the off-diagonal elements of the covariance matrix have small amplitudes, the matrix has a low rank, and the energy is concentrated on a few eigenvalues.

[0064] Conversely, when the model encounters visual textures that it has never learned before, that are contradictory, or that are ambiguous, multiple unrelated channels may be abnormally activated simultaneously, leading to increased correlation between channels and a significant increase in the trace (total variance) of the covariance matrix.

[0065] Based on the above, calculate the feature disorder index. : ; in Indicates the first The feature vectors of each channel.

[0066] It should be noted that, The higher the value, the noisier and more uncertain the model's intermediate feature representation. For example, when driving on a normal dry asphalt road surface, At a low level (typical value in) (on the order of magnitude); however, when there are large areas of oil stains, snow cover, or abnormal specular reflections on the road surface, multiple channels are non-specifically activated. Will leap The range is on the order of magnitude. To prevent excessively large differences in the numerical range from affecting subsequent comprehensive indicators, it is also possible to... Take the logarithm, that is .

[0067] S23. Weighted fusion of attention divergence and feature confusion indices yields a comprehensive cognitive uncertainty. and compare it with the preset trigger threshold. In comparison, when If the model enters a state of cognitive uncertainty, it will trigger scenario evolution; otherwise, it will return to S1 to continue monitoring.

[0068] By weighting and fusing the two single-dimensional indicators obtained from S21 and S22, we obtain a comprehensive cognitive uncertainty. .

[0069] In this embodiment, the following is defined: ; in and Let be the weighting coefficient, satisfying This is used to adjust the relative importance of the two types of uncertainty sources. and The default values ​​are all In practical applications, the weights can be adjusted according to the focus of the development phase. For example, an automated weight determination method involves assigning weights to labeled datasets of confused and normal scenarios. and Using scene type as a label as a feature, a logistic regression classifier is trained, and the weights... and This refers to the feature weights learned by the classifier.

[0070] For some cases where only a single dimension of diagnosis is needed, it can be used independently. or As an indicator of uncertainty, the corresponding weight can be set to... The other weight is set to Comprehensive understanding of uncertainty The value range is usually in arrive Between (through log normalization or by directly truncating the original value), The closer The higher the level of confusion the model has with the current input scenario, the more confused it is.

[0071] As an alternative, uncertainty assessment can also employ other metrics. For example, for spiking neural network models, the coefficient of variation of neuron spiking density within a given time window can be calculated; for models using Bayesian neural networks, the variance of the output distribution can be calculated through multiple forward propagations using Monte Carlo Dropout; and for models using mixed-density networks, the variance term of the output can be directly obtained. What all these metrics have in common is that they are derived directly from the model's internal expression, rather than from the final behavioral output.

[0072] This step S2 corresponds to Figure 2 The S2 calculation of information entropy value in the box determines whether the threshold is exceeded. It compares the uncertainty index with the preset trigger threshold to decide whether to enter the scene evolution step.

[0073] For example, the threshold can be selected through small-sample calibration before the experiment, such as selecting 50 edge scenarios known to cause failure and calculating their corresponding thresholds. The value is used as the initial threshold, with the lower quartile selected, and subsequently adjusted online adaptively based on testing efficiency. In this embodiment, the trigger threshold is set to... .when At that time, it was believed that the current scenario was still within the comfort zone of the model's processing capabilities, and the process continued... Figure 2 The return path on the right re-enters S1, extracts the feature vector for the next time step, and continues monitoring; when At this point, the model is determined to have entered a state of cognitive uncertainty, and the process proceeds down the path to S3.

[0074] S3. Feed the cognitive uncertainty index and its temporal characteristics obtained in S2 back to the digital twin engine. By querying the preset cognitive uncertainty-physical parameter mapping rule library, generate and issue scene adjustment parameters to dynamically change the physical attributes such as lighting, weather, occlusion and target shape in the virtual environment, and generate adversarial negative sample scenarios that maximize model cognitive confusion in real time. Specifically, this step further includes: S31. Extract current and historical uncertainty features, query the preset rule base in the mapping decision-maker, and according to... Conditions such as value range, rate of change, and duration are used to match corresponding adversarial environment adjustment actions.

[0075] The uncertainty assessment unit determines the outcome based on the results of S2. Once the trigger threshold is reached or exceeded, not only will the current value be output. The value is also output. Time series features, such as recent Each step Rate of change of value , At a high level ( The duration of (etc.).

[0076] These features are fed into a mapping decision engine, which maintains a rule base for mapping cognitive uncertainty to physical parameters. It should be noted that this rule base was formed through prior statistical analysis of numerous failure scenarios and offline evaluation of the cognitive characteristics of the tested model. Its basic logic is to associate the feature patterns of uncertainty indicators with the types of physical disturbances that can exacerbate that uncertainty.

[0077] The mapping rule base can be implemented in tabular or decision tree form. The condition part of each rule consists of the range and trend of uncertainty indicators, while the action part specifies one or more physical parameters that need to be adjusted in the digital twin engine, as well as their adjustment direction and magnitude.

[0078] In this embodiment, example rules include: Rule 1: If and This triggers a mild adversarial evolution, increasing the occlusion ratio of the main target vehicle in the scene beyond its current level. And add to the side of the road A static interference object.

[0079] Rule 2: If And the current scene light intensity exceeds This triggers a moderate counter-evolution, gradually reducing the solar azimuth angle, causing the main target to enter the backlight region, and simultaneously reducing meteorological visibility from... Gradually reduce to Particle concentration from Increase to (Normalized value), where a normalized value of 0 represents the minimum particle concentration (sunny day), and 1 represents the maximum particle concentration that the digital twin engine can simulate, with the target geometry introducing the maximum Non-uniform scaling distortion.

[0080] Rule 3: If ,or In continuous Within each step, all exceeded This triggers high-intensity complex evolution, simultaneously activating dynamic changes in light intensity and angle, and increasing the concentration of meteorological particles. The above-mentioned actions include multiple targets simultaneously exhibiting irregular motion trajectories and shaking, as well as local changes in the road surface adhesion coefficient, in order to create cognitive confusion to the greatest extent possible.

[0081] Rule 4: If long-term below This triggers exploratory evolution, where the digital twin engine randomly applies small perturbations to the parameter space to actively explore parameter directions that may cause an increase in model uncertainty, in order to break through potential unknown edge conditions.

[0082] In this embodiment, a rule-based mapping approach is used, which has the advantage of strong interpretability and ease of debugging and adjustment. In another embodiment, an optimization or reinforcement learning-based method can also be used, treating the digital twin engine's parameter configuration as the action space to maximize... As a reward function, online learning of the optimal adversarial strategy is particularly suitable for black-box optimization scenarios, but its computational overhead is large, making it suitable for offline regression testing rather than real-time interaction.

[0083] S32. The triggered rules are converted into a structured scene adjustment parameter package by the mapping decision-maker and passed to the digital twin engine. In the next rendering cycle, the virtual environment attributes such as lighting, meteorological particle concentration, target occlusion ratio, target geometric deformation, and road surface adhesion coefficient are dynamically changed. The new sensor data is injected into the chip under test through the hardware-in-the-loop simulation unit to form a test closed loop.

[0084] The mapping decision-maker generates a specific scene adjustment parameter package based on the triggered rules. This parameter package is passed to the digital twin engine in structured data form (such as JSON or Protobuf). Upon receiving the parameter package, the digital twin engine immediately adjusts the corresponding properties of its internal virtual world in the next rendering cycle. These properties include, but are not limited to:

[0085] Light intensity and angle: This feature can simulate the solar altitude and azimuth angles at different times of day, as well as abrupt changes in tunnel entrances and building shadows. The dynamic range of light intensity is [not specified]. (All black) to Adjust between (summer noon) and (midday).

[0086] Meteorological particle concentration: This setting can simulate weather effects such as rain, snow, fog, and dust storms. By setting different particle densities, particle size distributions, and extinction coefficients, it can influence the imaging quality of sensors (cameras, LiDAR). The concentration parameter can be set as follows: (Sunny day) to (Dense fog or blizzard) Continuous adjustment.

[0087] Target occlusion ratio: By controlling the occlusion pixel ratio of key targets by static obstacles or dynamic traffic participants in the 2D or 3D sensor field of view, the occlusion ratio can be set from... (Unobstructed) to (Almost completely obscured) Adjustment.

[0088] Geometric deformation of the target object: In the 3D model rendering pipeline of the digital twin engine, non-uniform scaling, twisting, stretching, and other operations are applied to the vertex coordinates of the target object (such as vehicles, pedestrians, and traffic signs) to generate adversarial targets with non-standard geometries, in order to test the model's ability to generalize to irregular targets. The magnitude of the deformation can be controlled by the deformation coefficient, for example, in... arrive between.

[0089] Road surface adhesion coefficient and material: The road surface friction parameters can be dynamically changed to induce instability at the control level and assist in testing the robustness of the control output of the model under cognitive uncertainty.

[0090] Background texture interference: Dynamically inject high-texture-density noise patterns or dynamically flashing billboards into roadside buildings or sky areas to interfere with attention mechanisms.

[0091] After the digital twin engine completes the virtual scene update, new sensor simulation data (camera images, LiDAR point clouds, etc.) are injected into the environment model of the hardware-in-the-loop simulation unit in real time and sent to the sensing input terminal of the computing chip under test via an interface. This process corresponds to... Figure 1 The downward arrow from the uncertainty assessment and mapping unit to the digital twin engine, and the virtual environment interaction relationship between the digital twin engine and the hardware-in-the-loop simulation unit, also correspond to... Figure 2 The S3 query in the system generates scenario adjustment parameters by querying the conflict mapping table.

[0092] S33. After each scenario adjustment, S1 and S2 continue to assess the new cognitive uncertainty. If the price falls back, it will continue to evolve according to the recovery strategy or exploration direction. If it remains high, the intensity of the confrontation will be increased. At the same time, physical rationality constraints and the maximum number of evolution steps are set. Once a clear failure event is detected, it will automatically pause and switch to S4 diagnosis.

[0093] It should be noted that the purpose of environmental evolution is to continuously put pressure on the model, keeping its cognitive uncertainty at a high level, thereby exposing potential failure modes.

[0094] After each scene parameter adjustment and several simulation steps, S1 and S2 will continue to evaluate new cognitive uncertainties. If the system falls below the threshold, it may gradually withdraw some adversarial interference according to the recovery strategy in the rule base, or continue to search for new vulnerable areas through exploratory evolution; if If it continues to rise, then the intensity of the confrontation will continue to increase along the current direction.

[0095] In another embodiment, to prevent infinite evolution from causing scene distortion, the digital twin engine sets physical plausibility constraints, such as fog concentration not exceeding [a certain value]. The angle of illumination must not exceed Physical scope, etc. Simultaneously, the maximum number of steps in a single evolution cycle can be set, or the evolution can be automatically paused and enter S4 for detailed diagnosis after the system detects a clear failure event.

[0096] S4. During the adversarial scenario injection process, the hardware-in-the-loop simulation global clock is used as the unified time axis to synchronously collect data from three dimensions: algorithm output, model internal cognitive state, and chip hardware state. Through failure event detection and multi-dimensional data comparison, the vulnerabilities that lead to performance degradation are classified into algorithm logic weaknesses, quantization accuracy weaknesses, or hardware performance weaknesses, and a graded diagnostic report is generated. The system monitors the operational status data of the tested neural network model and computing chip during the negative sample scenario injection process, including real-time power consumption, inference latency, and control command stability. Through comprehensive comparative analysis, it identifies and classifies hardware-model vulnerabilities that lead to performance degradation.

[0097] Specifically, the specific sub-steps of step S4 are as follows: S41. Using the simulation step size as the period, synchronously record dimension A (target trajectory, control commands, and vehicle attitude), dimension B (cognitive uncertainty sequence), and dimension C (chip power consumption, clock frequency, temperature, and inference delay) to form a complete state sequence with timestamps.

[0098] More specifically, throughout the entire testing process from S1 to S3, the vulnerability analysis and diagnosis module uses the global clock of the hardware-in-the-loop simulation unit as a unified time axis to synchronously record data in the following three dimensions, forming a time-stamped state sequence: Dimension A (Algorithm Output Dimension): This mainly includes the target trajectory prediction sequence (containing the target's horizontal and vertical positions for each second within the next 5 seconds) and the vehicle control command sequence (steering wheel angle, acceleration / braking commands, turn signal commands, etc.) output by the model. These data can be directly read from the control interface buffer of the hardware-in-the-loop simulation unit. At the same time, the real motion trajectories (i.e., true values) of each target in the scene are also collected synchronously from the digital twin engine as the benchmark for subsequent trajectory prediction error calculation.

[0099] In addition, it includes actual vehicle attitude information fed back from the vehicle dynamics model, such as yaw rate and lateral acceleration, used to determine whether control commands deviate from the safety boundary. The safety boundary can be preset, for example, the maximum steering wheel angular rate. The maximum lateral acceleration is Anything exceeding the boundary is considered an anomaly in the behavioral dimension.

[0100] Dimension B (internal dimension of the model): This refers to the sequence of cognitive uncertainty calculated in S2, which includes at least the degree of attentional divergence. Feature disorder (or Comprehensive uncertainty And their rates of change. Activation peaks or spatial entropy of BEV feature maps for certain specific channels can also be selectively recorded for further refined analysis; these data are recorded directly by the master control program of the uncertainty assessment unit.

[0101] Dimension C (Chip Hardware Dimension): Real-time hardware status read from the power management unit (PMU) registers, clock management module, and temperature sensor of the tested computing chip. Specifically, this includes: total chip core power consumption (watts), real-time operating clock frequency of the AI ​​computing unit (MHz), chip junction temperature (°C), inference frame rate, and single-frame inference latency (milliseconds). This data can be read through the performance monitoring API provided by the chip manufacturer or by direct memory-mapped registers. The sampling frequency is preferably consistent with the simulation step size (e.g., ...). (Once), to ensure time alignment with dimensions A and B. For some temperature sensors that do not support high-frequency readings, interpolation may be used to align with the time axis.

[0102] S42. Real-time monitoring dimension A: When any of the following situations occur, such as control commands exceeding safety boundaries, target prediction cumulative error exceeding limits and continuous or inference timeout leading to control frame loss, it is determined as a failure event, and multi-dimensional data of the time window before and after the failure time is captured to trigger cause diagnosis.

[0103] The vulnerability analysis and diagnosis module monitors the data in dimension A in real time. A failure event is determined to have occurred when any of the following conditions are met: (a) The vehicle control command exceeds the preset safety boundary, for example, the steering wheel angle changes by more than [a certain amount] within one frame. (leading to sideslip), or the acceleration command is significantly mismatched with the current vehicle speed and road surface adhesion, triggering the instability alarm of the vehicle dynamics model; (b) The cumulative error between the target trajectory prediction output by the model and the target's true motion trajectory (true value) synchronously acquired from the digital twin engine in S41 exceeds a preset threshold (e.g., the average displacement error exceeds...). (meters), and lasting for more than ; (c) A sudden drop in the inference frame rate causes control commands to fail to update in a timely manner; that is, the end-to-end latency of the entire closed loop from feature acquisition in S1 to scene update in S3 exceeds the hardware-in-the-loop simulation step size (in this example, ...). A timeout event occurred, causing the vehicle to remain in an open-loop coasting state without new control commands.

[0104] Once a failure event is detected, the diagnostic module records the precise timestamp of the failure moment. and automatically capture A certain time window before and after (e.g., before) Seconds later Complete data for dimensions A, B, and C within a second triggers cause-finding diagnosis.

[0105] S43. Using the captured time window data, execute the preset diagnostic logic. Based on whether the hardware status is abnormal, the comparison of the full-precision reference model, and the chip frequency reduction, classify the failure events into algorithm logic weaknesses, quantization accuracy weaknesses, or hardware performance weaknesses, and save the corresponding scene snapshots or computational load characteristics.

[0106] The diagnostic module uses the time window data captured by S42 to execute preset diagnostic logic and classify failure events into at least one of the following vulnerability types: algorithm logic weakness, quantization accuracy weakness, and hardware performance weakness.

[0107] The diagnostic logic is detailed below: Diagnostic Logic A (Algorithm Logic Weakness Determination): If at the time of failure... Dimension C's data shows that the hardware status is normal, meaning the core clock frequency has not been reduced (the frequency remains in its nominal P0 or P1 state), and the chip junction temperature is within the safe operating range (e.g., below). The real-time power consumption did not reach the hardware protection threshold; however, the data in dimension B showed cognitive uncertainty in the period leading up to the failure. Rapidly rising, and through the B dimension and Further analysis revealed that the increase in uncertainty was highly correlated with a certain type of geometric configuration or visual texture pattern (e.g., curves with a specific curvature, or irregularly shaped obstacles with a specific shape), thus marking this failure event as a weakness in the algorithm's logic.

[0108] It should be noted that the essence of this diagnostic logic is to eliminate interference from hardware anomalies and directly locate the perceptual decision-making defects of the model itself. For such weaknesses, the diagnostic module will automatically save a digital twin scene snapshot (including camera images, point clouds, scene parameter configurations, etc.) at the moment of triggering the failure, as a storage of the model's perceptual blind spots or adversarial examples for subsequent algorithm iteration training.

[0109] Diagnostic Logic B (Quantization Accuracy Weakness Judgment): This assumes that two versions of the test model have been generated by the compilation tool before testing: one is the fixed-point quantization model under test (e.g., INT8 quantization), deployed on the main test path; the other is a backup model retaining full precision (FP32), deployed on the same or another chip of the same model, used only for internal comparison and not directly involved in vehicle control. Both models receive identical sensor inputs from the hardware-in-the-loop simulation unit. In S41, dimension A additionally records the control command sequence output by the full-precision reference model at the same time. When a failure event is detected on the main quantization model in S42, the diagnostic module automatically compares the performance of the full-precision reference model at the same time. If the full-precision reference model outputs normally under identical inputs (control commands do not exceed safety boundaries, and prediction accuracy meets requirements), while the quantization model fails, the feature map weight value distribution at that time is further examined in dimension B. If it is found that a large number of feature map weight values ​​are concentrated in extremely low value ranges (e.g., the proportion of values ​​below the quantization step size exceeds a certain threshold), the diagnostic logic will be further investigated. This indicates that the truncation error in the quantization process led to the loss of effective information, thus the failure was determined to be a weakness in quantization accuracy.

[0110] It should be noted that this diagnostic conclusion can suggest to developers that they need to adjust the quantization strategy for this layer, such as using non-uniform quantization, mixed-precision quantization, or retaining a higher bit width (such as INT16) in these layers. If a full-precision reference model cannot be introduced, the degree of output jump can be observed by injecting test samples with known small perturbations and observing the degree of output jump. For example, if a small perturbation invisible to the human eye is added to the input image, and the output of the quantization model jumps sharply while the floating-point model changes only slightly, this can also be characterized as quantization vulnerability.

[0111] Diagnostic Logic C (Hardware Performance Weakness Determination): When the data in dimension C shows that within a short period of time after the adversarial scenario is injected (e.g., Within seconds, the chip's total power consumption suddenly spiked, exceeding the chip's power design limit and triggering on-chip hardware protection mechanisms (such as Dynamic Voltage Frequency Scaling (DVFS) or thermal management frequency throttling). This caused the AI ​​core clock frequency to drop from its normal level (e.g., within seconds). A significant decrease (e.g., to a decrease) The direct consequence is that the single-frame latency for model inference is reduced from the normal range. The number of steps increased dramatically, exceeding the hardware-in-the-loop simulation step size. This resulted in continuous control command frame drops and timing errors. This situation was clearly identified as a hardware performance weakness. This weakness was not an algorithmic logic error, but rather a failure of the chip's energy efficiency and thermal design to meet real-time requirements under specific computational loads. The diagnostic module records computational load characteristics during frequency reduction (such as the number of calls to specific operators, MAC utilization, etc.), which helps guide algorithm trimming or hardware selection.

[0112] In addition, hardware performance weaknesses may include momentary logic errors (i.e., soft errors) caused by voltage drops, which are difficult to detect directly. In such cases, they can be indirectly detected by comparing multiple repeated inferences with the same input.

[0113] S44. For each detected failure event, generate a diagnostic record including timestamp, failure type, trigger scenario parameters, multi-dimensional data waveform and confidence level. After the test, sort the data by vulnerability category to form a comprehensive vulnerability assessment report of the tested model on a specific hardware platform.

[0114] For each detected failure event, the diagnostic module generates a diagnostic record, which includes: timestamp, failure type, summary of triggering scenario parameters, screenshots of key data waveforms for dimensions A / B / C, confidence level of determining it as a certain vulnerability, and suggested handling measures.

[0115] After the test is completed, based on all diagnostic records, the vulnerability categories are statistically analyzed and ranked by severity to generate the final graded diagnostic report.

[0116] It should be noted that this report can clearly point out the main weaknesses of the tested model on a specific domestic heterogeneous computing platform. For example, a total of 12 vulnerabilities were found in this test, including 7 algorithm logic weaknesses (mainly concentrated in the perception of small targets at night), 3 quantization accuracy weaknesses (all related to the quantization error in the low value area of ​​the BEV feature fusion layer), and 2 hardware performance weaknesses (triggered frequency reduction when there is high computational load in dense traffic flow).

[0117] This step S4 is in Figure 2 The bottom S4 section monitors the hardware and software status and categorizes failure boxes. After completing the diagnosis, the process returns to S1 along the left-hand return path to continue the next round of feature extraction and testing iterations, thereby driving the continuous evolution of the digital twin scenario until the expected vulnerability discovery target is covered or the preset test termination conditions are met.

[0118] Through the above process, this invention not only realizes the generation of proactive test scenarios for cognitive states, but also accurately finds the root cause of failure in complex environments with software and hardware coupling, providing a comprehensive diagnostic means for algorithm logic, quantization strategies and hardware platform adaptability.

[0119] Example 3: The difference between this embodiment and Embodiment 2 is that the model under test is deployed on a spiking neural network accelerator implemented by an FPGA for end-to-end vision-driven control. The model output is not a continuous trajectory, but rather discrete steering and speed commands (left turn, straight ahead, right turn, accelerate, decelerate). In this case, the feature vector extracted in step S1 represents the specified hidden layer in... The pulse firing frequency vector within the time window is calculated by dividing the pulse count of each neuron by the time window length. The uncertainty assessment in S2 is no longer based on information entropy, but instead calculates the coefficient of variation (standard deviation / mean) of the firing frequency of the target layer neuron group and the pulse firing synchronization index between groups (e.g., cross-correlation peak). The mapping rule base establishes a mapping between the degree of disorder in pulse firing patterns and physical parameters in the virtual scene, such as stripe density and dynamic light flicker frequency, that can exacerbate pulse jitter and synchronization confusion. In S4, vulnerability diagnosis, in addition to monitoring FPGA power consumption and temperature, also needs to monitor the number of timing violations caused by logic resource contention. The remaining processes are similar to those in Example 2 and will not be repeated here.

[0120] Example 4: The difference between this embodiment and Embodiment 2 is that a reinforcement learning-based adversarial strategy replaces the fixed mapping rule base in the interaction between the digital twin engine and uncertainty assessment. The continuous parameter space of the digital twin engine is used as the action space to comprehensively understand uncertainty. As a reward signal (maximization) This approach trains a policy network that adjusts parameters by directly outputting the scenario based on the current uncertainty feature vector during testing. The advantage of this method is its ability to explore more subtle vulnerabilities beyond manually designed rules, making it suitable for offline long-term regression testing. When training the policy network, safety constraints (such as prohibiting the generation of extreme physical parameters that cause simulation crashes) should be added as a penalty term to the reward function.

[0121] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention. Those skilled in the art will understand that the accompanying drawings are merely schematic diagrams of a preferred embodiment, and the modules or processes in the drawings are not necessarily essential for implementing the present invention. The sequence numbers of the above embodiments are merely for description and do not represent the superiority or inferiority of the embodiments. In the several embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative, and the division of units is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple units or components being combined or integrated into another system, or some features being ignored or not executed. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of this embodiment.

[0122] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0123] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A hardware-in-the-loop vulnerability discovery system for autonomous driving models, characterized in that, include: The hardware-in-the-loop simulation unit is used to run the vehicle dynamics model and virtual environment in real time and provide sensor simulation data to the computing chip under test; A non-invasive neuron probe unit is deployed in the computing chip under test. It is used to extract the neuron activation feature vectors of the autonomous driving model under test in at least one hidden layer in real time during the hardware-in-loop closed-loop operation. The extraction is performed by direct memory access mirror output without changing the main computing path of the model. An uncertainty assessment unit is used to receive the neuron activation feature vector and calculate an index reflecting the cognitive uncertainty of the model based on the feature vector. A digital twin engine, connected to the uncertainty assessment unit, is used to dynamically adjust the physical parameters of the virtual scene according to the cognitive uncertainty index, generate adversarial negative sample scenes, and provide the updated scenes to the hardware-in-the-loop simulation unit. The vulnerability analysis and diagnosis module is used to simultaneously monitor the algorithm output, the internal state of the model, and the hardware state of the tested computing chip during the adversarial negative sample injection process. By comparison, the cause of failure is determined, and the vulnerability is classified into at least one of the following: algorithm logic weakness, quantization accuracy weakness, and hardware performance weakness.

2. A hardware-in-the-loop vulnerability mining method for autonomous driving models, applied to the hardware-in-the-loop vulnerability mining system for autonomous driving models as described in claim 1, characterized in that, include: S1. State perception: The non-invasive neuron probe unit is used to extract the neuron activation feature vector of the tested model in the target hidden layer in real time. S2. Uncertainty assessment: Based on the neuron activation feature vector, calculate the cognitive uncertainty index that reflects the uncertainty of the model's current semantic understanding. When the index meets the preset triggering conditions, proceed to step S3. S3. Environmental Evolution: Input the cognitive uncertainty index into the digital twin engine, query the preset mapping rule base, dynamically adjust the physical environment parameters in the virtual scene, generate targeted adversarial negative sample scenarios in real time, and update the hardware-in-the-loop simulation environment. S4. Vulnerability Identification and Diagnosis: Under the adversarial scenario, algorithm output data, model internal cognitive state data, and chip hardware state data are collected simultaneously. When a failure event is detected, the failure cause is determined by comprehensively comparing the three types of data to be due to weaknesses in algorithm logic, quantization accuracy, or hardware performance.

3. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, In step S2, the calculation of the cognitive uncertainty index includes: The attention weight matrix is ​​extracted from the neuron activation feature vector, and the attention divergence index is calculated based on the query dimension information entropy of each attention head in the matrix. Feature maps are extracted from the neuron activation feature vectors, the feature maps are flattened in the spatial dimension, and the trace of the covariance matrix between feature vectors of different channels is calculated to obtain the feature disorder index. The attention divergence index and the feature confusion index are weighted and fused to obtain a comprehensive cognitive uncertainty index.

4. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, In step S3, the mapping rule base stores multiple rules. Each rule specifies the type and adjustment range of physical parameters to be adjusted based on the numerical range and trend of the cognitive uncertainty index. The types of physical parameters include one or more of the following: light intensity and angle, meteorological particle concentration, target object occlusion ratio, and target object geometric deformation.

5. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, In step S4, the vulnerability determination and diagnosis further includes: If the chip hardware is in normal condition at the time of failure, but the cognitive uncertainty inside the model spikes and this spike is related to the geometric configuration or texture pattern of a specific scene, then it is determined to be a weakness in the algorithm logic. If, under the same input, the full-precision reference model outputs normally while the quantization model outputs incorrectly, and the feature map weight values ​​at the time of failure are concentrated in the range of values ​​below the quantization step size, then it is determined to be a weakness in quantization precision. If, at the moment of failure, the chip power consumption increases, triggering frequency reduction and causing the inference delay to exceed the hardware-in-the-loop simulation step size, then it is determined to be a hardware performance weakness.

6. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, The non-invasive neuron probe unit is implemented as follows: during the offline compilation stage of the autonomous driving model under test, a monitoring operator is inserted after each target hidden layer. The monitoring operator is configured to use the chip's direct memory access channel to transmit the output activation tensor image of the hidden layer to the main control computer.

7. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, In step S1, the target hidden layer includes a BEV feature fusion layer and a trajectory prediction multi-head attention layer; the output of the BEV feature fusion layer is used to calculate feature disorder, and the output of the trajectory prediction multi-head attention layer is used to calculate attention divergence.

8. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, In step S4, the synchronously acquired algorithm output data includes target trajectory prediction, vehicle control commands, and attitude information fed back by the vehicle dynamics model; the model's internal cognitive state data includes attention divergence, feature confusion, and comprehensive cognitive uncertainty index; the chip hardware state data includes chip real-time power consumption, core clock frequency, junction temperature, inference frame rate, and single-frame inference latency.

9. The method for vulnerability mining in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, In step S4, the detection conditions for the failure event include: the vehicle control command exceeds the preset safety boundary, the cumulative error of the target trajectory prediction exceeds the threshold and continues for a preset duration, or the end-to-end inference delay exceeds the hardware-in-the-loop simulation step size.

10. A method for mining vulnerabilities in a hardware-in-the-loop autonomous driving model according to claim 2, characterized in that, Also includes: Based on the vulnerability classification results, the number of vulnerabilities of each type is counted and ranked by severity, generating a graded diagnostic report that includes failure timestamp, failure type, triggering scenario parameters, and diagnostic suggestions.

Images