Software-in-the-loop verification method and system, computer device and readable storage medium

Abstract

The application relates to a software-in-the-loop verification method, system, computer device and readable storage medium. Environment perception data and vehicle state data corresponding to a self-vehicle simulation model in a current simulation period are acquired. Data timeliness of the vehicle state data is analyzed based on a simulation starting time of the current simulation period and a first timestamp corresponding to the vehicle state data, and timeliness results of the vehicle state data in the current simulation period are determined. Based on the timeliness results, a to-be-simulated data packet of the current simulation period is determined according to the vehicle state data, the environment perception data and a historical simulation data packet of a previous simulation period. Intelligent driving decision analysis is performed based on the to-be-simulated data packet, and simulation vehicle control instructions are generated to drive the self-vehicle simulation model to update the vehicle state, thereby improving the accuracy of a software-in-the-loop verification process.

Description

Technical Field

[0001] This application relates to the field of software-in-the-loop verification technology for intelligent driving, and in particular to a software-in-the-loop verification method, system, computer device, and readable storage medium. Background Technology

[0002] In the development of intelligent driving systems, MIL (Model-in-the-Loop) and SIL (Software-in-the-Loop) simulations have become core verification methods. Traditional technical solutions generally adopt a multi-toolchain co-simulation architecture: for example, using bus simulation tools such as CANoe to simulate the vehicle's CAN (Controller Area Network) bus signals (such as vehicle speed and steering wheel angle); using open-source scene simulation platforms (such as CARLA and AirSim) to generate raw data from sensors such as cameras, millimeter-wave radar, and lidar, as well as high-fidelity 3D traffic scenes; and simultaneously relying on open-source algorithm development environments (such as Scilab / Xcos and Python control models) to run ADAS (Advanced Driver Assistance Systems) control strategies.

[0003] However, the inconsistent clock sources of the various simulation platforms in this multi-toolchain co-simulation architecture can easily affect the timeliness of the data on which control decisions are based, and thus affect the accuracy of in-loop verification.

[0004] There is currently no effective solution to the problem of low accuracy in in-loop verification in traditional technologies. Summary of the Invention

[0005] Therefore, it is necessary to provide a software-in-the-loop verification method, system, computer device, and readable storage medium to address the aforementioned technical problems.

[0006] In a first aspect, this application provides a software-in-the-loop verification method, applied to an intelligent driving control unit in a software-in-the-loop verification system; the method includes:

[0007] Acquire environmental perception data and vehicle status data corresponding to the vehicle simulation model within the current simulation cycle;

[0008] Based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data, a data timeliness analysis is performed on the vehicle status data to determine the timeliness result of the vehicle status data in the current simulation cycle.

[0009] Based on the timeliness results, the data packet to be simulated in the current simulation cycle is determined according to the vehicle status data, the environmental perception data, and the historical simulation data packet from the previous simulation cycle.

[0010] Based on the data packet to be simulated, intelligent driving decision analysis is performed to generate simulated vehicle control commands to drive the autonomous vehicle simulation model to update the vehicle state.

[0011] In one embodiment, the step of performing a data timeliness analysis on the vehicle state data based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data, and determining the timeliness result of the vehicle state data in the current simulation cycle, includes:

[0012] If the current simulation cycle is not the first simulation cycle, obtain the historical delay comparison results corresponding to a preset number of consecutive historical simulation cycles preceding the current simulation cycle; wherein, the historical delay comparison result corresponding to each historical simulation cycle is used to characterize the relationship between the historical time difference corresponding to the historical simulation cycle and the historical delay threshold corresponding to the historical simulation cycle; the historical time difference refers to the time difference between the simulation start time of the historical simulation cycle and the second timestamp corresponding to the vehicle state data of the historical simulation cycle.

[0013] The current time difference corresponding to the current simulation cycle is determined based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data.

[0014] Based on the current time difference and the current delay threshold corresponding to the current simulation cycle, determine the current delay comparison result corresponding to the current simulation cycle;

[0015] Based on the current delay comparison result and a preset number of consecutive historical delay comparison results, the timeliness result of the vehicle status data in the current simulation cycle is determined.

[0016] In one embodiment, determining the timeliness result of the vehicle state data in the current simulation cycle based on the current latency comparison result and a preset number of consecutive historical latency comparison results includes:

[0017] If a predetermined number of consecutive historical delay comparison results and the current delay comparison result satisfy the first state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be an alarm; the first state transition condition is that a predetermined number of consecutive historical delay comparison results prior to the current simulation cycle all indicate that the historical time difference is greater than the historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold; and / or,

[0018] If a predetermined number of consecutive historical delay comparison results and the current delay comparison result satisfy the second state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be invalid; the second state transition condition is that a second consecutive number of historical delay comparison results prior to the current simulation cycle all indicate that the historical time difference is greater than the historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold; and / or,

[0019] If a predetermined number of consecutive historical delay comparison results and the current delay comparison result satisfy the third state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be normal; the third state transition condition is that the third consecutive number of historical delay comparison results before the current simulation cycle all indicate that the historical time difference is less than or equal to the historical delay threshold, and the current delay comparison result indicates that the current time difference is less than or equal to the current delay threshold; and / or,

[0020] If a preset number of consecutive historical delay comparison results and the current delay comparison results do not satisfy the first state transition condition, the second state transition condition, and the third state transition condition, then the historical timeliness result of the previous simulation cycle is determined as the timeliness result of the vehicle state data in the current simulation cycle.

[0021] The first quantity is less than the second quantity, and the second quantity is less than the third quantity.

[0022] In one embodiment, the step of performing a data timeliness analysis on the vehicle state data based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data, and determining the timeliness result of the vehicle state data in the current simulation cycle, includes:

[0023] If the current simulation cycle is the first simulation cycle, the current time difference corresponding to the current simulation cycle is determined based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data.

[0024] Based on the current time difference and the current delay threshold corresponding to the current simulation cycle, determine the current delay comparison result corresponding to the current simulation cycle;

[0025] If the current delay comparison result is that the current time difference is greater than the current delay threshold, then the timeliness result of the vehicle status data in the current simulation cycle is determined to be an alarm.

[0026] If the current delay comparison result is that the current time difference is less than or equal to the current delay threshold, then the timeliness result of the vehicle status data in the current simulation cycle is determined to be normal.

[0027] In one embodiment, determining the simulation data packet for the current simulation cycle based on the timeliness result, according to the vehicle status data, the environmental perception data, and the historical simulation data packet from the previous simulation cycle, includes:

[0028] If the timeliness result is normal, then the data packet to be simulated for the current simulation cycle is determined based on the vehicle status data and the environmental perception data.

[0029] If the timeliness result is invalid, then the historical simulation data packet of the previous simulation cycle is determined as the simulation data packet of the current simulation cycle;

[0030] If the timeliness result is an alarm, then candidate simulation data packets are determined based on the vehicle status data and the environmental perception data;

[0031] Based on the candidate simulation data packets and the historical simulation data packets from the previous simulation cycle, the data packets to be simulated in the current simulation cycle are determined.

[0032] In one embodiment, the environmental perception data includes multiple consecutive frames of initial environmental data, each frame of the initial environmental data corresponding to a third timestamp; if the timeliness result is normal, then based on the vehicle status data and the environmental perception data, the data packet to be simulated for the current simulation cycle is determined, including:

[0033] Interpolation calculations are performed based on each of the third timestamps and each of the initial environmental data to obtain target environmental perception data that is time-sequentially aligned with the simulation start time of the current simulation cycle.

[0034] The target environment perception data and the vehicle state data are encapsulated to obtain the simulation data package for the current simulation cycle.

[0035] In one embodiment, the environmental perception data includes multiple consecutive frames of initial environmental data, each frame of the initial environmental data corresponding to a third timestamp; determining the simulation data packet for the current simulation period based on the candidate simulation data packet and the historical simulation data packet from the previous simulation period includes:

[0036] Obtain the priority of the historical data packets to be simulated;

[0037] The priority of the candidate simulation data packet is determined based on the priority of all parameters in the candidate simulation data packet;

[0038] Based on the priority of the historical data packets to be simulated and the priority of the candidate data packets to be simulated, the data packets to be simulated for the current simulation period are determined from the historical data packets to be simulated and the candidate data packets to be simulated.

