A software flashing fault detection method and device and medium

Abstract

The application discloses a software flashing fault detection method and device and medium, and belongs to the technical field of software testing. The method comprises the following steps: taking a test device as a flashing host computer or only as a data monitoring tool. When the test device is taken as the host computer, the test device is connected with a programmable power supply and a measured piece through a control panel, a complete flashing process is executed, process data is recorded, and a fault situation is simulated during the flashing process. The response of the measured piece during the flashing process is monitored through the test device, whether the response meets the design requirement is verified, the fast positioning and reason analysis of the wrong response are carried out, and the simulation of a DoIP flashing process, the fault injection test of the DoIP flashing process and the test result analysis are realized.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and more specifically, to a method, apparatus, and medium for detecting software flashing faults. Background Technology

[0002] The development of intelligent connected vehicles marks a significant leap forward in the automotive industry, transforming it from traditional mechanical drive to a highly electronic and information-based system. At the heart of this transformation lies the vehicle's software system, which not only controls the vehicle's basic operation but also handles interactions with the external environment, data processing, decision-making, and advanced driver assistance functions. With the development of intelligent connected vehicles, vehicle software systems are becoming increasingly complex. For a better customer experience, OEMs need to frequently update and upgrade the software to fix bugs, optimize performance, or add new features. Traditional software flashing methods involve engineers carrying flashing tools to the vehicle site, which is time-consuming, labor-intensive, and costly. Against this backdrop, OTA (Over-The-Air) technology allows OEMs to directly push, download, and install software onto vehicles via wireless networks, gaining widespread adoption due to its convenience, speed, and low cost. Currently, OTA technology primarily utilizes CAN networks or in-vehicle Ethernet networks for the flashing process.

[0003] Compared to the 500Kbps~2Mbps communication rate of CAN networks, automotive Ethernet networks often offer communication rates exceeding 100Mbps, making them the preferred network for controllers with large software packages when performing flashing. Due to the more complex electrical environment of automotive Ethernet networks, automakers need to conduct more testing and verification of the security and reliability of Ethernet flashing.

[0004] One existing technical solution involves performing a normal flashing process stress test on a host computer and calculating the success rate of multiple flashes. This method involves continuously and repeatedly flashing the same controller using one or two software packages, which requires significant manpower and resources and cannot simulate special situations or fault conditions to verify the fault tolerance performance of the flashing process. If problems occur during the flashing process, the controller may become unrecognizable, preventing subsequent tests from being performed.

[0005] Another existing technical solution involves pushing software upgrades via a cloud platform, executing the upgrade on the vehicle's infotainment system, and then viewing the results. This fully simulates user scenarios using real-vehicle testing, with the software update manually performed on the vehicle's infotainment system. However, this method has drawbacks: it requires vehicle resources; it relies on manual execution of the update process; and the analysis of problems involves the vehicle's infotainment system, the cloud, the connectivity module, and the DUT (Device Under Test) itself, making it difficult to quickly pinpoint the cause of the fault. Summary of the Invention

[0006] One objective of this invention is to provide a software flashing fault detection method, apparatus, and medium to solve the aforementioned problems such as the need to consume a lot of manpower and resources for flashing, the inability to simulate special situations or fault states, and the difficulty in quickly locating the cause of the fault.

[0007] According to a first aspect of the present invention, a method for detecting software flashing failures is provided, comprising the following steps:

[0008] Step 1: Configure the tester's configuration parameters to match the device under test (DUT), and load the software package and corresponding drivers;

[0009] Step 2: Parse the software package and process the address information therein, including but not limited to the storage location of the data in memory and the transmission path in the network;

[0010] Step 3: Execute the flashing process, monitor the response of the device under test through the test equipment, and record the relevant test data during the flashing process;

[0011] Step 4: Analyze the test results based on the test data and generate a test report.

[0012] Optionally, in step 1, the device under test is connected to a preset test environment and the device under test is in a power-off state; configuration parameters of the diagnostic communication (DoIP) service based on the Ethernet protocol are input to the test device.

[0013] Optionally, inputting configuration parameters for the diagnostic communication service based on the Ethernet protocol into the test device includes:

[0014] General parameters include the Media Access Control (MAC) address of the device under test (DUT), the Internet Protocol (IP) address of the DUT, the logical address identifier of the DUT, the physical addressing logical address identifier of the test equipment, the functional addressing logical address identifier of the test equipment, the Event Identifier (EID), and the Vehicle Identification Number (VIN).

