Vehicle OTA upgrade methods and systems

Abstract

This application discloses a vehicle OTA upgrade method and system. The method includes obtaining the controller upgrade attributes and upgrade software package of the vehicle to be upgraded; wherein the controller upgrade attributes include dual-zone attributes and charge / discharge related attributes; determining an upgrade strategy based on the charge / discharge status of the vehicle to be upgraded and the controller upgrade attributes; and performing the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade software package. This method can solve the problems of low efficiency and time delays caused by the mutual exclusion between OTA upgrades and the vehicle's charge / discharge functions.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, specifically to a vehicle OTA upgrade method and system. Background Technology

[0002] In the current development of vehicle intelligence, in-vehicle wireless upgrade technology has become a key means to improve user experience and vehicle performance. However, the OTA upgrade process is mutually exclusive with the vehicle's charging and discharging functions, forming a strict serial execution mechanism. Specifically, when the system detects that the vehicle is in a charging or discharging state, it will forcibly stop the energy transfer process before starting the software update. While this design ensures the basic reliability of the system, it seriously affects the user experience. This puts users in a dilemma when they urgently need to replenish their range: either give up charging or delay the upgrade, severely restricting the functional synergy of intelligent connected vehicles and the continuous improvement of the user experience. Summary of the Invention

[0003] In view of the above problems, this application provides a vehicle OTA upgrade method and system, which can solve the problems of low efficiency and time delay caused by the mutual exclusion between OTA upgrade and vehicle charging and discharging functions.

[0004] Firstly, this application provides a vehicle OTA upgrade method, applied to the central domain controller of a vehicle OTA upgrade system, comprising: Obtain the controller upgrade attributes and upgrade package of the vehicle to be upgraded; wherein, the controller upgrade attributes include dual-zone attributes and charge / discharge related attributes; The upgrade strategy is determined based on the charging and discharging status of the vehicle to be upgraded and the upgrade attributes of the controller; Perform the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade package.

[0005] In the aforementioned technical solution, this method can acquire controller upgrade attributes and upgrade software packages, including dual-zone attributes and charge / discharge related attributes, ensuring the targeted nature of the upgrade strategy. The dual-zone attributes clearly define whether the controller supports an architecture where the operating zone and upgrade zone operate independently, thus providing the core hardware prerequisite for parallel execution of charge / discharge and OTA upgrades. The charge / discharge related attributes accurately determine whether the controller to be upgraded directly participates in the vehicle's charge / discharge process control, thereby accurately judging whether the upgrade operation will affect the safety of the charge / discharge function. Based on this, this method allows the formulation of upgrade strategies to no longer rely on a single charge / discharge state, but rather achieves accurate judgment based on the controller's hardware capabilities and functional correlations. Furthermore, dynamically formulating upgrade strategies by combining the vehicle's real-time charge / discharge state and upgrade attributes enables parallel charging / discharge and upgrades; and executing upgrade operations according to the strategy enables flexible coordination between charging / discharge and OTA upgrades, thereby ensuring upgrade reliability.

[0006] In some implementations, obtaining the controller upgrade attributes and upgrade package of the vehicle to be upgraded includes: After receiving the upgrade notification from the OTA server, a communication connection is established with the cloud server; The vehicle asset information of the vehicle to be upgraded is reported to the cloud server; Receive controller upgrade attributes and upgrade software packages sent by the cloud server.

[0007] In the above technical solution, the method can trigger a communication connection with the cloud after receiving an upgrade notification, ensuring real-time linkage between the vehicle and the cloud; it can also provide accurate data information for the cloud to customize and adapt upgrade attributes by timely reporting vehicle asset information; thus, it can accurately receive controller upgrade attributes and upgrade software packages issued by the cloud.

[0008] In some implementations, determining the upgrade strategy based on the charging / discharging state of the vehicle to be upgraded and the controller upgrade attributes includes: If the vehicle to be upgraded is detected to be in a charging / discharging state, and the upgrade involves charging / discharging related controllers, a list of target controllers including charging / discharging related controllers is determined based on the controller upgrade attributes. If, based on the controller upgrade attributes, each controller in the target controller list supports a dual-partition architecture, the upgrade strategy is determined to be a preset charge-discharge parallel upgrade strategy.

[0009] In the above technical solution, the method can accurately locate the target controller related to charging and discharging, and determine the upgrade scenarios that can be executed in parallel with charging and discharging by judging the support of the dual-partition architecture, thereby determining the upgrade strategy that satisfies the parallel operation of charging and discharging and upgrade.

[0010] In some embodiments, the method further includes: If the vehicle to be upgraded is detected to be in a charging / discharging state, and the upgrade does not involve charging / discharging related controllers, the upgrade strategy is determined to be the preset charging / discharging parallel upgrade strategy.

[0011] In the above technical solution, the method can simultaneously promote OTA upgrades that do not involve the charging and discharging controllers without interrupting the vehicle charging and discharging process.

[0012] In some embodiments, the method further includes: If, based on the controller upgrade attributes, it is determined that there are controllers in the target controller list that do not support dual-partition architecture, a message prohibiting parallel upgrades will be output. Upon receiving an upgrade instruction from the user based on the "prohibit parallel upgrade" prompt, an upgrade strategy is determined according to the upgrade instruction.

[0013] In the above technical solution, the method can accurately identify scenarios that cannot be upgraded in parallel by detecting the dual-partition architecture support of the target controller and promptly prompt the user, ensuring that the user is aware of the conflict risks between upgrading and charging / discharging; at the same time, it gives the upgrade decision-making power to the user, so that the user can choose the upgrade time according to their own battery life needs and the urgency of the upgrade, thereby further optimizing the user experience.

[0014] In some embodiments, the method further includes: If the upgrade instruction is an instruction to stop charging and discharging and perform an upgrade, the upgrade strategy includes executing a preset standard OTA upgrade process under the condition of stopping charging and discharging; If the upgrade instruction is to continue charging and discharging and postpone the upgrade, then the upgrade strategy includes continuing charging and discharging and delaying the OTA upgrade process.

[0015] In the above technical solution, the method can ensure the standardization and reliability of the upgrade through the standard OTA upgrade process when the user chooses to stop charging and discharging for the upgrade; it can also delay the upgrade process to ensure that the battery life is not affected when the user chooses to continue charging and discharging.

[0016] In some implementations, determining the upgrade strategy based on the charging / discharging state of the vehicle to be upgraded and the controller upgrade attributes includes: If the vehicle to be upgraded is not in a charging or discharging state, the upgrade strategy is determined to be the preset standard OTA upgrade process.

