Vehicle bus data generation method and device, electronic equipment and storage medium

Abstract

The invention provides a vehicle bus data generation method and device, electronic equipment and a storage medium, belongs to the technical field of vehicle data generation, and can generate a local field sequence in a demand scene through a data generation model according to obtained historical bus data, and solve a vehicle physical engine solution model to obtain a vehicle bus data generation result. The technical bottleneck of single generation or solution is broken through based on physical constraint reverse solution, data diversity and physical rationality are considered through interactive verification of a large model and a physical engine, timestamp alignment is performed on the local field sequence and the associated field, time sequence association of the data is realized, and the data processing efficiency is improved. And the generation of analog bus data with high noise, fault tolerance, low delay and strong diversity is realized.

Description

Technical Field

[0001] The present application relates to the technical field of vehicle data generation, and in particular to a method, device, electronic device, and storage medium for generating vehicle bus data. Background Art

[0002] In the development and testing process of vehicle electronic systems, the acquisition and verification of CAN bus data is a core link. CAN bus data is generally obtained through actual vehicle testing. However, this method of obtaining CAN bus data through actual vehicle testing is costly and time-consuming, and cannot cover all usage scenarios, resulting in vehicle bus data being unable to meet user usage needs. Summary of the Invention

[0003] In view of this, the purpose of the present application is to provide a method, device, electronic device and storage medium for generating vehicle bus data, so as to generate vehicle bus data that meets user needs.

[0004] Based on the above objectives, the present application provides a method for generating vehicle bus data, comprising:

[0005] capturing vehicle status data in real time, and determining data constraints based on the vehicle status data;

[0006] Acquiring historical bus data, determining vehicle performance parameters of the vehicle model to be tested, and inputting the historical bus data and vehicle performance parameters into a pre-trained data generation model so that the data generation model outputs a local field sequence under the data constraints;

[0007] Taking the local field sequence as a boundary condition, determining the associated fields corresponding to the local field sequence according to vehicle operating parameters and a physical engine solution model;

[0008] The local field sequence and the associated field are time stamp aligned to obtain simulated bus data.

[0009] Optionally, the method for generating vehicle bus data further includes:

[0010] determining a standardized text file corresponding to the historical bus data;

[0011] Performing message format verification, signal attribute verification, and communication rule verification on the simulated bus data according to the standardized text file to obtain a verification result;

[0012] In response to the absence of unqualified check items in the check result, performing a logic check on the analog bus data, and storing the analog bus data after passing the logic check;

[0013] Optionally, the method for generating vehicle bus data further includes:

[0014] In response to the presence of unqualified verification items in the verification results, the data generation model and the physical engine solution model are optimized according to the unqualified verification items.

[0015] Optionally, performing logic verification on the analog bus data includes:

[0016] Reversely inputting the simulated bus data into a vehicle simulation platform, so that the vehicle simulation platform performs simulation operation according to the signal chain causal relationship of the simulated bus data and outputs the operation result;

[0017] In response to the running result being a simulation running failure, the data generation model and the physical engine solving model are optimized according to the running result.

[0018] Optionally, the performing logic verification on the analog bus data further includes:

[0019] In response to the running result being that the simulation runs successfully, determining that the logic check passes;

[0020] By supplementing the result verification process to further ensure that the analog bus data does not have protocol compliance issues, it is also ensured that the analog bus data does not have problems that do not comply with physical laws, so as to improve the compliance and logic of the analog bus data.

[0021] Optionally, the data constraint condition includes a value range constraint condition and a change rate constraint condition; and determining the data constraint condition based on the vehicle state data includes:

[0022] determining a simulation control scenario according to the vehicle state data;

[0023] Adjusting the boundary value of the standard value range according to the simulation control scenario to obtain the value range constraint condition;

[0024] The boundary value of the standard change rate range is adjusted according to the simulation control scenario to obtain the change rate constraint condition.

[0025] Adjust the standard range according to the simulation control scenario to determine the data constraints that meet different simulation control scenarios, ensure that each simulation control scenario has separate data constraints, and ensure the accuracy of the simulation bus data generated in each simulation control scenario.

[0026] Optionally, the physical engine solution model includes a dynamic model and a thermodynamic model, and the associated fields include a dynamic associated field and a thermodynamic associated field; and determining the associated fields corresponding to the local field sequence based on the vehicle operating parameters and the physical engine solution model using the local field sequence as a boundary condition includes:

[0027] Classifying the vehicle operating parameters to obtain kinetic parameters and thermodynamic parameters;

[0028] Determining a dynamic boundary condition corresponding to the dynamic parameter in the local field sequence, so that the dynamic model outputs the dynamic association field under the dynamic boundary condition;

[0029] Thermodynamic boundary conditions corresponding to the thermodynamic parameters are determined in the local field sequence, so that the thermodynamic model can output the thermodynamically associated fields under the thermodynamic boundary conditions.

[0030] Using a physics engine to solve the model generates associated fields, ensuring that the simulated bus data meets the physical requirements of dynamics and thermodynamics. Combining the data generation model with the physics engine's solution model enables collaborative generation and solution, breaking through the technical bottleneck of either single generation or solution. Through interactive verification between the large model and the physics engine, it balances data diversity with physical rationality.

[0031] Optionally, aligning the timestamps of the local field sequence and the associated field to obtain simulated bus data includes:

[0032] Writing the local field sequence into a first buffer queue, and writing the associated field into a second buffer queue; wherein the first buffer queue and the second buffer queue are independent of each other;

[0033] determining a time difference threshold according to a first writing cycle of the local field sequence and a second writing cycle of the associated field;

[0034] Data is extracted synchronously in the first buffer queue and the second buffer queue according to the time difference threshold to obtain the analog bus data.

[0035] A dual-buffered queue alternating read / write mechanism decouples data production and consumption. Separate buffer queues are allocated for the data generation model and the physics engine solver model, each temporarily storing their respective data streams. On the production side of the dual-buffered queues, real-time output data from the data generation model and the physics engine solver model is written to their respective buffer queues, preventing interference. On the consumer side of the dual-buffered queues, a synchronization thread extracts data from both queues, aligning timestamps and ensuring the timing of the analog bus data.

[0036] Optionally, determining the time difference threshold according to the first writing cycle of the local field sequence and the second writing cycle of the associated field includes:

[0037] determining a cycle time difference between the first writing cycle and the second writing cycle;

[0038] In response to the cycle time difference being greater than a preset difference threshold, determining a low-frequency writing cycle and a high-frequency writing cycle in the first writing cycle and the second writing cycle;

[0039] Interpolation compensation is performed according to the low-frequency write cycle to obtain interpolation compensation data and compensation time, the interpolation compensation data is written into a buffer queue corresponding to the low-frequency write cycle, and the compensation cycle is determined according to the compensation time and the low-frequency write cycle, and the least common multiple of the compensation cycle and the high-frequency write cycle is determined as the time difference threshold.

[0040] When the period time difference is greater than the preset difference threshold, difference compensation is used to avoid data loss caused by excessive period difference and improve the accuracy of timestamp alignment.

