OTA upgrading method and device and system for OTA upgrading

Abstract

The invention provides an OTA upgrading method and a device and system for OTA upgrading, and relates to the technical field of intelligent vehicles, and the method comprises the following steps: in the OTA upgrading process of a vehicle, responding to a user request, and according to the OTA upgrading progress, executing at least one of the following operations: continuing upgrading, stopping upgrading or rolling back. Based on the scheme, the user request can be responded in the OTA upgrading period, so that the vehicle using requirement of the user is met as soon as possible, and the vehicle using experience of the user is prevented from being reduced.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of intelligent vehicles, in particular to an OTA upgrade method, a device and a system for OTA upgrade. BACKGROUND

[0002] The over the air (OTA) upgrade technology of intelligent vehicle software is a widely used vehicle software upgrade method. In order to ensure the safety of OTA upgrade, the user needs to park the vehicle in a safe area before performing OTA upgrade. For example, the OTA upgrade management software checks whether the vehicle state meets the conditions of P gear, 0 speed, and hand brake pulled up. In the case that the vehicle state meets the above conditions, the OTA upgrade management software triggers the OTA upgrade of the vehicle, and locks the gear of the vehicle during the OTA upgrade process, so the user cannot use the vehicle during the OTA upgrade. However, during the OTA upgrade of the vehicle, if the user has a demand, the user needs to wait until the vehicle upgrade is completed before using the vehicle, which cannot meet the user's demand for using the vehicle as soon as possible, thereby reducing the user's experience of using the vehicle. SUMMARY

[0003] The present application provides an OTA upgrade method, a device and a system for OTA upgrade, which can respond to user requests during OTA upgrade to meet the user's demand for using the vehicle as soon as possible to avoid the user's experience of using the vehicle from being reduced.

[0004] In a first aspect, an OTA upgrade method is provided. During the process of OTA upgrade of a vehicle, the method comprises: in response to a user request, performing at least one of the following operations according to the progress of OTA upgrade: continuing upgrade, aborting upgrade, or rolling back.

[0005] By way of example, a component set composed of all components of a vehicle can be divided into a necessary component set, a required component set, and a non-required component set according to the functions to be implemented by each component and the cooperative relationship with other components.

[0006] By way of example, each component in the necessary component set can be used to cooperatively implement a driving-related function of the vehicle. For example, the necessary component set can include components of the power domain (direct current converter, battery management system, etc.), the chassis domain (brake controller, electronic power steering controller, etc.), the vehicle control domain, and the thermal management system (compressor).

[0007] By way of example, the components in the necessary component set can also be the minimum components for cooperatively implementing an autonomous driving function, which can at least implement the basic function of an autonomous driving vehicle. The basic function can include driving driving function, braking function, high-voltage power-on and power-off function, steering function, battery temperature control function, etc.

[0008] For example, each component in the set of necessary components can be used to independently implement a driving-related function of the vehicle, for example, the set of necessary components can include driving safety-related components such as an airbag controller, a headlamp, a range extender, a vehicle speed display, an anti-theft authentication component, and a module.

[0009] For example, each component in the set of non-necessary components can be used to implement a non-driving-related function of the vehicle, for example, the set of non-necessary components can include ambient light, in-vehicle audio controller, in-vehicle infotainment system, and the like.

[0010] For example, the at least one operation can refer to an operation on a component in the current OTA upgrade, for example, an operation of continuing to upgrade the component, an operation of aborting the upgrade of the component, or an operation of rolling back the upgraded content of the component. The at least one operation can also refer to an operation on a task in the current OTA upgrade, for example, a task of continuing to perform the component upgrade, a task of aborting the component upgrade, or a task of rolling back the upgraded content of the component.

[0011] For example, the user request can represent the user's current intention to use the vehicle, and further, the user request can further represent that the user currently needs to end the related operation of the current OTA upgrade as soon as possible, so that the vehicle end can trigger the execution of the operation to meet the user's demand for using the vehicle as soon as possible after responding to the user request.

[0012] Based on the above technical solution, the user's active user request can be responded to, and based on the progress of the OTA upgrade, the current upgrade is continued, aborted, or rolled back, and the like, so that the vehicle can recover the driving function as soon as possible, and the user's demand for using the vehicle during the OTA upgrade can be met as soon as possible, so as to avoid the OTA upgrade operation causing the user's use experience to decrease.

[0013] In combination with the first aspect, in some implementations of the first aspect, the object of the OTA upgrade includes a first component set, each component in the first component set is used to cooperatively implement a driving-related function of the vehicle, a first upgrade progress of the first component set is determined; and based on the first upgrade progress, any one of the following operations is performed on the first component set: continuing to upgrade or rolling back.

[0014] For example, the first component set can be at least part of the set of necessary components, that is, the first component set can be the set of necessary components (the current OTA upgrade involves all components in the set of necessary components), or the first component set can also be a subset of the set of necessary components (the current OTA upgrade only involves part of the components in the set of necessary components).

[0015] Since each component in the first component set is used to cooperatively implement a driving-related function of the vehicle, the firmware versions of each component in the first component set need to be consistent, so that the driving-related function cooperatively implemented by the components can normally run. If the first component set is rolled back, the versions of each component in the rolled-back first component set are consistent, and are all the versions before the upgrade, which will not affect the driving function cooperatively completed by the components. If the OTA upgrade on the first component set continues until completion, the versions of each component in the upgraded first component set are also consistent, and will not affect the driving function cooperatively completed by the components.

[0016] For example, in order to end the OTA upgrade as soon as possible, for the first component set, one of the above two ways of continuing the upgrade and rolling back can be selected, and the basis for the selection is the above first upgrade progress, which can be used to determine the time length of continuing the OTA upgrade on the first component set until completion, or the time length of rolling back the first component set. Because the current requirement is to end the OTA upgrade process as soon as possible and provide reliable driving-related functions to the user, the way that is expected to take less time can be selected.

[0017] Based on the above technical solution, the operation that takes less time can be selected and executed from the operations of continuing to perform the OTA upgrade on each component used to cooperatively implement a driving-related function of the vehicle until completion and rolling back the components, in order to end the OTA upgrade operation as soon as possible; and the firmware versions of each component can be guaranteed to be consistent after the OTA upgrade is ended as soon as possible, so as to guarantee that the function cooperation between the components is not affected after the OTA upgrade is stopped, thereby meeting the user's demand to use the vehicle as soon as possible and avoiding the user's experience of using the vehicle from being reduced as much as possible.

[0018] In combination with the first aspect, in some implementations of the first aspect, according to the first upgrade progress, a first predicted time length and a second predicted time length are determined, the first predicted time length being a time length from a current time to completion of the OTA upgrade on the first component set, and the second predicted time length being a time length from the current time to completion of the rollback of the upgraded content in the first component set; in a case where the first predicted time length is greater than or equal to the second predicted time length, the upgraded content in the first component set is rolled back; or, in a case where the first predicted time length is less than or equal to the second predicted time length, the OTA upgrade on the first component set continues.

[0019] For example, in the operation of triggering the OTA upgrade process of the vehicle, the OTA server sends configuration information of the current OTA upgrade to the vehicle end, and the configuration information includes the estimated time for each component of the current upgrade to complete the OTA upgrade, and the components include the components of the first component set. When the component starts the OTA upgrade, the component can be timed to obtain the consumed time in real time. According to the estimated time for the component to complete the OTA upgrade in the configuration information and the obtained consumed time, the remaining time for completing the OTA upgrade can be determined, and the remaining time is the time period from the current time to the completion of the OTA upgrade of the component. Generally, the first component set includes multiple components, so the first component set can include multiple remaining times, and the longest remaining time is the first estimated time.

[0020] For example, the second estimated time can be determined according to the amount of firmware data that has been written and the processor performance.

[0021] Based on the above technical solution, by determining the estimated time corresponding to the continued upgrade and rollback of the first component set, the OTA upgrade path with shorter time consumption is selected to make the vehicle provide driving functions for the user as soon as possible, meet the user's demand for using the vehicle as soon as possible, and avoid the user's experience of using the vehicle as much as possible.

[0022] In combination with the first aspect, in some implementations of the first aspect, when the first upgrade progress is used to indicate that each component in the first component set has completed the data writing stage in the OTA upgrade, the OTA upgrade of the first component set is continued; or when the first upgrade progress is used to indicate that each component in the first component set has not entered the data writing stage in the OTA upgrade, the OTA upgrade of the first component set is stopped.

[0023] For example, for OTA upgrade, it can be divided into multiple installation stages: installation countdown stage; installation preparation stage; writing stage; activation stage; exit stage; then even if the components in the first component set enter the OTA upgrade process, different installation stages of the components can also take corresponding processing operations.

[0024] Based on the above technical solution, the upgrade or rollback of the first component set can be determined according to the upgrade stage of each component in the first component set, without calculating the estimated time for completing the upgrade of each component, thereby reducing the calculation overhead.

[0025] For example, considering that when a component enters the exit phase of an OTA upgrade, it needs to generate and upload corresponding upgrade feedback information, such as collecting asset information, firmware version information, and upgrade logs, etc., then when facing the need to end the OTA upgrade as quickly as possible, these steps in the exit phase can be simplified to execute a simplified exit process. Taking the first set of components as an example, if it is determined that the first set of components will continue to undergo OTA upgrades, when each component in the first set enters the exit phase, operations such as collecting asset information, firmware version information, and upgrade logs mentioned above can be omitted. Only necessary operations need to be performed, such as verifying the integrity of the new firmware, updating the system status, and restarting the device. This can further speed up the completion of the OTA upgrade.

[0026] In conjunction with the first aspect, in some implementations of the first aspect, configuration information sent by the OTA server is received, the configuration information being used to indicate the reference estimated time for completing the OTA upgrade for each component in the first component set; the first estimated time is determined based on the reference estimated time for the components in the current first component set that have not completed the OTA upgrade.

[0027] For example, the above configuration information may include: the name or identifier of the upgrade object (i.e., component, or controller) for this OTA upgrade, the set of components to which the component to be upgraded belongs, and the estimated time for each component to complete the upgrade, etc.

[0028] For example, the above configuration information may also include: the network segment to which each component belongs, or the functional domain (e.g., vehicle control domain, chassis domain, power domain, thermal management domain, cockpit, etc.), and whether it is a dual-zone architecture.

[0029] For example, the above configuration information may also include some additional information, such as the upgrade order of each component, whether the high voltage can be connected after the component fails, whether the vehicle can be driven after the component fails, and the functions affected by the component failure (i.e. the failed functions), to further assist in determining the strategy to end the OTA upgrade as soon as possible.

[0030] Based on the above technical solution, a basis can be provided for the vehicle to determine the strategy for suspending OTA upgrade operations.

[0031] In conjunction with the first aspect, in some implementations of the first aspect, the first set of components constitutes the minimum number of components used to collaboratively achieve the manual driving function of the vehicle.

[0032] Based on the above technical solution, since the components involved in the manual driving function are fewer than those involved in the assisted driving function, the first set of components is defined as the minimum number of components used to collaboratively realize the manual driving function of the vehicle, which can further accelerate the progress of stopping OTA upgrades.

[0033] In conjunction with the first aspect, in some implementations of the first aspect, the objects of OTA upgrades also include a second set of components. Each component in the second set of components is used to independently implement the vehicle's driving-related functions. The following operations are performed on the components in the second set of components: continue the upgrade, abort the upgrade, or roll back.

[0034] For example, the first configuration information sent by the OTA server to the vehicle can also be used to indicate that the object of the OTA upgrade includes the second set of components. Alternatively, the first configuration information can also be used to indicate at least one component in the object of the OTA upgrade that is used to independently implement the vehicle's driving-related functions. After the vehicle determines the at least one component, the aforementioned second set of components can be determined.

[0035] For example, OTA abort operations can be performed on components in the second component set based on the following mechanism: continue upgrading the components in the second component set that are currently undergoing OTA upgrades, and abort upgrades on the components in the second component set that have not yet started OTA upgrades. Alternatively, continue upgrading the components in the second component set that have entered the data flashing stage of OTA upgrades, and abort upgrades on the components in the second component set that have not yet entered the data flashing stage. Since the components have not yet flashed the new firmware data when the upgrade of the components in the second component set that have not yet entered the data flashing stage is aborted, it is not necessary to roll back the components. Therefore, different operations can be taken for components in the second component set that are in different upgrade stages.

