Algorithm test-oriented dynamic correction method for real-time data of upper computer

Abstract

The invention provides an algorithm test-oriented dynamic correction method for real-time data of an upper computer. The method comprises the following steps of: acquiring original data of a multi-source sensor and generating a standardized data frame by the upper computer; training a difference prediction model based on a historical sample, and predicting a target field and a difference range which need to be corrected through an algorithm parameter sensitivity matrix; the upper computer generates a real-time data patch according to the prediction result and the test scene parameters, and performs structure and CRC dual verification on the patch; the data preprocessing module receives and injects a patch, performs differential updating on a target field, generates a corrected data frame and transmits the corrected data frame to the algorithm module in real time; and the algorithm module executes verification according to the correction data and feeds back the performance index to the upper computer to trigger self-learning updating of the differential model. According to the method, predictive dynamic correction, low-bandwidth transmission and algorithm performance self-optimization of data are realized, and the real-time performance of a simulation test and the resource utilization efficiency are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of host computer data correction technology, and in particular to a method for real-time dynamic correction of host computer data for algorithm testing. Background Technology

[0002] Currently, in the testing of autonomous driving, industrial control, and artificial intelligence algorithms, host computers are commonly used to collect and display data from multiple sensor sources. However, existing host computer systems generally only have data monitoring and visualization functions, lacking real-time interactive data modification capabilities. When testers need to simulate abnormal scenarios or verify the robustness of algorithms, they often need to rebuild the simulation environment or re-import the data, resulting in long testing cycles, high bandwidth consumption, and low efficiency.

[0003] Furthermore, traditional data update methods typically involve retransmitting entire frames, which is insufficient for millisecond-level real-time testing requirements and lacks a mechanism for self-learning and adjustment based on algorithm feedback. Therefore, we propose a real-time dynamic correction method for host computer data oriented towards algorithm testing.

[0004] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] The purpose of this invention is to address the shortcomings of existing technologies by providing a method for real-time dynamic correction of host computer data for algorithm testing, thereby solving the technical problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A method for dynamic correction of real-time data from a host computer for algorithm testing includes the following steps: S1. Collect raw real-time data from multiple source sensors; perform time synchronization and formatting processing on the real-time data to generate a standardized data stream that matches the input format of the algorithm module, and extract the change feature parameter vectors of each data field; S2. Based on a preset historical data sample set and algorithm parameter sensitivity matrix, train a difference prediction model; the difference prediction model is used to predict the target field that may need to be modified and its difference range based on the current feature parameter vector; S3. The host computer automatically generates corresponding real-time data patches based on the output results of the differential prediction model and the input parameters of the current test scenario. The real-time data patches include the target data Topic, field offset address, differential correction value, and check code. S4. Inject real-time data patches into the data preprocessing module. The data preprocessing module performs field-level differential updates on the real-time received data stream according to the patch content. After the update, a patched data frame is generated and transmitted to the algorithm module for real-time algorithm verification.

[0007] S5, the algorithm module performs real-time verification of the data after the injection of patches, and feeds back the performance indicators and fault tolerance results to the host computer; the host computer adjusts the self-learning parameters of the differential prediction model based on the feedback results.

[0008] S1 specifically includes: Data sources from multiple sensors, including LiDAR, cameras, and inertial navigation sensors, are collected; the raw data is encapsulated into a unified data frame structure to form a real-time data stream. The real-time data stream is timestamped and aligned with the coordinate system to ensure that data from different sensors correspond to the same spatial reference at the same time; a standardized data frame is generated after time synchronization and coordinate transformation. The rate of change, extreme value fluctuations, and statistical features of each field are extracted from the standardized data frame to form a feature parameter vector for input to the differential prediction model.

[0009] S2 specifically includes: Retrieve historical sensor data samples and corresponding algorithm response data from the database; construct a training dataset containing the association between feature parameters and algorithm output; Using the training dataset, a differential prediction model is trained; the model learns the weights of different fields on the algorithm's performance based on the algorithm sensitivity matrix. The feature parameter vector is input into the differential prediction model, and the target field that may need to be corrected and its differential range are output, generating a patch template that includes field offset, modification length and prediction increment value.

