A debugging data acquisition method and related apparatus

Abstract

The application discloses a debugging data acquisition method and related device, and relates to the technical field of vehicle testing. The test flow is split into multiple test flow components according to a test period, and is combined with a data acquisition component to form a test running entity for testing a target electronic control unit. The test results of the test flow components are acquired during the execution of the test flow. When the test results of a test period meet a target abnormal condition, the data acquisition component is triggered to execute a corresponding debugging data acquisition process, so that the debugging data acquisition process can be triggered in time during the execution of the test flow. Thus, compared with the method of performing debugging after the test is completed, the debugging data for the target electronic control unit can be acquired when an abnormality occurs, the probability of losing key information is reduced, and the efficiency of problem positioning and the accuracy of the debugging data are improved.

Description

Technical Field

[0001] This invention relates to the field of vehicle testing technology, and in particular to a method and related apparatus for acquiring debugging data. Background Technology

[0002] During the software development and verification process of an Electronic Control Unit (ECU), it is usually necessary to perform tests on the ECU to verify whether its functions are abnormal.

[0003] In related technologies, test code is typically run, and the results are used to determine if the electronic control unit (ECU) is malfunctioning. When abnormalities are found in the test results, further debugging of the ECU is often required manually or with the aid of independent debugging tools to determine the cause of the fault.

[0004] However, the accuracy of the debugging data is low in the above methods. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a debugging data acquisition method and related apparatus to improve the accuracy of debugging data.

[0006] Based on this, the following technical solution is disclosed in this application: In a first aspect, embodiments of this application provide a debugging data acquisition method, applied to a client, the client being used to test an electronic control unit, the method comprising: A test run entity for the target electronic control unit is obtained. The test run entity includes multiple test process components for executing test processes and a data acquisition component for executing debug data acquisition processes. The multiple test process components correspond to different test stages. The test run entity runs on the client. Based on the test processes corresponding to the multiple test process components included in the test operation entity, the target electronic control unit is tested, and during the execution of the test process, the test results of the test phase corresponding to the test process component are obtained. When executing the j-th test phase through the i-th test process component, if the test result of the j-th test phase meets the target anomaly condition, then based on the debugging data acquisition process corresponding to the data acquisition component, debugging data for the target electronic control unit is acquired. The debugging data is data used to locate the anomaly of the target electronic control unit, where i is a positive integer and j is a positive integer.

[0007] Secondly, embodiments of this application provide a debugging data acquisition device applied to a client, the client being used to test an electronic control unit, the device comprising: The acquisition unit is used to acquire a test run entity for the target electronic control unit. The test run entity includes multiple test process components for executing test processes and a data acquisition component for executing debug data acquisition processes. The multiple test process components correspond to different test stages, and the test run entity runs on the client. The testing unit is used to test the target electronic control unit based on the test processes corresponding to the multiple test process components included in the test operation entity, and to obtain the test results of the test phase corresponding to the test process component during the execution of the test process. The acquisition unit is further configured to, when executing the j-th test stage through the i-th test process component, if the test result of the j-th test stage meets the target abnormality condition, acquire debugging data for the target electronic control unit based on the debugging data acquisition process corresponding to the data acquisition component. The debugging data is data used to locate the abnormality of the target electronic control unit, where i is a positive integer and j is a positive integer.

[0008] Thirdly, embodiments of this application provide a computer device, the computer device including a processor and a memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the method described in the first aspect above according to the computer program.

[0009] Fourthly, embodiments of this application provide a computer-readable storage medium for storing a computer program for performing the method described in the first aspect above.

[0010] Fifthly, embodiments of this application provide a computer program product including a computer program, which, when run on a computer device, causes the computer device to perform the method described in the first aspect above.

[0011] As can be seen from the above technical solutions, this application has at least the following beneficial effects: By breaking down the testing process into multiple testing process components according to the testing cycle, and combining them with a data acquisition component to form a test execution entity for testing the target electronic control unit, the test results of the testing process components are acquired during the execution of the testing process. When the test results of a certain testing cycle meet the target abnormal conditions, the corresponding debug data acquisition process is triggered to execute the component. This ensures that the debug data acquisition process can be triggered in a timely manner during the execution of the testing process. Therefore, compared to debugging after the test is completed, debug data for the target electronic control unit can be obtained when an anomaly occurs, reducing the probability of losing critical information and improving the efficiency of problem localization and the accuracy of debug data.

