FOTA upgrading method and system capable of configuring upgrading strategy, terminal and medium

Abstract

The invention relates to an FOTA upgrading method and system capable of configuring an upgrading strategy, a terminal and a medium, and belongs to the technical field of ECU upgrading. The method comprises the steps that format data composed of multiple rows of records are obtained, the first row of records are read and analyzed, a structural body is configured, and the records comprise the Z0 record, the Z1 record, the Z2 record,..., the Zn record; reading the next row of records in the format data, judging the type of the records, executing a corresponding refreshing control process according to the type of the records, repeating the steps until the next row of records is judged to be Zn records after refreshing succeeds, analyzing the Zn records, ending refreshing, and completing ECU upgrading. When different ECUs are upgraded, the ECU software flashing function of different flashing processes can be achieved by loading the format data, T-BOX software does not need to be changed, the software quality can be guaranteed while the software development workload is reduced, and the customer experience is optimized.

Description

Technical Field

[0001] The present invention belongs to the technical field of ECU upgrade, and in particular relates to a FOTA upgrade method, system, terminal and medium with a configurable upgrade strategy. Background Art

[0002] With the widespread adoption of smart devices, FOTA (Firmware Over-The-Air) upgrade technology has become an integral part of device maintenance and updates. FOTA stands for Firmware Over-The-Air (FOTA). Most new energy vehicles now come standard with a T-BOX, which allows FOTA upgrades to other ECUs on the vehicle, eliminating the need for owners to visit a dealership for software upgrades. The T-BOX is the in-vehicle terminal, and the ECU is the controller node. Software upgrades can be implemented by remotely publishing upgrade packages, enabling ECU software feature updates or vulnerability fixes.

[0003] However, a prerequisite for successful FOTA upgrades is a unified flashing process for each ECU. Furthermore, since the security access algorithms for each ECU are already fixed on the T-BOX, different security access algorithms often need to be used to match them when upgrading different ECUs. Currently, most FOTA upgrades require a unified flashing process for each ECU software on the vehicle. Otherwise, the T-BOX would need to adapt the flashing logic for all ECUs simultaneously, which would require a significant adaptation workload, potentially requiring further adaptation for each vehicle model. This not only increases the software development workload, but also the testing workload, making software quality difficult to guarantee. Therefore, there is an urgent need to design a more flexible and efficient FOTA upgrade method to meet the growing demand for ECU upgrades. Summary of the Invention

[0004] The purpose of the present invention is to provide a FOTA upgrade method, system, terminal and medium with a configurable upgrade strategy in order to solve the above problems.

[0005] The present invention achieves the above-mentioned purpose through the following technical solutions:

[0006] The data refreshing method for ECU upgrade includes the following steps:

[0007] Obtain format data consisting of multiple lines of records, read and parse the first line of records, and configure a corresponding structure. The records are divided into Z0 records, Z1 records, Z2 records, ..., Zn records;

[0008] Read the next row of records in the format data and determine the record type. Based on the record type, execute the corresponding refresh control process. After the refresh is successful, repeat the above steps until the next row of records is determined to be a Zn record. Parse the Zn record and end the refresh to complete the ECU upgrade.

[0009] As a further optimization solution of the present invention, when executing the refresh control process, if the refresh fails, the ECU upgrade is exited. The refresh failure conditions include negative response, timeout response, and the number of message sending times reaching a threshold.

[0010] As a further optimization solution of the present invention, before reading the next row of records in the format data and determining the record type, the method further includes:

[0011] When the definition is judged as "Z1 record", the Z1 control process is executed to conduct a dialogue without response request;

[0012] When the definition is judged as "Z2 record", the Z2 control process is executed to determine the response;

[0013] When the definition is judged as "Z3 record", the Z3 control flow is executed to request the seed and obtain the key;

[0014] When the definition is judged as "Z4 record", the Z4 control process is executed to send the key.

[0015] As a further optimization solution of the present invention, the Z3 record and the Z4 record share a variable group, and n>5.

[0016] As a further optimization solution of the present invention, the Z1 control process is as follows:

[0017] S211, parse the Z1 record and configure the Z1 structure;

[0018] S212, send a message to the ECU and wait for a response. When a response is received from the ECU within the specified time, enter S213;