[0010] S3 specifically includes: The host computer obtains the input parameters of the current test scenario, including the test type, abnormal scenario labels, and algorithm running mode; The host computer automatically constructs real-time data patches containing data topics, field offset addresses, differential correction values, and check codes based on the patch template and scenario parameters. The real-time data patch is subjected to data structure and checksum verification to ensure that the patch format is valid and the correction value does not exceed the algorithm's allowed threshold range, thus forming a verified patch instruction set.

[0011] S4 specifically includes: The patch instruction set is sent to the data preprocessing module via the communication interface; a differential encoding format is used to reduce data transmission bandwidth usage. When the data preprocessing module receives a new data frame, it performs a local differential update operation on the target field based on the field offset and differential correction value of the patch instruction set. A new data frame containing the corrected fields is generated, and the updated data frame is transmitted to the algorithm module in real time for algorithm execution and verification.

[0012] S5 specifically includes: The algorithm module receives the corrected data frame, performs real-time calculations, and outputs performance metrics and fault tolerance results. The performance metrics of the algorithm module are fed back to the host computer, which then evaluates the impact of the patch correction on the robustness of the algorithm based on the feedback information. The host computer updates the weights of the differential prediction model based on the feedback results, thereby achieving adaptive optimization of the differential prediction model and improving the accuracy and timeliness of the next round of patch generation.

[0013] The beneficial effects of this invention are as follows: This invention utilizes a differential prediction model to analyze and predict the changing trends of multi-source sensor data. It can automatically generate correction patches before data anomalies or deviations in algorithm-sensitive parameters occur, enabling proactive intervention in algorithm input and avoiding data lag and scene discontinuity issues during testing. Through field-level differential updates and patched transmission, only the data difference of the modified field is transmitted, avoiding the retransmission of the entire frame of data and reducing bandwidth usage by approximately 60%, thereby significantly improving the data interaction efficiency between the host computer and the algorithm module.

[0014] This invention employs a millisecond-level patch injection and synchronous update mechanism, enabling the host computer to dynamically modify input data within the algorithm's execution cycle, thus achieving real-time simulation of abnormal scenarios. This mechanism effectively improves the algorithm's robustness, fault tolerance, and response accuracy, providing high-efficiency support for algorithm testing in complex environments. Furthermore, this invention utilizes an algorithm performance feedback mechanism to adaptively update the weights and parameters of the differential prediction model, forming an intelligent closed loop of "prediction, correction, verification, and learning." This allows the host computer to continuously optimize and automatically adapt to different algorithm versions and testing scenarios.

[0015] The differential patching mechanism, parallel transmission strategy, and performance feedback learning strategy of this invention work synergistically to reduce the number of test scenario reconstructions and decrease CPU and network resource usage, thereby improving the overall efficiency of algorithm testing by more than 30%. By introducing CRC checksums, patch logs, and model version recording mechanisms, the data modification process is ensured to be verifiable and traceable, effectively preventing abnormal data injection and erroneous patch execution, and guaranteeing the safety and reliability of the algorithm verification process. Attached Figure Description

[0016] Figure 1This is a schematic diagram of a real-time dynamic correction method for host computer data for algorithm testing according to the present invention. Detailed Implementation

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

[0018] Example: Figure 1 As shown, this embodiment provides a method for real-time dynamic correction of host computer data for algorithm testing, including the following steps: S1. Collect raw real-time data from multiple source sensors; perform time synchronization and formatting processing on the real-time data to generate a standardized data stream that matches the input format of the algorithm module, and extract the change feature parameter vectors of each data field; S2. Based on a preset historical data sample set and algorithm parameter sensitivity matrix, train a difference prediction model; the difference prediction model is used to predict the target field that may need to be modified and its difference range based on the current feature parameter vector; S3. The host computer automatically generates corresponding real-time data patches based on the output results of the differential prediction model and the input parameters of the current test scenario. The real-time data patches include the target data Topic, field offset address, differential correction value, and check code. S4. Inject real-time data patches into the data preprocessing module. The data preprocessing module performs field-level differential updates on the real-time received data stream according to the patch content. After the update, a patched data frame is generated and transmitted to the algorithm module for real-time algorithm verification.

