Method for cooperative upgrading of multiple controllers in a vehicle, vehicle and cooperative upgrading system

Abstract

The application discloses a kind of collaborative upgrading method of multiple controllers in vehicle, vehicle and collaborative upgrading system, comprising: obtaining the collaborative upgrading package and collaborative upgrading information provided by OTA cloud management platform;Collaborative upgrading information includes the upgrade priority of each controller, initial scheduling interval and the initial upgrade rate of each controller;After obtaining the collaborative upgrading package and collaborative upgrading information, the collaborative upgrading package is decrypted and checked;After the collaborative upgrading package is checked, according to the collaborative upgrading package, each controller is controlled to start upgrade in turn according to upgrade priority with initial scheduling interval and initial upgrade rate;In the process of controlling each controller upgrade, the load of vehicle and the residual capacity of power battery in vehicle are continuously obtained;According to load and residual capacity, current scheduling interval and current upgrade rate are obtained;According to the collaborative upgrading package, each controller is controlled to upgrade according to upgrade priority with current scheduling interval and current upgrade rate.

Description

Technical Field

[0001] This invention relates to the field of vehicles, and more particularly to a method for collaborative upgrading of multiple controllers in a vehicle, a vehicle, and a collaborative upgrading system. Background Technology

[0002] With the improvement of the intelligence level of pure electric mining trucks, OTA (over the air) technology has become the core means of controller software iteration and parameter optimization. It eliminates the need for on-site disassembly of the controller and can significantly reduce the operation and maintenance costs of the mining area.

[0003] However, existing OTA upgrade technologies for pure electric mining trucks mostly adopt an independent upgrade mode for each controller. This means that multiple controllers in the vehicle independently receive upgrade commands and execute upgrade operations without a unified timing plan, which easily leads to problems such as command conflicts, asynchronous upgrade progress, and disordered upgrade timing. For example, during the BMS (Battery Management System) upgrade, the ECU (Vehicle Controller) issues a power adjustment command, causing abnormal battery charging and discharging control; when the TCU (Transmission Control Unit) upgrade is interrupted, the ECU still issues a gear shifting command, causing the transmission to jam, which seriously affects the safety of mining truck operations.

[0004] Furthermore, during the OTA upgrade process of pure electric mining trucks, the upgrade scheduling of multiple controllers is often based solely on preset fixed parameters (such as fixed time intervals and fixed upgrade rates). This makes it impossible to adjust the upgrade rhythm according to the dynamic operating conditions of the vehicle in real time. As a result, under extreme operating conditions, upgrade commands and safety commands compete for bus resources, which can easily lead to command conflicts, abnormal controller resets, and even driving safety risks. Summary of the Invention

[0005] The present invention provides a method, vehicle and system for collaborative upgrading of multiple controllers in a vehicle, to solve or at least alleviate some or all of the above problems.

[0006] According to one aspect of the present invention, a method for collaborative upgrade of multiple controllers in a vehicle is provided, comprising: Obtain the collaborative upgrade package and collaborative upgrade information provided by the OTA cloud management platform; the collaborative upgrade information includes the upgrade priority, initial scheduling interval and initial upgrade rate of each controller; After obtaining the collaborative upgrade package and the collaborative upgrade information, the collaborative upgrade package is decrypted and verified. After the collaborative upgrade package passes verification, each controller is controlled to start the upgrade sequentially according to the upgrade priority, the initial scheduling interval, and the initial upgrade rate, based on the collaborative upgrade package. During the process of upgrading each of the controllers, the vehicle's load and the remaining power of the vehicle's power battery are continuously acquired. The current scheduling interval and current upgrade rate are obtained based on the load and the remaining power. According to the collaborative upgrade package, each controller continues to upgrade according to the upgrade priority, the current scheduling interval, and the current upgrade rate.

[0007] Optionally, obtaining the current scheduling interval and current upgrade rate based on the load and the remaining power includes: When the load is greater than or equal to the preset load and the remaining power is greater than the preset power, the current scheduling interval is determined as the first scheduling interval, and the current upgrade rate is determined as the first upgrade rate; Alternatively, when the load is less than the preset load and the remaining power is less than or equal to the preset power, the current scheduling interval is determined to be the first scheduling interval, and the current upgrade rate is determined to be the first upgrade rate. Wherein, the first scheduling interval is greater than the initial scheduling interval, and the first upgrade rate is less than the initial upgrade rate.

[0008] Optionally, obtaining the current scheduling interval and current upgrade rate based on the load and the remaining power also includes: When the load is greater than or equal to the preset load and the remaining power is less than or equal to the preset power, the current scheduling interval is determined to be the second scheduling interval, and the current upgrade rate is determined to be the second upgrade rate; the second scheduling interval is greater than the first scheduling interval, and the second upgrade rate is less than the first upgrade rate; When the load is less than the preset load and the remaining power is greater than the preset power, the current scheduling interval is determined to be the third scheduling interval, and the current upgrade rate is determined to be the third upgrade rate; the third scheduling interval is less than or equal to the initial scheduling interval, and the third upgrade rate is greater than or equal to the initial upgrade rate.

[0009] Optionally, before obtaining the current scheduling interval and current upgrade rate based on the load and the remaining power, the process includes: Obtain the load and remaining battery power of other vehicles located within the preset area; Based on the load and the remaining power, the current scheduling interval and the current upgrade rate are obtained, including: Obtain a first number of vehicles whose load capacity is greater than or equal to a preset load capacity and whose remaining battery power is greater than a preset battery power; when the first number is greater than a first preset number, determine the current scheduling interval as a first scheduling interval and determine the current upgrade rate as a first upgrade rate; Alternatively, obtain a second number of vehicles whose load is less than the preset load and whose remaining battery power is less than or equal to the preset battery power; when the second number is greater than the first preset number, determine the current scheduling interval as the first scheduling interval, and determine the current upgrade rate as the first upgrade rate; Wherein, the first scheduling interval is greater than the initial scheduling interval, and the first upgrade rate is less than the initial upgrade rate.

[0010] Optionally, obtaining the current scheduling interval and current upgrade rate based on the load and the remaining power also includes: Obtain a third number of vehicles whose load is greater than or equal to the preset load and whose remaining battery power is less than or equal to the preset battery power; and obtain a fourth number of vehicles whose load is less than the preset load and whose remaining battery power is greater than the preset battery power. When the third quantity is greater than the first preset quantity, the current scheduling interval is determined to be the second scheduling interval, and the current upgrade rate is determined to be the second upgrade rate; the second scheduling interval is greater than the first scheduling interval, and the second upgrade rate is less than the first upgrade rate; When the fourth quantity is greater than the second preset quantity, the current scheduling interval is determined to be the third scheduling interval, and the current upgrade rate is determined to be the third upgrade rate; The third scheduling interval is less than or equal to the initial scheduling interval, and the third upgrade rate is greater than or equal to the initial upgrade rate.

[0011] Optionally, the collaborative upgrade package includes a boot sector upgrade package, an application sector upgrade package, and a data sector upgrade package for each controller; Controlling each controller according to the collaborative upgrade package to continue upgrading at the current scheduling interval and the current upgrade rate according to the upgrade priority includes: According to the upgrade priority, the boot sector of each controller continues to upgrade according to its respective boot sector upgrade package at the current scheduling interval and the current upgrade rate; After the preset time for the upgrade of the guidance area of ​​each controller is completed, the application area of ​​each controller is controlled to upgrade according to the upgrade priority, based on its own application area upgrade package, at the current scheduling interval and the current upgrade rate. After the application areas of each controller have completed the upgrade within a preset time, the data areas of each controller are upgraded according to the upgrade priority, based on their respective data area upgrade packages, at the current scheduling interval and the current upgrade rate.