[0019] S213, determine whether the ECU responds positively. If the ECU responds positively, the conversation ends and the next line of records is read; if the ECU responds negatively, exit the ECU upgrade;

[0020] In S212, if no response is received from the ECU within the specified time, the following analysis is performed:

[0021] If the conversation has not timed out, the message is sent again and waits for a response.

[0022] If the conversation reaches the timeout period, the ECU upgrade will be exited.

[0023] As a further optimization solution of the present invention, the Z2 control process is as follows:

[0024] S221. Parse the Z2 record and configure the Z2 structure;

[0025] S222, send a message to the ECU and wait for a response. When a response is received from the ECU within the specified time, enter S223;

[0026] S223, determining whether a repeated request response is required. If a repeated request response is not required, determining whether the ECU responds positively. If the ECU responds positively, the conversation ends and the next line of records is read. If the ECU responds negatively, exiting the ECU upgrade.

[0027] In S222, if no response is received within the specified time, the following analysis is performed:

[0028] If the number of transmissions does not reach the threshold and the conversation time has not reached the timeout period, the message is sent again and waits for a response;

[0029] If the number of transmissions reaches the threshold or the conversation time reaches the timeout, the refresh fails and the ECU upgrade is exited;

[0030] In S223, when a repeated request response is required, the request is sent repeatedly and the ECU response and repeated response data are waited for, and the following analysis is performed:

[0031] If the conversation time has not reached the timeout period and the data is matched successfully, it is determined whether the request response needs to be repeated;

[0032] If the conversation time does not reach the timeout period and the data matching fails, it is judged that the ECU has a negative response and the ECU upgrade is exited;

[0033] If the conversation time reaches the timeout period, the ECU upgrade will be exited;

[0034] The difference between the Z3 control process and the Z2 control process is that if the ECU responds positively, when reading the next row of records, it extracts the data to calculate the key and stores the key in the shared variable group;

[0035] The difference between the Z4 control flow and the Z2 control flow is that when sending a message, the key in the shared variable group is sent.

[0036] The FOTA upgrade method with a configurable upgrade strategy includes the following steps:

[0037] Send the upgrade package and format data containing the upgrade strategy through the TCP network;

[0038] Obtain the upgrade package, and perform CAN communication with the ECU according to the data refresh method to refresh the ECU data to achieve FOTA upgrade.

[0039] A FOTA upgrade system with configurable upgrade strategies, including:

[0040] The cloud platform is used to send upgrade packages and formatted data containing upgrade policies to the T-BOX via the TCP network. The cloud platform supports remote wireless upgrades.

[0041] T-BOX is used to obtain the upgrade package and perform CAN communication with the ECU according to the data refresh method to refresh the ECU data;

[0042] The ECU is used to communicate with the T-BOX via CAN and refresh data to achieve FOTA upgrade of itself.

[0043] A terminal, comprising:

[0044] a processor configured to execute computer-executable instructions;

[0045] The memory stores one or more computer executable instructions, and when the computer executable instructions are executed by the processor, the various steps of the data refresh method are implemented.

[0046] A computer-readable storage medium stores a computer program thereon, wherein the computer program can be executed by a processor to implement each step of the data refreshing method.

[0047] The beneficial effects of the present invention are:

[0048] 1) This invention uses an intermediate refresh protocol solution for ECU upgrades, offloading some development work to the OTA platform or desktop application, reducing the difficulty and development cycle of T-BOX software. The T-BOX ECU refresh process is simplified to looping through the protocol dialogue described by format data until the refresh is complete. When upgrading different ECUs, the ECU software flash function with different flash processes can be implemented by simply loading the format data, without changing the T-BOX software. This reduces the software development workload while ensuring software quality and optimizing the customer experience.

[0049] 2) After parsing the Z0 record, the present invention continues to read the next line of records and executes the corresponding refresh control process according to the record type. The control process includes multiple ECU data flashing protocols such as repeated determination of response, requesting seeds and obtaining keys, and sending keys. When the current protocol can meet the FOTA upgrade, there is no need to define new rules, keeping the rules simple and reducing the complexity of the terminal code. For dialogues that cannot be defined by the current protocol, records can also be added to expand this protocol, making the FOTA upgrade method flexible and efficient. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] Figure 1 It is the overall flow chart of the present invention;

[0051] Figure 2This is a flow chart of record type determination and Z1 control of the present invention;