[0017] In the above technical solution, the method can directly adopt the standard OTA upgrade process when the vehicle is not in a charging or discharging state, without the need for additional coordination of the conflict between charging / discharging and upgrading.

[0018] In some implementations, performing the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade package includes: Under the condition that the upgrade strategy is a parallel charge and discharge upgrade strategy, the background software flashing operation is performed according to the parallel charge and discharge upgrade strategy while keeping the charge and discharge process uninterrupted.

[0019] In the above technical solution, the method can complete the upgrade through background flashing without interruption of charging and discharging, thereby realizing parallel charging and discharging and OTA upgrade.

[0020] In some embodiments, after performing the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade package, the method further includes: After the OTA parallel upgrade operation is completed, the upgrade results will be reported to the OTA server and the cloud server.

[0021] In the above technical solution, the method can provide timely feedback on the completion status of OTA parallel upgrade, ensuring that the cloud server and OTA server are in sync with the upgrade results, and providing reliable data support for subsequent upgrade task scheduling, fault diagnosis and function optimization.

[0022] Secondly, this application provides a vehicle OTA upgrade method, applied to a cloud server of the vehicle OTA upgrade system described in the first aspect, comprising: Based on this OTA upgrade task, obtain controller attribute information and upgrade software package; Based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information, generate controller upgrade attributes; The OTA server sends the controller upgrade attributes and the upgrade package to the central domain controller of the vehicle to be upgraded, so that the central domain controller can perform the corresponding OTA upgrade operation according to the charging and discharging status of the vehicle to be upgraded, the controller upgrade attributes, and the upgrade package.

[0023] In the aforementioned technical solution, this method can accurately capture the core basic data required for OTA upgrades and acquire complete upgrade program resources, thereby avoiding upgrade failures and compatibility issues that may result from missing information or incomplete software packages. Furthermore, this method can combine vehicle battery capacity, charging / discharging power, hardware configuration, and other asset information, along with the upgrade characteristics of the controller, to customize exclusive upgrade rules for the vehicle, thus improving the flexibility and relevance of upgrade strategy formulation. Finally, this method can also construct an efficient data transmission link for end-to-cloud collaboration, ensuring that customized upgrade attributes and complete software packages are accurately and securely transmitted to the vehicle, enabling the central domain controller to obtain all the information required for upgrade decisions in real time, and ensuring more reliable coordinated scheduling of upgrade tasks and charging / discharging functions.

[0024] In some implementations, obtaining controller attribute information and upgrade software packages based on the current OTA upgrade task includes: Obtain the task information for this OTA upgrade; The controller list, upgrade software package, and vehicles to be upgraded are determined based on the task information. Configure key attribute fields for each controller in the controller list to obtain controller attribute information; The controller attribute information includes charging and discharging process information for each controller and information on the dual-partition architecture supported by each controller.

[0025] In the above technical solution, the method can clearly identify the scope of controllers that need to be upgraded, the corresponding complete upgrade software package, and the vehicles to be upgraded through task information, avoiding confusion of upgrade objects or mismatch of resources. At the same time, it can specifically configure the key attribute fields of each controller to obtain information related to the charging and discharging process and the support of the dual-partition architecture, so that the controller attribute information is more suitable for application scenarios of charging and discharging and upgrading coordination, thereby further reducing the risk of upgrade and charging and discharging conflicts caused by ambiguous attribute information.

[0026] In some implementations, after obtaining the controller attribute information and upgrade package based on the current OTA upgrade task, the method further includes: The controller attribute information is synchronized to the OTA server so that the OTA server sends an upgrade notification to the central domain controller of the vehicle to be upgraded. Receive vehicle asset information of the vehicle to be upgraded from the central domain controller.

[0027] In the above technical solution, the method can synchronize controller attribute information to the OTA server and trigger upgrade notification, so that the vehicle central domain controller can know the core characteristics of the upgrade in advance, so as to prepare for the subsequent upgrade and avoid problems such as process blockage caused by temporary scheduling. At the same time, obtaining real-time vehicle asset information can ensure that the vehicle data held in the cloud is true and accurate, solve the problem of lag or deviation in preset information, and thus effectively improve the continuity and accuracy of end-cloud collaboration.

[0028] In some implementations, generating controller upgrade attributes based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information includes: Based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information, determine the controller to be upgraded and the controller upgrade attribute of the controller to be upgraded; The controller upgrade attributes include the dual-zone attributes of the controller to be upgraded and the charge / discharge related attributes of the controller to be upgraded.

[0029] In the above technical solution, the method can accurately screen out the controller that needs to be upgraded, and at the same time determine the dual-zone attributes and charging and discharging related attributes, thereby generating customized upgrade attributes that fit the actual asset characteristics of the vehicle.

[0030] Thirdly, this application provides a vehicle OTA upgrade system, including a cloud server, an OTA server, and a central domain controller for the vehicle to be upgraded, wherein... The cloud server is used to obtain controller attribute information and upgrade software package based on this OTA upgrade task; The cloud server is also used to generate controller upgrade attributes based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information; The cloud server is also used to send the controller upgrade attributes and the upgrade package to the central domain controller via the OTA server; The central domain controller is also used to determine an upgrade strategy based on the charging and discharging status of the vehicle to be upgraded and the controller upgrade attributes. The central domain controller is also used to perform corresponding OTA upgrade operations according to the upgrade policy and the upgrade software package.

[0031] In the aforementioned technical solution, the system integrates controller attribute information (such as model and upgrade dependencies) with vehicle asset information (such as battery capacity and charging / discharging power) through a cloud server. This generates controller upgrade attributes adapted to different scenarios. The upgrade attributes and software packages are then distributed via an OTA server, achieving precise matching between upgrade tasks and vehicle characteristics, providing data support for subsequent flexible decision-making. Simultaneously, the system can monitor the vehicle's charging and discharging status (such as charging / discharging power and remaining time) in real time through a central domain controller and dynamically formulate upgrade strategies based on the cloud-distributed upgrade attributes. (Tasks supporting on-the-go upgrades can be executed in parallel with charging; tasks requiring off-the-go upgrades can be implemented in a tiered manner based on charging progress), thus resolving the issue of "charging / discharging and upgrades being mutually exclusive." Furthermore, for the entire system, the closed-loop link of end-cloud collaboration completely solves the inefficiency problem caused by traditional serial execution, allowing users to replenish range without abandoning upgrades. It also adapts to the upgrade needs of different controllers and scenarios, effectively improving the functional synergy of intelligent connected vehicles and optimizing the user experience.

