A vehicle-mounted software testing device and testing method

Abstract

This invention discloses an in-vehicle software testing device and method, belonging to the field of automotive electronics technology. The device includes a test terminal, an in-vehicle TBOX module, a diagnostic protocol adaptation unit, and a data acquisition unit. The test terminal is connected to the in-vehicle TBOX module; the diagnostic protocol adaptation unit is connected to both the test terminal and the ECU under test; and the data acquisition unit is connected to both the in-vehicle TBOX module and the ECU under test. The method includes: S1 The test terminal establishes a communication connection with the ECU under test through the diagnostic protocol adaptation unit; S2 The test terminal sends an upgrade command to the in-vehicle TBOX and simultaneously starts data acquisition; S3 The data acquisition unit transmits the acquired data to the test terminal; S4 The test terminal processes the data to generate test results. This invention solves the problems of poor compatibility, incomplete data acquisition, and low fault diagnosis efficiency of existing testing devices.

Description

Technical Field

[0001] This invention relates to the field of automotive electronics technology, and specifically to an in-vehicle software testing device and method for OTA upgrade testing, diagnostic protocol compatibility testing, and network management performance testing of in-vehicle systems. Background Technology

[0002] In the field of automotive software testing, with the continuous improvement of vehicle intelligence and connectivity, OTA (Over-The-Air) updates have become a standard feature of intelligent connected vehicles. Correspondingly, this places higher demands on the testing methods and equipment for automotive software. Regarding compatibility issues related to diagnostic services, existing technologies have already conducted relevant research.

[0003] Publication No. (CN120547090A) discloses a diagnostic service processing method, device and electronic device based on gateway technology. The solution proposes a diagnostic protocol conversion scheme through an in-vehicle gateway. By determining whether the protocol used by the diagnostic service is consistent with the unified in-vehicle diagnostic protocol, the protocol is converted when they are inconsistent, thereby solving the compatibility problem between different protocols.

[0004] However, this solution primarily focuses on the protocol conversion layer of diagnostic services, and does not yet address aspects such as the comprehensiveness of data collection during OTA upgrade testing, flexible management of test cases, and automated report generation after test completion. Specifically, the existing technology cannot simultaneously acquire upgrade progress, performance parameters, and fault codes during the OTA upgrade process, making it difficult to accurately locate upgrade faults; test case management is fragmented, unable to be imported, exported, or edited in batches, resulting in insufficient flexibility for adapting to testing in-vehicle software for different vehicle models; and it cannot automatically generate test reports and fault diagnosis logs after test completion, increasing the workload of testers and easily leading to data omissions and misjudgments. Summary of the Invention

[0005] This invention aims to solve the problems of poor compatibility, incomplete data acquisition, inconvenient test case management, and low fault diagnosis efficiency of existing vehicle software testing devices. It provides a vehicle software testing device and method that is compatible with multiple diagnostic protocols, has accurate data acquisition, high testing efficiency, and can automatically generate test reports.

[0006] To achieve the above objectives, the present invention adopts the following technical solution: An in-vehicle software testing device includes: a test terminal 1, an in-vehicle TBOX module 2, a diagnostic protocol adaptation unit 3, and a data acquisition unit 4; the test terminal 1 has a first communication interface and a second communication interface, the in-vehicle TBOX module 2 has a third communication interface and a fourth communication interface; the diagnostic protocol adaptation unit 3 has a fifth communication interface and a sixth communication interface, and the data acquisition unit 4 has a seventh communication interface and an eighth communication interface; the first communication interface of the test terminal 1 is connected to the third communication interface of the in-vehicle TBOX module 2; the second communication interface of the test terminal 1 is connected to the fifth communication interface of the diagnostic protocol adaptation unit 3 and the eighth communication interface of the data acquisition unit 4; the sixth communication interface of the diagnostic protocol adaptation unit 3 and the seventh communication interface of the data acquisition unit 4 are connected to the CAN interface of the in-vehicle ECU under test; the fourth communication interface of the in-vehicle TBOX module 2 is also connected to the CAN interface of the in-vehicle ECU under test.

