On-demand triggered data updating method and device, electronic equipment and storage medium

Abstract

The invention relates to the technical field of on-demand triggered data updating, and discloses an on-demand triggered data updating method and device, electronic equipment and a storage medium, and the method comprises the following steps: receiving an operation instruction input by a user; obtaining a related module for executing the operation instruction; detecting whether a preset local to-be-updated area has a new version data packet corresponding to the related module or not; recording the related module with the new edition data packet as a related module; performing incremental merging updating based on the new-version data packet corresponding to the related module to generate a new-version module; and executing the operation instruction based on the new version module. The method has the beneficial effects that the continuity of user operation and the stability of system operation in the module updating process are ensured by pre-storing the new-version data packet in the local to-be-updated area, increment combination is executed to generate the new-version module, and then the user instruction is executed based on the new-version module, so that function updating can take effect immediately, and the user experience is improved. And thus, the user experience is greatly improved.

Description

Technical Field

[0001] This invention relates to the field of on-demand triggered data update technology, and in particular to an on-demand triggered data update method, apparatus, electronic device and storage medium. Background Technology

[0002] As automotive electronic control systems become increasingly complex, diagnostic equipment typically needs to support dozens or even hundreds of vehicle models and functional modules. Most existing update mechanisms use a full-package update approach, which requires downloading the complete new version file even if only minor changes are made to the module. For large modules or repair shops with limited network conditions, full updates are not only time-consuming but also consume a lot of bandwidth. If network fluctuations occur during the update process, the file needs to be downloaded again, resulting in a low success rate and impacting user operating efficiency.

[0003] To reduce bandwidth consumption, existing technologies often use a silent background update method, which directly replaces the module file after the update is completed. This can easily cause process interruption or abnormalities when the user is still operating the device. Summary of the Invention

[0004] Based on this, it is necessary to propose a method, device, electronic device and storage medium for on-demand data updates to address the existing problem of on-demand data updates.

[0005] A method for on-demand triggered data updates, the method comprising: Receive user input commands; The relevant modules for executing the operation instructions are obtained; The system detects whether a preset local update area contains the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; If the new data package is available, then an incremental merge update is performed based on the new data package corresponding to the relevant module to generate a new module. The operation instructions are executed based on the new module.

[0006] Furthermore, before the step of detecting whether the preset local area to be updated has the new version data packet corresponding to the relevant module, the method further includes: Receive an updated index table pushed by a cloud server; wherein the updated index table contains version information of each relevant module; Extract the local data index table and compare it with the updated index table to calculate the modules that need to be updated and the optimal update strategy; The new data package is downloaded based on the optimal update strategy and stored in the local area to be updated.

[0007] Furthermore, prior to the step of receiving the updated index table pushed by the cloud server, the method further includes: Read the user's diagnostic log file to obtain the user's vehicle operation information; Based on the vehicle operation information, analyze the time patterns of user operation on the device to determine the idle time periods of the client device; Set the receiving time for receiving updated index tables pushed by the cloud server according to the aforementioned idle time period.

[0008] Furthermore, after the step of incrementally merging and updating based on the new version data packet corresponding to the relevant module to generate a new version module if the new version data packet is available, the method further includes: Obtain the expected hash value and the corresponding preset hash algorithm carried in the new data packet; The new data packet is hashed based on the preset hash algorithm to obtain the hash value of the new module. Compare the calculated hash value with the expected hash value; The integrity of the new data packet is determined based on the comparison results.

[0009] Furthermore, after the step of determining the integrity of the new data packet based on the comparison results, the method further includes: If the calculated hash value is inconsistent with the expected hash value, the incremental merge update step is repeated to generate a new version of the module and perform integrity verification again. If the incremental merge update and integrity verification are repeated a preset number of times and the calculated hash value is still inconsistent with the expected hash value, further incremental merge update operations are terminated and the new version of the data packet is reported as unqualified.

[0010] Furthermore, the step of incrementally merging and updating based on the new version data packet corresponding to the relevant module to generate a new version module if the new version data packet exists includes: Parse the new data packet to obtain the change type of the relevant module and its target file path; Incremental merging and updating are performed based on the change type of the relevant modules and their target file paths to generate a new version of the modules.

[0011] Furthermore, the step of incrementally merging and updating the relevant modules based on their change types and target file paths to generate a new version of the modules includes: When the change type is modification, the patch file of the corresponding module is obtained from the new version data package, and a patching tool based on binary difference algorithm or unified difference format is used to apply the patch file to the local old version file according to the target file path to obtain the corresponding new version module; When the change type is replacement, delete the local old version target file according to the target file path, obtain the corresponding new file in the new version data package and copy it to the location of the target file to obtain the corresponding new version module; When the change type is "new", the new file in the new version data package is obtained and copied to the predetermined storage path of the local module according to the target file path to obtain the corresponding new version module.