[0015] The service information supported by the device under test includes various diagnostic identifiers (DIDs) related to flashing and their definitions;

[0016] Software update information: including the current software version, target software version, fingerprint information, and security authentication method;

[0017] Time-related parameters: including application layer session management timer parameters and network layer timer parameters.

[0018] Optionally, step 3 further includes: setting an abnormal voltage to power the device under test and executing a software flashing process; the test device listens to the response of the device under test and records communication messages; after the flashing process is completed, the software version information and fault code information of the device under test are read.

[0019] Optionally, in step 4, the host computer performs a consistency check on the timing parameters, response content, and writing results of the device under test.

[0020] Optionally, the steps for analyzing test results based on test data specifically include:

[0021] Collect various error responses that occurred during the software flashing process from historical test data. Error responses include, but are not limited to, communication timeouts, data verification errors, exceptions caused by software version mismatch, and flashing interruptions caused by hardware failures.

[0022] Based on the characteristics of error responses, failure modes are classified to form a failure mode library;

[0023] Receive raw data recorded during the flashing process, including communication messages between the test device and the device under test, time sequence data of the flashing operation, software version information, and hardware status parameters;

[0024] The raw data is cleaned and standardized.

[0025] Extract features related to error responses from the preprocessed data;

[0026] Based on the extracted feature types, a decision tree algorithm is used to make judgments, using error response type, time point, and key data outliers as node conditions of the decision tree to gradually classify into specific fault modes.

[0027] Optionally, the steps of analyzing test results based on test data may also include:

[0028] Once the test device detects an error response from the device under test during the flashing process, it immediately acquires and records all relevant data of the error response, including the response content, response time, and the execution stage information of the current flashing process.

[0029] Match error response characteristics with existing patterns in the fault mode library;

[0030] If no perfectly matching pattern is found in the fault mode library, a clustering algorithm is used to group the error response with other similar historical error responses, analyze the clustering results, and further analyze the hardware cause.

[0031] Optionally, the software flashing fault detection method further includes: the test equipment is configured to perform fault simulation according to user needs, including: setting communication-level fault types and hardware-related fault types, setting the fault occurrence time point, and customizing the specific manifestation of the fault.

[0032] According to a second aspect of the present invention, a software flashing fault detection device is provided, comprising:

[0033] The configuration module is used to configure the configuration parameters of the tester to match the device under test (DUT), and load the software package and the corresponding driver.

[0034] The parsing module is used to parse the software package and process the address information therein, including but not limited to the storage location of the data in memory and the transmission path in the network;

[0035] The flashing module is used to execute the flashing process, listen to the response of the device under test through the test equipment, and record relevant test data during the flashing process.

[0036] The analysis module is used to analyze test results based on test data and generate test reports.

[0037] According to a third aspect of the present invention, a computer-readable storage medium is provided, on which a computer program is stored, wherein when the computer program is executed by a processor, the computer program implements the steps of the software flashing fault detection method described in the first aspect of the present invention.

[0038] The software flashing fault detection method, apparatus, and medium disclosed herein have the following technical advantages:

[0039] The test equipment can be used as a host computer for flashing or simply as a data monitoring tool. When used as a host computer, the test equipment is connected to the programmable power supply and the device under test (DUT) via a control panel. It can execute the complete flashing process, record process data, and simulate fault scenarios during the process. During flashing, the test equipment monitors the DUT's response, verifies whether its response meets design requirements, and can quickly locate and analyze the causes of erroneous responses. By analyzing the success rate, problem points, and stability of the flashing process, it can generate a test report.

[0040] Other features and advantages of the invention will become clear from the following detailed description of exemplary embodiments of the invention with reference to the accompanying drawings. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments of the invention and, together with their description, serve to explain the principles of the invention.

[0042] Figure 1 This is a flowchart illustrating a software flashing fault detection method according to an embodiment of the present invention.

[0043] Figure 2 This is a flowchart illustrating a software flashing fault detection method according to another embodiment of the present invention. Detailed Implementation

[0044] Various exemplary embodiments of the present invention will now be described in detail with reference to the accompanying drawings. It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of the invention.

[0045] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit the invention or its application or use.