[0039] Secondly, this application provides a software-in-the-loop verification system, the system including an intelligent driving control unit;

[0040] The intelligent driving control unit is used to perform the software-in-the-loop verification method described above.

[0041] Thirdly, this application provides a computer device including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method described above.

[0042] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described above.

[0043] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described above.

[0044] The aforementioned software-in-the-loop verification method, system, computer equipment, and readable storage medium acquire environmental perception data and vehicle status data corresponding to the vehicle simulation model within the current simulation cycle. Using the simulation start time of the current simulation cycle as a time base, and combining it with the first timestamp corresponding to the vehicle status data, a timeliness analysis is performed on the vehicle status data to obtain the timeliness result of the vehicle status data in the current simulation cycle. Then, based on the timeliness result, combined with the vehicle status data, environmental perception data, and historical simulation data packets from the previous simulation cycle, the required simulation data packets for the current simulation cycle are determined. Based on the simulation data packets, intelligent driving decision analysis is performed to generate simulated vehicle control commands to drive the vehicle simulation model to update the vehicle status. This avoids the problem of inaccuracy caused by directly using environmental perception data and vehicle status data acquired within the current simulation cycle for intelligent driving decision-making. By analyzing the timeliness of the vehicle status data, a data filtering basis is provided for determining the required simulation data packets for the current simulation cycle, thereby ensuring the reliability and timeliness of the intelligent driving decision input data and effectively improving the accuracy of software-in-the-loop verification. Attached Figure Description

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

[0046] Figure 1 This is a schematic diagram of the structure of a software-in-the-loop verification system in one embodiment;

[0047] Figure 2 This is a flowchart illustrating a software-in-the-loop verification method in one embodiment;

[0048] Figure 3 This is a flowchart illustrating the timeliness analysis steps in one embodiment;

[0049] Figure 4 This is a flowchart illustrating the timeliness analysis steps in another embodiment;

[0050] Figure 5 This is a flowchart illustrating the steps for determining the data packet to be simulated in one embodiment;

[0051] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0053] At present, intelligent driving software-in-the-loop verification systems generally suffer from key defects such as insufficient collaboration of multiple toolchains, lack of timing synchronization, imperfect closed-loop feedback mechanism, and uncontrollable data timeliness. This results in the simulation environment being unable to realistically reproduce the characteristics of vehicle network communication and vehicle dynamic response behavior, which seriously affects the accuracy of ADAS algorithm verification. Specifically, the relevant technologies have the following core problems: (1) Most solutions do not integrate CANoe or similar professional bus simulation tools, which makes it impossible to simulate physical layer and link layer characteristics such as message jitter, arbitration delay, and frame loss between real ECU nodes, resulting in the lack of multi-source CAN signal input and incomplete coverage of verification scenarios. (2) Control commands cannot be transmitted back to the vehicle dynamics model in real time through standardized bus protocols. The system remains in the open-loop stage and cannot verify the complete closed-loop dynamic process of "perception-decision-control-execution-re-perception". In particular, it is difficult to evaluate the coupling effect of vehicle state changes on sensor and algorithm performance under emergency conditions. (3) Multiple tools run independently and lack a unified time synchronization mechanism, resulting in misalignment of cross-tool data sampling time and cumulative clock drift (up to 200ms or more), which cannot support the accurate verification of high real-time algorithms. (4) Data flow relies on manual intervention and has poor repeatability. For example, control commands need to be manually relayed, introducing second-level delays and human errors. This not only disrupts the continuity of the simulation but also causes the standard deviation of the results of multiple runs under the same working condition to exceed 15%, making it difficult to meet the consistency requirements of functional safety for calibration and regression testing. (5) Related systems generally regard all received data as valid input and do not quantify the freshness of data packets. When data lags due to network delays or fluctuations in tool load, the algorithm still makes decisions based on the expired state, causing inaccurate control commands and further amplifying the systematic deviation between simulation and actual vehicle.

[0054] Therefore, this application provides a software-in-the-loop verification method. Before describing the specific process and steps of the software-in-the-loop verification method of this application, its application environment is first described:

[0055] The software-in-the-loop verification method in this embodiment is applied to... Figure 1 The software-in-the-loop verification system shown includes an intelligent driving control unit; the software-in-the-loop verification system also includes a communication bus simulation unit and a scenario simulation unit; the intelligent driving control unit is connected to the communication bus simulation unit and the scenario simulation unit respectively; the communication bus simulation unit is connected to the scenario simulation unit.

[0056] The intelligent driving control unit can be an open-source algorithm platform like Scilab / Xcos, used to implement the core perception, decision-making, and control functions of intelligent driving. Specifically, the intelligent driving control unit can be based on the Scilab scripting language or the Xcos graphical modeling environment to build complete environmental perception, multi-sensor fusion, behavior prediction, path planning, and driving decision-making logic, such as typical ADAS functions like adaptive cruise control, lane keeping assist, and automatic emergency braking.

[0057] The communication bus simulation unit simulates the dynamic response of a real in-vehicle communication network, ensuring that the simulated vehicle control commands generated by the intelligent driving control unit can drive the vehicle simulation model in a manner consistent with real-vehicle specifications, and providing real-time feedback of updated vehicle status data. The communication bus simulation unit also simulates the behavior of other electronic controller nodes in the body domain, power domain, etc., replicating physical and link layer characteristics such as message interaction, bus load fluctuations, arbitration delays, signal jitter, and even frame drops in a real in-vehicle network, thereby improving the realism of the network environment and the verification coverage. Furthermore, the communication bus simulation unit can achieve efficient bidirectional communication with the scene simulation unit through CAPL scripts and the VINic interface, transmitting updated vehicle status data back to the scene simulation unit in real time to drive the precise movement of the vehicle in the virtual environment.

[0058] In one exemplary embodiment, the communication bus simulation unit includes a CANoe bus simulation platform and an integrated vehicle dynamics model. The vehicle dynamics model receives simulated vehicle control commands (such as steering angle, throttle opening, and braking pressure) from the intelligent driving control unit and calculates the vehicle's motion state in real time, including key parameters such as vehicle speed, acceleration, yaw rate, and center of gravity position. The vehicle dynamics model can utilize high-fidelity dynamics simulation tools such as DYNA4 and CarMaker, without specific limitations. The CANoe bus simulation platform, based on the actual vehicle model's communication matrix, packages the vehicle state data output from the vehicle dynamics model into vehicle state communication messages, i.e., CAN bus messages, and broadcasts them on the virtual CAN bus to simulate the vehicle's network communication behavior.

[0059] The scene simulation unit, which can be the CARLA open-source scene simulation platform, is used to construct and render the 3D dynamic traffic scenes required for intelligent driving, providing near-realistic perception input for the algorithms in the intelligent driving control unit. In an exemplary embodiment, the scene simulation unit, based on the OpenDRIVE standard, constructs diverse test scenarios including complex road topologies, traffic signs and markings, static obstacles, and dynamic traffic participants (such as vehicles, pedestrians, and cyclists). Simultaneously, the scene simulation unit utilizes the Unreal Engine physics rendering engine to accurately simulate multimodal sensors installed on the vehicle, including cameras, millimeter-wave radar, and lidar, and generates corresponding simulated perception data streams. Furthermore, the scene simulation unit supports real-time rendering from multiple perspectives, intuitively displaying vehicle behavior, traffic flow interactions, and sensor detection coverage during the simulation process, facilitating development, debugging, and result analysis.

[0060] In some embodiments, the scene simulation unit can also provide a Python API client interface to support remote configuration of scene parameters, dynamic adjustment of sensor attributes, injection of specific traffic events, and receiving vehicle status updates from the communication bus simulation unit, thereby achieving precise pose synchronization and closed-loop drive of the vehicle in the virtual environment.

[0061] Understandably, the software-in-the-loop verification system of this application provides a high-fidelity, full-link closed-loop simulation environment for software-in-the-loop verification methods. This system can not only accurately reproduce complex traffic scenarios and multimodal sensor data (such as cameras, millimeter-wave radar, lidar, etc.), but also accurately simulate the communication behavior of the vehicle CAN network. Based on the vehicle dynamics model, it can respond in real time to the simulated vehicle control commands generated by the intelligent driving control unit, thereby effectively supporting the full-process, closed-loop verification of intelligent driving algorithms from environmental perception, decision planning to vehicle execution.

