Vehicle system debugging method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of vehicle system debugging, and discloses a vehicle system debugging method and device, electronic equipment and a storage medium, and the method comprises the steps: obtaining a simulation architecture of a target vehicle system, and executing a plurality of preset function tests in a simulation environment, diagnostic logic verification can be completed without depending on a real vehicle. Compared with the prior art, the method has the beneficial effects that the development efficiency is remarkably improved, continuous, rapid and repeatable diagnosis testing can be carried out in a simulation framework, frequent field connection and waiting time are avoided, meanwhile, occupation of real vehicles, special sites and artificial resources is reduced, and the development cost is reduced. And the development cost is obviously reduced, and large-scale parallel projects become possible.

Description

Technical Field

[0001] This invention relates to the field of vehicle system debugging technology, and in particular to a vehicle system debugging method, apparatus, electronic device and storage medium. Background Technology

[0002] As automotive electronic and electrical architectures become increasingly complex, system development and debugging have become one of the most time-consuming and expensive aspects of the vehicle R&D process. Current technologies generally rely on a "real-vehicle debugging" model, where engineers must connect diagnostic equipment to a real vehicle, execute commands, and observe responses. This model has several limitations: First, it is inefficient. Each debugging operation requires connecting to a vehicle, waiting for a system response, and repeatedly triggering fault scenarios, resulting in fragmented time and hindering a continuous, efficient iterative process, severely impacting the R&D cycle. Second, it consumes significant development resources. Diagnostic debugging depends on vehicles, facilities, and on-site engineers. A large number of real vehicles must be simultaneously occupied to support the parallel development of different systems and vehicle models, leading to complex and costly equipment management, which is detrimental to large-scale project implementation. Current technologies typically use CANoe tools to directly connect to real vehicles, requiring hardware reconfiguration for each test, resulting in significant time consumption. Summary of the Invention

[0003] Therefore, it is necessary to propose a vehicle system debugging method, device, electronic equipment and storage medium to address the existing vehicle system debugging problems.

[0004] A method for debugging a vehicle system, the method comprising: Obtain the target simulation architecture for the specified vehicle system; Multiple preset functional tests are performed on the target simulation architecture to obtain the benchmark test results for each preset functional test; The code for the specified vehicle system is adjusted based on the benchmark test results.

[0005] Furthermore, the step of obtaining the target simulation architecture of the specified vehicle system includes: Collect raw communication data from the specified vehicle system; The original communication data is converted into a preset format to obtain the target communication data; The target communication data is input into a preset simulation platform to obtain the target simulation architecture.

[0006] Further, the step of converting the original communication data into a preset format to obtain the target communication data includes: The raw communication data is input into a preset data preprocessing engine to perform data cleaning and protocol parsing to obtain intermediate communication data; The intermediate communication data is input into a preset ODX generation platform to generate target communication data in ODX format.

[0007] Furthermore, the step of adjusting the code of the specified vehicle system based on the benchmark test results includes: The preset functions that fail the benchmark test are recorded as target functions. Extract the initial function code corresponding to the target function; The initial function code is adjusted to obtain the adjusted target function code; The target function code is flashed into the specified vehicle system.

[0008] Furthermore, after the step of adjusting the code of the specified vehicle system based on the benchmark test results, the method further includes: Multiple preset function tests are performed on the specified vehicle system to obtain optimized test results for each preset function test; Compare the benchmark test results with the optimized test results; The benchmark test results and the optimized test results with different comparison results are analyzed to obtain the analysis results; The target simulation architecture is updated based on the analysis results to obtain the updated simulation architecture.

[0009] Furthermore, after the step of updating the target simulation architecture based on the analysis results to obtain the updated simulation architecture, the method further includes: Multiple preset function tests are performed on the updated simulation architecture to obtain accurate test results for each preset function test; The specified vehicle system is adjusted based on the accurate test results.

[0010] Furthermore, after the step of adjusting the code of the specified vehicle system based on the benchmark test results, the method further includes: Multiple preset function tests are performed on the specified vehicle system to obtain optimized test results for each preset function test, and the original test results for each preset function test of the specified vehicle system before adjustment are obtained. Compare the optimized test results with the original test results; The optimized test results and the original test results with different comparison results are analyzed to obtain the analysis results; The target simulation architecture is updated based on the analysis results to obtain the updated simulation architecture.