[0046] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0047] In all the examples shown and discussed herein, any specific values ​​should be interpreted as merely exemplary and not as limitations. Therefore, other examples of exemplary embodiments may have different values.

[0048] This invention proposes an embodiment of a software flashing fault detection method, specifically, as follows: Figure 1 As shown, it includes the following steps:

[0049] Step 1: Configure the tester's configuration parameters to match the device under test (DUT), and load the software package and corresponding driver. The driver is responsible for accurately conveying the tester's instructions to the DUT and correctly transmitting the DUT's feedback information back to the tester. Through accurate parameter configuration, the stability and reliability of communication between the tester and the DUT are ensured, avoiding communication failures or data transmission errors caused by parameter mismatch.

[0050] Step 2: Parse the software package and process the address information therein. The address information includes, but is not limited to, the storage location of the data in memory and the transmission path in the network. Specifically, for the transmission path in the network, determine the network route of the data from the Tester to the DUT, including information on the network nodes, switches, routers and other devices that pass through, as well as the IP address allocation and port mapping on each node.

[0051] Step 3: Execute the flashing process. The test equipment monitors the response of the device under test (DUT) and records relevant test data during the flashing process. During this process, the Tester transmits the data from the software package to the DUT step-by-step according to a predetermined order and method. Specifically, a block transfer method is used to divide the software package into several data blocks, each with checksum information to ensure data integrity. The DUT sends various response messages to the Tester during data reception and processing, such as confirmation signals and error messages.

[0052] Step 4: Analyze the test results based on the test data and generate a test report. Specifically, compare the data recorded during the actual flashing process with the expected results to check whether all data blocks were correctly transmitted and received, and whether the final software version of the DUT is consistent with the target version. Then, perform statistical analysis on abnormal data and error information during the flashing process. The test report includes basic test information, such as the model of the Tester and DUT, software package version, test time, etc., as well as test result information such as whether the flashing was successful, what faults existed (if any), and the location and frequency of the faults.

[0053] In this embodiment of the invention, in step 1, the device under test (DUT) is connected to a preset test environment and is in a power-off state; configuration parameters for the Diagnostic Communication over Ethernet (DoIP) service are input to the test equipment. Specifically, the preset test environment includes connection lines, power supplies, network connection devices, etc., compatible with the DUT interface. When the Tester is used as the flashing host, it is connected to the programmable power supply and the DUT via a control panel, and can execute the complete flashing process and record process data. When powered off, the DUT's hardware circuitry is in an initial static state, with no data read / write operations in its internal storage units (such as flash memory, RAM, etc.), and the processor is not executing any instructions. This avoids interference from the unknown state inside the DUT during the configuration of test equipment parameters and the input of service configuration parameters. The DoIP service can utilize the Ethernet infrastructure to achieve diagnostic communication over longer distances. Inputting the DoIP service configuration parameters to the Tester enables the Tester to establish effective communication with the DUT via the DoIP protocol.

[0054] In this embodiment of the invention, inputting configuration parameters for diagnostic communication services based on the Ethernet protocol to the test device includes:

[0055] General parameters include the Media Access Control (MAC) address of the device under test (DUT), the Internet Protocol (IP) address of the DUT, the logical address identifier of the DUT, the physical addressing logical address identifier of the test equipment, the functional addressing logical address identifier of the test equipment, the Event Identifier (EID), and the Vehicle Identification Number (VIN).

[0056] The service information supported by the device under test includes various diagnostic identifiers (DIDs) related to flashing and their definitions;

[0057] Software update information: including the current software version, target software version, fingerprint information, and security authentication method;

[0058] Time-related parameters: including application layer session management timer parameters and network layer timer parameters.

[0059] In this embodiment of the invention, step 3 further includes: setting an abnormal voltage (e.g., 9V, normally 12V) to power the device under test (DUT) and executing a software flashing process. The test device listens to the response of the DUT and records communication messages. After the flashing process is completed, the software version information and fault code information of the DUT are read. The selection of the abnormal voltage is intended to trigger potential faults that are not easily exposed under normal voltage power supply conditions, such as data transmission errors, memory chip write errors, or processor operation abnormalities caused by abnormal voltage. These faults will be fed back to the Tester through the communication link. The DUT's response includes, but is not limited to, data reception confirmation signals, error messages, and current flashing progress. After performing software flashing under an abnormal voltage, reading the software version information can help determine whether there is a software version error, and reading the fault code information can quickly locate the problems that occurred during the flashing process. By setting an abnormal voltage power supply and executing the software flashing process, some hardware problems hidden under normal voltage conditions can be exposed, such as poor tolerance of hardware components to voltage fluctuations and instability of the power management module.