[0062] The following describes the specific process and steps of the software-in-the-loop verification method of this application.

[0063] In one embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating a software-in-the-loop verification method in one embodiment. The software-in-the-loop verification method of this application is applied to an intelligent driving control unit in a software-in-the-loop verification system, and includes the following steps:

[0064] Step S201: Obtain the environmental perception data and vehicle status data corresponding to the vehicle simulation model within the current simulation cycle.

[0065] It should be noted that the intelligent driving control unit includes a clock drift compensator. This clock drift compensator periodically monitors the local clocks of the intelligent driving control unit, the communication bus simulation unit, and the scenario simulation unit after the software-in-the-loop verification system starts. Using a preset reference clock, it calculates the clock deviation of each unit relative to the preset reference clock. Utilizing the obtained clock deviation, it dynamically compensates for the timestamps of data generated or received by each unit through timestamp correction and other methods. This ensures that the multi-source heterogeneous modules in the entire software-in-the-loop verification system maintain a high degree of synchronization in the time dimension, eliminating long-term cumulative clock drift caused by minor differences in operating system scheduling and hardware clock sources. In some embodiments, the clock drift compensator can be implemented using, but is not limited to, a proportional-integral (PI) controller to dynamically adjust the local clock deviation of each unit. The specific implementation method can be adapted according to system accuracy requirements, real-time constraints, and platform characteristics, and is not specifically limited here.

[0066] The simulation cycle refers to the basic time unit for the operation of the intelligent driving control unit. Each simulation cycle can be a fixed time step, such as 10ms or 20ms, which can be set according to the actual simulation requirements. No specific limitation is made here.

[0067] The vehicle simulation model refers to a virtual vehicle model; environmental perception data is generated by the scene simulation unit; environmental perception data includes multiple consecutive frames of initial environmental data; the initial environmental data may include, but is not limited to, the status of surrounding vehicles (such as position, speed, heading angle, etc.), traffic participant information (such as pedestrians, cyclists), static environmental elements (such as lane lines, traffic signs, traffic light status), and sensor simulation outputs (such as camera images, millimeter-wave radar point clouds, lidar point clouds, etc.). Vehicle state data is generated by the vehicle dynamics model; the vehicle dynamics model can be deployed in any of the intelligent driving control unit, communication bus simulation unit, and scene simulation unit. Vehicle state data may include, but is not limited to, position, speed, acceleration, heading angle, yaw rate, etc.

[0068] Vehicle status data carries a first timestamp; the first timestamp is a timestamp attached to the vehicle status data, used to indicate the time when the vehicle status data was transmitted. It should be noted that the first timestamp is the time after clock drift compensation. In an exemplary embodiment, to establish a unified time base, a strict clock handshake protocol needs to be executed during the system startup phase: After the intelligent driving control unit starts, it sends a clock synchronization request packet (such as SYNC_REQ) to the communication bus simulation unit via UDP (User Datagram Protocol), carrying its local startup time T_sci_start in the request. Upon receiving the request, the communication bus simulation unit immediately sends back its own high-precision startup time T_can_start. Both parties calculate the initial clock offset Offset = T_can_start - T_sci_start based on this. Subsequently, when the communication bus simulation unit generates and marks the first timestamp (denoted as T1), it automatically applies the aforementioned offset compensation offset at the data source to ensure that it is consistent with the time reference of the intelligent driving control unit. This fundamentally solves the problem of cumulative clock drift caused by the free operation of multiple tools in traditional technology and provides a unified absolute time reference for the entire system.

[0069] In an exemplary embodiment, the method for obtaining the environmental perception data and vehicle status data corresponding to the vehicle simulation model in the current simulation cycle may be as follows: receiving environmental perception data (including multiple consecutive frames of initial environmental data) generated and sent by the scene simulation unit through the intelligent driving control unit; receiving vehicle status communication messages sent by the communication bus simulation unit through the intelligent driving control unit, and parsing the vehicle status communication messages to obtain the corresponding vehicle status data.

[0070] Step S202: Based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data, perform data timeliness analysis on the vehicle status data to determine the timeliness result of the vehicle status data in the current simulation cycle.

[0071] The data timeliness analysis quantifies the time deviation of the first timestamp of the vehicle status data relative to the simulation start time of the current simulation cycle, and determines the timeliness result of the vehicle status data in the current simulation cycle accordingly. The timeliness result characterizes the degree of data delay of the vehicle status data relative to the simulation start time of the previous simulation cycle; the timeliness result is categorized as normal, alarm, or failure. Normal indicates that the data delay is within an acceptable range and the data is valid; alarm indicates that the data has a moderate delay, which may affect control accuracy and should be used with caution; failure indicates that the data is severely outdated and no longer applicable to the current simulation cycle, and should be discarded.

[0072] In an exemplary embodiment, the method for determining the timeliness result of vehicle state data in the current simulation cycle by performing data timeliness analysis on vehicle state data based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data may be as follows: calculate the time difference between the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data; obtain the current system network state information and determine the current delay threshold based on the current system network state information; and determine the timeliness result of vehicle state data in the current simulation cycle by comparing the time difference between the simulation start time of the current simulation cycle and the first timestamp with the current delay threshold.

[0073] Step S203: Based on the timeliness results, determine the data package to be simulated in the current simulation cycle according to the vehicle status data, environmental perception data, and historical simulation data packages from the previous simulation cycle.

[0074] The historical simulation data packets refer to the valid simulation data packets that participated in the intelligent driving decision analysis in the previous simulation cycle of the current simulation cycle. The historical simulation data packets from the previous simulation cycle are cached in a historical data packet queue; this queue is maintained by the buffer scheduling module in the intelligent driving control unit; the buffer scheduling module includes a circular buffer; the circular buffer is a fixed-depth First-In-First-Out (FIFO) queue (e.g., with a depth of 32 frames) used to temporarily cache a number of recently valid historical data packets. This buffering mechanism can effectively cope with instantaneous data fluctuations or temporary data gaps. In other embodiments, it is necessary to monitor the occupancy rate of the circular buffer in real time to prevent buffer overflow caused by continuous data accumulation and ensure stable system operation.

[0075] In an exemplary embodiment, if the timeliness result of the vehicle status data is invalid, the historical simulation data packet from the previous simulation cycle is determined as the simulation data packet for the current simulation cycle. This ensures that subsequent intelligent driving decision analysis will not be based on invalid vehicle status data, guaranteeing the reliability of the input data for intelligent driving decision analysis. It should be noted that using the historical simulation data packet from the previous simulation cycle as the simulation data packet for the current simulation cycle avoids simulation interruptions caused by data loss and also avoids decision biases caused by directly using invalid vehicle status data. If the timeliness result of the vehicle status data is not invalid (i.e., alarm or normal), candidate simulation data packets are determined based on the vehicle status data and environmental perception data. Based on preset scheduling conditions, the simulation data packet for the current simulation cycle is determined from the candidate simulation data packets and the historical simulation data packets from the previous simulation cycle. The preset scheduling conditions need to be set according to actual scheduling requirements and are not specifically limited here; the setting of the preset scheduling conditions is used to ensure a balance between accuracy and timeliness in the decision input data.

[0076] In some embodiments, the method for determining candidate simulation data packets based on vehicle state data and environmental perception data can be as follows: Based on the simulation start time of the current simulation cycle and the environmental perception data, determine the target environmental perception data; encapsulate the vehicle state data and the target environmental perception data to obtain the candidate simulation data packets. It should be noted that the environmental perception data includes multiple consecutive frames of initial environmental data, each frame of initial environmental data carrying a third timestamp. The third timestamp is used to identify the data transmission time of the corresponding initial environmental data. Consistent with the first timestamp, the third timestamp is also a time value after clock drift compensation, aligned to the system's globally unified time reference (e.g., the reference established through the clock handshake protocol of the aforementioned startup phase). The method for determining target environmental perception data based on the simulation start time of the current simulation cycle and the environmental perception data can be as follows: Using the simulation start time of the current simulation cycle as the interpolation target time point, based on several adjacent frames of initial environmental data and their corresponding third timestamps, use linear interpolation, spline interpolation, or other applicable time alignment algorithms to calculate the target environmental perception data corresponding to the simulation start time. This enables precise synchronization between the target environmental perception data and the current simulation cycle on a unified time axis. It is understandable that the target environment perception data has been strictly aligned with the simulation start time of the current simulation cycle on the time axis through the aforementioned interpolation mechanism. Therefore, its timeliness can be regarded as meeting the simulation timing requirements and no additional evaluation is required. Thus, it can be directly encapsulated with vehicle state data to generate corresponding candidate simulation data packets to participate in subsequent data packet scheduling decisions.