[0007] Furthermore, test terminal 1 sends OTA upgrade instructions and preset test cases to vehicle TBOX module 2 through the first communication interface; vehicle TBOX module 2 receives OTA upgrade instructions through the third communication interface and uses them to transmit to the vehicle ECU under test; diagnostic protocol adaptation unit 3 receives test instructions sent by test terminal 1 through the fifth communication interface, performs protocol conversion on the test instructions, and outputs them to vehicle ECU under test through the sixth communication interface; data acquisition unit 4 collects data packets, fault codes, and performance parameters of vehicle ECU under test and vehicle TBOX module 2 during the OTA upgrade process through the seventh communication interface, and transmits the collected data to test terminal 1 through the eighth communication interface.

[0008] Furthermore, the core control chip of the diagnostic protocol adaptation unit 3 is an STM32 chip, which has built-in UDS, CAN and CANFD bus protocol conversion programs.

[0009] Furthermore, the diagnostic protocol adapter unit 3 adapts to protocols including UDS protocol, CAN bus protocol and CAN FD bus protocol, with a protocol conversion response time ≤1ms.

[0010] Furthermore, the acquisition frequency of the data acquisition unit 4 is adjustable, ranging from 10 to 50 Hz, and the acquired performance parameters include CPU utilization, memory usage, upgrade success rate, and number of fault code triggers.

[0011] Furthermore, the test terminal 1 has the following built-in modules: a test case management module, a report generation module, and an alarm module. The test case management module can store and edit OTA upgrade test and network management test cases, and supports batch import and export of test cases. The report generation module verifies and analyzes the received test data and automatically generates test reports. The alarm module issues an alarm signal when the communication handshake fails.

[0012] The present invention also provides a testing method for an in-vehicle software testing device, comprising the following steps: Step S1: Test terminal 1 establishes a communication connection with the vehicle ECU under test through diagnostic protocol adapter unit 3; Step S2: Test terminal 1 sends an OTA upgrade command to vehicle TBOX module 2 through its communication interface, and at the same time controls data acquisition unit 4 to start data acquisition; Step S3: The data acquisition unit 4 transmits the acquired data to the test terminal 1; Step S4: Test terminal 1 processes the received data and generates test results.

[0013] Furthermore, in step S1, the test terminal 1 sends a communication handshake request to the vehicle ECU under test through the diagnostic protocol adaptation unit 3. The handshake duration is ≤3s. If the handshake fails, the test terminal 1 issues an alarm signal.

[0014] Further, in step S4, the test terminal 1 compares the collected data with preset test standards, which include: upgrade success rate ≥99%, communication latency ≤10ms, and fault code triggering times ≤1.

[0015] Furthermore, if the test results do not meet the preset standards, the test terminal 1 sends a fault diagnosis command to the vehicle ECU under test through the diagnostic protocol adaptation unit 3 to locate the fault node and record the troubleshooting log; the fault node includes protocol adaptation fault, vehicle ECU fault, and OTA data packet loss fault; the troubleshooting log includes fault type, fault occurrence time, fault diagnosis steps and solutions.

[0016] Compared with traditional solutions, the present invention has the following advantages: (1) The diagnostic protocol adapter unit selected in this invention can simultaneously adapt to UDS, CAN bus and CAN FD bus diagnostic protocols without changing the test equipment, adapt to the test requirements of different vehicle models and different types of vehicle ECUs, and greatly improve test efficiency.

[0017] (2) The present invention adopts a multi-channel data acquisition method to simultaneously acquire data packets, fault codes and performance parameters during the OTA upgrade process. The acquisition frequency is adjustable to avoid data omission and misjudgment and accurately support the analysis of test results.

[0018] (3) The test terminal has a built-in test case management module that supports batch import, export and editing of test cases, and can flexibly adapt to the test requirements of different scenarios such as OTA upgrade of vehicle system and network management.

