Memory testing methods, apparatus and vehicles

Abstract

This application discloses a memory testing method, apparatus, and vehicle. The method includes: sending a first write instruction containing a target data identifier (DID) and first test data to an electronic control unit (ECU), causing the ECU to store the first test data into a target memory unit; sending an ECU reset instruction to the ECU to restart the ECU; sending a first read instruction containing the target DID to the restarted ECU and receiving first read data returned by the instruction; and, if the first read data matches the first test data, the memory passes a persistence test. According to embodiments of this application, the memory testing coverage can be made more comprehensive.

Description

Technical Field

[0001] This application belongs to the field of memory testing technology, and in particular relates to a memory testing method, apparatus and vehicle. Background Technology

[0002] In current automotive electronic systems, the ECU (Electronic Control Unit) typically uses its internal EEPROM (Electrically Erasable Programmable Read-Only Memory) to store crucial information such as the Vehicle Identification Number (VIN), system configuration parameters, and calibration data. To ensure proper vehicle functionality and stable production processes, testing the accuracy of this stored data is essential. Currently, the industry commonly employs a testing method based on the Unified Diagnostic Services (UDS) protocol. This involves sending write commands to the ECU via diagnostic tools (such as CANoe), followed by read commands, and then comparing the retrieved data with expected values ​​to verify whether the data has been correctly stored.

[0003] However, existing testing methods primarily focus on verifying whether data can be correctly written and immediately read in a "one-time power-on, continuous operation" scenario, i.e., only focusing on the correctness of "instant read / write." This method fails to adequately simulate critical states that vehicles frequently experience in actual operation, such as ECU software resets and vehicle power cycles (i.e., power-off and power-on). Due to the lack of systematic verification regarding whether data can still be intact after these state changes, existing technologies cannot ensure that data stored in EEPROM can be reliably and persistently maintained after the ECU experiences a restart or power failure, resulting in incomplete test coverage. Summary of the Invention

[0004] This application provides a memory testing method, apparatus, and vehicle that enable more comprehensive memory testing coverage.

[0005] On one hand, embodiments of this application provide a memory testing method, the method comprising: sending a first write instruction containing a target data identifier DID and first test data to an electronic control unit (ECU), so that the ECU stores the first test data into a target memory unit; Send an ECU reset command to the ECU to restart it; Send a first read command containing the target DID to the restarted ECU and receive the first read data returned by it; If the first read data matches the first test data, the memory passes the persistence test.

[0006] Among some possible implementations, the method also includes: Send a second write command containing the target DID and the second test data to the ECU, so that the ECU stores the second test data into the target storage unit, wherein the second test data is different from the first test data; Send a second read command containing the target DID to the ECU, and receive the second read data returned by it; If the second read data matches the second test data, the memory passes the overwrite test.

[0007] In some possible implementations, the method further includes, before sending an ECU reset command to the ECU to restart it: Send a third read command containing the target DID to the ECU and receive the third read data returned by it; If the third read data matches the first test data, an ECU reset command is sent to the ECU to restart it.

[0008] In some possible implementations, the first write command, the first read command, the ECU reset command, the second write command, the second read command, and the third read command are all sent by calling the ZCANPRO device's single-line application programming interface (API).

[0009] Among some possible implementations, the method also includes: Record the verification result of whether the first read data is consistent with the first test data; Based on the verification results recorded within the preset period, calculate the test failure rate corresponding to the target DID; If the test failure rate exceeds the first preset threshold, adjust the test parameters corresponding to the target DID; wherein the test parameters include at least one of the following: number of tests, first test data generation rule.

[0010] In some possible implementations, there are multiple target DIDs, including at least a first target DID and a second target DID. The method also includes: Send a first write command containing a first target DID and first test data to the ECU, and send a second write command containing a second target DID and third test data; Send a fourth read command containing the first target DID to the restarted ECU and receive the fourth read data returned by it; send a fifth read command containing the second target DID and receive the fifth read data returned by it. If the fourth read data is consistent with the first test data, and the fifth read data is consistent with the third test data, it is determined that the data stored in the memory did not affect each other after the ECU was reset.

[0011] In some possible implementations, after sending a first write command containing a target data identifier (DID) and first test data to the electronic control unit (ECU) to cause the ECU to store the first test data into the target storage unit, the method further includes: Inject a preset interference signal into the ECU and delay it for a preset time; Send a sixth read command containing the target DID to the ECU and receive the sixth read data returned by it; If the sixth read data is consistent with the first test data, the memory is determined to have passed the test under interference signals.

[0012] Among some possible implementations, the method also includes: Record the sending and response status of each instruction during the execution of the method; Based on the sending and response status, determine the type of failure that caused the test to fail. The failure types include security access failure, communication failure, and data storage failure. Based on the fault type, output the specific fault location information and repair operation instructions corresponding to that type.

[0013] On the other hand, embodiments of this application provide a memory testing apparatus, the apparatus comprising: The first write module is used to send a first write command containing a target data identifier (DID) and first test data to the electronic control unit (ECU), so that the ECU stores the first test data into the target storage unit. The reset command module is used to send an ECU reset command to the ECU to restart the ECU; The first reading module is used to send a first reading command containing the target DID to the restarted ECU and receive the first reading data returned by it. The persistence verification module is used to determine if the memory passes the persistence test if the first read data is consistent with the first test data.

[0014] In another aspect, embodiments of this application provide a vehicle, which includes: a processor and a memory storing computer program instructions; the processor implements a memory testing method when executing the computer program instructions.