[0077] Step S204: Perform intelligent driving decision analysis based on the data packet to be simulated, generate simulated vehicle control commands to drive the vehicle simulation model to update the vehicle state.

[0078] The simulated vehicle control commands may include, but are not limited to, throttle opening, braking pressure, desired acceleration, front wheel steering angle, gear position signals, and other executable quantities. These commands are used to drive the vehicle dynamics model to update its vehicle state data, which in turn drives the vehicle simulation model to update its own vehicle state.

[0079] In an exemplary embodiment, taking the deployment of a vehicle dynamics model in a communication bus simulation unit as an example, the intelligent driving control unit uses the data packet to be simulated as input to its internally constructed intelligent driving algorithm chain. This algorithm chain performs core functions such as environment understanding, behavior decision-making, and motion planning, and ultimately outputs simulated vehicle control commands for controlling the vehicle's dynamic behavior, such as desired acceleration and front wheel steering angle. Subsequently, the simulated vehicle control commands are encapsulated according to a predefined data structure to form compact, efficient, and clearly defined command data packets to meet the requirements of subsequent communication interfaces for transmission efficiency and format consistency. Through the backhaul interface between the intelligent driving control unit and the communication bus simulation unit, the command data packets are sent in real-time to the vehicle dynamics model in the communication bus simulation unit via a low-latency communication link (such as shared memory, UDP, etc.). The vehicle dynamics model performs dynamic simulation based on the received simulated vehicle control commands, generates new vehicle state data, and uses this data to drive the vehicle simulation model to update its current state, thereby completing a full cycle of closed-loop simulation.

[0080] In other embodiments, an instruction timestamp can be appended to the aforementioned instruction data packet. This instruction timestamp records the moment when the intelligent driving algorithm chain completes the decision and generates the control instruction. By calculating the difference between the instruction timestamp and the first timestamp, the closed-loop delay introduced by the "perception-decision" process can be accurately quantified.

[0081] In the above embodiments, environmental perception data and vehicle status data corresponding to the vehicle simulation model within the current simulation cycle are acquired. Using the simulation start time of the current simulation cycle as the time base, and combining it with the first timestamp corresponding to the vehicle status data, a timeliness analysis is performed on the vehicle status data to obtain the timeliness result of the vehicle status data in the current simulation cycle. Then, based on the timeliness result, combined with the vehicle status data, environmental perception data, and historical simulation data packets from the previous simulation cycle, the required simulation data packets for the current simulation cycle are determined. Based on the simulation data packets, intelligent driving decision analysis is performed to generate simulated vehicle control commands to drive the vehicle simulation model to update the vehicle status. This avoids the problem of inaccuracy caused by directly using environmental perception data and vehicle status data acquired within the current simulation cycle for intelligent driving decision-making. By analyzing the timeliness of the vehicle status data, a data filtering basis is provided for determining the required simulation data packets for the current simulation cycle, thereby ensuring the reliability and timeliness of the intelligent driving decision input data and effectively improving the accuracy of software-in-the-loop verification.

[0082] In one embodiment, such as Figure 3 As shown, Figure 3This is a flowchart illustrating the timeliness analysis steps in one embodiment. Based on the above embodiment, and using the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data, a timeliness analysis is performed on the vehicle status data to determine the timeliness result of the vehicle status data in the current simulation cycle. This includes the following steps:

[0083] Step S301: If the current simulation cycle is not the first simulation cycle, obtain the historical delay comparison results corresponding to a preset number of consecutive historical simulation cycles before the current simulation cycle.

[0084] The preset quantity refers to the number of historical simulation cycles (e.g., the most recent 3, 5, or 10 simulation cycles) that the system retrospectively includes in the judgment when performing data timeliness analysis. The setting of the preset quantity must meet the system's requirements for hysteresis characteristics. That is, by introducing continuous state observation within a certain time window, the system avoids frequent switching of timeliness labels due to single instantaneous jitter or occasional delays, thereby enhancing the stability and robustness of time series judgment.

[0085] It is understandable that the hysteresis characteristic refers to the anti-jitter mechanism adopted by the system in the timeliness state decision-making process. Its core is that the state switching not only depends on the judgment result of the current simulation cycle, but also needs to meet the requirement of continuously triggering specific conditions within multiple consecutive cycles (i.e., reaching a "preset number") in order to suppress misjudgments caused by accidental noise or brief communication anomalies and improve the reliability of timeliness analysis.

[0086] The historical latency comparison results for each historical simulation cycle are used to characterize the relationship between the historical time difference and the historical latency threshold for that historical simulation cycle. The historical time difference refers to the time difference between the simulation start time of the historical simulation cycle and the second timestamp corresponding to the vehicle state data of that historical simulation cycle. The second timestamp is used to mark the data transmission time of the vehicle state data in the historical simulation cycle. The historical latency threshold is determined based on the system network status (such as load rate, network latency, CPU utilization, etc.) within the corresponding historical simulation cycle. By comparing the historical time difference with the corresponding historical latency threshold, corresponding historical latency comparison results can be generated, providing input for subsequent multi-cycle timeliness analysis based on hysteresis characteristics.

[0087] Step S302: Determine the current time difference corresponding to the current simulation cycle based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data.

[0088] For example, the time difference between the simulation start time of the current simulation cycle and the first timestamp is calculated to obtain the current time difference corresponding to the current simulation cycle.

[0089] Step S303: Determine the current delay comparison result corresponding to the current simulation cycle based on the current time difference and the current delay threshold corresponding to the current simulation cycle.

[0090] The current latency threshold can be adaptively determined based on the system network status (such as load rate, network latency, CPU utilization, etc.) within the current simulation cycle. By dynamically adapting to changes in the operating environment, it can effectively improve the robustness and adaptability of the system under different operating conditions, avoiding misjudgments or performance degradation caused by a fixed threshold under high load or weak network conditions. The current latency comparison result can characterize the relationship between the current time difference and the current latency threshold.

[0091] Step S304: Based on the current delay comparison result and a preset number of historical delay comparison results, determine the timeliness result of the vehicle status data in the current simulation cycle.

[0092] In an exemplary embodiment, the method for determining the timeliness of vehicle state data in the current simulation cycle based on the current delay comparison result and a preset number of consecutive historical delay comparison results may be: based on preset state transition conditions, jointly analyze a preset number of consecutive historical delay comparison results and the current delay comparison result to determine the timeliness of vehicle state data in the current simulation cycle.

[0093] The preset state transition conditions include a first state transition condition, a second state transition condition, and a third state transition condition. The first state transition condition determines whether the timeliness result can transition from a "normal" state to an "alarm" state. The second state transition condition determines whether the timeliness result can further transition from an "alarm" state to a "failure" state. The third state transition condition determines whether the timeliness result can recover from any current state (including "normal," "alarm," or "failure") to a "normal" state. "Normal" indicates that the data delay is within an acceptable range and the data is valid. "Alarm" indicates that the data has a moderate delay, which may affect control accuracy and should be used with caution. "Failure" indicates that the data is severely lagging and is no longer suitable for the current simulation cycle; it should be discarded.

[0094] In an exemplary embodiment, based on preset state transition conditions, a joint analysis is performed on a preset number of consecutive historical delay comparison results and current delay comparison results to determine the timeliness of vehicle state data in the current simulation cycle, including:

[0095] If a preset number of historical delay comparison results and the current delay comparison result satisfy the first state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be an alarm.