[0036] For example, for components in the second set that are in the data flushing phase, a similar decision logic to that for the first set of components can be adopted, namely, determining whether the component should continue upgrading or rollback. For instance, the third estimated time for each component to complete the upgrade and the fourth estimated time for completing the rollback can be determined. If the third estimated time is greater than or equal to the fourth estimated time, the component is rolled back; or, if the third estimated time is less than or equal to the fourth estimated time, the component continues upgrading.

[0037] Based on the above technical solution, it is possible to respond to users' vehicle needs during OTA upgrades. For components that independently implement driving-related functions of the vehicle, the process can be suspended for components that have not yet started OTA upgrades or have not yet entered the data flashing stage of OTA upgrades, so that these components can continue to run based on the original version, so as to provide users with reliable driving functions as soon as possible and avoid the decline in users' driving experience as much as possible.

[0038] In conjunction with the first aspect, in some implementations of the first aspect, the object of OTA upgrade also includes a third component set, in which each component is used to implement non-driving related functions of the vehicle, and the upgrade of the third component set is stopped.

[0039] For example, the first configuration information sent by the OTA server to the vehicle can also be used to indicate that the object of the OTA upgrade includes the third set of components. Alternatively, the first configuration information can also be used to indicate at least one component among the objects of the OTA upgrade that is used to implement non-driving related functions of the vehicle. After the vehicle determines the at least one component, the aforementioned third set of components can be determined.

[0040] For example, after OTA upgrades to the third component set are suspended, there may be components in the third component set that have completed OTA upgrades. For such components, if they can independently implement non-driving-related functions of the vehicle, they can run based on the updated firmware during subsequent user use. If these components need to work with other components to implement non-driving functions, it is necessary to ensure version consistency between these components and other components. Only when the versions are consistent can these components run based on the updated firmware during subsequent user use. If the versions are inconsistent, these components should be disabled during subsequent user use to prevent errors caused by version inconsistencies that could affect the user's normal driving. Furthermore, there may also be components in the third component set that have only completed partial data upgrades. For such components, they should be disabled during subsequent user use to prevent errors caused by incomplete firmware data that could affect the user's normal driving.

[0041] Based on the above technical solution, considering that the components used in OTA upgrades to realize non-driving related functions of the vehicle will not directly affect the user's driving function, when it is necessary to end the OTA upgrade process as soon as possible, the upgrade of these components can be directly stopped so that the OTA upgrade process can be completed as soon as possible, so as to meet the user's need to use the car as soon as possible and avoid a decline in the user's car use experience.

[0042] In conjunction with the first aspect, in some implementations of the first aspect, the object of OTA upgrade also includes a fourth component set. The fourth component set includes components used to independently implement the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each partition being used to store a set of firmware. Upgrades to the fourth component set are stopped, and each component in the fourth component set runs based on firmware that has not been flashed or firmware that has completed OTA upgrade.

[0043] For example, the first configuration information sent by the OTA server to the vehicle can also be used to indicate that the object of the OTA upgrade includes the fourth set of components. Alternatively, the first configuration information can also be used to indicate at least one component in the object of the OTA upgrade that is used to independently implement the relevant functions of the vehicle, and these components include multiple partitions, each of which is used to store a set of firmware. After the vehicle determines the at least one component, the aforementioned fourth set of components can be determined.

[0044] For example, for firmware that has completed an OTA upgrade, the corresponding functions can be implemented directly based on the new firmware; for firmware that has not completed an OTA upgrade, the corresponding functions can be implemented based on the firmware in the backup partition of the component.

[0045] For example, the fourth component set may intersect with the second and / or third component sets. Therefore, after triggering the operation to end the OTA upgrade process as soon as possible, it can be first determined whether the object of this OTA upgrade belongs to the fourth component set. If it does, the relevant operations for the fourth component set mentioned above can be taken first to process the components belonging to the fourth component set. After processing, the operations of S920 or S930 can be executed for components that belong only to the second and / or only to the third component set, thereby avoiding multiple path judgments to terminate OTA for the same component.

[0046] Based on the above technical solution, when responding to a user's request during the vehicle's OTA upgrade, the OTA upgrade process of components with a dual-partition storage architecture that independently implement the vehicle's relevant functions can be directly terminated. This allows these components to run based on backup firmware stored in other partitions, ensuring the functional reliability and stability of the firmware. It also helps to end the OTA upgrade as soon as possible to meet the user's vehicle usage needs.

[0047] In conjunction with the first aspect, in some implementations of the first aspect, the estimated time for the vehicle to resume driving function is displayed through a human-computer interaction interface.

[0048] For example, the estimated time for the vehicle to regain its driving function can be determined as follows: Obtain the estimated time for each component set to complete the continued upgrade, aborted upgrade, or rollback, and determine the longest estimated time among these as the estimated time for the vehicle to regain its driving function. Alternatively, obtain the estimated time for each component to complete the continued upgrade, aborted upgrade, or rollback separately, and determine the longest estimated time among these as the estimated time for the vehicle to regain its driving function.

[0049] In conjunction with the first aspect, in some implementations of the first aspect, a user request is generated in response to at least two confirmation operations performed by the user through the human-computer interaction interface, the confirmation operations being used to indicate the user's intention to use the vehicle.

[0050] Based on the above technical solution, the multiple confirmation operation mechanism can effectively avoid situations where OTA upgrades cannot be completed as expected due to user misoperation.

[0051] Secondly, an OTA upgrade method is provided. The OTA upgrade object is a first set of components. The first set of components is used to collaboratively implement driving-related functions of the vehicle. The storage architecture of each component in the first set of components includes a first partition and a second partition. During the OTA upgrade process of the vehicle, the method includes: in response to a user request, if the firmware versions stored in the second partition of each component are consistent, suspending the upgrade of the first set of components. Each component in the first set of components runs based on the firmware stored in the second partition.

[0052] Based on the above technical solutions, the speed of OTA upgrades can be further accelerated, meeting users' needs for immediate vehicle use and minimizing any decline in user experience. Furthermore, it ensures the reliability and stability of vehicle driving functions.

[0053] Thirdly, an OTA upgrade method is provided, which includes: sending enable information to the vehicle to enable the vehicle to respond to user requests, and performing at least one of the following operations according to the progress of the OTA upgrade: continuing the upgrade, aborting the upgrade, or rolling back.

[0054] In conjunction with the third aspect, in some implementations of the third aspect, first configuration information is sent to the vehicle, the first configuration information being used to indicate that the objects of the OTA upgrade include a first set of components, and each component in the first set of components is used to collaboratively implement the vehicle's driving-related functions; second configuration information is sent to the vehicle, the second configuration information being used to indicate the reference estimated time for completing the OTA upgrade for each component in the first set of components, so that when the vehicle responds to a user request during the OTA upgrade process, the first upgrade progress of the first set of components is determined, and based on the first upgrade progress, one of the following operations is performed on the first set of components: continue upgrading or rollback.

[0055] In conjunction with the third aspect, in some implementations of the third aspect, the first set of components constitutes the minimum number of components used to collaboratively achieve the manual driving function of the vehicle.

[0056] In conjunction with the third aspect, in some implementations of the third aspect, the first configuration information is also used to indicate that the object of the OTA upgrade includes a second set of components, each component in the second set of components is used to independently implement the vehicle's driving-related functions, so that when a user request is received during the vehicle's OTA upgrade process, the following operations are performed on the components in the second set of components: continue the upgrade, abort the upgrade, or roll back.

[0057] In conjunction with the third aspect, in some implementations of the third aspect, the first configuration information is also used to indicate that the object of the OTA upgrade includes a third component set, and each component in the third component set is used to implement non-driving related functions of the vehicle, so that when a user request is received during the OTA upgrade process of the vehicle, the upgrade of the third component set is stopped.

[0058] In conjunction with the third aspect, in some implementations of the third aspect, the first configuration information is also used to indicate that the object of the OTA upgrade includes a fourth component set. The fourth component set includes components for independently implementing the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each of which is used to store a set of firmware, so that when a user request is received during the OTA upgrade process of the vehicle, the upgrade of the fourth component set is stopped, and each component in the fourth component set runs based on the un-flashed firmware or the firmware that has been OTA upgraded.

[0059] Fourthly, an OTA upgrade method is provided, comprising: sending first configuration information to the vehicle, the first configuration information indicating that the object of the OTA upgrade includes a first set of components, each component in the first set of components being used to collaboratively implement driving-related functions of the vehicle; sending third configuration information to the vehicle, the third configuration information indicating that the storage architecture of each component in the first set of components includes a first partition and a second partition, such that when a user request is received during the OTA upgrade process of the vehicle, if the firmware versions stored in the second partition of each component are consistent, the upgrade of the first set of components is stopped, and each component in the first set of components operates based on the firmware stored in the second partition.

[0060] Fifthly, an apparatus for OTA upgrades is provided, the apparatus comprising: a main control unit, configured to, in response to a user request, perform at least one of the following operations according to the progress of the OTA upgrade during the process of OTA upgrade of a vehicle: continue upgrade, abort upgrade, or rollback.

[0061] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the object of OTA upgrade includes a first set of components, each component in which is used to collaboratively implement the vehicle's driving-related functions. The aforementioned main control unit includes: a determining unit, used to determine a first upgrade progress of the first set of components; and an execution unit, used to perform any one of the following operations on the first set of components based on the first upgrade progress: continue upgrading or rollback.

[0062] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the aforementioned execution unit is further configured to: continue the OTA upgrade of the first component set when the first upgrade progress indicates that each component in the first component set has completed the data writing phase of the OTA upgrade; or, suspend the OTA upgrade of the first component set when the first upgrade progress indicates that each component in the first component set has not yet entered the data writing phase of the OTA upgrade.

[0063] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the aforementioned determining unit is further configured to: determine a first estimated duration and a second estimated duration based on the first upgrade progress, wherein the first estimated duration is the duration from the current moment to the completion of the OTA upgrade of the first component set, and the second estimated duration is the duration from the current moment to the completion of the rollback of the upgraded content in the first component set. The aforementioned execution unit 1012 is further configured to: roll back the upgraded content in the first component set if the first estimated duration is greater than or equal to the second estimated duration; or, continue the OTA upgrade of the first component set if the first estimated duration is less than or equal to the second estimated duration.

[0064] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the aforementioned main control unit further includes: a receiving unit, used to receive configuration information sent by the OTA server, the configuration information being used to indicate the reference estimated time for completing the OTA upgrade for each component in the first component set; the aforementioned determining unit is specifically used to: determine the first estimated time based on the reference estimated time corresponding to the component in the current first component set that has not completed the OTA upgrade.

[0065] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the aforementioned first set of components constitutes the minimum number of components used to collaboratively achieve the manual driving function of the vehicle.

[0066] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the objects of the above-mentioned OTA upgrade also include a second set of components, each component in the second set of components is used to independently implement the driving-related functions of the vehicle, and the above-mentioned execution unit is also used to perform the following operations on the components in the second set of components: continue the upgrade, stop the upgrade, or roll back.

[0067] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the object of the above-mentioned OTA upgrade also includes a third component set, in which each component is used to implement non-driving related functions of the vehicle, and the above-mentioned execution unit is also used to: stop the upgrade of the third component set.

[0068] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the objects of the above-mentioned OTA upgrade also include a fourth component set, which includes components for independently implementing the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each partition being used to store a set of firmware. The above-mentioned execution unit is also used to: stop the upgrade of the fourth component set, and each component in the fourth component set runs based on the un-flashed firmware or the firmware that has been OTA upgraded.

[0069] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the aforementioned main control unit is also used to: display the estimated time for the vehicle to resume driving function through a human-machine interface.

[0070] In conjunction with the fifth aspect, in some implementations of the fifth aspect, the aforementioned main control unit is also used to: generate a user request in response to at least two confirmation operations performed by the user through the human-computer interaction interface, wherein the confirmation operations are used to indicate the user's intention to use the vehicle.

[0071] In a sixth aspect, an apparatus for OTA upgrade is provided, wherein the OTA upgrade object is a first set of components, the first set of components being used to collaboratively implement driving-related functions of a vehicle, and the storage architecture of each component in the first set of components includes a first partition and a second partition. The apparatus includes an execution unit for responding to a user request during the OTA upgrade process of the vehicle, wherein the OTA upgrade object is the first set of components, the first set of components being used to collaboratively implement driving-related functions of the vehicle, and the storage architecture of each component in the first set of components includes a first partition and a second partition.