[0011] A vehicle system debugging apparatus, the apparatus comprising: The acquisition module is used to acquire the target simulation architecture of a specified vehicle system. The testing module is used to perform multiple preset functional tests on the target simulation architecture and obtain benchmark test results for each of the preset functional tests. The adjustment module is used to adjust the code of the specified vehicle system based on benchmark test results.

[0012] An electronic device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the following steps: Obtain the target simulation architecture for the specified vehicle system; Multiple preset functional tests are performed on the target simulation architecture to obtain the benchmark test results for each preset functional test; The code for the specified vehicle system is adjusted based on the benchmark test results.

[0013] A computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the following steps: Obtain the target simulation architecture for the specified vehicle system; Multiple preset functional tests are performed on the target simulation architecture to obtain the benchmark test results for each preset functional test; The code for the specified vehicle system is adjusted based on the benchmark test results.

[0014] The beneficial effects of this invention are as follows: By obtaining the simulation architecture of the target vehicle system and performing multiple preset functional tests in the simulation environment, diagnostic logic verification can be completed without relying on the real vehicle. Compared with the prior art, this significantly improves development efficiency. Continuous, fast, and repeatable diagnostic tests can be performed in the simulation architecture, avoiding frequent on-site connections and waiting time. At the same time, it reduces the occupation of real vehicles, dedicated sites, and human resources, significantly reduces development costs, and makes large-scale parallel projects possible. Attached Figure Description

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

[0016] in: Figure 1 This is an application environment diagram of a vehicle system debugging method in one embodiment; Figure 2This is a flowchart of a debugging method for a vehicle system in one embodiment; Figure 3 This is a structural block diagram of a vehicle system debugging device in one embodiment; Figure 4 This is a structural block diagram of an electronic device in one embodiment. Detailed Implementation

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

[0018] Figure 1 This is a diagram illustrating the debugging application environment of a vehicle system in one embodiment. (Refer to...) Figure 1 This vehicle system debugging method is applied to a vehicle system debugging system. The vehicle system debugging system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal; a mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The terminal 110 is used to adjust the vehicle system, and the server 120 is used to perform multiple preset function tests. This method is applicable to the diagnostic testing of automotive electronic control units (ECUs), such as engine control modules.

[0019] like Figure 2 As shown, in one embodiment, a debugging method for a vehicle system is provided. This method can be applied to both terminals and servers; this embodiment uses terminal application as an example. The debugging method for the vehicle system specifically includes the following steps: S1: Obtain the target simulation architecture of the specified vehicle system; S2: Perform multiple preset functional tests on the target simulation architecture to obtain the benchmark test results of each preset functional test; S3: Adjust the code of the specified vehicle system based on the benchmark test results.

[0020] As described in step S1 above, the target simulation architecture of the specified vehicle system is obtained. This involves identifying which specific vehicle system will be debugged, typically a specific ECU (Electronic Control Unit). Common ECU types include: Engine Control Unit (ECU / ECM): controls engine functions such as fuel injection, ignition, and exhaust gas recirculation; Transmission Control Unit (TCU): controls gear shifting, clutch pressure, etc.; Battery Management System (BMS): manages battery charging, discharging, and balancing; Body Control Module (BCM): controls headlights, door locks, wipers, etc.; Airbag Control Unit (ACU): responsible for collision detection and airbag deployment; and Advanced Driver Assistance Systems (ADAS / Autonomous Driving Controller) (ADCU): processes data from cameras, radar, and other sensors. Through in-depth analysis of the vehicle architecture, the target simulation architecture related to the specified vehicle system is obtained. This involves understanding the functional modules of the specified vehicle system and their interrelationships, including input and output signals, fault handling mechanisms, and implementation logs. The target simulation architecture can be based on previously developed mathematical or software models that accurately simulate the behavior of the ECU under different operating conditions. This architecture enables diagnostics and testing without connecting to a real vehicle, laying the foundation for subsequent functional verification.

[0021] As described in step S2 above, multiple preset functional tests are performed on the target simulation architecture to obtain benchmark test results for each preset functional test. Specifically, a set of specific test cases can be predefined. These test cases are formulated based on the design requirements and functional specifications of the vehicle system, aiming to comprehensively cover the functions of the ECU. By executing these test cases, the system simulates the execution of various functions in the simulation architecture, including combining multiple variables of the ECU's input signals and testing its response under different conditions. The test results are collected and recorded by the system, and the benchmark test results will serve as the basis for subsequent analysis and adjustments.