[0015] The memory testing method, apparatus, and vehicle of this application, through the ECU reset step, simulate the system restart scenario that inevitably occurs during actual vehicle operation, and can accurately verify the data retention capability of the target storage unit after a state change. When the first read data is consistent with the first test data, it can be confirmed that the memory has the persistence of data not being lost or tampered with after reset, effectively ensuring the storage reliability of the first test data in the ECU, thereby maintaining the normal functioning of the vehicle and making the memory testing coverage more comprehensive. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a schematic flowchart of a memory testing method provided in one embodiment of this application; Figure 2 This is a schematic flowchart of a memory testing method provided in another embodiment of this application; Figure 3 This is a schematic flowchart of a memory testing method provided in another embodiment of this application; Figure 4 This is a schematic flowchart of a memory testing method provided in another embodiment of this application; Figure 5 This is a schematic diagram of the structure of a memory testing device provided in another embodiment of this application; Figure 6 This is a structural schematic diagram of a vehicle provided in another embodiment of this application. Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

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

[0020] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0021] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0022] In automotive electronic systems, ECUs rely on EEPROMs to store critical data such as VINs and system configuration parameters. The reliability of this data storage directly impacts the effectiveness of vehicle functions and the stability of production line processes; therefore, related testing is a core requirement in vehicle production and verification. Existing testing methods based on the UDS protocol (such as those using CANoe) focus on "instant read / write verification," which involves sending a write command to the ECU followed immediately by a read command, comparing the consistency of the read and write data to complete the test. However, this approach has inherent limitations: it only simulates the ideal scenario of the ECU "working continuously with a single power-on," failing to fully consider the dynamic conditions that vehicles inevitably face during actual operation, such as ECU software resets and vehicle power cycles. Under these conditions, the EEPROM storage units may experience data loss or tampering due to voltage fluctuations, internal charge migration, and other factors. Consequently, existing testing methods fail to cover critical verification scenarios after ECU state changes, making it impossible to fully verify the persistence and reliability of EEPROM data storage. This makes it difficult to guarantee the stability of stored data under complex real-world conditions, resulting in incomplete test coverage and insufficient verification effectiveness.

[0023] The memory testing method in this application simulates a system restart scenario that inevitably occurs during actual vehicle operation through an ECU reset step, enabling accurate verification of the target storage unit's data retention capability after state changes. When the first read data matches the first test data, it can be confirmed that the memory possesses the persistence of data retention after reset, effectively ensuring the storage reliability of the first test data in the ECU, thereby maintaining normal vehicle function and making memory testing more comprehensive.

[0024] To address the problems of the prior art, embodiments of this application provide a memory testing method, apparatus, vehicle, computer storage medium, and computer program product. The memory testing method provided in this application embodiment will be described first below.

[0025] Figure 1 A schematic flowchart of a memory testing method provided in one embodiment of this application is shown. Figure 1 As shown, the method includes the following steps.

[0026] S101, a first write instruction containing a target data identifier (DID) and first test data is sent to the electronic control unit (ECU) so that the ECU stores the first test data into the target storage unit.

[0027] As an example, the target data identifier (DID) can be an identification information used to uniquely identify the stored data to be tested in the electronic control unit (ECU). Each identifier corresponds to a specific stored content in the ECU. For example, the identifier corresponding to vehicle identification code related data is 0xF190, and the identifier corresponding to system configuration parameters is 0xF101. Through this identifier, the storage location of the target stored data in the ECU can be accurately located.

[0028] As an example, the first test data can be the initial test data used to verify the storage function of the target storage unit. It can be set according to the storage content type corresponding to the target DID. For example, the target DID corresponding to the vehicle identification code can be set to contain vehicle identification code data with a specific byte sequence, and the target DID corresponding to the system configuration parameters can be set to parameter data that conforms to the configuration rules.

[0029] As an example, the first write instruction may be an instruction that conforms to the Unified Diagnostic Services (UDS) protocol, contains a target data identifier (DID) and first test data, and instructs the ECU to write the first test data to the target storage unit.

[0030] As an example, the target storage unit could be an electrically erasable programmable read-only memory (EEPROM) inside the ECU used to store critical data, such as vehicle identification numbers, system configuration words, and calibration data, which are essential to vehicle functions and production line processes.

[0031] Specifically, as an example, pre-test preparations can be performed first, such as obtaining CAN bus information through the ZCANPRO device, clarifying the source and destination addresses for communication, and completing UDS service initialization. Then, iterative test parameters can be set, and the test rounds and other information can be determined.

[0032] Specifically, as an example, the security unlocking process can then be executed. An extended session entry command is sent via the ZCANPRO device to put the ECU into an extended session, and a diagnostic session maintenance command is sent to maintain the session connection. Next, a security access request command is sent, the seed data returned by the ECU is received, the fixed security string is combined with the seed string and encoded in UTF-8, a security key is calculated using the SHA256 hash algorithm, and a security access key sending command containing this key is sent to the ECU, completing the security unlocking process.

[0033] Specifically, as an example, after successful security unlocking, the ZCANPRO device's application programming interface (API) generates a first write command. This command follows the UDS protocol and has a format of 2EF190 (corresponding to target DID 0xF190) or 2EF101 (corresponding to target DID 0xF101) followed by first test data. For example, for target DID 0xF190, the first write command would be 2EF190 followed by the first test data 48 4A 34 42 42 42 42 4B 58 534E 30 36 35 35 35 35. This first write command is sent to the ECU, which, upon receiving it, stores the first test data in the corresponding target storage unit, EEPROM.

[0034] S102, send an ECU reset command to the ECU to restart the ECU.

[0035] As an example, an ECU reset command can be an instruction that follows the Unified Diagnostic Services (UDS) protocol and is used to trigger the ECU to stop its current operation and perform a re-initialization operation.

[0036] As an example, an ECU restart can be the process by which the ECU receives a reset command, terminates the currently running program and process, completes system initialization, and restores normal working status. During the restart process, the temporary power supply to the target storage unit will be cut off to simulate the power cycle scenario in actual vehicle operation.