[0012] Furthermore, since the test process is divided into multiple test process components based on the test phase, the debugging data acquisition process is encapsulated through the data acquisition component. This not only decouples the test process and the debugging process, improving reusability, but also makes the debugging process correspond to the test phase in which the specific exception occurs. This narrows the scope of debugging data acquisition, reduces interference from irrelevant data, improves the relevance and effectiveness of the acquired debugging data, and further enhances the accuracy of the debugging data. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application 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 recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart illustrating a debugging data acquisition method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a debugging data acquisition device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0015] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0016] In related technologies, the debugging process is usually separated from the testing process, making it difficult to obtain relevant data when test anomalies occur in a timely manner. This can easily lead to incomplete debugging data when anomalies occur, thus affecting the accuracy of problem localization.

[0017] For example, during testing, the electronic control unit (ECU) might experience a communication anomaly at a certain moment, failing to return the expected message, thus being identified as a test anomaly. However, when debugging is performed after the test, the ECU may have already returned to normal operation. At this point, reading the relevant data will no longer reflect the true situation at the time of the anomaly, resulting in incomplete or inaccurate debugging data.

[0018] Based on this, embodiments of this application provide a debugging data acquisition method and related apparatus. By dividing the test process into multiple test process components according to the test cycle, and combining these components with a data acquisition component to form a test execution entity for testing the target electronic control unit, the method acquires the test results of the test process components during the execution of the test process. When the test results of a certain test cycle meet the target abnormal condition, the data acquisition process is triggered to execute the corresponding debugging data acquisition process in the component. This ensures that the debugging data acquisition process can be triggered promptly during the execution of the test process. Therefore, compared to debugging after the test is completed, debugging data for the target electronic control unit can be acquired when an abnormality occurs, reducing the probability of losing critical information and improving the efficiency of problem localization and the accuracy of debugging data.

[0019] All data collected in this application (such as test results, debugging data, etc.) are collected with the consent and authorization of the data subject (such as user, organization or enterprise), and the collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0020] See Figure 1 This figure is a schematic flowchart of the debugging data acquisition method provided in an embodiment of this application. For ease of description, the following embodiment uses the computer device where the client is located as the execution subject of the debugging data acquisition method. Figure 1 As shown, the debugging data acquisition method includes S101-S103.

[0021] S101: Obtain the test run entity for the target electronic control unit.

[0022] In this embodiment of the application, the target electronic control unit is an electronic control unit that has been tested by the client. The following will take the target electronic control unit as an example to illustrate the debugging data acquisition method proposed in this embodiment of the application.

[0023] A test execution entity is a runtime entity used to represent a test case. For example, an executable test execution entity can be obtained by organizing, loading, and instantiating test cases. Test entities can run on the client side.

[0024] The test execution entity includes multiple test process components for executing the test process and a data acquisition component for executing the debug data acquisition process. Each test process component corresponds to a different test phase. A test process is at least one test operation step set for a test objective, and a test process component is a component used to implement the test process. A debug data acquisition process is at least one data acquisition step set for acquiring debug data, and a data acquisition component is a component used to implement the debug data acquisition process. Debug data is data used to locate anomalies in the target electronic control unit.

[0025] The testing phases are defined based on the testing process; multiple testing phases constitute a complete testing process. Specifically, each testing phase can have corresponding test results.

[0026] This application does not specifically limit the way the testing phase is divided. The following describes three ways of dividing the phase: One method of partitioning is according to the test execution order. For example, preparation phase, initialization phase, execution phase, result judgment phase, and termination phase.

[0027] The second method of division is based on the test content. For example, communication testing phase, functional testing phase, anomaly testing phase, recovery testing phase, etc.

[0028] The third method of division is based on the testing cycle. For example, the first testing cycle (basic verification), the second testing cycle (functional testing), and the third testing cycle (boundary testing).

[0029] In one possible implementation, the multiple test process components may include a triggering component, a data acquisition component, and a decision component. The triggering component is used to trigger the target electronic control unit to perform the expected behavior, the data acquisition component is used to acquire the communication data or operating data of the target electronic control unit during the test, and the decision component is used to make a decision on the acquired data according to preset rules.

[0030] In one possible implementation, the test process component can execute the test process by calling the corresponding test function component, which is used to perform test functions. For example, the test function component may include a Controller Area Network (CAN) message transceiver component, a Universal Measurement and Calibration Protocol (XCP) calibration and observation component, an End-to-End Communication (E2E) and Safe Onboard Communication (SecOC) protection component, and an Over-the-Air (OTA) flashing component, etc.