[0096] The first state transition condition is that the first consecutive set of historical delay comparison results before the current simulation cycle all indicate that the historical time difference is greater than the historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold. The first set of numbers can be 2 or other values, which need to be set according to the actual timeliness analysis requirements, and are not specifically limited here.

[0097] For example, taking a first quantity of 2 as an example, if the historical delay comparison results of the two consecutive historical delays before the current simulation cycle both indicate that the historical time difference is greater than the corresponding historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold, that is, for three consecutive simulation cycles (the current simulation cycle and the two historical simulation cycles), the time difference corresponding to each simulation cycle is greater than the corresponding delay threshold, then the timeliness result can be changed from "normal" to "alarm", and at this time the timeliness result can be determined to be an alarm.

[0098] And / or, if a preset number of consecutive historical delay comparison results and the current delay comparison result satisfy the second state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be invalid.

[0099] The second state transition condition is that the second consecutive number of historical delay comparison results before the current simulation cycle all indicate that the historical time difference is greater than the historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold; the second number is greater than the first number, and the second number can be 4 or other values, which are not specifically limited here.

[0100] For example, taking a second quantity of 4 as an example, if the historical delay comparison results of the previous 4 consecutive simulation cycles all indicate that the historical time difference is greater than the corresponding historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold, that is, for 5 consecutive simulation cycles (the current simulation cycle and 4 historical simulation cycles), the time difference corresponding to each simulation cycle is greater than the corresponding delay threshold, then the timeliness result can be changed from "alarm" to "failure", and at this time the timeliness result can be determined to be failure.

[0101] And / or, if a preset number of consecutive historical delay comparison results and the current delay comparison result satisfy the third state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be normal.

[0102] The third state transition condition is that the third consecutive set of historical delay comparison results before the current simulation cycle all indicate that the historical time difference is less than or equal to the historical delay threshold, and the current delay comparison result indicates that the current time difference is less than or equal to the current delay threshold; the third set of numbers is greater than the second set of numbers, and the third set of numbers can be 9 or other values, which are not specifically limited here.

[0103] For example, taking a third quantity of 9 as an example, if the historical delay comparison results of the previous 9 consecutive simulation cycles all indicate that the historical time difference is less than or equal to the corresponding historical delay threshold, and the current delay comparison result indicates that the current time difference is less than or equal to the current delay threshold, that is, for 10 consecutive simulation cycles (the current simulation cycle and the 9 historical simulation cycles), the time difference corresponding to each simulation cycle is less than or equal to the corresponding delay threshold, then the timeliness result can be determined to be "normal", and at this time the timeliness result can be determined to be normal.

[0104] And / or, if a preset number of consecutive historical delay comparison results and the current delay comparison results do not meet the first state transition condition, the second state transition condition, and the third state transition condition, then the historical timeliness result of the previous simulation cycle will be determined as the timeliness result of the vehicle state data in the current simulation cycle.

[0105] For example, taking the historical timeliness result corresponding to the vehicle status data of the previous simulation cycle as an "alarm", if a preset number of consecutive historical delay comparison results and the current delay comparison results do not meet the first state transition condition, the second state transition condition, or the third state transition condition, in this case, the system determines that there is insufficient evidence to support the state change. Therefore, the historical timeliness result "alarm" corresponding to the vehicle status data of the previous simulation cycle is directly inherited as the timeliness result corresponding to the vehicle status data in the current simulation cycle.

[0106] In the above embodiments, by introducing preset state transition conditions based on a multi-level hysteresis mechanism and combining multiple consecutive historical delay comparison results with the current delay comparison result for joint judgment, the stability, robustness and anti-interference ability of the timeliness state label recognition are effectively improved. This avoids state misjudgment caused by single instantaneous delay jitter. By setting the first number to be less than the second number and the second number to be less than the third number, it is ensured that the alarm level can be upgraded in time when continuous degradation occurs, and that recovery to the normal state is only allowed after long-term stable compliance. This effectively reduces state oscillation and enhances the reliability and timing decision accuracy of the system in complex network or high-load environments.

[0107] In one embodiment, such as Figure 4 As shown, Figure 4 This is a flowchart illustrating the timeliness analysis steps in another embodiment. Based on the above embodiment, and using the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data, a timeliness analysis is performed on the vehicle state data to determine the timeliness result of the vehicle state data in the current simulation cycle. This includes the following steps:

[0108] Step S401: If the current simulation cycle is the first simulation cycle, determine the current time difference corresponding to the current simulation cycle based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data.

[0109] Step S402: Determine the current delay comparison result corresponding to the current simulation cycle based on the current time difference and the current delay threshold corresponding to the current simulation cycle.

[0110] For example, the time difference between the simulation start time and the first timestamp of the current simulation cycle is calculated to obtain the current time difference corresponding to the current simulation cycle. The current time difference is then compared with the current delay threshold to obtain the current delay comparison result. The current delay threshold is determined based on the system network state within the current simulation cycle.

[0111] Step S403: If the current delay comparison result is that the current time difference is greater than the current delay threshold, then the timeliness result of the vehicle status data in the current simulation cycle is determined to be an alarm.

[0112] Step S404: If the current delay comparison result is that the current time difference is less than or equal to the current delay threshold, then the timeliness result of the vehicle status data in the current simulation cycle is determined to be normal.

[0113] For example, suppose the system starts up and enters its first simulation cycle (i.e., the current simulation cycle is cycle 1), at which point there are no historical latency comparison results available for reference. The system obtains the simulation start time of the current simulation cycle as T_curr, and the first timestamp carried by the vehicle status data is T1. The time difference between the two is calculated as ΔT = T_curr - T1. Assuming that the current latency threshold in the current simulation cycle is determined to be Tth = 15ms based on the current network status information, if ΔT is found to be greater than Tth = 15ms, the timeliness result of the vehicle status data in the current simulation cycle is directly determined as "alarm"; if ΔT is found to be less than or equal to Tth = 15ms, the timeliness result of the vehicle status data in the current simulation cycle is directly determined as "normal".

[0114] The above embodiments address the timeliness determination of the first simulation cycle. By directly comparing the current time difference with the current delay threshold, the timeliness result of the vehicle state data in the current simulation cycle can be quickly determined without relying on historical states during the system startup phase. This effectively avoids misjudgments or uncertain judgments caused by missing states. At the same time, this mechanism is seamlessly integrated with the subsequent hysteresis state transition strategy based on multi-cycle history, ensuring that the timeliness determination of the system from initialization to steady-state operation has completeness, consistency and robustness.

[0115] In one embodiment, such as Figure 5 As shown, Figure 5This is a flowchart illustrating the steps for determining the data packet to be simulated in one embodiment. Based on the above embodiment, and based on the timeliness results, the data packet to be simulated in the current simulation cycle is determined according to vehicle status data, environmental perception data, and historical simulation data packets from the previous simulation cycle, including the following steps:

[0116] Step S501: If the timeliness result is normal, then determine the data packet to be simulated in the current simulation cycle based on the vehicle status data and environmental perception data.

[0117] The environmental perception data includes multiple consecutive frames of initial environmental data, each frame of which has a corresponding third timestamp. The initial environmental data may include, but is not limited to, the status of surrounding vehicles (such as position, speed, heading angle, etc.), traffic participant information (such as pedestrians, cyclists), static environmental elements (such as lane lines, traffic signs, traffic light status), and sensor simulation outputs (such as camera images, millimeter-wave radar point clouds, lidar point clouds, etc.).

[0118] In an exemplary embodiment, if the timeliness result is normal in step S501, then based on the vehicle status data and environmental perception data, the data package to be simulated for the current simulation cycle is determined, including the following steps:

[0119] Step 1: Perform interpolation calculations based on each third timestamp and each initial environmental data to obtain target environment perception data that is time-sequentially aligned with the simulation start time of the current simulation cycle.

[0120] The initial environmental data is generated by the scene simulation unit. To effectively control extrapolation errors, the rendering frame rate of the scene simulation unit is required to be no less than the preset minimum frame rate (e.g., 20Hz, i.e., the interval between each frame is ≤50ms). This allows for the acquisition of sufficiently dense raw time-series data, providing a high-temporal-resolution input basis for subsequent interpolation calculations. This limits the extrapolation error to an acceptable range for the system, ensuring that the target environment perception data ultimately transmitted to the intelligent driving control unit has high quality and high reliability.