[0019] S5, the algorithm module performs real-time verification of the data after the injection of patches, and feeds back the performance indicators and fault tolerance results to the host computer; the host computer adjusts the self-learning parameters of the differential prediction model based on the feedback results.

[0020] S1 specifically includes the following sub-steps: S110, Data Acquisition Sub-step: Acquire data from multiple sensors, including LiDAR, cameras, and inertial navigation sensors (IMU); encapsulate the acquired raw data into a unified data frame structure to form a continuous real-time data stream; wherein, the data frame includes a timestamp field, a topic_id field, a payload field, and a checksum field, the definitions of which are shown in the table below: Field Name meaning Data types unit timestamp Collection time uint64 ms topic_id Data category identifier uint8 — payload Actual sensor data array float32[] Corresponding physical quantity checksum Frame Check Code uint16 — The data sampling frequency is set to 10Hz to 100Hz to ensure the real-time and continuous nature of the data stream; each frame of data is sent with a fixed frame length to ensure synchronous acquisition and unified encapsulation of data from multiple sources.

[0021] S120, Data Synchronization Sub-step: Timestamp alignment and coordinate system unification are performed on the real-time data stream to ensure that data from different sensors correspond to the same spatial reference at the same time; Time synchronization employs a unified time base protocol (e.g., ROS system time or NTP network time) and achieves time alignment through a linear interpolation algorithm, with a time error not exceeding ±1ms; coordinate system one is implemented using a homogeneous transformation matrix, defined as follows: ; in This represents the homogeneous coordinates of a point in the LiDAR coordinate system. This represents the homogeneous coordinates of the point in the Camera coordinate system; It is a 4×4 homogeneous transformation matrix, containing the rotation matrix R and the translation vector t, in the form of: ; The physical meaning of this formula is: the spatial point cloud coordinates collected by the lidar are mapped to the visual coordinate system of the camera through spatial rigid body transformation (rotation + translation), which is used to realize the spatial unification and fusion of multi-sensor data; the data after synchronization and transformation constitutes a standardized data frame for subsequent feature extraction and differential modeling.

[0022] S130, Data Feature Extraction Sub-step: Extract the rate of change, extreme value fluctuations and statistical features of each field from the standardized data frame to form the input feature parameter vector of the differential prediction model; The formula for calculating the rate of change is: ; in This represents the numerical difference of the i-th field in two adjacent frames. The corresponding time difference; statistical characteristics include the mean. Standard deviation The range R is calculated as follows: ; ; ; The resulting feature parameter vector is defined as follows: Each feature Triple features corresponding to a single sensor field: Dimension n corresponds to the number of sensor fields.

[0023] The feature parameter vector serves as the input to the difference prediction model, used for subsequent prediction of the target field and the difference range. The k-th sample value represents the sensor data field value collected at the k-th time point or within the sampling period, and is the basic data for statistical feature calculation; N represents the number of samples, that is, the total number of data samples participating in the statistical calculation. This represents the sample point with the largest value in the sample sequence; This represents the sample point with the smallest value in the sample sequence.

[0024] S2 specifically includes the following sub-steps: S210, Historical Sample Acquisition Sub-step: Retrieve a set of historical sensor data samples related to the target algorithm from the test database. The data sample set includes multiple sets of standardized data frames and their corresponding algorithm response outputs. Each sample group contains a feature parameter vector. and the corresponding algorithm output labels ,in This represents the algorithm's response to the i-th frame of data (such as control commands or recognition confidence).

[0025] By establishing a mapping relationship set from multiple sets of samples: ; A training dataset D containing historical features and response information is obtained and used to train the differential prediction model.

[0026] S220, Differential Model Training Sub-step: Using the training dataset D, construct a differential prediction model based on the algorithm parameter sensitivity matrix; The sensitivity matrix W represents the sensitivity of the algorithm output to changes in the input field, and is defined as follows: ; in Let y be the i-th feature field, and y be the algorithm output. This indicates that the algorithm output y corresponds to the i-th input feature. The partial derivatives reflect the sensitivity of output changes to changes in this feature.