[0012] An on-demand triggered data update device, the device comprising: The receiving module is used to receive operation commands input by the user; The acquisition module is used to acquire the relevant modules for executing the operation instructions; A detection module is used to detect whether a preset local update area has the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; An update module is used to perform incremental merging and updating based on the new version data packet corresponding to the relevant module if the new version data packet is available, so as to generate a new version module; An execution module is used to execute the operation instructions based on the new version of the module.

[0013] An electronic device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the following steps: Receive user input commands; The relevant modules for executing the operation instructions are obtained; The system detects whether a preset local update area contains the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; If the new data package is available, then an incremental merge update is performed based on the new data package corresponding to the relevant module to generate a new module. The operation instructions are executed based on the new module.

[0014] A computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the following steps: Receive user input commands; The relevant modules for executing the operation instructions are obtained; The system detects whether a preset local update area contains the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; If the new data package is available, then an incremental merge update is performed based on the new data package corresponding to the relevant module to generate a new module. The operation instructions are executed based on the new module.

[0015] The beneficial effects of this invention are as follows: By receiving user operation instructions, the system only updates the relevant modules involved in the instructions, avoiding the resource waste caused by blindly updating all modules in traditional solutions. This achieves accurate and necessary control of data updates. When a corresponding new data package exists in the local update area, the system performs incremental merging updates on the corresponding modules, making the update process more efficient and reducing the time and traffic consumption caused by downloading the full package. Since the new data package is pre-stored in the local update area and does not directly replace the modules currently in use, the continuity of user operations and the stability of system operation are ensured during the module update process. By performing incremental merging on relevant modules to generate new modules, and then executing user instructions based on the new modules, the function updates can take effect immediately, thereby greatly improving the user experience. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] in: Figure 1 This is an application environment diagram of an on-demand data update method in one embodiment; Figure 2 This is a flowchart of an on-demand triggered data update method in one embodiment; Figure 3 This is a structural block diagram of an on-demand triggered data update device in one embodiment; Figure 4 This is a structural block diagram of an electronic device in one embodiment. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Figure 1 This is a diagram of an application environment for on-demand data updates, as shown in one embodiment. (Refer to...) Figure 1This on-demand triggered data update method is applied to an on-demand triggered data update system. The on-demand triggered data update system includes a terminal 110 and a server 120. The terminal 110 and server 120 are connected via a network. The terminal 110 can be a desktop terminal or a mobile terminal; the mobile terminal can be at least one of a mobile phone, tablet, or laptop. The server 120 can be a standalone server or a server cluster consisting of multiple servers. The terminal 110 is used to receive operation commands, and the server 120 is used to provide new data packets.

[0020] like Figure 2 As shown, in one embodiment, an on-demand triggered data update method is provided. This method can be applied to both terminals and servers; this embodiment uses a terminal application as an example. The on-demand triggered data update method specifically includes the following steps: S1: Receives user input commands; S2: Obtain the relevant modules for executing the operation instructions; S3: Detect whether the preset local update area has the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; S4: If the new data package is available, then perform incremental merging and updating based on the new data package corresponding to the relevant module to generate a new module; S5: Execute the operation instructions based on the new module.

[0021] As described in step S1 above, the system receives user-inputted operation commands. These commands, input by the user through the terminal device, can be various operations, such as requesting to read fault codes, updating vehicle configuration, or performing specific diagnostic functions. These commands are the triggering factors for system updates, determining the modules and functions that need to be processed. Specifically, user input can be transmitted through a user interface (such as a touchscreen, button, or voice command) or through external devices (such as mobile devices connected to the terminal). Upon receiving the command, the system must immediately identify and parse it to determine the required functional modules, ensuring that subsequent processing is tailored to the user's actual needs. Furthermore, to ensure system reliability, an error detection mechanism is required when receiving commands to prevent operational anomalies caused by input errors or system malfunctions.

[0022] As described in step S2 above, the relevant modules for executing the operation instruction are obtained. The user-input operation instruction is analyzed, and the modules associated with that instruction are identified and obtained. These related modules are the foundation for implementing the functions required by the user instruction. For example, if a user requests to execute a specific vehicle diagnostic function, the system needs to obtain the diagnostic modules related to that function. To achieve comprehensive and accurate module identification, a module dependency database can be pre-built to store the interactions and dependencies between modules. It should be noted that this can involve the main module directly operated, and can also include any dependent modules that need to be called for the complete execution of the instruction. In practice, generally, one module is associated with one function, that is, each module corresponds one-to-one with a function, and related virtual or physical buttons are displayed on the screen to receive the operation instruction. During implementation, the system can perform dynamic module management, adjusting the acquisition strategy according to the current module version status and availability to adapt to constantly changing user needs and environmental conditions.