[0032] Fourthly, this application provides an electronic device including a memory and a processor, the memory storing a computer program, and the processor running the computer program to cause the electronic device to perform the vehicle OTA upgrade method described in any one of the first aspects.

[0033] Fifthly, this application provides a readable storage medium storing a computer program, which, when executed by a processor, performs the vehicle OTA upgrade method described in any one of the first aspects.

[0034] Sixthly, this application provides a computer program product, which includes a computer program that, when executed by a processor, performs the vehicle OTA upgrade method described in any one of the first aspects.

[0035] The beneficial effects of this application are as follows: it breaks the limitation of the traditional OTA upgrade and vehicle charging / discharging functions being mutually exclusive, enabling the upgrade operation to be completed simultaneously during vehicle charging / discharging. This eliminates the need for users to choose between supplementing range and software upgrades, and significantly saves time and costs. Furthermore, by flexibly adapting the upgrade mode according to controller characteristics and vehicle status, it ensures the stability and reliability of the upgrade process while avoiding impact on normal vehicle charging / discharging, thereby significantly improving the functional synergy and overall user experience of intelligent connected vehicles. Attached Figure Description

[0036] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0037] Figure 1 This is a flowchart illustrating the vehicle OTA upgrade method in some embodiments of this application; Figure 2 This is a schematic diagram of the framework of a vehicle OTA upgrade system in some embodiments of this application; Figure 3 This is a flowchart illustrating the vehicle OTA upgrade method in some embodiments of this application; Figure 4 This is a schematic flowchart illustrating an example of a vehicle OTA upgrade method in some embodiments of this application; Figure 5 This is a schematic flowchart illustrating another vehicle OTA upgrade method in some embodiments of this application; Figure 6 This is a schematic diagram of the structure of an electronic device in some embodiments of this application. Detailed Implementation

[0038] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0039] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0040] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more (including two), similarly, "multiple sets" refers to two or more sets (including two sets), and "multiple pieces" refers to two or more pieces (including two pieces) unless otherwise explicitly defined.

[0041] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0042] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0043] In the current vehicle electronic and electrical architecture, over-the-air (OTA) updates and vehicle charging / discharging functions are processed serially, but as mutually exclusive events, they cannot run in parallel. In existing applications, when the vehicle is charging or discharging, if an OTA update request is received, the vehicle control unit will suspend the charging / discharging process and resume it only after the update is complete. If the vehicle is undergoing an OTA update, the system will also prevent the charging / discharging process from starting, thus mitigating potential risks.

[0044] However, while this mutual exclusion mechanism between OTA upgrades and charging / discharging functions can ensure a certain level of safety and reliability, it significantly reduces user convenience and overall experience. For example, if a user encounters an emergency OTA upgrade while charging in a public place, they may be forced to interrupt charging, causing time delays and disrupting their plans. At the same time, frequent function interruptions may also affect the life cycle of the power battery and energy management efficiency.

[0045] To address the aforementioned technical issues, this application provides a vehicle OTA upgrade method that enables coordinated parallel operation of OTA upgrades and charging / discharging functions while ensuring system security. In this method, the server needs to pre-determine the charging / discharging participation status of each controller in the vehicle and the support status of the dual-partition architecture. It then performs a correlation comparison based on the asset information actively reported by each controller in the vehicle, thereby generating a feasibility determination result for the parallel operation of the OTA upgrade task and the charging / discharging process. Subsequently, based on this determination result, it is determined whether to run the OTA upgrade task and the charging / discharging process synchronously, or to execute the corresponding single core function according to a preset priority strategy.

[0046] Based on this, the method can determine whether OTA upgrades can be implemented simultaneously with the charging and discharging process based on the actual situation, thereby achieving the synchronous execution of non-critical controller upgrades and the charging and discharging process without increasing the overall vehicle hardware cost, thereby reducing the total execution time of the task and optimizing the user experience.

[0047] like Figure 1 As shown, some embodiments of this application provide a vehicle OTA upgrade method, which is applied to the central domain controller of a vehicle OTA upgrade system, including: S101. Obtain the controller upgrade attributes and upgrade package of the vehicle to be upgraded; S102. Determine the upgrade strategy based on the charging and discharging status of the vehicle to be upgraded and the upgrade attributes of the controller; S103. Perform the corresponding OTA upgrade operation according to the upgrade strategy and upgrade package.

[0048] In some embodiments, the method can automatically trigger a charging operation to meet the upgrade requirements when the preconditions for OTA upgrade are not met (such as insufficient power), thereby further improving the comprehensiveness of the upgrade process and enhancing the availability of the system under low power conditions.

[0049] In some embodiments, the central domain controller dynamically determines whether the upgrade and charging / discharging can be performed in parallel based on controller asset information (such as controller model, version, current status, etc.), dual-partition support, and whether the controller being upgraded involves charging / discharging related functions. Specifically, this includes the following scenarios: (1) If the vehicle has not been charged, proceed with the normal upgrade process. (2) If this upgrade does not include the charge and discharge related controller and the OTA main process controller, then regardless of whether the charge and discharge related controller and the OTA main process controller have dual partitions or not, the charge and discharge and OTA flashing can be performed in parallel. (3) If this upgrade includes a charge / discharge related controller and an OTA main process controller, and the charge / discharge related controller and the OTA main process controller do not have dual partitions, then charge / discharge and OTA flashing cannot be performed in parallel.

[0050] In the above embodiments, the charge and discharge related controller refers to a controller whose core control functions are directly related to the vehicle's charge and discharge process, and whose operating status directly affects the charge and discharge safety and energy flow path.

[0051] In some embodiments, obtaining the controller upgrade attributes and upgrade package of the vehicle to be upgraded includes: After receiving the upgrade notification from the OTA server, a communication connection is established with the cloud server; The vehicle asset information of the vehicle to be upgraded is reported to the cloud server; Receive controller upgrade attributes and upgrade software packages sent by the cloud server.

[0052] In the above implementation, the vehicle asset information is collected and reported by the vehicle-side central domain controller, and the vehicle asset information includes at least the vehicle identifier, controller identifier, and controller real-time capability information. The controller identifier is used to uniquely identify each controller in the vehicle and its software baseline. It typically includes the controller's hardware model, hardware version number, software identifier, and the currently activated software version number. This information is crucial for the cloud server to match the controller with a pre-stored controller design attribute library, thereby determining whether it participates in the charging and discharging process.