[0031] The CAN message transceiver component is used to communicate with the target electronic control unit (ECU) via the CAN bus, performing message sending and receiving. The XCP calibration and observation component accesses the target ECU's internal storage or operating variables via the XCP protocol, performing online calibration, modification, and download operations on the target ECU's parameters, and real-time observation and acquisition of internal variables, status quantities, and measurements. The E2E and SecOC protection components perform end-to-end protection processing on the data to be sent or received, and perform authenticity verification and integrity protection on communication messages. The OTA flashing component distributes software packages, firmware packages, or configuration data to the target ECU via the network, and performs operations such as program flashing, version upgrades, partition updates, flashing result verification, and upgrade rollback.

[0032] In one possible implementation, configuration files for multiple test components can be obtained, either from a server or pre-stored on the client.

[0033] Based on the configuration files for multiple test components, determine the types of test process components, their execution order, the binding relationships between test process components and test function components, the judgment rules for each test process component, and the exception conditions. Exception conditions are used to determine whether a test result is abnormal. Examples include: a test judgment result (i.e., the result obtained based on the test result) is a failure; a test judgment result is a warning, such as timing jitter or threshold deviation; the expected communication message or signal is not collected within a preset time window; inconsistent results occur in multiple executions of the same test case; and a test case is marked as a critical case requiring enhanced debugging data.

[0034] Therefore, by introducing configuration files for multiple test components, and defining the types, execution order, binding relationships with test functional components, judgment rules, and exception conditions based on these configuration files, the test process can be flexibly adjusted without modifying the test program, reducing the maintenance cost of test cases. Furthermore, defining exception conditions through configuration files not only supports unified judgment of various exception scenarios (such as failures, warnings, communication gaps, and inconsistent results), but also allows for the expansion of exception conditions, making the judgment of test results more accurate and comprehensive.

[0035] S102: Based on the test processes corresponding to the multiple test process components included in the test run entity, the target electronic control unit is tested, and the test results of the test phase corresponding to the test process component are obtained during the execution of the test process.

[0036] After obtaining the test run entity, the client can test the target electronic control unit according to its respective test process based on the multiple test process components included in the test run entity.

[0037] During execution, each test process component can be executed sequentially or according to logical relationships. After each test phase is executed, the test results corresponding to that test phase can be obtained, thereby realizing phased testing of the entire test process and obtaining phased test results.

[0038] The embodiments of this application do not specifically limit the correspondence between test run components and test phases. They can be one-to-one or one test run component can correspond to multiple test phases.

[0039] S103: When executing the j-th test stage through the i-th test process component, if the test result of the j-th test stage meets the target abnormal condition, then based on the debugging data acquisition process corresponding to the data acquisition component, the debugging data for the target electronic control unit is acquired.

[0040] The i-th test process component is any one of multiple test process components, where i is a positive integer representing the sequence number of the test process component. The j-th test stage is any one of the test stages in the entire test process, where j is a positive integer representing the sequence number of the test stage.

[0041] The following example illustrates the exception detection process when the i-th test process component executes the j-th test phase.

[0042] Specifically, after obtaining the test result of the j-th test phase, it can be determined whether the test result meets the abnormal condition. If the target abnormal condition is met, the debug data acquisition process is triggered. Based on the debug data acquisition process corresponding to the data acquisition component, debug data for the target electronic control unit is acquired. Here, the target abnormal condition is a type of abnormal condition.

[0043] In related technologies, the process typically involves completing the entire test first, identifying anomalies based on the test results, and then manually or with the aid of independent tools to debug the electronic control unit. This can lead to a situation where, by the time actual debugging begins, the electronic control unit may have already deviated from its operating state at the time of the anomaly, much crucial field information has been lost, and the data used for debugging cannot accurately reflect the situation at the time of the anomaly.

[0044] In S103, anomalies are determined directly based on test results at a certain test stage during the test execution process, and debugging data is obtained immediately, which can preserve the true state of the target electronic control unit when the anomaly occurs to a greater extent.

[0045] As one possible approach, test results can be either directly collected raw data or results obtained through further analysis based on the raw data.

[0046] As one possible implementation, the server can be used to send test tasks and test resources to the client. The test resources may include test execution entities. The server can also be used to receive relevant information reported by the client, such as test logs, collected data, and test results.

[0047] As one possible implementation, the server can be used to distribute test tasks and test resources to multiple clients in parallel, thereby achieving distributed testing and enabling the testing of multiple electronic control units at the same time, thus improving testing efficiency.

