A file synchronization method, device and system of a car machine and a cloud system

Abstract

The application discloses a file synchronization method, device and system of a car machine and a cloud system, wherein, before file modification, a car machine system / cloud file system applies for a corresponding file modification lock to a control center; if the lock is successfully applied, a lock file is generated locally, and the latest version number in the lock and the local file version number are compared; if the local file version number is not behind, file modification is performed, and after the modification is completed, the file is saved in a local temporary working area, the latest version number is generated and synchronized to the corresponding lock file of the control center, and a synchronization modification request trigger is waited for; if the local version number is behind, a synchronization modification process or a modification cancellation process is determined to be executed according to user selection; and if the lock is not successfully applied, a modification request is determined to be abandoned or the modification is forced to be synchronized to the opposite end, and then the lock is applied again. The application can save vehicle-mounted traffic while ensuring consistency of the car machine and the cloud data.

Description

Technical Field

[0001] This invention relates to a method, apparatus, and system for synchronizing files between a vehicle-mounted system and a cloud system, belonging to the fields of information processing and vehicle networking technology. Background Technology

[0002] As vehicles become increasingly intelligent, many in-vehicle infotainment systems use operating systems such as Android, allowing users to modify files via the central control screen. Additionally, OEMs offer cloud-based file management functions, enabling users to log in to the file management system on a PC using a unified account to perform operations such as modifying, backing up, and deleting files.

[0003] The system architecture of vehicle-mounted systems and the cloud, such as Figure 1 As shown, the control center interacts with the vehicle's infotainment system and the cloud file system to provide necessary auxiliary functions (such as account login permission verification). User modifications to files are synchronized in real-time between the vehicle's infotainment system and the cloud file system. Currently, the file synchronization mechanism between the vehicle's infotainment system and the cloud has the following shortcomings: 1. Both the cloud file system and the vehicle's infotainment system can modify files simultaneously. If modifications are made on one end before synchronization with the other, a conflict will occur during bidirectional synchronization; 2. Immediately synchronizing modified file content after changes to files on the vehicle's infotainment system consumes a significant amount of in-vehicle cellular data. Summary of the Invention

[0004] Purpose of the invention: In view of the problems existing in the prior art, the purpose of this invention is to provide a method, device and system for file synchronization between vehicle-mounted systems and cloud systems. By tracking file modifications to the vehicle-mounted system and the cloud file system, the consistency of data between the vehicle-mounted system and the cloud is ensured while saving in-vehicle data traffic.

[0005] Technical solution: To achieve the above-mentioned objectives, the present invention adopts the following technical solution:

[0006] A method for synchronizing files between a vehicle infotainment system and a cloud system includes the following steps:

[0007] Before modifying a file, the vehicle system / cloud file system requests a corresponding file modification lock from the control center; the lock stores the file's stable version number, latest version number, lock usage status, expiration time, and owner information;

[0008] If the lock application is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not behind, the file is modified, saved in the local temporary working area, and a latest version number is generated and synchronized to the corresponding lock file in the control center, waiting for a synchronization modification request to be triggered. If the local version number is behind, the synchronization modification process is executed or canceled according to the user's choice. The synchronization modification request is triggered when the vehicle system detects a WIFI signal or when the user actively requests synchronization.

[0009] If the lock application fails, the user can choose to either abandon the modification request or force synchronization of the peer's modifications and then apply for the lock again.

[0010] As a preferred option, the file modification lock is released after file synchronization is complete, modification is undone, and the lock holding time expires without renewal.

[0011] Preferably, the synchronous modification process includes:

[0012] The synchronized party compares the local file version number with the stable version number in the lock file in the synchronization package. If they match, the synchronization operation is accepted; otherwise, synchronization is rejected and the synchronization modification process ends. The synchronization package includes the file content of the synchronizing party's temporary working area and the lock file. The synchronized party is the party with the lagging version number, and the synchronizing party is the party with the leading version number.

[0013] The synchronizing party overwrites the actual file with the file content in the local temporary working area to complete the local file content synchronization; updates the corresponding stable version number of the control center with the latest version number of the local lock file; and clears the corresponding file content in the local lock file and the temporary working area.

[0014] The receiving party parses the data in the synchronization package, overwrites the local file version number with the latest version number in the lock file within the synchronization package, and simultaneously overwrites the local file with the file from the synchronization package.

[0015] As a preferred approach, during the file synchronization and modification process, it is not possible to request a lock for the corresponding file. After the synchronizing party and the synchronized party have completed synchronization, they notify the control center to release the lock for the corresponding file.