[0037] Specifically, as an example, after the first test data is written to the target storage unit in S101, a read command is first sent via the ZCANPRO device to verify that the first test data has been stored correctly and in real time. After confirming that there are no errors, an ECU reset command 1101 conforming to the UDS protocol is generated by calling the ZCANPRO device's application programming interface (API), and this command is sent to the ECU. After sending the command, the communication connection between the test system and the ECU is maintained, and the diagnostic session is kept active for a preset time to ensure that the ECU completely terminates the current workflow, completes system initialization, and restarts stably, avoiding the impact of incomplete restart on subsequent test results.

[0038] S103, send a first read command containing the target DID to the restarted ECU, and receive the first read data returned by it.

[0039] As an example, the first read instruction can be an instruction that follows the Unified Diagnostic Service (UDS) protocol and contains a target data identifier (DID), which requests the ECU to read and return the stored data corresponding to the identifier from the target storage unit. This instruction can be generated through the ZCANPRO device's application programming interface (API).

[0040] As an example, the first read data can be the data corresponding to the target DID read from the target storage unit by the ECU after receiving the first read command, and the response data returned to the test system via the CAN bus.

[0041] Specifically, as an example, after the ECU has restarted and is working stably, the security unlocking process can be re-executed through the ZCANPRO device. That is, the command 1003 is sent to make the ECU re-enter the extended session, send a security access request command to obtain the seed, calculate the key using the SHA256 hash algorithm, and send the security access key to complete the unlocking, ensuring that the test system has the permission to read the data of the target storage unit.

[0042] Specifically, as an example, a first read instruction can be generated by calling the ZCANPRO device's application programming interface (API). This instruction follows the UDS protocol and has a format of 22F190 (corresponding to target DID 0xF190) or 22F101 (corresponding to target DID 0xF101). This instruction is then sent to the ECU. After receiving the instruction, the ECU reads the stored data corresponding to the target DID from the target storage unit EEPROM, generates response information containing this data, and returns it to the test system. The test system receives this response information and extracts the valid data as the first read data. For example, if the received response is 62F190 48 4A 34 42 42 42 42 4B 58 53 4E 30 36 35 35 35 35, the subsequent byte sequence of 62F190 is extracted as the first read data.

[0043] S104, if the first read data is consistent with the first test data, the memory passes the persistence test.

[0044] As an example, a durability test can be a test to verify whether the data stored in the target storage unit EEPROM remains intact and consistent with the initially written test data after the ECU undergoes a restart operation. The core purpose is to verify the long-term reliability of the stored data after changes in system state.

[0045] Specifically, as an example, the testing system can compare the first read data obtained in S103 with the first test data sent in S101 byte by byte to check whether their byte sequences are completely identical. For example, if the first test data is 48 4A 34 42 42 42 42 4B 58 53 4E 30 36 35 35 35 35, and the first read data is the corresponding byte sequence extracted from the response, if there is no difference between the two, the comparison result is determined to be consistent.

[0046] Specifically, as an example, when the first read data is completely consistent with the first test data, it means that after the ECU restarts, the first test data stored in the target storage unit EEPROM has not been lost, tampered with, or corrupted, and the storage function of the target storage unit meets the persistence requirements. The memory is then determined to have passed the persistence test. If the two are inconsistent, it means that the stored data is abnormal after the ECU restarts, the memory fails the persistence test, and the test system records the failure result for subsequent analysis.

[0047] The memory testing method in this application simulates a system restart scenario that inevitably occurs during actual vehicle operation through an ECU reset step, enabling accurate verification of the target storage unit's data retention capability after state changes. When the first read data matches the first test data, it can be confirmed that the memory possesses the persistence of data retention after reset, effectively ensuring the storage reliability of the first test data in the ECU, thereby maintaining normal vehicle function and making memory testing more comprehensive.

[0048] As another implementation of this application, in order to make the verification of the memory storage function more comprehensive, such as Figure 2 As shown, the method may also include the following steps.

[0049] S201, a second write command containing the target DID and the second test data is sent to the ECU so that the ECU stores the second test data into the target storage unit, wherein the second test data is different from the first test data.

[0050] As an example, the second test data can be verification data with a different value from the first test data, set according to the storage type corresponding to the target DID, and used to verify the overwrite capability of the target storage unit.

[0051] As an example, the second write instruction can follow the UDS protocol and contain instructions for the target DID and the second test data, generated via the ZCANPRO device API, to instruct the ECU to overwrite the target memory with the second test data.

[0052] Specifically, as an example, after completing the first round of testing and ECU reset verification, the extended session remains active and the secure unlock state is maintained. A second write command is generated by calling the ZCANPRO device API. The command format is 2EF190 or 2EF101 plus the second test data. For example, the second test data corresponding to DID 0xF190 is 48 4A 3441 41 41 41 4B 58 53 4E 31 31 31 31 31 31 31. This command is sent to the ECU, which then overwrites the second test data and stores it in the corresponding target storage unit of the EEPROM.

[0053] S202, send a second read command containing the target DID to the ECU and receive the second read data returned by it.

[0054] As an example, the second read instruction could be an instruction that follows the UDS protocol, contains the target DID, and requests the ECU to read the overwritten second test data in the target memory cell.

[0055] As an example, the second read data can be the valid data extracted and returned from the target storage unit by the ECU after responding to the second read command, which is the core basis for verifying the overwrite effect.

[0056] Specifically, as an example, after the second write command is sent, a second read command is generated via the ZCANPRO device API, in the format 22F190 or 22F101, and sent to the ECU. After receiving the command, the ECU reads the corresponding data from the target storage unit and returns a response. The test system receives the response information, such as the byte sequence after 62F190 or 62F101, and extracts the valid data as the second read data.

[0057] S203, if the second read data is consistent with the second test data, the memory passes the overwrite test.

