A method and system for testing the pressure of OTA components based on UDS

Abstract

This invention belongs to the field of component stress testing, specifically relating to an OTA component stress testing method and system based on UDS. This invention establishes a communication connection between a host computer and the target ECU and acquires the ECU's basic information, enabling the testing process to adaptively configure itself based on the actual device state. This avoids the inaccuracies caused by relying on manual test case selection in traditional testing. Furthermore, by matching the ECU's basic information with a preset test case library and generating a test task queue, automatic screening and orderly organization of test cases are achieved, thereby improving the automation level and execution consistency of the testing process. This invention controls the host computer to execute flashing tests based on the test task queue, and synchronously collects response data and performs status determination during execution, forming an integrated processing flow for test execution and result judgment, thus improving the real-time performance and accuracy of the testing process.

Description

Technical Field

[0001] This invention belongs to the field of component stress testing, specifically relating to an OTA component stress testing method and system based on UDS. Background Technology

[0002] In existing technologies, with the development of intelligent connected vehicles, the software upgrade of vehicle electronic control units (ECUs) is gradually shifting from traditional offline flashing methods to OTA (Over-The-Air) remote upgrade methods. In actual development and verification processes, to ensure the stability and reliability of the ECU upgrade process, repeated testing of the OTA flashing process is usually required in a bench or single-component environment. Currently, mainstream testing methods are mostly based on the Unified Diagnostic Service (UDS, ISO 14229) protocol, which sends flashing-related commands to the ECU through diagnostic equipment, completing operations such as program download, data transmission, and verification according to a predetermined process.

[0003] However, current OTA single-component testing still primarily relies on manual or semi-automatic methods, where testers manually trigger test cases, monitor the flashing process, and record test results. While this approach may meet the needs of small-scale testing scenarios, it has significant shortcomings in stress testing scenarios requiring long-term, large-scale, repetitive testing. On the one hand, the high degree of human involvement leads to low test execution efficiency, making it difficult to support high-frequency continuous testing requirements. On the other hand, the consistency of operations during the testing process depends on human experience, making it susceptible to human factors and resulting in poor stability and repeatability of test results. Furthermore, existing testing processes typically lack effective data correlation and feedback mechanisms; test results exist only as independent records, making it difficult to adjust subsequent testing strategies based on historical test data, resulting in low utilization of test resources and limited coverage.

[0004] Meanwhile, with the increasing number of ECUs and the increasing complexity of software, the method of executing tests sequentially on a single device is difficult to meet the needs of parallel testing on multiple nodes. Existing technologies lack a unified automated mechanism for test task scheduling, execution control, and result feedback, which makes it impossible to achieve efficient organization and closed-loop management of the testing process, thus restricting the efficiency and depth of OTA stress testing. Summary of the Invention

[0005] The purpose of this invention is to overcome the problems of existing OTA testing methods that rely on manual execution and lack data-driven automated scheduling and closed-loop feedback mechanisms, resulting in low testing efficiency, poor consistency, and difficulty in achieving high-intensity stress testing. This invention provides an OTA component stress testing method and system based on UDS.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: In a first aspect, the present invention provides a stress testing method for OTA components based on UDS, comprising the following steps: Establish a communication connection between the host computer and the target ECU, and obtain basic information about the target ECU; Based on the basic information of the target ECU, select the corresponding test cases from the preset test case library and generate a test task queue; According to the test task queue, the host computer is controlled to perform a flashing test on the target ECU, while the response data of the target ECU is collected, and the test execution status is determined based on the response data. Generate test result data based on the test execution status and store the test result data; Test tasks are cyclically scheduled based on test result data to achieve stress testing.

[0007] A further improvement of this invention lies in the following method for establishing a communication connection between the host computer and the target ECU, and for obtaining the basic information of the target ECU: A physical connection between the host computer and the target ECU is established via the CAN FD interface; Send a diagnostic request message to the target ECU based on the UDS protocol; Receive the response message returned by the target ECU, and parse it to obtain the target ECU identification information and version information, which serve as the basic information of the target ECU; Determine whether the communication link has been successfully established based on the response message.