[0048] The following scenario illustrates the above method implementation: Assume the i-th test process component is a communication test component, and the j-th test stage is a message receiving stage. In this stage, the client sends a control message to the target electronic control unit and waits for the electronic control unit to return a response message within a preset time window. If the expected message is not received within this time window, the test result of the j-th test stage meets the target anomaly condition. At this time, the data acquisition component is triggered to execute the debug data acquisition process, such as: capturing the current CAN bus message, reading the current communication status of the target electronic control unit, obtaining the anomaly information in the communication buffer, and recording the timestamp and environmental parameters of this test stage. By acquiring the above debug data, it is possible to further determine whether the anomaly is caused by bus congestion, message loss, lack of response from the electronic control unit, or protocol anomaly.

[0049] It is important to emphasize that this application, by breaking down the testing process into multiple testing process components and introducing a data acquisition component within the same test execution entity, enables each testing phase to independently generate test results and participate in the judgment of abnormal conditions in real time. When the test result of any testing phase meets the abnormal conditions, the debugging component can be immediately triggered to execute the debugging data acquisition process, thereby obtaining debugging data that reflects why the target electronic control unit is abnormal more promptly after an anomaly occurs. Compared to the existing technology of debugging after the test is completed, embedding debugging capabilities into the test execution process using a component-based structure binds the debugging triggering time to the test phase where the anomaly occurs, reducing the probability of losing key information due to the recovery of the target electronic control unit's state, and improving the accuracy of debugging data and the efficiency of problem localization. In addition, the component-based testing approach provides a unified test execution model, improving the reusability of test cases.

[0050] As can be seen from the above technical solution, by breaking down the testing process into multiple testing process components according to the testing cycle, and combining them with the data acquisition component to form a test execution entity for testing the target electronic control unit, the test results of the testing process components are acquired during the execution of the testing process. When the test results of a certain testing cycle meet the target abnormal conditions, the data acquisition process is triggered to execute the corresponding debugging data acquisition process in the component. This ensures that the debugging data acquisition process can be triggered in a timely manner during the execution of the testing process. Therefore, compared to debugging after the test is completed, debugging data for the target electronic control unit can be obtained when an anomaly occurs, reducing the probability of losing key information and improving the efficiency of problem localization and the accuracy of debugging data.

[0051] Furthermore, since the test process is divided into multiple test process components based on the test phase, the debugging data acquisition process is encapsulated through the data acquisition component. This not only decouples the test process and the debugging process, improving reusability, but also makes the debugging process correspond to the test phase in which the specific exception occurs. This narrows the scope of debugging data acquisition, reduces interference from irrelevant data, improves the relevance and effectiveness of the acquired debugging data, and further enhances the accuracy of the debugging data.

[0052] In one possible implementation, the debug data acquisition process is used to execute multiple data acquisition processes, which can be executed serially to obtain debug data for the target electronic control unit.

[0053] The data acquisition process is an execution unit used to acquire debug data, and is used to acquire at least one piece of debug data.

[0054] Serial execution refers to multiple data acquisition processes being executed sequentially, one after another, with the next process starting only after the previous one has finished. Unlike parallel execution, serial execution emphasizes that one data acquisition process must complete before the next one begins, thus preventing multiple data acquisition processes from accessing the electronic control unit or communication resources simultaneously.

[0055] For example, the data acquisition process can be used to perform at least one of the following operations: Read the operating status, session status, and internal variables of the electronic control unit based on the UDS or XCP protocol; Read key data areas or status flags from the internal memory of the electronic control unit; Obtain the current diagnostic fault codes (DTCs) and event status information of the electronic control unit; The system can perform backtracking acquisition and freezing of specified CAN communication messages or specified Ethernet communication messages; wherein, the specified CAN communication message or specified Ethernet communication message can be determined based on trigger conditions.

[0056] Perform continuous sampling or instantaneous snapshots of key measurement quantities; Obtain the operation log or debugging log information output by the electronic control unit.

[0057] Therefore, by breaking down the debugging data acquisition process into multiple data acquisition processes and executing them sequentially, each data acquisition process exclusively occupies relevant communication resources or electronic control unit access channels during execution. This avoids communication conflicts, resource contention, and data overwriting issues that arise when multiple data acquisition processes execute in parallel, thus improving the stability and reliability of each debugging data acquisition process. Since different data acquisition processes do not interfere with each other, it ensures that the acquired debugging sub-data has a consistent timing relationship and integrity, thereby improving the accuracy of the debugging data. Furthermore, by refining the debugging data acquisition process into multiple independent data acquisition processes and executing them sequentially, it is easy to flexibly configure data acquisition strategies according to different abnormal scenarios, improving the system's scalability and adaptability while ensuring the stability of the debugging process.

