Vehicle application upgrade method and device

Abstract

Embodiments of the present application provide a vehicle application upgrade method and device, a software remote upgrade service engine includes a state machine manager and a state machine corresponding to each application, the state machine manager is used for receiving a message sent by a service and distributing the message to the state machine corresponding to each application, and the state machine is used for driving each application according to a driving behavior corresponding to the message, the method includes in the case of receiving an upgrade message of a target application sent by the state machine manager, detecting a current state of the target application, receiving event information in the current state, the event information including information of an event generated in the process of upgrading the target application, and migrating the target application from the current state to a target state when processing the event in the current state of the target application, so as to complete the upgrade of the target application. According to the embodiments of the present application, the application can be taken as an upgrade object, the upgrade object can be more finely controlled, and the SOTA process of the application can be more accurately and efficiently implemented.

Description

Technical Field

[0001] This application belongs to the field of remote vehicle upgrades, and particularly relates to a method and apparatus for upgrading vehicle applications. Background Technology

[0002] Currently, software-over-the-air (SOTA) solutions are mainly implemented based on the service-oriented architecture (SOA) of the Automotive Open System Architecture (Auto SAR).

[0003] However, the SOTA technology implemented based on the SOA architecture of AntoSAR provides technical support for remote upgrades of the software packages of various Electronic Control Units (ECUs) in the vehicle. The object of the upgrade is the ECU software package. The above SOTA upgrade method is a software upgrade for the entire ECU. However, the sub-functions provided by each ECU are diverse. One ECU can control multiple software. Therefore, the above solution cannot achieve more precise control over the upgrade object. Summary of the Invention

[0004] This application provides a method and apparatus for upgrading vehicle applications, which can solve the problem that the existing SOTA upgrade method is a software upgrade for the entire ECU, while the sub-functions provided by each ECU are diverse, and one ECU can control multiple software. Therefore, the above solutions have the problem of not being able to achieve more precise control over the upgrade object.

[0005] In a first aspect, embodiments of this application provide a method for upgrading a vehicle application, the method being applied to a state machine, the method comprising:

[0006] Upon receiving an upgrade message for the target application from the state machine manager, the current state of the target application is detected, and event information in the current state is received. This event information includes information about events generated during the upgrade process of the target application.

[0007] When processing events in the current state of the target application, the target application is migrated from its current state to the target state to complete the upgrade of the target application.

[0008] In one implementation, the current state includes a state with no available updates, the event information includes information on querying available updates events and timeout events for the state with no available updates, and the target state includes a querying available upgrade state. When processing events in the current state of the target application, the target application is migrated from the current state to the target state, including:

[0009] When processing query available update events and / or no available update state timeout events in the target application's no available update state, the target application is migrated from the no available update state to the query available upgrade state, and the no available update state timeout event is cleared from the state machine's buffer in the case of processing the no available update state timeout event.

[0010] In one implementation, the current state includes a state with no available updates, the event information includes information about proactive push events for new versions, and the target state includes a state awaiting user confirmation for download. When processing events in the current state of the target application, the target application is migrated from the current state to the target state, and the implementation further includes:

[0011] When handling proactive push events for new versions of the target application while the target application is in a state where no updates are available, the target application is migrated from a state where no updates are available to a state where the user confirms the download.

[0012] In one implementation, the current state includes querying available upgrade status, and the event information includes information on new version detection events, new version proactive push events, no new version detection events, and querying available upgrade status timeout events. The target state includes a waiting-for-user-confirmation-download state and a no-update-available state. When processing events in the current state of the target application, the target application is migrated from the current state to the target state, which further includes:

[0013] When handling events such as "new version detected" and / or "new version push notification" for the target application while it is in the "upgrade available" state, the target application will be moved from the "upgrade available" state to the "awaiting user confirmation for download" state.

[0014] When handling the "No new version detected" event and / or "Query available upgrade state timeout" event in the target application's "Query available upgrade state", the target application is migrated from the "Query available upgrade state" to the "No available update" state, and the "Query available upgrade state timeout" event is cleared from the state machine's buffer in the case of handling the "Query available upgrade state timeout" event.

[0015] In one implementation, the current state includes a waiting-for-user-confirmation-download status, and the event information includes information on a new version push event and a timeout event for the waiting-for-user-confirmation-download status. The method further includes:

[0016] When handling proactive push events for new versions and / or timeout events for waiting for user confirmation to download in the target application's waiting-for-user-confirmation-download state, maintain the current state as waiting for user confirmation to download, and clear the waiting-for-user-confirmation-download-timeout event from the state machine's buffer when handling the waiting-for-user-confirmation-download-timeout event.

[0017] In one implementation, the current state includes a waiting-for-user-confirmation-download state, the event information includes information about an event in which the user confirms the download of a new version, and the target state includes a download policy check state. When processing events in the current state of the target application, the target application is migrated from the current state to the target state. The implementation also includes:

[0018] When processing the user confirmation download event in the target application's waiting-for-user-confirmation-download state, the target application is transitioned from the waiting-for-user-confirmation-download state to the download policy check state, and the user confirmation download event in the state machine's buffer is cleared.

[0019] In one implementation, the current state includes a download policy check state, the event information includes information about download precondition check passing events, and the target state includes a state of downloading. When processing events in the current state of the target application, the target application is transitioned from the current state to the target state. The implementation further includes:

[0020] When processing the download precondition check pass event in the download policy check state of the target application, the target application is transitioned from the download policy check state to the download in progress state, and the download precondition check pass event in the state machine's buffer is cleared.

[0021] In one implementation, the current state includes a download policy check state, and the event information includes information on download precondition check failure events, download policy check state timeout events, and download precondition check retry events. The method further includes:

[0022] When handling download precondition check failure events and / or download policy check timeout events in the target application's download policy check state, obtain the state machine's configuration information, including the number of retries and the retry period for the download precondition check.

[0023] If the number of retries is not zero, decrement the number of retries by 1, and use the retry period as a delay to process the download preconditions for checking retry events.

[0024] Maintain the target application's current state as the download policy check state, and clear the download precondition check failure event, download policy check timeout event, and download precondition check retry event from the state machine's buffer.

[0025] When the number of retries is 0, the target application is transitioned from the download policy check state to the waiting for user confirmation state, the number of retries is reset to the target number, and the download precondition check failure event and the download policy check state timeout event are cleared from the state machine's buffer.

[0026] In one implementation, the current state includes a download in progress state, the event information includes information about a successful download event, and the target state includes a state awaiting user confirmation for an upgrade. When processing events in the current state of the target application, the application is migrated from the current state to the target state. The implementation also includes:

[0027] When handling a successful download event while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-upgrade state.

[0028] In one implementation, the current state includes a download in progress state, and the event information includes download failure events, download in progress timeout events, and user-cancelled download events. The target state includes a waiting-for-user-confirmation-result state and a waiting-for-user-confirmation-download state. When processing events in the target application's current state, the target application is transitioned from the current state to the target state, which further includes:

[0029] When handling download failure events and / or download timeout events in the target application's download in progress state, the target application is transitioned from the download in progress state to the state awaiting user confirmation. Furthermore, in the case of a download timeout event, the download timeout event is cleared from the state machine's buffer.

[0030] When handling user cancel download events while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-download state, and the user cancel download event is cleared from the state machine's buffer.

[0031] In one implementation, the current state includes a state awaiting user confirmation for an upgrade, and the event information includes information on user confirmation of installation events and user cancellation of new version installation events. The target state includes an upgrade policy check state and a state awaiting user confirmation for a download. When processing events in the current state of the target application, the target application is migrated from the current state to the target state, and the process further includes:

[0032] When processing user confirmation installation events in the target application's "waiting for user confirmation upgrade" state, the target application is transitioned from the "waiting for user confirmation upgrade" state to the "upgrade policy check" state, and the user confirmation installation events in the state machine's buffer are cleared.

[0033] When handling user cancellation of new version installation events in the target application's waiting-for-user-confirmation-upgrade state, the target application is transitioned from the waiting-for-user-confirmation-upgrade state to the waiting-for-user-confirmation-download state, and the user cancellation of new version installation events in the state machine's buffer is cleared.

[0034] In one implementation, the current state includes a state awaiting user confirmation of the upgrade, and the event information includes information about timeout events related to the state awaiting user confirmation of the upgrade. The method further includes:

[0035] When handling timeout events for the "waiting for user confirmation to upgrade" state in the target application, maintain the target application's current state as "waiting for user confirmation to upgrade" and clear the timeout events for "waiting for user confirmation to upgrade" from the state machine's buffer.

[0036] In one implementation, the current state includes an upgrade policy check state, the event information includes information about upgrade precondition check passing events, and the target state includes a state of performing an upgrade. When processing events in the current state of the target application, the target application is migrated from the current state to the target state. The implementation further includes:

[0037] When processing the upgrade precondition check pass event in the upgrade policy check state of the target application, the target application is transitioned from the upgrade policy check state to the state of executing upgrade, and the upgrade precondition check pass event in the state machine's buffer is cleared.

[0038] In one implementation, the current state includes an upgrade policy check state, and the event information includes information on upgrade precondition check failure events, upgrade policy check state timeout events, and upgrade precondition check retry events. The method further includes:

[0039] When handling upgrade precondition check failure events and / or upgrade strategy check timeout events in the target application's upgrade strategy check state, obtain the state machine's configuration information, including the number of retries and retry period for the upgrade precondition check.

[0040] If the number of retries is not zero, decrement the number of retries by 1, and use the retry cycle as a delay to process the upgrade preconditions for checking retry events.

[0041] Maintain the target application's current state as the upgrade policy check state, and clear the upgrade precondition check failure event, upgrade policy check timeout event, and upgrade precondition check retry event from the state machine's buffer.

[0042] When the number of retries is 0, the target application is transitioned from the upgrade policy check state to the waiting for user confirmation state, the number of retries is reset to the target number, and the upgrade precondition check failure event and upgrade policy check state timeout event are cleared from the state machine's buffer.

[0043] In one implementation, the current state includes a state of performing an upgrade, the event information includes information about an installation completion event, and the target state includes an upgrade result verification state. When processing events in the current state of the target application, the target application is migrated from the current state to the target state, further including:

[0044] When processing the installation completion event in the state of executing the upgrade of the target application, the target application is transitioned from the state of executing the upgrade to the state of verifying the upgrade result.

[0045] In one implementation, the current state includes a state of performing an upgrade, the event information includes information about a timeout event in the state of performing an upgrade, and the target state includes a state of waiting for user confirmation. When processing events in the current state of the target application, the application is migrated from the current state to the target state, further comprising:

[0046] When handling state timeout events during the execution upgrade process in the target application's execution upgrade state, the target application is transitioned from the execution upgrade state to the state awaiting user confirmation, and the execution upgrade state timeout events in the state machine's buffer are cleared.

[0047] In one implementation, the current state includes an upgrade result verification state, the event information includes verification success event information and verification failure event information, the target state includes a state awaiting user confirmation, and when processing events in the current state of the target application, the target application is migrated from the current state to the target state, further including:

[0048] When processing successful or failed verification events in the upgrade result verification state of the target application, the target application is transitioned from the upgrade result verification state to the state of waiting for user confirmation, and the successful and failed verification events in the state machine's buffer are cleared.

[0049] In one implementation, the current state includes an upgrade result verification state, and the event information includes information on upgrade result verification state timeout events and version verification retry events. The method further includes:

[0050] When handling the upgrade result verification status timeout event in the target application's upgrade result verification status, obtain the state machine's configuration information, including the number of retries and the retry period.

[0051] If the number of retries is not zero, decrement the number of retries by 1, and process the version verification retry event with a delay of the retry period.

[0052] Maintain the target application's current state as the upgrade result verification state, and clear the upgrade result verification state timeout event and version verification retry event from the state machine's buffer.

[0053] When the number of retries is 0, the target application is transitioned from the upgrade result verification state to the waiting for user confirmation state, the number of retries is reset to the target number, and the upgrade result verification state timeout event in the state machine's buffer is cleared.

[0054] In one implementation, the current state includes a state awaiting user confirmation, the event information includes information about a user confirmation of the upgrade result event, and the target state includes a state with no updates available. When processing events in the current state of the target application, the application is migrated from the current state to the target state, further comprising:

[0055] When processing the user confirmation upgrade result event in the target application's waiting-for-user-confirmation-result state, the target application is transitioned from the waiting-for-user-confirmation-result state to the no-update-available state, and the user confirmation upgrade result event in the state machine's buffer is cleared.