[0121] It should be noted that the rendering output frame rate of the scene simulation unit is usually affected by the scene complexity and fluctuates, resulting in the initial environmental data not being generated at strictly equal intervals. Therefore, the time interval between the third timestamps carried by multiple consecutive frames of initial environmental data may be variable, exhibiting a variable step size characteristic. However, intelligent driving control units typically operate with a fixed simulation step size (such as a simulation cycle every 10ms or 20ms), requiring strictly time-aligned environmental perception input at the start of each simulation cycle to ensure the determinism and temporal consistency of the algorithm chain (including perception fusion, prediction, decision-making, and planning).

[0122] To resolve the contradiction between variable step size output and fixed step size requirements, this application employs a linear interpolation algorithm: Assuming the simulation start time of the current simulation cycle is 10ms, and the third timestamps of the initial environmental data in two adjacent frames are t_k and t_{k+1}, where t_k < t < t_{k+1}, the target environmental perception data required for the simulation start time t = 10ms is calculated using the following formula:

[0123] Scene_Data(t)=Scene_Data(t_k)+(t-t_k)×[Scene_Data(t_{k+1})-Scene_Data(t_k)] / (t_{k+1}-t_k);

[0124] Where Scene_Data(t_k) represents the initial environmental data output by the scene simulation unit at time t_k; Scene_Data(t_{k+1}) represents the initial environmental data output by the scene simulation unit at time t_{k+1}. By introducing interpolation calculation, the algorithm input timing jitter and spectral artifacts caused by uneven input data frame intervals can be effectively eliminated, providing a stable and uniform input sequence for intelligent driving decision analysis, and improving the accuracy and reliability of simulation verification.

[0125] Step 2: Encapsulate the target environment perception data and vehicle status data to obtain the simulation data package for the current simulation cycle.

[0126] In an exemplary embodiment, before encapsulating the target environment perception data and vehicle status data in step 2, the method further includes: obtaining the vehicle status communication message corresponding to the vehicle simulation model within the current simulation cycle, parsing the vehicle status communication message to obtain the vehicle status data for the current simulation cycle. The vehicle status communication message is generated by the communication bus simulation unit; it carries the vehicle status data corresponding to the vehicle simulation model; the vehicle status data may include, but is not limited to, position, speed, acceleration, heading angle, yaw rate, etc. The vehicle status communication message may be a CAN bus message. Simultaneously, the vehicle status communication message carries a first timestamp.

[0127] In an exemplary embodiment, the method for generating and transmitting vehicle status communication messages can be as follows: The CANoe bus simulation platform in the communication bus simulation unit, based on a preset communication protocol format, structurally encapsulates vehicle status data (such as vehicle speed, acceleration, yaw rate, steering wheel angle, etc.) generated from the vehicle dynamics model, generating vehicle status communication messages conforming to the vehicle network specification. After encapsulation, a first timestamp is marked on the vehicle status communication message to identify the data transmission time of the vehicle status communication message (i.e., vehicle status data). Subsequently, the vehicle status communication message carrying the first timestamp is sent to the intelligent driving control unit, enabling the intelligent driving control unit to obtain the vehicle status data for the current simulation cycle by parsing the vehicle status communication message. The preset communication protocol format can be, but is not limited to, the CAN communication protocol format; the specific form needs to be set according to actual simulation requirements and is not specifically limited here. For example, a DBC (Database CAN) database file can be used to describe the communication protocol on the CAN bus.

[0128] In an exemplary embodiment, step 2, which encapsulates the target environment perception data and vehicle state data to obtain the data packet to be simulated in the current simulation cycle, can be as follows: based on a preset data encapsulation format, the target environment perception data and vehicle state data are encapsulated to obtain the data packet to be simulated in the current simulation cycle; wherein, the preset data encapsulation format can adopt a standardized data structure, such as the UnifiedDataPacket data packet format.

[0129] The above embodiments employ an interpolation algorithm to strictly align the variable-step initial environmental perception data output by the scene simulation unit to the fixed simulation step time reference of the intelligent driving control unit. This effectively eliminates the timing jitter of the algorithm input caused by the unstable output interval of the data source, compressing the timing uncertainty introduced by the scene simulation unit to a preset time range (e.g., within ±1ms), laying the foundation for improving the accuracy and reliability of algorithm simulation verification. Simultaneously, by parsing the vehicle status communication message carrying the first timestamp, not only is the vehicle status data obtained, but its precise timestamp is also preserved, providing a basis for subsequent timeliness analysis. Finally, the target environmental perception data and vehicle status data are encapsulated into a unified format data packet to be simulated, meeting the input data requirements of intelligent driving decision-making.

[0130] In step S502, if the timeliness result is invalid, the historical simulation data packet of the previous simulation cycle is determined as the simulation data packet of the current simulation cycle.

[0131] If the vehicle status data is deemed invalid, the historical simulation data packet from the previous simulation cycle is used as the simulation data packet for the current simulation cycle. This ensures that subsequent intelligent driving decision analysis will not be based on invalid vehicle status data, guaranteeing the reliability of the input data for intelligent driving decision analysis. Furthermore, using the historical simulation data packet from the previous simulation cycle as the simulation data packet for the current simulation cycle avoids simulation interruptions caused by data loss and prevents decision biases resulting from directly using invalid vehicle status data.

[0132] Step S503: If the timeliness result is an alarm, then determine the candidate simulation data package based on the vehicle status data and environmental perception data.

[0133] It should be noted that the method for determining the candidate simulation data packet in this embodiment is in the same principle as the method for determining the simulation data packet for the current simulation cycle described in step S501 of the above embodiment, and will not be repeated here.

[0134] Understandably, candidate simulation data packets are potential simulation data packets generated based on vehicle state data and environmental perception data acquired within the current simulation cycle. They need to be combined with historical simulation data packets from the previous simulation cycle for comprehensive decision-making to determine the final simulation data packet, ensuring an optimal balance between timeliness and continuity in the intelligent driving decision analysis input data. It should be noted that while candidate simulation data packets offer greater timeliness, they may suffer from discontinuity between data frames. In contrast, historical simulation data packets from the previous simulation cycle, although involved in the previous cycle's decision-making, have a verified connection between their data characteristics and the current vehicle simulation model's state evolution trajectory, effectively mitigating the low decision accuracy caused by discontinuity between data frames. Therefore, by comprehensively weighing candidate simulation data packets against historical simulation data packets from the previous simulation cycle, an optimal balance between timeliness and inter-frame continuity can be achieved, thereby ensuring the reliability of the intelligent driving decision input data.

[0135] Step S504: Determine the data packet to be simulated in the current simulation cycle based on the candidate simulation data packet and the historical simulation data packet from the previous simulation cycle.

[0136] In an exemplary embodiment, step S504 determines the data packet to be simulated in the current simulation cycle based on the candidate simulation data packet and the historical simulation data packet from the previous simulation cycle, including the following steps:

[0137] Step 1: Obtain the priority of historical data packets to be simulated.

[0138] Among them, the historical data packets to be simulated refer to the valid simulation data packets that participated in the intelligent driving decision analysis in the previous simulation cycle of the current simulation cycle; the historical data packets to be simulated are cached in the historical data packet queue; the historical data packet queue is maintained by the buffer scheduling module in the intelligent driving control unit; the buffer scheduling module includes a circular buffer; the circular buffer is a first-in-first-out (FIFO) queue with a fixed depth (e.g., a depth of 32 frames) used to temporarily cache several recent valid historical data packets.

[0139] The historical simulation data packet includes multiple historical parameters. The priority of the historical simulation data packet is determined based on the combined priorities of all historical parameters within it. Specifically, the priority of the historical parameter value corresponding to each historical parameter in the historical simulation data packet is determined as the priority of the corresponding historical parameter. Furthermore, the highest priority among the priorities of all historical parameters in the historical simulation data packet is determined as the priority of the historical simulation data packet. In some embodiments, the priority of the historical parameter value corresponding to a historical parameter can be determined according to a preset correspondence between parameter values ​​and priorities. This preset correspondence needs to be determined based on actual decision-making requirements and is not specifically limited here. For example, a historical parameter might be a traffic light status, and the corresponding parameter value could be red, green, or yellow. The priorities of red, green, and yellow, from highest to lowest, are: red light has the highest priority (Level 1), yellow light has the next highest priority (Level 2), and green light has the lowest priority (Level 3). Taking a red traffic light status as an example, the priority of the historical parameter can be determined as Level 1.