[0016] As a preferred approach, if the target of the synchronization refuses to synchronize, the user is prompted to undo the changes made by the target and restore the version to a stable version number.

[0017] Preferably, the undo modification process includes: rolling the file back to the previous stable version agreed upon by both parties, changing the latest version number in the control center lock file to the stable version number; releasing the file modification lock, and clearing the temporary working area.

[0018] As a preferred method, a distributed auto-incrementing algorithm is used to generate the file version number.

[0019] A file synchronization device between a vehicle-mounted system and a cloud system includes a control center, a vehicle-mounted system synchronization module, and a cloud system synchronization module; the control center is used to maintain file modification locks, which store the file's stable version number, latest version number, lock usage status, expiration time, and owner information;

[0020] The vehicle-to-everything (V2X) synchronization module is used by the V2X system to request a corresponding file modification lock from the control center before modifying a file. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not lagging behind, the file is modified, and the modified file is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center. The synchronization modification process is executed when a WIFI signal is detected or when the user actively requests synchronization. If the local version number is lagging behind, the synchronization modification process is executed or the modification process is canceled according to the user's choice. If the lock request is unsuccessful, the modification request is abandoned or the modification of the cloud file system is forcibly synchronized and the lock is requested again according to the user's choice.

[0021] The cloud synchronization module is used by the cloud file system to request a corresponding file modification lock from the control center before modifying a file. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not behind, the file is modified, and the modified file is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center, waiting for the synchronization modification request to be triggered to execute the synchronization modification process. If the local version number is behind, the user chooses to execute the synchronization modification process or cancel the modification process. If the lock request is unsuccessful, the user chooses to abandon the modification request or force the synchronization of the vehicle system's modifications and then re-apply for the lock.

[0022] A file synchronization system includes an in-vehicle terminal device, a cloud server, and a control server; the in-vehicle terminal device, the cloud server, and the control server each include a memory, a processor, and a computer program stored in the memory and capable of running on the processor;

[0023] When the computer program on the vehicle-mounted device is loaded into the processor, the following is implemented:

[0024] Before modifying a file, a corresponding file modification lock is requested from the program on the control server. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not lagging behind, the file is modified, saved in the local temporary working area, and the latest version number is generated and synchronized to the corresponding lock file in the control center. The synchronization modification process is executed when a WIFI signal is detected or when the user actively requests synchronization. If the local version number is lagging behind, the synchronization modification process or the modification process is canceled according to the user's choice. If the lock request is unsuccessful, the modification request is abandoned or the modification of the program on the cloud server is forcibly synchronized and the lock is requested again according to the user's choice.

[0025] When the computer program on the cloud server is loaded into the processor, the following is achieved:

[0026] Before modifying a file, a corresponding file modification lock is requested from the program on the control server. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not behind, the file is modified, and after modification, it is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center, waiting for the synchronization modification request to be triggered to execute the synchronization modification process. If the local version number is behind, the synchronization modification process or the modification process is canceled according to the user's choice. If the lock request is unsuccessful, the modification request is abandoned or the modification of the program on the vehicle terminal device is forcibly synchronized and the lock is requested again according to the user's choice.

[0027] When the computer program on the control server is loaded into the processor, the following is implemented:

[0028] The maintenance file modification lock stores the file's stable version number, latest version number, lock usage status, expiration time, and owner information.

[0029] Beneficial effects: Compared with the prior art, the present invention has the following advantages:

[0030] 1. This invention takes into account that if a file in either the vehicle infotainment system or the cloud file system is changed and immediately synchronized to the other, it may consume a lot of in-vehicle data traffic. Under cellular network conditions, only the latest version number of the file is synchronized, and the actual changes to the file are lazy-loaded. The actual file synchronization action is triggered only when a WIFI signal is detected or when forced synchronization is performed. This can save cellular data traffic, and considering the stability of WIFI signals, it also improves the speed and stability of file synchronization.

[0031] 2. The present invention has a built-in file change monitor in both the vehicle system and the cloud file system. It uses an incrementing latest version number to mark each change of the file and to track file modifications in a timely manner. By monitoring each life cycle of file changes and forcibly performing data synchronization when necessary, it can ensure the consistency of data between the vehicle system and the cloud. Attached Figure Description

[0032] Figure 1 This is an architecture diagram of the vehicle infotainment system and the cloud file system.