[0027] The difference prediction model uses weighted regression or a deep recursive structure (such as an LSTM network) to model the difference relationship between the input and output. The modeling formula is as follows: ; in This represents the difference change in the predicted i-th field; Indicates the activation function (such as ReLU or tanh); This represents the weight vector corresponding to the i-th field; It is the bias term. F(t) represents the input feature parameter vector at the current time t.

[0028] The model training process uses a function that minimizes the error loss: ; This represents the field difference (predicted change) of the k-th sample obtained from the model prediction. This represents the true field difference value (actual change) of the k-th sample; the weights are optimized using the gradient descent algorithm. With bias term This continues until the loss function converges.

[0029] S230, Prediction Result Generation Sub-step: The feature parameter vector extracted in real time... Input the trained differential prediction model to obtain the predicted field changes at future time steps. ; Based on this forecast, calculate the pre-correction value for the target field: ; in This represents the value of the i-th field after correction at time t+1, i.e., the new data value after applying the prediction difference. This represents the original value of the i-th field at the current time t; This represents the predicted change of the i-th field in the output of the differential prediction model at the next time step; A patch template is generated based on the correction values ​​of each field. The patch template includes: field offset (offset): indicating the position of the data to be modified; modification length (len): specifying the byte range of the correction segment; predicted correction value (value): the difference result output by the model; field checksum (rc): used for transmission integrity verification. The generated patch template is stored in structured JSON or binary format and is used by the host computer to dynamically generate patch instructions during real-time operation.

[0030] S3 specifically includes the following sub-steps: S310, Scenario Parameter Acquisition Sub-step: Before the test starts, the host computer obtains the current algorithm test scenario parameter set P from the test scheduling module. The parameter set includes: Test mode parameters : Indicates whether this test is in normal mode, abnormal simulation mode, or fault-tolerant verification mode; Scenario environment parameters This includes external physical environment information such as temperature, light intensity, humidity, and road friction coefficient; algorithm operating parameters. This includes the algorithm version number, the number of running threads, and the processing latency threshold.

[0031] Parameter set As the environment input for real-time patch generation, the host computer establishes a communication channel with the algorithm module through the interface module, and uses an asynchronous handshake mechanism to complete parameter synchronization, ensuring that patch generation and algorithm operation are in the same test context.

[0032] S320, Patch Content Construction Sub-step: The host computer constructs the correction field values ​​output by the differential prediction model. Construct corresponding real-time data patch content based on the scene parameter set P; The build process is as follows: Field mapping: Determines the target data Topic (topic_id) and its field offset address in the normalized data frame; Correction calculation: based on the predicted correction value and the environmental weight adjustment factor. Calculate the final correction amount: ; in This represents the final corrected value of the i-th field (i.e., the data value used in the patch to update the target field). This represents the environment correction weighting coefficient, used to dynamically adjust the patch correction magnitude based on the test scenario or environment parameters; its value ranges from 0.8 to 1.2. Patch structure assembly: generating a structured patch data package. ; Where: topic_id: data type identifier; : The byte offset of the target field in the data frame; : Field length; Correction value; timestamp: generation time; Verification code. The host computer can simultaneously construct multiple patch data packages to form a batch patch list. ; This represents the i-th patch object, containing the correction content of a single data field; k represents the total number of patches in the current batch; it is used for subsequent real-time injection.

[0033] S330, Patch Validity Verification Sub-step: To ensure the security and correctness of the patch injection process, the host computer performs dual verification of the structure and content of each patch before it is distributed.

[0034] Structure validation: Check if the patch fields are complete and the data types are as expected; if a field is missing or the data is out of bounds, mark it as an invalid patch and remove it from the PatchList.

[0035] Content verification: Calculate patch checksum The 16-bit CRC-CCITT algorithm is used. ; in The data checksum of the i-th patch is used to determine whether the patch content has been tampered with or damaged during transmission or storage. This function represents the calculation of the checksum using a 16-bit Cyclic Redundancy Check algorithm; topic_id represents the data topic number to which the patch belongs, used to identify the data channel or sensor type corresponding to the patch; This indicates the byte offset position of the target field in the normalized data frame in the i-th patch; This indicates the length of the field data in the i-th patch; This represents the correction field value corresponding to the i-th patch; if the calculation result matches the checksum recorded in the patch header, the patch is considered valid.