[0056] In one implementation, the current state includes a state awaiting user confirmation, and the event information includes information about a timeout event in the state awaiting user confirmation. The method further includes:

[0057] When handling the timeout event for the waiting-for-user-confirmation-result state in the target application's waiting-for-user-confirmation-result state, the target application's current state is maintained as the waiting-for-user-confirmation-result state, and the waiting-for-user-confirmation-result-timeout event in the state machine's buffer is cleared.

[0058] In one implementation, the method further includes:

[0059] Write the target status and the data generated during the upgrade of the target application into the database.

[0060] When the state machine starts, it retrieves the target state for entering the target application from the database.

[0061] Secondly, embodiments of this application provide a vehicle application upgrade apparatus, which is applied to a state machine, and the apparatus includes:

[0062] The detection module is used to detect the current state of the target application upon receiving an upgrade message from the state machine manager. The receiving module is used to receive event information in the current state, including information about events generated during the upgrade process of the target application.

[0063] The state transition module is used to transition the target application from its current state to the target state when processing events in the current state of the target application, so as to complete the upgrade of the target application.

[0064] In one implementation, the current state includes a state with no available updates, the event information includes information on querying available updates events and timeout events for the state with no available updates, and the target state includes a state with querying available upgrades.

[0065] The state transition module is also used to transition the target application from the state of no available updates to the state of available updates when handling query available updates events and / or no available updates state timeout events in the state of no available updates of the target application, and to clear the no available updates state timeout events in the buffer of the state machine when handling no available updates state timeout events.

[0066] In one implementation, the current state includes a state where no updates are available, the event information includes information about proactive push events for new versions, and the target state includes a state awaiting user confirmation for download.

[0067] The state transition module is also used to handle proactive push events for new versions of the target application when there are no updates available, by transitioning the target application from a state with no updates available to a state waiting for user confirmation to download.

[0068] In one implementation, the current state includes a query for available upgrade status, and the event information includes information on new version detected events, proactive push events for new versions, no new version detected events, and timeout events for querying available upgrade status. The target state includes a waiting-for-user-confirmation-download status and a no-update-available status.

[0069] The state transition module is also used to handle events such as detecting a new version and / or proactive push events of a new version when the target application is in a query-for-upgrade-available state. It transitions the target application from a query-for-upgrade-available state to a waiting-for-user-confirm-download state.

[0070] The state transition module is also used to transition the target application from the query available upgrade state to the no available update state when handling the no new version detected event and / or the query available upgrade state timeout event in the query available upgrade state of the target application, and to clear the query available upgrade state timeout event in the state machine buffer when handling the query available upgrade state timeout event.

[0071] In one implementation, the current state includes a waiting-for-user-confirmation-download status, and the event information includes information on proactive push events for new versions and timeout events for waiting for user confirmation of the download status. The vehicle application upgrade device also includes a processing module.

[0072] The processing module is used to maintain the current state as the waiting-for-user-confirmation-download state when handling the proactive push event for a new version and / or the waiting-for-user-confirmation-download state timeout event in the target application's waiting-for-user-confirmation-download state state, and to clear the waiting-for-user-confirmation-download state timeout event from the state machine's buffer when handling the waiting-for-user-confirmation-download state timeout event.

[0073] In one implementation, the current state includes a waiting-for-user-confirmation-download status, the event information includes information about an event where the user confirms the download of a new version, and the target state includes a download policy check status.

[0074] The state transition module is also used to transition the target application from the waiting-for-user-confirmation-download state to the download policy check state when handling the user confirmation event for downloading a new version in the target application's waiting-for-user-confirmation-download state, and to clear the user confirmation event for downloading a new version from the state machine's buffer.

[0075] In one implementation, the current state includes a download policy check status, the event information includes information about download precondition check passing events, and the target state includes the status of downloading in progress.

[0076] The state transition module is also used to transition the target application from the download policy check state to the download in progress state when processing the download precondition check pass event in the download policy check state of the target application, and to clear the download precondition check pass event in the state machine's buffer.

[0077] In one implementation, the current state includes a download policy check state, and the event information includes information on download precondition check failure events, download policy check state timeout events, and download precondition check retry events. The vehicle application upgrade device also includes an acquisition module.

[0078] The acquisition module is used to acquire the state machine configuration information when handling precondition check failure events and / or download policy check timeout events in the download policy check state of the target application. The configuration information includes the number of retries and the retry period for the download precondition check.

[0079] The processing module is also used to decrement the retry count by 1 when the retry count is not 0, and to process the download precondition check retry event with the retry period as a delay.

[0080] The processing module is also used to maintain the current state of the target application as the download policy check state, and to clear the download precondition check failure event, download policy check timeout event, and download precondition check retry event from the state machine's buffer.

[0081] The state transition module is also used to transition the target application from the download policy check state to the waiting for user confirmation state when the number of retries is 0, reset the number of retries to the target number, and clear the download precondition check failure event and the download policy check state timeout event in the state machine's buffer.

[0082] In one implementation, the current state includes a download in progress status, the event information includes information about a successful download event, and the target state includes a status awaiting user confirmation for an upgrade.

[0083] The state transition module is also used to handle the download success event when the target application is in the download process, and to transition the target application from the download process state to the waiting for user confirmation upgrade state.

[0084] In one implementation, the current state includes a download in progress status, event information includes download failure events, download in progress timeout events, and user-cancelled download events, and the target state includes a waiting-for-user-confirmation-result status and a waiting-for-user-confirmation-download status.

[0085] The state transition module is also used to transition the target application from the state of "downloading" to the state of "awaiting user confirmation" when handling download failure events and / or timeout events during the download process, and to clear the timeout event from the state machine's buffer in the case of handling the download timeout event.

[0086] The state transition module is also used to handle user cancel download events when the target application is in the process of executing a download, by transitioning the target application from the process of executing a download to the process of waiting for user confirmation of download, and clearing the user cancel download event from the state machine's buffer.

[0087] In one implementation, the current state includes a state awaiting user confirmation for upgrade, the event information includes information on user confirmation of installation events and user cancellation of new version installation events, and the target state includes an upgrade policy check state and a state awaiting user confirmation for download.

[0088] The state transition module is also used to transition the target application from the waiting-for-user-confirmation-upgrade state to the upgrade policy check state when processing user confirmation installation events in the target application's waiting-for-user-confirmation-upgrade state, and to clear the user confirmation installation events from the state machine's buffer.

[0089] The state transition module is also used to handle user cancellation of new version installation events when the target application is in the waiting-for-user-confirmation-upgrade state. It transitions the target application from the waiting-for-user-confirmation-upgrade state to the waiting-for-user-confirmation-download state and clears the user cancellation of new version installation events from the state machine's buffer.

[0090] In one implementation, the current state includes a state awaiting user confirmation of the upgrade, and the event information includes information about timeout events related to the state awaiting user confirmation of the upgrade.

[0091] The processing module is also used to maintain the current state of the target application as the state of waiting for user confirmation for upgrade when processing the timeout event of the state of waiting for user confirmation for upgrade, and to clear the timeout event of the state of waiting for user confirmation for upgrade in the state machine's buffer.

[0092] In one implementation, the current state includes an upgrade policy check status, the event information includes information about upgrade precondition check passing events, and the target state includes the status of performing an upgrade.

[0093] The state transition module is also used to transition the target application from the upgrade policy check state to the state of performing the upgrade when processing the upgrade precondition check pass event in the upgrade policy check state of the target application, and to clear the upgrade precondition check pass event in the state machine's buffer.

[0094] In one implementation, the current state includes an upgrade policy check state, and the event information includes information on upgrade precondition check failure events, upgrade policy check state timeout events, and upgrade precondition check retry events.

[0095] The acquisition module is also used to acquire the configuration information of the state machine when handling upgrade precondition check failure events and / or upgrade strategy check timeout events in the upgrade strategy check state of the target application. The configuration information includes the number of retries and the retry period for the upgrade precondition check.

[0096] The processing module is also used to decrement the retry count by 1 when the retry count is not 0, and to process the upgrade precondition check retry event with the retry period as a delay.

[0097] The processing module is also used to maintain the current state of the target application as the upgrade policy check state, and clear the upgrade precondition check failure event, upgrade policy check state timeout event, and upgrade precondition check retry event in the state machine's buffer. The state transition module is also used to transition the target application from the upgrade policy check state to the waiting for user confirmation result state when the retry count is 0, reset the retry count to the target count, and clear the upgrade precondition check failure event and upgrade policy check state timeout event in the state machine's buffer.

[0098] In one implementation, the current state includes the status of performing an upgrade, the event information includes information about an installation completion event, and the target state includes the upgrade result verification status.

[0099] The state transition module is also used to transition the target application from the state of performing the upgrade to the state of verifying the upgrade result when handling the installation completion event in the state of the target application in the process of performing the upgrade.

[0100] In one implementation, the current state includes an upgrade in progress status, the event information includes timeout information for the upgrade in progress status, and the target state includes a status awaiting user confirmation.

[0101] The state transition module is also used to handle state timeout events during the execution upgrade process of the target application, by transitioning the target application from the execution upgrade state to the state of waiting for user confirmation, and clearing the execution upgrade state timeout events from the state machine's buffer.

[0102] In one implementation, the current state includes an upgrade result verification state, the event information includes verification success and verification failure information, and the target state includes a state awaiting user confirmation.

[0103] The state transition module is also used to transition the target application from the upgrade result verification state to the waiting for user confirmation state when processing verification success or verification failure events in the upgrade result verification state of the target application, and to clear the verification success and verification failure events in the state machine's buffer.

[0104] In one implementation, the current state includes an upgrade result verification state, and the event information includes information on upgrade result verification state timeout events and version verification retry events.

[0105] The acquisition module is also used to acquire the state machine's configuration information when handling upgrade result verification status timeout events in the target application's upgrade result verification status. This configuration information includes the number of retries and the retry period.

[0106] The processing module is also used to decrement the retry count by 1 when the retry count is not 0, and to process the verification version retry event with a delay of the retry period.

[0107] The processing module is also used to maintain the current state of the target application as the upgrade result verification state, and to clear the upgrade result verification state timeout event and version verification retry event from the state machine's buffer.

[0108] The state transition module is also used to transition the target application from the upgrade result verification state to the waiting for user confirmation state when the number of retries is 0, reset the number of retries to the target number, and clear the upgrade result verification state timeout event in the state machine's buffer.

[0109] In one implementation, the current state includes a state awaiting user confirmation, the event information includes information about a user confirmation of the upgrade result event, and the target state includes a state with no available updates.

[0110] The state transition module is also used to transition the target application from the waiting for user confirmation result state to the no-update-available state when processing the user confirmation upgrade result event in the state of the target application waiting for user confirmation result, and to clear the user confirmation upgrade result event in the state machine's buffer.

[0111] In one implementation, the current state includes a state awaiting user confirmation, and the event information includes information about a timeout event in the state awaiting user confirmation.

[0112] The processing module is also used to maintain the current state of the target application as the state of waiting for user confirmation when processing the timeout event of the state of waiting for user confirmation in the state of waiting for user confirmation result of the target application, and to clear the timeout event of the state of waiting for user confirmation result in the buffer of the state machine.

[0113] In one implementation, the vehicle application upgrade device further includes a data writing module.

[0114] The data writing module is used to write the target state and data generated during the upgrade of the target application into the database.

[0115] The acquisition module is also used to retrieve the target state for entering the target application from the database when the state machine starts.

[0116] Thirdly, embodiments of this application provide an electronic device, which includes: a processor and a memory storing computer program instructions;

[0117] When the processor executes computer program instructions, it implements a method for upgrading the vehicle application as described in any embodiment of the first aspect.

[0118] Fourthly, embodiments of this application provide a computer storage medium storing computer program instructions, which, when executed by a processor, implement the vehicle application upgrade method as described in any embodiment of the first aspect.

[0119] Fifthly, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform an upgrade method for a vehicle application as described in any embodiment of the first aspect.