[0023] As described in step S3 above, it is checked whether the preset local update area contains the new version data packet corresponding to the relevant module. The update area is a specific area where the system stores locally downloaded new version data packets. This area is set up to improve update efficiency and ensure that the update process remains smooth even in environments with unstable networks or limited bandwidth. That is, the update content will be downloaded to the local update area. During subsequent operations, this area will be searched, and the module's unique identifier will be compared with the currently stored content. The key to this process is to achieve efficient file retrieval and management, because the number of modules in a terminal device may reach dozens or even more. If it is found that the update area does contain the new version data packet corresponding to the relevant module, the relevant module can be marked to prepare for the next incremental merge update step. If the corresponding new version data packet is missing, there is no need to mark it. It should be noted that the new version data packet can be a partial incremental data packet of a function, or a new and complete data packet, that is, it can modify, replace, and add to the module file corresponding to the relevant module.

[0024] The new data package includes the following types of content: 1) Add / modify vehicle configuration Content Description: Add new supported vehicle models, or modify parameters of existing vehicle models (such as year range, platform ID, and list of supported ECUs).

[0025] Change type: Added or updated.

[0026] 2) List of newly added / modified function names Description: Add diagnostic functions or modify the name / ID mapping of existing functions (such as changing the UI display name).

[0027] Change type: Add or rename / update.

[0028] 3) Add / modify text description Description: Add multilingual text, or modify the interface display text and prompts for existing functions.

[0029] Change type: New or localized update.

[0030] 4) Add / modify ECU data algorithm library Content description: Add new analytical algorithms or update the logic of existing algorithms (such as fixing signal analysis errors or adding new parameter calculations).

[0031] Change type: Added or logical update.

[0032] 5) Add / modify instruction library Description: Add new diagnostic commands, or modify communication parameters such as the format, timeout, and retry policy of existing commands.

[0033] Change type: New addition or agreement change.

[0034] 6) Add / modify ECU fault code database (DTC) Content Description: Add a new DTC, or update the description, level, repair recommendations, and associated systems of an existing DTC.

[0035] Change type: Added or updated information.

[0036] 7) Add / modify code modules Content Description: Add new feature code, or update the binary / script of an existing module (such as fixing bugs, optimizing performance, or adding new diagnostic processes).

[0037] Change type: Added or version upgrade.

[0038] As described in step S4 above, if the new version data package is available, incremental merging and updating are performed based on the new version data package corresponding to the relevant module to generate a new version module. That is, updates are performed incrementally based on the previously confirmed relevant modules and corresponding new version data packages. Specifically, the advantages of differential package updates can be utilized, selecting only content different from the local old version for merging, reducing the amount of updated data and improving efficiency. Incremental merging updates can involve operations such as adding, modifying, and replacing, executed through a patch application tool. Based on the version status of the relevant modules, the system generates a complete file of the merged new version. Specifically, a binary differential algorithm (such as bsdiff) or a unified difference format (unifieddiff) can be used to generate patch files, which are then applied to the local old version file. Furthermore, during the merging process, the system performs real-time verification to ensure that the generated new version module is fully functional and stable. In addition, if any errors occur during the merging process, such as format incompatibility or data corruption, the system must be able to automatically identify and take appropriate solutions, such as temporarily suspending the merging, rolling back to the old version, or retrying the update. This mechanism provides the system with greater flexibility and reliability, ensuring that users can seamlessly complete operations and enjoy the immediate experience of the latest version's features.

[0039] As described in step S5 above, the operation command is executed based on the new version module. In the final step, the system applies the generated new version module to execute the user's operation command. The new version module can provide enhancements to previous functions or may include entirely new functions. The user will not experience any delays or interruptions during operation. In addition, the system will monitor the user's operation feedback in real time to ensure that the new version module can operate normally in the current environment. During this process, if it is found that the new version module cannot execute the user command normally, the system must also respond quickly and provide the ability to roll back to the previous version. That is, if the new version module fails to execute, the system automatically rolls back to the old version module and notifies the user.

[0040] In one embodiment, before step S3 of detecting whether the preset local update zone has the new version data packet corresponding to the relevant module, the method further includes: S201: Receive the updated index table pushed by the cloud server; wherein the updated index table contains version information of each relevant module; S202: Extract the local data index table and compare it with the updated index table to calculate the modules that need to be updated and the optimal update strategy; S203: Download the new data package based on the optimal update strategy and store it in the local area to be updated.

[0041] As described in step S201 above, the system receives an update index table pushed by the cloud server. In this embodiment, the system first needs to receive an update index table from the cloud server. This index table is a structured data file containing version information of various related modules. Specifically, it may include the module name, version number, content to be updated, package size, hash value, etc., and can be based on network communication protocols, such as HTTP or HTTPS, to ensure the security and integrity of data transmission. After receiving the index table, the system verifies the integrity and source of the data to ensure that it has not been tampered with or damaged. The update index table acts like a "directory," allowing the client to know all currently available updates and simplifying the subsequent update process. Through this mechanism, the system can effectively manage update information from the cloud, thereby improving the version management of local modules and ultimately improving the overall data update efficiency.

