Software flashing fault detection method and device and medium

Abstract

The invention discloses a software flashing fault detection method and device and a medium, and belongs to the technical field of software test.The method comprises the steps that test equipment serves as a flashing upper computer or only serves as a data monitoring tool; when the testing device serves as an upper computer, the testing device is connected with the programmable power source and the tested piece through the control panel, a complete flashing process is executed, process data are recorded, and the fault situation is simulated in the flashing process; the response of the tested piece in the flashing process is monitored through the test equipment, whether the response meets the design requirement or not is verified, rapid positioning and reason analysis are conducted on the wrong response, and simulation, fault injection testing and test result analysis of the DoIP flashing process are achieved.

Description

Technical Field

[0001] The present invention relates to the field of software testing technology, and more specifically, to a software flashing fault detection method, device and medium. Background Art

[0002] The development of intelligent connected vehicles marks a major leap in the automotive industry from traditional mechanical drive to highly electronic and information-based. The core of this transformation lies in the vehicle's software system, which not only controls the basic operation of the vehicle, but is also responsible for the interaction between the vehicle and the external environment, data processing, decision-making, and advanced driver assistance functions. With the development of intelligent connected vehicles, the vehicle's software system is becoming more and more complex. In order to provide a better customer experience, OEMs need to frequently update and upgrade the software to fix vulnerabilities, optimize performance, or add new features. The traditional software flashing method is for engineers to carry flashing tools to the vehicle site to perform flashing, which is time-consuming, labor-intensive and costly. In this context, OTA technology (over-the-air download technology) allows OEMs to push, download and install software directly to vehicles through wireless networks, and is used by major OEMs for its convenience, speed and low cost. At present, OTA technology is mainly based on CAN network or vehicle Ethernet network to perform the flashing process.

[0003] Compared with the 500Kbps~2Mbps communication rate of the CAN network, the communication rate of the automotive Ethernet network can often reach more than 100Mbps, making it the preferred network for flashing controllers with larger software packages. Since the electrical environment of the automotive Ethernet network is more complex, automobile manufacturers need to conduct more testing and verification on the safety and reliability of Ethernet flashing.

[0004] One technical solution in the prior art is to perform a normal flashing process stress test on the flashing host computer and calculate the success rate of multiple flashing. This method uses one or two software packages to flash the same controller repeatedly without interruption, which requires a lot of manpower and material resources, and cannot simulate special situations or fault conditions to verify the fault tolerance performance of the flashing. If a problem occurs during the flashing process, it may be unrecognizable and subsequent tests cannot be performed.

[0005] Another technical solution in the prior art is to push the upgrade software through the cloud platform, perform the upgrade on the real vehicle and view the results. Use the real vehicle test to fully simulate the user scenario and manually perform the software update on the real vehicle. However, the disadvantages of this method are that it requires vehicle resources; it relies on manual execution of the update process; the analysis of the problem involves the vehicle, cloud, network module and DUT (device under test) itself, which is not conducive to quickly locating the cause of the fault. Summary of the invention

[0006] An object of the present invention is to provide a software flash fault detection method, device and medium to solve the aforementioned problems that flashing requires a lot of manpower and material resources, special situations or fault conditions cannot be simulated, and it is not conducive to quickly locating the cause of the fault.

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

[0008] Step 1: Configure the configuration parameters of the test equipment (Tester) to match the device under test (DUT), load the software package and corresponding driver;

[0009] Step 2: Parse the software package and process the address information therein, wherein the address information includes but is not limited to the storage location of the data in the 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 device, and record the relevant test data in 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 placed in an unpowered state; and configuration parameters of a diagnostic communication over Ethernet protocol (DoIP) service are input to the test device.

[0013] Optionally, inputting configuration parameters of the Ethernet protocol-based diagnostic communication service to the test device includes:

[0014] General parameters: including the media access control (MAC) address of the device under test, the Internet Protocol (IP) address of the device under test, the logical address identifier of the device under test, 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 code);

[0015] The service information supported by the DUT: including various diagnostic identifiers (DIDs) related to flashing and their definitions;

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

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

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

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

[0020] Optionally, the step of analyzing the test results according to the test data specifically includes:

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

[0022] According to the characteristics of the error response, the fault modes are classified to form a fault mode library;

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

[0024] Clean and standardize the raw data;

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

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

[0027] Optionally, the step of analyzing the test results according to the test data further includes:

[0028] Once the test device detects an error response of 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 execution stage information of the current flashing process;

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

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