[0120] This application discloses a vehicle application upgrade method and apparatus. In the vehicle application upgrade method, the software remote upgrade service engine includes a state machine manager and a state machine corresponding to each application. The state machine manager receives messages sent by the service and distributes them to the state machines corresponding to each application. The state machines drive each application according to the driving behavior corresponding to the message. By detecting the current state of the target application upon receiving an upgrade message from the state machine manager, the SOTA process can be managed for each application through its corresponding state machine. Next, event information in the current state is received, including information about events generated during the upgrade of the target application. Then, while processing events in the current state of the target application, the target application is transitioned from its current state to the target state, thus completing the upgrade of the target application through state transition. This allows the application to be treated as the upgrade object, enabling more granular control over the upgrade target. By controlling state transition through the state machine, the SOTA process of the application can be implemented more accurately and efficiently. Attached Figure Description

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

[0122] Figure 1 This is a schematic diagram of the architecture of a software remote upgrade service engine provided in one embodiment of this application;

[0123] Figure 2 This is a flowchart illustrating a vehicle application upgrade method provided in one embodiment of this application;

[0124] Figure 3 This is a schematic diagram of a state transition model provided in one embodiment of this application;

[0125] Figure 4 This is a schematic diagram of the SOTA (State Over-The-Air) process based on a state machine according to an embodiment of this application;

[0126] Figure 5 This is a schematic diagram of a database-based SOTA state recovery process provided in one embodiment of this application;

[0127] Figure 6 This is a schematic diagram of the structure of a vehicle application upgrade device provided in one embodiment of this application;

[0128] Figure 7 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

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

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

[0131] As described in the background section, existing SOTA (System-on-OTA) upgrade methods are software upgrades for the entire ECU (Engine Control Unit). However, an ECU can control multiple software programs, thus the above solutions cannot achieve more precise control over the upgrade target. To address this issue, this application provides a method and apparatus for upgrading vehicle applications. In this method, the software remote upgrade service engine includes a state machine manager and a state machine corresponding to each application. The state machine manager receives messages sent by the service and distributes them to the state machines corresponding to each application. The state machines drive each application according to the driving behavior corresponding to the message. By detecting the current state of the target application upon receiving an upgrade message from the state machine manager, the SOTA process can be managed for each application through its corresponding state machine. Next, event information in the current state is received, including information about events generated during the upgrade of the target application. Then, when processing events in the current state of the target application, the target application is transitioned from its current state to the target state, thus completing the upgrade of the target application through state transition. In this way, the application can be treated as the upgrade object, allowing for more precise control over the upgrade target. By controlling state transitions through a state machine, the application's SOTA process can be implemented more accurately and efficiently.

[0132] The software remote upgrade service engine (Sota ServiceEngine) provided in the embodiments of this application will be introduced first below.

[0133] like Figure 1 As shown, the software remote upgrade service engine 10 can be an engine that implements SOTA business logic. The software remote upgrade service engine 10 can include a state machine manager 101 (SotaFsm Manager) and a state machine 102 (Finite State Machine, Fsm) corresponding to each application.

[0134] like Figure 1 As shown, the state machine manager 101 receives messages sent by other services, such as startup messages (upgrade messages) sent by the software upgrade service, and preprocesses and distributes the messages to the state machines 102 corresponding to each application. Then, the state machines 102 drive the SOTA process of each application according to the driving behavior corresponding to the message.

[0135] In this embodiment, the multi-state machine of the software remote upgrade service engine 10 manages multiple SOTA processes, controlling and coordinating calls to services such as downloading, installation, and policies, thereby completing the SOTA process for each application. For each application, a state machine 102 manages the various stages and corresponding operations of the application's SOTA. The software remote upgrade service engine 10, through a state machine manager 101, manages the state transitions of the state machines 102 corresponding to different applications, thus enabling message distribution to the state machines 102 corresponding to different applications and supporting parallel upgrades of multiple applications.

[0136] The method for upgrading vehicle applications provided in this application embodiment will be described below.

[0137] Figure 2 The diagram illustrates a flowchart of a vehicle application upgrade method according to an embodiment of this application. This vehicle application upgrade method is applied to a state machine in a software remote upgrade service engine. The software remote upgrade service engine includes a state machine manager and a state machine corresponding to each application. The state machine manager is used to receive messages sent by the service and distribute them to the state machines corresponding to each application. The state machines are used to drive each application according to the driving behavior corresponding to the message.

[0138] like Figure 2 As shown, the method for upgrading the vehicle application may specifically include the following steps:

[0139] S210: Upon receiving an upgrade message for the target application from the state machine manager, the current state of the target application is checked. The state machine manager can preprocess received external messages, i.e., message escaping and dispatching. When the state machine manager receives the upgrade message for the target application, it sends the upgrade message to the target application's state machine SotaFsm, thereby allowing the state machine to receive the upgrade message from the state machine manager.

[0140] After receiving the upgrade message from the target application, the state machine checks the current state of the target application. The current state can be any state of the target application during the upgrade process, such as No Upgrade, Check For Upgrade, Download User Confirm, Download Policy Check, Download Progressing, Upgrade User Confirm, Upgrade Policy Check, Upgrade Progressing, Verification Progressing, and Result User Confirm.

[0141] S220, receives event information in the current state.

[0142] Event information can include information about events generated during the upgrade of the target application. These events can be predefined by the developers according to the SOTA process, such as user query version information events, user query available update events, proactive push events for new versions, and user confirmation of new version download events.

[0143] S230, when processing events in the current state of the target application, the target application is migrated from the current state to the target state in order to complete the upgrade of the target application.

[0144] A state machine is used to transition the target application from its current state to a target state. The state transition action can be implemented by the exit method of the current state and the enter method of the target state.

[0145] As an example, such as Figure 3The state transition model shown illustrates that the state machine maintains a current state and a destination state during runtime. During initialization, the state machine adds the necessary states to support the SOTA (State-Over-The-Air) process and sets an initial state. These states can include: no available updates, querying available upgrades, waiting for user confirmation to download, checking download strategy, downloading, waiting for user confirmation to upgrade, checking upgrade strategy, executing upgrade, verifying upgrade results, and waiting for user confirmation. The initial state can be "no available updates." Next, developers define events (Messages) according to the SOTA process and pre-define exit methods, entry methods, and "handle Message" methods for each state. The "handle Message" method can include the event's execution action and processing logic. When processing events in the target application's current state, the event-driven state machine implements the SOTA process based on the pre-defined state transition execution actions and processing logic, thus completing the upgrade of the target application.

[0146] Furthermore, the state transition model provided in this application supports extension, such as... Figure 3 As shown in the extensible module, it is used to extend state objects, event handling logic, and state transition methods.

[0147] In this embodiment, upon receiving an upgrade message for the target application from the state machine manager, the current state of the target application is detected. This allows for SOTA (State Over-The-Air) management of each application through a corresponding state machine. Next, event information in the current state is received, including information about events generated during the target application upgrade process. Then, while processing events in the target application's current state, the target application is transitioned from its current state to the target state; that is, the upgrade is completed through state transition. This allows the application to be treated as the upgrade object, enabling more granular control over the upgrade process. By controlling state transition through a state machine, the application's SOTA process can be implemented more accurately and efficiently.

[0148] In some embodiments, the current state may include a state with no available updates, the event information may include information about querying available updates events and timeout events for the state with no available updates, the target state may include querying available upgrade states, and S230 may specifically include:

[0149] When processing query available update events and / or no available update state timeout events in the target application's no available update state, the target application is migrated from the no available update state to the query available upgrade state, and the no available update state timeout event is cleared from the state machine's buffer in the case of processing the no available update state timeout event.

[0150] The "No Updates Available" state can be the initial or persistent state of the target application, which remains in this state until a new version of the application is released. The "Query Updates Available" event is generated when a user queries for available updates. The "No Updates Available" state timeout event is a state timeout event sent with a preset delay when entering the "No Updates Available" state. This timeout event can also be implemented using a timer, where the preset delay can be loaded from the state machine's configuration file as the state timeout time and passed in when constructing the "No Updates Available" state object.

[0151] As an example, such as Figure 4 As shown, when processing the query available update event and / or the no available update timeout event under the no available update state 401, the state migration of the target application is triggered, and the target application is migrated from the no available update state 401 to the query available upgrade state 402. The query available upgrade state 402 can be the state in which the user requests the server to query the new version of the target application. When entering the query available upgrade state 402, the vehicle-cloud communication query for available update version is initiated.

[0152] In some implementations, when a user queries version information in a state where no updates are available, the release information of the installed version is obtained and sent to the user's terminal device for displaying the release information of the installed version to the user.

[0153] Furthermore, while state machines handle events and state transitions in a separate thread, in SOTA (State Over-the-Air) applications, events typically originate from different sources, meaning there are scenarios where multiple threads send events simultaneously. To address this, the state machine's design of handling events and state transitions in a separate thread ensures synchronized event processing, thus mitigating state anomalies caused by multiple threads sending events. It's important to note that in this model, any state transition triggered by any event will cause the next event to be handled by the target state. Therefore, if the target state and the current state can handle the same event, it's necessary to consider whether to clear the event from the buffer when the current state exits.

[0154] In the case of a timeout event indicating no available updates, the event is not needed but will be processed during the query for available upgrade status or the waiting for user confirmation to download status. Therefore, the timeout event in the state machine's buffer needs to be cleared when exiting this state. If the timeout event is implemented using a timer, then the timer needs to be cleared. The user query for version information event will also be processed during the query for available upgrade status, but it is neither needed nor processed during the waiting for user confirmation to download status, so it does not need to be cleared when exiting this state. Similarly, the user query for available updates event is neither needed nor processed during the query for available upgrade status or the waiting for user confirmation to download status, so it does not need to be cleared when exiting this state.

[0155] In this embodiment, when processing the query for available updates event and / or the no-update-available-state timeout event in the target application's no-update-available-state state, the target application is migrated from the no-update-available-state state to the query-available-upgrade-state state. Furthermore, in the case of processing the no-update-available-state timeout event, the no-update-available-state timeout event is cleared from the state machine's buffer. This allows for state transitions during the target application upgrade process in the no-update-available-state state, achieving the SOTA upgrade process, and avoids state anomalies caused by multi-threaded event sending.

[0156] In some embodiments, the current state may include a state where no updates are available, the event information may include information about a proactive push event for a new version, the target state may include a state awaiting user confirmation for download, and S230 may specifically include:

[0157] When handling proactive push events for new versions of the target application while the target application is in a state where no updates are available, the target application is migrated from a state where no updates are available to a state where the user confirms the download.

[0158] The "No updates available" status allows users to query version information and available updates, and also allows them to receive proactive push notifications for new versions.

[0159] As an example, such as Figure 4 As shown, when processing a proactive push event for a new version under state 401 (no available updates), a state transition is triggered, moving to state 403 (waiting for user confirmation to download). Upon entering state 403, the state machine reports the new version's distribution status to the cloud and initiates a request to the vehicle's infotainment system, requesting user confirmation on whether to download the new version update.

[0160] Furthermore, since the new version's proactive push event is the highest priority request before downloading the upgrade package, it needs to be processed while querying the available upgrade status or waiting for the user to confirm the download status, so it does not need to be cleared when exiting this status.

[0161] In this embodiment of the application, when the target application is in a state where no updates are available, the target application is migrated from a state where no updates are available to a state where the user confirms the download. This allows the application to receive push notifications of new versions in a state where no updates are available and triggers the state migration, thereby realizing the SOTA upgrade process.

[0162] In some embodiments, the current state may include querying available upgrade status, the event information may include information on new version detection events, new version proactive push events, no new version detection events, and querying available upgrade status timeout events, the target state may include waiting for user confirmation download status and no available updates status, and S230 may specifically include:

[0163] When handling events such as "new version detected" and / or "new version push notification" for the target application while it is in the "upgrade available" state, the target application will be moved from the "upgrade available" state to the "awaiting user confirmation for download" state.

[0164] When handling the "No new version detected" event and / or "Query available upgrade state timeout" event in the target application's "Query available upgrade state", the target application is migrated from the "Query available upgrade state" to the "No available update" state, and the "Query available upgrade state timeout" event is cleared from the state machine's buffer in the case of handling the "Query available upgrade state timeout" event.

[0165] When entering the query available upgrade state, vehicle-to-cloud communication is initiated to query available update versions. That is, the user initiates a query for a new version to the server. The application remains in the query available upgrade state until it receives a response from the server or receives a timeout event for the query available upgrade state.

[0166] The "new version detected" event can be an event indicating that a new version of the server exists, or it can be an event generated when a response message is received from the server and the response message indicates that a new version has been detected.