[0012] Optionally, the process of upgrading each controller may also include: Continuously obtain the upgrade progress of each controller; If the difference in the upgrade progress of any two controllers exceeds a first preset value, the controller with the faster upgrade progress will pause the upgrade. Until the difference in the upgrade progress of any two controllers is less than the second preset value, return to the step of continuously obtaining the vehicle's load and the remaining power of the power battery during the upgrade process of each controller; Wherein, the first preset value is greater than the second preset value.

[0013] Optionally, the process of upgrading each controller may also include: Continuously acquire upgrade anomaly information; the upgrade anomaly information includes: network interruption time, power battery temperature, and remaining power battery charge; When a minor vehicle anomaly is determined based on the upgrade anomaly information, each controller is controlled to pause the upgrade and cache the upgrade progress until the minor vehicle anomaly is resolved, and each controller is controlled to continue the upgrade at the current upgrade progress. When a serious abnormality is determined in the vehicle based on the upgrade anomaly information, each controller is controlled to stop the upgrade and automatically roll back to its respective stable version before the upgrade.

[0014] Optionally, the collaborative upgrade method for multiple controllers in the vehicle further includes: After the upgrade of each controller is completed, the self-verification result of each controller is obtained; When the self-verification results of each controller are all successful upgrades, an upgrade success message is sent to the OTA cloud management platform; If the self-verification result of at least one of the controllers indicates that the upgrade has failed, the controller that failed the upgrade shall be rolled back to the stable version before the upgrade.

[0015] According to another aspect of the present invention, a vehicle is also provided, comprising: an on-board T-BOX terminal, a power battery, and a plurality of controllers; The vehicle-mounted T-BOX terminal is used to execute the aforementioned collaborative upgrade method for multiple controllers in a vehicle.

[0016] According to another aspect of the present invention, a multi-vehicle collaborative upgrade system is also provided, comprising: an OTA cloud management platform and a plurality of the aforementioned vehicles located in a preset area; The OTA cloud management platform is used to generate collaborative upgrade packages and collaborative upgrade information for each vehicle based on batch upgrade instructions, and send each collaborative upgrade package and collaborative upgrade information to the T-BOX terminal in the corresponding vehicle; The collaborative upgrade information includes the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller.

[0017] The collaborative upgrade method for multiple controllers in a vehicle provided by this invention obtains a collaborative upgrade package issued by the OTA cloud management platform, along with collaborative upgrade information including the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller. After decryption and verification, the upgrade of each controller is initiated sequentially according to priority and initial scheduling interval, enabling multiple controllers to enter the upgrade state in a very short time, forming a quasi-synchronous upgrade mode. This eliminates the risk of instruction conflict windows and mixed version operation caused by independent upgrades. During the upgrade process, the vehicle's load and the remaining power of the power battery are collected in real time. Based on these two parameters, the current scheduling interval and current upgrade rate are dynamically obtained. Then, the upgrade of each controller is controlled to continue according to the upgrade priority, current scheduling interval, and current upgrade rate. This allows the upgrade pace to be proactively slowed down under extreme conditions of heavy load or low power, freeing up bus resources for safety-critical instructions, and the upgrade speed to be accelerated and downtime reduced under light load and sufficient power conditions. Ultimately, this achieves a comprehensive technical effect of prioritizing safety, balancing efficiency, and protecting power supply.

[0018] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart of a collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention; Figure 2 This is a flowchart of another collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention; Figure 3 This is a flowchart of another collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention; Figure 4 This is a flowchart of another collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0023] This invention provides a collaborative upgrade method for multiple controllers in a vehicle, which can solve the problems of instruction conflicts, asynchronous upgrade progress, and disordered upgrade sequence that easily occur when upgrading multiple controllers. It can also solve the problems of instruction conflicts, abnormal controller resets, and even driving safety risks caused by fixed upgrade rhythm. This collaborative upgrade method for multiple controllers in a vehicle can be executed by the vehicle's on-board T-BOX terminal.

[0024] Figure 1 This is a flowchart of a collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention, such as... Figure 1 As shown, the collaborative upgrade method for multiple controllers in this vehicle includes: S110. Obtain the collaborative upgrade package and collaborative upgrade information provided by the OTA cloud management platform.

[0025] The collaborative upgrade information includes the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller.

[0026] Specifically, the vehicle-mounted T-BOX terminal can establish an encrypted connection with the OTA cloud management platform via a 4G or 5G communication module. The vehicle-mounted T-BOX terminal actively reports the vehicle's VIN (Vehicle Identification Number), current software version (version numbers of the ECU, BMS, and TCU), and vehicle status (e.g., whether it is in operation). Based on the mine's operation and maintenance plan, the OTA cloud management platform issues the generated collaborative upgrade package and collaborative upgrade information. For example, upon receiving an upgrade command, it can issue the generated collaborative upgrade package and collaborative upgrade information based on the upgrade command. The upgrade command can be for a single vehicle, in which case the OTA cloud management platform sends the collaborative upgrade package and collaborative upgrade information to only that vehicle. Alternatively, the upgrade command can be a batch upgrade command for multiple vehicles or all vehicles in a preset area that have a communication connection with the OTA cloud management platform. In this case, the OTA cloud management platform sends the collaborative upgrade package and collaborative upgrade information to multiple vehicles in batches based on the batch upgrade command. This embodiment of the invention does not specifically limit this approach.

[0027] The collaborative upgrade package can be an encrypted and digitally signed compressed file containing the firmware or configuration files of all controllers involved in the upgrade. For example, unless otherwise specified, this embodiment of the invention will illustrate the collaborative upgrade of the ECU, BMS, and TCU in a vehicle. Each controller's upgrade package can be further divided into a boot sector upgrade package, an application sector upgrade package, and a data sector upgrade package based on storage areas.

[0028] The collaborative upgrade information can be a metadata file in JSON format. JSON (JavaScript Object Notation, a lightweight key-value data exchange format) is used to structure and describe upgrade parameters, facilitating parsing and expansion by the vehicle-mounted T-BOX terminal. This metadata file can contain fields such as the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller. The upgrade priority of each controller refers to the order in which they initiate the upgrade. For example, when upgrading the ECU, BMS, and TCU, the upgrade priority of these three controllers can be set to ECU > BMS > TCU. That is, the vehicle-mounted T-BOX terminal sends upgrade interaction commands indicating the same upgrade progress (or identical upgrade interaction commands) to the three controllers in the order of "ECU first, then BMS, and finally TCU." After sending the upgrade interaction command for this round to the controller with the lowest upgrade priority (i.e., TCU), it then sends the next upgrade interaction command indicating the next upgrade stage to each controller in order of upgrade priority.