[0053] The controller's real-time capability information reflects the specific hardware and functional capabilities of each controller at the current operating moment. Specifically, it includes a dual-partition actual support identifier, a status bit determined by the controller's self-test or firmware configuration, indicating whether the controller instance currently possesses and has enabled a dual-partition storage architecture. This dual-partition actual support identifier is a crucial hardware condition for determining whether OTA and parallel charging / discharging are possible. Furthermore, the controller's real-time capability information may also include other capability parameters that may affect the upgrade strategy, such as controller memory capacity, controller communication bandwidth, and controller security level.

[0054] In the above embodiments, the vehicle asset information may also include a real-time vehicle status summary related to upgrade conditions and safety, such as the vehicle's high-voltage power-on status, current fault code status, network communication quality indicators, etc. This application embodiment does not limit this.

[0055] In the above implementation, the controller attribute information includes key attribute fields for each controller. These key attribute fields include at least information related to the charging / discharging process and information supporting a dual-partition architecture. Specifically, the cloud server obtains the task information for this OTA upgrade task, then determines the list of controllers requiring upgrade, the upgrade software package, and the vehicles to be upgraded based on the task information. Finally, it configures key attribute fields for each controller in the controller list to obtain the controller attribute information.

[0056] In some embodiments, the "dual-zone actual support identifier" in the vehicle asset information is a true report of the vehicle's actual physical hardware capabilities, while the controller attribute information updated and maintained by the OTA server is a theoretical attribute field updated and maintained based on design specifications. In practical applications, the cloud server also needs to compare and verify the vehicle asset information and controller attribute information to ensure the correctness of the real-time hardware status and controller attribute information for each specific vehicle. This ensures accurate controller upgrade attributes are sent to the vehicle, guaranteeing the security and reliability of the upgrade.

[0057] In some embodiments, the cloud server can generate controller upgrade attributes based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information. Specifically, the cloud server compares and verifies the vehicle asset information reported by the vehicle with the controller attribute information: First, it matches the corresponding entry in the controller attribute information with the controller identifier in the vehicle asset information to verify the controller identity and version compatibility; then, it compares the real-time capability information of each controller in the vehicle asset information (such as the actual support status of dual partitions) with the dual partition architecture support information of the corresponding controller in the controller attribute information. If the actual support status meets or exceeds the requirements in the attribute information, it is determined that the controller has the conditions for parallel upgrade; finally, the cloud server integrates the above verification results and configures corresponding key attribute fields for each controller in the controller list. These key attribute fields include at least the charging and discharging process-related attributes of the controller and the verified dual partition availability status, thereby obtaining the controller upgrade attributes.

[0058] In the above implementation, the controller upgrade attribute refers to the key attribute fields configured by the cloud server for each controller in the controller list to be upgraded, based on the requirements of this OTA upgrade task. These key attribute fields include at least a charge / discharge correlation identifier, a dual-zone support confirmation status, and a decision flag indicating whether charge / discharge operations are permitted. The dual-zone support confirmation status is determined by comparing the controller's real-time capabilities in the vehicle asset information with the theoretical attribute fields in the controller attribute information. The decision flag indicating whether charge / discharge operations are permitted is determined by the cloud based on a comprehensive assessment of the charge / discharge correlation identifier and the dual-zone support confirmation status.

[0059] In the above embodiments, this method can acquire controller upgrade attributes and upgrade software packages, including dual-zone attributes and charge / discharge related attributes, ensuring the targeted nature of the upgrade strategy. The dual-zone attributes clearly define whether the controller supports an architecture where the running zone and upgrade zone operate independently, thus providing the core hardware prerequisite for parallel execution of charge / discharge and OTA upgrades. The charge / discharge related attributes accurately determine whether the controller to be upgraded directly participates in the vehicle's charge / discharge process control, thereby accurately judging whether the upgrade operation will affect the safety of the charge / discharge function. Based on this, this method allows the formulation of upgrade strategies to no longer rely on a single charge / discharge state, but rather achieves accurate judgment based on the controller's hardware capabilities and functional correlations. Furthermore, dynamically formulating upgrade strategies by combining the vehicle's real-time charge / discharge state and upgrade attributes can also achieve parallel charging / discharging and upgrades; and executing upgrade operations according to the strategy can achieve flexible coordination between charging / discharging and OTA upgrades, thereby ensuring upgrade reliability.

[0060] In some embodiments, an upgrade strategy is determined based on the charging / discharging state of the vehicle to be upgraded and the controller upgrade attributes, including: If the vehicle to be upgraded is detected to be in a charging or discharging state, and the upgrade involves charging and discharging related controllers, a list of target controllers including charging and discharging related controllers is determined based on the controller upgrade attributes. Assuming that each controller in the target controller list supports a dual-partition architecture, the upgrade strategy is determined to be the preset parallel charge and discharge upgrade strategy.

[0061] In some embodiments, charge / discharge related controllers refer to controllers whose core control functions are directly related to the vehicle's charging and discharging process, and whose operating status directly affects charging and discharging safety and energy flow path. When these controllers are upgraded with software, changes to their firmware or algorithms may directly alter the charging and discharging logic, parameters, or protection thresholds. Therefore, when performing upgrades while the vehicle is charging or discharging, special upgrade strategies must be employed to ensure absolute safety and maintain the vehicle's basic charging and discharging functions.

[0062] In some embodiments, the target controller list refers to a list of controllers that include charge-discharge related controllers, determined based on the controller upgrade attributes, among all controllers to be upgraded when the vehicle is in a charging / discharging state and the upgrade involves charge-discharging related controllers.

[0063] In some embodiments, the parallel charging and discharging upgrade strategy refers to a pre-defined upgrade scheme that can simultaneously perform OTA upgrade operations while keeping the vehicle charging and discharging process uninterrupted.

[0064] In the above embodiments, the method can accurately locate the target controller related to charging and discharging, determine the upgrade scenarios that can be executed in parallel with charging and discharging by judging the support of the dual-partition architecture, and thus determine the upgrade strategy that satisfies the parallel operation of charging and discharging and upgrade.

[0065] In some embodiments, the method further includes: If the vehicle to be upgraded is detected to be in a charging or discharging state, and the upgrade does not involve charging or discharging related controllers, the upgrade strategy is determined to be the preset charging and discharging parallel upgrade strategy.

[0066] In the above embodiments, the method can simultaneously advance OTA upgrades that do not involve charge / discharge related controllers without interrupting the vehicle's charging and discharging process.

[0067] In some embodiments, the method further includes: If, based on the controller upgrade attributes, it is determined that there are controllers in the target controller list that do not support dual-partition architecture, output a message prohibiting parallel upgrades. Upon receiving an upgrade command from the user based on the message indicating that parallel upgrades are prohibited, the upgrade strategy is determined according to the upgrade command.