[0052] Figure 3 This is a flow chart of record type determination and Z2 control of the present invention;

[0053] Figure 4 This is a flow chart of record type determination and Z3 control of the present invention;

[0054] Figure 5 This is a flow chart of record type determination and Z4 control of the present invention;

[0055] Figure 6 It is the overall flow chart of the present invention;

[0056] Figure 7 It is a system block diagram of the present invention. DETAILED DESCRIPTION

[0057] The present application is described in further detail below in conjunction with the accompanying drawings. It is necessary to point out that the following specific implementation methods are only used to further illustrate the present application and cannot be understood as limiting the scope of protection of the present application. Technicians in this field can make some non-essential improvements and adjustments to the present application based on the above application content.

[0058] Example 1

[0059] like Figure 1 and Figure 6 As shown, this embodiment relates to a data refresh method for ECU upgrade, comprising the following steps:

[0060] In this embodiment, the format data and upgrade package are received by T-BOX, and the format data is a configuration file. After receiving the configuration file and the upgrade package, T-BOX splits the ECU upgrade package into several data packets according to the CAN communication protocol. The configuration file consists of multiple lines of records, which are divided into Z0 records, Z1 records, Z2 records, ..., Zn records. The record in the first line of the configuration file is the Z0 record. T-BOX first reads and parses the Z0 record and configures the Z0 structure. The above configuration file and upgrade package can be sent to T-BOX by the OTA cloud platform. In addition, in some other embodiments, the configuration file can also be manually adjusted and modified on the desktop through the application, and the upgrade package can also be obtained from local storage devices, vehicle diagnostic equipment and other devices.

[0061] T-BOX then reads and parses the remaining records in the configuration file line by line, executing the corresponding refresh control process according to the record type. In each refresh control process, T-BOX combines the metadata in the record with the data packet to form a structure corresponding to the record type. This structure is then sent to the ECU in the form of a message. Upon receiving the message, the ECU executes the corresponding flash process based on the message to implement the ECU upgrade. The ECU upgrade strategy is distributed within each structure.

[0062] The specific process of refreshing the above data is as follows:

[0063] Step S100: Send the configuration file to T-BOX. After receiving the configuration file, T-BOX reads the first row of records, which is the Z0 record, parses the Z0 record, and configures the Z0 structure.

[0064] It should be noted that the ECU in this embodiment does not include the vehicle's T-BOX node, and the Zn record is the Z9 record. Between the Z4 record and the Z9 record, the Z5 record, the Z6 record, the Z7 record, and the Z8 record can be extended to accommodate more ECU flashing protocols.

[0065] The Z0 record type is 0x5A30, and the address field is not used. The Z0 record is the first line of the configuration file and is used to store certain file description information. It contains no send data or checksum data. The Z0 record is primarily used for file initialization.

[0066] When the definition is judged as "Z1 record", the Z1 control process is executed to conduct a dialogue without response request;

[0067] When the definition is judged as "Z2 record", the Z2 control process is executed to determine the response;

[0068] When the definition is judged as "Z3 record", the Z3 control flow is executed to request the seed and obtain the key;

[0069] When the definition is judged as "Z4 record", the Z4 control process is executed to send the key.

[0070] In step S200, the T-BOX reads the next row of records in the Z-type data, determines the record type, and executes the corresponding refresh control process based on the record type. If the refresh is successful, the above steps are repeated until the next row of records is determined to be a Zn record. The record type is contained in the record. The types of the Z0 record, Z1 record, Z2 record, Z3 record, Z4 record, ..., Z9 record are 0x5A30, 0x5A31, 0x5A32, 0x5A33, 0x5A34, ..., 0x5A39, respectively. If the refresh fails during the refresh control process, the ECU upgrade is aborted. Refresh failures include negative responses, timeout responses, and reaching a threshold for message transmissions.

[0071] When it is determined that the record is a Z9 record, the Z9 record is parsed. The Z9 record is used to end the control process. After reading the Z9 record, the refresh is completed and the upgrade of the ECU is completed.

[0072] The refresh control process is divided into Z1 control process, Z2 control process, Z3 control process, Z4 control process, ..., Z9 control process. The specific control process is as follows Figure 2-6 As shown, Figure 2-5 The four processes Z1-Z4 are shown respectively. Figure 6 The overall control flow is shown. The refresh control flow is as follows:

[0073] 1) When the record is a Z1 record, T-BOX executes the Z1 control flow

[0074] The Z1 control flow is as follows:

[0075] S211, parse the Z1 record and configure the Z1 structure;

[0076] S212, send a message to the ECU and wait for a response. When a response is received from the ECU within the specified time, enter S213;

[0077] S213. Determine whether the response is positive. If the ECU responds positively, the conversation ends and the next line of records is read. If the ECU responds negatively, the ECU upgrade is exited. If the response is positive, it is determined to be a positive response. If the response is negative, it is determined to be a negative response.

[0078] In S212, if no response is received from the ECU within the specified time, the following analysis is performed:

[0079] If the conversation has not timed out, the message is sent again and waits for a response.

[0080] If the conversation reaches the timeout period, the ECU upgrade will be exited.

[0081] The above-mentioned timeout period is used to constrain the total time of each refresh control process. The specified time is the waiting time for each message transmission, and the specified time is less than the timeout period. In this embodiment, the timeout period is set to 5 seconds. In addition, in other embodiments, the length of the timeout period can also be adjusted according to actual needs. The timeout periods corresponding to different refresh control processes can also be set to different times. The specified time is the same as above and can also be adjusted according to actual needs.

[0082] The Z1 record type is 0x5A31. The address field contains only the sending address, with the receiving address padded with zeros. The control field contains the data transmission period, and the data transmission field contains the data length and the data to be sent. The Z1 record is primarily used to describe unresponsive request conversations.

[0083] 2) When the record is a Z2 record, T-BOX executes the Z2 control process

[0084] The Z2 control flow is as follows:

[0085] S221. T-BOX parses the Z2 record and configures the Z2 structure.

[0086] S222: T-BOX sends a message to the ECU via the CAN communication protocol and waits for a response. When a response is received from the ECU within the specified time, it proceeds to S223.

[0087] S223. After receiving the response from the ECU within the specified time, the T-BOX determines whether the request for response needs to be repeated. If the request for response does not need to be repeated, the T-BOX determines whether the ECU has a positive response. If the ECU has a positive response, the conversation ends and the next line of records is read. If the ECU has a negative response, the ECU upgrade is exited.

[0088] In S222, if no response is received from the ECU within the specified time, the following analysis is performed:

[0089] If the number of transmissions does not reach the threshold and the conversation time has not reached the timeout period, the T-BOX will send the message again and wait for a response;

[0090] If the number of transmissions reaches the threshold or the conversation time reaches the timeout period, the refresh fails and the ECU upgrade is exited.

[0091] In S223, when a repeated request response is required, the request is sent repeatedly and the ECU is waited for to respond and repeat the response data, and the following analysis is performed:

[0092] If the conversation time has not reached the timeout period and the data is matched successfully, it is determined whether the request response needs to be repeated;

[0093] If the conversation time does not reach the timeout period and the data matching fails, it is judged that the ECU has a negative response and the ECU upgrade is exited;

[0094] If the conversation time reaches the timeout period, the ECU upgrade will be exited.

[0095] It should be noted that a successful match refers to a match between the message sent by the T-BOX to the ECU and the repeated response data; a failed match refers to a mismatch between the message sent by the T-BOX to the ECU and the repeated response data. A successful match is a positive response, while a failed match is a negative response.

[0096] The Z2 record type is 0x5A32. The address field contains the CAN message send and receive addresses, the control field contains the CAN message send cycle and data receive time, the data send field contains the data length and send data, and the check data field contains the data length and comparison data. Z2 records are primarily used to describe confirm-response dialogues.

[0097] 3) When the record is a Z3 record, T-BOX executes the Z3 control process

[0098] The Z3 control flow differs from the Z2 control flow in that if the ECU responds positively, the key is calculated when the next row of records is read and stored in a shared variable group. T-BOX has a pre-established key algorithm library. In the Z3 control flow, after the ECU responds positively, the key is calculated based on the algorithm specified in the Z3 record. Other than these differences, the Z3 control flow is identical to the Z2 control flow and will not be further elaborated.

[0099] The Z3 record type is 0x5A33. The address field contains the CAN message send and receive addresses, with no data checksum. The control field contains the CAN message send cycle, data receive time, number of received data, and data parsing field. The data send field contains the data length and send data, and the data check field contains the data length and comparison data. Z3 records are primarily used to describe data request conversations, request seeds, and obtain keys.