[0058] As an example, a write-overwrite test can be a test item to verify whether the target storage unit can completely overwrite the original first test data with new second test data and whether the stored data is accurate.

[0059] Specifically, as an example, the test system compares the second read data with the second test data byte by byte to check if their byte sequences are completely identical. This can be achieved by writing different DID data in multiple iterations to ensure that the new data overwrites the previous value. If the comparison results are consistent, it indicates that the overwrite function of the target storage unit is effective, the original data has been successfully replaced, and the memory has passed the overwrite test.

[0060] The memory testing method in this application adds a write-overwrite test process, from writing different second test data to reading and verifying, to specifically verify the write-overwrite function of the target memory unit. By writing second test data that is different from the first test data, it is possible to verify whether the memory unit has the ability to completely replace the old data with the new data, avoiding storage logic confusion caused by old data residue. When the second read data is consistent with the second test data, it can be confirmed that the write-overwrite function of the memory is effective, ensuring that in subsequent practical applications, new key data (such as updated configuration parameters) can successfully overwrite the original data, making the verification of the memory storage function more comprehensive and further improving the reliability of the storage system.

[0061] As another implementation of this application, in order to reduce the waste of test resources caused by initial write exceptions, the method may also include the following steps before S102.

[0062] Send a third read command containing the target DID to the ECU and receive the third read data returned by it.

[0063] As an example, the third read instruction can refer to an instruction that follows the UDS protocol, contains the target DID, is generated through the ZCANPRO device API, and is used to verify the correctness of the first test data being written to the target storage unit immediately.

[0064] As an example, the third read data can refer to the valid data that the ECU extracts and returns from the target storage unit after responding to the third read command. It is the core basis for confirming the validity of the first test data in real time storage.

[0065] Specifically, as an example, after the first test data is written to the target storage unit via the second write command, the extended session activation and security unlock status of the ECU remain valid. A third read command is generated by calling the ZCANPRO device's API, with the command format being 22F190 or 22F101, corresponding to the target DID 0xF190 or 0xF101. After sending the command to the ECU, the response information returned by the ECU, such as the byte sequence after 62F190 or 62F101, is received. The valid data within is extracted as the third read data, preparing for subsequent data comparison.

[0066] If the third read data matches the first test data, an ECU reset command is sent to the ECU to restart it.

[0067] Specifically, as an example, the test system can compare the third read data byte-by-byte with the first test data to ensure that their byte sequences are completely identical, verifying that the first test data has been stored correctly in real time. After the comparison is successful, an ECU reset command conforming to the UDS protocol is generated by calling the API of the ZCANPRO device and sent to the ECU. After sending the command, the communication connection between the test system and the ECU is maintained, waiting for a preset time and keeping the diagnostic session active to ensure that the ECU completely terminates the current workflow, completes system initialization, and restarts stably, laying the foundation for subsequent verification of data persistence after reset.

[0068] The memory testing method of this application adds a third read instruction and data comparison step before ECU reset, forming a rigorous process from writing data to immediate read verification to reset to secondary verification. Through immediate read verification before reset, it can be confirmed that the first test data has been accurately written to the target memory unit, eliminating misjudgments in subsequent reset verification caused by immediate write failure. The reset operation is only performed if the third read data matches the first test data, ensuring that subsequent persistence verification is based on validly written data, avoiding invalid testing processes, improving the accuracy and reliability of test results, and making the testing process more logical and rigorous, reducing the waste of test resources caused by initial write anomalies.

[0069] As another implementation of this application, the first write instruction, the first read instruction, the ECU reset instruction, the second write instruction, the second read instruction, and the third read instruction are all sent by calling the single-line application programming interface (API) of the ZCANPRO device.

[0070] As an example, a single-line application programming interface (API) can be a simplified programming interface provided by ZCANPRO devices, which can implement specific functions through a single instruction call without the need for complex code writing, and is used to quickly generate and send test instructions that conform to the UDS protocol.

[0071] Specifically, as an example, after initialization and security unlocking are completed, a single call command is written based on the ZCANPRO device's single-line application programming interface (API) to integrate the target DID (such as 0xF190, 0xF101) and the first test data. The combined first write command is then sent directly through this API, eliminating the need for manual CAN frame assembly. The command is transmitted to the ECU via the CAN bus, triggering the ECU to execute the data write operation. Compared to traditional solutions, this simplifies the operation process and improves transmission efficiency.

[0072] The memory testing method in this application specifies that all test commands are sent by calling the single-line application programming interface (API) of the ZCANPRO device. Compared with the traditional manual assembly of CAN frames, this significantly simplifies the command sending process and reduces the complexity of the test operation. The single-line API of the ZCANPRO device has convenient calling characteristics, requiring no complex code writing or multi-step configuration. It can quickly generate and send test commands conforming to the UDS protocol, greatly improving testing efficiency and supporting large-scale automated testing. This solves the problems of long testing cycles and inability to scale up traditional manual operations. At the same time, the unified API calling method ensures the consistency and stability of command sending, reduces errors caused by manual operation, and balances low cost and high reliability in testing.

[0073] As another implementation of this application, to avoid overlooking occasional storage exceptions, such as Figure 3 As shown, the method may also include the following steps.

[0074] S301, record the verification result of whether the first read data and the first test data are consistent.

[0075] As an example, the verification result can be the conclusion drawn from comparing the first read data and the first test data byte by byte, which is used to identify the persistence status of the data in the target storage unit after the ECU is reset, including two cases: data consistency and data inconsistency.

[0076] Specifically, as an example, after a single iteration of persistence testing is completed, the testing system automatically records the verification results. This record can be associated with the target DID (Distributed ID) to identify the test round and iteration number. For example, for target DID 0xF190 or 0xF101, the system records the comparison result between the first read data and the first test data in each iteration. The recorded content is synchronously incorporated into the testing system's database, forming a traceable verification archive, replacing traditional manual recording methods and improving the accuracy and systematic nature of the records.