[0068] In the above embodiments, the method can accurately identify scenarios that cannot be upgraded in parallel by detecting the dual-partition architecture support of the target controller and promptly prompt the user, ensuring that the user is aware of the conflict risks between upgrading and charging / discharging; at the same time, it gives the upgrade decision-making power to the user, so that the user can choose the upgrade time according to their own battery life needs and the urgency of the upgrade, thereby further optimizing the user experience.

[0069] In some embodiments, the method further includes: If the upgrade command is to stop charging and discharging and then perform the upgrade, the upgrade strategy includes executing a preset standard OTA upgrade process under the condition that charging and discharging are stopped. If the upgrade instruction is to continue charging and discharging and postpone the upgrade, then the upgrade strategy includes continuing charging and discharging and delaying the OTA upgrade process.

[0070] In the above embodiments, the method can ensure the standardization and reliability of the upgrade through the standard OTA upgrade process when the user chooses to stop charging and discharging for the upgrade; it can also delay the upgrade process to ensure that the battery life is not affected when the user chooses to continue charging and discharging.

[0071] In some embodiments, an upgrade strategy is determined based on the charging / discharging state of the vehicle to be upgraded and the controller upgrade attributes, including: If the vehicle to be upgraded is not in a charging or discharging state, the upgrade strategy is determined to be the preset standard OTA upgrade process.

[0072] In the above embodiments, the method can directly adopt the standard OTA upgrade process when the vehicle is not in a charging or discharging state, without the need for additional coordination of the conflict between charging / discharging and upgrading.

[0073] In some embodiments, performing a corresponding OTA upgrade operation based on the upgrade policy and upgrade package includes: Under the condition that the upgrade strategy is a parallel charge and discharge upgrade strategy, the background software flashing operation is performed while keeping the charge and discharge process uninterrupted.

[0074] In the above embodiments, the method can complete the upgrade through background flashing without interruption of charging and discharging, thereby realizing parallel charging and discharging and OTA upgrade.

[0075] In some embodiments, after performing the corresponding OTA upgrade operation according to the upgrade policy and upgrade package, the method further includes: After the OTA parallel upgrade operation is completed, the upgrade results will be reported to the OTA server and the cloud server.

[0076] In some embodiments, the upgrade result refers to the final status data after the OTA upgrade operation is executed, including key information such as upgrade success, upgrade failure, and upgrade progress.

[0077] In the above embodiments, the method can provide timely feedback on the completion status of OTA parallel upgrades, ensuring that the cloud server and OTA server are in sync with the upgrade results.

[0078] In the above implementation, after receiving the upgrade result, the OTA server and / or cloud server can also update the corresponding vehicle information of the vehicle to be upgraded based on the upgrade result, which can ensure the consistency and real-time accuracy of the data of the vehicle to be upgraded, the OTA server and the cloud server, and provide reliable data support for subsequent upgrade task scheduling, fault diagnosis and function optimization.

[0079] like Figure 2 As shown, some embodiments of this application provide a vehicle OTA upgrade system, including a cloud server, an OTA server, and a central domain controller for the vehicle to be upgraded, wherein... The cloud server is used to obtain controller attribute information and upgrade software packages based on this OTA upgrade task. The cloud server is also used to generate controller upgrade attributes based on the vehicle asset information and controller attribute information of the vehicle to be upgraded; The cloud server is also used to distribute controller upgrade attributes and upgrade packages to the central domain controller via the OTA server; The central domain controller is also used to determine the upgrade strategy based on the charging and discharging status of the vehicle to be upgraded and the controller upgrade attributes; The central domain controller is also used to perform corresponding OTA upgrade operations based on upgrade policies and upgrade packages.

[0080] In some embodiments, a cloud server refers to a core server located in the cloud that coordinates OTA upgrade-related data processing, information generation, and command issuance.

[0081] In some embodiments, an OTA server refers to a server specifically responsible for relaying and transmitting OTA upgrade-related data between the cloud and the vehicle.

[0082] In some embodiments, the central domain controller of the vehicle to be upgraded refers to a control device installed on the vehicle to be upgraded, which determines the upgrade strategy based on the vehicle's charging and discharging status and the controller's upgrade attributes, and performs the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade software package.

[0083] In some embodiments, controller attribute information refers to characteristic information related to the controller to be upgraded, which is key data obtained by the cloud server based on this OTA upgrade task. Specifically, controller attribute information includes at least the charging and discharging process information of each controller and the dual-partition architecture support information of each controller.

[0084] In some embodiments, the upgrade package refers to a program package used for OTA upgrades of the vehicle controller, which is obtained by the cloud server and distributed through the OTA server.

[0085] In some embodiments, in the above implementation, the vehicle asset information is collected and reported by the vehicle-side central domain controller, and the vehicle asset information includes at least the vehicle identifier, controller identifier, and controller real-time capability information. The controller identifier is used to uniquely identify each controller in the vehicle and its software baseline. It typically includes the controller's hardware model, hardware version number, software identifier, and the currently activated software version number. This information is crucial for the cloud server to match the controller with a pre-stored controller design attribute library, thereby determining whether it participates in the charging and discharging process.

[0086] The controller's real-time capability information reflects the specific hardware and functional capabilities of each controller at the current operating moment. Specifically, it includes a dual-partition actual support identifier, a status bit determined by the controller's self-test or firmware configuration, indicating whether the controller instance currently possesses and has enabled a dual-partition storage architecture. This dual-partition actual support identifier is a crucial hardware condition for determining whether OTA and parallel charging / discharging are possible. Furthermore, the controller's real-time capability information may also include other capability parameters that may affect the upgrade strategy, such as controller memory capacity, controller communication bandwidth, and controller security level.

[0087] In the above embodiments, the vehicle asset information may also include a real-time vehicle status summary related to upgrade conditions and safety, such as the vehicle's high-voltage power-on status, current fault code status, network communication quality indicators, etc. This application embodiment does not limit this.

[0088] In the above implementation, the controller attribute information includes key attribute fields for each controller. These key attribute fields include at least information related to the charging / discharging process and information supporting a dual-partition architecture. Specifically, the cloud server obtains the task information for this OTA upgrade task, then determines the list of controllers requiring upgrade, the upgrade software package, and the vehicles to be upgraded based on the task information. Finally, it configures key attribute fields for each controller in the controller list to obtain the controller attribute information.