[0042] As described in step S202 above, the local data index table is extracted and compared with the update index table to calculate the modules that need to be updated and the optimal update strategy. The local data index table contains the version information and status of each module in the current system. By comparing it with the update index table in the cloud, the system can quickly identify which modules need to be updated. For example, if the version of a module on the local machine is lower than the version provided in the cloud, the system will record it as a module that needs to be updated. At this time, the system will also calculate the optimal update strategy, including downloading the full package or the differential package to reduce download time and traffic consumption. The process of generating the optimization strategy needs to consider multiple factors, such as the current version of the local module, the size of the module, and the user's network conditions. In this way, the system can not only ensure the effective updating of the required modules, but also provide the best update experience for users according to different context environments.

[0043] As described in step S203 above, the new version data package is downloaded based on the optimal update strategy and stored in the local update-pending area. The local update-pending area is an independent area reserved in the device's memory, used to temporarily store the new version data package downloaded from the cloud. It is isolated from the running modules and interacts with the cloud server through a network connection to download the corresponding new version data package. It can be a full package or a differential package, depending on the previously calculated optimal update strategy. This strategy ensures that users can still complete the update efficiently even with limited bandwidth. During the download process, integrity verification can be performed simultaneously to ensure the reliability and accuracy of the downloaded data. After the download is completed, the system stores the new version data package in the local update-pending area. The purpose of this storage area is to isolate the downloaded new files from the old files currently in use to ensure the stability and continuity of device operation.

[0044] In one embodiment, before step S201 of receiving the updated index table pushed by the cloud server, the method further includes: S2001: Read the user's diagnostic log file to obtain the user's vehicle operation information; S2002: Analyze the time pattern of user operation on the device based on the vehicle operation information to determine the idle time period of the client device; S2003: Set the receiving time for receiving the updated index table pushed by the cloud server according to the idle time period.

[0045] As described in step S2001 above, the user's diagnostic log file is read to obtain the user's vehicle operation information. The diagnostic log file records all operations performed by the user on the vehicle over a period of time, including executed commands, timestamps, vehicle model and functions involved, etc. By analyzing these records, the user's operating habits and preferences can be accurately grasped, and the user's vehicle operation information can be obtained, such as the user's most frequently used functions, the frequency of operation, and the time of each operation. Among these, the most important thing here is to obtain the user's operation time to obtain the off-peak time period.

[0046] As described in step S2002 above, the system analyzes the user's device operation time patterns based on the vehicle operation information to determine the idle time periods of the client device. After obtaining the user's vehicle operation information, the system will conduct in-depth analysis of this data to determine the user's device operation time patterns. This analysis mainly focuses on identifying which time periods are relatively inactive for the user, i.e., "idle" periods. By statistically analyzing the user's operation frequency, peak and off-peak periods for the user within a day or week can be identified. For example, if it is found that the user frequently operates between 7 pm and 9 pm, but has almost no activity from late night to early morning, then the period from late night to early morning can be considered an idle time period. The analysis process can use time series algorithms or cluster analysis methods to accurately capture the user's usage habits, ensuring that the update process does not disturb the user's normal use as much as possible, and further improving user satisfaction.

[0047] As described in step S2003 above, the receiving time for the updated index table pushed by the cloud server is set according to the idle time period. Based on the previously analyzed idle time period, the time for receiving the updated index table pushed by the cloud server is reasonably arranged to receive it during periods of low user activity, thereby minimizing interference with user operations. Specifically, the system can set a scheduled task to automatically trigger the receiving process during periods of low user activity. When the idle time period arrives, the system will establish communication with the cloud server through a network connection and request the latest updated index table. This intelligent arrangement of operations can reduce update failures caused by user operations and optimize the use of network resources. After setting the receiving time, the system will actively obtain update information from the cloud during this period to ensure timely access to the latest module update information, guiding subsequent module checks and update processes. In this way, the system not only achieves automated update management but also provides users with a seamless operating experience, allowing users to enjoy continuous optimization and upgrades of the device without their knowledge, ultimately improving the overall service quality.

[0048] In one embodiment, after step S4, which involves incrementally merging and updating based on the new version data packet corresponding to the relevant module to generate a new version module if the new version data packet is available, the method further includes: S501: Obtain the expected hash value and the corresponding preset hash algorithm carried in the new data packet; S502: Perform hash calculation on the new data packet based on the preset hash algorithm to obtain the calculated hash value of the new module; S503: Compare the calculated hash value with the expected hash value; S504: Determine the integrity of the new data packet based on the comparison results.