[0036] Consistency verification: The host computer pre-writes the patch into a set of test data frames through the virtual injection module, and compares the differences in fields before and after the correction. ; in Set the allowable error threshold for the field (typically 0.01 to 0.05 units); if all fields meet the threshold constraint, the patch passes the validity check and enters the real-time injection queue.

[0037] S4 specifically includes the following sub-steps: S410, Patch Transmission Sub-step: After the patch verification is passed, the host computer sends the patch data packet to the data preprocessing module in real time through the communication interface module.

[0038] Specifically, the following steps are included: Communication Channel Establishment: A bidirectional communication channel is established between the host computer and the data preprocessing module using TCP / IP or ZeroMQ high-speed bus protocol. The transmission bandwidth Bt (typically 10–100 Mbps) and the maximum transmission delay threshold are set. (Typical value ≤ 5ms) to ensure data real-time performance.

[0039] Patch sequence encapsulation: Encapsulating a list of valid patches ; The data is then sorted in ascending order by timestamp and encapsulated into a transmission data frame.

[0040] The frame structure is as follows: Fields meaning Data types unit header Frame header identifier uint16 — patch_count This frame contains the number of patches. uint8 — patch_data Patch content sequence bytes — crc_frame Frame Overall Check Code uint16 — Transmission and reception verification: The host computer sends a patch frame, and the data preprocessing module receives it and performs a CRC check. If the check result matches, an ACK confirmation frame is returned; if the check fails, a NACK is returned and a retransmission is requested. Number of retransmissions. ≤3 times; if the limit is exceeded, the system will enter exception handling mode.

[0041] S420, Field-level Update Sub-step: After receiving a valid patch frame, the data preprocessing module performs a field-level differential update operation on the incoming raw data stream in real time. The process is as follows: Data cache matching: Locate the data topic corresponding to the patch in the data buffer and obtain the offset address of the target field. and length .

[0042] Differential calculation and replacement: Perform differential update on the target field and calculate the updated field value: ; in This represents the updated value of the i-th field, i.e., the target data after patching and correction. This represents the original value of the i-th field before the update; where Correction values ​​in the patch .

[0043] Data frame reassembly: An updated, standardized data frame structure is generated immediately after the replacement is complete. ; symbol" " indicates a field replacement operation; This represents the standardized data frame before the update; This represents the updated data frame generated after the patch is applied; This represents the i-th patch object; the reassembled data frame is written to the update queue. Waiting for the algorithm module to be called.

[0044] S430, Correcting the data output sub-step: The data preprocessing module pushes the updated data frame to the algorithm module interface according to the time sequence.

[0045] The output process is as follows: Time synchronization and output control: A timestamp comparison mechanism is used to ensure that the timestamp of the output frame matches the algorithm input period. Alignment; like If the frame is not active, it is marked as a "synchronization valid frame" and output is permitted. Indicates the timestamp of the current data frame's generation or update; This indicates the input timestamp when the algorithm module receives a data frame and prepares to perform calculations. Output channel allocation: For multi-threaded algorithm environments, a thread-safe queue is used to implement parallel frame distribution; The allocation rule is based on the algorithm module number. Each algorithm thread has its own independent buffer channel to avoid frame contention.

[0046] Output confirmation and logging: The system generates a transmission log entry for each frame of correction data sent. ; `frame_id`: Represents the data frame number, used to identify the specific data frame corresponding to the current log; `patch_id`: Represents the patch number, corresponding to the patch used in this correction operation; `send_time`: Represents the sending timestamp of the data frame or patch, used to record the specific time when the patch was sent from the host computer to the algorithm module; `alg_id`: Represents the algorithm module number, used to distinguish different algorithm threads or task instances; `status`: Represents the sending status flag, 1 indicates successful sending, 0 indicates sending failure or timeout; where `status=1` indicates successful sending, and 0 indicates failure; this log is used for subsequent algorithm performance verification and anomaly backtracking.