[0089] In some embodiments, the "dual-zone actual support identifier" in the vehicle asset information is a true report of the vehicle's actual physical hardware capabilities, while the controller attribute information updated and maintained by the OTA server is a theoretical attribute field updated and maintained based on design specifications. In practical applications, the cloud server also needs to compare and verify the vehicle asset information and controller attribute information to ensure the correctness of the real-time hardware status and controller attribute information for each specific vehicle. This ensures accurate controller upgrade attributes are sent to the vehicle, guaranteeing the security and reliability of the upgrade.

[0090] In some embodiments, controller upgrade attributes refer to the specific criteria for determining whether the controller is compatible with this upgrade, such as whether the controller to be upgraded supports a dual-partition architecture or whether it can operate simultaneously with charging and discharging.

[0091] In some embodiments, the charging / discharging status refers to the current charging or discharging status of the vehicle to be upgraded, which is an important reference for the central domain controller to determine the upgrade strategy.

[0092] In some embodiments, the upgrade strategy refers to a strategy formulated by the central domain controller based on the vehicle's charging and discharging status and the controller's upgrade attributes, used to guide the execution of OTA upgrade operations.

[0093] In the above embodiments, this method integrates controller attribute information (such as model and upgrade dependencies) and vehicle asset information (such as battery capacity and charging / discharging power) through a cloud server to generate controller upgrade attributes adapted to different scenarios. Then, the OTA server distributes the controller upgrade attributes and upgrade software packages, achieving precise matching between upgrade tasks and vehicle characteristics, providing data support for subsequent flexible decision-making. Simultaneously, the system can also perceive the vehicle's charging / discharging status (such as charging / discharging power and remaining time) in real time through a central domain controller and dynamically formulate upgrade strategies based on the upgrade attributes distributed from the cloud (tasks supporting on-charge upgrades can be executed in parallel with charging, while tasks requiring off-charge upgrades can be implemented using a tiered approach based on charging progress), thus resolving the problem of "charging / discharging and upgrades being mutually exclusive." Furthermore, for the entire system, this closed-loop link of end-cloud collaboration completely solves the inefficiency problem caused by traditional serial execution, allowing users to replenish range without abandoning upgrades. It also adapts to the upgrade needs of different controllers and scenarios, effectively improving the functional synergy of intelligent connected vehicles and optimizing the user experience.

[0094] like Figure 3 As shown, some embodiments of this application provide a vehicle OTA upgrade method, which is applied to a cloud server of a vehicle OTA upgrade system, including: S201. Obtain controller attribute information and upgrade software package based on this OTA upgrade task; S202. Generate controller upgrade attributes based on the vehicle asset information and controller attribute information of the vehicle to be upgraded; S203. The controller upgrade attributes and upgrade software package are sent to the central domain controller of the vehicle to be upgraded via the OTA server, so that the central domain controller can perform the corresponding OTA upgrade operation according to the charging and discharging status of the vehicle to be upgraded, the controller upgrade attributes and upgrade software package.

[0095] In some embodiments, the cloud server can generate controller upgrade attributes based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information. Specifically, the cloud server compares and verifies the vehicle asset information reported by the vehicle with the controller attribute information: First, it matches the corresponding entry in the controller attribute information with the controller identifier in the vehicle asset information to verify the controller identity and version compatibility; then, it compares the real-time capability information of each controller in the vehicle asset information (such as the actual support status of dual partitions) with the dual partition architecture support information of the corresponding controller in the controller attribute information. If the actual support status meets or exceeds the requirements in the attribute information, it is determined that the controller has the conditions for parallel upgrade; finally, the cloud server integrates the above verification results and configures corresponding key attribute fields for each controller in the controller list. These key attribute fields include at least the charging and discharging process-related attributes of the controller and the verified dual partition availability status, thereby obtaining the controller upgrade attributes.

[0096] In the above embodiments, this method can accurately capture the core basic data required for OTA upgrades and obtain complete upgrade program resources, thereby avoiding problems such as upgrade failures and compatibility anomalies that may be caused by missing information or incomplete software packages. Furthermore, this method can combine asset information such as vehicle battery capacity, charging and discharging power, and hardware configuration, as well as the upgrade characteristics of the controller, to customize exclusive upgrade rules for the vehicle, thereby improving the flexibility and targeting of upgrade strategy formulation. Finally, this method can also build an efficient data transmission link for end-to-cloud collaboration, ensuring that customized upgrade attributes and complete software packages are accurately and securely transmitted to the vehicle, enabling the central domain controller to obtain all the information required for upgrade decisions in real time, and ensuring more reliable coordinated scheduling of upgrade tasks and charging / discharging functions.

[0097] In some embodiments, the controller attribute information and upgrade package are obtained based on this OTA upgrade task, including: Obtain the task information for this OTA upgrade; Determine the list of controllers, upgrade packages, and vehicles to be upgraded based on the task information; Configure key attribute fields for each controller in the controller list to obtain controller attribute information; The controller attribute information includes information related to the charging and discharging process of each controller and information on the dual-partition architecture supported by each controller.

[0098] In some embodiments, task information refers to the core descriptive data of this OTA upgrade task, which may include key information such as the purpose of the upgrade, the scope of the upgrade, and the time requirements.

[0099] In some embodiments, the controller list refers to a collection of all controllers that need to participate in this OTA upgrade, as determined based on the upgrade task information.

[0100] In some embodiments, the key attribute field refers to the specific record item configured for each controller in the controller list to generate controller attribute information (such as whether it participates in charging and discharging, whether it supports dual partitions, etc.).

[0101] In some embodiments, charging and discharging process related information refers to a sub-item of controller attribute information, which records data such as whether the controller participates in vehicle charging and discharging control and the specific stages it participates in.

[0102] In some embodiments, the dual-partition architecture information refers to a sub-item of the controller attribute information, which is used to identify whether the controller has a dual-partition design.

[0103] In some embodiments, the controller can employ a dual-partition design, where one partition is in operation and the other is used for backup and writing new software. During the upgrade process, the system can complete the writing and verification of new software without interrupting current functionality, and achieve a smooth switchover by restarting the controller.

[0104] In the above embodiments, the method can clearly identify the scope of controllers to be upgraded, the corresponding complete upgrade package, and the vehicles to be upgraded through task information, avoiding confusion of upgrade objects or mismatch of resources. At the same time, it can specifically configure the key attribute fields of each controller to obtain information related to the charging and discharging process and the support of the dual-partition architecture, so that the controller attribute information is more suitable for application scenarios of charging and discharging and upgrading coordination, thereby further reducing the risk of upgrade and charging and discharging conflicts caused by ambiguous attribute information.

