APP and whole vehicle OTA software version synchronization method and system

Abstract

The invention discloses an APP and whole vehicle OTA software version synchronization method and system, and relates to the technical field of intelligent networked automobiles. According to the method, an upgrade strategy and an initial synchronization version relation table are configured; according to the upgrading strategy, an upgrading task is created and pushed to a TSP end, so that the TSP end pushes the upgrading task to a vehicle end, upgrading success information fed back by the vehicle end is received, and the upgrading success information is fed back after the vehicle end executes upgrading according to the upgrading task and upgrading is successful; an APP version matching verification request sent by the TSP end is received, and the whole vehicle OTA version and the APP version are controlled to be synchronized according to the APP version matching verification request; and pushing the initial synchronization version relation table to the TSP end according to the upgrading information, so that the TSP end controls the APP version to be synchronized with the whole vehicle OTA version.

Description

Technical Field

[0001] The present application relates to the technical field of intelligent connected vehicles, and in particular to a method and system for synchronizing an APP with an OTA software version of a whole vehicle. Background Art

[0002] In the current field of intelligent connected vehicles, with the rapid development of OTA (Over-The-Air) technology, vehicle software upgrades have become the norm, bringing users continuous functional updates and experience optimization. However, this frequent software upgrade also brings new problems, especially in the synchronization of mobile phone car APP and vehicle OTA software versions. In the traditional mode, car APP and vehicle software often exist as independent systems, updated separately, and lack an effective synchronization mechanism. When the vehicle is upgraded to add or repair functions through OTA, if the mobile phone APP fails to update synchronously, the user will not be able to experience the new functions or correctly operate the repaired functions on the mobile phone, which seriously affects the user experience. Conversely, if the mobile phone APP is upgraded first and the vehicle software is not synchronized, it may also cause function mismatch problems. In addition, due to the differences in the upgrade progress of different user groups after the vehicle is put on the market, the same model may have multiple different versions of OTA software on the market at the same time. This complexity further exacerbates the difficulty of synchronizing the mobile phone APP with the vehicle software version.

[0003] Therefore, how to ensure that the mobile phone APP and the vehicle OTA software always remain consistent at the functional level is a problem that needs to be solved urgently. Summary of the invention

[0004] The main purpose of this application is to provide a method and system for synchronizing an APP with the OTA software version of a whole vehicle, aiming to solve the technical problem of how to ensure that the mobile phone APP and the OTA software of the whole vehicle always remain consistent at the functional level.

[0005] To achieve the above purpose, the present application proposes a method for synchronizing the APP and the vehicle OTA software version, which is applied to the OTA service platform. The method includes:

[0006] Configure the upgrade strategy and initial synchronization version relationship table;

[0007] Create and push an upgrade task to the TSP end according to the upgrade strategy, so that the TSP end pushes the upgrade task to the vehicle end, and receives upgrade success information fed back by the vehicle end, wherein the upgrade success information is the vehicle end performing the upgrade according to the upgrade task and fed back after the upgrade is successful;

[0008] Receive the APP version matching verification request sent by the TSP, and control the synchronization of the vehicle OTA version and the APP version according to the APP version matching verification request;

[0009] The initial synchronization version relationship table is pushed to the TSP end according to the upgrade information, so that the TSP end controls the synchronization of the APP version with the vehicle OTA version.

[0010] In one embodiment, the step of receiving the APP version matching verification request sent by the TSP, and controlling the synchronization of the vehicle OTA version with the APP version according to the APP version matching verification request includes:

[0011] Upon receiving the APP version matching verification request sent by the TSP, obtaining an updated APP version number according to the APP version matching verification request;

[0012] Query the updated OTA version number corresponding to the updated APP version number according to the initial synchronization version relationship table;

[0013] Receive the actual vehicle OTA version number fed back by the vehicle side, obtain the OTA version matching status according to the actual vehicle OTA version number and the updated OTA version number, and push the OTA version matching status to the TSP side, so that the TSP side controls the synchronization of the entire vehicle OTA version and the APP version.

[0014] In one embodiment, the step of creating and pushing the upgrade task to the TSP end according to the upgrade strategy includes:

[0015] Get the task push time;

[0016] Determine the mission validity period and vehicle identification code according to the upgrade strategy;

[0017] Creating an upgrade task according to the task validity period and the vehicle identification code;

[0018] The upgrade task is pushed to the TSP end according to the task push time.

[0019] In one embodiment, after the step of creating and pushing the upgrade task to the TSP end according to the upgrade strategy, the method further includes:

[0020] When receiving information that the vehicle-side OTA upgrade has failed, recreate and push the upgrade task to the TSP side to ensure that the vehicle-side OTA upgrade operation is successfully executed.

[0021] In addition, to achieve the above purpose, the present application also proposes a method for synchronizing the APP and the vehicle OTA software version, which is applied to the TSP side. The method includes:

[0022] Receive upgrade tasks, OTA version matching status, and initial synchronization version relationship pushed by the OTA service platform;

[0023] Pushing the upgrade task to the vehicle end so that the vehicle end performs the upgrade operation;