[0008] A further improvement of this invention lies in the following method for selecting corresponding test cases from a preset test case library and generating a test task queue based on the basic information of the target ECU: Obtain the basic information of the target ECU, compare the basic information of the target ECU with the matching rules in the preset test case library, and obtain the comparison results; Filter the test case set corresponding to the target ECU from the comparison results; Sort all test cases in the test case set according to the preset execution order; A test task queue is generated based on the sorted test cases.

[0009] A further improvement of this invention lies in the following method for controlling the host computer to perform a flashing test on the target ECU according to the test task, while simultaneously collecting the response data of the target ECU, and determining the test execution status based on the response data: Obtain test tasks and execute message sending, message receiving, and status monitoring tasks respectively based on a multi-threading mechanism; Test cases are executed sequentially according to the test task queue; During the testing process, the pre-programming stage, main programming stage, and post-programming stage are executed according to the UDS flashing process. Receive response messages returned by the target ECU in real time; Parse the service identifier and negative response code (NRC) in the response message; The comparison result is obtained by comparing the service identifier and negative response code (NRC) in the response message with the expected result. The test execution status is determined based on the comparison results.

[0010] A further improvement of this invention lies in the following specific method for generating test result data based on the test execution status and storing the test result data: Obtain the test execution status and generate test result records based on the test execution status; Add timestamp information to each test result record; The test results records with added timestamp information and the corresponding message data are uploaded to the backend management platform for storage.

[0011] A further improvement of this invention lies in the following method for implementing stress testing by cyclically scheduling test tasks based on test result data: Obtain test result data, and determine whether to re-execute the test task based on the execution status and exception information in the test result data; When the preset loop conditions are met, the test task is added back to the test task queue and the test task queue is executed repeatedly to achieve continuous stress testing.

[0012] Secondly, the present invention provides an OTA component stress testing system based on UDS, comprising: The connection establishment module is used to establish a communication connection between the host computer and the target ECU, and to obtain basic information about the target ECU. The queue generation module is used to select corresponding test cases from a preset test case library and generate a test task queue based on the basic information of the target ECU. The status determination module is used to control the host computer to perform flashing tests on the target ECU according to the test task queue, while collecting the response data of the target ECU and determining the test execution status based on the response data. The data storage module is used to generate test result data based on the test execution status and to store the test result data. The cyclic scheduling module is used to cyclically schedule test tasks based on test result data in order to achieve stress testing.

[0013] A further improvement of this invention is that the function of the connection establishment module is implemented through the following method: A physical connection between the host computer and the target ECU is established via the CAN FD interface; Send a diagnostic request message to the target ECU based on the UDS protocol; Receive the response message returned by the target ECU, and parse it to obtain the target ECU identification information and version information, which serve as the basic information of the target ECU; Determine whether the communication link has been successfully established based on the response message.

[0014] A further improvement of this invention is that the function of the queue generation module is implemented through the following method: Obtain the basic information of the target ECU, compare the basic information of the target ECU with the matching rules in the preset test case library, and obtain the comparison results; Filter the test case set corresponding to the target ECU from the comparison results; Sort all test cases in the test case set according to the preset execution order; A test task queue is generated based on the sorted test cases.

[0015] A further improvement of this invention is that the function of the state determination module is implemented through the following method: Obtain test tasks and execute message sending, message receiving, and status monitoring tasks respectively based on a multi-threading mechanism; Test cases are executed sequentially according to the test task queue; During the testing process, the pre-programming stage, main programming stage, and post-programming stage are executed according to the UDS flashing process. Receive response messages returned by the target ECU in real time; Parse the service identifier and negative response code (NRC) in the response message; The comparison result is obtained by comparing the service identifier and negative response code (NRC) in the response message with the expected result. The test execution status is determined based on the comparison results.

[0016] A further improvement of this invention is that the data storage module's function is implemented through the following method: Obtain the test execution status and generate test result records based on the test execution status; Add timestamp information to each test result record; The test results records with added timestamp information and the corresponding message data are uploaded to the backend management platform for storage.