[0033] Figure 2 This is a flowchart illustrating the file modification process according to an embodiment of the present invention.

[0034] Figure 3 This is a flowchart illustrating the synchronous modification process in an embodiment of the present invention. Detailed Implementation

[0035] The technical solution of the present invention will now be clearly and completely described in conjunction with the accompanying drawings and specific embodiments.

[0036] This invention discloses a file synchronization method between a vehicle-mounted system and a cloud system, providing a two-way file synchronization mechanism. Under cellular network conditions, the latest version number of the file is synchronized by default, and file modifications are only synchronized when a WIFI signal or a forced synchronization signal is detected, thereby minimizing cellular data traffic. File change operations are monitored and recorded at both ends to ensure the eventual consistency of data between the vehicle-mounted system and the cloud file system.

[0037] Specifically, in the method of this embodiment of the invention, each file corresponds to a file modification lock in the control center. Modification operations on the file by the vehicle system or cloud file system require acquiring this lock before proceeding. The lock stores the file's stable version number, latest version number, lock usage status, expiration time, and basic information of the owner. The stable version number refers to the file version number of the last successfully synchronized file between the vehicle system and the cloud file system. After each file modification, a globally incrementing distributed version number is generated based on a distributed auto-incrementing algorithm (such as the snowflake algorithm). This version number is promptly synchronized to the corresponding field of the lock in the control center after each generation. After acquiring the lock, the vehicle system or cloud file system modifies the file and releases the lock after file synchronization is complete. The lock's expiration time is used to automatically release the lock in case of a system crash or shutdown. If the local client is still alive, the lock can be automatically renewed before expiration, extending its validity until modification synchronization is complete.

[0038] like Figure 2 As shown, the overall process of this invention embodiment is divided into several stages: before file modification, local file modification, synchronous modification, and undo modification. The specific steps of each stage are described below:

[0039] Before the file was modified:

[0040] a1. The in-vehicle computer or the cloud file system applies for a file modification lock corresponding to the file to be modified to the control center. If the application is successful, jump to step a2; otherwise, jump to step a3.

[0041] a2. After the in-vehicle computer or the cloud file system successfully applies for the lock, a lock file is generated in the local temporary directory, and the file modification process is entered.

[0042] a3. If the file lock cannot be successfully applied, it means that there are unsubmitted modifications to the file on the other side. The user can choose to abandon the current modification request or force the submission of the modification on the other side. If the user abandons the current modification, the process ends; otherwise, jump to step a4.

[0043] a4. Trigger the actual synchronization task and execute the synchronization modification process.

[0044] a5. After the synchronization modification is completed, jump to step a1 and re-execute the lock application process.

[0045] Local file modification:

[0046] b1. The in-vehicle computer or the cloud file system compares the latest version number V0 of the file in the lock with the version number V1 of the local file. If V1 < V0, a request for synchronizing or canceling the file modification is triggered; otherwise, jump to step b2. Specifically, the user confirms whether to synchronize the new version. If synchronization is required, trigger the actual synchronization task and execute the synchronization modification process; if the user abandons the new version, execute the cancel modification process.

[0047] b2. When the file is modified and saved, the modified file content is stored in the system temporary working area; at the same time, a new incremental file version number is generated, and this version number is stored in the latest version number field of the corresponding lock file; at the same time, the latest version number of the corresponding file lock in the control center is set to the latest version number of the local lock file.

[0048] b3. The user repeats the modification process of step b2 on the in-vehicle computer or the cloud file system locally. Here, the file modification is not immediately synchronized, and the synchronization modification process is only executed when the synchronization modification request is triggered.

[0049] Examples of local temporary working area and lock file:

[0050]

[0051] Synchronization modification:

[0052] Basic settings for synchronization between the in-vehicle computer and the cloud file system: The party with a lower version number is called the synchronized party, and the party with a higher version number is called the synchronization party; the synchronization package for each file includes: the file content in the synchronization party's temporary working area, the file lock. During the file synchronization phase, a lock for this file cannot be applied.

[0053] Synchronization timing: The user initiates a file synchronization command after making modifications; the vehicle's infotainment system actively requests file synchronization upon detecting a Wi-Fi signal; or the vehicle's infotainment system or cloud file system forcibly requests file synchronization if file versions are inconsistent or a lock request fails, triggering synchronization between local and cloud file systems. The synchronization modification process is as follows: Figure 3 .

[0054] c1. Synchronization packet sent by the synchronization direction to the file being synchronized.