[0019] (4) The present invention can automatically complete the issuance of test instructions, data collection, data verification, test report generation and fault diagnosis, greatly reducing manual intervention, reducing the workload of testers, and improving test accuracy and efficiency.

[0020] (5) This invention is applicable to the testing of on-board software, OTA upgrades, diagnostic protocol compatibility and network management performance of new energy vehicles. It is highly practical and can be widely used in the field of automotive software testing. Attached Figure Description

[0021] This manual includes the following figures, which illustrate the following: Figure 1 This is a structural block diagram of the vehicle-mounted software testing device of the present invention; Figure 2 This is an overall flowchart of the vehicle-mounted software testing method of the present invention; The components include: 1. Test terminal; 2. Vehicle-mounted TBOX module; 3. Diagnostic protocol adaptation unit; and 4. Data acquisition unit. Detailed Implementation

[0022] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, in order to help those skilled in the art to have a more complete, accurate and in-depth understanding of the inventive concept and technical solution of the present invention, and to facilitate its implementation.

[0023] like Figure 1 As shown, this invention provides an in-vehicle software testing device, comprising a test terminal 1, an in-vehicle T-BOX module 2, a diagnostic protocol adaptation unit 3, a data acquisition unit 4, and an in-vehicle ECU under test (ECU) as the object of test. The ECU under test is an electronic control unit actually installed in a vehicle, such as a gateway, engine control module, body control module, or battery management system, and has at least one CAN bus communication interface or Ethernet communication interface. During testing, it is connected to the testing device of this invention as the object of test. Test terminal 1 has a first communication interface and a second communication interface; vehicle-mounted TBOX module 2 has a third communication interface and a fourth communication interface; diagnostic protocol adaptation unit 3 has a fifth communication interface and a sixth communication interface; data acquisition unit 4 has a seventh communication interface and an eighth communication interface; the first communication interface of test terminal 1 is connected to the third communication interface of vehicle-mounted TBOX module 2; the second communication interface of test terminal 1 is connected to the fifth communication interface of diagnostic protocol adaptation unit 3 and the eighth communication interface of data acquisition unit 4 respectively; the sixth communication interface of diagnostic protocol adaptation unit 3 and the seventh communication interface of data acquisition unit 4 are connected to the CAN interface of the vehicle ECU under test; the fourth communication interface of vehicle-mounted TBOX module 2 is also connected to the CAN interface of the vehicle ECU under test.

[0024] Test terminal 1 sends OTA upgrade commands and preset test cases to vehicle TBOX module 2 through the first communication interface; vehicle TBOX module 2 receives OTA upgrade commands through the third communication interface and uses them to transmit to the vehicle ECU under test; diagnostic protocol adaptation unit 3 receives test commands sent by test terminal 1 through the fifth communication interface, performs protocol conversion on the test commands, and outputs them to the vehicle ECU under test through the sixth communication interface; data acquisition unit 4 collects data packets, fault codes, and performance parameters of vehicle ECU under test and vehicle TBOX module 2 during the OTA upgrade process through the seventh communication interface, and transmits the collected data to test terminal 1 through the eighth communication interface.

[0025] Test terminal 1 uses an industrial-grade tablet PC with the following hardware configuration: processor clock speed of no less than 2.0GHz, memory capacity ≥8GB, solid-state storage capacity ≥128GB, running Windows 10 operating system or Linux embedded system. The touch screen of test terminal 1 supports multi-touch, facilitating operation by testers through a graphical interface.