[0017] A further improvement of this invention is that the function of the cyclic scheduling module is implemented through the following method: Obtain test result data, and determine whether to re-execute the test task based on the execution status and exception information in the test result data; When the preset loop conditions are met, the test task is added back to the test task queue and the test task queue is executed repeatedly to achieve continuous stress testing.

[0018] Thirdly, the present invention provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of an OTA component stress testing method based on UDS.

[0019] Fourthly, the present invention provides a storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of a UDS-based OTA component stress testing method.

[0020] Compared with the prior art, the present invention has the following beneficial effects: This invention establishes a communication connection between a host computer and the target ECU and acquires the ECU's basic information, enabling the testing process to adaptively configure itself based on the actual device state. This avoids the inaccuracies caused by relying on manual test case selection in traditional testing. Furthermore, by matching the ECU's basic information with a pre-set test case library and generating a test task queue, the invention achieves automatic screening and orderly organization of test cases, thereby improving the automation level and execution consistency of the testing process. By controlling the host computer to execute the flashing test according to the test task queue and simultaneously collecting response data and determining the status during execution, this invention integrates test execution and result judgment into a unified processing flow, improving the real-time performance and accuracy of the testing process. By generating test result data from the test execution status and storing it in a structured manner, this invention provides complete data recording and traceability capabilities for the testing process, offering a reliable basis for subsequent problem analysis. Finally, by cyclically scheduling test tasks based on the test result data, this invention enables the testing process to automatically repeat and form a closed-loop feedback mechanism, thereby achieving continuous stress testing of the ECU flashing process. In summary, this invention reduces the degree of human intervention, improves testing efficiency and execution consistency, and significantly enhances test coverage and problem detection capabilities, thereby effectively solving the problems of low testing efficiency, poor consistency, and difficulty in achieving high-intensity stress testing in existing technologies. Attached Figure Description

[0021] Figure 1 This is a flowchart of the present invention; Figure 2 This is a system diagram of the present invention; Figure 3 This is a system diagram of Example 8. Detailed Implementation

[0022] To further understand the content of this invention, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the embodiments are merely illustrative and not limiting of the invention.

[0023] Example 1: See Figure 1 A stress testing method for OTA components based on UDS includes the following steps: S1: Establish a communication connection between the host computer and the target ECU, and obtain basic information about the target ECU.

[0024] S2, based on the basic information of the target ECU, selects the corresponding test cases from the preset test case library and generates a test task queue.

[0025] S3, according to the test task queue, controls the host computer to perform a flashing test on the target ECU, while collecting the response data of the target ECU, and judging the test execution status based on the response data.

[0026] S4 generates test result data based on the test execution status and stores the test result data.

[0027] S5 uses test result data to cyclically schedule test tasks to achieve stress testing.

[0028] This invention establishes a communication connection between a host computer and the target ECU and acquires the ECU's basic information, enabling the testing process to adaptively configure itself based on the actual device status, thus avoiding inaccuracies caused by manual test case selection. Furthermore, by matching the ECU's basic information with a pre-set test case library and generating a test task queue, it achieves automatic screening and orderly organization of test cases, improving the automation level and execution consistency of the testing process. Further, by executing flashing tests according to the test task queue and simultaneously collecting response data and determining status during execution, it integrates test execution and result judgment into a unified processing flow, improving the real-time performance and accuracy of the testing process. Simultaneously, by generating test result data from the test execution status and storing it in a structured manner, the testing process possesses complete data recording and traceability capabilities. Finally, by cyclically scheduling test tasks based on the test result data, it creates a closed-loop feedback mechanism for the testing process and enables automatic repeated execution, thereby allowing for continuous stress testing of the ECU flashing process. Through the above-mentioned technical means, the overall level of human intervention is reduced, the testing efficiency and execution consistency are improved, and the testing coverage and the ability to detect anomalies are significantly enhanced. This effectively solves the problems of low testing efficiency, poor consistency and difficulty in achieving high-intensity stress testing in existing technologies.