[0055] c2. The synchronized party compares the local file version number with the stable version number in the lock file of the synchronization package. If they match, it means that the file has not been modified concurrently, and the synchronization is accepted; otherwise, the synchronization is rejected, and the process jumps to step c7.

[0056] c3. The control center instructs the synchronizing party to overwrite the actual files with the file content in the local temporary working area, completing the local file content synchronization; updates the stable version number of the corresponding file lock in the control center with the latest version number of the local lock file; and clears the corresponding file content in the local lock file and the temporary working area. After the above operations are completed, the control center is notified that synchronization is complete.

[0057] c4. The synchronized party parses the data in the synchronization package, overwrites the current version number of the local file with the latest version number in the lock file, and overwrites the local file with the file in the synchronization package; after the above operations are completed, the control center is notified that the synchronized party has completed the synchronization.

[0058] c5. The control center releases the lock on the file;

[0059] c6. After the synchronization operation is completed, back up the latest stable version of the file that has been agreed upon in both the vehicle system and the cloud system;

[0060] c7. Prompt the user to undo one party's changes.

[0061] Undo changes:

[0062] d1. Roll back to the previous stable version agreed upon by both parties (the previous version was generated in step c6); modify the latest version number corresponding to the control center file to the stable version number;

[0063] d2. Release the file lock (delete the local lock file and clear the placeholder marker for the lock in the Control Center), and empty the temporary work area.

[0064] Based on the same inventive concept, this invention discloses a file synchronization device for a vehicle-mounted system and a cloud system, comprising a control center, a vehicle-mounted system synchronization module, and a cloud synchronization module. The control center maintains file modification locks, which store the file's stable version number, latest version number, lock usage status, expiration time, and owner information. The vehicle-mounted system synchronization module is used by the vehicle-mounted system to request a corresponding file modification lock from the control center before modifying a file. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not lagging, the file is modified, saved in a local temporary working area, and a latest version number is generated and synchronized to the corresponding lock file in the control center. The synchronization process is executed when a Wi-Fi signal is detected or when the user actively requests synchronization. If the local version number is lagging, the system will proceed according to the user's selection. The system determines whether to execute or cancel the modification process. If the lock application fails, the system will either abandon the modification request or force synchronization of the cloud file system's modifications before reapplying for the lock, depending on the user's choice. The cloud synchronization module is used by the cloud file system to apply for a corresponding file modification lock from the control center before modifying a file. If the lock application is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not behind, the file is modified, saved in a local temporary working area, and a latest version number is generated and synchronized to the corresponding lock file in the control center, waiting for the synchronization modification request to be triggered to execute the synchronization modification process. If the local version number is behind, the system will either execute or cancel the modification process, depending on the user's choice. If the lock application fails, the system will either abandon the modification request or force synchronization of the vehicle system's modifications before reapplying for the lock, depending on the user's choice.

[0065] Based on the same inventive concept, the present invention discloses a file synchronization system, including an in-vehicle terminal device, a cloud server, and a control server; the in-vehicle terminal device, the cloud server, and the control server all include a memory, a processor, and a computer program stored in the memory and capable of running on the processor;

[0066] When the computer program on the vehicle-mounted device is loaded into the processor, it performs the following: Before modifying a file, it requests a corresponding file modification lock from the program on the control server; if the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number; if the local file version number is not lagging behind, the file is modified, and after modification, it is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center, and the synchronization modification process is executed when a WIFI signal is detected or when the user actively requests synchronization; if the local version number is lagging behind, the synchronization modification process or the modification process is canceled according to the user's choice; if the lock request is unsuccessful, the modification request is abandoned or the modification of the program on the cloud server is forcibly synchronized and the lock is requested again according to the user's choice.

[0067] When the computer program on the cloud server is loaded into the processor, it performs the following: Before modifying a file, it requests a corresponding file modification lock from the program on the control server; if the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number; if the local file version number is not behind, the file is modified, and after modification, it is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center, waiting for the synchronization modification request to be triggered to execute the synchronization modification process; if the local version number is behind, the synchronization modification process or the modification process is canceled according to the user's choice; if the lock request is unsuccessful, the modification request is abandoned or the modification of the program on the vehicle terminal device is forcibly synchronized according to the user's choice, and then the lock is requested again.

[0068] When the computer program on the control server is loaded into the processor, it implements the following: maintaining a file modification lock, which stores the file's stable version number, latest version number, lock usage status, expiration time, and owner information.

Claims