[0026] Test terminal 1 integrates three functional modules: a test case management module, a report generation module, and an alarm module. These modules are stored in memory as software programs and executed by the processor. The test case management module provides a graphical user interface, supporting testers in creating, editing, and deleting OTA upgrade test cases and network management test cases. Test cases are formatted as structured text files such as XML or JSON, with each test case containing a test name, test objective, expected result, and test parameters. This module supports batch import, allowing the import of a compressed package containing hundreds of test cases from an external USB storage device at once; it also supports batch export, exporting test results along with test cases to Excel or PDF format for easy archiving and traceability. The report generation module communicates with data acquisition unit 4, receiving real-time acquired data. The report generation module has multiple preset verification algorithms, such as statistical calculations of upgrade success rates, average calculations of communication latency, and statistical counting of fault code occurrences. After testing, this module compares the raw data with preset standards and automatically generates a test report that conforms to industry standards. The report includes the test time, test personnel, information on the vehicle under test, test conclusions, detailed data tables, and a link to the fault log. When a communication handshake fails or a serious error occurs during the test, the alarm module is triggered, emitting a buzzer sound through the speaker and flashing a red LED indicator on the casing of test terminal 1 to alert the test personnel.

[0027] The vehicle-mounted T-BOX module 2 adopts an automotive-grade telematics terminal, which integrates a 4G / 5G communication module and an Ethernet physical layer chip. The vehicle-mounted T-BOX module 2 connects to test terminal 1, and communication between the two uses a TCP or IP protocol stack with a communication latency of 5ms. Another interface connects to the CAN interface of the ECU under test. The vehicle-mounted T-BOX module 2 receives OTA upgrade commands from test terminal 1, which include the download address or local path of the upgrade package. The vehicle-mounted T-BOX module 2 downloads the upgrade package from a remote server via its 4G / 5G module or obtains the upgrade package directly from the local area network. Subsequently, the vehicle-mounted T-BOX module 2 sends the upgrade data in packets to the ECU under test via the CAN bus, and provides real-time updates on the upgrade progress to test terminal 1 during the upgrade process.

[0028] The core control chip of the diagnostic protocol adaptation unit 3 uses an STM32 series microcontroller, which has three independent CAN transceivers corresponding to the UDS protocol, CAN bus protocol, and CAN FD bus protocol, respectively. It connects to the vehicle ECU under test (ECU) via a sixth communication interface. When test terminal 1 issues a test command, the command first enters the STM32 chip. The STM32 chip first sends a protocol probe frame to the ECU under test via the CAN transceiver. This probe frame contains a composite format of standard UDS request, standard CAN request, and standard CAN FD request. Based on the response of the ECU under test, the STM32 chip automatically identifies the actual protocol type used. If the ECU correctly responds to the CAN FD format frame, it is determined to be using the CAN FD protocol. After identification, the STM32 chip converts all subsequent test commands into the corresponding protocol format in real time and sends them out through the corresponding CAN transceiver. The entire protocol identification and conversion process takes ≤1ms, ensuring the real-time performance and stability of the test commands.

[0029] Data acquisition unit 4 employs a multi-channel synchronous data acquisition card. This unit features multiple isolated CAN interfaces, enabling simultaneous connection to multiple vehicle ECUs under test. Data acquisition unit 4 also has a USB or Ethernet interface for connection to test terminal 1. The acquisition frequency of data acquisition unit 4 can be adjusted via software within the range of 10Hz to 50Hz, with a default setting of 30Hz. The types of data it acquires include: CPU utilization, memory usage, upgrade success rate, and fault code trigger count. CPU utilization and memory usage are obtained by reading the custom diagnostic address inside the vehicle ECU under test; the upgrade success rate is calculated by comparing the number of data packets successfully written to the flash memory of the vehicle ECU under test with the total number of data packets sent; the fault code trigger count is determined by monitoring the Diagnostic Trouble Code (DTC) messages on the CAN bus and counting the number of times each fault code occurs.

[0030] like Figure 2The diagram shown is an overall flowchart of the vehicle-mounted software testing method of the present invention. The specific steps are as follows: In this embodiment, the vehicle ECU under test is a smart gateway that supports the CAN FD protocol. The preset test standards are: upgrade success rate ≥99%, communication latency ≤10ms, and fault code triggering frequency ≤1 time.