[0058] Furthermore, during the execution of any data acquisition process, the test processes corresponding to each test process component can be paused to obtain debugging data for the target electronic control unit. In other words, during the execution of a data acquisition process, not only are other data acquisition processes not executed, but all test processes are also paused.

[0059] Therefore, by pausing the test process during any data acquisition process, the target electronic control unit is kept in a relatively stable operating state during the debugging data acquisition process. This can, to some extent, avoid interference with the state of the target electronic control unit caused by the continuous execution of the test process, reduce the probability of state changes in the target electronic control unit, and make the acquired debugging data more consistent with the state at the time of the anomaly.

[0060] In one possible implementation, a configuration file for the data acquisition component can be obtained. This configuration file allows for flexible configuration of the data acquisition process. Specifically: Based on the configuration file, determine the types of multiple data acquisition processes, the execution order of multiple data acquisition processes, the communication protocols corresponding to multiple data acquisition processes, the data source locations corresponding to multiple data acquisition processes, and the parameter information corresponding to multiple data acquisition processes.

[0061] The communication protocol refers to the communication method used by the data acquisition process to interact with the target electronic control unit (ECU). The data source location describes the location of the debug data, such as the ECU's internal storage area (e.g., RAM variable area), ECU diagnostic module (fault code storage area), communication bus (CAN bus, Ethernet), log buffer, etc. Parameter information describes how the data acquisition process acquires debug data, such as the sampling frequency, the time window for sampling debug data, and the sampling duration.

[0062] In one possible implementation, the configuration file can be obtained from a server.

[0063] Therefore, by introducing configuration files for the data acquisition component, the type, execution order, communication protocol, data source location, and parameter information of the data acquisition process can be configured. This allows for flexible adjustment and debugging of the data acquisition process based on different abnormal scenarios without modifying the program code, improving the flexibility and scalability of adjusting the data acquisition process. Debugging the data acquisition process does not depend on specific communication implementations or hardware environments, thereby improving adaptability and reusability in different electronic control units and different test platforms.

[0064] In one possible implementation, structured information can also be generated for the debugging data.

[0065] Specifically, based on the target anomaly conditions, the associated data corresponding to the debugging data is obtained. Based on the debugging data and associated data of the target electronic control unit, structured information for the debugging data is generated.

[0066] Among them, the associated data corresponding to the debugging data are the data that affects the test results of the j-th test stage to meet the target anomaly conditions. Structured information is used to associate debugging data and its corresponding associated data during the debugging process in order to locate the anomaly cause of the test results of the j-th test stage meeting the target anomaly conditions.

[0067] Specifically, when the test result in the j-th test phase meets the target anomaly condition, the associated data that causes the test result to meet the target anomaly condition can be obtained from the external data source based on the target anomaly condition. The structured information is generated by combining the debugging data and the associated data, so that the debugging data no longer exists in an isolated form, but can be uniformly represented with the associated data, thereby realizing the centralized expression of abnormal behavior data.

[0068] For example, if the target abnormal condition is the occurrence of fault A, and the test result is data related to fault A, then data related to fault B that could cause fault A, and signal C that could cause fault A, can be obtained from an external data source. The data related to fault B and signal C are used as correlated data and combined with debugging data to generate structured information for the test results.

[0069] In one possible implementation, structured information about the test results can be generated based on the relationships between debugging data, related data, test results, and the related data. These relationships indicate how the related data influences the test results to meet the target anomaly conditions. For example, if the target anomaly condition is the occurrence of fault A, the test results are related data for fault A, and the related data are related data for fault B, then the relationships could be fault decision trees containing fault A and fault B.

[0070] Therefore, by introducing the correlation between test results and related data (such as fault decision tree relationships), we can further characterize the impact path of anomalies and enhance the logic and interpretability of debugging results.

[0071] In one possible implementation, when generating structured information, the following information can be automatically associated: test case identification information, test execution time and execution environment information, target abnormal conditions, judgment results for target abnormal conditions, and software version and configuration version information of the target electronic control unit.