[0024] Obtaining the APP version matching status according to the initial synchronization version relationship table;

[0025] Control the vehicle-side OTA version synchronization update according to the OTA version matching status;

[0026] The mobile terminal APP version is controlled to be updated synchronously according to the APP version matching status.

[0027] In one embodiment, the step of controlling the vehicle-side OTA version synchronous update according to the OTA version matching status includes:

[0028] When the OTA version matching state is an unmatched state, an OTA version update request is sent to the mobile terminal, so that the mobile terminal controls the vehicle end to complete the OTA version synchronous update according to the OTA version update request.

[0029] In one embodiment, the step of controlling the synchronous update of the mobile terminal APP version according to the APP version matching status includes:

[0030] When the APP version matching state is an unmatched state, a target APP version number is sent to the mobile terminal, so that the mobile terminal completes the APP version synchronization update according to the target APP version number.

[0031] In addition, to achieve the above purpose, the present application also proposes a method for synchronizing the APP with the vehicle OTA software version, which is applied to a mobile terminal, and the method includes:

[0032] When a new version of APP is detected in the application market, an update request is sent to the TSP end through the vehicle identification code, so that the TSP end feeds back an OTA version update request, and the OTA version update request is obtained after the TSP end sends an OTA version matching verification request to the OTA service platform and receives the OTA version matching result fed back by the OTA service platform;

[0033] When the OTA version update request fed back by the TSP is received, the user is prompted to perform OTA upgrade according to the OTA version update request.

[0034] In one embodiment, after the step of prompting the user to perform an OTA upgrade according to the OTA version update request when the OTA version update request fed back by the TSP is received, the step further includes:

[0035] Receive upgrade instructions input by the user;

[0036] Determine the upgrade type according to the upgrade instruction;

[0037] Send a corresponding OTA version upgrade request to the TSP according to the upgrade type.

[0038] In addition, to achieve the above-mentioned purpose, the present application also proposes an APP and vehicle OTA software version synchronization system, characterized in that the APP and vehicle OTA software version synchronization system includes the OTA service platform, TSP terminal and mobile terminal mentioned above.

[0039] The present application provides a method for synchronizing the APP with the OTA software version of the whole vehicle. The present application configures an upgrade strategy and an initial synchronization version relationship table; creates and pushes an upgrade task to the TSP end according to the upgrade strategy, so that the TSP end pushes the upgrade task to the vehicle end, and receives the upgrade success information fed back by the vehicle end, wherein the upgrade success information is the vehicle end executing the upgrade according to the upgrade task and feedback after the upgrade is successful; receives the APP version matching verification request sent by the TSP end, and controls the synchronization of the whole vehicle OTA version and the APP version according to the APP version matching verification request; pushes the initial synchronization version relationship table to the TSP end according to the upgrade information, so that the TSP end controls the synchronization of the APP version and the whole vehicle OTA version. In summary, the present application solves the problem of how to ensure that the mobile phone APP and the whole vehicle OTA software are always consistent at the functional level by monitoring the version status of the vehicle OTA software and the mobile phone APP in real time, and automatically triggers the synchronization update process of the other end when the version of either end is updated, thereby improving the user's smart car experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0041] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0042] Figure 1 A flowchart of the first embodiment of the OTA service platform provided for the synchronization method of the APP and the vehicle OTA software version in this application;

[0043] Figure 2 This is a flowchart of the OTA service platform task creation in the first embodiment of the method for synchronizing the APP and the whole vehicle OTA software version in this application;

[0044] Figure 3This is the first flowchart of synchronous upgrading in the first embodiment of the method for synchronizing the APP and the vehicle OTA software version in this application;

[0045] Figure 4 This is the second flowchart of synchronous upgrading in the first embodiment of the method for synchronizing the APP and the whole vehicle OTA software version in this application;

[0046] Figure 5 A flowchart of the second embodiment of the APP and vehicle OTA software version synchronization method applied to the TSP side is provided;

[0047] Figure 6 This is a flow chart of the method for synchronizing the APP and the vehicle OTA software version, which is applied to the third embodiment of the mobile terminal.

[0048] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0049] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0050] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0051] The main solution of the embodiment of the present application is: configure the upgrade strategy and the initial synchronization version relationship table; create and push the upgrade task to the TSP end according to the upgrade strategy, so that the TSP end pushes the upgrade task to the vehicle end, and receives the upgrade success information fed back by the vehicle end, and the upgrade success information is that the vehicle end executes the upgrade according to the upgrade task and feeds back after the upgrade is successful; receive the APP version matching verification request sent by the TSP end, and control the synchronization of the whole vehicle OTA version and the APP version according to the APP version matching verification request; push the initial synchronization version relationship table to the TSP end according to the upgrade information, so that the TSP end controls the synchronization of the APP version and the whole vehicle OTA version.