[0167] The "No new version detected" event can indicate that the server does not have a new version. The "Query available upgrade status timeout" event can be a status timeout event sent with a preset delay time when entering the query available upgrade status. This status timeout event can also be implemented using a timer, where the preset delay time can be loaded from the state machine's configuration file as the status timeout time and passed in when constructing the query available upgrade status object.

[0168] As an example, such as Figure 4As shown, when processing a new version detection event and / or a new version proactive push event under the query available upgrade status 402, a state transition is triggered, transitioning to the waiting-for-user-confirm-download status 403. When processing a no-new-version-detection event and / or a query available upgrade status timeout event under the query available upgrade status 402, the vehicle's infotainment system is notified that there is no updated version, and a state transition is triggered, transitioning to the no-update-available status 401.

[0169] Since the new version detection event does not need to be processed in the state of no available updates or waiting for user confirmation to download, it does not need to be cleared when exiting this state; the new version proactive push event, as the highest priority request before downloading the upgrade package, needs to be processed in the state of no available updates or waiting for user confirmation to download, so it does not need to be cleared when exiting this state.

[0170] Additionally, the "No new version detected" event is not required and will not be processed in the "No available updates" or "Waiting for user confirmation to download" states, so it does not need to be cleared when exiting this state. The "Query available upgrade status timeout" event is not required but will be processed in the "No available updates" or "Waiting for user confirmation to download" states, so it needs to be cleared when exiting this state. If implemented using a timer, the timer needs to be cleared.

[0171] In this embodiment, when handling events such as "new version detected" and / or "active push of new version" in the "upgrade availability query" state, the target application is transitioned from the "upgrade availability query" state to the "awaiting user confirmation download" state. In the "upgrade availability query" state, an available update version can be queried from the server to achieve an upgrade. Conversely, when handling events such as "no new version detected" and / or "upgrade availability query timeout" in the "upgrade availability query" state, the target application is transitioned from the "upgrade availability query" state to the "no available update" state. Furthermore, in the case of a "upgrade availability query timeout" event, the "upgrade availability query timeout" event is cleared from the state machine's buffer. Thus, if no available update version is found in the "upgrade availability query" state, the state transitions to the "no available update" state, allowing for a re-upgrade of the target application.

[0172] In some embodiments, the current state may include a waiting-for-user-confirmation-download state, the event information may include information about an event in which the user confirms the download of the new version, the target state may include a download policy check state, and S230 may specifically include:

[0173] When processing the user confirmation download event in the target application's waiting-for-user-confirmation-download state, the target application is transitioned from the waiting-for-user-confirmation-download state to the download policy check state, and the user confirmation download event in the state machine's buffer is cleared.

[0174] When entering the waiting-for-user-confirmation-download state, the system reports the status of the new version being distributed to the cloud and sends a request to the vehicle's infotainment system, i.e., a request for the user to confirm whether to download the new version update. From the time the new version is received until the user confirms the download, the target application remains in the waiting-for-user-confirmation-download state.

[0175] As an example, such as Figure 4 As shown, when processing the event of user confirmation of new version download under the waiting for user confirmation download status 403, a state transition is triggered, transitioning to the download policy check status 404.

[0176] Since the user confirmation of downloading the new version event is not needed and will not be processed in the download policy check state, but will be processed in the waiting for user confirmation of downloading state, the user confirmation of downloading the new version event in the state machine's buffer needs to be cleared when exiting this state.

[0177] In this embodiment, when processing the event of user confirmation for downloading a new version in the target application's waiting-for-user-confirmation-download state, the target application is transitioned from the waiting-for-user-confirmation-download state to the download policy check state, and the event of user confirmation for downloading a new version in the state machine's buffer is cleared. This allows for initiating a request to the vehicle's infotainment system regarding whether the user wants to download the new version in the waiting-for-user-confirmation-download state, and transitioning the state to the download policy check state upon confirmation of download, thereby achieving an upgrade of the target application.

[0178] In some embodiments, the current state may include a waiting-for-user-confirmation-download status, and the event information may include information about a new version push event and a timeout event for the waiting-for-user-confirmation-download status. The vehicle application upgrade method may also include:

[0179] When handling proactive push events for new versions and / or timeout events for waiting for user confirmation to download in the target application's waiting-for-user-confirmation-download state, maintain the current state as waiting for user confirmation to download, and clear the waiting-for-user-confirmation-download-timeout event from the state machine's buffer when handling the waiting-for-user-confirmation-download-timeout event.

[0180] The waiting-for-user-confirmation-download-state-timeout event can be a state timeout event sent with a preset delay time when entering the waiting-for-user-confirmation-download-state. This state timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine's configuration file as the state timeout time and passed in when constructing the waiting-for-user-confirmation-download-state-object.

[0181] As an example, such as Figure 4As shown, when processing the proactive push event for a new version and / or the timeout event for the waiting-for-user-confirmation-download status under the waiting-for-user-confirmation-download status 403, the current status is maintained as the waiting-for-user-confirmation-download status 403, i.e., no state transition is triggered. Alternatively, the state transition to the waiting-for-user-confirmation-download status 403 can be triggered to notify the user again that a new version of the target application is available for download.

[0182] Additionally, the timeout event for waiting for user confirmation of download status is not required but will be processed in the waiting for user confirmation of download status or the download policy check status. Therefore, the waiting for user confirmation of download status timeout event in the state machine's buffer needs to be cleared when exiting this status. If implemented using a timer, the timer needs to be cleared.

[0183] In this embodiment of the application, by processing the proactive push event for a new version and / or the timeout event for the waiting-for-user-confirmation-download status when the target application is in the waiting-for-user-confirmation-download status, the current status is maintained as the waiting-for-user-confirmation-download status, and the user can be notified again that a new version of the target application is available for download, which facilitates the smooth execution of the target application upgrade.

[0184] In some embodiments, the current state may include a download policy check state, the event information may include information about a download precondition check passing event, the target state may include a state of downloading, and S230 may specifically include:

[0185] When processing the download precondition check pass event in the download policy check state of the target application, the target application is transitioned from the download policy check state to the download in progress state, and the download precondition check pass event in the state machine's buffer is cleared.

[0186] The download strategy check status can be a state that confirms the preconditions for application download. Entering this state initiates a download precondition check, which may include checks on battery level, vehicle speed, engine speed, charging status, handbrake status, power mode, etc. Arbitration can be performed by comparing the current value in the strategy module with a threshold, which is issued by the cloud. From the time the user confirms the download until the download precondition check is completed or the download strategy check status times out, the target application remains in the download strategy check status.

[0187] As an example, such as Figure 4 As shown, when processing the download precondition check pass event under download policy check state 404, a state transition is triggered, transitioning to state 405 where download is in progress, to download a new version of the target application, and resetting the retry count to the target count, where the target count can be any preset number.

[0188] Since the download precondition check pass event is not required and will not be processed in the state of executing download or waiting for user confirmation, the download precondition check pass event in the current state is not required but will be processed in the download strategy check state. Therefore, the download precondition check pass event in the state machine's buffer needs to be cleared when exiting this state.

[0189] In this embodiment, when processing the download precondition check pass event in the download policy check state of the target application, the target application is transitioned from the download policy check state to the download in progress state, and the download precondition check pass event in the state machine buffer is cleared, which facilitates the upgrade of the target application.

[0190] In some embodiments, the current state may include a download policy check state, and the event information may include information on download precondition check failure events, download policy check state timeout events, and download precondition check retry events. The vehicle application upgrade method may further include:

[0191] When handling download precondition check failure events and / or download policy check timeout events in the target application's download policy check state, obtain the state machine's configuration information. The configuration information may include the number of retries and the retry period for the download precondition check.

[0192] If the number of retries is not zero, decrement the number of retries by 1, and use the retry period as a delay to process the download preconditions for checking retry events.

[0193] Maintain the target application's current state as the download policy check state, and clear the download precondition check failure event, download policy check timeout event, and download precondition check retry event from the state machine's buffer.

[0194] When the number of retries is 0, the target application is transitioned from the download policy check state to the waiting for user confirmation state, the number of retries is reset to the target number, and the download precondition check failure event and the download policy check state timeout event are cleared from the state machine's buffer.

[0195] The download policy check state timeout event can be a state timeout event sent with a preset delay time when entering the download policy check state. This state timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine's configuration file as the state timeout time and passed in when constructing the download policy check state object.

[0196] The download strategy check status supports setting the number of retries and the retry period, which are loaded from the state machine configuration file and passed in when constructing the download strategy check status object.

[0197] If the number of retries is exhausted, a state transition is triggered, transitioning to the state of waiting for user confirmation, and the number of retries is reset to the target number, which can be any preset number.

[0198] As an example, such as Figure 4 As shown, in download policy check state 404, the download precondition check failure event is handled, the reason for the failure is recorded, and the number of retries and retry period for the download precondition check are obtained from the configuration file. If the number of retries has not been exhausted, the download policy check state timeout event is cleared, the number of retries is decremented by 1, and a download precondition check retry event is sent with a delay of the retry period. Then, the download precondition check retry event is handled, i.e., the download precondition check is re-initiated, and the current state is maintained as download policy check state 404, or a state transition to download policy check state 404 is triggered. In download policy check state 404, the download precondition check failure event is handled, the reason for the failure is recorded, and the number of retries and retry period for the download precondition check are obtained from the configuration file. If the number of retries has been exhausted, a state transition is triggered, transitioning to the waiting for user confirmation result state 410.

[0199] Additionally, download precondition check failure events do not need to be processed in the download in progress state or the waiting for user confirmation state. For download precondition check failure events in the current state, they do not need to be processed in the download policy check state, so they need to be cleared when exiting this state. Download precondition check retry events do not need to be processed in the download in progress state or the waiting for user confirmation state. For download precondition check retry events in the current state, they do not need to be processed in the download policy check state, so they need to be cleared when exiting this state. Download policy check state timeout events do not need to be processed in the download in progress state, the waiting for user confirmation state, or the download policy check state, so they need to be cleared when exiting this state. When implemented using a timer, the timer needs to be cleared. In this embodiment, when handling precondition check failure events and / or download policy check timeout events in the download policy check state of the target application, configuration information of the state machine is obtained. This configuration information may include the number of retries and the retry period for the download precondition check. When the number of retries is not zero, the number of retries is decremented by 1, and the download precondition check retry event is handled with a delay equal to the retry period, maintaining the target application's current state as the download policy check state. This allows for a re-initiation of the check if the download precondition check fails, ensuring a smooth upgrade. When the number of retries reaches zero, the target application is transitioned from the download policy check state to the state awaiting user confirmation, the number of retries is reset to the target number, and the download precondition check failure events and download policy check timeout events are cleared from the state machine's buffer. This allows for notification of the upgrade failure result to the user when the number of retries is exhausted, and awaits user confirmation, thus completing the SOTA upgrade process.

[0200] In some embodiments, the current state may include a download in progress status, the event information may include information about a successful download event, the target state may include a status awaiting user confirmation for an upgrade, and S230 may specifically include:

[0201] When handling a successful download event while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-upgrade state.

[0202] The "Downloading in Progress" state can be the state in which the target application is downloading; entering this state initiates the download of the upgrade package. The application remains in the "Downloading in Progress" state until the download preconditions are met, the download is complete, the download fails, or the state times out.

[0203] As an example, such as Figure 4 As shown, when processing the download success event in state 405 during the download process, a state transition is triggered, transitioning to state 406 where the user is waiting for confirmation of the upgrade.

[0204] In addition, the download success event does not need to be processed in the waiting for user confirmation download status, waiting for user confirmation upgrade status, or waiting for user confirmation result status, so it does not need to be cleared when exiting that status.

[0205] In this embodiment of the application, by processing the successful download event while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-upgrade state. This allows the application to jump to the installation step of the upgrade process upon successful download, thereby completing the upgrade of the target application.

[0206] In some embodiments, the current state may include a download in progress status, the event information may include download failure events, download in progress timeout events, and user cancellation of download events, the target state may include a waiting-for-user-confirmation-result status and a waiting-for-user-confirmation-download status, and S230 may specifically include:

[0207] When handling download failure events and / or download timeout events in the target application's download in progress state, the target application is transitioned from the download in progress state to the state awaiting user confirmation. Furthermore, in the case of a download timeout event, the download timeout event is cleared from the state machine's buffer.

[0208] When handling user cancel download events while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-download state, and the user cancel download event is cleared from the state machine's buffer.