[0140] Step 2: Determine the priority of the candidate simulation data packet based on the priority of all parameters in the candidate simulation data packet.

[0141] The principle for determining the priority of candidate simulation data packets is the same as that for determining the priority of historical simulation data packets in the above embodiments. Specifically, step 2, which determines the priority of candidate simulation data packets based on the priorities of all parameters in the candidate simulation data packets, can be as follows: based on a preset correspondence between parameter values ​​and priorities, determine the priority of each parameter value corresponding to each parameter in the candidate simulation data packets; determine the priority of each parameter value corresponding to each parameter in the candidate simulation data packets as the priority of the corresponding parameter in the candidate simulation data packets; and determine the highest priority among the priorities corresponding to each parameter in the candidate simulation data packets as the priority of the candidate simulation data packets.

[0142] Step 3: Based on the priority of historical data packets to be simulated and the priority of candidate data packets to be simulated, determine the data packets to be simulated for the current simulation cycle from the historical data packets to be simulated and the candidate data packets to be simulated.

[0143] In an exemplary embodiment, step 3, based on the priority of historical simulation data packets and the priority of candidate simulation data packets, determines the simulation data packet for the current simulation period from the historical simulation data packets and candidate simulation data packets. This method may be as follows: if the priority of the historical simulation data packet from the previous simulation period is higher than or equal to the priority of the candidate simulation data packet, then the historical simulation data packet from the previous simulation period is determined as the simulation data packet for the current simulation period; if the priority of the historical simulation data packet from the previous simulation period is lower than the priority of the candidate simulation data packet, then the candidate simulation data packet is determined as the simulation data packet for the current simulation period.

[0144] It should be noted that determining the data packets to be simulated in the current simulation cycle based on priority can reduce the packet loss rate of safety-critical perception data (such as forward collision warning signals) from >5% to <0.1% while ensuring the real-time performance of the system. This ensures that the safety-critical algorithm can obtain continuous and complete environmental perception input in the simulation verification, thereby improving the reliability and confidence of the verification results.

[0145] In the above embodiments, by dividing the timeliness results of vehicle status data into three levels—normal, alarm, and failure—and implementing differentiated methods for determining the simulation data packets for different timeliness results, hierarchical and refined management of intelligent driving decision input data is achieved. Specifically, when the timeliness result is normal, the vehicle status data and environmental perception data obtained in the current simulation cycle are directly used to generate the simulation data packets, ensuring that the decision input has optimal timeliness. When the timeliness result is failure, the historical simulation data packets that have been verified to be effective in the previous simulation cycle are directly reused to avoid accuracy degradation caused by the participation of failure data in decision-making. When the timeliness result is alarm, a competitive selection mechanism between candidate simulation data packets and historical simulation data packets is introduced to dynamically balance timeliness and the continuity of state evolution. This not only preserves the freshness advantage of real-time data but also suppresses the potential inter-frame jump risk of edge timeliness data through the alternative support of historical simulation data packets. This covers all scenarios of vehicle status data timeliness, ensuring that there is always a suitable data package to be simulated entering the intelligent driving decision analysis stage at any time, thereby comprehensively improving the reliability, timeliness and stability of decision input data during the software-in-the-loop verification process.

[0146] In one specific embodiment, the software-in-the-loop verification method is applied to, for example... Figure 1The software-in-the-loop verification system illustrated here is an example. This system includes an intelligent driving control unit, a communication bus simulation unit, and a scenario simulation unit. The intelligent driving control unit utilizes the Scilab / Xcos open-source algorithm platform; the communication bus simulation unit includes a CANoe bus simulation platform and an integrated vehicle dynamics model; and the scenario simulation unit uses the CARLA open-source scenario simulation platform. It is understood that in other embodiments, the vehicle dynamics model can also be deployed in the intelligent driving control unit or the scenario simulation unit. This embodiment's software-in-the-loop verification method can form a complete real-time synchronous closed loop, specifically including the following steps:

[0147] Step 1, Initial Environment Data Generation and Transmission: The CARLA open-source scene simulation platform sends the generated initial environment data (including image sequences, radar point clouds, target lists, and other sensor data) to the Scilab / Xcos open-source algorithm platform in real time via the Python API interface. This process ensures real-time data transmission through the UDP protocol, with latency controlled at the millisecond level.

[0148] Step 2, Intelligent Driving Algorithm Decision: For the current simulation cycle, the ADAS control algorithm model in the Scilab / Xcos open-source algorithm platform receives initial environmental data from the CARLA open-source scenario simulation platform and vehicle status communication messages carrying the first timestamp from the CANoe bus simulation platform. The corresponding vehicle status data is obtained by parsing the vehicle status communication messages. Based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data, a data timeliness analysis is performed on the vehicle status data to determine the timeliness result of the vehicle status data in the current simulation cycle. If the timeliness result is normal, the data packet to be simulated in the current simulation cycle is determined based on the vehicle status data and environmental perception data. If the timeliness result is invalid, the historical simulation data packet from the previous simulation cycle is determined as the data packet to be simulated in the current simulation cycle. If the timeliness result is an alarm, candidate simulation data packets are determined based on the vehicle status data and environmental perception data. Finally, the data packet to be simulated in the current simulation cycle is determined based on the candidate simulation data packets and the historical simulation data packets from the previous simulation cycle. Based on the simulated data packets, intelligent driving decision analysis (such as following, lane changing, braking, etc.) is performed to generate simulated vehicle control commands (such as steering angle, throttle opening, braking pressure), and these commands are encapsulated to obtain control command packets. The Scilab / Xcos open-source algorithm platform sends the control command packets carrying the simulated vehicle control commands to the vehicle dynamics model through a return interface (supporting shared memory or UDP protocol). The return interface employs a zero-copy design to minimize latency: the simulated vehicle control commands are directly written to a pre-allocated and mapped shared memory area, and the CAPL script on the CANoe side directly reads this memory address via @sysvar::, completely avoiding the serialization, deserialization, and copy overhead of traditional network protocol stacks. Experimental results show that this mechanism reduces the return latency from 15-20ms in conventional Socket communication to less than 8ms.

[0149] Step 3, Vehicle State Update Calculation: After receiving the control command packet carrying the simulated vehicle control command, the vehicle dynamics model calculates new vehicle state data (including position, speed, acceleration, yaw rate, etc.) based on the simulated vehicle control command. At the same time, the CANoe bus simulation platform assembles the new vehicle state data into a vehicle state communication message, i.e., a standard CAN bus message, according to the DBC file specification of the actual vehicle, and marks the vehicle state communication message with the first timestamp T1.

[0150] Step 4, State Feedback and Closed-Loop Update: New vehicle state data is fed back through two paths: Path 1, real-time feedback to the CARLA open-source scene simulation platform to drive the motion update of the vehicle simulation model in the 3D scene; Path 2, sent back to the Scilab / Xcos open-source algorithm platform via the simulation CAN bus to provide input for the algorithm decision in the next simulation cycle.

[0151] Through the cyclical execution of the above steps, the system forms a complete real-time synchronous closed-loop verification environment encompassing "environmental perception - algorithm decision-making - vehicle execution - status feedback." Each cycle is strictly controlled within a fixed step size of 10 milliseconds to ensure the accuracy and real-time performance of the ADAS algorithm verification.

[0152] It should be noted that during the closed-loop verification process, the system dynamically adjusts the current delay threshold of the synchronization criterion based on the real-time load and uses a PI controller to periodically (e.g., once per second) correct long-term micro-drifts between multiple tools. This reduces the maximum clock synchronization error between the three toolchains—CANoe, CARLA, and Scilab / Xcos—from the traditional 200ms level to less than 15ms, making it possible to verify the behavior of ADAS algorithms at the software level under precise time constraints (such as the time tolerance required by the ISO 26262 standard), greatly improving the timing reliability of the simulation results.