[0029] The initial scheduling interval can be understood as the interval between the on-board T-BOX terminal sending upgrade interaction commands to two controllers with adjacent upgrade priorities during the initial upgrade phase. The initial scheduling interval is preferably set to a short time (e.g., milliseconds), which allows upgrade interaction commands to be sent to each controller sequentially within a short period, avoiding simultaneous sending of multiple commands to each controller and preventing communication line contention that could lead to momentary congestion. This ensures reliable transmission of each upgrade interaction command. Secondly, a millisecond-level scheduling interval can distribute the transient current at the start of the upgrade for each controller over time, significantly reducing peak current and preventing triggering of the on-board power supply overcurrent protection or voltage drop. Furthermore, compressing the initial scheduling interval to the millisecond level allows all three controllers to initiate the upgrade process within a short time. During the subsequent upgrade process, all three controllers remain in an "upgrading" state. Since the millisecond interval (e.g., 100ms) is much shorter than the upgrade time for a single controller (typically tens of seconds to minutes), the upgrade progress of each controller is minimally different, essentially constituting a synchronous (quasi-synchronous) upgrade. This avoids the long time window where "one has resumed communication while the other is still upgrading," achieving synchronous upgrades for multiple controllers and preventing command conflicts. For example, if the vehicle-mounted T-BOX terminal sends an upgrade start command to the ECU, BMS, and TCU (one type of upgrade interaction command during the upgrade process) at the start of the upgrade, assuming an initial scheduling interval of 100ms, the vehicle-mounted T-BOX terminal sends the upgrade start command to the ECU, waits 100ms to send the upgrade start command to the BMS, and then waits another 100ms before sending the upgrade start command to the TCU. This allows all three controllers to initiate the upgrade within 200ms, which can be considered a quasi-synchronous upgrade. Because the ECU, BMS, and TCU are upgraded simultaneously, their communication functions are suspended or restricted according to a preset procedure. The ECU will not issue any adjustment commands during the BMS or TCU upgrade, thus avoiding command conflicts. In addition, since the three controllers complete their upgrades almost simultaneously (with similar upgrade times), the time when each controller resumes communication is also basically the same, eliminating the mixed version control phase of "old version ECU controlling new version BMS" or "new version ECU controlling old version TCU".

[0030] The initial upgrade rate refers to the rate at which the vehicle-mounted T-BOX terminal transmits upgrade package data to each controller during the initial upgrade phase. The initial upgrade rate can be different or the same for different controllers, depending on the performance and upgrade requirements of each controller. This embodiment of the invention does not impose specific limitations on this. For example, for ease of explanation, this embodiment of the invention uses the example of all controllers having the same initial upgrade rate. For instance, this embodiment of the invention can set the initial upgrade rate of each controller to 500kbps to balance upgrade speed and bus stability while implementing relatively simple scheduling logic.

[0031] S120. After obtaining the collaborative upgrade package and collaborative upgrade information, the collaborative upgrade package is decrypted and verified.

[0032] Specifically, when generating the collaborative upgrade package, the OTA cloud management platform can use an RSA private key (an asymmetric encryption algorithm with a key length of 2048 bits) to encrypt the collaborative upgrade package. After obtaining the collaborative upgrade package and collaborative upgrade information, the vehicle-mounted T-BOX terminal uses the public key corresponding to the RSA private key stored in the security chip (or uses the private key for decryption according to the negotiation mechanism, depending on the encryption direction setting) to decrypt the encrypted collaborative upgrade package, restoring it to the original plaintext data packet (containing the partition upgrade packages of each controller and the version number of each partition upgrade package, etc.). This can prevent the upgrade package from being stolen or tampered with during wireless transmission and protect trade secrets such as firmware code and calibration parameters.

[0033] In addition, when generating the collaborative upgrade package, the OTA cloud management platform simultaneously calculates the hash value (e.g., SHA-256) of the entire plaintext data packet, signs the hash value using an RSA private key, and appends it to the collaborative upgrade package. After decrypting the collaborative upgrade package, the vehicle-mounted T-BOX terminal recalculates the hash value of the plaintext data packet using the same hash algorithm (SHA-256) and compares it with the original hash value attached to the signature of the OTA cloud management platform. If they match, it indicates that the data packet is complete and has not been tampered with, and the collaborative upgrade package passes verification; if they do not match, the verification fails. If the collaborative upgrade package passes verification, the vehicle-mounted T-BOX terminal can transmit the decrypted and verified collaborative upgrade package to the internal collaborative control module (a software functional unit within the vehicle-mounted T-BOX terminal responsible for upgrade scheduling) to prepare for upgrade scheduling. If the collaborative upgrade package verification fails, the vehicle T-BOX terminal immediately reports the illegal upgrade package information to the OTA cloud management platform (with the reason for failure, such as "hash mismatch" or "decryption error"), refuses to execute the upgrade, and does not proceed to step S130. This ensures that illegal or damaged data is not written to the ECU, BMS, or TCU, thus protecting the safety of the controllers in the vehicle. After receiving the illegal upgrade package information, the OTA cloud management platform will reissue the collaborative upgrade package.

[0034] S130. After the collaborative upgrade package passes verification, each controller is controlled to start the upgrade sequentially according to the upgrade priority, initial scheduling interval and initial upgrade rate based on the collaborative upgrade package.

[0035] Specifically, after the collaborative upgrade package passes verification, the vehicle-mounted T-BOX terminal enters the upgrade scheduling master state. Strictly following the upgrade priority in the collaborative upgrade information, it sequentially sends upgrade interaction commands and corresponding upgrade packages to each controller at the initial scheduling interval. This allows each controller to perform its own upgrade process (flashing the boot sector, application sector, and data sector) at its initial upgrade rate. Since each controller enters upgrade mode within an extremely short time (milliseconds), it can be considered as a parallel upgrade (or quasi-synchronous upgrade), effectively reducing the time required for multiple controller upgrades.

[0036] S140. During the upgrade process of each controller, continuously obtain the vehicle's load and the remaining power of the vehicle's power battery.

[0037] Specifically, after each controller initiates the upgrade, the initial upgrade phase of each controller can be controlled according to the upgrade priority, initial scheduling interval, and initial upgrade rate. During this process, the vehicle's load and the remaining power of the power battery can be continuously acquired to monitor the vehicle status in real time, so as to dynamically adjust the subsequent upgrade rhythm.

[0038] The load capacity directly reflects the current operating load status of the mining truck. When the vehicle is under heavy load, its inertia is high and its power demand is high. If upgrade interaction commands are sent according to the initial scheduling interval and initial upgrade rate, a large number of data transmission commands, status query commands, and other upgrade interaction commands may compete with the vehicle's normal power adjustment messages and gear control messages for CAN bus bandwidth, leading to delays or loss of critical commands and posing significant safety hazards such as slippage and drive loss of control. The remaining battery power reflects the vehicle's power reserve capacity. When the remaining battery power is too low, the output voltage of the power battery drops, and the transient current generated during the upgrade process may trigger undervoltage protection, causing the upgrade to be interrupted or the controller to reset abnormally. At the same time, when the remaining battery power is too low, the vehicle itself is already in a state of energy shortage, and priority should be given to ensuring driving-related commands. When the remaining battery power is sufficient, the power supply is stable and can support a higher upgrade rate. Therefore, the subsequent upgrade rhythm can be adjusted by combining the vehicle's load capacity and the remaining battery power. The vehicle's load capacity can be obtained through a weighing sensor or suspension pressure sensor, in tons (t), and the remaining battery power (SOC, State of Charge) can be read through the BMS, in percentage (%).

[0039] S150: Obtain the current scheduling interval and current upgrade rate based on the load and remaining power.

[0040] Specifically, based on the above analysis of load and remaining battery power, under heavy load conditions, the current scheduling interval (i.e., the time interval for sending upgrade interaction commands to adjacent controllers) can be appropriately extended, and the current upgrade rate can be appropriately reduced to reduce the bus occupation of upgrade interaction commands and reserve sufficient communication resources for power control and safety-related commands. Under light load conditions, the vehicle has sufficient safety redundancy, and the current scheduling interval can be appropriately shortened and the current upgrade rate increased to improve upgrade efficiency while ensuring safety.