[0209] The state timeout event during download execution can be a state timeout event sent with a preset delay time when entering the state of download execution execution. This state timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine configuration file as the state timeout time and passed in when constructing the state object of download execution execution; or the delay time can be estimated based on the size of the upgrade package of the target application and initialized when entering the state of download execution execution execution.

[0210] The user cancel download event can be generated when a message is received indicating that a user has canceled a download.

[0211] As an example, such as Figure 4 As shown, when handling a download failure event in state 405 (downloading in progress), the reason for the failure is recorded. When handling a timeout event in the downloading process, the download is stopped, the timeout information is recorded, and a state transition is triggered, moving to state 410 (waiting for user confirmation). When handling a user cancel download event in state 405 (downloading in progress), a state transition is triggered, moving to state 403 (waiting for user confirmation).

[0212] Additionally, download failure events do not need to be processed in the waiting for user confirmation of download status, waiting for user confirmation of upgrade status, or waiting for user confirmation of result status, so they do not need to be cleared when exiting this status; download timeout events do not need to be processed in the waiting for user confirmation of download status, waiting for user confirmation of upgrade status, or waiting for user confirmation of result status, so they need to be cleared when exiting this status, and when implemented using a timer, the timer needs to be cleared.

[0213] User cancel download events do not need to be processed in the "Waiting for User Confirmation Download" or "Waiting for User Confirmation Result" states. In the current state, user cancel download events do not need to be processed in the "Waiting for User Confirmation Upgrade" state, so they need to be cleared when exiting this state.

[0214] In this embodiment, by handling download failure events and / or download timeout events when the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user confirmation state. This allows the user to be notified of the failure and await user confirmation when the download fails, thus completing the process in a state-of-the-art (SOTA) manner. Furthermore, by handling user cancellation events when the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user confirmation state. This allows a new request to the user to download the new version to be sent, avoiding upgrade failures caused by accidental user actions.

[0215] In some embodiments, the current state may include a waiting-for-user-confirmation-upgrade state, the event information may include information on user-confirmed installation events and user-cancelled new version installation events, the target state may include an upgrade policy check state and a waiting-for-user-confirmation-download state, and S230 may specifically include:

[0216] When processing user confirmation installation events in the target application's "waiting for user confirmation upgrade" state, the target application is transitioned from the "waiting for user confirmation upgrade" state to the "upgrade policy check" state, and the user confirmation installation events in the state machine's buffer are cleared.

[0217] When handling user cancellation of new version installation events in the target application's waiting-for-user-confirmation-upgrade state, the target application is transitioned from the waiting-for-user-confirmation-upgrade state to the waiting-for-user-confirmation-download state, and the user cancellation of new version installation events in the state machine's buffer is cleared.

[0218] The "awaiting user confirmation for upgrade" status can be a notification to the user that the new version download is complete and awaits user confirmation for installation. Upon entering this status, the application notifies the cloud that the download is complete and awaits user confirmation, and also notifies the vehicle's infotainment system that the download is complete and requests user confirmation to install the upgrade package. The application remains in the "awaiting user confirmation for upgrade" status until the user confirms the installation of the new version.

[0219] The user confirmation installation event can be generated when a message confirming the user's installation is received.

[0220] The "User Cancels Installation of New Version" event can be generated when a message is received indicating that the user has canceled the installation of the new version.

[0221] As an example, such as Figure 4 As shown, when processing a user confirmation installation event under the "Waiting for User Confirmation Upgrade" state 406, a state transition is triggered, moving to the upgrade policy check state 407. When processing a user cancellation of new version installation event under the "Waiting for User Confirmation Upgrade" state 406, a state transition is triggered, moving to the "Waiting for User Confirmation Download" state 403.

[0222] Additionally, user confirmation installation events are not required and will not be processed during the "Waiting for User Confirmation Download" or "Upgrade Policy Check" states. User confirmation installation events in the current state are not required but will be processed during the "Waiting for User Confirmation Upgrade" state, so they need to be cleared upon exiting this state. Similarly, user cancellation installation events are not required and will not be processed during the "Waiting for User Confirmation Download" or "Upgrade Policy Check" states. User cancellation installation events in the current state are not required but will be processed during the "Waiting for User Confirmation Upgrade" state, so they need to be cleared upon exiting this state.

[0223] In this embodiment, by processing the user confirmation installation event while the target application is in the "waiting for user confirmation upgrade" state, the application is moved from the "waiting for user confirmation upgrade" state to the "waiting for user confirmation download" state. This allows the application to jump to the upgrade policy check step in the upgrade process when the user confirms installation, facilitating the upgrade of the target application. Conversely, by processing the user cancellation of new version installation events while the target application is in the "waiting for user confirmation upgrade" state, the application is moved from the "waiting for user confirmation download" state. This allows the application to re-initiate a request to the user to download the new version, avoiding upgrade failures caused by accidental user actions.

[0224] In some embodiments, the current state may include a state awaiting user confirmation of the upgrade, and the event information may include information about a timeout event for the state awaiting user confirmation of the upgrade. The upgrade method for the vehicle application may further include:

[0225] When handling timeout events for the "waiting for user confirmation to upgrade" state in the target application, maintain the target application's current state as "waiting for user confirmation to upgrade" and clear the timeout events for "waiting for user confirmation to upgrade" from the state machine's buffer.

[0226] The timeout event for waiting for user confirmation of upgrade status can be a status timeout event sent with a preset delay time when entering the waiting for user confirmation of upgrade status. This status timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine's configuration file as the status timeout time and passed in when constructing the waiting for user confirmation of upgrade status object.

[0227] As an example, such as Figure 4 As shown, when handling the timeout event of the waiting-for-user-confirmation-upgrade-state 406, the current state of the target application is maintained as the waiting-for-user-confirmation-upgrade-state 406, or the state is triggered to transition to the waiting-for-user-confirmation-upgrade-state 406, so as to prompt the user again that the download is complete and request the user to confirm whether to install.

[0228] Additionally, timeout events for waiting for user confirmation of upgrade status are not required but will be handled in the waiting for user confirmation of download status, upgrade policy check status, or waiting for user confirmation of upgrade status. Therefore, they need to be cleared when exiting this status. When implemented using a timer, the timer needs to be cleared.

[0229] In this embodiment of the application, when processing the timeout event of the waiting-for-user-confirmation-upgrade state in the waiting-for-user-confirmation-upgrade state of the target application, the current state of the target application is maintained as the waiting-for-user-confirmation-upgrade state. The user can be prompted again that the download is complete and asked to confirm whether to install, which facilitates the upgrade of the target application.

[0230] In some embodiments, the current state may include the upgrade policy check status, the event information may include information about the upgrade precondition check passing event, the target state may include the status of performing an upgrade, and S230 may specifically include:

[0231] When processing the upgrade precondition check pass event in the upgrade policy check state of the target application, the target application is transitioned from the upgrade policy check state to the state of executing upgrade, and the upgrade precondition check pass event in the state machine's buffer is cleared.

[0232] The upgrade strategy check status can be a state that confirms the application installation prerequisites. Entering this state initiates an upgrade prerequisite check, which may include battery level, vehicle speed, engine speed, charging status, handbrake status, power mode, whether the diagnostic tool is connected, and whether it is in remote diagnostic mode. Arbitration is performed by comparing the current value in the strategy module with a threshold value, which is issued from the cloud. The application remains in the upgrade strategy check status from user confirmation until the installation prerequisite check is completed or the status times out.

[0233] As an example, such as Figure 4As shown, when processing the upgrade precondition check pass event under upgrade strategy check state 407, the retry count is reset to the target count, which can be any preset count, and state transition is triggered, transitioning to state 408 where the upgrade is being performed.

[0234] Since the upgrade precondition check pass event does not need to be processed in the state of performing the upgrade or waiting for user confirmation, the upgrade precondition check pass event in the current state does not need to be processed in the upgrade strategy check state. Therefore, the upgrade precondition check pass event in the state machine's buffer needs to be cleared when exiting this state.

[0235] In this embodiment of the application, when processing the upgrade precondition check pass event in the upgrade policy check state of the target application, the target application is migrated from the upgrade policy check state to the state of performing upgrade, which facilitates the execution of the upgrade of the target application.

[0236] In some embodiments, the current state may include an upgrade policy check state, and the event information may include information on upgrade precondition check failure events, upgrade policy check state timeout events, and upgrade precondition check retry events. The upgrade method for the vehicle application may further include:

[0237] When handling upgrade precondition check failure events and / or upgrade policy check timeout events in the target application's upgrade policy check state, obtain the state machine's configuration information. The configuration information may include the number of retries and the retry period for the upgrade precondition check.

[0238] If the number of retries is not zero, decrement the number of retries by 1, and use the retry cycle as a delay to process the upgrade preconditions for checking retry events.

[0239] Maintain the target application's current state as the upgrade policy check state, and clear the upgrade precondition check failure event, upgrade policy check timeout event, and upgrade precondition check retry event from the state machine's buffer.

[0240] When the number of retries is 0, the target application is transitioned from the upgrade policy check state to the waiting for user confirmation state, the number of retries is reset to the target number, and the upgrade precondition check failure event and upgrade policy check state timeout event are cleared from the state machine's buffer.

[0241] The upgrade strategy check state timeout event can be a state timeout event sent with a preset delay time when entering the upgrade strategy check state. This state timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine's configuration file as the state timeout time and passed in when constructing the upgrade strategy check state object.

[0242] The upgrade strategy check status supports setting the number of retries and the retry period, which are loaded from the state machine configuration file and passed in when constructing the upgrade strategy check status object.

[0243] If the number of retries is exhausted, a state transition is triggered, transitioning to the state of waiting for user confirmation, and the number of retries is reset to the target number, which can be any preset number.

[0244] As an example, such as Figure 4 As shown, in upgrade policy check state 407, an upgrade precondition check failure event is handled, the reason for the failure is recorded, and the number of retries and retry period for the upgrade precondition check are obtained from the configuration file. If the number of retries has not been exhausted, the upgrade policy check state timeout event is cleared, the number of retries is decremented by 1, and an upgrade precondition check retry event is sent with a delay of the retry period. Then, the upgrade precondition check retry event is handled, i.e., the upgrade precondition check is re-initiated, and the current state is maintained as upgrade policy check state 407, or a state transition to upgrade policy check state 407 is triggered. In upgrade policy check state 407, an upgrade precondition check failure event is handled, the reason for the failure is recorded, and the number of retries and retry period for the upgrade precondition check are obtained from the configuration file. If the number of retries has been exhausted, a state transition is triggered, transitioning to state 410 awaiting user confirmation.

[0245] Additionally, upgrade precondition check failure events do not need to be processed in the "upgrade in progress" or "waiting for user confirmation" states. For upgrade precondition check failure events in the current state, they do not need to be processed in the upgrade strategy check state, so they need to be cleared upon exiting that state. Upgrade precondition check retry events do not need to be processed in the "upgrade in progress" or "waiting for user confirmation" states. For upgrade precondition check retry events in the current state, they do not need to be processed in the upgrade strategy check state, so they need to be cleared upon exiting that state. Upgrade strategy check timeout events do not need to be processed in the "upgrade in progress," "waiting for user confirmation," or "upgrade strategy check" states, so they need to be cleared upon exiting that state. When implemented using a timer, the timer needs to be cleared.

[0246] In this embodiment, when handling upgrade precondition check failure events and / or upgrade policy check timeout events in the upgrade policy check state of the target application, configuration information of the state machine is obtained. This configuration information may include the number of retries and the retry period for the upgrade precondition check. When the number of retries is not zero, the number of retries is decremented by 1, and the upgrade precondition check retry event is handled with a delay of the retry period, maintaining the target application's current state as the upgrade policy check state. This allows for a re-initiation of the check if the upgrade precondition check fails, ensuring a smooth upgrade. By migrating the target application from the upgrade policy check state to the state awaiting user confirmation, and resetting the number of retries to the target number, the user can be notified of the upgrade failure when the retries are exhausted, and user confirmation is awaited, thus completing the SOTA upgrade process.

[0247] In some embodiments, the current state may include the status of performing an upgrade, the event information may include information about the installation completion event, the target state may include the upgrade result verification status, and S230 may specifically include:

[0248] When processing the installation completion event in the state of executing the upgrade of the target application, the target application is transitioned from the state of executing the upgrade to the state of verifying the upgrade result.