[0049] As described in step S501 above, the expected hash value and the corresponding preset hash algorithm carried in the new version data packet are obtained. The expected hash value is a tool used to verify the integrity of the module. It can generate a "digital fingerprint" corresponding to the data content of the new version module file, enabling the system to determine whether the downloaded module is at risk of being damaged or tampered with. Obtaining the preset hash algorithm (e.g., SHA-256) is equivalent to determining the template for subsequent hash calculations, because different algorithms generate hash values ​​with different lengths and meanings. Typically, the hash algorithm is determined and stored in the update index table when the differential packet is generated, ensuring that the client can correctly compare and verify, so that the system can perform integrity verification according to consistent rules, ensuring the security and effectiveness of the update process. Through this process, the system has clear standards in subsequent module verification, making the detection results more reliable and improving the security and stability of the system.

[0050] As described in step S502 above, a hash calculation is performed on the new version data packet based on the preset hash algorithm to obtain the calculated hash value of the new version module. According to the previously extracted preset hash algorithm, the module file in the new version data packet is read in blocks, and iterative hash calculation is performed. The reason for choosing block reading is to reduce memory usage when processing large files, as directly loading the entire large file consumes a lot of memory resources. Block processing makes the calculation process more efficient. During the block reading process, the system reads the module file segment by segment according to a preset size (e.g., 4KB or 8KB) and performs hash calculations sequentially. After each block of data is read, it is calculated using the hash algorithm. Therefore, the final generated hash value is a unified fingerprint for the entire module file. This iterative method not only reduces the memory burden but also handles incomplete or erroneous situations that may occur during data file transmission. Throughout the calculation process, the system must ensure that the byte order and content read each time correspond to the downloaded module file, further ensuring the accuracy of the generated calculated hash value so that a valid result can be obtained in the subsequent comparison stage.

[0051] As described in step S503 above, the calculated hash value is compared with the expected hash value. After calculating the hash value of the new module, the system compares the calculated value with the previously obtained expected hash value. This process is a key step in ensuring the integrity of the new module. The expected hash value is calculated and recorded during the generation and transmission of the new data packet, reflecting the original state of the module file. Therefore, if the calculated hash value matches the expected hash value, it indicates that the new module has not been damaged or tampered with since its generation. Conversely, if they do not match, further analysis is needed to determine whether there is a risk of data loss or damage during the module download or storage process. During the comparison, the system automatically operates according to preset conditions, usually by using equality operations to determine whether the two are consistent. If the comparison result shows consistency, the system can continue to perform subsequent processing; if they do not match, an error handling mechanism needs to be triggered to ensure the stability and security of the system.

[0052] As described in step S504 above, the integrity of the new version data packet is determined based on the comparison result. If the calculated hash value matches the expected hash value, the system will determine that the module file corresponding to the new version module is complete and usable. At this time, the subsequent processing flow will continue, allowing the system to execute user operation commands based on the new version module. On the other hand, if the comparison result shows an inconsistency, the system will determine that the module file may be corrupted or tampered with. In this case, the system will take corresponding error handling measures, such as terminating the current update process, providing corresponding alarm prompts, and rolling back or retrying the download process for the old version module.

[0053] In one embodiment, after step S504 of determining the integrity of the new data packet based on the comparison result, the method further includes: S5051: If the calculated hash value is inconsistent with the expected hash value, the incremental merging and updating step is repeated to generate a new version of the module and perform integrity verification again. S5052: When the number of times the incremental merge update and integrity verification are repeated reaches a preset number and the calculated hash value is still inconsistent with the expected hash value, terminate further incremental merge update operations and report that the new version data packet is unqualified.

[0054] As described in step S5051 above, if the calculated hash value is inconsistent with the expected hash value, the incremental merge update step is repeated to generate a new version of the module and perform integrity verification again. The calculated hash value is compared with the expected hash value. If they are inconsistent, it indicates a problem with the module file corresponding to the new version data package, such as data corruption during download or improper modification of the module. To ensure that the module ultimately used by the user is safe and complete, the system will automatically repeat the previous incremental merge update step. This process includes re-extracting the new version data package from the local update area, applying corresponding patches, and generating a new module file to obtain the new version of the module. Relying on this iterative mechanism, the system can maximally correct errors caused by the initial merge process and provide more reliable update results.

[0055] As described in step S5052 above, when the number of times the incremental merge update and integrity check are repeated reaches a preset number and the calculated hash value is still inconsistent with the expected hash value, further incremental merge update operations are terminated and the new version data packet is reported as unqualified. A maximum number of repetitions is set to control the actual number of iterations in the incremental merge update process. Specifically, if the system repeatedly executes the incremental merge update and integrity check to the preset upper limit, but the calculated hash value of the generated new version module still does not match the expected hash value, it will decide to terminate the subsequent update operation. This decision is based on risk management and user experience considerations, because in this case, continuing to try may lead to greater resource waste and has no practical significance. Subsequently, the system will automatically report the update failure information, clearly informing the user that the new version data packet has a qualification problem and cannot be used. The feedback content can be presented in the form of a prompt box through the user interface, so that the user is immediately aware and relevant suggestions are provided, such as suggesting downloading the complete update package. In a specific embodiment, if the integrity check fails, the system waits for a preset time (e.g., 5 seconds) and then retryes, up to 3 times, and records the log.