[0105] In some embodiments, after obtaining controller attribute information and upgrade software packages based on this OTA upgrade task, the method further includes: Synchronize controller attribute information to the OTA server so that the OTA server can send an upgrade notification to the central domain controller of the vehicle to be upgraded. Receive vehicle asset information of the vehicle to be upgraded from the central domain controller.

[0106] In some embodiments, an upgrade notification refers to a message sent by the OTA server to the central domain controller of the vehicle to be upgraded after receiving the controller attribute information synchronized from the cloud, informing it that an OTA upgrade is about to be performed.

[0107] In the above embodiments, the method can synchronize controller attribute information to the OTA server and trigger upgrade notifications, allowing the vehicle central domain controller to know the core characteristics of the upgrade in advance, so as to prepare for the subsequent upgrade and avoid problems such as process delays caused by temporary scheduling. At the same time, obtaining real-time vehicle asset information can ensure that the vehicle data held in the cloud is true and accurate, solve the problem of lag or deviation that may exist in the preset information, and thus effectively improve the continuity and accuracy of end-cloud collaboration.

[0108] In some embodiments, controller upgrade attributes are generated based on the vehicle asset information and controller attribute information of the vehicle to be upgraded, including: Based on the vehicle asset information and controller attribute information of the vehicle to be upgraded, determine the controller to be upgraded and the controller upgrade attributes of the controller to be upgraded; The controller upgrade attributes include the dual-zone attributes of the controller to be upgraded and the charge / discharge related attributes of the controller to be upgraded.

[0109] In some embodiments, the dual-partition attribute refers to a sub-item of the controller upgrade attribute, which records the specific parameters of the controller's dual-partition design (such as partition function allocation, switching logic, etc.).

[0110] In some embodiments, charge / discharge related attributes refer to sub-items of controller upgrade attributes, which record the adaptation parameters of the controller and charge / discharge coordination (such as whether the upgrade affects the charge / discharge function, coordination priority, etc.).

[0111] In the above embodiments, the method can accurately screen out the controllers that need to be upgraded, and at the same time determine the dual-zone attributes and charging and discharging related attributes, thereby generating customized upgrade attributes that fit the actual asset characteristics of the vehicle.

[0112] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below. In some embodiments, Figure 4 A schematic diagram illustrating an example of a vehicle OTA upgrade method is shown, which includes: S301, Preprocessing and attribute configuration of the vehicle OTA management platform.

[0113] In some embodiments, the method adds a dedicated field attribute in the vehicle OTA management platform to identify whether the controller participates in the charging and discharging process and whether it belongs to the OTA main process controller, and adds a field attribute to identify whether the controller supports a dual-partition architecture.

[0114] In some embodiments, the platform may configure the target controller to be upgraded and its related software packages as needed for this OTA task.

[0115] S302, Matching of vehicle-side asset information reporting and upgrade strategies.

[0116] In some embodiments, the method can obtain hardware and software asset information reported by each controller on the vehicle, compare it with the list of controllers to be upgraded, determine the upgradeable objects and their attributes, and generate upgrade strategy metadata including dual-partition attributes and charge / discharge related attributes.

[0117] S303, software packages and policy information are issued jointly.

[0118] In some embodiments, the method can send the software package to be upgraded along with a burning configuration file containing dual partition identifiers and charge / discharge association attributes to the vehicle-side central domain controller (OTA master control unit).

[0119] In some embodiments, the central domain controller acts as the decision-making core, used to determine whether to allow the charging and discharging state to be maintained during the OTA process based on the received metadata.

[0120] S304, the parallel decision-making mechanism of the central domain controller.

[0121] In some embodiments, the central domain controller determines whether to enter the upgrade process and whether to maintain charging and discharging based on the upgrade controller's attribute fields and the current vehicle status (such as whether it is currently charging or discharging). Specific scenarios include the following: (1) If the vehicle is not in a charging or discharging state, then follow the normal flashing process; (2) If the vehicle is in a charging and discharging state, and the upgrade involves the charging and discharging related controller or the OTA main process controller, and the charging and discharging related controller or the OTA main process controller has implemented a dual-partition architecture, then the system allows the OTA upgrade and the charging and discharging process to be executed in parallel. (3) If the vehicle is in a charging or discharging state, and this upgrade does not involve any charging or discharging related controllers or OTA main process controllers, the system allows the OTA upgrade and the charging or discharging process to be executed in parallel; (4) If the vehicle is in a charging or discharging state, and this upgrade involves the charging and discharging related controller or the OTA main process controller, and the charging and discharging related controller or the OTA main process controller is not configured with dual partitions, then the system prohibits OTA and charging and discharging from running in parallel, and one side must be terminated before it can continue.

[0122] S305, OTA upgrade execution and dynamic priority management.

[0123] In some embodiments, during the upgrade startup phase, the central domain controller verifies whether the task includes charge / discharge related controllers or OTA main process controllers and their dual-partition support. Based on this, it dynamically decides whether to exit the charge / discharge process and reasonably sets the function priority to achieve the optimal balance between system resources and user experience.

[0124] In the above embodiments, the method can achieve intelligent coordination of OTA upgrades and energy management functions without affecting the cost of the vehicle under the current vehicle electronic and electrical architecture (i.e., the charging and discharging related controller or OTA main process controller is not dual-zoned), thereby significantly improving the efficiency of system upgrades and the convenience of user vehicle use.

[0125] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions in this application will be clearly and completely described below. In some embodiments, Figure 5 A schematic diagram illustrating an example of another vehicle OTA upgrade method is shown, which includes: S401, Modular attribute management of the OTA management platform.

[0126] In some embodiments, the method adds a dedicated attribute field to the vehicle OTA management platform to identify whether a specific controller participates in the charging and discharging process and the OTA master control judgment logic, and maintains its dual-partition support status. The platform synchronizes such attribute metadata to the OTA server, providing a data foundation for subsequent upgrade decisions.

[0127] S402, upgrade task configuration and vehicle-side asset matching.

[0128] In some embodiments, the method configures a list of controllers to be upgraded on the platform side, and the OTA server compares and verifies the controller asset information (including hardware version, software version and functional attributes) reported by the vehicle side to generate a targeted upgrade strategy and software distribution list.

[0129] S403, policies, and software packages are jointly distributed.

[0130] In some embodiments, the OTA server can send the upgrade software package and its corresponding attribute metadata (including whether it is related to charging and discharging, whether it participates in OTA judgment, and whether it has dual partitions) to the central domain controller (i.e., the OTA master control unit).

[0131] S404, Parallelism Decision-Making and Process Control of the Central Domain Controller.