[0249] The "Upgrade in Progress" state can be the state where the target application is being installed. Entering this state initiates the installation of the upgrade package. The installation process in this state can include a rollback process after failure; that is, both a successful upgrade and a completed rollback after an upgrade failure are considered as successful installation. The application remains in the "Upgrade in Progress" state until the pre-installation prerequisite checks are passed and the installation is complete or the state times out.

[0250] As an example, such as Figure 4 As shown, when processing the installation completion event in state 408 during the upgrade process, a state transition is triggered, transitioning to state 409 for upgrade result verification.

[0251] Since the installation completion event is not required and will not be processed in the upgrade result verification state or the waiting for user confirmation state, it does not need to be cleared when exiting that state.

[0252] In this embodiment of the application, by processing the installation completion event in the state of executing the upgrade of the target application, the target application is transitioned from the state of executing the upgrade to the state of verifying the upgrade result. This allows the application to jump to the upgrade result verification step of the upgrade process when the upgrade is successful, thereby completing the upgrade of the target application.

[0253] In some embodiments, the current state may include the state of performing an upgrade, the event information may include information about the state timeout event of performing the upgrade, the target state may include the state of waiting for user confirmation, and S230 may specifically include:

[0254] When handling state timeout events during the execution upgrade process in the target application's execution upgrade state, the target application is transitioned from the execution upgrade state to the state awaiting user confirmation, and the execution upgrade state timeout events in the state machine's buffer are cleared.

[0255] The state timeout event during the upgrade process can be a state timeout event sent with a preset delay time when entering the state of the upgrade process. This state timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine configuration file as the state timeout time and passed in when constructing the state object of the upgrade process; or the delay time can be estimated based on the size of the upgrade package of the target application and initialized when entering the state of the upgrade process.

[0256] As an example, such as Figure 4 As shown, when handling the timeout event during the upgrade process in state 408, the installation is aborted, the timeout information is recorded, and a state transition is triggered, transitioning to state 410 where user confirmation is pending.

[0257] Additionally, the status timeout event during the upgrade process does not need to be processed but will be handled in the waiting for user confirmation of the upgrade status, waiting for user confirmation of the upgrade status, or waiting for user confirmation of the result status. Therefore, it needs to be cleared when exiting the status. When implemented using a timer, the timer needs to be cleared.

[0258] In this embodiment of the application, when processing the state timeout event during the execution upgrade of the target application, the target application is transitioned from the state of execution upgrade to the state of waiting for user confirmation. In the event of upgrade timeout, the user is notified of the failure result and waits for user confirmation, so as to complete the process in a state-of-the-art (SOTA) manner.

[0259] In some embodiments, the current state may include an upgrade result verification state, the event information may include verification success event and verification failure event information, the target state may include a state waiting for user confirmation, and S230 may specifically include:

[0260] When processing successful or failed verification events in the upgrade result verification state of the target application, the target application is transitioned from the upgrade result verification state to the state of waiting for user confirmation, and the successful and failed verification events in the state machine's buffer are cleared.

[0261] The upgrade result verification status can be the state in which the target application performs post-installation processing verification. Entering this status initiates the upgrade result verification of the target application, specifically comparing the target version being upgraded with the current upgraded version. The application remains in the upgrade result verification status until the new version installation is complete and the verification process is successful or fails.

[0262] As an example, such as Figure 4 As shown, when processing a successful or failed verification event in the upgrade result verification state 409, the retry count is reset, the SOTA result is recorded, and a state transition is triggered, transitioning to the state 410 waiting for user confirmation. The retry count can be loaded in the state machine's configuration file.

[0263] Successful verification events do not need to be processed in the "Waiting for User Confirmation" state. For successful verification events in the current state, they do not need to be processed in the "Upgrade Result Verification" state, so they need to be cleared when exiting this state. Failed verification events do not need to be processed in the "Waiting for User Confirmation" state. For failed verification events in the current state, they do not need to be processed in the "Upgrade Result Verification" state, so they need to be cleared when exiting this state.

[0264] In this embodiment of the application, when processing a successful verification event or a failed verification event in the upgrade result verification state of the target application, the target application is moved from the upgrade result verification state to the state of waiting for user confirmation, which facilitates the process step of jumping to the state of waiting for user confirmation after verification.

[0265] In some embodiments, the current state may include an upgrade result verification state, and the event information may include information on upgrade result verification state timeout events and version verification retry events. The upgrade method for the vehicle application may also include:

[0266] When handling the upgrade result verification status timeout event in the target application's upgrade result verification status, obtain the state machine's configuration information. The configuration information may include the number of retries and the retry period.

[0267] If the number of retries is not zero, decrement the number of retries by 1, and process the version verification retry event with a delay of the retry period.

[0268] Maintain the target application's current state as the upgrade result verification state, and clear the upgrade result verification state timeout event and version verification retry event from the state machine's buffer.

[0269] In some embodiments, the method for upgrading the vehicle application may further include:

[0270] When the number of retries is 0, the target application is transitioned from the upgrade result verification state to the waiting for user confirmation state, the number of retries is reset to the target number, and the upgrade result verification state timeout event in the state machine's buffer is cleared.

[0271] The upgrade result verification status timeout event can be a status timeout event sent with a preset delay time when entering the upgrade result verification status. This status timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine's configuration file as the status timeout time and passed in when constructing the upgrade result verification status object.

[0272] The upgrade result verification status supports setting the number of retries and the retry period, which are loaded from the state machine configuration file and passed in when constructing the upgrade result verification status object. If the number of retries is exhausted, the SOTA result, i.e., the upgrade failure result, is recorded, and a state transition is triggered to the waiting for user confirmation status, and the number of retries is reset to the target number, which can be any preset number.

[0273] As an example, such as Figure 4 As shown, in upgrade result verification state 409, the upgrade result verification state timeout event is handled. The number of retries and the retry period are obtained from the configuration file. If the number of retries has not been exhausted, the number of retries is decremented by 1, and a verification version retry event is sent with a delay of the retry period. Then, the verification version retry event is handled, i.e., the upgrade result verification is re-initiated, maintaining the current state as upgrade result verification state 409, or triggering a state transition to upgrade result verification state 409. In upgrade result verification state 409, the upgrade result verification state timeout event is handled. The number of retries and the retry period are obtained from the configuration file. If the number of retries has been exhausted, the SOTA result, i.e., the upgrade failure result, is recorded, and a state transition is triggered, transitioning to the waiting for user confirmation result state 410.

[0274] Additionally, the upgrade result verification status timeout event is not required but will be processed in the waiting for user confirmation status or the upgrade result verification status, so it needs to be cleared when exiting this status. If implemented using a timer, the timer needs to be cleared. The version verification retry event is not required and will not be processed in the waiting for user confirmation status. For the version verification retry event in the current status, it is not required but will be processed in the upgrade result verification status, so it needs to be cleared when exiting this status.

[0275] In this embodiment, when handling the upgrade result verification timeout event in the target application's upgrade result verification state, the configuration information of the state machine is obtained. This configuration information may include the number of retries and the retry period. When the number of retries is not zero, the number of retries is decremented by 1, and the version verification retry event is handled with a delay of the retry period, maintaining the target application's current state as the upgrade result verification state. This allows for re-initiating verification even if the upgrade result verification times out, ensuring a smooth upgrade. When the number of retries reaches zero, the target application is transitioned from the upgrade result verification state to the state awaiting user confirmation. This allows for notifying the user of the upgrade failure result when the retries are exhausted and waiting for user confirmation, thus completing the SOTA upgrade process.

[0276] In some embodiments, the current state may include a state awaiting user confirmation, the event information may include information about the user confirmation of the upgrade result event, the target state may include a state with no updates available, and S230 may specifically include:

[0277] When processing the user confirmation upgrade result event in the target application's waiting-for-user-confirmation-result state, the target application is transitioned from the waiting-for-user-confirmation-result state to the no-update-available state, and the user confirmation upgrade result event in the state machine's buffer is cleared.

[0278] The "Waiting for User Confirmation" state can be a state where the application is awaiting user confirmation of the upgrade result. Upon entering this state, the cloud-based SOTA (State Over-The-Air) result is notified, the vehicle-mounted system is notified of the SOTA result, and user confirmation is awaited. The application remains in the "Waiting for User Confirmation" state from the time the upgrade succeeds or fails until the user confirms the result.

[0279] As an example, such as Figure 4 As shown, when processing the user confirmation upgrade result event in state 410 while waiting for user confirmation result, a state transition is triggered, transitioning to state 401 where no updates are available.

[0280] Additionally, the user confirmation of upgrade result event does not need to be processed in the state of no available updates. For the user confirmation of upgrade result event in the current state, it does not need to be processed in the state of waiting for user confirmation result, so it needs to be cleared when exiting this state.

[0281] In this embodiment of the application, when processing the user confirmation upgrade result event in the state of the target application waiting for user confirmation result, the target application is migrated from the state of waiting for user confirmation result to the state of no available updates. This allows a complete SOTA upgrade process to be completed after the user confirms the upgrade result, and then jumps to the state of no available updates, which facilitates the next upgrade process.

[0282] In some embodiments, the current state may include a state awaiting user confirmation, and the event information may include information about a timeout event for the state awaiting user confirmation. The vehicle application upgrade method may further include:

[0283] When handling the timeout event for the waiting-for-user-confirmation-result state in the target application's waiting-for-user-confirmation-result state, the target application's current state is maintained as the waiting-for-user-confirmation-result state, and the waiting-for-user-confirmation-result-timeout event in the state machine's buffer is cleared.

[0284] The status timeout event for waiting for user confirmation can be a status timeout event sent with a preset delay time when entering the status of waiting for user confirmation. This status timeout event can also be implemented through a timer. The preset delay time can be loaded from the state machine's configuration file as the status timeout time and passed in when constructing the status object for waiting for user confirmation.

[0285] As an example, such as Figure 4 As shown, when processing the timeout event of the waiting for user confirmation result state under the waiting for user confirmation result state 410, the current state of the target application is maintained as the waiting for user confirmation result state 410, or the state is transitioned to the waiting for user confirmation result state 410, so as to re-notify the vehicle terminal of the SOTA result and wait for user confirmation.

[0286] The timeout event for the "Waiting for User Confirmation" state is not required but will be processed during the "Waiting for User Confirmation" state, so it needs to be cleared when exiting the state. If implemented using a timer, the timer needs to be cleared.

[0287] In this embodiment of the application, when processing the timeout event of the waiting for user confirmation result state in the state of the target application, the current state of the target application is maintained as the waiting for user confirmation result state. In the event of the waiting for user confirmation result timeout, the vehicle terminal can be notified of the SOTA result again and wait for user confirmation, which facilitates the completion of the complete upgrade process.

[0288] This application provides a database-based SOTA state recovery scheme. State recovery can be an exception handling mechanism after the SOTA service receives an external signal or restarts due to a runtime anomaly. Specifically, once the SOTA service restarts, the SOTA state of each application managed by the SOTA service needs to be restored to its state before the restart.

[0289] Based on this, in some embodiments, the method for upgrading the vehicle application may further include:

[0290] The target state and the data generated during the upgrade of the target application are written to the database. When the state machine starts, the target state of the target application is retrieved from the database.

[0291] The database needs to provide a read / write interface for the state machine state. When a state transition occurs in each state machine, this interface needs to be called to write data.

[0292] The data generated during the upgrade of the target application can include application data that each state of the state machine depends on. Specifically, it can include data related to the target version: target version number, target version release notes, target version policy check list, etc.; download-related data for the target version: download size, download link, decryption algorithm, hash value, etc.; installation-related data for the target version: local path of the installation package, local path of the rollback package, installation method, etc.; and SOTA process-related data: policy check result list, download results, installation results, etc.

[0293] When the state machine starts, to achieve state recovery, it retrieves the target state for entering the target application from the database. It can also retrieve the application data that the target state depends on from the database, thus entering the target state. Apart from event-driven state transitions, there are no interdependencies between states; the database provides a relatively independent decoupling scheme between states.

[0294] As an example, such as Figure 5 As shown, when the Software Over-The-Air (SOTA) service starts, the state machine manager 501 initiates the startup of each state machine 502. When each state machine 502 starts, it accesses the database 503, obtains the target state, and starts the state machine 502. That is, the target application continues to execute the SOTA process from the target state at the time of exiting the SOTA service.