[0041] Optionally, determining the time difference threshold according to the first writing cycle of the local field sequence and the second writing cycle of the associated field includes:

[0042] determining a cycle time difference between the first writing cycle and the second writing cycle;

[0043] In response to the cycle time difference being less than or equal to a preset difference threshold, a least common multiple of the first writing cycle and the second writing cycle is determined as the time difference threshold.

[0044] When the cycle time difference is less than or equal to the difference threshold, the cycle difference is small. Directly determining the least common multiple of the first write cycle and the second write cycle as the time difference threshold will not cause data loss, omitting the difference compensation process, and improving the alignment efficiency of the timestamp alignment process.

[0045] Based on the same inventive concept, the present disclosure also provides a device for generating vehicle bus data, comprising:

[0046] The constraint determination module is configured to: capture vehicle status data in real time and determine data constraint conditions based on the vehicle status data;

[0047] a data generation module configured to: acquire historical bus data, determine vehicle performance parameters of a vehicle model to be tested, and input the historical bus data and vehicle performance parameters into a pre-trained data generation model so that the data generation model outputs a local field sequence under the data constraints;

[0048] A data solving module is configured to: determine, using the local field sequence as a boundary condition, an associated field corresponding to the local field sequence according to vehicle operating parameters and a physical engine solving model;

[0049] The time alignment module is configured to: perform time stamp alignment on the local field sequence and the associated field to obtain simulated bus data.

[0050] Based on the same inventive concept, the present disclosure also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor implements the above-mentioned method when executing the computer program.

[0051] Based on the same inventive concept, the present disclosure further provides a non-transitory computer-readable storage medium, which stores computer instructions for causing a computer to execute the method described above.

[0052] As can be seen from the above, the vehicle bus data generation method, device, electronic device, and storage medium provided by this application capture vehicle status data in real time and determine data constraints based on the vehicle status data; obtain historical bus data to determine vehicle performance parameters of the vehicle model to be tested; and input the historical bus data and vehicle performance parameters into a pre-trained data generation model, so that the data generation model outputs a local field sequence under the data constraints; using the local field sequence as a boundary condition, the associated fields corresponding to the local field sequence are determined based on vehicle operating parameters and a physical engine solution model; and the local field sequence and the associated fields are timestamp-aligned to obtain simulated bus data. By determining the boundary limits of generated simulated bus data through the constraints, the generated data is prevented from being significantly inconsistent with reality, ensuring that the generated simulated bus data does not exceed the performance range of the real vehicle, achieving a strict mapping between the data generation process and the real vehicle performance, and providing simulated bus data that conforms to physical laws and engineering practices for vehicle testing. The historical data can truly reflect the logical relationships between the bus data of the vehicle model to be tested, providing a logical basis for generating the local field sequence. Using the data generation model to generate the local field sequence can simulate extreme operating conditions, improve the coverage of the simulated bus data, and ensure the diversity of the simulated bus data. The physics engine solver generates associated fields to ensure that the simulated bus data conforms to physical requirements. Combining the data generation model with the physics engine solver achieves collaborative generation and solving, breaking through the technical bottleneck of either single generation or single solving. Through interactive verification between the large model and the physics engine, the system balances data diversity with physical plausibility. Local field sequences and associated fields are timestamp-aligned to ensure strict causal relationships between data frames in the simulated bus data, ensuring the sequential nature of the simulated bus data and generating highly noise-tolerant, low-latency, and diverse simulated bus data. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] In order to more clearly illustrate the technical solutions in this application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are merely embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0054] Figure 1 This is a flow chart of a method for generating vehicle bus data according to an embodiment of the present application;

[0055] Figure 2 A flowchart for verifying analog bus data according to an embodiment of the present application;

[0056] Figure 3 A flowchart for determining data constraints for an embodiment of the present application;

[0057] Figure 4 A flowchart for determining associated fields for an embodiment of the present application;

[0058] Figure 5 A flowchart for timestamp alignment according to an embodiment of the present application;

[0059] Figure 6 This is a schematic diagram of the structure of a device for generating vehicle bus data according to an embodiment of the present application;

[0060] Figure 7 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0061] In order to make the objectives, technical solutions and advantages of this application more clear, this application is further described in detail below in combination with specific embodiments and with reference to the accompanying drawings.

[0062] It should be noted that, unless otherwise defined, the technical terms or scientific terms used in the embodiments of the present application should have the usual meanings understood by people with ordinary skills in the field to which this application belongs. The "first", "second" and similar words used in the embodiments of the present application do not indicate any order, quantity or importance, but are only used to distinguish different components. "Include" or "comprise" and similar words mean that the elements or objects appearing before the word cover the elements or objects listed after the word and their equivalents, without excluding other elements or objects. "Connect" or "connected" and similar words are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. "Up", "down", "left", "right" and the like are only used to indicate relative positional relationships. When the absolute position of the described object changes, the relative positional relationship may also change accordingly.

[0063] It should be understood herein that any number of elements in the drawings is for illustration only and not for limitation, and any naming is only for distinction and does not have any limiting meaning.

[0064] Based on the description of the above background technology, the following situations also exist in the related art:

[0065] Related technologies use real-vehicle measurements or hardware-in-the-loop (HIL) systems to obtain vehicle bus data. However, these technologies have the following drawbacks:

[0066] (1) Data acquisition relies on physical collection: When obtaining vehicle bus data by actual vehicle testing, for some extreme scenarios, obtaining vehicle bus data under extreme scenarios requires the test driver to drive the vehicle under extreme scenarios, which is dangerous and increases the test cost. Moreover, when the obtained vehicle bus data does not meet the requirements, the test driver needs to drive the vehicle under extreme scenarios again, resulting in a longer bus data acquisition cycle, higher acquisition costs, and failure to cover all scenarios (some scenarios are more dangerous, and it is not recommended for the test driver to drive the vehicle under actual vehicle).

[0067] (2) The HIL system is a testing technology that combines actual hardware devices with simulation models and is widely used in the development, verification, and debugging of complex systems. The HIL system simulates the controlled objects (such as sensors, actuators, or external environments) in real time, so that the hardware under test (such as controllers, power systems, thermal systems, etc.) can operate under conditions close to the real scene, thereby obtaining data during the operation of the hardware under test. Different controlled objects need to be constructed for different scenarios, resulting in a long bus data acquisition cycle and high acquisition costs. In addition, data in some extreme scenarios is missing, making it difficult to build a controlled object that meets the requirements, resulting in the generated CAN bus data being unable to cover all usage scenarios.

[0068] Low efficiency of physical model solving: Full-field solving based on pure physics engines requires complex modeling (such as vehicle dynamics, sensor noise, etc.), consumes a lot of computing resources, and is difficult to meet real-time requirements.

[0069] Insufficient data diversity: The lack of modeling of the dynamic correlation of vehicle operating status leads to poor physical consistency of bus data, which cannot meet the high-precision requirements of autonomous driving algorithm training.