[0060] In this embodiment of the invention, in step 4, the host computer performs a consistency check on the timing parameters, response content, and flashing results of the device under test (DUT). Specifically, by performing multiple software flashing tests on the same model of DUT under a standard environment, the timing parameter range for each operation is statistically determined. The host computer records the timing of each DUT response and compares it with this reference range. If the DUT's response delay to a certain instruction significantly exceeds the normal range, the host computer will mark this as an anomaly. The host computer checks the consistency of the response content by comparing it with the expected response content. When the DUT successfully receives a data block, it sends an acknowledgment message to the Tester containing the data block number, checksum result, and reception status. If a data error is found during reception, the DUT will include an error code and error location information in the response message. The consistency check for the flashing results includes checking whether the software version information of the DUT after flashing is consistent with the expected target version, and also checking the DUT's internal status registers and other information to determine if there are any abnormal flags. When a consistency check detects an anomaly, the check, which covers multiple aspects of information (time parameters, response content, and write results), can provide technicians with a wealth of clues to pinpoint the cause of the failure.

[0061] In this embodiment of the invention, the step of analyzing test results based on test data specifically includes:

[0062] Collect various error responses that occurred during the software flashing process from historical test data. Error responses include, but are not limited to, communication timeouts, data verification errors, exceptions caused by software version mismatch, and flashing interruptions caused by hardware failures.

[0063] Based on the characteristics of error responses, failure modes are classified to form a failure mode library;

[0064] Receive raw data recorded during the flashing process, including communication messages between the test device and the device under test, time sequence data of the flashing operation, software version information, and hardware status parameters;

[0065] The raw data is cleaned and standardized.

[0066] Extract features related to error responses from the preprocessed data;

[0067] Based on the extracted feature types, a decision tree algorithm is used to make judgments, using error response type, time point, and key data outliers as node conditions of the decision tree to gradually classify into specific fault modes.

[0068] In this embodiment of the invention, the step of analyzing test results based on test data further includes:

[0069] Once the test device detects an error response from the device under test during the flashing process, it immediately acquires and records all relevant data of the error response, including the response content, response time, and the execution stage information of the current flashing process.

[0070] Match error response characteristics with existing patterns in the fault mode library;

[0071] If no perfectly matching pattern is found in the fault mode library, a clustering algorithm is used to group the error response with other similar historical error responses, analyze the clustering results, and further analyze the hardware cause.

[0072] In this embodiment of the invention, the software flashing fault detection method further includes: the testing equipment is configured for fault simulation according to user needs, including: setting communication-level fault types and hardware-related fault types, setting the fault occurrence time point, and customizing the specific manifestation of the fault. This allows users to simulate various fault scenarios that may occur in actual operation, in order to more comprehensively evaluate the reliability and stability of the software flashing process.

[0073] The communication layer fault type settings include: packet loss ratio settings for network packet loss faults, delay time range settings for excessive delay faults, and selection of specific protocol error types for communication protocol error faults.

[0074] Hardware-related fault type settings include: memory fault, storage device fault, processor fault settings, etc.

[0075] Setting fault occurrence points includes: Setting faults during the software flashing initialization phase to simulate problems during startup, such as incorrect initialization parameters or device recognition failure. During the data transfer phase, faults can be triggered based on the amount of data transferred or specific data blocks to test the software's ability to handle faults at different data transfer progresses. For example, triggering a fault when half of the data is being transferred allows observation of whether the software can correctly pause, resume, or retransmit data. Setting faults during the write phase simulates problems that occur when writing data to the storage device, such as write conflicts or incorrect write addresses.

[0076] Customized specific manifestations of the fault include: network packet loss in communication faults, read / write errors in memory faults, and hard drive bad sectors in hardware faults.

[0077] Because users can precisely configure the fault type, occurrence time, and manifestation, when software flashing encounters problems, the issue can be more accurately correlated with specific fault simulation conditions. This helps to quickly pinpoint the cause of the fault, determining whether the flashing failure was due to a communication protocol error, hardware failure, or other specific factors.