[0077] S302, based on the verification results recorded within a preset period, calculate the test failure rate corresponding to the target DID.

[0078] As an example, the preset period can be a pre-defined time interval or iteration interval for statistical testing failure rate, which can be flexibly configured according to testing needs.

[0079] As an example, the test failure rate can be the ratio of the number of test failures of the target DID to the total number of tests within a preset period, used to quantify the reliability of the storage function corresponding to the target DID.

[0080] Specifically, as an example, the preset period can be set to a fixed number of iterations, such as 500 iterations per period. The testing system extracts all verification results of the target DID within that period from the database, counts the number of inconsistent failures, and calculates the test failure rate by dividing the number of failures by the total number of tests. This process is fully automated, solving the problem of low efficiency in traditional manual statistical observation and ensuring the accuracy of the statistical results.

[0081] S303, if the test failure rate exceeds the first preset threshold, adjust the test parameters corresponding to the target DID; wherein, the test parameters include at least one of the following: number of tests, first test data generation rule.

[0082] As an example, the first preset threshold can be a pre-set critical value for determining whether the target DID storage function needs to be optimized for testing, which is used to trigger the test parameter adjustment mechanism.

[0083] As an example, test parameters can be configurable items that affect the testing process, including the number of tests and the rules for generating the first test data, which can be dynamically adjusted based on the test results.

[0084] As an example, the first test data generation rule can be the setting logic for generating the first test data, including specifications such as the data byte length and numerical range.

[0085] Specifically, as an example, a first preset threshold can be set. When the statistical test failure rate exceeds this threshold, the testing system automatically adjusts the test parameters corresponding to the target DID. If the target DID frequently fails, the number of tests can be increased, extending the iteration cycle to over 3000 times; or the first test data generation rules can be adjusted to expand the numerical coverage and increase data complexity. By dynamically adjusting, problem-oriented testing can be achieved, improving the ability to discover defects in the target DID's storage function and ensuring sufficient test coverage.

[0086] The memory testing method of this application achieves adaptive test optimization through a closed-loop mechanism from recording verification results to calculating failure rates to dynamically adjusting test parameters. By recording the verification results of the first read data and the first test data, test process data can be systematically retained, replacing the inefficient method of traditional visual observation and statistics. Based on the verification results within a preset period, the test failure rate of the target DID can be calculated, quantifying the reliability of the storage function. When the failure rate exceeds a first preset threshold, by adjusting the number of tests or the first test data generation rules, the test can be strengthened for the target DID with frequent failures, realizing "problem-oriented" testing. This mechanism can accurately uncover potential defects in the target storage unit, extend the depth and breadth of test coverage, effectively verify the long-term storage reliability of EEPROM, and avoid missing occasional storage anomalies.

[0087] As another implementation of this application, in order to adapt to the actual application scenario of ECU multi-data storage, there are multiple target DIDs, and the target DIDs include at least a first target DID and a second target DID. The method may also include the following steps.

[0088] Send a first write command containing a first target DID and first test data to the ECU, and send a second write command containing a second target DID and third test data.

[0089] As an example, the first target DID can be identification information used to uniquely identify the first type of key stored data in the ECU, corresponding to a specific storage location in the EEPROM, such as the identifier corresponding to the vehicle identification code-related stored data.

[0090] As an example, the second target DID is a unique identifier that differs from the first target DID and is used to locate the second type of critical stored data in the ECU, such as the identifier corresponding to system configuration parameters.

[0091] As an example, the third test data could be verification data adapted to the second target DID storage type, following a different storage specification than the first test data, used to verify the storage validity of the second type of storage data.

[0092] As an example, the second write instruction could be an instruction that follows the UDS protocol, contains a second target DID and third test data, and is generated via the ZCANPRO device API to instruct the ECU to store the third test data.

[0093] Specifically, as an example, the ZCANPRO device API can be called to generate a first write command and a second write command, with the command formats being 2EF190 plus first test data and 2EF101 plus third test data, respectively. The two commands are then sent sequentially via the CAN bus. After receiving them, the ECU stores the first and third test data into the corresponding EEPROM storage locations of the target DID.

[0094] Send a fourth read command containing the first target DID to the restarted ECU and receive the fourth read data returned by it, and send a fifth read command containing the second target DID and receive the fifth read data returned by it.

[0095] As an example, the fourth read instruction could be an instruction generated via the ZCANPRO device API that conforms to the UDS protocol, contains the first target DID, and is used to request the reading of the stored data corresponding to the first target DID after the ECU reset.

[0096] As an example, the fifth read instruction could be an instruction generated via the ZCANPRO device API that follows the UDS protocol, contains the second target DID, and is used to request the reading of the stored data corresponding to the second target DID after the ECU reset.

[0097] As an example, the fourth read data can be valid data that the ECU extracts and returns from the storage location corresponding to the first target DID after responding to the fourth read command.

[0098] As an example, the fifth read data can be valid data that the ECU retrieves and returns from the storage location corresponding to the second target DID after responding to the fifth read command.

[0099] Specifically, as an example, after the ECU receives the reset command and restarts, it waits for a preset time and maintains the diagnostic session activation state to ensure stability. It then resends the command to enter the extended session and repeats the security unlocking process to obtain operating permissions. The ZCANPRO device API is called to generate the fourth and fifth read commands, with formats 22F190 and 22F101 respectively, and these are sent to the ECU sequentially. The test system receives the response information returned by the ECU, extracts the byte sequence after 62F190 as the fourth read data, and extracts the byte sequence after 62F101 as the fifth read data, preparing for subsequent comparison.