[0041] When the remaining charge of the power battery is too low, the current scheduling interval should be appropriately extended and the current upgrade rate reduced to minimize the impact on the power supply system. At the same time, the communication priority of upgrade interaction commands should be reduced to ensure that the vehicle's limited energy is used primarily for driving. When the remaining charge of the power battery is sufficient, more aggressive scheduling parameters (including scheduling interval and upgrade rate) can be adopted, which can appropriately shorten the current scheduling interval and increase the current upgrade rate to accelerate the upgrade process.

[0042] S160. Based on the collaborative upgrade package, control each controller to continue upgrading according to the upgrade priority at the current scheduling interval and the current upgrade rate.

[0043] Specifically, after obtaining the current scheduling interval and current upgrade rate based on the load and remaining power, the current scheduling interval and current upgrade rate can respectively cover the initial scheduling interval and initial upgrade rate, so that the upgrade process of subsequent controllers can continue to be executed based on the current scheduling interval and current upgrade rate. In this way, the upgrade rhythm can be dynamically adjusted. That is, under heavy load and / or low power conditions, the upgrade rhythm can be actively slowed down, the interval between sending upgrade interaction commands can be extended and the bus occupancy rate can be reduced, thereby freeing up sufficient communication resources for safety-critical commands such as power adjustment, gear control and battery protection, and avoiding delays or loss of safety commands due to upgrade commands crowding the bus. Under light load and high power safety conditions, the scheduling interval can be shortened and the upgrade rate can be increased, minimizing the downtime of mine car upgrades while ensuring safety. At the same time, this dynamic adjustment mechanism works in conjunction with fixed upgrade priorities and quasi-synchronous upgrade modes, which not only eliminates the command conflict window caused by severe misalignment of upgrade progress among controllers, but also realizes the self-adaptation of the upgrade process to the complex working conditions of the mining area, ultimately achieving a comprehensive technical effect of "safety first, efficiency in balance, and power supply protection".

[0044] The collaborative upgrade method for multiple controllers in a vehicle provided by this invention obtains a collaborative upgrade package issued by the OTA cloud management platform, along with collaborative upgrade information including the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller. After decryption and verification, the upgrade of each controller is initiated sequentially according to the priority order and initial scheduling interval, enabling multiple controllers to enter the upgrade state in a very short time, forming a quasi-synchronous upgrade mode. This eliminates the risk of instruction conflict windows and mixed version operation caused by independent upgrades. During the upgrade process, the vehicle's load and the remaining power of the power battery are collected in real time, and the current scheduling interval and current upgrade rate are dynamically obtained based on these two parameters. Then, the upgrade of each controller is controlled to continue according to the upgrade priority, current scheduling interval, and current upgrade rate. This allows the upgrade pace to be proactively slowed down under extreme conditions of heavy load or low power, freeing up bus resources for safety-critical instructions, and the upgrade speed to be accelerated and the upgrade time reduced under light load and sufficient power conditions. Ultimately, this achieves a comprehensive technical effect of prioritizing safety, balancing efficiency, and protecting power supply.

[0045] Optional, Figure 2 This is a flowchart of another collaborative upgrade method for multiple controllers in a vehicle provided in this application, such as... Figure 2 As shown, the collaborative upgrade method for multiple controllers in a vehicle includes: S211. Obtain the collaborative upgrade package and collaborative upgrade information provided by the OTA cloud management platform.

[0046] S212. After obtaining the collaborative upgrade package and collaborative upgrade information, the collaborative upgrade package is decrypted and verified.

[0047] S213. After the collaborative upgrade package passes verification, each controller is controlled to start the upgrade sequentially according to the upgrade priority, initial scheduling interval and initial upgrade rate based on the collaborative upgrade package.

[0048] S214. During the upgrade process of each controller, continuously obtain the vehicle's load and the remaining power of the vehicle's power battery.

[0049] S215. Determine whether the load is greater than or equal to the preset load and the remaining power is greater than the preset power, or whether the load is less than the preset load and the remaining power is less than or equal to the preset power; if yes, proceed to step S216; if no, proceed to step S217.

[0050] The preset load and preset battery level can be set according to design requirements. For example, the preset load can be 80% of the rated load, that is, assuming the vehicle's rated load is 60t, the preset load can be 48t; the preset battery level can be 60%, 70% or other values. This embodiment of the invention does not impose specific limitations on these values, and the design of this solution shall prevail.

[0051] S216. Determine the current scheduling interval as the first scheduling interval and the current upgrade rate as the first upgrade rate; execute step S220.

[0052] The first scheduling interval is greater than the initial scheduling interval, and the first upgrade rate is less than the initial upgrade rate.

[0053] Specifically, when the load is greater than or equal to the preset load and the remaining battery power is greater than the preset battery power, the vehicle can be determined to be in a heavily loaded, high-battery state. In this case, the scheduling interval can be appropriately extended and the upgrade rate slowed down. That is, the current scheduling interval can be determined to be a first scheduling interval greater than the initial scheduling interval, and the current upgrade rate can be determined to be a first upgrade rate less than the initial upgrade rate. This reduces the bus usage of upgrade interaction commands and leaves sufficient communication resources for power control and safety-related commands. For example, with an initial scheduling interval of 100ms and an initial upgrade rate of 500kbps, the first scheduling interval can be 150ms and the first upgrade rate can be 400kbps.

[0054] Additionally, when the load is less than the preset load and the remaining battery power is less than or equal to the preset battery power, the vehicle can be determined to be in a light-load, low-battery state. In this case, the dispatch interval can be appropriately extended and the upgrade rate slowed down to ensure that the vehicle's limited energy is prioritized for driving. At this point, the first dispatch interval and the first upgrade rate can also be used as the current dispatch interval and the current upgrade rate.

[0055] In short, when a vehicle's condition meets either heavy load or low battery, the first scheduling interval and the first upgrade rate are used as the current scheduling interval and upgrade rate, respectively. This allows for proactive slowing of the upgrade pace with appropriate safety strategies when a single adverse condition occurs. While ensuring that near-synchronous upgrades of multiple controllers remain effective, it achieves a balance between safety and upgrade efficiency. Once the vehicle recovers from the adverse condition, the scheduling parameters automatically return to normal upgrade settings.

[0056] S217. Determine whether the load is greater than or equal to the preset load and the remaining power is less than or equal to the preset power; if yes, proceed to step S218; if no, proceed to step S219.

[0057] S218. Determine the current scheduling interval as the second scheduling interval and the current upgrade rate as the second upgrade rate; execute step S220.

[0058] The second scheduling interval is greater than the first scheduling interval, and the second upgrade rate is less than the first upgrade rate.

[0059] Specifically, when the load is greater than or equal to the preset load and the remaining battery power is less than or equal to the preset battery power, the vehicle can be determined to be in a heavy-load, low-battery state. When heavy-load and low-battery conditions overlap, the vehicle faces the dual constraints of high safety risks and weak power supply capabilities. In this case, the scheduling interval can be further extended and the upgrade rate can be further reduced to further slow down the upgrade pace. That is, the current scheduling interval can be determined to be a second scheduling interval greater than the first scheduling interval, and the current upgrade rate can be determined to be a second upgrade rate less than the first upgrade rate. In this way, the longer scheduling interval provides a more ample bus transmission window for high-priority power adjustment and gear control commands under heavy-load conditions and frequent battery protection messages under low-battery conditions. The lower upgrade rate can significantly reduce the transient current impact when the controller erases and writes Flash, avoiding the triggering of battery undervoltage protection under low-battery conditions, which would lead to upgrade interruption or vehicle power failure. Therefore, under the dual dangers of heavy load and low power, the system proactively slows down the upgrade pace with the highest level of safety strategy. While ensuring that multiple controllers maintain a quasi-synchronous upgrade mode, it maximizes vehicle driving safety and power supply stability. Once the vehicle leaves the extreme conditions, it automatically resumes to more aggressive upgrade parameters. The second scheduling interval can be 200ms, and the second upgrade rate can be 300kbps.