[0029] Example 2: See Figure 2 A UDS-based OTA component stress testing system includes: The connection establishment module is used to establish a communication connection between the host computer and the target ECU, and to obtain basic information about the target ECU.

[0030] The queue generation module is used to select corresponding test cases from a preset test case library and generate a test task queue based on the basic information of the target ECU.

[0031] The status determination module is used to control the host computer to perform flashing tests on the target ECU according to the test task queue, while collecting the response data of the target ECU and determining the test execution status based on the response data.

[0032] The data storage module is used to generate test result data based on the test execution status and to store the test result data.

[0033] The cyclic scheduling module is used to cyclically schedule test tasks based on test result data in order to achieve stress testing.

[0034] This invention, by setting up a connection establishment module, a queue generation module, a status determination module, a data storage module, and a loop scheduling module, enables the functional modules to work collaboratively according to data flow. This achieves a complete automated processing flow from communication establishment, task generation, test execution, result determination to loop scheduling. The connection establishment module acquires basic ECU information as input for subsequent processing; the queue generation module generates a test task queue based on this basic information; the status determination module parses the response data and determines the execution status during test task execution; the data storage module records and centrally stores the test results in a structured manner; and the loop scheduling module performs feedback scheduling of test tasks based on the test results, thus forming a closed-loop operation mechanism for the entire system. Through this modular design, the system possesses excellent functional division and collaborative capabilities, improving system stability and scalability. Simultaneously, the data-driven processing method reduces manual intervention, improving the consistency and reliability of test execution, and the loop scheduling mechanism enhances test intensity and coverage, thereby effectively improving the overall performance and application value of the system in OTA flashing stress testing scenarios.

[0035] Example 3: In this embodiment, the process of establishing a communication connection between the host computer and the target ECU is described.

[0036] Specifically, the host computer and the target ECU are physically connected via a CAN FD interface. During the connection process, the host computer establishes a stable physical link with the ECU's CAN_H and CAN_L signal lines through a standard CAN FD transceiver, and provides a stable operating voltage to the ECU through a power module to ensure the reliability of the communication environment. In practice, the CAN FD interface on the host computer side can be implemented using dedicated communication hardware. This hardware works in conjunction with the host computer's software control program to complete the data transmission and reception functions. During the physical connection, the connection sequence and contact reliability of the CAN_H and CAN_L signal lines are confirmed to avoid communication interruptions due to poor contact. At the same time, a regulated power supply maintains a stable output voltage during the power supply process, reducing the impact of voltage fluctuations on the ECU communication process, thereby ensuring that the communication link is in a stable state.

[0037] After the physical connection is established, the host computer initializes communication parameters, including baud rate configuration, frame format settings, and network address allocation. The baud rate is set according to the communication rate supported by the target ECU, the frame format is configured according to the CAN FD protocol specification, and the network address is used to identify the communication node, ensuring effective data exchange between the host computer and the target ECU. During parameter initialization, the host computer uniformly configures all parameters to ensure consistency in data format and transmission rate between the communicating parties, thereby avoiding communication failures or data parsing errors due to parameter mismatches.

[0038] After initializing the communication parameters, the host computer sends a diagnostic request message to the target ECU based on the UDS protocol, requesting to obtain the ECU's basic information. The diagnostic request message may include session control requests and identifier read requests, used to trigger the ECU to return its current software version, hardware identifier, and related parameter information. When sending the diagnostic request message, the host computer encapsulates the request data according to the message format specified by the UDS protocol and sends the message to the target ECU via the CAN FD interface.

[0039] Upon receiving the diagnostic request message, the target ECU returns a corresponding response message according to the UDS protocol specification. The host computer receives and parses the response message, extracting the ECU identification information and version information from the data fields, and using this information as the basic information of the target ECU. During the parsing process, the host computer processes the response message according to preset data parsing rules, extracting the valid data from the message to form structured information that can be used for subsequent processing.