[0295] In this embodiment, by writing the target state and data generated during the upgrade of the target application into a database, it is easier to resume the interrupted SOTA process of each application. By retrieving the target state of the target application from the database when the state machine starts, the SOTA process can continue from the target state at the time of exiting the SOTA service, thus realizing the interrupted resumption of the SOTA process of each application.

[0296] Figure 6 This is a schematic diagram illustrating the structure of a vehicle application upgrade device 200 according to an exemplary embodiment.

[0297] like Figure 6 As shown, the vehicle application upgrade device 600 is applied to the state machine and may include:

[0298] The detection module 601 is used to detect the current state of the target application upon receiving an upgrade message from the state machine manager.

[0299] The receiving module 602 is also used to receive event information in the current state, including information about events generated during the upgrade of the target application.

[0300] The state transition module 603 is used to transition the target application from its current state to a target state when processing events in the current state of the target application, so as to complete the upgrade of the target application.

[0301] In one implementation, the current state includes a state with no available updates, the event information includes information on querying available updates events and timeout events for the state with no available updates, and the target state includes a state with querying available upgrades.

[0302] The state transition module 603 is also used to transition the target application from the state of no available updates to the state of querying available updates when processing the query available update event and / or the state of no available updates timeout event in the state of no available updates of the target application, and to clear the state of no available updates timeout event in the buffer of the state machine when processing the state of no available updates timeout event.

[0303] In one implementation, the current state includes a state where no updates are available, the event information includes information about proactive push events for new versions, and the target state includes a state awaiting user confirmation for download.

[0304] The state transition module 603 is also used to transition the target application from a state with no available updates to a state waiting for user confirmation to download when handling proactive push events for new versions of the target application in a state where no updates are available.

[0305] In one implementation, the current state includes a query for available upgrade status, and the event information includes information on new version detected events, proactive push events for new versions, no new version detected events, and timeout events for querying available upgrade status. The target state includes a waiting-for-user-confirmation-download status and a no-update-available status.

[0306] The state transition module 603 is also used to handle the detection of a new version event and / or a proactive push event of a new version when the target application is in the query-available-upgrades state, by transitioning the target application from the query-available-upgrades state to the waiting-for-user-confirm-download state.

[0307] The state transition module 603 is also used to transition the target application from the query available upgrade state to the no available update state when handling the no new version detected event and / or the query available upgrade state timeout event in the query available upgrade state of the target application, and to clear the query available upgrade state timeout event in the state machine buffer when handling the query available upgrade state timeout event.

[0308] In one implementation, the current state includes a waiting-for-user-confirmation-download status, and the event information includes information on proactive push events for new versions and timeout events for waiting for user confirmation of the download status. The vehicle application upgrade device also includes a processing module.

[0309] The processing module is used to maintain the current state as the waiting-for-user-confirmation-download state when handling the proactive push event for a new version and / or the waiting-for-user-confirmation-download state timeout event in the target application's waiting-for-user-confirmation-download state state, and to clear the waiting-for-user-confirmation-download state timeout event from the state machine's buffer when handling the waiting-for-user-confirmation-download state timeout event.

[0310] In one implementation, the current state includes a waiting-for-user-confirmation-download status, the event information includes information about an event where the user confirms the download of the new version, and the target state includes a download policy check status.

[0311] The state transition module 603 is also used to transition the target application from the waiting for user confirmation to the download policy check state when processing the user confirmation for download event in the waiting for user confirmation download state of the target application, and to clear the user confirmation for download event in the state machine buffer.

[0312] In one implementation, the current state includes a download policy check status, the event information includes information about download precondition check passing events, and the target state includes the status of downloading in progress.

[0313] The state transition module 603 is also used to transition the target application from the download policy check state to the download in progress state when processing the download precondition check pass event in the download policy check state of the target application, and to clear the download precondition check pass event in the state machine buffer.

[0314] In one implementation, the current state includes a download policy check state, and the event information includes information on download precondition check failure events, download policy check state timeout events, and download precondition check retry events. The vehicle application upgrade device also includes an acquisition module.

[0315] The acquisition module is used to acquire the state machine configuration information when handling precondition check failure events and / or download policy check timeout events in the download policy check state of the target application. The configuration information includes the number of retries and the retry period for the download precondition check.

[0316] The processing module is also used to decrement the retry count by 1 when the retry count is not 0, and to process the download precondition check retry event with the retry period as a delay.

[0317] The processing module is also used to maintain the current state of the target application as the download policy check state, and to clear the download precondition check failure event, download policy check timeout event, and download precondition check retry event from the state machine's buffer.

[0318] The state transition module 603 is also used to transition the target application from the download policy check state to the waiting for user confirmation state when the number of retries is 0, reset the number of retries to the target number, and clear the download precondition check failure event and the download policy check state timeout event in the state machine's buffer.

[0319] In one implementation, the current state includes a download in progress status, the event information includes information about a successful download event, and the target state includes a status awaiting user confirmation for an upgrade.

[0320] The state transition module 603 is also used to transition the target application from the state of downloading to the state of waiting for user confirmation of upgrade when the download success event is processed in the state of the target application in the downloading process.

[0321] In one implementation, the current state includes a download in progress status, event information includes download failure events, download in progress timeout events, and user-cancelled download events, and the target state includes a waiting-for-user-confirmation-result status and a waiting-for-user-confirmation-download status.

[0322] The state transition module 603 is further configured to, when handling download failure events and / or download timeout events in the state of the target application during download execution, transition the target application from the download execution state to the state of waiting for user confirmation, and clear the download timeout event from the state machine's buffer in the case of handling the download timeout event.

[0323] The state transition module 603 is also used to handle user cancel download events when the target application is in the state of executing download, by transitioning the target application from the state of executing download to the state of waiting for user confirmation of download, and clearing the user cancel download event in the state machine's buffer.

[0324] In one implementation, the current state includes a state awaiting user confirmation for upgrade, the event information includes information on user confirmation of installation events and user cancellation of new version installation events, and the target state includes an upgrade policy check state and a state awaiting user confirmation for download.

[0325] The state transition module 603 is also used to transition the target application from the waiting-for-user-confirmation-upgrade state to the upgrade policy check state when processing user confirmation installation events in the target application's waiting-for-user-confirmation-upgrade state, and to clear the user confirmation installation events from the state machine's buffer.

[0326] The state transition module 603 is also used to transition the target application from the waiting-for-user-confirmation-upgrade state to the waiting-for-user-confirmation-download state when handling user cancellation of new version installation events in the waiting-for-user-confirmation-upgrade state of the target application, and to clear the user cancellation of new version installation events in the state machine buffer.

[0327] In one implementation, the current state includes a state awaiting user confirmation of the upgrade, and the event information includes information about timeout events related to the state awaiting user confirmation of the upgrade.

[0328] The processing module is also used to maintain the current state of the target application as the state of waiting for user confirmation for upgrade when processing the timeout event of the state of waiting for user confirmation for upgrade, and to clear the timeout event of the state of waiting for user confirmation for upgrade in the state machine's buffer.

[0329] In one implementation, the current state includes the upgrade policy check status, the event information includes information about the upgrade precondition check passing event, and the target state includes the status of performing the upgrade.

[0330] The state transition module 603 is also used to transition the target application from the upgrade policy check state to the state of performing upgrade when processing the upgrade precondition check pass event in the upgrade policy check state of the target application, and to clear the upgrade precondition check pass event in the state machine buffer.

[0331] In one implementation, the current state includes an upgrade policy check state, and the event information includes information on upgrade precondition check failure events, upgrade policy check state timeout events, and upgrade precondition check retry events.

[0332] The acquisition module is also used to acquire the configuration information of the state machine when handling upgrade precondition check failure events and / or upgrade strategy check timeout events in the upgrade strategy check state of the target application. The configuration information includes the number of retries and the retry period for the upgrade precondition check.

[0333] The processing module is also used to decrement the retry count by 1 when the retry count is not 0, and to process the upgrade precondition check retry event with the retry period as a delay.

[0334] The processing module is also used to maintain the current state of the target application as the upgrade policy check state, and clear the upgrade precondition check failure event, upgrade policy check state timeout event and upgrade precondition check retry event in the state machine's buffer. The state transition module 603 is also used to transition the target application from the upgrade policy check state to the waiting for user confirmation result state when the retry count is 0, reset the retry count to the target count, and clear the upgrade precondition check failure event and upgrade policy check state timeout event in the state machine's buffer.

[0335] In one implementation, the current state includes the status of performing an upgrade, the event information includes information about an installation completion event, and the target state includes the upgrade result verification status.

[0336] The state transition module 603 is also used to transition the target application from the state of performing the upgrade to the state of verifying the upgrade result when processing the installation completion event in the state of the target application performing the upgrade.

[0337] In one implementation, the current state includes an upgrade in progress status, the event information includes timeout information for the upgrade in progress status, and the target state includes a status awaiting user confirmation.

[0338] The state transition module 603 is also used to process the state timeout event during the execution upgrade of the target application, when the target application is in the execution upgrade state, to transition the target application from the execution upgrade state to the state of waiting for user confirmation, and to clear the execution upgrade state timeout event in the state machine buffer.

[0339] In one implementation, the current state includes an upgrade result verification state, the event information includes verification success and verification failure information, and the target state includes a state awaiting user confirmation.

[0340] The state transition module 603 is also used to transition the target application from the upgrade result verification state to the waiting for user confirmation state when processing the verification success event or verification failure event in the upgrade result verification state of the target application, and to clear the verification success event and verification failure event in the state machine buffer.

[0341] In one implementation, the current state includes an upgrade result verification state, and the event information includes information on upgrade result verification state timeout events and version verification retry events.

[0342] The acquisition module is also used to acquire the state machine's configuration information when handling upgrade result verification status timeout events in the target application's upgrade result verification status. This configuration information includes the number of retries and the retry period.

[0343] The processing module is also used to decrement the retry count by 1 when the retry count is not 0, and to process the verification version retry event with a delay of the retry period.

[0344] The processing module is also used to maintain the current state of the target application as the upgrade result verification state, and to clear the upgrade result verification state timeout event and version verification retry event from the state machine's buffer.

[0345] The state transition module 603 is also used to transition the target application from the upgrade result verification state to the waiting for user confirmation state when the number of retries is 0, reset the number of retries to the target number, and clear the upgrade result verification state timeout event in the state machine's buffer.

[0346] In one implementation, the current state includes a state awaiting user confirmation, the event information includes information about a user confirmation of the upgrade result event, and the target state includes a state with no available updates.

[0347] The state transition module 603 is also used to transition the target application from the waiting for user confirmation result state to the no-update-available state when processing the user confirmation upgrade result event in the waiting for user confirmation result state of the target application, and to clear the user confirmation upgrade result event in the buffer of the state machine.

[0348] In one implementation, the current state includes a state awaiting user confirmation, and the event information includes information about a timeout event in the state awaiting user confirmation.

[0349] The processing module is also used to maintain the current state of the target application as the state of waiting for user confirmation when processing the timeout event of the state of waiting for user confirmation in the state of waiting for user confirmation result of the target application, and to clear the timeout event of the state of waiting for user confirmation result in the buffer of the state machine.

[0350] In one implementation, the vehicle application upgrade device further includes a data writing module.

[0351] The data writing module is used to write the target state and data generated during the upgrade of the target application into the database.

[0352] The acquisition module is also used to retrieve the target state for entering the target application from the database when the state machine starts.

[0353] Therefore, by detecting the current state of the target application upon receiving an upgrade message from the state machine manager, the SOTA process can be managed for each application through a corresponding state machine. Next, event information in the current state is received, including information about events generated during the upgrade process. Then, while processing events in the target application's current state, the application is transitioned from its current state to the target state; that is, the upgrade is completed through state transition. This allows the application to be treated as the upgrade object, enabling more granular control over the upgrade process. By controlling state transition through a state machine, the SOTA process can be implemented more accurately and efficiently.

[0354] Figure 7 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0355] An electronic device may include a processor 701 and a memory 702 storing computer program instructions.

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

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

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

[0359] The processor 701 implements any of the vehicle application upgrade methods in the above embodiments by reading and executing computer program instructions stored in the memory 702.

[0360] In one example, the electronic device may also include a communication interface 703 and a bus 710. For example, Figure 3 As shown, the processor 701, memory 702, and communication interface 703 are connected through bus 710 and complete communication with each other.

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

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