[0060] S219. Determine that the load is less than the preset load and the remaining power is greater than the preset power, and determine that the current scheduling interval is the third scheduling interval, and determine that the current upgrade rate is the third upgrade rate.

[0061] Among them, the third scheduling interval is less than or equal to the initial scheduling interval, and the third upgrade rate is greater than or equal to the initial upgrade rate.

[0062] Specifically, when the load is less than the preset load and the remaining battery power is greater than the preset battery power, the vehicle can be determined to be in a light-load, high-battery state. In this state, the vehicle has sufficient safety redundancy and stable power supply. The impact of upgrade interaction commands on driving safety is minimized, and the transient current of erasing and writing Flash will not trigger undervoltage protection. Therefore, a more aggressive upgrade pace can be supported. At this time, the scheduling interval can be appropriately shortened and the upgrade rate can be increased, or the current scheduling interval can be kept consistent with the initial scheduling interval, and the third upgrade rate can be kept consistent with the initial upgrade rate. That is, the current scheduling interval can be determined to be a third scheduling interval less than or equal to the initial scheduling interval, and the current upgrade rate can be determined to be a third upgrade rate greater than or equal to the initial upgrade rate. By shortening the scheduling interval and increasing the upgrade rate, multiple controllers can complete the upgrade process faster without sacrificing safety. The start-up time difference between controllers is further compressed, and the quasi-synchronous characteristics are more significant. Thus, under optimal operating conditions, the most aggressive upgrade strategy can be used to minimize the downtime of mining trucks for upgrades, improve the efficiency of mine operation and maintenance, and automatically downgrade to more conservative upgrade scheduling parameters when the vehicle enters a heavy-load or low-battery state.

[0063] S220. Based on the collaborative upgrade package, control each controller to continue upgrading according to the upgrade priority at the current scheduling interval and the current upgrade rate.

[0064] For example, the collaborative upgrade package includes a boot sector upgrade package, an application sector upgrade package, and a data sector upgrade package for each controller. Based on the collaborative upgrade package, each controller continues to upgrade according to its upgrade priority at the current scheduling interval and upgrade rate. This includes: controlling the boot sector of each controller to continue upgrading according to its respective boot sector upgrade package at the current scheduling interval and upgrade rate according to the upgrade priority; after a preset time has elapsed since the boot sectors of all controllers have completed their upgrades, controlling the application sectors of each controller to upgrade according to their respective application sector upgrade packages at the current scheduling interval and upgrade rate according to the upgrade priority; and after a preset time has elapsed since the application sectors of all controllers have completed their upgrades, controlling the data sectors of each controller to upgrade according to their respective data sector upgrade packages at the current scheduling interval and upgrade rate according to the upgrade priority.

[0065] Specifically, the collaborative upgrade package includes upgrade packages for the boot sector, application sector, and data sector of each controller. When controlling the collaborative upgrade of each controller, the upgrade can be completed in three stages according to upgrade priority, current scheduling interval, and current upgrade rate. First, according to upgrade priority and with the current scheduling interval as the start interval, the boot sector of each controller is controlled to start the upgrade sequentially (each is flashed according to the boot sector upgrade package). After the boot sectors of all controllers have completed the upgrade and a preset time has elapsed, the application sectors of each controller are controlled to start the upgrade sequentially according to priority and the current scheduling interval. Finally, after the application sectors of all controllers have completed the upgrade and a preset time has elapsed, the data sectors of each controller are controlled to start the upgrade sequentially. By completely separating the upgrade process into three stages—boot zone, application zone, and data zone—and setting a preset waiting time between each stage, the system ensures that all controllers in the previous stage have completed their upgrades and are running stably before proceeding to the next stage. This avoids protocol incompatibility issues that may arise from cross-stage upgrades. At the same time, within each stage, the upgrades of each controller are initiated sequentially according to upgrade priority and the current scheduling interval. After initiation, each controller is written in parallel, maintaining the advantage of near-synchronous upgrades. This ensures both the rigor of the upgrade process's timing and the refined management of partitioned upgrades.

[0066] It is understandable that the process of each controller upgrading with initial parameters (the process of each controller upgrading according to the upgrade priority with initial scheduling interval and initial upgrade rate based on the collaborative upgrade package) is the same as the process of upgrading with current upgrade parameters described above, and will not be repeated here.

[0067] Optional, Figure 3 This is a flowchart of another collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention, such as... Figure 3 As shown, the collaborative upgrade method for multiple controllers in a vehicle includes: S311. Obtain the collaborative upgrade package and collaborative upgrade information provided by the OTA cloud management platform.

[0068] S312. After obtaining the collaborative upgrade package and collaborative upgrade information, the collaborative upgrade package is decrypted and verified.

[0069] S313. After the collaborative upgrade package passes verification, each controller is controlled to start the upgrade sequentially according to the upgrade priority, initial scheduling interval and initial upgrade rate based on the collaborative upgrade package.

[0070] S314. During the upgrade process of each controller, continuously obtain the vehicle's load and the remaining power of the vehicle's power battery.

[0071] S315. Obtain the load and remaining battery power of other vehicles located within the preset area; execute steps S316 and S318.

[0072] The preset area can be a mining area or a precise working area; this embodiment of the invention does not specifically limit it.

[0073] S316. Obtain a first number of vehicles with a load weight greater than or equal to a preset load weight and a remaining battery power greater than a preset battery power, and obtain a second number of vehicles with a load weight less than a preset load weight and a remaining battery power less than or equal to a preset battery power.

[0074] S317. When the first quantity is greater than the first preset quantity, or when the second quantity is greater than the first preset quantity, determine the current scheduling interval as the first scheduling interval and determine the current upgrade rate as the first upgrade rate; execute step S320.

[0075] The first scheduling interval is greater than the initial scheduling interval, and the first upgrade rate is less than the initial upgrade rate.

[0076] Specifically, in mining environments, multiple mining trucks often operate densely in the same area. If upgrade scheduling is based solely on the operating conditions of a single vehicle, situations may arise where the truck is lightly loaded with high battery power while surrounding vehicles are heavily loaded with low battery power. In such cases, if the truck adopts an aggressive upgrade strategy, the large amount of bus communication generated by its upgrade commands may cause electromagnetic interference or communication congestion to surrounding vehicles in hazardous operating conditions, triggering a chain of safety risks. This embodiment expands the basis for adjusting upgrade parameters from the operating conditions of a single vehicle to the group operating conditions of multiple vehicles within a preset area. After obtaining its own load and remaining battery power, it also obtains the load and remaining battery power information of other vehicles within the preset area. Then, it counts the number of vehicles in the preset area that are in a "heavy load and high battery power" state (i.e., the first number) or the number of vehicles in the "light load and low battery power" state (i.e., the second number). When the number of vehicles in either category exceeds a preset threshold (i.e., the first preset number), the current scheduling interval is directly determined to be a first scheduling interval greater than the initial scheduling interval, and the current upgrade rate is determined to be a first upgrade rate less than the initial upgrade rate. By setting the upgrade rate of this vehicle in conjunction with the status of each vehicle in the preset area, when there are many heavily loaded vehicles with high battery power (meaning dense operation and concentrated safety risks) or many lightly loaded vehicles with low battery power (meaning energy shortage and easy breakdown), the upgrade pace of this vehicle is proactively slowed down to a conservative mode. This not only avoids the potential interference of the vehicle's upgrade behavior to surrounding vehicles, but also reflects the safety collaboration concept of "individuals obeying the group" in mining operations, thereby improving the overall operational safety at the regional level.