[0040] Simultaneously, the host computer judges the communication link status based on the return status and correctness of the response messages. For example, it determines whether a valid response has been received and whether the response conforms to the protocol specifications to confirm successful communication. Upon successful communication, a communication status identifier is generated. This identifier reflects the current status of the communication link, indicating whether the host computer and the target ECU have normal communication capabilities. Through this method, a complete processing flow is implemented from physical connection establishment, communication parameter initialization, diagnostic request sending, response message reception and parsing to communication status confirmation. This ensures the stability and standardization of the connection establishment process, thereby guaranteeing reliable execution of the communication process.

[0041] Example 4: In this embodiment, the process of test case selection and test task queue generation is described.

[0042] Specifically, after acquiring the basic information of the target ECU, the host computer transmits this basic information as input data to the test case matching module. The test case matching module analyzes and processes the ECU information according to matching rules in a preset test case library. These matching rules can include matching conditions based on ECU model, software version, functional category, or test requirements. By comparing the basic information of the target ECU with each matching rule, corresponding matching results are obtained. A set of test cases that meet the conditions is then selected from the matching results, ensuring that the selected test cases match the actual state of the target ECU. Subsequently, the host computer processes the selected set of test cases, sorting them according to a preset execution order. This sorting can be based on test process dependencies, priority settings, or execution logic order to ensure the rationality and continuity of test execution. After sorting, the system generates a test task queue based on the sorted set of test cases and outputs this test task queue as structured data for subsequent test execution steps. During the generation of the test task queue, the queue can also be formatted, for example, by adding task identifiers, execution parameters, and status flags to each test case for subsequent execution module calls and management. By using the above methods, the generation process of test tasks is driven by the basic information of the ECU, realizing the automatic selection and orderly organization of test cases. This avoids errors caused by manual selection, improves the automation level of the test process, and enhances the controllability and consistency of test execution through queue management, further improving test efficiency and reducing test deviations caused by improper test case selection during system operation.

[0043] Example 5: In this embodiment, the test execution and status determination process is described.

[0044] Specifically, after acquiring the basic information of the target ECU, the host computer transmits this basic information as input data to the test case matching module. The test case matching module analyzes and processes the ECU information according to matching rules in a preset test case library. These matching rules can include matching conditions based on ECU model, software version, functional category, or test requirements. In practice, the test case library can pre-store various test cases and establish corresponding matching rule sets for different types of ECUs. After receiving the basic information of the target ECU, the host computer parses and processes this information, extracting key fields for matching, such as model identifiers, version information, or functional identifiers. The extracted fields are then compared with the matching rules to form a basis for selecting test cases. By comparing the basic information of the target ECU with the matching rules item by item, corresponding matching results are obtained. From these results, a set of test cases that meet the conditions is selected, ensuring that the selected test cases match the actual state of the target ECU.

[0045] After obtaining the test case set, the host computer further processes the filtered test case set, sorting the test cases according to a preset execution order. This sorting method can be based on test process dependencies, priority settings, or execution logic order. During the sorting process, the order of test cases can be adjusted according to established rules to ensure that the execution order of test cases conforms to preset logic. For example, basic function-related tests are executed first, followed by flashing-related tests, thereby ensuring the continuity and orderly execution of the test process. During the sorting process, the host computer can also traverse the test case set, determining the position of each test case one by one according to preset rules, thus forming a test case sequence with a clear execution order.

[0046] After sorting, the system generates a test task queue based on the sorted test case set and outputs this queue as structured data for subsequent test execution steps. During the queue generation process, the host computer can encapsulate the test cases, converting each test case into a task unit and adding them to the queue sequentially according to the sorting result, thus forming a complete test task queue structure. Simultaneously, the queue can be formatted during generation, such as by adding task identifiers, execution parameters, and status flags to each test case, making each task unit identifiable and manageable, facilitating subsequent calling and control by the execution module. Furthermore, the test task queue can be stored as a list or array, allowing it to be read sequentially during execution.

[0047] By using the above methods, the generation process of test tasks is driven by the basic information of the ECU, realizing the automatic selection and orderly organization of test cases. This avoids errors caused by manual selection, improves the automation level of the test process, and enhances the controllability and consistency of test execution through queue management, further improving test efficiency and reducing test deviations caused by improper test case selection during system operation.