[0100] 4) When the record is a Z4 record, T-BOX executes the Z4 control process to send the key

[0101] Z3 records and Z4 records share variable groups. The difference between the Z4 control flow and the Z2 control flow is that when sending a message, the key in the shared variable group is sent. Other than these differences, the Z4 control flow is identical to the Z2 control flow and will not be described in detail.

[0102] The Z4 record type is 0x5A34. The address field contains the CAN message send and receive addresses, with no data checksum. The control field contains the CAN message send cycle, data receive time, number of received data, and data parsing field. The data send field contains the data length and send data, and the data check field contains the data length and comparison data. The Z4 record is primarily used to describe real-time parameter delivery, including the transmission of keys.

[0103] 5) When the record is a Z9 record, T-BOX executes the Z9 control process

[0104] When executing the Z9 control process, the Z9 record is parsed, the refresh control process ends, and the FOTA upgrade of the ECU is completed.

[0105] The Z9 record type is 0x5A39, which is used to store certain file description information. It does not contain send data or check data, but contains file transfer end control and is mainly used for file end description.

[0106] In addition, based on the ECU upgrade requirements, Z5, Z6, Z7, and Z8 records can be added to the configuration file to extend the Z5, Z6, Z7, and Z8 control flows between the Z4 and Z9 control flows. Furthermore, in other embodiments, if the Z1-Z4 control flows can meet the ECU upgrade requirements, then n can be equal to 5, meaning the last record can be the Z5 record.

[0107] Example 2

[0108] This embodiment relates to a FOTA upgrade method with a configurable upgrade strategy, including the following steps:

[0109] Step 1: The OTA cloud platform sends the upgrade package and configuration file to T-BOX via the TCP network;

[0110] Step 2: T-BOX obtains the upgrade package and configuration file, and communicates with the ECU via CAN according to the data refresh method in the previous embodiment to refresh the ECU data to achieve FOTA upgrade.

[0111] Example 3

[0112] This embodiment relates to a FOTA upgrade system with configurable upgrade strategies, such as Figure 7 As shown in Figure 1, the FOTA upgrade system includes an OTA cloud platform, T-BOX, and several ECUs in the vehicle. The OTA cloud platform is a processing platform managed by the OEM and has functions such as online management and vehicle control.

[0113] When the T-BOX is offline, the OTA cloud platform can send text messages to the T-BOX to control it and push ECU upgrade packages and configuration files to the T-BOX through the TCP network.

[0114] After obtaining the upgrade package and configuration file, the T-BOX communicates with the ECU via CAN according to the data refresh method described in Example 1, refreshing the ECU's data. When upgrading an ECU, the T-BOX no longer cares about the specific ECU type and the flashing process; it only needs to load the configuration file, and the entire flashing process is completed based on the configuration file's protocol. During the FOTA upgrade process, the T-BOX splits the upgrade package into data packets according to the CAN communication protocol. The T-BOX parses the configuration file as described in Example 1, obtains the various structures described in Example 1, and sends these structures to the ECU via the CAN communication protocol in the form of messages. The ECU then performs a data refresh based on the received messages, completing the ECU upgrade.

[0115] Example 4

[0116] This embodiment relates to a terminal for FOTA (Function Over the Air) upgrades of ECUs. This terminal is the T-BOX described in Example 3, which includes a processor and a memory. The processor is configured to execute computer-executable instructions. The memory is used to store one or more computer-executable instructions. When executed by the processor, these computer-executable instructions implement the various steps of the data refresh method.

[0117] Example 5

[0118] This embodiment relates to a computer-readable storage medium having a computer program stored thereon. The computer program can be executed by a processor to implement the various steps of the data refresh method in Embodiment 1.

[0119] The above-described embodiments merely illustrate several implementations of the present invention. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that a person skilled in the art would be able to make numerous variations and improvements without departing from the spirit of the present invention, and all such variations and improvements fall within the scope of protection of the present invention.

Claims

1. A data refresh method for ECU upgrade, characterized in that: The following steps are involved: S100, obtaining format data consisting of multiple lines of records, reading and parsing the first line of records, and configuring a corresponding structure, wherein the records are divided into Z0 records, Z1 records, Z2 records, ..., Zn records; S200. Read the next row of records in the format data and determine the record type. Based on the record type, execute the corresponding refresh control process. After the refresh is successful, repeat the above steps until the next row of records is determined to be a Zn record. Parse the Zn record and end the refresh to complete the ECU upgrade.