[0022] As described in step S3 above, the code of the specified vehicle system is adjusted based on the benchmark test results. After all preset functional tests are completed and benchmark test results are obtained, the system will adjust the specified vehicle system (i.e., ECU) based on these results. This aims to analyze and evaluate the test results to identify potential defects and deficiencies in the system. For example, if the test results of a certain function fail to meet the design specifications or expected effects, the developers need to analyze the reasons in depth. It may be that the input signal processing logic is incorrect, or that the control algorithm has defects. Through these debugging processes, the control logic can be modified, the algorithm optimized, or the parameter settings updated in a targeted manner to improve the overall performance of the system.

[0023] In one embodiment, step S1 of obtaining the target simulation architecture of a specified vehicle system includes: S101: Collect raw communication data from the specified vehicle system; S102: Convert the original communication data into a preset format to obtain the target communication data; S103: Input the target communication data into a preset simulation platform to obtain the target simulation architecture.

[0024] As described in step S101 above, raw communication data of the specified vehicle system is collected. Collecting raw communication data from a specific vehicle system (such as an ECU) is typically achieved through diagnostic tools and vehicle communication protocols (such as CAN or LIN). Specifically, diagnostic equipment (such as an OBD-II diagnostic tool or a dedicated CAN data acquisition device) can be connected to the vehicle's diagnostic interface. During vehicle operation or testing, real-time communication data between the target ECU and other modules is captured. This raw communication data includes various information such as message ID, data fields, and timestamps, covering content such as control commands, sensor feedback, and fault codes. To ensure the accuracy and comprehensiveness of the collected data, different driving scenarios (such as idling, acceleration, braking, and steering) are selected to reflect the ECU's performance and behavior under various conditions.