[0048] Example 6: In this embodiment, the process of generating and storing test results is described.

[0049] Specifically, after determining the test execution status, the host computer transmits the test execution status as input data to the result generation module. The result generation module generates corresponding test result records based on the test execution status. These test result records may include test case identifiers, execution status, exception information, and related parameter data. In practice, the result generation module can parse and process the test execution status, classify and organize the execution results corresponding to different test cases, and associate the test execution status with the corresponding test cases to generate structured test result records. Each record clearly corresponds to a specific test case and its execution status. During the generation of test result records, related parameter data can also be integrated, such as by aggregating status information during execution, making the test result records more complete and clear.

[0050] After generating test result records, the system adds a timestamp to each record to document the specific time the test was executed, thus providing a time dimension identifier for the testing process. In practice, the timestamp can be generated by the host computer system and appended to the test result record in a standardized format, ensuring the test results reflect their chronological order and facilitating subsequent time analysis and sorting of the test process. Adding timestamps gives each test result record a time attribute, ensuring the test data includes not only result information but also time information, thereby enhancing data integrity.

[0051] After adding the timestamp, the host computer associates the test result records with the corresponding response message data, ensuring that each test result can be traced back to the original communication data. In practice, the host computer can establish associations to store test result records and corresponding response message data generated during execution, creating a one-to-one correspondence between test results and original data, thus forming structured test log data. This association process ensures that the test log contains not only result information but also the original communication data, providing a complete data foundation for subsequent analysis.

[0052] Subsequently, the host computer uploads the test log data to the backend management platform via a network interface for centralized storage. The backend management platform provides unified management and archiving of the test logs. In the specific implementation, the host computer can send test log data to the backend management platform via network communication. Upon receiving the test log data, the backend management platform processes it, categorizes it according to certain rules, and supports subsequent data queries, statistical analysis, and problem localization. During storage, the data can also be formatted or compressed; for example, the test logs can be organized according to a unified data format or compressed to improve storage efficiency and reduce system resource consumption.

[0053] The above methods enable the standardized generation and centralized storage of test result data, giving the testing process complete data recording and traceability capabilities. At the same time, they provide reliable data support for subsequent test optimization and problem analysis, thereby improving the overall data management capabilities and application value of the testing system.

[0054] Example 7: In this embodiment, the process of cyclically executing the test task is described.

[0055] Specifically, after acquiring the test result data, the host computer transmits the test result data as input to the scheduling and analysis module. The scheduling and analysis module parses and analyzes the execution status and abnormal information in the test result data, and determines whether the current test task needs to be re-executed based on the analysis results. For example, when a test failure or abnormal situation is detected, it can be determined that the corresponding test task needs to be re-executed. In the specific implementation process, the scheduling and analysis module can perform structured parsing of the test result data, classify the execution status corresponding to different test cases, and identify abnormal information. By identifying and organizing the abnormal information, the system can clearly identify which test tasks have problems, thereby providing a basis for subsequent scheduling decisions. During the parsing process, the test result data can also be processed item by item, so that the execution status of each test task is included in the analysis scope, thereby improving the comprehensiveness and accuracy of the judgment.

[0056] After determining whether to re-execute the test task, the system schedules and controls the test task according to preset loop conditions. These loop conditions may include execution count thresholds, time periods, or exception triggering conditions. In practice, the system can pre-set control rules for loop execution, such as setting a maximum number of executions for the test task or a time range for loop execution. When the corresponding conditions are met, the test task is rescheduled. During scheduling, the host computer determines whether to re-add the current test task to the queue based on the loop conditions, thereby controlling the number of executions or the execution period of the test task.

[0057] When the loop condition is met, the host computer adds the test task back to the test task queue and updates the task status information for re-execution. In practice, the host computer can insert test tasks that need to be re-executed into the test task queue according to predetermined rules and mark the task status, such as "pending execution" or "repeated execution," so that the task can be identified and invoked in subsequent executions. Simultaneously, when tasks are added back to the queue, the original execution order can be maintained or reordered as needed to ensure the continuity of the testing process.