[0153] In some embodiments, an event-time hybrid triggering mechanism can also be introduced in the intelligent driving control unit; the execution of the Scilab / Xcos solver is triggered by both the "arrival of a valid simulation data packet" event and constrained by the clock synchronization pulse generated at each fixed step size (e.g., 10ms). The two are activated by "OR" logic, which ensures that the algorithm model can run at a strict fixed step size (hard real-time) and allows calculation in advance when the data is ready, avoiding resource waste caused by waiting for fixed clock pulses (zero overrun). This ensures the efficiency and timing determinism of the simulation process, making the results of multiple runs of the same test scenario highly repeatable with a standard deviation of <2%, fully meeting the stringent consistency requirements of algorithm iterative development and regression testing.

[0154] In one embodiment, see Figure 1 Furthermore, a software-in-the-loop verification system is provided, which includes an intelligent driving control unit, a communication bus simulation unit, and a scenario simulation unit; the intelligent driving control unit is connected to the communication bus simulation unit and the scenario simulation unit respectively.

[0155] The scenario simulation unit is used to generate initial environmental data and send the initial environmental data to the intelligent driving control unit;

[0156] The communication bus simulation unit is used to generate a vehicle status communication message carrying a first timestamp based on the received vehicle status data, and send the vehicle status communication message to the intelligent driving control unit.

[0157] The intelligent driving control unit is used to execute the software-in-the-loop verification method described in any of the above embodiments.

[0158] It should be noted that the specific limitations of the intelligent driving control unit, communication bus simulation unit, and scenario simulation unit can be found in the above description of the specific limitations of the intelligent driving control unit, communication bus simulation unit, and scenario simulation unit, and will not be repeated here.

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

[0160] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, the computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to software-in-the-loop verification. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a software-in-the-loop verification method.

[0161] Those skilled in the art will understand that Figure 6The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0162] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0163] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0164] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0165] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0166] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0167] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0168] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A software-in-the-loop verification method, characterized in that, An intelligent driving control unit applied in a software-in-the-loop verification system; the method includes: Acquire environmental perception data and vehicle status data corresponding to the vehicle simulation model within the current simulation cycle; Based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data, a data timeliness analysis is performed on the vehicle status data to determine the timeliness result of the vehicle status data in the current simulation cycle. Based on the timeliness results, the data packet to be simulated in the current simulation cycle is determined according to the vehicle status data, the environmental perception data, and the historical simulation data packet from the previous simulation cycle. Based on the data packet to be simulated, intelligent driving decision analysis is performed to generate simulated vehicle control commands to drive the autonomous vehicle simulation model to update the vehicle state.

2. The method according to claim 1, characterized in that, The method of performing data timeliness analysis on the vehicle state data based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data, and determining the timeliness result of the vehicle state data in the current simulation cycle, includes: If the current simulation cycle is not the first simulation cycle, obtain the historical delay comparison results corresponding to a preset number of consecutive historical simulation cycles preceding the current simulation cycle; wherein, the historical delay comparison result corresponding to each historical simulation cycle is used to characterize the relationship between the historical time difference corresponding to the historical simulation cycle and the historical delay threshold corresponding to the historical simulation cycle; the historical time difference refers to the time difference between the simulation start time of the historical simulation cycle and the second timestamp corresponding to the vehicle state data of the historical simulation cycle. The current time difference corresponding to the current simulation cycle is determined based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle status data. Based on the current time difference and the current delay threshold corresponding to the current simulation cycle, determine the current delay comparison result corresponding to the current simulation cycle; Based on the current delay comparison result and a preset number of consecutive historical delay comparison results, the timeliness result of the vehicle status data in the current simulation cycle is determined.

3. The method according to claim 2, characterized in that, The step of determining the timeliness result of the vehicle status data in the current simulation cycle based on the current delay comparison result and a preset number of consecutive historical delay comparison results includes: If a predetermined number of consecutive historical delay comparison results and the current delay comparison result satisfy the first state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be an alarm; the first state transition condition is that a predetermined number of consecutive historical delay comparison results prior to the current simulation cycle all indicate that the historical time difference is greater than the historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold; and / or, If a predetermined number of consecutive historical delay comparison results and the current delay comparison result satisfy the second state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be invalid; the second state transition condition is that a second consecutive number of historical delay comparison results prior to the current simulation cycle all indicate that the historical time difference is greater than the historical delay threshold, and the current delay comparison result indicates that the current time difference is greater than the current delay threshold; and / or, If a predetermined number of consecutive historical delay comparison results and the current delay comparison result satisfy the third state transition condition, then the timeliness result of the vehicle state data in the current simulation cycle is determined to be normal; the third state transition condition is that the third consecutive number of historical delay comparison results before the current simulation cycle all indicate that the historical time difference is less than or equal to the historical delay threshold, and the current delay comparison result indicates that the current time difference is less than or equal to the current delay threshold; and / or, If a preset number of consecutive historical delay comparison results and the current delay comparison results do not satisfy the first state transition condition, the second state transition condition, and the third state transition condition, then the historical timeliness result of the previous simulation cycle is determined as the timeliness result of the vehicle state data in the current simulation cycle. The first quantity is less than the second quantity, and the second quantity is less than the third quantity.

4. The method according to claim 1, characterized in that, The method of performing data timeliness analysis on the vehicle state data based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data, and determining the timeliness result of the vehicle state data in the current simulation cycle, includes: If the current simulation cycle is the first simulation cycle, the current time difference corresponding to the current simulation cycle is determined based on the simulation start time of the current simulation cycle and the first timestamp corresponding to the vehicle state data. Based on the current time difference and the current delay threshold corresponding to the current simulation cycle, determine the current delay comparison result corresponding to the current simulation cycle; If the current delay comparison result is that the current time difference is greater than the current delay threshold, then the timeliness result of the vehicle status data in the current simulation cycle is determined to be an alarm. If the current delay comparison result is that the current time difference is less than or equal to the current delay threshold, then the timeliness result of the vehicle status data in the current simulation cycle is determined to be normal.

5. The method according to claim 1, characterized in that, Based on the timeliness result, the method of determining the simulation data packet for the current simulation cycle according to the vehicle status data, the environmental perception data, and the historical simulation data packet from the previous simulation cycle includes: If the timeliness result is normal, then the data packet to be simulated for the current simulation cycle is determined based on the vehicle status data and the environmental perception data. If the timeliness result is invalid, then the historical simulation data packet of the previous simulation cycle is determined as the simulation data packet of the current simulation cycle; If the timeliness result is an alarm, then candidate simulation data packets are determined based on the vehicle status data and the environmental perception data; Based on the candidate simulation data packets and the historical simulation data packets from the previous simulation cycle, the data packets to be simulated in the current simulation cycle are determined.

6. The method according to claim 5, characterized in that, The environmental perception data includes multiple consecutive frames of initial environmental data, each frame of which corresponds to a third timestamp; if the timeliness result is normal, then based on the vehicle status data and the environmental perception data, the data packet to be simulated for the current simulation cycle is determined, including: Interpolation calculations are performed based on each of the third timestamps and each of the initial environmental data to obtain target environmental perception data that is time-sequentially aligned with the simulation start time of the current simulation cycle. The target environment perception data and the vehicle state data are encapsulated to obtain the simulation data package for the current simulation cycle.

7. The method according to claim 5, characterized in that, The environmental perception data includes multiple consecutive frames of initial environmental data, each frame of initial environmental data corresponding to a third timestamp; determining the simulation data packet for the current simulation period based on the candidate simulation data packet and the historical simulation data packet from the previous simulation period includes: Obtain the priority of the historical data packets to be simulated; The priority of the candidate simulation data packet is determined based on the priority of all parameters in the candidate simulation data packet; Based on the priority of the historical data packets to be simulated and the priority of the candidate data packets to be simulated, the data packets to be simulated for the current simulation period are determined from the historical data packets to be simulated and the candidate data packets to be simulated.

8. A software-in-the-loop verification system, characterized in that, The system includes an intelligent driving control unit; The intelligent driving control unit is used to execute the software-in-the-loop verification method according to any one of claims 1 to 7.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images