[0100] If the fourth read data is consistent with the first test data, and the fifth read data is consistent with the third test data, it is determined that the data stored in the memory did not affect each other after the ECU was reset.

[0101] As an example, the judgment criteria are: based on the consistency between the fourth read data and the first test data, and the consistency between the fifth read data and the third test data, the judgment criteria are used to confirm that the stored data corresponding to multiple target DIDs do not interfere with each other after the ECU is reset.

[0102] Specifically, as an example, the byte sequences of the fourth read data and the first test data can be compared first, and then the byte sequences of the fifth read data and the third test data can be compared. If the two sets of comparison results are completely consistent, it indicates that the stored data corresponding to the two target DIDs remains accurate before and after the ECU reset, and there is no data misalignment or mutual overwriting, which meets the requirements for verifying the consistency of the storage logic of different DIDs. Based on this, it can be determined that the data stored in the memory does not affect each other after the ECU reset.

[0103] The memory testing method in this application constructs a multi-DID concurrent verification mechanism for storage scenarios with multiple target DIDs. By simultaneously writing the first test data corresponding to the first target DID and the third test data corresponding to the second target DID, and then reading and comparing them after restarting, it can accurately determine whether the stored data corresponding to multiple DIDs affect each other. In practical applications, the ECU's EEPROM needs to store multiple key data (such as VIN and configuration words) simultaneously. This method can verify whether these data have mutual interference problems such as misalignment or overwriting during storage and reset, ensuring the storage independence and logical consistency of different types of key data. It fills the gap in traditional single DID testing, which cannot verify the compatibility of multi-data storage, adapts to the actual application scenario of ECU multi-data storage, and further improves the overall reliability of the storage system.

[0104] As another implementation of this application, in order to ensure the reliability of data storage during vehicle operation, such as Figure 4 As shown, after S101, the method may further include the following steps.

[0105] S401, injects a preset interference signal into the ECU and delays it for a preset time.

[0106] As an example, interference signals can simulate non-ideal operating conditions that may occur in actual vehicle operation, including abnormal power outages and voltage fluctuations, to verify the storage stability of the memory in complex environments.

[0107] As an example, the preset time can be a pre-defined time interval for the ECU to stabilize after the interference signal is injected, in order to ensure that the interference signal has a sufficient effect on the ECU.

[0108] Specifically, as an example, after the first test data is written to the target storage unit and verified instantly, the ECU's extended session and secure unlock state are maintained. Injecting interference signals into the ECU through the test system can simulate abnormal power outages due to random power disconnections or voltage fluctuations. After injecting the interference signal, following standard test waiting configurations, a preset time of 2-3 seconds is set to allow the ECU to stabilize under the interference environment, providing conditions for subsequent data reading and verification.

[0109] S402, sends a sixth read command containing the target DID to the ECU and receives the sixth read data returned by it.

[0110] As an example, the sixth read instruction could be an instruction that follows the UDS protocol, contains the target DID, and is generated via the ZCANPRO device API to read data from the target storage unit after interference signals have been applied.

[0111] As an example, the sixth read data can be valid data that the ECU retrieves from the target storage unit and returns after responding to the sixth read command.

[0112] Specifically, as an example, after the preset time has elapsed, the communication connection between the test system and the ECU is maintained. The ZCANPRO device's API is called to generate a sixth read command, with the command format being 22F190 or 22F101, corresponding to the target DID 0xF190 or 0xF101. After the command is sent to the ECU, the response information returned by the ECU is received, such as the byte sequence after 62F190 or 62F101. The valid data is extracted from this sequence as the sixth read data, ensuring that the data extraction process is consistent with the standard procedure for DID data reading.

[0113] S403, if the sixth read data is consistent with the first test data, it is determined that the memory has passed the test under interference signal.

[0114] As an example, passing the test under interference signals can refer to the test conclusion that the first test data stored in the target storage unit remains complete and accurate after being subjected to a preset interference signal, thus determining that the memory has the ability to resist interference storage.

[0115] Specifically, as an example, storage reliability can be ensured through multiple rounds of data verification. Continuing with this core logic, if the comparison results are completely consistent, it means that the interference signal has not caused the storage data to be lost, tampered with, or corrupted. The memory can still maintain data integrity under non-ideal operating conditions, and the memory is judged to have passed the test under interference signals.

[0116] The memory testing method in this application simulates non-ideal operating conditions (such as abnormal power outages and voltage fluctuations) that may occur in actual vehicle operation by injecting a preset interference signal and delaying for a preset time, thus constructing a specific verification scenario for the memory's anti-interference capability. Introducing the interference signal after writing the first test data allows for the verification of the data storage stability of the target storage unit in complex environments, avoiding anti-interference defects that cannot be exposed by traditional ideal operating condition tests. When the sixth read data is consistent with the first test data, it can be confirmed that the memory can still maintain data integrity under the influence of the interference signal, ensuring that the storage of critical data by the ECU is not affected by external interference in the complex operating environment of the vehicle. This improves the memory's ability to adapt to actual application scenarios and further guarantees the reliability of data storage during vehicle operation.

[0117] As another implementation of this application, in order to improve the maintainability and consistency of testing, the method may also include the following steps.

[0118] Record the sending and response status of each instruction during the execution of the method.

[0119] As an example, the transmission status can refer to the transmission status after the test command is sent from the ZCANPRO device, reflecting whether the command has been successfully transmitted to the CAN bus.

[0120] As an example, response status can refer to the feedback information returned by the ECU after receiving a command, including the timeliness, completeness, and validity of the feedback.