[0052] In the current field of intelligent connected vehicles, with the rapid development of OTA technology, vehicle software upgrades have become the norm, bringing continuous functional updates and experience optimization to users. However, this frequent software upgrade also brings new problems, especially in the synchronization of mobile phone car APP and vehicle-side OTA software versions. In the traditional mode, car APP and vehicle software often exist as independent systems, updated separately, and lack an effective synchronization mechanism. When the vehicle is upgraded to add or repair functions through OTA, if the mobile phone APP fails to update synchronously, the user will not be able to experience the new functions or correctly operate the repaired functions on the mobile phone, which will seriously affect the user experience. Conversely, if the mobile phone APP is upgraded first and the vehicle software is not synchronized, it may also cause functional mismatch problems. In addition, due to the differences in the upgrade progress of different user groups after the vehicle is put on the market, the same model may have multiple different versions of OTA software on the market at the same time. This complexity further exacerbates the difficulty of synchronizing the mobile phone APP with the vehicle-side software version. Therefore, how to ensure that the mobile phone APP and the vehicle OTA software are always consistent at the functional level is a problem that needs to be solved urgently.

[0053] This application solves the problem of how to ensure that the mobile phone APP and the vehicle OTA software are always consistent at the functional level by monitoring the version status of the vehicle OTA software and the mobile phone APP in real time, and automatically triggers the synchronous update process on the other end when the version on either end is updated, thereby improving the user's smart car experience.

[0054] It should be noted that the execution subject of this embodiment can be an APP and vehicle OTA software version synchronization system, or a computing service device with data processing, network communication and program running functions, such as a tablet computer, personal computer, mobile phone, etc., or an electronic device that can realize the above-mentioned APP and vehicle OTA software version synchronization function, etc., and this embodiment does not specifically limit this. The following takes the APP and vehicle OTA software version synchronization system as an example to illustrate this embodiment and the following embodiments.

[0055] Based on this, the embodiment of the present application provides a method for synchronizing the APP with the vehicle OTA software version. Figure 1 , Figure 1 This is a flow chart of the first embodiment of the method for synchronizing the APP and the vehicle OTA software version.

[0056] In this embodiment, the APP and vehicle OTA software version synchronization method is applied to the OTA service platform, including steps S10 to S40:

[0057] Step S10: Configure the upgrade strategy and the initial synchronization version relationship table.

[0058] It should be noted that if Figure 2 As shown, in this step, the system will configure the upgrade strategy and the initial synchronization version relationship table according to the pre-designed configuration information. The administrator of the OTA service platform can log in to the platform, enter the configuration interface, and perform custom configuration. Among them, the configuration upgrade strategy includes defining the upgrade relationship between the mobile phone APP and the vehicle OTA version in different situations. There are three main situations: both the vehicle OTA version and the mobile phone APP version need to be upgraded, only the vehicle OTA version needs to be upgraded, and only the mobile phone APP version needs to be upgraded. The system will set the corresponding upgrade strategy according to these situations, including specifying which versions need to be upgraded, the specific content of the upgrade, and the time node of the upgrade. At the same time, the system will also establish an initial synchronization version relationship table, which records the current vehicle-side OTA version and mobile phone APP version corresponding relationship of different models or different batches of vehicles. For example, suppose the current vehicle-side OTA version of a certain model is 1.0.0, and the mobile phone APP version is also 1.0.0. When the vehicle-side OTA version is upgraded to 1.1.0, if the new version involves interactive functions with the mobile phone APP, then the system will specify in the upgrade strategy that the mobile phone APP also needs to be upgraded to the corresponding version (such as 1.1.0) and update this corresponding relationship in the synchronization version relationship table.

[0059] Step S20: Create and push an upgrade task to the TSP end according to the upgrade strategy, so that the TSP end pushes the upgrade task to the vehicle end and receives the upgrade success information fed back by the vehicle end. The upgrade success information is the vehicle end executing the upgrade according to the upgrade task and fed back after the upgrade is successful.

[0060] It should be noted that if Figure 3 As shown in the figure, in this step, once the upgrade strategy configuration is completed, the OTA service platform will automatically or manually create upgrade tasks according to the strategy. These tasks include the upgraded vehicle-side OTA version, mobile phone APP version, and the time and method of the upgrade. After the upgrade task is created, the OTA service platform will push the task to the TSP. After receiving the task, the TSP will push the upgrade package to the specified vehicle according to the information in the task and monitor the upgrade process. After the vehicle receives the upgrade package, it will perform the upgrade operation and feedback the upgrade success information to the OTA service platform after the upgrade is successful.

[0061] In addition, it should be noted that security and stability are very important during the upgrade process. Therefore, before pushing the upgrade task, the OTA service platform will conduct strict testing and verification to ensure the effectiveness and security of the upgrade package.

[0062] Step S30: receiving the APP version matching verification request sent by the TSP, and controlling the synchronization of the vehicle OTA version and the APP version according to the APP version matching verification request.