[0077] S318. Obtain a third number of vehicles with a load weight greater than or equal to a preset load weight and a remaining battery power less than or equal to a preset battery power, and obtain a fourth number of vehicles with a load weight less than a preset load weight and a remaining battery power greater than a preset battery power.

[0078] S319. When the third quantity is greater than the first preset quantity, determine the current scheduling interval as the second scheduling interval and the current upgrade rate as the second upgrade rate; when the fourth quantity is greater than the second preset quantity, determine the current scheduling interval as the third scheduling interval and the current upgrade rate as the third upgrade rate.

[0079] The second scheduling interval is greater than the first scheduling interval, and the second upgrade rate is less than the first upgrade rate; the third scheduling interval is less than or equal to the initial scheduling interval, and the third upgrade rate is greater than or equal to the initial upgrade rate.

[0080] S320: Based on the collaborative upgrade package, control each controller to continue upgrading according to the upgrade priority at the current scheduling interval and the current upgrade rate.

[0081] Specifically, the system can also count the number of vehicles in two extreme conditions within a preset area: one is the number of vehicles in a "heavy load and low battery" state (the third quantity), and the other is the number of vehicles in a "light load and high battery" state (the fourth quantity). When the number of heavily loaded and low battery vehicles exceeds the first preset quantity, the current scheduling interval is set to a second scheduling interval greater than the first scheduling interval, and the current upgrade rate is set to a second upgrade rate less than the first upgrade rate, i.e., a slower upgrade pace than the conservative mode described above. When the number of lightly loaded and high battery vehicles exceeds the second preset quantity, the current scheduling interval is set to a third scheduling interval less than or equal to the initial scheduling interval, and the current upgrade rate is set to a third upgrade rate greater than or equal to the initial upgrade rate, i.e., a faster upgrade pace is adopted, increasing the upgrade rate. In this way, through the refined classification of vehicle operating conditions within the area, a tiered response to the upgrade strategy is achieved. When there are a large number of high-risk vehicles with heavy loads and low battery levels in the area, the upgrade speed of this vehicle is slowed down with the highest level of conservative strategy to minimize the interference of the upgrade behavior of this vehicle with the safety communication of high-risk vehicles. When there are a large number of safe vehicles with light loads and high battery levels in the area, it indicates that the overall operating environment of the area is good, and an aggressive upgrade strategy can be boldly adopted to make full use of the group's safety redundancy to improve upgrade efficiency. This makes the upgrade decision of a single vehicle dynamically linked with the overall safety situation of the area, realizing the optimization of upgrade scheduling from "single vehicle self-adaptation" to "regional collaboration".

[0082] For example, a second preset quantity can be set to be greater than 1 and less than or equal to the first preset quantity. For instance, assuming there are 20 vehicles operating in the preset area, the first preset quantity could be 12, and the second preset quantity could be 7. This requires a sufficient number of dangerous vehicles in the area to allow a conservative upgrade strategy, while a relatively small number of safe vehicles can trigger an aggressive upgrade strategy. This asymmetric threshold design makes upgrade decisions more cautious when leaning towards conservatism and more sensitive when leaning towards aggressiveness, aligning with the fundamental principle of "efficiency first, but safety as a safety net" in mining operations. It avoids blindly slowing down due to the presence of a few dangerous vehicles, while ensuring timely acceleration when a sufficient number of safe vehicles are present, thus achieving an optimized balance between upgrade efficiency and safety at the regional level.

[0083] Alternatively, in another feasible embodiment, a first preset number greater than 1 and less than or equal to a second preset number can be set. For example, assuming there are 20 vehicles operating in the preset area, the first preset number can be 7, and the second preset number can be 12. This requires a sufficient number of safe vehicles in the area to allow an aggressive escalation strategy, while a relatively small number of dangerous vehicles can trigger a conservative escalation strategy. This asymmetric threshold design makes escalation decisions more cautious when leaning towards aggressive and more sensitive when leaning towards conservative, conforming to the basic principle of "safety first, efficiency second" in mining operations. It avoids blindly accelerating due to the presence of a few safe vehicles, while ensuring a rapid response and conservative escalation when a small number of dangerous vehicles appear, thereby achieving an optimized balance between safety and efficiency at the regional level.

[0084] Optional, Figure 4 This is a flowchart of another collaborative upgrade method for multiple controllers in a vehicle provided by an embodiment of the present invention, such as... Figure 4 As shown, the flowchart of the collaborative upgrade method for multiple controllers in this vehicle includes: S410: Obtain the collaborative upgrade package and collaborative upgrade information provided by the OTA cloud management platform.

[0085] S420. After obtaining the collaborative upgrade package and collaborative upgrade information, the collaborative upgrade package is decrypted and verified.

[0086] S430. After the collaborative upgrade package passes verification, control each controller to start the upgrade sequentially according to the upgrade priority, initial scheduling interval and initial upgrade rate based on the collaborative upgrade package.

[0087] For example, after the collaborative upgrade package passes verification, the vehicle-mounted T-BOX terminal can also identify and determine the compatibility of the hardware and software versions of each controller using a compatibility adaptation algorithm. When all controller versions match the collaborative upgrade package and are determined to be compatible, the subsequent upgrade process continues. If any controller version is incompatible, the incompatibility information is reported to the OTA cloud management platform, which then re-pushes an upgrade package adapted to that controller version. By placing compatibility identification after decryption and verification, it ensures that the upgrade package used for compatibility determination is complete and tamper-proof, avoiding misjudgments due to damaged or illegal upgrade packages. Simultaneously, performing version matching detection after confirming the upgrade package's legitimacy accurately identifies version conflicts and triggers targeted adaptation pushes from the OTA cloud management platform, ensuring the security of the upgrade process and avoiding the risk of controller failure due to direct upgrades caused by incompatible versions.

[0088] S440: During the upgrade process of each controller, continuously acquire the vehicle's load, the remaining power of the vehicle's power battery, and the upgrade progress of each controller.

[0089] S450: Obtain the current scheduling interval and current upgrade rate based on load and remaining power.

[0090] S460: Based on the collaborative upgrade package, control each controller to continue upgrading according to the upgrade priority at the current scheduling interval and the current upgrade rate.

[0091] S470. Determine whether there is a difference in the upgrade progress of any two controllers that exceeds a first preset value; if yes, proceed to step S480; if no, return to steps S440 to S470.

[0092] S480: Controllers with faster upgrade progress should have their upgrades paused.

[0093] S490. Determine whether the difference in upgrade progress between any two controllers is less than the second preset value; if yes, return to step S460; if no, return to step S480.