[0058] Subsequently, the system invokes the test task queue execution process again, repeatedly executing the updated test task queue to achieve continuous stress testing of the target ECU flashing process. During execution, the system executes test tasks one by one according to the task queue order, and obtains the corresponding test result data after each execution, providing input for the next round of scheduling. During the loop execution, the system continuously records test results and updates test data, forming a closed-loop structure in the testing process. Through multiple loop executions, test results are continuously accumulated, thereby improving the ability to detect anomalies.

[0059] By employing the above methods, the testing process can achieve feedback scheduling and automatic cyclic execution based on historical test results. This not only improves the test coverage and intensity but also reduces the need for manual intervention and enhances the system's ability to detect potential problems in complex testing environments, thereby improving overall testing efficiency and depth.

[0060] Example 8: Please see Figure 3 As shown, the present invention also provides an electronic device 100 for an OTA component stress testing method based on UDS; the electronic device 100 includes a memory 101, at least one processor 102, a computer program 103 stored in the memory 101 and executable on the at least one processor 102, and at least one communication bus 104.

[0061] The memory 101 can be used to store the computer program 103. The processor 102 implements the steps of the UDS-based OTA component stress testing method described in Embodiment 1 by running or executing the computer program stored in the memory 101 and calling the data stored in the memory 101. The memory 101 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device 100 (such as audio data), etc. In addition, the memory 101 may include non-volatile memory, such as hard disk, memory, plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, at least one disk storage device, flash memory device, or other non-volatile solid-state storage device.

[0062] The at least one processor 102 may be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor 102 may be a microprocessor or any conventional processor. The processor 102 is the control center of the electronic device 100, connecting various parts of the electronic device 100 via various interfaces and lines.

[0063] The memory 101 in the electronic device 100 stores multiple instructions to implement an OTA component stress testing method based on UDS, and the processor 102 can execute the multiple instructions to achieve the following: Establish a communication connection between the host computer and the target ECU, and obtain basic information about the target ECU; Based on the basic information of the target ECU, select the corresponding test cases from the preset test case library and generate a test task queue; According to the test task queue, the host computer is controlled to perform a flashing test on the target ECU, while the response data of the target ECU is collected, and the test execution status is determined based on the response data. Generate test result data based on the test execution status and store the test result data; Test tasks are cyclically scheduled based on test result data to achieve stress testing.

[0064] Example 9: If the modules / units integrated in the electronic device 100 are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, and a read-only memory (ROM).

[0065] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0066] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0067] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0068] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0069] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for stress testing of OTA components based on UDS, characterized in that, Includes the following steps: Establish a communication connection between the host computer and the target ECU, and obtain basic information about the target ECU; Based on the basic information of the target ECU, select the corresponding test cases from the preset test case library and generate a test task queue; According to the test task queue, the host computer is controlled to perform a flashing test on the target ECU, while the response data of the target ECU is collected, and the test execution status is determined based on the response data. Generate test result data based on the test execution status and store the test result data; Test tasks are cyclically scheduled based on test result data to achieve stress testing.

2. The OTA component stress testing method based on UDS according to claim 1, characterized in that, The specific method for establishing a communication connection between the host computer and the target ECU and obtaining the basic information of the target ECU is as follows: A physical connection between the host computer and the target ECU is established via the CAN FD interface; Send a diagnostic request message to the target ECU based on the UDS protocol; Receive the response message returned by the target ECU, and parse it to obtain the target ECU identification information and version information, which serve as the basic information of the target ECU; Determine whether the communication link has been successfully established based on the response message.

3. The method for stress testing OTA components based on UDS according to claim 1, characterized in that, The specific method for selecting corresponding test cases from the preset test case library and generating a test task queue based on the basic information of the target ECU is as follows: Obtain the basic information of the target ECU, compare the basic information of the target ECU with the matching rules in the preset test case library, and obtain the comparison results; Filter the test case set corresponding to the target ECU from the comparison results; Sort all test cases in the test case set according to the preset execution order; A test task queue is generated based on the sorted test cases.