[0132] In some embodiments, the central domain controller determines, based on the received controller attributes, whether all the charge / discharge related controllers or the OTA main process controller involved in this upgrade support a dual-partition architecture. If this condition is met, the system can enter the OTA upgrade process even if the vehicle is in a charging / discharging state, without interrupting the energy replenishment process, thereby achieving reliable parallel operation of OTA and charging / discharging.

[0133] S405, non-intrusive upgrade execution.

[0134] In some embodiments, during the upgrade process, the central domain controller coordinates each controller to perform background writing and verification according to a predetermined dual-partition mechanism, without needing to exit the charging and discharging state throughout the process. This ensures functional safety while maximizing user experience and energy efficiency.

[0135] In the above embodiments, the method can significantly reduce the mandatory requirements on hardware resources under the current vehicle electronic and electrical architecture (i.e., all charging and discharging related controllers or OTA main process controllers must be dual-partitioned), through software-defined and attribute-driven decision-making mechanisms, and provides a feasible technical path for promoting OTA and charging and discharging parallel functions in cost-sensitive models.

[0136] In some embodiments, within the vehicle's electronic and electrical architecture involved in this method, achieving parallel OTA upgrades and charging / discharging requires the coordinated operation of multiple key controllers. These key controllers are listed in the table below:

[0137] In some embodiments, the aforementioned controllers collaborate closely via networks such as CAN (Controller Area Network), CAN FD, or Ethernet to form a complex system that supports intelligent charge and discharge management and secure, reliable OTA upgrades. CAN FD (Controller Area Network Flexible Data-Rate) is an upgraded protocol of the traditional CAN bus, supporting higher data transmission rates (up to 5 Mbps) and larger data frames (64 bytes), and is widely used in automotive electronics and industrial control.

[0138] like Figure 6As shown, this application provides an electronic device 500, which includes a processor 501 and a memory 502. The processor 501 and the memory 502 are interconnected and communicate with each other through a communication bus 503 and / or other forms of connection mechanism (not shown). The memory 502 stores a computer program that can be executed by the processor 501. When the computing device is running, the processor 501 executes the computer program to perform the method in any of the aforementioned optional implementations.

[0139] This application provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the method in any of the aforementioned optional implementations.

[0140] The computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0141] This application provides a computer program product, which includes a computer program that, when run by a processor, executes the method in any of the aforementioned optional implementations.

[0142] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. These modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application. In particular, as long as there is no conflict, the various technical features mentioned in the embodiments can be combined in any way. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

Claims

1. A vehicle OTA upgrade method, characterized in that, The central domain controller used in vehicle OTA upgrade systems includes: Obtain the controller upgrade attributes and upgrade package of the vehicle to be upgraded; wherein, the controller upgrade attributes include dual-zone attributes and charge / discharge related attributes; The upgrade strategy is determined based on the charging and discharging status of the vehicle to be upgraded and the upgrade attributes of the controller; Perform the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade package.

2. The vehicle OTA upgrade method according to claim 1, characterized in that, The process of obtaining the controller upgrade attributes and upgrade package of the vehicle to be upgraded includes: After receiving the upgrade notification from the OTA server, a communication connection is established with the cloud server; The vehicle asset information of the vehicle to be upgraded is reported to the cloud server; Receive controller upgrade attributes and upgrade software packages sent by the cloud server.

3. The vehicle OTA upgrade method according to claim 1, characterized in that, The step of determining the upgrade strategy based on the charging / discharging state of the vehicle to be upgraded and the upgrade attributes of the controller includes: If the vehicle to be upgraded is detected to be in a charging / discharging state, and the upgrade involves charging / discharging related controllers, a list of target controllers including charging / discharging related controllers is determined based on the controller upgrade attributes. If, based on the controller upgrade attributes, each controller in the target controller list supports a dual-partition architecture, the upgrade strategy is determined to be a preset charge-discharge parallel upgrade strategy.

4. The vehicle OTA upgrade method according to claim 3, characterized in that, The method further includes: If the vehicle to be upgraded is detected to be in a charging / discharging state, and the upgrade does not involve charging / discharging related controllers, the upgrade strategy is determined to be the preset charging / discharging parallel upgrade strategy.

5. The vehicle OTA upgrade method according to claim 3, characterized in that, The method further includes: If, based on the controller upgrade attributes, it is determined that there are controllers in the target controller list that do not support dual-partition architecture, a message prohibiting parallel upgrades will be output. Upon receiving an upgrade instruction from the user based on the "prohibit parallel upgrade" prompt, an upgrade strategy is determined according to the upgrade instruction.

6. The vehicle OTA upgrade method according to claim 5, characterized in that, The method further includes: If the upgrade instruction is an instruction to stop charging and discharging and perform an upgrade, the upgrade strategy includes executing a preset standard OTA upgrade process under the condition of stopping charging and discharging; If the upgrade instruction is to continue charging and discharging and postpone the upgrade, then the upgrade strategy includes continuing charging and discharging and delaying the OTA upgrade process.

7. The vehicle OTA upgrade method according to claim 1, characterized in that, The step of determining the upgrade strategy based on the charging / discharging state of the vehicle to be upgraded and the upgrade attributes of the controller includes: If the vehicle to be upgraded is not in a charging or discharging state, the upgrade strategy is determined to be the preset standard OTA upgrade process.

8. The vehicle OTA upgrade method according to claim 4 or 5, characterized in that, The step of performing the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade package includes: Under the condition that the upgrade strategy is a parallel charge and discharge upgrade strategy, the background software flashing operation is performed according to the parallel charge and discharge upgrade strategy while keeping the charge and discharge process uninterrupted.

9. The vehicle OTA upgrade method according to claim 1, characterized in that, After performing the corresponding OTA upgrade operation according to the upgrade strategy and the upgrade package, the method further includes: After the OTA upgrade operation is completed, the upgrade result will be reported to the OTA server and the cloud server.

10. A vehicle OTA upgrade system, characterized in that, This includes cloud servers, OTA servers, and the central domain controller for the vehicle to be upgraded. The cloud server is used to obtain controller attribute information and upgrade software package based on this OTA upgrade task; The cloud server is also used to generate controller upgrade attributes based on the vehicle asset information of the vehicle to be upgraded and the controller attribute information; The cloud server is also used to send the controller upgrade attributes and the upgrade package to the central domain controller via the OTA server; The central domain controller is also used to determine an upgrade strategy based on the charging and discharging status of the vehicle to be upgraded and the controller upgrade attributes. The central domain controller is also used to perform corresponding OTA upgrade operations according to the upgrade policy and the upgrade software package.

Images