[0031] Step S1: Before the test begins, the tester connects all hardware and powers on the test terminal 1, the vehicle-mounted T-BOX module 2, and the vehicle ECU under test. The tester starts the test software through the touchscreen of the test terminal 1 and loads the preset OTA upgrade test cases from the test case management module, including the following sub-test items: upgrade package integrity verification, erase sector time test, write speed test, and fault injection test. After loading, the test terminal 1 sends a handshake request command to the diagnostic protocol adaptation unit 3 through the first communication interface. The STM32 chip of the diagnostic protocol adaptation unit 3 immediately sends a protocol probe frame to the vehicle ECU under test through its sixth communication interface. The vehicle ECU under test responds with a positive CAN FD format response. Based on this, the STM32 chip determines that the protocol type is CAN FD and records the configuration. After the handshake request is sent, the test terminal 1 presets the handshake duration to 2 seconds. Within 2 seconds, the diagnostic protocol adaptation unit 3 forwards the serial number, software version number, and other information of the vehicle ECU under test to the test terminal 1. After receiving a correct response, test terminal 1 determines that the handshake was successful and proceeds to step S2. If no correct response is received within 2 seconds, the alarm module of test terminal 1 is triggered, emitting an audible and visual alarm and displaying "Communication handshake failed" on the screen, prompting the tester to check the communication connection and protocol compatibility.

[0032] Step S2: After a successful handshake, test terminal 1 sends an OTA upgrade command to the vehicle-mounted T-BOX module 2 via the first communication interface. This command contains the network address of the upgrade package, which is approximately 100MB in size. Simultaneously, test terminal 1 sends a data acquisition command to data acquisition unit 4 via the second communication interface, setting the acquisition frequency to 30Hz. Upon receiving the command, vehicle-mounted T-BOX module 2 immediately downloads the upgrade package via Ethernet and begins transmitting upgrade data to the vehicle-mounted ECU under test via the fourth communication interface. At the same time, data acquisition unit 4 connects to the vehicle-mounted ECU under test via the seventh communication interface, collecting its CPU utilization and memory usage in real time, and monitoring fault code messages on the CAN bus; the eighth communication interface monitors the communication between vehicle-mounted T-BOX module 2 and the ECU, recording the sending and receiving times of each data frame for calculating communication latency. The acquired data is transmitted to test terminal 1 in real time via the eighth communication interface in the form of a data stream and stored in the storage module of test terminal 1.

[0033] Step S3: During the OTA upgrade process, data acquisition unit 4 continues to operate. For example, when the upgrade reaches 50%, the following data is collected: CPU utilization is 45%, memory utilization is 32%, current communication latency is 6ms, and the fault code counter is 0. This data is displayed in real time on the monitoring interface of test terminal 1. After the upgrade is completed, the vehicle-mounted TBOX module 2 reports the upgrade completion status to test terminal 1, and test terminal 1 then sends a stop acquisition command to data acquisition unit 4. After transmitting the last batch of data to test terminal 1, data acquisition unit 4 stops operating.

[0034] Step S4: The report generation module of test terminal 1 begins offline analysis of the collected data files. The analysis process is as follows: The number of confirmation frames successfully written by the ECU is counted, denoted as N1; the total number of data frames sent by the vehicle TBOX module 2 is counted, denoted as N2. Upgrade success rate = N1 / N2 × 100%. If the success rate is ≥99%, it meets the standard. The send timestamp Ts and receive timestamp Tr of all data frames are extracted, and the difference is calculated. If all delays are ≤10ms, it meets the standard. The entire data stream is traversed, searching for diagnostic fault code formats conforming to the ISO 14229-1 standard. If no fault codes are found in this test, the trigger count is 0, meeting the standard of ≤1 trigger.

[0035] Since all indicators meet the preset standards, the report generation module automatically generates a PDF OTA upgrade test pass report. The report includes: basic test information, test environment photos, data statistics charts, and the test conclusion: pass.