[0072] Therefore, by obtaining relevant data that affects the anomaly from external data sources based on the target anomaly conditions, and combining it with debugging data to generate structured information, it is possible to correlate and map the anomaly results with their potential causes, thereby improving the accuracy of anomaly localization and the efficiency of analysis.

[0073] This application does not specifically limit the path for obtaining debugging data. The following describes two methods for obtaining data: For path one, if the test data of the j-th test phase includes debug data, then based on the debug data acquisition process corresponding to the data acquisition component, the debug data for the target electronic control unit is obtained from the test data of the j-th test phase. Here, the test data of the j-th test phase refers to the data generated during the execution of the j-th test phase.

[0074] This application does not specifically limit how to determine whether the test data of the j-th test stage includes debugging data. The following describes three determination methods.

[0075] Method 1: The test data in the j-th test phase can be determined based on the data type indicated by the debug data acquisition process. For example, the data type indicated by the debug data acquisition process may include communication messages, diagnostic fault codes, status variables, operation logs, key measurements, session states, internal storage data, etc. If the test data in the j-th test phase already includes at least one of the above data types, then it can be determined that the test data in the j-th test phase includes debug data.

[0076] For example, if the debugging data acquisition process is used to acquire the communication message of the target electronic control unit, and the communication message has already been collected in the test data of the j-th test stage, then the communication message can be directly acquired from the test data of the j-th test stage as debugging data for the target electronic control unit.

[0077] The second method involves determining whether the test data in the j-th test phase includes debug data based on the data identifiers indicated in the debug data acquisition process. For example, data identifiers may include message identifiers, signal identifiers, variable names, fault code identifiers, log identifiers, measurement quantity names, and storage address identifiers. If data matching this identifier exists in the test data of the j-th test phase, then it can be determined that the test data of the j-th test phase includes debug data.

[0078] For example, if the debug data acquisition process is used to acquire the CAN message with message identifier 0x123, and the test data of the j-th test stage already includes the CAN message with message identifier 0x123, then it can be determined that the test data includes debug data.

[0079] The third method involves determining whether the test data in the j-th test phase includes debug data based on the data source location indicated by the debug data acquisition process. For example, the data source location can indicate that debug data originates from the communication bus, internal variables of the electronic control unit, the log buffer, or the calibration observation channel. If the test data in the j-th test phase contains data from the same data source location, it can be further determined that the test data includes debug data.

[0080] For example, if the debugging data acquisition process is used to obtain the internal variables of the target electronic control unit from the calibration observation channel, and the test data of the j-th test stage already includes the internal variables collected through the calibration observation channel, then the corresponding debugging data can be obtained from the test data.

[0081] Therefore, since the test data in the j-th test phase already includes debug data, debug data can be directly obtained based on the test data without additional interaction with the target electronic control unit. This reduces communication overhead and processing latency during data acquisition, improving the efficiency of debug data acquisition. Furthermore, because the debug data originates from the test data generated during the test process, consistency between the debug data and test results in terms of time and execution context is guaranteed, which helps improve the accuracy of anomaly analysis.

[0082] For path two, if the test data of the j-th test phase does not include debug data, then based on the debug data acquisition process corresponding to the data acquisition component, the debug data for the target electronic control unit is obtained from the target electronic control unit.

[0083] Therefore, even if the test data in the j-th test phase does not include debugging data, obtaining debugging data from the target electronic control unit can overcome the limitations of the test data itself and obtain more comprehensive debugging data, thereby improving the coverage and analysis depth of abnormal situations.

[0084] In one possible implementation, the target communication protocol for acquiring debug data can be determined based on the target anomaly conditions. Based on the debug data acquisition process corresponding to the data acquisition component, debug data for the target electronic control unit is acquired through the target communication protocol.

[0085] The target communication protocol is the communication protocol corresponding to the target abnormal condition.

[0086] The data type of the debug data obtained may differ depending on the specific exception conditions. In related technologies, when obtaining debug data of different data types, the specific communication protocol needs to be specified in the test code. However, this method is cumbersome, requiring modifications to the test code to specify the different communication protocols each time the debug data type changes.

[0087] In this embodiment of the application, the communication protocol corresponding to the abnormal condition is automatically matched to achieve automatic adaptation of the data type of the debugging data, thereby decoupling the underlying communication protocol from the test process.

[0088] For example, when the target anomaly is an abnormal calibration parameter, the target communication protocol can be determined to be the XCP protocol to obtain the internal calibration parameters of the electronic control unit. When the target anomaly is an abnormal communication message, the target communication protocol can be determined to be the CAN protocol to obtain bus message data. When the target anomaly is an abnormal remote diagnostic, the target communication protocol can be determined to be the UDS protocol to obtain fault codes or diagnostic response data.