[0031] Optionally, the software flash fault detection method also includes: the test equipment performs fault simulation configuration according to user needs, including: communication layer fault type setting and hardware-related fault type setting, as well as fault occurrence time point setting, and fault specific manifestation customization.

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

[0033] Configuration module, used to configure the configuration parameters of the test equipment (Tester) to match the device under test (DUT), load the software package and the corresponding driver;

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

[0035] A flashing module, used to execute the flashing process, monitor the response of the device under test through the test device, and record relevant test data in the flashing process;

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

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

[0038] The software flash fault detection method, device and medium disclosed in the present invention have the following technical effects:

[0039] Use the test equipment as a flashing host computer 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 through the control panel, and can execute the complete flashing process and record process data, and simulate fault conditions during the process; during the flashing process, the test equipment will monitor the response of the device under test to verify whether its response meets the design requirements, and can quickly locate and analyze the cause of the wrong response. By analyzing the success rate, problem points, and stability of the flashing, a test report can be generated.

[0040] Further features and advantages of the present invention will become apparent from the following detailed description of exemplary embodiments of the present invention with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0042] Figure 1 A flowchart of a software flash fault detection method provided by an embodiment of the present invention;

[0043] Figure 2 A flowchart of a software flash fault detection method provided by another embodiment of the present invention. DETAILED DESCRIPTION