[0036] Suppose that in another test, the collected test report shows that the test results do not meet the preset standards. At this time, the test enters the fault diagnosis sub-process: Test terminal 1 sends a fault diagnosis command to the vehicle ECU under test through the diagnostic protocol adaptation unit 3 and reads the fault code freeze frame data. If it is a protocol adaptation fault, the adaptation protocol is automatically switched and the test is repeated; if it is a vehicle ECU fault, the fault code and fault location are recorded, and the test personnel are prompted to repair it; if it is an OTA data packet loss fault, the test terminal is controlled to resend the OTA upgrade package, and at the same time, a fault diagnosis log is recorded. The log includes the fault type, fault occurrence time, fault diagnosis steps and solutions, which is convenient for the test personnel to trace later.

[0037] Depending on the test object, the acquisition frequency of data acquisition unit 4 can be adjusted. When testing a high-speed real-time control system, to capture millisecond-level performance fluctuations, the acquisition frequency can be increased to 50Hz, at which point the timer interrupt period inside data acquisition unit 4 is correspondingly adjusted to 20ms. When testing a low-speed vehicle body control system or conducting long-term durability tests, to reduce data storage, the acquisition frequency can be decreased to 10Hz. The acquisition frequency adjustment is completed through the software interface of test terminal 1, which sends the configuration parameters to data acquisition unit 4 via the second communication interface.

[0038] To verify the compatibility of the diagnostic protocol adapter unit 3, this device can be connected to vehicle ECUs using different protocols. For example, when connected to an ECU that only supports the classic CAN protocol, the diagnostic protocol adapter unit 3 automatically identifies and switches to CAN mode; when connected to an ECU that supports the CAN FD protocol, it automatically switches to CAN FD mode. The entire process requires no hardware replacement or manual setup, verifying the compatibility and automated identification capabilities of this invention.

[0039] This invention, by setting up a diagnostic protocol adaptation unit and using the built-in UDS, CAN, and CAN FD bus protocol conversion program of the STM32 chip, can automatically identify the protocol type of the vehicle ECU under test and complete the instruction conversion, achieving compatibility with multiple diagnostic protocols. It can complete the testing of different vehicle models and different ECU modules without changing the test equipment, greatly improving the testing efficiency.

[0040] Secondly, by setting up a multi-channel data acquisition unit, the acquisition frequency can be adjusted within the range of 10-50Hz. This allows for the simultaneous acquisition of data packets, fault codes, and performance parameters such as CPU utilization, memory usage, and upgrade success rate during the OTA upgrade process. This avoids data omissions and misjudgments, providing accurate data support for test result analysis.

[0041] Furthermore, this invention, by incorporating a test case management module into the test terminal, supports the storage, editing, batch import and export of test cases, and can be flexibly adjusted according to different test scenarios such as OTA upgrades and network management, significantly improving the flexibility and adaptability of testing.

[0042] Furthermore, this invention achieves a high degree of automation in the testing process, enabling automatic completion of command issuance, data acquisition, data verification, test report generation, and fault diagnosis. This significantly reduces manual intervention, lowers the workload of testers, and avoids data omissions and misjudgments that may result from manual operation.

[0043] Finally, this invention is not only applicable to OTA upgrade testing, but also to diagnostic protocol compatibility testing and network management performance testing, and has wide applicability and practicality.

[0044] The present invention has been described above by way of example with reference to the accompanying drawings. Obviously, the specific implementation of the present invention is not limited to the above-described manner. Any non-substantial improvements made using the inventive concept and technical solution; or the direct application of the inventive concept and technical solution to other situations without modification, are all within the protection scope of the present invention.

Claims

1. An in-vehicle software testing device, characterized in that, include: The test terminal (1), vehicle-mounted TBOX module (2), diagnostic protocol adapter unit (3), and data acquisition unit (4) are configured. The test terminal (1) has a first communication interface and a second communication interface. The vehicle-mounted TBOX module (2) has a third communication interface and a fourth communication interface. The diagnostic protocol adapter unit (3) has a fifth communication interface and a sixth communication interface. The data acquisition unit (4) has a seventh communication interface and an eighth communication interface. The first communication interface of the test terminal (1) is connected to the third communication interface of the vehicle-mounted TBOX module (2). The second communication interface of the test terminal (1) is connected to the fifth communication interface of the diagnostic protocol adapter unit (3) and the eighth communication interface of the data acquisition unit (4). The sixth communication interface of the diagnostic protocol adapter unit (3) and the seventh communication interface of the data acquisition unit (4) are connected to the CAN interface of the vehicle ECU under test. The fourth communication interface of the vehicle-mounted TBOX module (2) is also connected to the CAN interface of the vehicle ECU under test.