[0089] Therefore, by automatically determining the target communication protocol based on the target anomaly conditions, the debugging data acquisition process can adaptively adjust according to the anomaly type, thereby reducing the complexity of manually configuring the communication protocol and lowering the coupling degree of the test code. Furthermore, this approach enhances adaptability to multi-communication protocol scenarios and improves the scalability and versatility of the overall debugging process.

[0090] See Figure 2 , Figure 2 A debugging data acquisition device provided in this application embodiment is applied to a client, which is used to test an electronic control unit. The device 200 includes: The acquisition unit 201 is used to acquire a test run entity for the target electronic control unit. The test run entity includes multiple test process components for executing test processes and a data acquisition component for executing debug data acquisition processes. The multiple test process components correspond to different test stages. The test run entity runs on the client. Test unit 202 is used to test the target electronic control unit based on the test processes corresponding to the multiple test process components included in the test operation entity, and to obtain the test results of the test phase corresponding to the test process component during the execution of the test process. The acquisition unit 201 is further configured to, when executing the j-th test stage through the i-th test process component, if the test result of the j-th test stage meets the target abnormality condition, acquire debugging data for the target electronic control unit based on the debugging data acquisition process corresponding to the data acquisition component. The debugging data is data used to locate the abnormality of the target electronic control unit, where i is a positive integer and j is a positive integer.

[0091] Optionally, the debugging data acquisition process is used to execute multiple data acquisition processes, and the acquisition unit 201 is specifically used for: The multiple data acquisition processes are executed sequentially to obtain debugging data for the target electronic control unit.

[0092] Optionally, the acquisition unit 201 is specifically used for: During the execution of any of the data acquisition processes, the test processes corresponding to each of the test process components are paused to obtain debugging data for the target electronic control unit.

[0093] Optionally, before executing the multiple data acquisition processes corresponding to the data acquisition component, the device 200 further includes a configuration unit for: Obtain the configuration file for the data acquisition component; According to the configuration file, the types of the multiple data acquisition processes, the execution order of the multiple data acquisition processes, the communication protocols corresponding to the multiple data acquisition processes, the data source locations corresponding to the multiple data acquisition processes, and the parameter information corresponding to the multiple data acquisition processes are determined; wherein, the parameter information is used to describe the method by which the data acquisition process acquires the debug data.

[0094] Optionally, after acquiring debugging data for the target electronic control unit, the device 200 further includes a structured information determination unit, used for: Based on the target anomaly condition, obtain the associated data corresponding to the debugging data, wherein the associated data corresponding to the debugging data is the data that affects the test result of the j-th test stage to satisfy the target anomaly condition; Based on the debugging data of the target electronic control unit and the associated data, structured information for the debugging data is generated. The structured information is used to associate the debugging data and the associated data corresponding to the debugging data during the debugging process, so as to locate the abnormal cause of the test result of the j-th test stage satisfying the target abnormal condition.

[0095] Optionally, the acquisition unit 201 is specifically used for: If the test data of the j-th test stage includes the debugging data, then based on the debugging data acquisition process corresponding to the data acquisition component, the debugging data for the target electronic control unit is obtained from the test data of the j-th test stage, wherein the test data of the j-th test stage is the data generated by executing the j-th test stage. If the test data of the j-th test phase does not include the debugging data, then based on the debugging data acquisition process corresponding to the data acquisition component, the debugging data for the target electronic control unit is acquired from the target electronic control unit.

[0096] Optionally, the acquisition unit 201 is specifically used for: Based on the target anomaly conditions, determine the target communication protocol used to acquire the debugging data; Based on the debugging data acquisition process corresponding to the data acquisition component, debugging data for the target electronic control unit is acquired through the target communication protocol.

[0097] See Figure 3 This application also provides a computer device, which includes a memory 301 and a processor 302. The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is used to execute the method of the above method embodiment according to the computer program.

[0098] This application also provides a computer-readable storage medium for storing a computer program for executing the methods described in the above-described method embodiments.

[0099] This application also provides a computer program product including a computer program, which, when run on a computer device, causes the computer device to perform the method described in the above method embodiments.

[0100] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems or apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant parts can be referred to the method section.