[0094] Specifically, during the upgrade process controlled by the collaborative upgrade package, each controller is upgraded according to its upgrade priority, current scheduling interval, and current upgrade rate. The consistency of the upgrade progress of each controller is continuously monitored. This involves continuously acquiring the upgrade progress of each controller. When the progress difference between any two controllers exceeds a first preset value, the controller with the faster progress is proactively paused, while the controller with the slower progress continues its current upgrade state until the progress difference between all controllers is reduced to less than a second preset value. Only then is the upgrade of the paused controller resumed. By pausing the faster-progressing controller and allowing the slower controller to catch up, progress deviations can be proactively eliminated without interrupting the upgrade process of lagging controllers. This avoids severe progress misalignment caused by differences in controller hardware or upgrade package sizes, thereby eliminating the risks of mixed version operation and instruction conflicts. Setting the first preset value to be greater than the second preset value creates a hysteresis interval, preventing controllers from frequently switching between pause and resume states due to minor progress fluctuations. This ensures the stability and convergence of the upgrade process, ultimately achieving robust collaborative upgrades of multiple controllers even with inherent differences. In one exemplary embodiment, the first preset value can be 5%, and the second preset value can be 2% or 0, which can be set according to design requirements. This embodiment of the invention does not impose specific limitations on this.

[0095] For example, during the process of controlling each controller to upgrade according to the upgrade priority, current scheduling interval and current upgrade rate based on the collaborative upgrade package, if the difference in the upgrade progress of any two controllers is less than or equal to the first preset value, the current upgrade process can be maintained, and the vehicle's load, the remaining power of the power battery and the upgrade progress of each controller can be continuously monitored to dynamically adjust the upgrade rhythm according to the vehicle status.

[0096] And after the controller with the faster upgrade progress is suspended from upgrading, the upgrade rhythm of each controller is resumed when the difference in the upgrade progress of any two controllers is less than the second preset value. That is, the controllers continue to upgrade according to the upgrade priority, the current scheduling interval and the current upgrade rate according to the collaborative upgrade package.

[0097] For example, during the upgrade process of each controller, the process also includes: continuously acquiring upgrade anomaly information; upgrade anomaly information includes: network interruption time, battery temperature of the power battery, and remaining power of the power battery; when a minor vehicle anomaly is determined based on the upgrade anomaly information, each controller is controlled to pause the upgrade and cache the upgrade progress until the minor vehicle anomaly is resolved, at which point each controller is controlled to continue the upgrade at the current upgrade progress; when a serious vehicle anomaly is determined based on the upgrade anomaly information, each controller is controlled to stop the upgrade and automatically roll back to its respective stable version before the upgrade.

[0098] Specifically, during the upgrade process of each controller, abnormal vehicle conditions can be continuously monitored. Based on information such as network interruption time, battery temperature, and remaining battery power, it can determine whether the vehicle is in an abnormal state and, if so, determine the level of abnormality. Specifically, when a minor abnormality is detected, each controller pauses the upgrade and saves the current upgrade progress and received upgrade package data using a local cache (≥1GB). Once the abnormality is resolved, the upgrade resumes from the cached progress, thus achieving breakpoint resumption during the upgrade process. When a severe abnormality is detected, each controller stops the upgrade and automatically rolls back to its previous stable version. For example, assuming the network interruption time is t0, the remaining battery charge is SOC, and the battery temperature is T, the vehicle is determined to be in a slightly abnormal state when 20s ≤ t0 ≤ 30s, 20% ≤ SOC ≤ 30%, and 5℃ ≤ T ≤ 55℃ is satisfied; when at least one of the following conditions is satisfied, the vehicle is determined to be in a severely abnormal state; and when t0 < 20s, SOC > 30%, and 5℃ ≤ T ≤ 55℃ is satisfied, the vehicle is determined to be in a normal state. It can be understood that when the vehicle is determined to be in a normal state based on the abnormal information, the controllers maintain their current upgrade status.

[0099] In this way, through the collaborative design of hierarchical response and breakpoint resume, the upgrade progress is saved by local caching in the event of minor anomalies, avoiding the inefficiency of having to start from scratch after the upgrade is interrupted due to network fluctuations or temporary failures. This significantly improves the upgrade success rate and operation and maintenance efficiency in the weak network environment of the mining area. In the event of severe anomalies, the method of stopping and automatically rolling back is adopted to ensure that each controller is restored to the stable version before the upgrade, avoiding the controller being in a "semi-upgraded" unavailable state, and ensuring that the mining truck can still operate safely after the anomaly occurs. This gives the upgrade process adaptive fault tolerance capability to the complex working conditions of the mining area, and takes into account both upgrade reliability and vehicle safety.

[0100] In addition, when a vehicle malfunctions, the abnormal information can be sent to the OTA cloud management platform, and different levels of audible and visual alarms can be triggered according to the level of the abnormality.

[0101] For example, after the upgrade of each controller is completed, the self-verification results of each controller can be obtained; when the self-verification results of each controller are all successful upgrades, an upgrade success message is sent to the OTA cloud management platform; when the self-verification result of at least one controller is a failed upgrade, the controller that failed the upgrade is rolled back to the stable version before the upgrade.

[0102] Specifically, after each controller completes its upgrade, it performs a self-verification. The onboard T-BOX terminal collects the verification results from all controllers. When all controllers successfully verify, the upgrade success information is reported to the OTA cloud management platform. If at least one controller fails verification, only the controller that failed the upgrade is rolled back to its stable version before the upgrade. By performing self-verification after each controller completes its upgrade, potential hidden faults during the upgrade process (such as incomplete firmware burning, checksum errors, etc.) can be detected in a timely manner, preventing safety incidents caused by putting faulty controllers into operation. By adopting a differentiated strategy of rolling back only the failed controllers, rather than rolling back all controllers as a whole, the results of successfully upgraded controllers are preserved, and faulty controllers are precisely repaired. This minimizes the impact of the rollback operation on vehicle functions and recovery time, improving the fault tolerance and operational efficiency of the upgrade process.

[0103] When the self-verification result of at least one controller is an upgrade failure, the corresponding abnormal information can be sent to the OTA cloud management platform so as to synchronize the upgrade status of each controller with the OTA cloud management platform, which facilitates subsequent differentiated upgrade control. That is, when upgrading again, only the controllers that failed to upgrade can be upgraded.

[0104] Based on the same inventive concept, embodiments of the present invention also provide a vehicle, including: an on-board T-BOX terminal, a power battery, and multiple controllers, wherein the on-board T-BOX terminal is used to execute the collaborative upgrade method for multiple controllers in a vehicle provided in any embodiment of the present invention. Therefore, the vehicle provided in the embodiments of the present invention includes the technical features of the collaborative upgrade method for multiple controllers in a vehicle provided in any embodiment of the present invention, and can achieve the beneficial effects of the collaborative upgrade method for multiple controllers in a vehicle provided in any embodiment of the present invention. Similarities can be referred to the above description of the collaborative upgrade method for multiple controllers in a vehicle provided in the embodiments of the present invention, and will not be repeated here.

[0105] Based on the same inventive concept, embodiments of the present invention also provide a multi-vehicle collaborative upgrade system, including: an OTA cloud management platform and multiple vehicles provided by embodiments of the present invention located in a preset area. Therefore, the vehicle collaborative upgrade system provided by embodiments of the present invention includes the technical features of vehicles provided by any embodiment of the present invention, and can achieve the beneficial effects of vehicles provided by any embodiment of the present invention. Similarities can be referred to the above description of vehicles provided by embodiments of the present invention, and will not be repeated here.

[0106] The OTA cloud management platform is used to generate collaborative upgrade packages and collaborative upgrade information for each vehicle based on batch upgrade commands, and send each collaborative upgrade package and collaborative upgrade information to the T-BOX terminal in the corresponding vehicle; the collaborative upgrade information includes the upgrade priority, initial scheduling interval and initial upgrade rate of each controller.