[0078] In another embodiment of the present invention, a schematic diagram of a Class II ECU flashing process is provided, as follows: Figure 2 As shown, Class II ECUs are ECUs with an operating system that support reprogramming, specifically including the following steps:

[0079] (1) Bootloader fault test: Perform fault test on the device's bootloader to check whether the bootloader can load normally and whether there are error codes or abnormal behaviors;

[0080] (2) Pre-programming, checking whether the preparation work is sufficient, such as whether the environment is set up correctly and whether the required tools are available;

[0081] (3) Read the serial number. Read the serial number of the device to identify and distinguish different devices. Ensure that the serial number can be read correctly. If it cannot be read, it may be a device connection problem or a reading program failure.

[0082] (4) Secure access: Verify whether the authentication and authorization mechanisms are working properly. If authorization fails, it may be due to permission settings or authentication system failure.

[0083] (5) Routing activation and MD5 check: Activate the route to establish a communication channel and check the MD5 value of the file to ensure file integrity;

[0084] (6) Determine if the MD5 hashes are the same to determine if the file is complete. If yes, proceed to step (12) to check programming dependencies. If no, proceed to step (7) to write the fingerprint.

[0085] (7) Write fingerprint: Write specific fingerprint information into the device for authentication. If the writing fails, it may be due to a device storage problem or a writing program failure.

[0086] (8) Request file transfer, check whether the request can be sent successfully, and whether the file server can respond to the request;

[0087] (9) Transmit data blocks, divide the file into data blocks, and check whether the data blocks can be transmitted correctly and whether there are any missing or damaged data blocks;

[0088] (10) Determine if there are still untransmitted data blocks to ensure that all data blocks can be transmitted correctly and avoid omissions; if yes, return to step (9) to continue transmitting data blocks; if no, request to exit transmission.

[0089] (11) Activate the route and check the integrity of the programming. Activate the route again and check the integrity of the programming.

[0090] (12) Check programming dependencies, such as whether specific software or hardware conditions are required to complete programming, and determine whether the dependencies required for programming are met. If they are not met, programming may fail.

[0091] (13) Start the installation and check whether the installation process can start normally and whether there are any error messages or abnormal behaviors;

[0092] (14) Establish a DoIP connection and check whether the connection can be established successfully and whether the communication is normal;

[0093] (15) Periodically obtain installation progress information to ensure that the installation progress information is obtained correctly and that the progress display is accurate;

[0094] (16) Reset the hardware and software to ensure that the device can operate normally after programming;

[0095] (17) Post-programming: After the software is flashed, follow-up processing is performed, including cleaning up temporary files and updating configurations, in order to check whether the post-programming operation is executed correctly and whether there are any omissions or errors.

[0096] (18) End.

[0097] In summary, common testing issues during software flashing include:

[0098] The secure access algorithm does not meet the specification requirements;

[0099] The consistency check failed due to packet loss or other failures during file transfer;

[0100] The installation process was interrupted abnormally and cannot be rolled back.

[0101] The voltage communication range does not meet design requirements;

[0102] Data processing error, unable to respond to operation instructions in a timely manner.

[0103] Test results are generated based on the above flashing process, and the results are analyzed. The analysis includes:

[0104] Check whether the configuration information of the DUT meets the design requirements;

[0105] Check if the DUT sends the response message according to the correct time parameters;

[0106] Check that the DUT software has been downloaded and installed correctly;

[0107] Check if the DUT can correctly write information such as fingerprint and version number;

[0108] Check whether the DUT correctly disabled functions such as fault code recording and software communication during the flashing process.

[0109] The present invention also provides an embodiment of a software flashing fault detection device, comprising:

[0110] The configuration module is used to configure the configuration parameters of the tester to match the device under test (DUT), and load the software package and the corresponding driver.

[0111] The parsing module is used to parse the software package and process the address information therein, including but not limited to the storage location of the data in memory and the transmission path in the network;

[0112] The flashing module is used to execute the flashing process, listen to the response of the device under test through the test equipment, and record relevant test data during the flashing process.

[0113] The analysis module is used to analyze test results based on test data and generate test reports.