[0072] In a seventh aspect, an apparatus for OTA upgrades is provided, the apparatus comprising: a sending unit for sending enable information to a vehicle, the enable information being used to enable the vehicle to respond to a user request and, based on the progress of the OTA upgrade, perform at least one of the following operations: continue the upgrade, abort the upgrade, or roll back.

[0073] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the aforementioned sending unit is further configured to: send first configuration information to the vehicle, the first configuration information indicating that the object of the OTA upgrade includes a first set of components, each component in the first set of components being used to collaboratively implement the vehicle's driving-related functions; and send second configuration information to the vehicle, the second configuration information indicating the reference estimated time for completing the OTA upgrade for each component in the first set of components, so that when the vehicle responds to a user request during the OTA upgrade process, it determines the first upgrade progress of the first set of components, and performs any of the following operations on the first set of components based on the first upgrade progress: continue upgrading or rollback.

[0074] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the aforementioned first set of components constitutes the minimum number of components for collaboratively realizing the manual driving function of the vehicle.

[0075] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the aforementioned first configuration information may also be used to indicate that the object of the OTA upgrade includes a second set of components, each component in the second set of components is used to independently implement the vehicle's driving-related functions, so that when a user request is received during the vehicle's OTA upgrade process, the following operations are performed on the components in the second set of components: continue the upgrade, abort the upgrade, or roll back.

[0076] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the aforementioned first configuration information may also be used to indicate that the object of the OTA upgrade includes a third component set, wherein each component in the third component set is used to implement non-driving related functions of the vehicle, so that when a user request is received during the OTA upgrade process of the vehicle, the upgrade of the third component set is stopped.

[0077] In conjunction with the seventh aspect, in some implementations of the seventh aspect, the aforementioned first configuration information may also be used to indicate that the object of the OTA upgrade includes a fourth component set. The fourth component set includes components for independently implementing the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each partition being used to store a set of firmware, so that when a user request is received during the OTA upgrade process of the vehicle, the upgrade of the fourth component set is stopped, and each component in the fourth component set runs based on un-flashed firmware or firmware that has completed the OTA upgrade.

[0078] Eighthly, an apparatus for OTA (Over-The-Air) upgrades is provided, the apparatus comprising: a sending unit for sending first configuration information to a vehicle, the first configuration information indicating that the object of the OTA upgrade includes a first set of components, each component in the first set of components being used to collaboratively implement driving-related functions of the vehicle; and sending third configuration information to the vehicle, the third configuration information indicating that the storage architecture of each component in the first set of components includes a first partition and a second partition, such that when a user request is received during the OTA upgrade process of the vehicle, if the firmware versions stored in the second partitions of each component are consistent, the upgrade of the first set of components is terminated, and each component in the first set of components operates based on the firmware stored in the second partition.

[0079] A ninth aspect provides an apparatus for OTA (Over-The-Air) upgrades, the apparatus including at least one processor coupled to at least one memory, the at least one processor being configured to execute a computer program or instructions stored in the at least one memory to cause the apparatus to perform an OTA upgrade method as possible in any of the first aspects, or to perform an OTA upgrade method as in the second aspect.

[0080] In a tenth aspect, an apparatus for OTA (Over-The-Air) upgrade is provided, the apparatus including at least one processor coupled to at least one memory, the at least one processor being configured to execute a computer program or instructions stored in the at least one memory to cause the apparatus to perform an OTA upgrade method as possible in any of the third aspects, or to perform an OTA upgrade method as in the fourth aspect.

[0081] In the eleventh aspect, a vehicle is provided that includes an OTA upgrade device as described in any of the fifth aspects above, or includes an OTA upgrade device as described in the sixth aspect above, or includes an OTA upgrade device as described in the eighth aspect above.

[0082] The term "vehicle" in this application is used in a broad sense and can refer to means of transportation (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawnmowers, harvesters, etc.), amusement equipment, toy vehicles, etc. The embodiments of this application do not specifically limit the type of vehicle.

[0083] In a twelfth aspect, a server is provided that includes any of the means for OTA upgrades possible in the seventh aspect above, or includes the means for OTA upgrades as in the eighth aspect above, or includes the means for OTA upgrades as in the tenth aspect above.

[0084] In a thirteenth aspect, a system for OTA (Over-The-Air) upgrades is provided, comprising: a vehicle equipped with a first control device for performing an OTA upgrade method as possible in any of the first aspects, or performing an OTA upgrade method as in the second aspect; and an OTA server equipped with a second control device for performing an OTA upgrade method as possible in any of the third aspects, or performing an OTA upgrade method as in the fourth aspect.

[0085] In a fourteenth aspect, a computer program product is provided, the computer program product comprising: computer program code, which, when executed on a computer, causes the computer to perform any of the possible OTA upgrade methods of the first aspect, or to perform the OTA upgrade method of the second aspect, or to perform any of the possible OTA upgrade methods of the third aspect, or to perform the OTA upgrade method of the fourth aspect.

[0086] In a fifteenth aspect, a computer-readable storage medium is provided, the computer-readable medium storing a computer program that, when the computer program is run on a computer, causes the computer to perform any of the possible OTA upgrade methods of the first aspect, or to perform the OTA upgrade method of the second aspect, or to perform any of the possible OTA upgrade methods of the third aspect, or to perform the OTA upgrade method of the fourth aspect.

[0087] In a sixteenth aspect, a chip is provided, the chip including circuitry for executing any of the possible OTA upgrade methods of the first aspect, or executing the OTA upgrade method of the second aspect, or executing any of the possible OTA upgrade methods of the third aspect, or executing the OTA upgrade method of the fourth aspect. Attached Figure Description

[0088] Figure 1 This is a functional block diagram of the vehicle 100 provided in an embodiment of this application;

[0089] Figure 2 This is a schematic diagram of a vehicle cabin scenario provided in an embodiment of this application;

[0090] Figure 3 This is a schematic diagram of an OTA upgrade system architecture provided in an embodiment of this application;

[0091] Figure 4 This is a schematic diagram of a system architecture for the OTA upgrade solution provided in this application when applied in a vehicle;

[0092] Figure 5 This is a schematic diagram of the component set relationship during OTA upgrade in the embodiments of this application;

[0093] Figure 6 This is a schematic diagram illustrating a method for generating user requests based on a human-computer interaction interface, as proposed in an embodiment of this application.

[0094] Figure 7 This is a schematic diagram illustrating another method for generating user requests based on a human-computer interaction interface, as proposed in this application embodiment.

[0095] Figure 8 This is a schematic diagram illustrating another method for generating user requests based on a human-computer interaction interface, as proposed in this application embodiment.

[0096] Figure 9 This is a flowchart illustrating an OTA upgrade method 900 proposed in an embodiment of this application;

[0097] Figure 10 This is a schematic block diagram of a device 1000 for OTA upgrades provided in an embodiment of this application;

[0098] Figure 11 This is a schematic block diagram of another device 1100 for OTA upgrades provided in the embodiments of this application. Detailed Implementation

[0099] It should be noted that, in the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in this article is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone.

[0100] In the embodiments of this application, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. Furthermore, in the description of the embodiments of this application, "multiple" refers to two or more, and "at least one" and "one or more" refer to one, two, or more than two. The singular expressions "a," "an," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context explicitly indicates otherwise.

[0101] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0102] In this application, "for indication" can be understood as "enabling," which can include direct and indirect enabling. When describing information as enabling A, it can include whether the information directly or indirectly enables A, but does not necessarily mean that the information carries A. The information enabled by the information is called the information to be enabled. In the specific implementation process, there are many ways to enable the information to be enabled, such as, but not limited to, directly enabling the information to be enabled, such as the information to be enabled itself or its index. It can also indirectly enable the information to be enabled by enabling other information, where there is a correlation between the other information and the information to be enabled. It can also enable only a part of the information to be enabled, while the other parts are known or pre-agreed. For example, enabling specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement order of various information, thereby reducing enabling overhead to some extent. At the same time, common parts of various information can be identified and enabled uniformly to reduce the enabling overhead caused by individually enabling the same information.

[0103] In this application, "pre-configuration" may include pre-defined terms, such as protocol definitions. These "pre-defined terms" can be implemented by pre-storing corresponding codes, tables, or other means of indicating relevant information in the device (e.g., including various network elements). This application does not limit the specific implementation method.

[0104] The term "storage" or "preservation" in this application can refer to storage in one or more memory devices. These memory devices can be separately configured or integrated into an encoder, decoder, processor, or communication device. Alternatively, some memory devices can be separately configured, while others can be integrated into the decoder, processor, or communication device. The type of memory can be any form of storage medium, and this is not limited.

[0105] The technical solutions in the embodiments of this application will now be described with reference to the accompanying drawings.

[0106] Figure 1 This is a functional block diagram of the vehicle 100 provided in the embodiments of this application.

[0107] Vehicle 100 may include a perception system 110, a computing platform 120, and a display device 130. The perception system 110 may include one or more sensors for sensing information about the environment surrounding the vehicle 100. For example, the perception system 110 may include a positioning system, which may be a Global Positioning System (GPS), a BeiDou Navigation Satellite System, or another positioning system. As another example, the perception system 110 may include one or more of an inertial measurement unit (IMU), an accelerometer, a lidar, millimeter-wave radar, ultrasonic radar, and a camera device. For instance, the accelerometer may include a sensor for detecting acceleration signals from the air suspension system, or it may include a sensor for detecting ESC acceleration signals.

[0108] Some or all of the functions of vehicle 100 can be controlled by computing platform 120. Computing platform 120 may include one or more processors, such as processors 121 to 12n (n being a positive integer). A processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction read and execute capabilities, such as a central processing unit (CPU), microprocessor, graphics processing unit (GPU) (which can be understood as a type of microprocessor), or digital signal processor (DSP). In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as a field-programmable gate array (FPGA). In reconfigurable hardware circuits, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the process of the processor loading instructions to implement some or all of the functions of the aforementioned units. Furthermore, the processor can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as a neural network processing unit (NPU), tensor processing unit (TPU), deep learning processing unit (DPU), etc. In addition, the computing platform 120 may also include a memory for storing instructions. Some or all of the processors 121 to 12n can call the instructions in the memory to implement corresponding functions, such as cockpit noise reduction.

[0109] The in-cabin display devices 130 are mainly divided into two categories: the first is the in-vehicle display screen; the second is the projection display screen, such as the head-up display (HUD). An in-vehicle display screen is a physical display screen and an important component of the in-vehicle infotainment system. Multiple displays can be installed in the cabin, such as the digital instrument cluster display, the central control screen, the display screen in front of the front passenger (also known as the front-seat passenger), the display screen in front of the left rear passenger, the display screen in front of the right rear passenger, and even the car window can be used as a display screen. A head-up display, also known as a head-up display system, is mainly used to display driving information such as speed and navigation on a display device in front of the driver (such as the windshield). This reduces the driver's eye-shift time, avoids pupil changes caused by eye-shifting, and improves driving safety and comfort. Examples of HUDs include combiner-HUD (C-HUD) systems, windshield-HUD (W-HUD) systems, and augmented reality HUD (AR-HUD) systems. It should be understood that HUDs can also evolve into other types of systems as technology progresses, and this application does not limit them.

[0110] The above description of the display device 130 uses an in-vehicle display screen and a projection display screen as examples, but the embodiments of this application are not limited thereto. For example, the display device 130 can also be a light display screen or a projection screen.