1. A method for synchronizing files between a vehicle-mounted infotainment system and a cloud-based system, characterized in that, Includes the following steps: Before modifying a file, the vehicle system / cloud file system requests a corresponding file modification lock from the control center. The lock stores the file's stable version number, latest version number, lock usage status, expiration time, and owner information. The stable version number refers to the file version number of the last successfully synchronized file between the vehicle system and the cloud file system. If the lock application is successful, a lock file is generated locally, and the latest version number in the lock is compared with the version number in the local file. If the local file version number is not outdated, the file is modified and saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center. The synchronization modification process is executed when the synchronization modification request is triggered. If the local version number is outdated, the system will either execute a synchronization modification process or cancel the modification process based on the user's choice. The synchronization modification request is triggered when the vehicle system detects a WIFI signal or when the user actively requests synchronization. If the lock application fails, the user can choose to either abandon the modification request or force synchronization of the peer's modifications and then apply for the lock again. Among them, forced synchronization of peer modification is a mandatory requirement to synchronize files, triggering the synchronization and modification process between the vehicle system and the cloud file system; The synchronous modification process includes: The synchronized party compares the local file version number with the stable version number in the lock file in the synchronization package. If they match, the synchronization operation is accepted; otherwise, synchronization is rejected and the synchronization modification process ends. The synchronization package includes the file content of the synchronizing party's temporary working area and the lock file. The synchronized party is the party with the lagging version number, and the synchronizing party is the party with the leading version number. The synchronizing party overwrites the actual file with the file content in the local temporary working area to complete the local file content synchronization; updates the corresponding stable version number of the control center with the latest version number of the local lock file; and clears the corresponding file content in the local lock file and the temporary working area. The receiving party parses the data in the synchronization package, overwrites the local file version number with the latest version number in the lock file within the synchronization package, and simultaneously overwrites the local file with the file from the synchronization package.

2. The file synchronization method between the vehicle-mounted system and the cloud system according to claim 1, characterized in that, Release the file modification lock after file synchronization is complete, modification is undone, and the lock expires without renewal.

3. The file synchronization method between the vehicle-mounted system and the cloud system according to claim 1, characterized in that, During the file synchronization modification process, it is not possible to request a lock for the corresponding file. After the synchronizing party and the synchronized party have completed synchronization, they notify the control center to release the lock for the corresponding file.

4. The file synchronization method between the vehicle-mounted system and the cloud system according to claim 1, characterized in that, If the target device refuses to synchronize, the user is prompted to undo the changes made by the target device and restore the version to a stable version number.

5. The file synchronization method between the vehicle-mounted system and the cloud system according to claim 1, characterized in that, The process of undoing modifications includes: rolling the file back to the previous stable version agreed upon by both parties, changing the latest version number in the control center lock file to the stable version number; releasing the file modification lock, and clearing the temporary working area.

6. The file synchronization method between the vehicle-mounted system and the cloud system according to claim 1, characterized in that, The version number of the file is generated using a distributed auto-increment algorithm.

7. A file synchronization device for a vehicle-mounted system and a cloud system, characterized in that, It includes a control center, a vehicle-to-everything (V2X) synchronization module, and a cloud-based synchronization module. The control center is used to maintain file modification locks, which store the file's stable version number, latest version number, lock usage status, expiration time, and owner information. The stable version number refers to the file version number of the last successfully synchronized file between the V2X and cloud-based file systems. The vehicle-mounted system synchronization module is used to request a corresponding file modification lock from the control center before modifying a file. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not behind, the file is modified, and after the modification is completed, it is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center. The synchronization modification process is executed when a WIFI signal is detected or when the user actively requests synchronization. If the local version number is outdated, the system will either execute the synchronization modification process or cancel the modification process based on the user's choice; if the lock application is unsuccessful, the system will either abandon the modification request or force the synchronization of the cloud file system modifications and then apply for the lock again based on the user's choice. The forced synchronization of the cloud file system modification is a mandatory requirement to synchronize files, triggering the synchronization and modification process between the vehicle system and the cloud file system. The cloud synchronization module is used to request a corresponding file modification lock from the control center before modifying a file in the cloud file system. If the lock request is successful, a lock file is generated locally, and the latest version number in the lock is compared with the local file version number. If the local file version number is not behind, the file is modified, and after the modification is completed, it is saved in the local temporary working area. At the same time, the latest version number is generated and synchronized to the corresponding lock file in the control center, and the synchronization modification process is executed when the synchronization modification request is triggered. If the local version number is outdated, the system will either execute the synchronization modification process or cancel the modification process based on the user's choice; if the lock application is unsuccessful, the system will either abandon the modification request or force the synchronization of the vehicle system's modifications and then apply for the lock again based on the user's choice. The forced synchronization of the vehicle system modification is a mandatory requirement to synchronize files, triggering the synchronization and modification process between the vehicle system and the cloud file system. The synchronous modification process includes: The synchronized party compares the local file version number with the stable version number in the lock file in the synchronization package. If they match, the synchronization operation is accepted; otherwise, synchronization is rejected and the synchronization modification process ends. The synchronization package includes the file content of the synchronizing party's temporary working area and the lock file. The synchronized party is the party with the lagging version number, and the synchronizing party is the party with the leading version number. The synchronizing party overwrites the actual file with the file content in the local temporary working area to complete the local file content synchronization; updates the corresponding stable version number of the control center with the latest version number of the local lock file; and clears the corresponding file content in the local lock file and the temporary working area. The receiving party parses the data in the synchronization package, overwrites the local file version number with the latest version number in the lock file within the synchronization package, and simultaneously overwrites the local file with the file from the synchronization package.