[0107] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for collaborative upgrade of multiple controllers in a vehicle, characterized in that, include: Obtain collaborative upgrade packages and collaborative upgrade information provided by the OTA cloud management platform; The collaborative upgrade information includes the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller. After obtaining the collaborative upgrade package and the collaborative upgrade information, the collaborative upgrade package is decrypted and verified. After the collaborative upgrade package passes verification, each controller is controlled to start the upgrade sequentially according to the upgrade priority, the initial scheduling interval, and the initial upgrade rate, based on the collaborative upgrade package. During the process of upgrading each of the controllers, the vehicle's load and the remaining power of the vehicle's power battery are continuously acquired. The current scheduling interval and current upgrade rate are obtained based on the load and the remaining power. According to the collaborative upgrade package, each controller continues to upgrade according to the upgrade priority, the current scheduling interval, and the current upgrade rate.

2. The collaborative upgrade method for multiple controllers in a vehicle according to claim 1, characterized in that, Based on the load and the remaining power, the current scheduling interval and the current upgrade rate are obtained, including: When the load is greater than or equal to the preset load and the remaining power is greater than the preset power, the current scheduling interval is determined as the first scheduling interval, and the current upgrade rate is determined as the first upgrade rate; Alternatively, when the load is less than the preset load and the remaining power is less than or equal to the preset power, the current scheduling interval is determined to be the first scheduling interval, and the current upgrade rate is determined to be the first upgrade rate. Wherein, the first scheduling interval is greater than the initial scheduling interval, and the first upgrade rate is less than the initial upgrade rate.

3. The collaborative upgrade method for multiple controllers in a vehicle according to claim 2, characterized in that, Based on the load and the remaining power, the current scheduling interval and current upgrade rate are obtained, and the method further includes: When the load is greater than or equal to the preset load and the remaining power is less than or equal to the preset power, the current scheduling interval is determined to be the second scheduling interval, and the current upgrade rate is determined to be the second upgrade rate; the second scheduling interval is greater than the first scheduling interval, and the second upgrade rate is less than the first upgrade rate; When the load is less than the preset load and the remaining power is greater than the preset power, the current scheduling interval is determined to be the third scheduling interval, and the current upgrade rate is determined to be the third upgrade rate; the third scheduling interval is less than or equal to the initial scheduling interval, and the third upgrade rate is greater than or equal to the initial upgrade rate.

4. The collaborative upgrade method for multiple controllers in a vehicle according to claim 1, characterized in that, Before obtaining the current scheduling interval and current upgrade rate based on the load and the remaining power, the process includes: Obtain the load and remaining battery power of other vehicles located within the preset area; Based on the load and the remaining power, the current scheduling interval and the current upgrade rate are obtained, including: Obtain a first number of vehicles whose load capacity is greater than or equal to a preset load capacity and whose remaining battery power is greater than a preset battery power; when the first number is greater than a first preset number, determine the current scheduling interval as a first scheduling interval and determine the current upgrade rate as a first upgrade rate; Alternatively, obtain a second number of vehicles whose load is less than the preset load and whose remaining battery power is less than or equal to the preset battery power; when the second number is greater than the first preset number, determine the current scheduling interval as the first scheduling interval, and determine the current upgrade rate as the first upgrade rate; Wherein, the first scheduling interval is greater than the initial scheduling interval, and the first upgrade rate is less than the initial upgrade rate.

5. The collaborative upgrade method for multiple controllers in a vehicle according to claim 4, characterized in that, Based on the load and the remaining power, the current scheduling interval and current upgrade rate are obtained, and the method further includes: Obtain a third number of vehicles whose load is greater than or equal to the preset load and whose remaining battery power is less than or equal to the preset battery power; and obtain a fourth number of vehicles whose load is less than the preset load and whose remaining battery power is greater than the preset battery power. When the third quantity is greater than the first preset quantity, the current scheduling interval is determined to be the second scheduling interval, and the current upgrade rate is determined to be the second upgrade rate; the second scheduling interval is greater than the first scheduling interval, and the second upgrade rate is less than the first upgrade rate; When the fourth quantity is greater than the second preset quantity, the current scheduling interval is determined to be the third scheduling interval, and the current upgrade rate is determined to be the third upgrade rate; The third scheduling interval is less than or equal to the initial scheduling interval, and the third upgrade rate is greater than or equal to the initial upgrade rate.

6. The collaborative upgrade method for multiple controllers in a vehicle according to claim 1, characterized in that, The collaborative upgrade package includes a boot sector upgrade package, an application sector upgrade package, and a data sector upgrade package for each controller; Controlling each controller according to the collaborative upgrade package to continue upgrading at the current scheduling interval and the current upgrade rate according to the upgrade priority includes: According to the upgrade priority, the boot sector of each controller continues to upgrade according to its respective boot sector upgrade package at the current scheduling interval and the current upgrade rate; After the preset time for the upgrade of the guidance area of ​​each controller is completed, the application area of ​​each controller is controlled to upgrade according to the upgrade priority, based on its own application area upgrade package, at the current scheduling interval and the current upgrade rate. After the application areas of each controller have completed the upgrade within a preset time, the data areas of each controller are upgraded according to the upgrade priority, based on their respective data area upgrade packages, at the current scheduling interval and the current upgrade rate.

7. The collaborative upgrade method for multiple controllers in a vehicle according to claim 1, characterized in that, The process of upgrading each controller also includes: Continuously obtain the upgrade progress of each controller; If the difference in the upgrade progress of any two controllers exceeds a first preset value, the controller with the faster upgrade progress will pause the upgrade. Until the difference in the upgrade progress of any two controllers is less than the second preset value, return to the step of continuously obtaining the vehicle's load and the remaining power of the power battery during the upgrade process of each controller; Wherein, the first preset value is greater than the second preset value.

8. The collaborative upgrade method for multiple controllers in a vehicle according to claim 1, characterized in that, The process of upgrading each controller also includes: Continuously acquire upgrade anomaly information; the upgrade anomaly information includes: network interruption time, power battery temperature, and remaining power battery charge; When a minor vehicle anomaly is determined based on the upgrade anomaly information, each controller is controlled to pause the upgrade and cache the upgrade progress until the minor vehicle anomaly is resolved, and each controller is controlled to continue the upgrade at the current upgrade progress. When a serious abnormality is determined in the vehicle based on the upgrade anomaly information, each controller is controlled to stop the upgrade and automatically roll back to its respective stable version before the upgrade.

9. The collaborative upgrade method for multiple controllers in a vehicle according to claim 1, characterized in that, Also includes: After the upgrade of each controller is completed, the self-verification result of each controller is obtained; When the self-verification results of each controller are all successful upgrades, an upgrade success message is sent to the OTA cloud management platform; If the self-verification result of at least one of the controllers indicates that the upgrade has failed, the controller that failed the upgrade shall be rolled back to the stable version before the upgrade.

10. A vehicle, characterized in that, include: Vehicle-mounted T-BOX terminal, power battery, and multiple controllers; The vehicle-mounted T-BOX terminal is used to execute the collaborative upgrade method for multiple controllers in a vehicle as described in any one of claims 1 to 9.

11. A multi-vehicle collaborative upgrade system, characterized in that, include: An OTA cloud management platform and multiple vehicles as described in claim 10 located in a preset area; The OTA cloud management platform is used to generate collaborative upgrade packages and collaborative upgrade information for each vehicle based on batch upgrade instructions, and send each collaborative upgrade package and collaborative upgrade information to the T-BOX terminal in the corresponding vehicle; The collaborative upgrade information includes the upgrade priority, initial scheduling interval, and initial upgrade rate of each controller.

Images