[0056] In one embodiment, step S5, which involves incrementally merging and updating based on the new version data packet corresponding to the relevant module to generate a new version module if the new version data packet is available, includes: S511: Parse the new data packet to obtain the change type of the relevant module and its target file path; S512: Perform incremental merging and updating based on the change type of the relevant modules and their target file paths to generate a new version of the modules.

[0057] As described in step S511 above, the new version data packet is parsed to obtain the change type of the relevant module and its target file path. The new version data packet typically uses a structured format, such as JSON or XML, to facilitate the system's reading and extraction of necessary fields. The change type specifies the nature of the operation to be performed on the relevant module, including add, modify, and replace. This information is crucial for subsequent incremental merge updates, as different change types determine the specific merge strategy and execution method. Furthermore, the target file path specifies the specific file location where the operation needs to be performed, whether it's the file's path in the local old version or the location of other persistently stored modules. During parsing, the system must ensure the accuracy of the data read to avoid affecting the accuracy and success rate of subsequent operations due to incorrect information.

[0058] As described in step S512 above, incremental merging and updating are performed based on the change type of the relevant modules and their target file paths to generate a new version of the module. Specifically, based on the extracted change type and path of the relevant modules, incremental merging and updating are executed, applying the content of the new data package to the local old version module. The specific process varies depending on the change type: for "addition" types, the system extracts new files from the new data package and copies them to the specified target path; for "modification" types, the system applies patch files and uses tools such as bsdiff to apply the differences to the target file, generating a module containing the new changes; and for "replacement" types, the system directly deletes the old files and copies the new files to the target location. The incremental merging process requires special attention to file dependencies, ensuring that any new or modified dependent modules are ready before merging. The entire process also requires strict integrity checks to ensure that the functionality and performance of the generated new module are not affected after merging and can be used normally.

[0059] In one embodiment, step S512, which involves incrementally merging and updating the relevant modules based on their change types and target file paths to generate a new version of the modules, includes: S5121: When the change type is modification, obtain the patch file of the corresponding module from the new version data package, use a patch tool based on binary difference algorithm or unified difference format, and apply the patch file to the local old version file according to the target file path to obtain the corresponding new version module; S5122: When the change type is replacement, delete the local old version target file according to the target file path, obtain the corresponding new file in the new version data package and copy it to the location of the target file to obtain the corresponding new version module; S5123: When the change type is new, obtain the new file in the new version data package, and copy it to the predetermined storage path of the local module according to the target file path to obtain the corresponding new version module.

[0060] As described in step S5121 above, when the change type is "modification," the patch file for the corresponding module is obtained from the new version data package. A patching tool based on a binary difference algorithm or a unified diff format is used to apply the patch file to the local old version file according to the target file path to obtain the corresponding new version module. When the system detects that the change type for a related module is "modification," it means that an incremental update of the existing old version file is required. First, the system extracts the patch file related to the module from the new version data package. The patch file is generated by comparing the differences between the old and new versions and usually contains specific modification instructions. Next, an appropriate patching tool is selected, which can be a tool based on a binary difference algorithm, such as bsdiff, or a method using a unified diff format. When using these tools, the system provides the target file path to the patching tool, specifying the specific file to be modified. The patching tool reads the contents of the patch file and applies the difference data to the local old version file, thereby generating a new version module containing the required modifications.

[0061] As described in step S5122 above, when the change type is replacement, the local old version target file is deleted according to the target file path, the corresponding new file in the new version data package is obtained and copied to the location of the target file, thus obtaining the corresponding new version module. The local old version target file is located according to the target file path, and a deletion operation is performed to completely remove the local old version file. Once the old file is confirmed to be deleted, the system extracts the corresponding new file from the new version data package. This new file should contain the latest functions or fixes. Then, the system copies the new file to the original target location. During the copying process, the system needs to verify the integrity and correctness of the file to ensure that every byte is accurate, thereby successfully generating a new module version. Through replacement updates, users can quickly obtain a new version module containing the latest improvements and features, thereby improving the performance or functionality of the device and ensuring that users always use the latest version of the module to meet constantly changing needs.

[0062] As described in step S5123 above, when the change type is "addition", the new file in the new version data package is obtained and copied to the predetermined storage path of the local module according to the target file path to obtain the corresponding new version module. First, the relevant new files are searched in the new version data package, and the specific information of these files is recorded, including file name, path and nature (such as whether it is a new module, data file, etc.). Then, according to the preset target file path, the system will determine the storage location for the new file to ensure compatibility and rationality with other modules. At this time, the system will extract the new file from the new version data package and copy the file, placing it in the corresponding predetermined storage path. The entire copying process must ensure the integrity and consistency of file transmission to prevent errors or data corruption during transmission.