[0025] As described in step S102 above, the raw communication data is converted into a preset format to obtain the target communication data. After the raw communication data is collected, it is converted into a preset format to obtain the target communication data. Since the raw communication data is a variety of data, such as raw CAN / LIN message streams (including timestamps, IDs, and Data), request / response pair sequences, fault codes, freeze frames, parameter change logs, etc., the acquired data is unstructured. Therefore, it needs to be converted into an intermediate format. This format is usually a standardized data format required by the simulation platform, such as JSON, XML, or other structured data formats. This application uses the JSON format, specifically involving data cleaning (removing irrelevant messages such as entertainment system communication, filtering noise frames, and duplicate frames) and parsing (identifying U... The process involves extracting the UDS service ID, sub-function, DID / RID, and extracting the secure access seed-key pair. First, the raw data needs to be denoised, deduplicated, and filtered to remove irrelevant messages and data. Then, the data is processed by a parser, including identifying different message types, protocol IDs, and service functions to ensure the obtained data comprehensively covers the ECU's functional characteristics. Additionally, optional specific parameters (such as fault codes and status information) are extracted for accurate ECU modeling. Data cleaning includes filtering invalid frames (such as messages with ID=0x000) and deduplication. Protocol parsing includes parsing the UDS service ID and DID parameters. The simulation platform is a commercial tool (such as CANoe) based on the ASAM MCD-2 standard or a custom software environment.

[0026] As described in step S103 above, the target communication data is input into a preset simulation platform to obtain the target simulation architecture. This simulation platform is typically a computer-based software system capable of simulating and reconstructing the operation of vehicle systems (such as ECUs) in real-world scenarios. It uses Python scripts to parse intermediate data and calls the ODX library to generate XML files. The system constructs the target simulation architecture on this platform, including various inputs and outputs similar to actual vehicle signals. The platform receives standardized target communication data and creates corresponding models accordingly, comprehensively reproducing the ECU's functional logic, communication protocols, and interactions with other modules. The simulation platform usually includes visualization tools and performance analysis modules, capable of displaying the ECU's status and response in real time, helping to quickly evaluate and verify the ECU's various functions. Then, the target simulation architecture is generated based on the target communication data. This can be done by directly obtaining the corresponding constraints from the target communication data to establish the corresponding target simulation architecture, or by inputting the generated target communication data into the platform, which will convert it into standard ODX format data. That is, the "ODX generation platform" automatically maps the target communication data to .odx files. The ODX generation platform's functions include automatic generation... <diag-comm>Object (service definition); Construction <ecu-variant>Node (ECU variant description); Add <did> 、 <routine> 、 <security-access>Key elements include: support for version management and difference comparison; finally, the standard data is imported into the simulation platform (such as the simulator EcuSimulator) environment. The simulator will give a response to the debugging command that is completely consistent with the real vehicle according to the ODX description, so as to obtain the target simulation architecture. The target simulation architecture can be repeatedly and quickly tested for functionality without occupying any real vehicle resources. The ODX generation platform includes a data mapping module and a verification module, which are used to convert intermediate communication data into XML files that conform to the ODX 2.2 standard.

[0027] In one embodiment, step S102, which converts the original communication data into a preset format to obtain the target communication data, includes: S1021: Input the raw communication data into a preset data preprocessing engine to perform data cleaning and protocol parsing to obtain intermediate communication data; S1022: Input the intermediate communication data into a preset ODX generation platform to generate target communication data in ODX format.

[0028] As described in step S1021 above, the raw communication data is input into a preset data preprocessing engine to perform data cleaning and protocol parsing to obtain intermediate communication data. The main function of the data preprocessing engine is to transform the messy raw data into more structured and standardized intermediate communication data through a series of transformation and processing steps. The aim is to remove irrelevant or noisy messages, such as information unrelated to diagnosis (e.g., entertainment system communication) and duplicate messages, thereby ensuring the accuracy of subsequent parsing and analysis. Next, the protocol parsing process uses specific parsing algorithms and models to analyze the cleaned data, identifying different types of messages and their related information, such as service IDs, sub-functions, and data identifiers (DIDs), and extracting important parameters and status information. Specifically, data cleaning can be based on the CAN database file (DBC) to filter irrelevant messages. The intermediate communication data generated after processing is well-structured and easy to operate in, laying a solid foundation for generating the target communication data in ODX format.

[0029] As described in step S1022 above, the intermediate communication data is input into a preset ODX generation platform to generate target communication data in ODX format. ODX (Open Diagnostic Data Exchange) is a diagnostic data description format conforming to the ASAM MCD-2MC standard. It is used to unify diagnostic and communication protocols in automotive electronic systems, aiming to efficiently and accurately map pre-processed intermediate communication data to the ODX format, ensuring that the generated target communication data conforms to industry standards and can be widely used by diagnostic and testing tools. First, the platform reads the structural information of the intermediate data and identifies the ODX elements to be generated, such as diagnostic services (DIAG-COMM), data identifiers (DID), routines (ROUTINE), and secure access structures. Then, these elements and their related characteristics are assembled into a complete description file conforming to the ODX standard, reflecting the definition and implementation of each function in the protocol. The generated target communication data will be output as an ODX format file, providing standardized data support for subsequent simulation and debugging.

[0030] In one embodiment, step S3, which involves adjusting the code of the specified vehicle system based on benchmark test results, includes: S301: Record the preset functions whose benchmark test results are "failed" as target functions; S302: Extract the initial function code corresponding to the target function; S303: Adjust the initial function code to obtain the adjusted target function code; S304: Write the target function code into the specified vehicle system.

[0031] As described in step S301 above, preset functions that fail the benchmark test are marked as target functions. Specific failed functions are extracted from the test results. These failed functions are often important indicators of system performance or security. In practice, the system statistically analyzes each test result to determine which functions fail to meet preset performance standards or design requirements. These failed functions may involve unidentified fault codes, response times exceeding thresholds, or malfunctioning error handling mechanisms. These functions are marked as target functions for subsequent processing.

[0032] As described in step S302 above, the initial function code corresponding to the target function is extracted. Access to the vehicle control system source code or functional modules is used to obtain the original code required to implement the target function. Typically, the target function has corresponding code implementations in the system, and the source code of these functions may be organized into different modules or classes. Through a code version management system or function database, the initial function code associated with the target function can be accurately identified. The extracted code includes not only the logic parts that directly implement the target function, but may also include various related dependencies, input / output configurations, and state management, etc.

[0033] As described in step S303 above, the initial functional code is adjusted to obtain the adjusted target functional code. The adjustment process may include various corrective measures, such as optimizing the algorithm, modifying parameters, adjusting logical judgments, or fixing potential defects. It is essential to fully understand why the target function failed during the testing phase and to adopt appropriate methods for modification based on the feedback data obtained. For example, if the functional failure is due to a logical error, the corresponding control flow logic needs to be adjusted; if it is due to insufficient response time, the algorithm performance needs to be optimized or the processing complexity reduced. Alternatively, additional error handling mechanisms can be added based on benchmark test results and functional requirements to improve the robustness of the system. After the adjustment is completed, all changes are recorded to form a change log for subsequent evaluation and auditing.

[0034] As described in step S304 above, the target function code is flashed into the designated vehicle system. This involves deploying the tested code to the target ECU to ensure the system can execute the latest functionalities. In practice, flashing can be accomplished using various communication protocols, such as CAN, DoIP, and FOTA (Firmware Over-The-Air), depending on the actual system architecture and configuration. For example, using the DoIP protocol with the ISO 13400 standard for code flashing, the system first performs certain pre-checks to ensure the target ECU is in a suitable state for flashing, such as checking battery power and ensuring a fault-free state. After the flashing operation is complete, the system typically verifies the correct deployment of the new code to ensure the new function can be enabled normally, and confirms the success of the update through a basic self-check or reboot process. When flashing the target function code into the designated vehicle system, the DoIP protocol is used as the communication standard to ensure efficient data transmission via Ethernet connection. Upon initial connection, the system verifies the status of the target ECU to ensure safe flashing. This process includes first authenticating via a secure access service to ensure legitimacy and generating a one-time key to establish secure communication. During the flashing operation, data is sent block by block using the UDS protocol in a specific order. Each block undergoes integrity verification after transmission to prevent data loss or corruption. Furthermore, after flashing, the system performs a self-check to ensure the new function code executes correctly. If any anomalies are found, error messages are logged and subsequent processing is performed. Detailed flashing logs allow for tracing the operation history, ensuring system availability and reliability.

[0035] In one embodiment, after step S3 of adjusting the code of the specified vehicle system based on benchmark test results, the method further includes: S401: Perform multiple preset function tests on the designated vehicle system to obtain optimized test results for each preset function test; S402: Compare the benchmark test results with the optimized test results; S403: Analyze the benchmark test results and the optimized test results that differ from the comparison results to obtain the analysis results; S404: Update the target simulation architecture based on the analysis results to obtain the updated simulation architecture.

[0036] As described in step S401 above, multiple preset function tests are performed on the designated vehicle system to obtain optimized test results for each preset function test. A comprehensive preset function test is then performed again on the adjusted target function to obtain optimized test results. The main purpose of this process is to determine the performance of the adjusted function in a real-world environment, ensuring it meets design specifications and performance standards. Then, the tests are re-performed based on the multiple preset function tests to obtain optimized test results.

[0037] As described in step S402 above, the benchmark test results and the optimization test results are compared. A detailed comparative analysis of the benchmark test results and the optimization test results will be conducted to confirm whether the adjustments to the target function have brought about significant improvements. The comparison process usually involves multiple dimensions, including whether the function passes or fails, response time, frequency of error occurrence, etc. Data analysis tools can be used to accurately match the two test results and identify differences between time series, events, and parameters. This involves not only qualitative analysis but also quantitative analysis, especially on key performance indicators such as response time and resource utilization. By comparing the results of each test case, the performance differences of different versions of the function can be clearly understood, laying the foundation for subsequent in-depth analysis. The intuitive presentation of the comparison results, such as data charts or reports, will help developers quickly identify which adjustments are effective and which still need further processing.

[0038] As described in step S403 above, the benchmark test results and the optimized test results with different results are analyzed to obtain analysis results. The system will conduct an in-depth analysis of the differences between the benchmark test results and the optimized test results to obtain more specific analysis results. The focus of this process is to understand the factors that lead to performance changes and to determine the direction of subsequent optimization through specific problem analysis. For example, statistical analysis methods can be used to check which test cases showed significant improvement or regression in the second round and identify the related factors. During the analysis, system logs, error messages, and runtime environment parameters can be combined to trace the root cause of the problem. By marking successful modifications and functions that still need improvement, it can be determined which strategies are effective in code adjustments and which failed to play their expected role. The final analysis results will help the development team optimize the strategy for feature iteration and lay the foundation for the next update of the target simulation architecture.

[0039] As described in step S404 above, the target simulation architecture is updated based on the analysis results to obtain an updated simulation architecture. By adjusting the simulation architecture to better reflect the target functionality and actual operating environment of the current version, updating the simulation architecture may include multiple technical measures, such as adding new model parameters, improving fault handling mechanisms, and updating the functional interaction interface. Based on the analysis results, detailed records are kept of which information and functions need to be added, modified, or deleted. The newly acquired knowledge is used in the new simulation architecture, which not only helps improve the accuracy and reliability of the simulation process but also enhances the understanding of the system's complexity and dynamism. The updated simulation architecture will become the basis for subsequent functional testing, enabling iteration and evaluation in an environment closer to the real scenario. In addition, through this method, continuous updates to the simulation architecture can also facilitate future expansion and improvement, allowing the system to quickly adapt to new requirements and challenges.

[0040] In one embodiment, after step S404 of updating the target simulation architecture based on the analysis results to obtain the updated simulation architecture, the method further includes: S4051: Perform multiple preset function tests on the updated simulation architecture to obtain accurate test results for each preset function test; S4052: Adjust the specified vehicle system based on the accurate test results.

[0041] As described in step S4051 above, the adjusted and updated simulation architecture is subjected to comprehensive preset functional tests again to obtain accurate test results. The main purpose of this process is to determine the performance of the adjusted and updated simulation architecture in the actual environment, ensure that it meets the design specifications and performance standards, and then retest according to multiple preset functional tests to obtain accurate test results.

[0042] As described in step S4052 above, the specified vehicle system is adjusted based on the accurate test results. This aims to ensure that the overall performance and functionality of the vehicle system can be further improved under the updated simulation architecture. The accurate test results are analyzed to identify any test cases that failed, and targeted optimizations and corrections are made. Adjustments may include modifying control logic, optimizing algorithms, adjusting threshold parameters, or adding new functional items to fully meet performance standards and user requirements. A reasonable adjustment plan can be formulated by referring to previous test results and the updated simulation environment, combined with current actual needs.

[0043] In one embodiment, after step S3 of adjusting the code of the specified vehicle system based on benchmark test results, the method further includes: S411: Perform multiple preset function tests on the designated vehicle system to obtain optimized test results for each preset function test, and obtain the original test results for each preset function test of the designated vehicle system before adjustment. S412: Compare the optimized test results with the original test results; S413: Analyze the optimized test results and the original test results that differ from the comparison results to obtain the analysis results; S414: Update the target simulation architecture based on the analysis results to obtain the updated simulation architecture.

[0044] As described in step S411 above, multiple preset function tests are performed on the designated vehicle system to obtain optimized test results for each preset function test, as well as the original test results for each preset function test of the designated vehicle system before adjustment. Obtaining the original test results of the target function before adjustment ensures that the two independent evaluations of the target function are compared to verify the adjustment effect. First, multiple preset function tests are performed to ensure that the new function implementation is consistent with the design requirements, including whether the function works normally, whether the response time is compliant, and whether the security mechanism is effective. Furthermore, to provide clear change analysis, it is necessary to ensure that all test cases are consistent. The original test results before adjustment also need to be reviewed and collected; this will be the performance baseline data before the function was adjusted. The aim is to provide comprehensive data support for later analysis in a systematic way, ensuring that any changes have solid evidence for comparison and verification, thereby determining whether the adjustment truly improves the performance and reliability of the vehicle system.

[0045] As described in step S412 above, the optimized test results and the original test results are compared. A detailed comparative analysis of the optimized test results and the original test results is conducted. The purpose of this process is to gain a deeper understanding of the substantial changes between the adjusted function and the function before the adjustment. Through comparison, it is possible to clearly identify whether the adjusted target function has advantages in key performance indicators, such as whether the function is enhanced, whether the running speed is improved, or whether there are new faults or problems. The comparison work is not limited to a simple pass or fail judgment, but also needs to focus on the specific values ​​of each performance indicator. Based on these data, the adjustment effect can be evaluated more accurately, providing a basis for subsequent analysis and improvement. At this stage, data visualization tools can be used to intuitively display the differences in test results, making the data easy to understand and interpret, helping to quickly identify problems and make targeted adjustments.

[0046] As described in step S413 above, the optimized test results and the original test results with different results are analyzed to obtain the analysis results. If the optimized test results show a significant improvement, it is necessary to understand which specific adjustments have played a positive role and how these adjustments have affected the function's response and behavior. Conversely, if no expected improvement is seen or the function deteriorates, it is necessary to trace back to code adjustments and the testing environment to identify potential root causes of the problem. Specific analyses may include component comparison, error log review, status monitoring, etc., to deeply mine the information behind the data from multiple dimensions.

[0047] As described in step S414 above, the target simulation architecture is updated based on the analysis results to obtain an updated simulation architecture. The purpose of this process is to ensure that the simulation architecture better reflects the actual performance and requirements of the system. The update work is typically based on problems or successful strategies discovered in the analysis results, adjusting parameters, models, and logic in the simulation environment. For example, if a specific function performs well in the second test but poorly in the fourth test, the implementation method and interaction logic of that function can be analyzed and improved through the real-time updated simulation architecture. Conversely, if positive feedback is received, successful strategies can be retained and strengthened. The updated simulation architecture generated through this step will provide a more realistic environment for subsequent functional testing and debugging, greatly improving the efficiency and accuracy of subsequent development work.

[0048] Reference Figure 3 The present invention also provides a vehicle system debugging apparatus, the apparatus comprising: Module 902 is used to obtain the target simulation architecture of a specified vehicle system; Test module 904 is used to perform multiple preset functional tests on the target simulation architecture and obtain benchmark test results for each of the preset functional tests; Adjustment module 906 is used to adjust the code of the specified vehicle system based on benchmark test results.

[0049] In one embodiment, the acquisition module 902 includes: The raw communication data acquisition submodule is used to acquire raw communication data of a specified vehicle system. The target communication data acquisition submodule is used to convert the original communication data into a preset format to obtain the target communication data. The target simulation architecture acquisition submodule is used to input the target communication data into a preset simulation platform to obtain the target simulation architecture.

[0050] In one embodiment, the target communication data acquisition submodule includes: An intermediate communication data acquisition unit is used to input the raw communication data into a preset data preprocessing engine to perform data cleaning and protocol parsing in order to obtain intermediate communication data. The target communication data acquisition unit is used to input the intermediate communication data into a preset ODX generation platform to generate target communication data in ODX format.

[0051] In one embodiment, the adjustment module 906 includes: The marking submodule is used to mark the preset functions that fail the benchmark test as target functions. The initial function code extraction submodule is used to extract the initial function code corresponding to the target function; The adjustment submodule is used to adjust the initial function code to obtain the adjusted target function code; The flashing submodule is used to flash the target function code into the specified vehicle system.

[0052] In one embodiment, the vehicle system debugging method further includes: The optimized test result acquisition module is used to perform multiple preset function tests on the specified vehicle system and obtain optimized test results for each preset function test. The first comparison module is used to compare the benchmark test results and the optimization test results; An analysis module is used to analyze the benchmark test results and the optimization test results that differ in the comparison results, in order to obtain analysis results; The simulation architecture acquisition module is used to update the target simulation architecture based on the analysis results, thereby obtaining the updated simulation architecture.

[0053] In one embodiment, the vehicle system debugging method further includes: The accurate test result acquisition module is used to perform multiple preset function tests on the updated simulation architecture and obtain accurate test results for each preset function test. The vehicle system adjustment module is used to adjust the specified vehicle system based on accurate test results.

[0054] In one embodiment, the vehicle system debugging method further includes: The original test results module is used to perform multiple preset function tests on the specified vehicle system, obtain optimized test results for each preset function test, and obtain the original test results of each preset function test of the specified vehicle system before adjustment. The second comparison module is used to compare the optimized test results with the original test results; The analysis result acquisition module is used to analyze the optimized test results and the original test results that have different comparison results to obtain the analysis results; The update module is used to update the target simulation architecture based on the analysis results to obtain the updated simulation architecture.

[0055] Figure 4 An internal structural diagram of an electronic device in one embodiment is shown. This electronic device can specifically be a terminal or a server, and more specifically, a computer device. Figure 4 As shown, the electronic device includes a processor, a memory, and a network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement a debugging method for the vehicle system. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to implement a debugging method for the vehicle system. Those skilled in the art will understand that… Figure 4 The 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 electronic device to which the present application is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0056] In one embodiment, an electronic device is provided, including a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the following steps: Obtain the target simulation architecture for the specified vehicle system; Multiple preset functional tests are performed on the target simulation architecture to obtain the benchmark test results for each preset functional test; The code for the specified vehicle system is adjusted based on the benchmark test results.