[0363] This electronic device can, upon receiving an upgrade message for the target application sent by the state machine manager, detect the current state of the target application and execute the vehicle application upgrade method in this embodiment, thereby achieving a combination of... Figure 2 The method for upgrading vehicle applications is described.

[0364] Furthermore, in conjunction with the vehicle application upgrade methods in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle application upgrade methods in the above embodiments.

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

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

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

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

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

Claims

1. A method for upgrading a vehicle application, characterized in that, The method is applied to the state machine in a software remote upgrade service engine. The software remote upgrade service engine includes a state machine manager and a state machine corresponding to each application. The state machine manager is used to receive messages sent by the service and distribute them to the state machines corresponding to each application. The state machines are used to drive each application according to the driving behavior corresponding to the message. The method includes: Upon receiving an upgrade message for the target application from the state machine manager, the current state of the target application is checked. Receive event information in the current state, the event information including information about events generated during the upgrade of the target application. When processing the event in the current state of the target application, the target application is migrated from the current state to the target state to complete the upgrade of the target application; The current state includes a state with no available updates, the event information includes information on querying available updates events and timeout events for a state with no available updates, the target state includes a state with querying available upgrades, and when processing the event in the current state of the target application, the target application is migrated from the current state to the target state, which includes: when processing querying available updates events and / or timeout events for a state with no available updates in the current state of the target application, the target application is migrated from a state with no available updates to a state with querying available upgrades, and in the case of processing timeout events for a state with no available updates, the timeout events for a state with no available updates are cleared from the buffer of the state machine; The current state includes a state with no available updates, the event information includes information about proactive push events for new versions, and the target state includes a state waiting for user confirmation to download. When processing the event in the current state of the target application, the target application is migrated from the current state to the target state. This also includes: when processing proactive push events for new versions in the state with no available updates of the target application, the target application is migrated from the state with no available updates to the state waiting for user confirmation to download.

2. The method according to claim 1, characterized in that, The current state includes querying available upgrade status; the event information includes information on new version detection events, new version proactive push events, no new version detection events, and querying available upgrade status timeout events; the target state includes waiting for user confirmation download status and no available updates status; when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing events such as detecting a new version and / or proactively pushing a new version to the target application in the query-available-upgrades state, the target application is moved from the query-available-upgrades state to the waiting-for-user-confirmation-download state. When processing the "No new version detected" event and / or "Query available upgrade state timeout" event in the "Query available upgrade state" of the target application, the target application is migrated from the "Query available upgrade state" to the "No available update" state, and the "Query available upgrade state timeout" event in the state machine's buffer is cleared when processing the "Query available upgrade state timeout" event.

3. The method according to claim 1, characterized in that, The current state includes a waiting-for-user-confirmation-download state, the event information includes information about an event where the user confirms the download of a new version, the target state includes a download strategy check state, and when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing the user confirmation download event in the waiting-for-user-confirmation-download state of the target application, the target application is transitioned from the waiting-for-user-confirmation-download state to the download policy check state, and the user confirmation download event in the state machine's buffer is cleared.

4. The method according to claim 1, characterized in that, The current state includes a waiting-for-user-confirmation-download status, the event information includes information on new version push events and timeout events for waiting for user confirmation of the download status, and the method further includes: When processing the new version push event and / or the user confirmation download timeout event in the target application's waiting-for-user-confirmation-download state, the current state is maintained as the waiting-for-user-confirmation-download state, and in the case of processing the user confirmation download timeout event, the waiting-for-user-confirmation-download timeout event in the state machine's buffer is cleared.

5. The method according to claim 1, characterized in that, The current state includes a download strategy check state, the event information includes information about a download precondition check passing event, the target state includes a download in progress state, and when processing the event in the current state of the target application, the process of migrating the target application from the current state to the target state further includes: When processing the download precondition check pass event in the download policy check state of the target application, the target application is transitioned from the download policy check state to the state of downloading, and the download precondition check pass event in the state machine's buffer is cleared.

6. The method according to claim 1, characterized in that, The current state includes the download policy check state, and the event information includes information on download precondition check failure events, download policy check state timeout events, and download precondition check retry events. The method further includes: When handling download precondition check failure events and / or download policy check timeout events in the download policy check state of the target application, the configuration information of the state machine is obtained. The configuration information includes the number of retries and the retry period for the download precondition check. If the number of retries is not zero, the number of retries is decremented by 1, and the retry event is checked as a precondition for downloading, with the retry period as the delay. Maintain the current state of the target application as the download policy check state, and clear the download precondition check failure event, download policy check timeout event, and download precondition check retry event from the state machine's buffer. When the number of retries is 0, the target application is transitioned from the download policy check state to the waiting for user confirmation state, the number of retries is reset to the target number, and the download precondition check failure event and the download policy check state timeout event are cleared from the state machine's buffer.

7. The method according to claim 1, characterized in that, The current state includes a download in progress state, the event information includes information about a successful download event, and the target state includes a state awaiting user confirmation for an upgrade. When processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing a successful download event while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-upgrade state.

8. The method according to claim 1, characterized in that, The current state includes a download in progress state, the event information includes download failure events, download in progress timeout events, and user-cancelled download events, the target state includes a waiting-for-user-confirmation-result state and a waiting-for-user-confirmation-download state, and when processing the event in the current state of the target application, the process of migrating the target application from the current state to the target state further includes: When handling download failure events and / or download timeout events in the state where the target application is in the process of downloading, the target application is transitioned from the downloading state to the state of waiting for user confirmation. Furthermore, in the case of a download timeout event, the download timeout event is cleared from the state machine's buffer. When handling a user cancel download event while the target application is in the downloading state, the target application is transitioned from the downloading state to the waiting-for-user-confirmation-download state, and the user cancel download event is cleared from the state machine's buffer.

9. The method according to claim 1, characterized in that, The current state includes a state awaiting user confirmation for an upgrade; the event information includes information on user confirmation of installation events and user cancellation of new version installation events; the target state includes an upgrade policy check state and a state awaiting user confirmation for a download; when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing user confirmation installation events in the target application's "waiting for user confirmation upgrade" state, the target application is transitioned from the "waiting for user confirmation upgrade" state to the "upgrade policy check" state, and the user confirmation installation events in the state machine's buffer are cleared. When processing a user cancels new version installation event while the target application is in the state of waiting for user confirmation to upgrade, the target application is transitioned from the state of waiting for user confirmation to the state of waiting for user confirmation to download, and the user cancels new version installation event in the state machine's buffer is cleared.

10. The method according to claim 1, characterized in that, The current state includes a state awaiting user confirmation of the upgrade, the event information includes timeout event information for the state awaiting user confirmation of the upgrade, and the method further includes: When processing the timeout event of the waiting-for-user-confirmation-upgrade state in the target application's waiting-for-user-confirmation-upgrade state, the current state of the target application is maintained as the waiting-for-user-confirmation-upgrade state, and the timeout event of the waiting-for-user-confirmation-upgrade state in the state machine's buffer is cleared.

11. The method according to claim 1, characterized in that, The current state includes an upgrade strategy check state, the event information includes information about upgrade precondition check passing events, the target state includes an upgrade in progress state, and when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing the upgrade precondition check pass event in the upgrade policy check state of the target application, the target application is transitioned from the upgrade policy check state to the upgrade in progress state, and the upgrade precondition check pass event in the state machine buffer is cleared.

12. The method according to claim 1, characterized in that, The current state includes the upgrade strategy check state, and the event information includes information on upgrade precondition check failure events, upgrade strategy check state timeout events, and upgrade precondition check retry events. The method further includes: When handling upgrade precondition check failure events and / or upgrade strategy check timeout events in the upgrade strategy check state of the target application, the configuration information of the state machine is obtained. The configuration information includes the number of retries and the retry period for the upgrade precondition check. If the number of retries is not zero, the number of retries is decremented by 1, and the retry event is checked as a prerequisite for upgrade processing with the retry period as a delay. Maintain the current state of the target application as the upgrade policy check state, and clear the upgrade precondition check failure event, upgrade policy check timeout event, and upgrade precondition check retry event from the state machine's buffer. When the number of retries is 0, the target application is transitioned from the upgrade policy check state to the waiting for user confirmation state, the number of retries is reset to the target number, and the upgrade precondition check failure event and upgrade policy check state timeout event are cleared from the state machine's buffer.

13. The method according to claim 1, characterized in that, The current state includes the state of performing an upgrade, the event information includes information about an installation completion event, the target state includes an upgrade result verification state, and when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing the installation completion event in the state of executing the upgrade of the target application, the target application is transitioned from the state of executing the upgrade to the state of verifying the upgrade result.

14. The method according to claim 1, characterized in that, The current state includes a state of performing an upgrade, the event information includes information about a timeout event in the state of performing an upgrade, the target state includes a state of waiting for user confirmation, and when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing the execution upgrade state timeout event in the state of the target application, the target application is transitioned from the execution upgrade state to the state of waiting for user confirmation, and the execution upgrade state timeout event in the state machine's buffer is cleared.

15. The method according to claim 1, characterized in that, The current state includes an upgrade result verification state, the event information includes verification success event information and verification failure event information, the target state includes a state waiting for user confirmation, and when processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing a successful verification event or a failed verification event in the upgrade result verification state of the target application, the target application is transitioned from the upgrade result verification state to the state of waiting for user confirmation, and the successful verification event and the failed verification event in the state machine's buffer are cleared.

16. The method according to claim 1, characterized in that, The current state includes the upgrade result verification state, the event information includes information on the upgrade result verification state timeout event and the version verification retry event, and the method further includes: When processing the upgrade result verification status timeout event in the target application's upgrade result verification status, the configuration information of the state machine is obtained. This configuration information includes the number of retries and the retry period. When the number of retries is not zero, the number of retries is decremented by 1, and the verification version retry event is processed with a delay of the retry period. Maintain the current state of the target application as the upgrade result verification state, and clear the upgrade result verification state timeout event and version verification retry event from the state machine's buffer. When the number of retries is 0, the target application is moved from the upgrade result verification state to the waiting for user confirmation state, the number of retries is reset to the target number, and the upgrade result verification state timeout event in the state machine's buffer is cleared.

17. The method according to claim 1, characterized in that, The current state includes a state awaiting user confirmation, the event information includes information about a user confirmation of an upgrade result event, and the target state includes a state with no available updates. When processing the event in the current state of the target application, migrating the target application from the current state to the target state further includes: When processing the user confirmation upgrade result event in the state of the target application waiting for user confirmation result, the target application is transitioned from the state of waiting for user confirmation result to the state of no available updates, and the user confirmation upgrade result event in the state machine's buffer is cleared.

18. The method according to claim 1, characterized in that, The current state includes a state awaiting user confirmation, the event information includes information about a timeout event in the state awaiting user confirmation, and the method further includes: When processing the waiting-for-user-confirmation-result-timeout event in the waiting-for-user-confirmation-result-state of the target application, the current state of the target application is maintained as the waiting-for-user-confirmation-result-state, and the waiting-for-user-confirmation-result-timeout event in the state machine's buffer is cleared.

19. The method according to claim 1, characterized in that, The method further includes: The target state and the data generated during the upgrade of the target application are written into the database. When the state machine starts, it retrieves the target state for entering the target application from the database.

20. An upgrade device for a vehicle application, characterized in that, The device is applied to a state machine, and the device includes: The detection module is used to detect the current state of the target application upon receiving an upgrade message from the state machine manager. A receiving module is configured to receive event information in the current state, the event information including information about events generated during the upgrade of the target application. A state transition module is used to transition the target application from its current state to a target state when the event is being processed in the current state of the target application, so as to complete the upgrade of the target application; The current state includes a state with no available updates, the event information includes information on query available updates events and timeout events for a state with no available updates, the target state includes a state with query available upgrades, and the state transition module is further configured to, when processing query available updates events and / or timeout events for a state with no available updates in the target application's state with no available updates, transition the target application from a state with no available updates to a state with query available upgrades, and, in the case of processing timeout events for a state with no available updates, clear the timeout events for a state with no available updates from the buffer of the state machine; The current state includes a state with no available updates, the event information includes information about proactive push events for new versions, the target state includes a state waiting for user confirmation to download, and the state transition module is further used to transition the target application from a state with no available updates to a state waiting for user confirmation to download when processing proactive push events for new versions in the state with no available updates of the target application.

Images