[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 the relative arrangement of components and steps, numerical expressions and numerical values ​​set forth in these embodiments do not limit the scope of the present invention unless otherwise specifically stated.

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

[0046] Technologies, methods, and equipment known to ordinary technicians in the relevant art may not be discussed in detail, but where appropriate, the technologies, methods, and equipment should be considered as part of the specification.

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

[0048] The present invention proposes an embodiment of a software flash fault detection method. Specifically, Figure 1 As shown, the following steps are included:

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

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

[0051] Step 3: Execute the flashing process, monitor the response of the DUT through the test equipment, and record the relevant test data in the flashing process; in this process, the Tester gradually transfers the data in the software package to the DUT in a predetermined order and manner. Specifically, the software package is divided into several data blocks using a block transmission method, and each data block carries checksum information to ensure the integrity of the data. In the process of receiving and processing data, the DUT sends various response information to the Tester, such as confirmation reception signals, error prompt information, etc.

[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 are 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 information about the test, such as the model of the Tester and DUT, the software package version, the test time, etc. At the same time, it also includes test result information such as whether the flashing is successful, what faults exist (if any), the location and frequency of the faults, etc.

[0053] In an embodiment of the present invention, in step 1, the device under test is connected to a preset test environment, and the device under test is in an unpowered state; the configuration parameters of the diagnostic communication (DoIP) service based on the Ethernet protocol are input to the test equipment. Specifically, the preset test environment includes connection lines, power supplies, network connection devices, etc. that are compatible with the DUT interface. When the Tester is used as a flashing host computer, the Tester is connected to the programmable power supply and the DUT through the control panel, respectively, and the complete flashing process can be executed to record process data. When the power is not on, the hardware circuit of the DUT is in an initial static state, the internal storage unit (such as flash memory, memory, etc.) has no data read and write operations, and the processor does not execute any instructions, so as to avoid the unknown state inside the DUT from interfering with these operations when configuring the test equipment parameters and inputting the service configuration parameters. The DoIP service can utilize the Ethernet infrastructure to achieve longer-distance diagnostic communication. The configuration parameters of the DoIP service are input to the Tester so that the Tester can establish effective communication with the DUT through the DoIP protocol.

[0054] In an embodiment of the present invention, inputting the configuration parameters of the Ethernet protocol-based diagnostic communication service to the test device includes:

[0055] General parameters: including the media access control (MAC) address of the device under test, the Internet Protocol (IP) address of the device under test, the logical address identifier of the device under test, 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 code);

[0056] The service information supported by the DUT: including various diagnostic identifiers (DIDs) related to flashing and their definitions;

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

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

[0059] In an embodiment of the present invention, step 3 also includes: setting an abnormal voltage (such as 9V, normally 12V) to power the device under test, and executing a software flashing process, the test equipment monitors the response of the device under test, and records the communication message, and after the flashing process is completed, reads the software version information and fault code information of the device under test. The selection of abnormal voltage is intended to trigger potential faults that are not easily exposed under normal voltage power supply, such as data transmission errors, memory chip write errors, or processor operation abnormalities caused by voltage abnormalities, and these faults will be fed back to the Tester through the communication link. The response of DUT includes but is not limited to data reception confirmation signals, error prompt information, current flashing progress and other information. After software flashing under abnormal voltage, reading the software version information can help determine whether there is a software version error problem, and reading the fault code information can quickly locate the problems that occur during the flashing process. By setting abnormal voltage power supply and executing the software flashing process, some hardware problems hidden under normal voltage can be exposed, such as hardware components with poor tolerance to voltage fluctuations, instability of power management modules, and other problems.

[0060] In an embodiment of the present invention, in step 4, the host computer performs consistency check on the time parameters, response content and flashing results of the response of the device under test. Specifically, by performing multiple software flashing tests on the same model of DUT under a standard environment, the time parameter range of each operation is statistically calculated, and the host computer records the time point of each DUT response and compares it with this reference range. If the response delay of the DUT to a certain instruction is obviously beyond the normal range, the host computer will mark this abnormal situation. The consistency check of the response content by the host computer is carried out by comparing it with the expected response content. When the DUT successfully receives a data block, it will send a confirmation message containing the data block number, checksum result and receiving status to the Tester. If a data error is found during the receiving process, the DUT will include an error code and error location information in the response message. The consistency check on the flashing result includes checking whether the software version information of the DUT after flashing is consistent with the expected target version, and also checking the internal status register of the DUT and other information to determine whether there are any abnormal signs. When a consistency check finds an anomaly, since the check covers multiple aspects of information (time parameters, response content, and flash results), it can provide technicians with rich clues to locate the cause of the failure.

[0061] In an embodiment of the present invention, the step of analyzing the test results according to the test data specifically includes:

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

[0063] According to the characteristics of the error response, the fault modes are classified to form a fault mode library;

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

[0065] Clean and standardize the raw data;

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

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

[0068] In an embodiment of the present invention, the step of analyzing the test results according to the test data further includes:

[0069] Once the test device detects an error response of 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 execution stage information of the current flashing process;

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

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

[0072] In an embodiment of the present invention, the software flash fault detection method further includes: the test device performs fault simulation configuration according to user requirements, including: communication layer fault type setting and hardware related fault type setting, as well as fault occurrence time point setting and fault specific manifestation customization. Allowing users to simulate various fault conditions that may occur in actual operation, so as to more comprehensively evaluate the reliability and stability of the software flash process.

[0073] Among them, the communication layer fault type settings include: packet loss ratio setting in network packet loss fault, delay time range setting in excessive delay fault, specific protocol error type selection in communication protocol error fault, etc.

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

[0075] The fault occurrence time setting includes: setting the fault in the initialization phase of software flashing to simulate problems in the startup process, such as initialization parameter errors or device identification failures. In the data transmission phase, triggering faults based on the amount of data transferred or specific data blocks can test the software's ability to cope with faults at different data transmission progress. For example, triggering a fault when half of the data is transferred to observe whether the software can correctly pause, resume, or retransmit data. Setting faults in the write phase can simulate problems that occur when the storage device is writing data, such as write conflicts, write address errors, etc.

[0076] The customization of specific fault manifestations includes: network packet loss manifestation in communication failure, read and write error manifestation in memory failure, and hard disk bad sector manifestation in hardware failure, etc.

[0077] Since users can precisely set the fault type, occurrence time, and manifestation, when a software flashing problem occurs, the problem can be more accurately associated with a specific fault simulation condition. This helps to quickly locate the cause of the fault and determine whether the flashing failure is caused by a communication protocol error, hardware failure, or other specific factors.

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

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

[0080] (2) Pre-programming: Check 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 setting problems or authentication system failures.

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

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

[0085] (7) Write fingerprints, write specific fingerprint information to the device for identity authentication. If the writing fails, it may be 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 is any loss or damage;

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

[0089] (11) Activate the route and check the programming integrity. Activate the route again and check whether the programming is complete.

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

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

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

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

[0094] (16) Software and hardware reset: reset the software and hardware 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 temporary files, updating configurations, etc., to check whether the post-programming operation is executed correctly and whether there are omissions or errors;

[0096] (18) End.

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

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

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

[0100] The installation process is abnormally interrupted and cannot be rolled back;

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

[0102] Data processing is abnormal and cannot respond to operation instructions on time.

[0103] Generate test results based on the above flashing process and analyze the test results. The analysis includes:

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

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

[0106] Check whether the DUT software is downloaded and installed correctly;

[0107] Check whether the DUT can correctly write fingerprint, version number and other information;

[0108] Check whether the DUT correctly shields the fault code recording, software communication and other functions during the flashing process.

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

[0110] Configuration module, used to configure the configuration parameters of the test equipment (Tester) to match the device under test (DUT), load the software package and the corresponding driver;

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

[0112] A flashing module, used to execute the flashing process, monitor the response of the device under test through the test device, and record relevant test data in the flashing process;

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

[0114] It should be noted that the information interaction, execution process and other contents between the above-mentioned modules are based on the same concept as the method embodiment of the present application, and are devices corresponding to the above-mentioned software flash fault detection method. All implementation methods in the above-mentioned method embodiment are applicable to the embodiments of the device. Its specific functions and technical effects brought about can be found in the method embodiment part, which will not be repeated here.

[0115] The present invention also provides an embodiment of a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned software flashing fault detection method are implemented, and the simulation and fault injection test of the DoIP flashing process and the analysis of the test results can be realized; it does not need to occupy vehicle resources, and solves the problems of flashing fault simulation and fault location based on DoIP.

[0116] The above describes in detail the structure, features and effects of the present invention based on the embodiments shown in the drawings, but the above is only a preferred embodiment 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 into a variety of equivalent schemes by those skilled in the art without departing from or changing the design ideas and technical effects of the present invention; therefore, the present invention is not limited to the scope of implementation shown in the drawings, and all changes made in accordance with the concept of the present invention, or modifications to equivalent embodiments with equivalent changes, which still do not exceed the spirit covered by the specification and drawings, should be within the protection scope of the present invention.

Claims

1. A software flash fault detection method, characterized in that: The following steps are involved: Step 1: Configure the configuration parameters of the test equipment (Tester) to match the device under test (DUT), load the software package and corresponding driver; Step 2: Parse the software package and process the address information therein, wherein the address information includes but is not limited to the storage location of the data in the 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 device, and record the relevant test data in the flashing process; Step 4: Analyze the test results based on the test data and generate a test report.

2. The software flash 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 placed in an unpowered state, and configuration parameters of a diagnostic communication over Ethernet protocol (DoIP) service are input to the test equipment.

3. The software flash fault detection method according to claim 2, characterized in that: Inputting configuration parameters of the Ethernet protocol-based diagnostic communication service to the test device includes: General parameters: including the media access control (MAC) address of the device under test, the Internet Protocol (IP) address of the device under test, the logical address identifier of the device under test, 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 code); The service information supported by the DUT: including various diagnostic identifiers (DIDs) related to flashing and their definitions; Software update information: including current software version, target software version, fingerprint information, and security authentication method; Time-related parameters: including application layer session management timer-related parameters and network layer timer parameters.