[0057] By acquiring the simulation architecture of the target vehicle system and executing multiple preset functional tests in the simulation environment, diagnostic logic verification can be completed without relying on the real vehicle. Compared with existing technologies, this significantly improves development efficiency, enables continuous, rapid, and repeatable diagnostic testing in the simulation architecture, avoids frequent on-site connections and waiting time, and reduces the occupation of real vehicles, dedicated sites, and human resources, significantly reducing development costs and making large-scale parallel projects possible.

[0058] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the following steps: Obtain the target simulation architecture for the specified vehicle system; Multiple preset functional tests are performed on the target simulation architecture to obtain the benchmark test results for each preset functional test; The code for the specified vehicle system is adjusted based on the benchmark test results.

[0059] By acquiring the simulation architecture of the target vehicle system and executing multiple preset functional tests in the simulation environment, diagnostic logic verification can be completed without relying on the real vehicle. Compared with existing technologies, this significantly improves development efficiency, enables continuous, rapid, and repeatable diagnostic testing in the simulation architecture, avoids frequent on-site connections and waiting time, and reduces the occupation of real vehicles, dedicated sites, and human resources, significantly reducing development costs and making large-scale parallel projects possible.

[0060] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0061] 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 specification.

[0062] 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 patent application should be determined by the appended claims. < / routine> < / did>