[0047] S5 specifically includes the following sub-steps: S510, Algorithm Verification Sub-step: After receiving the data frame corrected by the patch, the algorithm module performs real-time algorithm calculation and outputs a performance evaluation index set M.

[0048] The process includes: Input reception and computation execution: The algorithm module operates on a periodic basis. Obtain corrected data frames from the data preprocessing module. And execute the main algorithm function on each field. : ; in This indicates the algorithm's output. This represents the updated data frame input to the algorithm module at time t, i.e., the standardized data that has undergone differential correction and patch injection by the host computer.

[0049] Performance metrics calculation: based on the algorithm output and the expected reference output. Calculate performance metrics: ; in It refers to algorithm accuracy. It refers to response latency. It is the tolerance rate.

[0050] The calculation formulas are as follows: , , , in This is the actual output of the algorithm at time t. For reference or expected output results, The timestamp for the algorithm receiving input data. This is the timestamp of the output result. This represents the number of times the algorithm successfully outputs its output. This represents the total number of executions. A higher ratio indicates better algorithm robustness. Result encapsulation and feedback: The algorithm module encapsulates the indicator set M and the runtime log into a performance feedback package. ; Send it back to the host computer for further analysis.

[0051] S520, Performance Feedback Sub-step: After receiving the performance feedback packet, the host computer judges and quantifies the quality of the algorithm output. Performance evaluation: Compare the real-time metric set M with the historical expected metric set. Compare and calculate the degree of difference: ; This represents the offset of the i-th performance metric; This represents the performance metric value calculated during the current algorithm runtime; This indicates the reference or expected benchmark value corresponding to the indicator; when any (in When the threshold for the indicator tolerance is reached, the algorithm performance is considered to have deviated.

[0052] Offset attribution: By tracing back the patch log and field correction records, locate the patch field that caused the performance degradation; Form a set of offset fields: ; in This represents a set of performance offset fields used to record characteristic fields that cause performance degradation. This represents the i-th feature field; Let be the allowable deviation threshold for the i-th performance indicator.

[0053] Weight adjustment trigger condition: If the offset field set is not empty and the cumulative performance difference exceeds the threshold. This triggers the self-learning update process of the differential prediction model. This represents the cumulative sum of the absolute values ​​of all performance metric offsets; This represents the total performance offset threshold.

[0054] S530, Model Self-Learning Sub-Step: Based on the feedback results, the host computer adaptively adjusts the weight matrix and parameters of the differential prediction model to achieve model evolution and update. This process includes: Incremental sample update: The corrected fields from the performance feedback and the algorithm output results are added to the sample set as new training samples: ; This represents the historical training sample set; This represents the updated incremental sample set, containing historical data and newly added performance feedback data; Incremental weight adjustment: The differential prediction model is updated online using an incremental learning algorithm, and the new weight update formula is: ; This represents the updated i-th weight parameter; This represents the i-th weight parameter before the update; : Learning rate (typically 0.001 to 0.01), controlling the model update step size; L: Real-time loss function, used to measure the deviation between the model's predictions and the actual results; This indicates the loss function with respect to the weight parameters. The gradient reflects the direction of weight adjustment.

[0055] Adaptive Convergence and Model Evaluation: The host computer monitors the convergence status of the loss function. Updates stop when the convergence threshold is reached; This represents the loss function value after the latest training iteration; This represents the loss function value from the previous iteration; subsequently, the new model version number is marked as... And write the update records to the model log file: ; Used for subsequent performance tracing. It is the version number of the updated model; It is the final converged loss function value; update_time: the timestamp when the model completed this update.

[0056] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters and thresholds in the formulas are set by those skilled in the art according to the actual situation.

[0057] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. The semiconductor medium can be a solid-state drive.

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

[0059] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

[0061] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0062] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0063] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

[0065] In conclusion, the above description is only 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.

Claims