[0070] The vehicle bus data generation method, device, electronic device, and storage medium provided in this application capture vehicle status data in real time and determine data constraints based on the vehicle status data. Historical bus data is acquired and input into a pre-trained data generation model, which then outputs a local field sequence within the data constraints. Using the local field sequence as a boundary condition, the associated fields corresponding to the local field sequence are determined based on vehicle operating parameters and a physics engine solution model. The local field sequence and the associated fields are timestamped to generate simulated bus data. The constraints determine the boundary limits for generating simulated bus data, preventing the generation of data that is significantly inconsistent with reality and ensuring that the generated simulated bus data does not exceed the performance range of a real vehicle. This ensures a strict mapping of the data generation process to real vehicle performance, providing simulated bus data that conforms to physical laws and engineering practices for vehicle testing. Historical data can realistically reflect the logical relationships between bus data for the vehicle under test, providing a logical basis for generating local field sequences. Using the data generation model to generate local field sequences enables simulation of extreme operating conditions, improves the coverage of simulated bus data, and ensures the diversity of simulated bus data. Using the physics engine solution model to generate associated fields ensures that the simulated bus data conforms to physical requirements. The data generation model and the physics engine solution model are combined to achieve collaborative generation and solution, breaking through the technical bottleneck of either single generation or solution. Through interactive verification between the large model and the physics engine, data diversity and physical rationality are balanced. Local field sequences and associated fields are timestamp-aligned to ensure strict causal relationships between data frames of the simulated bus data, ensuring the timing of the simulated bus data and achieving high noise tolerance, low latency, and highly diverse simulation bus data generation.

[0071] The method for generating vehicle bus data provided by the embodiments of the present application is described in detail below with reference to the accompanying drawings.

[0072] In some embodiments, as Figure 1 As shown, a method for generating vehicle bus data includes:

[0073] Step 101: Capture vehicle status data in real time, and determine data constraints based on the vehicle status data and the vehicle model to be tested.

[0074] In specific implementations, the vehicle state data is simulated state data determined by the user based on the test scenario, i.e., input data corresponding to the test scenario described by the user in natural language. For example, if the user inputs the test scenario data of "sharp turn at 30 km / h on icy road triggering Electronic Stability Program (ESP) intervention," the corresponding vehicle state data includes icy road, current speed of 30 km / h, control operation of sharp turn, and auxiliary operation of initiating ESP intervention during the turn. If the user inputs "sharp acceleration starting from 20 km / h on urban road," the corresponding vehicle state data includes urban road, current speed of 20 km / h, and control operation of sharp acceleration.

[0075] For the same test scenario input by the user, the performance of different vehicles is not the same. Therefore, after capturing the vehicle status data, it is necessary to determine the data constraints based on the vehicle status data and the vehicle model to be tested. Because the performance parameters of different vehicle models to be tested are different, their performance capabilities are not the same in the same scenario.

[0076] For example, there are two models to be tested, model A and model B, which have large performance differences. For example, if the performance of model A is better than that of model B, after the user inputs the test scenario of "rapid acceleration at 20km / h on urban roads", if the maximum acceleration of model A is 0.5g and the maximum acceleration of model B is 0.4g, where g represents the acceleration due to gravity, which is 9.8m / s 2 , then under the rapid acceleration condition, the speed change rate (i.e., acceleration) of the test vehicle type A ranges from (0, 0.5g], and the speed change rate (i.e., acceleration) of the test vehicle type B ranges from (0, 0.4g], so the speed change rate constraint of the test vehicle type A is 0 < speed change rate ≤ 0.5g, and the speed change rate constraint of the test vehicle type B is 0 < speed change rate ≤ 0.4g.