[0121] Specifically, as an example, after the test system starts, the status recording function is simultaneously activated, recording relevant information for each instruction in real time according to the iteration round. For extended session instructions, seed request instructions, key sending instructions, write instructions, read instructions, reset instructions, etc., the instruction sending time and whether it was successfully sent are recorded. At the same time, the ECU's response time, response code, and response data are recorded, such as whether a seed response starting with 6701 (response code for seed request instruction) is received after sending 2701 (seed request sub-function instruction code), and whether a response starting with 6702 (response code for key sending instruction) is received after sending 2702 (key sending sub-function instruction code). All records are stored in a classified manner according to instruction type and test stage, forming a systematic archive, replacing traditional manual observation and recording.

[0122] Based on the sending and response status, determine the type of fault that caused the test to fail. Fault types include security access failure, communication failure, and data storage failure.

[0123] As an example, a security access failure can refer to a malfunction in the security unlocking process where abnormal command interaction results in the ECU not granting advanced operating privileges.

[0124] As an example, a communication failure can refer to a fault in which abnormal data transmission during command transmission or ECU response leads to an interruption of interaction.

[0125] As an example, data storage failure can refer to a discrepancy between the written and read data, reflecting a malfunction in the target storage unit's storage function.

[0126] Specifically, as an example, if no seed response is received after sending 2701, or no response is received after sending 2702, the security access is deemed to have failed; if there is no response after the command is sent, the response code is invalid, or the bus transmission reports an error, the communication is deemed to have failed; if the data returned by the read command is inconsistent with the written test data, the data storage is deemed to have failed. The entire process is based on the status information recorded by the system to avoid errors in manual judgment.

[0127] Output specific fault location information corresponding to the fault type and repair operation guidelines.

[0128] As an example, the fault location information can refer to information that clearly indicates the specific link where the fault occurs, related instructions, and the core cause.

[0129] As an example, the repair operation guidelines can refer to executable troubleshooting steps given for the fault cause.

[0130] Specifically, as an example, for a security access failure, the location information is that the security constants do not match or there is an algorithm calculation error, and the repair guideline is to check the consistency of the security constants between the test system and the ECU, and check the algorithm coding and hash calculation process; for a communication failure, the location information is that the bus parameter configuration is incorrect or the physical connection is abnormal, and the repair guideline is to check the bus ID device type channel information and check the CAN bus wiring and communication load; for a data storage failure, the location information is that the DID identification is incorrect or the EEPROM storage unit is abnormal, and the repair guideline is to verify the correctness of the target DID, detect the performance of the EEPROM storage block, and ensure consistency with the test process and hardware configuration requirements.

[0131] The memory test method of the embodiment of the present application realizes full-process data traceability of the test process by recording the instruction sending status and the response status, replacing the disadvantage of the traditional test lacking systematic recording. Based on the recorded status information, it can accurately distinguish three types of fault types: security access failure, communication failure, and data storage failure, avoiding the blindness of fault location; outputting corresponding fault location information and repair operation guidelines for different fault types can quickly lock the problem links (such as security key calculation error, CAN bus connection abnormality, EEPROM storage block damage, etc.), and provide executable troubleshooting solutions, greatly improving the fault troubleshooting efficiency and reducing the test interruption time. It enables the test process to have a complete problem closed-loop processing ability, improves the maintainability and coherence of the test, and at the same time forms a systematic fault file, providing data support for subsequent test optimization and storage system improvement.

[0132] Based on the memory test method provided in the above embodiment, correspondingly, the present application also provides a specific implementation manner of a memory test device. Please refer to the following embodiments.

[0133] First refer to Figure 5 , the memory test device 50 provided by the embodiment of the present application includes the following modules: The first writing module 501 is used to send a first writing instruction including a target data identifier DID and first test data to an electronic control unit ECU, so that the ECU stores the first test data in a target storage unit; The reset command module 502 is used to send an ECU reset command to the ECU to restart the ECU; The first reading module 503 is used to send a first reading command containing the target DID to the restarted ECU and receive the first reading data returned by it; The persistence verification module 504 is used to determine that the memory passes the persistence test if the first read data is consistent with the first test data.

[0134] In some embodiments, the memory testing apparatus 50 may further include the following modules: The second write module is used to send a second write command containing the target DID and the second test data to the ECU, so that the ECU stores the second test data into the target storage unit, wherein the second test data is different from the first test data; The second reading module is used to send a second reading command containing the target DID to the ECU and receive the second reading data returned by it; The coverage verification module is used to determine whether the memory has passed the coverage write test if the second read data is consistent with the second test data.

[0135] In some embodiments, the memory testing apparatus 50 may further include the following modules: The third read module is used to send a third read command containing the target DID to the ECU before sending the ECU reset command to restart the ECU, and to receive the third read data returned by the ECU. The reset trigger module is used to send an ECU reset command to the ECU to restart the ECU when the third read data is consistent with the first test data.

[0136] In some embodiments, the memory testing apparatus 50 may further include the following modules: The first write module, the first read module, the reset command module, the second write module, the second read module, and the third read module are all used to send corresponding commands by calling the single-line application programming interface (API) of the ZCANPRO device.

[0137] In some embodiments, the memory testing apparatus 50 may further include the following modules: The result recording module is used to record the verification result of whether the first read data is consistent with the first test data; The failure rate statistics module is used to calculate the test failure rate corresponding to the target DID based on the verification results recorded within a preset period. The parameter adjustment module is used to adjust the test parameters corresponding to the target DID when the test failure rate exceeds a first preset threshold; wherein the test parameters include at least one of the following: number of tests and first test data generation rules.

[0138] In some embodiments, there are multiple target DIDs, and the target DIDs include at least a first target DID and a second target DID. The memory testing apparatus 50 may further include the following modules: The multi-DID writing module is used to send a first write command containing a first target DID and first test data to the ECU, and to send a second write command containing a second target DID and third test data; The multi-DID reading module is used to send a fourth read command containing the first target DID to the restarted ECU and receive the fourth read data returned by it, and to send a fifth read command containing the second target DID and receive the fifth read data returned by it; The mutual influence verification module is used to determine that the data stored in the memory did not affect each other after the ECU was reset, provided that the fourth read data is consistent with the first test data and the fifth read data is consistent with the third test data.