2. The data refreshing method according to claim 1, wherein: When executing the refresh control process, if the refresh fails, the ECU upgrade will be exited. The refresh failure conditions include negative response, timeout response and the number of message sending times reaching the threshold.

3. The data refreshing method according to claim 1, wherein: Before reading the next row of records in the format data and determining the record type, the method further includes: When the definition is judged as "Z1 record", the Z1 control flow is executed to conduct a dialogue without response request; When the definition is judged as "Z2 record", the Z2 control process is executed to determine the response; When the definition is judged as "Z3 record", the Z3 control flow is executed to request the seed and obtain the key; When the definition is judged as "Z4 record", the Z4 control process is executed to send the key.

4. The data refreshing method according to claim 3, wherein: The Z3 record and the Z4 record share a variable group, n>5.

5. The data refreshing method according to claim 3, wherein: The Z1 control flow is as follows: S211, parse the Z1 record and configure the Z1 structure; S212, send a message to the ECU and wait for a response. When a response is received from the ECU within the specified time, enter S213; S213, determine whether the ECU responds positively. If the ECU responds positively, the conversation ends and the next line of records is read; if the ECU responds negatively, exit the ECU upgrade; In S212, if no response is received from the ECU within the specified time, the following analysis is performed: If the conversation has not timed out, the message is sent again and waits for a response. If the conversation reaches the timeout period, the ECU upgrade will be exited.

6. The data refreshing method according to claim 4, characterized in that: The Z2 control process is as follows: S221. Parse the Z2 record and configure the Z2 structure; S222, send a message to the ECU and wait for a response. When a response is received from the ECU within the specified time, enter S223; S223, determining whether a repeated request response is required. If a repeated request response is not required, determining whether the ECU responds positively. If the ECU responds positively, the conversation ends and the next line of records is read. If the ECU responds negatively, exiting the ECU upgrade. In S222, if no response is received within the specified time, the following analysis is performed: If the number of transmissions does not reach the threshold and the conversation time has not reached the timeout period, the message is sent again and waits for a response; If the number of transmissions reaches the threshold or the conversation time reaches the timeout, the refresh fails and the ECU upgrade is exited; In S223, when a repeated request response is required, the request is sent repeatedly and the ECU response and repeated response data are waited for, and the following analysis is performed: If the conversation time has not reached the timeout period and the data is matched successfully, it is determined whether the request response needs to be repeated; If the conversation time does not reach the timeout period and the data matching fails, it is judged that the ECU has a negative response and the ECU upgrade is exited; If the conversation time reaches the timeout period, the ECU upgrade will be exited; The difference between the Z3 control process and the Z2 control process is that if the ECU responds positively, when reading the next row of records, it extracts the data to calculate the key and stores the key in the shared variable group; The difference between the Z4 control flow and the Z2 control flow is that when sending a message, the key in the shared variable group is sent.

7. A FOTA upgrade method with a configurable upgrade strategy, characterized in that: The following steps are involved: Send the upgrade package and format data containing the upgrade strategy through the TCP network; Obtain the upgrade package, and perform CAN communication with the ECU according to the data refresh method described in any one of claims 1-6 to refresh the data of the ECU to achieve FOTA upgrade.

8. The FOTA upgrade system with configurable upgrade strategy is characterized by: include: The cloud platform is used to send the upgrade package and formatted data containing the upgrade policy to the T-BOX via the TCP network; The T-BOX is used to obtain the upgrade package and perform CAN communication with the ECU according to the data refresh method according to any one of claims 1 to 6 to refresh the data of the ECU; The ECU is used to communicate with the T-BOX via CAN and refresh data to achieve FOTA upgrade of itself.

9. A terminal, characterized in that The terminal includes: a processor configured to execute computer-executable instructions; A memory stores one or more computer-executable instructions, and when the computer-executable instructions are executed by the processor, the steps of the data refresh method according to any one of claims 1 to 6 are implemented.

10. A computer-readable storage medium, characterized in that: A computer program is stored thereon, and the computer program can be executed by a processor to implement each step of the data refreshing method according to any one of claims 1 to 6.

Images