[0101] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0102] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0103] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0104] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0105] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for acquiring debugging data, characterized in that, Applied to a client-side application for testing electronic control units, the method includes: A test run entity for the target electronic control unit is obtained. The test run entity includes multiple test process components for executing test processes and a data acquisition component for executing debug data acquisition processes. The multiple test process components correspond to different test stages. The test run entity runs on the client. Based on the test processes corresponding to the multiple test process components included in the test operation entity, the target electronic control unit is tested, and during the execution of the test process, the test results of the test phase corresponding to the test process component are obtained. When executing the j-th test phase through the i-th test process component, if the test result of the j-th test phase meets the target anomaly condition, then based on the debugging data acquisition process corresponding to the data acquisition component, debugging data for the target electronic control unit is acquired. The debugging data is data used to locate the anomaly of the target electronic control unit, where i is a positive integer and j is a positive integer.

2. The method according to claim 1, characterized in that, The debug data acquisition process is used to execute multiple data acquisition processes. The step of acquiring debug data for the target electronic control unit based on the debug data acquisition process corresponding to the data acquisition component includes: The multiple data acquisition processes are executed sequentially to obtain debugging data for the target electronic control unit.

3. The method according to claim 2, characterized in that, The serial execution of multiple data acquisition processes corresponding to the data acquisition component to obtain debugging data for the target electronic control unit includes: During the execution of any of the data acquisition processes, the test processes corresponding to each of the test process components are paused to obtain debugging data for the target electronic control unit.

4. The method according to claim 2, characterized in that, Before executing the multiple data acquisition processes corresponding to the data acquisition component, the method further includes: Obtain the configuration file for the data acquisition component; According to the configuration file, the types of the multiple data acquisition processes, the execution order of the multiple data acquisition processes, the communication protocols corresponding to the multiple data acquisition processes, the data source locations corresponding to the multiple data acquisition processes, and the parameter information corresponding to the multiple data acquisition processes are determined; wherein, the parameter information is used to describe the method by which the data acquisition process acquires the debug data.

5. The method according to claim 1, characterized in that, After acquiring debugging data for the target electronic control unit, the method further includes: Based on the target anomaly condition, obtain the associated data corresponding to the debugging data, wherein the associated data corresponding to the debugging data is the data that affects the test result of the j-th test stage to satisfy the target anomaly condition; Based on the debugging data of the target electronic control unit and the associated data, structured information for the debugging data is generated. The structured information is used to associate the debugging data and the associated data corresponding to the debugging data during the debugging process, so as to locate the abnormal cause of the test result of the j-th test stage satisfying the target abnormal condition.

6. The method according to claim 1, characterized in that, The debugging data acquisition process based on the data acquisition component, which acquires debugging data for the target electronic control unit, includes: If the test data of the j-th test stage includes the debugging data, then based on the debugging data acquisition process corresponding to the data acquisition component, the debugging data for the target electronic control unit is obtained from the test data of the j-th test stage, wherein the test data of the j-th test stage is the data generated by executing the j-th test stage. If the test data of the j-th test phase does not include the debugging data, then based on the debugging data acquisition process corresponding to the data acquisition component, the debugging data for the target electronic control unit is acquired from the target electronic control unit.

7. The method according to claim 1, characterized in that, The debugging data acquisition process based on the data acquisition component, which acquires debugging data for the target electronic control unit, includes: Based on the target anomaly conditions, determine the target communication protocol used to acquire the debugging data; Based on the debugging data acquisition process corresponding to the data acquisition component, debugging data for the target electronic control unit is acquired through the target communication protocol.

8. A debugging data acquisition device, characterized in that, Applied to a client-side application for testing electronic control units, the device includes: The acquisition unit is used to acquire a test run entity for the target electronic control unit. The test run entity includes multiple test process components for executing test processes and a data acquisition component for executing debug data acquisition processes. The multiple test process components correspond to different test stages, and the test run entity runs on the client. The testing unit is used to test the target electronic control unit based on the test processes corresponding to the multiple test process components included in the test operation entity, and to obtain the test results of the test phase corresponding to the test process component during the execution of the test process. The acquisition unit is further configured to, when executing the j-th test stage through the i-th test process component, if the test result of the j-th test stage meets the target abnormality condition, acquire debugging data for the target electronic control unit based on the debugging data acquisition process corresponding to the data acquisition component. The debugging data is data used to locate the abnormality of the target electronic control unit, where i is a positive integer and j is a positive integer.

9. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to perform the method according to any one of claims 1-7 according to the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the method according to any one of claims 1-7.

Images