[0111] Figure 2 This is a schematic diagram of a vehicle cabin scenario provided in an embodiment of this application. The intelligent cabin is equipped with one or more in-vehicle displays (or in-vehicle screens), including but not limited to display screen 201 (or central control screen), display screen 202 (or passenger entertainment screen), display screen 203 (or driver's headrest rear screen), display screen 204 (or passenger headrest rear screen), display screen 205 (or second-row entertainment screen) mounted on the cabin ceiling, door panel screen 206 mounted on the rear seats, armrest screen 207 mounted on the rear seats, and instrument panel screen. Further, displays 201 to 207 can display a graphical user interface (GUI), which may include icons for one or more applications, and / or one or more cards. For example, Figure 1The display device 130 shown can be one or more of displays 201 to 207. In some possible implementations, display 201 can also be a long screen extending into the passenger area. Additionally, display 205 can be a projection screen associated with a projector, which can be associated with a desktop launcher to manage applications projected onto the projection screen. Alternatively, display 205 can also be a rollable screen.

[0112] Figure 2 The cockpit can also be equipped with one or more cameras to capture images inside or outside the cockpit, such as cameras from a driver monitor system (DMS), a cabin monitor system (CMS), and a dashcam. These cameras can be the same or different cameras. In addition, one or more pressure sensors and acoustic sensors are installed in the cockpit to monitor the presence and location of users.

[0113] It should be understood that the following embodiments are based on Figure 2 The embodiments shown are illustrated using a 5-seat vehicle as an example, but the present application is not limited to this. For example, for a 7-seat sport / suburban utility vehicle (SUV), the cabin may include a central control screen, a passenger entertainment screen, a screen behind the driver's headrest, a screen behind the passenger's headrest, entertainment screens in the left-hand area of ​​the third row, and entertainment screens in the right-hand area of ​​the third row. As another example, for a bus, the cabin may include front and rear entertainment screens; or, the cabin may include a display screen in the driver's area and an entertainment screen in the passenger area. Furthermore, the following embodiments use a left-hand drive vehicle (i.e., the driver is on the left side of the vehicle) as an example; in actual implementation, the vehicle may also be a right-hand drive vehicle (i.e., the driver is on the right side of the vehicle).

[0114] Optionally, the structure of the vehicle 100 and the interior of the smart cockpit described above is merely illustrative. In actual applications, various components in the vehicle 100 and the interior of the smart cockpit can be added or removed as needed.

[0115] The vehicles involved in this application can include road vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment. For example, vehicles can include driverless vehicles. The term "vehicle" is used broadly and can refer to various types of vehicles, such as transportation vehicles (e.g., commercial vehicles, passenger cars, motorcycles, flying cars, trains), industrial vehicles (e.g., forklifts, trailers, tractors), engineering vehicles (e.g., excavators, bulldozers, cranes), agricultural equipment (e.g., lawnmowers, harvesters), amusement equipment, and toy vehicles. This application does not specifically limit the type of vehicle. For ease of description, this application uses an intelligent vehicle as an example for detailed explanation.

[0116] Over-the-air (OTA) updates for intelligent vehicle software are a widely used method for vehicle software upgrades. As intelligent vehicles become increasingly feature-rich, the frequency of software updates is also increasing. In current OTA upgrade designs, when upgrading the firmware of intelligent vehicle components using OTA, the user must park the vehicle in a safe area. The corresponding OTA upgrade management software will then check if the vehicle's status meets certain conditions, such as the gear being in Park (P), the vehicle speed being zero, and the handbrake being engaged. Only when these conditions are met can the OTA upgrade management software trigger the upgrade, locking the vehicle's gear during the upgrade process to prevent the user from using the vehicle. Once the OTA upgrade is complete, the software releases control of the gear, allowing the user to use the vehicle normally.

[0117] Therefore, once a vehicle meets the conditions for an OTA upgrade, it enters OTA upgrade mode. During the upgrade process, the user cannot drive the vehicle. Only after the upgrade is complete will the OTA upgrade management software release control of the vehicle, such as gear shifting, allowing the user to drive. The duration during which the user's driving needs cannot be met due to OTA upgrades typically varies depending on the number of controllers requiring upgrades, the size of the controller upgrade package, and the firmware data flashing time. It can range from a few minutes to over half an hour, making it difficult to meet the user's urgent need for temporary vehicle use.

[0118] For example, when a vehicle is in a public area such as an intersection, gas station, or charging station and is briefly stationary (e.g., waiting at a traffic light or temporarily stopping to retrieve an item), if the user does not promptly prevent the vehicle from entering the OTA upgrade process, the OTA upgrade management software will initiate the upgrade process once it determines that the vehicle meets the aforementioned conditions. During this time, the vehicle will remain in Park (P) and will not respond to gear shifting operations, affecting the user's normal driving and potentially causing traffic congestion or disorder. Another example is when the vehicle is undergoing an OTA upgrade within a scheduled time slot. If the user has an emergency requiring immediate vehicle access or movement during this upgrade period, they must wait for the OTA upgrade to complete before using the vehicle normally. Therefore, the user's needs cannot be met during the upgrade period. In situations like these, the user experience will be diminished.

[0119] Figure 3 This is a schematic diagram of an OTA upgrade system architecture provided in an embodiment of this application.

[0120] like Figure 3 As shown, the system includes an OTA server 310 and a smart device 320. The OTA server 310 includes a configuration module 311 and a firmware transmission module 312; the smart device 320 includes a main process control module 321, which further includes an interrupt control module 322.

[0121] The OTA server 310 can transmit firmware data, such as OTA upgrade packages, to the smart device 320 via the firmware transmission module 312. The OTA server 310 can also send upgrade configuration information to the smart device 320 via the configuration module 311. This upgrade configuration information indicates the components to be upgraded in this OTA, the estimated completion time of the OTA upgrade for each component, and upgrade-related information for each component. Correspondingly, the main process control module 321 of the smart device 320 can initiate the OTA upgrade process for the corresponding components based on the upgrade configuration information and firmware data.

[0122] Furthermore, during the OTA upgrade of the smart device 320, when the user requests that the smart device 320 be restored to a non-upgrade state as soon as possible (i.e., the upgrade be ended as soon as possible), the aforementioned upgrade configuration information can also serve as the basis for the interrupt control module 322 of the smart device 320 to determine whether to interrupt the OTA upgrade of at least one component. This allows the interrupt control module 322, based on its built-in judgment logic, to determine which components need to continue the OTA upgrade and / or which components need to be rolled back, and instruct the main process control module 321 to continue the OTA upgrade of at least one component and / or perform a rollback operation on the OTA upgrade of at least one component, so that the smart device 320 can quickly restore its basic functionalities to a usable state.

[0123] In some possible embodiments, the interrupt control module 322 may also be independent of the main flow control module 321, but the connection between the interrupt control module 322 and the main flow control module 321 must be ensured. This connection may be a wired connection or a wireless connection.

[0124] The aforementioned smart devices can be vehicles, and the vehicles designed in this application can include land vehicles, water vehicles, air vehicles, industrial equipment, agricultural equipment, or entertainment equipment, etc. For example, a smart device can be a vehicle, which is a vehicle in a broad sense, and can be a means of transportation (such as commercial vehicles, passenger cars, motorcycles, flying cars, trains, etc.), industrial vehicles (such as forklifts, trailers, tractors, etc.), engineering vehicles (such as excavators, bulldozers, cranes, etc.), agricultural equipment (such as lawnmowers, harvesters, etc.), amusement equipment, toy vehicles, etc. The embodiments of this application do not specifically limit the type of vehicle. Furthermore, a smart device can be a smart robot, smart home device, drone, airplane, or ship, etc.

[0125] The following section uses a smart device as an example to introduce the technical solution of this application.

[0126] Figure 4 This is a schematic diagram of a system architecture when the OTA upgrade solution provided in this application is applied in a vehicle.

[0127] refer to Figure 4 As shown, the system can be divided into a server side and a vehicle side. The server side includes an OTA server 410, and the vehicle side includes an OTA master control deployment component 420 and multiple domain controllers 430.

[0128] For example, an OTA server can be a cloud server deployed in the cloud.

[0129] and Figure 3 Similar to the OTA server 310 shown, the OTA server 410 may also include a firmware transmission module 411 and a configuration module 412. The firmware transmission module 411 is responsible for managing and distributing OTA upgrade packages, and the configuration module 411 is used to send upgrade configuration information to the OTA master control deployment component 420. The upgrade configuration information may include: the name or identifier of the upgrade object (i.e., component, or controller) of this OTA upgrade, the set of components to which the component to be upgraded belongs, and the estimated time for each component to complete the upgrade, etc.

[0130] In this embodiment of the application, the set of all vehicle components can be divided into a set of necessary components, a set of essential components, and a set of non-essential components based on the functions to be performed by each component and the collaborative relationship between each component and other components.

[0131] The components in the aforementioned set of essential components can be used to collaboratively realize the driving-related functions of the vehicle. For example, the aforementioned set of essential components may include components in the power domain (DC converter, battery management system, etc.), chassis domain (brake controller, electronic power steering controller, etc.), vehicle control domain, and thermal management system (compressor).

[0132] In some possible embodiments, in order to provide the user with driving functionality as soon as possible, the components in the component set must be the minimum components used to collaboratively realize the manual driving function, at least capable of realizing the basic functions of a manually driven vehicle, which may include: driving function, braking function, high voltage power-on / off function, steering function, battery temperature control function, etc.

[0133] Each component in the aforementioned set of necessary components can be used to independently realize the driving-related functions of the vehicle. For example, the aforementioned set of necessary components may include driving safety-related components, such as airbag controllers, headlights, range extenders, vehicle speed displays, anti-theft authentication, and other components and modules.

[0134] The components in the aforementioned set of non-essential components can be used to realize non-driving related functions of the vehicle. For example, the aforementioned set of non-essential components may include ambient lighting, in-vehicle audio controllers, in-vehicle infotainment systems, and other components.

[0135] The OTA upgrade method proposed in subsequent embodiments of this application allows for different OTA upgrade termination strategies when responding to user requests during the OTA upgrade process, depending on the components belonging to different sets. The "termination" in the termination strategy proposed in this application refers to adjusting the process to expedite the OTA upgrade process. At the component level, terminating the OTA upgrade process can include two processing strategies: one is to terminate the component upgrade and perform an upgrade rollback, and the other is to continue the component upgrade. In practice, a strategy with a relatively short processing time is adopted to end the OTA upgrade process as quickly as possible. Detailed operations are described in subsequent embodiments and will not be elaborated here.

[0136] In some possible embodiments, the above configuration information may further include: the network segment to which each component belongs, or its functional domain (e.g., vehicle control domain, chassis domain, powertrain domain, thermal management domain, cockpit, etc.), and whether it is a dual-partition architecture. The OTA upgrade method proposed in subsequent embodiments of this application can adopt corresponding OTA upgrade terminal strategies for components with a dual-partition architecture. Here, a dual-partition architecture refers to a strategy that divides storage space into an active partition and a backup partition, achieving reliable system software upgrades through a secure switching mechanism. This approach is widely used in vehicle OTA upgrades to ensure the stability and reliability of the upgrade process.

[0137] In some possible embodiments, the above configuration information may also include some additional information, such as the upgrade order of each component, whether the high voltage can be applied after the component fails, whether the vehicle can be driven after the component fails, and the functions affected by the component failure (i.e. the failed functions), to further assist in determining the strategy to end the OTA upgrade as soon as possible.

[0138] In some possible embodiments, basic information about different vehicle models can be stored in the OTA server. This basic information may include the names or identifiers of all components of the vehicle, the component sets to which each component belongs, and further, the network segment to which each component belongs, whether each component has a dual-partition architecture, and some additional information about each component (e.g., whether it can be connected to high voltage after component failure, whether it can be driven after component failure, and the functions affected by component failure). When the OTA server triggers an OTA upgrade for a specific vehicle model, it can filter the information corresponding to the components to be upgraded in this OTA upgrade from the basic information corresponding to that vehicle model to generate the corresponding configuration information, which is then sent to the vehicle or, if the vehicle needs to end the OTA upgrade as soon as possible, sent to the vehicle.

[0139] In some possible embodiments, the above basic information can be stored in the form of a table, or it can be represented in other data formats, such as key-value pairs, dictionaries, etc.

[0140] Therefore, before the OTA upgrade, the OTA server, based on the above basic information, can determine the component set to which each component in this OTA upgrade belongs from the complete set of components of the vehicle model.

[0141] Figure 5 This is a schematic diagram of the component set relationship during OTA upgrade in the embodiments of this application.

[0142] refer to Figure 5 As shown, taking a reference vehicle model as an example, the basic information of the reference vehicle model is stored in the OTA server. Therefore, the OTA server can determine the complete set of components corresponding to the reference vehicle model (the component in this example is the ECU). Based on the ECU-related information carried in this firmware upgrade, the OTA server can determine all the ECUs involved in this OTA upgrade, and based on the basic information corresponding to each ECU, it can determine the component set to which each ECU belongs.

[0143] For example, the component set 1 of this reference vehicle includes ECU1 to ECU30, where ECU1 to ECU10 are mandatory components, ECU11 to ECU20 are necessary components, and ECU21 to ECU30 are non-necessary components. In this OTA upgrade, ECU2, ECU6, ECU9, ECU13, ECU14, ECU26, and ECU29 need to be updated. These ECUs constitute the component set 2 for this OTA upgrade. Taking the intersection of component set 2 and the various component sets in component set 1 determines which ECUs in each component set need to be upgraded in this OTA upgrade. Then, based on the upgrade firmware data volume corresponding to each ECU in component set 2, the vehicle's processor performance, and network quality, the estimated time for completing the upgrade of each ECU is determined. The basic information corresponding to each ECU is then used to generate the aforementioned configuration information, which is then sent to the vehicle, or sent to the vehicle only if the vehicle requests to abort the OTA upgrade.

[0144] In summary, the OTA server 410 proposed in this application embodiment includes at least the following functions: 1. Supporting the grouping of vehicle components; 2. Supporting the generation and distribution of configuration information for components to be upgraded via OTA (which can be distributed when the vehicle needs to stop the OTA upgrade); 3. Supporting communication with the OTA master control module on the vehicle side; 4. Supporting the selection of whether the vehicle can perform the relevant operation of stopping the upgrade.

[0145] and Figure 3 Similar to the intelligent device 320 shown, the vehicle-side OTA main control deployment component 420 may include a main process control module 421 and an interrupt control module 422. The interrupt control module 422 can establish communication with the OTA server 410 to respond to user requests during OTA upgrades, requesting and saving configuration information for the components to be upgraded. Furthermore, the interrupt control module 422 can interact with the main process control module 421 to trigger the main process control module 421 to expedite the OTA upgrade process. Alternatively, the interrupt control module 422 can be integrated into the main process control module 421 as a sub-module.

[0146] The main process control module 421 is used to schedule the OTA process according to the configuration information issued by the OTA server, and to respond to the request from the interrupt control module 422 to start the corresponding OTA upgrade termination process. Then, according to the configuration information of each component involved in the OTA upgrade, it determines the OTA upgrade termination strategy (including OTA upgrade termination indication information for different components) to end the OTA upgrade process as soon as possible, thereby meeting the user's need to use the vehicle as soon as possible.

[0147] Furthermore, the aforementioned main process control module 421 is connected to multiple domain controllers 430, and each domain controller 430 is also connected to at least one accessory controller 440. Each domain controller 430 is equipped with a domain controller installer 431 to flash the original firmware of each accessory controller 440 based on downloaded upgrade firmware, thereby enabling OTA upgrades for each accessory controller 440. The accessory controller 440 can be understood as the components mentioned above (e.g., ECU, firmware-based sensors, etc.). When it is determined that a component needs to have its OTA upgrade aborted, the domain controller installer 431 can abort the firmware installation process of the corresponding component according to the OTA upgrade abort instruction information issued by the main process control module 421.

[0148] In some possible embodiments, the basic information of each component of the vehicle can be directly stored on the vehicle side. The configuration information issued by the OTA server 410 can include the names or identifiers of the components being upgraded, as well as the estimated time for each component to complete the upgrade. After receiving the configuration information for this OTA upgrade, the vehicle side can determine the component set to which each component belongs by combining it with the locally stored basic information of each component. During the OTA upgrade process, if a user has a need to use the vehicle, a user request will be sent to the vehicle side to indicate the user's intention to use the vehicle. At this time, based on the component set to which each component participating in the upgrade belongs, a corresponding strategy to end the OTA upgrade as quickly as possible can be adopted.

[0149] It should be understood that Figure 3 and Figure 4 The architecture shown is for illustrative purposes only; in actual implementation, Figure 3 or Figure 4 The system shown may include more or fewer modules or components.

[0150] The system architecture provided by the embodiments of this application has been described above. The method provided by the embodiments of this application will be described in detail below.

[0151] In some possible embodiments, during the OTA upgrade process of the vehicle, in response to a user request, and depending on the progress of the OTA upgrade, at least one of the following operations is performed: continue the upgrade, abort the upgrade, or roll back.

[0152] The progress of the OTA upgrade can be the progress of each component of the OTA upgrade, which can be expressed as a percentage, estimated remaining time, etc.

[0153] Furthermore, at least one of the aforementioned operations can refer to operations on the components being upgraded in this OTA update, such as continuing the upgrade of the component, aborting the upgrade of the component, or rolling back the upgraded content of the component. At least one of the aforementioned operations can also refer to operations on the tasks being upgraded in this OTA update, such as continuing the upgrade of the component, aborting the upgrade of the component, or rolling back the upgraded content of the component.

[0154] It's important to note that in OTA upgrades, rollback can have the following meanings: 1. Stopping the current upgrade process; 2. Undoing all completed upgrade operations; 3. Restoring the system to its stable state before the upgrade. Therefore, when we mention rolling back the upgraded content of a component, it means stopping the upgrade process for that component and undoing all completed upgrade operations, essentially reverting the upgraded firmware data to its stable state before the upgrade.

[0155] In some possible embodiments, the aforementioned user request can represent the user's current vehicle usage intention. Furthermore, the user request can further represent the user's need to end the relevant operations of this OTA upgrade as soon as possible. Therefore, after the vehicle responds to the user request, it can trigger the execution of the aforementioned operations to meet the user's vehicle usage needs as quickly as possible.

[0156] Based on the above technical solution, it can respond to user requests and, based on the progress of the OTA upgrade, perform operations such as continuing the upgrade, suspending the upgrade, or rolling back the upgrade, so that the vehicle can restore driving functions as soon as possible and meet the user's car use needs during the OTA upgrade period, thereby avoiding a decline in the user's car use experience caused by the OTA upgrade operation.

[0157] In some possible embodiments, a user request may be generated in response to at least two confirmation actions performed by the user through a human-computer interaction interface, wherein the confirmation actions are used to indicate the user's intention to use the vehicle.

[0158] Figure 6 This is a schematic diagram illustrating a method for generating user requests based on a human-computer interaction interface, as proposed in an embodiment of this application.

[0159] In some possible embodiments, the human-computer interaction interface proposed in this application can be presented to the user in the following ways:

[0160] After the vehicle enters OTA upgrade mode, if the user is in the cabin and the central control screen in the vehicle cabin is turned on, the above human-machine interaction interface can be displayed through the vehicle's central control screen; if the user is in the cabin and the central control screen in the vehicle cabin is in standby mode, the vehicle's central control screen can be woken up and the above human-machine interaction interface can be displayed; if the user is not in the cabin, the above human-machine interaction interface can be displayed through the user's portable terminal.

[0161] In some possible embodiments, the aforementioned human-computer interaction interface can provide a control to abort OTA upgrades. During the OTA upgrade process, the user can access the abort OTA upgrade entry point by manipulating this control within the human-computer interaction interface. At this time, the human-computer interaction interface can display a pop-up window asking "Do you need to abort the OTA upgrade?", and provide confirmation and cancellation controls for aborting the OTA upgrade. By manipulating the confirmation control (equivalent to the confirmation operation described above), the user can proceed to the next step; by manipulating the cancellation control, the user will not proceed to the next step.

[0162] To prevent accidental user actions and to emphasize the need to stop the OTA upgrade, a second pop-up can appear after the user initially confirms the OTA upgrade abort via the aforementioned pop-up. This second pop-up can display "Please confirm again whether you need to stop the OTA upgrade" and provide confirmation and cancellation controls for stopping the OTA upgrade. When the user confirms via the confirmation control (equivalent to the confirmation operation mentioned above), the OTA upgrade is stopped, thus generating the aforementioned user request. When the user cancels via the cancellation control, the OTA upgrade is not stopped, and the aforementioned user request is not generated. This achieves the function of generating a user request through at least two confirmation operations performed by the user via the human-computer interaction interface.

[0163] In some possible implementations, in order to better serve as a secondary reminder and confirmation for the user, the second pop-up notification window may have a significantly different design from the first pop-up notification window, such as through differences in color, font, font size, pop-up effect, and sound effect.

[0164] Figure 7 This is a schematic diagram illustrating another method for generating user requests based on a human-computer interaction interface, as proposed in this application.

[0165] refer to Figure 7As shown, the aforementioned human-computer interaction interface provides a control to abort OTA upgrades. During the OTA upgrade process, users can access the abort OTA upgrade entry point by manipulating this control within the human-computer interaction interface. At this time, the human-computer interaction interface can display a pop-up window asking "Do you need to abort the OTA upgrade?", and provide confirmation and cancellation controls for aborting the OTA upgrade. If the user confirms the upgrade, the human-computer interaction interface will further display a password input interface, which includes the prompt text "Please enter your password," a password input box, a confirmation control, and a cancellation control. If the user completes the password input and the password is correct, the aforementioned user request can be generated.

[0166] Figure 8 This is a schematic diagram illustrating another method for generating user requests based on a human-computer interaction interface, as proposed in this application.

[0167] refer to Figure 8 As shown, the aforementioned human-computer interaction interface provides a control to stop OTA upgrades. During the OTA upgrade process, users can access the stop OTA upgrade entry point by manipulating this control within the human-computer interaction interface. At this time, a pop-up window will appear on the human-computer interaction interface, providing confirmation and cancellation controls for stopping the OTA upgrade. However, the confirmation control's functionality requires a long-press operation. This long-press operation can be further divided into two confirmation actions: the first is when the user clicks the confirmation control, which can be considered a confirmation action; the second is when the user long-presses the confirmation control for a period longer than a preset time, which can be considered a confirmation action. After the user completes these two confirmation actions, the aforementioned user request is generated.

[0168] There are many other ways to generate user requests, which will not be exhaustively listed in this application embodiment.

[0169] Based on the above technical solution, the multiple confirmation operation mechanism can effectively avoid situations where OTA upgrades cannot be completed as expected due to user misoperation.

[0170] However, after OTA upgrades are suspended, it is necessary to ensure that components related to driving functions do not malfunction, i.e., to guarantee the reliability of vehicle driving-related functions. Furthermore, the OTA upgrade process needs to be completed as quickly as possible to restore vehicle driving functions and meet user needs. To simultaneously meet these two requirements, this application's embodiments adopt different operating strategies for components belonging to different component sets.

[0171] Figure 9 This is a flowchart illustrating an OTA upgrade method 900 proposed in an embodiment of this application.

[0172] refer to Figure 9 As shown, this OTA upgrade method can be completed through collaboration between the OTA server and the vehicle. When the OTA upgrade object includes a first set of components, each component in the first set of components is used to collaboratively implement the vehicle's driving-related functions. Therefore, during the OTA upgrade process, after responding to the aforementioned user request, the process can enter method 900, which may include the following operations:

[0173] S910: Determine the first upgrade progress of the first component set.

[0174] In some possible embodiments, the first set of components may be at least a part of the set of essential components in the basic vehicle information mentioned above. That is, the first set of components may be the set of essential components (this OTA upgrade involves all components in the set of essential components), or the first set of components may be a subset of the set of essential components (this OTA upgrade only involves a portion of the components in the set of essential components).

[0175] In some possible embodiments, the OTA server may send first configuration information to the vehicle, which indicates that the object of the OTA upgrade includes the aforementioned first set of components. Alternatively, the first configuration information may indicate multiple components among the objects of the OTA upgrade that are used to collaboratively implement the vehicle's driving-related functions, and after the vehicle determines these multiple components, the aforementioned first set of components is determined.

[0176] In some possible embodiments, the aforementioned first upgrade progress may refer to the current OTA upgrade progress of each component in the first component set, which can be expressed as a percentage, where 100% represents completed, 0% represents not yet started, and (0%, 100%) represents upgrade in progress; or it can be expressed as the remaining time expected to complete the upgrade for each component.

[0177] In some possible embodiments, the OTA server may also send second configuration information to the vehicle, which indicates the estimated time for completing the OTA upgrade for each component in the first component set.

[0178] In some possible embodiments, the first configuration information and the second configuration information described above can be sent through a single configuration message.

[0179] In some possible embodiments, after the vehicle enters the OTA upgrade process, the in-vehicle terminal's human-machine interface and / or the user's portable terminal device can jump to the upgrade installation interface and display the estimated remaining time to complete the OTA upgrade. The estimated remaining time can be determined based on the reference estimated time for each component to complete the upgrade in this OTA upgrade, issued by the OTA server, and the time elapsed since the upgrade began on the vehicle side.

[0180] S920: Based on the first upgrade progress, determine to perform one of the following operations on the first component set: continue the upgrade or roll back.

[0181] Since the components in the first component set are used to work together to implement the vehicle's driving-related functions, it is necessary to ensure that the firmware versions of the components in the first component set are consistent in order for the driving-related functions implemented by these components to function normally.

[0182] In summary, to expedite the OTA upgrade process, for the first component set, one of the two approaches described in S920 can be chosen. The selection is based on the aforementioned first upgrade progress, which can be used to determine the duration for continuing the OTA upgrade of the first component set until completion, or the duration for rolling back the first component set. Since the current requirement is to expedite the OTA upgrade process and provide users with reliable driving-related functions, the approach with the shorter expected timeframe can be selected.

[0183] If the first component set is rolled back, the versions of all components in the rolled-back first component set will be consistent, all being the versions before the upgrade, and will not affect the driving functions performed collaboratively by these components. If the first component set continues to be upgraded via OTA until completion, the versions of all components in the upgraded first component set will also be consistent, and will not affect the driving functions performed collaboratively by these components.

[0184] In some possible embodiments, since the components involved in the manual driving function are fewer than those involved in the driver assistance function, in order to further accelerate the OTA upgrade process, the first set of components in this OTA upgrade may include the minimum number of components for implementing the manual driving function of the vehicle.

[0185] Based on the above technical solution, the system can respond to users' vehicle usage needs during OTA upgrades. It can select and execute the shorter operation from the options of continuing to perform OTA upgrades on various components that coordinate to realize the vehicle's driving-related functions until completion, and rolling back these components, so as to end the OTA upgrade operation as soon as possible. Furthermore, it can ensure that the firmware versions of various components are consistent after the OTA upgrade is completed as soon as possible, so as to ensure that the functional coordination between these components is not affected after the OTA upgrade is stopped, thereby meeting the user's need to use the vehicle as soon as possible and minimizing the decline in the user's driving experience.

[0186] In some possible embodiments, for the first set of components, the above S920 can be implemented by the following operation:

[0187] S921: Determine the first estimated duration and the second estimated duration based on the first upgrade progress.

[0188] The first estimated duration is the time from the current moment to the completion of the OTA upgrade of the first component set, and the second estimated duration is the time from the current moment to the completion of the rollback of the upgraded content in the first component set.

[0189] S922: Determine whether the first estimated duration is greater than the second estimated duration. If yes, proceed to S923; otherwise, proceed to S924.

[0190] In some possible embodiments, when the first estimated duration is equal to the second estimated duration, either step S923 or S924 can be performed.

[0191] S923: Roll back the upgraded content in the first component set.

[0192] S924: Continue OTA upgrades for the first component set.

[0193] In this embodiment, the aforementioned rollback of the upgraded content in the first component set and the continuation of OTA upgrades for the first component set are defined as the path (or means) for terminating OTA upgrades. Therefore, terminating OTA upgrades does not necessarily require rolling back the component set; the upgrade of the component set can also be completed, with the aim of ending the OTA upgrade as quickly as possible.

[0194] In some possible embodiments, the vehicle can receive configuration information sent by the OTA server, which is used to indicate the reference estimated time for completing the OTA upgrade for each component in the first component set. Then, based on the reference estimated time for the components in the current first component set that have not completed the OTA upgrade, the first estimated time can be determined.

[0195] For example, during the OTA upgrade process for a vehicle, the OTA server sends configuration information for this OTA upgrade to the vehicle (the configuration information includes details in the aforementioned embodiments). This configuration information includes the estimated time for each component to complete the OTA upgrade, and some of these components belong to the aforementioned first component set. When a component initiates an OTA upgrade, a timer can be run to obtain the elapsed time in real time. Based on the estimated time for the component to complete the OTA upgrade in the configuration information and the elapsed time obtained, the remaining time for completing the OTA upgrade can be determined. This remaining time is the time required from the current moment until the OTA upgrade of the component is completed. Typically, the first component set includes multiple components, so it can include multiple remaining times. The longest remaining time is the aforementioned first estimated time.

[0196] In some possible embodiments, the second estimated duration can be determined based on the amount of firmware data that has been flashed and the processor performance.

[0197] Based on the above technical solution, by determining the estimated time for continuing to upgrade and rolling back the first component set, the shorter OTA upgrade termination path is selected so that the vehicle can provide driving functions to the user as soon as possible, meet the user's need to use the car as soon as possible, and minimize the decline in the user's driving experience.

[0198] In some possible implementations, OTA upgrades can be divided into multiple installation phases:

[0199] 1. Installation countdown phase;

[0200] 2. Installation preparation stage;

[0201] 3. Flashing / writing stage;

[0202] 4. Activation phase;

[0203] Therefore, even if the components in the first component set enter the OTA upgrade process, corresponding processing operations can be taken depending on the installation stage of the components.

[0204] In some possible embodiments, if the first upgrade progress indicates that each component in the first component set has completed the data writing phase of the OTA upgrade, the OTA upgrade of the first component set can continue. If, in this case, it is still chosen to roll back the first component set, the progress of ending the OTA upgrade process may be delayed.

[0205] Conversely, if the first upgrade progress indicates that the components in the first component set have not yet entered the data writing stage of the OTA upgrade, the OTA upgrade of the first component set can be suspended. If the upgrade of the first component set is still continued under this situation, the progress of ending the OTA upgrade process will be further delayed.

[0206] Based on the above technical solution, the upgrade stage of each component in the first component set can be used to determine whether to continue upgrading or roll back the first component set, without having to calculate the estimated time for each component to complete the upgrade, thereby reducing computational overhead.

[0207] Considering that when a component enters the exit phase of an OTA upgrade, it is necessary to generate and upload relevant upgrade feedback information, such as collecting asset information, firmware version information, and upgrade logs, etc., these operations can be simplified to execute a simplified exit process when there is a need to end the OTA upgrade as quickly as possible.

[0208] In some possible embodiments, taking the first set of components as an example, when it is determined that the first set of components will continue to be upgraded via OTA, when each component in the first set of components enters the exit phase, operations such as collecting asset information, firmware version information, and upgrade logs as described above may not be performed. Only necessary operations may be performed, such as verifying the integrity of the new firmware, updating the system status, and restarting the device.

[0209] Based on the above technical solutions, the speed of completing OTA upgrades can be further accelerated.

[0210] In an OTA (Over-The-Air) update, the components involved may not all belong to the same set of components, such as the first set of components mentioned above. Therefore, the OTA update may also include a second set of components, where each component independently implements the vehicle's driving-related functions. This second set of components may be at least a portion of the necessary set of components mentioned above.

[0211] In some possible embodiments, the first configuration information sent by the OTA server to the vehicle can also be used to indicate that the object of the OTA upgrade includes the second set of components. Alternatively, the first configuration information can also be used to indicate at least one component among the objects of the OTA upgrade that is used to independently implement the vehicle's driving-related functions. After the vehicle determines the at least one component, the aforementioned second set of components can be determined.

[0212] In this regard, the method 900 proposed in this application embodiment can also perform the following operations on the second set of components:

[0213] S930: Perform the following operations on the components in the second component set: continue the upgrade, abort the upgrade, or roll back.

[0214] In some possible embodiments, the above S930 can be executed based on the following mechanism: continue to upgrade the components in the second component set that are undergoing OTA upgrades, and stop upgrading the components in the second component set that have not started OTA upgrades.

[0215] In some possible embodiments, based on the foregoing, after a component enters the OTA upgrade process, it does not directly enter the data flashing operation, but needs to go through two stages: installation countdown and installation preparation. Therefore, the OTA upgrade process for components that have only entered the installation countdown and installation preparation stages can also be suspended. That is, S930 can also be executed based on the following mechanism: continue upgrading the components in the second component set that have entered the data flashing stage of the OTA upgrade, and suspend the upgrade of the components in the second component set that have not yet entered the data flashing stage.

[0216] Since the components in the second component set that have not yet entered the data flashing stage have not yet been flashed with the new firmware data when the upgrade is stopped, it is not necessary to roll back the components.

[0217] Therefore, different operations can be taken for components in the second set of components that are at different upgrade stages. For example, if some components in the second set of components have entered the data writing stage, the upgrade operation can be continued or rolled back for these components; if other components in the second set of components have not yet entered the writing stage, the upgrade operation can be stopped for these components; and if yet another set of components in the second set of components have completed the writing stage, the upgrade operation can be continued for these components until the OTA upgrade process is completed.

[0218] In some possible embodiments, for components in the second component set that are in the data flushing stage, a similar judgment logic as that for the first component set can be adopted, i.e., determining whether the component should continue upgrading or rollback. For example, a third estimated time for each component to complete the upgrade and a fourth estimated time for completing the rollback can be determined. If the third estimated time is greater than or equal to the fourth estimated time, the component is rolled back; or, if the third estimated time is less than or equal to the fourth estimated time, the component continues upgrading.

[0219] In the aforementioned operations targeting the second component set, there are two paths for aborting OTA upgrades for the components within the second set. However, unlike the operation logic for the first component set, the path for aborting OTA upgrades for the second set can differ for each component. Some components in the second set can continue OTA upgrades until completion, while others can exit the OTA upgrade process no later than the data flashing stage. This is because each component in the second set can independently implement the vehicle's driving functions, so the firmware versions of the components do not need to be consistent across all components. Furthermore, after the above operations, the functional reliability of each component in the second set is guaranteed, preventing any component from operating without complete and reliable firmware.

[0220] Based on the above technical solution, it is possible to respond to users' vehicle needs during OTA upgrades. For components that independently implement driving-related functions of the vehicle, the process can be suspended for components that have not yet started OTA upgrades or have not yet entered the data flashing stage of OTA upgrades, so that these components can continue to run based on the original version, so as to provide users with reliable driving functions as soon as possible and avoid the decline in users' driving experience as much as possible.

[0221] In addition, the objects of OTA upgrades may also include a third set of components, each of which is used to implement non-driving related functions of the vehicle. This third set of components may be at least a part of the set of non-essential components mentioned above.

[0222] In some possible embodiments, the first configuration information sent by the OTA server to the vehicle can also be used to indicate that the object of the OTA upgrade includes the third set of components. Alternatively, the first configuration information can also be used to indicate at least one component among the objects of the OTA upgrade that is used to implement non-driving related functions of the vehicle. After the vehicle determines the at least one component, the aforementioned third set of components can be determined.

[0223] In this regard, the method 900 proposed in this application embodiment can also perform the following operations on the third component set:

[0224] S940: Abort upgrade of the third component assembly.

[0225] In some possible embodiments, after the OTA upgrade of the third component set is stopped, there may be components in the third component set that have completed the OTA upgrade. For such components, if the components can independently implement the non-driving related functions of the vehicle, the components can run based on the updated firmware when the user uses the vehicle in the future. If the components need to cooperate with other components to implement the non-driving functions of the vehicle, it is necessary to determine the version consistency of the components with other components. If the versions are consistent, these components can run based on the updated firmware when the user uses the vehicle in the future. If the versions are inconsistent, these components are prohibited from running in the future to avoid component malfunctions due to version inconsistency, which would affect the user's normal driving.

[0226] In some possible embodiments, after the OTA upgrade of the third component set is stopped, there may be components in the third component set that have only completed partial data upgrades. For these components, they shall be prohibited from operating during subsequent user vehicle use to avoid component malfunctions due to incomplete firmware data, which would affect the user's normal driving.

[0227] In some possible embodiments, after the OTA upgrade of the third component set is stopped, there may still be components in the third component set that have not yet started OTA upgrade or have not yet entered the data flashing stage of OTA upgrade. For such components, if the component can independently realize the non-driving related functions of the vehicle, the component can run based on the original firmware when the user uses the vehicle in the future. If the component needs to cooperate with other components to realize the non-driving functions of the vehicle, it is necessary to determine the version consistency of the component with other components. If the versions are consistent, these components can run based on the original firmware when the user uses the vehicle in the future. If the versions are inconsistent, these components are prohibited from running when the user uses the vehicle in the future to avoid running errors caused by version inconsistency, which would affect the user's normal driving.

[0228] Based on the above technical solution, considering that the components used in OTA upgrades to realize non-driving related functions of the vehicle will not directly affect the user's driving function, when it is necessary to end the OTA upgrade process as soon as possible, the upgrade of these components can be directly stopped so that the OTA upgrade process can be completed as soon as possible, so as to meet the user's need to use the car as soon as possible and avoid a decline in the user's car use experience.

[0229] The storage partitions for some components in a vehicle may include multiple partitions, each storing a set of firmware. When a component is running, it operates on the firmware stored in one of these partitions. The firmware in unused partitions can be used as a backup. Typically, a dual-partition storage architecture is used, consisting of a primary partition and a backup partition. The primary partition is used to run the firmware, while the backup partition stores firmware backups. If an error occurs in the firmware on the primary partition, the component can directly switch to the backup partition to run the backup firmware, thereby ensuring the stability and reliability of the vehicle's components.

[0230] In response, this application also proposes a fourth component set, which includes components for independently implementing relevant vehicle functions. Each component in the fourth component set includes multiple partitions, each partition storing a set of firmware. Components belonging to the fourth component set can also belong to the aforementioned necessary component set and non-necessary component set. Accordingly, there is an intersection between the fourth component set and the aforementioned second and / or third component sets.

[0231] In some possible embodiments, the first configuration information sent by the OTA server to the vehicle can also be used to indicate that the object of the OTA upgrade includes the fourth set of components. Alternatively, the first configuration information can also be used to indicate at least one component among the objects of the OTA upgrade that is used to independently implement the relevant functions of the vehicle, and these components include multiple partitions, each of which is used to store a set of firmware. After the vehicle determines the at least one component, the aforementioned fourth set of components can be determined.

[0232] In this regard, the method 900 proposed in this application embodiment can also perform the following operations on the fourth component set:

[0233] S950: Abort upgrades for the fourth component set, in which each component is running on un-flashed firmware or firmware that has been OTA-upgraded.

[0234] The operation of each component in the fourth component set based on un-flashed firmware or firmware that has been upgraded via OTA can refer to the subsequent operations performed by the user during vehicle use.

[0235] In some possible embodiments, for firmware that has completed OTA upgrades, the corresponding functions can be implemented directly based on the new firmware; for firmware that has not completed OTA upgrades, the corresponding functions can be implemented based on the firmware in the backup partition of the component.

[0236] Since the component's running partition switches from the primary partition to the backup partition very quickly, typically much faster than the component continues to perform OTA upgrades until completion, this solution can further accelerate the completion of OTA upgrades.

[0237] It should be noted that the operations of the method 900 proposed in this application for the first set of components, the second set of components, the third set of components, and the fourth set of components are independent of each other. Since the first set of components, the second set of components, and the third set of components have no intersection, the operations for these three set of components do not affect each other. However, there may be an intersection between the second set of components, the third set of components, and the fourth set of components. Therefore, after determining the OTA abort strategy for the second set of components or the third set of components, it is not necessary to perform related operations for the fourth set of components, and vice versa.

[0238] In some possible embodiments, after triggering the operation to end the OTA upgrade process as soon as possible, it can be determined first whether the object of this OTA upgrade belongs to the fourth component set. If it does, the above-mentioned operation S940 can be performed first to process the component belonging to the fourth component set. After processing, the operation S920 or S930 is performed on the component that belongs only to the second component set and / or only to the third component set, thereby avoiding multiple path judgments to terminate OTA for the same component.

[0239] Based on the above technical solution, when responding to a user's request during the vehicle's OTA upgrade, the OTA upgrade process of components with a dual-partition storage architecture that independently implement the vehicle's relevant functions can be directly terminated. This allows these components to run based on backup firmware stored in other partitions, ensuring the functional reliability and stability of the firmware. It also helps to end the OTA upgrade as soon as possible to meet the user's vehicle usage needs.

[0240] Of course, when the storage architecture of each component in the first component set includes the first partition and the second partition, the above-mentioned operation logic for the fourth component set can also be referenced. However, since each component in the first component set is used to collaboratively implement the vehicle's driving-related functions, the operation logic needs to be adapted.

[0241] In some possible embodiments, during an OTA upgrade of a vehicle, in response to a user request, if the firmware versions stored in the second partition of each component are consistent, the upgrade of the first component set is aborted, and each component in the first component set can run based on the firmware stored in the second area.

[0242] In some possible embodiments, the OTA server may send first configuration information to the vehicle, which indicates that the object of the OTA upgrade includes the aforementioned first set of components. Alternatively, the first configuration information may indicate multiple components among the objects of the OTA upgrade that are used to collaboratively implement the vehicle's driving-related functions, and after the vehicle determines these multiple components, the aforementioned first set of components is determined.

[0243] In some possible embodiments, the OTA server may also send third configuration information to the vehicle, which indicates that the storage architecture of each component in the first component set includes a first partition and a second partition.

[0244] In some possible embodiments, the first configuration information and the third configuration information described above can be sent through a single configuration message.

[0245] In some possible embodiments, the third configuration information may also include the firmware version number stored in each partition of each component in the first component set before the upgrade, so that after the vehicle triggers the process of ending the OTA upgrade as soon as possible, it can determine whether each component in the first component set stores the same version of the original firmware in the corresponding partition. If so, the OTA upgrade of the first component set can be directly stopped, and each component in the first component set can run based on the same version of the original firmware.

[0246] Based on the above technical solutions, the speed of OTA upgrades can be further accelerated, meeting users' needs for immediate vehicle use and minimizing any decline in user experience. Furthermore, it ensures the reliability and stability of vehicle driving functions.

[0247] In some possible embodiments, the human-machine interface mentioned above for triggering the process of ending the OTA upgrade as soon as possible can also display the estimated time for the vehicle to resume driving functions after responding to the user's request.

[0248] In some possible embodiments, the estimated time for the vehicle to regain its driving function can be determined as follows: The estimated time for each component set to complete the continued upgrade, aborted upgrade, or rollback is obtained, and the longest estimated time among these is determined as the estimated time for the vehicle to regain its driving function. Alternatively, the estimated time for each component to complete the continued upgrade, aborted upgrade, or rollback is obtained separately, and the longest estimated time among these is determined as the estimated time for the vehicle to regain its driving function.

[0249] The above are methods for quickly ending OTA upgrades according to embodiments of this application. In summary, the method 900 proposed in embodiments of this application can at least satisfy the following rules:

[0250] 1. The firmware versions of all components in the first set of components involved in this OTA upgrade are consistent or compatible. This avoids operational malfunctions caused by inconsistent component versions while the user is driving.

[0251] 2. The firmware of each component in the second set of components involved in this OTA upgrade must be complete. This is to avoid firmware malfunctions caused by running the upgrade with incomplete component firmware data.

[0252] 3. The chosen path to end the OTA upgrade takes the least time.

[0253] In some possible embodiments, after the vehicle has completed the method 900 proposed in the embodiments of this application, driving privileges or manual driving privileges may be granted to the user.

[0254] In some possible embodiments, during or after the vehicle has completed the method 900 proposed in the embodiments of this application, a time appointment request to restart the OTA upgrade can be initiated to the user through the human-machine interface, and the OTA upgrade process can be restarted at the newly scheduled time.

[0255] In some possible implementations, after restarting the OTA upgrade process, for components that have previously completed OTA upgrades and have not been rolled back, the upgrade operation does not need to be repeated; for components that have been rolled back, the OTA upgrade can be performed again; for components that have previously upgraded some data, the OTA upgrade can continue from the last interrupted position.

[0256] Furthermore, embodiments of this application also provide an apparatus for implementing any of the above methods, the apparatus including units (or means) for implementing any of the above methods.

[0257] Figure 10 This is a schematic block diagram of a device 1000 for OTA upgrades provided in an embodiment of this application. The device 1000 is deployed on a vehicle.

[0258] refer to Figure 10 As shown, the device 1000 includes:

[0259] The main control unit 1010 is used to respond to user requests and perform at least one of the following operations according to the progress of the OTA upgrade during the vehicle's OTA upgrade process: continue the upgrade, abort the upgrade, or roll back.

[0260] In some possible embodiments, the OTA upgrade targets a first set of components, each component in which is used to collaboratively implement driving-related functions of the vehicle. The aforementioned main control unit 1010 includes:

[0261] Determining unit 1011 is used to determine the first upgrade progress of the first component set.

[0262] The execution unit 1012 is configured to perform any of the following operations on the first component set according to the first upgrade progress: continue upgrading or rollback.

[0263] In some possible embodiments, the execution unit 1012 is further configured to: continue the OTA upgrade of the first component set when the first upgrade progress indicates that each component in the first component set has completed the data writing stage of the OTA upgrade; or, stop the OTA upgrade of the first component set when the first upgrade progress indicates that each component in the first component set has not yet entered the data writing stage of the OTA upgrade.

[0264] In some possible embodiments, the determining unit 1011 is further configured to: determine a first estimated duration and a second estimated duration based on the first upgrade progress, wherein the first estimated duration is the duration from the current moment to the completion of the OTA upgrade of the first component set, and the second estimated duration is the duration from the current moment to the completion of the rollback of the upgraded content in the first component set. The execution unit 1012 is further configured to: roll back the upgraded content in the first component set if the first estimated duration is greater than or equal to the second estimated duration; or, continue the OTA upgrade of the first component set if the first estimated duration is less than or equal to the second estimated duration.

[0265] In some possible embodiments, the main control unit 1010 further includes: a receiving unit 1013, configured to receive configuration information sent by the OTA server, wherein the configuration information is used to indicate the reference estimated time for completing the OTA upgrade for each component in the first component set; the determining unit 1011 is specifically configured to: determine the first estimated time based on the reference estimated time corresponding to the component in the current first component set that has not completed the OTA upgrade.

[0266] In some possible embodiments, the first set of components described above is the minimum set of components used to collaboratively achieve the manual driving function of the vehicle.

[0267] In some possible embodiments, the object of the above-mentioned OTA upgrade also includes a second set of components, each of which is used to independently implement the driving-related functions of the vehicle. The execution unit 1012 is also used to perform the following operations on the components in the second set of components: continue the upgrade, stop the upgrade, or roll back.

[0268] In some possible embodiments, the target of the above-mentioned OTA upgrade also includes a third component set, each component in which is used to implement non-driving related functions of the vehicle, and the above-mentioned execution unit 1012 is also used to: stop the upgrade of the third component set.

[0269] In some possible embodiments, the object of the above-mentioned OTA upgrade also includes a fourth component set, which includes components for independently implementing the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each partition being used to store a set of firmware. The execution unit 1012 is also used to: stop the upgrade of the fourth component set, and each component in the fourth component set runs based on un-flashed firmware or firmware that has completed the OTA upgrade.

[0270] In some possible embodiments, the main control unit 1010 is also used to: display the estimated time for the vehicle to resume driving function through a human-machine interface.

[0271] In some possible embodiments, the main control unit 1010 is further configured to: generate a user request in response to at least two confirmation operations performed by the user through the human-machine interface, wherein the confirmation operations are used to indicate the user's intention to use the vehicle.

[0272] In some possible embodiments, the first set of components to be upgraded by the OTA is used to collaboratively implement the driving-related functions of the vehicle. The storage architecture of each component in the first set of components includes a first partition and a second partition. The execution unit 1012 is further configured to: during the OTA upgrade process of the vehicle, in response to a user request, upgrade the first set of components to be upgraded by the OTA, the first set of components to be upgraded by the OTA is used to collaboratively implement the driving-related functions of the vehicle. The storage architecture of each component in the first set of components includes a first partition and a second partition.

[0273] Figure 11 This is a schematic block diagram of another device 1100 for OTA upgrades provided in this application embodiment. The device 1100 is deployed on the OTA server.

[0274] refer to Figure 11 As shown, the device 1100 includes:

[0275] The sending unit 1110 is used to send enable information to the vehicle terminal, which enables the vehicle terminal to respond to user requests and perform at least one of the following operations according to the progress of OTA upgrade: continue upgrade, stop upgrade or rollback.

[0276] In some possible embodiments, the sending unit 1110 is further configured to: send first configuration information to the vehicle, the first configuration information indicating that the object of the OTA upgrade includes a first set of components, each component in the first set of components being used to collaboratively implement the vehicle's driving-related functions; and send second configuration information to the vehicle, the second configuration information indicating the reference estimated time for completing the OTA upgrade for each component in the first set of components, so that when the vehicle responds to a user request during the OTA upgrade process, it determines the first upgrade progress of the first set of components, and performs any of the following operations on the first set of components according to the first upgrade progress: continue upgrading or rollback.

[0277] In some possible embodiments, the first set of components described above is the minimum set of components used to collaboratively achieve the manual driving function of the vehicle.

[0278] In some possible embodiments, the first configuration information described above may also be used to indicate that the object of the OTA upgrade includes a second set of components, each component in the second set of components is used to independently implement the vehicle's driving-related functions, so that when a user request is received during the vehicle's OTA upgrade process, the following operations are performed on the components in the second set of components: continue the upgrade, abort the upgrade, or roll back.

[0279] In some possible embodiments, the first configuration information described above may also be used to indicate that the object of the OTA upgrade includes a third component set, wherein each component in the third component set is used to implement non-driving related functions of the vehicle, so that when a user request is received during the OTA upgrade process of the vehicle, the upgrade of the third component set is stopped.

[0280] In some possible embodiments, the first configuration information described above may also be used to indicate that the object of the OTA upgrade includes a fourth component set. The fourth component set includes components for independently implementing the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each partition being used to store a set of firmware, so that when a user request is received during the OTA upgrade of the vehicle, the upgrade of the fourth component set is stopped, and each component in the fourth component set runs based on un-flashed firmware or firmware that has completed the OTA upgrade.

[0281] In some possible embodiments, the sending unit 1110 is further configured to: send first configuration information to the vehicle, the first configuration information indicating that the object of the OTA upgrade includes a first component set, each component in the first component set being used to collaboratively implement the vehicle's driving-related functions; and send third configuration information to the vehicle, the third configuration information indicating that the storage architecture of each component in the first component set includes a first partition and a second partition, so that when a user request is received during the vehicle's OTA upgrade process, if the firmware versions stored in the second partitions of each component are consistent, the upgrade of the first component set is stopped, and each component in the first component set operates based on the firmware stored in the second partition.

[0282] It should be understood that the division of units in the above device is only a logical functional division. In actual implementation, they can be fully or partially integrated into a single physical entity, or they can be physically separated. Furthermore, the units in the device can be implemented by a processor calling software; for example, the device includes a processor connected to memory, which stores instructions. The processor calls the instructions stored in memory to implement any of the above methods or to implement the functions of each unit in the device. The processor can be, for example, a general-purpose processor, such as a CPU or microprocessor, and the memory can be internal or external to the device. Alternatively, the units in the device can be implemented as hardware circuits. The functions of some or all units can be implemented through the design of the hardware circuits, which can be understood as one or more processors. For example, in one implementation, the hardware circuit is an ASIC, and the functions of some or all units are implemented through the design of the logical relationships between the components within the circuit. In another implementation, the hardware circuit can be implemented using a PLD, such as an FPGA, which can include a large number of logic gates. The connection relationships between the logic gates are configured through configuration files, thereby implementing the functions of some or all units. All units of the above devices can be implemented entirely through processor calling software, or entirely through hardware circuits, or partially through processor calling software with the remaining parts implemented through hardware circuits.

[0283] In this application embodiment, a processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a CPU, microprocessor, GPU, or DSP. In another implementation, the processor can implement certain functions through the logical relationships of hardware circuits. These logical relationships are fixed or reconfigurable. For example, the processor may be a hardware circuit implemented as an ASIC or PLD, such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document and configuring the hardware circuit can be understood as the processor loading instructions to implement the functions of some or all of the above units. Furthermore, it can also be a hardware circuit designed for artificial intelligence, which can be understood as an ASIC, such as an NPU, TPU, or DPU.

[0284] As can be seen, each unit in the above device can be one or more processors (or processing circuits) configured to implement the above methods, such as: CPU, GPU, NPU, TPU, DPU, microprocessor, DSP, ASIC, FPGA, or a combination of at least two of these processor forms.

[0285] Furthermore, the units in the above devices can be integrated in whole or in part, or they can be implemented independently. In one implementation, these units are integrated together as a System-on-a-Chip (SoC). The SoC may include at least one processor for implementing any of the above methods or implementing the functions of the units in the device. The at least one processor may be of different types, such as CPU and FPGA, CPU and AI processor, CPU and GPU, etc.

[0286] This application provides yet another apparatus for OTA upgrades, which includes a processor and a memory connected together. The memory is used to store program code, and the processor is used to call the program code to execute any of the OTA upgrade methods proposed in this application.

[0287] In some possible embodiments, the aforementioned device for OTA upgrades is mounted in a vehicle to implement the vehicle-side operations in the OTA upgrade method proposed in this application embodiment. The aforementioned processor may be... Figure 1 One or more of the processors 121-12n shown.

[0288] In some possible embodiments, the above-described apparatus for OTA upgrades is mounted in an OTA server to implement the server-side operations in the OTA upgrade method proposed in the embodiments of this application.

[0289] This application also provides a vehicle that may include any of the devices for OTA upgrades proposed in this application, which are used to implement the vehicle-side operations in the OTA upgrade method proposed in this application.

[0290] This embodiment also provides a server, which may include any of the devices for OTA upgrades proposed in this application embodiment. The device is used to implement the server-side operations in the OTA upgrade method proposed in this application embodiment.

[0291] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the methods described in the above embodiments.

[0292] This application also provides a computer-readable medium storing program code that, when run on a computer, causes the computer to perform the methods described in the above embodiments.

[0293] This application also provides a chip that includes circuitry for performing the methods described in the above embodiments.

[0294] In some possible embodiments, the chip described above can be a DSP chip.

[0295] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0296] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0297] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0298] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0299] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0300] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0301] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An OTA upgrade method, characterized in that, During the OTA upgrade process for a vehicle, the method includes: In response to a user request, and based on the progress of the OTA upgrade, perform at least one of the following operations: continue the upgrade, abort the upgrade, or roll back.