[0063] It should be noted that if Figure 4 As shown, this step is to ensure that the mobile phone APP is synchronized with the vehicle OTA software version. Specifically, when the mobile phone APP detects a new version, it will send an APP version matching verification request to the TSP end. After receiving the request, the TSP end will forward this request to the OTA service platform. After receiving the request, the OTA service platform will compare the current vehicle-side OTA version and the mobile phone APP version according to the synchronization version relationship table. If the two versions are consistent, it means that they have been synchronized; if the versions are inconsistent, the whole vehicle OTA version and APP version are controlled to be synchronized according to the upgrade strategy. If the vehicle-side OTA version needs to be upgraded, the process of step S20 is repeated; if only the mobile phone APP version needs to be upgraded, an update instruction is sent to the mobile phone APP through the TSP end. For example, when the mobile phone APP is upgraded from 1.0.0 to 1.1.0, if the vehicle-side OTA version is still 1.0.0, the mobile phone APP will send an APP version matching verification request to the TSP end. The TSP end forwards the request to the OTA service platform. After comparing, the OTA service platform finds that the versions are inconsistent, so it sends instructions to the TSP end according to the upgrade strategy, requiring the vehicle-side OTA version to be upgraded to 1.1.0. The TSP will then forward this command to the vehicle to perform the upgrade operation. At the same time, the mobile phone APP will also be updated to version 1.1.0 through the application market or other means.

[0064] It can be understood that this step can effectively achieve the synchronization matching between the mobile phone APP and the OTA software version of the whole vehicle, ensuring the functional consistency between the vehicle and the mobile phone APP and the continuity of the user experience.

[0065] In a feasible implementation manner, the step S30 specifically includes:

[0066] Step S301: upon receiving the APP version matching verification request sent by the TSP, obtaining an updated APP version number according to the APP version matching verification request.

[0067] It should be noted that the APP version matching verification request contains the updated APP version number, that is, the target APP version number that needs to be updated. Specifically, when the OTA service platform (i.e., OTA-Server) receives the APP version matching verification request from the TSP (remote service provider), the OTA service platform will first parse the request and extract the updated APP version number from it.

[0068] Step S302: query the updated OTA version number corresponding to the updated APP version number according to the initial synchronization version relationship table.

[0069] It should be noted that the OTA service platform maintains an initial synchronization version relationship table, which records the matching relationship between different APP versions and corresponding OTA versions. After obtaining the updated APP version number, the OTA service platform will use the version number to query the corresponding updated OTA version number in the initial synchronization version relationship table. For example, if the updated APP version number is 1.1.1, the OTA management platform will look for the OTA version number (such as 1.2.0) corresponding to the version number in the initial synchronization version relationship table. If a matching OTA version number is found, the subsequent process continues; if no match is found, it means that there may be a configuration error or the new version of the APP has not yet been registered in the platform, and corresponding processing is required.

[0070] It can be understood that this step can ensure that the update of the APP version is consistent with the update of the vehicle OTA version, avoiding functional abnormalities caused by version mismatch.

[0071] Step S303: Receive the actual vehicle OTA version number fed back by the vehicle side, obtain the OTA version matching status according to the actual vehicle OTA version number and the updated OTA version number, and push the OTA version matching status to the TSP side, so that the TSP side controls the synchronization of the vehicle OTA version and the APP version.

[0072] It should be noted that after querying the updated OTA version number, the OTA management platform needs to wait for the vehicle side (i.e., smart car) to feedback the current OTA version number of the actual vehicle. Once the actual vehicle OTA version number fed back by the vehicle side is received, the OTA service platform will compare the version number with the updated OTA version number queried in step S302. If the two are consistent, it means that the vehicle-side software is already the latest version and no upgrade is required; if they are inconsistent, it means that the vehicle-side software needs to be upgraded. Based on the comparison results, the OTA service platform generates an OTA version matching status (such as "matched" or "unmatched") and sends the status to the TSP.

[0073] Step S40: Pushing the initial synchronization version relationship table to the TSP end according to the upgrade information, so that the TSP end controls the synchronization of the APP version with the vehicle OTA version.

[0074] It should be noted that if Figure 3 and Figure 4 As shown in the figure, after the vehicle completes the OTA upgrade or the mobile phone APP version is updated, the OTA service platform will update the internal initial synchronization version relationship table according to the latest upgrade information. Then, the updated version relationship table is pushed to the TSP end so that the TSP end can grasp the latest version correspondence. After receiving the new version relationship table, the TSP end will control the synchronization of the APP version and the vehicle OTA version according to the information in the table to ensure that the two always keep matching.

[0075] In a feasible implementation manner, the step S40 specifically includes:

[0076] Step S401: Obtain task push time.

[0077] It should be noted that the task push time is automatically set by the OTA service platform after the vehicle OTA upgrade strategy and mobile APP version update are configured, based on the pre-set push plan or user trigger conditions (such as the release time of the new version). This time can ensure that the vehicle and APP are upgraded in the most suitable time period to reduce the impact on the normal use of users.

[0078] It is understandable that this step can ensure that the upgrade task can be pushed smoothly according to the scheduled plan and avoid delays or conflicts caused by improper time setting.

[0079] Step S402: Determine the task validity period and the vehicle identification code according to the upgrade strategy.