[0063] Reference Figure 3 The present invention also provides an on-demand triggered data update device, the device comprising: The receiving module 902 is used to receive operation commands input by the user; Acquisition module 904 is used to acquire relevant modules for executing the operation instructions; The detection module 906 is used to detect whether a preset local update area has the new version data packet corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data packet; The update module 908 is used to perform incremental merging and updating based on the new version data packet corresponding to the relevant module if the new version data packet is available, so as to generate a new version module. Execution module 910 is used to execute the operation instructions based on the new version of the module.

[0064] In one embodiment, the on-demand triggered data update device further includes: An updated index table receiving module is used to receive an updated index table pushed by a cloud server; wherein, the updated index table contains version information of each related module; The first comparison module is used to extract the local data index table and compare it with the updated index table to calculate the module that needs to be updated and the optimal update strategy. The download module is used to download the new version data package based on the optimal update strategy and store it in the local area to be updated.

[0065] In one embodiment, the on-demand triggered data update device further includes: The reading module is used to read the user's diagnostic log file to obtain the user's vehicle operation information; The judgment module is used to analyze the time pattern of user operation of the device based on the vehicle operation information in order to determine the idle time period of the client device. The settings module is used to set the receiving time for receiving the updated index table pushed by the cloud server according to the idle time period.

[0066] In one embodiment, the on-demand triggered data update device further includes: The expected hash value acquisition module is used to acquire the expected hash value and the corresponding preset hash algorithm carried in the new version data packet; The hash value acquisition module is used to perform hash calculation on the new version data packet based on the preset hash algorithm to obtain the hash value of the new version module; The second comparison module is used to compare the calculated hash value with the expected hash value; The integrity determination module is used to determine the integrity of the new data packet based on the comparison results.

[0067] In one embodiment, the on-demand triggered data update device further includes: The new module file generation module is used to repeat the incremental merging and updating step if the calculated hash value is inconsistent with the expected hash value, so as to generate a new version of the module and perform integrity verification again. The termination module is used to terminate further incremental merge update operations and report that the new data packet is unqualified when the number of times the incremental merge update and integrity verification are repeated reaches a preset number and the calculated hash value is still inconsistent with the expected hash value.

[0068] In one embodiment, the update module 908 includes: The change type acquisition submodule is used to parse the new data packet and obtain the change type of the relevant module and its target file path; The new module generation submodule is used to perform incremental merging and updating based on the change type of the relevant modules and their target file paths to generate the new module.

[0069] In one embodiment, the new version of the module generates submodules, including: The patch file acquisition unit is used to acquire the patch file of the corresponding module from the new version data package when the change type is modification, and to apply the patch file to the local old version file according to the target file path using a patch tool based on binary difference algorithm or unified difference format to obtain the corresponding new version module. The deletion unit is used to delete the local old version target file according to the target file path when the change type is replacement, obtain the corresponding new file in the new version data package and copy it to the location of the target file to obtain the corresponding new version module; The newly added file acquisition unit is used to acquire the newly added file in the new version data package when the change type is new, and copy it to the predetermined storage path of the local module according to the target file path to obtain the corresponding new version module.

[0070] Figure 4 An internal structural diagram of an electronic device in one embodiment is shown. This electronic device can specifically be a terminal or a server, and more specifically, a computer device. Figure 4 As shown, the electronic device includes a processor, a memory, and a network interface connected via a system bus. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system and may also store a computer program. When executed by the processor, this computer program enables the processor to implement an on-demand data update method. The internal memory may also store a computer program, which, when executed by the processor, enables the processor to implement an on-demand data update method. Those skilled in the art will understand that... Figure 4 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0071] In one embodiment, an electronic device is provided, including a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the following steps: Receive user input commands; The relevant modules for executing the operation instructions are obtained; The system detects whether a preset local update area contains the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; If the new data package is available, then an incremental merge update is performed based on the new data package corresponding to the relevant module to generate a new module. The operation instructions are executed based on the new module.

[0072] By receiving user operation commands and only updating the relevant modules involved, the system avoids the resource waste caused by blindly updating all modules in traditional solutions. This achieves precise and necessary control over data updates. The system only performs incremental merging updates on the corresponding modules when the corresponding new data package exists in the local update area, making the update process more efficient and reducing the time and bandwidth consumption caused by downloading the full package. Since the new data package is pre-stored in the local update area and does not directly replace the modules currently in use, the continuity of user operations and the stability of system operation are guaranteed during the module update process. By performing incremental merging on relevant modules to generate new modules, and then executing user commands based on the new modules, the function updates can take effect immediately, thereby greatly improving the user experience.

[0073] In one embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, causes the processor to perform the following steps: Receive user input commands; The relevant modules for executing the operation instructions are obtained; The system detects whether a preset local update area contains the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; If the new data package is available, then an incremental merge update is performed based on the new data package corresponding to the relevant module to generate a new module. The operation instructions are executed based on the new module.