4. The OTA component stress testing method based on UDS according to claim 1, characterized in that, According to the test task, the host computer is controlled to perform a flashing test on the target ECU, while simultaneously collecting the response data of the target ECU. The specific method for determining the test execution status based on the response data is as follows: Obtain test tasks and execute message sending, message receiving, and status monitoring tasks respectively based on a multi-threading mechanism; Test cases are executed sequentially according to the test task queue; During the testing process, the pre-programming stage, main programming stage, and post-programming stage are executed according to the UDS flashing process. Receive response messages returned by the target ECU in real time; Parse the service identifier and negative response code (NRC) in the response message; The comparison result is obtained by comparing the service identifier and negative response code (NRC) in the response message with the expected result. The test execution status is determined based on the comparison results.

5. The OTA component stress testing method based on UDS according to claim 1, characterized in that, The specific method for generating and storing test result data based on the test execution status is as follows: Obtain the test execution status and generate test result records based on the test execution status; Add timestamp information to each test result record; The test results records with added timestamp information and the corresponding message data are uploaded to the backend management platform for storage.

6. The method for stress testing OTA components based on UDS according to claim 1, characterized in that, The specific method for implementing stress testing by cyclically scheduling test tasks based on test result data is as follows: Obtain test result data, and determine whether to re-execute the test task based on the execution status and exception information in the test result data; When the preset loop conditions are met, the test task is added back to the test task queue and the test task queue is executed repeatedly to achieve continuous stress testing.

7. A UDS-based OTA component stress testing system, characterized in that, include: The connection establishment module is used to establish a communication connection between the host computer and the target ECU, and to obtain basic information about the target ECU. The queue generation module is used to select corresponding test cases from a preset test case library and generate a test task queue based on the basic information of the target ECU. The status determination module is used to control the host computer to perform flashing tests on the target ECU according to the test task queue, while collecting the response data of the target ECU and determining the test execution status based on the response data. The data storage module is used to generate test result data based on the test execution status and to store the test result data. The cyclic scheduling module is used to cyclically schedule test tasks based on test result data to achieve stress testing; The functionality of the connection establishment module is implemented through the following methods: A physical connection between the host computer and the target ECU is established via the CAN FD interface; Send a diagnostic request message to the target ECU based on the UDS protocol; Receive the response message returned by the target ECU, and parse it to obtain the target ECU identification information and version information, which serve as the basic information of the target ECU; Determine whether the communication link has been successfully established based on the response message.

8. The OTA component stress testing system based on UDS according to claim 7, characterized in that, The functionality of the queue generation module is implemented through the following methods: Obtain the basic information of the target ECU, compare the basic information of the target ECU with the matching rules in the preset test case library, and obtain the comparison results; Filter the test case set corresponding to the target ECU from the comparison results; Sort all test cases in the test case set according to the preset execution order; Generate a test task queue based on the sorted test cases; The functionality of the status determination module is implemented through the following methods: Obtain test tasks and execute message sending, message receiving, and status monitoring tasks respectively based on a multi-threading mechanism; Test cases are executed sequentially according to the test task queue; During the testing process, the pre-programming stage, main programming stage, and post-programming stage are executed according to the UDS flashing process. Receive response messages returned by the target ECU in real time; Parse the service identifier and negative response code (NRC) in the response message; The comparison result is obtained by comparing the service identifier and negative response code (NRC) in the response message with the expected result. The test execution status is determined based on the comparison results; The data storage module's functionality is implemented through the following methods: Obtain the test execution status and generate test result records based on the test execution status; Add timestamp information to each test result record; The test results records with added timestamp information and the corresponding message data are uploaded to the backend management platform for storage; The functionality of the round-robin scheduling module is implemented through the following methods: Obtain test result data, and determine whether to re-execute the test task based on the execution status and exception information in the test result data; When the preset loop conditions are met, the test task is added back to the test task queue and the test task queue is executed repeatedly to achieve continuous stress testing.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the UDS-based OTA component stress testing method according to any one of claims 1 to 6.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the OTA component stress testing method based on UDS as described in any one of claims 1 to 6.

Images