[0080] It should be noted that in this step, the upgrade strategy not only contains the upgraded version information, but also specifies the validity period of the task and the scope of applicable vehicles. The validity period of the task refers to the time period from the start of the task push to the end of the task, which can ensure that the upgrade task is completed in a reasonable time period and avoid problems caused by expired upgrades. VIN (Vehicle identification number) is a unique identifier for each car, which is used to accurately identify vehicles that need to be upgraded. For example, the upgrade strategy stipulates that the validity period of a certain upgrade task is 7 days, and it is applicable to all vehicles whose 4th digit in the VIN code is L. When creating an upgrade task, the system will filter out qualified vehicles based on these conditions.

[0081] Step S403: creating an upgrade task according to the task validity period and the vehicle identification code.

[0082] It should be noted that once the task push time, task validity period and vehicle identification code are obtained, the OTA service platform will automatically create the corresponding upgrade task. These tasks contain all necessary upgrade information, such as target version, upgrade file link, upgrade instructions, etc., and mark the task validity period and applicable vehicle range.

[0083] Step S404: Pushing the upgrade task to the TSP end according to the task push time.

[0084] It should be noted that in this step, when the task push time arrives, the OTA service platform will automatically push the created upgrade task to the TSP. As a bridge connecting the vehicle and the OTA service platform, the TSP is responsible for receiving and forwarding the upgrade task to the target vehicle. For example, at the scheduled time of 22:00 in the evening, the OTA service platform pushes the created upgrade task to the TSP. After receiving the task, the TSP will immediately parse and process it and forward the upgrade task to the target vehicle to be upgraded.

[0085] In a feasible implementation manner, after step S40, the method further includes:

[0086] Step S50: When receiving the information that the vehicle-side OTA upgrade has failed, recreate and push the upgrade task to the TSP side to ensure that the vehicle-side OTA upgrade operation is successfully executed.

[0087] It should be noted that in this step, the system will also consider possible failures during the OTA upgrade process on the vehicle side. When the vehicle side is performing the OTA upgrade operation, if the upgrade fails due to network problems, insufficient power, insufficient storage space or other technical failures, the TSP side will receive the corresponding failure information and feedback to the OTA service platform. After receiving the information about the failed upgrade, the OTA service platform will first analyze the cause of the failure. If the cause can be eliminated (such as the network problem has been restored, the power has been replenished, etc.), the OTA service platform will recreate the upgrade task and push it to the TSP side again. After receiving the new upgrade task, the TSP side will re-initiate the upgrade process to ensure that the vehicle side can successfully complete the OTA upgrade operation. For example: Assume that the OTA version of a certain model of vehicle is 1.2.0, and the corresponding mobile phone APP version should be 1.1.1. This relationship has been clearly recorded in the initial synchronization relationship table. However, when pushing the upgrade task to the vehicle to perform the OTA upgrade, the upgrade process is interrupted because the vehicle is in a low power state. The TSP side immediately receives the upgrade failure information and feeds it back to the OTA service platform. After analysis, the OTA service platform confirmed that the upgrade failed due to power issues and prompted the user to charge the vehicle. After the vehicle had sufficient power, the OTA service platform re-created the upgrade task and pushed it to the TSP again. The TSP initiated an upgrade request to the vehicle again, and the vehicle successfully completed the OTA upgrade to version 1.2.0. At the same time, the TSP also ensured that the APP version in the user's mobile phone was updated to 1.1.1, realizing the synchronization of the APP and the vehicle software.

[0088] This embodiment provides a method for synchronizing the APP with the OTA software version of the whole vehicle. This embodiment configures the upgrade strategy and the initial synchronization version relationship table; creates and pushes the upgrade task to the TSP end according to the upgrade strategy, so that the TSP end pushes the upgrade task to the vehicle end, and receives the upgrade success information fed back by the vehicle end, the upgrade success information is the vehicle end performing the upgrade according to the upgrade task and feedback after the upgrade is successful; receives the APP version matching verification request sent by the TSP end, and controls the synchronization of the whole vehicle OTA version and the APP version according to the APP version matching verification request; pushes the initial synchronization version relationship table to the TSP end according to the upgrade information, so that the TSP end controls the synchronization of the APP version and the whole vehicle OTA version. In summary, this embodiment solves the problem of how to ensure that the mobile phone APP and the whole vehicle OTA software are always consistent at the functional level by monitoring the version status of the vehicle OTA software and the mobile phone APP in real time, and automatically triggers the synchronization update process of the other end when the version of either end is updated, thereby improving the user's smart car experience.

[0089] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can refer to the above introduction, and will not be repeated later. Figure 5 , Figure 5 This is a flow chart of the method for synchronizing the APP and vehicle OTA software versions, applied to the second embodiment of the TSP end.

[0090] In this embodiment, the APP and vehicle OTA software version synchronization method is applied to the TSP side, including steps A10 to A50:

[0091] Step A10: Receive the upgrade task, OTA version matching status and initial synchronization version relationship pushed by the OTA service platform.

[0092] It should be noted that the TSP has a communication connection with the OTA service platform to receive various messages from the OTA service platform in real time. When the OTA service platform detects a software upgrade requirement, it will generate a corresponding upgrade task and push it to the TSP together with the OTA version matching status and the initial synchronization version relationship table. After receiving these messages, the TSP will parse them and extract the upgrade task, OTA version matching status and initial synchronization version relationship based on the message content.