Claims

1. A method for debugging a vehicle system, characterized in that, The method includes: Obtain the target simulation architecture for the specified vehicle system; Multiple preset functional tests are performed on the target simulation architecture to obtain the benchmark test results for each preset functional test; The code for the specified vehicle system is adjusted based on the benchmark test results.

2. The vehicle system debugging method according to claim 1, characterized in that, The step of obtaining the target simulation architecture of the specified vehicle system includes: Collect raw communication data from the specified vehicle system; The original communication data is converted into a preset format to obtain the target communication data; The target communication data is input into a preset simulation platform to obtain the target simulation architecture.

3. The vehicle system debugging method according to claim 2, characterized in that, The step of converting the original communication data into a preset format to obtain the target communication data includes: The raw communication data is input into a preset data preprocessing engine to perform data cleaning and protocol parsing to obtain intermediate communication data; The intermediate communication data is input into a preset ODX generation platform to generate target communication data in ODX format.

4. The vehicle system debugging method according to claim 1, characterized in that, The step of adjusting the code of the specified vehicle system based on the benchmark test results includes: The preset functions that fail the benchmark test are recorded as target functions. Extract the initial function code corresponding to the target function; The initial function code is adjusted to obtain the adjusted target function code; The target function code is flashed into the specified vehicle system.