2. The method according to claim 1, characterized in that, The OTA upgrade targets a first set of components, where each component in the first set is used to collaboratively implement the vehicle's driving-related functions. The method further includes: Determine the first upgrade progress of the first component set; Based on the first upgrade progress, perform one of the following operations on the first component set: continue upgrading or rollback.

3. The method according to claim 2, characterized in that, The method further includes: If the first upgrade progress indicates that each component in the first component set has completed the data flashing phase of the OTA upgrade, then the OTA upgrade of the first component set continues; or... If the first upgrade progress indicates that each component in the first component set has not yet entered the data writing stage of the OTA upgrade, the OTA upgrade of the first component set shall be terminated.

4. The method according to claim 2, characterized in that, The method further includes: Based on the first upgrade progress, a first estimated duration and a second estimated duration are determined. The first estimated duration is the time from the current moment to the completion of the OTA upgrade of the first component set, and the second estimated duration is the time from the current moment to the completion of the rollback of the upgraded content in the first component set. If the first estimated duration is greater than or equal to the second estimated duration, the upgraded content in the first component set will be rolled back; or... If the first estimated duration is less than or equal to the second estimated duration, continue to perform OTA upgrades on the first component set.

5. The method according to claim 4, characterized in that, The step of determining the first estimated duration based on the first upgrade progress includes: Receive configuration information sent by the OTA server, the configuration information being used to indicate the reference estimated time for completing the OTA upgrade for each component in the first component set; The first estimated time is determined based on the reference estimated time corresponding to the components in the current first component set that have not completed OTA upgrades.