[0093] Step A20: Push the upgrade task to the vehicle end so that the vehicle end performs the upgrade operation.

[0094] It should be noted that in this step, after receiving the upgrade task from the OTA service platform, the TSP will immediately send this task and related information (such as OTA version number, upgrade package, etc.) to the vehicle-side main control unit of the target vehicle through a wireless communication network (such as 4G / 5G, Wi-Fi, etc.). After receiving the upgrade task, the vehicle-side main control unit will parse and execute it according to the preset upgrade process, including but not limited to downloading the upgrade package, verifying the integrity of the upgrade package, and performing installation operations.

[0095] Step A30: Obtain the APP version matching status according to the initial synchronization version relationship table.

[0096] It should be noted that in this step, after receiving the upgrade success message reported by the vehicle, the TSP will determine whether the current mobile phone APP version matches the vehicle-side OTA version based on the previously received synchronization version relationship table. Specifically, the TSP first queries the initial synchronization version relationship table to find the APP version number corresponding to the current vehicle-side OTA version. Then, the TSP will compare this version number with the current actual version number of the mobile phone APP. If the two are consistent, it means that the APP version matches; if they are inconsistent, it means that the APP version needs to be updated.

[0097] In addition, it should be noted that the initial synchronization version relationship table is dynamically updateable to meet the upgrade requirements of different models and versions. The TSP will regularly synchronize the latest relationship table information with the OTA service platform to ensure the accuracy and timeliness of version matching.

[0098] Step A40: Control the vehicle-side OTA version synchronization update according to the OTA version matching status.

[0099] It should be noted that in this step, the system will determine whether an OTA upgrade operation needs to be performed based on the OTA version matching status. If it is confirmed that an upgrade is required, the TSP will push the upgrade task to the vehicle OTA main control unit. During the push process, the TSP will record the push status to ensure that the task can be successfully delivered. After the vehicle OTA main control unit receives the upgrade task, it starts to execute the upgrade operation.

[0100] In a feasible implementation manner, the step A40 specifically includes:

[0101] Step A401: When the OTA version matching state is an unmatched state, an OTA version update request is sent to the mobile terminal, so that the mobile terminal controls the vehicle end to complete the OTA version synchronization update according to the OTA version update request.

[0102] It should be noted that when the vehicle-side OTA version is inconsistent with the OTA version configured by the platform, that is, it is in an unmatched state, the OTA service platform will generate an OTA version update request based on the matching status. This request contains relevant information such as the OTA version number and vehicle identification number (VIN) that need to be updated so that the mobile terminal can recognize and process the request. After receiving the OTA version update request, the mobile terminal will control the vehicle OTA to perform the upgrade operation, including downloading the new OTA software package, installation and verification steps. After the installation is complete, the vehicle OTA main control unit will report the successful upgrade information to the TSP.

[0103] Step A50: Control the synchronous update of the mobile terminal APP version according to the APP version matching status.

[0104] It should be noted that in this step, the system will determine whether the APP upgrade operation needs to be performed based on the APP version matching status. If it is confirmed that an upgrade is required, TSP will send an update notification to the mobile APP based on the update request sent by the mobile APP (such as the user clicking the update button), or TSP will actively push the update notification to the mobile APP. After receiving the update notification, the mobile APP will download the new APP software package from the TSP or the designated server and perform the installation operation.

[0105] In addition, it should be noted that mobile terminal APP refers to the mobile terminal application program that is compatible with the intelligent network-connected car, which provides users with services such as remote control, status query, function setting, etc. Mobile terminals include mobile phones, notebooks, and tablet computers.

[0106] In a feasible implementation manner, the step A50 specifically includes:

[0107] Step A501: When the APP version matching state is an unmatched state, a target APP version number is sent to a mobile terminal, so that the mobile terminal completes the APP version synchronization update according to the target APP version number.

[0108] It should be noted that after confirming that the APP version matching status is an unmatched state, the TSP will send the target APP version number to the user's mobile terminal through its communication channels (such as mobile network, Wi-Fi, etc.) based on the target matching APP version number provided by the OTA service platform. After the mobile terminal receives the target APP version number sent by the TSP, it will trigger the APP update mechanism. If the APP supports automatic updates, it will directly download and install the new version; if the user needs to manually confirm, the APP will display an update prompt to guide the user to complete the update operation. After the mobile terminal APP completes the update, it will send a feedback message of successful update to the TSP. After receiving this message, the TSP will update the vehicle OTA version and mobile terminal APP version records in its system to ensure consistency between the two.

[0109] In this embodiment, through the centralized coordination of TSP and the judgment of the matching status of OTA and APP versions, remote and automatic synchronous updating of the vehicle OTA version and the mobile phone APP version is achieved, which improves the efficiency and accuracy of the synchronous upgrading of vehicle software and provides users with a more timely and convenient update experience.