1. A method for real-time dynamic correction of host computer data for algorithm testing, characterized in that, Includes the following steps: S1. Collect raw real-time data from multiple source sensors; perform time synchronization and formatting processing on the real-time data to generate a standardized data stream that matches the input format of the algorithm module, and extract the change feature parameter vectors of each data field; S2. Based on a preset historical data sample set and algorithm parameter sensitivity matrix, train a difference prediction model; the difference prediction model is used to predict the target field that may need to be modified and its difference range based on the current feature parameter vector; S3. The host computer automatically generates corresponding real-time data patches based on the output results of the differential prediction model and the input parameters of the current test scenario. The real-time data patches include the target data Topic, field offset address, differential correction value, and check code. S4. Inject the real-time data patch into the data preprocessing module. The data preprocessing module performs field-level differential updates on the real-time received data stream according to the patch content. After the update, a patched data frame is generated, and the data frame is passed to the algorithm module for real-time algorithm verification.

2. The method for real-time dynamic correction of host computer data for algorithm testing according to claim 1, characterized in that, It also includes S5 and the algorithm module to perform real-time verification of the data after the injection of patches, and to feed back the performance indicators and fault tolerance results to the host computer; the host computer adjusts the parameters of the differential prediction model based on the feedback results.

3. The method for real-time dynamic correction of host computer data for algorithm testing according to claim 1, characterized in that, S1 specifically includes: Data is collected from multiple sensors, including LiDAR, cameras, and inertial navigation sensors; the collected raw data is encapsulated into a unified data frame structure to form a real-time data stream. The real-time data stream is timestamped and aligned with the coordinate system to ensure that data from different sensors correspond to the same spatial reference at the same time; a standardized data frame is generated after time synchronization and coordinate transformation.

4. The method for real-time dynamic correction of host computer data for algorithm testing according to claim 3, characterized in that, S1 further includes: extracting the rate of change, extreme value fluctuations and statistical features of each field from the standardized data frame to form a feature parameter vector for input to the differential prediction model.

5. The method for real-time dynamic correction of host computer data for algorithm testing according to claim 1, characterized in that, S2 specifically includes: Retrieve historical sensor data samples and corresponding algorithm response data from the database; construct a training dataset containing the association between feature parameters and algorithm output; Using the training dataset, a differential prediction model is trained; the model learns the weights of different fields on the algorithm's performance based on the algorithm sensitivity matrix. The feature parameter vector is input into the differential prediction model, and the target field that may need to be corrected and its differential range are output, generating a patch template that includes field offset, modification length and prediction increment value.

6. The method for real-time dynamic correction of host computer data for algorithm testing according to claim 1, characterized in that, S3 specifically includes: The host computer obtains the input parameters of the current test scenario, including the test type, abnormal scenario labels, and algorithm running mode; The host computer automatically constructs real-time data patches containing data topics, field offset addresses, differential correction values, and checksums based on the patch template and scenario parameters.

7. A method for real-time dynamic correction of host computer data for algorithm testing according to claim 6, characterized in that, S3 further includes: verifying the data structure and checksum of the real-time data patch to ensure that the patch format is legal and the correction value does not exceed the allowable threshold range of the algorithm, thus forming a verified patch instruction set.

8. A method for real-time dynamic correction of host computer data for algorithm testing according to claim 1, characterized in that, S4 specifically includes: The patch instruction set is sent to the data preprocessing module via the communication interface; a differential encoding format is used to reduce data transmission bandwidth usage. When the data preprocessing module receives a new data frame, it performs a local differential update operation on the target field based on the field offset and differential correction value of the patch instruction set. A new data frame containing the corrected fields is generated, and the updated data frame is transmitted to the algorithm module in real time for algorithm execution and verification.

9. A method for real-time dynamic correction of host computer data for algorithm testing according to claim 2, characterized in that, S5 specifically includes: The algorithm module receives the corrected data frame, performs real-time calculations, and outputs performance metrics and fault tolerance results. The performance metrics of the algorithm module are fed back to the host computer, which then evaluates the impact of the patch on the algorithm's robustness based on the feedback information.

10. A method for real-time dynamic correction of host computer data for algorithm testing according to claim 9, characterized in that, S5 also includes: the host computer updates the weights of the parameters of the differential prediction model based on the feedback results, realizing the adaptive optimization of the differential prediction model, so as to improve the accuracy and timeliness of the next round of patch generation.

Images