6. The method according to any one of claims 2 to 5, characterized in that, The first set of components is the minimum number of components used to collaboratively achieve the manual driving function of the vehicle.

7. The method according to any one of claims 2 to 6, characterized in that, The OTA upgrade also includes a second set of components, each component in the second set of components being used to independently implement the vehicle's driving-related functions. The method further includes: Perform the following operations on the components in the second component set: continue the upgrade, abort the upgrade, or roll back.

8. The method according to any one of claims 2 to 7, characterized in that, The OTA upgrade also includes a third component set, where each component in the third component set is used to implement non-driving-related functions of the vehicle. The method further includes: The upgrade of the third component set is terminated.

9. The method according to claim 2, characterized in that, The OTA upgrade also includes a fourth component set, which comprises components for independently implementing the relevant functions of the vehicle. Each component in the fourth component set includes multiple partitions, each partition storing a set of firmware. The method further includes: The upgrade of the fourth component set is terminated. Each component in the fourth component set operates based on firmware that has not been flashed or firmware that has been upgraded via OTA.

10. The method according to any one of claims 1 to 9, characterized in that, The method further includes: The estimated time for the vehicle to regain its driving function is displayed through a human-computer interaction interface.

11. The method according to any one of claims 1 to 10, characterized in that, The method further includes: The user request is generated in response to at least two confirmation actions performed by the user through the human-computer interaction interface, the confirmation actions being used to indicate the user's intention to use the vehicle.