[0110] Based on the first and second embodiments of the present application, in the third embodiment of the present application, the same or similar contents as those in the first and second embodiments can be referred to the above description, and will not be described in detail later. Figure 6 , Figure 6 This is a flow chart of the method for synchronizing the APP and the vehicle OTA software version, which is applied to the third embodiment of the mobile terminal.

[0111] In this embodiment, the method for synchronizing the APP and the vehicle OTA software version is applied to a mobile terminal, including steps B10 to B20:

[0112] Step B10: When a new version of the APP is detected in the application market, an update request is sent to the TSP through the vehicle identification code, so that the TSP can feedback an OTA version update request. The OTA version update request is obtained after the TSP sends an OTA version matching verification request to the OTA service platform and receives the OTA version matching result fed back by the OTA service platform.

[0113] It should be noted that if Figure 4As shown in the figure, when the application market of the mobile terminal detects that a new mobile terminal APP version has been released, the mobile terminal APP will automatically or under the user's trigger to perform version detection. If it is determined that a new version exists, the mobile terminal APP first obtains the vehicle identification code (VIN), which is the unique identifier of the vehicle and is used to distinguish different vehicles. Subsequently, the mobile terminal APP sends an update request to the TSP through the network (such as 4G / 5G, Wi-Fi, etc.), and the request contains the VIN of the current vehicle. After the TSP receives the update request from the mobile phone APP, it will send an OTA version matching verification request to the OTA service platform based on the VIN information. It is used to verify whether the OTA version of the current vehicle is compatible with the new version of the mobile terminal APP or whether it needs to be updated synchronously. The OTA service platform determines whether the OTA version of the current vehicle has matched the new version of the mobile terminal APP by querying the stored OTA version and mobile terminal APP version relationship table. For example, suppose that the mobile terminal APP has released a new version (1.1.1), and the OTA version of the current vehicle is 1.2.0. After the mobile terminal APP detects the new version, it sends an update request to the TSP through the VIN. TSP then sends a matching verification request to the OTA service platform. If the OTA service platform reports that the OTA version (1.2.0) has matched the new version (1.1.1) of the mobile terminal APP, TSP will not initiate an OTA version update request. If there is no match, TSP will initiate an OTA version update request to ensure that the vehicle OTA version is synchronized with the mobile terminal APP version.

[0114] In addition, it should be noted that the correspondence between the OTA version and the APP version can be a one-to-one relationship, or a one-to-many or many-to-one relationship, depending on the corresponding requirements of the software functions.

[0115] Step B20: When receiving the OTA version update request fed back by the TSP, prompt the user to perform OTA upgrade according to the OTA version update request.

[0116] It should be noted that, specifically, when the mobile terminal APP receives the OTA version update request fed back by the TSP, it means that the OTA version of the current vehicle does not match the new version of the mobile terminal APP, and an OTA upgrade is required to synchronize the versions. At this time, the mobile terminal APP will pop up an upgrade prompt on the user interface, informing the user that a new version of the OTA upgrade is available, and prompting the user to perform the upgrade operation. For example, the mobile phone APP interface will display a prompt message saying "A new version of OTA upgrade has been found, please click to upgrade now to ensure functional synchronization." Users can choose the option of "upgrade now" or "book an upgrade." If the user chooses "upgrade now", the mobile phone APP will interact with the OTA service platform through the TSP to download and install the latest OTA upgrade package to the vehicle; if you choose "book an upgrade", the upgrade operation can be automatically performed at the preset time.

[0117] In a feasible implementation manner, after step B20, the method further includes:

[0118] Step B30: receiving an upgrade instruction input by the user.

[0119] It should be noted that the upgrade instruction refers to the operation instruction entered by the user through the APP interface, indicating the willingness to perform OTA upgrade. Specifically, after the user sees the OTA upgrade prompt and makes a choice, the APP will receive the user's input instruction. The input instruction includes two instructions: immediate upgrade and scheduled upgrade.

[0120] Step B40: Determine the upgrade type according to the upgrade instruction.

[0121] It should be noted that after receiving the user's upgrade instruction, the APP will determine the specific upgrade type based on the currently received upgrade instruction. For example, if the upgrade instruction is an immediate upgrade instruction, the regular OTA upgrade process is executed; if the upgrade instruction is a scheduled upgrade, it is determined to be an OTA scheduled upgrade process. It can be understood that the role of this step is to clarify the specific type of upgrade in order to perform subsequent upgrade operations.

[0122] Step B50: Sending a corresponding OTA version upgrade request to the TSP according to the upgrade type.

[0123] It should be noted that after determining the upgrade type, the mobile terminal will send the corresponding OTA version upgrade request to the TSP according to the type. The request contains detailed information required for the upgrade, such as the target OTA version number, vehicle VIN code, and upgrade time. After receiving the request, the TSP will further process it and push the upgrade task to the vehicle for OTA upgrade.

[0124] In this embodiment, through intelligent version matching verification, transparent user prompts and scheduled upgrade methods, the customization of synchronous upgrades is achieved, and the flexibility and convenience of synchronous upgrade matching are improved.