[0114] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application, and are devices corresponding to the above software flashing fault detection method. All implementation methods in the above method embodiments are applicable to the embodiments of this device. For details on its specific functions and the technical effects it brings, please refer to the method embodiments section, which will not be repeated here.

[0115] The present invention also provides an embodiment of a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the above-described software flashing fault detection method, enabling simulation of the DoIP flashing process, fault injection testing, and test result analysis. It does not require the use of vehicle resources and solves the problems of DoIP-based flashing fault simulation and fault location.

[0116] The above description of the structure, features, and effects of the present invention is based on the embodiments shown in the figures. However, the above are only preferred embodiments of the present invention. It should be noted that the technical features involved in the above embodiments and their preferred methods can be reasonably combined and matched by those skilled in the art to form a variety of equivalent solutions without departing from or changing the design concept and technical effects of the present invention. Therefore, the present invention is not limited to the scope of implementation shown in the figures. Any changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments, that do not exceed the spirit covered by the specification and figures, should be within the protection scope of the present invention.

Claims

1. A method for detecting software flashing failures, characterized in that, Includes the following steps: Step 1: Use the test device as the host computer, configure the test device (Tester) configuration parameters to match the device under test (DUT), load the software package and corresponding drivers, including inputting configuration parameters for diagnostic communication services based on the Ethernet protocol to the test device. Specifically, the test device performs fault simulation configuration according to user needs, including: setting communication-level fault types and hardware-related fault types, setting the fault occurrence time point, and customizing the specific fault manifestations. The communication-level fault type settings include: setting the packet loss ratio in network packet loss faults, setting the delay time range in high latency faults, and selecting specific protocol error types in communication protocol error faults. The hardware-related fault type settings include: memory faults, storage device faults, and processor fault settings. Common parameters include the Media Access Control (MAC) address of the device under test (DUT), the Internet Protocol (IP) address of the DUT, the logical address identifier of the DUT, the physical addressing logical address identifier of the test device, the functional addressing logical address identifier of the test device, the Event Identifier (EID), and the Vehicle Identification Number (VIN). The service information supported by the device under test includes various diagnostic identifiers (DIDs) related to flashing and their definitions; Software update information, including the current software version, target software version, fingerprint information, and security authentication method; Time-related parameters, including application layer session management timer parameters and various network layer timer parameters; Step 2: Parse the software package and process the address information therein, including but not limited to the storage location of the data in memory and the transmission path in the network; Step 3: Execute the flashing process, monitor the response of the device under test through the test equipment, and record the relevant test data during the flashing process; Step 4: Analyze the test results based on the test data and generate a test report; wherein, the analysis of test results based on the test data specifically includes: Collect various error responses that occurred during the software flashing process from historical test data. Error responses include, but are not limited to, communication timeouts, data verification errors, exceptions caused by software version mismatch, and flashing interruptions caused by hardware failures. Based on the characteristics of error responses, failure modes are classified to form a failure mode library; Receive raw data recorded during the flashing process, including communication messages between the test device and the device under test, time sequence data of the flashing operation, software version information, and hardware status parameters; The raw data is cleaned and standardized. Extract features related to error responses from the preprocessed data; Based on the extracted feature types, a decision tree algorithm is used to make judgments, using error response type, time point, and key data outliers as node conditions of the decision tree to gradually classify into specific fault modes.

2. The software flashing fault detection method according to claim 1, characterized in that, In step 1, the device under test is connected to a preset test environment and the device under test is put into a power-off state.

3. The software flashing fault detection method according to claim 1, characterized in that, Step 3 also includes: setting an abnormal voltage to power the device under test and executing a software flashing process. The test device listens to the response of the device under test and records communication messages. After the flashing process is completed, the software version information and fault code information of the device under test are read.

4. The software flashing fault detection method according to claim 1, characterized in that, In step 4, the host computer performs a consistency check on the timing parameters, response content, and writing results of the device under test.

5. The software flashing fault detection method according to claim 1, characterized in that, The steps for analyzing test results based on test data also include: Once the test device detects an error response from the device under test during the flashing process, it immediately acquires and records all relevant data of the error response, including the response content, response time, and the execution stage information of the current flashing process. Match error response characteristics with existing patterns in the fault mode library; If no perfectly matching pattern is found in the fault mode library, a clustering algorithm is used to group the error response with other similar historical error responses, analyze the clustering results, and further analyze the hardware cause.

Images