12. An OTA upgrade method, characterized in that, The OTA upgrade targets a first set of components, which are used to collaboratively implement the vehicle's driving-related functions. The storage architecture of each component in the first set includes a first partition and a second partition. During the OTA upgrade process of the vehicle, the method includes: In response to a user request, if the firmware versions stored in the second partition of each component are consistent, the upgrade of the first component set is terminated, and each component in the first component set operates based on the firmware stored in the second region.

13. An OTA upgrade method, characterized in that, The method includes: Send an enable message to the vehicle, which enables the vehicle to respond to user requests and perform at least one of the following operations based on the progress of the OTA upgrade: continue the upgrade, stop the upgrade, or roll back.

14. The method according to claim 13, characterized in that, The method further includes: Send first configuration information to the vehicle, the first configuration information being used to indicate that the object of the OTA upgrade includes a first set of components, and each component in the first set of components is used to collaboratively implement the vehicle's driving-related functions; Send second configuration information to the vehicle. The second configuration information is used to indicate the reference estimated time for completing the OTA upgrade for each component in the first component set. When the vehicle responds to a user request during the OTA upgrade process, it determines the first upgrade progress of the first component set and performs any of the following operations on the first component set according to the first upgrade progress: continue upgrading or rollback.

15. The method according to claim 14, characterized in that, The first set of components is the minimum number of components used to collaboratively achieve the manual driving function of the vehicle.