4. The software flash 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 equipment monitors the response of the device under test and records communication messages, and after the flashing process is completed, reads the software version information and fault code information of the device under test.

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

6. The software flash fault detection method according to claim 1, characterized in that: The steps for analyzing the test results based on the test data specifically include: Collect error responses that occur during various software flashing processes from historical test data. Error responses include but are not limited to communication timeouts, data verification errors, exceptions caused by software version mismatches, and flashing interruptions caused by hardware failures; According to the characteristics of the error response, the fault modes are classified to form a fault mode library; Receiving raw data recorded during the flashing process, the raw data including communication messages between the test device and the device under test, time series data of the flashing operation, software version information, and hardware status parameters; Clean and standardize the raw data; Extracting features related to error responses from the preprocessed data; According to the extracted feature types, the decision tree algorithm is used to make judgments, and the error response type, time point and key data outliers are used as the node conditions of the decision tree to gradually classify them into specific fault modes.

7. The software flash fault detection method according to claim 6, characterized in that: The steps of analyzing the test results based on the test data also include: Once the test device detects an error response of 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 execution stage information of the current flashing process; Match the error response characteristics with existing patterns in the fault mode library; If no completely matching pattern is found in the fault mode library, a clustering algorithm is used to cluster the error response with other similar historical error responses, analyze the clustering results, and further analyze the hardware causes.

8. The software flash fault detection method according to claim 1, characterized in that: Also includes: The test equipment performs fault simulation configuration according to user needs, including: communication layer fault type setting and hardware-related fault type setting, as well as fault occurrence time point setting and fault specific manifestation customization.

9. A software flashing fault detection device, characterized in that: include: A configuration module, used to configure the configuration parameters of the test equipment to match the device under test, and load the software package and the corresponding driver; A parsing module, used to parse the software package and process the address information therein, wherein the address information includes but is not limited to the storage location of the data in the memory and the transmission path in the network; A flashing module, used to execute the flashing process, monitor the response of the device under test through the test device, and record relevant test data in the flashing process; The analysis module is used to analyze the test results based on the test data and generate a test report.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the software flash fault detection method according to any one of claims 1 to 8 are implemented.

Images