5. The vehicle system debugging method according to claim 1, characterized in that, Following the step of adjusting the code of the specified vehicle system based on benchmark test results, the method further includes: Multiple preset function tests are performed on the specified vehicle system to obtain optimized test results for each preset function test; Compare the benchmark test results with the optimized test results; The benchmark test results and the optimized test results with different comparison results are analyzed to obtain the analysis results; The target simulation architecture is updated based on the analysis results to obtain the updated simulation architecture.

6. The vehicle system debugging method according to claim 5, characterized in that, After the step of updating the target simulation architecture based on the analysis results to obtain the updated simulation architecture, the method further includes: Multiple preset function tests are performed on the updated simulation architecture to obtain accurate test results for each preset function test; The specified vehicle system is adjusted based on the accurate test results.

7. The vehicle system debugging method according to claim 1, characterized in that, Following the step of adjusting the code of the specified vehicle system based on benchmark test results, the method further includes: Multiple preset function tests are performed on the specified vehicle system to obtain optimized test results for each preset function test, and the original test results for each preset function test of the specified vehicle system before adjustment are obtained. Compare the optimized test results with the original test results; The optimized test results and the original test results with different comparison results are analyzed to obtain the analysis results; The target simulation architecture is updated based on the analysis results to obtain the updated simulation architecture.

8. A debugging device for a vehicle system, characterized in that, The device includes: The acquisition module is used to acquire the target simulation architecture of a specified vehicle system. The testing module is used to perform multiple preset functional tests on the target simulation architecture and obtain benchmark test results for each of the preset functional tests. The adjustment module is used to adjust the code of the specified vehicle system based on benchmark test results.

9. A computer-readable storage medium, characterized in that, The system contains a computer program that, when executed by a processor, causes the processor to perform the steps of the debugging method for the vehicle system as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the debugging method for the vehicle system as described in any one of claims 1 to 7.

Images