8. The file synchronization device for the vehicle-to-infrastructure and cloud system according to claim 7, characterized in that, The file modification lock is released after file synchronization is completed, modification is undone, and the lock's holding time expires without renewal.

9. A file synchronization system, characterized in that, It includes an in-vehicle terminal device, a cloud server, and a control server; each of the in-vehicle terminal device, cloud server, and control server includes a memory, a processor, and a computer program stored in the memory and capable of running on the processor; When the computer program on the vehicle-mounted device is loaded into the processor, the following is implemented: Before modifying a file, request a corresponding file modification lock from the program on the control server. If the lock request is successful, generate a lock file locally and compare the latest version number in the lock with the local file version number. If the local file version number is not behind, modify the file and save it in the local temporary working area. At the same time, generate the latest version number and synchronize it to the corresponding lock file in the control center. Wait for the WIFI signal to be detected or for the user to actively request synchronization to execute the synchronization modification process. If the local version number is outdated, the system will either execute the synchronization modification process or cancel the modification process based on the user's choice. If the lock application is unsuccessful, the system will either abandon the modification request or force the synchronization of the program's modifications on the cloud server and then apply for the lock again based on the user's choice. The forced synchronization of program modifications on the cloud server is a mandatory requirement to synchronize files, triggering the synchronization and modification process between the vehicle-mounted device and the cloud server. When the computer program on the cloud server is loaded into the processor, the following is achieved: Before modifying a file, request the corresponding file modification lock from the program on the control server. If the lock request is successful, generate a lock file locally and compare the latest version number in the lock with the local file version number. If the local file version number is not behind, modify the file, save it in the local temporary working area after modification, generate the latest version number and synchronize it to the corresponding lock file in the control center, and wait for the synchronization modification request to be triggered to execute the synchronization modification process. If the local version number is outdated, the system will either execute the synchronization modification process or cancel the modification process based on the user's choice; if the lock application is unsuccessful, the system will either abandon the modification request or force the synchronization of the program modifications on the vehicle terminal device and then apply for the lock again based on the user's choice. The forced synchronization of program modifications on the vehicle-mounted device is a mandatory requirement to synchronize files, triggering the synchronization and modification process between the vehicle-mounted device and the cloud server. The synchronous modification process includes: The synchronized party compares the local file version number with the stable version number in the lock file in the synchronization package. If they match, the synchronization operation is accepted; otherwise, synchronization is rejected and the synchronization modification process ends. The synchronization package includes the file content of the synchronizing party's temporary working area and the lock file. The synchronized party is the party with the lagging version number, and the synchronizing party is the party with the leading version number. The synchronizing party overwrites the actual file with the file content in the local temporary working area to complete the local file content synchronization; updates the corresponding stable version number of the control center with the latest version number of the local lock file; and clears the corresponding file content in the local lock file and the temporary working area. The receiving party parses the data in the synchronization package, overwrites the local file version number with the latest version number in the lock file in the synchronization package, and overwrites the local file with the file in the synchronization package; When the computer program on the control server is loaded into the processor, the following is implemented: The maintenance file modification lock stores the file's stable version number, latest version number, lock usage status, expiration time, and owner information; the stable version number refers to the file version number of the most recent successful synchronization between the vehicle system and the cloud file system.

Images