[0125] In addition, the present application also provides an APP and vehicle OTA software version synchronization system, and the APP and vehicle OTA software version synchronization system includes the OTA service platform, TSP terminal and mobile terminal mentioned above. The APP and vehicle OTA software version synchronization system provided in the present application adopts the APP and vehicle OTA software version synchronization method in the above embodiment, which can solve the technical problem of how to ensure that the mobile phone APP and the vehicle OTA software always remain consistent at the functional level. Compared with the prior art, the beneficial effects of the APP and vehicle OTA software version synchronization system provided in the present application are the same as the beneficial effects of the APP and vehicle OTA software version synchronization method provided in the above embodiment, and the other technical features of the APP and vehicle OTA software version synchronization device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0126] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0127] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0128] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0129] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0130] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for synchronizing APP and vehicle OTA software version, characterized in that: The method is applied to an OTA service platform, and the method includes: Configure the upgrade strategy and initial synchronization version relationship table; Create and push an upgrade task to the TSP end according to the upgrade strategy, so that the TSP end pushes the upgrade task to the vehicle end, and receives upgrade success information fed back by the vehicle end, wherein the upgrade success information is the vehicle end performing the upgrade according to the upgrade task and fed back after the upgrade is successful; Receive the APP version matching verification request sent by the TSP, and control the synchronization of the vehicle OTA version and the APP version according to the APP version matching verification request; The initial synchronization version relationship table is pushed to the TSP end according to the upgrade information, so that the TSP end controls the synchronization of the APP version with the vehicle OTA version.

2. The method according to claim 1, characterized in that The step of receiving the APP version matching verification request sent by the TSP end, and controlling the synchronization of the vehicle OTA version and the APP version according to the APP version matching verification request includes: Upon receiving the APP version matching verification request sent by the TSP, obtaining an updated APP version number according to the APP version matching verification request; Query the updated OTA version number corresponding to the updated APP version number according to the initial synchronization version relationship table; Receive the actual vehicle OTA version number fed back by the vehicle side, obtain the OTA version matching status according to the actual vehicle OTA version number and the updated OTA version number, and push the OTA version matching status to the TSP side, so that the TSP side controls the synchronization of the entire vehicle OTA version and the APP version.

3. The method according to claim 1, characterized in that The step of creating and pushing the upgrade task to the TSP end according to the upgrade strategy includes: Get the task push time; Determine the mission validity period and vehicle identification code according to the upgrade strategy; Creating an upgrade task according to the task validity period and the vehicle identification code; The upgrade task is pushed to the TSP end according to the task push time.

4. The method according to claim 1, characterized in that After the step of creating and pushing the upgrade task to the TSP end according to the upgrade strategy, the method further includes: When receiving information that the vehicle-side OTA upgrade has failed, recreate and push the upgrade task to the TSP side to ensure that the vehicle-side OTA upgrade operation is successfully executed.

5. A method for synchronizing a mobile phone APP with an OTA software version, characterized in that: The method is applied to the TSP end, and the method includes: Receive upgrade tasks, OTA version matching status, and initial synchronization version relationship pushed by the OTA service platform; Pushing the upgrade task to the vehicle end so that the vehicle end performs the upgrade operation; Obtaining the APP version matching status according to the initial synchronization version relationship table; Control the vehicle-side OTA version synchronization update according to the OTA version matching status; The mobile terminal APP version is controlled to be updated synchronously according to the APP version matching status.

6. The method according to claim 5, characterized in that The step of controlling the vehicle-side OTA version synchronous update according to the OTA version matching status includes: When the OTA version matching state is an unmatched state, an OTA version update request is sent to the mobile terminal, so that the mobile terminal controls the vehicle end to complete the OTA version synchronous update according to the OTA version update request.

7. The method according to claim 5, characterized in that The step of controlling the synchronous update of the mobile terminal APP version according to the APP version matching status includes: When the APP version matching state is an unmatched state, a target APP version number is sent to the mobile terminal, so that the mobile terminal completes the APP version synchronization update according to the target APP version number.

8. A method for synchronizing a mobile phone APP with an OTA software version, characterized in that: The method is applied to a mobile terminal, and the method comprises: When a new version of APP is detected in the application market, an update request is sent to the TSP end through the vehicle identification code, so that the TSP end feeds back an OTA version update request, and the OTA version update request is obtained after the TSP end sends an OTA version matching verification request to the OTA service platform and receives the OTA version matching result fed back by the OTA service platform; When the OTA version update request fed back by the TSP is received, the user is prompted to perform OTA upgrade according to the OTA version update request.

9. The method according to claim 8, characterized in that After the step of prompting the user to perform OTA upgrade according to the OTA version update request when receiving the OTA version update request fed back by the TSP, the method further includes: Receive upgrade instructions input by the user; Determine the upgrade type according to the upgrade instruction; Send a corresponding OTA version upgrade request to the TSP according to the upgrade type.

10. A system for synchronizing APP and vehicle OTA software versions, characterized in that: The APP and vehicle OTA software version synchronization system includes the OTA service platform described in any one of claims 1-4, the TSP terminal described in any one of claims 5-7, and the mobile terminal described in any one of claims 8-9.

Images