[0074] By receiving user operation commands and only updating the relevant modules involved, the system avoids the resource waste caused by blindly updating all modules in traditional solutions. This achieves precise and necessary control over data updates. The system only performs incremental merging updates on the corresponding modules when the corresponding new data package exists in the local update area, making the update process more efficient and reducing the time and bandwidth consumption caused by downloading the full package. Since the new data package is pre-stored in the local update area and does not directly replace the modules currently in use, the continuity of user operations and the stability of system operation are guaranteed during the module update process. By performing incremental merging on relevant modules to generate new modules, and then executing user commands based on the new modules, the function updates can take effect immediately, thereby greatly improving the user experience.

[0075] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.

[0076] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0077] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A data update method triggered on demand, characterized in that, The method includes: Receive user input commands; The relevant modules for executing the operation instructions are obtained; The system detects whether a preset local update area contains the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; If the new data package is available, then an incremental merge update is performed based on the new data package corresponding to the relevant module to generate a new module. The operation instructions are executed based on the new module.

2. The on-demand triggered data update method according to claim 1, characterized in that, Before the step of detecting whether the preset local update area has the new version data packet corresponding to the relevant module, the method further includes: Receive an updated index table pushed by a cloud server; wherein the updated index table contains version information of each relevant module; Extract the local data index table and compare it with the updated index table to calculate the modules that need to be updated and the optimal update strategy; The new data package is downloaded based on the optimal update strategy and stored in the local area to be updated.

3. The on-demand triggered data update method according to claim 2, characterized in that, Before the step of receiving the updated index table pushed by the cloud server, the method further includes: Read the user's diagnostic log file to obtain the user's vehicle operation information; Based on the vehicle operation information, analyze the time patterns of user operation on the device to determine the idle time periods of the client device; Set the receiving time for receiving updated index tables pushed by the cloud server according to the aforementioned idle time period.

4. The on-demand triggered data update method according to claim 1, characterized in that, Following the step of incrementally merging and updating based on the new version data packet corresponding to the relevant module to generate a new version module if the new version data packet exists, the method further includes: Obtain the expected hash value and the corresponding preset hash algorithm carried in the new data packet; The new module is subjected to hash calculation based on the preset hash algorithm to obtain the calculated hash value of the new module; Compare the calculated hash value with the expected hash value; The integrity of the new data packet is determined based on the comparison results.

5. The on-demand triggered data update method according to claim 4, characterized in that, After the step of determining the integrity of the new data packet based on the comparison results, the method further includes: If the calculated hash value is inconsistent with the expected hash value, the incremental merge update step is repeated to generate a new version of the module and perform integrity verification again. If the incremental merge update and integrity verification are repeated a preset number of times and the calculated hash value is still inconsistent with the expected hash value, further incremental merge update operations are terminated and the new version of the data packet is reported as unqualified.

6. The on-demand triggered data update method according to claim 1, characterized in that, The step of incrementally merging and updating based on the new version data package corresponding to the relevant module to generate a new version module, if the new version data package is available, includes: Parse the new data packet to obtain the change type of the relevant module and its target file path; Incremental merging and updating are performed based on the change type of the relevant modules and their target file paths to generate a new version of the modules.

7. The on-demand triggered data update method according to claim 6, characterized in that, The steps for incrementally merging and updating the relevant modules based on their change types and target file paths to generate a new version of the modules include: When the change type is modification, the patch file of the corresponding module is obtained from the new version data package, and a patching tool based on binary difference algorithm or unified difference format is used to apply the patch file to the local old version file according to the target file path to obtain the corresponding new version module; When the change type is replacement, delete the local old version target file according to the target file path, obtain the corresponding new file in the new version data package and copy it to the location of the target file to obtain the corresponding new version module; When the change type is "new", the new file in the new version data package is obtained and copied to the predetermined storage path of the local module according to the target file path to obtain the corresponding new version module.

8. A data update device triggered on demand, characterized in that, The device includes: The receiving module is used to receive operation commands input by the user; The acquisition module is used to acquire the relevant modules for executing the operation instructions; A detection module is used to detect whether a preset local update area has the new version data package corresponding to the relevant module; wherein, the local update area is used to store the downloaded new version data package; An update module is used to perform incremental merging and updating based on the new version data packet corresponding to the relevant module if the new version data packet is available, so as to generate a new version module; An execution module is used to execute the operation instructions based on the new version of the module.

9. A computer-readable storage medium, characterized in that, The system contains a computer program that, when executed by a processor, causes the processor to perform the steps of the on-demand data update method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, The device includes a memory and a processor, the memory storing a computer program that, when executed by the processor, causes the processor to perform the steps of the on-demand triggered data update method as described in any one of claims 1 to 7.

Images