2. The vehicle-mounted software testing device according to claim 1, characterized in that, The test terminal (1) sends an OTA upgrade command and preset test cases to the vehicle TBOX module (2) through the first communication interface; the vehicle TBOX module (2) receives the OTA upgrade command through the third communication interface and transmits it to the vehicle ECU under test; the diagnostic protocol adaptation unit (3) receives the test command sent by the test terminal (1) through the fifth communication interface, performs protocol conversion on the test command, and outputs it to the vehicle ECU under test through the sixth communication interface; the data acquisition unit (4) collects the data packets, fault codes and performance parameters of the vehicle ECU under test and the vehicle TBOX module (2) during the OTA upgrade process through the seventh communication interface, and transmits the collected data to the test terminal (1) through the eighth communication interface.

3. The vehicle-mounted software testing device according to claim 1, characterized in that, The core control chip of the diagnostic protocol adaptation unit (3) is an STM32 chip, which has built-in UDS, CAN and CAN FD bus protocol conversion programs.

4. The vehicle-mounted software testing device according to claim 2, characterized in that, The diagnostic protocol adaptation unit (3) adapts to protocols including UDS protocol, CAN bus protocol and CAN FD bus protocol, with a protocol conversion response time ≤1ms.

5. The vehicle-mounted software testing device according to claim 2, characterized in that, The acquisition frequency of the data acquisition unit (4) is adjustable, ranging from 10 to 50 Hz. The acquired performance parameters include CPU utilization, memory usage, upgrade success rate, and number of fault code triggers.

6. The vehicle-mounted software testing device according to claim 2, characterized in that, The test terminal (1) has the following built-in modules: test case management module, report generation module, and alarm module; the test case management module can store and edit OTA upgrade test and network management test cases, and supports batch import and export of test cases; the report generation module verifies and analyzes the received test data and automatically generates test reports; the alarm module issues an alarm signal when the communication handshake fails.

7. A testing method based on the vehicle-mounted software testing device according to any one of claims 1-6, characterized in that, Includes the following steps: Step S1: The test terminal (1) establishes a communication connection with the vehicle ECU under test through the diagnostic protocol adapter unit (3); Step S2: The test terminal (1) sends an OTA upgrade command to the vehicle TBOX module (2) through its communication interface, and at the same time controls the data acquisition unit (4) to start data acquisition; Step S3: The data acquisition unit (4) transmits the acquired data to the test terminal (1); Step S4: The test terminal (1) processes the received data and generates test results.

8. The vehicle-mounted software testing method according to claim 7, characterized in that, In step S1, the test terminal (1) sends a communication handshake request to the vehicle ECU under test through the diagnostic protocol adapter unit (3). The handshake duration is ≤3s. If the handshake fails, the test terminal (1) issues an alarm signal.

9. The vehicle-mounted software testing method according to claim 7, characterized in that, In step S4, the test terminal (1) compares the collected data with the preset test standards, which include: upgrade success rate ≥99%, communication latency ≤10ms, and fault code triggering times ≤1.

10. The vehicle-mounted software testing method according to claim 7, characterized in that, If the test results do not meet the preset standards, the test terminal (1) sends a fault investigation command to the vehicle ECU under test through the diagnostic protocol adaptation unit (3), locates the fault node, and records the investigation log; the fault node includes protocol adaptation fault, vehicle ECU fault, and OTA data packet loss fault; the investigation log includes fault type, fault occurrence time, fault investigation steps and solutions.

Images