[0077] It means that in the sudden acceleration scenario, the speed change rate output by the data generation model (such as the large language model) for the test vehicle type A cannot exceed 0.5g, and cannot be a negative number (that is, deceleration data cannot be generated in the sudden acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 0.5g or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized. Similarly, in the sudden acceleration scenario, the speed change rate output by the data generation model for the test vehicle type B cannot exceed 0.4g, and cannot be a negative number (that is, deceleration data cannot be generated in the sudden acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 0.4g or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized.

[0078] If the maximum speed of test vehicle model A is 200 km / h and the maximum speed of test vehicle model B is 150 km / h, then under rapid acceleration conditions, the speed range of test vehicle model A is (0, 200 km / h], and the speed range of test vehicle model B is (0, 150 km / h]). Therefore, the speed constraint condition for test vehicle model A is 0 < speed ≤ 200 km / h, and the speed constraint condition for test vehicle model B is 0 < speed ≤ 150 km / h.

[0079] It means that in the sudden acceleration scenario, the speed output by the data generation model for the test model A cannot exceed 200km / h, and cannot be a negative number (that is, deceleration data cannot be generated in the sudden acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 200km / h or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized. Similarly, in the sudden acceleration scenario, the speed change rate output by the data generation model for the test model B cannot exceed 150km / h, and cannot be a negative number (that is, deceleration data cannot be generated in the sudden acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 150km / h or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized.

[0080] By capturing vehicle status data to determine the corresponding test scenario, in the test scenario corresponding to the vehicle status data, data constraints are determined according to the vehicle model to be tested, and the boundary limits of generating simulated bus data are determined by the constraints to avoid generating data that is obviously inconsistent with reality, so as to ensure that the generated simulated bus data does not exceed the performance range of the real vehicle, and achieve a strict mapping of the data generation process with the real vehicle performance, providing vehicle testing with simulated bus data that conforms to physical laws and engineering practices. Therefore, by using constraints to improve the authenticity, rationality and accuracy of simulated bus data, and using simulated bus data with higher authenticity, rationality and accuracy for vehicle development and testing, it can effectively improve the credibility of vehicle electronic system development and test results.

[0081] Step 102: Obtain historical bus data, determine vehicle performance parameters of the vehicle model to be tested, and input the historical bus data and vehicle performance parameters into a pre-trained data generation model so that the data generation model outputs a local field sequence under data constraints.

[0082] During implementation, after determining the data constraints, historical bus data must be obtained. This historical data accurately reflects the logical relationships between the bus data of the vehicle under test, providing a logical foundation for generating local field sequences. This historical bus data can be obtained from the cloud or directly from a local database. Using an edge-cloud collaborative framework, a lightweight model is deployed on the edge to achieve real-time data generation. The cloud regularly synchronizes high-precision physical models and training data, supporting over-the-air (OTA) updates to parsing rules and vehicle parameter libraries. This allows for the acquisition of historical bus data that meets current testing requirements. The cloud collects and stores CAN bus data from different vehicles in different driving scenarios in real time. This data serves as input data and can be used to train and optimize the data generation model. To ensure the security of trained model parameters, the cloud regularly synchronizes high-precision physical models and training data to prevent data loss caused by accidental deletion on the edge. The edge is designed with a compatible interface, providing a communication matrix import interface in DBC / Excel format, supporting multiple protocols such as J1939 and ISO15765, and output data that can be directly integrated into test toolchains such as CANoe and Vector.

[0083] During the vehicle bus data generation process, historical bus data is fed into a pre-trained data generation model, which then outputs a local field sequence under data constraints. Using the pre-trained data generation model, the model learns the temporal characteristics and association rules of important local fields (such as vehicle speed and steering angle) in the historical bus data by inputting historical bus data, DBC files, and vehicle performance parameters. Under the vehicle performance parameters and data constraints, the model outputs a local field sequence that conforms to the CAN matrix specification. The signal ID, bit order, and byte order of the local field sequence are compatible with the protocol of the vehicle under test.

[0084] For example, after inputting historical bus data of engine speed into a trained data generation model, the data generation model can generate speed sequence segments that are logically associated with temperature and load under vehicle performance parameters and data constraints.

[0085] Among them, the attention mechanism is introduced by setting data constraints. By capturing the changes in vehicle status, the value range and change rate of the generated field are dynamically adjusted, that is, the data constraints are dynamically changed to avoid physical distortion caused by data jumps.

[0086] Compared to acquiring vehicle bus data through on-site testing, using a data generation model to generate local field sequences offers the advantages of rapid generation and agile development. CAN data conforming to the protocol format is generated directly from natural language descriptions, eliminating the need for manual coding or complex toolchains, thus shortening development time. During algorithm debugging, test cases with different parameter combinations (such as different vehicle speeds and fault codes) can be quickly generated by modifying prompts. This enables rapid iteration of the data generation model, avoids the need to repeatedly build new data generation models, and reduces wasted human resources.

[0087] Generating local field sequences using data generation models can cover complex scenarios and boundary conditions. Data generation models can simulate extreme operating conditions, such as ultra-high-speed communications and abnormal DLC values, which are difficult to cover using real-vehicle testing methods, thereby improving test development coverage. For example, fault injection scenarios can simulate the probability of 100% CAN bus load, ID conflicts, or parity errors (CRC failures). Extreme value testing can also include speed signal out-of-range (e.g., >300 km / h) and negative temperature values ​​(requiring complement processing). Data generation models can also be used to batch generate local field sequences for multiple scenarios, such as generating mixed data streams covering multiple operating conditions (e.g., simultaneously simulating acceleration, braking, and battery failure) to verify controller robustness. Furthermore, compared to real-vehicle testing, data generation costs are reduced, reducing reliance on real-vehicle testing and saving hardware costs. Furthermore, test drivers are no longer required to drive the vehicle, and local field generation and physical inference replace manual full-field labeling or collection, saving labor costs.

[0088] Step 103: Taking the local field sequence as a boundary condition, determine the associated fields corresponding to the local field sequence according to the vehicle operating parameters and the physical engine solution model.

[0089] In specific implementation, further, the use of a single data generation model to generate full-field vehicle bus data will cause the data generation model to become too bloated, and it cannot guarantee that the generated data complies with the laws of vehicle physics. Therefore, it is chosen to use the data generation model to generate a local field sequence, and then use the local field sequence as the boundary condition. According to the vehicle operating parameters and the physical engine solution model, the associated fields corresponding to the local field sequence are determined. Combining the diversity advantages of the data generation model with the constraint capabilities of the physical engine solution model, it is ensured that the generated simulated bus data complies with the laws of vehicle physics (such as vehicle dynamics and vehicle thermodynamics).

[0090] The physics engine's solution model is a multi-domain physics model, including vehicle dynamics models (such as the longitudinal motion equation) and vehicle thermodynamics models (such as the battery temperature diffusion model). It uses the local field sequence generated by the data generation model as boundary conditions, and numerically derives the values ​​of other fields to obtain associated fields associated with the local field sequence. For example, based on the vehicle speed and slope data generated by the data generation model, combined with the air resistance coefficient and mass parameters, the vehicle dynamics model is used to solve the engine torque and fuel consumption fields to achieve the generation of full-field vehicle bus data.

[0091] The data generation model and the physical engine solution model are combined to achieve the coordination of generation and solution, breaking through the technical bottleneck of single generation or solution. Through the interactive verification of the large model and the physical engine, data diversity and physical rationality are taken into account. The data generation model and the physical engine solution model are combined to realize the modular architecture design, which supports the replacement of physical models in the physical engine solution model (such as replacing them with high-order vehicle models) and model upgrades (such as switching large language models to diffusion models), thereby improving scalability. The data generation model has a dynamic optimization mechanism that can adjust the generation strategy based on real-time feedback to avoid long-term data distortion caused by model drift during the data generation process. It can also be applied across scenarios: it can adapt to new requirements by adjusting parameters, for example, it can be migrated to different vehicle models (such as cars, trucks) and test scenarios (such as high-speed cruising, emergency obstacle avoidance).

[0092] Only key fields (such as local field sequences such as vehicle speed and steering angle) are subject to large model generation, and the remaining fields (such as tire force, yaw angular velocity and other related fields) are solved through lightweight physical models, which reduces the computing power required for simulation bus data generation and improves data generation efficiency.

[0093] Step 104: align the local field sequence and the associated field with respect to timestamps to obtain simulated bus data.

[0094] In specific implementations, while balancing data diversity and physical rationality, it is necessary to ensure the timing of generated data. This requires timestamp alignment of the output of the data generation model and the output of the physical engine solution model. This involves timestamp alignment of local field sequences and associated fields to ensure strict causal relationships between data frames. During timestamp alignment, differentiated interpolation strategies are designed for periodic and aperiodic signals to meet the timing constraints of analog bus data, ensuring strict causal relationships between data frames and guaranteeing the timing of the analog bus data.

[0095] In summary, the vehicle bus data generation method provided in this application uses constraints to determine the boundaries of generated simulated bus data, avoiding the generation of data that is clearly inconsistent with reality. This ensures that the generated simulated bus data does not exceed the performance range of real vehicles, achieves a strict mapping of the data generation process to real vehicle performance, and provides simulated bus data that conforms to physical laws and engineering practices for vehicle testing. Historical data can truly reflect the logical relationships between bus data of the tested vehicle model, providing a logical basis for generating local field sequences. Using a data generation model to generate local field sequences enables simulation of extreme operating conditions, improves the coverage of simulated bus data, and ensures the diversity of simulated bus data. Using a physics engine solution model to generate associated fields ensures that the simulated bus data conforms to physical requirements. Combining the data generation model with the physics engine solution model achieves coordinated generation and solution, breaking through the technical bottleneck of either single generation or solution. Through interactive verification between a large model and the physics engine, data diversity and physical plausibility are balanced. Furthermore, the local field sequences and associated fields are timestamp-aligned to ensure strict causal relationships between data frames of the simulated bus data, ensuring the temporal order of the simulated bus data and achieving the generation of simulated bus data with high noise tolerance, low latency, and high diversity.

[0096] In some embodiments, during the generation of analog bus data, data constraints and boundary conditions are used to ensure data accuracy. However, the above processes are all process verifications, and corresponding result verification processes are required, i.e., protocol compliance checks and physical logic closed-loop verification of analog bus data. The result verification process is as follows: Figure 2 As shown, the method for generating vehicle bus data further includes:

[0097] Step 201: Determine a standardized text file corresponding to historical bus data.

[0098] In practice, the protocol compliance check process first requires the identification of a standardized text file (Database CAN, DBC) corresponding to the historical bus data. A DBC file is a standardized text file used to describe the Controller Area Network (CAN) bus communication protocol. It primarily defines the message format, signal attributes, and communication rules between electronic control units in the vehicle network. The core functions of the DBC file include:

[0099] (1) Communication standardization: Unify the message ID, signal definition, and transmission rules of different control units to ensure the compatibility of vehicle communications.

[0100] (2) Data parsing and conversion: Convert the raw binary data on the CAN bus into engineering values ​​with physical meaning (such as vehicle speed and temperature), while supporting data monitoring and diagnosis.

[0101] (3) Development and testing support: Provide basic data templates for the development and testing process.

[0102] Therefore, by comparing the simulated bus data with the standardized text file, the protocol compliance check of the simulated bus data can be achieved.

[0103] Step 202: Perform message format verification, signal attribute verification, and communication rule verification on the simulated bus data according to the standardized text file to obtain verification results.

[0104] In specific implementation, by comparing the simulated bus data and the standardized text file, it is possible to determine whether the message format, signal properties, communication rules, etc. of the simulated bus data meet the requirements of the actual CAN bus data. Therefore, the message format of the simulated bus data is verified by comparing the standard message format in the standardized text file and the simulated message format in the simulated generated data.

[0105] The signal attribute verification of the simulated bus data is achieved by comparing the standard signal attributes in the standardized text file with the simulated signal attributes in the simulated generated data.

[0106] The communication rules of the simulated bus data are verified by comparing the standard communication rules in the standardized text file with the simulated communication rules in the simulated generated data.

[0107] At the same time, by comparing standardized text files with simulation-generated data, problems such as bit field out-of-bounds and checksum errors can be identified and corrected, thereby achieving protocol compliance checks on the result side of the simulation bus data.

[0108] Step 203: In response to the absence of unqualified check items in the check result, perform logic check on the analog bus data, and store the analog bus data after the logic check passes.

[0109] During specific implementation, if there are no unqualified check items in the verification results, it means that all inspection items of the protocol compliance check on the result side have passed, and there are no protocol compliance issues with the analog bus data. At this time, it is necessary to perform logical verification on the analog bus data, that is, to perform physical logical closed-loop verification.

[0110] In some embodiments, performing logic verification on analog bus data includes:

[0111] Step 2031: The simulated bus data is inputted in reverse to the vehicle simulation platform, so that the vehicle simulation platform can perform simulation operation according to the signal chain causal relationship of the simulated bus data and output the operation result.

[0112] Step 2032: In response to the simulation failure as a result of the operation, the data generation model and the physical engine solution model are optimized according to the operation result.

[0113] During specific implementation, a virtual sensor model is deployed, and the simulated bus data is input back into the vehicle simulation platform to verify whether the cause-effect relationship of the signal chain such as the throttle-vehicle speed-torque conforms to the actual physical laws. If the running result is that the simulation is successful, it is determined to conform to the actual physical laws and pass the logical check. If the running result is that the simulation fails, it is determined that it does not conform to the actual physical laws and fails the logical check. According to the running results, the data generation model and the physical engine solution model are optimized, and the simulated bus data is regenerated to ensure that the simulated bus data can pass the physical logic closed loop verification and there is no problem of not conforming to the physical laws.

[0114] Furthermore, in response to the existence of unqualified verification items in the verification results, the data generation model and the physical engine solution model are optimized according to the unqualified verification items.

[0115] During specific implementation, if there are unqualified check items in the verification results, it means that there are errors in the message format, signal properties and communication rules of the simulated bus data. It is necessary to optimize the data generation model and the physical engine solution model based on the unqualified check items to ensure the correctness and accuracy of the simulated bus data.

[0116] By supplementing the result verification process to further ensure that the analog bus data does not have protocol compliance issues, it is also ensured that the analog bus data does not have problems that do not comply with physical laws, so as to improve the compliance and logic of the analog bus data.

[0117] In some embodiments, the determination of the constraints improves the authenticity, rationality and accuracy of the simulated bus data. The implementation of the constraints is determined, for example Figure 3 As shown, the data constraints include value range constraints and change rate constraints; the data constraints are determined based on the vehicle status data and the vehicle model to be tested, including:

[0118] Step 301: Determine a simulation control scenario based on vehicle status data.

[0119] In specific implementation, the vehicle status data includes multiple keywords, and the scene database is matched according to the keywords in the vehicle status data to determine the corresponding simulation control scene. If the match fails, the user is prompted to manually add the corresponding simulation control scene, and the added simulation control scene is stored in the scene database.

[0120] Step 302: Adjust the boundary value of the standard value range according to the simulation control scenario to obtain the value range constraint condition.

[0121] During specific implementation, the numerical boundary adjustment direction is determined according to the simulation control scenario, and the target boundary value that needs to be adjusted is determined from the upper boundary value and the lower boundary value of the standard value range according to the simulation control scenario, and the boundary value of the target boundary value is adjusted according to the numerical boundary adjustment direction to obtain the numerical range constraint condition.

[0122] Step 303: Adjust the boundary value of the standard change rate range according to the simulated control scenario to obtain the change rate constraint condition.

[0123] During specific implementation, the direction of the change rate boundary adjustment is determined according to the simulation control scenario, and the target boundary change rate that needs to be adjusted is determined in the upper boundary change rate and the lower boundary change rate of the standard change rate range according to the simulation control scenario, and the boundary value of the target boundary change rate is adjusted according to the change rate boundary adjustment direction to obtain the numerical range constraint condition.

[0124] For example, take the test models A and B with large performance differences as an example. If the performance of the test model A is better than that of the test model B, the simulation control scenario is determined to be "acceleration at 20km / h on snowy road" according to the vehicle status data. If the maximum acceleration of the test model A is 0.5g and the maximum acceleration of the test model B is 0.4g, the maximum driving speed of the test model A is 200km / h and the maximum speed of the test model B is 150km / h, where g represents the acceleration due to gravity, which is 9.8m / s 2 The standard speed range of the test model A is (0, 200 km / h], and the standard speed change rate range is (0, 0.5g]; the standard speed range of the test model B is (0, 150 km / h], and the standard speed change rate range is (0, 0.4g].

[0125] However, in snowy conditions, to prevent skidding, the upper limits of the standard rate of change range and the standard value range need to be narrowed. For example, the 200km / h speed of test vehicle A is reduced to 50km / h, and the 0.5g speed is reduced to 0.2g. This means that in snowy conditions, the vehicle is not allowed to perform aggressive acceleration or deceleration, and high-speed driving is also prohibited to prevent skidding during braking, which could lead to traffic accidents. Similarly, the 150km / h speed of test vehicle B is reduced to 40km / h, and the 0.4g speed is reduced to 0.15g.

[0126] In the snow acceleration scenario, the speed change rate constraint condition for the test model A is 0 < speed change rate ≤ 0.2g, and the speed change rate constraint condition for the test model B is 0 < speed change rate ≤ 0.15g.

[0127] It means that in the snow acceleration scenario, the speed change rate output by the data generation model (such as the large language model) for the test vehicle model A cannot exceed 0.2g, and cannot be a negative number (that is, deceleration data cannot be generated in the sudden acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 0.2g or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized. Similarly, in the snow acceleration scenario, the speed change rate output by the data generation model for the test vehicle model B cannot exceed 0.15g, and cannot be a negative number (that is, deceleration data cannot be generated in the sudden acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 0.15g or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized.

[0128] Similarly, in the snow acceleration scenario, the speed constraint condition for the test model A is 0 < speed ≤ 50 km / h, and the speed constraint condition for the test model B is 0 < speed ≤ 45 km / h.

[0129] This means that in the snow acceleration scenario, the speed output by the data generation model for the test model A cannot exceed 50km / h and cannot be a negative number (i.e., deceleration data cannot be generated in the rapid acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 50km / h or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized. Similarly, in the snow acceleration scenario, the speed change rate output by the data generation model for the test model B cannot exceed 45km / h and cannot be a negative number (i.e., deceleration data cannot be generated in the rapid acceleration scenario) to ensure the rationality and correctness of the output data. If the output speed change rate exceeds 45km / h or is a negative number, it means that there are certain problems with the data generation model and the data generation model needs to be optimized.

[0130] Adjust the standard range according to the simulation control scenario to determine the data constraints that meet different simulation control scenarios, ensure that each simulation control scenario has separate data constraints, and ensure the accuracy of the simulation bus data generated in each simulation control scenario.

[0131] In some embodiments, the physics engine solution model includes a kinetic model and a thermodynamic model, and the associated fields include a kinetic associated field and a thermodynamic associated field; Figure 4 As shown, with the local field sequence as the boundary condition, the associated fields corresponding to the local field sequence are determined according to the vehicle operating parameters and the physical engine solution model, including:

[0132] Step 401: classify vehicle operating parameters to obtain dynamic parameters and thermodynamic parameters;

[0133] In specific implementation, the vehicle operating parameters are classified according to their parameter meanings, and the parameters representing thermodynamic meanings are classified as thermodynamic parameters, and the parameters representing kinetic meanings are classified as thermodynamic parameters.

[0134] Step 402: Determine the dynamic boundary conditions corresponding to the dynamic parameters in the local field sequence, so that the dynamic model can output the dynamic correlation field under the dynamic boundary conditions.

[0135] Step 403: Determine thermodynamic boundary conditions corresponding to thermodynamic parameters in the local field sequence, so that the thermodynamic model can output thermodynamically associated fields under the thermodynamic boundary conditions.

[0136] In specific implementations, the physics engine solves a multi-domain physics model, including a vehicle dynamics model (such as the longitudinal motion equation) and a vehicle thermodynamics model (such as the battery temperature diffusion model). The local field sequence generated by the data generation model is used as a boundary condition, and numerical calculations are used to derive the values ​​of other fields, resulting in associated fields associated with the local field sequence. For example, based on the vehicle speed and slope data generated by the data generation model, combined with the air resistance coefficient and mass parameters, the vehicle dynamics model is used to solve the engine torque and fuel consumption fields, achieving the generation of full-field vehicle bus data.

[0137] If the physical engine solution model includes a dynamic model and a thermodynamic model, the vehicle operating parameters will be classified to obtain dynamic parameters and thermodynamic parameters. At the same time, the dynamic boundary conditions corresponding to the dynamic parameters will be determined in the local field sequence so that the dynamic model can output dynamic-related fields under the dynamic boundary conditions. The thermodynamic boundary conditions corresponding to the thermodynamic parameters will be determined in the local field sequence so that the thermodynamic model can output thermodynamic-related fields under the thermodynamic boundary conditions. This will achieve synchronous solution of multiple physical models and improve solution efficiency.

[0138] The data generation model and the physical engine solution model are combined to achieve the coordination of generation and solution, breaking through the technical bottleneck of single generation or solution. Through the interactive verification of the large model and the physical engine, data diversity and physical rationality are taken into account. The data generation model and the physical engine solution model are combined to realize the modular architecture design, which supports the replacement of physical models in the physical engine solution model (such as replacing them with high-order vehicle models) and model upgrades (such as switching large language models to diffusion models), thereby improving scalability. The data generation model has a dynamic optimization mechanism that can adjust the generation strategy based on real-time feedback to avoid long-term data distortion caused by model drift during the data generation process. It can also be applied across scenarios: it can adapt to new requirements by adjusting parameters, for example, it can be migrated to different vehicle models (such as cars, trucks) and test scenarios (such as high-speed cruising, emergency obstacle avoidance).

[0139] In some embodiments, as Figure 5 As shown, the local field sequence and the associated field are timestamp aligned to obtain the simulated bus data, including:

[0140] Step 501: Write the local field sequence into a first buffer queue, and write the associated field into a second buffer queue, wherein the first buffer queue and the second buffer queue are independent of each other.

[0141] In specific implementations, while balancing data diversity and physical rationality, it is necessary to ensure the temporal order of generated data. This requires aligning the timestamps of the data generation model output and the output of the physics engine's solution model. This means aligning the timestamps of local field sequences and associated fields to ensure strict causal relationships between data frames. During timestamp alignment, a double-buffered queue is used to align the timestamps of the data generation model output and the physics engine's solution model output, ensuring strict causal relationships between data frames.

[0142] The dual-buffered queue decouples data production and consumption through an alternating read-write mechanism. Separate buffer queues are allocated for the data generation model and the physics engine solution model, each temporarily storing their respective data streams. On the production side of the dual-buffered queue, real-time output data from the data generation model and the physics engine solution model is written to their respective buffer queues, preventing interference. On the consumer side of the dual-buffered queue, a synchronization thread extracts data from both queues to align timestamps.

[0143] First, the local field sequence needs to be written into the first buffer queue, and the associated field needs to be written into the second buffer queue. The first buffer queue and the second buffer queue are independent of each other and constitute a double buffer queue.

[0144] Step 502: Determine a time difference threshold according to a first writing cycle of a local field sequence and a second writing cycle of an associated field.

[0145] In some embodiments, determining the time difference threshold according to a first writing cycle of a partial field sequence and a second writing cycle of an associated field comprises:

[0146] Step 5021: Determine the cycle time difference between the first writing cycle and the second writing cycle;

[0147] Step 5022: In response to the cycle time difference being greater than a preset difference threshold, determining a low-frequency writing cycle and a high-frequency writing cycle in the first writing cycle and the second writing cycle;

[0148] Step 5023: Perform interpolation compensation according to the low-frequency write cycle to obtain interpolation compensation data and compensation time, write the interpolation compensation data into the buffer queue corresponding to the low-frequency write cycle, determine the compensation cycle according to the compensation time and the low-frequency write cycle, and determine the least common multiple of the compensation cycle and the high-frequency write cycle as the time difference threshold.

[0149] In specific implementations, the time difference threshold is the time period for extracting data from the double-buffered queue. Since different data have different write cycles, to ensure that the local field sequence and associated fields can be extracted at the same time, it is necessary to ensure that the data extraction time point corresponds to both the first write cycle and the second write cycle.

[0150] Therefore, it is first necessary to determine whether simultaneous data extraction is possible. The calculation is based on the time difference between the first and second write cycles. For example, if the first write cycle of a local field sequence is 10ms and the second write cycle of an associated field is 20ms, the time difference is 10ms. If the preset difference threshold is 30ms, then the time difference is less than the preset difference threshold, indicating that simultaneous data extraction can be achieved by directly determining the extraction time point. This also prevents data loss due to excessively large time differences. Therefore, the lowest common multiple of the first and second write cycles is determined as the time difference threshold, and 20ms is used as the data extraction cycle for the double-buffered queue. This achieves timestamp alignment and ensures the strict validity of the causal relationship between data frames. That is, when the time difference is less than or equal to the difference threshold, the period difference is small. Directly determining the lowest common multiple of the first and second write cycles as the time difference threshold will not result in data loss, thus omitting the difference compensation process and improving the alignment efficiency of the timestamp alignment process.

[0151] If the first write cycle of the local field sequence is 90ms, the second write cycle of the associated field is 15ms, and the cycle time difference is 75ms, if the preset difference threshold is 30ms, then the cycle time difference is greater than the preset difference threshold, indicating that the extraction time point can be directly determined. The data loss phenomenon caused by the large cycle difference is because if 90ms is used as the data extraction cycle, when the local field sequence is output once, the associated field has been output 6 times, which will cause the first 5 associated fields to be lost, resulting in a significant impact on the continuity of the data. Therefore, it is necessary to determine the low-frequency write cycle in the first and second write cycles. write cycle and high-frequency write cycle; if the first write cycle of the local field sequence is 90ms and the second write cycle of the associated field is 15ms, the low-frequency write cycle is 90ms and the high-frequency write cycle is 15ms. In order to avoid data loss, the local field sequence is interpolated and compensated, that is, interpolated compensation is performed according to the low-frequency write cycle to obtain interpolated compensation data and compensation time, and the interpolated compensation data is written into the buffer queue corresponding to the low-frequency write cycle, and the compensation cycle is determined according to the compensation time and the low-frequency write cycle, and the least common multiple of the compensation cycle and the high-frequency write cycle is determined as the time difference threshold to improve the accuracy of timestamp alignment.

[0152] For example, the time for the two adjacent digital outputs of the local field sequence is the model sampling points t1=10ms and t2=100ms, then (10+100) / 2=55ms is selected as the interpolation compensation time, and the new first write cycle becomes 55-10=45ms, and the intermediate value corresponding to the compensation time is calculated according to the linear difference formula, and the intermediate value is the interpolation compensation data.

[0153] Among them, the linear difference formula is:

[0154] yt=y1+(y2-y1)×(t-t1) / (t2-t1)

[0155] Wherein, y1 represents the local field sequence output at t1, y2 represents the local field sequence output at t2, t represents the compensation time, and yt = interpolation compensation data.

[0156] If the cycle time difference after one interpolation compensation is still greater than the difference threshold, two or more interpolation compensations may be performed simultaneously until the cycle time difference after the interpolation compensation is still greater than the difference threshold.

[0157] The output of the data generation model and the output of the physics engine solution model are timestamped. This means that the local field sequences and associated fields are timestamped to ensure strict causal relationships between data frames. During the timestamp alignment process, a double-buffered queue is used to align the output of the data generation model with the output of the physics engine solution model, ensuring strict causal relationships between data frames.

[0158] Step 503: extracting data from the first buffer queue and the second buffer queue synchronously according to the time difference threshold to obtain analog bus data.

[0159] In real time, data is extracted synchronously in the first buffer queue and the second buffer queue according to the time difference threshold, and the local field sequence and the associated field have the same timestamp, which realizes the timestamp object and obtains the simulated bus data with strict causal relationship, ensuring the accuracy of data generation.

[0160] It should be noted that the method of the embodiment of the present application can be performed by a single device, such as a computer or server. The method of this embodiment can also be applied in a distributed scenario and performed by multiple devices working together. In such a distributed scenario, one of the multiple devices may only perform one or more steps of the method of the embodiment of the present application, and the multiple devices will interact with each other to complete the method.

[0161] It should be noted that the above description is limited to some embodiments of the present application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in an order different from that described in the above embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order or sequential order shown to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0162] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides a device for generating vehicle bus data.

[0163] refer to Figure 6 , the vehicle bus data generating device comprises:

[0164] The constraint determination module 10 is configured to: capture vehicle status data in real time and determine data constraint conditions based on the vehicle status data;

[0165] The data generation module 20 is configured to: obtain historical bus data, determine vehicle performance parameters of the vehicle model to be tested, and input the historical bus data and vehicle performance parameters into a pre-trained data generation model so that the data generation model outputs a local field sequence under data constraints;

[0166] The data solving module 30 is configured to: use the local field sequence as a boundary condition and determine the associated fields corresponding to the local field sequence according to the vehicle operating parameters and the physical engine solving model;

[0167] The time alignment module 40 is configured to perform time stamp alignment on the local field sequence and the associated field to obtain simulated bus data.

[0168] For the convenience of description, the above devices are described as being divided into various modules according to their functions. Of course, when implementing this application, the functions of each module can be implemented in the same or multiple software and / or hardware.

[0169] The apparatus of the above embodiment is used to implement the corresponding vehicle bus data generation method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0170] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and runnable on the processor, wherein when the processor executes the program, the method for generating vehicle bus data described in any of the above embodiments is implemented.

[0171] Figure 7 10 is a schematic diagram showing a more specific hardware structure of an electronic device provided in this embodiment. The device may include: a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 are communicatively connected to each other within the device via the bus 1050.

[0172] The processor 1010 can be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this specification.

[0173] The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, etc. The memory 1020 can store an operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 1020 and is called and executed by the processor 1010.

[0174] The input / output interface 1030 is used to connect input / output modules to implement information input and output. The input / output modules can be configured as components within the device (not shown in the figure) or can be externally connected to the device to provide corresponding functions. Input devices may include a keyboard, mouse, touch screen, microphone, various sensors, etc., and output devices may include a display, speaker, vibrator, indicator light, etc.

[0175] The communication interface 1040 is used to connect to a communication module (not shown) to enable communication between the device and other devices. The communication module can communicate via a wired method (such as USB, network cable, etc.) or a wireless method (such as mobile network, WiFi, Bluetooth, etc.).

[0176] The bus 1050 comprises a path for transmitting information between the various components of the device (eg, the processor 1010 , the memory 1020 , the input / output interface 1030 , and the communication interface 1040 ).

[0177] It should be noted that although the above device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in a specific implementation, the device may also include other components necessary for normal operation. In addition, it will be understood by those skilled in the art that the above device may only include the components necessary to implement the embodiments of this specification, and does not necessarily include all the components shown in the figure.

[0178] The electronic device of the above embodiment is used to implement the corresponding vehicle bus data generation method in any of the above embodiments, and has the beneficial effects of the corresponding method embodiment, which will not be described in detail here.

[0179] Based on the same inventive concept, corresponding to any of the above-mentioned embodiments and methods, the present application also provides a non-transitory computer-readable storage medium, wherein the non-transitory computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the computer to execute the vehicle bus data generation method as described in any of the above embodiments.

[0180] The computer-readable media of this embodiment include permanent and non-permanent, removable and non-removable media that can be used to store information by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, tape disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device.

[0181] The computer instructions stored in the storage medium of the above embodiment are used to enable the computer to execute the method for generating vehicle bus data as described in any of the above embodiments, and have the beneficial effects of the corresponding method embodiments, which will not be repeated here.

[0182] It is understandable that before using the technical solutions of each embodiment of the present disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved will be informed to the user in an appropriate manner, and the user's authorization will be obtained.

[0183] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operation of the disclosed technical solution based on the prompt message.

[0184] As an optional but non-limiting implementation, in response to a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0185] It is understandable that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0186] Those skilled in the art should understand that the discussion of any of the above embodiments is merely illustrative and is not intended to imply that the scope of the present application is limited to these examples. In line with the present application, the technical features in the above embodiments or different embodiments may be combined, the steps may be implemented in any order, and there are many other variations of the different aspects of the embodiments of the present application as described above, which are not provided in detail for the sake of simplicity.

[0187] In addition, for simplicity of description and discussion, and in order not to make the embodiment of the application difficult to understand, the known power supply / ground connection with integrated circuit (IC) chip and other components may or may not be shown in the accompanying drawings provided. In addition, the device can be shown in the form of a block diagram to avoid making the embodiment of the application difficult to understand, and this also takes into account the following fact, that is, the details of the embodiment of these block diagram devices are highly dependent on the platform to be implemented in the embodiment of the application (that is, these details should be fully within the scope of understanding of those skilled in the art). When specific details (for example, circuit) are set forth to describe exemplary embodiments of the application, it will be apparent to those skilled in the art that the embodiment of the application can be implemented without these specific details or when these specific details are changed. Therefore, these descriptions should be considered to be illustrative rather than restrictive.

[0188] Although the present invention has been described in conjunction with specific embodiments thereof, many alternatives, modifications, and variations of these embodiments will be apparent to those skilled in the art based on the foregoing description. For example, other memory architectures (e.g., dynamic RAM (DRAM)) may utilize the embodiments discussed.

[0189] The embodiments of the present application are intended to cover all such substitutions, modifications, and variations that fall within the broad scope of the present application. Therefore, any omissions, modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the embodiments of the present application should be included in the scope of protection of the present application.

Claims

1. A method for generating vehicle bus data, characterized in that: include: Capturing vehicle status data in real time, and determining data constraints based on the vehicle status data and the vehicle model to be tested; Acquiring historical bus data, determining vehicle performance parameters of the vehicle model to be tested, and inputting the historical bus data and vehicle performance parameters into a pre-trained data generation model so that the data generation model outputs a local field sequence under the data constraints; Taking the local field sequence as a boundary condition, determining the associated fields corresponding to the local field sequence according to vehicle operating parameters and a physical engine solution model; The local field sequence and the associated field are time stamp aligned to obtain simulated bus data.

2. The method according to claim 1, characterized in that Also includes: determining a standardized text file corresponding to the historical bus data; Performing message format verification, signal attribute verification, and communication rule verification on the simulated bus data according to the standardized text file to obtain a verification result; In response to the absence of unqualified check items in the check result, a logic check is performed on the analog bus data, and the analog bus data is stored after passing the logic check.

3. The method according to claim 2, characterized in that The performing logic verification on the analog bus data includes: Reversely inputting the simulated bus data into a vehicle simulation platform, so that the vehicle simulation platform performs simulation operation according to the signal chain causal relationship of the simulated bus data and outputs the operation result; In response to the running result being a simulation running failure, the data generation model and the physical engine solving model are optimized according to the running result.

4. The method according to claim 1, wherein The data constraints include a value range constraint and a change rate constraint; the data constraints are determined based on the vehicle state data and the vehicle model to be tested, including: determining a simulation control scenario according to the vehicle state data; Determine the standard value range and standard change rate range according to the vehicle model to be tested; Adjusting the boundary value of the standard value range according to the simulation control scenario to obtain the value range constraint condition; The boundary value of the standard change rate range is adjusted according to the simulation control scenario to obtain the change rate constraint condition.

5. The method according to claim 1, wherein The physical engine solution model includes a dynamic model and a thermodynamic model, and the associated fields include a dynamic associated field and a thermodynamic associated field. The determining of the associated fields corresponding to the local field sequence based on the vehicle operating parameters and the physical engine solution model using the local field sequence as a boundary condition includes: Classifying the vehicle operating parameters to obtain kinetic parameters and thermodynamic parameters; Determining a dynamic boundary condition corresponding to the dynamic parameter in the local field sequence, so that the dynamic model outputs the dynamic association field under the dynamic boundary condition; Thermodynamic boundary conditions corresponding to the thermodynamic parameters are determined in the local field sequence, so that the thermodynamic model can output the thermodynamically associated fields under the thermodynamic boundary conditions.

6. The method according to claim 1, wherein The step of aligning the timestamps of the local field sequence and the associated field to obtain simulated bus data includes: Writing the local field sequence into a first buffer queue, and writing the associated field into a second buffer queue; wherein the first buffer queue and the second buffer queue are independent of each other; determining a time difference threshold according to a first writing cycle of the local field sequence and a second writing cycle of the associated field; Data is extracted synchronously in the first buffer queue and the second buffer queue according to the time difference threshold to obtain the analog bus data.

7. The method according to claim 6, characterized in that The determining of the time difference threshold according to the first writing cycle of the local field sequence and the second writing cycle of the associated field comprises: determining a cycle time difference between the first writing cycle and the second writing cycle; In response to the cycle time difference being greater than a preset difference threshold, determining a low-frequency writing cycle and a high-frequency writing cycle in the first writing cycle and the second writing cycle; Interpolation compensation is performed according to the low-frequency write cycle to obtain interpolation compensation data and compensation time, the interpolation compensation data is written into a buffer queue corresponding to the low-frequency write cycle, and the compensation cycle is determined according to the compensation time and the low-frequency write cycle, and the least common multiple of the compensation cycle and the high-frequency write cycle is determined as the time difference threshold.

8. The method according to claim 6, characterized in that The determining of the time difference threshold according to the first writing cycle of the local field sequence and the second writing cycle of the associated field comprises: determining a cycle time difference between the first writing cycle and the second writing cycle; In response to the cycle time difference being less than or equal to a preset difference threshold, a least common multiple of the first writing cycle and the second writing cycle is determined as the time difference threshold.

9. A device for generating vehicle bus data, characterized in that: include: The constraint determination module is configured to: capture vehicle status data in real time and determine data constraint conditions based on the vehicle status data; a data generation module configured to: acquire historical bus data, determine vehicle performance parameters of a vehicle model to be tested, and input the historical bus data and vehicle performance parameters into a pre-trained data generation model so that the data generation model outputs a local field sequence under the data constraints; A data solving module is configured to: determine, using the local field sequence as a boundary condition, an associated field corresponding to the local field sequence according to vehicle operating parameters and a physical engine solving model; The time alignment module is configured to: perform time stamp alignment on the local field sequence and the associated field to obtain simulated bus data.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that: When the processor executes the program, the method according to any one of claims 1 to 8 is implemented.

Images