16. The method according to claim 14 or 15, characterized in that, The first configuration information is also used to indicate that the object of the OTA upgrade includes a second set of components, each component in the second set of components is used to independently implement the driving-related functions of the vehicle, so that when a user request is received during the OTA upgrade of the vehicle, the following operations are performed on the components in the second set of components: continue the upgrade, stop the upgrade, or roll back.

17. The method according to any one of claims 14 to 16, characterized in that, The first configuration information is also used to indicate that the object of the OTA upgrade includes a third component set, each component in the third component set is used to implement non-driving related functions of the vehicle, so that when a user request is received during the OTA upgrade of the vehicle, the upgrade of the third component set is stopped.

18. The method according to claim 14, characterized in that, The first configuration information is also used to indicate that the object of the OTA upgrade includes a fourth component set, the fourth component set includes components for independently implementing the relevant functions of the vehicle, and each component in the fourth component set includes multiple partitions, each of which is used to store a set of firmware, so that when a user request is received during the OTA upgrade of the vehicle, the upgrade of the fourth component set is stopped, and each component in the fourth component set runs based on un-flashed firmware or firmware that has completed the OTA upgrade.

19. An OTA upgrade method, characterized in that, The method includes: Send first configuration information to the vehicle, the first configuration information being used to indicate that the object of the OTA upgrade includes a first set of components, and each component in the first set of components is used to collaboratively implement the vehicle's driving-related functions; Send third configuration information to the vehicle, the third configuration information being used to indicate that the storage architecture of each component in the first component set includes a first partition and a second partition, so that when the vehicle is undergoing an OTA upgrade and a user request is received, if the firmware versions stored in the second partition of each component are consistent, the upgrade of the first component set is stopped, and each component in the first component set operates based on the firmware stored in the second area.

20. A device for OTA (Over-The-Air) upgrades, characterized in that, The device includes at least one processor coupled to at least one memory, the at least one processor being configured to execute a computer program or instructions stored in the at least one memory to cause the device to perform the method as described in any one of claims 1 to 12.

21. A device for OTA (Over-The-Air) upgrades, characterized in that, The device includes at least one processor coupled to at least one memory, the at least one processor being configured to execute a computer program or instructions stored in the at least one memory to cause the device to perform the method as described in any one of claims 13 to 19.

22. A vehicle, characterized in that, Includes the apparatus as described in claim 20.

23. A server, characterized in that, Includes the apparatus as described in claim 21.

24. A system for OTA upgrades, characterized in that, include: A vehicle equipped with a first control device, the first control device being configured to perform the method as described in any one of claims 1 to 12; An OTA server, the OTA server being equipped with a second control device, the second control device being used to perform the method as described in any one of claims 13 to 19.

25. A chip, characterized in that, The chip includes circuitry for performing the method as described in any one of claims 1 to 12, or the method as described in any one of claims 13 to 19.

26. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as claimed in any one of claims 1 to 12, or to implement the method as claimed in any one of claims 13 to 19.

27. A computer program product, characterized in that, It includes instructions that, when executed by a processor, cause the method as described in any one of claims 1 to 12 to be performed, or cause the method as described in any one of claims 13 to 19 to be performed.

Images