[0139] In some embodiments, the memory testing apparatus 50 may further include the following modules: An interference injection module is used to inject a preset interference signal into the electronic control unit (ECU) and delay it for a preset time after sending a first write command containing a target data identifier (DID) and first test data to the ECU to cause the ECU to store the first test data into the target storage unit. The sixth read module is used to send a sixth read command containing the target DID to the ECU and receive the sixth read data returned by it. The anti-interference verification module is used to determine whether the memory passes the test under interference signals if the sixth read data is consistent with the first test data.

[0140] In some embodiments, the memory testing apparatus 50 may further include the following modules: The status recording module is used to record the sending and response status of each instruction during the execution of the device; The fault type determination module is used to determine the fault type that caused the test to fail based on the sending status and response status. Fault types include security access failure, communication failure, and data storage failure. The fault handling module is used to output specific fault location information and repair operation instructions corresponding to the fault type.

[0141] Figure 6 A schematic diagram of the hardware structure of the vehicle provided in an embodiment of this application is shown.

[0142] The vehicle may include a processor 601 and a memory 602 storing computer program instructions.

[0143] Specifically, the processor 601 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0144] Memory 602 may include mass storage for data or instructions. For example, and not limitingly, memory 602 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 602 may include removable or non-removable (or fixed) media. Where appropriate, memory 602 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 602 is non-volatile solid-state memory.

[0145] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0146] The processor 601 implements any of the memory testing methods described in the above embodiments by reading and executing computer program instructions stored in the memory 602.

[0147] In one example, the vehicle may also include a communication interface 603 and a bus 610. Wherein, as... Figure 6 As shown, the processor 601, memory 602, and communication interface 603 are connected through bus 610 and complete communication with each other.

[0148] The communication interface 603 is mainly used to realize communication between various modules, devices, units and / or vehicles in the embodiments of this application.

[0149] Bus 610 includes hardware, software, or both, that couples vehicle components together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 610 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, this application contemplates any suitable bus or interconnect.

[0150] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0151] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0152] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0153] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0154] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A memory testing method, characterized in that, include: Send a first write instruction containing a target data identifier (DID) and first test data to the electronic control unit (ECU) so that the ECU stores the first test data into the target storage unit. Send an ECU reset command to the ECU to restart the ECU; Send a first read command containing the target DID to the restarted ECU, and receive the first read data returned by it; If the first read data matches the first test data, the memory passes the persistence test.

2. The method according to claim 1, characterized in that, The method further includes: A second write instruction containing the target DID and second test data is sent to the ECU, so that the ECU stores the second test data into the target storage unit, wherein the second test data is different from the first test data; Send a second read command containing the target DID to the ECU, and receive the second read data returned by it; If the second read data matches the second test data, the memory passes the overwrite test.

3. The method according to claim 1, characterized in that, Before sending an ECU reset command to the ECU to restart the ECU, the method further includes: Send a third read command containing the target DID to the ECU and receive the third read data returned by it; If the third read data matches the first test data, the ECU reset command is sent to the ECU to restart the ECU.

4. The method according to claim 1, characterized in that, The first write command, the first read command, the ECU reset command, the second write command, the second read command, and the third read command are all sent by calling the ZCANPRO device's single-line application programming interface (API).

5. The method according to claim 1, characterized in that, The method further includes: Record the verification result of whether the first read data is consistent with the first test data; Based on the verification results recorded within a preset period, the test failure rate corresponding to the target DID is calculated. If the test failure rate exceeds a first preset threshold, the test parameters corresponding to the target DID are adjusted; wherein, the test parameters include at least one of the following: number of tests, first test data generation rule.

6. The method according to claim 1, characterized in that, The target DID is multiple, and the target DID includes at least a first target DID and a second target DID. The method further includes: Send a first write command containing the first target DID and the first test data to the ECU, and send a second write command containing the second target DID and the third test data; Send a fourth read command containing the first target DID to the restarted ECU and receive the fourth read data returned by it; send a fifth read command containing the second target DID and receive the fifth read data returned by it. If the fourth read data is consistent with the first test data, and the fifth read data is consistent with the third test data, it is determined that the data stored in the memory do not affect each other after the ECU is reset.

7. The method according to claim 1, characterized in that, After sending a first write instruction containing a target data identifier (DID) and first test data to the electronic control unit (ECU) to cause the ECU to store the first test data into the target storage unit, the method further includes: Inject a preset interference signal into the ECU and delay it for a preset time; Send a sixth read command containing the target DID to the ECU and receive the sixth read data returned by it; If the sixth read data is consistent with the first test data, the memory is determined to have passed the test under the interference signal.

8. The method according to any one of claims 1-7, characterized in that, The method further includes: Record the sending and response status of each instruction during the execution of the method; Based on the sending and response status, determine the type of fault that caused the test to fail. The fault types include security access failure, communication failure, and data storage failure. Based on the fault type, output the specific fault location information and repair operation instructions corresponding to that type.

9. A memory testing device, characterized in that, The device includes: The first write module is used to send a first write instruction containing a target data identifier (DID) and first test data to the electronic control unit (ECU), so that the ECU stores the first test data into the target storage unit. A reset command module is used to send an ECU reset command to the ECU to restart the ECU; The first reading module is used to send a first reading command containing the target DID to the restarted ECU and receive the first reading data returned by it; The persistence verification module is used to determine that the memory passes the persistence test if the first read data is consistent with the first test data.

10. A vehicle, characterized in that, The vehicle includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the memory testing method as described in any one of claims 1-9.

Images